Будет ли KOL портирован на FreePascal?

← →
Darts (2002-12-23 12:56) [0]

Или заточен только под Delphi?

← →
Darts (2002-12-23 15:26) [1]

Не будет. А жаль...

← →
Boguslaw (2002-12-23 21:42) [2]

Why not ? I think I could compile non-visual objects ,but not sure for now. This must lead to break KOL into parts , becouse porting visual part is problematic.

KOL.pas should be just stub which include approprate files for each compiler (Delphi and FPC).
Something like :
{$IFDEF DELPHI}
{$I nonvisual.inc}
{$I visual.inc}
{$ELSE}
{$I nonvisual.inc}
{$ENDIF}

(It is just an example, really it"s more complicated ;-)
I like KOL much but without deep change there is no way to port it to fpc (and without deep knowledge of many issues like GTK library )
Anyway nonvisual objects (with platform independant code) should be portable when these objects will be extracted from KOL.pas file.

Take a look into example below. It is the easiest console program with object based on _TObj (however I extracted _TObj from KOL.pas , that"s why it works ! KOL.pas has too many dependiences)

This almost the same example as original from FPC distribution and it works also in Linux (when compiled by FPC) :-)
I"m starting to learn FPC (and many others multiplatform compilers and GUIs) so if I can do that , someone who knows FPC better can do much more !

{
$Id: hello.pp,v 1.2 2002/02/22 21:46:25 carl Exp $
This file is part of the Free Pascal run time library.
Copyright (c) 1993-98 by the Free Pascal Development Team

Hello World Example

See the file COPYING.FPC, included in this distribution,
for details about the copyright.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

**********************************************************************}

program hello;
{$APPTYPE CONSOLE}
{$MODE DELPHI}
{$asmmode intel}

type
_TObj = object
{* auxiliary object type. See TObj. }
protected
procedure Init;
{* Is called from a constructor to initialize created object instance
filling its fields with 0. Can be overriden in descendant objects
to add another initialization code there. (Main reason of intending
is what constructors can not be virtual in poor objects). }
{=

← →
Vladimir Kladov (2002-12-26 10:50) [3]

Разделению KOL.PAS я предпочитаю использование внешнего скрипта,
который выделит указанные куски текста в заданные файлы. Команды для скрипта могут находиться в коде KOL.PAS. Например:

{===CREATE KOLNOWIN.PAS}
... начиная с этой строки все пишется в KOLNOWIN.PAS

{===STOP KOLNOWIN.PAS}
... начиная с этой строки прекращается копирование текста в
KOLNOWIN.PAS

{===APPEND KOLNOWIN.PAS}
... начиная с этой строки текст добавляется в конец KOLNOWIN.PAS

Дело в том, что я уже использовал деление на inc-файлы на начальныхстадиях разработки. Ни сам Delphi, ни многие внешние средства (MemProof, BoundsChecker) не работают с ними хорошо, особенно затрудняется навигация по коду и отладка. Символы условной компиляции тоже не очень хороши для редактора IDE и иногда вводят его в ступор, если начинать править код, который согласно опциям проекта сейчас вне видимости компилятора.

Предлагаемый вариант, по-моему, не очень плох. Исправлять результирующие файлы особого смысла нет. Проще исправить исходный (KOL.PAS) и запустить скрипт. Если использовать именно такие команды, то можно одновременно формировать несколько выходных файлов для различных конфигураций. Например:

{===CREATE KOLLIN.PAS}
{===CREATE KOLNOVISUAL.PAS}
...
{===STOP KOLLIN.PAS}
...
{===STOP KOLNOVISUAL.PAS}
...
{===APPEND KOLLIN.PAS}
...
{===STOP KOLLIN.PAS}

Если надо добавить какой-то код, который не нужен в Windows/Delphi и т.д., можно вставить его дополнительно между {$IFDEF}-{$ENDIF}, и внутри добавить {===APPEND} ... {===STOP}. Или, можно добавить еще команду для скрипта:

{===COPY KOLLIN.PAS FROM "path\Linux1.inc"}

← →
Kirill (2002-12-26 16:29) [4]

А по-подробнее можно? А то я ничего не понял, как это реализовать.

← →
Vladimir Kladov (2002-12-27 16:32) [5]

Например, так:

program DivPasFile; uses windows, KOL; procedure DivideFile( const Filename: String ); var SL, FSNames: PStrList; Outs: PList; // of file streams i, j: Integer; S: String; FS: PStream; procedure ShowError; begin MessageBox( 0, PChar( "Can not execute line " + Int2Str( i ) + ", command: " + SL.Items[ i ] ), "DivPasFile", MB_OK ); end; begin SL := NewStrList; SL.LoadFromFile( Filename ); Outs := NewList; FSNames := NewStrList; for i := 0 to SL.Count-1 do begin S := UPPERCASE( SL.Items[ i ] ); if StrIsStartingFrom( PChar(S), "{===CREATE" ) then begin S := CopyEnd( S, 11 ); S := Trim( Parse(S, "}") ); FS := NewWriteFileStream( S ); if FS.Handle = 0 then begin ShowError; break; end; Outs.Add( FS ); FSNames.Add( S ); end else if StrIsStartingFrom( PChar(S), "{===APPEND" ) then begin S := CopyEnd( S, 11 ); S := Trim( Parse(S, "}") ); FS := NewReadWriteFileStream( S ); if FS.Handle = 0 then begin ShowError; break; end; FS.Position := FS.Size; Outs.Add( FS ); end else if StrIsStartingFrom( PChar(S), "{===STOP" ) then begin S := CopyEnd( S, 9 ); S := Trim( Parse(S, "}") ); j := FSNames.IndexOf( S ); if j < 0 then begin ShowError; break; end; FS := Outs.Items[ j ]; FS.Free; Outs.Delete( j ); FSNames.Delete( j ); end {else if StrIsStartingFrom( PChar(S), "{===COPY" ) then begin end} else begin for j := 0 to Outs.Count-1 do begin FS := Outs.Items[ j ]; FS.WriteStr( SL.Items[ i ] + #13#10 ); end; end; end; Outs.ReleaseObjects; FSNames.Free; SL.Free; end; procedure DivideAllFiles; var i: Integer; begin for i := 1 to ParamCount do ( ParamStr( i ) Например, так: program DivPasFile; uses windows, KOL; procedure DivideFile( const Filename: String ); var SL, FSNames: PStrList; Outs: PList; // of file streams i, j: Integer; S: String; FS: PStream; procedure ShowError; begin MessageBox( 0, PChar( "Can not execute line " + Int2Str( i ) + ", command: " + SL.Items[ i ] ), "DivPasFile", MB_OK ); end; begin SL := NewStrList; SL.LoadFromFile( Filename ); Outs := NewList; FSNames := NewStrList; for i := 0 to SL.Count-1 do begin S := UPPERCASE( SL.Items[ i ] ); if StrIsStartingFrom( PChar(S), "{===CREATE" ) then begin S := CopyEnd( S, 11 ); S := Trim( Parse(S, "}") ); FS := NewWriteFileStream( S ); if FS.Handle = 0 then begin ShowError; break; end; Outs.Add( FS ); FSNames.Add( S ); end else if StrIsStartingFrom( PChar(S), "{===APPEND" ) then begin S := CopyEnd( S, 11 ); S := Trim( Parse(S, "}") ); FS := NewReadWriteFileStream( S ); if FS.Handle = 0 then begin ShowError; break; end; FS.Position := FS.Size; Outs.Add( FS ); end else if StrIsStartingFrom( PChar(S), "{===STOP" ) then begin S := CopyEnd( S, 9 ); S := Trim( Parse(S, "}") ); j := FSNames.IndexOf( S ); if j < 0 then begin ShowError; break; end; FS := Outs.Items[ j ]; FS.Free; Outs.Delete( j ); FSNames.Delete( j ); end {else if StrIsStartingFrom( PChar(S), "{===COPY" ) then begin end} else begin for j := 0 to Outs.Count-1 do begin FS := Outs.Items[ j ]; FS.WriteStr( SL.Items[ i ] + #13#10 ); end; end; end; Outs.ReleaseObjects; FSNames.Free; SL.Free; end; procedure DivideAllFiles; var i: Integer; begin for i := 1 to ParamCount do DivideFile( ParamStr( i ) ); end; begin DivideAllFiles; end. После компиляции получается 12К. Подставляем как параметр путь к нужному файлу: c:\kol\kol.pas, и запускаем. Можно добавить в IDE: Tools. Остается расставить по kol.pas в нужных местах правильные директивы (я надеюсь, мне сообщат, где точно их надо поставить, и какие). И все.

← →
PVOzerski (2002-12-28 23:21) [6]

Значит, так... Я, понятно, не Vladimir Kladov, за него планировать генеральную линию развития KOL не могу. Скажу о проблемах со стороны FPC.
1) Самое отвратительное - FPC не умеет выбрасывать полностью перекрытые виртуальные методы объектов BP-стиля из готового кода. Это обстоятельство препятствует тому самому уменьшению размеров, за которое так любят KOL. А причина - в организации VMT. При этом в FPC Team фиксить здесь ничего не собираются, полагая, что объекты эти нужны только для переноса старых программ.
2) properties для объектов BP-стиля поддерживаются только в довольно глючной версии 1.1, и то только в Delphi-совместимом режиме;
3) BASM INTEL-стиля довольно ограничен по возможностям по сравнению с BASM AT&T. Для компиляции кода KOL его не хватает;
4) Не работает передача параметров в функции через регистры - для части ассемблерных функций это критично;
5) Есть некоторые проблемы с поддержкой свойств по индексу (детали уже не помню).

Так что для переноса KOL надо сначала изрядно потрудиться над компилятором. Добровольцы есть? Считайте, я свой вклад сделал уже давно :^)

← →
Boguslaw (2002-12-29 00:06) [7]

What FPC version You used ? I use 1.0.6.
I know that Lazarus team used slighty modified version of FPC. Will this version be better ?

← →
PVOzerski (2002-12-29 00:26) [8]

Я уже давно экспериментировал с перекомпиляцией, сразу же возникли проблемы с properties. Это была версия 1.1, но она не имеет релизов, это постоянно изменяющийся вариант компилятора, который когда-нибудь будет релизом с очередным четным номером версии. Так что насколько изменилась ситуация с его совместимостью с KOL к настоящему времени - не знаю. Но советую произвести простенькие опыты с Вашей версией. Например:
{$smartlink on}
type
to1=object
procedure proc;virtual;
constructor create;
end;

to2=object(to1)
procedure proc;virtual;
end;

procedure to1.proc;
begin
writeln("111111111111111");
end;

procedure to1.proc;
begin
writeln("222222222222222");
end;

constructor to1.create;
begin
end;

var
o2:to2;
begin
o2.create;
o2.proc;
end.

Пожалуйста, проверьте, содержит ли получившийся exe-файл 111111111111111. Если да - ситуация не изменилась :^(

← →
Boguslaw (2002-12-29 21:00) [9]

I changed second procedure "proc" (You didn"t want to overload ths procedure right ?) and seem working even without DELPHI mode ;-)
Please confirm.
My FPC version = 1.0.6
That"s why I insist in FPC port of KOL :-0
Look below:

program demo1;
{$APPTYPE CONSOLE}
//{$MODE DELPHI}
{$smartlink on}

type
to1=object
procedure proc;virtual;
constructor create;
end;

to2=object(to1)
procedure proc;virtual;
end;

procedure to1.proc;
begin
writeln("111111111111111");
end;

procedure to2.proc;
begin
writeln("222222222222222");
end;

constructor to1.create;
begin
end;

var
o2:to2;
begin
o2.create;
o2.proc;
end.

Result := 222222222222222
For me it is well OK! (object inheritance is working) What do You think ?

Boguslaw

← →
Gandalf (2002-12-29 22:51) [10]

Я думаю всеж таки FPC еще далек от того состояния когда на него стоит портировать КОЛ. Да и многие другие вариации компиляторов тоже. Какие собственно компилятор даст плюсы? Размер - и сейчас неплохо, тем более уверен, он уменьшится не сильно. Скорость работы (мда... вот у Borland промах - особенно по ммм... железячной оптимизации, ни тебе MMX, XMM, SSE и т.п. - а не плохо бы). Мульти ОС - влечет за сабой довольно глобальную переработку KOLnMCK. Ну это я так в порядке здоровой критике, конечно же идея портирования - интересна и всегда актуальна для обсуждения, переодически просматриваю компиляторы, на тему - "а может уже пора?". Тут вопрос только на какой компилятор идти - их много.

← →
Boguslaw (2002-12-30 18:01) [11]

Bad news. FPC do not like properties in objects :-(
(FPC version 1.0.6)
What perfect compiler for KOL should have ?

← →
Zanuda (2002-12-30 18:17) [12]

А как насчет? Virtual Pascal или покета компиляторов gcc допустим трейтьей версии?!

← →
Gandalf (2002-12-30 22:31) [13]

Незнаю, из всего обилия компиляторов FreePascal, GNUPascal,Virtual,Fast - самые, еще вектор хорош мощной оптимизацией под SIMD (но это не самое важное, пока). Я вот хочу попробовать приладить КОЛ к GNU (и ОС много, и платформ (например MIPS :))- думаю он в этом планее наиболее совместимый и перспективный. Вообще если кому интересно вот линк, на россыпь компиляторов http://www.thefreecountry.com/developercity/pascal.shtml.

У вирта совсем маленький набор портов, потому лично мне он не очень интересен. А на счет адаптации, пожалуй она под вирт не так уж и сложна.

← →
PVOzerski (2003-01-10 15:36) [14]

FPC 1.1 понимает properties в старых объектах при Delphi-совместимом режиме компиляции -
{$ mode Delphi} или -Sd (кстати, сам эту фичу делал и специально для KOL).
Boguslaw, you did not understand me correctly. I"m not doubt that FPC supports OOP, but it is not able
to cut out fully overwritten and therefore unused virtual methods of parent old-style objects. That"s
a real problem. Всем остальным: извините за вставку по-английски, но я счел нужным сделать ее
специально для Boguslaw"а в надежде облегчить ему общение. Надеюсь, важность затрагиваемой
им проблемы позволит чуть-чуть нарушить правила форума, при том, что русский язык не является
для него родным.

← →
Boguslaw (2003-01-11 21:32) [15]

Yes.You are right.You"ve written long time ago that Virtual Method Table should be rewritten.Could You explain in more details why is it so difficult , becouse maybe I do not realize where is the main problem.Will this broke compability with older versions of FPC ?

Boguslaw

← →
PVOzerski (2003-01-13 01:58) [16]

Ситуация c VMT вот какая.

Вот текст тестовой программы.

{$smartlink on}
{$mode delphi}
type
t1=object
constructor create;
procedure proc;virtual;
destructor destroy;
end;
t2=object(t1)
procedure proc;virtual;
end;

constructor t1.create;
begin
end;

destructor t1.destroy;
begin
end;

procedure t1.proc;
begin
writeln("111111");
end;

procedure t2.proc;
begin
writeln("222222");
end;

var
o2:t2;
begin
o2.create;
o2.proc;
o2.destroy;
end.

А вот что получается в ассемблерном виде при компиляции FPC
для VMT (асм в стиле AT&T):

.data
.balign 4
.globl VMT_PROGRAM_T1
VMT_PROGRAM_T1:
.long 4,-4,0
.long _PROGRAM_T1_$_PROC$ //адрес метода t1.proc - мертвый код!
.balign 4
.globl VMT_PROGRAM_T2
VMT_PROGRAM_T2:
.long 4,-4
.long VMT_PROGRAM_T1 // ссылка на класс-родитель
.long _PROGRAM_T2_$_PROC$

Примерно такое же попадает в obj-файлы или библиотеки после компиляции юнитов. А поскольку заранее не известно, что из юнита понадобится при линковке, на этапе компиляции ненужные ссылки на неиспользуемые методы убрать нельзя.
Есть ли выход? IMHO, всё-таки есть, но он требует серьезной переделки компилятора. Я вижу такое решение (не настаиваю на его единственности и оптимальности): пусть этот код вообще не помещается в obj-файлы/библиотеки, соответствующие юнитам, но в виде "заготовок" хранится в соответствующих PPU-шках (кто знает FPC, поймет, о чем речь), а перед сборкой .exe/.dll компилятор на основе этих "заготовок" сгенерит VMT либо в главном модуле программы, либо в отдельном obj-файле, проверяя при этом ссылки на используемость. Возможно, пригодный для этой цели механизм хранения "заготовок" уже реализован в ветви 1.1 (но точно не знаю) - для хранения public inline-функций.
Так что вот материал для размышлений добровольцам :^)

← →
PVOzerski (2003-01-13 02:13) [17]

Теперь - что я думаю о применимости других компиляторов. Коммерческие (типа TMT или SpeedPascal) обсуждать, IMHO, смысла нет. Из free знаю FPC (AKA FreePascal), Virtual Pascal, gpc (GNU Pascal). Относительно FPC моя позиция понятна: принципиально пригоден, но требует доработки, причем на помощь официальныз разработчиков, похоже, рассчитывать не приходится. О GPC знаю мало, но складывается впечатление, что его совместимость по синтаксису с BP/Delphi весьма ограничена. Virtual Pascal, в принципе, мне кажется небезнадежным, но требует примерно тех же доработок, что и FPC (я проверял), однако поскольку его исходники недоступны, заниматься этими доработками самостоятельно невозможно.

← →
PVOzerski (2003-01-17 18:20) [18]

Решил вот поднять эту ветку... Помнится, перед Новым годом [m]Dem0n брался собрать команду под сабж... Притом безо всяких смайликов. А я обещался, по мере сил и времени, помогать (если это было написано невнятно, прошу прощения). Так как, команда-то появилась? Еще раз подчеркиваю: IMHO, дело более сложное, чем на первый взгляд, но небессмысленное.

← →
Gandalf (2003-01-31 21:04) [19]

GNU Pascal:
1) Не держит половину необходимого синтаксиса (например property, private, public и т.п.)
2) Отвратительно компилирует (огромный по размеру код)

Virtual Pascal:
1) Не держит необходимый синтаксис (тот же property, нужен переход на классы)

Итак на повестке для перевод KOL на class, ну, кто возмется ?

← →
Kladov (2003-02-01 10:00) [20]

Я ведь не зря отказался от классов. Тестирование проводил, смотрел, как влияет на увеличение объема экзешника добавление очередного наследника класса против добавления одного наследника объекта.

← →
_Vadim (2003-02-03 08:11) [21]

Можно глупый вопрос?
А почему обязательно FreePascal? Как насчет Kylix? У него тоже есть open source версия, называется Open Edition. Я так понял, нужен только компилятор паскаля для порторования KOL, который бы один в один делал те-же действия с исходником библиотеки, что и DCC32?

← →
Gandalf (2003-02-03 11:16) [22]

> Можно глупый вопрос?
> А почему обязательно FreePascal? Как насчет Kylix? У него
> тоже есть open source версия, называется Open Edition. Я
> так понял, нужен только компилятор паскаля для порторования
> KOL, который бы один в один делал те-же действия с исходником
> библиотеки, что и DCC32?

Нам нужен не всякий компилятор, нам нужен хорошой компилятор, так один на тысячу... Тогда можно и DCC32 взять он максимально близок к Self. Дело ведь в качестве компиляции, а не в совместимости.

← →
_Vadim (2003-02-03 11:50) [23]

2Gandalf

Честно говоря не понял твой ответ. А чем ты компилишь KOL под виндой? Разве не DCC32? Если DCC32 нельзя брать для компиляции KOL"а, то чем его нужно компилировать?
Прочитав высказывания в этом разделе я понял, что дело вовсе не в качестве компиляции (точнее, не совсем в качестве), а в том, что компиляторы паскаля под линух (и в частности free pascal) не поддерживают некоторых КЛЮЧЕВЫХ моментов, которые есть в DCC32 (под вин), поэтому KOL и не портируется под линух без особых ухищрений (скриптов например, как предлагал сам автор KOL"а. хотя и здесь есть свои сложности). Следовательно нужна именно совместимость по возможностям компиляции тех или иных компонент библиотеки). А качество компиляции - это, как я понял, только страдания компилирующего по размеру полученого бинарника.
Я не прав?

← →
Gandalf (2003-02-03 15:39) [24]

> чем ты компилишь KOL под виндой? Разве не DCC32? Если DCC32
> нельзя брать для компиляции KOL"а, то чем его нужно компилировать?

Конечно DCC32, больше (пока) KOL ничем не компилируется.

> А качество компиляции - это, как я понял, только страдания
> компилирующего по размеру полученого бинарника.
> Я не прав?

Это для кого как, для меня актуален вопрос качества компиляции, потому GNU Pascal не годится, хотя и держит ОЧЕНЬ много платформ, но не держит часть синтакчиса, и тут ищут компилятор который мульти платформенный, хороший (в плане качества компиляции), и под который реально адаптировать KOL не переделывая его полностью. Kylix конечно максимально совместим с Delphi, но качество компиляции оставляет желать лучшего, потому я лично его не рассматриваю. Но это мое мнение.

← →
_Vadim (2003-02-03 15:58) [25]

2 Gandalf
А примерчики "не того" качества компиляции у Kylix, если можно.
Просто я в Kylix"e еще новичок :)).

← →
Gandalf (2003-02-03 21:18) [26]

> примерчики "не того" качества компиляции у Kylix, если
> можно.
> Просто я в Kylix"e еще новичок :)).

Отсутсвие аппаратной оптимизации выше FPU. По моему это большой недостаток, опять же если сравнивать с GCC, p2cc эффективнее. Так же лично мне хотелось бы иметь ОДИН компилятор с адаптированной под него библиотекой, а не море компиляторов под разные платформы которые как тараканы разбигаются в свои стороны синтаксиса. По моему мы перешли на пустую полемику, которую если есть желание можно перевести на мыло. Тем более, что "необязательная" (в дальнейшем) открытость компилятора мне не очень нравится. Я не хочу делать новый компилятор, во всяком начитанать такой проект, ради библиотеки, лучше присоединится к готовым (тот же FPC, или GPC).

← →
_Vadim (2003-02-04 07:53) [27]

Можно и по мылу :))

Будет ли KOL портирован на FreePascal? Найти похожие ветки