OberonCore

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

кстати, я тут подумал: а ведь графоний для всякого инди (читай: low-effort games) можно хранить как обычный ODC-документ. просто накопипастить туда пингов, и всё. ну, имя каждому дать. а на старте парзить этот документ обычным сканером, графоний добывать из views. такая себе замена WAD-ов.

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

не то чтобы это было практически полезно, но очень забавно.

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

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

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

а вот на заре BBCB могло бы получиться killer app. овермарсовый гейммакер довольно кривой и тормозной был, можно было бы его легко обскакать и по фичам, и по удобству, и по скорости (по скорости особенно). получили бы кучу людей, которые умеют писать практически на обероне, гыг. а многие из них потом обнаружили бы, что у них бонусом к гейммакеру ещё и офигенная мощная среда идёт. и вообще, убойный selling point: «вы можете делать видеоигори, которые компилируются в честный машинный код! прямо как профессиональные разрабочики, только проще и быстрее!»

эх, не туда омики целились, надо было в hobbyst entertainment/gamedev лупить. но академическая среда почему-то традиционно считает видеоигори чем-то если и не позорным, то всё равно не очень приличным для серьёзных людей. хотя играть — это самое любимое занятие всех человеков.

Денис, кради идею, пока я патентовать не побежал! ;-)

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

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

Требуете цитату? При том что я и пытался объяснить, но как видим, тщетно, что запрет проверки - это следствие. Ещё раз - следствие, а не прямой текст.

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

Даже тут ложь. Даже C не превращается в вашу воображаемую сишечку. Казалось бы, включите "-fsanitize=undefined -fno-sanitize=alignment -fsanitize-undefined-trap-on-error" и никогда не выключайте, но нет - будут грызть кактус и утверждать, что им так сверху велели.

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

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

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

Этого и не должно быть в стандарте языка, что должно быть очевидно, если понимать для чего стандарт предназначен и для чего не предназначен. Данные ключи предназначены для компиляции в том числе и кода на совершенно стандартном C, так как они в определении языка ничего не меняют. Ошибочно работающий код, полученный при компиляции без этих ключей, не станет работать корректно из-за использования этих ключей, а правильный код, работающий корректно при этих ключах, не начнёт работать некорректно без них. В этом существенное отличие от отключаемой "инициализации", определённой в языке. Совершенно корректный код, написанный в полном соответствии с таким определением, при попытке включения проверки на инициализацию в общем случае станет некорректным, потому что такая проверка нарушает определение языка, провозглашающего, что переменные автоматически "инициализированы", и в большом коде это обязательно будет использоваться.

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

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

кстати: кто замечал, что интерфейс BBCB по сравнению с Обероном сильно ухудшен?

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

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

да, если вспомнить Раскина — это то, что он открытым текстом предлагал. и в Обероне это было. а потом потерялось в угоду мэйнстримному интерфейсу (который абсолютно ужасен по всем параметрам). в A2, вроде бы, ещё не потерялось.

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

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

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

пришло время сделать на форте немного оберона. объекты я уже запилил, надо к ним сверху простенький GC ещё докинуть, и аллокатор объектов на стеке с автоуничтожением по выходу из слова. в смысле: «а зачем, почему оберон не взять?» потому что гортензия. а объектная система понадобилась для гуёв; чем придумывать что-то новое — проще скопировать устройство гуёв из BBCB: чай, умные люди придумывали, не чета мне. соответственно, проще всего тупо сделать расширяемые записи и аналог WITH.

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

вообще, будет довольно интересно попробовать сделать «концепцию BBCB» на другом языке. в том плане, что я вот сейчас думаю, что бы можно было выкинуть для упрощения — и сходу ничего не нахожу. это я про организацию window->document->frame->view. разве только кроме window: мне нативные окна не нужны, так что по идее документ вполне справится. всё равно оконная система — это документ, внутри которого другие документы, так что внутренние окна можно сделать и так.

кстати. а если и в LC окончательно плюнуть на совместимость, и оставить окна только как способ группировки документов в ОС-зависимой рабочей области? понятно, что старый код (не только самой среды) к такому окажется не готов, но у меня-то такого кода немного, и он в основном про окна вообще ничего не знает. тайлер сейчас изо всех сил демонстрирует акробатику прыжков через обручи, пытаясь сделать вид, что он оконный менеджер, а не менеджер документов. это оправдано для совместимости, но мне-то на неё наплевать!

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

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

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

Вот за это мы и любим Оберон ))

надо упороться и сделать оберон-компилятор на форте. будет забавно.

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

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

и не могу не удержаться. местами форт всё-таки адски заруливает всех.

это вот — исполняемый код на форте. таблички инструкций для встроеного ассемблера. в прямом смысле исполняемый: тут нет никакого специального парзера, это просто набор обычных констант, а слово "}" складывает в табличку пять последних значений со стека. (а слово "{" делает ровно ничего, и находится там для красоты.)

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

по зрелом размышлении выделение символов нужно примерно никогда. вместо этого alt+wasd должно работать как стрелочки, alt+space как удаление. про удаление надо подумать: там delete и backspace, оба варианта удобны. но wasd для навигации однозначно. таким образом если у нас правая рука на мыши, то левой не надо к стрелочкам тянуться, чтобы правку в тексте сделать. кроме wasd, возможно, ещё сдвинутый вариант нужен, где-то ближе к центру.

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

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

Вы у себя случайно не делали масштабирование растров каким-то приличным алгоритмом? А то AlphaBlend делает это непотребным образом. Сделал пока через FreeImage изменение размеров, а потом уже AlphaBlend это наносит на DC, но хочется заменить изменение размера на нативную реализацию на КП.

я из AOS упёр. там где-то в Rasters, по-моему, даже с билинейной фильтрацией. он не то чтобы очень приличный, но меня вполне устраивает. по-моему, даже без ассемблера.

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