Анастасия писал(а):
Что Вы, мне никто не разрешит использовать такие компиляторы без исходников, а за C/C++ вообще расстреляют.
Странно вот что. А есть ли вообще у Вас возможность личного выбора инструмента , раз так все строго в конторе?
| OberonCore https://forum.oberoncore.ru/ |
|
| Консольный компилятор ETH Oberon для Win32 https://forum.oberoncore.ru/viewtopic.php?f=30&t=2982 |
Страница 2 из 3 |
| Автор: | Valery Solovey [ Вторник, 30 Ноябрь, 2010 23:55 ] |
| Заголовок сообщения: | Re: Консольный компилятор ETH Oberon для Win32 |
Там регистрации на самом сайте достаточно или ещё нужно приглашение в проект? Я бы от реестра его поотучал. |
|
| Автор: | Александр Ильин [ Среда, 01 Декабрь, 2010 05:53 ] |
| Заголовок сообщения: | Re: Консольный компилятор ETH Oberon для Win32 |
Достаточно регистрации, потом делаете Fork репозитория и работаете в своей копии. Когда закончите логический этап, присылаете Pull Request, и я сливаю в свой реп изменения либо говорю, что доработать. Если не договариваемся, то так и остаётся две ветки. |
|
| Автор: | Alexey Veselovsky [ Среда, 01 Декабрь, 2010 11:55 ] |
| Заголовок сообщения: | Re: Консольный компилятор ETH Oberon для Win32 |
Насколько сложно будет его портировать под linux и прочие *nix'ы? |
|
| Автор: | Александр Ильин [ Среда, 01 Декабрь, 2010 12:14 ] |
| Заголовок сообщения: | Re: Консольный компилятор ETH Oberon для Win32 |
Alexey Veselovsky писал(а): Насколько сложно будет его портировать под linux и прочие *nix'ы? Ну, есть же ОС Оберон под всякие никсы. Значит, и линкер там есть. Надо только вытащить оттуда и добавить сюда. Насколько сложно - не знаю.ftp://ftp.inf.ethz.ch/pub/ETHOberon/Unix/ http://www.oberon.ethz.ch/downloads/index |
|
| Автор: | Александр Ильин [ Четверг, 02 Декабрь, 2010 13:37 ] |
| Заголовок сообщения: | Re: Консольный компилятор ETH Oberon для Win32 |
Поправил встроенный ассемблер (не признавал LF за перевод строки, зависал при разборе комментария, заканчивающегося EOF вместо EOL). По сравнению с данным постом доработана также процедура OPA.skipBlanks. В линкер добавлена опция "/d", с которой он просто разбирает Link-файл и выдаёт список зависимостей: Obj-файлы модулей, курсоров, иконок и stub.exe - всё, что требуется для сборки проекта. Данная опция была задействована для автоматического формирования зависимостей для мейкфайлов. Sed в этой связи больше не требуется (tr всё равно нужен). Таким образом, одну проблему я решил, но походя обнаружил ещё одну: компилятор и линкер падают, если командная строка длиннее 260 символов. Причём, ошибка не в них самих, а где-то в библиотечных модулях. https://github.com/AlexIljin/OPCL https://github.com/AlexIljin/OPCL/issues |
|
| Автор: | Александр Ильин [ Четверг, 02 Декабрь, 2010 15:08 ] |
| Заголовок сообщения: | Re: Консольный компилятор ETH Oberon для Win32 |
Kemet писал(а): У меня есть, файл приложен. Добавил вас в Readme, в раздел Contributors.
|
|
| Автор: | Valery Solovey [ Четверг, 02 Декабрь, 2010 15:18 ] |
| Заголовок сообщения: | Re: Консольный компилятор ETH Oberon для Win32 |
Александр Ильин писал(а): компилятор и линкер падают, если командная строка длиннее 260 символов Думаю, проблема в строке Код: IF len >= Kernel32.MaxPath THEN HALT(99) END; Она расположена в модуле реестра, в инициализационной секции. Я немного проанализировал инициализационную секцию модуля ещё раньше, и думаю, что в этом модуле она не нужна вообще. То, что там есть, нужно разнести по разным модулям, а частично вообще удалить.PS Мне тут подкинули работы, поэтому могу надеяться, что только (хотя бы) в выходные будет время переключиться на OPCL. |
|
| Автор: | Александр Ильин [ Четверг, 02 Декабрь, 2010 17:12 ] |
| Заголовок сообщения: | Re: Консольный компилятор ETH Oberon для Win32 |
Valery Solovey писал(а): Мне тут подкинули работы, поэтому могу надеяться, что только (хотя бы) в выходные будет время переключиться на OPCL. Хорошо, я эту задачу пока не трогаю.Посмотрел сейчас, что изменилось в компиляторе, сравнив с текущей версией Plugin Oberon 2.6. Пробежался поверхностно, заметил MMX, SSE и SSE2 в ассемблере и делегаты в Активном Обероне. Плюс фикс многозадачности в Kernel, из-за которого Plugin Oberon не стартовал в Vista/7. Анонсировал проект на GitHub в списке рассылки ETH Oberon и на форуме OCP. |
|
| Автор: | Анастасия [ Среда, 08 Июнь, 2011 12:18 ] |
| Заголовок сообщения: | Re: Консольный компилятор ETH Oberon для Win32 |
Я так понимаю, разработка почему-то заглохла? |
|
| Автор: | Александр Ильин [ Среда, 08 Июнь, 2011 12:32 ] |
| Заголовок сообщения: | Re: Консольный компилятор ETH Oberon для Win32 |
Анастасия писал(а): Я так понимаю, разработка почему-то заглохла? От реестра отучили, на GitHub в fork'е есть. В общем, пользоваться уже можно.Я сам пока на XDS работаю, собираюсь посмотреть в сторону OO2C. |
|
| Автор: | Анастасия [ Четверг, 09 Июнь, 2011 11:06 ] |
| Заголовок сообщения: | Re: Консольный компилятор ETH Oberon для Win32 |
Да реестр это не проблема, мне дали исходники где не только registry, но и text не требуется, и еще куча изменений, но, положа руку на сердце, давайте признаем, что в реальной работе этот компилятор, в текущем состоянии, использовать не то что не удобно (это само собой разумеется), а просто нельзя. Требуется привлечение участников оберонсообщества для получения чего-то более вменяемого. Александр Ильин писал(а): Я сам пока на XDS работаю, собираюсь посмотреть в сторону OO2C. Что Вы, мне никто не разрешит использовать такие компиляторы без исходников, а за C/C++ вообще расстреляют. |
|
| Автор: | albobin [ Четверг, 09 Июнь, 2011 11:23 ] |
| Заголовок сообщения: | Re: Консольный компилятор ETH Oberon для Win32 |
Анастасия писал(а): Что Вы, мне никто не разрешит использовать такие компиляторы без исходников, а за C/C++ вообще расстреляют. Странно вот что. А есть ли вообще у Вас возможность личного выбора инструмента , раз так все строго в конторе?
|
|
| Автор: | Александр Ильин [ Четверг, 09 Июнь, 2011 16:12 ] |
| Заголовок сообщения: | Re: Консольный компилятор ETH Oberon для Win32 |
Анастасия писал(а): Да реестр это не проблема, мне дали исходники где не только registry, но и text не требуется, и еще куча изменений Дали? Делись!Анастасия писал(а): но, положа руку на сердце, давайте признаем, что в реальной работе этот компилятор, в текущем состоянии, использовать не то что не удобно (это само собой разумеется), а просто нельзя. [С невинным взглядом и неподдельным удивлением в голосе] - Да? А что не так?
|
|
| Автор: | Сергей Губанов [ Четверг, 09 Июнь, 2011 16:52 ] |
| Заголовок сообщения: | Re: Консольный компилятор ETH Oberon для Win32 |
Анастасия писал(а): а за C/C++ вообще расстреляют. Вот бы в такую контору на стажировку отправить наших плюсоведов...
|
|
| Автор: | Oleg N. Cher [ Вторник, 07 Февраль, 2012 19:18 ] | ||
| Заголовок сообщения: | Re: Консольный компилятор ETH Oberon для Win32 | ||
Несколько дней назад я внёс в 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 Коммит ещё не окончательный, я его буду дорабатывать, однако уже вполне действенный. Планы на этот компилер? Конечно многое хотелось бы сделать, было бы побольше времени. Подумывается о добавлении поддержки Компонентного Паскаля. Мечты, мечты. Но, по крайней мере, если будут какие-то отзывы о багах в моих правках, или сам замечу, без внимания конечно не оставлю. Вот такие дела.
|
|||
| Автор: | Александр Ильин [ Среда, 08 Февраль, 2012 09:15 ] |
| Заголовок сообщения: | Re: Консольный компилятор ETH Oberon для Win32 |
Oleg N. Cher писал(а): Есть 2 варианта: либо вычислять строку/колонку по этому числу, либо же решиться на добавление в много разных структур нового абстрактного типа TextPos и определение операций для него. Первый вариант я рассматривал с огромным желанием не вмешиваться в ещё не до конца понятую логику работы компилятора, но его пришлось отбросить ввиду вот чего. Для того, чтобы вычислить строку/колонку по позиции в тексте нужно иметь доступ ко входному файлу, чтобы считать строки. Этого сделать нельзя, потому что компилятор не хранит весь текст сразу, а считывает его маленькими порциями в буфер и уже оттуда выдаёт посимвольно. Ещё вариант — хранить в отдельном массиве длины строк — я отбросил тоже. Всё-таки зачем заводить лишнюю структуру, если по уму оно должно выглядеть совсем не так. Вот почему я и решился на введение нового типа OPM.TextPos. У него есть методы TextPosInit — начальное обнуление позиции, TextPosPrev — отступить на символ назад (по мере сил конечно) и присваивание одной структуры другой (типа errpos := curpos). Я посмотрел, где и как используется TextPosPrev, и посмотрел, что было на этом месте ранее. А ранее там всегда был отступ только на один символ назад. Если посмотреть на контекст, то становится также очевидно, что при этом никогда не производится переход на предыдущую строку. Следовательно, обычного декремента позиции col было бы достаточно.Что же касается вычисления строки/колонки по позиции в тексте, то поскольку компилятор однопроходный, то хранить или повторно вычислять длины строк нет никакой необходимости. Достаточно иметь два глобальных счётчика: line и col. Первый увеличивать при встрече символов перевода строки (при этом сбрасывать второй), а второй - при чтении любого другого символа. Идею объединить pos, line и col в одной структуре в целом поддерживаю. А зачем вам понадобилось поле prevcol? |
|
| Автор: | Oleg N. Cher [ Среда, 08 Февраль, 2012 14:02 ] |
| Заголовок сообщения: | Re: Консольный компилятор ETH Oberon для Win32 |
Александр Ильин писал(а): Я посмотрел, где и как используется TextPosPrev, и посмотрел, что было на этом месте ранее. А ранее там всегда был отступ только на один символ назад. Если посмотреть на контекст, то становится также очевидно, что при этом никогда не производится переход на предыдущую строку. Следовательно, обычного декремента позиции col было бы достаточно. Вы точно уверены? Ну, тогда можно prevcol убрать.Цитата: Что же касается вычисления строки/колонки по позиции в тексте, то поскольку компилятор однопроходный, то хранить или повторно вычислять длины строк нет никакой необходимости. Достаточно иметь два глобальных счётчика: line и col. Первый увеличивать при встрече символов перевода строки (при этом сбрасывать второй), а второй - при чтении любого другого символа. Напоминаю, что так и было сделано, см. процедуру Win32.OPM.GetЦитата: Идею объединить pos, line и col в одной структуре в целом поддерживаю. prevcol вводился из тех соображений, что вдруг какое-то изменение позиции pos ведёт на предыдущую строку, а раз так, то значение поля col после перехода на новую строку будет обнулено и потеряно. Но раз Вы утверждаете, что переходов на предыдущую строку там не бывает, то тем легче наша задача, а благодаря структуре будет легко убрать prevcol безболезненно. Для меня контекст перехода на предыдущую позицию не столь очевиден, но попробую это выяснить, хотя бы для начала отладочной распечаткой.
А зачем вам понадобилось поле prevcol? |
|
| Автор: | Александр Ильин [ Среда, 08 Февраль, 2012 15:51 ] |
| Заголовок сообщения: | Re: Консольный компилятор ETH Oberon для Win32 |
Oleg N. Cher писал(а): Александр Ильин писал(а): Если посмотреть на контекст, то становится также очевидно, что при этом никогда не производится переход на предыдущую строку. Вы точно уверены? Ну, тогда можно prevcol убрать.1. OPA.GetIdent: данная процедура вызывается для того, чтобы считать идентификатор. При вызове процедуры первая буква идентификатора уже прочитана, и декремент нужен для того, чтобы позиция ошибки указывала на позицию перед этой первой буквой (или перед самим идентификатором, если он состоит из одной буквы). Разрыв строки между первой и второй буквой идентификатора, сами понимаете, не допускается. 2. OPS.DefaultGet: TextPosPrev вызывается сразу после цикла 'WHILE ch <= " " DO', т.е. при выходе из цикла последний прочитанный символ будет > " ", а шаг назад (декремент позиции) нужен для того, чтобы курсор в случае ошибки встал перед этим последним прочитанным символом. Поскольку последний прочитанный символ > " ", то это также не может быть разрыв строки. |
|
| Автор: | Oleg N. Cher [ Среда, 08 Февраль, 2012 19:12 ] |
| Заголовок сообщения: | Re: Консольный компилятор ETH Oberon для Win32 |
Что ж, действительно ценное замечание, позволившее неплохо упростить код. Но всё же не настолько, чтобы вывод позиции отложенных ошибок не касался сразу нескольких модулей, где происходит запоминание и восстановление запомненной позиции в тексте. Сделал коммит, реализующий предложенное упрощение: https://github.com/Oleg-N-Cher/OPCL/com ... a8391365ae Признаюсь, меня сбили с толку отложенные ошибки. Компилятор в процессе обработки исходного текста программы делает метки, откладывая на потом принятие решения является ли данный код ошибочным. За точки отсчёта меток принимается позиция pos, являющаяся одним числом. Я, естественно, хотел сделать всё как можно проще, по минимуму влезая в разные модули компилятора. Александр, сейчас в твоей ветке гитхуба с моей подачи (коммит под названием "Show line and column in error message") образовалась ошибка, не позволяющая корректно выводить позицию отложенных ошибок. Протестируй на коде типа: Код: TYPE Компилятор не обнаружит строку/колонку данной ошибки верно, он укажет на следующую после конца текста строку. Что и было исправлено в коммите "Fix postpone errors positions output" https://github.com/Oleg-N-Cher/OPCL/commit/af439c50c5aae524afc652386f990e9b37e3f680.Unknown = SomethingJustNotDefined; Происходит такое потому, что позиция pos, которую восстанавливает компилятор из различных структур, сберегающих позицию отложенных потенциальных ошибок (для этого не всегда используется имя errpos, часто используется просто другое целочисленное поле (obj.val, x.conval.intval, x.conval.intval2, Instr[pc].src1 и т.д.), что сбивает с толку, однако наверное это сделано для большей эффективности, чтобы не вводить дополнительную переменные в запись, когда уже есть неиспользованная другая). Пока позицией является одно число, хватает любого поля типа LONGINT, но поелику же мы решаем, что надо хранить ещё и строку/колонку (как раз для того, чтобы не вычислять их по одной-единственной позиции pos), уже нужно отдельное поле, для которого я ввёл тип OPM.TextPos. Похоже, ты решил, что такое усложнение накручено мною зря, но смотри, допустим: var a -- [запомнено: pos 123] type b -- [запомнено: pos 345] record c -- [запомнено: pos 567] Теперь мы на каком-то этапе компиляции убедились что тип b описан неверно. И нам нужно знать строку/колонку, в которой он описан. А вовсе не позицию pos, которая там запомнилась, когда компилятор ещё не знал, является ли описание типа b ошибочным, и не текущие строку/колонку, которые находятся в наших переменных OPM.line и OPM.col и уже явно указывают на самый конец текста, ибо проход компиляции программы уже завершен, осталось "подобрать хвосты", проверяя типы и так далее. Извиняюсь, если объясняю тривиальные вещи, но я же сейчас оправдываю свой код, над которым думал не один день, принимая решения как будет лучше и оптимальнее. Но можешь предложить что-нибудь другое, на твой свежий взгляд.
|
|
| Автор: | Александр Ильин [ Среда, 08 Февраль, 2012 19:33 ] |
| Заголовок сообщения: | Re: Консольный компилятор ETH Oberon для Win32 |
Oleg N. Cher писал(а): Похоже, ты решил, что такое усложнение накручено мною зря, но смотри, допустим Нет, я в этом лишь немного внутренне усомнился, а вслух сказал вот что:Александр Ильин писал(а): Идею объединить pos, line и col в одной структуре в целом поддерживаю. После твоего подробного объяснения и вовсе никаких сомнений в правильности выбранного пути у меня лично не осталось.Отличная работа! |
|
| Страница 2 из 3 | Часовой пояс: UTC + 3 часа |
| Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |
|