Релиз Pisaahriktux 4.0 (Naagliteruufaetraceerefocozeneaxtoreial II) (комментарий)

вот это. хотя я помню, как старичок-препод в универе поставил мне трояк за то, что я ему сказала, что в C нет «текстовых и бинарных данных» и ничем они не отличаются, а есть только интерпретация. а у него была уверенность, что данные бывают текстовые и не-текстовые.

Может он думает что текстовые это те которые \r\n?

Эмм...

Какой нативный строковый тип данных в линукс

В С (Linux) нет аналогов CString или QString. В C нет вообще ничего похожего на string, если честно. Т.е., так, чтоб содержало длину строки + содержимое строки как минимум, а как максимум ещё и функции по работе с такого рода «строками». В С есть только «массив (array) символов». А уж какой он будет… Это дело десятое. Может представляться как int *, может как char * и в системе, которая полностью UTF-8 (ну, то есть там всё – и консоль и DE utfнутые), там совершенно пофиг. Все ф-ии, работающие с массивами, типа snprint()/printf()/sprintf()/read()/write/…, короче, все ф-ии ввода-вывода (точнее, все функции, без уточнения для ввода-вывода они или нет) будет работать с UTF-8 и можно не париться особо по данному поводу. Даже ф-ии по работе с регулярными выражениями, и те будут вести себя «прилично».

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

да и /r/n не везде. /r может и не быть и вообще это условности. этих управляющих символов в разных протоколах пруд пруди. а /r/n осталось в наследство ещё от старых терминалов.

старичок-препод в универе поставил мне трояк

Ну ты как с Луны упала. Нельзя быть умнее препода, это аксиома для экзаменуемого.

так я ему предлагала в начале года сразу сдать экзамен и не ходить на лекции. какого хрена? я к тому времени уже лет пять писала на сишечке. и даже сама её преподавала, подрабатывая репетиторством. остальным преподам по программированию я сдала экзамены сразу и у меня освободилось время для работы. а этот дедуля упёрся рогом: дескать, его сакральные знания невозможно не перенять. ну, я забила на посещение. а он, видимо, затаил обиду. но, блин, данные есть данные. просто последовательности байтов. ничего сакрального. текст и строка - понятия очень условные. до сих пор этот «возврат каретки» болтается в терминологии, хотя никто этой каретки живьём не видал уже лет пятьдесят.

там, внезапно, порядок с юникодом.

А где непорядок?

Тебе назвать, какие проблемы в LaTeX с юникодом? Например, он не поддерживает BOM. Например, каждый символ UTF-8 ему нужно задавать отдельно, что уже сделано в texmf-dist/tex/latex/base/utf8.def, но далеко не для всех символов. Например, отсутствие поддержки юникода не дает LaTeX использовать OpenType, которые прибиты гвоздями к юникоду.

В обоих случаях для выделения графической единицы придётся парсить этот юникод. если кто-то работает с не-ascii символами в utf-8 как с ascii - то вероятно и с utf32 он накосячит где-нибудь

Я не против того, чтобы использовать UTF-8 как входной формат. Выше разговор шел о том, что UTF-32 вообще не нужен, даже для внутреннего представления, «и так справимся» - на что я отвечаю: не справились, только XeTeX со внутренним представлением в UTF-32 справился. XeTeX пережевывает и UTF-8, и UTF-16, и ASCII.

если с utf-8 не справляется то тут дело в неосиляторах, а не utf-32

яннп

если что, use utf-8, Luke

(из соседнего):

вызывающихся и исполняющихся как единый блок.

следовательно сопрограммы и функции с entry отсекаются.

зы. и ужимки c longjmp()

если с utf-8 не справляется то тут дело в неосиляторах, а не utf-32

Ага, старые линуксоидные сказки «эта фича вам не нужна», «это не софт кривой - это вы не справились».

какие проблемы в LaTeX с юникодом?

Из всего перечисленного, меня не тронуло ни одно. Как так? Это ж ведь «проблемища»!

Из всего перечисленного, меня не тронуло ни одно. Как так? Это ж ведь «проблемища»!

Твои проблемы решались и при помощи koi8-r - тебе не нужен был юникод.

Твои проблемы решались

Не поверишь. Не было никаких «проблем».

Не поверишь. Не было никаких «проблем»

Ты не пользовался юникодом - у тебя не было никаких проблем. Проблемы начинаются, когда ты начинаешь использовать юникод, поскольку LaTeX не поддерживает юникод. А юникода нет - проблем нет. Юникод есть - проблемы есть. До тебя дошло или еще нет?

Ты не пользовался юникодом

По вангованию кол. Перезачёт!

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

Ты прям себя описала.

Вроде даже ICU внутри все декодирует в массивы целых непеременной длины перед трансформациями и поисками.

Вы не осилили прочесть тот коммент до конца?

Или до Вас какие-то детали «не дошли», если Вы их «не заметили»? Пожалуйста, перечитайте тот коммент внимательно и до конца.

Если не осилите, то уточняющий комменатрий здесь Максимально допустимый размер массива на стеке? (комментарий)

И дополнение здесь Максимально допустимый размер массива на стеке? (комментарий)

Большая просьба делать над собой усилие и дочитывать комментарии до конца и хотя бы пытаться понять что там написано. Так всем будет проще. Не стоит демонстрировать СДВ (синдром дефицита внимания) прилюдно.

следовательно сопрограммы

Сопрограммы не были и не являются частью стандарта С. О чём вообще речь? Они реализуются при необходимости программистом. И он же несёт ответственность за их реализацию.

зы. и ужимки c longjmp()

Это вполне валидное решение, за применение которого несёт ответственность программист.

P.S. И да, я тут добавлю что никаких нарушений в случае setjmp()/longjmp() нет. longjmp() переставляет стек в состояние, которое было установлено setjmp(), не более. Стек как был, так и остаётся, пролог/эпилог как были так и остаются, вызов вызываемой ф-ии (передача параметров, определение точки возврата, etc, как были так и остаются. Просто несколько более простой способ решить частные локальные проблемы и чуток сэкономить тактов процессора. Вполне валидный способ, который ничего не отменяет в части генерации кода компилятором.

Вроде даже ICU внутри все декодирует в массивы целых непеременной длины перед трансформациями и поисками

Не вроде, а точно. XeTeX именно ICU и использует.

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

Постоянно докапывалась, почему я на лекциях ничего не записываю, а что я должен был записывать, если мог сам эти лекции рассказывать? В общем на экзамене стала она также всякие тупые вопросы задавать, получил четвёрку в итоге. Сейчас смешно вспоминать, а тогда я просто офигел от несправедливости

И я свою могу рассказать. Один препод чуть не оставил меня на повторный курс по паскалю, на занятия второго препода по физике я сам перестал ходить после того, как он на лабах меня по ерунде гонял из-за того, что я не повторил его определения с лекции слово в слово. Это при том, что я был призерем областных олимпиад по физике, я уже тогда имел некий опыт писания на делфи, а потом много лет еще кормился этим делфи. Да, не нужно быть умнее препода.

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

сожалею.

а есть только интерпретация.

уровней напряжений/зарядов в полупроводниках. Удобный ответ на все вопросы. Строк в С нет, а куча функций str* есть. 42.

Прошу прощения.

Я слишком жёстко ответил. Видимо, устал просто от дискуссии.

ну, в LaTeX эти костыли исторически. в отличие от например troff в Plan-9 где utf-8 изначально.

исторически, в TeX была однобайтная ASCII кодировка, и какое-то своё расширение, вообще своя отдельная кодировка для русских букв, например. нативные тулзы TeX компилировали в .DVI, который очень простой – но расчитан на эту свою велосипедную кодировку.

затем появился PostScript с отдельной кодировкой ADOBE (cp1252 с умлаутами и кракозябрами, модифицированный; была в NeXT по дефолту). чтобы заставить его генерить с русскими буквами либо греческими и т.п. кодировкой нужно а) тексты писать либо бинарными в однобайтной кодировке либо лучше через номер символа, благо что диапазон задаётся больший 256, почти как уникод тот же; б) использовать шрифты, где такая кодировка есть. и если она есть для принтера в дефолтных шрифтах и его растеризаторе, далеко не факт, что они поддерживаются в дефолтных от GhostScript, например (где и остаются честные Adobe с кракозябрами). в) внедрять, встраивать embed шрифты непосредственно в сам генерируемый *.ps, ибо у клиента их может и не быть.

потом появились уникод шрифты, и к Type1 добавился Type3 и те же уникодные TrueType, OpenType. есть честный конвертор на перле из TTF в Type3 (расширенный Type1). можно посмотреть, сколько весят такие шрифты, например. или тот же cm-unicode из LaTex посмотреть, сколько весят, как устроены, какие диапазоны поддерживаются.

потом например этот PostScript можно генерить не только LaTeX-ом, но и Lout, например, с функциональной композицией. собственно, весь Lout наполовину написан на PostScript, на сишечке только меньшая часть. там исторически однобайтные кодировки, сам lout умеет перекодировать xlat в другие (то есть, можно писать например koi8 которая будет в \код символа автоматически перекодироваться). поддержка русского в lout – это aspell, переносы, xlat, embed шрифты в генерируемый PostScript. всё это есть, правда в основном не из коробки (из коробки там закомментировано всё, шрифтов нормальных Type1 нету потому что они как правило copyrighted). настройка lout под однобайтный русский – отдельный квест. уникод там ЕМНИП не поддерживается вообще (Type3 это закат солнца вручную), ядро lout про однобайтные кодировки, utf8 возможен с костылями. автор lout грозился переписать его заново и красиво (а не хаком на самом PostScript) – получился nonpareil – но он недописанный.

в LaTeX опять наступают на эти же грабли. с одной строны, у нас исторически своя специальная кодировка. с другой – в *.ps она своя. в *.pdf она тоже своя и уже ближе к полному уникоду. поэтому ядро TeX-а пытаются теперь переписать с нормальной поддержкой уникода. плюс тот же LaTeX или ConTeX как набор расширений базового TeX.

поэтому выплывают реализации TeX на Lua, или тот же XeLaTeX. где на эти грабли с уникодом наступили уже лет 15 назад, и уже это всё периписали заново, с нормальной поддержкой уникода в самом ядре.

вообще, сравнивая например LaTeX, lout и skribilo на Guile видно что где-то ядро с костылями, а где-то всё нормально и прозрачно с уникодными кодировками.

здесь наиболее компактно и уникод прозрачно сделаны troff в Plan 9. которые генерят документацию в нормальном PostScript с поддержкой уникода в utf-8. опять же, есть рисовалки формул, графиков, макросы, функционально аналогичные LaTeX-овым только в своём велосипедном языке разметки, типа того что из man.

всё что можно сделать в LaTeX можно сделать и в troff – просто нужно дольше читать документацию. кстати, GNU groff изначально хуже поддерживал уникод, там ещё какой-то набор скриптов MOM был чтобы удобнее было. а простой и наглядный был этот troff из plan9 с utf8 и ещё порт какого-то араба, nroff под Linux где тоже всё нормально с ядром, поддерживающим utf8.

вообще всё гораздо проще может быть, гораздо – если ядро программы нормальное и без костылей. например, тот же makedoc на REBOL написанный. весит примерно пару экранов текста. делает примерно всё тоже самое, что и latex. в RED с уникодом ЕМНИП, тоже всё нормально.

Ты не пользовался юникодом - у тебя не было никаких проблем. Проблемы начинаются, когда ты начинаешь использовать юникод, поскольку LaTeX не поддерживает юникод. А юникода нет - проблем нет. Юникод есть - проблемы есть

значит, скрипач уникод не нужен, родной. если и без него всё работает (и даже лучше и быстрее).

значит, уникод не нужен

Нужен конечно. Только нехрен молиться на него, как на «священную корову».

да и /r/n не везде. /r может и не быть и вообще это условности. этих управляющих символов в разных протоколах пруд пруди. а /r/n осталось в наследство ещё от старых терминалов

ЕМНИП, /n в Unix, /r/n в винде и досе, /r было в MacOS Classic (v9 и ниже). оттуда и пошло.

кстати, то что это всего лишь разная интерпретация одного и того же наглядно видно по тому же printf в cи или format в CL. разные символы для «возврата каретки», «число целое», «число флоат», «строка такая» «строка сякая, с выравниванием» и т.п.

и получается что рантайм языка навязывает свою интерпретацию строк. в этом смысле ввод-вывод в той же модуле или аде честнее ибо отдельные выводы по отдельным типам, нужно разбивать вручную. или полуавтомагически, макросами (например, в Nim AST макросы CTFE времени компиляции разбивают форматные си-строки на модула-подобное API, потом Nim компилирует это в сишечку, и собирает си компилятором).

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

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

эх, молодость, молодость…

был призерем областных олимпиад по физике, я уже тогда имел некий опыт писания на делфи, а потом много лет еще кормился этим делфи

тоже писал всякое олимпиадное и прочее, демонстрации физических процессов, моделирование и симуляции. параллельно на четырёх языках: паскаль, модула, дельфи, си++.

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

никакой мифической эффективности с++ ну вот вообще видно не было. а что компилируется дольше и весь этот edit-compile-run-debug цикл разработки медленне – ощутимо заметно.

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

а в py3 половина стандартной библиотеки свято верит, что имя файла представимо в юникоде (и есть немного костылей, чтобы запихнуть невалидный юникод в перевариваемый остальным питоном вид). Отсюда вывод: ~100% софта на python не умеет в линуксовые файловые системы.

и в итоге, пишем на каком-нибудь sphinx русскую доку в файле с русскими символами. парсим каким-нибудь ole tools на питоне *.doc чтобы переконвертировать в богоугодный markdown RST.

так эта зараза падает стектрейсами на простом обычном тексте. вывод: 80% полезного софта на питон не умеет в русские буквы, по факту. правда есть ощущение что в py2 это была 90%.

а не перекодировывали бы туда-сюда, и проблемы на ровном месте никакой бы не было.

А нахрена я буду конвертировать её в utf32 и обратно?

I like to move it, move it.

не помню конкретных версий питона, вордовских документов, кириллических имён файлов и содержимого – но вот в перекодировании в этот уникод оно стектрейсами и сыпалось.

питон такой питон. создали себе проблему на ровном месте. я вот вижу два питона: один py3, другой ooReXX (который совсем не питон а даже лучше). один 100 мегабайт и икру мечет по всему диску со всеми батарейками, другой 30 Мб, 10 Мб инсталлятор.

при этом и там и там расширяется примитивами на си. при этом и там и там легко читаемый синтаксис. в ooREXX правда, ещё метаклассы из смоллтока есть.

а в питоне зато GIL «из коробки», лол.

если не нужны питоновые батарейки – то питон как язык и не нужен от слова совсем.

неграммотный подход

sic

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

а потом удивляемся, отчего тот же веб тормозит. если даже в трёх соснах с уникодом и строками всё так сложно, медленно и печально. а дальше – больше: интерпретатор интерпретатора интерпретатора на интерпретаторе сидит и интерпретатором погоняет, на ровном месте. там, где ненужно.

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

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

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

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

Можем считать, что питон просто некому поддерживать - это весьма недалеко от реальной ситуации.

а и не нужно его поддерживать. засохнет – само отвалится и упадёт.

какое в ж бинарное дерево?

это вам, доктор.

(ну или можно эту лесенку из if-ов через Duff device закодировать).

будет работать с UTF-8 и можно не париться особо по данному поводу. Даже ф-ии по работе с регулярными выражениями, и те будут вести себя «прилично».

Если библиотека поддержки регулярных выражений не будет знать UTF-8, будут проблемы с регулярками, включающими не-ASCII последовательности.

дедуля сумел таки передать ей «сакральные знания» – одного похода на экзамен хватило ) его кунг С очень сильное

джедаи?

лесенка ифов лишь показывает правила парсинга, а как, чем и где - дело десятое, но бин деревья там явно лишние.

всё что можно сделать в LaTeX можно сделать и в troff – просто нужно дольше читать документацию. кстати, GNU groff изначально хуже поддерживал уникод, там ещё какой-то набор скриптов MOM был чтобы удобнее было. а простой и наглядный был этот troff из plan9 с utf8 и ещё порт какого-то араба, nroff под Linux где тоже всё нормально с ядром, поддерживающим utf8.

Я сейчас читаю сорцы groff, и в нем, судя по всему, построили какие-то собственные велосипеды для внутреннего представления юникода, а именно - текст разбивается на отдельные токены. То есть, строка внутри вообще не хранится как строка. Вроде такого:

struct S {
  const char *key;
  const char *value;
} unicode_decompose_list[] = {
  { "00C0", "20041_0300" },
  { "00C1", "20041_0301" },
  { "00C2", "20041_0302" },
  ...
}

class symbol {
  static const char **table;
  static int table_used;
  static int table_size;
  static char *block;
  static int block_size;
  const char *s;
  ...
}

вообще всё гораздо проще может быть, гораздо – если ядро программы нормальное и без костылей. например, тот же makedoc на REBOL написанный. весит примерно пару экранов текста. делает примерно всё тоже самое, что и latex. в RED с уникодом ЕМНИП, тоже всё нормально.

Побольше двух экранов, и поддерживает только HTML вывод:

https://web.archive.org/web/20120220060620/http://www.rebol.org/view-script.r...

значит, скрипач уникод не нужен, родной. если и без него всё работает (и даже лучше и быстрее)

Так я ж не спорю. Я до 2016 года разрабатывал софтину с однобайтовой кодировкой, и никто об этом не парился, потому что пользователи все были русские. И поиск по однобайтовой строке заметно быстрее юникода работал, раза так в полтора. Но потом внезапно выясняется, что пользователи используют в своей работе более 250 различных символов, и в таких случаях моя софтина идёт лесом.

долгое время не врубался, зачем он вообще нужен, с++ этот. если программы делали всё то же самое, компилировались быстрее, бинарники весили меньше и памяти жрали больше.
никакой мифической эффективности с++ ну вот вообще видно не было. а что компилируется дольше и весь этот edit-compile-run-debug цикл разработки медленне – ощутимо заметно

Я люблю на примере C++ демонстировать то, как, экономя тысячу рублей вчера на отсутствии необходимости миграции от Си, индустрия сегодня переплачивает миллионы за продолжение работы на C++, с иглы которого уже очень тяжело спрыгнуть. Индустрия могла бы писать даже на Brainfuck, если бы для него было много готовых решений, IDE с рефакторингом, и квалифицированных кодописак.

если не нужны питоновые батарейки – то питон как язык и не нужен от слова совсем

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

а и не нужно его поддерживать. засохнет – само отвалится и упадёт

Судя по тенденциям, оно ен собирается засыхать, а наоборот - гниет с увеличивающейся силой. Вот, асинхронные библиотеки делают.