Проект pw

[смотритель]

Содержит 2922 строки на исходном языке, не считая тестов.

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

2024-11-12 - перевёл 177 строк констант, но из-за смены версий придётся вернуться к этому (или даже совсем переделать)
2024-11-26 - перевёл ещё 11 строк (и написал пару сотен для инфраструктуры)
2024-12-04 - ещё 27 строк

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

[Глеб]

Даже с этим на полный перевод 3000 строк уйдёт 240 дней.

Это нормально, но работать не будет.

[Лис [Вежливый]]

Что за проект такой? Для чего он нужен? Какие имеет характеристики? Это и многое другое предлагается угадать телепатам.

̶P̶W̶-̶p̶r̶o̶j̶e̶c̶t̶ ̶→̶ ̶и̶г̶р̶о̶в̶о̶й̶ ̶с̶е̶р̶в̶е̶р̶ ̶P̶e̶r̶f̶e̶c̶t̶ ̶W̶o̶r̶l̶d̶

[смотритель]

Не обращайте внимания, это я для себя записки делаю.

[смотритель]

После долгого перерыва перевёл ещё 27 строчек. Усилия были затрачены на улучшения языка Яр-22, в него были добавлены типы-объединения, которые нужны для конвертации данного входного кода. Ни один тест ещё не запускал.

[смотритель]

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

[смотритель]

Применением неимоверных усилий удалось написать ещё три строчки (на самом деле просто откатился от "продвинутых" решений к простым). Но на самом деле то, что мне не удалось одолеть ошибку в мат. массивах, вызывает дрожь. Это ведь ещё ни разу у меня не было повреждения кучи. Надо что-то делать с этим. Видимо, уделить треть усилий на покрытие всего, что можно и нельзя, тестами и пополнение документации. Хотя на самом деле и так 95% усилий идёт на развитие инструментария.

[смотритель]

Ещё 2 строчки.

[смотритель]

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

[БудДен]

Ещё 7 (перешёл обратно под Windows, где лучше с отладкой, хотя это "лучше" тоже вызывает слёзы).

[БудДен]

Последняя версия вывода:

Код: Выделить всё

 (к.Пиши 10B4F200~)(

 объ = 10B4F200 адрВнутр = 00000000, смещ = 24C,  имяМодуля =
pyBytes[&10B4F200 pyBytes.t10B4CC7C<- УМетаданныеТипаДляСборщикаМусора1: АдресИзОбъектИТип ->10B4F200{pechPredokISebja10B4CC7C::10B4F200{pechPredokISebja: вход}{pechPredokISebja: 2, offset4 = 588}

   п typeCode 10B4CC7C
   п count 3{P cpuid= 0, pid= 10076 C:/jaos/source/МетаПечать2а.ярм@32418 МетаПечать2а.ЭтоSystemBlockЛи:ок; }

   п байты (к.См 10B4F20C pyBytes:292~)(ADR &10B4F240 [3] бцел8 : (
      0: 48
      1: 69
      2: 21))}]){P cpuid= 0, pid= 10076 C:/jaos/source/pyBytes.Mod@2851 pyBytes.ПроверьМассивБЦел8:щ^=
 объ = 00000000 адрВнутр = 10B4F200, смещ = 24C,  имяМодуля =
pyBytes[&10B4F200 pyBytes.t10B4CC7C<- УМетаданныеТипаДляСборщикаМусора1: АдресИзОбъектИТип ->10B4F200{pechPredokISebja10B4CC7C::10B4F200{pechPredokISebja: вход}{pechPredokISebja: 2, offset4 = 588}

  п typeCode 10B4CC7C
  п count 3

Работает:

Код: Выделить всё

пВКонтексте
  ПечВКонтекстеВнутр
    ИзучиТипЭтогоANY
    пИзученныйОбъект
      WritePointerToRecord
        пЗапись,используяОит
          пПредкаИСебя,используяОИТ

Не работает:

Код: Выделить всё

Пиши
  LisIntermediateBackend
    к.ПишиЗаписьЛЯ
       пПоАдр(адресЗаписи, адресДескриптораТипа)
          пПоАдрВКонтексте
             АдресЗаписиИУМетаданныеТипаДляСборщикаМусораВRecordTypeDeclOffset
                пЗапись˛используяОит

[БудДен]

Мораль - понять, что на входе в пЗапись˛используяОит

[БудДен]

Итого, падает в

МетаПечать2а.пБолееСТ_массивВнутр.ДайДлинуИАдресПервогоЭлта

на

"если ЭтоSystemBlockЛи(адресОбъекта) то"

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

[БудДен]

Падает на трассировке, вероятно интроспекция где-то испортила стек. Это происходит в самом начале, когда мы изучаем тип записи.

Код: Выделить всё

========= ПроверьМассивБЦел8 вход =========
 (к.Пиши 0DB80DC0~)°1°2°3(°5°6
[&0DB80DC0 pyBytes.t0DB7E83C<- УМетаданныеТипаДляСборщикаМусора1: АдресИзОбъектИТип ->0DB80DC0{pechPredokISebja {pechPredokISebja: вход}{pechPredokISebja: 2, offset4 = 588}
base = 0DB80DC0
@599ссПеременная
{P cpuid= 0, pid= 12960 C:/jaos/source/МетаПечать2а.ярм@93792 МетаПечать2а.OutputOffset:1= 1; }

  п typeCode
@614ссОтносительн
{P cpuid= 0, pid= 12960 C:/jaos/source/МетаПечать2а.ярм@93792 МетаПечать2а.OutputOffset:1= 1; }
адр/base = 0DB80DC0/0DB80DC0Ъ≡0DB7E83Cbase = 0DB80DC0
@619ссПеременная
{P cpuid= 0, pid= 12960 C:/jaos/source/МетаПечать2а.ярм@93792 МетаПечать2а.OutputOffset:1= 1; }

  п count
@631ссОтносительн
{P cpuid= 0, pid= 12960 C:/jaos/source/МетаПечать2а.ярм@93792 МетаПечать2а.OutputOffset:1= 1; }
адр/base = 0DB80DC4/0DB80DC0Ъ≡3base = 0DB80DC0
@636ссПеременная
{P cpuid= 0, pid= 12960 C:/jaos/source/МетаПечать2а.ярм@93792 МетаПечать2а.OutputOffset:1= 1; }

  п байты
@653ссОтносительн
{P cpuid= 0, pid= 12960 C:/jaos/source/МетаПечать2а.ярм@93792 МетаПечать2а.OutputOffset:1= 1; }
адр/base = 0DB80DCC/0DB80DC0†≡(к.См 0DB80DCC pyBytes:292~)[х][ю]°1°2°3(ADR °3а°3в&0DB80E00 °4$1$2$3$5~1`2b0DB80E00{P cpuid= 0, pid= 12960 C:/jaos/source/МетаПечать2а.ярм@32465 МетаПечать2а.ЭтоSystemBlockЛи:☼1; }
{P cpuid= 0, pid= 12960 C:/jaos/source/МетаПечать2а.ярм@32530 МетаПечать2а.ЭтоSystemBlockЛи:☼2; }
{P cpuid= 0, pid= 12960 C:/jaos/source/МетаПечать2а.ярм@32756 МетаПечать2а.ЭтоSystemBlockЛи:☼4; }
{P cpuid= 0, pid= 12960 C:/jaos/source/МетаПечать2а.ярм@32830 МетаПечать2а.ЭтоSystemBlockЛи:☼5; }
{P cpuid= 0, pid= 12960 C:/jaos/source/МетаПечать2а.ярм@32972 МетаПечать2а.ЭтоSystemBlockЛи:ок; }
`2b1[3]~2 бцел8 : ~3(
     0: 48
     1: 69
     2: 21)~4)
@660sfProcedure
{P cpuid= 0, pid= 12960 C:/jaos/source/МетаПечать2а.ярм@93792 МетаПечать2а.OutputOffset:1= 1; }

@705sfProcedure
{P cpuid= 0, pid= 12960 C:/jaos/source/МетаПечать2а.ярм@93792 МетаПечать2а.OutputOffset:1= 1; }

@781sfProcedure
{P cpuid= 0, pid= 12960 C:/jaos/source/МетаПечать2а.ярм@93792 МетаПечать2а.OutputOffset:1= 1; }

@839sfProcedure
{P cpuid= 0, pid= 12960 C:/jaos/source/МетаПечать2а.ярм@93792 МетаПечать2а.OutputOffset:1= 1; }
}]){P cpuid= 0, pid= 12960 C:/jaos/source/pyBytes.Mod@2947 pyBytes.ПроверьМассивБЦел8:щ^= [&0DB80DC0 pyBytes.t0DB7E83C<- УМетаданныеТипаДляСборщикаМусора1: АдресИзОбъектИТип ->0DB80DC0{pechPredokISebja {pechPredokISebja: вход}{pechPredokISebja: 2, offset4 = 588}
base = 0DB80DC0
@599ссПеременная

[БудДен]

Дело в рекурсивном вызове трассировки. Вот так можно потратить полдня на ерунду. Как защититься?

[Глеб]

Как защититься?

1. Выбрать метод программирования.
2. Выбросить исходники.
3. Действовать по инструкции, приложенной к методу.

[БудДен]

Неохота оставлять это за спиной, поэтому попробую докопаться
до сути этой проблемы. Вот что генерируется (компиляция с -trace='*') из
вызова пПиши.

Код: Выделить всё

	 9: call u32 ЛогЯдра.ЗахватВЕдиноличноеПользование[C94E30954DB97A8E]:0, 0
	10: push u32 67
	11: push u32 pyBytes.@const0[66A1C635009C574B]:0
	12: call u32 ЛогЯдра.пСтроку8[C78E309CBB1F01D1]:0, 8
	13: mov u32 r1, u32 [fp-16432]
	14: push u32 r1
	15: push u32 r1
	16: push u32 [r1-4]
	17: call u32 к.ПишиЗаписьЛЯ[3A0A0A81DED757F2]:0, 8
	18: pop u32 r1
	19: push u32 3
	20: push u32 pyBytes.@const1[F4620016C6132BB9]:0
	21: call u32 ЛогЯдра.пСтроку8[C78E309CBB1F01D1]:0, 8
	22: call u32 ЛогЯдра.ОсвобождениеИзЕдиноличногоПользования[CFA2806FFB3E2E3]:0, 0

[БудДен]

А вот - для трассируй(щ):

Код: Выделить всё

	 9: call u32 ЛогЯдра.ЗахватВЕдиноличноеПользование[C94E30954DB97A8E]:0, 0
	10: push u32 66
	11: push u32 pyBytes.@const0[96CD438C6A19F60E]:0
	12: call u32 ЛогЯдра.пСтроку8[C78E309CBB1F01D1]:0, 8
	13: push u32 [fp-16432]
	14: call u32 ЛогЯдра.пАдресВПамяти[FE26EFDE2576FB0C]:0, 4
	15: push u32 2
	16: push u32 pyBytes.@const1[73E8C4002D8C1FF7]:0
	17: call u32 ЛогЯдра.пСтроку8[C78E309CBB1F01D1]:0, 8
	18: push u32 3
	19: push u32 pyBytes.@const2[F4640016C6132BB9]:0
	20: call u32 ЛогЯдра.пСтроку8[C78E309CBB1F01D1]:0, 8
	21: call u32 ЛогЯдра.ОсвобождениеИзЕдиноличногоПользования[CFA2806FFB3E2E3]:0, 0

[БудДен]

Соответственно, минимальный вариант, ведущий к катастрофе, таков:

Код: Выделить всё

	ЛогЯдра.ЗахватВЕдиноличноеПользование();
	ЛогЯдра.ЗахватВЕдиноличноеПользование();

Второй вариант:

Код: Выделить всё

перем перем й: укль на массив из симв8;
нач
	ЛогЯдра.ЗахватВЕдиноличноеПользование();
	утв(й # НУЛЬ);

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

Для завершения картины, в Windows захват ядерной блокировки вызывает утв.
Решение - вместо утв ставить Shutdown с уникальным кодом?

[БудДен]

Как защититься?

1. Выбрать метод программирования.
2. Выбросить исходники.
3. Действовать по инструкции, приложенной к методу.

4. Когда это не сработает, перейти к пункт 1.

[БудДен]

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

[Глеб]

4. Когда это не сработает, перейти к пункт 1.

Сначала - пройти все положенные петли в пп. 2 и 3.

Нет, конечно, Вы можете верить, что "дальше будет легче", но обычно бывает наоборот. Что заложил в начале, то и расходуешь по дороге к результату, и приходишь к цели с "пустыми баками" и "нулевым запасом прочности".

[БудДен]

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

[БудДен]

Сегодня написал порядка 3 строчек, хотя основные усилия были потрачены на расширение функционала интерпретатора . Когда стало ясно, что я занимаюсь не тем, написал эти 3 строки, и тут выяснилось, что есть ошибка при присваивании маленького (8-битного беззнакового) числа большому (64-битному знаковому). Вроде бы я её даже исправил, но что-то пошло не так и в других случаях компилятор начал падать. Придётся дальше разбираться.

[БудДен]

Ещё 3. Зато исправил одну ошибку в компиляторе (возможно, что впервые залез в файл кодогенерации для AMD). На 3 строки, которые надо было поправить, ушло примерно 2 дня, и они не считаются за использованные в проекте, конечно.

[БудДен]

И ещё строчек 5-6 дописал.

[БудДен]

Целых 27 строчек, хотя тестами они не покрыты. И заодно решал проблему с литералами с плавающей точкой (так до конца и не понял). В итоге была переписана функция преобразования из строки в число с плавающей точкой, строк на 50.

[БудДен]

Ещё 42. Напоминает игру "верю-не верю" : ещё 42 туза.

[БудДен]

Строчки не движутся, начался очередной рефакторинг.

[БудДен]

6 строк, но отладочную печать опять надо чинить.

[БудДен]

Ну вот, похоже, зря я столько мучался с типами-объединениями, поскольку первый же объект с полями всё равно лезет в кучу. А поскольку в Питоне нет Value types, то сравнение объектов требует, чтобы каждый объект был отдельным объектом на куче и передавался по ссылке. В этой ситуации мой тип "v" становится не более, чем "умным указателем". А нужен ли он для данного проекта? Вряд ли. Если же в коде будут смешаны и типы-значения (для особых случаев, каковыми на самом деле являются только одиночные числа), и типы-ссылки, то путаница возрастёт. Вместо одной сущности уже сейчас приходится определять три:

* член типа-объединения для v со специфическими полями
* метакласс
* переменную метакласса

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

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

[БудДен]

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

[БудДен]

Пока не буду менять.
Ещё 10 строк за сегодня, и опять правил отладочную печать. Но теперь хоть чуть разобрался.
Из 10 строк ни одна не протестирована к тому же.

[БудДен]

Видимо, всё же напишу ещё класс-другой, а потом надо будет упрощать и приводить всё к уклям. Простота прежде всего.
Хотя в принципе и так оно должно быть способно работать.

Между тем, в проекте python + pw у меня уже 3159 строк, из них 1240 относятся к проекту pw. Наблюдается большой коэффициент разрыхления при переводе с Питона на Яр-23

[БудДен]

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

[БудДен]

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

* исчезли метаклассы (хотя на самом деле, потеряна информация о соответствии между питоновым именем класса и обероновым классом, но пока она ни разу не понадобилась)
* исчезло множество преобразований типов
* размер кода сократился до 2716 строк, т.е. примерно 350 строк удалено. Учитывая, что в проекте до 1000 строк занимают всякие определения констант - это много.
* код стал проще и яснее
* нагрузка на кучу вырастет - но это не страшно, "сначала сделай, чтобы работало".

+ ещё 14 строчек. Постепенно разгоняюсь, похоже. Однако это каникулы. Если всё будет нормально, то 9-го числа мне должны предложить работу. Делим остаток из 3000 строк (пусть даже содержательных там 1500) на 10 строк в день и получаем срок завершения в 150 дней, т.е. полгода. Ну сомнительно.

[БудДен]

Ещё 13+10+8 = 41. Пока что идут однообразные и простые классы. Тестов сегодня не писал.

[БудДен]

12 + 9 + 12 + 8 = 41 и даже один тест.

[БудДен]

Не видать мне больше шахмат. Я начинал с более новой версии, а теперь перешёл на более старую. У меня средней тяжести игромания и я вчера установил правило, что день шахмат может быть в любой день, но после того, как написаны очередные 250 строчек с прошлого дня шахмат. И вот, я уже успел "портировать" большой модуль констант с новой версии исходного проекта. А теперь оказалсь, что надо откатиться на старую версию исходного питоньего проекта, а там этот файл гораздо меньше. Итого, -240 строчек.

[БудДен]

На конец дня: -240 + 18 = -222. Опять пришлось лезть в разные инфраструктурные вещи, в т.ч. добавлять для Питона ещё одно обличье кортежа.

[БудДен]

+21 = -201
+15 = -196
+6
+27
+13
+9 = -141
+13
+10
+11 = -107
да, до +250 уже разучусь в шахматы играть. Хотя, казалось бы, надо радоваться - почти 100 строк за сегодня.

[БудДен]

+25 - видимо, на обед заработал.
+11
Нда, быстро пишется, но это простые классы и сериализация. Может уже пора ChatGPТ это поручить?
+11 (ChatGPT перевёл)
+10 (ChatGPT перевёл, но странно, что второй кусок он перевёл хуже, хотя это был новый чат. Неужели он халтурит?)
+11 (ChatGPT перевёл, без замечаний)
+10+11 =-18

[БудДен]

+40 = 22 на фрагменте в 100 строк ChatGPT стал откровенно чудить, пришлось много переделывать. Руками было бы быстрее в данном случае. Хотя я и модель переключил на более дешёвую. Но ура, я в плюсе! До шахмат остаётся перевести "всего" 228 строк.
+12 (GPT ок простой файл)
+19+12 = 65 (GPT пришлось дать ещё одну инструкцию, но на самом деле там не хватало реализаций деталей, чтобы
он перевёл правильно)

[БудДен]

+11 (можно даже не удалять текст инициализации модуля)
+10+9+15 = 110

[БудДен]

+11+14+13 = +148

[БудДен]

+6+7+11

[БудДен]

+10 (и порядка 70 строк инфраструктурного кода, но это же не считается)
+11
+6
+29 = 228 - до дня шахмат осталось 22 строчки
+28 = 256 - ура, шахматы!

[БудДен]

+9+9+5+5

[БудДен]

+5+7+5+15+7+5 = 328

по мере того, как код перестаёт быть тривиальным, польза от ChatGPT стремительно убывает. Ждём, пока перевалит за 0 и станет отрицательной. Впрочем, это будет ясно только после начала тестирования.

[БудДен]

+53 = 381 - нашёл модуль, который ниоткуда не вызывается и перевёл его за 5 минут, которые потребовались, чтобы это выяснить и вставить заглушку вместо модуля. Вот как надо работать, учитесь! Правда, потом, когда выяснится, что он всё же был нужен, буду плакать и вычитать.

[БудДен]

+6=387 - ещё один маленький модуль. И остался основной модуль грязным размером (включая пустые строки и комментарии) в 2111 строк. Мало не покажется.

Код: Выделить всё

-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Python                           1            302            157           1654
-------------------------------------------------------------------------------

[БудДен]

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

Во всяком случае, уже получен положительный опыт использования ChatGPT для хоть какого-то перевода на Яр-23. Успехи оказались, в принципе, лучше ожидаемого. Хотя перевод наполовину бредовый, всё же он помог ускориться и некоторую часть работы ChatGPT сделал сам. В наше время нужно уметь применять БЯМ-ы, и вот я получил очередной кусочек практики.

Кроме того, я сделал типы-объединения. Реальной пользы они не успели принести (скорее вред, т.к. на них было потрачено много драгоценного времени), но во всяком случае, меня больше не будет преследовать мысль "как сделать типы-объединения для Яра-2*", теперь будет преследовать мысль "как в них закрыть оставшуюся дыру".

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

[БудДен]

Выкинуть ничего нельзя, решил протянуть срок ещё на месяц, хотя это уже совсем впритык. Видимо, параллельно надо всё же предпринять усилия для трудоустройства.
+95 = 476, без ChatGPT

[БудДен]

+17+8+7=508, без ChatGPT
Шахматы.

[БудДен]

+6+5+12 = 531, итого за сегодня 144 строки, невзирая даже на шахматы. Такими темпами что-то будет сделано, но пока идёт очень простой код, дальше явно должно быть сложнее.

[БудДен]

+4 - ни дня без строчки (на самом деле нет).

[БудДен]

+1+7 (руками, но уже подумываю, не пора ли припрячь опять ChatGpt *)
+6+4
+15 = 568 (с ChatGPT, но пришлось переделывать)
+6+6+11=591 (ChatGPT, даже с переделками всё равно выигрыш по скорости кажется большим)

[БудДен]

+9
+8 (эти 8 потребовали реализовать сравнения для целых чисел)
+2 (а теперь понадобилось реализовать поэлементное сравнение списков)
+2 = 612

[БудДен]

+18 - вкалывают роботы, а человек за ними всё исправляет.

[БудДен]

+49=679 , но надо не забыть сделать сложение списков. И ещё хвосты остались. Но ничего, пока потерпим.

[БудДен]

+4+6+8+8+15 = 720 - всё руками. Пробовал ускорить макросом редактора, но по сути дела пользы никакой. Зато освежил память о том, как эти макросы работают.
+45 = 765 - шахматы заработаны, обед тоже.
+19 Ох как на самом деле ещё много осталось :( Грязного кода 1500 строк, чистого лень считать.