Кому чего в KOLnMCK не хватает?

← →
_gandalf_ (2006-11-23 22:42) [0]

Я уже както задавал - но было довольно давно - интересно как сейчас дела обстоят...?

← →
ANTPro © (2006-11-24 00:22) [1]

>Кому чего в KOLnMCK не хватает?
Отрисовки контролов на GPU, ИМХО за этим будущее, да и скорость должна быть огромной...
Хотя, возможно это бредовая идея.

← →
Vga © (2006-11-24 00:28) [2]

> [1] ANTPro © (24.11.06 00:22)

После добавления отрисовки контролов KOl потеряет смысл.

← →
Vga © (2006-11-24 00:28) [3]

> KOl

Блин, опять... KOL.

← →
ANTPro © (2006-11-24 00:42) [4]

> [2] Vga © (24.11.06 00:28)
> После добавления отрисовки контролов KOL потеряет смысл.

Вряд ли, в GRush ведь используется собственная отрисовка...

← →
Vga © (2006-11-24 00:52) [5]

> [4] ANTPro © (24.11.06 00:42)

Но не на GPU. И кстати, сколько они добавляют веса приложению?

← →
homm © (2006-11-24 01:15) [6]

> Но не на GPU. И кстати, сколько они добавляют веса приложению?

Форма с любыл GRush конролом (они все почти весь код вклачают) от 30кб. Но это с учетом того что добавляется вся графическая система кол (канва, битмэпи, шрифты) и еще некоторые функции.

← →
Vga © (2006-11-24 01:46) [7]

> [1] ANTPro © (24.11.06 00:22)

Точно, бредовая :)

> [2] Vga © (24.11.06 00:28)

Я имею в виду на GPU...

← →
_gandalf_ (2006-11-24 15:46) [8]

отрисовка на GPU - в смысле - чтоб gl окно появлялось или dx? надо чтобы ось поддерживала графические примитивы на GPU - что вроде уже есть в vista и местами в XP

1) мне не хватает полноценной либы для сетей - ics - проблема даже не в портинге а в дальшем сопровождении - когда авторы ics ее вдруг обновят - сложно это
2) jedi бы сюда - опять же трудно сопровождать
3) подружить mck с BDS2005-2006 и выше - наверное на днях займусь
4) VirtualTreeview - оч удобная вещь
5) ещеб несколько модных контролов в стиле office XP-2007 и VS2005/Delphi2006 - градиент табы/ribbon и т.п.

← →
ANTPro © (2006-11-24 16:05) [9]

> [8] _gandalf_ (24.11.06 15:46)
> отрисовка на GPU - в смысле - чтоб gl окно появлялось или dx? надо чтобы ось поддерживала графические примитивы на GPU - что вроде уже есть в vista и местами в XP

Да отрисовка на OpenGL, но зачем поддержка осью примитивов? Если GPU будет только рисовать...

> [8] _gandalf_ (24.11.06 15:46)
> 3) подружить mck с BDS2005-2006 и выше - наверное на днях займусь

Очень интересна реализация, надеюсь будет отдельная ветка об этом...

← →
Vladimir Kladov (2006-11-24 17:51) [10]

у меня с БДС не получилось. Он "видит" обман. MCK проект для него больше не VCL, так что подружить таким способом уже не удастся, наверное. Есть мысль: сделать автономный MCK, чтобы он по максимуму задействовал наработки MCK. Т.е. чтобы большая часть кода MCK и зеркал дополнительных пакетов могла быть задействована. Свой Инспектор, возможно опциональный агент-визард, встраиваемый в BDS, чтобы тот взаимодействовал с этой тулзой и "сообщал" Delphi, что файлы надо обновить, а то и обновлял их автоматом. Я пока что успешно юзаю Delphi6, но не ровен час, лет через 5 придется по какой-либо причине переезжать на новые версии Delphi.

← →
Vedun (2006-11-24 22:27) [11]

Как вариант, можно сделать wizard типа QT Designer в Linux, и с помощью него конструировать формы, менять визуальные мсвойства, а на выходе получать inc-файл, аналогичный тому, который создает MCK. Ну а обработчики событий придется назначать вручную. Но это лучше, чем конструировать форму невизуально для чистого KOL.

← →
Vga © (2006-11-24 22:37) [12]

> [11] Vedun (24.11.06 22:27)

Qt Designer в версии 3 и сигналы позволял связывать, и редактор с подсветкой имел...

← →
_gandalf_ (2006-11-24 22:45) [13]

А если допустим lazarus модифицировать?

← →
ANTPro © (2006-11-24 22:57) [14]

> [13] _gandalf_ (24.11.06 22:45)

Он же глючный и не стабильный?

← →
Vedun (2006-11-24 23:05) [15]

Кстати, а почему в lazarus такие большие экзешки получаются когда делаешь оконное приложение?

← →
Vga © (2006-11-24 23:15) [16]

> [14] ANTPro © (24.11.06 22:57)

А с нуля ты не лучше напишешь. Быстрее его адаптировать.

← →
Vga © (2006-11-24 23:16) [17]

> [15] Vedun (24.11.06 23:05)

LCL. Большая. И smart linking в FPC похоже хуже работает. Тем более своего линкера у него нет, он гнутым пользуется.

← →
ANTPro © (2006-11-24 23:17) [18]

> [16] Vga © (24.11.06 23:15)

Я то тут причем? Delphi стабильней будет намного...

← →
Vga © (2006-11-24 23:20) [19]

> [18] ANTPro © (24.11.06 23:17)

Дельфи закрытый, его никак не перепишешь, увы. Разве что придурь разработчикам придет, как с InterBase 6.0 OpenSource.

← →
Vedun (2006-11-24 23:34) [20]

А размер программ, откомпилированных с использованием KOL в Delphi и FPC, сильно отличается?

← →
Vladimir Kladov (2006-11-25 10:47) [21]

FPC добавлял примерно 50К за счет своего system.pp или как его там. Так было до версии 2, в 2 я не смотрел. Можно поискать, не делал ли кто замены system для него. Кроме того, наша асм-версия с ним несовместима, из-за некоторых отличий в синтаксисе. Для небольших проектов, использующих из KOL немного, это несущественно, ну 5К добавит. При увеличении проекта разница нивелируется. Зато FPC поддерживает очень много платформ, и не только разных ОС на PC, но и совсем других архитектур процессора и памяти.

← →
Vga © (2006-11-25 11:25) [22]

> [21] Vladimir Kladov (25.11.06 10:47)

А толку, если KOL (Windows) их не поддерживает? Разве что GTK версия будет компилироваться везде...

← →
Vladimir Kladov (2006-11-25 11:36) [23]

GTK поддерживается для всех unix-платформ, и для Windows. Т.е. это тоже мультиплатформенная штука. Вот сейчас продолжу работу над переходом к нему, как раз после UNICODE боле-мене начал приходить в себя.

Для MCK надо делать standalone-приложение, которое имеет свой дизайнер форм, и использует именно код из MCK по максимуму, чтобы задействовать наработанный код зеркал. Делать надо на VCL/CLX (иначе как использовать классы MCK), так его можно будет откомпилировать по крайней мере для Windows И Linux. (Ну можно попробовать и на FPC, но MCK сразу был под Windows заточен, так что могут появиться проблемы).

Часть, которая встраивается в Delphi (а такая все-таки нужна) - в виде визарда, который обменивается с standalone-дизайнером сообщениями или через mapping-файл. Нужна она, чтобы сразу сообщать Delphi/BDS об изменениях в файлах pas и inc, и наоборот - тоже. Хорошо бы интерфейс сделать таким, что если появится возможность сделать аналогичный визард для Lazarus, то это тоже прошло бы без особых изменений в standalone-MCK.

Но standalone можно сделать так, что если визарда нет (или еще нет), работать все равно можно бы было.

Еще: standalone-MCK должен понимать / модифицировать dfm-файлы, они в текстовом виде в Delphi где-то с 4-5, так что это не великая проблема.

Так что, кто-то хочет взяться (Gandalf?). Срочности большой нет, сложности в не-визард-части тоже особо никакой не вижу (пока). Время только надо. У меня и так GTK подвис.

← →
Galkov © (2006-11-25 12:00) [24]

Про FPC.
Версии выше 2-й не проверял... Просто потому, что не нашел их консольных вариантов. А качать 20M ради сомнительного удовольствия - не хотелось

А ниже, действительно, ASM - неприменим. И не только из-за синтаксических различий. Порой просто умирает по необъяснимым причинам (может потому, что -MDelphi)

С тем, что при увеличении проекта разница невелируется - не соглашусь.
Просто ОЧЕНЬ тупой компилятор. И это проявляется на КАЖДОЙ команде.
Свидетельством этого косвенно является еще и большая степень компрессии каким нибудь UPX.

Говорю потому, что мне не лень было полазить дизасмом. Что видел, то и говорю

← →
Vladimir Kladov (2006-11-25 13:52) [25]

а оптимизацию включали? в дебуг-режиме код от Delphi тоже не блещет остроумием.

← →
Vga © (2006-11-25 14:46) [26]

> Для MCK надо делать standalone-приложение, которое имеет
> свой дизайнер форм, и использует именно код из MCK по максимуму,
> чтобы задействовать наработанный код зеркал. Делать надо
> на VCL/CLX (иначе как использовать классы MCK), так его
> можно будет откомпилировать по крайней мере для Windows
> И Linux. (Ну можно попробовать и на FPC, но MCK сразу был
> под Windows заточен, так что могут появиться проблемы).

Standalone - да, согласен, а вот насчет CLX... Кратковременное знакомство с кайликсом вызвало ощущение, что не только он сам как-то странно сделан (это возникло после просмотра запущенных им профессов - он много чего для своей работы запустил, включая wine), но и компилирует через то же место (во всяком случае, хотя тестовый проект хорошо работал из IDE/Debugger"а, но непосредственно исполнимый файл запустить не удалось - линукс его ни в какую не признавал).

← →
Vladimir Kladov (2006-11-25 15:13) [27]

что стандалоне не запустился, это возможно проблемы триала. Или в настройках надо ковыряться. Надо попробовать, что он мне скажет. Правда у меня кайликс-1 только.

← →
Vga © (2006-11-25 15:21) [28]

> что стандалоне не запустился, это возможно проблемы триала.

Вроде не триал был...

> а оптимизацию включали? в дебуг-режиме код от Delphi тоже
> не блещет остроумием

Да. Перепробованы все варианты. Что именно там называется оптимизацией - осталось загадкой.
А тупость такая, что Debug-ом объяснять очень трудно...
Да и про гнутый линкер... Не для этой темы, наверное :))))

> [29] Galkov © (25.11.06 15:36)

Быть может, ты включал оптимизацию по скорости выполнения, а не по размеру кода? В одном тесте AFAIK Intel C++ намного обскакал ассемблерщика по производительности и изрядно отстал по размеру кода.

Слова, слова.... :)
А если конкретно, при использовании FPC с такой шапкой
Free Pascal Compiler version 1.9.6 [2004/12/31] for i386
Copyright (c) 1993-2004 by Florian Klaempfl
Target OS: Win32 for i386

следующий простенький код (специально ничего не делал, просто дернул со своего форума)

procedure THICounter._work_doReset; begin if _prop_Type = 0 then FCounter := _prop_Min else FCounter := _prop_Max; end;

делается вот так:
0040ECA0: 55 push ebp 0040ECA1: 89E5 mov ebp,esp 0040ECA3: 83EC0C sub esp,0000000C 0040ECA6: 8945F4 mov dword ptr [ebp-0C],eax 0040ECA9: 8955FC mov dword ptr [ebp-04],edx 0040ECAC: 66894DF8 mov word ptr [ebp-08],cx 0040ECB0: 8B45F4 mov eax,dword ptr [ebp-0C] 0040ECB3: 0FB64018 movzx eax,byte ptr [eax+18] 0040ECB7: 85C0 test eax,eax 0040ECB9: 7402 jz 0040ECBD 0040ECBB: EB0E jmp 0040ECCB 0040ECBD: 8B45F4 mov eax,dword ptr [ebp-0C] 0040ECC0: 8B55F4 mov edx,dword ptr [ebp-0C] 0040ECC3: 8B400C mov eax,dword ptr [eax+0C] 0040ECC6: 894204 mov dword ptr [edx+04],eax 0040ECC9: EB0C jmp 0040ECD7 0040ECCB: 8B45F4 mov eax,dword ptr [ebp-0C] 0040ECCE: 8B55F4 mov edx,dword ptr [ebp-0C] 0040ECD1: 8B4010 mov eax,dword ptr [eax+10] 0040ECD4: 894204 mov dword ptr [edx+04],eax 0040ECD7: C9 leave 0040ECD8: C3 ret

Для сравнения, как это же самое делает дельфя:
00411198: 80781800 cmp byte ptr [eax+18],00 0041119C: 7507 jnz 004111A5 0041119E: 8B500C mov edx,dword ptr [eax+0C] 004111A1: 895004 mov dword ptr [eax+04],edx 004111A4: C3 ret 004111A5: 8B5010 mov edx,dword ptr [eax+10] 004111A8: 895004 mov dword ptr [eax+04],edx 004111AB: C3 ret

И вот теперь было бы уместно порассуждать: чего надо, или нет для Debug....
Хотя мне представляется, что комментарии тут излишни.
И аналогичное - по всему коду, естественно.
Вот ОТСЮДА и возникали у меня сомнения про то, что разница в размере кодов на больших проектах нивелируется

И если кто-то подскажет комбинацию ключей для fpc делающую его умнее - то просто нет слов. Я пока не нашел. :(

И что версии 2.X.X - умнее не очень верится.
Но если кто продемонстрирует (у кого есть зачанные эти версии, конечно) что я ошибаюсь - придется качать :)))

Как видите, аргументация-то очень простая - вот код, а вот результат :)
Но, она ведь действительно аргументация...

← →
Vladimir Kladov (2006-11-26 18:00) [32]

Даже если он такой тупой, то это все равно не смертельно. Я сейчас глянул, пустое приложение, которое ничего не делает, в версии 2 всего 29,5К. Это не 16К от Delphi, конечно, тем более не 5,5К от Delphi+замены system, но уже и не 50К, как было раньше. Размер приложений чаще растет не за счет своего кода, а засчет всяких сторонних модулей, и ресурсов, а их размер и там, и там будет примерно одинаковый. Библиотеки для работы с графикой, например, часто делаются на С и прилинковываются из obj-файлов. (Кстати, в отличие от Delphi, FPC умеет это делать). В этом случае все равно будет размер нивелироваться с ростом приложения. Еще может быть такое, что большая часть кода - это код, сгенерированный для инициализации формы (если проект портируется из Delphi, а там он делался в MCK). И тогда вполне возможно использовать Collapse, и эта часть не только не будет зависеть от компилятора, но еще и будет меньше в 2 раза, чем даже после "умного" Delphi. Ну, сделайте допуск * 2 на тупость компилятора, но я уверен - это не фатально, и малые приложения останутся все равно малыми, потому что просто порядки размеров другие для KOL: в 5-10 раз все равно меньше.

> Ну, сделайте допуск * 2 на тупость компилятора

Согласен. Даже где-то 1.5...2.0 (по опыту) :))

Но сделать KOL для FPC (5-10 раз конечно хочется :)) - серьезные напряжения вызывает сегодня...
Безглючного портирования я как-бы и не видел...
Пользую, конечно. Но порой такие прелести, что цензурных слов-то и нет :(

← →
Vladimir Kladov (2006-11-26 19:43) [34]

Так если что надо от KOL в этом направлении, мы всегда по мере сил. И даже народ помогал авторам FPC (т.е. участвовал в open source) чтобы и гора к магомету тоже пришла. Было же, что FPC не хотел object, так "уговорили", чтобы хотел.

Offtop немного....

имею некоторое отношение к проекту, который на основание некой схемы, (понятной даже, скажем так, незнакомому с программированием челу) генерирует исходные коды.
Т.е., является надстройкой над неким компилятором.
Когда среда весит пару метров, сложновато как-то говорить о компиляторе в 20М. Или 320 :)
С 4-м Дельфи все прелестно - вместе с KOL-ом, упакованый весит всего метр.
С FPC посложнее, прямо скажем. Из-за размеров - это 1.9.X
Просто не знаю консольного варианта для 2.X.X, которым уже известны object. Следовательно - это портирование KOL под классы

Проблемы, в общем :)
Кстати, первое (но очень не сразу) на что я "наступил" в портированном варианте:
procedure TObj.DoDestroy; begin if fRefCount <> 0 then begin if not LongBool( fRefCount and 1) then Dec( fRefCount ); end else Self.Destroy; //Было просто Destroy, но FPC это понимает как TObj.Destroy end;

Кстати, если кто знает консольную "нарезку" с того FPC, который знает object, наша благодарность не будет иметь границ, в разумных пределах.
:)))))))))))

> Что означает "консольная нарезка"? И что за проект? Описание
> напоминает HiAsm...

1) Мне кажется, что версии выше 2-й - это IDE. Возможности которой в моем случае просто излишни. Возможно (я не знаю), что достаточно лишь части файлов этого пакета для запуска из командной строки. Отдельно таковой вариант авторы вроде не выложили.
2) Да, там хватает проблем. Возможно и из-за не полного понимания KOL. По крайней мере в момент создания.

> [38] Galkov © (27.11.06 01:22)

Откуда там IDE? Он вроде (на первый взгляд) почти не отличается от 1.9.6 (неудивительно, ведь 1.9.6 - это 2.0 beta 6). Сборка видимо будет примерно та же, что в HiAsm (там на основе 1.9.6 - бетки).

В FPC есть fpc.exe -консольный компилятор и fp.exe - Ide оболочка аля TP7.
FPC 2.0.4 кстати уже компилит родные KOL файлы без модификации, правда скомпиленная прога в зависимости от сложности стабильной работой не отличаеся. Проверял на последней версии KOL в unicode программе: unicode шрифт так и не врубился, а при добавлении строк с не ANSI символами в KOLListBox прога выдает мат и закрывается.

Кому чего в KOLnMCK не хватает? Найти похожие ветки