Common Lisp - заготовка для portable define-advice

Во-первых, вы уже пытаетесь оставить себя выше разработчиков Allegro, CMU, CCL и LW, утверждая, что адвайсы не нужны.

Прикол в том что разработчики Allegro написали пространный текст (#) о том что конкретно адвайсы надо похоронить наконец. И

We recommend that you replace any advice code you might have with fwrapper code

В рамках CMU была

extensions:encapsulate

* Deprecated features:
     - EXT:ENCAPSULATE and associated functions; use fwrappers instead.

А можно ли считать fwrap-еры адвайсами на этом фоне видимо обсуждать бессмыслено.

А можно ли считать fwrap-еры адвайсами на этом фоне видимо обсуждать бессмыслено.

Почему?

Моя секта проста: мне нравится инкрементная разработка как в CL, нравится, что он компилирует в маш.код., нравится пермиссивное лицензирование, нравятся макросы. Мне также нравится стат. типизация, нравится пошаговый отладчик. Я хочу всё вот это, но сделанное по-нормальному. Такого не сделано нигде, CL противится любым изменениям, поэтому я пилю свой язык. Если по ходу дела возникают полезные прототипы библиотек (например, define-advice), я про них пишу (раньше писал, во-всяком случае).

мне нравится инкрементная разработка

можно в Clojure двинуть.

компилирует в маш.код

racket/chez/chicken

пермиссивное лицензирование

С лицензированием у кложи все ок(у ракетки собственно тоже).

нравятся макросы

Макросы - да хоть в ским, хоть в кложу.

нравится стат. типизация

Стат. типизация - у самой кложи под капотом Java с той самой типизацией, можно через spec указывать явно, что тебе нужно, ну или typed-racket.

нравится пошаговый отладчик

Пошаговый отладчик возможен и в скиме, и в кложе.

Плюс, сообщество в Racket, Chicken и Clojure уже потеряли ощущение своей мегаэлитности и не смотрят на остальных, как на говно. Намного легче и приятнее общаться, чем с common lisp илиткой.

Clojure и Racket - это байткод, не люблю. Или я что-то упустил? Racket только собирается перейти на Chez и пермиссивную лицензию, вот тогда и будет предмет для разговора (Монк меня давно на него сманивает). Хотя на мой взгляд, Racket монструознее чем даже CL. Фич очень много, я, например, не осилил их цикл. Мне кажется, он перефичастый по сравнению даже с loop/iterate, притом мне его дизайн странен.

что хорошо в Racket - это syntax-objects, но я в своём Яре уже их аналог давно запилил. Отсутствие syntax-objects в CL и чтение кода непосредственно в дерево весьма затрудняет отслеживание преобразований исходного текста, а без этого опять же, сложно поддерживать макросы. Т.е. если читается 42 (С), то мы не знаем, где оно прочитано - информация об этом теряется в момент чтения из файла и потом её тяжело «тянуть». Поэтому, чтобы улучшить пошаговый отладчик для SBCL, я начал патчить компилятор таким образом, который завеодомо исключает возможное затягивание последующих версий SBCL. А поскольку SBCL состоит почти полностью из багов, то без этой возможности тяжко. Так разработка пошагового отладчика зашла в тупичок. Один человек в команде SBCL признался, что они тоже хотят отладчик «как в Visual Basic». Но в том же письме написал, что примитивы для отладчика там ненадёжны и что исправлять их займёт несколько месяцев. Короче, опять всё внутри кривое. Ну что же, посмотрим, каков в этом плане CCL. Хорошо то, что CCL замер и не развивается, поэтому будет легче поддерживать форк, если понадобится.

Chez интересен, да. Но на самом деле мне не нравятся сами скобочки. Вот примерно в 2010 году я опубликовал свою proga https://bitbucket.org/budden/budden-tools/commits/6746446ddd93ec632adce44ec93... и пытался её продвигать. Меня, конечно, смешали с говном. Не прошло и 7 лет, как подобный макрос под именем nest вошёл в состав uiop и он вовсю используется в коде asdf. Жаль, что моё имя не упомянуто. Я не смог отследить, откуда взялся этот nest и понять, придумали ли его раньше меня. Хотя вообще это нормально, что нормальные идеи воплощаются через 100 лет и заслуги приписываются не исходному автору, которого смешивают с говном. Мне главное это не забывать, а то можно и приуныть.

Т.е. то, что каждый let, flet, labels порождает отдельный уровень вложенности - это просто чудовищная потеря читабельности. Я думаю, это одна из причин, по которой лиспы хронически не стреляют: нечитабельное месиво из скобок настолько затрудняет поддержку, что мы видим слабость библиотек на CL, невзирая на мощь макросов и инкрементной разработки. Я пишу свой код примерно так:

(perga
  (:lett a (+ 2 2) integer)
  (flet f (x) (* x 4))
  (:@ mlvl-bind (foo bar) (find-symbol 'foo))
  и т.п.
  )

Это читается несравнимо легче.

И кроме того, Chez был открыт спустя год после начала моего проекта. Теперь несколько поздно. Если у меня появятся дальнейшие ресурсы, то я подробно рассмотрю возможность перехода на Chez. В принципе ещё интересен Oberon. Я скачал BlackBox - он гораздо более развит, чем SLIME. Есть врождённый гуй, к примеру, а в CL его нет по сей день. Но там замена может быть только на уровне модулей. Сообщество Oberon гораздо более живое, чем CL, думаю, я мог бы найти соратников. Кроме того, он чертовски компактен.

Ну и смотри, хочешь хороший лисп без скобочек и есть желание что-либо развивать - есть же Red.

Если ты понимаешь, что совершил ошибку в выборе технологий и будешь дальше копать в ее сторону, только потому что ты вложил много сил - то ты совершаешь ошибку.

Если тебе кажется, что с обероном дело пошло бы дальше и больше шансов закончить проект - то бери оберон и спасай свой проект.

Хотя на мой взгляд, Racket монструознее чем даже CL.

Чего? Было бы так, рантаймы CL развивались бы с бешеной скоростью и не было бы печали от видавших сырцы SBCL, что надо очко на британский флаг порвать, чтобы привести его в порядок.
А Ракетку очень скромное сообщество тянет. И после неё как-то не тянет CL использовать вообще. На Кложуру бы вернулся, но это жиромясокомбинат, натурально. Очень хорошо скроенный дизайн, но удобство управления её инфраструктурой как у угольного паровоза, как mv про Emacs выразился когда-то.

хороший лисп без скобочек

Factor

Мой проект на данный момент спасёт только хорошая порция денег, а её взять неоткуда. SBCL не годен, я сейчас добавляю поддержку CCL, чтобы законсервироваться на чуть более весёлой ноте, не более того. В Яре потихоньку набежало уже более 1мб сорсов (а я блин думал, что он очень маленький, сейчас первый раз померял). Очевидно, что на изучение альтернатив и переходы мне оставшегося месяца не хватит.

надо очко на британский флаг порвать, чтобы привести его в порядок.

За 17 лет вполне можно было бы. Но не было поставлено такой цели. Отсюда и результат. Как сказал stassats, «And SBCL has no goal, it's not an organization.»

mv хорошо об этой реализации отозвался как-то https://github.com/drmeister/clasp

Вроде оно LGPL. + построение в течение часа - двух - это убийство. И CCL, и SBCL строятся несколько минут у меня, весь мой код тоже собирается несколько минут.

Да и вообще, я слышал плохие отзывы об LLVM. Оно модно, да. Но что-то там было про потерю высокоуровневой инфы при трансляции из-за чего что-то плохо. Дальше не в курсе. Мой личный опыт с LLVM состоит в том, что я один раз его попробовал собрать и не смог.

В любом случае, всё это сейчас неактуально. Сейчас надо допилить поддержку CCL, и этот процесс близок к завершению.

Racket можно описать примерно одним словом - академическая. И этим все сказано. Куча несовместимых и подчас неудобных фич, тормозная реализация, примерно совсем нет упора на практические библиотеки. Вот и все.

Плюс сообщество абсолютно замкнутое, и во многом повторяют ошибки старых, докоммонлисповых, лиспов. (ооп etc)

Clojure это такой Go от мира лиспов, слишком простая если не сказать тупая. Тот этап, которые лиспы прошли где-то в конце 70х, а именно, скобки и хэши во все поля, фиксированный синтаксис, и все такое, в ней почему-то ставится во главу угла. Плюс Java, да, про это можно долго рассказывать. По факту, джавовской инфраструктурой то и не пользуются, зато имеют recur и прочие приколы. Впрочем как и любой тупой язык для масс, типа Go или Python, она пользуется популярностью(впрочем особо интересного на ней не пишут, один хрен).

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

По сюди единственный живой и нормальный лисп это CL. Да, у него есть проблемы, но утверждения это не отменяет. И это единственный лисп который не является тупиковой веткой развития всего семейства.

Пойми же ты, что CL законсервирован из-за поддержки Legacy. Хрен ты в нём что-нибудь изменишь.

Если «форкнуть CL», т.е. сказать «мы делаем свой любительский новый стандарт CL», забить на поддержку старых приложений и на мнение их пользователей - тогда можно его развивать. Но сообщество нужно будет набирать с нуля, и не факт, что сегодня ты многих наберёшь.

Развивающиеся языки - это Scala и Python, авторы которых взяли себе право ломать совместимость. Язык, в котором совместимость - главное - не может развиваться.

Но при таком мнении про типизированные хеш-таблицы и пошаговые отладчики я не вижу тех, кто мог бы в этом поучаствовать. Людей, как-то участвующих в обсуждении про CL - человека 3-4, и никто из них мне попутчиком не является, кроме Монка, которому и на Racket хорошо. Можете без меня скооперироваться, но я и в это не верю - также между собой пересрётесь :) Так что я тебе желаю дальнейшей счастливой гребли на галере .Net :)

Насчёт фиксированного синтаксиса - видимо, ты недостаточно много смотрел в исходники SLIME и реализаций. Если бы посмотрел, то понял бы, чем хорош фиксированный синтаксис.

Фактически SLIME не может существовать. То, что ты видишь - это мираж. Оно «как бы работает». Если же не создавать новых readmacro, пользоваться всегда одной таблицей чтения (стандартной для данной реализации), то можно построить башню из костылей, которая заставит SLIME более-менее работать.

Но популярные библиотеки этому пути не следуют.

Я ещё забыл упомянуть о том, что SLIME не может работать и из-за многопоточности. 2 года назад я нашёл, что room с многопоточностью несовместим. antares0 пытался меня с этим замести под коврик, но в конечном итоге так внятно и не ответил ничего. ПО сути, в мануале SBCL чётко написано, что многопоточность, вообще говоря, не работает. При этом SLIME многопоточен и в потоках пользователь может вызывать произвольный код. Т.е. его работа - это просто счастливое стечение обстоятельств, не более того.

Если будет время, я попробую перевести SLIME на один поток - может быть, тогда будет чуть более устойчивый фундамент для работы и под SBCL - хотя бы один фактор ненадёжности будет устранён. В конце-концов, JS и TCL спокойно живут в одном потоке.

Язык, в котором совместимость - главное - не может развиваться.

Жаба спокойно себе развивается.

нет упора на практические библиотеки

Да и в CL не особо, если не брать в расчёт всякие Allegro и т.п.

По факту, джавовской инфраструктурой то и не пользуются

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

не является тупиковой веткой развития всего семейства.

Может быть и не является, но Кложа его почти потопила. Если это аргументировать вакансиями на закордонном рынке.

Ладно. Скажем иначе: развитие такого языка сильно затруднено.

Да и в CL не особо, если не брать в расчёт всякие Allegro и т.п.

Все популярные либы в CL очень практичные, что compatibility layers, что веб-серверы, биндинги к чему-нибудь итд. В кложе, а я за ней плотно слежу, и вообще, и на митапах всяких, что не библиотека - так какое-нибудь говно вроде «зацените как мы сделали декораторы на DSL над хешами». Так и хочется спросить - вы в аутсорсе на основной работе, раз вам настолько делать нехрен?

Там что ни библиотека, то обёртка над какой-нибудь жабовской либой.

Не вижу ни одной обертки например тут: https://blog.takipi.com/the-top-100-clojure-libraries-in-2016-after-analyzing...

Может быть и не является, но Кложа его почти потопила. Если это аргументировать вакансиями на закордонном рынке.

Обычный хайп. Так же и сдуется, проходили уже. Ваканский и на php полно. Я вот например, на себя работаю, и по факту на любом проекте могу любой язык втащить, руководствуюсь исключительно практическими соображениями. Сейчас - дотнет, потому что и сервер и клиент по причинами сторонних компонентов, обязаны на винде находится. Но если будет выбор между CL и Clojure, на сервере, конечно, я ни секунды не сомневаясь выберу CL.

Хорошо, публично каюсь, что сильно преувиличил. Но:
#0 Ring — обёртка над Jetty.
Тут вообще явно заявлено:

#5 clj-http (and clj-time at #8) – Similarly to the top libraries in Java, clj-http, the wrapper for Apache HttpComponent, and clj-time, the wrapper for joda-time, take the spots at the top.

Quil — обёртка над Processing.

В кложе, а я за ней плотно слежу

Если ты аргументируешь, что Кложа — говно, на кой за ней следить тогда?

А можно ли считать fwrap-еры адвайсами на этом фоне видимо обсуждать бессмыслено.

Почему?

Посмотрев пристально на раскрыв def-fwrapper легко понять что он всего лишь сахар поверх

(setf (fdefinition|macro-fuction ...

И вот обсуждение. С одной стороны ты с уникальными адвайсами. Но половина перечисленых CL-ов уже больше 10-летия(!) как закопала этот несчастный трупик. С другой стороны оппонеты доказывающие их ненужность игнорируют факт что в opensource lisp-е на месте забытых адвайсов просто пишут вариации (setf (fdefinition

Если бы кто-то выковырял из cmucl открытый вариант fwrap то это бы сделало код немножко красивше, но функционально оно и сейчас работает за счет возможностей заложеных в стандарте.

Плюс, сообщество в Racket ... Clojure уже потеряли ощущение своей мегаэлитности и не смотрят на остальных, как на говно.

Просто забегают в треды про лисп и и кидают на вентилятр это самое г.. вперемежку с жиром :(

и не было бы печали от видавших сырцы SBCL

Я видел. Печали не понимаю. Покажите где хорошо. Некоторые исходники allegro видел вот там срашно своеобразно.

там библиотек вместе взятых еще меньше, чем стдлиба коммонлиспа. Сюда же chicken scheme.

В chiken-е библиотек сильно больше вышупомянутого stdlib-a. Как ты их считал?

Плюс, сообщество в Racket, Chicken и Clojure уже потеряли ощущение своей мегаэлитности

Может потому, что эти языки ничего из себя _не представляют_? Hint - в программировании, с 80-x _ничего придумано не было_.

Намного легче и приятнее общаться, чем с common lisp илиткой.

Первый шаг на пути в никуда. Начать оперировать словами «илитка». Особенно применительно к CL.

В слове элита ничего плохого нет, не так ли? Или уже и это вызывает сомнение?

<альтруизм>

Да, CL элитная система. И чтобы понять это и научиться ее использовать для себя придется потратить время. Но если есть желание, то СЛОЖНО, но можно.

Придется

a) Забить на рекламу на всех углах как популярен языки X,Y,Z и «смотри что мы могем». Забить на то, что в X,Y,Z _уже сейчас все легко_, иди к нам используй framework F1,F2,F3 и получай $ здесь и сейчас. А в CL - сложно и непонятно. b) Оторвать задницу от дивана и начать действовать c) Сделать что-то параллельно изучая d) Быть готовым, что ничего сразу не дастся и потребуется время

Могу добавить оптимизма, где-то на пункте с) когда что-то сделал и оно заработало, тебе уже будет наплевать на d) да и на все остальное.

</альтруизм>

По-другому не знаю как сказать. Можешь считать, что «илитка» опять что-то прокукарекала :)

Пойми же ты, что CL законсервирован из-за поддержки Legacy. Хрен ты в нём что-нибудь изменишь.
Если «форкнуть CL», т.е. сказать «мы делаем свой любительский новый стандарт CL», забить на поддержку старых приложений

Хм. Нынешний стандарт - это все-таки вторая версия. А лет за 10 до этого была и первая, прозваная cltl1. Которая от второй отличалась больше чем второй питон от 3-его. И ничего переехали, legacy не сломали. :use :cl как-раз оттуда пошло. Какой-то дохлый изменятор пошел, неуверенный:( А если умеешь только ломать от незнания матчасти, то ктож тебе доктор.

Развивающиеся языки - это Scala и Python, авторы которых взяли себе право ломать совместимость.

И это те языки которые тянут прикладную функциональность из jvm и C. На этой базе чож не ломать, все рано ключевой код вне этих языков и даже не на них написан. А вот если ты сломаешь работу чего-нибудь типа swing-а или gtk:) То могут ведь и прибить.

2 года назад я нашёл, что room с многопоточностью несовместим. antares0 пытался меня с этим замести под коврик, но в конечномитоге так внятно и не ответил ничего.

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

ПО сути, в мануале SBCL чётко написано, что многопоточность, вообще говоря, не работает.

По сути там написано что не все вызовы атомарны. Но твой вывод из этого конечно прекрасен.

Я вот что-то не готов с тобой согласиться. Насколько я понял, fwrap в Allegro хорош тем, что он меняет код, а не просто symbol-function. Как это согласуется с приведённым тобой макрорасширением, я сказать не могу. Как минимум, создание frwap в Аллегро состоит из двух частей - сначала его определяешь, а потом вызываешь с ним fwrap. Вот что пишут в Allegro в обосновании fwrap-ов:

This means that for example if #'foo were encapsulated, but had been previously captured and stored in a variable to be later funcalled, the funcalled function does not execute the encapsulating functionality.

Раз они это пишут, то подразумевается, что fwrap свободен от этого недостатка. Хотя мне некогда искать, где бы это прямо утверждалось, и даже выяснять, правда это или нет.

fwrapper-ы в CMUCL определены здесь: https://github.com/rtoy/cmucl/blob/master/src/code/fwrappers.lisp

Похоже, что и вправду в CMUCL действуют по стандарту. А я ожидал, что они будут патчить исполняемый код (правда, это ненадёжно, поскольку код может исполняться в момент наложения патча). Даже если и так, всё равно в них есть функционал, позволяющий добавить несколько советов к одной функции. Во всяком случае, пока этот код обсуждается, я уже запустил Яр и под CCL, и под SBCL и в этом мне очень сильно помогли мои полсотни define-advice-ов, к-рыми я патчу сами реализации, swank и asdf. Возможность найти определение функции И одновременно определение всех его адвайсов даёт чёткий контроль над тем, что происходит в коде. Так что вы как хотите, а для меня этот опыт был полезным, и, более того, данное обсуждение уже несколько устарело.

Ты мне когда-нибудь озвучишь, где находится документ «практика многопоточности в SBCL»? То, что ты пытался написать про safe environment - к теме не относится. И скажи, безопасно ли вызывать room в SLIME или нет.

Раз они это пишут, то подразумевается, что fwrap свободен от этого недостатка. Хотя мне некогда искать, где бы это прямо утверждалось, и даже выяснять, правда это или нет.

Наоборот. Они говорят что старые advise-ы были прибиту к символу функции и не работали для анонимных функций. А fwrap кроме всего прочего возвращает function объект - исходную функцию обернутую в этот самый advise-образный

А я про что? Смысл в чём? Где-то записано (funcall #'my-fun ...)

Они пишут о том, что encapsulation на это не подействует. Отсюда можно заключить, что fwrap лучше (т.е. frwrap на это подействует)

Поставил аллегро:

(compile (defun foo (x) 1))

; While COMPILING #'FOO at top level:
Warning: Variable X is never used.
FOO
T
NIL
CG-USER(2): 
CG-USER(2): (def-fwrapper blub (z) 123)
BLUB
CG-USER(3): (compile (defun outer (x) (funcall #'foo 7)))
; While COMPILING #'OUTER at top level:
Warning: Variable X is never used.
OUTER
T
NIL
CG-USER(4): (outer 5)
1
CG-USER(5): (fwrap 'foo :change-foo 'blub)
#<Function FOO>
CG-USER(6): (outer 5)
123
CG-USER(7): 

И скажи, безопасно ли вызывать room в SLIME или нет.

Я вызываю же. Ни разу не падал. Небезопасно теоритечески его одновременная конкурентная работа самого с собой.

Ты мне когда-нибудь озвучишь, где находится документ «практика многопоточности в SBCL»?

У меня очучение что у тебя какой-то пробел в знаниях в рамках темы многопоточность и posix. Sbcl писали и документировали люди которую это умеют без букваря. В принципе есть и более высоуровневые и по идее более безопасные обертки. Котрыми я не пользовался. Но на что оно тебе, если ты уже счастлив с ccl:) К слову я не видел тестового примера на котром у тея все это падает. Возможно это и к room отношения не имеет.

А вот CCL с моим define-advice (т.е. это по сути advise).

504 CL-USER>(compile (defun foo (x) (declare (ignore x)) 1))
505 CL-USER>(compile (defun outer (x) (funcall #'foo x)))
506 CL-USER>(outer 8)
1
510 CL-USER>(cl-advice:define-advice foo #'(lambda (fn z) (declare (ignore fn)) z))
#<Compiled-function (CCL::ADVISED 'FOO) (Non-Global)  #x302003FA75EF>
511 CL-USER>(outer 8)
8

Это не по стандарту. Так что не знаю, кто там что закопал, а CCL всё круто.

Sbcl писали и документировали люди которую это умеют без букваря.

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

Возможно это и к room отношения не имеет.

Ну, я не буду ради того, чтобы тебя убедить, рыться в sbcl-devel двухлетней давности. Ты взрослый дядя, решай сам. Конечно, проще всего списать на меня (ага, и сейчас ты скажешь, что я это тебе приписываю, на этот случай напоминаю твои слова: «У меня очучение что у тебя какой-то пробел в знаниях в рамках темы многопоточность и posix. »)

Т.е. в принципе если бы я захотел портировать cl-advice на Allegro, я бы взял fwrappers, который тоже работает не по стандарту. Хотя кто их знает, как они компилируют #'foo - может быть при определённой оптимизации и fwrap перестанет работать. Не суть важно. Практическая польза для меня есть. Проблем (пока) не обнаружено.

У меня очучение что у тебя какой-то пробел в знаниях в рамках темы многопоточность и posix.

А вообще-то в _нормальных_ программах, если часть функций thread-safe, а часть нет, то в документации пишут, какие. Если в документации написано «часть функций не thread-safe» без указания перечня thread-safe функций, то это не программа, а говно. Но конечно, дело в том, что мои знания содержат пробелы, да.

Зашибись! Скачал последний CCL под офтопик. Запустил и ввёл всего лишь одну команду: (quit). Зависает с вероятностью около 50% ЛОЛ.

Ссылку на багу я присылал. Общую идею примера говорил.
Ну, я не буду ради того, чтобы тебя убедить, рыться в sbcl-devel двухлетней давности.

Если я зароюсь, я найду там конкретный код который роняет sbcl? Домыслы на тему я и сам могу придумать.

Sbcl писали и документировали люди которую это умеют без букваря.

Ну ясно, в авторитеты ты веришь, а у меня авторитета нет.

не верю. У тебя прежде всего кода нет:(
но это все к докуметации и твоему ее непониманию/толкованию не имеет отношения:(

Конечно, проще всего списать на меня (ага, и сейчас ты скажешь, что я это тебе приписываю, на этот случай напоминаю твои слова: «У меня очучение что у тебя какой-то пробел в знаниях в рамках темымногопоточность и posix. »)

Если падает только у тебя, 2года назад и в непонятных обстоятелтсвах то на кого еще?:)

на этот случай напоминаю твои слова: «У меня очучение что у тебя какой-то пробел в знаниях в рамках темымногопоточность и posix. »)

Это цитата относится не к багу а к требованию букваря по многопоточности.

Можешь считать, что этого бага нет,если тебе так комфортнее.

Меня волнует исключительно какой именно код роняет sbcl и его воспроизводимость в лабораторных условиях. Если этот код потерялся 2 года назад то и вопрос исчерпан.

В принципе я могу воспроизвести, но зачем? Чтобы доказать, что я не верблюд? Ну, считай, что я верблюд. Мне, конечно, неприятно, но я переживу.

Т.е. в принципе если бы я захотел портировать cl-advice на Allegro, я бы взял fwrappers,

Вот кстати кто-то портировал что подобное https://github.com/sellout/quid-pro-quo/tree/master/src

Ты кстати обещал посмотреть, зависает ли у тебя тест на семафоры в современной версии - у меня зависал с вероятностью 50% на вирт. машине под VMWare, на виртмашине крутится debian 64-разрядный. Т.е. и не нужно на два года отматывать - и сегодня всё плохо :)

я найду там конкретный код который роняет sbcl?

По сути дела - не найдёшь. Я не смог создать достаточно простой пример, было нужно скачать весь clcon, каким он был на тот момент. Код включал в себя hunchentoot и drakma, т.е. даже без моей среды он достаточно сложный. Я потратил полдня или день на попытки создать простой пример, но не смог. Так что там скорее всёго мёртвая ссылка на какой-нибудь файлообмненик.

Но у них и на тот момент что-то в тестах было неладно, во всяком случае, мою багу зачислили как дубликат баги про падающий тест threads.impure или что-то в этом роде.

Это тоже, кстати, говорит много о качестве поддержки тредов на тот момент.

Вот с этого и надо было начинать, тогда бы, может и не нужно было мне делать то, что я сделал.

но зачем? Чтобы доказать, что я не верблюд?

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

на вирт. машине под VMWare,крутится debian 64-разрядный. Т.е. и не нужно на два года отматывать - и сегодня всё плохо :)

Я пока на vmwarь грешу с ней часто бывает плохо:( Но я еще не гонял:(

Ну мне на самом деле не привыкать, что не хотят помогать. Я уже привык лет 7 назад. Да и... иных уж нет, а те далече. Ничего злого тут нет - просто такова реальность. На тему твоего научного интереса - я тебе привёл гораздо более простые примеры, и не получил обратной связи. Про те же семафоры.

Вот с этого и надо было начинать,

Я это только сегодня нагуглил. Ты тоже мог бы