OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 19 Март, 2024 08:54

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




Начать новую тему Ответить на тему  [ Сообщений: 328 ]  На страницу Пред.  1 ... 11, 12, 13, 14, 15, 16, 17  След.
Автор Сообщение
СообщениеДобавлено: Понедельник, 30 Август, 2021 22:17 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Если я правильно понял диагноз по третьей проблеме, то в ББ есть например, вот такое определение в Properties с вложенной записью:

Код:
      StdProp = POINTER TO RECORD (Property)
         next-: Property;
         known, readOnly, valid: SET;
         color: Dialog.Color;
         typeface: Fonts.Typeface;
         size: INTEGER;
         style: RECORD
            val, mask: SET
         END;
         weight: INTEGER;
      END;


StdProp не EXTENSIBLE, в отличие от примера, вызывающего ошибку. Возможно, тогда дело не во вложенности, а в расширяемости, или в комбинации свойств записей.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 31 Август, 2021 23:00 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 518
Откуда: Украина, Днепропетровская обл.
adimetrius писал(а):
Возможно, тогда дело не во вложенности, а в расширяемости, или в комбинации свойств записей.
Да, дело точно в расширяемости.

Я так понимаю, что транслятор дублирует два раза запись, которую расширяет (Ex__1). Но в Си структуры, вложенные в другие структуры, не могут иметь одинаковое имя.

Йозеф предложил два решения, но, видимо, делать правку в скором будущем не будет. Я ещё в процессе обдумывания.


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

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 583
Откуда: Москва
Oleg N. Cher писал(а):
По третьей Так что, я думаю, нам есть смысл подключить Дмитрия Викторовича Дагаева, если у него есть интерес закрыть эту ошибку в МультиОбероне.

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


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

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

Я передал Йозефу Ваше предложение, посмотрим, что ответит.


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

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 583
Откуда: Москва
Oleg N. Cher писал(а):
На первый взгляд мысль кажется очень интересной. Но как тогда обращаться к элементам внутренней анонимной структуры?

Я передал Йозефу Ваше предложение, посмотрим, что ответит.

В примере анонимная структура 'y' не имеет элементов, хотя может иметь. Но это превращается в С коде в элемент 'y' с типом в виде анонимной структуры struct без элементов.


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

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 518
Откуда: Украина, Днепропетровская обл.
Понятно. Ещё такой вопрос: анонимные структуры являются частью стандарта ANSI C?

Судя по этой ссылке, нет. Глубже не копал.

Думаю, тогда лучше не стоит так делать. Не везде есть C11 и выше.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 03 Сентябрь, 2021 13:15 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
Oleg N. Cher писал(а):
Понятно. Ещё такой вопрос: анонимные структуры являются частью стандарта ANSI C?
Судя по этой ссылке, нет. Глубже не копал.
Думаю, тогда лучше не стоит так делать. Не везде есть C11 и выше.
компилятора под руками нет...
Только в виде вложенных и возвращаемых значений, насколько мне память не изменяет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 03 Сентябрь, 2021 13:28 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
Oleg N. Cher писал(а):
.Не везде есть C11 и выше.
нет, я думаю, акценты - несколько иначе надо расставить...
Есть конторы, где обязательно надо самые последние и свежие новшества языка использовать, а есть, где - только "прошедшие сертификацию" версии разрешается работать. Например, во времена, когда уже везде пользовались gcc версии 4.5+, в конторе, где я работал, разрешалось использовать только 2.97.*... И там даже 99 версию не разрешалось включать...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 03 Сентябрь, 2021 19:21 
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 05 Сентябрь, 2021 03:14 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
Oleg N. Cher писал(а):
Влад, всё верно. Но в данном случае мы гонимся не за последними новшествами из мира Си, а чтобы покрыть побольше Си-компиляторов, в т.ч. и старых.

Могу, конечно же, ошибаться, но - не пустые ли это заморочки получаются?
Потому, что я уже практически не знаю компиляторов си(++), даже для встраиваемых приложений, где бы не было самых последних стандартов реализовано.
Нет, года четыре назад, я столкнулся с уникумом-начальником, который требовал, что бы ПО писалось на K&R варианте стандарта...но это уже, похоже, - исчезающий тип. В основном все уже безоговорочно приняли минимумом 11-тые стандарты. А на си++ уже требуют 17ый стандарт применять.
И - самое главное - уже как бы и повальное увлечение следованию MISRA проходит и восстанавливается здравый смысл. Очень этому статические анализаторы особенно способствуют... :)


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

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 518
Откуда: Украина, Днепропетровская обл.
Тем временем, в Ofront+ появилась долгожданная поддержка двухбайтного символьного типа CHAR. Это открывает перед нами отличные перспективы по пересборке модулей BlackBox при помощи Ofront+, а также можно уже смело присмотреться к большой библиотеке исходников Гельмута Цинна, которые тоже можно пробовать пересобирать Ofront'ом+.

Лично мне очень приятно, что такая серьёзная, не побоюсь этого слова, работа привела к практически полной поддержке в Ofront+ Компонентного Паскаля. У нас нет ещё только поддержки мета-информации для работы BlackBox'овского модуля Meta, но я надеюсь, что нам это ещё долго не понадобится. В GPCP тоже этого нет, но, тем не менее, GPCP имеет право называться компилятором Компонентного Паскаля, согласно описания языка.

В Ofront+ появилась опция командной строки -w, отвечающая за то, как именно интерпретируются символы исходника программы: без -w - как и раньше (т.е. любой символ попадает в строку по его коду, и кодировка может быть абсолютно любая), а с -w транслятор считает, что на вход поступают широкие символы, даже если кодировка исходника UTF-8.

Ещё раз. На вход без режима -w можно подавать что угодно, любую кодировку - хоть 1251, хоть 866, хоть KOI-8R. Она просто ляжет в целевой сишник с теми же кодами, что и входящие символы.

А вот в режиме -w нужно подавать только такие юникодные символы, которые поместятся в два байта. Иначе будет ошибка err 3. Это я предусмотрел специально.

err #3: illegal character in string

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

С опцией -w пока что поддерживается только входной формат .txt в кодировке UTF-8 (в версии для BlackBox - и .odc), но список входящих форматов мы обязательно расширим. В итоге нам должно быть без разницы, как именно закодирован исходник. Я как раз хотел этот момент автоматизировать и не задавать доп. ключами. А вот как именно интерпретировать символы - совсем другое дело, для этого теперь есть опция -w. А когда мы научим Texts понимать формат .odc (я планирую это сделать), оттуда будут идти широкие символы, но нужно оставить возможность, чтобы они интерпретировались как UTF-8 (без ключа -w).

Кстати, в процессе работы над CHAR появилась интересная мысль сделать ключик -w переключателем широкого или узкого CHAR в Обероне-07. Уже даже реализовал. Я подумал, что ведь раз будут идти широкие символы с входного потока, а тип CHAR в O7 только один, то нормально будет их обрабатывать именно как широкие. А если будут идти узкие, в UTF-8, то нормально будет узкие.

Расклад по широкому CHAR'у:

Oberon-1, Oberon2: CHAR, SYSTEM.CHAR16
Oberon-07: варьируемой длины CHAR
КП: SHORTCHAR, CHAR
Oberon-3: CHAR, LONGCHAR

Одна небольшая тонкость, связанная с ключиком -w:

Модуль
Код:
MODULE TestChar16;
VAR ch: CHAR;
BEGIN
  ch := "Ж"
END TestChar16.

С -w поступивший символ "Ж" будет интерпретирован как широкий CHAR и программа нормально скомпилится.

А без -w символ "Ж" это будет юникодовая строка, состоящая из двух байт, и программа уже не скомпилится.

Код:
MODULE TestChar16;
VAR i: INTEGER;
BEGIN
  i := LEN("Ж")
END TestChar16.

Здесь с -w длина будет 1, а без -w длина 2. Но тут, надеюсь, всё понятно)

Также ввёл для Оберона-3 новую операцию LCHR. Связано это с тем, что CHAR тут короткий, и поэтому CHR не может и не должна выдавать длинный символ, значит нужна новая операция.

Для O1, O2 реализован SYSTEM.LCHR.

Также во всех диалектах реализованы типы SYSTEM.CHAR8 и SYSTEM.CHAR16.

Я подверг Ofront+ зверскому испытанию - попробовал оттранслировать модуль Strings из BlackBox:

Изображение

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

А вот часть ББ, собранная для Linux. Strings и Math должны работать. Из Kernel взято только несколько процедур:

Изображение

Модули bb* не только транслируются, но и компилятся сишкой. Но их работу я не тестировал. Привязки LinLibc и LinLibW сделаны очень сильно с уклоном на 32-битность, надо перепахивать. Пока сделал, что смог. К сожалению, нет возможности для заимствованных привязок тестировать все функции.

Один очень важный момент: перед сборкой любого проекта новым Ofront+ нужно удалить все символьники. Пришлось немного изменить формат символьников. OP2 вообще очень похабно работает с символьниками: если подсунуть символьник неправильного формата, то транслятор закрэшится почти гарантированно. И это касается и Ofront, и Ofront+, и BlackBox.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 15 Октябрь, 2021 12:05 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 518
Откуда: Украина, Днепропетровская обл.
Для третьей проблемы выкатываю такое решение.

Компилируемость проверил в GCC, Clang, Turbo C v2.01, cc65, SDCC и SCCZ80.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 27 Декабрь, 2021 17:06 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 518
Откуда: Украина, Днепропетровская обл.
В процессе реализации RECORD [union] в Ofront+ столкнулся с вопросом наследования системного флага при наследовании записей. Конечно посматриваю на BlackBox. Оказалось, что в BlackBox наследовать от безтеговых записей с системным флагом можно. Более того, можно даже иметь тегированную запись внутри безтеговой, притом BlackBox не мешает иметь тегированные записи с тегированными (отслеживаемыми сборщиком) указателями внутри записи, унаследованной от RECORD [union]. Это страшное безобразие, которое можно оправдать только если безтеговость неявно переходит во внутренню запись. Да и то, хорошо ли, что неявно?

В общем, вопрос к знатокам: проясните этот момент. Может нам стоит зареквестить в ББ генерацию ошибки в случае объявления тегированной записи, унаследованной от безтеговой? Пусть программист явно и осознанно подставит туда системный флаг, не полагаясь на такое неявное поведение ББ.

Я затрудняюсь даже представить себе юнион с отслеживаемыми сборщиком указателями внутри. :shock:


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

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 518
Откуда: Украина, Днепропетровская обл.
Ну, я так понимаю, никто ничего не хочет добавить по данному вопросу? :roll:

Между тем, у Ofront'а+ праздник: 1,500 коммитов! :D С чем я нас всех поздравляю!

Сейчас будет 1,501-й - окончательная реализация RECORD [union]. Вычисление размера поборол, всё правильно вычисляет, и размер, и выравнивание.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 14 Январь, 2022 21:19 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 220
Откуда: Питер
Следующая ошибка.

Вот модуль, компилируется oftont+'ом с параметром -i:
Win.cp:
Код:
MODULE Win;

IMPORT
  S:=SYSTEM;

PROCEDURE -GetModuleHandleA (IN [nil] lpModuleName:ARRAY OF CHAR): S.PTR "GetModuleHandleA(lpModuleName)";

PROCEDURE Example;
  BEGIN
    IF GetModuleHandleA(NIL)=NIL THEN END;
  END Example;

END Win.


Win.h0:
Код:
#include <_windows.h>


Этот модуль транслируется в си, но при дальнейшей компиляции появляется ошибка:
Изображение

Если в процедуре Example GetModuleHandleA(NIL) заменить на GetModuleHandleA("AnyString"), то результат компилируется с подозрительными предупреждениями:
Изображение


Вложения:
Image2.png
Image2.png [ 18.84 КБ | Просмотров: 4514 ]
Image1.png
Image1.png [ 15.41 КБ | Просмотров: 4514 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 14 Январь, 2022 21:20 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 220
Откуда: Питер
Этой ошибке не было в одной из предыдущих версий ofront+'а (не могу сказать в какой именно)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 15 Январь, 2022 02:39 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 518
Откуда: Украина, Днепропетровская обл.
А теперь смотрите как реагирует BlackBox на подобный код:

Изображение

То есть, проблема Ofront'а+ только в том, что он на него не ругается. Это мы поправим.

Здесь вместо ARRAY OF используйте POINTER TO ARRAY [untagged] OF, лучше всего вот так:

Код:
PROCEDURE GetModuleHandleA* ["GetModuleHandleA"] (lpModuleName: POINTER TO ARRAY [untagged] OF CHAR): S.PTR;
Зачем здесь нужно доп. задание имени в скобках? Это указание, что функция внешняя и тело BEGIN..END не требуется. Для модулей, помеченных системным флажком [foreign], это необязательное условие.

Кстати, здесь у Вас должен использоваться диалект с однобайтным CHAR, иначе надо GetModuleHandleW.

Ещё лучше используйте WinApi, он для того и создан:

Код:
MODULE Win; IMPORT w := WinApi;

PROCEDURE Example;
  BEGIN
    IF w.GetModuleHandleA(NIL)=0 THEN END;
  END Example;

END Win.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 15 Январь, 2022 16:58 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 518
Откуда: Украина, Днепропетровская обл.
Сделал отчёт об этой проблеме на форуме Центра.


По поводу ошибки сравнения с NIL на уровне Си - погляжу, выглядит действительно странновато.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 16 Январь, 2022 04:32 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 220
Откуда: Питер
Хорошо, спасибо.
Для связи с Windows Api хорошо работает такая конструкция:
Код:
PROCEDURE -GetModuleHandleA * (IN [nil] lpModuleName:ARRAY [untagged] OF SHORTCHAR): HMODULE "GetModuleHandleA(lpModuleName)";


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 16 Январь, 2022 04:37 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 220
Откуда: Питер
Следующий вопрос.

Вот простой модуль:
Код:
MODULE Ex;

IMPORT
  Console;

BEGIN
  Console.String("Asdf");
  Console.Flush();
END Ex.


Он компилируется и ofront+'ом, и в дальнейшем си. Но почему-то не линкуется. Вот что пишет gcc (mingw-w64): "c:/Util/MinGW-w64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-crt0_c.o):crt0_c.c:(.text.startup+0x2e): undefined reference to `WinMain'
collect2.exe: error: ld returned 1 exit status"

В чём может быть причина? Со старой версией ofront+'а программа успешно линкуется и исполняется.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 328 ]  На страницу Пред.  1 ... 11, 12, 13, 14, 15, 16, 17  След.

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


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

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


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

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