SASGIS - SAS.Планета
View Issue Details
0002166SAS.Планета[All Projects] Хотелкаpublic16-09-2013 06:5626-11-2016 09:41
vdemidov 
zed 
normalminorhave not tried
resolvedfixed 
121010 
160707160707 
0002166: Переход на версию Delphi с полной поддержкой юникода
Сейчас для сборки как основная используется Delphi 2007. Но только начиная с Delphi 2009 был полный переход на юникод. Для полной поддержки юникода в программе нужно перейти на что-то более свежее.
юникод
parent of 0002169resolved vdemidov Исправить импорт plt под юникодной Delphi 
parent of 0002493resolved vdemidov Упорядочить использование RegExpr и RegExprUtils 
parent of 0002690resolved vdemidov Добавить определение кодировки ini-файлов при загрузке в ConfigDataProvider 
parent of 0002691resolved zed Юникодная версия. Результаты геокодера Яндекса в виде знаков вопроса. 
parent of 0002705resolved vdemidov Unicode. В юникодной версии экспор в AUX неправильно записывает файл 
parent of 0002781resolved GunSmoker Access Violation в TDownloadResultError.GetErrorText в юникодной версии 
parent of 0002868resolved vdemidov В юникодной версии SAS, в главном меню, вместо хинтов выводятся знаки вопроса 
parent of 0002869resolved vdemidov Проблемы с отображением датчиков в юникодной версии 
parent of 0002877resolved vdemidov Поддержка utf-8 и utf-16 при загрузке параметров карты в неюникодной версии программы 
parent of 0002880resolved zed Возможно есть проблемы в экспорте в Ecw c использовании PChar в юникодной версии 
parent of 0002881resolved vdemidov Проблемы при работе с PChar в юникодной версии в CPDrv.pas 
parent of 0002882resolved vdemidov Мелкие проблемы работы с юникодом в MD5.pas и KAZip.pas 
parent of 0002883resolved zed Проблемы с юникодом при обработке событий WMCopyData 
parent of 0002047resolved vdemidov После изменения названия карты в zmp не меняется название в интерфейсе 
parent of 0002891resolved vdemidov Заменить использование WideString 
parent of 0002892resolved vdemidov Добавить обработку vtUnicodeString в FinalizeVarRec 
parent of 0002901resolved zed Переход на базу меток в SQLite по умолчанию 
parent of 0002975resolved zed В Unicode версии неправильно отображаются названия квадратов ГШ 
has duplicate 0002553closed vdemidov Перевод на рельсы Delphi XE7 
related to 0002107resolved zed sml файлы не по стандарту XML 
related to 0002900resolved vdemidov Принудительное сохранение ini файлов в utf-8 
related to 0003155resolved zed Ошибка в заголовках файлов, экспортированных в формат МЯК (версия 3) 
child of 0000626resolved zed Добавить возможность создавать метки и категории в Юникоде 
child of 0000181resolved vdemidov Комментарии слоя wikimapia, написанные иероглифами, отображаются знаками вопроса 
child of 0002278resolved vdemidov Не импортируется файл с именем с символами не из основной локали 
Issue History
16-09-2013 06:56vdemidovNew Issue
16-09-2013 06:56vdemidovTag Attached: юникод
16-09-2013 06:56vdemidovStatusnew => confirmed
16-09-2013 06:57vdemidovRelationship addedchild of 0000626
16-09-2013 06:57vdemidovRelationship addedchild of 0000181
16-09-2013 16:34vasketsovNote Added: 0012805
16-09-2013 17:05vdemidovNote Added: 0012806
16-09-2013 17:12vasketsovNote Added: 0012808
16-09-2013 17:16vdemidovNote Added: 0012809
16-09-2013 17:27vasketsovNote Added: 0012812
17-09-2013 17:00vdemidovRelationship addedparent of 0002169
30-11-2013 17:45zedRelationship addedchild of 0002278
04-09-2014 06:00zedNote Added: 0014605
04-09-2014 18:24vdemidovNote Added: 0014608
04-09-2014 19:13zedNote Added: 0014609
04-09-2014 20:37vdemidovNote Added: 0014610
06-09-2014 17:32vdemidovIssue cloned: 0002493
06-09-2014 17:32vdemidovRelationship addedparent of 0002493
20-11-2014 07:16vdemidovRelationship addedhas duplicate 0002553
19-02-2015 11:38vdemidovRelationship addedrelated to 0002107
20-04-2015 07:21vdemidovNote Added: 0015615
20-04-2015 07:54zedNote Added: 0015616
20-04-2015 12:59vasketsovNote Added: 0015617
20-04-2015 13:54vdemidovNote Added: 0015619
20-04-2015 14:33vasketsovNote Added: 0015620
20-04-2015 14:54vdemidovNote Added: 0015622
20-04-2015 15:27vasketsovNote Added: 0015623
20-04-2015 15:28vasketsovNote Edited: 0015623bug_revision_view_page.php?bugnote_id=15623#r6531
20-04-2015 17:48vdemidovNote Added: 0015625
20-04-2015 18:56vasketsovNote Added: 0015626
20-04-2015 19:30vdemidovNote Added: 0015627
20-04-2015 21:31vasketsovNote Added: 0015628
21-04-2015 06:57vdemidovNote Added: 0015630
21-04-2015 08:25vasketsovNote Added: 0015631
21-04-2015 09:13vdemidovNote Added: 0015632
21-04-2015 09:29vdemidovRelationship addedparent of 0002690
21-04-2015 16:15zedNote Added: 0015633
21-04-2015 17:35vasketsovNote Added: 0015634
21-04-2015 17:36vasketsovNote Edited: 0015634bug_revision_view_page.php?bugnote_id=15634#r6533
21-04-2015 17:38vdemidovRelationship addedparent of 0002691
21-04-2015 18:01vdemidovNote Added: 0015636
21-04-2015 19:05zedNote Added: 0015638
21-04-2015 19:44vasketsovNote Added: 0015639
21-04-2015 22:52vasketsovNote Added: 0015641
21-04-2015 22:55vasketsovNote Added: 0015642
22-04-2015 01:03vasketsovNote Added: 0015644
22-04-2015 06:04zedNote Added: 0015646
22-04-2015 10:44vasketsovNote Added: 0015659
22-04-2015 10:47zedNote Added: 0015662
22-04-2015 10:58vasketsovNote Added: 0015666
22-04-2015 11:00vdemidovNote Added: 0015667
25-04-2015 10:04vasketsovNote Added: 0015739
25-04-2015 10:19zedNote Added: 0015740
25-04-2015 10:44vasketsovNote Added: 0015741
26-04-2015 11:28vdemidovRelationship addedchild of 0002703
26-04-2015 13:41vdemidovRelationship addedparent of 0002705
26-04-2015 13:49vdemidovRelationship deletedchild of 0002703
21-07-2015 06:16GunSmokerNote Added: 0016195
03-08-2015 20:04GunSmokerRelationship addedrelated to 0002781
03-08-2015 20:06vdemidovRelationship replacedparent of 0002781
09-10-2015 09:06vdemidovRelationship replacedchild of 0002690
26-10-2015 10:51vdemidovNote Added: 0016627
26-10-2015 12:15zedNote Added: 0016628
26-10-2015 12:22vdemidovNote Added: 0016629
26-10-2015 17:33zedNote Added: 0016632
26-10-2015 18:28vdemidovNote Added: 0016633
27-10-2015 07:51vdemidovRelationship addedparent of 0002868
27-10-2015 21:00vdemidovRelationship addedparent of 0002869
28-10-2015 19:48vdemidovNote Added: 0016644
28-10-2015 20:00zedNote Added: 0016645
29-10-2015 11:05vdemidovRelationship addedparent of 0002877
30-10-2015 10:00vdemidovNote Added: 0016652
30-10-2015 10:14zedNote Added: 0016653
30-10-2015 10:15zedNote Added: 0016654
30-10-2015 10:25vdemidovNote Added: 0016655
30-10-2015 14:17vdemidovRelationship addedparent of 0002880
30-10-2015 14:17vdemidovRelationship addedparent of 0002881
30-10-2015 14:17vdemidovRelationship addedparent of 0002882
30-10-2015 14:18vdemidovRelationship addedparent of 0002883
01-11-2015 10:53zedNote Added: 0016677
02-11-2015 07:51vdemidovNote Added: 0016680
02-11-2015 11:14zedNote Added: 0016683
02-11-2015 11:21vdemidovNote Added: 0016684
03-11-2015 09:13vdemidovRelationship addedparent of 0002047
05-11-2015 08:08vdemidovRelationship replacedparent of 0002690
05-11-2015 09:15vdemidovRelationship addedparent of 0002891
05-11-2015 09:31vdemidovRelationship addedparent of 0002892
11-11-2015 15:30vdemidovRelationship addedparent of 0002900
11-11-2015 15:31vdemidovRelationship addedparent of 0002901
03-03-2016 11:55vdemidovRelationship addedparent of 0002975
10-06-2016 07:39vdemidovTarget Version26xxxx => 191221
10-06-2016 07:40vdemidovNote Added: 0017325
10-06-2016 08:37vdemidovTarget Version191221 => 160707
10-06-2016 17:31zedNote Added: 0017333
11-06-2016 17:45vdemidovStatusconfirmed => resolved
11-06-2016 17:45vdemidovFixed in Version => 160707
11-06-2016 17:45vdemidovResolutionopen => fixed
11-06-2016 17:45vdemidovAssigned To => zed
12-06-2016 09:09vdemidovRelationship replacedrelated to 0002900
26-11-2016 09:41zedRelationship addedrelated to 0003155

Notes
(0012805)
vasketsov   
16-09-2013 16:34   
XE2 или XE4?
(0012806)
vdemidov   
16-09-2013 17:05   
Да хоть XE5. У меня XE2 установлена. А какую Zed на сервер для сборки поставит та и будет, я не думаю, что там принципиальная разница будет.
(0012808)
vasketsov   
16-09-2013 17:12   
Под XE4 проект не собирается капитально, юниты надо именовать с префиксами. Если нет желания перелопачивать всё и вся - значит XE2.
(0012809)
vdemidov   
16-09-2013 17:16   
Ну тебе виднее. Я не пробовал. Но переход на юникод нужен однозначно.
(0012812)
vasketsov   
16-09-2013 17:27   
Я ставил XE4 чтобы оттуда свистнуть файлы для Sensor API (и ещё несколько зависимых, которых в XE2 нет). Но даже после правки имён юнитов просто так их заюзать в XE2 не вышло из-за delayed. Сделал вывод, что переход 2007 -> XEn для n>2 слишком сложен для одновременной поддержки обоих компиляторов.
Возможно где-то конечно и недодумал.
Также для GR32 (или чего-то такого столь же важного) нет поддержки XE4.
(0014605)
zed   
04-09-2014 06:00   
Открыл для себя фреймворк Synops mORMot. По поводу работы со строками, в нём заложена идея вообще отказаться от типа string (который в разных версия Delphi, разный), а использовать свой переопределённый тип и внутри фреймворка работать только с utf-8 строками (у них этот тип строк назван RawUTF8), чтобы независимо от версии Delphi была однотипная работа со строками. Соответственно, они переписали SysUtils и всё что касается работы со строками, плюс хорошенько оптимизировали полученный код. Всё это дело живёт в ОЧЕНЬ большом юните SynCommons.pas.

Из описания:

Our mORMot Framework has 100% UNICODE compatibility, that is compilation under Delphi 2009 and up (including latest XE6 revision). The code has been deeply rewritten and tested, in order to provide compatibility with the String=UnicodeString paradigm of these compilers. But the code will also handle safely Unicode for older versions, i.e. from Delphi 6 up to Delphi 2007.

Since our framework is natively UTF-8 (this is the better character encoding for fast JSON streaming/parsing and it is natively supported by the SQLite3 engine), we had to establish a secure way our framework used strings, in order to handle all versions of Delphi (even pre-Unicode versions, especially the Delphi 7 version we like so much), and provide compatibility with the FreePascal Compiler.

Some string types have been defined, and used in the code for best cross-compiler efficiency (avoiding most conversion between formats):
- RawUTF8 is used for every internal data usage, since both SQLite3 and JSON do expect UTF-8 encoding;
- WinAnsiString where WinAnsi-encoded AnsiString (code page 1252) are needed;
- Generic string for i18n (e.g. in unit mORMoti18n), i.e. text ready to be used within the VCL, as either AnsiString (for Delphi 2 to 2007) or UnicodeString (for Delphi 2009 and later);
- RawUnicode in some technical places (e.g. direct Win32 *W() API call in Delphi 7) - note: this type is NOT compatible with Delphi 2009 and later UnicodeString;
- RawByteString for byte storage (e.g. for FileFromString() function);
- SynUnicode is the fastest available Unicode native string type, depending on the compiler used (i.e. WideString before Delphi 2009, and UnicodeString since);
- Some special conversion functions to be used for Delphi 2009+ UnicodeString (defined inside {$ifdef UNICODE}...{$endif} blocks);
- Never use AnsiString directly, but one of the types above.

User Interface layer that you may convert explicitly the RawUTF8 content into the generic VCL string type, using either the Language. UTF8ToString method (from mORMoti18n.pas unit) or the following function from SynCommons.pas:

/// convert any UTF-8 encoded String into a generic VCL Text
// - it's prefered to use TLanguageFile.UTF8ToString() in mORMoti18n.pas,
// which will handle full i18n of your application
// - it will work as is with Delphi 2009+ (direct unicode conversion)
// - under older version of Delphi (no unicode), it will use the
// current RTL codepage, as with WideString conversion (but without slow
// WideString usage)
function UTF8ToString(const Text: RawUTF8): string;

Of course, the StringToUTF8 method or function are available to send back some text to the ORM layer.

A lot of dedicated conversion functions (including to/from numerical values) are included in SynCommons.pas. Those were optimized for speed and multi -thread capabilities, and to avoid implicit conversions involving a temporary string variable.

Warning during the compilation process are not allowed, especially under Unicode version of Delphi (e.g. Delphi 2010): all string conversion from the types above are made explicit ly in the framework's code, to avoid any unattended data loss.
(0014608)
vdemidov   
04-09-2014 18:24   
Ну так давай, хотя, это несколько расходится с моими мыслями о переходе везде на 2-х байтный юникод, что бы потом в интерфейсах использовать WideString с меньшими расходами, но это такое отдаленное будущее, что бог с ним...
Мне честно говоря очень не хватает новых плюшек делфи.
(0014609)
zed   
04-09-2014 19:13   
>использовать WideString
Это тип строк работает убийственно медленно. Их вообще не стоит использовать без острой необходимости. Лучше старый добрый PAnsiChar, через который и utf-8 прекрасно передаётся.
(0014610)
vdemidov   
04-09-2014 20:37   
> Это тип строк работает убийственно медленно.
За все нужно платить. Зато эти строки можно передавать в dll на любом языке скомпилированную в любом компиляторе и обратно без малейших проблем. А это для интерфейсов достаточно важно.

Но я же говорю, что это не существенно и не предлагаю так делать.

И вообще я за скорейший переход на более свежую версию делфи.
(0015615)
vdemidov   
20-04-2015 07:21   
Какие у нас остались проблемы с переходом на юникодную версию делфи кроме регекспов?
(0015616)
zed   
20-04-2015 07:54   
А что с регэкспами? Там же widestrig под юникодом. Медленно, но надежно.

Думаю, можно выпускать юникодную сборку для тестов и звать китайцев, чтобы они нас багрепортами забросали. Тогда будет более-менее понятно.
(0015617)
vasketsov   
20-04-2015 12:59   
А парсеры и читалки уже умеют отличать буфер и файл с диска соответственно, юникодный он или нет?
А сохранять файлы всегда в юникоде будете?
(0015619)
vdemidov   
20-04-2015 13:54   
Об этом и вопрос. В большинстве мест там уже есть определение типа текстовых файлов. Но везде ли оно правильно сделано?
(0015620)
vasketsov   
20-04-2015 14:33   
>В большинстве мест там уже есть определение типа текстовых файлов
Хм. Видимо мы друг друга не очень понимаем. Но мне кажется, что про большинство мест ты несколько погорячился.

Возьмём для примера файл mp (польский формат).
Он может быть не юникодный, но в заголовке указана кодировка.
Я не помню такого куска кода, который бы это нюхал и конвертировал в юникод или текущую кодировку, а без этого что-то искать в общем случае бессмысленно.
И в принципе я поднимал вопрос с определением того, вот конкретно взятый буфер с текстом юникодный или нет, интереса оно у вас не вызвало. А между тем это первое, что надо делать после чтения любого файла, если мы хотим с ним работать как с текстом. У меня есть такой пример в коде внутреннего httpd.

Тайл векторный внезапно прилетит юникодный - залетит в хранилище, а потом нормально поднимется из хранилища и покажется?

Сохранение тайла должно быть в том же виде, как он был при чтении (например, настроек), это есть? Нет.

У HashFunction есть расчёт хэша по WideString? Нет. А между тем, где оно будет форсироваться после проверки, оно должно быть.

Экспортилка меток на alcinoe ансишная - форсировать UTF8 и надеяться, что всех китайцев это устроит? ))) SML тоже UTF8 ЕМНИП.
В принципе по каждому сохраняемому типу файлов надо понимать, в каком виде надо уметь их сохранять. Потому что если потом встать в позу, что мы сохраняем файл как юникод, а то что следующая программа в рабочей цепочке его не понимает или устройство его не принимает это не наши проблемы, поза будет внезапно очень глупая. Это касается привязок, экспортов и т.п. Даже там, где нет юникода, может прокатить AnsiString и прямое указние кодировки, но перекодировка обязана возникнуть, а сейчас её нет.

Также ЕМНИП была проблема с текстом в IInternalDomainInfoProvider сотоварищи: contenttype описан как AnsiString, а в провайдерах String. Хотя конкретно это может и мелочь.

Это только то что я помню сходу. Но даже этого достаточно.
(0015622)
vdemidov   
20-04-2015 14:54   
>Возьмём для примера файл mp (польский формат).
>Он может быть не юникодный, но в заголовке указана кодировка.
Основной вопрос станет ли он работать хуже чем работает сейчас сейчас там используется TStringList.LoadFromStream(VDataStream) вот и нужно смотреть что оно там в новой делфи загрузит.

> Тайл векторный внезапно прилетит юникодный - залетит в хранилище, а потом нормально поднимется из хранилища и покажется?
Для kml/kmz есть определения кодировки, так что тут проблем нет.

> Сохранение тайла должно быть в том же виде, как он был при чтении (например, настроек), это есть? Нет.
У нас вообще нет сохранения векторных тайлов кроме конвертации kml<->kmz, но там проблема не возникает, как и для сохранения растров.

> У HashFunction есть расчёт хэша по WideString?
Там есть расчет хэша по текущему типу строк, его более чем достаточно.

> Экспортилка меток на alcinoe ансишная - форсировать UTF8 и надеяться, что всех китайцев это устроит? ))) SML тоже UTF8 ЕМНИП.
Что тебя тут не устраивает?

> мы сохраняем файл как юникод, а то что следующая программа в рабочей цепочке его не понимает или устройство его не принимает это не наши проблемы, поза будет внезапно очень глупая
Увы, но я это переделывать буду, только если сам столкнусь с такой проблемой или за отдельные деньги, а до тех пор юникод наше все.

>Также ЕМНИП была проблема с текстом в IInternalDomainInfoProvider сотоварищи: contenttype описан как AnsiString, а в провайдерах String. Хотя конкретно это может и мелочь.
Ну, не считая импорта mp (тупого и такого наколенно-ущербного что дальше некуда) это первая реальная проблема о которой ты напомнил, но о ней напоминает и компилятор.

> Это только то что я помню сходу. Но даже этого достаточно.
Итого - ничего серьезного. Можно пробовать делать ночные сборки. Спасибо что успокоил.
(0015623)
vasketsov   
20-04-2015 15:27   
(edited on: 20-04-2015 15:28)
>TStringList.LoadFromStream ... нужно смотреть что оно там в новой делфи загрузит
А посмореть никак что ли? )))
Хотя куда более интересно, что оно сохранит, и как потом быть, если надо запустить старую версию саса.

>У нас вообще нет сохранения векторных тайлов
Уважаемый, Вы невнимательны. Речь была не о векторных тайлах, а о файлах вообще. Пример - настройки. В нужной пользователю кодировке.

>Что тебя тут не устраивает?
В Ansi-шном экспорте меток надо китайцев спрашивать, что их не устроит. Меня устраивает cp1251 может быть ))

>но я это переделывать буду, только если сам столкнусь с такой проблемой
Ну так значит кинешь всех, у кого такие проблемы будут, или zed будет вынужден собирать старые сборки в 2007 дельфе? В принципе, я такой позицией не удивлён, просто акцентирую на этом внимание.

(0015625)
vdemidov   
20-04-2015 17:48   
> А посмореть никак что ли? )))
Увы, на работе делфи нету, так что никак.

> Речь была не о векторных тайлах, а о файлах вообще.
Файлы вообще нас не интересуют. Нас интересуют текстовые файлы. Причем каждый конкретный тип сохраняемых данных требует своего подхода: некоторые форматы подразумевают юникод и уже сейчас сохраняются в UTF8, некоторые допускают только Ansi и соответственно уже сейчас там прописано использование AnsiString и следовательно будет работать как и сейчас. А некоторые типа ини-файлов разницы никакой лишь бы работало. Поэтому нужно говорить о конкретных файлах, а не в общем.

> В Ansi-шном экспорте меток надо китайцев спрашивать, что их не устроит. Меня устраивает cp1251 может быть ))
Хуже чем сейчас не будет, это факт.

>Ну так значит кинешь всех, у кого такие проблемы будут, или zed будет вынужден собирать старые сборки в 2007 дельфе?
И чем это их спасет? Но в общем и целом никто пока не призывает совсем отказываться от сборки в 2007 делфе. Речь о начале сборки в новой.

> В принципе, я такой позицией не удивлён, просто акцентирую на этом внимание.
Странно. Почему не удивлен. Я ведь эту позицию, что я никому ничем не обязан и это опенсорс, озвучивал всего пару десятков раз.
(0015626)
vasketsov   
20-04-2015 18:56   
> чем это их спасет?
файлы будут неюникодные.

>некоторые типа ини-файлов разницы никакой
Совместимость с предыдущей версией и одновременная работа из одной папки двух разных сборок не требуется?

>Речь о начале сборки в новой
Разве?
Читаю в заголовке: "Переход на версию Delphi с полной поддержкой юникода".
Мы о разному понимаем слово "Переход"?
Одновременная временная поддержка двух версий среды разработки - совершенно не "Переход", но лишь его ранняя предвестница.

>Речь о начале сборки в новой
Не вижу связи между словои "Переход" и словосочетанием "начале сборки в новой".
Ты именно предлагаешь ночнушки начать собирать в XE2 и только в этой версии?
Так это вообще не переход. Это даже не запах его на горизонте. Тем более что мне казалось, что сборка в XE2 уже выполняется и даже публикуется.
(0015627)
vdemidov   
20-04-2015 19:30   
> файлы будут неюникодные.
Какие конкретно и что это им даст?

> Совместимость с предыдущей версией и одновременная работа из одной папки двух разных сборок не требуется?
Нужно проверять конкретные места и если не работает заводить отдельные инциденты. Но ИМХО для этого достаточно что бы каждая версия могла читать юникод и анси, а писать в своем родном формате.
 
>Одновременная временная поддержка двух версий среды разработки - совершенно не "Переход", но лишь его ранняя предвестница.
Ну, это часть перехода. И ИМХО таки уже пора.

>Тем более что мне казалось, что сборка в XE2 уже выполняется и даже публикуется.
Когда кажется - креститься нужно.
(0015628)
vasketsov   
20-04-2015 21:31   
>ИМХО для этого достаточно что бы каждая версия могла читать юникод и анси
Это минимум, без которого говорить о переходе более чем наивно.
Сейчас ini и паскальскрипты в zmp читаются корректно в любом формате?
(0015630)
vdemidov   
21-04-2015 06:57   
> Сейчас ini и паскальскрипты в zmp читаются корректно в любом формате?
Вот, наконец, хоть какая-то польза из этого переливания из пустого в порожнее. Нужно проверить как юникодная версия сохраняет конфиги и читает их.

Zed, можешь сбилдить XE2 версию? А еще лучше было бы сделать хотя бы еженедельную сборку дебажной XE2 версии.
(0015631)
vasketsov   
21-04-2015 08:25   
>Вот, наконец, хоть какая-то польза
Ты издеваешься?
Ещё вчера в первом же сообщении я написал про "читалки" файлов. Потом конкретно уточнил "например, настроек" - ты это прочитал вообще, или просто по диагонали?
Если тебе кажется, что я излишне прямолинеен - это не повод не читать, что тебе пишут. Особенно когда в написанном содержится ответ на вопрос. Тогда бы и "переливания" удалось избежать.

>проверить как юникодная версия сохраняет конфиги и читает их
А ещё нужно проверить, как неюникодная версия поднимет юникодные ini-шки и скрипты. А поскольку ini-шки у нас правятся в том числе руками, для проверки этого не обязательно собирать U-версию и забирать из-под неё ini-шки, достаточно обычного блокнота. И я так уже делал. Результат не самый приятный, но в какой-то степени очевидный.

>еженедельную
Зачем? Еженедельно можно старую версию собирать. Если озабочены переходом - собирать новую надо ежедневно. При случае всегда можно откатиться на старую не более чем недельную.

А каких именно "новых плюшек делфи" не хватает, кроме юникода?
(0015632)
vdemidov   
21-04-2015 09:13   
>Ещё вчера в первом же сообщении я написал про "читалки" файлов.
Это общий свист ни о чем. Конкретное предложение это добавить чтение юникодных конфигов в текущую версию. Сейчас создам отдельный инцидент.

>А ещё нужно проверить, как неюникодная версия поднимет юникодные ini-шки и скрипты.
Только ini-шки. Скрипты пока будут жить в виде Ansi - для генерации урлов этого более чем достаточно.

> И я так уже делал. Результат не самый приятный, но в какой-то степени очевидный.
Вот и нужно было об этом написать.

> Зачем? Еженедельно можно старую версию собирать. Если озабочены переходом - собирать новую надо ежедневно. При случае всегда можно откатиться на старую не более чем недельную.
Ну, это если есть возможность. А на первое время хотя бы раз в неделю.

> А каких именно "новых плюшек делфи" не хватает, кроме юникода?
Ну лично мне, не хватает дженериков. Плюс некоторые плюшки самой среды разработки.
(0015633)
zed   
21-04-2015 16:15   
Периодически собираю для себя юникодную версию и запускаю прямо из рабочего каталога неюникодной версии, а потом наоборот, запускаю неюникодную. Соответственно, ни в той, ни в другой версии проблем с ini, zmp, метками и кэшем Беркли не наблюдаю. Настройки как хранились в win1251, так и хранятся.

По поводу билдов XE2, у меня есть задумка доделать автоматическое обновление SAS и добавить канал обновлений Nightly Unicode, чтобы все желающие могли тестировать. Соответственно, и билды в тот канал будут заливаться одновременно с билдами обычной ночнушки.

Ну и наконец, по поводу "плюшек" новых делфи. Лично я за то, чтобы в коде сохранялась совместимость с D2007.
(0015634)
vasketsov   
21-04-2015 17:35   
(edited on: 21-04-2015 17:36)
>не хватает дженериков
А мне Exit() не хватает.

>сохранялась совместимость
Очень тяжело себя сдерживать. Вчера только перед коммитом опомнился и вычищал такие вот Exit('') и т.п.

Вот пример:
TIeEmbeddedProtocol.LoadDataToStream

var
VContentType: string;

получается:
VDomain.LoadBinaryByFilePath(VFilePath, VContentType)

юзается:
PWideChar(WideString(VContentType))

С таким приведением типов компилятор просто затыкается и молчит.
Между тем совершенно непонятно, что делает здесь тип String, если ContentType определён как AnsiString:
  IInternalDomainInfoProvider = interface
    ['{CD84B08E-E84B-4688-9D9A-A9A34F29139D}']
    function LoadBinaryByFilePath(
      const AFilePath: string;
      out AContentType: string
    ): IBinaryData;
  end;

(0015636)
vdemidov   
21-04-2015 18:01   
> Очень тяжело себя сдерживать.
Именно

> Настройки как хранились в win1251, так и хранятся.
C одной стороны хорошо тем, что две версии работают без усилий.
Но тогда получается будут потери данных в юникоднрой версии. Так что хотелку 0002690 стоит реализовать.
(0015638)
zed   
21-04-2015 19:05   
>Очень тяжело себя сдерживать
Сдерживались же до этого, и вроде все живы.

В новых компиляторах много сюрпризов может быть: http://alexander-bagel.blogspot.com/2015/04/8.html В идеале, если и менять компилятор, то на самый стабильный. Кто готов назвать такой в ветке XE? Сама по себе XE2 уже устарела (выпощена в 2011 году). А с более новыми версиями (к примеру, если замахнуться на XE8), боюсь у нас с Toolbar2000 и EmbeddedWB будут проблемы.
(0015639)
vasketsov   
21-04-2015 19:44   
>Кто готов назвать такой в ветке XE?
По отзывам - как раз XE8 )))

>XE2 уже устарела
Переход на XEn, где n>2, вызывает сомнения.
В частности, на XE4 проект не собирается из-за префиксов, см. выше в теме.
Имхуется, что XE2 - необходимое зло, то самое, которое надо минимизировать, и без которого (перехода на которое) никак не двинуться дальше.

>EmbeddedWB
В SACS его нет уже очень давно. Выпиливается легко, пользы от выпиливания много.
(0015641)
vasketsov   
21-04-2015 22:52   
Сохранил GetUrlScript.txt в юникоде и открыл в супер-zed-отладчике - вот так он выглядит:

яюv

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

Собственно, поведение вполне ожидаемое, что и было написано выше.

Конкретно за паскальскрипты - это будете фиксить, или просто надо будет анонсировать, что скрипты не юникодные?
(0015642)
vasketsov   
21-04-2015 22:55   
Там же вдогонку: если скрипт был в UTF8, то читается он как Ansi:

п»їvar res:string;
    i:byte;
    osX,osY,prX,prY:integer;
begin
   res:=''; // проверка
(0015644)
vasketsov   
22-04-2015 01:03   
Хинты в главном меню отображаются знаками вопроса
(0015646)
zed   
22-04-2015 06:04   
>В SACS его нет уже очень давно. Выпиливается легко, пользы от выпиливания много.
А Toolbar2000 тоже предлагаешь выпилить?
(0015659)
vasketsov   
22-04-2015 10:44   
>Toolbar2000
Успеют, с нашей-то скоростью )))
(0015662)
zed   
22-04-2015 10:47   
Куда там. Судя по всему, мёртв он давно.
(0015666)
vasketsov   
22-04-2015 10:58   
Упс. Ну тогда будем решать по факту. Допиливать по месту или искать аналоги/замену.
(0015667)
vdemidov   
22-04-2015 11:00   
Ну нам нужно искать замену не Toolbar2000, а TBX, а для него есть аналог SpTBX
(0015739)
vasketsov   
25-04-2015 10:04   
На 2010-й дельфе пробовали пускать проект?
Я пожалуй откажусь от сборки под 2007, а то что-то какие-то косяки при установке 2007 на новую ось на ноуте. Версии 2010 и XE2 оставлю. Не ради новых фич, а просто жаль время разбираться, фичи пока подождут.
(0015740)
zed   
25-04-2015 10:19   
А смысл? Там же тот же юникод. Тогда уж переходи на XE2 сразу.
(0015741)
vasketsov   
25-04-2015 10:44   
Так XE2 и так на соседнем разделе есть. 2010 для других проектов надо поставить.
(0016195)
GunSmoker   
21-07-2015 06:16   
> "Под XE4 проект не собирается капитально, юниты надо именовать с префиксами."

Достаточно в опции проекта вписать нужные namespace.
(0016627)
vdemidov   
26-10-2015 10:51   
Предлагаю начинать выпускать ночные версии собранные в XE2. Это пока еще не даст нам полную поддержку юникода, но хотя бы позволит убедится, что юникодная версия работает не хуже собранной в D2007.
(0016628)
zed   
26-10-2015 12:15   
В дополнение к D2007 или вместо?
(0016629)
vdemidov   
26-10-2015 12:22   
Ну, на первое время, конечно, в дополнение. А там посмотрим по количеству багов и отзывов. Если будет слишком мало, то и вместо. Но вообще смотри по возможностям твоего билд сервера :) Как решишь так и будет.
(0016632)
zed   
26-10-2015 17:33   
Ок, в ночнушке теперь будет ещё один exe: SASPlanet.Unicode.exe - дебажная версия, собранная в XE2. Так же, пришлось добавить midas.dll из поставки XE2, чтобы там работали sml метки (см. http://www.sasgis.org/forum/viewtopic.php?f=47&t=2348).
(0016633)
vdemidov   
26-10-2015 18:28   
Спасибо большое. Пока пусть втихую появляется. А потом сделаем объявление с просьбой активнее тестировать.
(0016644)
vdemidov   
28-10-2015 19:48   
В общем, после того как соберется сегодняшняя ночная версия, я не вижу никаких препятствий для объявления о тестировании юникодной версии.
(0016645)
zed   
28-10-2015 20:00   
Да, можешь анонсировать. Хотя, сомневаюсь, что народ сильно заинтересуется.
(0016652)
vdemidov   
30-10-2015 10:00   
Заглянул в модуль libdb51 и теперь не понимаю как оно вообще работает в юникодной версии (по всем законом не должно).

Функция загрузки процедур из dll выглядит вот так:

  procedure LoadProc(var proc; const procName: string);
  begin
    pointer(proc) := GetProcAddress(DllHandle, pchar(procName));
    if pointer(proc) = nil then begin
      raise EBerkeleyDBExeption.Create(
        'Function ''' + procName + ''' not found in ' + DllName
      );
    end;
  end;

Но функция GetProcAddress определена только для PAnsiChar. Как она хавает юникодные строки я не понимаю.
(0016653)
zed   
30-10-2015 10:14   
А WinApi.Windows.pas из XE2 говорит нам что:

function GetProcAddress(hModule: HMODULE; lpProcName: LPCSTR): FARPROC; external kernel32 name 'GetProcAddress';
function GetProcAddress(hModule: HMODULE; lpProcName: LPCWSTR): FARPROC;
begin
  if ULONG_PTR(lpProcName) shr 16 = 0 then // IS_INTRESOURCE
    Result := GetProcAddress(hModule, LPCSTR(lpProcName))
  else
    Result := GetProcAddress(hModule, LPCSTR(AnsiString(lpProcName)));
end;
(0016654)
zed   
30-10-2015 10:15   
Но можно и пофиксить, для надёжности.
(0016655)
vdemidov   
30-10-2015 10:25   
Понятно. Это была настолько популярная бага, что для нее сделали костыль. Думаю лучше пофиксить для беркли и пнг
(0016677)
zed   
01-11-2015 10:53   
Using UTF-8 as the internal representation for strings in C and C++ with Visual Studio - та же идея работы со строками, что и в mORMot фреймворке, о котором я писал выше.

По-моему, крутейшее решение.
(0016680)
vdemidov   
02-11-2015 07:51   
Решение крутейшее, но не для делфи, где почти все компоненты и инструменты заточены на работу с юникодом. Например, как работать с ini файлом в utf-8 без полной перекодировки его в utf-16, если стандартный компонент для работы с ini-файлами в юникодной делфи работает только в utf-16. Но можешь попробовать в отдельной ветке.
(0016683)
zed   
02-11-2015 11:14   
>Например, как работать с ini файлом в utf-8
В SynCommons есть соответствующие функции. Там вообще много чего есть.

>Но можешь попробовать в отдельной ветке.
Спасибо за разрешение, но нет.
(0016684)
vdemidov   
02-11-2015 11:21   
>>Но можешь попробовать в отдельной ветке.
>Спасибо за разрешение, но нет.
Жаль. Было бы интересно посмотреть что из этого выйдет.
(0017325)
vdemidov   
10-06-2016 07:40   
Учитывая последние изменения в билд системе, похоже, что эту хотелку можно закрывать как выполненную?
(0017333)
zed   
10-06-2016 17:31   
Да.