САПР на Lazarus

[olegy123]

Как раз я писал про "сохранения знаний" и там где нужно еще сохранить объекты их описание и связи - лучше XML пока не придумали(может быть JSON как более компактный вид XML).
Но они не подходят для частого применения. Там уже применяется SQL.

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

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

[zub]

>>и там где нужно еще сохранить объекты их описание и связи - лучше XML пока не придумали
Под связями имеется ввиду древовидная структура? Наверно да, но в общем случае с связанными данными xml какраз не помошник.

Ладно, потихоньку перевожу текстовую мелочевку типа описания гуя на xml. Но не изза чудесных свойств оного, а изза лени тратить время на нормальные парсеры. Частенько бывают жалобы типа "поправил панельку инструментов, а зкад работать перестал"

[MylnikovDm]

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

Проект в 1.5 миллиона строк, это достаточно большой или как?
Используемый инструмент должен соответствовать решаемой задаче. Никто не спорит, что в целом структурированный файл лучше, как с точки зрения поддержания проекта, так и в случае необходимости быстрой правки в процессе отладки или эксплуатации. Поэтому в больших проектах для этих целей либо используется какая-то из готовых библиотек, либо пишется своя.
Кстати, если уж говорить об XML, то в FreePascal парсер XML более менее нормально заработал с кириллицей только в версии 3.0, когда допилили нормальную работу перекодировки строк и поддержку Unicode. А до этого момента приходилось кодировку постоянно самим руками шаманить.

Как раз я писал про "сохранения знаний" и там где нужно еще сохранить объекты их описание и связи - лучше XML пока не придумали(может быть JSON как более компактный вид XML).
Но они не подходят для частого применения. Там уже применяется SQL.

Существует масса структурированных языков описания данных помимо ХML. В той же промышленной автоматике и САПр давно и успешно применяются STEP и EXPRESS.
Также существует такая вещь, как бинарный XML, в котором вместо тэгов используются бинарные коды. Занимает заметно меньше места и парсится намного быстрее, чем текстовый формат. Но он только машинно читаемый, то есть, в обычном текстовом редакторе, как простой XML, вы его уже не исправите.

Что касается SQL, то я ещё раз повторяю, что это не структура хранения или даже описания данных! Это язык запросов к серверу реляционной СУБД. И если уж на то пошло, то хранить сложную структуру данных с большой и сложной иерархией объектов в реляционной СУБД не очень удобно, а в некоторых случаях даже нежелательно. Хотя, к явным преимуществам большинства SQL серверов следует отнести то, что при грамотном описании структуры данных, внутренних связей и ограничений, сервер сам будет поддерживать целостность связанных данных, чего в случае XML не будет никогда.

[olegy123]

>>и там где нужно еще сохранить объекты их описание и связи - лучше XML пока не придумали
Под связями имеется ввиду древовидная структура? Наверно да, но в общем случае с связанными данными xml какраз не помошник.

Ладно, потихоньку перевожу текстовую мелочевку типа описания гуя на xml. Но не изза чудесных свойств оного, а изза лени тратить время на нормальные парсеры. Частенько бывают жалобы типа "поправил панельку инструментов, а зкад работать перестал"

Я думаю, что потом заметете, что этот проект сам потом будет "перестроен" в сторону улучшения и универсальности.
Чтобы сохранить структуру - она должна быть структурирована.

Добавлено спустя 18 минут 26 секунд:

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

Проект в 1.5 миллиона строк, это достаточно большой или как?

1.5 миллиона строк - не о чем говорит. Вывод "Hello world" можно постараться растянут до 2мл строк.

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

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

Что касается SQL, то я ещё раз повторяю, что это не структура хранения или даже описания данных! Это язык запросов к серверу реляционной СУБД. И если уж на то пошло, то хранить сложную структуру данных с большой и сложной иерархией объектов в реляционной СУБД не очень удобно, а в некоторых случаях даже нежелательно. Хотя, к явным преимуществам большинства SQL серверов следует отнести то, что при грамотном описании структуры данных, внутренних связей и ограничений, сервер сам будет поддерживать целостность связанных данных, чего в случае XML не будет никогда.

я может не точно раскрыл зачем нужен - SQL, проясню: там где нужно обрабатывать большие данные и часто нужны вставки/изменения/удаления.
С обычными форматами легко можно потерять их, даже на этапе перезаписи..

Я вчера потерял диск, только потому что вместо формата qcow2 написал raw.. подключил диск (видимо была запись в структуру), в итоге все данные потерял.

[zub]

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

[olegy123]

Конечно, но не засчет xml.

А мне помогло. В итоге упростил на 20% подход к реализации задачи. Что главное, а что второстепенное, появилось универсальность.
Просто взял карандаш и начал писать сохранку:

Код: Выделить всё

<ObjectA>
  <ObjectB>


скоро, еще наверное на 20% упрощу.

[debi12345]

На самом деле данные вроде XML можно хранить и в SQLITE3-базе:

Код: Выделить всё

table_level1: id, text
table_level2: id, table_level1_id, text
...
table_levelN: id, table_level(N-1)_id, text

Плюсы:
- минимальная избыточность
- вся ништяки БД (поиск, группировка, транзакции, параметрические (прекомпилированные) запросы.,.)

Минусы:
- без ухищрений - фиксированное число уровней

Добавлено спустя 3 минуты 21 секунду:

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

Ага - подумаешь "какая мелочь" ))

[zub]

debi12345
Хоть что можно сделать хоть как. Каждый решает вмеру своей испорчености))

Свои потуги с тулбарами вынес отдельно http://svn.shamangrad.net/zcad/trunk/ca ... ztoolbars/ тамже простой пример использования. Естественно нужен транковый лазарь для компиляции))

[zub]

Вроде новый интерфейс закончил, выложил бинарник ревизии 2330. Прошу интересующихся потестить сохранение-восстановление разных конфигураций тулбаров.
На данный момент имеются такие оговорки:
-если тулбары не влазят на кулбар, автоматом переносятся на следующую строку
-если после манипуляций с тулбаром нужно восстановить его размер - делаем двойной щелчек по его грабберу
-высота "командной" строки самопроизвольно увеличивается - нерешеный баг анхордокинга
-переключалка раскладок окон "налету" иногда глючит на сложных раскладках - тоже баг анхордокинга

[zub]

Интерфейс полностью съехал на xml. в папке menu лежат файлы описания:
actionscontent.xml - описание экшенов, привязка зкадных команд к иконкам, капшенам и хинтам. для централизованного перевода и использования в описаниях меню и тулбаров
menuscontent.xml - описание меню, главного и попуп на разные случаи
toolbarscontent.xml - описание тулбаров

Для подстройки интерфейса файлы можно править руками, может когда нибудь руки дойдут до написания графической оболочки для этого увлекательного процесса))

[zub]

Убил день на ловлю багов - давно наблюдал проявление 2х вылетов при определенных условиях.
Первый - классический - тыкаю пальцем в небо через опечатку в имени переменной, потом ловлю вылет в случайном месте, был пойман с ходу.
А вот второй я не могу объяснить(( буду рад любой помощи:
На определенных данных наблюдается стабильный вылет в одном и том же месте. Есть тестовый чертеж и вылет воспроизводится 100%
Стек:

[FORMS.PP] ExceptionOccurred
Sender=EAccessViolation
Exception=Access violation
Stack trace:
$007744CA CACHE_DONE, line 360 of ttcache.pas
$00770B1D TT_DONE_GLYPH, line 952 of lazfreetype.pas
$0076CDC7 TFREETYPEGLYPH__DESTROY, line 840 of easylazfreetype.pas
$0040DC62
$004CF3B2 FREENODEDATA, line 1145 of laz_avl_tree.pp
$004CF384 TAVLTREE__FREEANDCLEAR, line 1154 of laz_avl_tree.pp
$0076D676 TFREETYPEFONT__DISCARDINSTANCE, line 1153 of easylazfreetype.pas
$0076E254 TFREETYPEFONT__DESTROY, line 1449 of easylazfreetype.pas //это и выше не мое
$007701B3 TTFFONT__DONE, line 479 of ./zengine/fonts/uzefontttf.pas //это и ниже мое
$006442CD GDBFONT__DONE, line 383 of ./zengine/fonts/uzefont.pas
$0044C495 GZVECTORPDATA$2$CRC093FB6BB__DONE, line 46 of gzctnrvectorpdata.pas
$0044C8B7 GDBFONTMANAGER__DONE, line 87 of ./zengine/fonts/uzefontmanager.pas
$0044D070 UZEFONTMANAGER_$$_finalize$, line 307 of ./zengine/fonts/uzefontmanager.pas
$00410249

Программа использует lazfreetype для поддержки ttf шрифтов и при закрытии на финализации менеджера шрифтов происходит AV внутри lazfreetype
Экспериментально выяснил падает если на момент GDBFONTMANAGER__DONE было определенное количество записей в лог. в лог пишу так:

Код: Выделить всё

procedure tlog.WriteToLog(s:AnsiString; ...);
begin
  ....
  OpenLog;
  FileWrite(FileHandle,PerfomaneBuf.parray^,PerfomaneBuf.count); // на этот момент в PerfomaneBuf.parray^ лежит PerfomaneBuf.count байт подготовленных для записи на диск
  PerfomaneBuf.Clear;
  CloseLog;
end;
procedure tlog.OpenLog;
begin
  FileHandle := FileOpen(logfilename, fmOpenWrite);
  FileSeek(FileHandle, 0, 2);
end;

procedure tlog.CloseLog;
begin
  fileclose(FileHandle);
  FileHandle:=0;
end;

Т.е. открываю файл, дописываю туда строчку, закрываю файл.
Проблема в количестве сделаных FileOpen операций, после определенного колва вылет.
Могу закоментировать всё кроме FileOpen - вылет остается. Могу закоментировать только FileOpen (или подсунуть ему невалидное имя файла) - вылета нет. Вылет повторяется и в винде и в линуксе... учитывая то что по крайней мере в винде FileOpen - просто обертка над апи функцией. Тупик какойто((

[olegy123]

на 100% уверен что есть протечка. ревизию кода надо делать. Течь может в другом месте.

Добавлено спустя 8 минут 53 секунды:
Тесть модулями Heaptrc, GDB в консоле больше даст ответов.

[MylnikovDm]

В lazfreetype есть косяки, которые приводят к краху программы. Сам на них натыкался. У меня это проявлялось, когда пытался один и тот же файл шрифта загрузить несколько раз. Также происходит вылет на некоторых шрифтах, причём не всегда, а когда используется символ, геометрию которого этот модуль не может нормально обработать, причём при каком-то определённом размере. На других размерах шрифта всё работает. Последняя ошибка встречается редко, видимо поэтому её не могут толком отловить.

Я пробовал посмотреть в коде lazfreetype и используемых им модулях, что и где падает, но там такой код, что без бутылки не разобраться. Разработчики явно перемудрили со всякими оптимизациями и играми с указателями. Кстати, по этой же причине ошибка в этом модуле может приводить к тому, что начинает рушиться вся программа и появляются наведённые ошибки в других местах, так как что там куда записалось по ошибочному указателю, предсказать невозможно. Так что не факт, что у тебя ошибка с логом и FileOpen. Скорее всего это наведённая ошибка из-за повреждений данных при ошибочной записи не туда.

Вроде как в новой версии FPC начали делать другой модуль для работы с TTF и OTF шрифтами. По крайней мере новая версия библиотеки для работы с PDF сейчас его использует. Но я его пока не тестировал, поскольку он есть только в транковых версиях, а я использую релиз и на транковую сейчас переходить возможности нет.

[vitaly_l]

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

PerfomaneBuf.Clear; <== вот эта строчка смущает, т.к. если записей было несколько, а она в первой уже сделала Clear; но это скорее всего ошибочное предположение.

А без записи в лог AV отсутствует или тоже есть?
А если "перенести запись" с помощью QueueAsyncCall - AV исчезнет?

Добавлено спустя 55 минуту 55 секунд:
Ещё можно в tru exception завернуть и может они чего-то подскажут, если сбой в этом месте. Утечки же, ведь нет.

[zub]

olegy123
течки конечно есть, сегодня их пофикшу, но баг наблюдаю очень давно, тогда кода который сегодня капает еще и в помине небыло. Классические рецепты - heaptrc, valgrind ничего не проясняют.
MylnikovDm
Насколько я понимаю lazfreetype это дословно переведеный с С на паскаль FreeType - поэтому внутри оно такое уродское. Других проблем я не встречал, хотя тестировал на очень экзотических шрифтах/символах, а тут имею глюк с arial.ttf(( Думаю проблема 100% у меня - уж больно странные условия ее воспроизведения и повторить на минимальной программе ничего не получается.
>>Вроде как в новой версии FPC начали делать другой модуль для работы с TTF и OTF шрифтами
Прежде чем думать о переходе, надо понять что с этим модулем нетак
vitaly_l
>>вот эта строчка смущает
Там всё в порядке - код работает кучу лет в таком виде. QueueAsyncCall - совсем из другой оперы))
>>Ещё можно в tru exception завернуть и может они чего-то подскажут.
Что они могут подсказать больше чем уже имеющийся стек?