almost to 0.8.0 - feedback welcome
Hi all, I am happy to announce that we are almost upon the 0.8.0 release of jhc, which has quite a few changes from the past so I was hoping I could get some people to help test the newest darcs tree and give feedback. changes include. - A brand new library descriptor file format. Now it is a true YAML file. no more of the confusing quasi-cabal files that were not well defined. - the library description files now can affect pretty much any aspect of compilation, so it is much easier to make a self-contained build or for tools like configure/cabal to interface to jhc. They just need to spit out an appropirate yaml file rather than care about passing the right options to jhc in addition to creating a description file. - jhc transparently handles '.hsc' files (assuming you have hsc2hs installed). It even does the right thing when cross compiliing! using the target architectures types rather than the hosts. - the primtive libraries have been re-done, now there is a truely absolutely minimal jhc-prim library that is everything that must exist for jhc to work. everything else and i mean everything is implemented in normal haskell code. Want to create a varient of haskell that has 16 bit ints, ASCII 8 bit Chars and pervasively uses null terminated C style strings? just create a base-tiny library and link it against jhc-prim. - the standalone deriving extension has been implemented, this greatly improves the ability to re-arrange the libraries logically. - support the LANGUAGE pragma and the equivalant field in the library description files with ghc-compatibility. (ghc extensions are mapped to the closest matching jhc flags.) Things I am still working on but want for the release: - C code and header files will be wrapped up into the .hl file as part of a library build. so there is no need to coordinate native code and jhc libraries, installing a library will always be as simple as dropping an hl file in your library directory. (notably, this will allow transparent distribution of 'bytestring' which has C components) - full haskell 2010 compliance, getting closer, rewrote a lot of libraries, still some work to go. - newtype deriving, sort of hacky and unchecked right now but oh so very useful. What I can use help with: - documentation, anything obvious missing, out of date? - external libraries. in the lib/ext directory I have a few. I'd like to expand it and keep track of what people want. I'd like some better automated way to handle these libraries so they need not be integrated with the main darcs tree. probably post 0.8.0. - many error messages produced by jhc are inscrutable. I'd like to start keeping track of the most eggregious ones and working on fixes. John
On 31 January 2012 20:41, John Meacham
I am happy to announce that we are almost upon the 0.8.0 release of jhc, which has quite a few changes from the past so I was hoping I could get some people to help test the newest darcs tree and give feedback.
Great work, John!
On 1/31/12 7:41 PM, John Meacham wrote:
Hi all,
I am happy to announce that we are almost upon the 0.8.0 release of jhc, which has quite a few changes from the past so I was hoping I could get some people to help test the newest darcs tree and give feedback.
So, I just pulled down a clean copy of the repo and tried to build it. So far I've run into the following build issues: * autoconf correctly identified that DrIFT wasn't installed, but then make ended up trying to call DrIFT anyways. * some package named HsSyck is specified when trying to compile jhc, though that's not listed in the required tools http://repetae.net/computer/jhc/development.shtml and isn't checked for during autoconf. * During `make libs` I get the following errors: ... [23 of 57] Jhc.Inst.Order lib/jhc/Jhc/Inst/Order.hs:13 - Error: Unknown name: Jhc.Class.Ord.< lib/jhc/Jhc/Inst/Order.hs:13 - Error: Unknown name: Jhc.Class.Ord.> lib/jhc/Jhc/Inst/Order.hs:13 - Error: Unknown name: Jhc.Class.Ord.== lib/jhc/Jhc/Inst/Order.hs:13 - Error: Unknown name: Jhc.Class.Ord./= ... -- Live well, ~wren
When pulling from the repo you need DrIFT installed, the tarballs don't need it though. I can make that message more informative... The development.html page is only updated on a release from docs/development.mkd, It would probably make more sense to have it track the repository version rather than the current release. I'll see about adding a cron job to fix that up. I have a fix for the third issue done. will post it soon, in the meantime you can find the call to qualifyInstMethod in src/FrontEnd/Rename.hs and just replace it and the hsDecls processing for HsInstDecl with
hsDecls' <- rename hsDecls
to just do a full renaming of the declarations.
John
On Sun, Feb 5, 2012 at 4:28 PM, wren ng thornton
On 1/31/12 7:41 PM, John Meacham wrote:
Hi all,
I am happy to announce that we are almost upon the 0.8.0 release of jhc, which has quite a few changes from the past so I was hoping I could get some people to help test the newest darcs tree and give feedback.
So, I just pulled down a clean copy of the repo and tried to build it. So far I've run into the following build issues:
* autoconf correctly identified that DrIFT wasn't installed, but then make ended up trying to call DrIFT anyways.
* some package named HsSyck is specified when trying to compile jhc, though that's not listed in the required tools http://repetae.net/computer/jhc/development.shtml and isn't checked for during autoconf.
* During `make libs` I get the following errors:
... [23 of 57] Jhc.Inst.Order lib/jhc/Jhc/Inst/Order.hs:13 - Error: Unknown name: Jhc.Class.Ord.< lib/jhc/Jhc/Inst/Order.hs:13 - Error: Unknown name: Jhc.Class.Ord.> lib/jhc/Jhc/Inst/Order.hs:13 - Error: Unknown name: Jhc.Class.Ord.== lib/jhc/Jhc/Inst/Order.hs:13 - Error: Unknown name: Jhc.Class.Ord./= ...
-- Live well, ~wren
_______________________________________________ jhc mailing list jhc@haskell.org http://www.haskell.org/mailman/listinfo/jhc
On 2/5/12 7:42 PM, John Meacham wrote:
When pulling from the repo you need DrIFT installed, the tarballs don't need it though. I can make that message more informative...
Yeah, I know, I just forgot I didn't have it installed. (I do now, of course.) I was mentioning it more because I would've expected the autoconf step to spot that it had neither DrIFT nor the generated files and therefore fail, rather than the failure happening in the build step. Not a big issue, just some polish.
The development.html page is only updated on a release from docs/development.mkd, It would probably make more sense to have it track the repository version rather than the current release. I'll see about adding a cron job to fix that up.
No worries. Again, mostly mentioned for the sake of making the build process nice, clean, and easy to follow.
I have a fix for the third issue done. will post it soon, in the meantime you can find the call to qualifyInstMethod in src/FrontEnd/Rename.hs and just replace it and the hsDecls processing for HsInstDecl with
hsDecls'<- rename hsDecls
to just do a full renaming of the declarations.
With that change it gets up to: [14 of 21] Data.Record.HT.Private tmp/build/utility-ht-0.0.5.1/src/Data/Record/HT/Private.hs:13 - Error: Ambiguous Name: compare Could refer to: (Data.Record.HT.Private.compare,Jhc.Class.Ord.compare) tmp/build/utility-ht-0.0.5.1/src/Data/Record/HT/Private.hs:14 - Error: Ambiguous Name: compare Could refer to: (Data.Record.HT.Private.compare,Jhc.Class.Ord.compare) tmp/build/utility-ht-0.0.5.1/src/Data/Record/HT/Private.hs:15 - Error: Ambiguous Name: compare Could refer to: (Data.Record.HT.Private.compare,Jhc.Class.Ord.compare) Running Command Failed! at utils/build_extlibs.prl line 26, <$fh> line 41. make: *** [utility-ht-0.0.5.1.hl] Error 2 Unrelatedly, I'm curious, what is the reason for still using base-1.0? Is there any hope of getting a newer base to compile so that we can use Hackage effectively? If not, what are the impediments: technical issues, or just manpower? -- Live well, ~wren
On Mon, Feb 6, 2012 at 10:42 PM, wren ng thornton
I have a fix for the third issue done. will post it soon, in the meantime you can find the call to qualifyInstMethod in src/FrontEnd/Rename.hs and just replace it and the hsDecls processing for HsInstDecl with
> hsDecls'<- rename hsDecls
to just do a full renaming of the declarations. With that change it gets up to:
[14 of 21] Data.Record.HT.Private tmp/build/utility-ht-0.0.5.1/src/Data/Record/HT/Private.hs:13 - Error: Ambiguous Name: compare Could refer to: (Data.Record.HT.Private.compare,Jhc.Class.Ord.compare) tmp/build/utility-ht-0.0.5.1/src/Data/Record/HT/Private.hs:14 - Error: Ambiguous Name: compare Could refer to: (Data.Record.HT.Private.compare,Jhc.Class.Ord.compare) tmp/build/utility-ht-0.0.5.1/src/Data/Record/HT/Private.hs:15 - Error: Ambiguous Name: compare Could refer to: (Data.Record.HT.Private.compare,Jhc.Class.Ord.compare) Running Command Failed! at utils/build_extlibs.prl line 26, <$fh> line 41. make: *** [utility-ht-0.0.5.1.hl] Error 2
Yeah, I discovered that bug too. Not sure what exactly introduced it but i was messing with the renamer. I temporarily disblede utility-ht until I get a chance to look at it again.
Unrelatedly, I'm curious, what is the reason for still using base-1.0? Is there any hope of getting a newer base to compile so that we can use Hackage effectively? If not, what are the impediments: technical issues, or just manpower?
Well, it isn't really base 1.0, it has no relation to the hackage/ghc version other than the unfortunate shared name and the fact they implement similar things which can be confusing. There is no correspondence between the version numbers but it does support many of the interfaces that newer versions of ghcs base has, so you can generally compile cabal projects by simply deleting their build-depends and letting jhc loose on it. probably not with 0.8.0, but with something soon I want to get rid of base and just have 'haskell2010' and 'haskell98' as provided libraries that strictly follow the standards then some packages that extend them, such as 'haskell-extras'. I was thinking I would mirror the namespaces of the standard libraries for extended versions. like mallocPlainForeignPtrBytes would be in Ext.Foreign.ForeignPtr, in general Ext.foo would be the haskell2010 version of something with jhc extensions included. 'jhc' and 'jhc-prim' would also exist, but generally wouldn't be used directly by users. The good news is that jhc sidesteps most of the issues with package incompatibility that plauge ghc, no need to make haskell98 incompatible with later libraries as class aliases and module re-exports make it pretty easy to support both seamlessly and provide custom views that look more like whatever version of ghc or nhc or uhc you (or your programs) are used too :) There is nothing in particular keeping cabal from supporting jhc, in fact, it is a nicer target in a lot of ways, not requiring registering/hiding packages, keeping track of interface hashes internally to allow many versions of libraries to be used side-by-side, etc.. The issue is that cabal's model just doesn't scale. By using version numbers the work scales non-linearly with the number of _potential_ incompatibilites, rather than the actual ones. It can barely handle keeping up with multiple versions of ghc, let alone throwing another compiler into the mix. So, it is certainly possible to target jhc with cabal and use the same inscrutible version numbers, I just don't think it is a very productive use of peoples time. Every time someone has to update their build-depends or I have to reverse engineer code to figure out that #if MIN_VERSION_base(foo) is actually testing for the presence of Data.Typeable is time lost that could have been spent programming. ah well. something better will come along eventually, I'll just make jhc very easy to target and use and hope for the best. John
participants (3)
-
John Meacham -
Robin Bate Boerop -
wren ng thornton