OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Понедельник, 22 Июль, 2024 09:03

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 390 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7 ... 20  След.
Автор Сообщение
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Суббота, 31 Декабрь, 2022 09:55 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3793
arisu писал(а):
сообщаю об опасной ужасти в nix-версиях (как минимум в GNU/Linux): для вывода в консоль используется `printf()` с одним аргументом. это чревато: достаточно, чтобы в строке попался какой-нибудь «%s» — и всё, пошла плясать губерния. желательно бы везде это заменить на нечто вроде:
Код:
res_ := Libc.write(1, SYSTEM.ADR(str[0]), LEN(str$));

кстати, и вызов `Libc.fflush()` можно будет тогда убрать (или делать его перед `write()` — на случай, если какая-то внешняя библиотека тоже гадит в консоль, и делает это через `printf()`).

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Суббота, 31 Декабрь, 2022 11:48 

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Суббота, 31 Декабрь, 2022 11:59 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1248
Иван Денисов писал(а):
Также не приветствую внедрения в Блэкбокс всяких дополнительных синтаксисов, ключей и т.п. Лучше все программировать на Компонентном Паскале, если это возможно.
я, признаться, не вижу, как можно сделать отключение, например, «Mdi» иначе. проблема в том, что его грузит «INCLUDE "*"». тут варианта ровно два: или потерять возможность автоматически грузить менюшки из всех модулей, или как-то маркировать менюшки в модулях. поэтому я предложил решение, которое сделано минимальными изменениями, полностью обратно совместимо, в будущем при необходимости расширяемо, и позволяет не заниматься ручным перечислением каждого меню. эта фича может быть удобна и авторам компонентов, кстати.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Суббота, 31 Декабрь, 2022 12:19 

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Суббота, 31 Декабрь, 2022 13:07 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
MODULE WinGdip ["gdiplus.dll"];;
...
PROCEDURE DeletePen* ["GdipDeletePen"] (pen: Pen): Status;
...
END WinGdip.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Суббота, 31 Декабрь, 2022 13:10 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1248
ага, ясно. спасибо большое! надо бы не лениться и сначала попытаться находить самому, конечно. простите.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Суббота, 31 Декабрь, 2022 13:14 
Аватара пользователя

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Суббота, 31 Декабрь, 2022 13:17 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1248
adimetrius писал(а):
А вы хотите git запускать? Напрямую их апи - существенно сложнее? (я вообще не в курсе)
а у них нет апи вообще: это просто рассыпуха разных бинарей. есть libgit2 (от других людей), но она тоже корявенькая.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Суббота, 31 Декабрь, 2022 13:38 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Да, было бы полезно иметь штатную возможность запустить внешний процесс, узнать о его завершении и почитать его результаты err и stdout. Время от времени такие запросы пролетают в форуме и чатах. Может, правда, не в Std, а в Cons.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Суббота, 31 Декабрь, 2022 14:00 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1248
adimetrius писал(а):
Да, было бы полезно иметь штатную возможность запустить внешний процесс, узнать о его завершении и почитать его результаты err и stdout. Время от времени такие запросы пролетают в форуме и чатах. Может, правда, не в Std, а в Cons.
ну, в принципе, запускалке надо только передать ридер для stdin, и два вритера для stdout и stderr, а где там она конкретно жить будет — не так важно. достигаем независимости, и заодно можем кормить её хоть алгоритмически, и выход обрабатывать как угодно, не только в TextModel складывать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Суббота, 31 Декабрь, 2022 18:12 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3793
Если делать такую функциональность, то требуется, чтобы она работала кросс-платформенно. В Linux то можно вывод процесса писать в файл, запуская через Dialog.RunExternal, и потом этот файл анализировать. Узнать только, что процесс завершился как-то.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Суббота, 31 Декабрь, 2022 19:20 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1248
это плохой вариант (писать в файл), к тому же излишний, и требует использовать `system()`. что никсы, что винда позволяют перехватывать консольный i/o без дополнительных файлов. в никсах для этого надо открыть трубу и использовать `dup2 2`, в винде уже не помню, давно это было. для проверки статуса процесса (и опционального ожидания) используется `wait 2` (а в винде, кажется, `WaitForSingleObject()`).

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Суббота, 31 Декабрь, 2022 19:44 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3793
Да, лучше бы избежать записей в файл. Всё это портит SSD диски. Для промышленных решений плохо.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Суббота, 31 Декабрь, 2022 20:03 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
А линукс разве не создаст какой-нибудь служебный файл при создании канала?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Суббота, 31 Декабрь, 2022 20:16 
Аватара пользователя

Зарегистрирован: Воскресенье, 09 Декабрь, 2018 15:14
Сообщения: 117
Откуда: Equestria
можно гадить в /proc, но это как бы не портабельно и не надёжно.
сделать подсистему с абстрактным интерфейсом и забыть про то на какой вообще ос находимся.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Суббота, 31 Декабрь, 2022 20:17 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1248
adimetrius писал(а):
А линукс разве не создаст какой-нибудь служебный файл при создании канала?
ни в коем случае. даже именованые трубы, в принципе, этого не требуют, а безымянные вообще никогда на реальные файлы не отображаются, чистые memory transfers.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Четверг, 05 Январь, 2023 01:20 

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Четверг, 05 Январь, 2023 02:00 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Вот тут коллеги рассуждали на тему диска, временных файлов и файлов в памяти:
viewtopic.php?f=23&t=4214

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Четверг, 05 Январь, 2023 04:27 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1248
adimetrius писал(а):
Вот тут коллеги рассуждали на тему диска, временных файлов и файлов в памяти:
viewtopic.php?f=23&t=4214
спасибо, посмотрю!

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 2.0
СообщениеДобавлено: Пятница, 06 Январь, 2023 07:45 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1248
с контекстным меню баг: оно не форсится в главное окно. например, если мышь очень внизу — то оно вылезет за экран. или если главное окно не во весь экран, и мышь увести влево-вверх, и вызвать контекстное меню с клавиатуры — то оно за левый и верхний края частично вылезет. надо бы его насильно форсить внутрь главного фрейма, чтобы никуда не пряталось. я быстронахачил быстрофикс, но не уверен, что корректно: пусть лучше сделает тот, кто больше понимает.

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 390 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7 ... 20  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB