Мне тоже понадобился XCode для эпизодических задач. Не помню, но какой-то первый нагугленный вариант с ходу не завелся. Потом нашел OneClick macOS Simple KVM. Ничего не настраивал вроде бы — только добавил ядер и памяти до 16ГБ и пару раз уже расширял диск. Устройства не пробрасывал, интеграцию с буфером обмена тоже не делал. Процессор со встройкой (AMD Ryzen 5700G), SSD.
Особо вроде ничего не тормозит в XCode и AppCode. Единственное, что умирает на несколько секунд — это анимированная минимизация окна. Но так я делаю очень редко и лень искать, где что отключить.
Под структурой документа понимаете layout (расположение текста на странице) или что-то другое (например, раздел/глава)? По-моему, расположение текста на странице утилита определяет более-менее корректно.
Нашел старый файл, из которого был извлечен текст с параметрами -table -fixed 3
Пример извлечения текста
Events Since Last Reset (22-OCT-2015)
There are no events to display.
Battery Good
Longevity Remaining >5.0 years
@ Current Pacing Percentage(s)
Magnet Rate 100 min¯¹ Elective Replacement (ERT) Beginning of Life
End of Life (EOL) (BOL)
Leads Data Implant Previous Session Present Session
08 JUN 2015 28-OCT-2015
Atrial
Intrinsic Amplitude 1 mV 0.7 mV N.R. mV
Pace Impedance 400 Ω 290 Ω 300 Ω
Pace Threshold <0.50 V 0.2 V @ 0.4 ms
Ventricular
Intrinsic Amplitude 10 mV 9.1 mV N.R. mV
Pace Impedance 430 Ω 300 Ω 300 Ω
Pace Threshold <0.50 V 0.7 V @ 0.4 ms
Settings
Ventricular Tachy Settings
Ventricular Tachy Detection On
Rate 170 min¯¹
Duration 8 cycles
Atrial Tachy Settings
ATR Mode Switch -- min¯¹ --
Brady Settings Pacing Output
Mode VVIR Atrial -- V @ -- ms
Lower Rate Limit 60 min¯¹ Ventricular AUTO 1.2V @ 0.40 ms
Maximum Tracking Rate -- min¯¹ Sensitivity
Maximum Sensor Rate 130 min¯¹ Atrial -- mV
Paced AV Delay -- - -- ms Ventricular AUTO 1.48 mV
Sensed AV Offset -- ms Lead Configuration Split
A-Refractory (PVARP) -- - -- ms A-Pace --
V-Refractory (VRP) 250 ms A-Sense --
V-Pace Unipolar
V-Sense Bipolar
Daily Measurement
Atrial Ventricular
Date Amplitude Impedance Amplitude Impedance Threshold
(mV) (Ω) (mV) (Ω) (V)
27-OCT-2015 N.R. N.R. N.R. 290 0.6
26-OCT-2015 N.R. N.R. N.R. 280 0.7
25-OCT-2015 0.3 250 N.R. 280 Off
Page 1 of 5
Я тоже на фрилансе брал несколько подобных заказов, если в приложенных примерах файлов был текстовый слой. В результате к OCR никогда не приходилось прибегать.
Если есть текстовый слой, можно попробовать утилиту pdftotext, в частности с параметрами −layout/−table и затем парсить уже текст.
Сначала я тоже использовал только CapsLock для постоянного переключения между раскладками. Потом перешел на CapsLock/Shift+CapsLock, чтобы не задумываться о текущей раскладке. Потом пытался (пытаюсь) приобщиться к neovim и для этого перебиндил CapsLock на Esc (галочка Make Caps Lock an additional Esc). Стал выбирать, на что заменить CapsLock для переключения раскладки и решил попробовать временное переключение на другую раскладку по Left Win. Пока на этом варианте и остановился.
В Kubuntu/KDE тоже достаточно галочки в настройках. Сначала я использовал CapsLock/Shift+CapsLock чтобы переключаться между русской/английской раскладкой, но всё равно было не удобно, т.к. в основном мне нужен один язык (как правило, английский). Я выбрал Left Win, т.к. никогда этой клавишей не пользовался, но пока ещё не совсем привык и иногда промахиваюсь по Left Alt.
Добавил поддержку полных дублей (для уникальности учитывается еще позиция строки в файле), но пока это не проверял.
Добавил поддержку русского языка. В чистом виде массовое сравение pkg.go.dev/golang.org/x/text/collate тормозит, я даже форкнул библиотеку, чтобы некоторые внутренние струкутры сделать публичными и переиспользовать уже «вычисленные» данные. Но в результате обошелся парой «трюков» в функции сравнения строк в своем коде.
Время выполнения для русского языка (несмотря на другой алгоритм/реализацию/язык/компилятор результаты для Go и .Net оказались схожими):
$ time ./HugeFileSort 1GB.txt
seed: 1676191709148358132
Split done in 2.066s
Sort/Write done in 5.192s
TOTAL done in 7.258s
real 0m7,291s
user 1m6,773s
sys 0m4,695s
$ time ./HugeFileSort 10GB.txt
seed: 1676191614805000905
Split done in 24.541s
Sort/Write done in 39.46s
TOTAL done in 1m4.001s
real 1m4,018s
user 12m1,858s
sys 0m40,673s
$ time ./HugeFileSort 100GB.txt
seed: 1676191997311186498
Split done in 7m5.411s
Sort/Write done in 5m46.03s
TOTAL done in 12m51.441s
Если строки совсем одинковые (и текст, и число), то работать не будет. Возможно, если добавить еще позицию строки в файле для уникальности, то заработает.
С сортировкой строк посмотрю на досуге, спасибо.
Вчера попробовал реализовать другой алгоритм на Go.
Если файл не влазит в лимит (по умолчанию 1 ГБ), то разбиваем его на мелкие части (по умолчанию на 100 МБ). Для этого рандомно выбираем нужное кол-во строк (тут используется произвольный доступ к файлу) и сортируем их. Например, получились строки Груша.123, Земляника.321, Помидор.456.
Потом выполняем полный проход по файлу и распределяем строки по временным файлам — если строка меньше Груша.123, то в первый файл, если меньше Земляника.321 — то во второй и т.д. Если какие-то файлы всё равно получились больше лимита, то рекурсивно разбиваем их дальше.
В результате имеем список файлов, в каждом из которых все строки больше, чем в предудущих файлах и меньше, чем в следующих. Загружаем временные файлы по порядку, сортируем содержимое и пишем в результирующий файл.
Шаги распределения по временным файлам и загрузки/сортировки временных файлов паралеллятся, но в случае сортировки временных файлов с учетом порядка файлов и общего лимита по памяти.
В Go только побайтовая сортировка, соответственно другие варианты не реализованы. Почему-то при варианте Ordinal .Net вариант даже на 1 GB завис, поэтому запускал я его с вариантом по умолчанию LocalСulture.
Используются только стоковые реализации сортировки и бинарного поиска.
Время работы (потребление памяти для 100GB держалось на уровне 2.2-2.7 GB):
$ ./HugeFileSort 1GB.txt
seed: 1675673671845497510
Split done in 1.692s
Sort/Write done in 2.45s
TOTAL done in 4.143s
$ ./HugeFileSort 10GB.txt
seed: 1675673683524993942
Split done in 11.599s
Sort/Write done in 19.012s
TOTAL done in 30.611s
$ ./HugeFileSort 100GB.txt
seed: 1675674146313347712
Split done in 4m1.065s
Sort/Write done in 3m22.516s
TOTAL done in 7m23.581s
Для сравнения время работы оригинального варианта:
$ ./bin/Release/net7.0/Sort ../Generate/1GB.txt
SplitSort done in 00:00:04.6032571
Merge done in 00:00:02.5344427
$ ./bin/Release/net7.0/Sort ../Generate/10GB.txt
SplitSort done in 00:00:31.9568792
Merge done in 00:00:35.2578093
$ ./bin/Release/net7.0/Sort ../Generate/100GB.txt
SplitSort done in 00:05:03.6851885
Merge done in 00:09:11.5672847
Среда выполнения: Kubuntu 22.04.1, AMD 5700G, 64GB, SSD Samsung 970 Evo Plus $ go version
go version go1.20 linux/amd64
1. Попробуйте посмотреть рутокеновскими утилитами — может там видны все сертификаты. Или посмотреть в другой операционке.
2. Да, как я писал выше, не все умеют работать без КриптоПро.
3. Ограниченная лицензия на КриптоПро должна быть вшита в новый сертификат — по идее ничего покупать не надо.
4. Я всё делаю в виндовой виртуалке — основная ОС у меня Kubuntu. Это позволяет не захламлять основную операционку, использовать все утилиты/тулзы (некоторые работают только в Windows), а также при необходимости начать с чистого листа (сохраненного снапшота со свежеустановленной операционкой).
КЭП записывается на предоставляемый заявителем носитель ключевой информации (токен), сертифицированный ФСТЭК России или ФСБ России. УЦ ФНС России поддерживает ключевые носители формата USB Тип-А
В конце ноября получал в ФНС. Только надо предупредить, что вам нужен формат PKCS#11 (ключевые слова «активный ключ», «аппаратный ключ», «как для ЕГАИС») — и то они смотрят непонимающе. РуТокен должен быть ЭЦП 2.0 или ЭЦП 3.0, Lite не подойдет. Скорее всего будет вшита и ограниченная лицензия на КриптоПро на срок действия подписи (15 месяцев), так что покупать не придется.
Это работает только с ключами формата PKCS#11. Если у вас ключ формата КриптоПро CSP (вы выбираете при входе «Ключ ЭП», а не «Рутокен ЭЦП 2.0 и 3.0»), то без КриптоПро не получится.
Да, для максимальной безопасности ваших закрытых ключей нужно генерировать ключи на Рутокен ЭЦП 2.0 2100, серт. ФСБ, используя библиотеку PKCS#11 (формат «как для ЕГАИС»), тогда они будут неизвлекаемыми и, действительно не покинут память токена. Их нельзя будет ни перехватить, ни скопировать.
…
Если на Рутокен из семейства ЭЦП будет сгенерированы пассивные ключи формата КриптоПро CSP, как на Рутокен Lite, они так же будут извлекаемыми. В ФНС проставляют запрет экспорта, который будет запрещать копирование штатными средствами.
Мне тоже понадобился XCode для эпизодических задач. Не помню, но какой-то первый нагугленный вариант с ходу не завелся. Потом нашел OneClick macOS Simple KVM. Ничего не настраивал вроде бы — только добавил ядер и памяти до 16ГБ и пару раз уже расширял диск. Устройства не пробрасывал, интеграцию с буфером обмена тоже не делал. Процессор со встройкой (AMD Ryzen 5700G), SSD.
Особо вроде ничего не тормозит в XCode и AppCode. Единственное, что умирает на несколько секунд — это анимированная минимизация окна. Но так я делаю очень редко и лень искать, где что отключить.
Есть в go полиморфизм, не вводите в заблуждение. И проблемы в вашей системе вовсе не связаны с выбранным языком.
На 2022.3 у вас "perpetual fallback license", т.к. эта версия вышла до марта 2023г. — её можете использовать сколь угодно долго.
Можно еще для подобных простых утилит использовать Terminal UI — например так примерно будет выглядеть с библиотекой tview для Go:
Размер бинарника будет примерно 3-4мб.
Для манипуляций с PDF есть еще такая утилита pdfcpu. Написана на Go, может использоваться как библиотека из своих go-программ.
Под структурой документа понимаете layout (расположение текста на странице) или что-то другое (например, раздел/глава)? По-моему, расположение текста на странице утилита определяет более-менее корректно.
Нашел старый файл, из которого был извлечен текст с параметрами
-table -fixed 3Если есть текстовый слой, можно попробовать утилиту pdftotext, в частности с параметрами
−layout/−tableи затем парсить уже текст.Make Caps Lock an additional Esc). Стал выбирать, на что заменить CapsLock для переключения раскладки и решил попробовать временное переключение на другую раскладку по Left Win. Пока на этом варианте и остановился.Добавил поддержку русского языка. В чистом виде массовое сравение pkg.go.dev/golang.org/x/text/collate тормозит, я даже форкнул библиотеку, чтобы некоторые внутренние струкутры сделать публичными и переиспользовать уже «вычисленные» данные. Но в результате обошелся парой «трюков» в функции сравнения строк в своем коде.
Время выполнения для русского языка (несмотря на другой алгоритм/реализацию/язык/компилятор результаты для Go и .Net оказались схожими):
$ time ./HugeFileSort 1GB.txt
seed: 1676191709148358132
Split done in 2.066s
Sort/Write done in 5.192s
TOTAL done in 7.258s
real 0m7,291s
user 1m6,773s
sys 0m4,695s
$ time ./HugeFileSort 10GB.txt
seed: 1676191614805000905
Split done in 24.541s
Sort/Write done in 39.46s
TOTAL done in 1m4.001s
real 1m4,018s
user 12m1,858s
sys 0m40,673s
$ time ./HugeFileSort 100GB.txt
seed: 1676191997311186498
Split done in 7m5.411s
Sort/Write done in 5m46.03s
TOTAL done in 12m51.441s
real 12m51,525s
user 128m25,751s
sys 7m27,114s
С сортировкой строк посмотрю на досуге, спасибо.
Если файл не влазит в лимит (по умолчанию 1 ГБ), то разбиваем его на мелкие части (по умолчанию на 100 МБ). Для этого рандомно выбираем нужное кол-во строк (тут используется произвольный доступ к файлу) и сортируем их. Например, получились строки
Груша.123,Земляника.321,Помидор.456.Потом выполняем полный проход по файлу и распределяем строки по временным файлам — если строка меньше
Груша.123, то в первый файл, если меньшеЗемляника.321— то во второй и т.д. Если какие-то файлы всё равно получились больше лимита, то рекурсивно разбиваем их дальше.В результате имеем список файлов, в каждом из которых все строки больше, чем в предудущих файлах и меньше, чем в следующих. Загружаем временные файлы по порядку, сортируем содержимое и пишем в результирующий файл.
Шаги распределения по временным файлам и загрузки/сортировки временных файлов паралеллятся, но в случае сортировки временных файлов с учетом порядка файлов и общего лимита по памяти.
В Go только побайтовая сортировка, соответственно другие варианты не реализованы. Почему-то при варианте
Ordinal.Net вариант даже на 1 GB завис, поэтому запускал я его с вариантом по умолчанию LocalСulture.Используются только стоковые реализации сортировки и бинарного поиска.
Время работы (потребление памяти для 100GB держалось на уровне 2.2-2.7 GB):
$ ./HugeFileSort 1GB.txt
seed: 1675673671845497510
Split done in 1.692s
Sort/Write done in 2.45s
TOTAL done in 4.143s
$ ./HugeFileSort 10GB.txt
seed: 1675673683524993942
Split done in 11.599s
Sort/Write done in 19.012s
TOTAL done in 30.611s
$ ./HugeFileSort 100GB.txt
seed: 1675674146313347712
Split done in 4m1.065s
Sort/Write done in 3m22.516s
TOTAL done in 7m23.581s
Для сравнения время работы оригинального варианта:
$ ./bin/Release/net7.0/Sort ../Generate/1GB.txt
SplitSort done in 00:00:04.6032571
Merge done in 00:00:02.5344427
$ ./bin/Release/net7.0/Sort ../Generate/10GB.txt
SplitSort done in 00:00:31.9568792
Merge done in 00:00:35.2578093
$ ./bin/Release/net7.0/Sort ../Generate/100GB.txt
SplitSort done in 00:05:03.6851885
Merge done in 00:09:11.5672847
Среда выполнения: Kubuntu 22.04.1, AMD 5700G, 64GB, SSD Samsung 970 Evo Plus
$ go version
go version go1.20 linux/amd64
$ dotnet --version
7.0.102
Быстрокод: github.com/falconandy/HugeFileSort
2. Да, как я писал выше, не все умеют работать без КриптоПро.
3. Ограниченная лицензия на КриптоПро должна быть вшита в новый сертификат — по идее ничего покупать не надо.
4. Я всё делаю в виндовой виртуалке — основная ОС у меня Kubuntu. Это позволяет не захламлять основную операционку, использовать все утилиты/тулзы (некоторые работают только в Windows), а также при необходимости начать с чистого листа (сохраненного снапшота со свежеустановленной операционкой).
Выбор модели Рутокен для получения ЭП в УЦ ФНС России и Доверенных лицах УЦ ФНС России
С Type-C могут отказать.
Там есть ссылки — одна на Рутокен Плагин, вторая на браузерное расширение Адаптер Рутокен Плагин (в зависимости от браузера)
Для Linux еще наверно нужны шаги отсюда, точно сейчас не помню: Рутокен ЭЦП в операционных системах GNU/Linux