Re: Re: 6.4.3 and threaded RTS problems
I ran the testsuite against the current HEAD (as of saturday afternoon) and had far fewer failures. Is the last week's work supposed to have fixed so many test cases? Or are different machines giving different results? The tests that resulted in unexpected failures for greg were all run on my machine, but many of them worked on my setup. -david k. -- Results for a lightly loaded dual proc G5 running OS 10.4.7. OVERALL SUMMARY for test run started at Sat Aug 26 19:00:07 PDT 2006 1434 total tests, which gave rise to 6334 test cases, of which 0 caused framework failures 1107 were skipped 5138 expected passes 47 expected failures 3 unexpected passes 39 unexpected failures Unexpected passes: barton-mangler-bug(optasm) cholewo-eval(optasm,profasm) Unexpected failures: TH_repPatSig(normal) barton-mangler-bug(opt) conc019(opt) conc024(normal) conc039(threaded1) conc056(threaded1) ffi009(ghci) ffi016(normal,prof) gadt7(normal) galois_raytrace(opt,prof) maessen_hashtab(normal,opt,optasm,prof,profasm,ghci,threaded1) rnfail026(normal) signals002(ghci) tcfail068(normal) tcfail071(normal) tcfail090(normal) tcfail099(normal) tcfail103(normal) tcfail115(normal) tcfail140(normal) tcrun021(normal,opt,optasm,prof,profasm,ghci,threaded1) utf8_002(normal) utf8_003(normal) utf8_004(normal) utf8_005(normal) On 8/24/06, Gregory Wright [EMAIL PROTECTED] wrote: Here's what happened (this is after I applied David Kirkman's SMP.h patch to my tree). When I said 132 failures I was speaking from memory. The actual number was 136, as noted in the log: OVERALL SUMMARY for test run started at Mon Aug 14 11:20:03 EDT 2006 1412 total tests, which gave rise to 4711 test cases, of which 0 caused framework failures 658 were skipped 3882 expected passes 32 expected failures 3 unexpected passes 136 unexpected failures Unexpected passes: barton-mangler-bug(optasm) cholewo-eval(optasm) ds052(normal) Unexpected failures: TH_spliceE5_prof(normal) arr004(normal,opt,optasm) arr007(opt,optasm) barton-mangler-bug(opt,threaded2) cabal01(normal) cabal02(normal) cg016(normal,opt,optasm) cg051(opt,optasm) conc012(normal) conc014(opt,optasm) conc021(opt,optasm) conc024(normal,opt,optasm) conc034(normal,opt,optasm) conc037(threaded2) conc039(threaded1) conc052(opt) conc056(threaded1,threaded2) concprog001(normal,opt,optasm) concprog002(threaded2) dsrun005(opt,optasm) dsrun007(opt,optasm) dsrun008(opt,optasm) enum01(normal,opt,optasm) enum02(normal,opt,optasm) enum03(normal,opt,optasm) exceptions001(normal,opt,optasm) exceptions002(opt,optasm) forkprocess01(ghci) galois_raytrace(opt,threaded2) ghci013(ghci) ghcpkg04(normal) joao-circular(optasm) list001(normal,opt,optasm) maessen_hashtab(normal,opt,optasm,ghci,threaded1,threaded2) mod1(normal) mod150(normal) mod151(normal) mod152(normal) mod153(normal) mod2(normal) net001(normal,opt,optasm,ghci,threaded1,threaded2) net002(normal,opt,optasm,ghci,threaded1,threaded2) newtype(opt) pkg02_b(normal,opt,optasm) read003(normal) rw(normal) seward-space-leak(ghci) signals002(ghci) simpl011(normal,opt,optasm) strun002(opt) tc102(normal,opt,optasm) tc134(normal,opt,optasm) tc136(normal,opt,optasm) tc141(normal,opt,optasm) tcfail068(normal) tcfail071(normal) tcfail082(normal) tcfail090(normal) tcfail099(normal) tcfail103(normal) tcfail115(normal) tcfail140(normal) tcrun021(normal,opt,optasm,ghci,threaded1,threaded2) uri001(normal,opt,optasm,ghci,threaded1,threaded2) utf8_002(normal) utf8_003(normal) utf8_004(normal) utf8_005(normal) Cheers, Simon /Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Exists any null instruction in Haskell?
On 8/27/06, Neil Mitchell [EMAIL PROTECTED] wrote: [Moving to haskell-cafe] Hi, I want to know if it exists a null instruction (a instruction that do anything Not really, since instructions don't do anything anyway - they only compute values. If you are in the IO monad then return () is the do nothing. I need this answer. This is my case. Thanks you very much. In the function world, id is the do nothing. In recursive list processing, then something like [] is probably the base case in a recursive function, so stops the recursivity. If you give a more concrete example, then maybe we can give you a better answer. Thanks Neil ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] [Haskell - I/O] Problem with 'readFile'
On 8/27/06, John Hughes [EMAIL PROTECTED] wrote: Hi, I use the operation 'readFile' for obtain information locates on a file. When I try to write another information on the same file, I obtain this error message: openFile: permision denied. I found this: The readFile operation holds a semi-closed handle on the file until the entire contents of the file have been consumed. It follows that an attempt to write to a file (using writeFile, for example) that was earlier opened by readFile will usually result in failure with isAlreadyInUseError. in this web http://www.haskell.org/onlinereport/io.html. How can I break that semi-closed handle for to write in the preaviously readed file? Thank you. readFile returns an *unevaluated* list of characters from the file--as your program needs those characters, so they will be read from the file. Once they have all been read, then the file is closed. So to ensure that the file is closed, you just have to make sure your program reads all the characters. One way is to count them. So here's a function that reads a file, then rewrites it with hello added at the beginning: addHello f = do s - readFile f length s `seq` writeFile f (hello++s) length s counts the characters in the file (forcing it all to be read), and the `seq` is like a semicolon in C: it forces length s to be computed before the writeFile is performed. John Thanks you for your code. I try with it and it works well, but I can not use it in my aplication because I read the file in one function, I compute the results with the readed information and, finally, I wrote this results in another function (in this moment I do not have the readed string, I have my structured data). How can I use this `seq` with different functions? ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] [Haskell - I/O] Problem with 'readFile'
L. J. wrote: Hi, I use the operation 'readFile' [...] How can I break that semi-closed handle for to write in the preaviously readed file? Thank you. Not at all. But you can get the same effect you get from 'readFile' if you use 'openFile' and 'hGetContents'. If you do the latter, you can really close the semi-closed handle by calling 'hClose'. However, chances are, that you will not have consumed the whole file at the point where you close it (lazy evaluation can^W will be tricky), you will find that you write a new file with empty content, because apparently you read an empty file when in fact it wasn't empty, and so on. In short: don't do that. Also, don't fight the error message, understand, that it saved you from trashing a perfectly good file. Instead, 'readFile' your data, 'writeFile' it into a new(!) file, then 'renameFile' the new over the old one. Before doing anything else, get a deep understanding of lazy IO. (And this understanding will basically be, that a database package (gdbm, Berkeley DB, you name it) will serve you better.) Udo. -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Brandeis signature.asc Description: Digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] [Haskell - I/O] Problem with 'readFile'
On 8/27/06, L. J. [EMAIL PROTECTED] wrote: On 8/27/06, John Hughes [EMAIL PROTECTED] wrote: Hi, I use the operation 'readFile' for obtain information locates on a file. When I try to write another information on the same file, I obtain this error message: openFile: permision denied. I found this: The readFile operation holds a semi-closed handle on the file until the entire contents of the file have been consumed. It follows that an attempt to write to a file (using writeFile, for example) that was earlier opened by readFile will usually result in failure with isAlreadyInUseError. in this web http://www.haskell.org/onlinereport/io.html. How can I break that semi-closed handle for to write in the preaviously readed file? Thank you. readFile returns an *unevaluated* list of characters from the file--as your program needs those characters, so they will be read from the file. Once they have all been read, then the file is closed. So to ensure that the file is closed, you just have to make sure your program reads all the characters. One way is to count them. So here's a function that reads a file, then rewrites it with hello added at the beginning: addHello f = do s - readFile f length s `seq` writeFile f (hello++s) length s counts the characters in the file (forcing it all to be read), and the `seq` is like a semicolon in C: it forces length s to be computed before the writeFile is performed. John Thanks you for your code. I try with it and it works well, but I can not use it in my aplication because I read the file in one function, I compute the results with the readed information and, finally, I wrote this results in another function (in this moment I do not have the readed string, I have my structured data). How can I use this `seq` with different functions? I solve the problem, but my method could not be the better (methodologically speaking). I insert this code inmediately after read the file (with readFile): length mates_str `seq` return () Is it so bad this code? I think it works so well. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] [Haskell - I/O] Problem with 'readFile'
On 8/27/06, Donald Bruce Stewart [EMAIL PROTECTED] wrote: djsenda: Hi, I use the operation 'readFile' for obtain information locates on a file. When I try to write another information on the same file, I obtain this error message: openFile: permision denied. I found this: The readFile operation holds a semi-closed handle on the file until the entire contents of the file have been consumed. It follows that an attempt to write to a file (using writeFile, for example) that was earlier opened by readFile will usually result in failure with isAlreadyInUseError. in this web http://www.haskell.org/onlinereport/io.html. How can I break that semi-closed handle for to write in the preaviously readed file? Thank you. Due to lazy IO, you'll need to either read the entire file first, before you can safely write to that file, (or explicitly close the Handle): import Control.Exception main = do s - readFile x evaluate $ length s -- evaluate the list, reading it in writeFil e x (reverse s) GHCi says me that: evaluate is not in scope Here we use 'evaluate (length s)' to explictily force the entire file to be read, which will close the Handle, and allows us to safely write back to the same file. -- Don P.S. Learning Haskell questions are better addressed to haskell-cafe@haskell.org Ok, for another question I will write in this mailing list. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re[2]: [Haskell] [Haskell - I/O] Problem with 'readFile'
Hello L., Sunday, August 27, 2006, 12:43:24 PM, you wrote: length s `seq` writeFile f (hello++s) length mates_str `seq` return () it's the same. i recommend you to use: return $! tail mates_str $! defined as f$!x = x `seq` f x 'tail' should be slightly faster than 'len' -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Re[2]: [Haskell] [Haskell - I/O] Problem with 'readFile'
Bulat Ziganshin wrote: length mates_str `seq` return () it's the same. i recommend you to use: return $! tail mates_str 'tail' should be slightly faster than 'len' ...but also slightly less correct. You probably meant 'last'. (But it's still an ugly and dangerous programming style.) Udo. -- Why is television called a medium? Because it is neither rare nor well-done. signature.asc Description: Digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re[4]: [Haskell] [Haskell - I/O] Problem with 'readFile'
Hello John, Sunday, August 27, 2006, 5:45:21 PM, you wrote: return $! tail mates_str But you need to evaluate the result of readFile all the way to the end--you need to use a function that traverses the entire file contents. Otherwise the file will be left open to read the bit you haven't traversed. Hence length rather than tail. oh, sorry, i mean 'last' -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] AutoForms release 0.2
Hi all Haskeleers I am pleased to announce AutoForms release 0.2. AutoForms is a library to ease the creation of Graphical User Interfaces (GUI). It does this by using generic programming (SYB) to construct GUI components. See the full description at http://autoforms.sourceforge.net/ . Any comments will be much appreciated. Greetings, Mads Lindstrøm ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: Haddock/GHC SoC project over
Hi everyone, Here is a short status report of the Port Haddock to use GHC Summer of Code project, which is now over. Part 1), the GHC modifications, are finished and will be included in the GHC head repository as soon we have made sure that they don't cause any significant slowdowns. Part 2), the actual port of Haddock, is able to render the examples/Test.hs file from the original distribution. There are some problems however, most notably a GHC API panic that keep it from rendering docs for many packages. In terms of functionality, the port is at a very experimental stage, and work remains to render the full set of GHC syntax and to support more than just HTML rendering (e.g Hoogle output). To try the code out, grab these repositories: http://darcs.haskell.org/SoC/ghc.haddock http://darcs.haskell.org/SoC/haddock.ghc You have to compile and install ghc.haddock and then use it to compile and install haddock.ghc. If you want to help out, or just have questions, email me or ping me on #haskell. But maybe the best place to discuss would be [EMAIL PROTECTED], where everyone can follow. Big thanks to Google, haskell.org and Simon M! /David ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Optimistic Evaluation?
Hi, I remember once reading a paper by SPJ about Optimistic Evaluation that is somewhere between lazy and strict. If I remember correctly, they even implemented it in GHC. Now, it seems that current version of GHC doesn't support optimistic evaluation (not even as an optional feature), so my question is: what happened to OE? Was it that it seemed like a good idea on paper but not in reality? Or was it too costly to maintain? Or it didn't deliver the goods it promised? I'm just curious. Regards, Lajos Nagy ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell - I/O] Problem with 'readFile'
L. J. wrote: Hi, I use the operation 'readFile' for obtain information locates on a file. When I try to write another information on the same file, I obtain this error message: openFile: permision denied. I found this: The readFile operation holds a semi-closed handle on the file until the entire contents of the file have been consumed. It follows that an attempt to write to a file (using writeFile, for example) that was earlier opened by readFile will usually result in failure with isAlreadyInUseError. in this web http://www.haskell.org/onlinereport/io.html. How can I break that semi-closed handle for to write in the preaviously readed file? Thank you. Since readFile reads the file lazily (on demand), you have to make sure that the whole file gets read by completely evaluating the result string. BTW, I think haskell-cafe is the more appropriate forum for questions like these. Cheers Ben ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Optimistic Evaluation?
On Sun, Aug 27, 2006 at 05:51:34PM -0400, Lajos Nagy wrote: I remember once reading a paper by SPJ about Optimistic Evaluation that is somewhere between lazy and strict. If I remember correctly, they even implemented it in GHC. Now, it seems that current version of GHC doesn't support optimistic evaluation (not even as an optional feature), so my question is: what happened to OE? It was only ever in a branch of ghc 5.something. Was it that it seemed like a good idea on paper but not in reality? Or was it too costly to maintain? Or it didn't deliver the goods it promised? I'm just curious. My understanding is that the benefit it gave didn't make up for the increased complexity of GHC's source code. Thanks Ian ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Derived Read instance for types with infix constructors (ghc 6.4.1)
Am Sonntag, 27. August 2006 01:02 schrieb Daniel Fischer: Extremely odd, today ghc 6.4.2 (also on linux) works for me, too: Prelude InfixR show (A `And` A) A `And` A Prelude InfixR show (And A A) A `And` A Prelude InfixR read (show (And A A)) :: T A `And` A Prelude InfixR read And A A :: T *** Exception: Prelude.read: no parse Prelude InfixR read A `And` A :: T A `And` A (and it can't read And A A, which is what ghc 6.2.2 could read), yesterday it couldn't read either form. What sort of hiccough could produce such behaviour? Bewildered, Daniel Probably my sleep deprived memory erred and what couldn't read either form was ghc 6.4.1. Bash history confirms that this is definitely a possibility. And since it's far easier to believe that I erred in this respect than that the derived Read instance of one day could read what that from another day couldn't, I'm pretty sure that's what happened. Sorry. Another thing: Would it be a good idea to create derived Read instances that could parse both, A `And` A and And A A ? Since 6.4.2 parses the former and 6.2.2 parses the latter that should be possible, I believe (and both forms are accepted at the ghci prompt). Cheers, Daniel -- In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt. -- Blair P. Houghton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
