July 2010 - jhc - Haskell.org

Haskell + SDL on the Wii
by Korcan Hussein 30 Jul '10

30 Jul '10

I just managed to achieve this over the last few days: On the PC (vbox): http://imgur.com/J9Nkd.png on the Wii: http://i.imgur.com/7DWdf.jpg So i've managed to get the core SDL bindings building on jhc, I've barely tested it and I did notice an issue with the low level bmp function not working and I'm not sure if this is an issue with jhc or something else but I haven't looked into this much yet.

2 2

Benchmarks including JHC
by Felipe Lessa 28 Jul '10

28 Jul '10

In case someone on this list missed this blog post: http://lhc-compiler.blogspot.com/2010/07/great-haskell-compiler-shootout.ht… It is nice to see JHC being superior than GHC in some tests. =) Cheers, -- Felipe.

2 1

bracket_ issue and fix
by Korcan Hussein 28 Jul '10

28 Jul '10

Hello, I've been tyring to modify the Haskell SDL bindings from hackage to get it to work on jhc (people should not use Haskell extensions in binding libraries!!!) and I had a problem with a piece of code that was using bracket_ but I did find a solution, the error message was: [1 of 1] Graphics.UI.SDL.General(.......................................jhc: user error ( What: failure Why: boxyMatch failure: (Jhc.Prim.IO Jhc.Basics.()) (s629 -> Jhc.Prim.IO s630) Where: on line 148 in General.hs in the application Control.Exception.bracket_ (Graphics.UI.SDL.General.init Graphics.UI.SDL.General.20_flags) Graphics.UI.SDL.General.quit Graphics.UI.SDL.General.21_action in Graphics.UI.SDL.General.withInit {- on line 148 -} in the function binding Graphics.UI.SDL.General.withInit Graphics.UI.SDL.General.20_flags Graphics.UI.SDL.General.21_action = Control.Exception.bracket_ (Graphics.UI.SDL.General.init Graphics.UI.SDL.General.20_flags) Graphics.UI.SDL.General.quit Graphics.UI.SDL.General.21_action {- on line 148 -}) My suspicion was that the type signature for bracket_ wasn't exactly the same as defined in Haskell98 so I copied from haddoc docs the defintion and made bracket2_ function: bracket2_ :: IO a -> IO b -> IO c -> IO c bracket2_ before after thing = bracket before (const after) (const thing) Then it all works fine, when I was googling the problem I think someone else had it too so hopefully if another person gets it they can find this :)

2 1

Re: [Haskell] ANNOUNCE: jhc 0.7.4
by John Meacham 27 Jul '10

27 Jul '10

On Tue, Jul 27, 2010 at 12:42:27AM +0100, Thomas Schilling wrote: > > * a garbage colletor which can be enabled with '-fjgc' is available. > > after some more testing, I will make it the default in the 0.7.5 release. > > * A new memory allocator based on Jeff Bonwick's slab memory allocator for > > kernels. This means that in many cases, memory can be pulled off a slab > > and immediately used with no initialization, in addition, it allowed a > > rearrangement of the GC meta-data to optimizally use the cache. > > That sounds like you're essentially using BIBOP (big bag of pages, > http://www.memorymanagement.org/glossary/b.html#bibop) Did you > compare the overheads with the header-based scheme? Do you still need > a tag/header word or do you get the tag by looking up the per page > info? Do you use this scheme for all objects or only for small > objects? I could imagine a hybrid scheme where where you use bibop > for, say, single-constructor objects, although I wonder how you would > deal with thunks and their update. Yeah, it is somewhat similar to that, except I don't need to look up in a table what the type is, I just take the address modulo the block size and there is a shared info section at the front of the block. all the GC bookeeping bits are kept here too and can usually fit on a single cache line, that way you can mark a object used without actually having to dereference a pointer to it, allowing the cache line for the object itself to fill hopefully by the time I get around to it on the grey list. objects that contain no pointers are never touched by the GC, an advantage of keeping the bookeeping bits away from the objects. There is no per object overhead/tag word imposed by the storage manager, other than the one or two bits used by the GC. (one bit right now, but I will need to expand it to add some GC features that are missing (destructors, incremential collection)). I currently use this scheme for all objects, however, beyond a certain size I think a header approach might be better, so I will look into that. In particluar, my arrary sizes are limited to what can fit in a block right now when you have the GC on, which is a limitation I need to fix. I did experiment with a header scheme, however, it was never really optimized that well so I don't think I could make performance conclusions from it. I may add a switch to control this though. Honestly, a slab inspired allocator has been my plan since day one of writing jhc, I had a fair amount of experience with them from my previous OS work and felt they would be a good fit for jhcs model. > > * packed representation of algebraic types, 'Maybe Foo' is actually > > represented in memory as a NULL pointer or just a 'Foo' with no tag bits. > > Combined with the slab allocator, this can double the number of some common > > values that can be put in a cache line. > > Interesting. How do you distinguish 'Just e' from 'Just _|_'? Do > you need the whole program assumption to disprove that the latter case > can happen? each word has two tag bits, one says whether the value is in WHNF, the other says whether it should be followed by the GC. So to eval something, I check the tag bit, if it says WHNF I am done, otherwise the object must be one of a thunk or an indirection, if it is a thunk, it has a code pointer as its first entry, otherwise it is a redirection that _must_ be a WHNF pointer. Unlike ghc, there are strong invarients about what sort of objects can appear where, WHNF and non WHNF values actually have different types in Grin and C. For instance, an indirection to an indirection is impossible, as is redirecting a whnf value, this also means a lot of things that are easy for ghc, a collector that moves things around incrementally, implementing concurrent locks by overwriting an evaluation pointer, etc are difficult in jhc. So there are tradeoffs. (a selectable alternate RTS may mitigate this though) Now, the interesting thing is that if the WHNF bit is set, there are no rts or gc imposed restrictions on the word whatsoever, it need not even be a pointer, and often isn't. (unless the gc flag is set, in which case it has to be a heap pointer, but the format of what it is pointing to is completly undefined). For instance, data Foo !Word8 !Word8 will theoretically be packed directly into the word itself as the two most signifigant bytes. For each type I can statically generate an "optimal" layout based on its structure. For instance, maybe benefits from two of these optimizations, first of all, nullary constructors (Nothing) need never appear in the heap, so they are given values that pack directly into a word, this happens for all nullay constructors in general. Then, since there is only one constructor left (Just) we can discard the tag field, because if something of type Maybe, is in WHNF, and is not Nothing then in must be a Just. so the Just is a single heap allocated word (which are packed end to end in a page with no overhead) I am refining the optimization algorithm, on 64 bit machines I have another few bits to play with for instance that I can take advantage of. A particularly nice case is that characters can be fully integreated into the word, so the entire space usage of "Hello" is 10 words as lists benefit from the same packing benefits as Maybe. compare this to 30 or so words used in a traditional "everything is on the heap and tagged" model. The manual has a section describing the RTS, it doesn't describe the GC though, but talks about how I pack things in the pointers. http://repetae.net/computer/jhc/manual.html#the-run-time-system John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

1 0

darcs patch: add Jhc.Num.m4 and Jhc.Inst.Num that were accidentaly ...
by John Meacham 26 Jul '10

26 Jul '10

Mon Jul 26 13:39:07 PDT 2010 John Meacham <john(a)repetae.net> * add Jhc.Num.m4 and Jhc.Inst.Num that were accidentaly left out.

1 0

Is a full POSIX env required for cross-compiling?
by Korcan Hussein 25 Jul '10

25 Jul '10

Hello, I've managed to get a hello world Haskell program working on the Wii (homebrew), cross-compiling JHC compiling the C code using devkitPPC (http://wiibrew.org/wiki/DevkitPPC) Unfortunately I had to hack the generated C code to get this working because devkitPPC doesn't seems to fully support POSIX standards, there where two headers missing from devkitPPC that the C code referenced which was sys/select.h and sys/utsname.h, I was also having problems with __WORDSIZE not being defined even though in my targets.ini I've explicated stated the bit-size, byte-ordering, etc. so I added this define to my targets.ini definition. The headers that was missing the actual functions that depended on those headers didn't seem completely essential code so I commented out the includes and problematic code, I also changed the value of the define JHC_isPosix to 0. Of-course this isn't ideal, the proper solution would be for me (or devkitpro) to implement those missing headers but does jhc require a full implementation of posix standard? is it possible to use jhc cross compiling with non-posix platforms? I also added some other code to the generated C code to setup the Wii, prepare the system for console output, etc but this has nothing to do with jhc and of-course this stuff would need a FFI binding, I just did this for testing purposes. _________________________________________________________________ http://clk.atdmt.com/UKM/go/197222280/direct/01/ We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now

2 2

darcs patch: add QuickCheck to external libs (and 3 more)
by John Meacham 23 Jul '10

23 Jul '10

Thu Jul 22 05:21:48 PDT 2010 John Meacham <john(a)repetae.net> * add QuickCheck to external libs Thu Jul 22 05:33:50 PDT 2010 John Meacham <john(a)repetae.net> * add parsec to external libraries Thu Jul 22 06:00:36 PDT 2010 John Meacham <john(a)repetae.net> * add misc utilities Thu Jul 22 06:00:53 PDT 2010 John Meacham <john(a)repetae.net> * rename existential data declarations properly

1 0

darcs patch: get rid of special handling of Num, Real... (and 2 more)
by John Meacham 23 Jul '10

23 Jul '10

Thu Jul 22 04:07:59 PDT 2010 John Meacham <john(a)repetae.net> * get rid of special handling of Num, Real, and Integral classes Thu Jul 22 04:27:56 PDT 2010 John Meacham <john(a)repetae.net> * clean out a lot of cruft thanks to getting rid of built in classes and types Thu Jul 22 04:56:34 PDT 2010 John Meacham <john(a)repetae.net> * get rid of some unusued hardcoded names

1 0

darcs patch: use YAML to specify properties of regres... (and 1 more)
by John Meacham 23 Jul '10

23 Jul '10

Thu Jul 22 00:38:02 PDT 2010 John Meacham <john(a)repetae.net> * use YAML to specify properties of regression tests Thu Jul 22 01:50:16 PDT 2010 John Meacham <john(a)repetae.net> * add target names to dependency files generated by jhc and include true lib dependencies in makefile

1 0

ANNOUNCE: jhc 0.7.5
by John Meacham 22 Jul '10

22 Jul '10

Announcing jhc 0.7.5! This mainly fixes some bugs that came up in peoples testing of 0.7.4 and includes a lot more libraries in the standard install and better standards support. http://repetae.net/computer/jhc/ Any testing people can do with the new garbage collector -fjgc would be greatly appreciated! As far as I know, this release has no regressions when using the new GC, so it will be enabled by default if I get no reports of problems with this release. Major changes * The Garbage Collector now fully supports the Windows, OSX 10.5 (leapord), and OSX 10.6 (snow leapord) targets. * Lots of libraries, now that I have a somewhat general script to cut through the cabal the following are now included with the default install - haskell98 - flat-foreign (CForegin, etc..) - jhc - base (not the same as ghcs base, close enough for most tasks though) - applicative - containers - Diff - html - HUnit - pretty - safe - smallcheck - utility-ht - xhtml * updates to base libraries to bring them closer to haskell 2010 and ghc base. - updated Functor and Applicative - added Debug.Trace - added a few functions in h2010 not in h98 * support for adding valgrind annotations to generated source for debugging the RTS. * support for having the generated code annotate every heap location with useful profiling/debugging info. useful for debugging the RTS. * support for passing --win to the regression test driver to run all the tests cross-compiled for windows. * The Big HsName cleanup, finally got rid of old alegebraic HsName in favor of abstract Name and its faster operations, faster typechecking/frontend and code simplification opprotunities result. * improve the selftest. * bug fixes John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

2 2