- Yhc - Haskell.org

buildbot failure in macosx_x86_dual
by andrewjwilkinsonw＠gmail.com 08 Mar '07

08 Mar '07

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

1 0

buildbot failure in gentoo_x86
by andrewjwilkinsonw＠gmail.com 08 Mar '07

08 Mar '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/126 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 yhi sincerely, -The Buildbot

1 0

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

07 Mar '07

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

1 0

build system, endianness test
by Isaac Dupree 07 Mar '07

07 Mar '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I wrote the current endianness test Yhc uses for telling the ffi library it compiles. It uses C (compiled from Python/Scons), and it's an endianness test, so it's not portable. Seeing as there has been a bit of interest in a Haskell-based build system, whether or not that happens, I wrote a test in Haskell based around (Ptr WordX), and it works correctly on my big-endian machine at least (and its comments reference a modern source on endianness, namely, wikipedia :). It didn't take long. If you're interested: darcs get http://isaac.cedarswampstudios.org/2007/Endian/ (or don't even bother with darcs, just web-browse) Isaac P.S. Following the tradition of releasing little libraries, I feel tempted to do that, but... ;) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF7epRHgcxvIWYTTURAvorAJ4ns8TXlqt0pYPrJtzcWpZbWp9CzQCfW+Vf uw4xepQ/58n5Ly/L4xyZpns= =ysGx -----END PGP SIGNATURE-----

1 1

buildbot failure in linux_ppc
by andrewjwilkinsonw＠gmail.com 06 Mar '07

06 Mar '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/83 Buildbot URL: http://www.indiegigs.co.uk:8010/ Buildslave for this Build: linuxppc Build Reason: Build Source Stamp: HEAD Blamelist: golubovsky(a)gmail.com BUILD FAILED: failed failed slave lost sincerely, -The Buildbot

1 0

Re: [Yhc] New Build System
by Peter Tanski 06 Mar '07

06 Mar '07

On Sat, 3 Mar 2007 04:49:16 +0000 Neil Mitchell wrote: > ... I was wondering if we'd have more success with > something written purely in Haskell. <snip> > * Everything is based on profiles, more on that once its done > * Compile C files with GHC everywhere (will this go wrong?) <snip> > It is not currently useable! The "Main configure" works and does the C > configure tests and searches for GHC etc. "Main push" works fine. > "Main yhc" will work if you have all the required packages > pre-installed by Cabal - likely to only be me - but it does work. The first thing that would certainly go wrong is compiling the Yhc RTS. It currently compiles only with MS CL--if I correctly understand another message you wrote: On Fri, 2 Mar 2007 22:54:38 +0000: Subject: Re: [Yhc] Problems installing YHC on Windows XP > We don't support the gcc from MingW, in fact we don't support GCC on > Windows at all. We only support Visual Studio. GHC only supports GCC. (Many apologies for flagging on the Windows- native port of GHC. (I have been desperate to finish the replacement library--adequately, i.e., better than or at least comparable to GMP-- running out of time (and money) and I admit I spend too much time experimenting with new algorithms. To my knowledge, an almost purely SIMD library has not been done before.) > There are only 3 things left to do which might go wrong/take some > time: > > 1) Download dependancies automatically and install them with Cabal. > Haskell's lack of a good wget/tar combo here may hurt us, but I'll see > what code I can find lying around. What about a direct interface to darcs? At least that way you could sponge off the darcs wrapper for curl. > 2) Compile Yhi, which requires make-style knowledge about C. Scons had > this built in much more, I'll need to roll my own. Cabal with hooks might help, or at least pull things from Distribution.Simple. > Anyone have any thoughts? As an alternative to using GHC to control the C-compiler, you might consider using VCBUILD from the command line for the current yhi .vcproj files. Towards that end, here is an unfinished module I started writing last January when we were talking about finding and obtaining the environment variables from vsvars32.bat. It probably should only use Distribution modules instead of System; it does not print the environment variables to a command file; and, it uses both Text.Regex and Text.ParserCombinators.Parsec but it might help: Cheers, Pete Tanski

2 2

What constitutes an 'evaluated node'?
by Stefan O'Rear 06 Mar '07

06 Mar '07

Hello. I am writing my own Yhi-Bytecode backend. I wish to minimize the number of indirection checks, and the bytecode.xml is not clear on the subject. Some of the bytecodes, eg INT_SWITCH, require the node they are applied to, to be 'evaluated'. EVAL takes a node and returns an equivalent evaluated node. However in the current implementation (Yhi) EVAL has the side-effect of making any other reference to the original node become evaluated. For instance, this is "legal": not: PUSH_ARG_0 EVAL POP_1 PUSH_ZAP_ARG_0 JUMP_FALSE L2 POP_1 PUSH_CON_0 RETURN L2: POP_1 PUSH_CON_1 RETURN { Prelude.False, Prelude.True } Specifically, I have in mind an implementation where indirections are NEVER automatically followed, and only EVAL and RETURN_EVAL (and for efficiency perhaps APPLY) check for them, returning the targets as the evaluated nodes. Thus in the above example, the value pushed by PUSH_ZAP_ARG_0 would be an indirection node, not False in any case, so our 'not' would mis-behave as 'const False'. Does any yhc generated code rely on this (mis?) feature? Does anyone (note that I do NOT say 'else') think this is a misfeature? Stefan

3 3

What constitutes an 'evaluated node'?
by Dimitry Golubovsky 06 Mar '07

06 Mar '07

Hi, I'm hoping that some followup to Stefan's question will be posted here. I have a similar question to answer with my Javascript code generator. In Javascript, it is very easy to update the "original" node after evaluation because references to an object referencing such node are passed around, and updating of some property value via such reference automatically updates the original node itself. If it is more appropriate to limit update propagation, special measures need to be taken (such as cloning a node object instead of passing a reference), and it is better to be learned now. -- Dimitry Golubovsky Anywhere on the Web

2 1

Long standing Scons bug fixed
by Andrew Wilkinson 05 Mar '07

05 Mar '07

Hi all, Over the weekend I spent some time bashing our Scons scripts and I managed to find and work around a scons bug which has been plaguing us for some time. The bug caused the type-size checks to fail the second time configure was run. The fix is in darcs now, and I've reported it to the Scons people so hopefully it'll be fixed soon. Cheers, Andrew

1 0

New Build System
by Neil Mitchell 04 Mar '07

04 Mar '07

Hi, After hearing numerous complaints from lots of people about our build system (esp Malcolm and Donald ;) ) - I took a look at the details. We now have 1300 lines of Python in our build system, that seems like quite a lot! The build system has evolved over time to keep up with the users, but I was wondering if we'd have more success with something written purely in Haskell. It's not done yet, but I've pushed the first patch which has the basic stuff done. I've made a couple of completely different decisions from the scons method: * All object files go under obj, clean is equal to deleting obj * Use ghc --make, yhc make mode etc, where possible * Everything should be able to be overiden, i.e. os=mac works just fine on a windows box (great for cross compiling!) * Everything is based on profiles, more on that once its done * Compile C files with GHC everywhere (will this go wrong?) * Install Haskell packages using Cabal * No explicit library dependancies It is not currently useable! The "Main configure" works and does the C configure tests and searches for GHC etc. "Main push" works fine. "Main yhc" will work if you have all the required packages pre-installed by Cabal - likely to only be me - but it does work. There are only 3 things left to do which might go wrong/take some time: 1) Download dependancies automatically and install them with Cabal. Haskell's lack of a good wget/tar combo here may hurt us, but I'll see what code I can find lying around. 2) Compile Yhi, which requires make-style knowledge about C. Scons had this built in much more, I'll need to roll my own. 3) Compile the libraries. If this isn't trivially easy I'll extend Yhc until it is. So far I'm quite happy with it - it seems very flexible and very modular. The disadvantage of moving to this (if it works) is that we'd likely throw away some of the fixes we've made. The advantage is fewer dependancies, and more people who know Haskell - provided the Haskell stays simple and clean. Anyone have any thoughts? Thanks Neil

2 1