>>25316
И при чём тут разработка?

>>25322
Предлагаешь в /b/ это обсуждать?

>On the practical level, Guix provides pre-compiled packages which can be a huge time-saver compared to Gentoo
О минусах тактически умолчено

>Portage does not let you configure features that were not thought of in advance by the packager
>Conversely, Guix gives you full customization for everything, albeit with a bit more Scheme code
То есть написать ебилд и написать схемовый код - 2 большие разницы, в которой написание арбитрарного костыля лучше компонента с абстрактным EAPI?

>Moreover, Portage suffer from the same aforementioned issue with the lack of proper support for multiple versions. Indeed, USE flags significantly increase the magnitude of the issue
Как относятся флаги к версиям?
О слотах автор не знает?

Конечно с лиспами, хурдом и фсф интереснее никсоса, но такие статьи только отталкивают и все заявленные ключевые фишки кажутся оторванными от реального мира реализации

Да кому нужна вся эта хрень. Нужен максимально простой стек, чтобы в облако добавить и контейнеры запускать.

>>25343

>О минусах тактически умолчено
Это же не детальный анализ что бы купить гентушников.

>То есть написать ебилд и написать схемовый код - 2 большие разницы, в которой написание арбитрарного костыля лучше компонента с абстрактным EAPI?
Декларативно описывать зависимости на полноценном языке программирования > всё остальное.

>Как относятся флаги к версиям?
>О слотах автор не знает?
Ну, не у всех версий одни и теже флаги могут быть. Лично я о слотах ничего не знаю.

Что ты хочешь узнать о guix?

Пробовал пользоваться Guix, но не осилил.

Проблема была в нерабочем WiFi модуле и в том что я пытался настроить OpenBox не разу им не пользовавшись.

После этого поставил NixOS и с ней всё пошло куда бодрее. Ставил версию 20.09 и обновился до 21.05. Но после обновления ноутбук стал работать хуже и я решил попробовать что-нибудь другое (Artix если интересно).

Ещё разобраться в Nix мне было куда проще чем в Scheme. Может быть потому что по Nix документация была сразу под рукой, а в Guix подразумевается что вы уже знаете Scheme или пойдёте его учить по другим источникам.

К тому же NixOS имеет прекрасную документацию по всем настройкам.

Или может быть я просто дурачок.

Идея лежащая за этими двумя проектами очень интересная, буду следить за развитием.

>>25700

>Пробовал пользоваться Guix, но не осилил. Проблема была в нерабочем
>WiFi модуле и в том что я пытался настроить OpenBox ни разу им не
>пользовавшись.

Аналогично, но перед этим была практика установки дебиана без блобов,
так что знал, что придётся купить патч-корд для подключения сети по
ethernet (полезная кстати штука!). Но потом понял [как поставить ядро с
блобами] и опыт сразу улучшился, правда обновление базовой системы
вместе с ядром довольно напряжное по CPU и времени занятие, так что
именно базовую систему обновляю редко, а обновление пакетов получаю
через

guix pull' для получение обновлений именно пакетного менеджера,

не ОС, и после этого 

guix upgrade' собственно для получения новых
пакетов. И всё без sudo!

>После этого поставил NixOS и с ней всё пошло куда бодрее. Ставил версию
>20.09 и обновился до 21.05. Но после обновления ноутбук стал работать
>хуже и я решил попробовать что-нибудь другое (Artix если интересно).

Очень жаль, что ушел из ОС на базе функциональный пакетных менеджеров.
Вроде как я сразу тоже ничего не понял, но второй заход, уже с
пониманием основных концепций, прошёл проще.

>Ещё разобраться в Nix мне было куда проще чем в Scheme. Может быть
>потому что по Nix документация была сразу под рукой, а в Guix
>подразумевается что вы уже знаете Scheme или пойдёте его учить по
>другим источникам.

Нуу, довольно спорная тема. Даже очень.

>К тому же NixOS имеет прекрасную документацию по всем настройкам. Или
>может быть я просто дурачок.

Скорее всего ментальная система, сформированная опытом работы с отличным
от проекта GNU документацией, как-то препятствует поиску необходимой
информации. Перекладывание ответсвенности на "абстрактного себя-дурачка"
не приблизит исправление этой, на мой взгляд, проблемы. А может и
действительно (хотя замечаю это редко) в документации чего-то не хватает
или что-то не так. А может нужная часть инфомация не переведена, а
специфичные из предметной области дистрибутиво-строения термины не
совсем понятны через переводчики.

Ещё раз – не ищите абстрактную проблему, а пытайтесь понять глубже
какой результат нужен и какие препятствия возникают. Не исключено, что
императивный образ мышления о работе ОС сформировал такую позицию, что
проблема А решается инструментом Б при помощи инструкции Ц, хотя в
действительности даже проблемы А может не быть (маловероятно, например
разрешение завсимостей), или она решается не тем инструментом (чаще, к
примеру в guix сервисами управляет shepherd, а отложенными задачами
mcron, в отличие от монолита systemd), или она решается не теми
инструкциями (очень часто, я с первого раза все операции с пакетами
совершал через sudo, хотя это абсолютно не то как стоит использовать
функциональные пакетные менеджеры).

>Идея лежащая за этими двумя проектами очень интересная, буду следить за
>развитием.

А можно не только следить, но и использовать функциональный пакетный
менеджер вместе(!) с уже существующим системным (более того, можно
использовать guix на nixos, ровно как и наоборот, только как там с
сервисами я не знаю, но из всех знакомых с кем общался, говорят что опыт
положительный). Nix ставиться через [одну команду], guix есть в паре
дистрибутивов по типу [недавно вышедшего дебиана] и [некоторых других].

[как поставить ядро с блобами] https://willschenk.com/articles/2019/installing_guix_on_nuc/

[одну команду] https://nixos.org/download.html

[недавно вышедшего дебиана] https://packages.debian.org/stable/admin/guix

[некоторых других] https://repology.org/project/guix/versions

>>25703

> Но потом понял [как поставить ядро с блобами]
> This command will take forever (around 1 hour) mainly because it’s compiling the linux kernel and other fun stuff.

Спасибо, но компилировать ядро я не согласен. Так как это займёт вечность, как указано выше.

> Перекладывание ответственности на "абстрактного себя-дурачка"

Возможно тогда повлияло стечение обстоятельств, лень читать огромный мануал и т.д и т.п. В NixOS сразу описаны настройки для конкретных программ "Чтобы сделать то-то и то-то надо заменить это на это". Возможно в мануале по Guix это всё тоже есть, но как я сказал выше я не осилил его до конца.

> использовать функциональный пакетный менеджер вместе(!) с уже существующим системным

Этот вариант я видел довольно часто. Устанавливаешь минимальный дистрибутив, а все пакеты потом накидываешь через Guix или Nix. Может быть позже тоже так сделаю.

> Пакет: guix (1.2.0-4)
> rec: systemd загрузчик системы и служб

Не очень нравится, что оно завязано на systemd или shepherd. В данный момент интересно попробовать что-то для меня новое, например openrc.

>>25704
> This command will take forever (around 1 hour)
> forever
> 1 hour
Ххаха. Ха ха ха. Сразу видно человек Хром на Атлоне не компилял. И ничего толще 100 гБ ЛЗМой не жал. Даже Хрюшу на древний Бендиум и то, наверно, не ставил.

@c --texinfo--
@c This is part of the GNU Guile Reference Manual.
@c Copyright (C) 2008, 2010, 2011, 2013, 2018, 2020
@c Free Software Foundation, Inc.
@c See the file guile.texi for copying conditions.

@node История
@section Краткая история Гиля

Гиль это результат исторического процесса, одновременно и код и
сообщество хакеров. Когда редактируешь код, иногда полезно знать его
историю создания, о предыдущих решениях и будущем направлении.

Разумеется, истинная история Гиля была написана хакерами за
хакингом, а не писателями за письмом, так что мы завершим раздел
заметками о текущем статусе и будущей траектории работы.

@menu

• Тезис Имакса::
• Ранние дни::
• Схема, сопровождаемая многими::
• Врменная линия значимых релизов Гиля::
• Статус::

@end menu

@node Тезис Имакса
@subsection Тезис Имакса

История Гиля это история превнесения опыта разработки имакса во
многие программы на системе ГНУ.

Имакс, когда он был выпущен от ГНУ в 1984 году, был новым ответом на
проблему о том "каким образом писать программы". Тезис имакса
заключался в концентрации на удовольствии от написания программ,
основанных на ортогонально стоящих ядре, написанном на языке низкого
уровня и высокоуровнего языка расширений.

Язык расширений способствует созданию асширяемых программ, которые
легко адаптируются к разным пользователям и в течении времени.
Доказателство этого может служить в текущем существовании и
разработки имакса, охватывающее более четверти века.

Помимо того, что он предлагает средства для изменения существующих
программ, язые программирования так же хорош и сам по себе.
Программы, созданные "в стиле Имакса" приятно создавать и дополнять
новыми функциями их авторам.

После того как опыт разработки Имакса был оценён многими, многие хакеры
стали задумываться как распространить свой опыт для оставшейся системы ГНУ.
Было ясно, что саый простой способ Имаксификации программы было внедрение
в эту программу реализацию общего языка программирования.

@node Ранние дни
@subsection Ранние дни

Том Лорд был первым, кто целенаправленно сконцентрировал усилия на
встраиваемый в рантайм язые, который он назвал "ГЕЛ", GNU Extension
Language.

ГЕЛ был продуктом конвертирования SCM, реализации схемы Эббри Джаффера,
во что более менее соответсвующее требованию встраиваемого языка.
(В свою очередь SCM базирования на реализации Георгия Карретта, SIOD'е)

Лорд уговорил Ричарда Столлмана признать ГЕЛ официальным языком расширений
проекта ГНУ. Это было естественно, учитывая что Скима была более чистой и
современной версией чем Имакс Лисп. Среди аргументов было то, что когда-нибудь
Гиль будет настолько развит, что будет способен исполнять другие языка,
в особенности Имакс Лисп.

Из-за того, что происходил конфликт имён с другим языком програамировния,
Джим Бленди проедложил новое называние для ГЕЛ: Гиль. К тому, что он
являлся рекурсивным акронимом, Гиль также хитро наследовал имена своих авторов,
"Планнер", "Коннивер", и "Скимер". Последний был сокращён до "Ским" из-за
ограничения на 6 символов в имени файла на старых операционных системах.
Ну и "Гиль" напоминал "Гай-эль", или "Гай Л. Стил", кто вместе с Геральдом
Сассманом изобрели оригинальную Скиму.

Примерно в то же самое время когда Гиль (тогда ГЕЛ) был готов для
публичного релиза, другой язык расширений, Tcl, набирал популярность.
Многие разработчики находили преимущество Tcl в том, что его синтаксис
напоминал шелл, а так же он имел хорошо написанную библиотеку для отрисовки графики,
Tk. Так же в это время шло массовое продвижение языка как "универсального языка расширений".

Ричард Столлман, основной разработчик ГНУ Имакса, имел свой взгляд на то
каким должен быть язык расширений, и Tcl для него не подходил на данную роль
так же, как и Имакс Лисп. Он опубликовал критику в новостную группу comp.lang.tcl
разожгав этим самым одну из легендарных святых войн в интернете.
Как часть дискуссии, названную потом "Tcl Wars", он аннонсировал
намерение Фонда Свободного Программного Обеспечения продвигать Гиль как
язык расширений для проекта ГНУ.

Довольно общей ошибкой считать Гиль как реакцию на Tcl. Да, Гиль
был представлен в то же время, что и "Tcl Wars", но Гиль был создан
по причине, находящейся вне этой полемики. Потребность в иощном языке программирования,
занимающего свою нишу как прослойка между расширениями
существющих программ и в качестве динамической среды программирования
существует и до сих пор.

@node Схема, сопровождаемая многими
@subsection Схема, сопровождаемая многими

Смотря на все реализации, кажется, что реализации Скимы соответсвует
к сопровождащим его людям в отношении N-к-1. Это говорит о том, что
те, кто релазиовывают скиму делают это в результате неких событий, но
так же что жизненный цикл таких Ским соответствует периоду жизни индвидуального
разработчика.

Гиль в этом плане не таков.

Том Лорд разрабатывал Гиль с его год с половиной или типо того, соответсвующая
примерно с конца 1994 года по середину 1996 года. Тогда выпускаемые релизы
были переходным этапом между SCM как самостоятельной программой и Гилём как
повторно используемой, встроенной библиотеке, но пронесённая сквозь огромное
количество фич: встраеваемый Tcl и Tk, средства для компиляции и дизассемблирования
Джавы, добавление Си подобного синтаксиса, созадние системы модулей и старт
создания богатого ПОСИКС интерфейса.

Только часть этих функций осталась в Гиле. Тут мы проникаем в
напржённую грань между предоставлением маленького, встраиваемого
языка и между тем, который имеет всякие фишки (по типу графического интерфейса),
который скорее нужен современному Имаксу. В конце концов, когда Гиль
начал набирать популярность, команда разработки решила сфокусироваться на глубине,
документации и ортогональности, более чем на ширине функций. Это
изначально было целью Гиля, хотя существует широкий спектр сторонних
библиотек для Гиля.

Джим Блендли руководил этим периодом стабилизации в течении трёх лет
до конца 1999 года, когда и он перешёл на другие проекты. С тех пор
Гиль перешёл под командное управление. В первой группе был Мацей Стаховяк,
Микаэль Юрфельдт и Мариус Фольмер, где Фольмер продержался дольше всех.
К концу 2007 года, Мариус большей частью перешёл на другие вещи, и
Ниэль Джеррам и Людвик Куртес взяли на себя главную ответсвенность за сопровождение.
К Нейлу и Людвику присоеденился Энди Винго во второй половине 2009,
позволя Нейлу отойти от всего этого, и где-то там ещё подсоединился
Марк Вивер. Проведя в роли более пяти лет, Марк так же отошёл, оставив
Людвика и Энди как текущих сопровождающих Гиля на январь 2020 года.

Конечно же, большая часть существенной работы для Гиля была сделана
огромным количеством контрибутуров, которых слишком много что бы тут
упоминуть, но без которых мир был более скудным местом.

@node Статус
@subsection Статус, или: Нужна ваша помощь

Гиль достиг многого из того, что он ставил своей целью, но ещё
осталось очень много того что надо сделать.

Сущестует до сих пор старая проблема привнесения в существующие программы
Имакс-лайк опыт. Гиль в этом достиг больгих успехов, но до схи пор
большая часть программ в системе ГНУ без Гиль интеграции.

Внедрение Гиля в такие программы требуют таких инвестиций "хакерской энергии",
которые окупаются только тогда, когда налаженная интеграция с Гилём настолько
хороша удалась, что позволяет внедрит новое поведение в программу. Таков
будет очень ценный вклад новых хакеров: взять существующую программу,
которую вы используете и которую хорошо знаете, подумать над тем, что
она не умеет делать, и понять каким путём можно интегрировать Гиль и
реализовать свою хотелку на Гиле.

Со временем, однако, этот тип распространения может обратиться вспять,
когда программы будут запускаться Гилём, а не наоборот, в конце концов приведя к
имаксификации всей системы ГНУ. Это причина по которой давались названия
модулям в области видимости @code{ice-9}, отссылка на вымышленную
субстанцию Курта Вуннегута из рассказа "Кошачья колыбель", выступающая
как изначальный кристал для кристализации огромного числа ПО.

Неявным во всей этой дискуссии, является идея того, что динамические языки
в какой-то мере лучше языков по типу С. В то время как языки по типу С
имеют своё место, Гиль берётся за этот вопрос и говорит да, Скима намного
более выразительная чем С, и на ней интереснее писать. Осознание этого ведёт к
тому, что хочется всё больше писать кода на Скиме, чем на любом другом языке.

В наши дни можно писать расширяемые приложения полностью на языков высокого
уровня, и через байт код или нативную компиляцию скорость, увеличению скорости
оборудования и вызывам внешних функций из языка высокого уровня. Таковы системы
по типу Смоллтолка и на основе Common Lisp. В то время как сейчас уже много приложений
на чистом гиле, в прошлом многим пользователям приходилось использовать С для
некоторых задач: взаимодействие с библиотеками, которые не имеют готового
интерфейса для Гиля и для некоторых задач, требующих высокой скорости.
С приходом нативной генерации кода через JIT компилятора в третьей версии Гиля,
большинство старых приложений теперь могут быть обновленны что бы убрать
код на С, кодом на Скиме.

До сих пор, даже если приложение полностью написано на Гиле,
иногда вы хотите предоставить расширять своё приложение на языке
более близком к С или Питону. Другая интересная идея для реализации
это скомпилировать (допустим) Питон в Гиль. Эта идея не взята из
ниоткуда: для примера посмотрите на IronPyton или JRuby.

Так же существует и сам Имакс. Поддержка Гилем Имакс Лиспа достигла превосходного уровня
корректности, надёжности и скорости. Однако до сих пор существует работа
по окончанию его интеграции в сам имакс. Это привнесёт огромное количество
отличных вещей в Имакс: нативные потоки, реальная объектная система, больше
сложных типов, более чистый синтаксис, и доступ ко всем Гиль расширениям.

В конце концов, в этом мире очень много кода исполняется в веб-браузерах,
что даёт основания спросить себя о том какова будет судьба Гиля как
Веб Клиента. С изобретением WebAssembly, уже обоснованно можно считать
его целью для сборки, которая присутствует на почти всех пользовательких
устройствах. Особенно с учётом будущих нововведений в виде разрешения
хвостовой реккурсии, ограниченных продолжениях, обслуживаемых-ГЦ объектов,
Скима может снова найти место в веб-браузере. Вперёд и в бой же!

@node Врменная линия значимых релизов Гиля
@subsection Врменная линия значимых релизов Гиля

@table @asis
@item guile-i --- 4 февраля 1995
SCM, превращённая в библиотеку.

@item guile-ii --- 6 апреля 1995
Добавлена низкоуровневая система библиотек. Была добавлена поддержка Tcl/Tk,
позволяющая расширять Tcl через Scheme и наоборот. Была улучшена поддержка POSIX
и была эксперементальная заглушка интеграции с Джавой.

@item guile-iii --- 18 августа 1995
Си подобный синтаксис, ctax, улучшен, но по большей части в этом релизе происходило
деление Гиля на части.

@item 1.0 --- 5 января 1997
@code{#f} было отделено от @code{'()}. Была добавлена кооперативная, на уровне
пользователя, многопоточность. Отладка на уровне исходников стала ещё более
полезна. Была начата работа над мануалами для пользователя и разработчка.
Система модулей получила высокоуровневый интерфейс, который в той или иной
форме используется и по сей день.

@item 1.1 --- 16 мая 1997
@itemx 1.2 --- 24 мая 1997
Поддержка Tcl/Tk была разделена на несколько пакетов, какой остаётся
и до сих пор. Гиль стал более совместим с SCSH, и более полезен для
скриптования UNIX. Libguile теперь может быть собран как разделяемая библиотека.
Сторонние расширенния, написанные на С, можно подгружать через динамический линкинг.

@item 1.3.0 --- 19 октября 1998
Редактирование в коммандной строке стала ещё более удобная благодаря
использованию библиотеки Readline. Изначальная поддержка интернализации
через мульти-байтовую строку была убрана; только через 10 лет хорошая
интернализация будет внедрена в проект. Изначальная поддержка Имакс Лиспа
добавлена, были добавлены флуиды, а так же порты получили улучшенную
поддержку файловых дискрипторов.

@item 1.3.2 --- 20 августа 1999
@itemx 1.3.4 --- 25 сентября 1999
@itemx 1.4 --- 21 июня 2000
Добавлен большой список лисповых особенностей: хуки, Коммон Лисповский
@code{format}, опциональные и именованные аргументы в процедурах,
@code{getopt-long}, сортировки, случайные числа, а так же огромное
количество исправлений и улучшений. Гиль так же получил интерактивный
дебаггер, интерактивную помощь и улучшенный бэктрейс.

@item 1.6 --- 6 сентября 2002
Гиль получил поддержку стандарта R5RS, а так же определённое число
SRFI модулей. Система модулей получила расширение, позволяющее программно
определять что именно нужно и изменять имена. Объектная система GOOPS
была добавлена в основную поставку Гиля.

@item 1.8 --- 20 февраля 2006
Гиль перешёл с собственной реализации длинной арифметики на
использование библиотеки GMP, и так же была добавлена поддержка
точный рациональных чисел. Встроенные на уровня пользователя потоки
были заменены в пользу POSIX упреждающих потоков, которые использовать
реальную многопроцессорность. Была добавлена поддержка gettext,
С API была почищенна и по большей части была приведена в порядок.

@item 2.0 --- 16 февраля 2010
В Гиль была добавлена виртуальная машина, вместе с связанной с ней
компилятором и инструментарием. Наконец была добавленна поддержка
интернализации в терминах юникода, локали и libunistring. Запуск Гиля
стало более контролируемо и отлаживаемо в Имаксе через Geiser.
Имакс получил фичи, которые уже были во многих Скимах: SRFI-18 потоки,
гигиеничные на уровне модулей макросы, профайлер, трейсер, отладчик,
интеграцию с SSAX XML, байтвекторы, динаический FFI, ограниченные продолжения,
версии модулей и частичная поддержка R6RS.

@item 2.2 --- 15 марта 2017
Виртуальная машина, представленная в версии 2.0, полностью переписана,
вместе с большей частью иснтрументария и инструментов. Это ускорило многие
програмы на Гиле, так же как и уменьшило время загрузки и использования памяти.
Поддержка POSIX многопоточности улучшено, стэк стал динамически расширяемым,
порты получили возможность работать в небокирующем режиме.

@item 3.0 -- января 2020
Гиль получил возможность нативной генерации кода через простой
во-время-работы (ВВР) компиляции, чему последовало увеличение скорости
виртуальной машины. Сам по себе компилятор получил определённые оптимизации:
инлайнинг верхнеуровневых связываний, улучшенная оптимизация замыканий, улучшенная
распаковка целых чисел и значений с плавающей запятой. Была добавлена поддержка R7RS,
а поддержка R6RS улучшена. Механизм исключений (throw и catch) был переписан в соответствии
с как это описано в SRFI-34.
@end table

@c --texinfo--
@c This is part of the GNU Guile Reference Manual.
@c Copyright (C) 1996, 1997, 2000, 2001, 2002, 2003, 2004, 2010, 2015, 2018
@c Free Software Foundation, Inc.
@c See the file guile.texi for copying conditions.

@node Представление данных
@section Представление данных

Скима это скрыто-типизированный язык; это означает что система не может,
в общем случае, определить тип данного выражения в процессе компиляции.
Типы начинают пониматься только во время работы. Переменные не имеют
фиксированный тип; переменные могут в один момент времени хранит пару,
целое число в следующий, и вектор на тысячу элементов в следующий.
В противовес этому значения, а не переменные, имеют определённый тип.

Для того, что бы реалзиовать стандартные процедуры в Скиме по типу
@code{pair?} или @code{string?} и иметь возможность собирать мусор,
представление каждого значения должно содержать информации для точного
определения его типа в процессе работы. Обычно, Скима использует эту информацию
что бы определить не применятся ли функция к неподходящему типу значения
(как например, взятие @code{car} у строки).

Потому как переменные, пары и векторы могут хранить значения разных типов,
реализации Ским используют однородное представление для значений ---
единый тип, достаточно большой что бы хранить как полные данные, так и ссылку на
полные данные, вместе с необходимой информацией о типе.

Следующие разделы представят простую систему типов, а затем уточнят пару
тонкостей в значительных местах. В заключение мы обсудим определённые выборы,
сделанные в Гиле для сборщика мусора и представления данных.

@menu

• Простое представлние::
• Быстрые целые числа::
• Дешёвые пары::
• Консервативный сборщик мусора::
• Тип SCM в Гиле::

@end menu

@node Простое представление
@subsection Простое представление

Простейший тип представления значений Скимы через С -- это представить
каждое значение как ссылку на структуру, содержащую индикатор типа,
за которым следует объеденённое за ним реальное значение. Допуская, что
@code{SCM} это название нашего общего типа данных, мы можем записать:

@example
enum type @{ integer, pair, string, vector, ... @};

typedef struct value SCM;

struct value @{
enum type type;
union @{
int integer;
struct @{ SCM car, cdr; @} pair;
struct @{ int length; char elts; @} string;
struct @{ int length; SCM *elts; @} vector;
...
@} value;
@};
@end example
Где на месте многоточий будут перечислены остальные типы в Скиме.

Это представление любой семантике в Скиме. Если @var{x} это @code{SCM} значение:
@itemize @bullet
@item
Что бы проверить, что @var{x} это число, мы можем написать @code{@var{x}->type == integer}.
@item
Что бы узнать его значение, мы можем написать @code{@var{x}->value.integer}.
@item
Что бы проверить, что @var{x} это вектор, мы можем @code{@var{x}->type == vector}.
@item
Если мы значем, что @var{x} это вектор, мы можем написать
@code{@var{x}->value.vector.elts[0]} что бы обратиться к его cпервому элементу.
@item
Если мы знаем, что @var{x} это пара, мы можем написать
@code{@var{x}->value.pair.car} что бы получить её перый элемент.
@end itemize

Что тут происходит?

>>26490
Когда мне скучно на работе я перевожу документацию по имплементации Guile https://www.gnu.org/software/guile/manual/html_node/Guile-Implementation.html

@node Быстрые целые числа
@subsection Быстрые целые числа

К сожалению, приведенное выше представление имеет серьёзный недостаток.
Что бы вернуть целоые число, выражение должно аллоцировать @code{struct value},
инициализировать его что бы оно представляло целое число и возвратить
цказатель на него. Помимо этого, доставание значение целого числа требует
отссылки к памяти, что намного дольше на большинстве процессоров
чем ссылка на регистровую память. Так как целые числа очень популярны,
их представлние очень дорого стоит с точки зрения вреени доступа и памяти.
Целые числа должны быть очень дешёвыми для создания и манипуляции.

Одним из возможных решений с этой точки зрения таково, что для большинсва
архитектур, аллоцированные в куче данные (т.е. те, которые получаются в результате
вызова @code{malloc}), должны помещаться в ячейки по 8 байт. (В не зависимости так
ли это на самом деле для конкретной архитектуры, мы можем написать наш собственный
аллокатор для объектов @code{struct value}, которые гаранитрует это). В таком случае,
мы можем быть уверены, что последние три бита адресса структуры будут нулями.

Уже имея средства для реализации улучшенного представления целых чисел, мы можем
утверждать следущее:
@itemize @bullet
@item
Если последние три бита значения @code{SCM} это нули, тогда значение SCM
это ссылка на @code{struct value}, и оно обрабатывается как и раньше.
@item
Иначе, значение @code{SCM} представляет целое число, чьё значение можно получить из верхних
трёх битов.
@end itemize

Здесь предложена реализация на С данного утверждения:
@example
enum type @{ pair, string, vector, ... @};

typedef struct value SCM;

struct value @{
enum type type;
union @{
struct @{ SCM car, cdr; @} pair;
struct @{ int length; char elts; @} string;
struct @{ int length; SCM *elts; @} vector;
...
@} value;
@};

#define POINTER_P(x) (((int) (x) & 7) == 0)
#define INTEGER_P(x) (! POINTER_P (x))

#define GET_INTEGER(x) ((int) (x) >> 3)
#define MAKE_INTEGER(x) ((SCM) (((x) << 3) | 1))
@end example

Заметьте, что обработка целого числа @code{integer} больше не является членом перечисления @code{enum
type}, и из объединения бы убрали элемент @code{integer}.
Вместо этого мы используем макросы @code{POINTER_P} и @code{INTEGER_P}
для грубой классификации значений на целые числа и не-целые числа, и
проводим проверки на типы как было и раньше.

Снова ответим на вопрос, заданный ранее (не забывая, что @var{x} это значение @code{SCM}):
@itemize @bullet
@item
Что бы проверить, является ли @var{x} целым числом, мы можем написать @code{INTEGER_P (@var{x})}.
@item
Что бы найти его значение, мы можем написать @code{GET_INTEGER (@var{x})}.
@item
Что бы проверить, что @var{x} это вектор, мы пишем:
@example
@code{POINTER_P (@var{x}) && @var{x}->type == vector}
@end example
Имея новое представление, мы сначала должны убедится, что @var{x} мы
должны убедиться что это указатель перед тем как получить по нему значение.
@item
Если мы значем, что @var{x} это вектор, мы можем написать
@code{@var{x}->value.vector.elts[0]} что бы обратиться к его
cпервому элементу, как и было ранее.
@item
Если мы знаем, что @var{x} это пара, мы можем написать
@code{@var{x}->value.pair.car} достать от туда первый элемент, как
и ранее.
@end itemize

Это представние, по сравнению с первым, позволяет нам работать
с целыми числами более эффективно. Например, @var{x} и @var{y}
действительно целые числа, мы можем получить их сумму следующим образом:
@example
MAKE_INTEGER (GET_INTEGER (@var{x}) + GET_INTEGER (@var{y}))
@end example
Теперь, арифметика целых чисел не тербует аллоцирования или ссылок на память.
Большинство существующих Ским систем в действительности реализуют в добавок к этому
и помимо этого другие операции, используя более эффективные алгоритмы, но этот гайд
не про перемалывание битой. (Подсказка: как вы определите что перегрузили до большого числа?
Как бы вы это сделали на ассемблере?) %!% Хотя кажется, что ассембли переводится "вручную".

@node Дешёвые пары
@subsection Дешёвые пары

Однако существует ещё одна проблема с которой придётся столкнуться.
Большинство куч в Скимах содержат пар больше чем других типов объектов.
Джонатан Рис однажды сказал, что куча состоит из пар на 45% в его реализации
Скимы, Scheme 48.Однако наше представление требует три @code{SCM} слова на одну пару ---
одно под слово, и ещё два под @sc{car} и @sc{cdr}. А есть ли какой нибудь способ представить
пару используя только два слова?

Давайте точнее определим чего мы хотим. Допустим, мы утверждаем следущее:
@itemize @bullet
@item
Если последние три бита значения @code{SCM} представляют собой нули -- @code{#b000}, тогда
это указатель, как всё и было ранее.
@item
Если последние три бита таковы: @code{#b001}, то верхние биты представляют целое число.
Это немного более строго чем раньше.
@item
Если последние три бита это @code{#b010}, то его значение, за
исключением трёх последних битов, содержит адрес пары.
@end itemize

Посмотрим на новый С код:

@example

enum type @{ string, vector, ... @};



typedef struct value *SCM;



struct value @{

  enum type type;

  union @{

    struct @{ int length; char *elts; @} string;

    struct @{ int length; SCM  *elts; @} vector;

    ...

  @} value;

@};



struct pair @{

  SCM car, cdr;

@};



#define POINTER_P(x) (((int) (x) & 7) == 0)



#define INTEGER_P(x)  (((int) (x) & 7) == 1)

#define GET_INTEGER(x)  ((int) (x) >> 3)

#define MAKE_INTEGER(x) ((SCM) (((x) << 3) | 1))



#define PAIR_P(x) (((int) (x) & 7) == 2)

#define GET_PAIR(x) ((struct pair *) ((int) (x) & ~7))

@end example

Заметьте, что @code{enum type} и @code{struct value} теперь содержат
только описания?? для вектора и строки; и целые числа и пары теперь
стали специальными случаями. Код выше так же подразумаевает, что
@code{int} достаточно большой что бы хранить указатель, что в общем
случае не так.

Наш список примеров теперь таков:
@itemize @bullet
@item
Что бы проверить, что @var{x} это целое число, мы, как и ранее, можем написать @code{INTEGER_P
(@var{x})}.
@item
Что бы получить его значение, нам, как и ранее, нужно выполнить @code{GET_INTEGER (@var{x})}.
@item
Что бы проверить, что @var{x} это вектор, мы пишем:
@example
@code{POINTER_P (@var{x}) && @var{x}->type == vector}
@end example
Нам до сих пор нужно убеждаться, что @var{x} это указатель на @code{struct
value} что бы получить значение по ссылке и проверить его тип.
@item
Если мы знаем, что @var{x} это вектор, мы можем написать
@code{@var{x}->value.vector.elts[0]} что бы обратиться к его
первому элементу, как и ранее.
@item
Мы можем написать @code{PAIR_P (@var{x})}, что бы определить, является ли @var{x} парой,
а затем написать @code{GET_PAIR (@var{x})->car} что бы обратиться к его первому значению.
@end itemize

Это изменение в представлении данных сокращает ипользование кучи на 15%.
Это так же делает проверку на пару дешевле, так как не надо ссылаться на
память; необходимо всего лишь проверить последние два бита у значения @code{SCM}.
Это может быть значительным при проходе по списку, что является
обычной опрецией в Ским системах.

Опять таки, большинство реально существующих Ским систем используют слегка
изменённые реализации; например, если GET_PAIR удаляет последние три бита из
@code{x}, а не маскирует их, оптимайзер часто может связать удаление
со смещением элемента структуры, чьё значение мы хотим получить, так что
изменённый указатель такой же быстрый, как немодифицированный.

>>26492
А нахрена здесь?

>>26496
Это же тред о гиксе, который написан на Гиле. Да и вообще мне так приятнее, когда сделал--выложил.

@node Консервативный сборщик мусора
@subsection Консервативный сборщик мусора

Помимо скрытого типизирования, одна из больших ограничений
реализаций Скимы в плане представлния данных это сборщик мусора.
Сборщик должен проходить каждый существующий объект в куче чтобы
определить какие объекты уже не живы что бы их можно было собрать.

Есть много разных способов для его реализации. Сборщик Гиля построен поверх
библиотеки, Богем-Демер-Вейзеровского консервативного сборщика мусора (БДВ-СМ).
БДВ-СМ "просто работает", по большей части. Но так как интересно, как же эта штука работает,
мы прикладываем сюда верхнеуровневое описание того, что делает БДВ-СМ.

Сборщик мусора имеет две логические фазы: фазу маркировки @dfn{mark}, в
которой перечисляется множество существующих объектов, и фаза @dfn{sweep},
в которой объекты, до которых сборщик не дошел на стадии маркировки, собираются.
Правильное функционирование сборщика зависит от того, сможет ли он обойти все живые объекты.

На стадии маркировки, сборщик сканирует системные глобальные переменные
и локальные переменные на стэке, что бы определить какие объекты
моментально доступны через код на С. Затем он сканирует эти объекты
что бы определить на что ссылаются уже они, и так далее. Сборщик устанавливает
логический бит @dfn{mark bit} на каждый объект, который он находит, так что
каждый объект проходится всего один раз. %!% Как понимаю, что бы не было рекурсии

Когда сборщик не может найти немаркированные объекты, которые
следуют за маркированными, он считает, что все объекты, на которых
нет метки, никогда не будут вызваны из программы (так как нет пути по
которому они могут быть вызваны ни через глобальную, ни через локальную
зону видимости) и поэтому их можно деаллоцировать.

Выше мы не описывали как сборщик определяет локальные и глобальные переменные;
как обычно, тут есть много разных подходов. Обычно, программист должен
поддерживать список указателей на все глобальные переменные, которые отссылаются
в кучу, и другой список, который содержит локальные переменные (существование
которых определенно входом и выходом из каждой функции) для работы сборщика.

Список глобальных переменных обычно не очень трудно поддерживать, потому как они
относительно редки. И напротив, поддерживать список локальных переменных
(по личному опыту автора) является ночным кошмаром разработчика. Поэтому,
БДВ-СМ @dfn{conservative garbage collection}, делающий использование локального
списка переменных ненужным.

Трюк, который используется в консервативном сборщике заключается в том, что
весь С стэк рассматривается просто как кусок памяти, подразумаевая, что
@emph{каждое} слово на нём, стэке, это указатель на кучу.
Поэтому, сборщик маркирует каждый объект, чей адрес лежит где-то на С стэке,
не понимая как это слово следует интерпритировать.

В дополнение к стэку, БДВ-СМ так же сканирует статичные секции с данными.
Это означает, что глобальные значения так же сканируются когда проверяются
все живые объекты Скимы.

Очевидно, что такая система иногда будет оставлять объекты, которые являются мусором,
и которые должны быть освобождены. На практике это не проблема, так как область консервативного
сканирования фиксированна. Ским стэк поддерживается отдельно от Си стэка, и сканируется
точно (в отличии от консервативного подхода). Управляемая СМ куча так же поделена
на части, которые могут содержать указатели (такие как векторы), и части, которые их
содержать не могут (такие как байтвекторы), ограничивая возможность воспринимать
сырое целоые число как ссылку на живой объект.

Все интересующиеся могут ознакомиться с БДВ-СМ на странице @uref{http://www.hboehm.info/gc/},
что бы получить больше информации о консервативных СМ, а так же о реализации
БДВ-СМ в частности.

@node Тип SCM в Гиле
@subsection Тип SCM в Гиле

Гиль разделяет все Ским объекты на две части: те, что способны полностью
поместиться в SCM и те, которым нужна куча.

Первый класс называется @dfn{немедленными}. Этот класс содержит малые целые числа,
знаки, булевые типы, пустой список, мифический объект конца файла (end-of-file object),
и некоторые другие.

Остальные, как не сложно догадаться, называются @dfn{не-немедленными}.
Они включают пары, процедуры, строчки, вектора и все другие типы данных
в гиле. Для не-немедленных, SCM слово содержит указатель на данные в куче,
вместе с остальными данными, которые хранятся в данных.

Эта секция покажет как SCM тип представлен и используется на Си уровне.
Интересующиеся могут заглянуть в @code{libguile/scm.h} для ознакомления с тем
как Гиль хранит информацию о типе.

Сейчас есть два базовых типа данных Си, через которые представлены данные в
Гиле: @code{SCM} и @code{scm_t_bits}.

@menu

• Отношения между Between SCM и scm_t_bits::
• Немедленные объекты::
• Не-немедленные объекты::
• Аллоцирование объектов на куче::
• Получение типа данных объекта на куче::
• Получение полей объектов на куче::

@end menu

>>26492
Понятно. А ты не из России? Просто из РФ сайт guix недоступен.

>>26524
Хороший человек сделал зеркало: http://guix.trop.in/
И сделал сборку с нужным сервером подстановок: https://trop.in/guix
(Но у меня так и не завелось)

(define-module (influx)

  #:use-module (web client)

  #:use-module (web uri)

  #:use-module (srfi srfi-9)

  #:use-module (srfi srfi-9 gnu)    ;records

  #:use-module (srfi srfi-11)        ;let-values

  #:use-module (srfi srfi-19)        ;new (current-time)

  #:use-module (srfi srfi-26)        ;cut

  #:use-module (ice-9 iconv)        ;decode utf8

  #:use-module (ice-9 match)

  #:use-module (json))



(define-record-type <influx>

  (influx url version)

  influx?

  (url influx-url)

  (version influx-version))



(define* (make-influx #:key

              (host "localhost")

              (port 8086)

              (version 1))

  (influx (build-uri 'http #:host host #:port port)

      version))



(define my/influx (make-influx #:host "ZZZZZ"))



(define* (create-db influx db #:optional (duration "30d"))

  (req influx (format #false "CREATE DATABASE ~a~a~a WITH DURATION ~a"

              #\" db #\"

              duration)))



(define (delete-db influx db)

  (req influx (format #false "DROP DATABASE ~a~a~a" #\" db #\")))



(define (show-databases-strings influx)

  (match (get-values (req influx "SHOW DATABASES"))

    (#(#(db-name) ...) db-name)))



(define (show-databases influx)

  (map (cut string->symbol <>)

       (show-databases-strings influx)))



(define (query-response-body influx query)

  (let*-values

      (((header body)

    (http-post (set-fields (influx-url influx)

                   ((uri-path) "/query")

                   ((uri-query) (format #false "q=~a" (uri-encode query))))

           #:decode-body? #false))

       ((response-alist) (json-string->scm (bytevector->string body "utf8"))))

    response-alist))



(define (get-values result-body)

  (match result-body

    [((series . #(((values . values-body) columns name))) statement_id) values-body]))



(define (get-result response)

  (match response

    [((result . #(result-body))) result-body]))



(define (req influx query)

  (get-result

   (query-response-body influx query)))



(define current-influx-db (make-parameter "RRRRRR"))

(define current-efs-session (make-parameter "XXXX"))



(define* (make-metric request-func name status tph sla #:key

               (db "business_metrics")

               (infdb (current-influx-db))

               (efs_session (current-efs-session)))



  (define response_time

    (let* ((start (current-time))

       (request (begin (sleep 1) request-func))

       (end (current-time))

       (diff (time-difference end start))

       (nanos (time-nanosecond diff))

       (seconds (time-second diff)))

      (round (+ (* seconds 1000)

        (/ nanos 1000000)))))

  

  (format #f

      "YYYYYYYYYYYYYY"

      db

      name

      status

      infdb

      tph

      sla

      response_time

      efs_session

      (string-append (number->string (time-second (current-time)))

         (format #f "~9,'0d" (random 999999999)))))