OberonCore

Спасибо за конкретное предложение, как это заменить! Уже не первый человек высказывается про эту проблему, и тут надо как-то решить это разом. Я помню, что когда с Александром Ширяевым мы обсуждали вопрос замены, он говорил, что главное везде заменить одновременно, чтобы нигде не осталось этих "printf()". И есть ещё какие-то сложности, но не помню какие. Главное опять вопрос поднят, на каникулах надо сделать.

не, одновременно не очень обязательно. ну, разве что из соображений «точно-точно починить». если оставить на месте `fflush()` перед `write()`, то оно вполне вместе сочетается. но там на самом деле не так много мест — если копипасту ErrWrite, которая есть в нескольких модулях, вынести в отдельный — то выходит буквально около трёх мест. я у себя так заменил сразу, как только заметил: сишные рефлексы, от такой конструкции любой бывалый сишник покрывается холодным потом. ;-)

я, признаться, не вижу, как можно сделать отключение, например, «Mdi» иначе. проблема в том, что его грузит «INCLUDE "*"». тут варианта ровно два: или потерять возможность автоматически грузить менюшки из всех модулей, или как-то маркировать менюшки в модулях. поэтому я предложил решение, которое сделано минимальными изменениями, полностью обратно совместимо, в будущем при необходимости расширяемо, и позволяет не заниматься ручным перечислением каждого меню. эта фича может быть удобна и авторам компонентов, кстати.

я не считаю, что каркас выдали нам в идеальном виде, и там ничего трогать не надо. то есть, если что-то можно без труда добавить модулем — то имеет смысл модулем, да. но некоторые вещи надо вводить прямо в базу. Omic-и не сделали практически ничего для со-существования в одном каталоге разных версий BBCB: им просто не надо было, видимо. вы (разработчики BB2.0) уже довольно сильно изменили каркас — есть смысл доделать и мелочи, мне кажется.

как-то вот так. надеюсь, вы передумаете и согласитесь со мной. ну, а нет — так нет, такое тоже бывает, не страшно. ;-)

кстати. ни у кого случайно нет уже готового модуля для вызова внешних утилит (желательно с поиском по PATH), и перенаправлением stdout в TextModel? `system()`, первый этаж и без телефона просьба не предлагать! ;-) имеется в виду кросс-платформенное решение (но для начала сойдёт и только GNU/Linux). вообще, в идеале такое надо бы иметь сразу в Std где-нибудь (или оно есть, а я как обычно слепой?). оно надо для многих вещей — в частности, мне сейчас надо чтобы git дёргать.

а. и сопутствующий вопрос: поддерживает ли компилятор работу с сишными vararg-функциями именно как с vararg? ну, то есть, тот же `printf()` можно как-то объявить как `printf(fmt, …)`, или увы? а если нельзя, то можно ли как-то задать объявлению алиас, типа такого: `PROCEDURE [ccall] printf2 (fmt: PtrSTR, s: PtrSTR) = "printf";`? ну, чтобы куча их ссылалась на один и тот же импорт. я могу, конечно, посмотреть прямо в компиляторе, но боюсь. в смысле, если я залезу в компилятор, то это чревато тем, что я там и останусь, очень уж люблю компиляторы ломать. может быть так кто-то знает?

MODULE WinGdip ["gdiplus.dll"];;
...
PROCEDURE DeletePen* ["GdipDeletePen"] (pen: Pen): Status;
...
END WinGdip.

ага, ясно. спасибо большое! надо бы не лениться и сначала попытаться находить самому, конечно. простите.

С перенаправлением нет, но у меня есть (был) LinDialog, который вызывает fork (собсно это вошло в обычный ББ), а по завершении дочернего процесса вызывает Action. Впрочем, он делает это не в ответ на системный сигнал (что было бы каноничнее), а в режиме активного ожидания, тоже через Action, т.е. оч незамысловато.

А вы хотите git запускать? Напрямую их апи - существенно сложнее? (я вообще не в курсе)

а у них нет апи вообще: это просто рассыпуха разных бинарей. есть libgit2 (от других людей), но она тоже корявенькая.

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

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

Да, было бы полезно иметь штатную возможность запустить внешний процесс, узнать о его завершении и почитать его результаты err и stdout. Время от времени такие запросы пролетают в форуме и чатах. Может, правда, не в Std, а в Cons.

ну, в принципе, запускалке надо только передать ридер для stdin, и два вритера для stdout и stderr, а где там она конкретно жить будет — не так важно. достигаем независимости, и заодно можем кормить её хоть алгоритмически, и выход обрабатывать как угодно, не только в TextModel складывать.

Если делать такую функциональность, то требуется, чтобы она работала кросс-платформенно. В Linux то можно вывод процесса писать в файл, запуская через Dialog.RunExternal, и потом этот файл анализировать. Узнать только, что процесс завершился как-то.

это плохой вариант (писать в файл), к тому же излишний, и требует использовать `system()`. что никсы, что винда позволяют перехватывать консольный i/o без дополнительных файлов. в никсах для этого надо открыть трубу и использовать `dup2 2`, в винде уже не помню, давно это было. для проверки статуса процесса (и опционального ожидания) используется `wait 2` (а в винде, кажется, `WaitForSingleObject()`).

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

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

А линукс разве не создаст какой-нибудь служебный файл при создании канала?

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

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

по ходу, предложение: на GNU/Linux прибить гвоздями безусловную замену `[ccall]` в парзере на `[ccall16]`. к сожалению, GCC сломали настолько, что `[ccall]` сейчас имеет мало смысла, а замена чинит всё, и ничего не ломает (проверено у себя). в принципе, это надо приколотить на любой платформе, где используется GCC — чисто для безопасности.

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

Вот тут коллеги рассуждали на тему диска, временных файлов и файлов в памяти:
viewtopic.php?f=23&t=4214

А чем ccall отличается от ccall16?
Если ccall уже точно не нужен, и если он точно равносилен ccall16, то можно, не трогая парсер и не вводя "не верь глазам своим", поменять в документации SYSTEM@Linux и в реализации кодогенератора.

спасибо, посмотрю!

выравнивает стек на 16 байт. бравые парни из GCC давно возложили детородный орган на x86 ABI (который требует только выравнивания на 4 байта), и генерируют код с SSE (в том числе для memory transfers, так что даже не обязательно плавающую точку использовать), который ожидает 16-байтовых выравниваний. и подразумевают, что всё на свете GCC, и всё гарантирует на входе эти 16 байт. `[ccall16]` как раз и реализует хак для такого выравнивания. старому коду плевать, а новый код доволен. недостаток только в чуть более медленном вызове, потому что код для выравнивания надо везде пихать.

тогда будет проблема с библиотеками: если использовать селекторы, можно делать один модуль для нескольких систем. в винде, например, `[ccall]` вполне достаточно. оборачивать каждое объявление функции в селектор — замахаешься, так что проще сделать подмену в парзере, и не мусорить в коде. это всё равно системная фишка, зависящая от ABI конкретной ОС и архитектуры, так что компилятор вправе подменять её на то, что будет работать для конкретной цели, мне кажется.

p.s.: на самом деле всё сломано ещё кардинальней, и всяческие массивы тоже надо равнять на 16 байт. то есть, если мы передаём в библиотечную функцию буфер, и он не выравнен на 16 байт, то мы играем в русскую рулетку. в идеале надо просто сломать кодоген, чтобы он держал инвариант «всё выравнено» автоматически (так и делает GCC), но мне очень эта идея не нравится. не потому что кодоген сломать сложно (это дело нехитрое), а потому что это… неизящно. нужен флажок для локалов, который будет говорить: «этот локал надо выравнять для системного ABI», наподобие `[ccall]` для процедур. что-то типа:

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

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

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