После двух лет разработки опубликован релиз проекта GNU Mcron 1.2, в рамках которого развивается реализации системы cron, написанная на языке Guile. В новом выпуске проведена большая чистка кода - весь код на языке Си переписан и проект теперь включает только исходные тексты на языке Guile...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53549
Зачем это нужно при наличии systemd-cron?
Ну, как-бы Вы должны быть наоборот довольны - systemd-cron на "дырявом" C, а этот - вовсе нет, не на божественных Rust или Go, конечно, но всё-же.
Гнутые бороды не могут писать без дыр, так что толку от этого переписывания...
Главное, вы с Лёней можете.
Ага, значит, ты признаёшь, что дыр можно наклепать на любом языке, в т. ч. и на Rust?
Уважаемый гладко выбритый Fracta1L, не затруднит ли Вас продемонстрировать нам пример своего кода (на любом языке), полностью лишённого дыр?
А откуда ты знаешь что он ТАМ гладко выбрит?
Браво! Нет, не так -- БРАВО! :)
Михаил, а у вас же альтератор на этом? Разработчики довольны? Ну у вас хотя бы можно DSL для своих задач сделать, а для крона решение переехать на язык без статической типизации как-то не очень, не то, чтобы С был лучше.
А что такое systemd-cron?..
Это юниты типа timer или там уже еще что-то изобрели?
Да, это timer driven cron. Ничего так... забавно и даже работает.
Поддерживаю! Зачем пытаться писать то, что уже написан таким профессионалом, как Линус Потерринг. GNU и так уже прославились баш-портянками - время же за современными юнитами Линуса Поттеринга!
> Линус Потерринг
> Линустипун тебе…
Так это для Guix :)
>Зачем это нужно при наличии systemd-cron?Много минусов на опеннете, значит коммент резонный.
смотрим systemctl list-timers, дистрописатели то уже давно переключились на него.
И от себя - проверил, в отличие от дебиановокронового @reboot системдшный таймеры нормально работает.
Это просто пример никому не нужной программы, которую евангелисты Гуиле нашли и запердолили в исполняемый файл и делают вид, что на этом недоязыке можно написать системнеы утилиты. Просто попытка показать, что их сиситема не унылое позабытое ... а хрень на которой можно что-то даже полезное сделать. Впрочем кроме этого ничего на Guile полезного вроде бы больше и не написано. Такой вот язык для одной программы крон и то ставить ее можно тольок в случае полного заболевания головы или уничтожении оригинального крона
Внезапно но systemd-cron ой как нафик не упал в ну огромном количесве оборудования. В подовляющем я бы сказал (от общей массы) по причине что как минимум systemd там нет и никогда не будет и быть не может.
>написанная на языке GuileLinux написано не на Guile! Фатальный недостаток! Срочно переписать!
Думаю, Фабрис Беллар, который написал виртуалку на JS, смог бы и ядро на Guile.
и зачем этот Лисп?
Как минимум чтобы тыкать носом таких как я, когда мы будет ехидно спрашивать "Ну и что там написано-то на этом вашем самом лучшем в мире скобко-расставителе?"
"вместо постоянного мониторинга времени в Mcron применяется выстраивание заданий в линейную очередь c определением задержек между вызовом каждого элемента очереди"И что они будут делать если оно запустится до установки времени. или время кто-то установит в процессе работы. Да и что-то мне подсказывает, что процесс определения задержек не сильно отличается по ресурсам от постоянного мониторинга времени. Там же точность нужна до секунд.
> "вместо постоянного мониторинга времени в Mcron применяется выстраивание заданий в линейную
> очередь c определением задержек между вызовом каждого элемента очереди"
> Да и что-то мне подсказывает, что процесс определения задержек не сильно отличается по
> ресурсам от постоянного мониторинга времени. Там же точность нужна до секунд.Например, Вы выставили время запуска через 10 минут. В случае постоянного мониторинга процесс будет просыпаться за это время 599 раз, проверять всю очередь (в нашем примере в очередь одно Ваше задание), и запустит его только на 600 раз. В случае их подхода - он проснётся один раз - через 10 минут. А теперь можно посчитать, что будет, если надо запускать раз в неделю или раз в месяц.
Планировщик, тоже потребляет ресурсы. В классическом кроне процедура отсчитывающая секунды и проверяющая нет ли заданий для запуска не сильно напрягается.
> Планировщик, тоже потребляет ресурсы. В классическом кроне процедура отсчитывающая секунды
> и проверяющая нет ли заданий для запуска не сильно напрягается.В смысле?
формально там, по ресурсам что-то типа:
sleep_time = calc_time(when);
sleep(sleep_time);
do_job();в стандартном кроне, что-то вроде:
sleep_time = calc_time(when);
while (sleep_time > 0)
sleep(1);
do_job();т.е. будут дополнительные накладные расходы на sleep_time-1 системных вызовов. Понятно что на самом деле всё гораздо сложнее, но я это в контексте исходной предпосылкой с одним заданием.
Помимо прочего, система может проанализировать, что работающих процессов нет и сбросить частоту и много ещё чего поделать для обеспечения экономии энергии, т.е. обеспечить, например, большую экономию энергии батарей для ноутбуков и прочих мобильных устройств.
"Понятно что на самом деле всё гораздо сложнее, но я это в контексте исходной предпосылкой с одним заданием."
Вот именно. Сферические кони весьма хороши в вакууме. На практике же классический что-то никто не выбрасывает, хотя режимы энергосбережения существуют уже десятки лет. Сабж же заявляет, что он лучше в плане энергосбережения, но что-то не видно особых сравнений.
> "Понятно что на самом деле всё гораздо сложнее, но я это в
> контексте исходной предпосылкой с одним заданием."
> Вот именно. Сферические кони весьма хороши в вакууме. На практике же классический
> что-то никто не выбрасывает, хотя режимы энергосбережения существуют уже десятки лет.
> Сабж же заявляет, что он лучше в плане энергосбережения, но что-то
> не видно особых сравнений.Остаётся только надеяться, что авторы в итоге выложат результаты бенчмарков. Другое дело, что их выигрыш в одном может быть потерян в другом. Например, т.к. используется интерпретатор, то некоторые вещи могут наоборот большего времени, чем если бы был использован компилятор и работал нативный код.
Просто с точки зрения работы ядра, оптимизация крона это такая мелочь по сравнению со всем остальным, что почти никак не повлияет на общее энергосбережение. Надо же один процесс просыпается один раз в секунду, в то время как ядро наносекундами оперирует. Плюс в случае с mcron вы будете иметь n (число заданий) спящих тредов, между которыми нужно будет переключаться, а это тоже ресурсы.
Каких ещё тредов? Один тред, в нём - очередь. Классический вариант для эмбеда того же - не на схеме, понятно, но логика точно эта. Минималистично, удобно, надёжно.
С точки зрения ядра всё складывается из вот таких "почти".
> Просто с точки зрения работы ядра, оптимизация крона это такая мелочь по
> сравнению со всем остальным, что почти никак не повлияет на общее
> энергосбережение. Надо же один процесс просыпается один раз в секунду, в
> то время как ядро наносекундами оперирует. Плюс в случае с mcron
> вы будете иметь n (число заданий) спящих тредов, между которыми нужно
> будет переключаться, а это тоже ресурсы.У меня как у нуба вот какой вопрос: в системе уже стоит cron, на него ещё всякие компоненты системы могут полагаться, может ли mcron полностью заменить его во всех аспектах?
Потому что если его ставить дополнительно, в том же дебиане с зависимостями он ещё 47 Мб пространства отжирает
> Просто с точки зрения работы ядра, оптимизация крона это такая мелочь по сравнению со всем остальным, что почти никак не повлияет на общее энергосбережение. Надо же один процесс просыпается один раз в секунду, в то время как ядро наносекундами оперирует.Система в спячке, но раз в секунду её надо вывести из спячки, дать поработать процессу, и отправить систему обратно спать. Чёт мне не кажется, что это будет так уж бесплатно, как ты описываешь.
> Плюс в случае с mcron вы будете иметь n (число заданий) спящих тредов, между которыми нужно будет переключаться, а это тоже ресурсы.
Откуда ты вычитал про спящие треды? Как я понял из описания, он закидывает в единый список структурки типа { .wake_time = ???, .cmd = "???" }, сортирует их по wake_time, выбирает первый, и уходит в сон, пока не придёт время запускать первый .cmd.
Уже сейчас можно посмотреть powertop например.
>На практике же классический что-то никто не выбрасываетПро tickless kernel слышал? Это примерно то же самое, 10 лет уже используют.
> Сферические кони весьма хороши в вакууме. На практике же классический что-то никто не выбрасывает, хотя режимы энергосбережения существуют уже десятки лет.Если не выбрасывают и мы не знаем причины, почему не выбрасывают, то наш долг выбросить, и посмотреть, что произойдёт: а вдруг все не выбрасывают его только потому, что не знают, почему другие не выбрасывают? Если же есть какая-то разумная причина для сохранения "классического" подхода, то по крайней мере мы её узнаем, и в отличие от всех остальных будем знать.
> sleep_time = calc_time(when);
> sleep(sleep_time);
> do_job();В таком кроне если кто-то выключил систему во время выполнения команды sleep(sleep_time), а потом включил её до истечения времени sleep_time, то команду do_job() уже будет некому запустить.
А в стандартном кроне если выполнение команды назначено на 5-тысячный год от рождества Христова, то на оставшиеся 3 тысячи лет ноутбук можно выключить и надеяться на то, что потомки его ко времени назначенного задания таки включат и в этом случае задание выполняться таки начнёт! Нужно оно там будет потомкам или не нужно - это другой вопрос. :-)
ps:
Ноутбук за это время скорее всего уже несколько раз "сгниёт". Но потомки его создадут заново. Причём может быть уже в соседней галактике. А может быть даже внутри VirtualBox и вообще только ради исторического и археологического интереса, ну и как дань уважения предкам :-).
>> sleep_time = calc_time(when);
>> sleep(sleep_time);
>> do_job();
> В таком кроне если кто-то выключил систему во время выполнения команды sleep(sleep_time),
> а потом включил её до истечения времени sleep_time, то команду do_job()
> уже будет некому запустить.Прошу прощения, не совсем понял о чём Вы. Если Если выключить во время выполнения sleep(), а потом включить до его истечения - так cron при включении ведь заново запуститься, и рассчитает время ожидания исходя из текущего времени запуска. вроде как с этой стороны проблем быть не должно.
> Прошу прощения, не совсем понял о чём Вы. Если Если выключить во
> время выполнения sleep(), а потом включить до его истечения - так
> cron при включении ведь заново запуститься, и рассчитает время ожидания исходя
> из текущего времени запуска. вроде как с этой стороны проблем быть
> не должно.А. Ну да. Если в случае перезапуска крона предусмотрен перасчёт времени до ближайшего задания, то тогда всё нормально.
> Планировщик, тоже потребляет ресурсы. В классическом кроне процедура отсчитывающая секунды
> и проверяющая нет ли заданий для запуска не сильно напрягается.прошу прощения, не дописал. А отредактировать не могу. Для крона получится:
sleep_time = calc_time(when);
while (sleep_time > 0)
{ sleep(1);
sleep_time--;
}
do_job();
[/codee]
А в стандартном кроне реально подобным образом сделано? Или это домыслы на основании новости?Я не пытаюсь подъ@%нуть, если что.
Просто мысль отсортировать задания по времени до наступления события, как минимум, чтоб не проверять каждый раз всю очередь - вроде бы настолько очевидна, что как-то сомнительно что до этого не додумались за столько лет. А если очередь заданий сортировать, то уж практически сразу приходит мысль, что зачем "просыпаться" периодически для бесполезных проверок, если тупо по первому элементу сразу видно через сколько наступит ближайшее событие и раньше просыпаться большого смысла нет...
Либо есть что-то ещё, для чего надо "просыпаться" даже заведомо "зная", что задания выполнять не понадобится, либо стандартный крон все-таки устроен не так примитивно, мне так кажется.
А почему никто не удосужился просто посмотреть? Это же проще всего.
Ubuntu 20.04, vixie cron 3.0pl1-136ubuntu1
Выдача strace:
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=60, tv_nsec=0}, 0x7ffc840b1930) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1535, ...}) = 0
stat("crontabs", {st_mode=S_IFDIR|S_ISVTX|0730, st_size=4096, ...}) = 0
stat("/etc/crontab", {st_mode=S_IFREG|0644, st_size=1042, ...}) = 0
stat("/etc/cron.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/etc/cron.d/popularity-contest", {st_mode=S_IFREG|0644, st_size=190, ...}) = 0
stat("/etc/cron.d/anacron", {st_mode=S_IFREG|0644, st_size=285, ...}) = 0
stat("/etc/cron.d/sysstat", {st_mode=S_IFREG|0644, st_size=396, ...}) = 0
stat("/etc/cron.d/atop", {st_mode=S_IFREG|0644, st_size=217, ...}) = 0
stat("/etc/cron.d/e2scrub_all", {st_mode=S_IFREG|0644, st_size=201, ...}) = 0
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f85d0b9eb10) = 3867
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=59, tv_nsec=0}, {tv_sec=58, tv_nsec=996789973}) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3867, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG, NULL) = 3867
wait4(-1, 0x7ffc840b1314, WNOHANG, NULL) = -1 ECHILD (Нет дочерних процессов)
rt_sigreturn({mask=[]}) = -1 EINTR (Прерван системный вызов)
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1535, ...}) = 0
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=59, tv_nsec=0}, 0x7ffc840b1930) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1535, ...}) = 0
stat("crontabs", {st_mode=S_IFDIR|S_ISVTX|0730, st_size=4096, ...}) = 0
stat("/etc/crontab", {st_mode=S_IFREG|0644, st_size=1042, ...}) = 0
stat("/etc/cron.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/etc/cron.d/popularity-contest", {st_mode=S_IFREG|0644, st_size=190, ...}) = 0
stat("/etc/cron.d/anacron", {st_mode=S_IFREG|0644, st_size=285, ...}) = 0
stat("/etc/cron.d/sysstat", {st_mode=S_IFREG|0644, st_size=396, ...}) = 0
stat("/etc/cron.d/atop", {st_mode=S_IFREG|0644, st_size=217, ...}) = 0
stat("/etc/cron.d/e2scrub_all", {st_mode=S_IFREG|0644, st_size=201, ...}) = 0
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=60, tv_nsec=0},
----------
Делайте выводы сами, все понятно :)
Это если заданий немного. Да и то есть сомнения, что при малом кол-ве заданий выигрыш заметен.
Кроме того, надо хотя бы раз в минуту проверять сдвиг реального времени от синхронизации. То есть просыпаться, даже если заданий почти нет. И вести пересчёт таймеров ожидания запуска в списке, если сдвиг произошёл. Плюс если локалтайм сменился - добро пожаловать в ад :)
> Это если заданий немного. Да и то есть сомнения, что при малом
> кол-ве заданий выигрыш заметен.
> Кроме того, надо хотя бы раз в минуту проверять сдвиг реального времени
> от синхронизации. То есть просыпаться, даже если заданий почти нет. И
> вести пересчёт таймеров ожидания запуска в списке, если сдвиг произошёл. Плюс
> если локалтайм сменился - добро пожаловать в ад :)В clock_nanosleep() есть TIMER_ABSTIME - можно ждать сразу до назначенного времени (времени ближайшего к выполнению задания), а дальше это уже больше проблемы ядра. По поводу localtime-а - тут, наверное, действительно может быть проблема.
Сигнал, EINTR и отсутствие remain. Мммм... Не уверен, что ABSTIME хороший выбор для планировщика.
Конечно, сигнал крону - это скорее редкость, хотя и не такая уж, crontab всяко должен сказать "reload plz".
upd. can restarted я не прочёл, прежде чем написал, да, ABSTIME можно.
Если задания отсортированы, то не надо пересчитывать весь список - можно реализовать так, что будет достаточно пересчитать только время до первого элемента списка. Можно ли "немного про#@$ть" время запуска ближайшего задания в угоду экономии "пробуждений" - вопрос...Смена локалтайма может доставить проблем независимо от того сортировано оно или нет. Часто ли меняется локалтайм? Но даже если часто - если есть задания с высокой периодичностью то это спокойно отловится и скомпенсируется при выполнении ближайшего задания и будет условно "незаметно". Если все задания с низкой периодичностью, то относительная ошибка может быть тоже условно "незаметна" (относительная погрешность времени запуска будет малой). Тут снова тот же компромисс: либо оперативная компенсация всяких "чудес" с текущим временем, либо экономия на "холостых" пробуждениях. "Насколько важна точность по времени запуска заданий" - ответ на этот вопрос, имхо, и определяет как лучше делать планировщик.
Можно, например, как вариант, штатный запуск заданий делать на основе сортировки (точно зная через сколько надо просыпаться), но если время до ближайшего задания больше какого-то порога (компромисс = точность времени запуска заданий), то планировать дополнительное "холостое" пробуждение для анализа не изменилась ли обстановка и т. п.Можно с ходу придумать с десяток всяких подобных вариаций, ухищрений и оптимизаций. Это относительно несложно реализовать и вроде бы довольно очевидно, поэтому мне кажется что уж, как минимум, до подобного всяко додумались ещё в незапамятные времена (и, думаю, неоднократно).
Оверинжиниринг!
> Ключевой особенностью проекта является ... В периоды между активацией заданий mcron полностью неактивен. Подобный подход существенно снижает накладные расходы при работе cronЭкономия на спичках
Спичка здесь, спичка там... Глядишь, а вот уж и лес сэкономлен.
Достопочтенные комментаторы OpenNet, меня интересует ваше авторитетное мнение. Какая, на ваш взгляд, самая лучшая, придуманная и быстрая DE в среде Linux? Существует ли она? Не шучу, мне правда интересно
bash
быстро, удобно
и я не шучу - для тех кто юзает крон, баш вполне себе ДЕ
Как будто, cron нельзя юзать пользуясь KDE.
Ну он же флейма хотел, так что нет, никакой не bash, а zsh! (и ещё надо gremlin@ позвать, втопит за tcsh)
fish shell. Можно-молодежно.
> молодежноШел 2004 год, я был молодым, а ты так вообще был в яслях, на опеннете с лором вышла новость про будущего конкурента bash'у под названием fish
Идет 2020 год, я полностью седой дядька, а ты пишешь про молодежность fish'а
Смешно
command.com из-под dosbox -- прост и удобен.
bash разжирел за последние 10 лет.для текста выбираю screen и tcsh,
для X - jwm (возможно, найдется лучше).
И в чём же он разжирел?
> И в чём же он разжирел?в потреблении RAM и CPU, очевидно же.
Linux Mint MATE, ничего лучше ещё не нашёл, хотя пробовал много чего.
Ещё один не отличает DE, IDE и KDE.
Xfce.
emacs
> Подобный подход существенно снижает накладные расходы при работе cronну хорошо бы тогда чтоб показали насколько процентов компьютер в итоге разгрузился
на mcron
по сравнению с vixiecronоптимизаторы хрЕновы :-) (оптимизировали там где легко, а не там где узкое место :))
Пишете, надеюсь, из узкого места или ещё не дошли?
надо же какой тонкий юмор :-)
Двенадцатиперстный.
Я выбираю https://github.com/cronie-crond/cronie все остальные шляпа.
Cronyism
Я вот жду, когда у них появится система сборки на Guile.
А до меня вчера дошло при разглядывании очередного однопотокового выхлопа шмяка, что бы стоило сделать.Одноклассника autoconf/cmake и подобных, только параллелящегося. Например, поверх того же make.
Но поскольку я понимаю, что в этом классе софта даже не чайник -- то и делать не стану; а жаль даже немножко...
уже https://www.gnu.org/software/make/manual/html_node/Guile-Int...
meson + ninja. и ничего делать не надо
Есть guile-встройка у gmake (её только не всегда собирают).
Посмотреть практическое использование (за пределами hello world)
мне не удалось: не нашёл. А посмотреть было бы интересно.
О нафлудили-то!Юзал когда-то, еще на GuixSD вроде. Насколько могу припомнить, у Mcron больше фичей, чем тут указано.
как-то ради интереса пробовал этот mcron: при ошибке в конфигурации выдает простыню стек трейса на лишпе.
> лишпе.лиспе, там „С“.
лишп машт флоу!
флуд
Специально исковеркал
В словаре английского указано, что "to lisp" переводится как "шепелявить". У Пратчетта все Игори были лисперами, lisp'али безбожно.
На самом деле это "шепелявить наоборот", говорить "с" вместо "ш". Для русского такой дефект речи близко к невозможен, потому что у нас "ш" -- сравнительно редкий звук. А для английского -- только в путь. Так что скорее уж "сепелявить".
> написанная на языке GuileИ кто это развивать будет кроме полутора сумасшедших бородатых «альтернативщиков»? Код, в особенности развиваемый сообществом, должнн быть написан максимально просто и понятно. А все эти потуги на «правильные» (с точки зрения сумасшедших) языки обрекают проект на провал.
Если есть готовый заказчик, который башляет за решение, то привязка к экзотике - это гарантированный сбыт в нужную сторону на определённое время.
Ты это про GNU, наркоман?
> И кто это развивать будет кроме полутора сумасшедших бородатых «альтернативщиков»?Точно! Хоть бы на javascript, дебилы, переписали)))
Проблема в том, что никакого мейнстрима, который был бы мелок и давал чистый красивый код, нет. Lua разве что, но так себе мейнстрим и так себе качество кода. Питон подразумевает адовый рантайм, JS - тот ещё урод. компилируемые они брать не захотели и в этом что-то есть.
Питон можно без рантайма.
Питухонский код выполняется на виртуальной машине. Жаба точно такая же. Ты вообще о чём?
> Питухонский код выполняется на виртуальной машине. Жаба точно такая же. Ты вообще
> о чём?Сам по себе интерпретатор там дохрена и больше лёгкий (а запуск его мгновенный), тормозит только код который можно и выкинуть при желании.
и тогда оно ничего уметь не будет. Толку-то?
Зачем тебе что-то уметь в мать его обёртке над ядром?
> «правильные» (с точки зрения сумасшедших) языкиЭто синдром утёнка: в Беркли всех студентов-первокурсников лиспом портят.
Странно. Оригинальная статья с мотивацией 2003 года. А ведь есть (для сравнения функциональности/архитектурных решений) всякий anacron, или fcron (который перекрывает функциональность классики и anacron, а начинается где-то в 2000-м). А если порыться, то ещё, наверное, всяких реализаций найти можно.Т.е. главное --- написано на guile?
> Т.е. главное --- написано на guile?Написано на Guile И используется в Guix(SD), который.. [RTFM]
который есть Лисп?
Scheme
Все комменты не читал, но не одобряю. Я нашего Столлмана люблю, но убил бы только за то, что он в любой проект свою реализацию LISPа пропихивает...
Хмм... Он даже в Emacs Guile так и не подтянул. Хотя вялотекущая деятельность там, кажется, ещё есть.
Вася, шёл бы с миром...
Есть, конечно. Протянем еще правильные скобочки куда нада!
Вот они, анонимные аналитики Опеннета во всей красе))Причем тут Столлман - создатель Emacs - в котором Emacs Lisp, и Guile, расскажи-ка. Ты дурбэцило знаешь, сколько всего Лиспов есть? ;)
Ну, с 2000 несколько реализацийю. А ты?
В смысле свою? Он автор Emacs - вот там, действительно, весьма свой лисп с приветами из 70-х в виде динамического связывания и т.п.Схему - придумал не RMS, не им она стандартизована и даже сам проект Guile - не он начал.
Она не его, Guile довольно плохая реализация Scheme: ни r7rs в день отгрузки, ни натива, ни образов. Вдобавок украдена.
> ни нативаПорой это как раз хорошо.
> Она не его, Guile довольно плохая реализация Scheme: ни r7rs в день отгрузкиЭто вы вообще об чем? r7rs поддерживается.
> Вдобавок украдена.
Это еще у кого?
YAC? Велосипед.