Haskell, гротесковое
Nov. 1st, 2011 08:57 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassЕнумераторы-итератии наконец заработали так, как я себе это представлял.
Ошибок было две:
Ключевая: надо было IO action лифтить внутрь iteratee и там всю работу и выполнять. А не внутри IO дергать енумератор с итератее-парсером и доставая результат:
неправильно, теряет куски буферов :
правильно:
Вторая ошибка: в протоколе одного девайса после строки данных идет \r\n. в протоколе другого только \r. Строки разделены пустыми строками как бог на душу положит.
Я пишу парсер на attoparsec таким образом:
Таймауты, впрочем, вообще не обрабатываются - пакет serialport на них возвращает пустые строки. Дойдут руки - буду разбираться как это исправлять, кроссплатформенным образом.
И да, я вспомнил, зачем же я это все делал: меня задрало не иметь под руками прототипа софта, который можно единообразно запустить как винде, так и на линуксе и который бы работал с висящими на ком-порту девайсами согласно разнообразных от фонаря придуманных протоколов.
Ошибок было две:
Ключевая: надо было IO action лифтить внутрь iteratee и там всю работу и выполнять. А не внутри IO дергать енумератор с итератее-парсером и доставая результат:
неправильно, теряет куски буферов :
processWeather3 :: SerialPort -> IO ()
processWeather3 serial = loop
where loop = do a <- E.run_ $ enumSerial serial E.$$ P.iterParseLine
BS.putStrLn a
loop
правильно:
iterWeather5 = loop
where loop = do a <- P.iterParseLine
liftIO $ BS.putStrLn a
loop
processWeather5 :: SerialPort -> IO ()
processWeather5 serial = E.run_ $ enumSerial serial E.$$ iterWeather5
Вторая ошибка: в протоколе одного девайса после строки данных идет \r\n. в протоколе другого только \r. Строки разделены пустыми строками как бог на душу положит.
Я пишу парсер на attoparsec таким образом:
do skipWhile isSpace_w8 --пропускаем whitespace data <- ReadData --читаем строку данных skipWhile isSpace_w8 --пропускаем whitespace (т.е. - перенос строки) return dataТак вот, skipWhile, что характерно - будет ждать данных пока не придет хоть что-нибудь, отличающееся от предиката. Если девайс не гонит данные непрерывным потоком - то это повисает до истечения таймаута.
Таймауты, впрочем, вообще не обрабатываются - пакет serialport на них возвращает пустые строки. Дойдут руки - буду разбираться как это исправлять, кроссплатформенным образом.
И да, я вспомнил, зачем же я это все делал: меня задрало не иметь под руками прототипа софта, который можно единообразно запустить как винде, так и на линуксе и который бы работал с висящими на ком-порту девайсами согласно разнообразных от фонаря придуманных протоколов.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2011-11-01 06:04 pm (UTC)no subject
Date: 2011-11-01 06:06 pm (UTC)no subject
Date: 2011-11-01 06:09 pm (UTC)no subject
Date: 2011-11-01 06:16 pm (UTC)no subject
Date: 2011-11-01 06:19 pm (UTC)самое оно для этого языка.
no subject
Date: 2011-11-01 06:39 pm (UTC)no subject
Date: 2011-11-01 07:38 pm (UTC)Когда я еще учился, то есть, этак в начале века, было модно считать, что фортран быстрее сей. Особенно 77, а 90й (в котором появилась поддержка рекурсии) типа не так круто. Но при аккуратном кодировании, когда на С пишет сишник а на фортране фортранист, выяснялось, что на с/с++ и код короче и глюкогенных мест меньше, и работает чуть быстрее.
Так что фортран - это банальное поддержание устаревшего/унаследованного кода, и когда вымрет последний фортранодинозавр, эта услуга заметно вздорожает.
no subject
Date: 2011-11-01 07:48 pm (UTC)no subject
Date: 2011-11-01 08:01 pm (UTC)no subject
Date: 2011-11-01 09:05 pm (UTC)no subject
Date: 2011-11-02 01:31 am (UTC)Пытались переписать одну критичную подпрограммку с фортрана на макро, в целях ускорения. Поделие на макро оказалось медленнее фортрана в разы, а то и на порядки. Очень дофига.
Так что тот фортран на той платформе математику считал превосходно.
no subject
Date: 2011-11-02 04:05 am (UTC)Получить проигрыш в разы - это ж постараться надо.
no subject
Date: 2011-11-02 04:18 am (UTC)Для ухудшения в разы при использовании простых инструкций - надо постараться, а вот при операциях с плавающей точкой стараться не надо - оно само получится. Процедура там была - быстрое преобразование Фурье, т.е. одна математика.
no subject
Date: 2011-11-02 04:49 am (UTC)Кстати, у меня переписывание ГОСТ-что-то-там-89 с сей на ассемблер дало примерно трехкратный прирост скорости и я абсолютно точно знаю, почему именно и в каких случаях такое переписывание вообще ничего не даст кроме лишних трат времени.
no subject
Date: 2011-11-02 05:11 am (UTC)С переходами и циклами проблем точно не было, все упиралось в плавающую точку - это очень тяжелая операция для проца. Вот щас подумалось что тогда тупанули - надо было дизассемблировать исполняемый модуль и посмотреть во что оно там транслировалось из фортрана, и уже это допиливать а не изобретать с пустого места.
Паскаль там транслировался в Макро - и было все видно что он там намутил, а фортран - сразу в obj.
no subject
Date: 2011-11-02 05:23 am (UTC)А паскаль в плане оптимизации мне как-то никогда не нравился.
no subject
Date: 2011-11-02 06:14 am (UTC)no subject
Date: 2011-11-03 05:02 am (UTC)no subject
Date: 2011-11-02 06:11 am (UTC)no subject
Date: 2011-11-01 07:41 pm (UTC)no subject
Date: 2011-11-02 05:38 am (UTC)