Re: [Haskell-cafe] H98, OOHaskell - getting started with objects in Haskell
Am Donnerstag, den 13.01.2011, 15:23 -0800 schrieb gutti: I'm especially interestes in engineering calculation tasks where cellular automata could be used. In that case all u have to do is to give the class the right properties and that let it grow. Such a localised intelligence approach seems an ideal OO - task. I don't know whether something functional could achieve the same. Is this really ideal for OO? I thought that in a cellular automaton, all cells have to change synchronously. In addition, cells have to access the old states of their neighbours to compute their new states. So you would have to heavily synchronize the objects. In this light, I’d say that the distributed OO approach isn’t very practical. A global control of the whole system might be better. Note that I’m by no way an expert in cellular automata. I’m just thinking of the game of life. :-) Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] H98, OOHaskell - getting started with objects in Haskell
On 11-01-13 06:23 PM, gutti wrote: I'm especially interestes in engineering calculation tasks where cellular automata could be used. In that case all u have to do is to give the class the right properties and that let it grow. Such a localised intelligence approach seems to be exactly existential type and/or message passing. It looks OO because people's first exposure to existential type and message passing is through OO. But OO also bundles a lot of things not needed for this, for example I doubt that inheritance is needed. You could use OO but you don't need OO. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] H98, OOHaskell - getting started with objects in Haskell
Hi Philipp, depending on what engineering calculations you are interested in, you might like http://timber-lang.org/ , a direct descendant of O'Haskell, targeted at embedded real-time systems. If you are just stepping out of the OO programming world, it might be helpful to imagine OO as a rather narrow specialization of a concept called type, so that from the FP perspective it is just one of so many alternatives so that it gets lost a little -- which may be a useful translation to use. So the short answer to where's OO? in Haskell might just be data, while the expressive freedom of type classes / families might surprise you. There have been some people playing with cellular automata, Google helps, e.g.: http://mjsottile.wordpress.com/ http://trac.haskell.org/gloss/ Both cases might give you an impression how it's done with Haskell types. If you really are interested in using the OO class concept together with the Haskell type system by a more than practical motivation, an expert in the field who is interested in the subject for a long time is Peter Padawitz (http://fldit-www.cs.uni-dortmund.de/~peter/ http://fldit-www.cs.uni-dortmund.de/%7Epeter/); he has presented a beautiful synthesis based on category theory, swinging types (http://fldit-www.cs.uni-dortmund.de/~peter/Swinging.html http://fldit-www.cs.uni-dortmund.de/%7Epeter/Swinging.html). Of course, he did also use O'Haskell for his programming works in the past. Cheers, Nick On 01/14/2011 12:23 AM, gutti wrote: Hi, thanks for all Your answers (and again I'm amazed how active and good this forum is). I expected OOHaskell to be on the somewhat extended side, but I didn't expect it to be so uncommon. This very strong and clear feedback is indeed very valuable. I think I see the complexities of OO-programming in larger programs (unforeseen interactions), but I'm still doubtfull, that functional programming can equally adress all tasks equally efficient. I'm especially interestes in engineering calculation tasks where cellular automata could be used. In that case all u have to do is to give the class the right properties and that let it grow. Such a localised intelligence approach seems an ideal OO - task. I don't know whether something functional could achieve the same. Sounds like a nice challenge. -- I'll chew on a small example. Cheers Phil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Needed: A repeatable process for installing GHC on Windows
Hi, Earlier today I was trying to set up a Windows build bot for the 'network' package. That turned out to be quite difficult. Too much playing with PATHs, different gcc versions, etc. Does anyone have a repeatable, step-by-step process to install GHC and get a build environment (where I could build network) going? Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] H98, OOHaskell - getting started with objects in Haskell
Hi! 2011/1/14 gutti philipp.guttenb...@gmx.net I'm especially interestes in engineering calculation tasks where cellular automata could be used. In that case all u have to do is to give the class the right properties and that let it grow. Such a localised intelligence approach seems an ideal OO - task. I don't know whether something functional could achieve the same. Thanks to your question, I took another look and the old and wonderful OOHaskell paper. It is very well written and describes almost exhaustively the haskell alternatives and their shortcomings: http://homepages.cwi.nl/~ralf/OOHaskell/paper.pdf Honestly, with the information I can have, my view is that the ·let it grow issue in the full is only achievable by following the OOHaskell path, but you can use the other ways paying a little price. This past discussion also applies: http://www.haskell.org/pipermail/haskell-cafe/2006-January/013925.html Sounds like a nice challenge. -- I'll chew on a small example. Cheers Phil -- View this message in context: http://haskell.1045720.n5.nabble.com/H98-OOHaskell-getting-started-with-objects-in-Haskell-tp3338991p3340604.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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Question concerning Network.Curl.Opts
I'm having trouble passing header strings properly, and I'd like some advice on how to proceed. Below is a capture of what is being sent, versus what I am trying to send. I won't include all code, only what I think is necessary. If I have omitted something important, please let me know. How could I discover what the cause of the discrepancy is? Thanks again for any feedback. Here's a snippet from the header, what is being sent. GET /resourceList.do?form=webForwardsFormreadOnly=falsepolicyLaunching=trueresourcePrefix=webForwardspath=%2FshowWebForwards.domessageResourcesKey=webForwardsactionPath=%2FresourceList.do HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) Host: 172.16.1.18 Accept: */* Accept-Encoding: gzip,deflate Referer: https://172.16.1.18/showWebForwards.do Cookie: domainLogonTicket=SLXa10225c6e8389b3eb181e3df5dcf08de; logonTicket=SLXa10225c6e8389b3eb181e3df5dcf08de; lbTrack=OAIAGHMWQDOLYYTJEXQHXBYPXVALXNREKIHAYYRZSOGYJLUYNNCJ; SSLX_SSESHID=bvgx4mggmy6v ^ compare this to CurlHttpHeaders Here's the part of the source I think is relevant launch :: String - String - IO (Either String String) launch user pass = do -- Initialize Curl curl - initCurl -- Sequence of steps let steps = do curlResp curl urlInitial method_GET curlResp curl urlLogin $ loginOpts user pass curlResp curl urlFlash1 method_GET curlResp curl urlFlash2 method_GET curlResp curl urlGetResource resourceOpts here's where the problem is revealed runErrorT steps main :: IO () main = do -- username and password user:pass:_ - getArgs -- Launch webpage resp - launch user pass -- Response comes as Either String String -- You have to handle each case case resp of Left err - print err Right body - putStrLn body resourceOpts :: [CurlOption] resourceOpts = [ CurlHttpHeaders [ Accept text/javascript, text/html, application/xml, text/xml, */* , Accept-Language en-us,en;q=0.5 , Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7 , Keep-Alive 115 , Connection keep-alive , X-Requested-WithXMLHttpRequest , X-Prototype-Version 1.6.0.3 ] , CurlEncoding gzip,deflate , CurlReferer https://172.16.1.18/showWebForwards.do; ] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Needed: A repeatable process for installing GHC on Windows
On Fri, 14 Jan 2011 23:53:33 +0100, Johan Tibell johan.tib...@gmail.com wrote: Hi, Earlier today I was trying to set up a Windows build bot for the 'network' package. That turned out to be quite difficult. Too much playing with PATHs, different gcc versions, etc. Does anyone have a repeatable, step-by-step process to install GHC and get a build environment (where I could build network) going? Johan A Google search lead to: http://neilmitchell.blogspot.com/2010/12/installing-haskell-network-library-on.html Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] parsec2 vs. parsec3... again
On Thu, Jan 13, 2011 at 12:15 AM, Evan Laforge qdun...@gmail.com wrote: Well, I tried it... and it's still slower! parsec2, String: (a little faster since last time since I have new computer) total time = 9.10 secs (455 ticks @ 20 ms) total alloc = 2,295,837,512 bytes (excludes profiling overheads) attoparsec-text, Data.Text: total time = 14.72 secs (736 ticks @ 20 ms) total alloc = 2,797,672,844 bytes (excludes profiling overheads) Interesting. Just in case there's some useful criticism, here's one of the busier parsers: p_unsigned_float :: A.Parser Double p_unsigned_float = do i - A.takeWhile Char.isDigit f - A.option (A.char '.' A.takeWhile1 Char.isDigit) if (Text.null i Text.null f) then mzero else do case (dec i, dec f) of (Just i', Just f') - return $ fromIntegral i' + fromIntegral f' / fromIntegral (10 ^ (Text.length f)) _ - mzero where dec :: Text.Text - Maybe Int dec s | Text.null s = Just 0 | otherwise = case Text.Read.decimal s of Right (d, rest) | Text.null rest - Just d _ - Nothing I've tried creating a benchmark using this code. It's on the recently created attoparsec-text darcs repo [1,2]. There is a 2.7 MiB test file with many numbers to be parsed. The attoparsec-text package was installed using -O (Cabal's default) and the test program was compiled with ghc -hide-package parsec-3.1.0 --make -O2. Using parsers that return the parsed number as a double and then sum everything up, I get the following timings: attoparsec_text_builtin 2,241,038,864 bytes allocated in the heap 46 MB total memory in use (1 MB lost due to fragmentation) MUT time1.10s ( 1.13s elapsed) GCtime0.15s ( 0.20s elapsed) Total time1.25s ( 1.32s elapsed) attoparsec_text_laforge 1,281,603,768 bytes allocated in the heap 101 MB total memory in use (2 MB lost due to fragmentation) MUT time0.58s ( 0.62s elapsed) GCtime0.47s ( 0.54s elapsed) Total time1.05s ( 1.16s elapsed) parsec_laforge 1,558,621,208 bytes allocated in the heap 47 MB total memory in use (0 MB lost due to fragmentation) MUT time0.82s ( 0.84s elapsed) GCtime0.46s ( 0.51s elapsed) Total time1.27s ( 1.35s elapsed) 'attoparsec_text_builtin' uses Data.Attoparsec.Text.double available on the darcs version of the library. It tries to handle more cases, like exponents, and thus it is expected to be slower than your version. 'attoparsec_text_laforge' and 'parsec_laforge' are very similar to the one you gave in your e-mail, but with some modifications (e.g. Text.Read.decimal can't be used with Strings). Using attoparsec-text is faster and allocates less, but for some reason the faster version takes up a lot more memory. As the total memory figures were strange, I created a different version that parses the input but does not create any Doubles. Instead of summing them, the number of Doubles (if they were parsed) is counted. These are the results: attoparsec_text_laforge_discarding 985,843,696 bytes allocated in the heap 25 MB total memory in use (0 MB lost due to fragmentation) MUT time0.38s ( 0.39s elapsed) GCtime0.07s ( 0.10s elapsed) Total time0.45s ( 0.49s elapsed) parsec_laforge_discarding double_test.txt +RTS -s 1,471,829,664 bytes allocated in the heap 28 MB total memory in use (0 MB lost due to fragmentation) MUT time0.66s ( 0.68s elapsed) GCtime0.44s ( 0.46s elapsed) Total time1.10s ( 1.14s elapsed) Now attoparsec-text is more than twice faster, allocates even less memory and the total memory figures seem right. Bottom line: I think this benchmark doesn't really represent the kind of workload your parser has. Can you reproduce these results on your system? Cheers! =) [1] http://patch-tag.com/r/felipe/attoparsec-text/ [2] http://patch-tag.com/r/felipe/attoparsec-text/snapshot/current/content/pretty/benchmarks/Double.hs -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] parsec2 vs. parsec3... again
Now attoparsec-text is more than twice faster, allocates even less memory and the total memory figures seem right. Bottom line: I think this benchmark doesn't really represent the kind of workload your parser has. Can you reproduce these results on your system? I spent quite a bit of time trying to reduce this down to a minimal reproduction and getting confusing results. Then I found out that compiling with profiling enabled makes attoparsec slow and parsec fast. When I compile without any profiling, here's what I get, in CPU time: parsec run 100 - time: 1.22s - atto bs run 100 - time: 0.38s - atto text run 100 - time: 0.78s - This looks more like I expect it to. I don't understand the parsec thing... one of the first things I did was recompile and reinstall parsec2, making sure to pass -p to configure, and verify that there is a /usr/local/lib/parsec-2.1.0.1/ghc-6.12.3/libHSparsec-2.1.0.1_p.a. However, on closer inspection, I believe I've found the culprit. Compiling with 'build -v' for attoparsec reveals a ghc cmdline line: '-prof -hisuf p_hi -osuf p_o -auto-all'. Compiling parsec has: '-prof -hisuf p_hi -osuf p_o'. And indeed, attoparsec cabal has 'ghc-prof-options: -auto-all', which parsec's cabal does not. And in fact, parsec3 also has this -auto-all, which both explains why the profile is full of internal functions and why parsec3 was so much slower than parsec2. I'm glad to have finally tracked this down, but unhappy that I spent so much time on it. It seems like a trap waiting to be sprung if various libraries are compiled with their individually specified flags, which have major effects on performance. Maybe I should have noticed, but it seems pretty subtle to me. GHC will refuse to compile non-profiling libs against a profiling build, but doesn't go down to the level of flags. I think my short term solution is going to be remove -auto-all from attoparsec's cabal---I'm not profiling attoparsec and so I don't want my entire profile output to be internal attoparsec functions. But presumably the flag was added there for a reason, so maybe there are people who really want that. Is there a better solution? GHC warns when linking a profiling lib compiled with different profiling flags? A separate .p_auto-all_o suffix? Removal of ghc-prof-options from cabal? A consensus to standardize on a set of flags? BTW, yes my situation is a little different from your test. It's lots and lots of little expressions for a simple language in an in-memory structure that get parsed individually. So I don't care about file reading speed, but I do care about parser startup overhead, since it's lots and lots of little parses. The numbers above are how long it takes to parse 2.34 1m times. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] parsec2 vs. parsec3... again
On Fri, Jan 14, 2011 at 5:54 PM, Evan Laforge qdun...@gmail.com wrote: Then I found out that compiling with profiling enabled makes attoparsec slow and parsec fast. Yes, the SCC annotations added by GHC have a fairly high cost. I think my short term solution is going to be remove -auto-all from attoparsec's cabal---I'm not profiling attoparsec and so I don't want my entire profile output to be internal attoparsec functions. But presumably the flag was added there for a reason, so maybe there are people who really want that. Yes - me :-) I typically turn on profiling for most of my libraries while I think of them as under development, a period of indefinite length that comes to an end when I deem the performance good enough. None of my libraries has actually hit that point yet :-) This isn't completely without basis. For instance, I made some big speed improvements to attoparsec's very performance-sensitive takeWhile function just the other day, thanks to -auto-all. I might, though, see if there's a way I could enable that flag only for myself (in a way that I wouldn't routinely forget). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
