LINUX.ORG.RU

Lazarus 1.4

 , , ,


0

5

22 апреля 2015 года тихо и незаметно вышла очередная версия кроссплатформенной среды разработки, использующая компилятор FPC версии 2.6.4 — Lazarus 1.4.0-0
О релизе:

  • Добавлены методы и утилиты для загрузки объектов за счет средств FPC.
  • Изменения коснулись форматов файлов ресурсов LCL: теперь их можно редактировать, используя файлы ресурсов на платформе Windows.
  • Добавлены совместимые c Delphi компоненты TDateTimePicker, TDBDateTimePicker, TComboBoxEx и TCheckComboBox.
  • Появился новый класс THintWindowManager, улучшающий работу подсказок в редакторе.
  • Многочисленные изменения функционала IDE.
  • Компонент TOpenGLControl теперь работает в GNU/Linux.
  • Переписаны и изменены некоторые компоненты и параметры.

>>> Release notes

★★★★★

Проверено: JB ()
Последнее исправление: cetjs2 (всего исправлений: 4)

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

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

С этим надо осторожнее, в LCL поддержки такой фичи пока нет - незря данный релиз выходит на «старом» fpc 2.6.4. Надеюсь к lazarus 1.6 запилят

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

Надеюсь к lazarus 1.6 запилят

Транк уже рабочий. В целом вообще очень приятная фича, код очищается заметно.

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

Да, рабочий. Но есть вероятность словить «необъяснимые» крякозяблины на ровном месте и полку хейтеров прибудет))

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

и полку хейтеров прибудет))

Хейтеров вылечим, аргументированно. Воинствующих загоним под плинтус.

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

Спасибо, так вот откуда у меня в голове взялось про паскалевские строки, длину в отрицательном смещении и \0. С юникодм,емнип, тогда помнится беды какие-то были были - правда не помню какие именно, в самом языке, RxLib'е, FibPlus'e, ODAC'e, фасте или далее по списку, плюс Kylix ожидался, хз что с совместимостью, так обычными, (гусары, молчать!), стрингами и обходился :).
Под андроид, яфон не пробовал в лазаре проекты собирать ? - Я так и не понял живое-ли оно там и как это вообще работает, если даже то, что RAD XE выдает - тихий ужас.

handbrake ★★★
()
Последнее исправление: handbrake (всего исправлений: 1)
Ответ на: комментарий от handbrake

С юникодм,емнип, тогда помнится беды какие-то были были - правда не помню какие именно, в самом языке, RxLib'е, FibPlus'e, ODAC'e, фасте или далее по списку, плюс Kylix ожидался, хз что с совместимостью, так обычными, (гусары, молчать!), стрингами и обходился :).

Так-то, UnicodeString появились в дельфях только в 2008 году (и с тех пор структура строк ansi и unicode полностью совпадает). В 95-96 появились именно динамические строки (но только ansi). Через пару лет появилась поддержка юникодовых строк Win32 - WideString (BSTR). VCL не поддерживала юникод до 2008 года, поддержка осуществлялась сторонними библиотеками (TNT, TB2K, VirtualTreeview и прочими). В LCL сделали проще, ввели поддержку юникода на ansi-строках с кодировкой utf-8.

Под андроид, яфон не пробовал в лазаре проекты собирать

Под андроид демки собирал. Впечатления самые положительные: бинари мелкие, выглядит нативно, всё летает. Но тема не моя, поэтому детально не отвечу.

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

Хейтеров вылечим, аргументированно. Воинствующих загоним под плинтус.

Лучше чтобы перекодировка не включалась по умолчанию и без возможности отключения, а то загонишь в ansistrig массив рандомной информации а какая-нибудь #@$#$5ла его перекодирует из кодировки X в кодировку Y и всё «неправильное» сконвертирует в вопросики. В ансистрингах ведь можно хранить и пересылать бинарные данные, побайтовый доступ имеется - не надо ломать хорошую фичу принудительной перекодировкой.

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

Есть RawByteString, строки со специальной codepage ($FFFF). Для таких строк перекодирование не выполняется. Но для хранения бинарных данных идеологически правильнее использовать байтовые динамические массивы.

anonymous
()

Годнота! Продолжайте дальше!

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

Но для хранения бинарных данных идеологически правильнее использовать байтовые динамические массивы.

А кому какое дело, какая информация хранится в строках если это не жаба? Отрубил перекодировку и наслаждайся хорошей работой ансистрингов жующих всё подряд, а если в каком-то исходнике перекодировка нужна - там включил, так правильнее чем ломать старые фичи ради не всем нужных новых.

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

Отрубил перекодировку и наслаждайся хорошей работой ансистрингов жующих всё подряд, а если в каком-то исходнике перекодировка нужна - там включил, так правильнее чем ломать старые фичи ради не всем нужных новых.

Я же тебе сказал, если не хочешь перекодировок - используешь RawByteString и ничего у тебя перекодироваться не будет. Более того, если у тебя раньше использовались AnsiString (не просто String, а именно AnsiString) для хранения данных, и есть методы обработки принимающие параметры AnsiString то и в этом случае ничего перекодироваться не будет т.к. компилятор не видит смысла перекодировать AnsiString <-> AnsiString. Но вот если такую AnsiString с мусором передать как Utf8String, например, то получишь мусор в результирующей строке. В общем, кроме появившихся положительных моментов, в плане работы со строками ничего не меняется.

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

Я же тебе сказал, если не хочешь перекодировок - используешь RawByteString и ничего у тебя перекодироваться не будет.

И что, в транке демка

VAR

A,B: {ANSISTRING;} RawByteString;

BEGIN
A:=#0#1#2#3#49#50;
B:=#4#5#6#7#51#52;
A:=A+B;
WRITELN(A);
A:='123';
WRITELN(A);
END.
с типом данных RawByteString выдаёт тот же результат что и с ANSISTRING?

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

Проверочный код:

uses sysutils;
VAR

A,B:  RawByteString;
A1,B1: ANSISTRING;

BEGIN

A:=#0#1#2#3#49#50;
B:=#4#5#6#7#51#52;
A:=A+B;

A1:=#0#1#2#3#49#50;
B1:=#4#5#6#7#51#52;
A1:=A1+B1;
WriteLn(Length(a) = Length(a1));
writeln(CompareMem(pointer(a), pointer(a1), length(a)));

A:='123';
A1:='123';
WriteLn(Length(a) = Length(a1));
writeln(CompareMem(pointer(a), pointer(a1), length(a)));

END.
Результат:
TRUE
TRUE
TRUE
TRUE

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

Мда, тяжело не понимать разницы между официальным портом и самосбором. Создатели неочевидных проблем - это вообще первое зло OpenSource, и людям, которые советуют такое, а потом «а почему библиотека не нашлась», «почему линкер не вызывается», «почему всё сломалось», «а как восстановить такую же среду вон там» и ещё тысяча вопросов к САМЫМ УМНЫМ - надо бить по руках. Они дебилы, дебильные дебильствующие дебилы, которые не могут понять, чем частный случай отличается от общего, и ВСЕГДА (всегда!) проводят частные случаи до общих.

Такие вещи советовать нельзя, нельзя в принципе.

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

Теоретик, так сделал бы официальную сборку для OpenBSD уже, если тебе так припёрло. Тут-то чего метанировать?

Или ты думаешь, что тебе все должны?

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

Теоретик, так сделал бы официальную сборку для OpenBSD уже, если тебе так припёрло.

Мда. Я фигею без баяна с местного населения. Интернет-интернет, верни меня на 15 лет назад!

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

Мда. Сказали же сделай сборку, в своей виртуальной машине, если так переживаешь за основную систему, и отправь патч.

И да, тебе никто не должен :)

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

И да, тебе никто не должен :)

Это уже за гранью...

buratino ★★★★★
()

Эх, Паскаль, Паскаль! Учебник Фаронова, tpascal55.exe размером 156 килобайт, дискеты 5,25, EC-1841.

Верните меня обратно в этот рай!

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

Верните меня обратно в этот рай!

EC-1841 - это ад. В адудитории на 20 машин гул стоял, как в токарном цеху.

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