LINUX.ORG.RU

Lazarus 0.9.30

 , , ,


0

2

Команда разработчиков Lazarus рада представить вам новую версию свободной среды разработки для компилятора FreePascal - Lazarus 0.9.30.

Изменения в самой IDE:

  • добавлена поддержка ресурсов FreePascal
  • улучшен конвертор Delphi-проектов
  • настройки компилятора для отдельного проекта теперь могут быть сохранены как основные для новых проектов
  • по умолчанию каталог для откомпилированных модулей теперь установлен в «lib/$(TargetCPU)-$(TargetOS)»
  • теперь для всего модуля используется то окончание строки, которое было использовано в начале модуля
  • добавлена директива %H- для скрытия отдельных подсказок
  • теперь интерфейс IDE можно сделать «dockable» используя пакеты AnchorDockingDsgn и EasyDockMgrDsgn
  • функционал «ToDo list» перемещён в отдельный пакет todolistlaz.lpk
  • добавлен перевод на чешский язык.

Изменения в LCL:

  • добавлена поддержка буфера обмена для Windows CE
  • разделены интерфейсы GTK2 и GTK1
  • fpGUI теперь поддерживает весь набор компонентов с закладки Standard
  • добавлена поддержка Haiku используя Qt
  • расстановка виджетов по слоям и подстраивание размера теперь более отзывчиво
  • добавлена новая функция AlphaBlend для TLazIntfImage
  • TBarChar объявлен устаревшим(см. пакет TAChartLazarusPkg)

Изменения в редакторе кода:

  • добавлено скрытие/сворачивание комментариев
  • реализована поддержка нескольких окон просмотра кода
  • реализована система пользовательских тем подсветки синтаксиса
  • теперь размер всплывающего списка идентификаторов может быть изменён

Изменения в отладчике:

  • вставленные/удалённые строки во время отладки теперь отслеживаются. Точки останова и выполнения смещаются
  • добавлена команда вхождения в функции во время отладки
  • реализована команда «Шаг в обход»(спасибо Flavio)
  • добавлена команда показа строки с текущим исполняемым кодом
  • улучшена окно дизассемблера и окна для наблюдения за значениями переменных
  • добавлены команды навигации в окне дизассемблера
  • увеличена скорость работы в режиме отладки

>>> Подробности

★★★★

Проверено: mono ()
Последнее исправление: Andru (всего исправлений: 1)

Ответ на: комментарий от korvin_

>> lazarus вполне себе зачетная среда быстрой разработки.

до Xcode или IDEA им еще расти и расти, а на паскале это ох как сложно

А никто такой цели и не ставит.

PS

Что на паскале сложно? Написать IDEA? Не сложнее, чем на чем-то другом )

dikiy ★★☆☆☆
()
Ответ на: комментарий от Oleaster

> Назовите десять фич фара, которые не поддерживает тотал.

Мне хватает одной - полноценная интеграция с командной строкой. В чём-то она даже лучше, чем в mc. Тотал тут даже у порога не валялся. Но хомячкам это не нужно, да.

Ах да, Far 2 к тому же умеет юникод и открыт под BSD.

hobbit ★★★★★
()
Ответ на: комментарий от wxw

>Допустим, я всё равно не понимаю, нифига бинарнику в обязательном порядке держать (текстовой?) инфы аж на 10 Mb. Зачем она ему, рефлексия, rtti или что?

Для сообщений об ошибках и прочей отладочной информации. Совместимость с кактусовым gdb это вообще отдельная песня. Лишний размер нужен не бинарнику а ИДЕ для отладки. Собираешь тот же самый проект из коммандной строки и, о чудо, файл получается даже чуть меньше чем скомпиленный в ИДЕ после стрипа.

Napilnik ★★★★★
()
Ответ на: комментарий от korvin_

>> me знает кроме паскаля C, Assembler, python чуть хуже. На паскале писать намного удобнее, имхо. И код прозрачней.

прозрачней? за кучей begin-end'ов и общего примитивизма?

begin и end заметить много легче, чем { }. Да и причем тут begin и end к общей прозрачности?

примитивнейщей системой модулей? примитивных (примитивней только в С++) классах и вообще типах данных?

Вполне себе нормальная система. (В C++ вообще непонятно что). И как язык объектного программирования стройный и понятный, и прост в изучении. Чего еще надо?

И сравнивали в прозрачности есессно с другими ширпотребовскими языками (читай С). А не со всякими «брейнфаками».

dikiy ★★☆☆☆
()

Новость радует, поздравляю.

Хотя считаю, что для основной стези Паскаля - обучения - сейчас уже лучше смотреть на Оберон либо на его развитие, Component Pascal.

hobbit ★★★★★
()
Ответ на: комментарий от dikiy

begin и end заметить много легче, чем { }

естественно, они не создают область видимости. замените

(let ((i 0))
  (let ((i 1))
    (print i))
  (print i))

на begin/end

Да и причем тут begin и end к общей прозрачности?

да при том, что избыточный синтаксис захламляет код

Вполне себе нормальная система.

ни списков экспорта/импорта, ни квалификации — это нормальная система?

И как язык объектного программирования стройный и понятный

это SmallTalk, но не Паскаль/Делфи

И сравнивали в прозрачности есессно с другими ширпотребовскими языкамих

какой в этом смысл? все равно, что с дерьмом сравнивать, тут любое недерьмо — не дерьмо

korvin_ ★★★★★
()
Ответ на: комментарий от dikiy

> А никто такой цели и не ставит.

а стоило бы, глядишь и нормальная IDE вышла бы

korvin_ ★★★★★
()
Ответ на: комментарий от hobbit

> Мне хватает одной - полноценная интеграция с командной строкой. В чём-то она даже лучше, чем в mc.

учитывая какой убогий у венды командный интерфейс, это не нужно

korvin_ ★★★★★
()
Ответ на: комментарий от dikiy

> begin и end заметить много легче, чем { }

кстати, какие средства в делфи/лазарус для этого? и будет ли наконец подсветка парных операторных скобок?

korvin_ ★★★★★
()
Ответ на: комментарий от hobbit

> Хотя считаю, что для основной стези Паскаля - обучения - сейчас уже лучше смотреть на Scheme либо ML.

fixed

korvin_ ★★★★★
()
Ответ на: комментарий от korvin_

>до Xcode ... расти и расти

=) ох насмешил))) хкоду до возможностей даже Лазаруса ещё расти и расти)), хотя по стабильности конечно Xcode чуть стабильней.

FedeX ★★
()
Ответ на: комментарий от korvin_

>>Да и причем тут begin и end к общей прозрачности?

да при том, что избыточный синтаксис захламляет код

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

Napilnik ★★★★★
()
Ответ на: комментарий от Napilnik

> Это не избыточный синтаксис а имитация _человеческого_ языка. Если человеческий язык для вас избыточен, можете разговаривать с людьми на ассемблере, они вас поймут и оценят.

эта «имитация» бессмысленна, ибо назначения языков сильно разные, даже Пролог большая имитация, ибо более декларативен, нежели примитивный паскаль, у которого большинство типов машино-ориентированные

korvin_ ★★★★★
()
Ответ на: комментарий от korvin_

>кстати, какие средства в делфи/лазарус для этого? и будет ли наконец подсветка парных операторных скобок?

не повериш - даже подсветка парных begin/end-ов работает))

FedeX ★★
()
Ответ на: комментарий от FedeX

> в XCode уже запилили нормальное автодополнение?

в сотни раз лучше делфийского

а генерацию кода?

опять лучше

а рефакторинг?

этого нет, тысячи хкод-о юзеров негодуют, просто жуть

korvin_ ★★★★★
()
Ответ на: комментарий от FedeX

> не повериш - даже подсветка парных begin/end-ов работает))

не прошло и десяти лет...

korvin_ ★★★★★
()
Ответ на: комментарий от korvin_

>в сотни раз лучше делфийского

«не верю» (с) в последний раз как туда заглядывал - вообще нифига там небыло

FedeX ★★
()
Ответ на: комментарий от korvin_

эта «имитация» бессмысленна, ибо назначения языков сильно разные, даже Пролог большая имитация, ибо более декларативен, нежели примитивный паскаль, у которого большинство типов машино-ориентированные

Ничего себе, «бессмысленная». Смысл есть - часть лишних вычислений переносится с человека на железяку которая не потеет и почти не устаёт.

даже Пролог большая имитация, ибо более декларативен, нежели примитивный паскаль

Пролог (фр. Programmation en Logique) — язык и система логического программирования, основанные на языке предикатов математической логики дизъюнктов Хорна, представляющей собой подмножество логики предикатов первого порядка.

В топку «математическую логику», она не для всех человеков а только для математиков которые общаются на не совсем человеческом языке математических формул.

у которого большинство типов машино-ориентированные

И замечательно - с железом желательно иметь консенсус и примерно знать когда использовать козырной INT64 а когда и BYTE достаточно.

Napilnik ★★★★★
()
Ответ на: комментарий от anonymous

>Наверно писал всё-таки не на самом Qt, а кнопочки по формочкам мышкой гонял, а на Qt их перегонял при компиляции уже сам Lazarus.
Прочти интервью. Да, перегонял Лазарус. Да, про сигналы в интервью молчок, всё про callback. Но основной проблемой стало всё-таки поведение потоков. Хз, где он там грабли нашёл, но наступил, видимо, с размаху. Тысячи разных кодеров нормально пишут, а вот у него не получилось. Предполагаю проблемы линуксовой версии компилятора.

fractaler ★★★★★
()
Ответ на: комментарий от fractaler

не понял ответа...

мне написали, что в школе не учат ООП - нас в школе в 10-11 классе «учили» (громко сказано) этому самому визуальному басику...

BattleCoder ★★★★★
()
Ответ на: комментарий от fractaler

>Но основной проблемой стало всё-таки поведение потоков. Хз, где он там грабли нашёл, но наступил, видимо, с размаху. Тысячи разных кодеров нормально пишут, а вот у него не получилось.

Есть несколько отличий в исполнении некоторых конструкций на дельфи и объектпаскале, наверно он ими злоупотреблял. Ну и под поток по умолчанию выделяется 4 метра памяти а не килобайты как в дельфи. Если потоков мало, так даже лучше, память меньше фрагментируется - линуксовый менеджер памяти не идеален. Дельфийский менеджер к линуксу не пришьёшь. Чтобы догадаться подкрутить константу в исходниках, нужно полазить по паскалевским форумам, набить чуток экспы. А он наверно решил что свободная реализация языка обязана на 100% дублировать платную.

Napilnik ★★★★★
()
Ответ на: комментарий от Napilnik

Позволю себе заметить, что у FPC менеждер всё-таки памяти свой, а не общесистемный. С претензией на высококачественность (и, по-моему, небезосновательной). Хотя сколько он выделяет под поток - врать не буду. Замечу, кстати, что пока работа с потоками у FPC реализована, если я не отстал от жизни, довольно костыльно, по крайней мере в линуксе, - приходится цеплять специальный юнит cthreads, название которого говорит само за себя.

PVOzerski ★★★
()
Ответ на: комментарий от korvin_

>>begin и end заметить много легче, чем { }

естественно, они не создают область видимости. замените

(let ((i 0)) (let ((i 1)) (print i)) (print i))

Сравнил жопу с пальцем называется.

Да и причем тут begin и end к общей прозрачности?

да при том, что избыточный синтаксис захламляет код

В функциональных языках - есессно.

Пиши на брейнфаке, если лишний синтаксис тебе код захламляет.

Вполне себе нормальная система.

ни списков экспорта/импорта, ни квалификации — это нормальная система?

После этого можно не продолжать. Понятно, что ты знашь паскаль только со слов ЛОРовских троллей.

И как язык объектного программирования стройный и понятный

это SmallTalk, но не Паскаль/Делфи

какой в этом смысл? все равно, что с дерьмом сравнивать, тут любое недерьмо — не дерьмо

Смысл в том, что Паскаль - это хороший универсальный инструмент.

dikiy ★★☆☆☆
()
Ответ на: комментарий от korvin_

>> SmallTalk это твой диагноз

это эталон ООП, до которого Паскалю как до Луны

Пердеть, не мешки ворочать.

dikiy ★★☆☆☆
()
Ответ на: комментарий от pozitiffcat

>AIMP2 использую уже много лет, ниразу не заглючило!. Причем тут быдло лазарус и т.п. Лишь бы руки прямые были!

Люто, бешено плюсую, АИМП юзаю уже более двух лет и ни одного косяка не наблюдалось. Удобный интерфейс + не жрёт ни память ни проц, ну и для совсем вендузятников - куча скинов разных. И да, мне пох, на чём он там написан, как и большинству вендохомячков.
Ах да, а на чем написан мой любимый audacious?

Vier_E ★★★
()
Ответ на: комментарий от BattleCoder

>мне написали, что в школе не учат ООП - нас в школе в 10-11 классе «учили» (громко сказано) этому самому визуальному басику...

Суровая правда школьной жызни предусматривает только Паскаль, в ипостаси TP 7.0. И сейчас - только для классов «физмат» профиля. Остальные быдлоклассы программирование не учат ВООБЩЕ - только основы алгоритмов в 9 классе. И да, в качестве эксперимента, у нас вводился VB в курс 9 «физмат» класса. Так, тока основы и простенькие проги. Вроде бы особых трудностей не вызвал.
Да, по сабжу, для Зузи 11.4 нормально собирается? Без косяков и прочих несовместимостей?

Vier_E ★★★
()
Ответ на: комментарий от segfault

>Без указания контекста заявлять

Ух как, мой милый толстячок ^_^

это по-любому паскакаль работает в 5 раз медленней и жрёт в 616 раз меньше памяти, супротив С, а не тесты криво написаны, дадад

заявлять, что паскаль, цитата: «жрёт в 616 раз меньше памяти, супротив С» - это разве не жирно???

Не находишь некоторой разницы в заявлениях, не? Или первый посыл (со столь любимым тобою контекстом) приводит к совершенно иным заключениям, нежели второй, если конечно жиром не заплыл орган, отвечающий за детекцию сарказма? ^_~

Эти тесты самые что ни есть объективные - реализация одного и того же алгоритма. Подобный разброс для сходных технологий свидетельствует о различиях компиляторов и оптимизаторов.

http://shootout.alioth.debian.org/u32/program.php?test=knucleotide&lang=fpasc...

http://shootout.alioth.debian.org/u32/program.php?test=knucleotide&lang=gpp&id=1

Раздел import'ов и uses'ов (ой, а в паскакальном тесте их и нет 0.о) вот просто кричит об абсолютной идентичности алгоритмов, да-да ^_^ (expesially 2 segfault - >>>сарказм<<<). Заодно и на имена переменных посмотреть можете.

Лазарус, внезапно, не только кроссплатформенная обёртка

Вот про плату за это «обертывание»

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

anonymous
()
Ответ на: комментарий от Jayrome

>Только интересно, какой разработчик в здравом уме, знающий что-то кроме, будет использовать Free Pascal.

А ты представь себе что кто-то кроме паскаля и делфи ничего не осилил, а на делфях у него пол жизни проги писались! Как их без Лазаруса под Линукс и БСД ему портировать? Именно такие люди и развивают этот проект.

sdh
()

Сам паскаль им пора развивать... вот хотябы добавить «компонентный паскаль».....

sdh
()
Ответ на: комментарий от Shlyapa

ну так если все утрировать то все сегодняшние достижения это заслуга древних египтян, чет я не видел в нортоне плагинов, а скрестить тоже надо додуматся, и можешь хоть себе тельник на груди порвать, как инструмент фар намного удобнее, даже с архивами в тотале досих пор работает все через Ж.., работа с сетью и фтп убил бы.., что радует хомячков так это его гуевые кнопочки, а мне на них лично наплевать far и mc наше все...

grigoreo
()
Ответ на: комментарий от PVOzerski

>>привязка rpm-пакета исключительно к Федориному горю

так слей с svn и будет тебе счастье...

grigoreo
()
Ответ на: комментарий от korvin_

В xcode нет рефакторинга? гыгыгы! Тогда твой баттхерт понятен)))

anonymous
()
Ответ на: комментарий от Oleaster

>>Что касаемо «полноценной» (убогой виндовой) консоли, то она — с помощью плагина TConsole — была в TC ещё в те лохматые годы, когда я юзал венду. Открывалась в панели.

эта убогая консоль зачастую имеет практическое применение, а то как это реализовано в фаре и тотале даже сравнивать не надо, в фаре на 5 ибо он итак в консоле, в тотале в форме костыля...

так это все, тады незачет...

grigoreo
()
Ответ на: комментарий от korvin_

>>учитывая какой убогий у венды командный интерфейс, это не нужно

просто ты не знаешь что это такое,

grigoreo
()
Ответ на: комментарий от korvin_

Ладно умник уболтал, а теперь назови нормальный кросплатформеный язык разработки и тут я подразумеваю не только OS но и инструкции процессора(поддержку ГУЯ и СУБД незабываем), кроме жабы (и не дай бог тебе про C# заикнутся) и С пока ничего не всплывает, только не надо тут городить языки где многое на костылях держится...

Я бы и на ассемблере писал (тем более что помню) если бы он был кросплатформеным

grigoreo
()
Ответ на: комментарий от grigoreo

> даже с архивами в тотале досих пор работает все через Ж

Все отлично работает, ели руки там, где надо, в противном случае вам к хирургу.

работа с сетью и фтп убил бы

Тоже нет особых нареканий, за исключением тормознутости обозревателя сетевого окружения, но это косяк ведра а не тотала.

win7
()
Ответ на: комментарий от grigoreo

> поддержку ГУЯ

кроме жабы


может я не прав, но вроде как дейстительно кроссплатформенный гуй один - wxWidgets, но и тот убог, все остальное с разной степенью паршивости эмулирует нативный гуй

aho
()
Ответ на: комментарий от hobbit

Хотя считаю, что для основной стези Паскаля - обучения - сейчас уже лучше смотреть на Оберон либо на его развитие, Component Pascal.

Вот-вот, и я о том же, в freepascal надо добавить новые языки!!!

И для развития Лазарус необходимо дальше объединять с GNU Modula-2 http://www.nongnu.org/gm2/homepage.html BlackBox Component Builder http://www.inr.ac.ru/~info21/info/qtoblackbox.htm An Integrated Development Environment for Component Pascal for .NET http://www.cfbsoftware.com/cpide/cpide.aspx а не смотреть на Делфи утопию.

Разрабам GCC работающими над Modula-2 взять шевство над всем этим процессом...

sdh
()
Ответ на: комментарий от aho

> все остальное с разной степенью паршивости эмулирует нативный гуй

и да - тут Qt таки впереди

aho
()
Ответ на: комментарий от BattleCoder

>не понял ответа...
Я хотел сказать, что куда ж мы в школе от VB денемся.
Пару раз переводил школы на СПО. Один из первых вопросов «А есть ли VB?». Благо, GAMBAS уже хорошо развит.

мне написали, что в школе не учат ООП - нас в школе в 10-11 классе «учили» (громко сказано) этому самому визуальному басику...

При современном состоянии школы приходится согласится, что ООП это слишком. Лучше пусть функции хорошо освоят, тогда потом с ООП проблем меньше будет.

fractaler ★★★★★
()
Ответ на: комментарий от grigoreo

> Ладно умник уболтал, а теперь назови нормальный кросплатформеный язык разработки...

...поддержку ГУЯ...
C

Ну-ка покажи исходники гуевой проги на натив-си, которая у меня на ведре и линухе соберется! Или я чегото не знаю и апи теперь на всех осях к одному стандарту подтянули?

кроме жабы

Похоронить.

win7
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.