- jhc - Haskell.org

ANNOUNCE: jhc-0.7.3
by John Meacham 28 Feb '10

28 Feb '10

It's been a long time coming, but jhc-0.7.3 is here. If you have been following the darcs repository, there are not a whole lot of new changes, but there have been substantial fixes since 0.7.2. http://repetae.net/computer/jhc/ One of the most important ones is I have begun the process of standardizing on YAML for all external interfaces that may be useful to automation, this should make interfacing jhc with external tools written in any language much easier, and it will prevent me from spending time trying to invent proprietary formats every time I think of something new to spit out. right now it is used in 3 places: - dumping dependency info with --deps - library dumping with --list-libraries -v - annotating source code, for inputting to documentation generators via --annotate-source The main place it isn't used yet that I desire too is to replace the 'cabal' library description format with a true YAML file. jhc cabal files were never quite compatible with cabal ones anyway and naming them the same thing has been a source of connfusion. some of the other changes have been: features: - a lot more regression tests, many user submitted bugs are now regressions - support for using 'mock' to build rpms - System.Exit, System.Cmd added to base - better compatibility with ghc in some library functions - ui improvements in showing progress and errors - extended --list-libraries info - --deps dependency dumping - more francise compatible thanks to patches from droundy - more instances for bigger tuples added - uses editline if readline not available - select libraries by hash as well as version - add System.IO.Pipe - detect version of gcc needed for cross compiling to windows performance: - storage analysis - a very basic region inference enabled by default - deadcode analysis can see through partial applications now - profiled and sped up some library routines that were producing inellegant core. - figure out when top level grin functions call themselves recursively and turn them into explicit loops. bug fixes: - do expression in infix - fix strict newtype bug - U2U bug fixed - desugaring inside of list comprehensions fix - c generator doesn't mess up on unknown values - the compiler version is stored in the cache files, so multiple versions of jhc don't clobber each others cache entries - Ord instance for lists fixed - recursive type synonyms detected properly - make sure errno.h is included when errno is referenced - don't give a parse error when seeing ghc extensions to INLINE - qualified method names fix John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

1 0

dependency information
by John Meacham 27 Feb '10

27 Feb '10

Sorry for the long hiatus in development. I am glad to say that I have begun work again this month and accepted a position at Google. They are very keen on letting their developers work on open source projects in their own time, so I should have no problem spending more time on jhc. I am getting ready to release 0.7.4 which among other things has a new feature '--deps file.yaml' which will spit out the dependency information for everything it reads as a yaml file. This, along with the extended --list-libraries output should make it easier for other tools to interact with jhc. I have attached a sample dependency file generated by a build of the containers library for comment. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

2 1

Re: [jhc] Fast array processing
by Henning Thielemann 26 Feb '10

26 Feb '10

On Wed, 24 Feb 2010, Josef Svenningsson wrote: > Hi, > > I'd like some advice on how to get decent array processing speeds. jhc > doesn't seem to be able to remove all the inefficiencies of the Array > library interface according to my experiments. And as far as I can see > jhc doesn't support any kind of unboxed arrays. Are there any other > alternatives that I've missed? I got StorableVector compiled on JHC but even simple examples did not produce runnable executables.

2 3

Re: [jhc] Fast array processing
by Josef Svenningsson 24 Feb '10

24 Feb '10

On Wed, Feb 24, 2010 at 11:57 AM, Henning Thielemann <lemming(a)henning-thielemann.de> wrote: > > On Wed, 24 Feb 2010, Josef Svenningsson wrote: > >> Hi, >> >> I'd like some advice on how to get decent array processing speeds. jhc >> doesn't seem to be able to remove all the inefficiencies of the Array >> library interface according to my experiments. And as far as I can see >> jhc doesn't support any kind of unboxed arrays. Are there any other >> alternatives that I've missed? > > I got StorableVector compiled on JHC but even simple examples did not > produce runnable executables. > Ok. Thanks for the info. Josef

1 0

Fast array processing
by Josef Svenningsson 24 Feb '10

24 Feb '10

Hi, I'd like some advice on how to get decent array processing speeds. jhc doesn't seem to be able to remove all the inefficiencies of the Array library interface according to my experiments. And as far as I can see jhc doesn't support any kind of unboxed arrays. Are there any other alternatives that I've missed? Thanks, Josef

1 0

jhc-0.7.1 and parsec-2.1.0.1
by Christian Maeder 19 Nov '09

19 Nov '09

Hi, I've tried to compile (part of) parsec-2.1.0.1 with jhc-0.7.1 and Parsec.Combinator had several problems with do-expression as infix arguments, which should be simple to fix for you. I.e. do{ p; return ()} <|> return () needed explicit parenthesis: (do{ p; return ()}) <|> return () (also if layout is used instead of curly braces) Cheers Christian name: parsec version: 2.1.0.1 exposed-modules: Text.ParserCombinators.Parsec.Error, Text.ParserCombinators.Parsec.Char, Text.ParserCombinators.Parsec.Combinator, Text.ParserCombinators.Parsec.Pos, Text.ParserCombinators.Parsec.Prim, Text.ParserCombinators.Parsec

3 7

Building cabal packages
by Chris Eidhof 17 Nov '09

17 Nov '09

Hey everyone, What's the way to build a cabalized package with jhc? I tried the following: > hc --build-hl Yampa.cabal yampa-0.9.2.3.hl > jhc --build-hl Yampa.cabal yampa-0.9.2.3.hl > jhc 0.7.3 (-n 0.7.2-40 > ) > Creating library from description file: "Yampa.cabal" > Reading: "Yampa.cabal" > Finding Dependencies... > Using Ho Cache: '/Users/chris/.jhc/cache' > Typechecking... > Compiling... > Writing Library: Yampa-0.9.2.3.hl But I don't think jhc actually compiled something, or it was *really* fast. I tried copying that .hl file to my JHC_LIBRARY_PATH, but when I invoke JHC with "-pyampa" it still won't find it. I'm a bit lost... -chris

3 6

containers package
by Chris Eidhof 16 Nov '09

16 Nov '09

It seems like JHC won't compile the darcs version of the containers library. After removing some pragmas, it failed to compile Data.Sequence at some quite normal-looking datatype. It fails with a parse error, I'm not sure why, but I'll investigate it later. For now I'm using the containers 0.2.0.1 version, which compiles just fine. -chris

2 1

Compiling JHC on OS X
by Chris Eidhof 16 Nov '09

16 Nov '09

Hey all, I'm trying to compile JHC on OS X. However, when I do a 'make jhc', I got the following error: > make jhc > perl ./utils/opt_sets.prl -n src/FlagDump.flags src/FlagDump.flags > > src/FlagDump.hs > Use of uninitialized value in hash element at ./utils/opt_sets.prl > line 44, <> line 84. > perl ./utils/opt_sets.prl -n src/FlagOpts.flags src/FlagOpts.flags > > src/FlagOpts.hs > Use of uninitialized value in hash element at ./utils/opt_sets.prl > line 44, <> line 45. > Use of uninitialized value in hash element at ./utils/opt_sets.prl > line 44, <> line 45. > happy -a -g -c src/FrontEnd/HsParser.y -o src/FrontEnd/HsParser.hs > unused rules: 2 > shift/reduce conflicts: 73 > reduce/reduce conflicts: 23 > sed -e 's/^{-# OPTIONS[A-Z_]*/{-# OPTIONS_GHC -w /' -i src/FrontEnd/ > HsParser.hs > sed: -i may not be used with stdin > make: *** [src/FrontEnd/HsParser.hs] Error 1 > make: *** Deleting file `src/FrontEnd/HsParser.hs' I fixed that by adding the extension to sed -i (I've attached a patch for that, my sendmail is broken). For future reference: I had some problems installing readline (using fink's readline). There's a thread [1] on haskell-café that solves that. After changing the line and installing readline, it started compiling. After a while, the compiler stopped with: > src/E/Subst.hs:143:22: > No instance for (T.Traversable (Lit TVr)) This was because I had an old version of Drift installed. I didn't see an error, it should probably fail as early as possible and notify me that I had an old version that didn't support deriving Traversable. Finally, JHC was compiled! When compiling the libraries, however, it failed again: > lib/containers/Data/Sequence.hs:312:16: Parse error > make[1]: *** [containers-0.2.0.hl] Error 1 Is somebody already working on that? If not, I'd be happy to dive in and fix it. (BTW, the culprit is the following line:) > {-# SPECIALIZE INLINE deep :: Digit (Elem a) -> FingerTree (Node > (Elem a)) -> Digit (Elem a) -> FingerTree (Elem a) #-} Thanks, -chris [1]: http://www.haskell.org/pipermail/libraries/2009-May/011597.html

1 0

Monad.ST
by Henning Thielemann 16 Nov '09

16 Nov '09

Before looking into the actual source code of the ST monad, I thought that ST must be something like newtype ST s a = ST (IO a) where the strict ST monad is based on normal IO bind function and lazy ST monad also uses unsafeInterleaveIO. Then runST would be just an unsafePerformIO. However when looking into http://darcs.haskell.org/packages/st it is in Control.Monad.ST.Lazy newtype ST s a = ST (State s -> (a, State s)) data State s = S# (State# s) and in Hugs.ST: newtype ST s a = ST (forall r. (a -> r) -> r) Both GHC and Hugs seem to use primitives, that are not available in JHC. Would my IO definition above be correct, at all? It seems that much of the code in the 'st' package could not be re-used in JHC.

3 9