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

Но что-то тема заглохла.
Мне показалась интересной идея формировать хидеры из PDF-ов.
И я для начала сварганил вот такой тестер регулярный выражений - https://github.com/Indemsys/Regular-Expression-Tester
Для тестирования реально больших файлов. В десятки мегабайт.

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

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

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

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

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

В Delphi регулярные выражения - это тоже стандартная библиотека и даже мощнее чем в питоне.
Про GUI я даже не буду спорить. Преимущества GUI в повышении личной производительности очевидны еще со времен Windows 3.1.
А вот роль MS Acсess наверно даже не поняли. Но об этом позже расскажу.

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

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


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


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

Почему же не упомянут.
Вот он парсер мануала на Kinetis K66 -

Снята вся информация о 2182 регистрах.
Обработано 170 тыс. строк мануала.
Сами данные никак в ручную не корректируются, все проходит автоматом.
Все имена остаются оригинальными без всякой отсебятины.
Даже ссылки на секции и страницы мануала для каждого регистра даны.
Статейка тоже будет, вот только закончу сертификацию нашей системы на Kinetis.

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

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

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

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

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

Сообщение отредактировал one_eight_seven - Mar 22 2018, 10:13

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

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

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

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

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



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

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

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


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

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

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

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


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

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

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

Есть железка, есть программа на Qt (моего авторства). Они обмениваются пакетами, в Qt-шной программе есть класс "пакет".
Для тестов регулярно приходится писать логику вида "если получили пакет А, а перед этим в пакете Б был флажок, то через 100 миллисекунд отправить пакет В".
Сейчас оно написано на C++ и скомпилировано с основной Qt-шной программой, для выбора нужного теста банально вызывается нужная функция.

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

если не понятно какой язык выбрать, берите lua.
только, пожалуй, не надо сразу какой-нибудь swig пытаться прикрутить особенно если
класс "пакет" один и не сильно большой.
лучше ручками хотя один раз бы проделать, для понимания как оно устроено.
хотя что-нибудь вроде https://github.com/vapourismo/luwra может жизнь облечить.

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