Несколько дней назад я внёс в OPCL действительно серьёзные изменения, связанные с отображением позиции отложенной ошибки. Все ошибки, скажем так, которые ловит компилятор, либо отображаются сразу (с ними нет проблем), либо же откладываются компилятором до принятия решения, являются ли они действительно ошибками. Такие ошибки я назвал отложенными (postpone). Не Бог весть как много я за это время программировал на этом компиляторе, но всё-таки дошли руки и до этого бага. Хочу пояснить почему столь существенные изменения. Я не очень уверен в них, скажем так, не на 100%. Потенциальные баги ещё предстоит отловить, но вся прелесть Git'а, на который меня подсадил Саша Ильин (я ему за это очень благодарен) в том, чтобы плоды разработчиков были доступны друг другу даже после изменения мэйнтейнера проекта.
Удалось скрестить Syn Text Editor с компилятором. Выглядит симпатично, почти что IDE. Ошибки ловятся очень приятно и быстро (раньше для этого приходилось в hex-редакторе вычислять позицию в тексте). Если кому-нибудь интересно, распишу подробно как его настроить для использования с OPCL.
Так про изменения. Внутренняя структура компилятора очень всерьёз опирается на позицию в тексте, выраженную одним числом (и одной переменной соответственно), поэтому все структуры, где хранится данная позиция, естественно жёстко предписывают её одним числом. Есть 2 варианта: либо вычислять строку/колонку по этому числу, либо же решиться на добавление в много разных структур нового абстрактного типа TextPos и определение операций для него. Первый вариант я рассматривал с огромным желанием не вмешиваться в ещё не до конца понятую логику работы компилятора, но его пришлось отбросить ввиду вот чего. Для того, чтобы вычислить строку/колонку по позиции в тексте нужно иметь доступ ко входному файлу, чтобы считать строки. Этого сделать нельзя, потому что компилятор не хранит весь текст сразу, а считывает его маленькими порциями в буфер и уже оттуда выдаёт посимвольно. Ещё вариант — хранить в отдельном массиве длины строк — я отбросил тоже. Всё-таки зачем заводить лишнюю структуру, если по уму оно должно выглядеть совсем не так. Вот почему я и решился на введение нового типа OPM.TextPos. У него есть методы TextPosInit — начальное обнуление позиции, TextPosPrev — отступить на символ назад (по мере сил конечно) и присваивание одной структуры другой (типа errpos := curpos). Определения я вводил таким образом, чтобы не выбиваться из общего стиля устроения компилятора. В частности, не воспользовался процедурами, связанными с типом. Это было бы логичнее, но такие процедуры не используются в компиляторе.
Также обновил файл Readme.txt, дерзнув назвать мои попытки версией 0.3. Также ввёл метку-тег
https://github.com/Oleg-N-Cher/OPCL/tree/v0.3Цитата:
23 Jan 2012, v0.3
- Show line and column in errors messages (postpone errors also supported).
Now you can use Syn Text Editor -
http://sourceforge.net/projects/syn/with syntax scheme "Modula 3". Try this regular expression
line\s+$[LineNumber]\s+col\s+$[ColNumber]\s
for setting an error marker to necessary position.
- Add MoveWindow sample application by Alexander Iljin.
- Fix memory allocation bug in OPL.AllocCaseTab.
Add Test/TestAllocMemError.Mod that crashes compiler without this fix.
WARNING: this bug is present in official ETH Oberon 2.4, 2.5 and 2.6.
- Add support '_' in identifiers.
- GitHub hosting:
https://github.com/Oleg-N-Cher/OPCLЯ даже обновил компилятор и линкер до PlugIn 2.6 Prerelease, выяснив попутно, что отличий от Release 2.5 у него фактически нет, так что можно смело утверждать, что все известные на данный момент доработки PlugIn'а вошли в обновление. Ну может у Зеллера что новенькое и появилось, но мне пока об этом ничего не известно. Я писал ему багрепорт лично, и писал на другие адреса ETH, указанные в качестве контактных, ответа никакого не получил. Кстати, я обнаружил ещё один довольно хитрый баг, связанный с переполнением маленьких массивов для отложенных объектов. Теперь мы с SATAN'ом думаем как его поправить.
Самая свежая версия, основанная на PlugIn 2.4, по задумке будет лежать здесь, в ветке "v2.4":
https://github.com/Oleg-N-Cher/OPCL/tree/v2.4Версия, обновлённая до Release 2.5, здесь, в ветке master:
https://github.com/Oleg-N-Cher/OPCL/commits/masterКоммит ещё не окончательный, я его буду дорабатывать, однако уже вполне действенный.
Планы на этот компилер? Конечно многое хотелось бы сделать, было бы побольше времени. Подумывается о добавлении поддержки Компонентного Паскаля. Мечты, мечты. Но, по крайней мере, если будут какие-то отзывы о багах в моих правках, или сам замечу, без внимания конечно не оставлю.
Вот такие дела.