Ищется acme под везде

симулякр понимания сообщения, понятия – это из треугольника фреге знак-концепт-денотат пустой знак без денотата или не с тем концептом который закладывался автором сообщения, а не твоей интерпретацией.

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

«Если однажды зимней ночью путник..» Итало Кальвино

но полезней Смаллианить как же называется эта принцеса тигр

А может мне кто-нибудь объяснить, чем так хорош этот acme и почему он лучше emacs?

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

у языка есть аффтар. и кажный криэйтор сего креатиффа суть творитель своево езыка.

от переливания сути смысла в порожние порожняки новые значеньица – ни создаюцца.

смысел тоже есть. если есть аффтар.

For its role in the overall system, Acme most resembles EMACS [Stal93]. It is tricky to compare Acme to EMACS, though, because there are many versions of EMACS and, since it is fully programmable, EMACS can in principle do anything Acme does. Also, Acme is much younger and therefore has not had the time to acquire as many features. The issue therefore is less what the systems can be programmed to do than how they are used. The EMACS versions that come closest to Acme’s style are those that have been extended to provide a programming environment, usually for a language such as LISP [Alle92, Lucid92]. For richness of the existing interface, these EMACS versions are certainly superior to Acme. On the other hand, Acme’s interface works equally well already for a variety of languages; for example, one of its most enthusiastic users works almost exclusively in Standard ML, a language nothing like C.

Where Acme excels is in the smoothness of its interface. Until recently, EMACS did not support the mouse especially well, and even with the latest version providing features such as ‘extents’ that can be programmed to behave much like Acme commands, many users don’t bother to upgrade. Moreover, in the versions that provide extents, most EMACS packages don’t take advantage of them.

The most important distinction is just that EMACS is fundamentally keyboard-based, while Acme is mouse-based.

https://p9f.org/sys/doc/acme/acme.pdf

NAMESPACE = `{mktemp -d}

Интересная идея. А я вручную это делаю. Наверное, это излишне.

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

acme -b

А что делает этот флаг?

а что такая свежая бумажка, аж за 1994 год?

или вообще подобное только на go переписать вместо лимбо и собирать подо все. видел что-то plan9 подобное, harvey кажется.

вспомнилась еще вот такая кузинатра: edwood

даже в plan 9 gsoc 2024 есть – пытаются добавить синтаксическую раскраску:

EDWOOD — COLORED TEXT
Likely mentor:		Paul Lalonde & Rob Kroeger
Skills:			Go
Project size:		Large
Difficulty:		Medium (High if including all three, below)
Expected outcome:	Modifications to Edwood to support colored text in windows
Edwood is a text editor based on Plan 9’s acme user interface and programmable interface, rewritten in Go to allow more agile extension. Like acme, edwood is limited to monochrome and mono-font text representations. It allows changing the font on a per-window basis. It does not support any text coloring. This project is to extend edwood with three new interconnected features:

* Per-character attributes, managed with the same undo features, etc., as the normal text;

* Colored text rendering based on these attributes; and

* A synthetic file-system based attribute-setting system.

These together should allow external programs to manage syntax coloring, for example. A stretch goal would be to connect established syntax coloring processors to edwood through its synthetic file system interface. Part 1 will require modifying edwood’s text buffer representation to include an attribute per character. A policy will be required to determine what attributes newly inserted text should inherit from surrounding text. Part 2 will require modifying libframe to support color attributes. Part 3 will require developing an interface to compactly communicate the attributes of the visible portion of the text.

в anvil есть ansi и цвета, но насчет файловой системы для аналогичной emacs faces раскраски – это интересно.

еще интересно например что-то литературно-грамотное через файловую систему который acme управлять – например, отдельные блоки кода и блоки документации чтобы были через нее доступны, а потом обычным tsort при weave включающего web-блока выполнить топологическую сортировку включаемых в него, например.

вообще: weave/tangle как обычный шелл (или rc-shell) скрипт, управляющий кузинатрой acme

в репозиториях rjkroege есть немало интересного на тему acme, plan9, go, libdraw – например, irc-клиент для acme: форк velour

можно запилить клиента к локальному koboldcpp, например.

acme -b

    Typing
      The behavior of typed text is similar to that in rio(1)
      except that the characters are delivered to the tag or body
      under the mouse; there is no `click to type'.  (The experi-
      mental option -b causes typing to go to the most recently
      clicked-at or made window.)  The usual backspacing conven-
      tions apply.  As in sam(1) but not rio, the ESC key selects
      the text typed since the last mouse action, a feature par-
      ticularly useful when executing commands.  A side effect is
      that typing ESC with text already selected is identical to a
      Cut command (q.v.).

Стареют пользователи, не программы.

acme.pdf: tl;dr комментирую свое понимание этого текста

есть два подхода: операционная система и операционная среда

• операционная система – это управляющая программа (например, монолитное ядро классического unix), которая управляет ресурсами компьютера: для чего она отображает или мультиплексирует физические ресурсы (например, память ядра; дисковые блоки; текущий поток управления userland; системное API в виде syscalls; структуры данных уровня ядра) на логические (например: память процесса; файлы и файловые системы; процессы; libc API стандартной библиотеки над syscalls; системные объекты).

• операционная среда – это среда взаимодействия, ориентированная на конечного пользователя, на его взаимодействие с ней – в терминах самой среды, на каком-то уровне (например: GUI конечного приложения; HUD игры; текстовый интерфейс запрос-ответ к СУБД; терминал и текстовый shell; гипертекстовый интерфейс и т.п.)

в каком-то смысле, уже с классическим unix все не просто: это и система, и среда одновременно.

например:

• shell – это и среда языка программирования, и система которая запускает задачи jobs и процессы.

• процесс unix – это и ориентация на конечного пользователя, API уровня ЯП; и на предоставляемые ядром процессу интерфейсы, например: монтирование файловой системы

в этом смысле – plan9 пост-неклассический юникс, в котором все более файл чем в классическом (например, интерфейс устройств или множественные пространства имен или p9fs и styx).

из-за множественных пространств имен файловых серверов у каждого процесса и наличия универсального интерфейса доступа к таким псевдофайлам через обычный файловый интерфейс типа (open/create/read/write/walk/close/unlink, см. API p9fs/styx) – по сути можно сказать что в plan9, inferno отдельный процесс менеджер файловой системы – это сетевой сервер объектной системы ООСУБД, предоставляющей персистентные (хранимые) объекты через этот псевдофайловый API запросов/ответов к самим объектам + метаданные в виде запросов/ответов к командным /mnt/foobarfs/ctl файлам.

то есть, в Plan9 файл – это больше чем просто файл: это фактически некоторый псевдофайловый объект, предоставляемый по p9fs/styx ответственным за нужную точку монтирования __псевдо__файловым сервером.

путь к файловой системе здесь можно интерпретировать как отображение из множественного пространства имён внутри процесса в некоторое глобальное пространство имен всех объектов уровня ядра ОС, например (типа того что есть в NT native kernel api или даже в том же классическом unix структур ядра в kmem памяти)

соответственно, получаются физические имена самих объектов и логические, а также логические имена ctl-файлов с запросами, интерпретирующими команды к серверу и каких-то log-файлов с ответами на эти запросы.

например: Rio и 8.5 – оконная среда, которая мультиплексирует на физические /dev/window/…/123 логические /dev/window/ текущего приложения.

в этом смысле само acme: – среда текстовых буферов, которая управляется по интерфейсу ctl-файлов над псевдофайловым API над /mnt/acme:

стр. 7/15 acme.pdf Coupling to new programs

Like many Plan9 programs, Acme offers a programmable interface to other programs by acting as file server. <..tl;dr:tl;dr..> Acme provides the interaction for applications.

the root mounted on /mnt/acme, here /mnt/acme/ID => window’s ID, /mnt/acme/ID/{addr,body,ctl,data,event,tag} – псевдофайловый интерфейс к acme-объектам

body – текст окна, tag – текст заголовка окна (путь к объекту вида глобальной ФС /… или вида отображение в псевдофайл в другом процессе, см. Acid/396/stk, Mail/mbox, adict/oed/{,futtock} на картинке 1 на стр 2/15 acme.pdf)

эти файлы можно читать/писать снаружи, обычным rc shell писать в окно другой программы (текстовый буфер acme-объекта)

addr, data – random access: char pos+read/write at that position след. страница 8/15, пример:

echo 3,7 > /mnt/acme/$NNN/addr
cp /tmp/foobar.txt > /mnt /acme/$NNN/data

=> заменить содержимое текстового буфера с 3 по 7 строку (char pos в духе sed/sam/vim адресации)

самый интересный тут конечно, интерфейс запросов к ctl-файлам и event-файлы.

ctl: писать запросы:понимает команды, например, name; del window; put; и т.п.

ctl: читать ответы: возвращает 5 textual numbers – window ID, #chars in tag, #chars in body. and some status – followed by the text of the tag, up to a newline.

event: текстовый fixep format запросов и ответов про события: source of action (keyboard, mouse, external program, etc), location(what was pointed or modified), and its nature(change, search, execution, etc)

пример сообщения о нажатии кнопок мыши и вставке по 4 символов за раз в нужную позицию, и время события.

программы-фильтры могут обрабатывать свою интерпретацию или просто транслировать события назад в acme event файл, для дефолтной обработки событий. далее на стр. 8/15 идут примеры.

/mnt/acme/index – список всех текстовых буферов: windowID, windowName

/mnt/acme/new – аналогичное clone из /ns/, создать новое текстовое окно/текстовый буфер

стр. 9/15 grep -n var *.c > /mnt/acme/new/body => поместить текстовый выхлоп grep в содержимом нового текстового буфера

стр. 9/15 раздел Acme-specific programs – про написание «плагинов» для acme.

фактически, здесь ровно наоборот: внешняя программа управляет acme, а не IDE управляет плагином.

например, Win – запустить shell внутри acme. просто обрабатывать события из /mnt/acme/event если нужно, и добавлять свои обработчики; писать в /mnt/acme/$NNN/body новый лог и обновлять его; запускать новые команды и через pipe перенаправлять выхлоп команды добавляя в новый лог.

560 строк всего, обработка «интеркликов мышкой» – middle click executes command, right click => cd dir, open file, ls dir; по идее, где-то здесь должна быть обработка plumbing и его правил тоже.

далее на стр. 9/15 написано как реализован текстовый mail клиент к mbox файлу.

далее стр. 10/15 – /acme/edit/{guide,src} файлы, макросы для acme.

наподобие sed/ed скриптов. в форке Anvil, кстати реализованы sam-подобные структурные регэкспы

далее идут описания различий в реализации в сравнение acme с EMACS

если коротко: то плагин для Emacs запускается самим Emacs, и должен быть ориентирован либо на его Lisp-api либо C-API (компилируемые С модули, которые относительно недавно появились в GNU/Emacs, а в XEmacs были гораздо раньше)

в то время как acme – это кузинатра среда для взаимодействия отдельных программ, которые управляют самим acme через его __псевдо__файловый интерфейс

а что такая свежая бумажка, аж за 1994 год?

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

например, даже с начала самой статьи, идет сравнение с Cedar / MESA системой без подробного описания самой этой системы, смотри например обзор про MESA и Cedar

упомянуто впрочем, что Xerox породил Cedar/MESA (а еще он породил например, InterLisp и SmallTalk), Cedar породил Project Oberon

тут на момент 1994 под Oberon скорее понимается классический Project Oberon который действительно однозадачный и со слабой сетью. ну или BlackBox Component Pascal, который тогда уже был, только под Windows API и/или Macintosh Classic OS9.

в конце 90х (чего на момент статьи еще не было) – уже появились BlueBottle/AOS/A2 и Active Oberon; Inferno и регистровая Dis VM, язык Limbo; PlanB а не только Plan9; TaoOS/Taos/Elate/intent/AmigaDE как embedded RTOS и VP, virtual processor как тоже регистровая VM времени выполнения; LLVM как регистровая VM времени компиляции с SSA представлением; CAM, ZAM и прочие категорные абстрактные машины для Ocaml/Caml/SML как более эффективные регистровые машины;….; Oz, Mozart; FONC/STEP, Frank, OMETA; COLA оттуда; ABE, actor based environment на С для реализации Kernel vau-exprs lisp by J.Shutt;…; curl RIA web language;Dylan, goo, functional objects; LLVM, pony; actors, REBOL2/3, RED; …; ChrysaLisp ну и т.п.

да даже те же веб-подобные IDE c javascript реализацией типа electron.js или еще какого клиента. если заменить js на нормальный лисп – то ими даже пользоваться можно станет, наконец-то. или например, транспилировать нормальный лисп в/из этого нелолиспа с curly-braces синтаксисом.

например: в это сравенение операционных сред IDE напрашиваются реализации на Go IDE, а также на веб-технологиях.

например, тот же Anvil – ЕМНИП, 40 мегабайт оно весит потому что там реализована синтаксическая раскраска через javascript, который там по сути не нужен – а нужен механизм расширений в духе старого классического acme или например, то что предлагают в edwood.

edwood на Go – тоже надо бы в сравнение добавить. практически почти прямой перевод из acme реализацию на си в почти буквальную реализацию на Go. где-то в процессе этого форка автор, судя по его репозиторию на гитхабе – портировал libdraw на Go. (вообще, вот реализовал бы кто-то libdraw из plan9/inferno через libSDL – было бы зело хорошо: например, поддержка TTF шрифтов и OpenGL/vulkan ускорения «из коробки»)

опять же, эти 3 задания на gsoc 2024 – в целом, понятно куда оно дальше развивается (например: для синтаксической раскраски продумать API цветного вместо /mnt/acme/$NN/body и генерировать например обычным GNU highlight выхлоп в цветном ANSI VT100 ESC-кодах для некоторого /mnt/edwood/$NN/color-body)

лично мне – в общем понятно куда все это развивается и чего не хватает в этих сравнениях (по состоянию на сегодня):

1. сам вектор, тенденция перехода от чисто текстового typescript выхлопа в векторный гипертекстовый более расширенный. например, добавлять картинки, фавиконки и эмодози, раскрашивать терминальное чтиво выхлоп какой-то команды как это сейчас стало модно. то есть: текстово-графический терминал, а не чисто текстовый typescript.

тут надо бы сравнение например того, как это было реализовано в Оберонах.

уже в классическом однозадачном Project Oberon который был нативной самостоятельной ОС – был Gadget API и документы более похожие на составные compound document типа MS word и соотв. бинарных интерфейсов.

то есть: в виду паттерна Carrier & Rider там было что-то наподобие MVC.

то есть: API коммандеров, интеракторов – позволяло читать не только текст через этот API но и соответствующие ему глифы и иконы, кнопки типа тех же коммандеров.

поскольку API было реализовано как ОО потомок над текстовым API – все текстовое API автоматически работало и для графического.

это более явно прозвучало в API BlackBox Component Pascal, BBCP насчет его бинарного формата файлов. потом плагинами научились экспортировать и импортировать его в XML и ODT.

в проекте A2 который Active Oberon там уже с одной стороны регресс, с другой прогресс.

регресс в том, что вместо графических коммандеров опять carrier&rider чтобы читать например Module.Cmd arg1 arg2 arg 3 ~, то есть, нужно спецсимволами обносить явно.

прогресс например в том, что это по сути набор акторов, активных объектов.

оберон активный от оберона пассивного отличается тем, что активные объекты автоматически запускают активности сопрограмм, и синхронизируются через EXCLUSIVE и критические секции (типа семафоров/мониторов вместо механизма типа рандеву для tasks как например в Ada)

то есть, далее этот ZUI который в A2/ActiveOberon и его встроенные текстовые редакторы нужно дорабатывать до похожего тексто-графического ОО интерфейса или API.

если говорить про acme-sac – то там acme реализован поверх inferno на лимбо через типизированные каналы, как в go и limbo.

если говорить про edwood – то там каналы в go и почти буквальный перевод из исходной acme C реализации.

если говорить про акторную операционную среду (например, тот же mozart, oz; pony LLVM actor lang) – то это то, куда это все развивается

если говорить про лисп-подобную среду типа Kernel vau exprs, John Schutt – и например, реализацию ABE actor based environment на Си, и kernel лиспа поверх этого – и например, в сравнении с ChrysaLisp/Elate/TaOS — и например, first class objects = first class environments

– то это про то, куда оно все развивается #2, в связи с лиспом и акторами.

лисп: программируемый язык программирования, развиваемый например «метациклически на самом себе»

acme: текстовая кузинатра операционная среда обрабатывающая – предоставляющая в использование как сервер и читающая как клиент текстовые объекты через универсальный псевдо-файловый интерфейс

oberon: гипер-текстовая кузинатра, обрабатывающая monadic shell через расширенный текстово-графический API как потомка простого текстового API

акторные среды, тысячи их: более четкое выделение границ, ядра и расширений этой операционной среды

акторные лиспы: first class objects, first class environment как функционально-логические объектно-ориентированные скорее акторы чем объекты для реализации такой «расширяемой на себе самой» гипермедийной, гипертекстовой операционной среды акторных активных объектов

дискасс.

например, даже с начала самой статьи, идет сравнение с Cedar / MESA системой без подробного описания самой этой системы, смотри например обзор про MESA и Cedar

упомянуто впрочем, что Xerox породил Cedar/MESA (а еще он породил например, InterLisp и SmallTalk), Cedar породил Project Oberon

про язык программирования MESA, затем Cedar и операционную среду на всем этом на мой взгляд, стоило бы рассказать более подробно, чем «он породил Оберон, и все тут».

это достаточно интересная «операционная среда» сама по себе.

вот например, несколько ссылок:

• XeroxStarRetrospective

• COMPUTER GRAPHICS AND COMPUTER ANIMATION: A RETROSPECTIVE OVERVIEW chapter 16.1 Xerox PARC

• блогозаписи некоего лоровца Xerox Alto, BCPL и спиритизм

• исторически ГУЕвое Xerox Cedar ‘Viewers Window Package’ 1987

• анналы музейной истории History of Mesa

Documentation for the computers Mesa ran on. Alto hardware and software documents. Online at bitsavers.org Dandelion. Online at bitsavers.org Dicentra. Online at bitsavers.org Dolphin. Online at bitsavers.org Dorado. Online at bitsavers.org

больше информации появляется в описании самих этих машин

• интероперабельность с сишкой

• тулзы на гитхабе rochus-keller/Cedar – у него кстати, интересный набор popular repositories в профиле

• CSL-79-3_Mesa_Language_Manual_Version_5.0.pdf

• The_Elements_of_Mesa_Style_Jun1976.pdf

блогозаписи некоего лоровца Xerox Alto, BCPL и спиритизм

раздел про программирование на MESA и Cedar, оттуда ссылка на архив xerox_alto_file_system_archive.html#Mesa

cat а не cp, или с cp без > – описочка.

в репозиториях rjkroege есть немало интересного на тему acme, plan9, go, libdraw – например, irc-клиент для acme: форк velour

можно запилить клиента к локальному koboldcpp, например.

в этом смысле, velour на go c irc-клиентом напоминает тот самый win из acme.pdf для реализации Emacs-shell в acme, который отдельной программой управляет самим acme через api/и-или, через псевдо-файловый интерфейс.

через псевдо-файловый интерфейс управлять можно программой на любом языке программирования – достаточно просто уметь читать и писать файлы на этом языке программирования.

то есть, управляем кузинатрой из любой реализации на чем угодно.

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

edwood

давай на чистоту: этим говном же невозможно пользоваться.

Бамп годному треду.

По случаю хочу задать нубский вопрос: вот я повесил в тэге ссылку на скрипт, скрипт получает winid и может читать и писать acme/$winid/body через 9p, зашибись. В скрипте прогоняю текущий буфер через ocamlformat. Все работает но при записи текст добавляется в конец.

Читал man 4 acme так и не вкурил что надо написать в ctl чтобы очистить буфер перед записью. Или надо делать через addr и data

Может где примеры есть?

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

Дайкстра говорил что это бестолковая идея

интересно девки пляшут

func clearBody(winid int, file *os.File) {
	len := bodyLength(winid)
	file.WriteString(strings.Repeat("\b", len))
}

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

Это где такое?

повесил в тэге ссылку на скрипт … В скрипте прогоняю текущий буфер через ocamlformat

Я делаю немного по-другому: https://www.icloud.com/iclouddrive/01a_hdynIQgcqMAV965J0rtRQ

Раньше копировал название скрипта в тег, но почти сразу перешёл на этот метод. Он легче и быстрее. Если нажать на путь, то при использовании аккорда 2-1 будет использоваться весь путь, а не просто слово как в общем случае. По этому пути в скрипте можно найти winid:

. 9.rc

if (~ $#* 1)
	winid = `{9p read acme/index |grep '*'$1 |sed '1q' |awk '{print $1}'} || exit

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

shell и пр немыслимы без понимания что такое телетайп и как там оно полвека назад работало

Раскрой, пожалуйста, мысль.

Это vsamc mpd client https://github.com/TobiasHeinicke/vsamc/blob/master/vsamc.go

привет. бампну тред, ибо.

ты кажется, спрашивал про то, как через acme общаться с plumbing-ом к LLM-кам, например, той же llama.cpp или OpenClaw.

это было в треде про plan 9 правильного человека – Jehane, кажется, который gcc обычным собирается, ну и там соответственно APEX доработанный относительно родного планового APE к POSIX-анутости. там его написал какой-то итальянец, у него ещё скриншот хелловорда был с ls -l hello.elf на 1.5 Мб, кажется :))

1. то есть, технически используя эту штуку, можно собрать g++ llama.cpp под такой вот plan 9 правильного человека (на CPU; хз что там насчёт IOMMU с проброской чтобы CUDA версию запустить, куды то там нетути; то есть, пробрасывать можно и через QEMU хостового линакса)

2. вторая часть марлезонского балета – про то, как пользоваться клиентом из acme к лламе.

вот из недавнего треда про inferno64 => ссылка на https://github.com/caerwynj/inferno64

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

похоже он проснулся от спячки и начал снова активничать.

одна из интересных штук это как раз про llmfs и интерфейс к claw : caerwynj/limbo-claw/

зацени, например промпты: SOUL.md system.md tools.md

и сорец claw.b

как прикрутить это к acme – надеюсь, сам сообразишь?

кстати, где-то ещё на лоре в треде про форки acme была ссылка про не acme-sac на лимбо, а тот который нативный хостовый с RPC механизмом для плюмбинга, тот нативно JSON-ом плюется куда-то через плюмбинг, так что там наверно дале проще должно быть.

в общем, становится довольно-таки интересно.

конечно, пообщавшись с LLM-ками становится чертовски ясен их фундаментальный недостаток: какие же они тупые.

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

в смысле, вот представь что например в SQL надо было бы вместо курсоров и хранимок всё это в промпт SQL запроса запихивать.

или еще круче: вот например, FIS-GTM 7 который MUMPS – спокойно себе становится в Debian и работает, у него ещё новый модный и молодёжный форк есть который YottaDB где поддержку Cygwin выпилили, а так в основном тоже самое.

то есть, SET ^GLOBAL[KEY1,KEY2,KEY3]=VALUE вот это самое, BTree+ с много ключей-одно значение, и все типы данных это строки (даже числа)

или вот например, REXX классический в котором всё тоже строки, а stem-ы это ну почти глобалы (только не персистентные, без ^)

или ooREXX объектно-ориентированный в духе смоллтока с метаклассами, а там в 5.1.0+ (последний что-то около 5.3.0, как-то так) – появилась многопоточка через do метод, guard/unguarded – то есть, это по сути многотредовый акторный смоллток такой. и там от stem и его метакласса можно отнаследоваться и перекрыть например в персистентость, в глобалы мумпса того же.

то есть, использовать кеширующий сервер глобалов и рутин в основном ради глобалов, а рутины писать на ooREXX-е как акторный смоллток с персистентностью и многопоточкой.

то может быть, можно вытащить через узкий контекст всё во внешнюю память.

а чтобы понять что изменилось – можно создать промпт для ещё одной лламы которой опрашивать выхлоп этой вложенной =^)))

о, точно: anvil и velour, в которых готовый JSON RPC есть из коробки, и под хостом а не в инферновском аcme можно сразу, а не через llmfs промпты JSON-ом дёргать туда-сюда через plumbing

а это llmfs caerwynj/limbo-llmfs

как видишь в *.b сорцах, там «ехал JSON через JSON» через APIKEY к внешнему.

кстати, узнал внезапно из презенташки про ooREXX-Python binding что там можно просто import OpenAI сделать:

$ mupdfPython for ooREXX.pdf` g 34 page 34/39

Example: LLM text output

py = .PyRexx~new()
py~import('json')
py~from("openai")~import("OpenAI")

jsonString = .resources~entry("json_string")~makeString
pythonObject = py~json~loads(jsonString)
kwargs = py~kwargs(pythonObject)

client = py~OpenAI()
completion = client~chat~completions~create(kwargs)
say completion~choices[py~0]~message~content

::resource json_string
{ 
  "model":"gpt-4.1-nano",
  "messages":[
    { 
      "role":"user",
      "content":"Write a once-sentence bedtime story about a unicorn."
    }
   ]
}
::END

::requires 'PyRexx.cls'

ещё через пару страниц на page 36/39 интересный пример:

...

jsonString = completion~choices[py~0]~message~content

pythonObject = py~json~loads(jsonString)
say pythonObject
say pythonObject["participants"][py~0]

::resource json_string
{ 
  "model":"gpt-4.1-nano",
  "messages":[
    { 
    "role":"system",
    "content": "You are a helpful assistant designed to output JSON. Please respond in the format {name: ..., date: ..., participants: ...}"
 }, { 
      "role":"user",
      "content":"Alice and Bob are going to a science fair on Friday."
    }
 ],
 "response_format":{"type":"json_object"}
}
::END

::requires 'PyRexx.cls`

=> rexx openai_structured.rex {'name':'Science Fair','date':'Friday','participants':['Alice','Bob']} Alice

может этот второй пример можно в полноценную внешнюю память вместо узкого контекстного окна раскрутить.

и хранить их в персистентных стемах openRexx-а в глобалах МУМПСа.

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

shell и пр немыслимы без понимания что такое телетайп и как там оно полвека назад работало

Раскрой, пожалуйста, мысль.

я хоть не rtxrtx, но попытаюсь раскрыть его мысль:

вот смотри например, на Unix way классический «do one thing, and to it right», «cat -v and gnu hello на 300 кб и hello.cpp на 1.5 мб – considered harmful», «программы простые обмениваются текстовыми потоками через пайпы» – вот это вот всё.

где это проявляется конкретно в утилитах юникса классического V7 и GNU-того?

2. compiler driver в cc/as/ld – и gcc как compiler driver к gpp/gcc -E/cc/gas/ld/collect.

3. compiler driver в troff|equ|tbl|grap|pic |ps2pdf |page -

вот это вот всё, сравни например pipeline troff-а (например, neatroff с годным utf-8 или из plan9; а ещё лучше бы было, на limbo под inferno, далее dis, далее кроссплатформно и везде)

например, с pipeline tex классического: tex-fpc содержит минималистический tex (с шрифтами и прочим) всё ещё собирающийся паскалем, как завещал Кнут:

tangle.web => tangle.{pas,tex,pdf}, weave.web => weave.{pas,tex,pdf} , tangle tex-fpc.web => tex.{pas,tex,pdf}

причём там ещё с отдельными внятными патчами в change-файлах :)

вот, сравни это с классическим troff и nroff консольным «драйвером терминала» (который потом доработали с уникодностью в devutf для ps,pdf и ttf фонтов)

на уровне «команд troff-а» есть ручные команды «передвинуть курсор вперед/назад, вертикально/горизонтально».

на уровне equ/tbl/pic/grap/.. это тупой препроцессор текста в нужном окружении, можно хоть на awk, хоть на шелле написать.

то есть: далее вот этот compiler driver напрямую обворачивается всякими драйверами псевдопринтеров, терминалов, интерпретаторами ANSI/VT100/VT300/ReGis и тектоник, ctx.graphics.svg метапроговые,векторные и гипертекстовые/kitty,iTerm graphics/url protocol/MCCM/MCP MXM mud transfer protocol/…./3270/5150(+графики метароговые,лол+)/ и прочими GET/POST формами.

начиная например с {n,pd}curses{,w} с terminfo/termcap и глюками с не/совместимостями и уникодностями.

но по сути, вместо какого-то продвинутого композитора и мультиплексора типа `tmux на максималках~ (directvt/vtm как-то так) – это всё примерно то же самое, только в крайней терминальной стадии.

тот же самый текстовый pipeline с интерпретацией ESC-кодов, только

с ненужными наворотами.

например: шеллы обычные, ограниченные, интерактивные баши и сищели. или: сравни с православным rc или inferno в sh (с через плагины – tk, регэкспы и ещё всякое там, llmfs,sqlite,mumpfs,и прочая).

а теперь загляни например в ту же инферну, где там написан эмулятор терминала на Limbo c гуём на tk.

вот она, чистота и ясность-то где!! ляпота! без всего этого ненужно.

а теперь представь что было бы, если бы всю эту идею водопроводов, которую придумал советский программист и воплотили практически в compiler driver в troff и cc / gcc – реализовывола-перереализовывала, да так и не выреализовывола новомодная хипстота или старомодныя программисты на фортране, которые заместо MDL православного парсер зорка в адвентюре конечными автоматами с вычисляемым гото нахренячили.

где там «контекст промпта»? где «ограничения на размер контекстного окна» – в нормально спроектированном pipeline?

не, известен ещё альтернативный способ реализации pipeline заместо водопроводных юниксвеев с текстовыми потоками – это гипертекстовые например, REXX и его очереди в CMS и прочих ОС ЕС/360/370/390.

по сути, сам рекс это очень простой интерпретатор. почти как у форта.

есть единственный тип данных – это строка. в классическом рексе все переменные это строка, даже числа. в оо – все переменные это объект или метаобъект или метакласс смоллтоковый, OID которого это эта строка. то есть, строка это объект класса и метакласса, которому можно посылать message типа объект посылкой строк строкам, вызывая акторные асинхронные методы объекта (и метаобъекта, и прокси или unknown ~ :doesNotUnderstand смоллтоковый).

интерпретатор рекса напоминает почти внешний и внутренний интерпретатор форта, только зело проще.

1. нормализуем строки: склеиваем пробелы (как в tex и web), печатаем капслоком.

2. если есть = то слева имя переменной, идентификатор; справа значение

3. интерполируем переменные и строки

4. если начинается с ключевого слова – его обрабатываем.

5. если не обработали раньше, в 2)..4) => то передаём в другой интерпретатор (тот, который можно переключать в ADDRESS CMD или ADDRESS XEDIT например)

6. или в субкоманды если встроен например ‘ADDRESS XEDIT’ написанные на С/С++

7. или в другие объекты (в 5.1.0+ ooREXX они могут быть акторами многопоточными, форкаться, исполняться асинхронно с GUARD/unguarded и т.п.)

8. или вызываем субкоманды из DLL-ки.

то есть, можно например сразу писать строки строками через строки , чтобы уж точно пролезло в субкоманды того приложения, куда этот интерпретатор встроен (примеры в скриптах/профилях/макросах к XEDIT/ISPF/THE/KEDIT/X2 и т.п.)

остаются вопросы, конечно же: а что там с вводом/выводом? откуда читает pull и куда выхлоп выплёвывает say? и куда ADDRESS то отправляет все эти субкоманды метапроговых метаобъектов?

в REXX классическом, кондовом мейнфреймовом – придумали rxqueue и CMS pipeline для этого.

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

но в целом процесс самого водопровода и его потоков пайплайновых остаётся всё тот же до нельзя прозрачный.

то есть, можно втыкать себе новый рекс через рекс богу рексов в любое место этого пайплайна.

и нетути никакого принципиального (~наподобие приснопамятного: «640кб хватит для каждого!»~) встроенного имманентного внутреннего ограничения костылей реализации (которое вообще-то ниоткуда нахрен не упало, это именно костыли реализации а не первоначальной концепции)

другое дело – глубина или даже ширина (или там, толщина) этого контекста. и промпта. и старой памяти, и новой.

и попытка всю модель мира в один-единственный промпт запихнуть.

вот скажи мне, чебурашка: что было бы, если бы в compiler driver некие добрые милые люди (хипстеры малохольныя, вот кто они) зачем-то засунули бы ограничения на количество максимальных программ в пайплайне?

это был бы совсем другой водопровод. и – никакого юниксвея и системной архитектуры для текстовых программ драйвера обменивающихся поточной обработкой только своих триггернутых кусков в итоговый драйвер (терминала, или там для troff-а это этот финальный devutf который в ps/pdf рендерит, и потому шрифты понимать должен).

или вот, тот же /dev/llmfs/ctl. в него же чем угодно писать можно, вообще на любом языке.

то есть, вот такой plumbing pipeline как в acme – он тоже потенциально композабельный.

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

а то очередное 640kb is enough for everybody и костыли-велосипеды с dos memory model (это когда ещё в V7 был даже до a.out – но нормальная обычная линейная память) наворотили.

считать слова векторами – идея изначально дурацкая. какой размерности эти вектора, для начала?

ну вот аристотель писал как-то давеча что слово – это число. но он это понимал в смысле структурных отношений, как части речи или ещё какие онтологии с метафизиками.

или вот например, Хренников про моделирование процессов мышления в p-адических, адельных числах. единственный второй вариант пополнения кроме R, кстати. так там и диски ципфа и фракталы и фрейдизмы во все поля.

так почему тут – моделируют ембеддинги токенов заделки строк векторами непонятной размерности?

а не p-адическими, адельными, например. с понятной структурой, подчинённостью и поиском типа BTree, например.

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

ctx.graphics.svg метапроговые,векторные и гипертекстовые

а ещё видел интересный метапрог в презенташке про NetRexx и ooREXX где Java AWT/SWING через BSF.

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

вот честно, пытался спросить чятгопоту со ссылкой на тред на метапрог на лоре – что же такое есть этот ваш метапрог? и каковы там диагармы, и отчего же подфункции непременно конпелируемые? – а он так и не вывез, даже что это такое – понять ниасилил.

слабак!

Я пока ещё не осилил прочесть всё, но по диагонали заметил:

если бы всю эту идею водопроводов, которую придумал советский программист

Как звали этого советского программиста?