LINUX.ORG.RU
ФорумTalks

Вышел True hackers' reader 0.23

 , , , ,


4

4

Состоялся релиз нового просмотрщика текстов (минималистичного аналога less'а) в однобайтных кодировках True hackers' reader 0.23.

Особенности реализации:

  • Читает содержимое файла в оперативную память и разблокирует текстовый файл, который больше программе не нужен. В отличие от less'а, который читает файл маленькими порциями, а потому требует чтобы файл продолжал присутствовать в системе. Это отличие позволяет True hackers' reader'у, например, читать кучу разных текстовых файлов с разных дискет в системе с одним дисководом. В то время как less заблокировал бы первую же дискету.
  • Несмотря на минималистичные исходники оперативную память расходует сильнее less'а, поскольку текст из файла хранится в буфере в оперативной памяти. Что, впрочем, значительно уменьшает время доступа к любой строке текста (тот же less при прокручивании N строк начинает обращаться к файлу, читать и прокручивать по одной строке с выводом промежуточных результатов, что очень медленно и в последних версиях при вводе цифры полученной при помощи '=' результат не всегда совпадает с ожиданием (что, собственно, и способствовало появлению True hackers' reader'а)).
  • True hackers' reader использует меньше чем less таких функций как, например, doupdate(). Как следствие, True hackers' reader на ARM'ах значительно шустрее чем less.
  • Локаль UTF-8 не поддерживается совсем. Если программа обнаружит локаль UTF-8, то её выполнение завершится ошибкой «Error: invalid locale (UTF-8) found».
  • В первых версиях присутствовали значительные ограничения на размеры текстовых файлов, которые были связаны с внутренними ограничениями библиотеки ncurses (внутренние размеры ncurses (а текст сразу выводился в окно ncurses, которое затем просто сколлилось) ограничены максимальным значением short int, что для x86_64 составляет 32767). Это приводило к тому, что программа могла отказаться читать текстовые файлы, размер которых превышал 2,5 Мб. О чтении текстовых файлов на десятки мегабайт не могло идти и речи. Начиная с версии 0.10 введён промежуточный буфер для текста (который, вопреки ожиданиям, не так уж и снизил скорость программы, но очень значительно сократил расход оперативной памяти) и программа начала открывать текстовые файлы на сотни мегабайт.
  • У программы есть 4 опции:
    -r - удалить файл после прочтения в оперативную память;
    -f - прокрутка по целой странице
            (по дефолту программа оставляет последнюю строку предыдущей страницы в самом начале новой);
    -t - заменить табы пробелами;
    -s - переформатировать текст по ширине экрана;
    
    Переключатель режима прокрутки доступен и во время работы программы по клавише 'f'. Опции должны указываться после пути к файлу, который всегда указывается первым аргументом. Если в первом аргументе программа обнаружит вместо пути к файлу одну из опций, то её выполнение завершится с ошибкой «Error: wrong options and path to file order».
  • Если программа обнаружит локаль KOI8-R, то в окне справки (вызывается по F1) появится надпись «Привет KOI8-R'щикам!». При другой однобайтной локали эта надпись будет отсутствовать.
  • В комплект входят два скрипта на bash'е: lzthreader, который разархивирует пожатый gzip/bzip2/lzma/xz/lzip текстовый файл во временный, а затем открывает его в True hackers' reader'е с опцией удаления файла, а также hexthreader, который при помощи утилиты Brutal squirrel ( http://saahriktu.org/downloads/brtlsqrrl-0.4.tar.xz ) преобразует файл в шестнадцатеричное представление, а затем открывает его в True hackers' reader'е с переформатированием по ширине экрана.

Скачать True hackers' reader и Brutal squirrel также можно по протоколу gopher при помощи команд

curl gopher://sdf.org/9/users/saahriktu/saahriktu.org/truehackersreader-0.23.tar.lzma > truehackersreader-0.23.tar.lzma
curl gopher://sdf.org/9/users/saahriktu/saahriktu.org/brtlsqrrl-0.4.tar.xz > brtlsqrrl-0.4.tar.xz

Скачать (3177 байт)

Перемещено Shaman007 из opensource

★★★★★

Последнее исправление: Shaman007 (всего исправлений: 2)

Не понял зачем это нужно, но на всякий случай осуждю.

anonymous
()
Ответ на: комментарий от saahriktu

экономить... оперативку... при том, что память выделяется огромными страницами... кхм

практически 1 экран это несколько мегабайт, совершенно всё равно на отдельные байты

anonymous
()

Это отличие позволяет True hackers' reader'у, например, читать кучу разных текстовых файлов с разных дискет в системе с одним дисководом

Лол. А как там с перфокартами, помогает читать?

spec_po_kiskam ★★★
()
Ответ на: комментарий от shdown

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

iluha16
()
Ответ на: комментарий от anonymous

практически 1 экран это несколько мегабайт

В структурах ncurses что-ли? Даже 120x36 экран - 4320 байт.

И, да, о том и речь, что если текст окажется уже экрана, то оперативки будет выделяться меньше.

saahriktu ★★★★★
() автор топика
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от iluha16

Настоящий хакер - сам редактор, ему не нужны костыли.

anonymous
()
Ответ на: комментарий от saahriktu

И для меня и для всех тех, у кого похожие задачи.

Что, есть еще кто-то, кого забыли госпитализировать?

madcore ★★★★★
()

использование Fn клавиш - не тру, не у всех они на клавиатуре есть без доп нажатий, особенно у хакеров.

Раскладку стоит заменить на Vim.

Юникод нужно поддержать, это отрицание не то, что 2k18, а аж 80ых.

nihirash ★★★
()

Кастануть бы сюда Терри А. Дэвиса, да жаль русского не знает и на ЛОРе не ошивается.

Thetan ★★★
()
Ответ на: комментарий от nihirash

использование Fn клавиш - не тру

С этим согласен.

telikan
()

Для просмотра больших файлов есть glogg - фактически GUI аналог less, что довольно удобно. А поделие в новости выглядит как приблуда для повыпендриваться перед коллегами.

bbk123 ★★★★★
()
Последнее исправление: bbk123 (всего исправлений: 1)
Ответ на: комментарий от saahriktu

На, держи, за тебя под валгриндом запустил:

==21538==
==21538== Process terminating with default action of signal 8 (SIGFPE)
==21538==  Integer divide by zero at address 0x1002E2D217
==21538==    at 0x1097B3: putpuwin (threader.c:103)
==21538==    by 0x109D05: main (threader.c:360)

P.S. threader.c:103 это

	return (rslt - txtbuf) / wtxt;

shdown
()
Последнее исправление: shdown (всего исправлений: 1)

Error: invalid locale (UTF-8) found

Типа специально показать свою принципиальность? А то может быть сделал бы свою поделку нужной, во всяком случае она бы запустилась не только у тебя. Базовая поддержка юникода не такая уж сложная.

KivApple ★★★★★
()
Ответ на: комментарий от shdown

Ну так это же не просто открытие файла. Кто в здравом уме будет что-то искать в пустом файле? Тут только открыть и закрыть.

А делить на ширину текста для определения номера строки при поиске нужно обязательно.

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

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

KivApple ★★★★★
()
Ответ на: комментарий от KivApple

Но, это уже немного другая реализация (в т.ч. и чтение не в unsigned char). Если брать по байту и пихать в юникодный терминал, то можно поломать парсеры юникода и через них юникодный терминал. Именно поэтому я и ввёл такое ограничение. А вот если заменить их на юникодные, то всё будет работать, да. Но, уже не с однобайтными локалями.

saahriktu ★★★★★
() автор топика

Мои глаза!

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

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

anonymous
()
Ответ на: комментарий от KivApple

Там не просто символы, а ещё и модификаторы. И надо всё это парсить чтобы понять где какой символ. И собирать из отдельных codepoint'ов соответствующие символы. Кому оно надо если можно обойтись однобайтной кодировкой?

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от mx__

Плохое железо у малины. Даже третьей. Повесить 4 USB, WiFi и Ethernet через хаб на один физический порт это идиотизм. У меня даже банальный стрим с вебки по сети глючил. Есть куча одноплатников более правильно сделанных (те же orange pi). Малина это УГ, но раскрученное и поэтому с самым большим коммунити.

KivApple ★★★★★
()
Ответ на: комментарий от crypt

Так у сабжевого пейджера есть фича, которой нет у less — отсутствие поддержки UTF-8.

theNamelessOne ★★★★★
()
Ответ на: комментарий от saahriktu

Если боишься поломать терминал невалидными последовательностями, можно парсить кодпойнты и выдавать уже их. Разумеется, сделать этот небольшой код отключаемым через опции сборки.

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от saahriktu

Для начала можно на это забитьи считать 1 кодпойнт 1 символом. Сейчас у тебя поддержка в любом случае хуже (вообще ничего не работает).

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 2)
Ответ на: комментарий от KivApple

Ему надо знать сколько литералов чтобы пробелы не уплыли. Это придётся отдельную переменную заводить — в одной байты, а в другой чаркаунт. Сложна.

anonymous
()
Ответ на: комментарий от saahriktu

Нет, это называется «я забил на граничные случаи, потому что на локалхосте не падает». Это допустимо, если ты не показываешь свой код никому, не будет code review, никто кроме тебя не будет это читать или дописывать. Публикуя же код на главной посещаемого ресурса ты претендуешь на нечто большее. Сейчас тут code review уровня /b и ты его не проходишь.

Shaman007 ★★★★★
()
Последнее исправление: Shaman007 (всего исправлений: 1)
Ответ на: комментарий от saahriktu

Кто в здравом уме будет что-то искать в пустом файле?

Кто будет в здравом уме пользоваться твоей программой, чтобы читать файлы с дискет в 2019?

Алсо, правильное поведение в случае «исключительной» ситуации (хотя просмотр пустого файла таковой ситуацией не является) — это показать пользователю сообщение об ошибке и, возможно, завершить работу, а не свалиться с сегфолтом/ошибкой деления на ноль.

theNamelessOne ★★★★★
()
Последнее исправление: theNamelessOne (всего исправлений: 1)
Ответ на: комментарий от saahriktu

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

anonymous
()
Ответ на: комментарий от KivApple

Это можно обрабатывать при чтении и падать с «Error: text not found». А если текст таки есть, то значение этой переменной сразу же перестанет быть нулём.

saahriktu ★★★★★
() автор топика
Ответ на: комментарий от Shaman007

Вот кстати да, у меня 90% кода на локалхосте такие, потому что меня устраивает. Но я и не показываю людям, в лучшем случае там реализовано 1/10 и до тех пор пока хотя бы некорректные данные не валидируются (что нужно далеко не всегда) мне будет слишком стыдно за моё говно, чтобы его показывать.

Наверное все думают по-разному, кому-то не стыдно.

anonymous
()
Ответ на: комментарий от saahriktu

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

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от Shaman007

Проверено: Shaman007

Зачем оно?

Не нужно — не проверяй. Серьезно, лучше бы удалил, 5 страниц новой унылой волокиты с саахрикту, который даже бомбить нормально не умеет, а надо ли оно?

Valman_old
()
Ответ на: комментарий от saahriktu

И для меня и для всех тех, у кого похожие задачи.

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

anonymous
()
Ответ на: комментарий от Valman_old

А потом будут говорить, что я душу опенсорц, человек старался, художника всякий норовит обидеть! Нет уж, тред полезен тем, что на него потом можно будет ссылаться в ответах любителям KOI-8. Всем четверым.

Shaman007 ★★★★★
()
Ответ на: комментарий от hobbit

Скажу за RPi 2 B+, которая вроде бы значительно медленее 3, со стоковым Raspbian: Firefox 52 и Chromium (Версию не помню) запускаются наверно минуту-две до появления окна, отклик на нажатие клавиш - десятки секунд. Включение экспериментального GL драйвера не помогает совсем (+ угрожает окончательно-бесповоротно испортить железо), ещё и половина шрифтов просто исчезает. Видео тоже ни одним из плееров (Без патчей руками), кроме стокового omxplayer из консоли не посмотреть, со всем остальным - тоже не лучше. Для сравнения: даже бюджетный ноут 2006 года (Но с нынешними линуксами и последними хромом/лисой) в разы быстрее.
Ах да, DE не пробовал, голый i3 поверх X11.

Deleted
()
Ответ на: комментарий от theNamelessOne

Алсо, правильное поведение в случае «исключительной» ситуации (хотя просмотр пустого файла таковой ситуацией не является) — это показать пользователю сообщение об ошибке и, возможно, завершить работу, а не свалиться с сегфолтом/ошибкой деления на ноль.

Это такой Ъ-юникс-вей: проверять на пустой файл и обрабатывать ошибки должны другие утилиты.

madcore ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.