Ищется 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