OberonCore https://forum.oberoncore.ru/ |
|
Портируем библиотеку KOL (Key Object Library) под BlackBox https://forum.oberoncore.ru/viewtopic.php?f=47&t=2829 |
Страница 1 из 1 |
Автор: | Oleg N. Cher [ Четверг, 09 Сентябрь, 2010 16:33 ] | |||
Заголовок сообщения: | Портируем библиотеку KOL (Key Object Library) под BlackBox | |||
Я уже приступил. Небольшая вводная выдержка из документации. Цитата: Библиотека KOL может быть полезна для думающего Windows-разработчика, которому не чуждо эстетическое удовлетворение от красивых решений. Она предоставляет удобные абстракции на контролы и маскирует сложность многих WinApi-вызовов, но назвать её только обёрткой вокруг WinApi нельзя — в ней много самобытных решений, воплощённых опытным автором при поддержке русскоязычного сообщества. Замечательна она и тем, что позволяет создавать на языке Object Pascal программы очень компактные по размеру, делая процесс создания намного более простым, чем на чистом WinApi, а с привлечением технологии MCK сохраняется возможность визуальной разработки. Целевые приложения не только малы по размеру, но и более экономичны к потреблению памяти. Многое в KOL для оптимальности переписано на ассемблер.
KOL успешно портирована под Windows CE (этот проект известен как KolCE и его ведёт Юрий Сидоров — http://sourceforge.net/projects/kol-ce) так что некоторый задел для кроссплатформенной разработки уже есть. Также Владимир Кладов планирует портировать KOL под GTK и Qt, но когда это будет и будет ли вообще — неизвестно. Разумеется, KOL пока нельзя считать универсальным и, главное, кроссплатформенным средством построения интерфейсов с пользователем, но всё может измениться. Проект по портированию KOL задуман для упрощения и повышения безопасности и скорости разработки целевых Windows-приложений на языке Component Pascal (надмножество языка Oberon-2) в системе BlackBox Component Builder от Oberon microsystems Inc. (http://www.oberon.ch/blackbox.html), когда, по мере освоения Оберон-систем и написания на них приложений под Windows, я понял, что мне не хватает аналога KOL для Оберона и приступил к адаптации нужных мне возможностей KOL под BlackBox. Владимир Кладов отнёсся к идее портирования KOL на Компонентный Паскаль с пониманием и согласился поместить порт на сайт http://kolmck.net, за что ему отдельная благодарность. В процессе портирования, безусловно, придётся изменить многое в KOL, и, наверное, самая для этого веская причина — отсутствие в BlackBox условной компиляции (это вызовет дикий ступор у Объект Паскаль-программиста, которого лишили любимой игрушки, но для меня условная компиляция это пройденный этап и средство засорения исходников, и я вполне научился обходиться без неё; плюсы, поверьте, в её отсутствии тоже есть, и самый веский, как ни странно, стимул к повышению аккуратности при проектировании). Решено завести по 2 варианта модулей: Kol[Module] (для UNICODE) и Kol[Module]A для ANSI. Можно было бы впихнуть всё в один большой модуль Kol, как у Владимира, я, может быть, так позже и сделаю, но пока для большей структуризации — пусть будет в разных. На данный момент подсистема Kol состоит из следующих модулей: KolTypes KolObjects KolStrings KolRegistry KolIniFiles KolFiles KolIO KolTypesA KolStringsA KolRegistryA KolIniFilesA При наименовании типов и переменных, а также отступов при объявлении и вызове процедур я применил некоторые соглашения, рекомендуемые Oberon microsystems. Работа ведётся не целенаправленно, а по мере необходимости параллельно с другими проектами. Не весь портированный код тщательно тестировался. Любая Ваша помощь (в т.ч. и по созданию тестовых модулей и переписыванию отдельных процедур) будет принята с благодарностью. Отчёты об ошибках и предложения по улучшению направляйте по адресу allot (at) bk.ru Естественно это не путь классических Оберон-решений, традиционно кроссплатформенных и минималистичных, но Оберон-подобные языки, безусловно, имеют право на жизнь и на платформе Microsoft Windows. v0.02 от 13-сен-2010: Реализован модуль KolIniFiles для работы с Ini-файлами (UNICODE и ANSI), кроме функций GetSectionNames и SectionData (по той же причине). Начаты модули KolObjects (объекты), KolStrings (строки), KolTypes (типы KOL и преобразования между ними), KolFiles (файлы), IO (консольный ввод-вывод). Вместо функций Int2Str, Str2Int, Double2Str и Str2Double пока сделаны заглушки, но рабочие. Запустилась первая тестовая консольная программа на KolBB. Занимает после упаковки UPX-ом 25,5 Кб. С учётом того, что туда запихнут практически весь готовый код KOL (кроме KolRegistry) и плюс ядро со сборкой мусора и поддержкой динамической модульности с разбором формата .OCF, который легковеснее DLL, выглядит неплохо. Крайне необходимо смартлинкование. С ним код будет в разы компактнее. v0.01 от 7-сен-2010: Практически полностью реализованы модули KolRegistry для работы с реестром (UNICODE и ANSI), за исключением функций RegKeyGetSubKeys и RegKeyGetValueNames, которые требуют ещё неготовой работы со списками типа KOLStrList. Код компилируется без ошибок, но не тестировался.
|
Автор: | Александр Ильин [ Пятница, 10 Сентябрь, 2010 07:05 ] |
Заголовок сообщения: | Re: Портируем библиотеку KOL (Key Object Library) под BlackB |
viewtopic.php?p=51071#p51071 Oleg N. Cher писал(а): Решаю свои задачи. Удобным для себя способом. Чего и вам желаю. Вы всё правильно делаете. Успехов вам!
|
Автор: | Роман М. [ Суббота, 11 Сентябрь, 2010 13:02 ] |
Заголовок сообщения: | Re: Портируем библиотеку KOL (Key Object Library) под BlackB |
Считаю, что KOL имеет право на жизнь, как и любой другой проект на КП. Время покажет какой проект будет востребован. Из viewtopic.php?f=34&t=1280&start=260 : Oleg N. Cher писал(а): Можно же складировать решения не только в закрытом SVN OberonCore, но и на открытом сайте http://oberonrevival.sourceforge.net? Тем более уже создан неплохой для этого задел. Размещать можно в svn.sourceforge.net , в директории компонентов bbox-components. |
Автор: | Евгений Темиргалеев [ Воскресенье, 12 Сентябрь, 2010 15:55 ] |
Заголовок сообщения: | Re: Портируем библиотеку KOL (Key Object Library) под BlackB |
Тема разделена: 1) Данная: обсуждение вопросов портирования библиотеки KOL. Другие темы --- просьба не поднимать. 2) Целесообразность портирования для ББ, альтернативы и проч.: viewtopic.php?f=47&t=2841 3) Видение "ББ"-подхода со стороны "мэйнстрим" и споры на почве их сопоставления: viewtopic.php?f=73&t=2844 |
Автор: | Axcel [ Понедельник, 13 Сентябрь, 2010 14:50 ] |
Заголовок сообщения: | Re: Портируем библиотеку KOL (Key Object Library) под BlackB |
Кстати, а действительно, как в Обероне реализовать procedure ... of object для обработчиков событий KOL (type TOnEvent = procedure( Sender: PObj ) of object;)? Процедурными полями в объектах? |
Автор: | Евгений Темиргалеев [ Понедельник, 13 Сентябрь, 2010 16:52 ] |
Заголовок сообщения: | Re: Портируем библиотеку KOL (Key Object Library) под BlackB |
Обсуждалось здесь: viewtopic.php?f=29&t=2125 |
Автор: | Oleg N. Cher [ Среда, 15 Сентябрь, 2010 16:50 ] |
Заголовок сообщения: | Re: Портируем библиотеку KOL (Key Object Library) под BlackB |
Готова KolBB v0.02. Ссылка на скачку в начале ветки. Придумал интересный механизм для строковых полей объектов KolBB. В Delphi-версии KOL активно используются динамические строки (одна из причин почему KOL нельзя собрать в DLL и сделать обёртку), Оберон-2 и КП предлагают для хранения строковых полей неизвестной длины стандартный для них механизм динамической памяти и сборку мусора, поэтому хранить строки неизвестной длины в объектах можно только в виде указателей. Очень жаль, что при экспорте таких строк только для чтения остаётся возможность менять сами строки, нельзя менять лишь значение указателей. Естественно, можно не экспортировать такие поля напрямую, а обернуть возврат их значения в функцию, но это уже утяжеляет, хотя для критичных случаев придётся применять. Это делает KolBB ещё более отличным от Delphi-версии. Итак, для упрощения присвоения строковых полей-указателей на строки неизвестной длины я разработал процедуру KolStrings.Assign, которая следит, чтобы указатель не был NIL, при необходимости резервируя память. Если память уже выделена и места под размещение значения строки достаточно, она присваивается; если недостаточно, то происходит перевыделение памяти для размещения строки полностью. Это удобно, поскольку большая часть моих ошибок при работе на Оберонах связана с невыделением памяти и работой с памятью по NIL-указателям. Мне не нравится в механизме Assign только характерный для Си способ определения длины NULL-terminated строки путём постоянного подсчёта символов до '\0'. Традиционная и более эффективная Паскаль-модель работает с хранимой в отдельном поле реализации строковой пременной длины строки, что достижимо и в Оберонах, но требуется усложнить код введением нового типа-записи, реализующего работу с динамическими строками, что видится мне пока что неоправданным ввиду необходимости использования более усложнённых синтаксически конструкций [Вместо IF KolFn()^ = str2^ ... что-то вроде IF KolFn().GetStrVal()^ = str2.GetStrVal()^ ...]. Но это к вопросу об эффективной реализации на Оберон-языках динамических строк. Пока оставим это на будущее, недостаточно эффективную реализацию всегда можно усовершенствовать. Сейчас же пусть Assign выполняет свою главную роль: безопасного присвоения строковых значений полям объектов без боязни NIL-указателя и без боязни, что строка не поместится и будет обрезана. Как отличается работа с KOL-Delphi от KolBB и как вообще выглядит программа на KolBB: Код: MODULE KolIniFilesTest;
(* Приведу небольшой пример того, как возможно одним и тем же кодом обеспечить и запись, и сохранение настроек. Пусть, например, мы хотим сохранять по завершении работы координаты окна приложения в файле настроек, а в начале работы восстанавливать их оттуда. Создадим метод, который будет выполнять обе эти операции: procedure MyObj.ReadWriteIni( write: boolean ); var ini: PIniFile; begin ini := OpenIniFile( GetStartDir + 'my.ini' ); if write then ini.Mode := ifmWrite; ini.Section = 'position'; form.Left := ini.ValueInteger( 'Left', form.Left ); form.Top := ini.ValueInteger( 'Top', form.Top ); ini.Free; end; Теперь, при запуске приложения организуем вызов этого метода с параметром false, а при закрытии - с параметром true. Предоставляю вам самим разобраться, почему этот код будет делать все, что от него требуется, хотя работают одни и те же операторы в обоих случаях. *) IMPORT IO := KolIO, Typ := KolTypes, Str := KolStrings, Files := KolFiles, Ini := KolIniFiles; VAR formLeft, formTop: INTEGER; pi: REAL; path: POINTER TO Typ.KOLString; ch: CHAR; PROCEDURE ReadWriteIni (mode: Ini.TIniFileMode); VAR ini: Ini.PIniFile; BEGIN ini := Ini.OpenIniFile(Files.GetStartDir() + 'my.ini'); ini.mode := mode; Str.Assign(ini.section, 'Position'); formLeft := ini.ValueInteger( 'Left', formLeft ); formTop := ini.ValueInteger( 'Top', formTop ); Str.Assign(ini.section, 'Misc'); pi := ini.ValueDouble( 'Pi', pi ); path := ini.ValueString( 'Path', path ); (*ini.Free;*) ini.Destroy END ReadWriteIni; BEGIN IO.WriteLn("Hello World from KolBB!"); IO.WriteLn("Sozdaem " + Files.GetStartDir() + "my.ini ..."); formLeft := 123; formTop := 765; pi := 3.141592653589793; Str.Assign(path, Files.GetStartDir()); ReadWriteIni(Ini.IfmWrite); IO.WriteLn("Gotovo. Chitaem iz my.ini ..."); IO.Ln; formLeft := 0; formTop := 0; pi := 0.0; Str.Assign(path, ""); ReadWriteIni(Ini.IfmRead); IO.Write("formLeft = "); IO.WriteInt(formLeft); IO.Write(", formTop = "); IO.WriteInt(formTop); IO.Ln; IO.Write("pi = "); IO.Write(Typ.Double2Str(pi)); IO.Ln; IO.Write("path = "); IO.WriteLn(path); IO.Ln; ch := IO.ReadChar() END KolIniFilesTest. Generate independent Win32 console application w/o icon: DevLinker.LinkExe dos KolIniFilesTest.exe := Kernel+ KolTypes KolStrings KolObjects KolIO KolFiles KolIniFiles KolIniFilesTest$ ~ |
Автор: | Александр Ильин [ Среда, 15 Сентябрь, 2010 18:09 ] |
Заголовок сообщения: | Re: Портируем библиотеку KOL (Key Object Library) под BlackB |
Oleg N. Cher писал(а): procedure MyObj.ReadWriteIni( write: boolean ); Ох, не люблю я такой подход.
|
Автор: | GameHunter [ Четверг, 16 Сентябрь, 2010 00:53 ] |
Заголовок сообщения: | Re: Портируем библиотеку KOL (Key Object Library) под BlackB |
Ей-ей, KOL для XDS более актуален |
Страница 1 из 1 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |