counting units for I/O

classic Classic list List threaded Threaded
57 messages Options
123
Reply | Threaded
Open this post in threaded view
|

counting units for I/O

Ruvim Pinka
Привет всем!

По стандарту WRITE-FILE & co. исчисляют размер в символах. Получается, что нет стандартного способа оперировать бинарными файлами. Особо актуально, когда размер символа не равен размеру юнита адреса.
По моему, WRITE-FILE должно исчислять в тех же юнитах, что и слово MOVE. А для символов (если необходимо) -- CWRITE-FILE (аналогично CMOVE -- префикс 'C').

Для протоколов обмена (в том числе и перенос файлов между машинами) важно исчесление в байтах (октетах), а не абстрактных address-unit. Поэтому, для всех операций ввода/вывода (сокеты, пайпы, файлы), нужна возможность исчислять в октетах размеры блоков данных (?). Актуально на платформах, где юнит адреса (машинное слово) не равен октету (например, в SeaForth — 18 бит)

Какие юниты лучше использовать для операций ввода-вывода?
По моему, точно не символы. Либо байты, либо юниты адреса (а для байтов тогда: BWRITE-FILE или особые хэндлы...). По идее, юниты адреса — базовый уровень для форт-машины, и остальное делается на его основе.

Ссылка по теме: http://groups.google.com/group/comp.lang.forth/browse_thread/thread/58bc3a1a19c2b4f0

--
Ruvim

------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to
best implement a security strategy that keeps consumers' information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|

Re: counting units for I/O

Andrey Cherezov
Re: [Spf-dev] counting units for I/O

Привет!

Можно сделать отдельный флаг вдобавок ко всем этим R/O, R/W. Как в Unix'е есть флаги для переключения режима работы с файлом - бинарный или текстовый. Вообще идея "транслированного IO" очень неудачна, imho. Юниксоидные программисты постоянно ошибаются при работе с ним - лично исправлял такие однообразные баги в Windows-версиях нескольких известных программ. В юниксах 70х годов это имело какой-то смысл для совместимости с другими архитектурами. А сейчас, получается, для совместимости с юниксами (у которых, на самом деле нет причин для поддержки этой устаревшей фичи).

Что касается архитектур без возможности побайтной адресации, то в форте всё-таки обычно эмулируют эту возможность так, чтобы C@/C! работали с байтами независимо от низлежащей "словности". Актуальность этой проблемы также снижается - даже контроллеры уже практически переключились на 32-битный режим и поддержку побайтной адресации (плюс отказались от гарвардской архитектуры). Если мы обсуждаем "юниты ввода-вывода", то почему бы тогда не обсудить заодно и "юниты перезаписи встроенной flash-памяти контроллеров" (перезапись памяти не побайтовая и даже не пословная, а постраничная)? Imho, для фортов в контроллерах это более актуальная проблема.

Ещё можно вспомнить, что в CP/M (и в DOS'е, кажется, тоже) был режим работы с файлом "записями" - чем это хуже иных "небайтовых" способов работы с файлом?

На самом деле все эти режимы - очень частные особенности, которые лучше бы скрыть от программиста на уровне Форта. Забыть обо всём кроме 8-битных байтов и бинарного в/в. В конце-концов все ЗУ работают в бинарном режиме и ничего не знают об абстракции "символ".


-------- Исходное сообщение --------
Тема: [Spf-dev] counting units for I/O
Дата: 2011-01-08 21:41:17
От: [hidden email]
Привет всем!

По стандарту WRITE-FILE & co. исчисляют размер в символах. Получается, что нет стандартного способа оперировать бинарными файлами. Особо актуально, когда размер символа не равен размеру юнита адреса.
По моему, WRITE-FILE должно исчислять в тех же юнитах, что и слово MOVE. А для символов (если необходимо) -- CWRITE-FILE (аналогично CMOVE -- префикс 'C').

Для протоколов обмена (в том числе и перенос файлов между машинами) важно исчесление в байтах (октетах), а не абстрактных address-unit. Поэтому, для всех операций ввода/вывода (сокеты, пайпы, файлы), нужна возможность исчислять в октетах размеры блоков данных (?). Актуально на платформах, где юнит адреса (машинное слово) не равен октету (например, в SeaForth — 18 бит)

Какие юниты лучше использовать для операций ввода-вывода?
По моему, точно не символы. Либо байты, либо юниты адреса (а для байтов тогда: BWRITE-FILE или особые хэндлы...). По идее, юниты адреса — базовый уровень для форт-машины, и остальное делается на его основе.

Ссылка по теме: http://groups.google.com/group/comp.lang.forth/browse_thread/thread/58bc3a1a19c2b4f0

--
Ruvim

------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to
best implement a security strategy that keeps consumers' information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|

Re: counting units for I/O

Ruvim Pinka
Привет!

2011/1/10 Andrey Cherezov <[hidden email]>

Можно сделать отдельный флаг вдобавок ко всем этим R/O, R/W. Как в Unix'е есть флаги для переключения режима работы с файлом - бинарный или текстовый. Вообще идея "транслированного IO" очень неудачна, imho. Юниксоидные программисты постоянно ошибаются при работе с ним - лично исправлял такие однообразные баги в Windows-версиях нескольких известных программ. В юниксах 70х годов это имело какой-то смысл для совместимости с другими архитектурами. А сейчас, получается, для совместимости с юниксами (у которых, на самом деле нет причин для поддержки этой устаревшей фичи).

Особый флаг открытия мне тоже не нравится: ведет к особым хэндлам и дополнительной прослойке (над системными хэндлами). Кроме того, для сокетов у нас нет подобного флага при открытии.


Что касается архитектур без возможности побайтной адресации, то в форте всё-таки обычно эмулируют эту возможность так, чтобы C@/C! работали с байтами независимо от низлежащей "словности".


Если низлежащая "словность" более мелкой грануляции, чем CHAR, это работает. Если же более крупной грануляции (скажем, 18 или 32 бита) -- то C@ будет обращаться только к младшей части, а для доступа к произвольному символу необходимо расширять адресацию.

Кроме того, C@ -- работает с символами, которые не всегда байтовые. В юникодном виндовом приложении символы должны быть двухбайтные. Или, ты предлагаешь, чтобы даже и в таком случае C@ оперировало байтом?

Когда нужен именно байт, я использую B@  (см. ~pinka/lib/ext/basics.f)

Актуальность этой проблемы также снижается - даже контроллеры уже практически переключились на 32-битный режим и поддержку побайтной адресации (плюс отказались от гарвардской архитектуры).

Согласен.
Конечно, есть и универсальное решение: виртуальная прослойка поверх аппаратной, со своей по-байтовой адресацией оперативной памяти — но, применимо лишь в особых случаях в силу неэффективности.

 

Если мы обсуждаем "юниты ввода-вывода", то почему бы тогда не обсудить заодно и "юниты перезаписи встроенной flash-памяти контроллеров" (перезапись памяти не побайтовая и даже не пословная, а постраничная)? Imho, для фортов в контроллерах это более актуальная проблема.

Ещё можно вспомнить, что в CP/M (и в DOS'е, кажется, тоже) был режим работы с файлом "записями" - чем это хуже иных "небайтовых" способов работы с файлом?

На самом деле все эти режимы - очень частные особенности, которые лучше бы скрыть от программиста на уровне Форта. Забыть обо всём кроме 8-битных байтов и бинарного в/в. В конце-концов все ЗУ работают в бинарном режиме и ничего не знают об абстракции "символ".

Да, согласен, это вполне оправдано для операций ввода-вывода.

Следует только учитывать, что (по стандарту) длина блоков данных исчисляется в юнитах адреса (см. слова ALLOCATE, MOVE и т.п.).

Поэтому, например, 11 байт данных (88 бит) на форт-машинах с 8-битном, 16-битном и 18-битном юнитом адреса займут соответственно — 11 юнитов адреса, 6 (5.5) юнитов адреса  и 5 (4.8(8) = 88/18) юнитов адреса. Надо постараться, чтобы сделать исходный код (скажем, для сетевого протокола), одинаково работающий в таком разнообразии форт-машин ;)   В comp.lang.forth было предложено использовать операции PACK (упаковка последовательности октетов перед выводом) и UNPACK (распаковка октетов в юниты адреса после ввода).

--
Ruvim

------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to
best implement a security strategy that keeps consumers' information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|

Re: counting units for I/O

Andrey Cherezov
Re: [Spf-dev] counting units for I/O

 

Особый флаг открытия мне тоже не нравится: ведет к особым хэндлам и дополнительной прослойке (над системными хэндлами). Кроме того, для сокетов у нас нет подобного флага при открытии.
Для сокетов и "у них" нет, по-моему. Некоторая взаимодействие с юниксоидными режимами транслированного в/в есть только в протоколе FTP (команда TYPE) - включение текстового режима для команд (выдача списка файлов, например) и бинарного для передачи файлов, но это как раз потому, что команда LIST работала в исходной реализации через юниксный ls. А во всех более поздних протоколах (с середины 80х) переводом строки считается строго CRLF, и символы совпадают с байтами.
Если низлежащая "словность" более мелкой грануляции, чем CHAR, это работает. Если же более крупной грануляции (скажем, 18 или 32 бита) -- то C@ будет обращаться только к младшей части, а для доступа к произвольному символу необходимо расширять адресацию.
Да, необходимо. Без побайтовой адресации, хотя бы виртуальной, нынче никуда.

Кроме того, C@ -- работает с символами, которые не всегда байтовые. В юникодном виндовом приложении символы должны быть двухбайтные. Или, ты предлагаешь, чтобы даже и в таком случае C@ оперировало байтом?
Ну раз стандарт не озаботился стандартизацией иного способа работы с байтами, лучше считать C@ байтовым.

Когда нужен именно байт, я использую B@  (см. ~pinka/lib/ext/basics.f)
Когда нужны два байта, я использую W@ :) Согласен, здесь есть определенный разнобой, в т.ч. и в SPF, и еще больше в dsForth (он внутри весь юникодный). Но этот разнобой играет заметную роль только в интерфейсных делах, которые крайне редко сейчас делаются средствами фортового TYPE, а делаются средствами ОС, в которых всю заботу о разноширинных строках можно вынести во wrapper'ы соответствующих функций ОС (так было сделано в китайской и арабской версиях Eserv/2 в 98-99м гг; арабские RTL и "зеркальность" интерфейса спрятались там же), что для самого форта и транслятора незаметно. Поэтому я за байты=символы во всём, кроме ОС-взаимодействия, которые в любом случае системно-зависимы и не стандартизируются в форте. Аналогично с остро/тупо-конечностью порядка следования байт в слове. Везде в форте это не играет роли, и только при взаимодействии через ОС иногда становится заметным ("сетевой порядок" байт отличается от принятого в современных архитектурах, поэтому требуется "разворот" порядка, но не в форте, а в обертках соответствующих не-фортовых функций). Т.е. считать весь этот разнобой системно-зависимым, а внутри форта работать единообразно, что годится для 99.9% применений.

Поэтому, например, 11 байт данных (88 бит) на форт-машинах с 8-битном, 16-битном и 18-битном юнитом адреса займут соответственно — 11 юнитов адреса, 6 (5.5) юнитов адреса  и 5 (4.8(8) = 88/18) юнитов адреса. Надо постараться, чтобы сделать исходный код (скажем, для сетевого протокола), одинаково работающий в таком разнообразии форт-машин ;)   В comp.lang.forth было предложено использовать операции PACK (упаковка последовательности октетов перед выводом) и UNPACK (распаковка октетов в юниты адреса после ввода).

Я думаю, что те, кто работает со старыми Муровскими архитектурами, могут позволить себе создавать либы столь же несовместимыми с остальными фортами, как собственно муровский форт не совместим со стандартом. Всех остальных это наверняка не касается, а в будущем будет касаться еще меньше, поэтому предлагаю с несоразмерными юнитами не заморачиваться. SPF для до-32-битных контроллеров у нас нет, а если потребуется, то там все-равно придётся работать в стиле SPF/2.5 (16 бит и почти гарвард) и о переносе либ из 32-битного SPF врядли пойдёт речь просто из-за разных подходов к программированию в тонких и толстых железках.
Проблема юникода является более актуальной (в связи с восходящей звездой Китая :), но легко решается на уровне функций ОС [кроме случаев разработки китайского текстового редактора или китайского браузера (что в наших копилках тоже вроде есть :)]. Злобные UTF-8-консоли в юниксах тоже в общем не забота фортового ядра (вектора ANSI><OEM в TYPE хватит для большинства консольных задач).

------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to
best implement a security strategy that keeps consumers' information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|

Re: counting units for I/O

Ruvim Pinka
2011/1/11 Andrey Cherezov <[hidden email]>
> А во всех более поздних протоколах (с середины 80х) переводом строки считается строго CRLF, и символы совпадают с байтами.
[...]
> Ну раз стандарт не озаботился стандартизацией иного способа работы с байтами, лучше считать C@ байтовым.

Вот и Anton Ertl написал: "Systems with 1 chars > 1 au are a bad idea,
mainly because most programs dealing with chars have a dependency on 1
chars = 1" (au -- adress-unit).

В стандарт заложена идея "абстрактности"  au, char,  cell (т.е., их
размер не фиксирован).

> Когда нужны два байта, я использую W@ :) Согласен, здесь есть определенный разнобой, в т.ч. и в SPF, и еще больше в dsForth (он внутри весь юникодный).

Кстати, а в dsForth (в версии для WindowsCE) размер CHAR 1 или 2
байта? Т.е., C@ там дает полный юникодный код символа, или октет в пол
символа?

--
Ruvim
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|

Re: counting units for I/O

Andrey Cherezov
Re: [Spf-dev] counting units for I/O

C@ и W@ там работают как в SPF. 

С@:

x86: MOV AL,  [EBX]

 

   00 [+] R0   R1  LDRB#   \

arm:   00 [+] R0   R1  LDRB# 

mips: %v0 %v1 00 LBU

sh3:    R0  R0    C@(Rx)

 


-------- Исходное сообщение --------
Тема: Re: [Spf-dev] counting units for I/O
Дата: 2011-01-12 00:32:33
От: [hidden email]

Кстати, а в dsForth (в версии для WindowsCE) размер CHAR 1 или 2 байта? Т.е., C@ там дает полный юникодный код символа, или октет в пол символа?


------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|

Re: counting units for I/O

Ruvim Pinka
2011/1/12 Andrey Cherezov <[hidden email]>

C@ и W@ там работают как в SPF. 

а я-то думал, что в юникодной WindowsCE и внутри форта символы двухбайтные (не было под рукой WindowsCE, чтобы проверить dsForth).. значит, я дезинформировал comp.lang.forth :(

А имена файлов там сразу в форте юникодные, или переводятся из ASCII в юникод внутри OPEN-FILE, перед CreateFileW ?

--
Ruvim

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|

Re: counting units for I/O

Andrey Cherezov
Re: [Spf-dev] counting units for I/O

dsForth/2.x для не-CE Windows компилируется из тех же исходников, что и для CE.

Параметры OPEN-FILE там изначально в юникоде, не конвертируются внутри. Но есть еще версии тех же слов с суффиксом -U, кодировка которых определяется флагом __UC. Подробности лучше выяснять у Кости, он 2.х писал.

Меня dsForth только укрепил во мнении, что тексты должны быть байтовыми, а конвертироваться только "на границе" с не-байтовым окружением. Ради китайцев я не готов терпеть мучения в некитайском коде (при всём моем глубочайшем уважении к нашим старым тайваньским партнерам, которые, к слову, в качестве партнеров надежнее родных однобайтовых американцев).

Сожалею, что из-за меня ты дезинформировал comp.lang.forth. Но, надеюсь, они от этого не пострадают - никто не кинулся покупать dsForth после этой дезы :)


-------- Исходное сообщение --------
Тема: Re: [Spf-dev] counting units for I/O
Дата: 2011-01-12 17:35:18
От: [hidden email]
2011/1/12 Andrey Cherezov <[hidden email]>

C@ и W@ там работают как в SPF. 

а я-то думал, что в юникодной WindowsCE и внутри форта символы двухбайтные (не было под рукой WindowsCE, чтобы проверить dsForth).. значит, я дезинформировал comp.lang.forth :(

А имена файлов там сразу в форте юникодные, или переводятся из ASCII в юникод внутри OPEN-FILE, перед CreateFileW ?

--
Ruvim

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|

Re: counting units for I/O

1001
In reply to this post by Ruvim Pinka
Ruvim,

юникод вовсе не обязательно двухбайтный.
utf8 кодировка с переменной длиной 1-5 байт
-1001

2011/1/12 Andrey Cherezov <[hidden email]>

C@ и W@ там работают как в SPF. 

а я-то думал, что в юникодной WindowsCE и внутри форта символы двухбайтные (не было под рукой WindowsCE, чтобы проверить dsForth).. значит, я дезинформировал comp.lang.forth :(

А имена файлов там сразу в форте юникодные, или переводятся из ASCII в юникод внутри OPEN-FILE, перед CreateFileW ?



------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|

Re: counting units for I/O

Ruvim Pinka
Привет!

2011/1/12 1001 <[hidden email]>
Ruvim,

юникод вовсе не обязательно двухбайтный.
utf8 кодировка с переменной длиной 1-5 байт
-1001

Да, конечно. В случае UTF задается размер базового символа ("primitive character" в предложенном Xchar wordset).

Но, в Windows-то юникод на основе 16-битных символов (куций USC-2 или полный UTF-16).

--
Ruvim

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|

Re: counting units for I/O

Ruvim Pinka
In reply to this post by Andrey Cherezov
2011/1/12 Andrey Cherezov <[hidden email]>

dsForth/2.x для не-CE Windows компилируется из тех же исходников, что и для CE.

Параметры OPEN-FILE там изначально в юникоде, не конвертируются внутри. Но есть еще версии тех же слов с суффиксом -U, кодировка которых определяется флагом __UC. Подробности лучше выяснять у Кости, он 2.х писал.

Значит, портабельный код трудно сделать.. Например, слово LAY-PATH сходу не заработает в dsForth. А если бы и внутри форта символы были двухбайтные, то заработало бы.
 

Меня dsForth только укрепил во мнении, что тексты должны быть байтовыми, а конвертироваться только "на границе" с не-байтовым окружением.

Т.е., если требуется более, чем ASCII, то пользовать UTF-8? Или ограничиться локальными кодировками?
 

Сожалею, что из-за меня ты дезинформировал comp.lang.forth. Но, надеюсь, они от этого не пострадают - никто не кинулся покупать dsForth после этой дезы :)

это я сам виноват, причем тут ты?  ;)

--
Ruvim

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|

Re: counting units for I/O

Andrey Cherezov
Re: [Spf-dev] counting units for I/O

Локальными. Жили же мы как-то с четырьмя русскими кодировками :)

UTF-8 неизбежное зло (сначала из-за браузеров, потом из-за несознательной линуксовой молодежи, соблазненной глобалистами :). Повсеместно его использовать - это все равно что пытаться всегда говорить на Эсперанто. С точки зрения глобализации хорошо, с точки зрения удобства - плохо. Я предлагаю с однобайтовыми расами (европеоидами) говорить их родными доюникодными кодировками (то бишь "ANSI"-версиями в Windows и доюникодными локалями в Unix), а с двухбайтовыми расами - на юникоде или utf8, коль уж иных средств общения нам не дано понять/увидеть. А с русскими - по-русски, то бишь на тотально победившей и наиболее программно-эффективной windows-1251 :)

Браузеры стали доминирующим интерфейсом, и браузеры понимают все существующие кодировки, предоставляя нам возможность работы с любой удобной нашему приложению кодировкой или их смесью. Не вижу особой разницы, с точки зрения охвата всего многообразия письменностей, хранения текстов в виде "номер кодировки + текст" (как в письмах - текст и мета-инфо раздельны) или в виде "номер кодировки в каждом символе" (юникоды). С программной точки зрения удобнее и универсальнее первое, и для хранения компактнее первое.


-------- Исходное сообщение --------
Тема: Re: [Spf-dev] counting units for I/O
Дата: 2011-01-12 23:01:54
От: [hidden email]
> Меня dsForth только укрепил во мнении, что тексты должны быть байтовыми, а
> конвертироваться только "на границе" с не-байтовым окружением.

Т.е., если требуется более, чем ASCII, то пользовать UTF-8? Или ограничиться
локальными кодировками?

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|

Re: counting units for I/O

Phil Krylov
2011/1/13 Andrey Cherezov <[hidden email]>
> Не вижу особой разницы, с точки зрения охвата всего многообразия письменностей, хранения текстов в виде "номер кодировки + текст" (как в письмах - текст и мета-инфо раздельны) или в виде "номер кодировки в каждом символе" (юникоды). С программной точки зрения удобнее и универсальнее первое, и для хранения компактнее первое.

Конечно, спорить на эту тнму бесполезно, но вот мне уже более 20 лет
приходится писать разнообразные конвертеры текстов для окружающих
лингвистов, и должен сказать, что тексты, набранные одним-двумя
шрифтами в уникоде, мне как программисту нравятся гораздо больше, чем
тексты, написанные двадцатью шрифтами  в двадцати нестандартных
(отсуствующих в iconv) 8-битных кодировках с диакритиками и пр.

-- Ф.
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|

Re: counting units for I/O

Nicholas Nemtsev-2
In reply to this post by Andrey Cherezov


13 января 2011 г. 2:36 пользователь Andrey Cherezov <[hidden email]> написал:

UTF-8 неизбежное зло (сначала из-за браузеров, потом из-за несознательной линуксовой молодежи, соблазненной глобалистами :). Повсеместно его использовать - это все равно что пытаться всегда говорить на Эсперанто. С точки зрения глобализации хорошо, с точки зрения удобства - плохо. Я предлагаю с однобайтовыми расами (европеоидами) говорить их родными доюникодными кодировками (то бишь "ANSI"-версиями в Windows и доюникодными локалями в Unix), а с двухбайтовыми расами - на юникоде или utf8, коль уж иных средств общения нам не дано понять/увидеть. А с русскими - по-русски, то бишь на тотально победившей и наиболее программно-эффективной windows-1251 :)


Некоторое время назад я пришёл к выводу, что удобнее всего работать в среде, где вся текстовая информация (включая и слова форта) будет представлена в единой кодировке. В качестве такой единой кодировки был выбран Юникод. На входе (например, чтение из файла) всё преобразуется в Юникод (по умолчанию считается, что вся входящая информация - ANSI, но всегда можно переопределить это умолчание), на выходе - обратно. Очень удобно, когда для работы с текстовой информацией используется один набор слов (сравнение, поиск, замена и т.д.) и нужно следить только за входом и выходом. Сейчас у меня есть версия SPF 3.75 (условно), которая переделана на работу с юникодами.

--
Nicholas Nemtsev

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|

Re: counting units for I/O

Andrey Cherezov
In reply to this post by Phil Krylov
Re: [Spf-dev] counting units for I/O

За 20 лет отсутствующие кодировки надо было добавить в iconv ;)

Юникодов тоже несколько штук (более десятка!), и лично у меня возни с ними больше. См. историю правки файлов

~ac/lib/lin/iconv/iconv.f 

~ac/lib/lin/iconv/utf7-imap.f 

~ac/lib/lin/idn/idn.f 

А шрифты не имеют прямого отношения к кодировке, это отдельное "второе измерение".


-------- Исходное сообщение --------
Тема: Re: [Spf-dev] counting units for I/O
Дата: 2011-01-13 07:47:09
От: [hidden email]

Конечно, спорить на эту тнму бесполезно, но вот мне уже более 20 лет приходится писать разнообразные конвертеры текстов для окружающих лингвистов, и должен сказать, что тексты, набранные одним-двумя шрифтами в уникоде, мне как программисту нравятся гораздо больше, чем тексты, написанные двадцатью шрифтами в двадцати нестандартных
(отсуствующих в iconv) 8-битных кодировках с диакритиками и пр.



------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|

Re: counting units for I/O

Andrey Cherezov
In reply to this post by Nicholas Nemtsev-2
Re: [Spf-dev] counting units for I/O

Ты пришел к этому выводу в эпоху SPF/3, т.е. в конце прошлого века, когда к такому же выводу пришли все :) Пропаганда была сильна :) И довод ты приводишь ровно тот же самый - "одним махом всех побивахом". Сколько процентов китайского текста было в том объеме, что ты ежедневно конвертировал туда-сюда эти 10 лет?

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


-------- Исходное сообщение --------
Тема: Re: [Spf-dev] counting units for I/O
Дата: 2011-01-13 08:45:04
От: [hidden email]
13 января 2011 г. 2:36 пользователь Andrey Cherezov написал:

>  UTF-8 неизбежное зло (сначала из-за браузеров, потом из-за несознательной
> линуксовой молодежи, соблазненной глобалистами :). Повсеместно его
> использовать - это все равно что пытаться всегда говорить на Эсперанто.

Некоторое время назад я пришёл к выводу, что удобнее всего работать в
среде, где вся текстовая информация (включая и слова форта) будет
представлена в единой кодировке. В качестве такой единой кодировки был
выбран Юникод. На входе (например, чтение из файла) всё преобразуется в
Юникод (по умолчанию считается, что вся входящая информация - ANSI, но
всегда можно переопределить это умолчание), на выходе - обратно. Очень
удобно, когда для работы с текстовой информацией используется один набор
слов (сравнение, поиск, замена и т.д.) и нужно следить только за входом и
выходом. Сейчас у меня есть версия SPF 3.75 (условно), которая переделана на
работу с юникодами.

-- 
Nicholas Nemtsev

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|

Re: counting units for I/O

Phil Krylov
In reply to this post by Andrey Cherezov
2011/1/13 Andrey Cherezov <[hidden email]>
> А шрифты не имеют прямого отношения к кодировке, это отдельное "второе измерение".

К сожалению, в ситуации, когда немного менее 256 символов
категорически недостаточно для представления текста, шрифт начинает
иметь прямое отношение к кодировке.

-- Ф.
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|

Re: counting units for I/O

Nicholas Nemtsev-2
In reply to this post by Andrey Cherezov


13 января 2011 г. 17:35 пользователь Andrey Cherezov <[hidden email]> написал:

Ты пришел к этому выводу в эпоху SPF/3, т.е. в конце прошлого века, когда к такому же выводу пришли все :) Пропаганда была сильна :) И довод ты приводишь ровно тот же самый - "одним махом всех побивахом". Сколько процентов китайского текста было в том объеме, что ты ежедневно конвертировал туда-сюда эти 10 лет?

Не, в прошлом веке мне и без Юникода жилось отлично :) И для меня "эпоха SPF/3" ещё не закончилась :)
Я тексты не конвертировал, я программы писал :)

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

Простой пример: на входе есть Юникодная строка (именно Юникодная, преобразование в ANSI не катит, так как может быть потеряна информация), которую надо разобрать и склеить по-новому. Для разборки и склейки есть слово, которое работает с однобайтовыми символами. Как его использовать для Юникодной строки? А никак. Надо писать такое же слово, только для Юникодов. Или сразу писать для Юникодов, а строки из однобайтных символов перегонять до и после работы слова. И всегда помнить, с какого рода строками ты работаешь в каждый конкретный момент.

--
Nicholas Nemtsev

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|

Re: counting units for I/O

Andrey Cherezov
Re: [Spf-dev] counting units for I/O

Ты писал программы, которые попутно вхолостую конвертировали тексты, если я правильно понял твоё описание процедур чтения [неюникодных] файлов.

Юникод европеоидов всегда может преобразоваться в байтовые кодировки без потерь. Если не может, то это сильно заметно: windows-функции забивают строку знаками вопроса, а iconv-функции возвращают ошибку. В моей практике (Eserv ежедневно декодирует тысячи писем из всех мировых кодировок в windows-1251) такие проблемы только с кодировками наших юго-восточных братьев по разуму, которые мы всё-равно прочесть не в состоянии (арабские спамеры действуют иначе - они свои тексты присылают в виде картинок, и мы по крайней мере можем полюбоваться арабской вязью "в оригинале").

> И всегда помнить, с какого рода строками ты
работаешь в каждый конкретный момент.

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

Повторюсь: поддержка юникода внутри (равно как всех остальных кодировок на входе) безусловно важна в браузерах и в текстовых редакторах. Текстовые редакторы плавно перекочевывают в браузеры, поэтому остается одно приложение. И браузеры снимают все наши проблемы с кодировками - это они, а не мы, будут одним махом всех побивахом, мы им эту работу делегируем.

Особый случай - двуязычные тексты. Для всех европеоидных пар эта задача решена 8-байтовыми кодировками - младшая половина для "римских" языков, старшая половина для "византийских". Второй байт добавлен для "нехристиан", но две эти цивилизации говорят между собой исключительно языками колонизаторов, т.е. романскими кодировками. (А для Эсперанто хватает и 7 бит :). Итого вопрос выбора кодировки для приложения диктуется только ответом на один-единственный вопрос: будут ли вашей программой пользоваться китайцы, причем именно для редактирования текстов, причем именно вне браузера, а именно непосредственно в вашей программе. Во всех остальных случаях вы просто копируете и склеиваете тексты как байтовые blob'ы, и вам обычно без разницы - тексты там или картинки, или еще что, и ни одной функции кроме MOVE вам не надо (как, собственно, и процессору, на котором всё это крутится ;).

Ч.Мур: "Слыша, как кто-то похваляется миллионами строк кода, я уверен, что этот человек вопиющим образом не разобрался в своей задаче."

Слыша, что кто-то использует юникод в качестве основной кодировки, я думаю "о, этот человек пишет китайский текстовый редактор или даже браузер для китайцев"! ;) Задача безусловно достойная (все существующие браузеры не очень хороши), но, imho, китайцы или японцы сделают это лучше, потому что могут увидеть, понять и оценить результат. Хотя, впрочем, не исключено, что это они и написали все последние поколения браузеров :-)))


-------- Исходное сообщение --------
Тема: Re: [Spf-dev] counting units for I/O
Дата: 2011-01-13 18:28:44
От: [hidden email]
Я тексты не конвертировал, я программы писал :)

Простой пример: на входе есть Юникодная строка (именно Юникодная,
преобразование в ANSI не катит, так как может быть потеряна информация),
которую надо разобрать и склеить по-новому. Для разборки и склейки есть
слово, которое работает с однобайтовыми символами. Как его использовать для
Юникодной строки? А никак. Надо писать такое же слово, только для Юникодов.
Или сразу писать для Юникодов, а строки из однобайтных символов перегонять
до и после работы слова. И всегда помнить, с какого рода строками ты
работаешь в каждый конкретный момент.

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
Reply | Threaded
Open this post in threaded view
|

Re: counting units for I/O

Ruvim Pinka
2011/1/13 Andrey Cherezov <[hidden email]>

Юникод европеоидов всегда может преобразоваться в байтовые кодировки без потерь.

[...]

Особый случай - двуязычные тексты. Для всех европеоидных пар эта задача решена 8-байтовыми кодировками - младшая половина для "римских" языков, старшая половина для "византийских". Второй байт добавлен для "нехристиан", но две эти цивилизации говорят между собой исключительно языками колонизаторов, т.е. романскими кодировками. (А для Эсперанто хватает и 7 бит :). Итого вопрос выбора кодировки для приложения диктуется только ответом на один-единственный вопрос: будут ли вашей программой пользоваться китайцы, причем именно для редактирования текстов, причем именно вне браузера, а именно непосредственно в вашей программе.

Еще пример: обработка имен файлов — их нельзя преобразовывать в однобайтовую кодировку, т.к. могут быть потери. На диске пользователя могут быть файлы с именами на разных языках одновременно.

Тексты могут быть гораздо более, чем двуязычными (например, разные цитаты могут приводится на оригинальном языке и в переводе).


Вообще, хорошо, если форт-систему можно собрать в различных вариантах: размер символа (8 или 16 бит), размер ячейки (16, 32 или 64 бита), и т.п. задаются опциями. Тогда, для каждой задачи выбирается тот вариант форт-системы, который больше для нее подходит (например, для acWEB -- байтовый символ и никаких накладных расходов на преобразования текстов протокола ;)  
А в некоторых случаях будет удобно иметь оба набора слов (с однобайтным и двухбайтным символом) в разных словарях: в форт-систему должно быть просто подключить еще раз реализацию данного набора слов в отдельный словарь (с другим размером символа).

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

--
Ruvim

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev
123