- Haskell-Cafe - Haskell.org

Haskell compilers targeting VMs
by Carlton Mills 24 Feb '12

24 Feb '12

LLVM has a .net and JVM code generator. I don't think it is production ready yet. GHC can generate code via LLVM. So in theory one could run on either VM. However, see the "Why isn't GHC available ..." link below. The GC and library integration would require lot's of work. Good senior project for someone who wishes to spend 3 years as a senior. -Carlton Daniel Peebles pumpkingod at gmail.com A more subtle issue is that there's some sort of memory leak that arises when you can't instruct the GC to follow projection functions of datatypes. I believe the GHC heap representation has a built-in notion of theseforwarding closures and the GC follows them when possible, but most VM GCsare just black boxes. It might still be possible to create an artificialfield in a representation of your closure that the GC can follow, but itcould be tricky.On Thu, Feb 23, 2012 at 11:59 AM, Tom Murphy <amindfv at gmail.com> wrote: >There are some substantial technical challenges: >>http://www.haskell.org/haskellwiki/GHC:FAQ#Why_isn.27t_GHC_available_for_.N… >>Not that it can't be done, but there's nothing ready yet. >>Tom (IRC: amindfv) >>> >> Does any one knows of an Haskell compiler targeting the JVM ? And of one >> targeting the .Net virtual machine ? >> >> Regards, >> ARJANEN Loïc

1 0

ANN: network-socket-options 0.1
by Joey Adams 24 Feb '12

24 Feb '12

I added a new package containing wrappers for getsockopt and setsockopt: http://hackage.haskell.org/package/network-socket-options The network package already has getSocketOption and setSocketOption. The problem is, these don't work for socket options that aren't represented by integers, such as SO_LINGER: http://trac.haskell.org/network/ticket/23 Another, less serious problem is that getSocketOption and setSocketOption don't leverage the type system as well as they could. Many options are boolean values; it'd be better to get and set them with 'Bool's instead of 'Int's. network-socket-options implements options using getter and setter functions, e.g.: getLinger :: HasSocket sock => sock -> IO (Maybe Seconds) setLinger :: HasSocket sock => sock -> Maybe Seconds -> IO () type Seconds = Int The HasSocket type class is defined to overload the getters and setters to work on raw file descriptors, not just Socket objects. This functionality should probably go in the network package itself. However, I decided to release it as a separate package so I could start using it sooner. If people like it enough, perhaps the network package can absorb it, as was done with network-bytestring. -Joey Adams

3 8

Haskell compilers targeting VMs
by ARJANEN Loïc Jean David 23 Feb '12

23 Feb '12

Hello, Does any one knows of an Haskell compiler targeting the JVM ? And of one targeting the .Net virtual machine ? Regards, ARJANEN Loïc

4 3

ANN: cabal-file-th-0.2.2
by Simon Michael 23 Feb '12

23 Feb '12

I have uploaded a new version of cabal-file-th which bumps the Cabal upper bound to avoid difficulties with GHC 7.4. Best - Simon

1 0

getAddrInfo: does not exist
by Alexander Vasiliev 23 Feb '12

23 Feb '12

Hi. I use FreeBsd and get the following error during execution. "mvz_server: getAddrInfo: does not exist (servname not supported for ai_socktype)" System: FreeBsd 7.1; amd64. Haskell: ghc-7.0.3; network-2.3.0.5. The programm works well on Ubuntu and on Windows XP. The piece of code is: bindit :: String -> ServData -> IO() bindit port sd@(mvzs, clnts) = withSocketsDo $ do addrinfos <- getAddrInfo (Just (defaultHints {addrFlags = [AI_PASSIVE]})) Nothing (Just port) I googled that this error was solved in ghc 6.8. But i use ghc 7.0.3. Can anyone help me? Best Regards, Alexander

4 4

Re: [Haskell-cafe] Clarifying a mis-understanding about regions (and iteratees)
by John Lato 23 Feb '12

23 Feb '12

ResourceT really addresses a different problem. Specifically, the issue of how to guarantee that finalizers will run in the context of short-circuiting monadic effects. It does this by providing a single region (not nested regions as Oleg describes) as the base of the monad stack, ensuring that any short-circuiting effects still need to go through the ResourceT layer's finalization steps. Same implementation strategy, different goal. It doesn't provide nested regions, although you may be able to stack multiple ResourceT's on top of each other (I have no idea if this works or not) to do so. The "regions" package (http://hackage.haskell.org/package/regions) is another implementation predating ResourceT. I don't know why it never caught on, except perhaps that at announcement time it was a solution without a problem. John L. > From: Yves Par?s <yves.pares(a)gmail.com> > > Hi, so there are different regions libraries? > Is there a shootout comparing them, possibly also with ResourceT from > conduit (which has also been implemented in a stand-alone package > http://hackage.haskell.org/package/resource-simple-0.1 by Robin Banks), for > I take it it tries to respond to the same problem? > > 2012/2/23 <oleg(a)okmij.org> > >> >> I have just come across the reddit discussion about regions and >> iteratees. >> >> http://www.reddit.com/r/haskell/comments/orh4f/combining_regions_and_iterat… >> >> There is an unfortunate misunderstanding about regions which I'd like to >> correct. I'm posting in Cafe in hope that some of the participants of >> that discussion read Haskell-Cafe (I'm not a redditor). >> >> The user Faucelme wrote: >> > Would it be possible to implement a region-based iteratee which opened >> some >> > file "A" and wrote to it, then opened some file "B" and wrote to it, >> while >> > ensuring that file A is closed before file B is opened? >> >> To which the user tibbe replied >> > You can typically explicitly close the files as well. >> >> and the user dobryak commented >> >> > Regions that Oleg refers to started out with region-based memory >> allocation, >> > which is effectively a stack allocation strategy, in which resource >> > deallocation is in LIFO order. So I think your assumption is correct. >> >> Regretfully, these comments are incorrect. First of all, memory >> regions were invented to get around the stack allocation, LIFO >> strategy. If the stack allocation sufficed, why do we need heap? We >> have heap specifically because the memory allocation patterns are >> complex: a function may allocate memory that outlives it. Regions >> let the programmer create arbitrarily many nested regions; everything >> in a parent region is available to a child. Crucially, a child may >> request any of its ancestors to allocate memory in their >> regions. Therefore, although regions are nested, memory does not have >> to be allocated and freed in LIFO order. >> >> The Lightweight monadic regions implement all these patterns for files >> or other resources (plus the dynamic bequest). >> http://okmij.org/ftp/Computation/resource-aware-prog/region-io.pdf >> >> The running example of the Haskell Symposium 08 paper was the >> following (see sec 1.1) >> >> 1. open two files for reading, one of them a configuration file; >> 2. read the name of an output file (such as the log file) from the >> configuration file; >> 3. open the output file and zip the contents of both input files into >> the output file; >> 4. close the configuration file; >> 5. copy the rest, if any, of the other input file to the output file. >> >> As you can see, the pattern of opening and closing is non-LIFO: the >> output file has to be opened after the configuration file and is >> closed also after the configuration file. Therefore, the user Faucelme >> can find the solution to his question in the code accompanying the >> Monadic Regions paper. >> >> Section 5 of the paper describes even more complex example: >> >> 1. open a configuration file; >> 2. read the names of two log files from the configuration file; >> 3. open the two log files and read a dated entry from each; >> 4. close the configuration file and the newer log file; >> 5. continue processing the older log file; >> 6. close the older log file. >> >> where the pattern of opening and closing is not statically known: >> it is decided on values read from the files. >> >> So, Faucelme's question can be answered in affirmative using the >> existing RegionIO library (which, as has been shown, well integrates >> with Iteratees). There is already a region library with the desired >> functionality. >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >

1 0

Haskell Meeting in Munich
by Heinrich Hördegen 23 Feb '12

23 Feb '12

Dear all, it's time again for our monthly Haskell meeting in Munich. If you plan to join us on Tuesday, 28th of February at Cafe Puck in Munich at 19h30, please go to: http://www.haskell-munich.de/dates and hit the button. This will help us to reserve tables. With hope to meet many of you, Heinrich -- -- hoerdegen(a)funktional.info www.funktional.info --

1 0

Clarifying a mis-understanding about regions (and iteratees)
by oleg＠okmij.org 23 Feb '12

23 Feb '12

I have just come across the reddit discussion about regions and iteratees. http://www.reddit.com/r/haskell/comments/orh4f/combining_regions_and_iterat… There is an unfortunate misunderstanding about regions which I'd like to correct. I'm posting in Cafe in hope that some of the participants of that discussion read Haskell-Cafe (I'm not a redditor). The user Faucelme wrote: > Would it be possible to implement a region-based iteratee which opened some > file "A" and wrote to it, then opened some file "B" and wrote to it, while > ensuring that file A is closed before file B is opened? To which the user tibbe replied > You can typically explicitly close the files as well. and the user dobryak commented > Regions that Oleg refers to started out with region-based memory allocation, > which is effectively a stack allocation strategy, in which resource > deallocation is in LIFO order. So I think your assumption is correct. Regretfully, these comments are incorrect. First of all, memory regions were invented to get around the stack allocation, LIFO strategy. If the stack allocation sufficed, why do we need heap? We have heap specifically because the memory allocation patterns are complex: a function may allocate memory that outlives it. Regions let the programmer create arbitrarily many nested regions; everything in a parent region is available to a child. Crucially, a child may request any of its ancestors to allocate memory in their regions. Therefore, although regions are nested, memory does not have to be allocated and freed in LIFO order. The Lightweight monadic regions implement all these patterns for files or other resources (plus the dynamic bequest). http://okmij.org/ftp/Computation/resource-aware-prog/region-io.pdf The running example of the Haskell Symposium 08 paper was the following (see sec 1.1) 1. open two files for reading, one of them a configuration file; 2. read the name of an output file (such as the log file) from the configuration file; 3. open the output file and zip the contents of both input files into the output file; 4. close the configuration file; 5. copy the rest, if any, of the other input file to the output file. As you can see, the pattern of opening and closing is non-LIFO: the output file has to be opened after the configuration file and is closed also after the configuration file. Therefore, the user Faucelme can find the solution to his question in the code accompanying the Monadic Regions paper. Section 5 of the paper describes even more complex example: 1. open a configuration file; 2. read the names of two log files from the configuration file; 3. open the two log files and read a dated entry from each; 4. close the configuration file and the newer log file; 5. continue processing the older log file; 6. close the older log file. where the pattern of opening and closing is not statically known: it is decided on values read from the files. So, Faucelme's question can be answered in affirmative using the existing RegionIO library (which, as has been shown, well integrates with Iteratees). There is already a region library with the desired functionality.

2 1

Where to get kansas-lava version 2.5
by dilawar rajput 23 Feb '12

23 Feb '12

Hello Cafe, Greetings from Mumbai. Does anyone know where to get kansas-lava version 2.5? On their github repository (as well as on Hackage), they have not posteed version 2.5. However their kansas-lava-cores requires version kansas-lava 2.5. Currently I am working with kansas-lava 2.4 but I can not use their latest kansas-lava-core with it. -- Dilawar

2 2

Preventing leaked open file descriptors when catching exceptions
by Ryan Newton 23 Feb '12

23 Feb '12

Hi all, I'm trying to run a loop that repeatedly attempts to open a file until it succeeds. The file is a named pipe in nonblocking mode, so the writer can only connect after the reader has connected. (Perhaps there is some way to determine this by stat'ing the pipe, but I don't know it yet.) Thus I do something like the following: tryUntilNoIOErr $ do performGC -- The reader must connect first, the writer here spins with backoff. PIO.openFd filename PIO.WriteOnly Nothing fileFlags I'm running GC between iterations to try to make sure I get rid of open files. Also, in the "tryUntilNoIOErr" code below I have some debugging messages which indicate that ioeGetHandle reports no handles associated with the exceptions I'm getting back. (If there were handles provided I could close them explicitly.) In spite of these attempted precautions I'm seeing "too many open files" exceptions in simple benchmarks that should only have a maximum of ONE file open. Any hints / pointers? Thanks, -Ryan mkBackoff :: IO (IO ()) mkBackoff = do tref <- newIORef 1 return$ do t <- readIORef tref writeIORef tref (min maxwait (2 * t)) threadDelay t where maxwait = 50 * 1000 tryUntilNoIOErr :: IO a -> IO a tryUntilNoIOErr action = mkBackoff >>= loop where loop bkoff = handle (\ (e :: IOException) -> do bkoff BSS.hPutStr stderr$ BSS.pack$ " got IO err: " ++ show e case ioeGetHandle e of Nothing -> BSS.hPutStrLn stderr$ BSS.pack$ " no hndl io err." Just x -> BSS.hPutStrLn stderr$ BSS.pack$ " HNDL on io err!" ++ show x loop bkoff) $ action

4 5