October 2006 - Yhc - Haskell.org

Buildbot goes nuts!
by Neil Mitchell 30 Oct '06

30 Oct '06

Hi, After Dimitry's patch buildbot went nuts and fired off a new build every 10 minutes. I guess this is due to parsing issues in a similar way the version stuff was, but only Andrew has this code so only Andrew will be able to fix it. I have committed a patch which will hopefully stop this cycle going on. Dimitry: Can you record some dummy patch with no comment just before you do a scons push? This should at least stop buildbot going crazy until Andrew gets back and can take a look at it. Thanks Neil

1 0

HCAR entry
by Neil Mitchell 30 Oct '06

30 Oct '06

Hi, I put up a provisional HCAR entry: http://haskell.org/haskellwiki/Yhc/HCAR Thoughts? Comments? Missing bits? Feel free to add anything you want, or edit a will. In 2 days this is getting sent off to the HCAR. Thanks Neil

1 0

buildbot failure in windows
by andrewjwilkinsonw＠gmail.com 30 Oct '06

30 Oct '06

The Buildbot has detected a failed build of windows. Full details are available at: http://www.indiegigs.co.uk:8010/windows/builds/174 Buildbot URL: http://www.indiegigs.co.uk:8010/ Build Reason: Build Source Stamp: HEAD Blamelist: golubovsky(a)gmail.com BUILD FAILED: failed failed slave lost sincerely, -The Buildbot

1 0

Regarding Yhc bytecode versioning
by Robert Dockins 30 Oct '06

30 Oct '06

Yhc hackers, Several weeks ago I received a report that my bytecode library for Yhc was not working correctly. I investigated the matter and discovered several reasons for the problem. I've fixed the bugs and released a new version of the library. The problems were: * Idiocy on my part. I somehow managed to get the minor version of the Yhc bytecode set wrong. I thought it was 9, but it actually is 10. * Compatibility-breaking changes to the bytecode file format. The second problem is the one I wish to discuss. Since I began work on the Yhc bytecode library in May, there have been at least two instances of compatibility-breaking changes. One relates to Hat integration, I believe, and the other has to do with the switch to libFFI. Both of these changes were made without bumping the version number that appears in the file header. I would like to suggest that such changes be avoided in the future. It seems to me that Yhc is fairly rapidly approaching a feature- complete release, and I think we should start thinking pretty seriously about stability issues. If it becomes necessary to somehow modify the file format, then I feel that we should be careful to document the changes, and be sure to bump the version number. That way we can rely on the stated version number to reliably identify the proper parsing procedures for a bytecode file. Without this basic guarantee, it becomes very difficult to achieve interoperability. It may also be a good time to think about a ways to future-proof the file format so that future additions can be made without breaking compatibility. Right now the format is quite fragile. Perhaps we could take inspiration from the Java classfile format. The basic idea is that there are named blocks of data with a minimal header which gives the name of the block and the size of the data payload. The name of the block defines the meaning of the data. Eg, the 'CODE' block contains bytecode instructions, etc. If any block is encountered with an unrecognized name, it is ignored. That way, one can have optional blocks, or one can add blocks without breaking compatibility. One can also have optional information (like debugging symbols) and things of that nature. What do you think? Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

3 3

[Announce] Yhc Bytecode library 0.3
by Robert Dockins 29 Oct '06

29 Oct '06

[Please direct disccusion to the yhc list] Fellow Haskellers, I am pleased to announce the release of the Yhc Bytecode library, version 0.3. The major differences from version 0.2 are: * Updated to work with the current Yhc development branch as of 2006-10-13 * API modified to fully handle the string table so that it is no longer exposed to the user * Added support for the 'Ext' and 'Prim' object types * Slightly improved some error messages Source and Haddock documentation downloads are avaliable from: http://www.eecs.tufts.edu/~rdocki01/yhc-bytecode.html Direct access to the darcs repository from: http://www.eecs.tufts.edu/~rdocki01/yhc-bytecode/ Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

2 4

Proposal: Yhc Core file generation
by Neil Mitchell 29 Oct '06

29 Oct '06

Hi, There are shortly going to be 2 projects that use Yhc.Core extensively, one of them even _not_ written by me! As such maybe now is the time to start taking our Core output a bit more seriously - so here are my proposals: 1) core=1 is the default for Scons, installed libraries contain .ycr files - Slower to compile the libraries (a bit) takes up more space (a few Mb) + useful for the Yhc.Core users 2) Make the -core plus lack of a .ycr file, or an old .ycr file, cause a file to be rebuilt. At the moment it only has an effect on newly built files. - more recompilation + but only for people who specify -core 3) Add a -corelink option, which implicitly issues -core, and after all the .ycr files have been generated, pulls them together into one big .yca file. + useful for Yhc.Core users 4) Add a -O option that calls Catch with the big .yca file after its be generated. + optimised binaries :) + can default to GHC -O2 when catch is unavailable In addition there will be another user of the Yhc.Core files, which will be announced shortly, but for which steps 1 through 3 would be really handy. So basically, only 1) hurts anyone, and not by that much. Does this seem fine to everyone? Thanks Neil

1 1

buildbot failure in macosx_x86
by andrewjwilkinsonw＠gmail.com 28 Oct '06

28 Oct '06

The Buildbot has detected a failed build of macosx_x86. Full details are available at: http://www.indiegigs.co.uk:8010/macosx_x86/builds/34 Buildbot URL: http://www.indiegigs.co.uk:8010/ Build Reason: Build Source Stamp: HEAD Blamelist: Andrew Wilkinson <aw(a)cs.york.ac.uk>,Neil Mitchell,golubovsky(a)gmail.com BUILD FAILED: failed darcs sincerely, -The Buildbot

1 0

System upgrade for my buildbot
by Isaac 28 Oct '06

28 Oct '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just upgraded the system running my linux-powerpc yhc buildbot to Ubuntu 6.10 "Edgy Eft". I changed the information I put in the buildbot "info/host" file to match. Hopefully it won't cause any problems, but, just a warning in case anything goes wrong because of it. Edgy has GHC 6.4.2 (up from 6.4.1, so there is binary incompatibility). Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFQ4vrHgcxvIWYTTURAv1NAJ9FFanOe5l+YyfclejSmn0/HXJ9zwCbB8x1 tsXfhriWqLU/e4bP6kkcHtg= =GqPx -----END PGP SIGNATURE-----

1 0

Possible bug with floats
by Dimitry Golubovsky 27 Oct '06

27 Oct '06

Neil, I have added missing show functions for CoreFloat and CoreDouble. While testing, I came across this issue: Haskell: module Vt1 where ... y :: Float -> Float y f = case f of 1.0 -> 2.0 3.45 -> 0.2e-4 0.99 -> 7.463 other -> -3.65 Core: Vt1.y v423 = case (YHC.Internal._eqFloat v423 1.0) of Prelude.True -> 2.0 Prelude.False -> -3.65 It looks like a case expression was converted as an if expression. Hopefully this is only a Core problem because: bash$ cat fltest.hs module Main where y :: Float -> Float y f = case f of 1.0 -> 2.0 3.45 -> 0.2e-4 0.99 -> 7.463 other -> -3.65 main = do putStrLn $ show (y 1.0) putStrLn $ show (y 3.45) putStrLn $ show (y 0.99) putStrLn $ show (y 4.56) bash$ yhc fltest.hs Compiling Main ( fltest.hs ) bash$ yhi Main.hbc 2.0 2.0e-5 7.463 -3.65 i. e. the program works OK. -- Dimitry Golubovsky Anywhere on the Web

3 3

Yhc chokes on __ identifer
by Russell O'Connor 25 Oct '06

25 Oct '06

I have a Haskell program that defines the value __ as __ = Prelude.error "Logical or arity value used" Yhc seems unhappy with this name. Any reason for this? Can Yhc be made to accept this?

4 7