Состоялся (http://forum.lazarus-ide.org/index.php?topic=44161) релиз интегрированной среды разработки Lazarus 2.0 (http://lazarus.freepascal.org/), основанной на компиляторе FreePascal (http://freepascal.org/) и выполняющей задачи, сходные с Delphi. Среда рассчитана на работу с выпуском компилятора FreePascal 3.0.4. Готовые установочные пакеты с Lazarus подготовлены (http://sourceforge.net/projects/lazarus/files/) для Linux, macOS и Windows.Среди изменений (http://wiki.lazarus.freepascal.org/Lazarus_2.0.0_release_notes) в новом выпуске:
- Поведена работа по улучшению работы на экранах с высокой плотностью пикселей (HighDPI);
- Добавлена поддержка поиска мест определения различных конструкций и вывода подсказки по значениям параметров;
- Реализован пакет pas2jsdsgn (http://wiki.lazarus.freepascal.org/lazarus_pas2js_integration) для создания web-приложений путём трансляции кода Pascal в представление на JavaScript с использованием Node.js;
- Добавлено меню для скрытия пиктограмм компонентов, таких как TOpenDialog. Добавлена опция для показа не отображаемых компонентов;
- Переработан интерфейс для публикации проекта и формирования пакетов;
- Улучшен интерфейс для создания новых компонентов;
- В редактор добавлена команда "smart move cursor" для быстрого перемещения курсора между словами (по началу или концу слов). В панель добавлено подменю для перехода по закладкам;
- Представлен новый экспериментальный отладчик на базе LLDB от проекта LLVM. Расширены возможности штатного отладчика на базе GDB;- Реализованы опции для отключения поддержки различных графических форматов с целью уменьшения размера приложения (-dDisableLCLGIF,
-dDisableLCLJPEG, -dDisableLCLPNM, -dDisableLCLTIFF).URL: http://forum.lazarus-ide.org/index.php?topic=44161
Новость: https://www.opennet.ru/opennews/art.shtml?num=50097
Оно живо?
Увы, как видите.
А в чем недовольство? Оно работает, даже приложение можно написать, а не довольствоваться "в консоли можно" и "голодрано, зато в вебе"... Альтернатива Java и C#, но они со сборкой и с зависимостями. Qt... Ну стоимость C++ со скилом Qt такова, что уж лучше на Java или C# с моно, хотя бы найти потом на поддержку можно будет кого-то...
Да ладно вам. Pascal/Дульфи давно уже умерли, даже студенты на них ничего не пишут.
Ну раз Embarcadero ещё не обанкротилось, с его-то прайсом (причаститься тут http://store.embarcadero.ru/),качеством и маркетингом, и FPC/Lazarus кто-то пилит (судя по Git-зеркалам https://github.com/graemeg/freepascal/commits/master и https://github.com/graemeg/lazarus/commits/upstream довольно бодро), значит всё-таки кто-то пишет.
А вот серьёзно: что такое есть из мейнстрима, чтобы "натыкать" GUI, собрать, и оно нативно (т.е. не Electron, не Java и тд) работало, без перепиливаний и выноса мозга со сборкой dependencies?
Лазарь, конечно штука свеобразная, но, в принципе, почему бы и нет.ЗЫ. Отладчик, правда, ужасный.
Qt?
> Qt?Не, руками-то оно понятно. В лазаре тоже можно всё руками писать. Среда, она же RAD IDE, по возможностям хотя бы похожая существует? Я такой не знаю. Возможно только я не знаю.
Плюс Лазарь удобен чем: собрал под linux - собрал с GTK/Qt, собрал под Windows - родной WinAPI, собрал под Mac - родной Cocoa. Они как-минимум стараются делать свой LCL максимально нативным под каждую таргет-платформу, а не мимикрию в стиле Qt.ЗЫ. Lazarus умеет использовать Qt, как виджет-сет. Хоть Qt4, хоть Qt5.
https://en.wikipedia.org/wiki/Qt_Creator разве не достаточно? Возможности портирования приложения на win, linux, macos, android, ios - разве мало? Да, Embarcadero RAD который "делфи" сейчас тоже умеет на андроид и ios портироваться, но видели бы вы какое вырвиглазное непотребство там получается. Я уже молчу про код который оно генерит - забудьте все что вы знали про оптимизацию и придумайте самую невероятную пакость, и все равно такого как у них не получится выдумать
> https://en.wikipedia.org/wiki/Qt_Creator разве не достаточно? Возможности портирования
> приложения на win, linux, macos, android, ios - разве мало? Да,
> Embarcadero RAD который "делфи" сейчас тоже умеет на андроид и ios
> портироваться, но видели бы вы какое вырвиглазное непотребство там получается. Я
> уже молчу про код который оно генерит - забудьте все что
> вы знали про оптимизацию и придумайте самую невероятную пакость, и все
> равно такого как у них не получится выдуматьНу дак и Qt и Qt_Creator умеет на андройд! Я запускал свою самоделку на телефоне. Правда тоже вырвиглазно получилось :)))
в Qt есть такая богата копмонентная база как в Delphi, как визуальная так и не визуальная? Те же grid'ы для отображения данных из БД, да и компонентов для работы с СУБД гораздо больше, чем в Qt. Для примера, если нужно написать приложение для анализа .apk (так, на вскидку), нужно несколько компонентов: распаковщик архивов, парсер XML, компонент для отображения данных - grid, tree-view, если хотите, записать это в базу. В Delphi это делается с использованием компонентов, предоставляемых из коробки. Делая это в Qt вам придется искать исходники архиватора, парсера xml (ладно, он есть там), а работу с FireBird, например нужно еще попотеть обеспечить, плюс grid - писать свой адаптер, потом мучиться все это скомпилировать, выискивая недостающие includ'ы....
> а работу с FireBirdну толсто же :)))
http://doc.qt.io/qt-5/sql-driver.html#qibase-for-borland-int...
Да-да-да. InterBase который уже далеко не FireBase, особенно с версии FireBase 3.x. Упоминание qmake особенно напрягает.
Он FireBird FireBase это другое.
В Qt нет быстрых gridview-ов уровня тех что были в delphi 7 и выше, может за пару последних лет что-то появилось(не смотрел), оно может быть написано правильно, но работать с большими гридами очень тяжко (и много-много памяти).
> а работу с FireBirdА чё не paradox?
Собственно, почему бы и нет, ведь с sqlite мне и предлагают альтернативу в Qt.
Потому-что серверная БД, которая удобна для решений используемых небольшими компаниями, при этом может одновременно работать как встореная ( не нужно пользоваться двумя сразу ), умеет транзакции тригеры хранимки при этом не требует столько внимания как PG и опять таки единый синтаксис для встроенной и серверной(унификация кода/разработчиков).
ну пользуй свой интербейзкакое-то нытье на пустом месте...
http://doc.qt.io/qt-5/sql-driver.html
The table below lists the drivers included with Qt:
Driver name DBMS
QDB2 IBM DB2 (version 7.1 and above)
QIBASE Borland InterBase
QMYSQL MySQL
QOCI Oracle Call Interface Driver
QODBC Open Database Connectivity (ODBC) - Microsoft SQL Server and other ODBC-compliant databases
QPSQL PostgreSQL (versions 7.3 and above)
QSQLITE2 SQLite version 2
QSQLITE SQLite version 3
QTDS Sybase Adaptive Server
в Qt есть такая богата копмонентная база как в Delphi, как визуальная так и не визуальная? Те же grid'ы для отображения данных из БД, да и компонентов для работы с СУБД гораздо больше, чем в Qt. Для примера, если нужно написать приложение для анализа .apk (так, на вскидку), нужно несколько компонентов: распаковщик архивов, парсер XML, компонент для отображения данных - grid, tree-view, если хотите, записать это в базу. В Delphi это делается с использованием компонентов, предоставляемых из коробки. Делая это в Qt вам придется искать исходники архиватора, парсера xml (ладно, он есть там), а работу с FireBird, например нужно еще попотеть обеспечить, плюс grid - писать свой адаптер, потом мучиться все это скомпилировать, выискивая недостающие includ'ы....
Вы лукавите и притягиваете себе странные инструменты в оправдание. Зачем вы взяли тут странный Firebird? Хочется в приложении иметь для себя базу - возьмите более логичный тут sqlite. И сразу все встанет на свои места: в (не поддерживаемом уже) Delphi либо Lazarus вам придется искать какие-то левые приблуды типа LiteDAC, попотеть с интеграцией всего этого, потом мучаться все скомпилировать и тп. А в Qt - все реально полезные на практике SQL модули из коробки (http://doc.qt.io/qt-5/sql-driver.html), подключаетесь с адаптером QSQLITE и вперед.(а проблему с архиватором вообще не понял. Первой же ссылкой в гугле предлагают готовую либу http://quazip.sourceforge.net/ - но это вы опять ведь специально .zip файл взяли. А вы возьмите чуть более современный 7z, и тут выяснится, что в delphi вам придется тащить в проект уж точно непойми что)
Между прочим, насколько я помню из Delphi вы даже к тому же ораклу просто так не подключитесь, либо придется покупать коммерческий коннектор непонятно какого качества, либо придется лезть через мерзкий ODBC, лишившись при этом всех полезных фич типа объектов, вложенных курсоров и прочего. Впрочем, может сейчас что-то изменилось, давно с этим сталкивался.
> тут странный Firebird? Хочется в приложении иметь для себя базу -
> возьмите более логичный тут sqlite. И сразу все встанет на свои
> места: в (не поддерживаемом уже) Delphi либо Lazarus вам придется искать
> какие-то левые приблуды типа LiteDAC, попотеть с интеграцией всего этого,Чо за бред?
В (не)поддерживаемомо Дельфи... (...ть, почему неподдерживаемом? то, что у тя не хватило его удержать, не делает его неподдерживаемым...) давно есть firedac "искаропки", цепляй библиотеки и хошь sqlite, хошь мускул, хошь постгрес тебе, хошь черт в ступе. В лазарусе все это было доступно еще раньше, чем в делфи...> А вы возьмите чуть более современный 7z, и тут выяснится, что в delphi
> вам придется тащить в проект уж точно непойми что)Вот отсюда и растут ноги у "браузеров" и "текстпроцесоров", которые читают вслух и бегают за пивом, а вот серфить и работать с текстами нормально не могут, потомучто все силы афтара ушли на рюшечки и встроенные архиваторы, а createprocess осилить - не, это неспортивно...
> Между прочим, насколько я помню из Delphi вы даже к тому же
> ораклу просто так не подключитесь, либо придется покупать коммерческий коннекторДа, придется покупать коннектор.
Видимо, придется купить при этом еще и Оракл, и окружение, которое его потянет, но самая серьезная проблема в данной ситуации - это, конечно, необходимость покупать коннектор...
Причём непонятно зачем таки покупать, есть же куча вариантов (законных).
Какие законные варианты без покупать ?ты без "покупать" даже саму свою делфю законно не сможешь использовать на предприятии
были когда-то турбо-продукты корявенькие, но бесплатные, дак они юзеров посте перепродажи тупо кинули как и тех кто дома использовал домашние делфи 6/7...
Я, конечно, всё понимаю, но зачем в QT поддержка Sqlite? И если она есть, то есть ли поддержка MSSQL и постгреса?Разве он не должен просто окошки рисовать?
И всё это в условиях, когда почти для любого языка есть pip, npm, nuget, cargo.
> Я, конечно, всё понимаю, но зачем в QT поддержка Sqlite? И если
> она есть, то есть ли поддержка MSSQL и постгреса?Я выше дал ссылку, там полный список. Есть даже оракл.
> Разве он не должен просто окошки рисовать?
Создатели Qt решили, что там должно быть все, начиная от работы со строками (QString и все унаследованные классы + функции для работы) и структур данных (обертки над массивами/очередь/стек/словарь и тп) и сетевых взаимодействий (свой API и уровня сокетов, и высокоуровневые взаимодействия по куче протоколов) до XML, SQL и кучи всего. И да, это все можно использовать в отрыве от гуя, библиотеки, предоставляющие это отделены от гуевых и не требуют их.
Хорошо это или плохо - тут можно разные точки зрения иметь. Надо понимать, что когда Qt появился, STL еще толком никто не использовал, шаблонов либо не было, либо они были убогими, с поддержкой юникода в плюсах было плохо и куча других особенностей середины 90'ых. Qt реализовывал обертки над структурами C++ либо свои структуры и давал возможности, которых не было в базовом языке. Qt реально расширял C++ штуками типа сигналов и слотов, которые реализовывались через свой препроцессор (moc), устраняя проблему отсутствия С++ шаблонов в компиляторе. И так далее.
> И всё это в условиях, когда почти для любого языка есть pip,
> npm, nuget, cargo.С современной точки зрения вы правы (впрочем, как можно заметить, ни один из этих инструментов не работает для C++), но 20 лет назад при разработке переносимого тулкита заодно иметь переносимую между платформами и компиляторами реализацию всяких высокоуровневых штук было неплохой идеей. Хотя в первых Qt никаких SQL, конечно, не было, но структуры данных уже были.
Давайте возьмём за сервер PostgreSQL, какая будет разница, gridview к которому легко подключить выборку на 100000 строк не требующий 16Гб оперативки есть? ( и не пишите что "не нужно", если пользователь решает что нужно, то ему нужно предоставить возможность, особенно если ему реально нужно глазами и с фильтрами и править по маскам после просмотра ).
глазами 100000 строк ????ну да, ну да...
это все что надо знать о делфи программистах Ж)))
Давайте не будем судить по одному комментатору о сообществе в целом.
>Между прочим, насколько я помню из Delphi вы даже к тому же ораклу просто так не подключитесь, либо придется покупать коммерческий коннектор непонятно какого качества, либо придется лезть через мерзкий ODBC, лишившись при этом всех полезных фич типа объектов, вложенных курсоров и прочего. Впрочем, может сейчас что-то изменилось, давно с этим сталкивался.http://wiki.freepascal.org/SQLdb_Package
https://sourceforge.net/projects/zeoslib/
В Qt уже есть поддержка, как zip-архивов, так и Firebird - "из коробки". Ничего искать не надо
> уже молчу про код который оно генерит - забудьте все что
> вы знали про оптимизацию и придумайте самую невероятную пакость, и все
> равно такого как у них не получится выдуматьТогда уж молчи и о кодерах, которые пишут говнокод, даже не вспоминая о существовании такого понятия как "оптимизация". Заодно промолчим о настройках компилятора и линковщика - иногда программисты, которые приходят на работу устраиваться, не могут ide запустить, если на десктопе ярлычок отсутствует...
> даже не вспоминая о существовании такого понятия как "оптимизация"Потому что запуганы таким понятием как "предварительная оптимизация". Вообще, разработчики, которые тонко улавливают грань когда нужно начинать оптимизировать не так часто и встречаются
Ха. Зато почти повсеместно встречаются разработчики, которые на вопрос "почему твое творение через 10 секунд после старта сжирает всю оперативу, сколько ее есть?", отвечают с олимпийским спокойствием, что память сейчас дешевая. Правда следующее предложение сменить кресло разработчика с зарплатой штука баксов на стульчик менеджера по продажам за 250$ плюс проценты почему-то вызывает такое свинячье верещание, что KAV обзавидуется...
> через 10 секунд после старта сжирает всю оперативу, сколько ее есть?",Это, конечно, не допустимо.
Когда сложная бизнесс-логика пересекается с оптимизированным кодом - тогда разработка замедляется непредсказуемо. И тут становится плохо всем.
> память сейчас дешевая.
Просто когда вам такое скажут, предложите посмотреть своему собеседнику, сколько стоит ноутбук с 32 гигами памяти на борту.
А что там с кодом, они же llvm переехали?
Тот же вопрос возник
Пилится.
Можно собрать самому уже сейчас, правда не без бубна.
> https://en.wikipedia.org/wiki/Qt_Creator разве не достаточно?Не настолько плотно им пользовался, чтобы авторитетно заявлять.
К примеру, минимально, чтобы не заводить ниже-тред про dbgrid-ы и ассортимент, есть там что-то вроде лазаревских Actions-компонентов? Нет, сигналы-слоты я понимаю, что это тоже самое и можно накрутить. Можно создать аналог ActionList (возможно не один) и от него в один-два клика биндить обработчики к любому нужному компоненту?
Когда я последний раз пробовал QtCreator - это было адски муторно. Может с тех пор что поменялось, я честно не в курсе.
> приложения на win, linux, macos, android, ios - разве мало?Не мало, но это опять же не нативные контролы, а qt-мимикрия, которая не всегда хороша. Как минимум под последние три получается не очень хорошо, дипломатично выражаясь. Плюс, как уже отмечали в треде тащить/собирать за собой рантайм.
Плюс, не самый важный вопрос, но помятуя о недавних сра^W диспутах здесь с любителями древностей, лазарь, даже свежий 2.0, до сих пор собирает кодобазу и работает как под всякие мхом поросшие WinXP и прочие древности, так и под свежим Win10/Mac/Linux. В то время как Qt-toolchain - по большей части только мейнстрим.> Embarcadero RAD
Ну, скажем так, качество никогда не было сильной стороной Embarcadero. К лазарю/fpc оно, впрочем, имеет отношения ровно никакого, кроме собственно Паскаля. Наоборот, к примеру ЕМНИП в FPC пришлось переделывать поддержку дженериков (да они есть и лямбды есть и почти всё современное есть) собственной реализации, которая уже давно была, и делать совместимость Embarcadero, которая наворотила сильно позже и по-своему.
Оффтоп: Если почитать History UniLink-а (ftp://ftp.styx.cabel.net/pub/UniLink) можно проследить, как его автор "любит" продукцию Borland/Embarcadero за её "качество".
В qt мимикрия на очень высоком уровне. Там минимальные отличия от нативного тулкита, большинство и не заметит. qt под в качестве rad подходит на все 100%. Единственное "но" - размер дистрибутива, в который надо включить рантайм, но 30 мегабайт туда, 30 сюда, сейчас таким уже не парятся.А то что LCL стараются сделать нативным - так себе преимущество, шаг в лево от того, что позволяет сделать нативный тулкит - и уже получится хрен знает что, заморочки под конкретный тулкит, и тд и тп.
30 мегабайт туда-сюда? Спасибо, я лучше на Delphi.
Ну уж нет, С++ православнее!
30 мегабайт сейчас в интернете любай страничка с котиками весит.когда свою делфи-поделку на линуксе или фре запустишь без бубна и без вайна и когда делфя будет бесплатна - тогда и поговорим о 30 мегабайтах
> ЗЫ. Lazarus умеет использовать Qt, как виджет-сет. Хоть Qt4, хоть Qt5.Посмотрел:
% pkg search lazarus
lazarus-gtk2-1.8.4_1 Portable Delphi-like IDE for the FreePascal compiler (GTK2)
lazarus-qt4-1.8.4_1 Portable Delphi-like IDE for the FreePascal compiler (QT4)
lazarus-qt5-1.8.4_2 Portable Delphi-like IDE for the FreePascal compiler (QT5)
прикольно. Если бы еще первый релиз был лет на 6-7 раньше ...
> прикольно. Если бы еще первый релиз был лет на 6-7 раньше ...Ну бета в 2009 уже была (а LCL — вообще давно начали), но, похоже, пока был более-менее жив Borland Kylix стимула выводить альтернативу из беты было куда меньше. А когда Kylix не стало — вот тогда Лазарь воскрес и воспрял.
>> прикольно. Если бы еще первый релиз был лет на 6-7 раньше ...
> Ну бета в 2009 уже была (а LCL — вообще давно начали),
> но, похоже, пока был более-менее жив Borland Kylix стимула выводитьKylix кстати вроде тоже с вайна так и не портировали, забросив.
И начать-то начали, но сначала оно дельфям не конкурентом было, а когда стало, оказалось уже и потихоньку почти невостребованным, потому что после перепокупок кодожиром и (в конце) эмбаркадерой и всяческих метаний с дельфей стали сползать везде, где можно. На VB.NET, C# и прочее - гуй там, если я не путаю ничего, тоже можно было накликать только в путь.
> На VB.NET, C# и прочее - гуй
> там, если я не путаю ничего, тоже можно было накликать только
> в путь.С учётом того, что разрабатывал это тот же Андерс Хейлсберг, что и Delphi в его золотые времена, большинство дельфистов перешло на шарп безболезнено (сужу, правда, теоретически, сам чуть раньше ущёл на C++/Qt, ещё даже последние недели Qt3 застал).
И да, сигнал-слоты, конечно — не ActionList, но лично я никакой боли при переходе не испытал. Тем более, что до того знакомился с наработками некоего Delphi программиста, который переизобрёл сигна-слотовую систему. Причём, кажется, именно в том, слаботипизированном виде, в котором это присутствует в Qt < 5 (он правда это почему-то функциональным программированием называл)
Qt !!!
> Qt !!!Выше ответил комментатору.
wxWidget. IDE Borland напоминает.
wxWidgets. И напоминает оно не Borland IDE, конечно, а MFC / VCL, с которых и писалось.
В остальном именно так, как мечтает вышеписавший: без лишней тяжести, нативные контролы, кой-какие редакторы для того, чтобы это добро намышевозить, если не умеешь ручками...
> wxWidgets. И напоминает оно не Borland IDE, конечно, а MFC / VCL,
> с которых и писалось.
> В остальном именно так, как мечтает вышеписавший: без лишней тяжести, нативные контролы,
> кой-какие редакторы для того, чтобы это добро намышевозить, если не умеешь
> ручками......и даже без совместимости по ABI между минорными версиями, всё как у больших. ))
gtk + glade + rust + relm
Давно хочу правилку табличек в бд со своими правилами, проблема в том что там 100+ тыс. строк люди фильтруют/правят в т.ч. массово, в кнопко-формочном(когда правка записей по одной или по заранее определённому алгоритму) никак не реализуемо за вменяемые сроки, сейчас используется вариант DB->Excel->Db и текущими инструментами что-то как-то всё не хочет адекватно работать ( нет gridvew умеющих с более-менее адекватными трудозатратами работать с кучей данных не сжирая по несколько Гб оперативки)
Тоже в свое время на него смотрел, пока не увидел CodeTyphon.
Тот же Лазарь, только доработанный и часто обновляющийся.
Самособирающийся и мультиплатформный из коробки с самосборкой всех прекомпилиров если надо.
https://www.pilotlogic.com/sitejoom/
Это тот, который в русский Wiki Lazarus по кросскомпиляции вписали, удалив оригинальную инструкцию? Вы меня извините, но за одно это бежать нужно от таких "проектов".
> Тоже в свое время на него смотрел, пока не увидел CodeTyphon.
> Тот же Лазарь, только доработанный и часто обновляющийся.Это не Лазарь доработанный, это master-trunk snapshot лазаря, на который положены не ревьювеные и не принятые патчи из багтрекера, и натащены до кучи все более-менее популярные пакеты.
Стабильность от всего этого кое как склееного мягко говоря удручающая.Особенно после запиливания в 2.0 менеджера пакетов, так что можно все популярные пакеты ставить из репы "в один клик", нужность CT остаётся под большим вопросом.
Живо, и быстрее многих хипстерских языков.
быстрее в чем? - время написания, время исполнения, время компиляции?
В основе идеологии паскаля с самого начала было заложено быстрое время компиляции и за счет этого быстрое время написания и отладки программ на слабых машинах, что было очень нужно и полезно 30-40 лет назад, но извините сейчас совешенно не актуально.
По сабжу: да, freepascal очень даже толковый проект для поддержки легаси и академического кода, в том числе и на делфи конечно, да и поиграться на тему расширения кругозора тоже не повредит, так что радует что там хоть что-то шевелится. Но пожалуйста, не надо его кому-то для реальных новых проектов советовать.
>Но пожалуйста, не надо его кому-то для реальных новых проектов советовать.Абаснуй?! Я на Дельфях под Винду приличные приложения пишу. Жалоб нет.
жалобы появятся у тех кому ваши приложения поддерживать придется. А также портировать, тестировать и оптимировать.
Лазарус, вообще-то, прост, как топор, что с дельфей пошло ещё. Не чета кутям тем же. Ну и если хоть что-то на дельфях делал (а делали очень многие, в постсовке - тем более) - вообще проблем никаких.Портировать - разве что на какую-то адскую экзотику? Потому что на всех трёх основных ос оно просто работает. Оптимизировать? Уж хуже питона/php/js не будет, а для performance critical оно и не предназначено.
Вот как раз если "хоть что-то", то проблем никаких, а вот дельфисты что-то не шибко переходят - там они к своим проприетарным сторонним компонентам приросли и нитуды и нисюды...
это да, анекдотов на эту тему хватало. Но тем не менее есть куча народу, умеющего дельфи и паскаль. И лазарус - как следствие
Да LLVM там в качестве компилятора, что он такой ужасный? Что вы всё какие-то байки из прошлого тянете?
Поддерживать C++, Rust или (не дай.. ) js легче?
Тулкита для компиляции, да не важно.
Чёё, FreePascal на LLVM? Чур меня, чур меня, чур меня...
http://wiki.freepascal.org/LLVM - он тан не есть, его там можно опционально включить (не самый свежий), и там же подробно и совершенно в согласии с их идеологией написанно почему это можно и не делать
Быстрое время написания тоже сейчас важно. Человеко часы и бизнес делают своё дело. Иначе писали бы на ассемблере.
Скорость исполнения: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
>В основе идеологии паскаля с самого начала было заложеноНа самом деле нет - в основе идеологии легкая анализируемость кода. Вау эффект связанный с быстрой компиляцией это побочное. Основное - при сопровождении намного легче понимать что написано и зачем (хотя и не идеал). За эту свою академичность и нелюбим профами на западе.
> быстрое время компиляции <...> извините сейчас совешенно не актуально.Ты большие проекты когда-нибудь видел? Попробуй для примера собрать Андроид из сорцов, потом поговорим о неактуальности быстрой компиляции.
почти делфи :)
>> Реализован пакет pas2jsdsgn для создания web-приложений путём трансляции кода Pascal в представление на JavaScript с использованием Node.js;"Это кого-то попросили сделать!"
Эмбаркадеро Делфи до сих пор не умеет в 64-бита. ФриПаскаль умеет в 64 бита? Почему компиляторы Паскаль не умеют в 64 бита?
Умеет FreePascal без Лазаруса в 64 бита, только его качать отдельно от 32-битного надо
им идеология паскаля не позволяет пользоваться сишными компиляторами вроде llvm или gcc, они вынуждены все сами писать, а поскольку занимаются там этим полтора человека, то и результат такой. freepascal хоть что-то пытается заимствовать, были у них обсуждения в ленте, а в Embarcadero вообще забили на это.
Freepascal имеет 64-битный вариант, в чём дело? Лазарус это лишь поверх того среда разработки и набор классов.
Вон лежит примитивный 64-битный линуксовый экзешник, набросанный в Лазарусе поверх одного из базовых классов с GUI.
> линуксовый экзешник))))))
>> линуксовый экзешник
> ))))))эКЗекьютебл бит сет (+x). Ну?
> Эмбаркадеро Делфи до сих пор не умеет в 64-бита. ФриПаскаль умеет в
> 64 бита? Почему компиляторы Паскаль не умеют в 64 бита?новость 2011 года
http://blog.synopse.info/post/2011/12/04/Total-Commander-64-...
Ну хватит уже... не смешно даже... Всё он умеет.
What's New in Delphi and C++Builder XE2Go Up to What's New
This release provides key new features for developing applications using both Delphi and C++Builder.
Summary of the XE2 ReleaseKey features of the XE2 release are:
FireMonkey Application Platform for cross-platform applications that run on Windows (both 32- and 64-bit), Mac OS X, and iOS.
VCL supports 64-bit Windows and 32-bit Windows
The Delphi RTL now supports Mac OS X and both 32-bit and 64-bit Windows
Cross-platform application development
Mac OS X Application Development
Two cross compilers for Mac OS X:
Delphi (DCCOSX.EXE, the Delphi Cross Compiler for OS X)
C++ (BCCOSX, the C++ Cross Compiler for OS X)
64-bit Windows Cross-Platform Application Development (for Delphi only)
Delphi 64-bit cross compiler (DCC64.EXE, the Delphi 64-bit Command Line Compiler)
> Delphi 64-bit cross compiler (DCC64.EXE, the Delphi 64-bit Command Line Compiler)Ты про команд-лайн компилер? А скажи почему в вкладке создать новый проект VCL нету 64-бита. Там только 32-бита фигурируют. Согласись ЭмбаркадероДельфийцы не осилили 64-бита до конца.
Потому что обычный делфи проект компиляется без проблем и под 32 и под 64 бита - не?))
Оно морально и физически устарело.
Ну да, но такие вещи как sh-скрипты и make-файлы физически и морально устарели на порядок больше. И тем ни менее ими приходится пользоваться.
А Лазарус - я никогда им не пользовался, но паскаль мой первый язык, и хотя си-подобные языки мне нравятся куда больше, все-же из ностальгических соображений приятно что проект развивается.
В чем конкретно заключается устаревание? Просто не модно или существуют какие-то принципиально новые подходы, которые сделали это систему неактуальной?И говоря об устаревании, Смолток, например, до сих пор во многом лучше и продуктивнее современных языков и сред, хотя графические интерфейсы и интегрированные среды разработки с него начинались. И с тех пор ничего принципиально нового не появилось, только компромиссы в погоне за популярностью.
> В чем конкретно заключается устаревание? Просто не модно или существуют какие-то принципиально
> новые подходы, которые сделали это систему неактуальной?На любое количество вопросов этого рода получается (в вечном цикле) ответ "мы просто знаем, что паскаль устарел". Как устарел? Устарел. Откуда известно? Все знают. И начинай сначала.
Не исключаю даже, что сей коллега просто дразнится -- мол паскаль устарел "физически (!)и морально". Не те уже биты в стандарте, ох, не те. Нет прежней крепости.
паскаль устарел в тот момент когда Борланд решил вместо более-менее универсального TP развивать заточенный под один юзкейс дельфи. Да, дельфи первый зянял свою нишу, но очень скоро в нее влез M$ со своим VB и потом C#, сан влез со своей явой, и пошло-поехало. Еще паскаль устарел потому что Вирт со своей цюрихской университетской тусовкой не просекли идею опенсорса и остались на моделях разработки и распространения софта из прошлого века, а весь мир поехал дальше. Также как например моментально устарел их-же Eiffel, которого тоже очень жалко, столько труда на ветер. И поэтому на сегодняшний день для проекта на паскале иле эйфеле вам будет очень сложно организовать и поддерживать комьюнити из адекватных разработчиков и тестеров, на дельфи тем более, люди просто не захотят тратить время и охотнее займутся той-же Lua, там хоть больше перспектив что проект будет жить и развиваться.
Что еще грустно: паскаль на самом деле очень хорошо мог бы вписаться в embedded разработку, и в конце девяностых - начале двухтысячных там произходил активный переход от ассемблера к си и вообще активное развитие новых инструментов. У Борланда был шанс заняться этой темой и оказаться там раньше многих. Но они свой шанс прохлопали.
> паскаль устарел в тот момент когда Борланд решил вместо более-менее универсального TP
> развивать заточенный под один юзкейс дельфи.Да Дельфи-то как таковой ИМХО вполне ничего. Нормально развивался.
Проблема и основной провал, соглашусь с Вами - это Borland. После эпического успеха Delphi7 их понесло не развивать успех, а в какие-то недоразумения: то они D8.net выпустят, никому нафиг не нужную, то потом возвращаются на натив, то потом пилят Delphi4PHP (не менее нафиг никому не нужную), среда становится глючной до невозможности. Как результат - банкротятся и продаются мутной CodeGear, которая скатывает среду совсем в хлам и только потом уже после ещё я уже и не помню каких перепродаж приткнувшись к Embarcadero среда начала хоть как-то развиваться: появились x64, платформы, FireMonkey относительно удобоваримый, в самом языке что-то наконец-то осовременивается.
Но время уже давно потеряно (10 лет выпусков трэша, где-то до XE2 ИМХО), аудитория и рынок тоже. Плюс изначально совершенно идиотский маркетинг и оверпрайс, который сейчас вроде как стал получше, но всё-таки.А на онтопике: тут всегда правил бал Си и его развития. Не знал и не знаю таких, кто собирался писать под nix-ы не зная, хотя бы минимально С/С++. Что FPC, что лазарь хоть и сами по себе неплохи (модули приличные, например, мы когда-нибудь в С/плюсах дождёмся? а в pascal - есть by design), но есть постольку-поскольку, а не из-за острой в них надобности.
> Да Дельфи-то как таковой ИМХО вполне ничего. Нормально развивался.
> Проблема и основной провал, соглашусь с Вами - это Borland. После эпического
> успеха Delphi7 их понесло не развивать успех, а в какие-то недоразумения:Наверное всё дело в том что Microsoft Андерса Хейлсберга переманила? И не его одного, Клемента Шиперского, который придумал компонентный паскаль (вариант виртовского оберона) и Black Box Component Builder — тоже.
И да, кто не в курсе, наши ребята BBCB под linux пару-другую лет назад таки портировали. Правда он всё ещё 32-битный, через слой совместимости работает). А ещё я вчера в связи с выпуском Лазаря наткнулся на https://gitlab.com/mseide-msegui/mselang/ Это разработчику MSEgui/MSEide (такая минималистичная альтернатива Лазарусу) FreePascal показался недостаточно хорош (и в чём-то он, кажется, прав), и он пилит поверх LLVM нечто обероноподобное.
спасибо за ссылку, тоже очень интересно. Автор еще там и книгу по программированию написал, в лучших традициях :)
Автор умер 27. Dez 2018, сердечный приступ. Проект остался, последние коммиты 27 ноября.
http://www.lazarusforum.de/viewtopic.php?f=1&t=11923
Кошмар какой.
да кошмар, слов нет просто.
> паскаль устарел в тот момент когдаТочка зрения вроде интересная, но как-то всё в куче, что в пространстве решений, что во времени.
Т.е. до 95-го года (кстати, год я верно назвал по памяти :))) паскаль не устарел, а потом сразу устарел?И виндоуз 95 никак ни на что не повлиял?
И каким здесь боком Вирт?
> Т.е. до 95-го годаесли это решение было принято в 95-ом - то да, именно в тот момент и в согласии с их решением он и устарел, а поскольку других живых паскалей к тому времени уже небыло, то можно говорить про весь паскаль а не только TP. До того времени у него еще был шанс развиваться.
С точки зрения пользователей/разработчиков он устарел чуть позже, в 97-98, когда дельфи набрал популярность. Тот момент я уже хорошо помню, сам тогда активно писал на TP7 dos+windows - вдруг все потянулись этот самый дельфи пробовать и все как-то разделились, кто-то на нем остался а кто-то пошел искать себе другие инструменты. Я тогда еще на какое-то время на оберон подсел, думал выйдет что-то адекватное, но оказалось что оно к тому времени тоже уже умерло.> И виндоуз 95 никак ни на что не повлиял?
а чего бы ему влиять, Борланд от него вроде не зависел
> И каким здесь боком Вирт?
Вирт и его друзья не смогли пересмотреть представления своей молодости о том как разрабатывается софт, как распространяется и как поддерживается. В их время разрабы сидели в прямом контакте рядом в одном помещении, тестировали и отлаживали сравнительно небольшой группой, выпускали в основном мажорные релизы и хорошо если раз в несколько месяцев (бинарники распространяли на материальных носителях и делать корректирующии релизы не могли при всем желании), либы брались в основном от одного поставщика (или из небольшого числа надежных источников), лицензии были само-собой разумеющимся закрытыми и платными, программные решения патентовались, исходники или не публиковали совсем, или наоборот в академической среде выкладывали под честное слово, без юридической защиты, независимыми разработчиками код не анализировался, фидбек на тему багов и новых идей практически не поступал и не ожидался.
Можно понять что в 70-х другого просто небыло, и в 80-х можно было еще тешить себя иллюзией что так было и поэтому будет всегда, но с начала 90-х все начало меняться, масса свободных молодых разработчиков получает доступ в инет и начинает организовываться в крупные распределенные комьюнити по совсем другим правилам, их модель кооперации оказывается более эффективной, а кто не приспособился потихоньку уходит в прошлое, что мы последние 25 лет и наблюдаем. И можно даже понять манагеров M$ которые на голубом глазу делали вид что не замечают этот процесс, у них работа такая, блефовать до последнего. Но вот как понять почему швейцарские профы такой поворот проморгали?
>> Т.е. до 95-го года
> если это решение было принято в 95-ом - то да, именно в
> тот момент и в согласии с их решением он и устарел,
> а поскольку других живых паскалей к тому времени уже небыло, то
> можно говорить про весь паскаль а не только TP. До тогоПонятно. Но выражение неудачное очень. Не устарел, а был вытеснен, и всё-таки не одномоментно, и не потому, что сам (Дельфи) был плох. А потому, что существенно изменилась среда обитания, стала "однополярной". Как это "Вин95 не повлиял на инструментальные средства"? МС-овские студии убили все прочие сишные среды, включая моего любимца зортека/симантека.
Изменились (развиваясь) и рынок ПО, и структура производственных сил :))) Ява и сишарп это всё совсем другая история, на несколько инфо-эпох позднее.И не один же Паскаль. Я знавал (бывшего) программиста на ПЛ/1.
>> И каким здесь боком Вирт?
> Вирт и его друзья не смогли пересмотреть представления своей молодости о том
> как разрабатывается софт, как распространяется и как поддерживается. В их времяЕщё раз -- сколько имплементаций Паскаля сделали Вирт и его друзья? За Оберон ещё можно обижаться, но за Паскаль?
А в опенсорсе, по его происхождению, главенствовал Си.
> Не устарел, а был вытесненна мой взгляд устарел потому что был обьявлен ненужным в угоду более новому продукту. А дельфи был не то что бы плох, просто ниша RAD это совершенно другое отношение к качеству производимого софта и соответственно требования к уровню программистов, если паскаль жил виртовской идеей научить программировать то дельфи как раз предлагал программировать не умея этого делать.
МС-овские студии наверное также как и дельфи не имеют прямого отношения к win95, в том плане что не выйди win95 по каким-то причинам или появись он позже, на их релизы бы это особо не повлияло. Да, win95 заметно разогрел рынок, но не он его создал, запрос и предложения были уже раньше, тот же VB for windows уже был под тройку.
> сколько имплементаций Паскаля сделали Вирт и его друзья
Вирт очень плотно участвовал в создании UCSD паскаля. Основатель Борланда Филипп Кан был его студент, надо думать что контакты там тоже неплохие были.
Дело не в том чтобы обижаться, дело в том что он был идеологом и создал большую школу, на нем и ответственность за то что его ученики под влиянием его авторитета не смогли адаптироваться к новой ситуации.Друья - это например и Бертран Майер с его эйфелем, та же история, слишком долго держались старых моделей разработки и не понимали как заинтересовать людей и организовать комьюнити, так оно и умерло, никому кроме их универа не нужно стало. А ведь просто сказка была бы, раскрути они лет 20 назад эйфель по примеру перла или пайтона.
> МС-овские студии наверное также как и дельфи не имеют прямого отношения к
> win95, в том плане что не выйди win95 по каким-то причинамВыход вин95 придал их студиям совершенно особую значимость. Одна система, одна студия. Затея с бэйсиком вообще хуцпа. Но у них-то всё "выстреливало".
>> сколько имплементаций Паскаля сделали Вирт и его друзья
> Вирт очень плотно участвовал в создании UCSD паскаля.Так это тоже университетское "изделие". Каждый из нас и таких может назвать не одно "проваленное" (на самом деле определение неверно, поскольку НИР успешно завершена, а деньги получены и растрачены :)))).
Сам же Вирт в реальном производстве не замечен, насколько понимаю. Это вот ГНУ-шные парни удивили мир.
> Дело не в том чтобы обижаться, дело в том что он был
> идеологом и создал большую школу, на нем и ответственность за тоНет, решительно не понимаю, что за ответственность такая *особенная* вдруг на нём. Не больше ведь любого другого автора стандарта. Ну, того же Мак-Карти?
> Друья - это например и Бертран Майер с его эйфелем, та же
> история, слишком долго держались старых моделей разработки и не понимали как
> заинтересовать людей и организовать комьюнити, так оно и умерло, никому кроме
> их универа не нужно стало. А ведь просто сказка была бы,А много ли вообще из универов вышло "успешных ЯП"? Питон? Как говоритЦа, name two.
> раскрути они лет 20 назад эйфель по примеру перла или пайтона.
"Раскрути" это значит "сделай что-то коммерчески успешное". 20 лет назад это бы значило одолеть МС на его поле.
> Сам же Вирт в реальном производстве не замечен, насколько понимаю. Это вот
> ГНУ-шные парни удивили мир.Виртовский компьютер Lilith (с вертикальным диспллем и многооконной операционной системой, написанной на Modula-2) как-то немного продавался. Вирт (кажется) с выходом этой штуки (за 5 килобаксов) даже успел раньше Apple Macintosh (но позже Apple Lisa, которая правда все 10 килобаксов стоила). И с ней Вирт в суде между «пиратами силиконовой долины» выступал, как свидетель защиты Гейтса, показав что первую персоналку с многооконной системой на рынок выпустил таки он. Вероятно тогда у победившего в тот раз Билла (к счастью, так как альтернативой было бы право на многооконность только у яблочников) и появилась идея, что нанимать паскалистов — полезно.
А вот сделай Вирт Лилит каким-то чудом года на три раньше (чудом, потому-как все брали идеи у Алана Кея с его смоллток-машинами, что яблочники, что Вирт, что разработчики юниксовых иксов и все шли «ноздря в ноздрю» с финишем в 1984 году) то у паскалеподобных языков и, возможно минималистических оконных менеджеров с командным управлением, ниша была бы побольше. Вероятно сравнимая с нишей Objective C и того, что на этом объектном си обычно пишут.
> А много ли вообще из универов вышло "успешных ЯП"? Питон? Как говоритЦа, name two.
Lua. De facto — стандартный встраиваемый язык в gamedev'е (хотя за его пределами в этом качестве тоже вполне популярен). Католический Университет Рио-де-Жанейро, три доцента писали. Правда у них в заказчиках были нефтянники, но они-то от этого не перестали быть университетскими парнями. Ну и, да, кстати, язык многое перенявший у виртовской Модулы.
UCSD паскаль вроде активно и не дешево продавался, на чем собственно Борланд и вырос - они стали продавать активно но дешево.
Первые виндовсы ( т.е. включая 3.10 и 3.11) имели паскалевский ABI, 95-ый не помню, вроде тоже. Яблочники в те годы тоже активно паскаль продвигали, не бесплатно надо думать.Lua - да, хороший пример, еще common lisp вполне жив и здравствует, еще ocaml во франкоязычной среде довольно популярен. Ну и фортран конечно.
> Первые виндовсы ( т.е. включая 3.10 и 3.11) имели паскалевский ABI, 95-ый
> не помню, вроде тоже. Яблочники в те годы тоже активно паскаль
> продвигали, не бесплатно надо думать.Ubuntu Control Center, который, я так понимаю, в начале 2010 годов использовался (вот никогда убунтой без буквочки k, x или l в начале не пользовался) на лазарусе (в основном) написан.
> UCSD паскаль вроде активно и не дешево продавался, на чем собственно Борланд
> и вырос - они стали продавать активно но дешево....
Думаю, всё же дело в том, что Си (тогда уже достаточно повсеместный) был, что называется, и Паскалем
(и да, был же pascal call и пресловутый bp :)))> Lua - да, хороший пример, еще common lisp вполне жив и здравствует,
Тут где-то уже и lisp закопали. Не говоря о Фортране.
(Кстати, вот случай глянуть - ну да, openmpi 4 сохраняет фортрановский интерфейс, вот дураки-то, им бы пацанов с опеннета слушать).
>> Сам же Вирт в реальном производстве не замечен, насколько понимаю. Это вот
>> ГНУ-шные парни удивили мир.
> Виртовский компьютер Lilith (с вертикальным диспллем и многооконной операционной системой,
> написанной на Modula-2) как-то немного продавался. Вирт (кажется) с выходом этойЕсли верить википедии, времена до-досовские? Читал "Almost perfect" Peterson-а недавно, и мне показалось, мы отсюда слабо представляем себе тамошние реалии той поры.
>> А много ли вообще из универов вышло "успешных ЯП"? Питон? Как говоритЦа, name two.
> Lua. De facto — стандартный встраиваемый язык в gamedev'е (хотя за его...что, и в коммерческих играх?
> времена до-досовские?Нет, первая DOS — 1981. Алан Кей раньше начинал, но он работал на дорогом, совсем не массовом железе.
> ...что, и в коммерческих играх?
Вот прежде всего в них. Началось всё с того что LucasArts заменил на Lua самописанный SCUMM-language в своих квестах. А так — World of Warcraft, Cry ENGINE, S.T.A.L.K.E.R, Serious Engine, Silent Storm (и пятые Герои, использовавшие, в чиле прочих, их движок), Цивилизация, начиная с пятой (в четвёртой был Python и вышло это как-то не очень), Кризис, Дота… https://en.wikipedia.org/wiki/Category:Lua-scripted_video_games — далеко не полный список (и вместе с открытыми проектами), потому как коммерческие игроделы доступ к внутренностям своей игры обычно не открывают. Например Симов в списке нет, только SimCity, а по крайней мере во вторых Симах Lua никуда не делся, см. например http://modthesims.info/archive/index.php?t-90095.html Правда в четвёртых вроде питоном заменили (у меня дочка уже большая и самостоятельная студентка, так что четвёртых Симов не ковырял).
>паскаль на самом деле очень хорошо мог бы вписаться в embedded разработкуТам уже давно была Ада и всякие модулы, из семейства паскаля. Теперь некоторые старые идеи по новому реализует ржавчина.
На самом деле мне, например, жаль, что нет таких свободных "дельфиподобных" сред быстрой разработки именно для Ады и модул и эйфеля - как несколько более совершенных языков. Как минимум, они были бы полезны студентам и разработчикам нативных одноразовых программ (особенно строгая к учащимся Ада - в не новом для себя амплуа "прекрасной и строгой классной дамы с линейкой"). У компонентного паскаля есть потенциал в учебной сфере, но с любыми сердцу студиозусов и школяров, графическими компонентами, там пока ещё не очень.
Устаревание не в прямом смысле "больше не годен", а "не соответствует современности".Ну вот например синтаксис. Он явно устарел. Времена, когда можно было писать 100-строчные программы и этого было достаточно - прошли. Ломать глаза на белиберду begin-end нет никакого желания, "си-шный" синтаксис победил. Писать отдельно "заголовочные модули" - вообще общепринятый маразм, что в Си, что в Паскакале. C# дал людям вменяемый синтаксис и назад пути нет.
Фичи самого языка - увы, я давно уже не слежу за ними, лишь предположу, чего там скорее всего нет: partial classes, mixins, pattern matching, lambdas, multiple return values, String interpolation, ну и синтаксический сахарок всякий, СИЛЬНО упрощающий чтение кода. Язык, который конвульсирует на обочине мэйнстрима ещё долго не получит должного развития, так что он даже будучи "живым", мёртв как никогда.
Смоллток - красив только в концепции, на практике этот маразм не применим. Как и Лисп.
> Ну вот например синтаксис. Он явно устарел. Времена, когда можно было писать...
> синтаксический сахарокЕщё короче, Паскаль это не Сишарп?
Ура! Ждём обновление Free Pascal Compiler'а!
Кто знает, почему я сколько не боролся, не смог запустить его на сентос 7? Вроде не вконец криворукий, а поди ж ты! Кто-нибудь смог?
на бубунте работает без плясок с бубном
телепаты в отпуске
Это понятно. А адекваты?
Всё работает.
strace в помощь.
Скорее всего, проблема из-за требования прав root (или +s, что почти то же самое)
Работает и Сент, и на Федоре, и на всем остальном.
"Живи долго и процветай"
Сам по себе, чтобы проЦветал не получится. Надо слегка вскопать, посадить, наконец оградку вокруг привести в порядок, чтобы навещающие Кобол не затоптали. Хотя, впрочем, пожелание "живи" тоже больше похоже на черную издевку...
Молодцы! Расцеловал и побежал ставить.
Раз оно существует - кому-то это да надо. Успехов!
Для старпёров сойдёт, а для молодёжи нужно IDE на Rust'е, но его нету.
У вас 4 ошибки в слове rust: правильно писать D. :)
> У вас 4 ошибки в слове rust: правильно писать D. :)Боюсь те, кто значает что такое язык D — молодёжью уже не называются. Хотя что-то в стиле Lazarus'а или Qt Creator для D могло бы добавить этому языку популярности. Совсем начинающим можно б было говорить, что это такой диалект C# с понижеными требованиями к железу. :D
IDE для Rust уже есть - плагин Rust для IntelliJ IDEA. Работает далеко не идеально, но лучше, чем ничего или плагин для VSCode (которую только с натяжкой можно назвать IDE). Что касается гуя, в Rust'е нету ничего, и проблема актуальна, но ни разу не фатальна.
Долгих лет процветания сему набору. Хоть и не пользуясь давно.
Мне вот не хватает в ней однооконного режима. Почему-то на винде он есть,а в линуксе - нет...
> Мне вот не хватает в ней однооконного режима. Почему-то на винде он
> есть,а в линуксе - нет...Так делается же. Не через настройку, а модуль какой-то надо ставить, но делается (сам проверял). Не помню, где это (мне оно не нужно), может, на лазарус-вики.
> Мне вот не хватает в ней однооконного режима. Почему-то на винде он
> есть,а в линуксе - нет...Пакет AnchorDockingDsgn из поставки включить надо (https://imgur.com/dWeDwV4)
Даже странно, почему docking (как лучший стандарт де-факто) ещё должен отдельно включаться. Ностальгия - ностальгией, но в 21 веке думать надо на порядок ширше.
> Даже странно, почему docking (как лучший стандарт де-факто) ещё должен отдельно включатьсяВозможно потому, что не с каждым виджетсетом конкретной платформы оно работает. А IDE должно загрузиться "при любой погоде". Докинга может и не быть, но окна-то как-минимум должны быть везде.
> Даже странно, почему docking (как лучший стандарт де-факто) ещё должен отдельно включаться.
> Ностальгия - ностальгией, но в 21 веке думать надо на порядок
> ширше.Однако экран может оказаться не ширше замысла. Или, скажем, не на весь экран -- можно?
Посмотрел я на Lazarus, а то после того я пересел с Delphi на BC++B, а потом на Qt и, постепенно, окончательно на Linux я на паскале как-то и почти не писал ничего. Но всегда знал, что открытый аналог дельфей есть. Впечатления — смешанные. Многое понравилось. Вот как включать докирование окошек нашёл быстро и без чтения документации (просто просмотрел что там в /usr/share/lazarus/components/ мой slackbuild сложил). В живущей у меня дефолтной XFCE, правда, заголовки доков выглядят как привет из 1990, но ладно, к этому можно или привыкнуть, ну или со временем как-то подрихтовать. Можно даже понять, что подключение этой штуки требует перекомпиляции среды. Но вот почему подключение банального набора SQL-ных датасетов (пакет SQLDBLaz), да и _вообще_ любого пакета тоже требует перекомпиляции? Которая, скажем так, далеко несупербыстрая. Есть подозрение, что веселухи в этот процесс добавляет то, что линуксовый ld пытается проинтерпретировать код dfm-ок, в смысле lfm-ок и начинает несколько тупить. Это как-то вообще лечится?
> В живущей у меня дефолтной XFCE, правда, заголовки доков выглядят как привет из 1990Оно вроде как настраивается вот тут (https://imgur.com/IRXmObf). RightClick по линии дока.
> Но вот почему подключение банального набора SQL-ных датасетов (пакет SQLDBLaz), да и _вообще_ любого пакета тоже требует перекомпиляции?Как пишут тут (http://wiki.freepascal.org/Lazarus_Packages#What_is_a_Lazaru...), FPC пока не поддерживает динамические пакеты, только статические. Следовательно надо всю IDE пересобирать, т.к. динамичской загрузки хидеров пока тоже нет, но что-то в этом направлении вроде как делают http://wiki.freepascal.org/Dynamically_loading_headers
Спасибо, со стилем заголовков доков или полным их отключением всё оказалоь элементарно. Что там с динамической подгрузкой компонент пилят — полюбопытствую. А насчёт ускорения линковки кто-то работает?
> ускорения линковки кто-то работает?Вот это, честно говоря, не интересовался, но можно на форуме FPC или в irc спросить.
хмм, а правда на fpc можно в кросскомпиляцию под Cortex M0?
под андроид/32 компилил консольную прокраму из Linux/х64.
Правда, использовал CodeTyphon. Он при установке все кроскомпилеры/IDE/модули нужные вам накомпилит и все будет работать...
M0 это совсем не андроид, это помельче. Судя по их вики на сам кор можете fpc легко собрать, но для конкретного контроллера нужен будет рантайм и скрипты линкера, так что скорее всего придется попотеть и портировать из сишного тулчейна
Да, Это Arduino Zero и вся розетка MKR. Ок, короче, только отдельные функции
нет, скорее всего вы сможете с ним нормально работать, но не сразу, нужно будет адаптировать под контроллер. Рантаим контролелру для чего нужен: он инициализирует стек, обнуляет ram и инициализирует ее дефолтами из bss сегмента, больше от него никакой магии не требуется. В принципе 30-40 строк кода, но нужно понимать как оно работает.
не скажу за М0, а для raspberri pi можно
http://wiki.freepascal.org/Ultibo_core
Все на DevelStudio фигачу, внучек дельфей.
Краткое введение в современный Object Pascal для программистов
https://castle-engine.io/modern_pascal_introduction_russian....Modern Object Pascal Introduction for Programmers
https://castle-engine.io/modern_pascal_introduction.html
> Краткое введение в современный Object Pascal для программистов
> https://castle-engine.io/modern_pascal_introduction_russian....ну а кто игроделинм интересуется, может на сам castle-engine посмотреть.
> Краткое введение в современный Object Pascal для программистов
> https://castle-engine.io/modern_pascal_introduction_russian....
> Modern Object Pascal Introduction for Programmers
> https://castle-engine.io/modern_pascal_introduction.htmlСпасибо, интересно, особенно в части Object. Но:
*беглейше* глянул -- и, как и ожидал в русском переводе, обнаружил, что 1) добавлен юмор (как бы ни к чему). 2) термины переведены небрежно / неточно.Пример для 1) разделы 9.1 и 9.4, заглавия. Пример для 2) раздел 9.2, введение (перевод "CORBA" vs "bare" и, далее, "чистая особенность языка" vs "особенность чистого языка").
Есть еще вполне неплохой перевод официальной документации:https://drive.google.com/drive/folders/0By1Ihlfr9cFlLUdtMFhl...
http://fpc-doc-ru.1gb.ru/
Ух... Как же он меня в своё время выручил. Надо было под Linux простенькую вещь сделать, а я в Linux не особо шарил (особенно в их традиционных методах программирования). Lazarus - стал для меня спасением. Интуитивно понятная, не требующая дополнительного изучения, кроссплатформенная. Что ещё нужно? Иметь одну среду разработки, один язык с единым набором компонентов для разных систем - это просто счастье программиста! Раз изучил и пиши хоть под Linux, хоть под Windows. Люди голову ломают, решая проблему портирования проекта под другую ОС, а тут всё для тебя из "коробки" завезли.
> Люди голову ломают, решая проблему портирования проекта под другую ОС,
> а тут всё для тебя из "коробки" завезли....на x86; см., например, https://bugzilla.altlinux.org/36023