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

UPD: Конечно же указание формата -F rfc4180 здесь избыточно и неправильно, т.к. файл /etc/passwd в Unix-формате, с двоеточияи в качестве разделителей. Но Guile-DSV автоматически может определить разделитель в большинстве случаев, поэтому принудительное указание неправильного формата не повлияло на интерпретацию файла.

#dev #projects #guile #dsv

Guile-DSV 0.6.0 теперь в GNU Guix:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=43510204c631e59b9a5a38e09caeea94d7a94de2

Поставить/обновить можно командой:

guix install guile-dsv

#dev #projects #guile #dsv #guix

Сравнение скорости обработки текстовых данных через Guile-DSV.

В первом случае (верхняя синяя линия на графике) тест проходил на оригинальной версии Guile-DSV с рукописным ДКА, а во втором случае (оранжевая нижняя линяя на графике) — с ДКА, сгенерированным через Guile-SMC. Отладочный лог выключен. Используется реальное время работы программы, в секундах.

Размер тестового текстового файла:

$ wc datasets/covid.csv 
  53591   54463 3985948 datasets/covid.csv
$ du -h datasets/covid.csv
3,9M  datasets/covid.csv

Скрипт сбора статистики:
https://gist.github.com/artyom-poptsov/d53c10875e85cb735dd34e5a0f428bbe

#dev #guile #dsv

Исправил ошибки в профилировщике детерминированных конечных автоматов из поставки Guile-SMC, исправления пойдут в следующий релиз.

Использование профилировщика на примере Guile-DSV:

$ dsv --log-driver file --log-opt=file=smc.log -F rfc4180 --to unix datasets/covid.csv > test.csv
$ smc profile smc.log
Total transitions: 1661324
Total time:        84173181 us
Stats:
  read_quote: 30647003 us (36.4095 %)
  read_quoted_field: 27615130 us (32.8075 %)
  read_field_first_char: 23677038 us (28.1290 %)
  add_row: 2233946 us (2.6540 %)
  add_final_row: 35 us (.0000 %)
  read_first_field_first_char: 29 us (.0000 %)

Кусок файла smc.log:

$ head smc.log
2023-08-10 21:19:05.522313 (DEBUG): [*] -> [read_first_field_first_char]
2023-08-10 21:19:05.522342 (DEBUG): [read_first_field_first_char] -> [read_quoted_field]
2023-08-10 21:19:05.522377 (DEBUG): [read_quoted_field] -> [read_quote]
2023-08-10 21:19:05.522427 (DEBUG): [read_quote] -> [read_field_first_char]
2023-08-10 21:19:05.522448 (DEBUG): [read_field_first_char] -> [read_quoted_field]
2023-08-10 21:19:05.522483 (DEBUG): [read_quoted_field] -> [read_quote]
2023-08-10 21:19:05.522508 (DEBUG): [read_quote] -> [read_field_first_char]
2023-08-10 21:19:05.522527 (DEBUG): [read_field_first_char] -> [read_quoted_field]
2023-08-10 21:19:05.522556 (DEBUG): [read_quoted_field] -> [read_quote]
2023-08-10 21:19:05.522585 (DEBUG): [read_quote] -> [read_field_first_char]

#dev #projects #guile #dsv #smc

Провёл ещё один замер производительности Guile-DSV с новым ДКА, сделанным на базе Guile-SMC, используя датасет "Feed Grains: Yearbook Tables" на почти полмиллиона строк (498929 строк, если быть точным.)

Время на графиках в секундах.

Новая версия парсера работает быстрее старого на этом примере примерно в 15 раз.

Конечно, сорость обработки данных ещё зависит от самих данных и их формата. Например, парсер Unix-формата DSV работает быстрее, поскольку там нюансов меньше, и следовательно сам ДКА для Unix-формата проще.

#dev #projects #guile #dsv

Выпустил релиз Guile-DSV 0.7.0:
https://github.com/artyom-poptsov/guile-dsv/releases/tag/v0.7.0

Анонс в списке рассылки guile-user:
https://mail.gnu.org/archive/html/guile-user/2023-08/msg00050.html

Ключевые изменения:

- Guile-DSV теперь использует Guile State Machine Compiler (Guile-SMC) для генерации кода парсеров формата Unix и RFC 4180 из PlantUML описания во время сборки. Это изменение позволило сократить количество кода на Scheme, и сделать описание парсера более читаемое и краткое. Кроме того, новая версия парсеров работает от 3 до 15 раз быстрее старой версии (замеры: 1, 2).

- Процедуры dsv->scm и dsv-string->scm теперь поддерживают дополнительные именованные параметры: #:debug-mode? (включить/выключить режим отладки), #:log-driver (установить драйвер логирования; по-умолчанию используется "syslog"), #:log-opt (установить параметры драйвера логирования — см. документацию для детального описания.)

- Утилита dsv теперь также поддерживает опции --log-driver и --log-opt — см. dsv --help для справки.

#dev #projects #guile #dsv

Добавил возможность нумеровать столбцы и строки таблицы в Guile-DSV. Будет в следующем релизе.

#projects #guile #dsv #parser

Выпустил релиз Guile-DSV 0.7.1:
https://github.com/artyom-poptsov/guile-dsv/releases/tag/v0.7.1

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

Анонс в рассылке Guile-User:
https://mail.gnu.org/archive/html/guile-user/2023-10/msg00082.html

#guile #projects #dsv #parser

Обнаружил недавно проблему в Guile-DSV, что библиотека не проверяет консистентность длины строк табличных данных. Это не обязательно является проблемой в случае чтения данных, однако при обработке таблиц (например, при форматированном выводе на экран) это приводило к трудно осмысляемым ошибкам вроде:

$ echo -e "a,b,c\nd,e\n" | ./pre-inst-env ./utils/dsv
Backtrace:
In ice-9/boot-9.scm:
  1752:10  7 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
           6 (apply-smob/0 #<thunk 7f1b3a516300>)
In ice-9/boot-9.scm:
    724:2  5 (call-with-prompt _ _ #<procedure default-prompt-handle…>)
In ice-9/eval.scm:
    619:8  4 (_ #(#(#<directory (guile-user) 7f1b3a519c80>)))
In utils/dsv:
    272:8  3 (main _)
In dsv/table.scm:
   460:21  2 (format-table (("a" "b" "c") ("d" "e")) () #:width _ # _ …)
   347:27  1 (table-wrap (("a" "b" "c") ("d" "e")) _ #:width _ # _ # _)
   241:23  0 (table-wrap-row _ _)

dsv/table.scm:241:23: In procedure table-wrap-row:
In procedure car: Wrong type argument in position 1 (expecting pair): ()

Сейчас я исправил эту недоработку и добавил для процедуры dsv->scm опцию #:validate?, которая по-умолчанию выставлена в #f (false). Если же выставить её в #t (true), то тогда ошибка будет более понятной. Вот пример на тех же тестовых данных:

$ echo -e "a,b,c\nd,e\n" | ./pre-inst-env ./utils/dsv
Backtrace:
In ice-9/boot-9.scm:
  1752:10  9 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
           8 (apply-smob/0 #<thunk 7f1f270af300>)
In ice-9/boot-9.scm:
    724:2  7 (call-with-prompt _ _ #<procedure default-prompt-handle…>)
In ice-9/eval.scm:
    619:8  6 (_ #(#(#<directory (guile-user) 7f1f270b2c80>)))
In utils/dsv:
    272:8  5 (main _)
In dsv/cli/common.scm:
   144:38  4 (print-file #<input: file 0> unix "" _ #:numbering? _ # …)
In dsv/unix.scm:
    81:19  3 (dsv->scm _ #:debug-mode? _ #:delimiter _ #:validate? _ …)
In smc/fsm.scm:
   469:37  2 (_ #<fsm current-state: add_row statistics: 11/5 7f1f1…> …)
   426:22  1 (_ #<fsm current-state: add_row statistics: 11/5 7f1f1…> …)
In dsv/fsm/dsv-context.scm:
    100:2  0 (throw-row-length-error _ _ _ _)

dsv/fsm/dsv-context.scm:100:2: In procedure throw-row-length-error:
Inconsistent row length on line 10: expected 3, got 2 #<input: file 0> 10 0 ("d" "e") #<char-context 7f1f1d41a8c0>

По ходу дела выяснилось также, что парсер RFC 4180 похоже неправильно парсит некоторые сложные поля, где внутри поля содержится знак-разделитель. Это ещё требует дополнительного исследования.

И ещё выяснилось, что в Guile-SMC оказывается неправильно считаются строки в контексте functional/char.

#guile #dsv #smc #projects