OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 21:50

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




Начать новую тему Ответить на тему  [ Сообщений: 53 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: Понедельник, 02 Март, 2020 20:35 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Илья Ермаков писал(а):
Чрезмерный размер Strings тоже не особо хорош. Иногда он статически линкуется, например.
Если только иметь там интерфейс, а реализацию хранить отдельно.

Проверил, размер кодового файла из 20Кб получается 70 Кб. Не такая уж большая жертва. Но зато не надо отдельный модуль вообще.


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
А чего бояться-то так отдельного модуля?

У нас теперь есть MultiOberon для разных платформ. Захотим на ARM с 1024К что-то скомпилировать на ББ, а тут у вас 70 Кб туда, 70 сюда ))


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Илья Ермаков писал(а):
А чего бояться-то так отдельного модуля?

У нас теперь есть MultiOberon для разных платформ. Захотим на ARM с 1024К что-то скомпилировать на ББ, а тут у вас 70 Кб туда, 70 сюда ))


В Strings есть процедура Upper, значит надо импортировать будет этот новый модуль для реализации этой процедуры. А раз импортировать, то и в слинкованый файл добавлять. Так. Так что для АРМа импорт придется руками удалять? Или вы предлагаете какой-то хитрый механизм расширения функциональности Strings через Hook. Нужна тут такая сложность?
Скажем нужна... Тогда Strings без установленного UnicodeHook будет пребразовывать только ASCII, а с установленным работать как положено над всем CHAR. Но хорошо ли, что будут меняться постусловия процедур? Не думаю...

Скорее для ARM нужен отдельный модуль Stringsacii, который гарантирует работу только над ASCII.

Или сделать отдельным модулем и импортировать Unicode в ядро? Но это проблему размера не решает.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Март, 2020 13:47 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Евгений Темиргалеев писал(а):
Маленький модуль, только преобразователь UTF8. Его можно линковать в пускач и импортировать в Kernel и HostFiles.
Когда-то школьная сборка была сделана точно по этой схеме (там ещё поучаствовал куда-то пропавший И.Горячев) -- отдельный маленький модуль National.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Март, 2020 13:51 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Илья Ермаков писал(а):
Чрезмерный размер Strings тоже не особо хорош. Иногда он статически линкуется, например.
Если только иметь там интерфейс, а реализацию хранить отдельно.
Strings -- HostStrings ?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Март, 2020 13:51 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Если отказаться от идеи, что Kernel базовый модуль и импортировать в него, как у Фёдора Васильевича сделано в i21 сборке.

По получится следующая иерархия с полным переиспользованием кода.
Код:
Unicode Utf8 Math Strings Console HostConsole Kernel+$ Files HostFiles StdLoader


Все модули до Kernel не используют динамическую память. Надо будет только в Console через процедурные переменные сделать реализацию установки реализаций.

Тогда мы имеем единую точку вывода STDERR через Console и преобразования кросс-платформенные в ядре...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Март, 2020 14:32 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Иван Денисов писал(а):
Если отказаться от идеи, что Kernel базовый модуль и импортировать в него, как у Фёдора Васильевича сделано в i21 сборке.

Но этого делать не надо. Оставим в Kernel необходимые ему встроенные вещи, остальное продублируем куда надо.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Март, 2020 14:43 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Иван Денисов писал(а):
получится следующая иерархия с полным переиспользованием кода.
Код:
Unicode Utf8 Math Strings Console HostConsole Kernel+$ Files HostFiles StdLoader

Норм чо

А как же HostConsole? Она же через расширение типа, знач там динамическая память. А можно ее после Kernel?

И повторю свою просьбу: можно Utf вместо Utf8?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Март, 2020 14:51 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Борис Рюмшин писал(а):
Иван Денисов писал(а):
Если отказаться от идеи, что Kernel базовый модуль и импортировать в него, как у Фёдора Васильевича сделано в i21 сборке.

Но этого делать не надо. Оставим в Kernel необходимые ему встроенные вещи, остальное продублируем куда надо.

Борис, зато интерфейсы будут не тронуты. Отдельный модуль для Unicode, отдельный для Utf, чтобы его потом убрать, если будет реализация ядра и компилятора для CHAR.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Март, 2020 14:52 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
adimetrius писал(а):
И повторю свою просьбу: можно Utf вместо Utf8?

Думаю, что да. Тут даже Евгений согласился.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Март, 2020 15:09 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
adimetrius писал(а):
А как же HostConsole? Она же через расширение типа, знач там динамическая память. А можно ее после Kernel?

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


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Для приложений без ядра, но использующих фиксированный набор дин. объектов типа хуков-директорий и т.п., можно сделать мини-реализацию NewArr, на непрерывной области памяти, когда место под новый объект тупо выделяется в хвосте. Ну и из структур данных Kernel оставлен только Kernel.Type, Kernel.Module, Kernel.Object (эти структуры всё равно вкопилируются в каждый модуль и нужны для IS/WITH и др.).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Март, 2020 17:37 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1428
adimetrius писал(а):
можно Utf вместо Utf8?

А что будет означать Utf?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Март, 2020 18:41 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Иван Денисов писал(а):
Борис Рюмшин писал(а):
Иван Денисов писал(а):
Если отказаться от идеи, что Kernel базовый модуль и импортировать в него, как у Фёдора Васильевича сделано в i21 сборке.

Но этого делать не надо. Оставим в Kernel необходимые ему встроенные вещи, остальное продублируем куда надо.

Борис, зато интерфейсы будут не тронуты. Отдельный модуль для Unicode, отдельный для Utf, чтобы его потом убрать, если будет реализация ядра и компилятора для CHAR.

Иван, мне не нужны влинкованными ни Math, ни Strings, ни тем более Console вместе с Unicode и Utf8.

Ещё раз убедительно прошу, сместитесь, со всей этой веселухой, на уровень в сторону отсюда.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 03 Март, 2020 18:42 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Иван Денисов писал(а):
Надо убрать динамическую память для приложений без ядра.

Илья Ермаков писал(а):
Для приложений без ядра...

А теперь признайтесь, кто из вас хоть раз делал приложения без ядра?


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Я делал библиотеки без ядра. Но собственно эта тема произросла из желания Евгения избавиться от Kernel в Strings. Цепочкой логических рассуждений на тему "а зачем ему это надо", я пришел к тому, что видимо для приложений без ядра. Ну и в этом есть смысл, конечно. Могут быть и большие приложения без ядра, и не только библиотеки :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 04 Март, 2020 10:28 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Борис Рюмшин писал(а):
Иван, мне не нужны влинкованными ни Math, ни Strings, ни тем более Console вместе с Unicode и Utf8.

Ещё раз убедительно прошу, сместитесь, со всей этой веселухой, на уровень в сторону отсюда.

Не весело, к сожалению. Слишком много противоречий.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 04 Март, 2020 11:31 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Итак по просьбе Евгения мы делаем отдельный модуль Unicode на основе модуля SovierPony. По просьбе Антона переименовываем модуль Utf8 в модуль Utf. Теперь мы можем оставить я вдре библиотечную реализацию. При этом проверим, что она совпадает на всем диапазоне модулю Unicode в Linux и в Windows. В ядре остаётся скрытая конверсия, экспорт которой мы закрываем. В Kernel, HostFiles и HostConsole будут копии кода "знак в знак" реализаций для низкоуровневой отладки, это будет помечено специальным комментарием и контролироваться при изменении одного из модулей. Борис, так вас устроит?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 04 Март, 2020 14:49 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Иван Денисов писал(а):
Итак по просьбе Евгения мы делаем отдельный модуль Unicode на основе модуля SovierPony. По просьбе Антона переименовываем модуль Utf8 в модуль Utf. Теперь мы можем оставить я вдре библиотечную реализацию. При этом проверим, что она совпадает на всем диапазоне модулю Unicode в Linux и в Windows. В ядре остаётся скрытая конверсия, экспорт которой мы закрываем. В Kernel, HostFiles и HostConsole будут копии кода "знак в знак" реализаций для низкоуровневой отладки, это будет помечено специальным комментарием и контролироваться при изменении одного из модулей. Борис, так вас устроит?

Я не знаю, зачем вам переименовывать Utf8 в Utf, но это как хотите.
Но если вы не трогаете Kernel, не ставите его в зависимость от кучи модулей, которые надо линковать, не импортируете его куда попало, то да, меня это устраивает.


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Борис Рюмшин писал(а):
Иван Денисов писал(а):
Итак по просьбе Евгения мы делаем отдельный модуль Unicode на основе модуля SovierPony. По просьбе Антона переименовываем модуль Utf8 в модуль Utf. Теперь мы можем оставить я вдре библиотечную реализацию. При этом проверим, что она совпадает на всем диапазоне модулю Unicode в Linux и в Windows. В ядре остаётся скрытая конверсия, экспорт которой мы закрываем. В Kernel, HostFiles и HostConsole будут копии кода "знак в знак" реализаций для низкоуровневой отладки, это будет помечено специальным комментарием и контролироваться при изменении одного из модулей. Борис, так вас устроит?

Я не знаю, зачем вам переименовывать Utf8 в Utf, но это как хотите.
Но если вы не трогаете Kernel, не ставите его в зависимость от кучи модулей, которые надо линковать, не импортируете его куда попало, то да, меня это устраивает.

В Kernel получается, что будет процедура для перенаправления вывода сообщений об ошибках, как предложил Евгений. Через установку процедурных переменных, которые будут скрыты. Это изменения ядра не коснется никаких используемых интерфейсов. Изменение ядра такого рода вас устроит?


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

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


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

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


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

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