[00:51:35] <vlad3> Угу. Надо уточнять. Я думал на виках раздел завести. Типа уточнения, но не расширения.
[02:55:49] <vlad2> Блин. Два шага от машины до двери офиса. И все равно промок насквозь. Даже как-то холодно. Типа сначала +38, потом еще и тропический дождь...
[14:42:37] <valexey> vlad2: ну и погодка у вас там!
[15:24:56] <valexey> http://oberspace.dyndns.org/index.php/topic,544.0.html
[15:25:55] <valexey> блин. bigendian это таки говно
[15:25:58] <valexey> фу
[15:26:03] <valexey> бяка
[15:26:08] <valexey> аццтой
[16:41:35] <Kemet> @
[16:42:36] <valexey> !
[16:46:07] <Kemet> а где Вирт запретил экспорт переменных структурных типов?
[16:47:49] <valexey> в репорте, вестимо
[16:48:31] <valexey> я ни про что другое и не пишу :-) Оберон-2, Компонентный Паскаль, Оберон образца 90 года, Активный Оберон, Оберон-0 и так далее - меня не интересуют
[16:49:10] <valexey> "Variables cannot be exported, with the exception of those of scalar types in read-only mode."
[16:49:28] <valexey> Это раздел 11. Modules
[17:13:21] <Kemet> всё болье убеждаюсь, что Вирт занимается специализированными железяками и точит Оберон под своё занятие
[17:14:43] <valexey> в плане этих экспортов я не нашел ни одного преимущества для микроконтроллеров
[17:14:49] <valexey> то есть не вижу смысла это запрещать
[17:14:56] <valexey> и ни одного преимущества для компиляторостроения
[17:15:01] <valexey> (со всех сторон)
[17:15:18] <valexey> а вот запрет на возврат переменных структурного типа из функций - это да, это смысл имеет
[17:22:59] <valexey> А вот с целочисленкой в Обероне для МК - это будет боль страдания и унижения
[17:23:14] <valexey> Ибо 16битных целых в Обероне не предусмотрено принципиально
[17:23:27] <valexey> Равно как и алиасов для простых типов
[17:38:21] <Kemet> так у Виртовских железок даже байт 32-х битный
[17:38:48] <valexey> это ты про какие железки?
[17:42:11] <Kemet> плисы
[17:42:29] <valexey> а, ну разве что
[17:42:39] <valexey> но он же еще ARM'ами упарывался
[17:42:59] <valexey> Впрочем, Оберон в Виртовском мире никогда на чем-то не 32битном и не работал
[17:43:20] <Kemet> так он ими в последнее время занимался и группа из етх, так и для АО расширение для программирования плисов написали
[18:11:42] <valexey> черт. не люблю big-endian
[18:17:24] <TRUE> <Kemet> а где Вирт запретил экспорт переменных структурных типов?
<valexey> в репорте, вестимо
<valexey> "Variables cannot be exported, with the exception of those of scalar types in read-only mode."

Так не структурные же, а скалярные. А что это такое - мы до сих пор не знаем.
[18:17:40] <TRUE> а что там с биг эндианом
[18:18:47] <valexey> c биг-ендианом нужно при чтении из потока сразу знать размер и тип переменной в которую читаешь
[18:19:03] <valexey> то есть не выйдет написать универсальную процедуру чтения
[18:22:44] <TRUE> без размера ты по-любому не прочтёшь правильно данные.
[18:23:36] <valexey> прочту
[18:23:42] <TRUE> как?
[18:24:01] <valexey> я знаю что нужно прочитать 13 бит. и мне не нужно знать какого размера переменная/буфер в которую я читаю
[18:24:08] <valexey> мне достаточно знать что там размера хватит
[18:24:15] <valexey> это в случае little endian
[18:24:38] <valexey> в случае  big-endian'a - мне это знать не достаточно
[18:24:41] <valexey> хотя...
[18:25:20] <valexey> да, Kemet прав. можно туда давать адрес не головы, а хвоста, + давать константу инкремента. которая можут быть и отрицательной
[18:25:28] <valexey> Тогда все путем будет
[18:25:35] <valexey> Всем спасибо, я кажется придумал :-)
[18:27:15] <TRUE> а если читать побайтово, то разве не биг-эндиан эти 13 бит выставит в правильном порядке? С литл придётся же байтами жонглировать.
[18:27:40] <valexey> не придется. там везде все будет хорошо.
[18:27:47] <valexey> впрочем, доделаю, скажу как оно вышло :-)
[18:28:04] <valexey> У меня тут сишечка. там есть макросы. там можно все это чтение завернуть в высокоуровневую обертку
[18:28:18] <valexey> (и нужно будет придумать как это же сделать потом в Обероне, эх...)
[18:51:12] <Kemet> valexey: на BE архитектуре с BE нет проблем, там как раз проблемы с LE ))
[20:22:24] <valexey> гы
[20:22:29] <valexey> интел жжот
[20:23:04] <valexey> HTML5 vs. Native — Who Will Win?
In Episode 2, join the discussion as our panelists tackle the debate between HTML5 and native code—which builds the better apps? Go Inside the Brackets to get beyond the fan-boy hype, and hear directly from app developers like Dan Bricklin, Drew Crawford, Dave Methvin, and Mike Richmond as they challenge each other—and you—to take an honest look at the best way to build an app.