- Yhc - Haskell.org

Cross-compiling YHC for XScale/ARM based WinCE
by Iván Pérez Domínguez 25 Apr '07

25 Apr '07

I have a PDA, I'm trying to port YHC to it. It's currently using Windows (in the PDA only), and I'm not planning to change it for the time being. I'm using cegcc to compile yhc. Since yhc is written in haskell, I used ghc to generate the .hc files, then used cegcc to compile them to binary code. I'm getting this error: In file included from /usr/lib/ghc-6.4.2/include/Stg.h:149, from State.c:3: /usr/lib/ghc-6.4.2/include/Regs.h:213: error: invalid register name for 'R1' ... Looks like has something to do with ghc. Should I install yhc and use it to generate the C code instead? Any suggestions?

3 2

buildbot failure in gentoo_x86
by andrewjwilkinsonw＠gmail.com 18 Apr '07

18 Apr '07

The Buildbot has detected a new failure of gentoo_x86. Full details are available at: http://www.indiegigs.co.uk:8010/gentoo_x86/builds/154 Buildbot URL: http://www.indiegigs.co.uk:8010/ Buildslave for this Build: markus1 Build Reason: Build Source Stamp: HEAD Blamelist: Neil Mitchell BUILD FAILED: failed yhc sincerely, -The Buildbot

1 0

Yhc buildbot failures
by Neil Mitchell 17 Apr '07

17 Apr '07

Hi Its my fault that all the builtbots have broken, so I thought I'd post including the reasons why - and asking for how to fix it. The reason is that I've now introduced a dependency on Data.Binary - which is definately the right thing to do (before we were using our own Binary instances). Data.Binary depends on Data.ByteString. The problem is that Data.ByteString is available as a library in base on GHC 6.6, but not on 6.4 - where you have to use fps. So basically, we can say Yhc is GHC 6.6 only, or we can make the build system download and use fps, which would be rather annoying, or we can ask the Yhc users to install fps on their own for 6.4. Or we can ask the ByteString developers how to clean up what looks like a bad case of DLL hell. Thanks Neil

1 0

buildbot failure in linux_ppc
by andrewjwilkinsonw＠gmail.com 17 Apr '07

17 Apr '07

The Buildbot has detected a new failure of linux_ppc. Full details are available at: http://www.indiegigs.co.uk:8010/linux_ppc/builds/108 Buildbot URL: http://www.indiegigs.co.uk:8010/ Buildslave for this Build: linuxppc Build Reason: Build Source Stamp: HEAD Blamelist: Neil Mitchell BUILD FAILED: failed yhc sincerely, -The Buildbot

1 0

buildbot failure in gentoo_amd64
by andrewjwilkinsonw＠gmail.com 16 Apr '07

16 Apr '07

The Buildbot has detected a new failure of gentoo_amd64. Full details are available at: http://www.indiegigs.co.uk:8010/gentoo_amd64/builds/142 Buildbot URL: http://www.indiegigs.co.uk:8010/ Buildslave for this Build: gentooamd64 Build Reason: Build Source Stamp: HEAD Blamelist: Neil Mitchell BUILD FAILED: failed yhc sincerely, -The Buildbot

1 0

buildbot failure in slack_x86
by andrewjwilkinsonw＠gmail.com 16 Apr '07

16 Apr '07

The Buildbot has detected a new failure of slack_x86. Full details are available at: http://www.indiegigs.co.uk:8010/slack_x86/builds/182 Buildbot URL: http://www.indiegigs.co.uk:8010/ Buildslave for this Build: slackx86 Build Reason: Build Source Stamp: HEAD Blamelist: Neil Mitchell BUILD FAILED: failed yhc sincerely, -The Buildbot

1 0

Warning: Yhc.Core Binary Format changing
by Neil Mitchell 16 Apr '07

16 Apr '07

Hi, The Yhc.Core Binary format is about to change, the Haskell interface will remain the same - but you'll need to recreate all core files you have floating around - anything .ycr or .yca. I am sorry to say that opening an old Core file with the new instances seems to non-terminate, rather than giving an error message. This is unfortunate, but hopefully future Core changes should not have this side effect. The reason for this change is the move from our hand-made Binary instance to the standard Data.Binary one. This should give us a speed up, and means we are keeping less of our own code in our tree. It probably means that we require either GHC 6.6 or the fps package to be installed on GHC 6.4. This change also means that to generate the Binary instance we are no longer relying on DrIFT but instead on Derive [1]. This means that anyone should be able to regenerate the Binary instance, rather than just me with a weird batch file. Thanks Neil [1] http://www-users.cs.york.ac.uk/~ndm/derive/

1 0

Yhc using mtl
by Twan van Laarhoven 11 Apr '07

11 Apr '07

Hallo Yhc developers, While I was in a masochistic mood this week, I decided to change Yhc to use proper monads. The old State.hs 'monad' was based around the functions (>>>=) and (>>>), representing a WriterT State monad. They had some quirky features, like different output state types, and because of the writer monad, there were lots of functions taking dummy environment parameters. There was also a different State0 s type representing State s (). I have replaced this mess by usage of the mtl, in particular Control.Monad.State and Control.Monad.Writer. Usage of (>>>=) is replaced by do notation. As replacement for the (=>>>) operator I use (<*>) and (<$>) based on Control.Applicative. I also added a new class "MonadIS" for monads that carry IntState around. > class Monad m => MonadIS m where > getIS :: m IntState > putIS :: IntState -> m () Most functions are generalized over this class. And to further improve the readability, all state and environment types are now records. Now, I may have introduced some bugs. The code was rather fond of reusing variable names like > case liftExp exp state of > (exp, state) -> ... While I tried to be careful, it is possible that somewhere there is a reference to an old value. Yhc does still pass the test suite. I may have also removed some of the strictness, in the old code =>>> (aka. <*>) was strict in the state, after the cleanup it no longer is. This could be fixed by using a different monad. There is already a StrictState monad in State.hs which I used for debugging (to get traces in some sensible order). I also changed "case x of (a,b) -> y" into "let (a,b) = x" in do blocks. Usually either a or b is examined afterwards anyway, so it should not matter much for the strictness. Unfortunately, the code now requires -fglasgow-exts (or a LANGUAGE pragma) in some places. The only reason for this is FlexibleInstances for the instance: > instance MonadIS (State IntState) where ... If this is a problem it might be possible to work around it by changing it to: > class HasIntState a > instance HasIntState a => MonadIS (State a) But IMO FlexibleInstances are a noncontroversial extension, and they are supported by most compilers. Finally, it should be noted that I kind of gave up at the end; the type checker just uses runState to get around the monads. The reason for this is that I saw a circular reference there somewhere, and I decided it was best not to mess with it. The patch is too big to send by email to this list, so it can be downloaded from http://twan.home.fmf.nl/yhc-mtl.patch.gz Twan van Laarhoven

4 6

buildbot failure in windows
by andrewjwilkinsonw＠gmail.com 10 Apr '07

10 Apr '07

The Buildbot has detected a new failure of windows. Full details are available at: http://www.indiegigs.co.uk:8010/windows/builds/106 Buildbot URL: http://www.indiegigs.co.uk:8010/ Buildslave for this Build: neilwindows Build Reason: Build Source Stamp: HEAD Blamelist: golubovsky(a)gmail.com BUILD FAILED: failed yhi release sincerely, -The Buildbot

1 0

Scons depends required
by Neil Mitchell 31 Mar '07

31 Mar '07

Hi, We're going to be making use of some new libraries shortly, which means these new libraries have to be downloaded for each machine that builds Yhc, so could everyone do a "scons depends". For information, we're going to be killing the Yhc general package, which contained a home-grown binary library and a tweaked play library - moving to the official Play library (now modified to support our hacks natively) and the official Binary library (much much faster, we hope). We are also updating to the filepath libary that will be in GHC 6.6.1. Once we've done that, we can move to making a proper Cabal package for Yhc.Core, with proper dependencies, making programs that depend on Yhc.Core much more deployable. When I do the work to move to the binary library, this will mean that the on disk Yhc.Core format will change. Not yet, but just a warning for people. I don't think this will have much of an impact to many people, but those who use Yhc.Core a lot will probably need to rebuild their libraries. I'll send out an email when this happens. Thanks Neil

1 1