Thread-backed handles: thread blocked indefinitely in an MVar operation
Hi, I am experimenting with the new feature in GHC such as custom Handles. I use GHC 6.12.2, base 4.2.0.1 I have pasted the code in question as http://hpaste.org/fastcgi/hpaste.fcgi/view?id=26413#a26413 I am trying to create a Handle using a thread as data producer. In my example is is a union of directories, and the Handle contents is newline-separated list of full paths of all files in the union. This list is produced by a thread which reads contents of all directories in the union, turns them into absolute filenames, and sends to the channel. The method of BufferedIO responsible for filling in the Handle's buffer reads data from the channel and places it in the buffer. The problem is, after the contents of the Handle (via hGetContents) has been consumed, the program crashes with the following message: : thread blocked indefinitely in an MVar operation that is, the BlockedIndefinitelyOnMVar exception has occurred. What is done wrong in my code? The dirClose method seems to be called (its output shows up), however with or without the call to killThread, the exception occurs anyway. Thanks for any ideas. -- Dimitry Golubovsky Anywhere on the Web ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: new recursive do notation (ghc 6.12.x) spoils layout
I think this would just require the lex layout rules already in place for do/let in GHC; my guess is that your example would work if the body were indented past the "r" of "rec". for the record ... > t2 = > do rec > a <- getChar > b <- f c > c <- g b > putChar c > return b > f = return . (const 'a') > g = return eg.lhs:23:6: The last statement in a 'do' construct must be an expression Failed, modules loaded: none. so I suppose it is not so far from "recognising" the construct and yet too far! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: new recursive do notation (ghc 6.12.x) spoils layout
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/21/10 13:18 , John Lask wrote: > it does spoil the nice layout - it would be nice to just be able to write > (which does not parse) > > do rec > a <- getChar > b <- f c > c <- g b > putChar c > return b > > I don't particularly care that the only recursive statements are #2,#3 - I > just want my nice neat layout back. I have just spent an inordinate amount > of time updating code when if the parser recognised "do rec" as a recursive > group it would have been a drop in replacement and taken me one tenth of the > time. I think this would just require the lex layout rules already in place for do/let in GHC; my guess is that your example would work if the body were indented past the "r" of "rec". - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkweuP0ACgkQIn7hlCsL25XifQCgzvfvf9utQxkb2gdmVRPyhea2 iIUAnRT8XUhTKds0wrVkFaccyzAKTA9v =YjX6 -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
new recursive do notation (ghc 6.12.x) spoils layout
Whilst I have nothing against the change in syntax for recursive do aka
http://old.nabble.com/Update-on-GHC-6.12.1-td26103595.html
Instead of writing
mdo
a <- getChar
b <- f c
c <- g b
putChar c
return b
you would write
do
a <- getChar
rec { b <- f c
; c <- g b }
putChar c
return b
it does spoil the nice layout - it would be nice to just be able to
write (which does not parse)
do rec
a <- getChar
b <- f c
c <- g b
putChar c
return b
I don't particularly care that the only recursive statements are #2,#3 -
I just want my nice neat layout back. I have just spent an inordinate
amount of time updating code when if the parser recognised "do rec" as a
recursive group it would have been a drop in replacement and taken me
one tenth of the time.
Why can't we have this?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Modules and their explicit export lists (are an annoyance)
Another useful extension here could be "friend modules" and "friend packages," similar to friend declarations in C++. Then a restricted set of modules or packages could see inside a package to extend it, even as the package is closed to the rest of the world. Alex On Sat, Jun 19, 2010 at 1:29 PM, Roman Beslik wrote: > Hi, Christian. Here is my humble and somewhat vague thoughts. I think that > export list is reasonable for commonly used and stable (ancient) library. > Export list is a contract between library's author and user. Though current > Haskell rules force author to have one and only one contract with all the > people in the world. E.g. in law there is no such restriction. Assuming that > (using/not using) an unstable function in the library is responsibility of > library's user (not author), there may be: > - declaration "import hidden" for importing everything; > - compiler option for banning "import hidden"; > - several export lists (in separate files) for different type of users. > On 19.06.10 21:38, Christian Höner zu Siederdissen wrote: >> >> Hi everybody, >> >> I'd like some input on other peoples' thoughts on this. Recently, I >> played around with a library that uses an explicit export list. >> … >> But the more important thing is, that it makes extending module >> functionality a pain (eg. if a constructor is not exported using (..)). >> So, should I really fork a library just to be able to add a function? >> > > -- > Best regards, > Roman Beslik. > > ___ > 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: Modules and their explicit export lists (are an annoyance)
On Sat, Jun 19, 2010 at 07:23:50PM -0700, Evan Laforge wrote: > On Sat, Jun 19, 2010 at 6:00 PM, Felipe Lessa wrote: > > On Sat, Jun 19, 2010 at 08:38:52PM +0200, Christian Höner zu Siederdissen > > wrote: > >> But the more important thing is, that it makes extending module > >> functionality a pain (eg. if a constructor is not exported using (..)). > > > > I think this is another problem. Sure, without export lists you > > *currently* can't hide those constructors. However, languages > > like Java don't have export lists as well. Imagine if we could > > write this in Haskell: > > > > private data Foo a = Foo a (Foo (Either a a)) > > But that's just a syntactical difference. I suspect whether you > prefer to put visibility directly on the definition or collect it all > in one place depends on personal taste and what you're used to. That's my point. Hiding a constructor is orthogonal to using export lists. Cheers, -- Felipe. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
