- Haskell-Cafe - Haskell.org

GLFW-0.5.0.0 is released
by Paul Liu 22 Jan '12

22 Jan '12

There is now a new GLFW package on hackage with version number 0.5.0.0. Maintainers of packages that depend on GLFW may want to update your packages since (1) GLFW-0.4.2 is mostly broken on OS X Lion (10.7); (2) there are incompatible API changes. Notable changes include (but not limited to): 1. It now uses GLFW C library version 2.7.2 on all platforms. 2. It still tries to compile and build a static version of the C library on all platforms. If this is not what you want, use '--flags dynamic' to dynamically link to pre-installed glfw C library on your system. 3. It nows does a much better job at configuring itself on Linux and FreeBSD. 4. There is an outstanding bug preventing GLFW programs to be invoked from GHCi on OS X. One has to compile before running GLFW programs. 5. Documentation has been improved, and there are also API changes affecting window params and hints. See the hackage documentation for details. 6. An example program and detail change log are included if you unpack the source. Many thanks to Marc Sunet and a lot of other people for sending in bug reports and helping out with this upgrade. Marc is now also a maintainer of this package. Please send your bug report to either of us or to the GLFW mailing list <glfw(a)projects.haskell.org>. For new users to GLFW or GLFW-b, there are some style and API differences between these two packages (see https://github.com/bsl/GLFW-b/blob/master/README.md) and in particular, GLFW includes some basic texture support and a "quick-and-dirty" font rendering hack (not found in GLFW C library). Now, more on the outstanding bug with GHCi on OS X. Here is what happens when invoking initialize from GHCi on OS X: Prelude> import Graphics.UI.GLFW Prelude Graphics.UI.GLFW> initialize Loading package OpenGLRaw-1.1.0.1 ... linking ... done. Loading package GLURaw-1.1.0.0 ... linking ... done. Loading package ObjectName-1.0.0.0 ... linking ... done. Loading package StateVar-1.0.0.0 ... linking ... done. Loading package Tensor-1.0.0.1 ... linking ... done. Loading package OpenGL-2.4.0.1 ... linking ... done. Loading package GLFW-0.5.0.0 ... linking ... done. objc[18039]: Object 0x105e00a70 of class __NSCFString autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug 2012-01-21 03:23:58.574 ghc[18039:1303] -[NSAutoreleasePool init]: unrecognized selector sent to instance 0x105e00740 2012-01-21 03:23:58.577 ghc[18039:1303] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSAutoreleasePool init]: unrecognized selector sent to instance 0x105e00740' On the other hand, if GLFW is installed with the dynamic flag to link to a pre-installed system libglfw.dylib, then initialize would work fine but again GLFW applications still fail to run properly as the window fails to receive user input and seems to hang. The enableGUI hack wouldn't help either (and is broken on 10.7). I believe this situation is the same when running GLFW-b applications from GHCi on OS X, since it builds and installs dynamic library on OS X too. Compiled applications are not affected by this bug. Any help is greatly appreciated! Thanks! -- Regards, Paul Liu

2 2

Re: [Haskell-cafe] Fwd: Monads, do and strictness
by David Barbour 22 Jan '12

22 Jan '12

On Sat, Jan 21, 2012 at 2:24 PM, Roman Cheplyaka <roma(a)ro-che.info> wrote: > * David Barbour <dmbarbour(a)gmail.com> [2012-01-21 12:18:09-0800] > > `undefined` is not a value in any domain. It isn't a value at all. It's > > certainly not part of my monad language or algebra. Up to the semantic > > level of comparing observable and legally defined behaviors, we can have > > the identity law. That's sufficient for the letter of the law, even if > not > > ideal from Haskell's operational perspective. > > First, can we please agree on what kind of semantics we are discussing? > > In the beginning you are talking about domains, so it sounds like > denotational semantics. But then you move to behaviours, and that sounds > like operational semantics. > Can you first agree what *layer* of semantics you are discussing? It's useful to understand programs in layers. Your argument seems to depend on confusing the semantics of the monad abstraction with the semantics of the Haskell representation of the abstraction. We could even look at underlying layers, such as the implementation of Haskell - including allocation and GC. The important point is that the ONLY relevant layer for monad laws is the monad algebra itself - not the representation in Haskell, and certainly not the representation of Haskell on a Von Neumann machine. Since strictness does not affect the *values* of any elements in the monad's algebra, it is trivial to meet the monad laws. My argument did switch from denotational to operational as I crossed layers, but that was a conscious decision on my part. > If we are talking about the denotational semantics, then we choose a > domain and need to map every legal Haskell expression to something in > that domain. > We can discuss denotational semantics of many languages. And we can discuss the representations of those languages in Haskell. And we can discuss the denotational semantics of Haskell. Layers upon layers. Denotational semantics certainly doesn't imply the Haskell layer. Regards, Dave

1 0

Fwd: Monads, do and strictness
by David Barbour 22 Jan '12

22 Jan '12

`undefined` is not a value in any domain. It isn't a value at all. It's certainly not part of my monad language or algebra. Up to the semantic level of comparing observable and legally defined behaviors, we can have the identity law. That's sufficient for the letter of the law, even if not ideal from Haskell's operational perspective. Implicit use of laziness or undefined to model and reason about data or algebras is a mistake that mixes semantic layers. Even in Haskell. There's a reason every robust library for processing signals or streams will model them explicitly. Regards, Dave On Sat, Jan 21, 2012 at 11:22 AM, Roman Cheplyaka <roma(a)ro-che.info> wrote: > * David Barbour <dmbarbour(a)gmail.com> [2012-01-21 11:09:43-0800] > > Logically only has meaning when `=` applies to values in the domain. > > `undefined` is not a value in the domain. > > > > We can define monads - which meet monad laws - even in strict languages. > > In strict languages 'undefined' is not a value in the domain indeed, but > it is in non-strict languages, exactly because they are non-strict. > > I think that's what Robert Harper meant by saying that Haskell doesn't > have a type of lists, while ML has one [1]. > > [1]: > http://existentialtype.wordpress.com/2011/04/24/the-real-point-of-laziness/ > > -- > Roman I. Cheplyaka :: http://ro-che.info/ >

2 1

Serializing UTCTimes
by Bas van Dijk 22 Jan '12

22 Jan '12

Hello, What's the recommended way for serializing (with the cereal package) an UTCTime? It's easy to give Serialize instances for UTCTime and Day: instance Serialize UTCTime where get = liftM2 UTCTime get get put (UTCTime day time) = put day >> put time instance Serialize Day where get = liftM Day get put = put . toModifiedJulianDay However I have no idea how to serialize the DiffTime stored in an UTCTime: instance Serialize DiffTime where get = ? put = ? Regards, Bas

3 4

Parsing workflow
by Nils Schweinsberg 22 Jan '12

22 Jan '12

Hi! I'm having a really hard time to write a correct parser for a small language I've developed. I have been trying to write a parser using parsec, but always get a lot of error messages like "unexpected "\n", expected ..., new-line or..." when trying to run the parser. Then I read about the happy parser and really liked the separation of lexing the text into tokens and parsing the actual logic behind those tokens. Since I couldn't get familiar with the lexer "alex" I gave up on the alex-happy-approach again and went back to parsec. But with that lexer->parser idea on my mind, my parser currently looks a lot like a lexer. So I came up with the idea of using a combination of parsec and happy, where I generate a list of tokens for my text via parsec and analyse it with happy. My questions would be: - Is this a valid approach? - What is your workflow on parsing complex data structures? - What about performance? Since my project is going to be an interpreted language parsing performance might be interesting aswell. I've read that happy is in general faster than parsec, but what if I combine both of them as I said above? I guess that parsing a simple list of tokens without any nested parser structures would be pretty fast? - Do you have any other ideas on how to improve my parser? - What are your general thoughts on happy vs. parsec? Thanks for any replies, Nils

10 17

generating parens for pretty-printing code in haskell-src-exts
by Conal Elliott 22 Jan '12

22 Jan '12

I'm using haskell-src-exts together with SYB for a code-rewriting project, and I'm having difficulty with parenthesization. I naïvely expected that parentheses would be absent from the abstract syntax, being removed during parsing and inserted during pretty-printing. It's easy for me to remove them myself, but harder to add them (minimally) after transformation. Rather than re-inventing the wheel, I thought I'd ask for help. Has anyone written automatic minimal parens insertion for haskell-src-exts? -- Conal

4 3

Combining Regions and Iteratees
by oleg＠okmij.org 21 Jan '12

21 Jan '12

Regions is an automatic resource management technique that statically ensures that all allocated resources are freed and a freed resource cannot be used. Regions also promote efficiency by helping to structure the computation so that resources will be freed soon, and en masse. Therefore, regions are particularly suitable for scarce resources such as file handles, database or network connections, etc. A lightweight monadic region library is available on Hackage. Iteratee IO also aims, among other things, to encapsulate resources such as file handles and network connections, ensuring their safe use and prompt disposal. One may wonder how much Iteratees and Regions have in common and if that commonality can be factored out. There seem to be several ways to combine regions and iteratees. This message describes the most straightforward attempt, combining a monadic region library (mostly as it is) with an Iteratee IO library, also mostly as it is. We use monadic regions to manage file handles or file descriptors, ensuring that file handles are always closed even in case of IO and other asynchronous exceptions. An enumerator like enumFile provided similar guarantees for its handles. (Since an enumerator keeps its handles to itself, there is no danger of iteratees' misusing them.) With the monadic region library, the enumerator code becomes simpler: we no longer have to worry about exceptions. The main benefit of monadic region library is to manage files opened by iteratees. The latter being passed around, and so their resources are harder to keep track. We thus demonstrate enumFile and iterFile for incremental file reading and writing, with the same safety guarantees. All opened files are *always* closed, regardless of any (asynchronous) exceptions that may arise during opening, reading, writing or transforming. The code has many examples of throwing errors from various stages of the pipeline and at various times. All files are closed. The commented code is available at http://okmij.org/ftp/Haskell/Iteratee/IterReg.hs which uses the lightweight monadic regions library from http://okmij.org/ftp/Computation/resource-aware-prog/ Since lightweight monadic library needs rank-2 types (now standard), it seemed appropriate to avail ourselves to common GHC extensions. We can clearly see that enumerators and enumeratees unify, both being instances of a general type forall a. Iteratee e mi a -> mo (Iteratee e mi a) which is a Monoid. To compose enumerators or enumeratees, we use the standard mappend. An alias in the code type R e m = Iteratee e m suggests that Iteratees are the view from the right -- the System.IO, getChar-like view. From that point of view, Iteratee IO is hardly different from System.IO (getChar, getLine, peekChar, etc). The dual newtype L e mi mo = L{unL :: forall a. R e mi a -> mo (R e mi a)} is the view from the left. Here are a few examples from the IterReg code. The first simply copies one file to another, block-by-clock. tIF1 = runSIO $ run =<< unL (enumFile "/etc/motd") (iterFile "/tmp/x") According to the trace opened file /etc/motd iterFile: opening /tmp/x Closing {handle: /etc/motd} Closing {handle: /tmp/x} the files are indeed closed, but _not_ in the LIFO order. That is important, so to let an iteratee write data coming from several sources. For example: tIF3 = runSIO $ run =<< unL (enumFile "/etc/motd" `mappend` enumFile "/usr/share/dict/words") (iterFile "/tmp/x") opened file /etc/motd iterFile: opening /tmp/x Closing {handle: /etc/motd} opened file /usr/share/dict/words Closing {handle: /usr/share/dict/words} Closing {handle: /tmp/x} The files will be closed even in case of exceptions: tIF4 = runSIO $ run =<< unL (enumFile "/etc/motd" `mappend` enumFile "/nonexistent") (iterFile "/tmp/x") opened file /etc/motd iterFile: opening /tmp/x Closing {handle: /etc/motd} opened file /nonexistent Closing {handle: /tmp/x} *** Exception: /nonexistent: openFile: does not exist All monadic region monads all support shCatch, so we can write our own exception-handling code. Other examples in IterReg.hs raise errors during data transformation. Monadic regions plus GHC extensions simplify code. For example, here are iterFile and enumFile (the signatures could be omitted; they will be inferred) iterFile :: (SMonad1IO m, m ~ (IORT s' m')) => FilePath -> R ByteString m () iterFile fname = lift (newSHandle fname WriteMode) >>= loop where loop h = getChunk >>= check h check h (Chunk s) = lift (mapM (shPut h) s) >> loop h check h e = return () enumFile :: (SMonadIO m) => FilePath -> L ByteString m m enumFile filepath = L $ \iterv -> do newRgn $ do h <- newSHandle filepath ReadMode unL (enumHandle h) iterv

1 0

How to get Cabal to spit out a .a library suitable for linking into C/Objective-C
by David Pollak 21 Jan '12

21 Jan '12

Howdy, I'm trying to figure out how to get Cabal configured to compile and link my Haskell code such that the code can be part of C and/or Objective-C code such that all the Haskell dependencies are rolled into a .a file and can be linked by a normal C linker (e.g., ld). I've been through http://haskell.org/ghc/docs/6.12.2/html/users_guide/ffi-ghc.html#using-own-… the associated linked, but I'm unable to find out the Cabal incantation to output a library that's linkable into my other code. Any pointers or examples would be greatly appreciated. Thanks, David -- Visi.Pro, Cloud Computing for the Rest of Us http://visi.pro Lift, the simply functional web framework http://liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im

3 3

Re: [Haskell-cafe] How to get Cabal to spit out a .a library suitable for linking into C/Objective-C
by Donn Cave 21 Jan '12

21 Jan '12

Sorry about the belated response, but this shouldn't be a problem since it isn't going to be very helpful anyway! I've managed to follow the process described on this page: http://www.haskell.org/haskellwiki/Using_Haskell_in_an_Xcode_Cocoa_project to link Haskell code to a non-Haskell main program, via Xcode. You've probably already seen this, it's mostly about a few iterations of trial and error linking, to get the list of GHC library dependencies, which is what you need whether you're using Xcode or not. If you really need a single library with your code and all those dependencies, that may be technically feasible, though awfully tedious. The only clear problem I encountered while experimenting with it is that GHC run time options need ghc -rtsopts, so they're unavailable if your program isn't built by ghc. I believe I worked around that with a special rtsmain.o, could probably recover the details if that's of interest. Donn

2 1

In-memory Handle for testing
by Simon Hengel 21 Jan '12

21 Jan '12

For testing I want to stub handles, performing all reads and writes in memory (and in process, so no mmap). From looking at the documentation of mkFileHandle[1], I think this should be possible. But it requires some work. Is there already something out there? Cheers, Simon [1] http://hackage.haskell.org/packages/archive/base/4.4.1.0/doc/html/GHC-IO-Ha…

2 2