Entry tags:
Haskell, гротесковое
Енумераторы-итератии наконец заработали так, как я себе это представлял.
Ошибок было две:
Ключевая: надо было 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 на них возвращает пустые строки. Дойдут руки - буду разбираться как это исправлять, кроссплатформенным образом.
И да, я вспомнил, зачем же я это все делал: меня задрало не иметь под руками прототипа софта, который можно единообразно запустить как винде, так и на линуксе и который бы работал с висящими на ком-порту девайсами согласно разнообразных от фонаря придуманных протоколов.
no subject
no subject
no subject
самое оно для этого языка.
no subject
no subject
Когда я еще учился, то есть, этак в начале века, было модно считать, что фортран быстрее сей. Особенно 77, а 90й (в котором появилась поддержка рекурсии) типа не так круто. Но при аккуратном кодировании, когда на С пишет сишник а на фортране фортранист, выяснялось, что на с/с++ и код короче и глюкогенных мест меньше, и работает чуть быстрее.
Так что фортран - это банальное поддержание устаревшего/унаследованного кода, и когда вымрет последний фортранодинозавр, эта услуга заметно вздорожает.
no subject
no subject
no subject
no subject
Пытались переписать одну критичную подпрограммку с фортрана на макро, в целях ускорения. Поделие на макро оказалось медленнее фортрана в разы, а то и на порядки. Очень дофига.
Так что тот фортран на той платформе математику считал превосходно.
no subject
Получить проигрыш в разы - это ж постараться надо.
no subject
Для ухудшения в разы при использовании простых инструкций - надо постараться, а вот при операциях с плавающей точкой стараться не надо - оно само получится. Процедура там была - быстрое преобразование Фурье, т.е. одна математика.
no subject
Кстати, у меня переписывание ГОСТ-что-то-там-89 с сей на ассемблер дало примерно трехкратный прирост скорости и я абсолютно точно знаю, почему именно и в каких случаях такое переписывание вообще ничего не даст кроме лишних трат времени.
no subject
С переходами и циклами проблем точно не было, все упиралось в плавающую точку - это очень тяжелая операция для проца. Вот щас подумалось что тогда тупанули - надо было дизассемблировать исполняемый модуль и посмотреть во что оно там транслировалось из фортрана, и уже это допиливать а не изобретать с пустого места.
Паскаль там транслировался в Макро - и было все видно что он там намутил, а фортран - сразу в obj.
no subject
А паскаль в плане оптимизации мне как-то никогда не нравился.
no subject
no subject
no subject