OberonCore

Попробовал рисовать. Как то раньше пропустил этот момент. Запускаю win версию (на моих линукс не хочет, где то у Вас остались привязки к gtk). Идея супер. Вопросик и е - маленькая рисуются (красивый оранжевый цвет, прям мой любимый, правда не всегда). Так понимаю, что-то должно случиться хорошее ))). Но на win не случается (((.

gtk используется для некоторых диалогов, да. я сделал реализацию модальных форм, но диалоги не заменил — всё как-то руки не доходят.

рисовалка у меня в вайне работает нормально, результат даёт. а живой винды нет. возможно, вы не так глиф нарисовали, как я рисую. %-) Edit -> Stroke Library Editor — там редактор глифов.

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

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

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

Нет, полные исходники по ряду причин выкладывать не буду. Одна из причин - негативное отношение к open source проектам, и одна из причин - против клонов. Чем мне импонирует именно Ваш проект. То что он именно Ваш - со своими замечательными придумками, которых больше нет ни у кого.

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

да мне не надо: я всё равно принципиально пользуюсь только тем, что сам сделал. ;-)

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

вот не было бы исходников оригинального BBCB — не было бы и LC. я BBCB знаю уже не первый десяток лет — и в своё время не смог использовать как раз потому, что исходников не было. на то время драйвер ODBC настаивал, что весь текст в базе — latin1 или unicode. а у меня в базе был cp1251. который BBCB никак не хотел правильно понимать. и не поправить — потому исходников нет. на том попытка применения BBCB для «серьёзных дел» и закончилась. купить на то время я не мог, попросить омиков допилить тоже. и забросил на кучу лет.

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

вернулся только несколько лет назад — что-то стрельнуло в голову поспмотреть, как там дела у BBCB, что с линукс-портом, как чо ваще. и оказалось, что исходники перелицензировали, линукс-порт более-менее пилят, оно живое! я, конечно, непередаваемо обрадовался, порт запустил — а он мне не понравился. не то. не так. я иначе хочу. пришлось браться мозолистой рукой за редактор…

это я всё к тому, что без исходников ничего бы этого не случилось, и я бы так и не вернулся. сборок BBCB было много — ну и что? все они спокойно померли, достойное было интегрировано или в маинлайн, или вытащено в виде библиотек. никто на «спёртом» BBCB прославиться не смог.

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

p.s.: оригинальная лицензия не заставляла выкладывать исходники LC, например. я тоже мог их спокойно спрятать. GPL на LC повесил я лично, потому что BSDL позволяет такой финт.

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

>>>> да мне не надо: я всё равно принципиально пользуюсь только тем, что сам сделал.

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

В моем коде, также нет ни одной заимствованной строчки. Да, книжка Вирта - настольная. Читана и перечитана. Но код написан с нуля. Не скажу, что он лучше, скорее хуже. Но он мой. А идеи, или то что считаю идеями, давно все рассказал и разжевал. Не скрывая ничего. Их совсем не много и повторить не представляет усилий.

Вот с BB мне повезло больше. Сразу попала в руки 1.5 с исходными текстами. До сих пор сижу на ней. Спасибо Омикам. Да, допиливал под себя. Добавил dispose. Наверное главный хак. Делал на нем, свои многопоточные системные проги (ftp, http, dbf сервера, от odbc сразу отказался, несколько 100-ен пользователей не вытягивал, и idapi не вытягивал). И ormcode - первая рабочая версия на нем ))).

По поводу лицензии. Честно даже не думал пока об этом. На сегодняшний день ormcode для среднестатистического пользователя - игрушка. И подаю ее как игрушку. Слишком много багов, которые пытаюсь выдать за фичи. Я их знаю, научился обходить и мне они не мешают. Практически почти всё свое из BB портировал к себе. Вот как только, баги-фишки исправлю, тогда и буду думать над лицензией.

>>> с BBCB такой финт не прокатит: там же дерево видимых views строится каждый раз на лету

По мне настоящий подвиг, view-model-controller. Написал на BB несколько простых визуалов. И понял это не мое. Так и появилась SML, примитивная, прямолинейная, на двухнаправленных списках. Эстеты скажут отстой, а мне хватает ))).

на самом деле у BBCB одна из самых простых, логичных и удобных концепций для гуёв. надо только один раз её себе в голову встроить — и остальные покажутся костыльным убожеством. BBCB не заставляет обязательно иметь полный MVC: view спокойно можеть обходиться без остального.

скорее всего, вас просто отпугнула непривычность. это нормально: непривычное поначалу всегда кажется неудобным. надо внимательно курить справку и Obx до просветления. у BBCB великолепная справка: там есть ВСЁ. никаких книг, которые «обучают программированию в BBCB», не нужно: всё есть в справке. всё, рассказаное в справке, сопровождается примерами в Obx. когда возникает вопрос «как сделать» — ответ есть в справке. точно есть. ни разу ещё так не было, чтобы я там не находил ответа. точнее, было: когда я заранее решал, что ответа там нет, и справку не открывал. потому что Настоящие Программисты не читают помощь, ага. ;-)

когда вы грок — вы увидите, что система BBCB не только проще решений, которые кажутся простыми, но ещё и гибче. оберон же: простота и гибкость, выбирайте любые два. единственное, чего не хватает — это нормального layouter'а в Forms. я всё собираюсь его сделать, но всё как-то…

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

для меня BBCB — единственная система, где вместо: «ох, ёлы-палы, опять гуй лепить, снова СТРАДАНИЯ» — получается: «а, гуй? да ща, один момент. дело нехитрое. через пол-часика будет, сейчас настрочу нужных компонентов, чтобы было КРОСИВОЕ, не проблема.»

так это Хитрый План: кто-нибудь обязательно придумает что-нибудь лучше. или сделает красивей. а я тут как тут: сопру себе!

а так — дело ваше, конечно. я вам высказал своё мнение: открывайте код, ничего не бойтесь. дальше «давить авторитетом» не буду: право автора делать как ему нравится.

>>>> для меня BBCB — единственная система, где вместо: «ох, ёлы-палы, опять гуй лепить, снова СТРАДАНИЯ» — получается: «а, гуй? да ща, один момент. дело нехитрое. через пол-часика будет, сейчас настрочу нужных компонентов, чтобы было КРОСИВОЕ, не проблема.»

Прям с языка сняли ))). SML тоже так и сделал, чтоб - ok через пол-часика будет. Так и строгаю, по мере надобности ))). А редактор форм ???. Да в BB не самый лучший (((.

В своё время запилил, автономный редактор на основе Delphi с универсальными самописными дельфийскими компонентами, и в html тоже. Получилась связка Delphi приложение + свой http сервер = автоматическая публикация в инете. Ну там, всякие авторизации доступа, форумы, интернет магазины. Сейчас хочу эту технологию перенести в wasm. Должно получиться красивее. Заодно и редактор форм портировать (скорее по новой написать) исключительно для ormcode. Правда, и у меня как-то . . . (((.

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

так-то если вас ваша система устраивает — и отлично. у меня вон в O/Ur дельфиподобные динамические строки, прямо в язык тип STRING вкрячен. пуристы закричат: «ату его!» а я отвечу… матерно отвечу, в общем. «не ваша, потому и завидуете!»

я свой спич вёл не к тому, что ваше решение плохое. я хотел вас заинтриговать немного, чтобы вы опять попытались логику за BBCB грок. а вдруг в конце концов больше понравится? ;-)

p.s.: я же вот по поводу наличия DISPOSE (FRE, или как там её, простите) молчу, ну. хотя это такая дырень в системе безопасности оберона, что туда космокрейсер с друзьями влезет и не заметит. ;-)

И правильно сделали, в компоненты дельфи лучше не лезть. Мне деваться некуда было. Скрипел всеми местами, читал заумные книжки и по аналогии ваял, не очень понимая, что делаю. Честно, до сих пор не понимаю (((.

Дельфовые строки, это супер. То же бы сделал. Пороху не хватило, или мозгов скорее всего (((.

Да, я и сам двумя руками за. Вы уже на столько интересных моментов, глаза открыли. Не знаю, за что хвататься. Хочется все и сразу. А голова кругом, умею одномоментно делать только, что-то одно.

Dispose, да. И спорить не буду. Выбрал вариант по силам. GC мне нужен многопоточный и плюс, у меня стиль - без зазрения совести временным переменным присваиваю ссылки. Хорошо кроме меня, никто не видит ))).

да там несложно. по сути STRING — это указатель на динамически выделяемую структуру, в которой счётчик ссылок, длина строки, да указатель на её данные. в прологе процедуры всем локальным переменным типа STRING присваиваем NIL (я вообще все-все локалы на входе зануляю, потому что лень ловить ошибки типа «use before initialised»). потом аккуратно инкрементим/декрементим ссылки. перед каждым RETURN вставляем вызовы внутренней процедуры `StringDecRef()`, например. в общем-то всё. главное быть внимательным, и нигде не пропустить инкремент/декремент. и будут у нас динамические строки.

я ещё слайсы строк сделал: структура строки имеет флажок: «а я не настоящая строка, я кусочек вон той строки!» чтобы всякие операции взятия подстрок дешёвые были.

в общем, компилятор под капотом занимается шулерстом — ну и пусть: на то он и компилятор.

сами строки я выделяю вне обероновского хипа, тупо через либцшные `malloc()`/`free()`. можно было сделать для них отдельный менеджер памяти, конечно — но зачем, если я всё равно к libc обращаюсь уже.

знакомая беда, да. столько интересного, и всё хочется.

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

кратко: вставляйте в начало (или конец) циклов, а также в пролог и эпилог gc sync points. это обычная глобальная переменная, которая работает как спинлок. `NEW()` поднимает спинлок и ожидает, пока все потоки дойдут до safe point и застынут в ожидании освобождения спинлока. на этом моменте можно совершенно безопасно делать обычный GC, потому что у нас гарантировано ровно один пользователь. как закончили — отпускаем лочку, все спокойно едут дальше.

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

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

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

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

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

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

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

Супер, спасибо большое. Взял на вооружение. У себя сделал отдельный модуль ARISU.MOD - туда вошло вычисление хэша, гпсч, мантисса и экспонента без ассемблера и Вами подсмотренный в kernel алгоритм сортировки ))).

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

И хочу похвастаться - простенький менеджер памяти. Выделяет блоки переменной длины, и даже объединяет свободные блоки. Если убрать коменты, чуть больше 50 строк. Использую как встраиваемый, по необходимости. Скорее всего открыл велосипед. Но вдруг кому окажется полезным ))).

проблема с таким подходом в том, что требуется почти полноценный data flow analysis. например:

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

это не так бессмысленно, как может показаться: штуки чуть сложнее вполне встречаются в разных алгоритмах (инициализация переменной внутри цикла по некоему условию, причём программист доказал, что инициализация будет всегда, но компилятору это не очевидно). конечно, проще всего в таком случае потребовать явной инициализации `a` до цикла, но… лично у меня это вызывает матерную тираду. «муля, не нервируй меня!»

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

по уму, конечно, REAL'ы надо бы инициализировать NaN'ами, но это усложняет и замедляет код.

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

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

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

Так и хочется сказать, кто не . . . , тот сам себе Буратино. И что хотел . . . с большой колокольни !!!. Но не скажу, потому что сам и есть первый Буратино, и за руку ловился не один, не два и даже не три раза. Даже в таком неполноценном варианте.

Почему, не обнуляю (узнал с Вашего топика, уже месяца 3 точно), тем более структура ABI в Ormcode идеально подходит. По одной причине, к хорошему привыкаешь мгновенно. И мгновенно сместится приоритет (сделано исключительно, для исключения UB на пустом месте), к - о как здорово у меня переменная всегда 0 (что global, что local) и буду этим пользоваться напропалую (знаю себя) (((.

И вторая причина. Примерно 20 % времени в BB и 80 % в Ormcode. До сих пор сохраняется почти полная идентичность исходников и там и там. Кстати легко получить полноценный 32-х разрядный Ormcode скомпилировав в BB.

Полноценный аллокатор, да. Теперь знаю где искать при необходимости. Спасибо ))). А простенький можно например для стека использовать, где нибудь в верхних областях ???.

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

на самом деле с моей точки зрения то, что некоторые локалы инициализируются — намного хуже. надо делать лишнее усилие, вспоминать, какие да, какие нет. зачем? просто почистим всё. тем более что репорт по компонентному паскалю требует, например, чтобы `NEW()` память занулял. получается разнобой: тут да, тут нет, тут частично… а я за единообразие, где это ничему не мешает.

у оригинального CP2 из коробки есть режим «обнулять все локалы», просто он выключен. в LC я включил, так что LC тоже обнуляет, например. включите себе — и проблема пропадёт. ;-)

этого вопроса я не понял. разверните, пожалуйста.

В Линукс две процедуры выделения памяти. Одна для кучи, другая для стека (если не смотреть shm). А в windows - для стека нет. Можно присвоить heap на конец (или начало - в общем на адрес с меньшим значением) и считать его началом стековой кучи (не знаю как правильно выразиться).

Тем более, что и BB есть системная функция - вытащить значение из регистра sp. Вот кажется идеально может подойти для реализации дельфийских строк. Как вариант, не надо вообще использовать malloc, и GC никак не затронет. Мысли вслух. Если, что не так, смело бросайте помидоры (только не зеленые) ))).