OberonCore

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

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

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

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

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

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

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

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

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

кстати, направление стрелочек тоже неочевидно. ну, как минимум для меня. может потому что я переученый левша, и мне влево кажется естественней. ;-)

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

Лучше, чтобы пометка аргументов происходила не обязательно программистом, а автоматически. Например, если компиляция модуля в текущем окне была выполнена на несохранённом документе, транслятор вставляет в него нужные знаки. К слову, пометки могут быть и несохраняемыми, чтобы позволить читать дополнительную информацию тем, кто вообще не хочет изменений в языке. И такие пометки могли бы относиться не только к аргументам вызовов, а к чему угодно, что может потребовать дополнительных сведений, и быть настраиваемыми.

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

спасибо большое! всем кричу, что у нас живые документы, а сам без напоминаний постоянно забываю…

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

про DevAnalyzer я в курсе, и мне активно не нравится дублирование кода в нём, и в DevCPP. я конкретно задолбался править два места. почти всё из анализатора умеет и DevCPP (например, компилятор вполне помечает неиспользуемые переменные, и в состоянии их не инициализировать, если это указатели; RETURN у меня уже проверяется лучше; я планирую встроить в компилятор проверку на "use before write", etc.). в итоге анализатор будет проще сделать или одним из режимов работы парзера, или полностью на обработке уже AST.

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

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

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

загрязнохачил модальные формы. модальными одни делаются через gtk, а в модуль Loop добавил `LoopModal()`. это отвратительно и так быть не должно, но я хочу родные формочки вместо гткшных.

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

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

а если совсем честно — мне просто интересно, что с таким подходом сломается, и с каким грохотом.

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

из плюсов — диалог всегда поверх главного окна: это нам обеспечивает GTK+, как и модальность. по идее, на фоне даже дожны продолжать работать actions (что довольно опасно, если акшон попробует открыть окно, ну да ладно).

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

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

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

сделал примитивные и очень небезопасные drawable rasters. примерно вот отсюда и дальше. небезопасные потому что пиксельбуфер — pointer to untagged array. в принципе, его можно и нормальным массивом сделать, я подумаю. но факт в том, что можно заниматься пикселпи… неприличным, в общем, заниматься. и даже альфа-канал есть.

это пока эксперимент, API даже не WIP, а вообще PoC. ну и традиционно: для винды не делал, мне лень. но тем не менее уже можно делать загрузчики любых картинок без внешних библиотек. и экспериментировать со всякими AGG сотоварищи есть на чём.

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

раз уж рекомендуют давать скриншоты, то вот. на самом деле картиночка с альфой, хоть это и не очень видно. формируется чисто кодом, потому very artistic.

кстати сказать, как в обероне, так и в A2 есть ведь рисовалки. в обероне весьма навороченая (и без AA, что мне скорее нравится), а в A2 даже AA вроде бы завезли. интересно, почему никто их не портанул, а сразу на AGG замахнулись? надо посмотреть на предмет быстроутаскивания обероновской: к AA я всё равно отношусь довольно прохладно, и скорее не хочу. вообще, есть желание внедрить в LC регионы, чтобы обсекать графоний как захочется.

подумал — и объединил Raster и DrawableRaster. потом допилю возможность загрузить тот же пинг, получить канвас и всласть порисовать. пока что на загруженых картинках рисовать нельзя, для рисования надо создавать пустые.

доделал reference mode в StdRasters (не знаю, зачем; просто так). заодно сделал отрывание загруженой картинки от файла, если из неё пытаются получить буфер для рисования. то есть, можно загрузать картинку, потом программно на ней порисовать, и это схоронить в документе. схоронится (некомпрессированый пока) RGBA. надо какой-нибудь простенький LZ-компрессор туда привинтить (чтобы не таскать за собой весь zlib).

кстати, раздешил форварды в TYPE. в смысле, форварды для методов (а также EMPTY и ABSTRACT) не запрещают дальнейшие секции TYPE/CONST. а вот после VAR снова TYPE и CONST уже нельзя (CP2 это в оригинале разрешает).

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

а форварды методов разрешил чтобы удобно описывать интерфейсы в одном месте. вроде бы Илья Евгеньевич на форуме за это уже топил, и я согласен, что это handy feature.

как обычно, `MODULE xxx IN ComponentPascal` позволяет всё вернуть в точности как было в оригинале. мой компилятор, кстати, можно (и нужно, я считаю) полностью утаскивать в mainline, достаточно поменять `inCP := FALSE;` на `inCP := TRUE;` в `DevCPP.Module`. совместимость почти полная, исключение ровно одно: проверка на отсутствующие RETURN более строгая. утаскивать затем, что у меня точно есть багфиксы к оригиналу, которых в mainline нет (а какие точно — я уже не помню).

а заодно сделал и синтаксис `Mod.Proc[(…)]:Proc[(…)]…` (идея того же автора). удобно для логов, например.

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

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

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

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