August 2009 - jhc - Haskell.org

a quick word of praise
by Mark Wotton 29 Aug '09

29 Aug '09

debugging stack behaviour is WAY easier in jhc than in ghc... mark

1 0

Re: [Haskell] Re: [Haskell-cafe] ANNOUNCE: jhc 0.7.1
by sylvain 27 Aug '09

27 Aug '09

> There should be no excuses for not giving jhc a whirl. Agreed. In a lot of ways, jhc seems like a Haskell compiler done right. It generates very fast and lean binaries - using C as an intermediary language - which makes it a natural cross-compiler and indicates it should not be too difficult to write a back-end for the CIL and the jvm. On the other hand, it is still far away from GHC features-wise. So there is definitively room for people looking to contribute to a compiler with a high potential. Wouldn't that be fun? Sylvain.

1 0

darcs patch: bump version number (and 4 more)
by John Meacham 27 Aug '09

27 Aug '09

Mon Aug 24 18:03:11 PDT 2009 John Meacham <john(a)repetae.net> * bump version number Mon Aug 24 18:27:23 PDT 2009 John Meacham <john(a)repetae.net> * clean up SourceCode data type Mon Aug 24 20:03:31 PDT 2009 John Meacham <john(a)repetae.net> * add --annotate-source option to spit out annotated, preprocessed source code for use by other tools Mon Aug 24 22:34:25 PDT 2009 John Meacham <john(a)repetae.net> * fix typo in manual, gcc should be cc Tue Aug 25 19:27:45 PDT 2009 John Meacham <john(a)repetae.net> * show output of --list-libraries in YAML format.

1 0

dynamic linking
by Mark Wotton 27 Aug '09

27 Aug '09

Hi all, trying to get a handle on this conceptually - ideally, I'd like to be able to load an arbitrary number of JHC-compiled dylibs at the same time. Is this likely to work? Do hs_init and hs_exit apply globally to some static variables in the C code JHC produces? Cheers Mark

2 1

where's the appropriate place to put regression tests for compile bugs?
by Mark Wotton 26 Aug '09

26 Aug '09

I've been having a bit of a poke about the regression tests, and all the tests seem to be for single Main files. One of my test cases that fails is for compiling a separate module - the bug doesn't manifest if you change it to Main. John, have you got a plan for expanding the test suite to cover this sort of thing? On another note, it'd be nice to have some basic integration/ functionality tests - ensure that a given jhc tree can build something using containers, for instance, or build a sensible dynamic library (my own personal bugbear). Have you thought about using one of the test frameworks for Haskell? Or even one of the more generic Perl test frameworks, given that regress.prl is in Perl already? Cheers mark (JAJH)

2 2

ANNOUNCE: jhc 0.7.1
by John Meacham 26 Aug '09

26 Aug '09

Here is another pre-release fixing some issues that came up after the 0.7.0. the fixes are: * documentation clean ups * add writeFile and appendFile to the libraries * Fix C prototypes when foreign exporting/importing pointers * add containers and applicative to dist tarball * add System.Environment * fill out System.Directory and some more System.IO routines * have the renamer check module exports for correctness http://repetae.net/computer/jhc/ John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

3 4

Re: [Haskell] ANNOUNCE: jhc 0.7.1
by John Meacham 26 Aug '09

26 Aug '09

On Tue, Aug 25, 2009 at 02:15:14PM +0100, Duncan Coutts wrote: > 1. Would it be possible to have a machine-readable form of: > jhc --list-libraries > > It's possible to parse the output of course but the worry is always that > the format will change again. Good Idea, I'll modify the output to be a proper YAML file with a few guarenteed fields, that will leave room for expansion later and backwards compatability. > 2. In older jhc versions it was possible to specify .hl libraries by > name and version, eg jhc -p filepath-1.0.1.1. In the latest release it > is only possible by name. Is this intentional? I know jhc uses hashes to > uniquely identify installed packages, perhaps it should be possible to > specify packages by hash for the case that one has several instances of > the same package (possibly different versions, or built against > different versions of various dependencies). Ah, this is an unintentional regression. I intended to keep the behavior of being able to specify a library name/version or file name. Being able to specify a hash is also a good idea. > like when there are several packages of the same version but with a > different hash? Maybe a machine readable --list-libraries should list > the hash too. > > > 4. Is there a way to get back the library/package description that jhc > bakes into the .hl files? There's a --show-ho. Perhaps we want a > --show-hl that dumps the library description? I guess that should also > tell us the package hash. --show-ho will also work on hl files, which probably isn't mentioned anywhere in the manual. I think I will add a verbose mode to --list-libraries that will also spit out much of this meta-info (in the aforementioned YAML format) > 5. The ./configure doesn't check for the Haskell readline package. Yeah, I am currently only checking for the purpose of ghc 6.8/6.10 compatibility, but adding checks for all dependencies is a good idea. As an aside, here are the principles that guided the design of the new library system and ho cache. The main motivations were ameliorating two notable shortcomings of jhc, its speed and compatibility with other compilers: * Ho files will only affect speed of compilation, never results. No matter what. This allows the shared ho cache and decoupling the unit of caching from module granularity. * Only the interface of libraries explicitly mentioned on the command line shall affect code compiled by jhc. For instance, a libraries implementation can use an alternate prelude without hurting its compatibility with haskell 98 code. * From the users perspective, a library defines an interface, which is not necessarily coupled to the implementation. I have thought long and hard on the problem of being able to maintain some level of compatibility with ghc and hackage without sacrificing jhc's ability to innovate, or tying its development to the ghc libraries. Making libraries logical 'interfaces' rather than 'implementations' decouples compatibility issues from the compiler itself, anyone can write a library that emulates a particular interface. For instance, a compat-ghc-base3 library might have things like 'Reexport: Compat.Haskell98.Prelude as Prelude, Compat.Ghc.Base3.Monad as Control.Monad, ... '. Or more interestingly, you might create your own library that does a 'Reexport: MyApplicativePrelude as Prelude' to get your own prelude. (this is not fully realized yet in 0.7.1, but will be in a point release soon. The mechanism and framework is there though.) * Stateless. There is no such thing as hidden libraries, libraries mentioned on the command line are available, libraries not mentioned are not. Since libraries can re-export modules this won't cause a command line explosion. For instance, a -phaskell-platform could pull in and make available all the libraries in the haskell platform. * Adding libraries, even incompatible ones, won't break working builds unless said libraries are explicitly mentioned by the build in a non-precise way. This is necessary so a theoretical 'jhc-pkg' tool need only worry about adding required libraries, not cleaning up or worrying about finding consistent sets of libraries. A simple recursive download on dependencies suffices as a rudimentary cabal-install style tool. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

1 0

targets.ini ignored
by Paulo Tanimoto 25 Aug '09

25 Aug '09

Hello, I just installed jhc 0.7.1 and wanted to try cross-compilation (it works!). The manual tells me about some places I can put a targets.ini file. Unfortunately, it seems that no matter where I put it, it's ignored. This is what I have: ---- 8< ---- [win32] gcc=i586-mingw32msvc-gcc cflags+=-mwindows -mno-cygwin executable_extension=.exe merge=i686 ---- 8< ---- Basically, I just copied the example from the manual, but changed gcc to "i586-mingw32msvc-gcc" because that's what comes with Ubuntu Jaunty 64bit. See the error message below (sorry it's long). Is there something I can do to investigate what's failing? Creating a symlink as "i386-mingw32-gcc" works, by the way. Thanks, Paulo $ cat > hello.hs module Main where main = putStrLn "hello world" $ cat ~/.jhc/targets.ini # or ~/etc/jhc/targets.ini [win32] gcc=i586-mingw32msvc-gcc cflags+=-mwindows -mno-cygwin executable_extension=.exe merge=i686 {- Also tried putting it in /usr/local/etc/jhc-0.7/, even replacing the existing targets.ini -} $ jhc --cross -mwin32 -v hello.hs reading /usr/local/etc/jhc-0.7/targets.ini reading /usr/local/etc/jhc-0.7/targets-local.ini reading /home/[username]/etc/jhc/targets.ini reading /usr/local/etc/jhc-0.7/targets.ini reading /usr/local/etc/jhc-0.7/targets-local.ini reading /home/[username]/etc/jhc/targets.ini jhc --cross -mwin32 -v hello.hs jhc 0.7.1 (0.7.0-13) Finding Dependencies... Using Ho Cache: '/home/[username]/.jhc/cache' -- Base: base Exported: True Hash: 8c94a7b43fd3d66558ab3d1f2182abae Name: base-1.0 -- Base: haskell98 Exported: True Hash: ee7ca5091f963b5420ca56a56a176264 Name: haskell98-1.0 -- Base: jhc Exported: False Hash: fb645af1aa0971f3be17c34f7c0a032f Name: jhc-1.0 Main [hello.hs] <~/.jhc/cache/a61a65a6addfa4a2aa3c57618613f47a.ho> Fresh: <~/.jhc/cache/a61a65a6addfa4a2aa3c57618613f47a.ho> Typechecking... Compiling... Collected Compilation... PassStats -- typeAnalyzeMethods Type analyzed methods Jhc.Basics.concatMap \({})({}) Jhc.Monad.mapM_ \({Jhc.Prim.IO})({Jhc.Prim.Char})({Jhc.Basics.()}) Jhc.Basics.++ \({}) Jhc.Monad.>> \({Jhc.Prim.IO})({Jhc.Basics.()})({Jhc.Basics.()}) Jhc.Monad.>>= \({})({})({}) Jhc.Monad.return \({Jhc.Prim.IO})({Jhc.Basics.()}) Jhc.IO.runMain \({Jhc.Basics.()}) Instance@.iJhc.Monad.>>.Jhc.Prim.IO \({Jhc.Basics.()})({Jhc.Basics.()}) Instance@.iJhc.Monad.>>.default \({})({})({}) Instance@.iJhc.Monad.>>=.Jhc.Prim.IO \({})({}) Instance@.iJhc.Monad.>>=.Jhc.Prim.[] \({})({}) Instance@.iJhc.Monad.return.Jhc.Prim.IO \({Jhc.Basics.()}) Instance@.iJhc.Monad.return.Jhc.Prim.[] \({}) Instance@.iJhc.Monad.>>=.Jhc.Maybe.Maybe \({})({}) Instance@.iJhc.Monad.return.Jhc.Maybe.Maybe \({}) -- typeAnalyze-Main-AfterMethod -- Simplify-Main-One -- Simplify-Main-One -- Simplify-Main-One -- Simplify-Main-One -- Simplify-Main-One -- Simplify-Main-One -- Simplify-Main-One Total: Main-One {- Simplifications -} Writing "hs.out.exe_code.c" Running: i386-mingw32-gcc '-std=gnu99' -D_GNU_SOURCE '-falign-functions=4' -ffast-math -Wshadow -Wextra -Wall -Wno-unused-parameter -m32 -m32 -m32 -m32 -m32 -m32 -m32 -m32 -m32 -m32 -m32 -m32 -m32 -m32 -m32 -m32 -mwindows -mno-cygwin -m32 -m32 -m32 -m32 -m32 -m32 -m32 -m32 -mwindows -mno-cygwin -m32 -m32 -m32 -m32 -m32 -m32 -m32 -m32 -o hs.out.exe hs.out.exe_code.c -DNDEBUG -O3 -fomit-frame-pointer -fomit-frame-pointer -fomit-frame-pointer -fomit-frame-pointer -fomit-frame-pointer -fomit-frame-pointer -fomit-frame-pointer -fomit-frame-pointer /bin/sh: i386-mingw32-gcc: not found user error (C code did not compile.)

2 2

ANNOUNCE: jhc 0.7.1
by John Meacham 25 Aug '09

25 Aug '09

Hi, I am happy to announce the jhc optimizing haskell compiler version 0.7.1. Information on installing jhc is here: http://repetae.net/computer/jhc/building.shtml And the Main page is here: http://repetae.net/computer/jhc There have been a lot of changes since the last public release, Some notable ones are: * The use of a general compiler cache by default rather than object files. This means work done by jhc is shared between projects, jhc uses cryptographic hashes internally to never compile the same piece of code more than once. This has numerous benefits, a notable one being speed. * Reworked library support. Jhc libraries are now much more general, when linking only the bits needed are loaded from the hl file, libraries are allowed to re-export modules from other libraries, making versioning or providing multiple interfaces to the same functionality a lot simpler. Library conflicts are 'lazy', like ambiguity errors now. * Updated Manual, clearer build instructions * Support for writing pure C libraries in Haskell. * numerous library updates, filled out many IO routines that were stubs before * Smart progress meters when compiler for a better user experience * performs all typechecking before compilation, for a faster edit-compile loop when writing code with jhc. * various bug fixes * Cross Compilation improvements, for instance you can compile for windows transparently on a linux box. Or for an embedded target that is independent of the host. * Better Mac OSX Support, as both a host and target. If you are wondering about the large version number bump since the last release, It is because several versions were released only internally to the jhc list for testing. If you are interested in jhc, join the list at: http://www.haskell.org/mailman/listinfo/jhc John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/

1 0

odd bug
by Mark Wotton 24 Aug '09

24 Aug '09

22:40 ~/projects/Hubris/lib % cat Crasher.hs module RubyMap where qtrue = 2 22:40 ~/projects/Hubris/lib % jhci Crasher.hs jhci Crasher.hs jhc 0.7.1 (-n 0.7.1-0 ) Finding Dependencies... Using Ho Cache: '/Users/mwotton/.jhc/cache' RubyMap [Crasher.hs] Typechecking... [1 of 1] RubyMap (.............................................) Compiling... [1 of 1] RubyMap <..................................................> jhci: src/FrontEnd/Representation.hs:98:9-24: No instance nor default method for class operation Data.Binary.put this is a much cut-down version of a real problem. I've not used Binary anywhere, so I'm a bit confused - any tips? this is with the latest darcs sources. mark

2 1