- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
by :: Int -> [a] -> [[a]]
by _ [] = []
by n xs = take n xs: by n (drop n xs)
words2 :: String -> (String, String)
words2 str = conc $ words str where
conc (x:xs) = (x, concat xs)
groupTemplates :: String -> [(String, String)]
groupTemplates xs = map (words2) (lines xs)
decodeOne :: String -> [(String, String)] -> String
decodeOne _ [] = ""
decodeOne str (x:xs) | str == fst x = fst x ++ " " ++ snd x ++ "\n"
decodeOne str (_:xs) = decodeOne str xs
decode :: [String] -> [(String, String)] -> String
decode bs ts = concat $ map (\b -> decodeOne b ts) bs
main = do
bits <- readFile "bits.txt"
templates <- readFile "templates.txt"
writeFile "out.txt" $ decode (by 4 bits) (groupTemplates templates)
Follow us!
Хаскелевские readFile и hgetContents тоже закрывают файл, когда он дочитается. Другое дело если список до конца не поюзал, тогда закроется только когда GC увидит, что файл никому не нужен.
> не даст читать из закрытого файла молча
hClose h
s <- hGetContents h
*** Exception: 1.hs: hGetBufSome: illegal operation (handle is closed)
> Ну и конечно в шарпике можно не тратить за счет елды память под весь файл
Как-будто тут нужно. hGetContents и readFile - ленивые операции. А если хочется производительности и ленивости - Data.ByteString.Lazy. Читает чанками по необходимости.
> s <- hGetContents h
Неа, делай так:
Он тихо прочитает список пустой.
Once a semi-closed handle becomes closed, the contents of the associated list becomes fixed. The contents of this final list is only partially specified: it will contain at least all the items of the stream that were evaluated prior to the handle becoming closed.
Есть два правильных варианта использования hGetContents:
1) Обрабатываешь список до конца и не юзаешь hClose, файл закроется как только ты дойдешь до конца списка.
2) Обрабатываешь список до куда надо (не забыв подавить ленивость с помощью evaluate, seq и т.п., чтобы все что нужно дочиталось перед hClose), и делаешь hClose руками.
Если c# и его yield могут сделать что-то кроме этих двух вариантов - запости пруф.
В хаскеле не раздать по потокам не можешь не автозакрыть список, если не читаешь до конца. И надежды 100процентной в хаскеле нет, что файл не весь прочитается в память, а только используемый в данный момент кусок.
> И надежды 100процентной в хаскеле нет, что файл не весь прочитается в память, а только используемый в данный момент кусок.
Прочитается чуть-чуть больше использованного куска. Или для тебя лишние 32 килобайта, прочитанные из-за буферизации уже фатальны?
Имхо это слишком большая цена за почти никому не нужную иксклюзивность.
Нашел только самодельные быдлоподелия с yield, которые мало того что всяко работают медленнее хаскелевых байтстрингов, так еще и имеют ту же самую проблему с закрытием файла (что-то никакого close/finish я у IEnumerator'а не вижу...).
Так что реквестирую пруф для твоего утверждения:
когда последний энумератор во всех потоках дочитает до конца или раньше выйдет изфорича по причине не нужности дольнейших данных - файл закроется самостоятельно. Варианты "gc вызовет финализатор когда рак на горе свистнет", и "я закрою его сам" не канают, в хаскеле ведь точно так же.
IEnumerator - наследуется от IDisposable
И любой форич или линкью запрос
Сам закроет курсор через вызов диспос
Но да, hGetContents это далеко не лучшая связка между чистым миром хаскеля и нашим полным грязи миром...
Есть задачи где это нужно
>Читает чанками по необходимости.
Только вот чанки эти в памяти сохраняются в том числе и уже не нужные если не быть достаточно осторожным (хотя ты ещё не показал реальной программы, позволяющей это сделать (собирать сборщиком мусора гриву списка)), а ленивый шарпик может не держать в памяти ничего кроме тех блоков, с которыми сейчас работаешь в данный момент и таким образом безпроблем прочитать "в память" 6 гб файл на 32хбитной ос и что-то с ним сделать.
Опечатался, сорри, читай как "как-будто тут нельзя".
Неиспользуемые чанки собираются сборщиком мусора. Не будешь держать спискок за гриву - без проблем обработаются и 6 и 40 и 100 гигов.
> хотя ты ещё не показал реальной программы, позволяющей это сделать
На ideone не особо получится из-за таймингов. Ну, впрочем, сейчас напишу код читающий 4 гига из /dev/zero, если оно позволит.
P.S. Смени ник на HaskellGovno, раз уж о хаскеле говорим.
Смотри ниже. http://govnokod.ru/12262#comment163864
Начнем с простого, а иименно френдли для отпускания хвоста. Сложить все прочитанные байты и вывести результат. Потом нужно подумать над чем-нибдь не френдли
http://ideone.com/FuxIDo
время: 5.92s память: 4660 kB
ЧЯНТД?
P.S. Не веришь, что читает файл? Запусти у себя с +RTS -s, покажет честно выделенные и освобожденные мусоросборщиком 40 гигов.
http://ideone.com/QPfsSd
Я хочу пользоваться стандартной библиотечной функцией sum а не сильно ограниченным набором функций из лази библиотеки
наверное как-то так? Только это медлено
- вводный курс на руском здесь.
http://nemerle.org/wiki/index.php?title=Quick_Guide
http://nemerle.org/grokking.html
http://nemerle.org/tutorial.html
http://nemerle.org/documentation.html
https://github.com/rsdn/nemerle/wiki/Grokking-Nemerle
http://nemerle.org/About/
http://nemerle.org/wiki/index.php?title=Main_Page
- тут вика, она самая. Имхо весьма полная, если знаешь язык. Поэтому этим заканчивать.
+
в целом Немерле поддерживает все тоже самое, что и Net framework, так что любой курс по C# или самому фреймворку подойдет.
генератор парсеров на основе граматик. смотреть обязательно. очень интересно
http://vimeo.com/24022350
видеолекция по нему. может будет проще. от дениса рысцова и VladD2 с рсдн, учавствующего в разработке немерле
http://blogerator.ru/page/nemerle-ili-obshhaja-teorija-bezopasnogo-koda-2
некоторые средства немерле для написания безопасного кода и некоторые из них уникальны благодаря способностям языка
презентация по основам немерле. этот автор (денис рысцов) больше лекций по немерле в том числе и видеолекций сделал, только нужно погуглить
А вот тебе часть монад (они есть все, только гуглить нужно) и асинхронное программирование:
http://habrahabr.ru/post/108184/
https://github.com/rsdn/nemerle/wiki/Computation-Expression-macro
http://nemerle.org/wiki/index.php?title=ComputationExpression_ma cro
- Ну и по фреймворку найдешь здесь. Уже помоему немерле под 4.0 фреймворк вышла, а пройдет время и под что-нибудь поновее, но раз у тебя моно, то там вроде пока только 2.0, но лучше конечно не заниматься ерундой. под моно разрабатывать будет проблематично. надо разрабатывать, а главное компилировать под вижуалстудией, а потом результат легко запуститься под моно
да, вот они видеолекции от влада чистякова и дениса рысцова
https://github.com/rsdn/nemerle/wiki - вот ещё одна более полная, бета вики
кажись теперь на говнокоде самый полный список статей и лекций по немерле
небось они тебе доплачивают за поднятие PageRank
Пользуйся, кто мешает. Оно работает точно так же, и не крашится от переполнения памяти. Но работает медленней, пиздец медленнее, как бы не на 2 порядка.
чувак, у тебя 32хбитная ос?:) у тебя может и FDD имеется?