Страницы: 1 2 3
Проблемы KOL на 2022 год.
lord (01.11.22 14:17) [20]
Не говорите мне что делать и я не скажу куда вам идти.
Вот именно. Вам адрес уже назвали. Потактичней и поделикатней.
Dimaxx © (01.11.22 15:02) [21]
Вам могу указать тот же адрес.
Vladimir Kladov © (28.11.22 08:13) [22]
Дело совсем не в том, что KOL какой-то особо гениальный, а Алфор - наоборот. По мне, так совсем иначе, но дело совсем не в этом.
Вот если бы до 2016 года КОЛ не было, а в 2016 он впервые появился - вы бы о нем вообще не знали. И он так же никому не был нужен. И сейчас КОЛ если кому и нужен, то только тем, кто про него уже знает, и на вас он кончится. Увы.
Новые люди не приходят. Они все ушли в мейнстрим: Go, Java, Python, и прочие Rubi. А что еще вы хотели? Всем нужна мультиплатформенность или хотя бы востребованность, чтобы было на что жить.
Мне очень обидно, что я не бросил КОЛ лет на 10 раньше, и не сделал Алфор тогда. Может быть, успели бы появиться последователи. Теперь уже поздно - поезд для одиночек-энтузиастов ушел. Сделай сейчас кто-то в одиночку супер-пупер новый язык - никто и не пошевельнется и не заинтересуется. Это же не гугль/ибм/микрософт/оракле. Значит, скоро (лет за 5-20-40) помрет. И нет смысла изучать, пробовать. Остался только ням-ням того, что втюхали Корпорации. Ну и нямкайте без меня дальше.
lord (03.12.22 03:14) [23]
Проблема в том, что Алфор страшно ограничен.
Нет многомерных массивов. Цикла While
и много прочего по мелочам.
И я не думаю что на нем можно было бы влезть в пикселы и работать с ними на уровне битов.
В общем всего того к чему я привык.
Что касается кроссплатформы, KOL прекрасно компилируется.
И под любую ось и даже под ARM
Go, Java, Python, и прочие Rubi это не языки программирования. Это скриптовые языки. Библиотеки к ним так и так пишут на Си
Я всего лишь хотел чтобы некоторые модули смогли компилироваться под 64 бита.
Все есть, только что и надо перевести это это в KOL
Вы прекрасный специалист. Однако не надо опускать руки. Писали бы для одиночек.
Сама KOL под 64 существует. Паскалевская версия, но адаптированная.
Она прекрасно ставится на новые версии Делфи, или как там сейчас их называют.
А вот проблема только с графикой и компрессорами. Там только 32 разрядные версии.
У меня есть несколько проектов, которые хотелось бы перевести в 64 бита.
И еще было неплохо исправить глюки в некоторых компонентах.
Если бы у меня было бы больше времени и возможно ума, я всё бы это сделал сам, но это займет много времени, и его не хватит на проекты.
И вы не правы по отношению к живучести всякой фигни вроде андройда и прочего. Импортозамещение потребует настоящих программистов а не скриптописателей.
Vladimir Kladov © (03.12.22 19:26) [24]
По первому абзацу - все неверно. И многомерные массивы есть - через классы. Я просто не стал их "встраивать" в компилятор. Гибкость - иногда вреднее, чем нужнее. И в пикселы можно влазить. А как бы еще можно было сделать поддержку текстур для Open GL.
KOL может и компилируется под разные платформы. Но в чем смысл его на этих платформах, если он заточен под WinApi. А на Android он тоже компилируется? Насчет Линукса - если без Wine - то как быть?
Новые Delphi мне не интересны. Ставил пару раз - и больше не буду. Очень громоздкий, долго ставится, долго сносится, слетает по непонятным причинам, зас***ет систему - требуется переустановка винды для очистки от мусора. Работа на ПК, не подключенном к сети - как бы помягче сказать - затруднена. Сам Delphi постоянно что-то там у себя меняет: революции 2 раза в год. FireMonkey - вообще какой-то шлак с помойки.
Я не понял насчет Андроида - я вообще слова про него и его живучесть не сказал. И насчет импортозамещения тоже ничего не понял. Настоящие программисты программируют на Фортране. Для Эльбруса. Хотя нет, там же в С++ компилятор - своих языков-то нет.
lord (04.12.22 00:03) [25]
KOL если полностью включить режим паскаля, компилируется и под линукс и под андройд, и под ARM
FireMonkey вообще не при чем.
Что касается андройда, я просто обобщил.
вы написали про Java и про прочую муть.
Я всего лишь сказал. что настоящие языки, это те что компилируются в исходный исполняемый код.
А то что вы перечислили это скриптовые языки, которые работают не в осях а виртуальных машинах. Вот андройд виртуальная машина и есть, для джавы.
Поэтому я и обобщил все это под андройд.
Про импортозамещение я сказал, что нужны настоящие программисты. То есть те которые пишут на компилируемых языках. и те, которые смогут заставить дышать эльбрус.
И потом, я же уже написал что у меня есть несколько почти готовых проектов, которые я просто бы хотел скомпилировать в KOL в 64 бита без всяких других языков. Да, в паскалевской версии они не такие маленькие, но не 2 мегабата.
меньше 100 K.
Но мене нужны модули с компрессорами и работы с графикой. вот и все.
Сам модифицированный KOL с названием KOL64 и МСK работают вполне нормально на новых версиях Делфи.
А модули эти, которые работают и в 32 и 64, существуют, но для VCL
Все что нужно, это чтобы они работали с KOL.
Вот когда у меня все заработает как надо и в 64 разрядах я посмотрю и ваш язык. Может действительно что получится. А пока надо разобраться с тем. что есть.
Vladimir Kladov © (04.12.22 07:17) [26]
По-моему, Вы, lord, не разобрались, где языки программирования, где платформы, и где библиотеки функций. KOL (проект на KOL) НЕ МОЖЕТ компилироваться никуда, кроме Windows. Ну, если только это не консольное приложение. Другое дело, что результат компиляции - бинарный файл - может быть выполнен в Линукс (даже и визуального, с формами). Через wine - это еще 20 лет назад работало. Для этого не требуется особая компиляция, достаточно обычного Delphi 3-7. Визуальная часть KOL работает через оконные сообщения Windows, без них KOL - уже не KOL, куда бы вы его не компилировали. Если новый Delphi умеет компилировать в dalvik и при этом транслирует с сообщения Windows на android-е - ну что ж, поздравляю - у вас на андроиде развернута виртуальная машина с эмулятором WinApi. О-о-очень экономненько так.
Алфор позволяет выбрать в качестве целевой платформы Delphi+KOL. Или Delphi+VCL. Или FreePascal+LCL. Или C#+WinForms. Или Java+Android. И при этом не требуется никаких изменений в исходном коде. У меня есть несколько больших и средних проектов на VCl. Так вот, я за пару месяцев перевел большой проект с VCL под Алфор и теперь он спокойно может запускаться и работать под Линукс (Free Pascal) или Виндовс (Delphi7(+KOL/+VCL) / Free Pascal / C# - на выбор).
Не знаю, чем вам так уперлась 64-битность кода, но 3 из перечисленных вариантов - 64-битные. Размер кода в случае большого проекта уже мало зависит от того, KOL там или не KOL. Там изначально было 3-6 Мбайт в exe-файле (в зависимости от опций проекта). После перехода на Алфор получаются те же 3 Мб в случае VCL, и 2 Мб - KOL. 64-битность спокойно получается при компиляции Free Pascal-ем (около 7 Мб) и C# (около 5Мб).
Или под 64-битностью Вы понимаете поддержку unicode? Так в случае компиляции во Free Pascal и C# она тоже есть.
А вообще, KOL изначально не для больших проектов. Я это всегда особо отмечал.
lord (05.12.22 11:49) [27]
{$I KOLDEF.INC}
{$IFDEF WIN64}
{$DEFINE PAS_ONLY}
{$DEFINE STREAM_LARGE64}
{$ENDIF}
{$IFDEF PAS_ONLY}
{$DEFINE PAS_VERSION}
{$ENDIF}
{$IFDEF EXTERNAL_KOLDEFS}
{$INCLUDE PROJECT_KOL_DEFS.INC}
{$ENDIF}
{$IFDEF EXTERNAL_DEFINES}
{$INCLUDE EXTERNAL_DEFINES.INC}
{$ENDIF EXTERNAL_DEFINES}
{$DEFINE GDI}
{$UNDEF LIN} {$UNDEF WIN} {$UNDEF GDI}
{$IFDEF LINUX}
{$DEFINE UNIX}
{$DEFINE LIN}
{$DEFINE PAS_VERSION}
{$DEFINE NOT_USE_RICHEDIT}
{$IFNDEF GTK}
{$IFNDEF XQT}
{$DEFINE GTK} // it is also possible to define GTK as a project option
{$ENDIF XQT} // even for Windows system
{$ENDIF GTK}
{$ELSE} // to exploit GTK under Win32 rather then native GDI
{$DEFINE WIN}
{$DEFINE GDI}
{$ENDIF}
{$IFDEF GTK} {$UNDEF GDI} {$DEFINE _X_}
{$DEFINE NOT_USE_RICHEDIT}
{$ENDIF}
//{$IFDEF Q_T} {$UNDEF GDI} {$DEFINE _X_} {$ENDIF}
{$IFDEF WIN} {$IFDEF GDI}
{$DEFINE WIN_GDI}
{$ENDIF GDI} {$ENDIF WIN}
{$INCLUDE delphidef.inc}
{$IFDEF WIN_GDI}
//test
{$ENDIF WIN_GDI}
{$IFDEF LIN}
//test
{$ENDIF LIN}
unit KOL;
{$IFDEF FPC}
{$MODE Delphi}
{$ENDIF}
lord (05.12.22 12:17) [28]
Это вот кусок из KOL64
Сколько раз говорить.
Мне нужен не KOL а чтобы модули с ним работали.
есть модуль PNG с 32 и 64 битами.
Вот он мне нужен. Чтобы просто он работал с KOL как тот, что есть сейчас под 32
Для других картинок так же.
И компремссоры.
Алфр как работает с графикой?
И вообще я не голословно говорю. я говорю о том что сделано и что реально с компилировано.
32 битные приложения на чистом паскале 42K 64 битные - 84K
Под линкус тоже работает все прекрасно.
Мне нужны картинки. Проблема в модулях OBJ они 32 разрядные.
А для 64 разрядных нужно переделать сам файл, который уже существует.
Вот все что мне нужно.
Мне нужно отвязать эти модули от VCL
Вот и все.
По поводу больших проектов громко сказано, но конечно не мелкие утилиты.
На 32 готово и работает.
Я не понимаю вашего упрямства. Ну не хотите вы мне помочь не надо.
Но не надо из меня строить идиота.
Я прекрасно знаю что такое платформа.
Мне достаточно винды.
И прекрасно знаю что KOL это огромная библиотека на языке паскаль.
А PNG GIF это библиотечные модули, которые работают конкретно с KOL
Что такое языки программирования я тоже знаю.
И Питон и то что вы перечислили это скриптовые языки. Это уже не программирование а кодерство.
И точно так же знаю что Андройд это виртуальная машина вклеенная в линукс.
И на все смартах стоит именно линукс с этой примочкой.
Vladimir Kladov © (06.12.22 07:24) [29]
Алфор работает с графикой нормально. Есть демо-приложение zoomer6 на Алфор, lite-версия выложена в директории Demo с исходниками. Для Алфор я переписал gif на высокий уровень, изрядно потеряв в быстродействии, но обеспечив быстрый переход на любую платформу. При желании и наличии времени, никто не запрещает для каждой интересующей платформы самую медленную часть переделать на нативный код.
Т.е. вам не интересен KOL, а нужны его возможности работы с графикой - так бы и сказали. И платформа нужна только Windows. Допускаю, что Windows будет еще некоторое время нужен, но уже сейчас в 11 версии потихоньку начинают зажимать 32-разрядные приложения. Подталкивают разработчиков в сторону 64. Лет через 5-10 будет поставлен окончательный крест на 32-битном Api. Конечно, не так радикально, как поступило яблоко, но все равно к тому идет. Подозреваю, что в Windows12 32-битность будет убита на уровне ОС.
Я все равно не принимаю Ваше упорство по поводу разделения ЯП на нормальные и скриптовые. ЯП - это ЯП, скриптовый он или нет. Для той же Джавы и Питона есть возможности компиляции в машинный код, но даже это им и не нужно, чтобы становитья ЯП. У меня есть разочаровывающий опыт: когда я для Алфор поддерживал направление Java/Desktop, программа число-строко-дробилка при компиляции в Java обгоняла почти вдвое самый быстрый вариант. Delphi/VCL отставал примерно в 1,5-2 раза, за ним впритык шел Delphi/KOL и немного приотставал C#. Затем в 2 раза хуже шарпа был Free Pascal (но с тех пор я оптимизировал работу со строкаму в utf-8, и теперь он практически на том же уровне). Хуже всех был хваленый C++ - из-за его неоптимальной работы с std::string. Но главное - это то, что Java уделал всех.
Да, Java на Android-е тот еще тормоз. Но, при желании, и наличии времени (и людей) всегда есть возможность поддержать и низкоуровневое программирование под конкретные процессоры. Алфор допускает низкоуровневые вставки.
lord (06.12.22 12:36) [30]
Как же с вами сложно.
KOL уже есть. И работает он и под винду и под линукс.
Для чего мне 64 битные приложения? Вы уже сами ответили на этот вопрос.
В данный момент меня интересуют модули прежде всего.
Что касается джавы то тут вы уже чушь написали.
Джава это интерпретатор в котором исходный код скомпилирован в байткод, который выполнятся на виртуальной машине. И он управляет библиотеками, которые написаны на самом С++.
Точно так же как и Direct X и Open GL
И он никак не может быть быстрее скомпилированного кода в полтора раза, и тем более в 2.
Языки программирования не влияют на скорость и на что-либо. Эти рассуждения на уровне что лучше, русский английский испанский и так далее.
Дело в компиляторе. А тормоза это классы и прочая муть.
Это если говорить про языки программирования.
У скриптовых языков скорость зависит от скорости работы самой виртуальной машины и не более того.
Знаете почему был получен прирост скорости?
Да очень просто, потому что виртуальные машины активно используют нити (программные потоки) и всякие штуки вроде MMX и прочего.
Точно так же используются разные алгоритмы.
Читать текст как бинарные данные из потока намного быстрее.
И вы сами написали модуль списка с нуль-терминаторами. Это тоже ускоряет обработку строк.
Вот скажем простой пример. Нужно считывать и обрабатывать текстовые данные в юникоде. Да еще в регистронезависимом режиме. Как это сделать быстрее? Да очень просто. Использовать таблицы.
Кстати про обработку строки в UTF-8
А нафига? UTF-8 нужен для хранения текста а не для работы с ним.
Поэтому он как и другие экзотические кодировки превращаются в UTF-16
Его за глаза и за уши, если язык не китайский.
Мой проект как раз и делает что занимается всем этим. И уж поверьте экспериментов по этому поводу было сотни на разных языках и на разных платформах. Особой разницы нет.
Все зависит от скорости процессора памяти и вообще от аппаратного обеспечения и алгоритмов. А от компилятора практически ничего. Но я сказал про компиляторы, а не интерпретаторы.
А такие заявки что мне KOL не нужен... это бред. Если я выбрал эту библиотеку, то вполне осознанно и очень давно.
Он хорош, но без внешних библиотек сильно ограничен, как и любая глобальная библиотека. составляющая ядро.
Просто было бы проще, если бы кто-то сделал то что вы сделали для 32 версии
В принципе все тоже самое, но с вставкой 64 битной версии.
Сами модули для VCL и OBJ есть.
Vladimir Kladov © (07.12.22 10:52) [31]
KOL никто и не закрывает. Более того, для меня он - одна из целевых платформ. 64-битностью для kol я заниматься не буду. Как минимум, по причине отсутствия бесплатного, легковесного (хотя бы сравнимого со старыми Delphi), нормально работающего (в том числе без доступа к сети/интернету) компилятора. Про новый Delphi я уже говорил.
Насчет Java вы не правы - это не интерпретатор. Сейчас основной принцип его работы - его код из байт-кода компилируется при первом обращении к функции. Далее выполняется честный машинный код. Почитайте про JIT.
lord (07.12.22 14:33) [32]
А причем тут компилятор? При чем тут новая версия Делфи?
Я только хочу переделать несколько модулей под KOL и все.
Там уже все есть, надо только сделать то. что вы уже когда-то сделали.
Модули работают как под 32 так и под 64 бита. Переключается ключами условной компиляции.
Так что компилятор и версия Делфи им до лампочки. в крайнем случае если это мешает задокументировать все что относится 64 битам и сделать чтобы заработала 32 разрядная версия. А потом мне только останется снять скобки и все.
Прежде всего мне нужен архивный компрессор. И PNG. В нем тоже компрессор, почти аналогичный модуль архивному компрессору. И для этого вполне достаточно даже 7 Делфи. Если заработает 32 битная часть, то заработает и 64 битная.
Что касается Java.
Если все так как вы написали, она теряет кроссплатформенность. И превращается в обычный клон С++.
А Новые Делфи компилируют под любую платформу.
И про FreePascal забывать не стоит забывать. Он давно это делает.
Так что вся соль Java именно в байткоде. а преимущество в мощной поддержке.
В любом случае JAVA актуальна лишь в качестве аплетов под Андройд.
И у меня проделана огромная работа над моими двумя проектами.
И переделывать весь код на другой язык и на что либо другого нет смысла.
на 32 все отлично работает. На 64 упирается в графические модули.
И даже в 32 разрядной версии есть глюк.
ListView если положить их два и более на форму. вступают в конфликт друг с другом. Особенно если задействовано событие отрисовки. Висит не только приложение но и вся система. Даже диспетчер не вызвать. только полная перезагрузка компа.
lord (07.12.22 20:37) [33]
что касается JIT
интерпретатор остался интерпретатором, только компилируемым.
Никакого преимущества перед другими языками не вижу. Это не технология, а как любят сейчас выражаться лафхак.
И она совершенно не нова.
На одном форуме есть аналогичная система на паскале.
Там интерпретируемый калькулятор.
Он для ускорения превращает саму заданную текстом функцию или вычисляющий скрипт в байткод.
Этот код выполняется.
И далее было написано расширение этого модуля.
Для построения графика используется та же самая штука что и JIT
Пользователь набирает сложную формулу или всякие скрипты вычисления с интегралами и прочим. Это превращается в паскалевский код, котрый компилируется в DLL компиляторм от самого Делфи. То есть этот компилятор лежит в папке с прогой и запускается через командную строку.
Ну а DLL пускается в дело и сама вычисляет и строит график.
Таким же способом на других форумах делались всякие проги для криптографии и прочих премудростей, например защиты от взлома.
так что в динамической интерпретации-компиляции нет ничего нового.
Насколько помню у вас на принципе поточной компиляции работает какой-то модуль. ну когда вы писали эмулятор спектрума, то его использовали.
На этом же принципе работают и аддоны и макросы в многих прогах.
Так что это не преимущество джавы, а хорошо забытая старая хитрость.
Митя (08.12.22 18:06) [34]
Давно хотел попросить Владимира Кладова создать поддержку юникода
lord (08.12.22 20:27) [35]
В KOL и MCK юникод есть.
Для включения юникода надо вставить в проект символ условной компиляции UNICODE_CTRLS
Все прекрасно работает.
Но юникода нет в дополнительных модулях. Их надо дописывать.
Митя (08.12.22 23:22) [36]
Ещё странный глюк заметил - иногда при сборке проекта с запуском, при закрытии главного окна приложения происходит какая-то ошибка в модуле KOL, access violation at 0x00404d93: read of adress 0x00000084.
От строки 28983
По строку 29003.
Если это закомментировать то всё норм. Этот глюк редкий но прочный - если вылез то надолго
Митя (08.12.22 23:38) [37]
О да! - сбылась мечта идиота - наконец в заголовке формы отображаются названия файлов с юникодами.
Теперь понимаю что нужны контроля наподобие TNT
lord (09.12.22 03:08) [38]
вообще то некоторые нужные функции в kol отсутсвуют. и приходится писать их самому. но это не критично. в дополнительных модулях некотрые таковые функции есть, но не поддерживают юникод. в некотрых местах есть код, не поддерживаемый даже 7-ой.
но и это не проблема.
что касается этой ошибки...
ну надо почаще делать перестройку проекта. особенно после добаваления на форму новых компонентов.
и еще некотрые проекты не стоит запускать под отладчиком, а только запускать из папки. например если есть перетаскивание.
и очень часто такая ошибка возникает при установке на форму компонентов старых версий.
их имена в uses становятся не туда куда надо.
а иногда стоит пересобрать проект вручную. то есть сделать новую форму, и заново поставить компоненты.
подобные приколы возникают если по ошибке воткнута vcl.
или вместо формы kol событие открыто в несущей форме.
или после некоректоного удаления компонента.
иногда случайно может быть стерт переключатель условной комиляции
так что надо просто быть очень внимательным.
и делать персборку. build
Митя (09.12.22 20:33) [39]
Пересборка не помогает - подозрение на винду с её реестром
Разрешается использование тегов форматирования текста:
<b>жирный</b> <i>наклонный</i>
<u>подчеркнутый</u>,
а для выделения текста программ, используйте <code> ... </code>
и не забывайте закрывать теги! </b></i></u></code> :)
Наверх 
Чтобы не потерять эту дискуссию, сделайте закладку