OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 17 Январь, 2019 20:11

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 41 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: Вторник, 30 Ноябрь, 2010 23:55 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1537
Откуда: Беларусь, Минск
Там регистрации на самом сайте достаточно или ещё нужно приглашение в проект? Я бы от реестра его поотучал.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 01 Декабрь, 2010 05:53 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2289
Откуда: Россия, Санкт-Петербург
Достаточно регистрации, потом делаете Fork репозитория и работаете в своей копии. Когда закончите логический этап, присылаете Pull Request, и я сливаю в свой реп изменения либо говорю, что доработать. Если не договариваемся, то так и остаётся две ветки.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 01 Декабрь, 2010 11:55 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2178
Откуда: Нижний Новгород
Насколько сложно будет его портировать под linux и прочие *nix'ы?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 01 Декабрь, 2010 12:14 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2289
Откуда: Россия, Санкт-Петербург
Alexey Veselovsky писал(а):
Насколько сложно будет его портировать под linux и прочие *nix'ы?
Ну, есть же ОС Оберон под всякие никсы. Значит, и линкер там есть. Надо только вытащить оттуда и добавить сюда. Насколько сложно - не знаю.
ftp://ftp.inf.ethz.ch/pub/ETHOberon/Unix/
http://www.oberon.ethz.ch/downloads/index


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 02 Декабрь, 2010 13:37 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2289
Откуда: Россия, Санкт-Петербург
Поправил встроенный ассемблер (не признавал 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 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2289
Откуда: Россия, Санкт-Петербург
Kemet писал(а):
У меня есть, файл приложен.
Добавил вас в Readme, в раздел Contributors.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 02 Декабрь, 2010 15:18 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1537
Откуда: Беларусь, Минск
Александр Ильин писал(а):
компилятор и линкер падают, если командная строка длиннее 260 символов
Думаю, проблема в строке
Код:
IF len >= Kernel32.MaxPath THEN HALT(99) END;
Она расположена в модуле реестра, в инициализационной секции. Я немного проанализировал инициализационную секцию модуля ещё раньше, и думаю, что в этом модуле она не нужна вообще. То, что там есть, нужно разнести по разным модулям, а частично вообще удалить.

PS
Мне тут подкинули работы, поэтому могу надеяться, что только (хотя бы) в выходные будет время переключиться на OPCL.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 02 Декабрь, 2010 17:12 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2289
Откуда: Россия, Санкт-Петербург
Valery Solovey писал(а):
Мне тут подкинули работы, поэтому могу надеяться, что только (хотя бы) в выходные будет время переключиться на OPCL.
Хорошо, я эту задачу пока не трогаю.

Посмотрел сейчас, что изменилось в компиляторе, сравнив с текущей версией Plugin Oberon 2.6. Пробежался поверхностно, заметил MMX, SSE и SSE2 в ассемблере и делегаты в Активном Обероне. Плюс фикс многозадачности в Kernel, из-за которого Plugin Oberon не стартовал в Vista/7.

Анонсировал проект на GitHub в списке рассылки ETH Oberon и на форуме OCP.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Июнь, 2011 12:18 

Зарегистрирован: Среда, 24 Ноябрь, 2010 11:35
Сообщения: 6
Я так понимаю, разработка почему-то заглохла?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Июнь, 2011 12:32 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2289
Откуда: Россия, Санкт-Петербург
Анастасия писал(а):
Я так понимаю, разработка почему-то заглохла?
От реестра отучили, на GitHub в fork'е есть. В общем, пользоваться уже можно.
Я сам пока на XDS работаю, собираюсь посмотреть в сторону OO2C.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 09 Июнь, 2011 11:06 

Зарегистрирован: Среда, 24 Ноябрь, 2010 11:35
Сообщения: 6
Да реестр это не проблема, мне дали исходники где не только registry, но и text не требуется, и еще куча изменений, но, положа руку на сердце, давайте признаем, что в реальной работе этот компилятор, в текущем состоянии, использовать не то что не удобно (это само собой разумеется), а просто нельзя.
Требуется привлечение участников оберонсообщества для получения чего-то более вменяемого.
Александр Ильин писал(а):
Я сам пока на XDS работаю, собираюсь посмотреть в сторону OO2C.

Что Вы, мне никто не разрешит использовать такие компиляторы без исходников, а за C/C++ вообще расстреляют.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 09 Июнь, 2011 11:23 

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 685
Откуда: Псков
Анастасия писал(а):
Что Вы, мне никто не разрешит использовать такие компиляторы без исходников, а за C/C++ вообще расстреляют.

Странно вот что. А есть ли вообще у Вас возможность личного выбора инструмента , раз так все строго в конторе? :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 09 Июнь, 2011 16:12 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2289
Откуда: Россия, Санкт-Петербург
Анастасия писал(а):
Да реестр это не проблема, мне дали исходники где не только registry, но и text не требуется, и еще куча изменений
Дали? Делись!
Анастасия писал(а):
но, положа руку на сердце, давайте признаем, что в реальной работе этот компилятор, в текущем состоянии, использовать не то что не удобно (это само собой разумеется), а просто нельзя.
[С невинным взглядом и неподдельным удивлением в голосе] - Да? А что не так?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 09 Июнь, 2011 16:52 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Анастасия писал(а):
а за C/C++ вообще расстреляют.
Вот бы в такую контору на стажировку отправить наших плюсоведов...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 07 Февраль, 2012 19:18 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 201
Откуда: Украина, Днепропетровская обл.
Несколько дней назад я внёс в 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

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

Планы на этот компилер? Конечно многое хотелось бы сделать, было бы побольше времени. Подумывается о добавлении поддержки Компонентного Паскаля. Мечты, мечты. Но, по крайней мере, если будут какие-то отзывы о багах в моих правках, или сам замечу, без внимания конечно не оставлю.

Вот такие дела.


Вложения:
syn-opcl.png
syn-opcl.png [ 12.15 КБ | Просмотров: 5989 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Февраль, 2012 09:15 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2289
Откуда: Россия, Санкт-Петербург
Oleg N. Cher писал(а):
Есть 2 варианта: либо вычислять строку/колонку по этому числу, либо же решиться на добавление в много разных структур нового абстрактного типа TextPos и определение операций для него. Первый вариант я рассматривал с огромным желанием не вмешиваться в ещё не до конца понятую логику работы компилятора, но его пришлось отбросить ввиду вот чего. Для того, чтобы вычислить строку/колонку по позиции в тексте нужно иметь доступ ко входному файлу, чтобы считать строки. Этого сделать нельзя, потому что компилятор не хранит весь текст сразу, а считывает его маленькими порциями в буфер и уже оттуда выдаёт посимвольно. Ещё вариант — хранить в отдельном массиве длины строк — я отбросил тоже. Всё-таки зачем заводить лишнюю структуру, если по уму оно должно выглядеть совсем не так. Вот почему я и решился на введение нового типа OPM.TextPos. У него есть методы TextPosInit — начальное обнуление позиции, TextPosPrev — отступить на символ назад (по мере сил конечно) и присваивание одной структуры другой (типа errpos := curpos).
Я посмотрел, где и как используется TextPosPrev, и посмотрел, что было на этом месте ранее. А ранее там всегда был отступ только на один символ назад. Если посмотреть на контекст, то становится также очевидно, что при этом никогда не производится переход на предыдущую строку. Следовательно, обычного декремента позиции col было бы достаточно.

Что же касается вычисления строки/колонки по позиции в тексте, то поскольку компилятор однопроходный, то хранить или повторно вычислять длины строк нет никакой необходимости. Достаточно иметь два глобальных счётчика: line и col. Первый увеличивать при встрече символов перевода строки (при этом сбрасывать второй), а второй - при чтении любого другого символа.

Идею объединить pos, line и col в одной структуре в целом поддерживаю.
А зачем вам понадобилось поле prevcol?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Февраль, 2012 14:02 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 201
Откуда: Украина, Днепропетровская обл.
Александр Ильин писал(а):
Я посмотрел, где и как используется TextPosPrev, и посмотрел, что было на этом месте ранее. А ранее там всегда был отступ только на один символ назад. Если посмотреть на контекст, то становится также очевидно, что при этом никогда не производится переход на предыдущую строку. Следовательно, обычного декремента позиции col было бы достаточно.
Вы точно уверены? Ну, тогда можно prevcol убрать.
Цитата:
Что же касается вычисления строки/колонки по позиции в тексте, то поскольку компилятор однопроходный, то хранить или повторно вычислять длины строк нет никакой необходимости. Достаточно иметь два глобальных счётчика: line и col. Первый увеличивать при встрече символов перевода строки (при этом сбрасывать второй), а второй - при чтении любого другого символа.
Напоминаю, что так и было сделано, см. процедуру Win32.OPM.Get
Цитата:
Идею объединить pos, line и col в одной структуре в целом поддерживаю.
А зачем вам понадобилось поле prevcol?
prevcol вводился из тех соображений, что вдруг какое-то изменение позиции pos ведёт на предыдущую строку, а раз так, то значение поля col после перехода на новую строку будет обнулено и потеряно. Но раз Вы утверждаете, что переходов на предыдущую строку там не бывает, то тем легче наша задача, а благодаря структуре будет легко убрать prevcol безболезненно. Для меня контекст перехода на предыдущую позицию не столь очевиден, но попробую это выяснить, хотя бы для начала отладочной распечаткой.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Февраль, 2012 15:51 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2289
Откуда: Россия, Санкт-Петербург
Oleg N. Cher писал(а):
Александр Ильин писал(а):
Если посмотреть на контекст, то становится также очевидно, что при этом никогда не производится переход на предыдущую строку.
Вы точно уверены? Ну, тогда можно prevcol убрать.
Всего два случая:
1. OPA.GetIdent: данная процедура вызывается для того, чтобы считать идентификатор. При вызове процедуры первая буква идентификатора уже прочитана, и декремент нужен для того, чтобы позиция ошибки указывала на позицию перед этой первой буквой (или перед самим идентификатором, если он состоит из одной буквы). Разрыв строки между первой и второй буквой идентификатора, сами понимаете, не допускается.
2. OPS.DefaultGet: TextPosPrev вызывается сразу после цикла 'WHILE ch <= " " DO', т.е. при выходе из цикла последний прочитанный символ будет > " ", а шаг назад (декремент позиции) нужен для того, чтобы курсор в случае ошибки встал перед этим последним прочитанным символом. Поскольку последний прочитанный символ > " ", то это также не может быть разрыв строки.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Февраль, 2012 19:12 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 201
Откуда: Украина, Днепропетровская обл.
Что ж, действительно ценное замечание, позволившее неплохо упростить код. Но всё же не настолько, чтобы вывод позиции отложенных ошибок не касался сразу нескольких модулей, где происходит запоминание и восстановление запомненной позиции в тексте. Сделал коммит, реализующий предложенное упрощение:

https://github.com/Oleg-N-Cher/OPCL/com ... a8391365ae

Признаюсь, меня сбили с толку отложенные ошибки. Компилятор в процессе обработки исходного текста программы делает метки, откладывая на потом принятие решения является ли данный код ошибочным. За точки отсчёта меток принимается позиция pos, являющаяся одним числом. Я, естественно, хотел сделать всё как можно проще, по минимуму влезая в разные модули компилятора. Александр, сейчас в твоей ветке гитхуба с моей подачи (коммит под названием "Show line and column in error message") образовалась ошибка, не позволяющая корректно выводить позицию отложенных ошибок. Протестируй на коде типа:
Код:
TYPE
  Unknown = SomethingJustNotDefined;
Компилятор не обнаружит строку/колонку данной ошибки верно, он укажет на следующую после конца текста строку. Что и было исправлено в коммите "Fix postpone errors positions output" https://github.com/Oleg-N-Cher/OPCL/commit/af439c50c5aae524afc652386f990e9b37e3f680.

Происходит такое потому, что позиция 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 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2289
Откуда: Россия, Санкт-Петербург
Oleg N. Cher писал(а):
Похоже, ты решил, что такое усложнение накручено мною зря, но смотри, допустим
Нет, я в этом лишь немного внутренне усомнился, а вслух сказал вот что:
Александр Ильин писал(а):
Идею объединить pos, line и col в одной структуре в целом поддерживаю.
После твоего подробного объяснения и вовсе никаких сомнений в правильности выбранного пути у меня лично не осталось.
Отличная работа!


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 41 ]  На страницу Пред.  1, 2, 3  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB