Lazarus 2.2

но есть нюансы :о) тыць

fppkg? Это не связано с qt4

окно настроек IDE-Lazarus (это связано с лазарем :о)

Время сборки пустого проекта

сложилось ощущение, что во время сборки проекта «принудительно» пересобирается «вся библиотека» паскаля/лазаря

ВОПРОС: я что-то путаю? раньше пустой проект собирался мгновенно, не успевал «отпустить шоткат» а пустая форму уже запускалась. что произошло?!

спасибо

p.s. в догонку: пока то да-се, пересобирал лазаря с разными версиями qt, прочими настрйоками, патчами итд ... короче, теперь собирает нормально, а до этого молотил, реально всю свою библиотеку пересобирал, секунд на 10-15 сборка растягивалась

Имя функции это не мусор, тем более если она реализует полезный алгоритм. Это не то-же самое, что глобальная переменная. Вы опасаетесь совпадения имён ? Для этого существует специальный механизм, называется namespace, пользуйтесь им. Но если для вас это действительно проблема, можете реализовать свою функцию как функтор (т.е. обьект со своим оператором скобочек), или воспользоваться лямбда-функцией (что хуже, если эта лямбда слишком сложная). В любом случае это будет более читаемо, чем функция, раздутая вложенными функциями. Поверьте, мне приходилось переписывать delphi-код на C# и C++. Так вот функции со множеством вложенных функции (да ещё если они достаточно нетривиальны) - это порой ад и израиль для понимания из-за их тесной взаимозависимости и необозримости кода. Такая возможность - это поощрение плохой практики программирования.

удобство разработки вещь сугубо материальная, когда за неё платят деньги. Или если это измерять временем из вашей жизни, что намного дороже :)

https://github.com/Fr0sT-Brutal/awesome-pascal

Если мне надо просто собрать кутешную программу из исходников (не статикой), мне Qt Creator не нужен. Мне достаточно поставить несколько пакетов из репы моего дистрибутива. Лазарь такое позволяет?

Позволяет, конечно. Необходимо только иметь в системе пакет с библиотекой интерфейсной привязки Qt5Pas.

Ещё мне не понравилось, что тот же CudaText надо собирать каким-то левым скриптом с левого ресурса. Это при том, что у fpc/Delphi, вообще-то, файл проекта совмещён с главным модулем программы, и для многих случаев сборочная система вообще, по идее, не нужна. Но понятно, что это особенность конкретного проекта (CudaText). Может, другие проекты на Лазаре (DoubleCommander, что-то ещё) свободны от этого недостатка?

Это зависит от проекта, как и везде. Самому Лазарю (не самый маленький проект) в простейшем случае достаточно дать команду make.

Если я пишу какой-то свободный проект, мне мало написать код. Мне надо дать вменяемую инструкцию мейнтейнерам дистрибутивов, как это собрать без головной боли. Они точно не будут ставить IDE на каждый чих.

Ну вот, например, ебилд для Double Commander. В принципе, всё как у всех.

Не очень понятно, почему вы так боитесь ставить IDE. Она всё равно содержит библиотеки, необходимые для сборки таких проектов. Ну можно выбросить исполнимый файл IDE в отдельный пакет (в Debian, наверное, так и сделали), но как это значимо повысит качество жизни всем вовлечённым в процесс?

rip

Зачем постить фотки своего надгробия? :)

Не очень понятно, почему вы так боитесь ставить IDE.

«Я??? Боюсь??? Да я!…» (шутка)

Слово «боюсь» тут не совсем точно. Если я собираюсь активно писать код проекта — да, лучше поставить IDE. Но человеку, которому проект нужно просто собрать, эта IDE совершенно не нужна. Тут есть люди, ноющие, что для запуска кутешных проектов нужно ставить кучу кутешных же библиотек, представляю, как бы они заныли, если бы ещё и Qt Creator пришлось бы для этого тащить.

Ну эти ладно, тут просто потребление. А я писал про мейнтейнеров, которые делают полезную работу для других и которым и так кучу всякого дерьмища для 100500 других пакетов ставить. Так вот, если их избавить хотя бы от установки явно не нужной им IDE — думаю, это действительно повысит им качество жизни. Может, не очень значимо, но хотя бы не подтолкнёт их сразу отказаться от этой гиблой затеи, уже хлеб.

в Debian, наверное, так и сделали

Значит, я таки зря с Дебиана ушёл :)))

В FreePascal есть fppkg

> Чем ближе инициализация переменной к её использованию, тем проще читать и сопровождать такой код.

Очевидно!

mister_VA> Особенно если пишут несколько программистов и один такой: int a=5; c=b+a; а другой через 350 строк допишет float a=5.5; e=a^6;

Вот дурачок! ЛЮБОЙ компилятор тебе немедленно сообщит, что переменная 'a' уже существует! В чём проблема??

Помню, в c# мне нужно было в цикле читать чанки больших csv и укладывать в хранилище. Угадайте, когда приходил GC, чтобы выкинуть ненужный массив из памяти? Правильно, никогда.

Чувак, хватит уже насиловать тостер! Купи уже себе ПК. На нём GC вызовется ЕСЛИ очень припрёт. А так .NET прекрасно работает. Ты почитай как там устроен механизм GC и памяти вообще - ты такое за всю жизнь не придумаешь!

Практика использования вложенных функций превращает функцию в бесконечную портянку.

Согласен. ИЧО? Вложенные функции всё равно нужны. Без них код превращается в вермишель.

Но человеку, которому проект нужно просто собрать, эта IDE совершенно не нужна. Тут есть люди, ноющие, что для запуска кутешных проектов нужно ставить кучу кутешных же библиотек, представляю, как бы они заныли, если бы ещё и Qt Creator пришлось бы для этого тащить.

Для сборки проекта как минимум будет нужна LCL, которая поставляется вместе с IDE (если же LCL не требуется, то и Lazarus, вероятно, не будет для сборки требоваться тоже).

Кроме того, вы сильно переоцениваете размер и время сборки Lazarus.

в Debian, наверное, так и сделали

Значит, я таки зря с Дебиана ушёл :)))

Их разбиение на мелкие пакеты доставляет проблемы новичкам. Всё имеет свою цену.

Они ухудшают читаемость кода

Это кому как

Хорошо написанная функция должна быть обозрима, и поэтому обычно вмещается в один экран +/-.

После паскаля в си очень не хватало по-первости вложенных функций: приходится делать то же самое только кишки вытаскивать наружу – хоть часто они вне пределов этой функции не нужны

Практика использования вложенных функций превращает функцию в бесконечную портянку.

и какая разница? написать 10 функций по экрану каждая отдельно или написать 1 большую, у которой реализация в конце тоже на экран и девять вложенных на экран перед основной? Зато не приедется данные ви логику из общей большой задачи в глобальное пространство модуля вытаскивать

Причём правило обозримости здесь плохо работает и для вложенных функций, поскольку они имеют доступ к локальным переменных родительской функции.

этот недостаток – он же – достоинство. При умелом использовании упрощает межфункцное взаимодействие и увеличивает тем самым читаемость

Так чего ты его защищаешь?

Да ниче подобного, я просто не понял чем тебе стдлиб не угодил, ответил так, шутки ради, не в защиту анона

Вариант, в принципе. Но кривой, если честно.

LD_LIBRARY_PATH?

Например в вызовах функций. На уровне стека и ассемблера.

Это-то понятно: я просто паскаль до таких тонкостей не знаю (со школы практически ни-ни). Я интересовался именно про принципы: ну в си компилируется функция, ейный адрес потом линковщиком везде связывается, все вот это вот. Принципы же те же самые в паскале? Я думаю да, но сам ни разу не смотрел, вот и решил по случаю спросить у знающих

В МОДУЛЬНОСТИ. Настоящей, а не поддельной, как в C.

А в чем профит настоящей модульности? Более быстрая линковка – раз. Более точная линковка – двас. А еще?

Во-вторых предсказуемость

Да помню я про эти оба раза :) Это очень красноречивый пример: я надеялся еще чего-нибудь такого интересного понасобирать

Для сборки проекта как минимум будет нужна LCL, которая поставляется вместе с IDE (если же LCL не требуется, то и Lazarus, вероятно, не будет для сборки требоваться тоже).

Я как раз про ситуацию, когда LCL нужна, а вот Lazarus нет. И это даже не только вопрос размера и времени сборки (хотя они тоже важны), это вопрос элементарной архитектурной опрятности.

Неосиляторы такие неосиляторы.

Не всякий найдет в себе силы жрать говно ложками, да еще и нахваливать при этом)

LD_LIBRARY_PATH?

Так его в скрипте проще всего и прописать. Что кривости решения, имхо, не убавляет.

Ситуаций когда сс нужен, а вот g++ нинужен не бывает? Бинарник ide весит копейки, не в пример опакеченному добру в gcc.

ЛЮБОЙ компилятор тебе немедленно сообщит, что переменная ‘a’ уже существует! В чём проблема??

В том, дурашка, что на ровном месте вылазит ошибка. И если эти прогеры такую переменную поиспользовали ещё и чехардой (т.е. один написал код с 50 по 100 страницу, а потом с 324 по 486, а другой – со 150 по 200, а ещё внёс «свою» «a» в строки 378, 389 и 457), то хрен ты быстро исправишь код.

Давно g++ в IDE превратился?

И расскажи всё это мейнтейнеру, человеку, который поддерживает в репе энное количество чужих проектов и делает это, как я подозреваю, зачастую на энтузиазме. Ему надо всячески помогать и облегчать его труд, а не наоборот. А известие о том, что n+1-й проект на неоченьсильнораспространённом языке тащит за собой ещё и IDE, боюсь, просто сподвигнет его на это забить и поискать аналог опакечиваемой софтины на чём-то более мейнстримовом.

Я за то, чтобы в репах был и Лазарус, и LCL. Обеими руками. Но для этого надо бы по максимуму обеспечить дружелюбность.

А кто сказал, что только именно IDE в gcc кому-то может быть нинужен? И какую дружелюбность? Насколько я знаю, IDE сабжа бывает в двух ипостасиях: GTK и QT. Cильно сомеванаюсь, что есть мейнтейнеры впихивающие в репы монолитные пакеты сабжа, да еще и с двумя бинарниками.

это вопрос элементарной архитектурной опрятности.

Это вопрос стиля опакечивания, архитектура в данном случае ни при чём. Те, кто хотел опакетить Lazarus таким образом, уже давно сделали это.

Lazarus в Debian: https://packages.debian.org/ru/sid/lazarus-2.0

Double Commander в Debian: https://packages.debian.org/sid/doublecmd-common

Остальные прикидываются снежинками.

Децкий сад. Ейбогу :)

есть типизация, которую называют строгой

В питоне?... Она «строгая» по сравнению с чем?

хз какое конвертирование типов под капотом из скаляра в вектор

А не надо заниматься ананизмомконвертированием, тем более, из скаляра в вектор. Ты бы ещё скаляр в хэш конвертанул.

Я интересовался именно про принципы: ну в си компилируется функция, ейный адрес потом линковщиком везде связывается, все вот это вот.

В паскале почти всё тоже самое, только есть нюанс...
компилятор паскаля может всё это сделать за один проход, а сишный не могёт бай десинг :)

А в чем профит настоящей модульности? Более быстрая линковка – раз. Более точная линковка – двас. А еще?

Сам спросил - сам ответил :)

От себя добавлю, что ещё можно очень просто реализовать ООП «изкаробки», не прибегая к ++костылям. Но это уже другая история.

ЗЫ
Ещё в паскале можно было лихко и просто реализовать шаблоны, но ... это уже другая++ и печальная история.

есть типизация, которую называют строгой

В питоне?... Она «строгая» по сравнению с чем?

Она строгая по определению. Определение строгой типизации ищи, где угодно. Сможешь доказать, что в питоне не строгая — пруфы в студию. Я тебе покажу, почему в перле типизация слабая.

хз какое конвертирование типов под капотом из скаляра в вектор

А не надо заниматься ананизмомконвертированием, тем более, из скаляра в вектор. Ты бы ещё скаляр в хэш конвертанул.

Это пример от балды был. Будешь отрицать, что в перле нет неявной конвертации между его типами? К слову о слабой типизации в пердле.

Я тебе покажу, почему в перле типизация слабая.

Что тут сложного?
Умеет складывать количество гвоздей с количеством консервных банок …

Я тебе покажу, почему в перле типизация слабая.

Что тут сложного?

Умеет складывать количество гвоздей с количеством консервных банок …

А не надо заниматься ананизмом...

Ещё в паскале можно было лихко и просто реализовать шаблоны,

Шаблоны в ЯП появились от того, что разработчики этих языков толком не понимают, что означает термин «Метапрограммирование».
К примеру в C++ навыдумывали всяких template, constexpr, … и иной ЧУШИ, в теперь строят АБСТРАКЦИИ над всей этой чушью …

Пилят золотую гирю ...

А не надо заниматься ананизмом..

Каждый все понимает все по своему.
Вы это поняли так, хотя речь шла о слабой типизации …

О Lazarus, Java, .Net, …

Смешались в кучу ООП, классы,
И залпы тысяч интерфейсов
Слились в протяжный вой…

Владимир

Рад, что ты его не забросил, рад что люди вообще пишут что-то интересное в то время когда у всех и хватает сил только на то чтобы пахать. Творческие люди - это круто. Желаю процветания и тебе и проекту. Вот.

Полностью поддерживаю слова R_He_Po6oT. Удачи

плохо сомневаетесь, арчлинух не гнушается и делает обе версии GUI

Децкий сад. Ейбогу :)

Наконец-то до тебя дошла суть твоего поведения. :-))

Кондратий, я пересмотрел все ваши ролики на Ютуб … Весьма технически познавательно. Из вас может получиться хороший режиссер …

Владимир

надо заниматься ананизмом…

Вам да, надо …

Владимир

Мне кажется, вы не Владимир.
А казачок-то

засланный!

Владимир

Что-то много «changes affecting compatibilities». Даже если большинство в GUI части фреймворка, всё равно какой-то стремный релиз.

sunjob

Кстати пролистал эти changes, там и про gtk2 написано. Так что да, это в релизе они ошиблись когда написали про gtk2 2.8

GTK2 widgetset version requirement

    Old behavior: At least GTK2 2.8 was required.
    New behavior: At least GTK2 2.24 is required.
    Reason: All supported distribution versions already have GTK2 2.24.
    Remedy: GTK2 2.22 may still work (untested). 
    Older GTK2 (2.20 and earlier) versions may still work (untested, so completely at your own risk) after reverting commit 0172124a423be.

ну вообще, как только среда становится кроссплатформенной и опенсорсно-бесплатной, о стабильности и обратной совместимости можно забыть. Поэтому там, где крутится какое-то бабло, легче утилитки писать на шарпДевелоп (и для оффтопика), который помер в 2016г. и для конкретной версии дотНэт, чем на этих ваших растах, которые на каждый чих пересобирают полмира.