|
Комментарии | #1 Автор: Nika (2020.04.28 20:52, изменений: 2, 2020.04.28 20:53) | Странным образом за двадцать лет ничего не захотелось в этой утилите изменить. Версия 0.03b это оттранслированная в WIN32 та же старая тулза. Ну, только одна махонькая некритичная ошибка в выводе на экран поправлена, и всё. Просто сейчас есть желание использовать эту тулзу и под Win64. |
#2 Автор: SergeCpp (2020.04.28 21:08) | А завершающие строку пробелы как удаляются? Что-то я не усмотрел на скрине. Или db2 это делает (неясно там, неужто совсем все пробелы удаляются).
s0 -- это как? |
#3 Автор: Nika (2020.04.28 21:21, изменений: 3, 2020.04.28 21:36) | -s0 -- это значит не заниматься сворачиванием строк вообще. Например, если нужна только перекодировка или только удаление ведущих пробелов.
А с удалением завершающих пробелов это таки идея, надо добавить. Просто всегда пользуюсь THE/KEDIT'ом, а в нём настройка уже такая есть. Так что просто не было такой нужды. Но идея заслуживает.
Сейчас по опции -db2 удаляются вообще все ненужные пробелы, и ведущие, и завершающие.
|
#4 Автор: SergeCpp (2020.04.29 05:45, изменений: 1, 2020.04.29 05:48) | -s0 -- неинтуитивно, -s- можно бы.
Я с этим игнорированием (неудалением) завершающих пробелов постоянно встречаюсь. И для VS делал команду (размещено здесь) и для Multi-Edit и ещё было.
-db2 описана так, что из " а б в " делает "абв".
А сжатие пробелов у вас есть? " а б в " (см. редактирование комментария) => " а б в " (остаётся по одному пробелу).
А замена таб на пробел? (один на один) (замена также 0x0 на пробел порой пригождается)
А расширение таб? (здесь нужно задавать размер табуляции) |
#5 Автор: SergeCpp (2020.04.29 05:59) | Резидентный print в dos всегда расширял табуляцию, считая её за 8. А у меня табуляция принтера настраивалась в multi-edit, пришлось из print это авторасширение убирать (ещё остановку по eof убирал). Это, вроде бы, в readme для multi-edit описано и указаны замены байтов для dos 6.22. |
#6 Автор: Nika (2020.04.29 12:28, изменений: 1, 2020.04.29 18:31) | -db2 работает так, что из "___а___б___в____" делает "_а_б_в_". Это для текстов. Всё довольно примитивно, табы не расширяются и считаются пробелами, насколько помню. |
#7 Автор: Nika (2020.04.29 17:11, изменений: 1, 2020.04.29 18:12) | Добавить опцию удаления только завершающих пробелов сложно - потому, что она станет конфликтовать с опцией -db2 (удалять все лишние пробелы в строке). .. Нет, вернее, так: Программа работает как примитивный фильтр с посимвольным чтением и записью. Поэтому невозможно определить, являются ли завершающие пробелы действительно завершающими, или там в строке будет ещё какой-то символ. Сделать такое можно, но это усложнение. |
#8 Автор: Nika (2020.04.29 22:39, изменений: 3, 2020.04.30 02:05) | Ну, сделал отдельно опцию удаления завершающих пробелов в строке. Потестирую пока.
--Добавлено-- Вроде бы работает, залил версию 0.04b.
Опция работает прозрачно для всего существующего алгоритма, только в конце каждой строки перенастраивает буффер выходнго файла, чтобы дальнейшие прочитанные символы исходного текста перезаписывали уже записанные туда пробелы, завершающие предыдущую строку. Это хотя и костыль в определённой степени, но оно работает. |
#9 Автор: SergeCpp (2020.04.30 17:20, изменений: 1, 2020.04.30 17:22) | Программа работает как примитивный фильтр с посимвольным чтением и записью. Поэтому невозможно определить, являются ли завершающие пробелы действительно завершающими, или там в строке будет ещё какой-то символ. Сделать такое можно, но это усложнение. ===
Если прочитан первый пробел после не-пробела, читаем, пока не встретится не-пробел, увеличивая счётчик прочитанных пробелов. Если встретился конец строки (файла), уходим из этого алгоритма. Если же иное, сперва пишем насчитанные пробелы.
У вас уже такая же логика вот тут усматривается: "db2 работает так, что из "___а___б___в____" делает "_а_б_в_". |
#10 Автор: Nika (2020.04.30 18:04, изменений: 5, 2020.04.30 18:24) | Можно и так, но это будет работать некорректно в том случае, если в строке между словами идут вперемежку пробелы и символы табуляции. Поэтому я такой вариант и изначально не стал рассматривать, и сейчас не стал им заниматься.
А теперь уже всё работает. И кстати, без подсчётов символов, тупо, но элегантно. При чтении пробела запоминается на всякий случай длина уже записанного выходного файла, и если по прочтении <cr/lf> с момента запоминания не было прочтено непробельных символов, то выходной файл обрезается по запомненному значению длины. Решение простое и эффективное.
Кстати, снова пережил незабываемые ощущения, когда не подключил <io.h> и ТурбоСи 2.0 для lseek(..) втихаря подставлял short вместо long. C WIN32-билдом при этом всё было в порядке, потому, что всюду по умолчанию long. |
#11 Автор: Nika (2020.04.30 18:32) | Кстати, у меня в THE-Editor'е на этой программе держится перекодировка DOS<->WIN блоков текста. Макрос сохраняет выделенный блок текста в файл, а потом запускает эту утилиту с нужными аргументами, после чего файл-результат записывается поверх исходного помеченного блока. Никакой другой способ реализации в виде макроса THE не дал бы удовлетворительной скорости работы.
Потому и пришлось потревожить старые исходники, - для того, чтобы иметь возможность пользоваться перекодировкой текста в редакторе и под Win64 системами, а не только под 32-битными. |
#12 Автор: SergeCpp (2020.04.30 19:07) | Если есть возможность, сравните, пожалуйста, намного ли медленнее у меня в Multi-Edit идёт перекодировка. Это нужно Shift+F3 запустить, и в нём на файле Alt+W (или Alt+D), там окошко подтверждения появится, там уже можно и нажимать вместе с секундомером. Там всё в макросе сделано. |
#13 Автор: SergeCpp (2020.04.30 19:18, изменений: 1, 2020.04.30 19:19) | А через внешний EXE (плюс файл-посредник для передачи туда-сюда) у меня сделано вычисление CRC32 для файлового ревизора (Shift+F3 и Alt+F7, вроде бы). Исходный текст этого внешнего EXE там где-то есть.
Ещё поиск в файлах с использованием perl-regexp тоже делается внешним RE.EXE.
Соответственно, в только-DOS это всё не работает (ещё есть Alt+Enter и Alt+F в файловом менеджере, который Shift+F3; ещё вызов архиваторов, кстати). |
#14 Автор: Nika (2020.04.30 19:42) | Сейчас попытаюсь это продедать. |
#15 Автор: Nika (2020.04.30 20:29, изменений: 2, 2020.04.30 20:51) | Ну, в общем так - ваш перекодировщик работает с файлом ~1Мб в течение 3-х секунд. Мой макрос из редактора отрабатывает на этом же файле в течение ~1.5 секунд. Между тем будучи запущенной вручную из командной строки программа line2000 перекручивает этот файл вообще за ..1/10-ую долю секунды. Это только подтверждает тот факт, что работа макросов в THE крайне медлительная. Она медлительная даже по сравнению с DOS'овским KEDIT'ом, который реализует тот же функционал касательно запуска макросов. И это значит, что чем больше размер обрабатываемого файла, тем большим будет разрыв между макро-реализацией в вашем ME7 и у меня в THE.
Кстати, для замера времени пользовался удобной программкой: OnlyStopWatch: http://www.softwareok.com/?seite=Microsoft/OnlyStopWatch/History
|
#16 Автор: SergeCpp (2020.05.01 05:19) | Nika, спасибо. А почему такая разница между макросом из редактора и самой программой?
У меня при работе файлового ревизора обмен туда-сюда через файл между макросом и EXE достигал, сколь помню, сотню и больше таких обменов в секунду на маленьких файлах (вычисление их CRC32) и на P166-MMX.
Для измерения времени и в NT4 ResKit есть программа хорошая и ещё какие-то у меня есть, но я уже не помню ничего. |
#17 Автор: SergeCpp (2020.05.01 06:27) | Причём, если я ставил там в макросе release_time_slice сразу же после записи в файл-посредник (я считал, что работа ещё ускорится, если ME отдаст сразу же квант внешнему EXE), то обмен -- замедлялся (!?.). Это там всё где-то в S-файлах есть в комментариях (и что-то есть в исходниках crc.exe). Это так было и в Win ME и в Win NT4. Но у меня внешний EXE запускался один раз в начале всего этого подсчёта и выгружался в конце (получив такой сигнал в файле-посреднике). |
#18 Автор: Nika (2020.05.01 10:24) | Огромная разница по времени связана с медлительностью самого макродвижка в THE-Editor'е. |
#19 Автор: SergeCpp (2020.05.01 10:30) | Мой макрос из редактора отрабатывает на этом же файле в течение ~1.5 секунд. Между тем будучи запущенной вручную из командной строки программа line2000 перекручивает этот файл вообще за ..1/10-ую долю секунды. ===
А если засечь в программе (запущенной из редактора) время (таймер-выхода - таймер-входа), то сколько будет? Если больше, чем при запущенной из ком. строки, то, может, приоритет EXE повысить, чтоб не вытеснялась, пока считает (у меня именно высокий, я посмотрел)? |
#20 Автор: Nika (2020.05.01 10:41) | Ничего не поменяется. Пока запущен SHELL, редактор время не расходует. А увеличение времени получается большей частью за счёт нерационального гоняния туда - сюда крупных файлов. Сперва редактор копирует весь помеченный блок в отдельное окно, потом сохраняет его в виде файла, и только после этого напускает на тот файл эту программку line2000.exe (теперь уже line2k32.exe). Потом в новое окно читается целиком полученный файл-результат, его содержимое помечается целиком как блок текста и этот блок вставляется поверх первоначально выделенного. То есть разбирается каждая строчка в исходном файле, где помечался текст, и в каждую строчку вставляется соответствующая строка из полученного результата перекодирования. Вот именно этот весь процесс и выполняется медлительно, но тут уж ничего не поделаешь.
|
#21 Автор: SergeCpp (2020.05.01 11:33) | 1) А если обрабатывать "по месту"?
1. Сохранить файл (если не сохранён). 2. Передать в EXE имя файла и координаты блока (сложнее, если квадратный и нестандартная табуляция). 3. Обработать в EXE эту часть файла (по крайней мере перекодировка ведь очевидно проста). 4. Обновить в редакторе.
2) А если без внешней программы, только макро, то будет заметно медленнее 1.5 секунд нынешних? Может, за счёт того, что уйдёт эта работа с файлами и окнами, где-то так и останется?
У меня, слабо припоминаю, что-то подобное есть при вставке из (или в) clipboard windows с преобразованием кодировок. Тоже между окнами что-то передаётся, не помню ни деталей ни почему так. Ага, чтобы исходный текст не менялся, то при отправке в clipboard текст копируется в новое окно, там преобразуется, и идёт в clipboard. |
#22 Автор: Nika (2020.05.01 12:46) | Без внешней программы будет на порядок(~ки) медленнее. А усложнять, в общем-то, примитивную программу нет никакого желания. В смысле поиска и обработки только фрагментов файлов. Сейчас, в общем-то, всё работает удовлетворительно. И у меня DOS-версия line2000.com осталась для KEDIT'а в DOS, а WIN32 версия line2k32.exe применяется в THE-Editor'е. |
#23 Автор: Nika (2020.09.08 14:47) | .. и не только в нём. Пользуюсь для сворачивания длинных строк в текстовых файлах книжек, скачанных в DOC,RTF и т.п. Поскольку читаю книжки всё равно в MultiEdit'е для Windows. |
| |
|