[AlexandrY 3]

Каких имён?

Имен регистров.

 

Но что-то тема заглохла.

Мне показалась интересной идея формировать хидеры из PDF-ов.

И я для начала сварганил вот такой тестер регулярный выражений - https://github.com/Indemsys/Regular-Expression-Tester

Для тестирования реально больших файлов. В десятки мегабайт.

 

Интересно кто на питоне может так же быстро сделать такой интерактивный тестер.

Кстати потом и по скорости могли бы помериться, как раз на даташитах.

[dxp 34]

Имен регистров.

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

 

Парсер файлов, аналогичный вашему, на питоне писать не интересно - разбором текста там будет заниматься стандартная библиотека re, которая внутри реализована очень эффективно. GUI лепить тоже интереса нет, как и сохранять всё это в формате M$ Access. На практике куда удобнее и эффективнее пакетная обработка - скормил утилите файл, она выдала результат в виде файла (файлов).

 

Кстати, приоткрою завесу: формирование заголовочных файлов из того PDF выполнялось именно по такой схеме - пакетно. Конкретно было так: сначала PDF был преобразован в текстовый файл, далее шёл ручной этап - дополнение недостающих имён. И после этого парсинг описаний, таблиц и формирование всех трёх наборов заголовков. Текстовый файл, насколько помню, весил порядка 2.5 МБ (50+ тыс. строк). Никаких проблем не возникло.

[mantech 35]

И я для начала сварганил вот такой тестер регулярный выражений - https://github.com/Indemsys/Regular-Expression-Tester

Для тестирования реально больших файлов. В десятки мегабайт.

 

Но дельфя-же уже мертвый язык

[AlexandrY 3]

Парсер файлов, аналогичный вашему, на питоне писать не интересно - разбором текста там будет заниматься стандартная библиотека re, которая внутри реализована очень эффективно. GUI лепить тоже интереса нет, как и сохранять всё это в формате M$ Access. На практике куда удобнее и эффективнее пакетная обработка - скормил утилите файл, она выдала результат в виде файла (файлов).

 

Кстати, приоткрою завесу: формирование заголовочных файлов из того PDF выполнялось именно по такой схеме - пакетно. Конкретно было так: сначала PDF был преобразован в текстовый файл, далее шёл ручной этап - дополнение недостающих имён. И после этого парсинг описаний, таблиц и формирование всех трёх наборов заголовков. Текстовый файл, насколько помню, весил порядка 2.5 МБ (50+ тыс. строк). Никаких проблем не возникло.

В Delphi регулярные выражения - это тоже стандартная библиотека и даже мощнее чем в питоне.

Про GUI я даже не буду спорить. Преимущества GUI в повышении личной производительности очевидны еще со времен Windows 3.1.

А вот роль MS Acсess наверно даже не поняли. Но об этом позже расскажу.

 

И тоже приоткрою завесу. Чтобы еще быстрее и более автоматизировано парсить PDF-ы их надо переводить в HTML, а не в plain text.

[dxp 34]

В Delphi регулярные выражения - это тоже стандартная библиотека и даже мощнее чем в питоне.

Пруф насчёт мощнее?

 

Про GUI я даже не буду спорить. Преимущества GUI в повышении личной производительности очевидны еще со времен Windows 3.1.

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

 

А вот роль MS Acсess наверно даже не поняли.

Где уж нам. Очень важная информация в теме про питон. Странно, что кинетис тут не упомянут. Надо исправить этот недостаток и тиснуть об этом статейку на хабре.

[AlexandrY 3]

Где уж нам. Очень важная информация в теме про питон. Странно, что кинетис тут не упомянут. Надо исправить этот недостаток и тиснуть об этом статейку на хабре.

Почему же не упомянут.

Вот он парсер мануала на Kinetis K66 - :08:

Снята вся информация о 2182 регистрах.

Обработано 170 тыс. строк мануала.

Сами данные никак в ручную не корректируются, все проходит автоматом.

Все имена остаются оригинальными без всякой отсебятины.

Даже ссылки на секции и страницы мануала для каждого регистра даны.

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

 

Реально вся работа по парсингу проводится в базе данных. В данном случае это MS Access.

С такой базой уже дело техники сформировать хидеры любого формата с любым составом файлов, хоть все вместе хоть по файлу на каждый регистр.

 

Где там ваш питон? Ау!!

Пруфы в моей утилите, которую дал выше. Берите и сравнивайте.

 

И как питон можно обсуждать без сравнения с другими технологиями?

[one_eight_seven 3]

Где там ваш питон? Ау!!

В каком смысле? Что, правда думаете, что для питона нет коннекторов к БД, если уж очень хочется именно БД? Да всё есть, и ODBC, и JDBC, и прямые коненкторы к PostgreSQL, MySQL/MariaDB и прочим. В общем-то, как и для любого другого популярного языка. Вопрос в том, что дельфины уже мало кого интересуют, а питонистов работодатели хотят видеть. По большому счёту, инструмент должен соответствовать задаче, и обеспечивать простую поддержку после того, как разработчик уйдёт. Питон сегодня этим требованиям отвечает, Delphi - нет.

 

P.S. Да и порог входа в питон - куда ниже, при не уступающих возможностях.

Изменено 22 марта, 2018 пользователем one_eight_seven

[dxp 34]

Где там ваш питон? Ау!!

Пруфы в моей утилите, которую дал выше. Берите и сравнивайте.

Вы заявили, что библиотека работы с регулярными выражениями в дельфях круче, чем в питоне (что, конечно, глупость). Вот и докажите это! Например, что библиотека re питона не поддерживает каких-то фич или работает безобразно медленно по сравнению с дельфовой. Но вы этого не сможете сделать, потому что для этого надо знать обе реализации в практическом применении, а вы питоновую не знаете. Заметьте, никто не утверждает, что библиотека питона круче дельфовой. Может это так, может не так, мы не сравнивали, поэтому не можем ничего подобного утверждать. И вы тоже находитесь в такой же ситуации. Просто сказали глупость, почему бы это не признать.

 

А приводить в качестве доказательства преимущества библиотеки сторонее приложение - это пытаться слить вопрос на левую тему.

 

С этим вопросом мне всё ясно, продолжать его обсуждать не буду.

[AlexandrY 3]

а питонистов работодатели хотят видеть.

P.S. Да и порог входа в питон - куда ниже, при не уступающих возможностях.

А приятно чувствовать себя волшебником, все таки.

Пока один на питоне ковыряет командную строку,

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

При желании тоже дельфинское приложение переносит на смартфон хоть под андроидом, хоть на айфон.

 

Питон у программистов - это аналог ардуино у хардваристов.

Да, гвалт вокруг ардуино огромный, но K66 (ладно, STM32) дает непередаваемое чувство превосходства.

 

 

Вот и докажите это!

Началось с того что вы сделали некий крутой парсер, а исходники не выложили, предложив нам верить.

Сначала исправьте свой косяк.

[one_eight_seven 3]

А приятно чувствовать себя волшебником, все таки.

Это мнимое чувство.

Пока один на питоне ковыряет командную строку,

другой в Delphi за то же время делает гибкое GUI приложение с кучей фичей и отдает его просто пользоваться другим,

Разница в том, что и там, и там можно работать и в командной строке, и делать GUI.

 

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

Это до тех пор, пока не окажется, что это приложение не отвечает задачам. Вот видел кучу говнокода, сделанного по таким же шаблонам. И на крестах, и на Си, и на питонах, и на жабе.

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

[AlexandrY 3]

Разница в том, что и там, и там можно работать и в командной строке, и делать GUI.

Вопрос не в том можно или нельзя.

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

Примеры убеждают лучше всего.

 

Идея делать хидеры из pdf-ов однако благодатная.

Сейчас я в хидеры рядом с регистрами буду вставлять вот такие строки коментов:

 // "file://M.cmd 211"

А содержимое файла M.cmd такое :

start  /d "C:\Program Files (x86)\FOXIT SOFTWARE\FOXIT READER" /b FoxitReader.exe  D:\Embedded_uC\Kinetis\MK66\K66P144M180SF5RMV2.pdf /A page=%1

 

Таким образов в SlickEdit кликая на коммент в сорсах сразу открывается pdf мануал на нужной странице.

Это лайфхак такой.

[one_eight_seven 3]

Идея делать хидеры из pdf-ов однако благодатная.

Не в моей области. В моей области и в документацию (в том числе и pdf), и в header'ы для драйверов, и в тестбенчи, и в исходный код это всё попадает из одного первоисточника.

[esaulenka 5]

Господа, у меня вопрос, раз уж тут собрались специалисты по скриптовым языкам.

 

Есть железка, есть программа на Qt (моего авторства). Они обмениваются пакетами, в Qt-шной программе есть класс "пакет".

Для тестов регулярно приходится писать логику вида "если получили пакет А, а перед этим в пакете Б был флажок, то через 100 миллисекунд отправить пакет В".

Сейчас оно написано на C++ и скомпилировано с основной Qt-шной программой, для выбора нужного теста банально вызывается нужная функция.

 

Вопрос: как бы вынести этот функционал наружу в скрипты? QtScript пробовал, как-то криво оно связывается с плюсовой частью...

[_pv 52]

Вопрос: как бы вынести этот функционал наружу в скрипты?

если не понятно какой язык выбрать, берите lua.

только, пожалуй, не надо сразу какой-нибудь swig пытаться прикрутить особенно если

класс "пакет" один и не сильно большой.

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

хотя что-нибудь вроде https://github.com/vapourismo/luwra может жизнь облечить.

 

[dxp 34]

esaulenka, если хотите именно встроенный скриптовый движок, то, как уже сказали, Lua или Squirrel. Альтернативный путь - переписать (портировать) программу на PyQt5 (Python), тогда процесс написания, сопровождения, модификации всего приложения изрядно упрощается. Внешне это будет то же самое, работает без тормозов. Какой вариант предпочтительнее - сугубо выбор разработчика.