OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 08 Декабрь, 2023 13:33

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


Правила форума


Посмотреть правила форума



Начать новую тему Ответить на тему  [ Сообщений: 631 ]  На страницу Пред.  1 ... 27, 28, 29, 30, 31, 32  След.
Автор Сообщение
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Пятница, 15 Сентябрь, 2023 19:20 

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 293
Откуда: Russia
arisu писал(а):
[ясно, спасибо. жаль, что A2 вместо этого не делает консервативный скан стека (если есть активные колбэки): можем же нечаянно всю систему развалить
Как бы она это делала в чужом процессе?))) ведь это не стек а2.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Пятница, 15 Сентябрь, 2023 19:47 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1140
Sergej Durmanov писал(а):
arisu писал(а):
[ясно, спасибо. жаль, что A2 вместо этого не делает консервативный скан стека (если есть активные колбэки): можем же нечаянно всю систему развалить
Как бы она это делала в чужом процессе?))) ведь это не стек а2.
почему не A2? если я вызываю функцию из системной библиотеки — она ведь тот же самый стек использует, что и caller. а потом эта библиотека вызывает обероновский колбэк — опять тот же самый стек. или A2 при каждом вызове библиотек ОС создаёт новый стек и копирует туда аргументы?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Пятница, 15 Сентябрь, 2023 20:24 

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 293
Откуда: Russia
мы о каких-то разных колбэках говорим. Я имею ввиду процедуры а2, которые регистрируются в нижележащей ОС и которые эта ОС вызывает когда ей вздумается. Конечно, ОС вызывает эти процедуры из своих процессов, у которых свой стек. Этот стек и использует колбэк.
Решение для учета ссылок в колбеках на самом деле в а2 есть. Это барьеры записи. В основной версии а2 они простые но быстрые, в кооперативной сложнее и совершаются дополнительные телодвижения, например подсчет ссылок для локальных указателей, для выявления утекших за пределы процедуры. В основной версии а2 этого пока нет.
Так вот, локальные указатели помещаются в специальный список и исключаются из него при выходе из процедуры, если количество ссылок равно нулю, то есть они точно локальны и память можно освободить даже не обращаясь к сборщику. В основной версии указатели попадают в такой список только если у экземпляра есть поля или элементы ссылочного типа и требуется их обработка для маркировки в основном цикле. Дальше они обрабатываются сборщиком.
Здесь нужно кое что доделать для колбэков и завернуть в FINALLY, чтобы гарантированно потом освободить все ссылки.


Последний раз редактировалось Sergej Durmanov Пятница, 15 Сентябрь, 2023 20:27, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Пятница, 15 Сентябрь, 2023 20:26 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1543
Sergej Durmanov писал(а):
budden писал(а):
Не верю, но разобраться некогда.

Во что именно ты не веришь? Если в процедуру, помеченную {WINAPI}, например Windows.Display.WindowProc поставить HALT или ASSERT, то в трапе метаданные будут присутствовать, несмотря на то, что никаких тегов нет, так как соглашение о вызове WINAPI не подразумевает их наличия.

Спасибо за ответ. Раз уж я слазал в исходники ЯОС, то вот код этой процедуры:
Код:
   проц {WINAPI} WindowProc( hwnd: User32.HWND;  uMsg: цел32;  wParam: User32.WParam;
                                                 lParam: User32.LParam ): User32.LResult;
   перем win {неОтслСборщиком}: Window;  dbh {неОтслСборщиком}: DEV_BROADCAST_HDRP; dbv  {неОтслСборщиком}: DEV_BROADCAST_VOLUMEP;
   нач

      если uMsg = WM_DEVICECHANGE то
         если wParam = DBT_DEVICEARRIVAL то
            dbh := НИЗКОУР.подмениТипЗначения(DEV_BROADCAST_HDRP,lParam);
            если dbh.dbch_devicetype = DBT_DEVTYP_VOLUME то
               dbv := НИЗКОУР.подмениТипЗначения(DEV_BROADCAST_VOLUMEP,lParam);
               WinFS.DeviceNotification(цел32(wParam),dbv.dbcv_unitmask);
            всё;
         аесли wParam = DBT_DEVICEREMOVECOMPLETE то
            dbh := НИЗКОУР.подмениТипЗначения(DEV_BROADCAST_HDRP,lParam);
            если dbh.dbch_devicetype = DBT_DEVTYP_VOLUME то
               dbv := НИЗКОУР.подмениТипЗначения(DEV_BROADCAST_VOLUMEP,lParam);
               WinFS.DeviceNotification(цел32(wParam),dbv.dbcv_unitmask);
            всё;
         всё;
      всё;

      win := НИЗКОУР.подмениТипЗначения( Window, адресВПамяти(User32.GetWindowLong( hwnd, GWLWindow )) );
      если win # НУЛЬ то возврат WindowHandler( win, uMsg, wParam, lParam )
      иначе возврат DummyProc( hwnd, uMsg, wParam, lParam )
      всё
   кон WindowProc;

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

Код:
Собирать свой мусор в чужом процессе A2 не умеет, о чём я выше написал.

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

Цитата:
В документе несколько напутано с процедурами а2, помеченными как WINAPI и собственно процедурами winapi, при вызове которых вставляются вызовы Objects.LeaveA2/Objects.ReenterA2 для отслеживания фреймов стека

Ну вот, и обёртка нашлась, правда не та, которую мы искали. Вот код этих функций в ЯОС:

Код:
   (* Leave A2 is called when a process leaves A2 by a call to the underlying OS API *)
   проц LeaveA2*;
   перем cur {неОтслСборщиком}: Process; ebp, pc, sp: адресВПамяти;
   нач{UNTRACKED}
      если сравнениеСОбменом(startedMainProcess,ложь,ложь) то
         cur := CurrentProcess();
         если cur # НУЛЬ то
            ebp := НИЗКОУР.GetFramePointer();
            sp := НИЗКОУР.GetStackPointer();
            НИЗКОУР.прочтиОбъектПоАдресу(ebp+размер16_от(адресВПамяти), pc);
            НИЗКОУР.прочтиОбъектПоАдресу(ebp, ebp);
            cur.gcContext.AddContext(ebp, pc, sp);            
         всё;
      всё;
   кон LeaveA2;

Она вставляется не в функции обратного вызова, а в функции "прямого" вызова, когда собранная как приложение A2 (в данном случае ЯОС) вызывает библиотечную функцию ОС.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Пятница, 15 Сентябрь, 2023 21:09 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1140
Sergej Durmanov писал(а):
мы о каких-то разных колбэках говорим. Я имею ввиду процедуры а2, которые регистрируются в нижележащей ОС и которые эта ОС вызывает когда ей вздумается.
а я имею в виду гипотетический API типа такого:
Код:
void enum_resources (void (*cback) (void *rsrc, void *udata), void *udata);

куда в качестве cback передаётся обероновская процедура, и `enum_resources()` её из себя в цикле вызывает, например. а саму `enum_resources()` вызывает другая обероновская процедура.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Суббота, 16 Сентябрь, 2023 19:32 

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Воскресенье, 17 Сентябрь, 2023 08:18 

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

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

а может даже и модули не надо расшаривать: в конце концов, объём кода не такой уж большой. потому что расшаривание модулей потребует смены формата модуля, и реализации в компиляторе механизма обращения к глобалам через смещение от некоторой базы, что довольно муторно (хоть и возможно). (вот тут очень не хватает универсального механизма LDT, который позволял бы при переключении потока подменять некоторые страницы на другие, не меняя их логического адреса.)

наличие общего адресного пространства позволит быстрее обмениваться данными, чем через IPC, поэтому так. конечно, обмениваться напрямую указателями нельзя (и внутри данных тоже), так что в принципе почтовому API всё равно, в одном АП ли процессы. так что в теории потом можно реализвать полноценные процессы в разных АП так, что уже написаный код ничего не заметит. да хоть по сети маршалить.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Воскресенье, 17 Сентябрь, 2023 10:39 

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

как будет вдохновение — попробую сделать PoC. если всё пойдёт так хорошо, как я себе воображаю — то внесу в LC как официальную фичу тогда.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Воскресенье, 17 Сентябрь, 2023 10:56 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1543
Этой идее сто лет в обед, в частности, некоторые хотели сделать "несколько блекбоксов внутри A2", но всё так на обсуждениях и закончилось. Внезапно, в обычных ОС типа Win/Lin так и работают несколько Java-машин, в браузере так работают несколько окон и т.п. И прекрасно совмещается возможность работы программ, написанных со сборкой мусора, и без, питон и ассемблер, локализация повреждения кучи, автоматическое освобождение ресурсов, масштабирование кучи на мелкие подкучи, бригады работяг (пулы воркеров).

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

А проблемы параллельности существуют сами по себе в объективной реальности. Они не зависят от того, как эта параллельность оформлена. Даже в событийно-ориентированном программировании спокойно можно словить гонку. Оформление в виде отдельных потоков (горутин, нитей, активностей) лишь придаёт этому более удобную, по сравнению с событийно-ориентированным подходом форму, потому что становится возможным иногда сосредоточиться на действиях одного потока управления, а не рассматривать всегда только вышивку крестиком.

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

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

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

Ну и плюс к тому, здесь можно найти тему, когда я спрашивал про TLS (thread local storage). TLS - это по сути дела хороший шаг к тому, чтобы каждый поток владел своими данными и тем самым конфликты параллельности для этих данных становятся невозможными по построению. Отслоив эти данные, можно сильно ограничить объём разделяемых между потоками данных. Если в этом направлении идти достаточно далеко, можно и до почтовой системы дойти, если это нужно. Местные снобы написали мне, что я ничего не понимаю и что TLS не нужен (в A2), потому что там есть активные объекты. На самом деле это они сами ничего не понимают и это вряд ли можно вылечить. В других культурах тоже плохо относятся к TLS. Ну и пускай. Пусть победа роботов над людьми не приближается.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Воскресенье, 17 Сентябрь, 2023 11:15 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1543
Касаемо быстроты одного АП, вообще вот в линуксе есть много способов межпроцессного взаимодействия, в частности среди них есть и очень быстрые:

https://github.com/goldsborough/ipc-bench

Насчёт внезапного прихода GC не стоит особо обольщаться. Если у тебя есть N независимых "работяг", и к одному из них пришёл GC, то он на время GC ничего делать не будет. Если ты построил из них конвейер, то будет задержка во всём конвейере. А дальше простой для меня пример цифровой музыкальной студии с плагинами. Суммарная задержка в тракте должна быть минимальной. 5 мс - это всё ещё повод для совершенствования. А количество операций над звуком от входа до выхода может достигать десятка (микширование и обработки). Если взять N ББЦБ и в каждом из них написать алгоритм со сборкой мусора, то это всё в целом работать не будет. А если посмотреть программы типа Cakewalk или Pro Tools, то мы увидим там жирнючий ГУЙ, который в оберон-культуре принято писать на куче со сборкой мусора. В общем, есть над чем задуматься (делить обработки на графическую и неграфическую часть, смириться с тем, что отрисовка звука будет лагать и т.п.)

Кроме того, понадобится планировщик задач, команды типа ps и kill. В итоге всё равно получится A2 или другая операционная система :)
Написать планировщик задач - непросто. Либо нужно приостанавливать каждый ББЦБ в произвольной точке, как в вытесняющей многозадачности - это нетривиальная задача из-за взаимодействия с периферией, и может быть ещё из-за чего-то (я помню, что это сделать сложно или нельзя, но не помню, почему). Либо делать кооп. многозадачность - это снижение стабильности и возникновение неявных взаимодействий. Либо ещё что-то. В любом случае, процессы не будут полностью изолированными и нужно будет следить за тем, как они конкурируют за вычислительные ресурсы, управлять этой конкуренцией.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Воскресенье, 17 Сентябрь, 2023 11:26 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1140
budden писал(а):
Этой идее сто лет в обед
это да, я и не претендую на то, что придумал что-то новое. просто вспомнил то, что придумали до меня, и очень обрадовался. ;-)

budden писал(а):
Но это означает появление в простой системе Оберона ещё одного этажа, которого там изначально не было, и размывание чёткости изначальной идеи. В какой момент таким образом будет утрачена элегантность и простота?
потоки/активности — тоже добавление этажа, которого не было.

budden писал(а):
А проблемы параллельности существуют сами по себе в объективной реальности. Они не зависят от того, как эта параллельность оформлена.
но наличие явно разделяемых данных добавляет в эту кучу ещё проблем. как будто их и так мало. я вполне серьёзно написал, что слишком глупый для написания хорошего многопоточного кода, который ещё и разделяемыми данными оперирует.

budden писал(а):
Дальше, если речь идёт о программах реального времени, то почтовая система вряд ли с этим хорошо справится.
вряд ли я для такой задачи возьму стоковый BBCB. на решение подобных штук я и не претендую, тут надо и другие мезанизмы, и — обычно — подтачивать их под конкретное применение.

budden писал(а):
Ну и плюс к тому, здесь можно найти тему, когда я спрашивал про TLS (thread local storage). TLS - это по сути дела хороший шаг к тому, чтобы каждый поток владел своими данными и тем самым конфликты параллельности для этих данных становятся невозможными по построению.
технически это просто способ избежать дублирования кода в памяти. то есть, вместо загрузки в каждый «поток-процесс» модулей с нуля — каждому создаём отдельный сегмент данных. фича приятная, но не жизненно необходимая (как минимум в той схеме, которую я хочу сделать).

в принципе, если активность все свои данные держит внутри себя и не публикует наружу — то TLS действительно не очень нужно. ну, может чуть-чуть облегчить реализацию схемы «каждой активности свою кучу», но поскольку в A2 активностям не запрещено обмениваться указателями, то даже в этом особого смысла нет. я специально по этой причине обмен указателями делать не планирую, только специальными объектами, которыми можно оперировать исключительно через райдеры.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Воскресенье, 17 Сентябрь, 2023 11:41 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1140
budden писал(а):
Касаемо быстроты одного АП, вообще вот в линуксе есть много способов межпроцессного взаимодействия
и все они приходят к тому, что быстрее всего иметь разделяемую область памяти и API для работы с ней. что я, в принципе, и реализую, только без специальных трюков с системными вызовами (но с трюком бутстрапа нового псевдопроцесса, да; однако это чисто обероновский трюк, независимый от ОС).

budden писал(а):
Насчёт внезапного прихода GC не стоит особо обольщаться. Если у тебя есть N независимых "работяг", и к одному из них пришёл GC, то он на время GC ничего делать не будет.
это всё ещё более предсказуемо, чем многопоточный GC, который может прийти в любой момент. тут я хотя бы точно знаю, какие именно сущности взаимодействуют, и могу быть уверен, что больше в концерт никто не вмешается. если я во всех работниках заранее выделил память, и больше не — то я точно знаю, что нигде в цепочке не будет внезапного прихода GC, который возьмёт и стопнет мне весь мир.

budden писал(а):
Если ты построил из них конвейер, то будет задержка во всём конвейере. А дальше простой для меня пример цифровой музыкальной студии с плагинами. Суммарная задержка в тракте должна быть минимальной. 5 мс - это всё ещё повод для совершенствования. А количество операций над звуком от входа до выхода может достигать десятка (микширование и обработки). Если взять N ББЦБ и в каждом из них написать алгоритм со сборкой мусора, то это всё в целом работать не будет.
конкретно такую задачу я буду решать, когда она у меня возникнет. я ж не претендую на решение типа one size fits all. вполне вероятно, что я для чего-то подобного вообще не буду писать алгоритмы обработки на BBCB, а буду использовать BBCB чисто в качестве высокоуровневого клея. я не настолько фанатик, чтобы «или всё на BBCB, или ничего мне не надо!» ;-)

budden писал(а):
Кроме того, понадобится планировщик задач, команды типа ps и kill. В итоге всё равно получится A2 или другая операционная система :)
BBCB и есть операционная система. ;-) ну подумаешь, она пытается этот факт спрятать. честно говоря — не очень сильно и пытается.

budden писал(а):
Написать планировщик задач - непросто.
так мне не надо его писать, у меня для этого host OS есть.

budden писал(а):
В любом случае, процессы не будут полностью изолированными и нужно будет следить за тем, как они конкурируют за вычислительные ресурсы, управлять этой конкуренцией.
мне вполне достаточно того, что язык не позволит написать код, который нагадит в чужой горшочек. это обеспечивает достаточную изоляцию. приоритеты «потокам-процессам» спокойно назначаются через host OS. а управление ресурсами — это уже задача программиста. у меня будет механизм, который позволит использовать все ядра CPU, и простой API для обмена сообщениями — а остальное строится по необходимости поверх этого. нахождение таких «псевдопроцессов» в одном АП просто облегчает передачу между ними большого объёма данных (по сути, это сводится к передаче одного объекта-хэндла).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Воскресенье, 17 Сентябрь, 2023 11:58 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1140
собственно, мне в компиляторе надо будет только одно маленькое изменение сделать, чисто во фронтэнде: добавить к VAR-параметрам флажок `[nopts]`. чтобы гарантировать, что API обмена сообщениями не получит на вход фигню с указателями, а не проверять это руками каждый раз.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Воскресенье, 17 Сентябрь, 2023 15:45 

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Воскресенье, 17 Сентябрь, 2023 16:48 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1543
arisu писал(а):
собственно, мне в компиляторе надо будет только одно маленькое изменение сделать, чисто во фронтэнде: добавить к VAR-параметрам флажок `[nopts]`. чтобы гарантировать, что API обмена сообщениями не получит на вход фигню с указателями, а не проверять это руками каждый раз.

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


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

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1140
budden писал(а):
но в целом нужно будет ещё как-то управлять жизненным циклом этих процессов, ловить дедлоки на почте и т.п.
а никак не надо. мне для моих задач хватит системного kill(2), чтобы туда сигнал послать. ты учитывай, что у меня есть некоторый круг задач, под которые такая простая система отлично подходит. вот ничего свыше этого я делать и не буду, пока мне оно не понадобится позарез. мне вообще нужны штуки типа «играем музыку на фоне при помощи OpenAL и libxmplite», «просчитываем визуализацию по тайлам» и подобное. для этого с головой хватит: раз отладил — и оно работает. на крайний случай послал туда какой-нибудь SIGTRAP, оно померло.


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

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1543
Ну, если получится - то и хорошо. В принципе-то проект действительно не выглядит сложным, если не ставить высоких требований.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Воскресенье, 17 Сентябрь, 2023 22:06 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1140
budden писал(а):
Ну, если получится - то и хорошо. В принципе-то проект действительно не выглядит сложным, если не ставить высоких требований.
вот! вот это правило, да. я его пытаюсь соблюдать. потому что всегда страдаю овергенерализацией, и пытаюсь сделать что-то чтобы Большое, Универсальное, На Все Случаи. с закономерным результатом. в LC пытаюсь с этим бороться, и делать исключительно простые небольшие кусочки, которые сразу использовать можно. надеюсь, получится. ;-)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 18 Сентябрь, 2023 16:05 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1140
пол-года собирался, и наконец-таки сделал undo/redo в editor control. сам не знаю, зачем: мне оно особо и не надо. но пусть будет, надо ж чем-то бесполезным в память гадить.

p.s.: это я, конечно, начал делать спавнер процессов в том же АП. а получилось undo/redo в editor control. неисповедимы, очень загадочны эти пути.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Вторник, 19 Сентябрь, 2023 14:01 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1140
кстати, в Fonts не хватает полезного API: «а посчитай-ка мне, сколько символов из строки влезет в данную ширину». понятно, что это можно и в цикле руками сделать, но бэкэнд подобную считалку может сильно заоптимайзить. например, мой бэкэнд для X11 считает ширину строки посимвольно, так что там несложно просто остановиться в нужный момент. виндобэкэнд тоже делает что-то похожее, но я не понимаю, что там за куча таблиц и зачем они нужны, так что туда пока воткнул просто цикл.

кстати (лень проверять, писал ли уже): разрешил в текстах один комбайн: acute accent. так-то LC просто отфильтровывает нафиг все юникодовые комбайны, и печатает вместо них «плохой символ» (квадратик, или знак вопроса). потому что я считаю, что комбайны — идиотская идея (как и весь юникод, впрочем). ударение тоже должно быть не комбайном, а набором глифов с пририсованым ударением, но фиг с ним: сделал исключение, потому что использую LC в том числе и для простого набора текстов, и там иногда нужно ударение ставить так, как ожидают ударение некоторые другие софтины.

редактор, если что, вполне нормально с такими извращениями справляется, и всегда справлялся. ну, насколько вообще можно нормально справляться с подобной фигнёй — то есть, приемлемо.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 631 ]  На страницу Пред.  1 ... 27, 28, 29, 30, 31, 32  След.

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


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

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


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

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