Re: [Haskell-cafe] ∀ lexing in ghc and ghci
Daniel Fischer daniel.is.fisc...@web.de writes: In ghci I can do ∀ :: Var - Base - Formula - Formula ∀ = All fine. But then ghc complains. What's going on here? Maybe your encodings aren't UTF8? Or rather, one of them is UTF-8, and the other isn't. So that in one case, you get the 'forall' Unicode symbol, and in the other, you get a sequence of two (or more?) code-points between 128 and 255, which happen to not be declared as symbols. (This is just a guess, I haven't really checked) See also this thread: http://www.mail-archive.com/haskell-cafe@haskell.org/msg63555.html -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell-beginners] map question
Gregory Propf gregorypr...@yahoo.com writes: Heh, perhaps we should petition to have a new computer key and symbol added to the world's way of writing maths, something like maybe a downward angled slash to mean prefix (-) Or just use 'negate' and 'subtract'? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Where can I find a non-fee-based version of Hudak's paper, Conception, evolution, and application of functional programming languages?
On Thu, 17 Sep 2009 15:32:51 + (GMT), jean legrand kkwwe...@yahoo.fr wrote: Does anybody know where I can find a non-fee-based version of Paul Hudak's paper, Conception, evolution, and application of functional programming languages [1]? There used to be a version that did not seems you can get a djvu copy here http://lib.org.by/info/Cs_Computer science/CsPl_Programming languages/Hudak P. Conception, evolution, and application of functional programming languages (ACM comp.surveys 21, 1989)(T)(53s).djvu the site is in Russian and you wait 30s before a link to the file appears. Thank you for the link. Actually, I had encountered this site earlier, but it had caused my browser to hang, and I had been unable to download the file earlier. For some reason, control-clicking the button to download thirty seconds after visiting the site only causes the thirty-second-waiting process to repeat in another tab, where the button must be clicked (as opposed to control-clicked) thereafter in order to cause a download in the same tab. Then the .djvu-suffixed file downloads, but viewing the file requires installing a DjVu file viewer; I downloaded and installed DjVuLibre 3.5.22+DjView 4.5 from SourceForge at http://sourceforge.net/projects/djvu/files/DjVuLibre_Windows/3.5.22%2B4.5/DjVuLibre%2BDjView-3.5.22%2B4.5-Setup.exe/download. Then the file opens. The file is approximately 731 KB, as opposed to 5.067 MB for the PDF version of the same content (available by clicking on the CACHED button at CiteSeerX at http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.83.6505). The image quality appears identical. -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 Furuike ya, kawazu tobikomu mizu no oto. -- Matsuo Basho^ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is it safe to use unsafePerformIO here?
On Fri, Sep 18, 2009 at 4:06 AM, Ryan Ingram ryani.s...@gmail.com wrote: I am confused about why this thread is talking about unsafePerformIO at all. It seems like everything you all want to do can be accomplished with the much less evil unsafeInterleaveIO instead. (Which is still a bit evil; but it's the difference between stealing cookies from the cookie jar and committing genocide) I didn't read about unsafeIntervleaveIO but yesterday I rewrote my code exactly as you did here, and it allowed me to use the applicative style... Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is it safe to use unsafePerformIO here?
On Fri, Sep 18, 2009 at 5:15 AM, Daniel Fischer daniel.is.fisc...@web.de wrote: ... But that does something completely different from what Cristiano wants to do. He wants to read many files files quasi-parallel. As far as I can tell, he needs to read a small chunk from the beginning of every file, then, depending on what he got from that, he needs to read the rest of some files. If he reads all the files lazily, he (maybe) runs into the open file limit (a semi-closed handle is still open from the OS' point of view, isn't it?). Not quite. In one case I want to dumbly read all the files' metadata and printing them out sorted: reading the next file doesn't depend on what happened previously so they could be read in parallel indeed. In the other case, it reads a specific file completely and print everything out. In both cases, I want to use the same code for reading, exploiting laziness in order not to read the body of files if only metadata are requested. I would separate the reading of headers and bodies, reopening the files whose body is needed, for some (maybe compelling) reason he wants to do it differently. Yes, that's the way Haskell forces you to do that as it's the only way for you to go safe. But, if you know more about your code, you can use unsafe(Perform|Interleave)IO to assure the compiler that everything's right. Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Thank you guys
I wish to thank Cafè's people for their great support in understanding Haskell. Thank you all! Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell-beginners] map question
Ketil Malde ke...@malde.org writes: Gregory Propf gregorypr...@yahoo.com writes: Heh, perhaps we should petition to have a new computer key and symbol added to the world's way of writing maths, something like maybe a downward angled slash to mean prefix (-) Or just use 'negate' and 'subtract'? Well, now that ghc accepts unicode characters in programme source, we could ask that ¬ (NOT SIGN, U+00AC) be recategorised as an identifier character and use that (as a simple function name) for negation and lose the wart altogether. class Negatable t where ¬ :: t - t (and as a side effect we could have identifiers like slightly¬dodgy). Or, if we want to make things look even nicer, make ‐ (HYPHEN, U+2010) an identifier character and use − (MINUS SIGN, U+2212) for the infix operator. Now we could have hyphenated‐identifiers too. I think this second option would be the ㊣ (CORRECT, U+32A3) thing to do, though editors and so on would have to be changed to make the distinction readily visible. I think it's Friday, but I'm not entirely sure this is silly. -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell-beginners] map question
On 18 Sep 2009, at 04:32, Gregory Propf wrote: Heh, perhaps we should petition to have a new computer key and symbol added to the world's way of writing maths, something like maybe a downward angled slash to mean prefix (-) Such a symbol already exists, but isn't in the ASCII set: (-) (unicode 0x2D) hyphen minus and (‐) (unicode 0x2010) hyphen are not the same as (−) (unicode 0x2200) minus sign notably also, not the same as ‒, –, — and ― (figure dash, en- dash, em-dash and horizontal bar). Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] weak pointers and memoization (was Re: memoization)
I would also like to see a solution for problems like these. Haskell provides a lot of nice memoizing / caching data structures - like a trie - but the ones I know indeed keep growing, so no garbage collection takes place? It would be nice to have a data structure that performs caching but does not grow unlimited. I had a similar problem with stable names; it is not possible to check if a stable name is still alive. On Fri, Sep 18, 2009 at 1:39 AM, Rodney Price rodpr...@raytheon.com wrote: In my case, the results of each computation are used to generate a node in a graph structure (dag). The key, oddly, is a hash of a two-tuple that gets stored in the data structure after the computation of the node finishes. If I don't memoize the function to build a node, the cost of generating the tree is exponential; if I do, it's somewhere between linear and quadratic. Another process prunes parts of this graph structure as time goes on. The entire data structure is intended to be persistent, lasting for days at a time in a server-like application. If the parts pruned aren't garbage collected, the space leak will eventually be catastrophic. Either the memo table or the graph structure itself will outgrow available memory. -Rod On Thu, 17 Sep 2009 13:32:13 -0400 Job Vranish jvran...@gmail.com wrote: What are you trying to use this for? It seems to me that for memo tables you almost never have references to they keys outside the lookup table since the keys are usually computed right at the last minute, and then discarded (otherwise it might be easier to just cache stuff outside the function). For example with a naive fibs, the values you are passing in are computed, and probably don't exist before you do the recursive call, and then are discarded shortly afterward. It seems like putting a cap on the cache size, and then just overwriting old entries would be better. Am I missing something? - Job On Wed, Sep 16, 2009 at 4:48 PM, Rodney Price rodpr...@raytheon.com wrote: How does garbage collection work in an example like the one below? You memoize a function with some sort of lookup table, which stores function arguments as keys and function results as values. As long as the function remains in scope, the keys in the lookup table remain in memory, which means that the keys themselves always remain reachable and they cannot be garbage collected. Right? So what do you do in the case where you know that, after some period of time, some entries in the lookup table will never be accessed? That is, there are no references to the keys for some entries remaining, except for the references in the lookup table itself. You'd like to allow the memory occupied by the keys to be garbage collected. Otherwise, if the function stays around for a long time, the size of the lookup table always grows. How do you avoid the space leak? I notice that there is a function in Data.IORef, mkWeakIORef :: IORef a - IO () - IO (Weak (IORef a)) which looks promising. In the code below, however, there's only one IORef, so either the entire table gets garbage collected or none of it does. I've been reading the paper Stretching the storage manager: weak pointers and stable names in Haskell, which seems to answer my question. When I attempt to run the memoization code in the paper on the simple fib example, I find that -- apparently due to lazy evaluation -- no new entries are entered into the lookup table, and therefore no lookups are ever successful! So apparently there is some interaction between lazy evaluation and garbage collection that I don't understand. My head hurts. Is it necessary to make the table lookup operation strict? Or is it something entirely different that I am missing? -Rod On Thu, 10 Sep 2009 18:33:47 -0700 Ryan Ingram ryani.s...@gmail.com wrote: memoIO :: Ord a = (a - b) - IO (a - IO b) memoIO f = do cache - newIORef M.empty return $ \x - do m - readIORef cache case M.lookup x m of Just y - return y Nothing - do let res = f x writeIORef cache $ M.insert x res m return res memo :: Ord a = (a - b) - (a - b) memo f = unsafePerformIO $ do fmemo - memoIO f return (unsafePerformIO . fmemo) I don't think there is any valid transformation that breaks this, since the compiler can't lift anything through unsafePerformIO. Am I mistaken? -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list
Re: [Haskell-cafe] ∀ lexing in ghc and ghci
Hi Daniel, Prelude Data.Char.isSymbol (toEnum 8704) True On Thu, Sep 17, 2009 at 11:09 PM, Daniel Fischer daniel.is.fisc...@web.dewrote: Am Friday 18 September 2009 04:41:13 schrieben Sie: Weird. OK, thanks a lot! I'm switching to ¥ until I get this figured out. Sean What does your ghci say for Data.Char.isSymbol (toEnum 8704) ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] weak pointers and memoization (was Re: memoization)
Yeah it seems like the general solution to the problem would be some sort of map-like datastructure that you add items via a key/value pair, and if the key gets GC'd, that entry gets removed from the structure. I've been wanting something like this as well, but didn't know about weak references so I didn't know if it was possible, but I think I could make something like this now. I'll give it a shot and let you guys know how it goes. Rodney could you post your memo code that uses the weak references? - Job On Fri, Sep 18, 2009 at 7:56 AM, Peter Verswyvelen bugf...@gmail.comwrote: I would also like to see a solution for problems like these. Haskell provides a lot of nice memoizing / caching data structures - like a trie - but the ones I know indeed keep growing, so no garbage collection takes place? It would be nice to have a data structure that performs caching but does not grow unlimited. I had a similar problem with stable names; it is not possible to check if a stable name is still alive. On Fri, Sep 18, 2009 at 1:39 AM, Rodney Price rodpr...@raytheon.com wrote: In my case, the results of each computation are used to generate a node in a graph structure (dag). The key, oddly, is a hash of a two-tuple that gets stored in the data structure after the computation of the node finishes. If I don't memoize the function to build a node, the cost of generating the tree is exponential; if I do, it's somewhere between linear and quadratic. Another process prunes parts of this graph structure as time goes on. The entire data structure is intended to be persistent, lasting for days at a time in a server-like application. If the parts pruned aren't garbage collected, the space leak will eventually be catastrophic. Either the memo table or the graph structure itself will outgrow available memory. -Rod On Thu, 17 Sep 2009 13:32:13 -0400 Job Vranish jvran...@gmail.com wrote: What are you trying to use this for? It seems to me that for memo tables you almost never have references to they keys outside the lookup table since the keys are usually computed right at the last minute, and then discarded (otherwise it might be easier to just cache stuff outside the function). For example with a naive fibs, the values you are passing in are computed, and probably don't exist before you do the recursive call, and then are discarded shortly afterward. It seems like putting a cap on the cache size, and then just overwriting old entries would be better. Am I missing something? - Job On Wed, Sep 16, 2009 at 4:48 PM, Rodney Price rodpr...@raytheon.com wrote: How does garbage collection work in an example like the one below? You memoize a function with some sort of lookup table, which stores function arguments as keys and function results as values. As long as the function remains in scope, the keys in the lookup table remain in memory, which means that the keys themselves always remain reachable and they cannot be garbage collected. Right? So what do you do in the case where you know that, after some period of time, some entries in the lookup table will never be accessed? That is, there are no references to the keys for some entries remaining, except for the references in the lookup table itself. You'd like to allow the memory occupied by the keys to be garbage collected. Otherwise, if the function stays around for a long time, the size of the lookup table always grows. How do you avoid the space leak? I notice that there is a function in Data.IORef, mkWeakIORef :: IORef a - IO () - IO (Weak (IORef a)) which looks promising. In the code below, however, there's only one IORef, so either the entire table gets garbage collected or none of it does. I've been reading the paper Stretching the storage manager: weak pointers and stable names in Haskell, which seems to answer my question. When I attempt to run the memoization code in the paper on the simple fib example, I find that -- apparently due to lazy evaluation -- no new entries are entered into the lookup table, and therefore no lookups are ever successful! So apparently there is some interaction between lazy evaluation and garbage collection that I don't understand. My head hurts. Is it necessary to make the table lookup operation strict? Or is it something entirely different that I am missing? -Rod On Thu, 10 Sep 2009 18:33:47 -0700 Ryan Ingram ryani.s...@gmail.com wrote: memoIO :: Ord a = (a - b) - IO (a - IO b) memoIO f = do cache - newIORef M.empty return $ \x - do m - readIORef cache case M.lookup x m of Just y - return y Nothing - do let res = f x writeIORef cache $ M.insert x res m return res memo
Re: [Haskell-cafe] weak pointers and memoization (was Re: memoization)
Hey it works :D Here is a proof of concept: http://gist.github.com/189104 Maybe later today I'll try to make a version that can be safely used outside IO. - Job On Fri, Sep 18, 2009 at 10:19 AM, Job Vranish jvran...@gmail.com wrote: Yeah it seems like the general solution to the problem would be some sort of map-like datastructure that you add items via a key/value pair, and if the key gets GC'd, that entry gets removed from the structure. I've been wanting something like this as well, but didn't know about weak references so I didn't know if it was possible, but I think I could make something like this now. I'll give it a shot and let you guys know how it goes. Rodney could you post your memo code that uses the weak references? - Job On Fri, Sep 18, 2009 at 7:56 AM, Peter Verswyvelen bugf...@gmail.comwrote: I would also like to see a solution for problems like these. Haskell provides a lot of nice memoizing / caching data structures - like a trie - but the ones I know indeed keep growing, so no garbage collection takes place? It would be nice to have a data structure that performs caching but does not grow unlimited. I had a similar problem with stable names; it is not possible to check if a stable name is still alive. On Fri, Sep 18, 2009 at 1:39 AM, Rodney Price rodpr...@raytheon.com wrote: In my case, the results of each computation are used to generate a node in a graph structure (dag). The key, oddly, is a hash of a two-tuple that gets stored in the data structure after the computation of the node finishes. If I don't memoize the function to build a node, the cost of generating the tree is exponential; if I do, it's somewhere between linear and quadratic. Another process prunes parts of this graph structure as time goes on. The entire data structure is intended to be persistent, lasting for days at a time in a server-like application. If the parts pruned aren't garbage collected, the space leak will eventually be catastrophic. Either the memo table or the graph structure itself will outgrow available memory. -Rod On Thu, 17 Sep 2009 13:32:13 -0400 Job Vranish jvran...@gmail.com wrote: What are you trying to use this for? It seems to me that for memo tables you almost never have references to they keys outside the lookup table since the keys are usually computed right at the last minute, and then discarded (otherwise it might be easier to just cache stuff outside the function). For example with a naive fibs, the values you are passing in are computed, and probably don't exist before you do the recursive call, and then are discarded shortly afterward. It seems like putting a cap on the cache size, and then just overwriting old entries would be better. Am I missing something? - Job On Wed, Sep 16, 2009 at 4:48 PM, Rodney Price rodpr...@raytheon.com wrote: How does garbage collection work in an example like the one below? You memoize a function with some sort of lookup table, which stores function arguments as keys and function results as values. As long as the function remains in scope, the keys in the lookup table remain in memory, which means that the keys themselves always remain reachable and they cannot be garbage collected. Right? So what do you do in the case where you know that, after some period of time, some entries in the lookup table will never be accessed? That is, there are no references to the keys for some entries remaining, except for the references in the lookup table itself. You'd like to allow the memory occupied by the keys to be garbage collected. Otherwise, if the function stays around for a long time, the size of the lookup table always grows. How do you avoid the space leak? I notice that there is a function in Data.IORef, mkWeakIORef :: IORef a - IO () - IO (Weak (IORef a)) which looks promising. In the code below, however, there's only one IORef, so either the entire table gets garbage collected or none of it does. I've been reading the paper Stretching the storage manager: weak pointers and stable names in Haskell, which seems to answer my question. When I attempt to run the memoization code in the paper on the simple fib example, I find that -- apparently due to lazy evaluation -- no new entries are entered into the lookup table, and therefore no lookups are ever successful! So apparently there is some interaction between lazy evaluation and garbage collection that I don't understand. My head hurts. Is it necessary to make the table lookup operation strict? Or is it something entirely different that I am missing? -Rod On Thu, 10 Sep 2009 18:33:47 -0700 Ryan Ingram ryani.s...@gmail.com wrote: memoIO :: Ord a = (a - b) - IO (a - IO b) memoIO f = do cache - newIORef M.empty return $ \x - do
Re: [Haskell-cafe] code-build-test cycle
Yeah linking in windows is _very_ slow. Supposedly this is because the linker forks a lot of processes. In linux this is fine as forking is dirt cheap, but in windows (at least older versions, not completely sure about vista or 7) forking is expensive. Building a Qt app on my EEE in linux only takes a couple seconds. Building in windows on my dual core 3.2Ghz machine takes 15-30 seconds. It's pretty sad. I second Bulat's suggestion. If you can compile everything and just use ghci to avoid the link you should be able to get the best of both works. - Job On Fri, Sep 18, 2009 at 12:34 AM, Bulat Ziganshin bulat.zigans...@gmail.com wrote: Hello Michael, Friday, September 18, 2009, 6:42:32 AM, you wrote: Now I'm wondering if Hugs is a faster interpreter. 2x slower, and incompatib;e with qtHaskell meaningful way without compilation. Any advice welcome. Maybe there is a way to speed up the interpretation. if compilation is fast and only linking is slow, you may recompile haskell modules every time but use ghci to omit linking. just execute ghc compilation command inside ghci before running your app -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to generate random string?
Snouser wrote: I need to generate a random string from 1 to 30. This is the parts I've done so far. unikString xs | let x = unsafePerformIO (randomRIO (1,30)) elem x xs = x : unikString xs | otherwise = unikString xs How do I proceed? I need the string/list to look like this: [1,9,3,6,2] et.c with only unik numbers. Thanks! I wasnt added to the mailinglist, but now I'm. -- View this message in context: http://www.nabble.com/How-to-generate-random-string--tp25512293p25512298.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell-beginners] map question
I actually meant it as sort of a joke but maybe it's not after all. Among the many benefits, think of all the delightful conspiracy theories such a change would spawn - even our math isn't safe now!, Save the minus sign!. --- On Fri, 9/18/09, Jon Fairbairn jon.fairba...@cl.cam.ac.uk wrote: From: Jon Fairbairn jon.fairba...@cl.cam.ac.uk Subject: [Haskell-cafe] Re: [Haskell-beginners] map question To: haskell-cafe@haskell.org Date: Friday, September 18, 2009, 2:09 AM Ketil Malde ke...@malde.org writes: Gregory Propf gregorypr...@yahoo.com writes: Heh, perhaps we should petition to have a new computer key and symbol added to the world's way of writing maths, something like maybe a downward angled slash to mean prefix (-) Or just use 'negate' and 'subtract'? Well, now that ghc accepts unicode characters in programme source, we could ask that ¬ (NOT SIGN, U+00AC) be recategorised as an identifier character and use that (as a simple function name) for negation and lose the wart altogether. class Negatable t where ¬ :: t - t (and as a side effect we could have identifiers like slightly¬dodgy). Or, if we want to make things look even nicer, make ‐ (HYPHEN, U+2010) an identifier character and use − (MINUS SIGN, U+2212) for the infix operator. Now we could have hyphenated‐identifiers too. I think this second option would be the ㊣ (CORRECT, U+32A3) thing to do, though editors and so on would have to be changed to make the distinction readily visible. I think it's Friday, but I'm not entirely sure this is silly. -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Suggested additions to System.FilePath.Posix/Windows
Hi Marcus, Thanks for your suggestions. I'm a Windows user so aren't really qualified to comment on these suggestions - it depends what Posix users would like. I suggest you follow the Library Submission Process - filepath is now a core library, and as such I don't have the freedom/power to change it as I like, and it's generally something lots of people should think about. http://www.haskell.org/haskellwiki/Library_submissions Thanks Neil PS. I'm off for 3 weeks starting very soon, so will be unlikely to reply to any email thread for a long time :-) On Thu, Sep 17, 2009 at 10:58 AM, Marcus D. Gabriel mar...@gabriel.name wrote: Hello Neil I used System.FilePath.Posix quite extensively recently, and I thank you for the package filepath. There were however two words that I needed which I could not construct from those in System.FilePath.Posix. They are maybe of interest to you and others. I submit these two words to you for consideration for inclusion in System.FilePath.Posix. Please change the names as you see fit. I do not know if they make sense for System.FilePath.Windows. If the do not make sense, then please feel free to drop them so as to preserve the interface. As requested, I Cc'ed the haskell-cafe, but I am not at the moment following these threads, so if anyone else responds, please Cc me if you wish. Thanks again and cheers, - Marcus P.S. Here they are. Although I use ksh(1) as an example, this is a feature of POSIX shells. -- | 'reduceFilePath' returns a pathname that is reduced to canonical -- form equivalent to that of ksh(1), that is, symbolic link names are -- treated literally when finding the directory name. See @cd -L@ of -- ksh(1). Specifically, extraneous separators @(\/\)@, dot -- @(\.\)@, and double-dot @(\..\)@ directories are removed. reduceFilePath :: FilePath - FilePath reduceFilePath = joinPath . filePathComponents This is in turn built on filePathComponents that does all the work. filePathComponents :: FilePath - [FilePath] filePathComponents = [] filePathComponents (c:cs) = reverse $ snd $ foldl accumulate (if c == pathSeparator then ([],[/]) else ([c],[])) (cs++[pathSeparator]) where accumulate :: (String,[String]) - Char - (String,[String]) accumulate (cs, css) c = if c == pathSeparator then ([],(if null cs then id else cons cs) css) else (cs++[c],css) cons :: String - [String] - [String] cons cs css | cs == . = css | cs /= .. || null css = cs : css | otherwise = let hd = head css tl = tail css in if hd == [pathSeparator] then css else if hd == .. then cs : css else if null tl then [.] else tl // -- Marcus D. Gabriel, Ph.D. Saint Louis, FRANCE http://www.marcus.gabriel.name mailto:mar...@gabriel.name Tel: +33.3.89.69.05.06 Portable: +33.6.34.56.07.75 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Too much strictness in binary-0.5.0.2
Hello I run into problems with new binary package. Following function reads a list of elements one by one until end of stream. List is very long (won't fit into memory). In binary-0.5.0.1 and earlier it read list lazily. Now it seems that it tries to read whole list to memory. Program does not produce any output and memory usage steadily grows. getStream :: Get a - Get [a] getStream getter = do empty - isEmpty if empty then return [] else do x - getter xs - getStream getter return (x:xs) How could I add laziness to this function to revert to old behavior. -- Khudyakov Alexey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Suggested additions to System.FilePath.Posix/Windows
Hello Neil, Thanks for the pointer Neil. I will read the site. Besides, it allows me to submit a fixed version since I just found a bug! Cheers, - Marcus P.S. 452 black box tests of my little command utility, and I still forgot about a corner case. Now there are 454 black box test cases :). Neil Mitchell wrote: Hi Marcus, Thanks for your suggestions. I'm a Windows user so aren't really qualified to comment on these suggestions - it depends what Posix users would like. I suggest you follow the Library Submission Process - filepath is now a core library, and as such I don't have the freedom/power to change it as I like, and it's generally something lots of people should think about. http://www.haskell.org/haskellwiki/Library_submissions Thanks Neil PS. I'm off for 3 weeks starting very soon, so will be unlikely to reply to any email thread for a long time :-) On Thu, Sep 17, 2009 at 10:58 AM, Marcus D. Gabriel mar...@gabriel.name wrote: Hello Neil I used System.FilePath.Posix quite extensively recently, and I thank you for the package filepath. There were however two words that I needed which I could not construct from those in System.FilePath.Posix. They are maybe of interest to you and others. I submit these two words to you for consideration for inclusion in System.FilePath.Posix. Please change the names as you see fit. I do not know if they make sense for System.FilePath.Windows. If the do not make sense, then please feel free to drop them so as to preserve the interface. As requested, I Cc'ed the haskell-cafe, but I am not at the moment following these threads, so if anyone else responds, please Cc me if you wish. Thanks again and cheers, - Marcus P.S. Here they are. Although I use ksh(1) as an example, this is a feature of POSIX shells. -- | 'reduceFilePath' returns a pathname that is reduced to canonical -- form equivalent to that of ksh(1), that is, symbolic link names are -- treated literally when finding the directory name. See @cd -L@ of -- ksh(1). Specifically, extraneous separators @(\/\)@, dot -- @(\.\)@, and double-dot @(\..\)@ directories are removed. reduceFilePath :: FilePath - FilePath reduceFilePath = joinPath . filePathComponents This is in turn built on filePathComponents that does all the work. filePathComponents :: FilePath - [FilePath] filePathComponents = [] filePathComponents (c:cs) = reverse $ snd $ foldl accumulate (if c == pathSeparator then ([],[/]) else ([c],[])) (cs++[pathSeparator]) where accumulate :: (String,[String]) - Char - (String,[String]) accumulate (cs, css) c = if c == pathSeparator then ([],(if null cs then id else cons cs) css) else (cs++[c],css) cons :: String - [String] - [String] cons cs css | cs == . = css | cs /= .. || null css = cs : css | otherwise = let hd = head css tl = tail css in if hd == [pathSeparator] then css else if hd == .. then cs : css else if null tl then [.] else tl -- Marcus D. Gabriel, Ph.D. Saint Louis, FRANCE http://www.marcus.gabriel.namemailto:mar...@gabriel.name Tel: +33.3.89.69.05.06 Portable: +33.6.34.56.07.75 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] big array allocation too slow?
I'm trying to use newArray to allocate something that has 100M unboxed doubles. It takes quite a few seconds to do so on GHC 6.10.2. But doing the same thing (and initialize all to 0) in C returns immediately. Setting RTS heap size doesn't help. Does anybody happen to know why? -- Regards, Paul Liu Yale Haskell Group http://www.haskell.org/yale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] big array allocation too slow?
ninegua: I'm trying to use newArray to allocate something that has 100M unboxed doubles. It takes quite a few seconds to do so on GHC 6.10.2. But doing the same thing (and initialize all to 0) in C returns immediately. Setting RTS heap size doesn't help. Does anybody happen to know why? Use newArray_ to avoid initialising it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] big array allocation too slow?
wow, using newArray_ and initialize the whole thing myself is much faster than newArray. But why? On 9/18/09, Don Stewart d...@galois.com wrote: ninegua: I'm trying to use newArray to allocate something that has 100M unboxed doubles. It takes quite a few seconds to do so on GHC 6.10.2. But doing the same thing (and initialize all to 0) in C returns immediately. Setting RTS heap size doesn't help. Does anybody happen to know why? Use newArray_ to avoid initialising it. -- Regards, Paul Liu Yale Haskell Group http://www.haskell.org/yale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Compiling Yi's Dependencies on Windows
Hey all, Yi has a lot of dependencies that currently make it a pain to install on Windows, so I'm wondering which of those can be streamlined for easier install on Windows. So far, I haven't succeeded at getting them to work on my own machine, and I've already spent a lot of time on it. The first major impediment is Gtk2Hs. Duncan has mostly resolved this issue with a minimal build that works on 6.10.4 [1], but I think that this should at least be mentioned on the Gtk2Hs site if it is impossible for now to get cabal-install to work by itself. Then comes bindings for things like curl (this may only be needed for Darcs, I don't remember), zlib, and regex (POSIX). If I remember correctly, zlib, or some other library, is able to ship with its *.c/*.h files and compile them as necessary on Windows. Can this be done for regex-posix and curl, too? On my system now, I've got both GnuWin32 and MSYS (MinGW) installed in attempts to get regex headers that work with regex-posix, but, at the moment, I've run into a wall, in which I get this error when loading or linking to regex-posix (it compiles fine itself): ghc.exe: C:\...\cabal\regex-posix-0.94.1\ghc-6.10.4\HSregex-posix-0.94.1.o: unknown symbol `_regerror' Loading package regex-posix-0.94.1 ... linking ... ghc.exe: unable to load package `regex-posix-0.94.1' I doubt most of these changes are significant (like linking on the gtk2hs site to the 6.10.4 build), but changing them could make many apps easier to install on Windows, not just Yi. Are there any other dependencies that have trouble on Windows which I haven't run into yet? If they're library dependencies, can the headers be included in the Hackage tarball? Jeff Wheeler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
