From ndmitchell at gmail.com  Mon Jul  2 15:41:31 2007
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Mon Jul  2 15:35:28 2007
Subject: [Yhc] Location of generated files
Message-ID: <404396ef0707021241u2f0b9d39i67176aacd870b36c@mail.gmail.com>

Hi,

I'd like to change where Yhc puts generated files. I propose:

Every module gets assigned a "root" directory:
* foo/Main.hs has a root of "foo".
* foo/System/Cmd.hs, module System.Cmd, has a root of "foo".
* foo/System/Cmd.hs, module Cmd, has a root of "foo/System".

(Note that this is already done when searching for imports)

Every file with <ext> (where ext is one of hi, hbc,ycr,yca) will be created in:

* foo/Main.hs leads to foo/<dir-ext>/Main.<ext>
* foo/System/Cmd.hs, module System.Cmd, leads to foo/<dir-ext>/System.Cmd.<ext>

By default, <dir-ext> is "obj" for all extensions. The flag objdir
will allow the default <dir-ext> to be changed. The flag <ext>dir will
allow the location of <ext> files to be changed. For example
--hidir=hi would put all the hi files in foo/hi/Main.hi. --objdir=bar
will put all generated files in foo/bar/*.*.

There is exactly one exception to this rule:

foo/Foo.hs, module Main, creates foo/Foo.hbc, in all circumstances.

Comments? If the argument you use relies on some other compiler
(GCC/GHC) doing something different, please say _why_ that compilers
behaviour is preferable.

The reason for this change is that I have written a low-level Make
library, and therefore want to port Yhc to use this. I could
re-implement the existing behaviour, but once you sit down and take a
close look at the existing behaviour, it starts to look more and more
silly. The existing make facilities are around ~22Kb of source, the
new one will have a separate well defined library of ~7Kb, and a Yhc
specific part of ~3Kb. For free we will get minimal compilation, cycle
detection (and breaking using hand written .hi files), minimal file
tests etc.

As part of this move to a new make architecture, I want Yhc to be able
to compile the base library by simply invoking yhc *.hs, I want
linking of .yca files to work better, and I want world peace.

I also hope that once the Make library has been tested in the context
of Yhc, it can be shoved in the direction of the Cabal people.

Thanks

Neil
From stefanor at cox.net  Mon Jul  2 16:19:08 2007
From: stefanor at cox.net (Stefan O'Rear)
Date: Mon Jul  2 16:13:07 2007
Subject: [Yhc] Location of generated files
In-Reply-To: <404396ef0707021241u2f0b9d39i67176aacd870b36c@mail.gmail.com>
References: <404396ef0707021241u2f0b9d39i67176aacd870b36c@mail.gmail.com>
Message-ID: <20070702201908.GA5751@localhost.localdomain>

On Mon, Jul 02, 2007 at 08:41:31PM +0100, Neil Mitchell wrote:
> Hi,
> 
> I'd like to change where Yhc puts generated files. I propose:
> 
> Every module gets assigned a "root" directory:
> * foo/Main.hs has a root of "foo".
> * foo/System/Cmd.hs, module System.Cmd, has a root of "foo".
> * foo/System/Cmd.hs, module Cmd, has a root of "foo/System".
> 
> (Note that this is already done when searching for imports)
> 
> Every file with <ext> (where ext is one of hi, hbc,ycr,yca) will be created 
> in:
> 
> * foo/Main.hs leads to foo/<dir-ext>/Main.<ext>
> * foo/System/Cmd.hs, module System.Cmd, leads to 
> foo/<dir-ext>/System.Cmd.<ext>
> 
> By default, <dir-ext> is "obj" for all extensions. The flag objdir
> will allow the default <dir-ext> to be changed. The flag <ext>dir will
> allow the location of <ext> files to be changed. For example
> --hidir=hi would put all the hi files in foo/hi/Main.hi. --objdir=bar
> will put all generated files in foo/bar/*.*.
> 
> There is exactly one exception to this rule:
> 
> foo/Foo.hs, module Main, creates foo/Foo.hbc, in all circumstances.
> 
> Comments? If the argument you use relies on some other compiler
> (GCC/GHC) doing something different, please say _why_ that compilers
> behaviour is preferable.
> 
> The reason for this change is that I have written a low-level Make
> library, and therefore want to port Yhc to use this. I could
> re-implement the existing behaviour, but once you sit down and take a
> close look at the existing behaviour, it starts to look more and more
> silly. The existing make facilities are around ~22Kb of source, the
> new one will have a separate well defined library of ~7Kb, and a Yhc
> specific part of ~3Kb. For free we will get minimal compilation, cycle
> detection (and breaking using hand written .hi files), minimal file
> tests etc.
> 
> As part of this move to a new make architecture, I want Yhc to be able
> to compile the base library by simply invoking yhc *.hs, I want
> linking of .yca files to work better, and I want world peace.
> 
> I also hope that once the Make library has been tested in the context
> of Yhc, it can be shoved in the direction of the Cabal people.

This sounds like a very reasonable proposal, and I will take it for my
project as well.

My only concern is that some projects have obj/ dirs containing very
important sources (3D object models, etc) so we will need to be a bit
careful in the implementation of clean.

Also, when you say 3kb yhc-specific - how much of that relates to
invoking yhc, and how much is for building yhc?

Stefan
From ndmitchell at gmail.com  Mon Jul  2 16:53:12 2007
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Mon Jul  2 16:47:08 2007
Subject: [Yhc] Location of generated files
In-Reply-To: <20070702201908.GA5751@localhost.localdomain>
References: <404396ef0707021241u2f0b9d39i67176aacd870b36c@mail.gmail.com>
	<20070702201908.GA5751@localhost.localdomain>
Message-ID: <404396ef0707021353g4db0f26vca07b923dd59742d@mail.gmail.com>

Hi

> This sounds like a very reasonable proposal, and I will take it for my
> project as well.

Good :) You are welcome to use the Make library as well - I
deliberately wrote it to target all compilers and Cabal.

> My only concern is that some projects have obj/ dirs containing very
> important sources (3D object models, etc) so we will need to be a bit
> careful in the implementation of clean.

True. I would have thought that few of these projects put Haskell
sources at the root level, then their important objects underneath.
However, if we restrict to cleaning .hi, .hbc etc we should be ok. At
the moment there is no yhc clean command, so it can be done later.

> Also, when you say 3kb yhc-specific - how much of that relates to
> invoking yhc, and how much is for building yhc?

That all relates to invoking Yhc on Haskell files. This mainly
involves building a list of dependent modules, then extracting rules
from this dependency information. The make library is already in the
tree (src/libraries/make), and I'll hopefully have committed the
Make2.hs tonight.

Thanks

Neil
From ndmitchell at gmail.com  Mon Jul  2 17:21:10 2007
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Mon Jul  2 17:15:07 2007
Subject: [Yhc] Location of generated files
In-Reply-To: <4689616B.7020100@charter.net>
References: <404396ef0707021241u2f0b9d39i67176aacd870b36c@mail.gmail.com>
	<4689616B.7020100@charter.net>
Message-ID: <404396ef0707021421p30eb5a6cu418cc350e1a094aa@mail.gmail.com>

Hi

> What about
>  * foo/System/Cmd.hs, module Data.Whatever
> or other ridiculous arrangements, where the actual module name contains
> some number of dots greater than zero but doesn't match the directory
> structure.

Similar to putting module Foo in Bar.hs. There is no chance this will
ever be found by the compiler, so we emit an error. The one exception
is module Main, which can have any file name.

> You may want to allow filenames that replace some slashes with dots, such as
>  * foo/System.Cmd.hs, module System.Cmd
>  * foo/System/FilePath.Posix.hs, module System.FilePath.Posix
> both of which should have root "foo", I think.

Yes, I did intend to allow this. This is only an issue for finding the
root, everything else works out as before.

> Anyway, please don't look in the source directory for .hi files
> (assuming one didn't explicitly tell it to), it confuses yhc when
> looking at something ghc's been compiling.

Ah, good point! I've been bitten by this before, in the other
direction, with GHC reading Yhc's .hi files. I guess this is another
reason why this proposal is better than the current situation.

How about we default to being "yhc_obj" instead of "obj" - that way we
get a clear Yhc specific location, we won't clash with qhc, and we
don't run the risk of trampling anyone's image data etc.

Thanks

Neil
From isaacdupree at charter.net  Mon Jul  2 19:04:58 2007
From: isaacdupree at charter.net (Isaac Dupree)
Date: Mon Jul  2 18:57:06 2007
Subject: [Yhc] Location of generated files
In-Reply-To: <404396ef0707021421p30eb5a6cu418cc350e1a094aa@mail.gmail.com>
References: <404396ef0707021241u2f0b9d39i67176aacd870b36c@mail.gmail.com>	
	<4689616B.7020100@charter.net>
	<404396ef0707021421p30eb5a6cu418cc350e1a094aa@mail.gmail.com>
Message-ID: <4689849A.2060601@charter.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Neil Mitchell wrote:
> Hi
> 
>> What about
>>  * foo/System/Cmd.hs, module Data.Whatever
>> or other ridiculous arrangements, where the actual module name contains
>> some number of dots greater than zero but doesn't match the directory
>> structure.
> 
> Similar to putting module Foo in Bar.hs. There is no chance this will
> ever be found by the compiler, so we emit an error. The one exception
> is module Main, which can have any file name.

good. What if Yhc is explicitly invoked on a module other than Main -
then Yhc will "find" that file, right? (assuming yhc supports partial
compilation). In that case I would be happy with giving an error, or
putting the obj-dir in the same place as the file (what if it is used
like main, via some sort of -main-is - and there is always
hugs/ghci-like usage)

> How about we default to being "yhc_obj" instead of "obj" - that way we
> get a clear Yhc specific location, we won't clash with qhc, and we
> don't run the risk of trampling anyone's image data etc.

seems good.

Cabal can set that directory's position/name to be wherever it wants
inside its own build directory, okay.

Isaac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGiYSZHgcxvIWYTTURAs98AJ9+068W6rIvUt4vQMzFK98KMkOZygCfcEQg
AzRCoaGJXuMwcbbeYcjWlJA=
=guDP
-----END PGP SIGNATURE-----
From andrewjwilkinsonw at gmail.com  Mon Jul  2 21:02:18 2007
From: andrewjwilkinsonw at gmail.com (andrewjwilkinsonw@gmail.com)
Date: Mon Jul  2 20:56:15 2007
Subject: [Yhc] buildbot failure in gentoo_x86
Message-ID: <20070703005613.D37AF3241B9@www.haskell.org>

The Buildbot has detected a new failure of gentoo_x86.
Full details are available at:
 http://www.indiegigs.co.uk:8010/gentoo_x86/builds/216

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

From andrewjwilkinsonw at gmail.com  Mon Jul  2 21:02:19 2007
From: andrewjwilkinsonw at gmail.com (andrewjwilkinsonw@gmail.com)
Date: Mon Jul  2 20:56:15 2007
Subject: [Yhc] buildbot failure in debian_amd64
Message-ID: <20070703005614.4E0D93241B9@www.haskell.org>

The Buildbot has detected a new failure of debian_amd64.
Full details are available at:
 http://www.indiegigs.co.uk:8010/debian_amd64/builds/248

Buildbot URL: http://www.indiegigs.co.uk:8010/

Buildslave for this Build: debianamd64

Build Reason: 
Build Source Stamp: HEAD
Blamelist: Neil Mitchell

BUILD FAILED: failed yhc

sincerely,
 -The Buildbot

From andrewjwilkinsonw at gmail.com  Mon Jul  2 21:02:32 2007
From: andrewjwilkinsonw at gmail.com (andrewjwilkinsonw@gmail.com)
Date: Mon Jul  2 20:56:29 2007
Subject: [Yhc] buildbot failure in linux_ppc
Message-ID: <20070703005627.D99853241B9@www.haskell.org>

The Buildbot has detected a new failure of linux_ppc.
Full details are available at:
 http://www.indiegigs.co.uk:8010/linux_ppc/builds/163

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

From andrewjwilkinsonw at gmail.com  Mon Jul  2 21:03:59 2007
From: andrewjwilkinsonw at gmail.com (andrewjwilkinsonw@gmail.com)
Date: Mon Jul  2 20:57:56 2007
Subject: [Yhc] buildbot failure in slack_x86
Message-ID: <20070703005754.DFCA93241B9@www.haskell.org>

The Buildbot has detected a new failure of slack_x86.
Full details are available at:
 http://www.indiegigs.co.uk:8010/slack_x86/builds/251

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

From andrewjwilkinsonw at gmail.com  Tue Jul  3 05:32:48 2007
From: andrewjwilkinsonw at gmail.com (andrewjwilkinsonw@gmail.com)
Date: Tue Jul  3 05:26:46 2007
Subject: [Yhc] buildbot failure in macosx_x86
Message-ID: <20070703092644.7F5E93243E7@www.haskell.org>

The Buildbot has detected a new failure of macosx_x86.
Full details are available at:
 http://www.indiegigs.co.uk:8010/macosx_x86/builds/195

Buildbot URL: http://www.indiegigs.co.uk:8010/

Buildslave for this Build: macosxx86

Build Reason: 
Build Source Stamp: HEAD
Blamelist: Neil Mitchell

BUILD FAILED: failed yhc

sincerely,
 -The Buildbot

From andrewjwilkinsonw at gmail.com  Tue Jul  3 07:24:25 2007
From: andrewjwilkinsonw at gmail.com (andrewjwilkinsonw@gmail.com)
Date: Tue Jul  3 07:18:20 2007
Subject: [Yhc] buildbot failure in windows
Message-ID: <20070703111820.01E75324281@www.haskell.org>

The Buildbot has detected a new failure of windows.
Full details are available at:
 http://www.indiegigs.co.uk:8010/windows/builds/154

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

From akmorris at gmail.com  Tue Jul  3 19:33:39 2007
From: akmorris at gmail.com (Alexis Morris)
Date: Tue Jul  3 19:27:32 2007
Subject: [Yhc] More questions when debugging /w arm-elf-gcc
Message-ID: <c2717f270707031633ib248411u929c902c095854cb@mail.gmail.com>

Hi all,

I have a few "undefined" errors when trying to link iofuncs.o, primitive.o,
and external.o...anyone know where those missing defines (see below) are
from?

-  In the file integer.h there is this define:

   #define mpz_ui_pow_ui(r, x, y)  { r[0].value = (Int64)pow(x, y); }  But
pow(x,y) is undefined...does anyone know where it came from?...was it a part
of LIBGMP or LIBFFI?

-  In primitive.c the functions below seem to be undefined too....

   primitive.c:void init_YHC_Primitive(WrapRegisterFun reg, void* arg);
   primitive.c:  init_YHC_Primitive(prim_register, NULL);


- In external.c the arm-gcc toolchain doesn't seem to support the <dlfcn.h>
(or <windows.h>) that are used for the dll functions. I could be wrong
though...will look into that some more. I had them commented out.


Thanks again :)


============================

$ make
arm-elf-gcc -Wall -c basepath.c
arm-elf-gcc -Wall -c foreign.c
arm-elf-gcc -Wall -c heap.c
arm-elf-gcc -Wall -c info.c
arm-elf-gcc -Wall -c iofuncs.c
arm-elf-gcc -Wall -c main.c
arm-elf-gcc -Wall -c mark.c
mark.c: In function 'mark_rec':
mark.c:238: warning: unused variable 'indent'
arm-elf-gcc -Wall -c mutator.c
arm-elf-gcc -Wall -c primitive.c
arm-elf-gcc -Wall -c profile.c
arm-elf-gcc -Wall -c stable.c
arm-elf-gcc -Wall -c external.c
arm-elf-gcc -Wall -c hashtable.c
arm-elf-gcc -Wall -c hsffi.c
hsffi.c:46: warning: 'hsffi_allocContext' defined but not used
hsffi.c:182: warning: 'hsffi_evalContext' defined but not used
arm-elf-gcc -Wall -c integer.c
arm-elf-gcc -Wall -c jonkers.c
arm-elf-gcc -Wall -c make.c
arm-elf-gcc -Wall -c module.c
arm-elf-gcc -Wall -c pretty.c
pretty.c: In function 'pr_nodeWith':
pretty.c:277: warning: unused variable 'tmp'
arm-elf-gcc -Wall -c process.c
arm-elf-gcc -Wall -c sanity.c
sanity.c: In function 'sanity_init':
sanity.c:59: warning: format '%d' expects type 'int', but argument 3 has
type 'long unsigned int'
sanity.c:59: warning: format '%d' expects type 'int', but argument 4 has
type 'long unsigned int'
arm-elf-gcc -Wall -c stopcopy.c


arm-elf-gcc  basepath.o foreign.o heap.o info.o iofuncs.o main.o mark.o
mutator.o primitive.o profile.o stable.o external.o hashtable.
o hsffi.o integer.o jonkers.o make.o module.o pretty.o process.o sanity.o
stopcopy.o -o yhi


iofuncs.o: In function `fGetMPZ':
iofuncs.c:(.text+0x468): undefined reference to `pow'

primitive.o: In function `prim_load':
primitive.c:(.text+0x750): undefined reference to `init_YHC_Primitive'

external.o: In function `ext_load':
external.c:(.text+0x170): undefined reference to `dll_open'
external.c:(.text+0x1c8): undefined reference to `dll_error'
external.c:(.text+0x1f8): undefined reference to `dll_sym'
external.c:(.text+0x204): undefined reference to `dll_error'

collect2: ld returned 1 exit status
make: *** [yhi] Error 1

-- 
</Alexis>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/yhc/attachments/20070704/51c8a96c/attachment.htm
From starocean.wx at gmail.com  Tue Jul  3 21:50:00 2007
From: starocean.wx at gmail.com (pierric)
Date: Tue Jul  3 21:43:54 2007
Subject: [Yhc] More questions when debugging /w arm-elf-gcc
In-Reply-To: <c2717f270707031633ib248411u929c902c095854cb@mail.gmail.com>
References: <c2717f270707031633ib248411u929c902c095854cb@mail.gmail.com>
Message-ID: <f60bac540707031850x68cbd147l3e10af45b3823249@mail.gmail.com>

Hi.
2007/7/4, Alexis Morris <akmorris@gmail.com>:
> Hi all,
>
> I have a few "undefined" errors when trying to link iofuncs.o, primitive.o,
> and external.o...anyone know where those missing defines (see below) are
> from?
>
>    #define mpz_ui_pow_ui(r, x, y)  { r[0].value = (Int64)pow(x, y); }  But
> pow(x,y) is undefined...does anyone know where it came from?...was it a part
> of LIBGMP or LIBFFI?
>
It's from the standard math library. So plz add "-lm" when linking to
include the libm.a.

> -  In primitive.c the functions below seem to be undefined too....
>
>    primitive.c:void init_YHC_Primitive(WrapRegisterFun reg,
> void* arg);
>    primitive.c:  init_YHC_Primitive(prim_register, NULL);
> ........
> primitive.c: (.text+0x750): undefined reference to `init_YHC_Primitive'
> external.o: In function `ext_load':
> external.c:(.text+0x170): undefined reference to `dll_open'
> external.c:(.text+0x1c8): undefined reference to `dll_error'
> external.c:(.text+0x1f8): undefined reference to `dll_sym'
> external.c:(.text+0x204): undefined reference to `dll_error'
>
This should related to the shared library. And so do the following
errors which say "dll_**** missing". If your target board doesn't
support shared library, you can just uncomment the "#define NO_SHARED"
in platform.h. Otherwise, just add the "-ldl" when linking.


> _______________________________________________
> Yhc mailing list
> Yhc@haskell.org
> http://www.haskell.org/mailman/listinfo/yhc
>
>
From andrewjwilkinsonw at gmail.com  Fri Jul  6 10:38:14 2007
From: andrewjwilkinsonw at gmail.com (andrewjwilkinsonw@gmail.com)
Date: Fri Jul  6 10:32:02 2007
Subject: [Yhc] buildbot failure in linux_ppc
Message-ID: <20070706143200.30DF832416E@www.haskell.org>

The Buildbot has detected a new failure of linux_ppc.
Full details are available at:
 http://www.indiegigs.co.uk:8010/linux_ppc/builds/168

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 failed slave lost

sincerely,
 -The Buildbot

From andrewjwilkinsonw at gmail.com  Fri Jul  6 10:41:37 2007
From: andrewjwilkinsonw at gmail.com (andrewjwilkinsonw@gmail.com)
Date: Fri Jul  6 10:35:23 2007
Subject: [Yhc] buildbot failure in windows
Message-ID: <20070706143521.F39B13247C9@www.haskell.org>

The Buildbot has detected a new failure of windows.
Full details are available at:
 http://www.indiegigs.co.uk:8010/windows/builds/160

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

From andrewjwilkinsonw at gmail.com  Wed Jul 11 22:32:03 2007
From: andrewjwilkinsonw at gmail.com (andrewjwilkinsonw@gmail.com)
Date: Wed Jul 11 22:25:31 2007
Subject: [Yhc] buildbot failure in debian_amd64
Message-ID: <20070712022530.A41CA324039@www.haskell.org>

The Buildbot has detected a new failure of debian_amd64.
Full details are available at:
 http://www.indiegigs.co.uk:8010/debian_amd64/builds/261

Buildbot URL: http://www.indiegigs.co.uk:8010/

Buildslave for this Build: debianamd64

Build Reason: 
Build Source Stamp: HEAD
Blamelist: golubovsky@gmail.com

BUILD FAILED: failed yhc

sincerely,
 -The Buildbot

From isaacdupree at charter.net  Fri Jul 13 07:52:25 2007
From: isaacdupree at charter.net (Isaac Dupree)
Date: Fri Jul 13 07:46:43 2007
Subject: [Yhc] End-of-life of my linux-ppc buildbot
In-Reply-To: <46844020.9030205@charter.net>
References: <46844020.9030205@charter.net>
Message-ID: <46976779.8040306@charter.net>

Isaac Dupree wrote:
> By the end of the summer I'll have stopped having access to a powerpc
> system (although qemu could emulate any architecture system...), and
> hopefully I'll have stopped using it much sooner.

Well, my linux-ppc buildbot is gone now. Probably never will run again.

Isaac
From ndmitchell at gmail.com  Fri Jul 13 08:08:34 2007
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Fri Jul 13 08:01:55 2007
Subject: [Yhc] End-of-life of my linux-ppc buildbot
In-Reply-To: <46976779.8040306@charter.net>
References: <46844020.9030205@charter.net> <46976779.8040306@charter.net>
Message-ID: <404396ef0707130508t30aeb19fn8a050937b19e6e88@mail.gmail.com>

Hi Isaac,

> Well, my linux-ppc buildbot is gone now. Probably never will run again.

We'll miss it :-)

It caught a bug that on Linux PPC char is unsigned by default,
something we'd have never found without it.

As a related note, if anyone has some alternative hardware for a Yhc
buildbot, let us know. Something SPARC/Sun related would be nice, if
its lying around.

Thanks

Neil
From andrewjwilkinsonw at gmail.com  Fri Jul 13 11:55:39 2007
From: andrewjwilkinsonw at gmail.com (andrewjwilkinsonw@gmail.com)
Date: Fri Jul 13 11:59:23 2007
Subject: [Yhc] buildbot failure in macosx_x86
Message-ID: <20070713155921.750B432451D@www.haskell.org>

The Buildbot has detected a new failure of macosx_x86.
Full details are available at:
 http://www.indiegigs.co.uk:8010/macosx_x86/builds/210

Buildbot URL: http://www.indiegigs.co.uk:8010/

Buildslave for this Build: macosxx86

Build Reason: 
Build Source Stamp: HEAD
Blamelist: Andrew Wilkinson <aw@cs.york.ac.uk>,Christopher Lane Hinson <lane@downstairspeople.org>,Goetz Isenmann,Malcolm.Wallace@cs.york.ac.uk,Neil Mitchell,Stefan O'Rear <stefanor@cox.net>,Tom Shackell <shackell@cs.york.ac.uk>,Unknown,dominic.steinitz@blueyonder.co.uk,golubovsky@gmail.com

BUILD FAILED: failed Darcs

sincerely,
 -The Buildbot

From golubovsky at gmail.com  Sat Jul 14 23:49:38 2007
From: golubovsky at gmail.com (Dimitry Golubovsky)
Date: Sat Jul 14 23:42:57 2007
Subject: [Yhc] Problem with scons, cannot build Yhc
Message-ID: <bcba51a0707142049h590f1bcfl97a03483b4b58515@mail.gmail.com>

Hi,

I migrated from my old Celeron to a virtual machine (KVM) on AMD64
(but the VM is 32 bit).

I checked out the Yhc repo, but cannot even start building because of
strange error scons reports:

=============================
[dima@dmgdevel yhc]$ scons core=1 prefix=/home2/dima/install/ build
scons: Reading SConscript files ...
Building version 0.7.0-20070712053136-custom.
Checking for architecture... x86
Checking for operating system... linux2
Checking for Subversion binary... "svn"
Checking for Subversion version... Found version 1.4.4.
Checking for GHC binary... "ghc"
Checking for GHC version 6.4.1 or later... Found version 6.6.1.
Checking for C header file gmp.h... yes
Checking for mpz_t integ; mpz_init (integ) in C library gmp... yes
Checking for libgmp version... 4.2.1

scons: ***
File "/home2/dima/repos/yhc/build/configure.py", line 109, in configure
=============================

The file with problem (build/configure.py):

  108   def configure(env, Configure, args):
  109       conf = Configure(env, checks)
  110
  111       if not conf.CheckPythonVersion(env):
  112           print "Error. Python 2.3 or later must be used to compile Yhc"


Looks like that Configure is a pointer to some function passed as a parameter .

If I try to get some debug information from scons, I get (only
debug=includes gave me something)

=============================
[dima@dmgdevel yhc]$ scons --debug=includes core=1
prefix=/home2/dima/install/ build
scons: Reading SConscript files ...
Building version 0.7.0-20070712053136-custom.
Checking for architecture... x86
Checking for operating system... linux2
Checking for Subversion binary... "svn"
Checking for Subversion version... Found version 1.4.4.
Checking for GHC binary... "ghc"
Checking for GHC version 6.4.1 or later... Found version 6.6.1.
Checking for C header file gmp.h... yes
Checking for mpz_t integ; mpz_init (integ) in C library gmp...
TypeError: 'NoneType' object is not callable:
  File "Sconstruct", line 84:
    gmp_configure(env, Configure, ARGUMENTS)
  File "/home2/dima/repos/yhc/build/configure.py", line 95:
    if not conf.CheckLibWithHeader("gmp", "gmp.h", "C", "mpz_t integ;
mpz_init (integ);", 0):
  File "/home2/dima/install/lib/scons/SCons/SConf.py", line 354:
    ret = apply(self.test, (context,) +  args, kw)
  File "/home2/dima/install/lib/scons/SCons/SConf.py", line 750:
    call = call, language = language, autoadd = autoadd)
  File "/home2/dima/install/lib/scons/SCons/Conftest.py", line 387:
    ret = context.BuildProg(text, suffix)
  File "/home2/dima/install/lib/scons/SCons/SConf.py", line 599:
    res = self.TryBuild(self.env.Program, text, ext)
  File "/home2/dima/install/lib/scons/SCons/SConf.py", line 573:
    return apply(self.sconf.TryBuild, args, kw)
  File "/home2/dima/install/lib/scons/SCons/SConf.py", line 279:
    ret = self.BuildNodes(nodesToBeBuilt)
  File "/home2/dima/install/lib/scons/SCons/SConf.py", line 229:
    jobs.run()
  File "/home2/dima/install/lib/scons/SCons/Job.py", line 67:
    self.job.start()
  File "/home2/dima/install/lib/scons/SCons/Job.py", line 120:
    task.executed()
  File "/home2/dima/install/lib/scons/SCons/Script/__init__.py", line 146:
    tree = t.render_include_tree()
  File "/home2/dima/install/lib/scons/SCons/Node/__init__.py", line 795:
    return SCons.Util.render_tree(s, f, 1)
  File "/home2/dima/install/lib/scons/SCons/Util.py", line 932:
    children = child_func(root)
  File "/home2/dima/install/lib/scons/SCons/Node/__init__.py", line 794:
    return node.get_found_includes(env, scanner, target)
  File "/home2/dima/install/lib/scons/SCons/Node/FS.py", line 1504:
    includes = scanner(self, env, path)
  File "/home2/dima/install/lib/scons/SCons/Scanner/__init__.py", line 216:
    return self.select(node)(node, env, path)

=============================

Any ideas what this could be? This occurred with both most recent
scons (0.97) and Python (2.5.1), and after I downgraded to scons
0.96.1 and Python 2.4.4c1 (these worked fine on my old Celeron)

I don't believe there are any issues based on the fact that this is
VM: I was able to compile ghc 6.6.1 from sources (several hours),  and
there were no problems (except that gcc 4.2.1 did not work, I used
gcc-3.3, but this is a known issue related to gcc itself). The VM runs
(output from uname -a)

Linux dmgdevel 2.6.22-rc5-ARCH #1 SMP PREEMPT Sun Jun 24 11:12:27 CEST
2007 i686 QEMU Virtual CPU version 0.9.0 AuthenticAMD GNU/Linux

libc 2.6

Thanks.

-- 
Dimitry Golubovsky

Anywhere on the Web
From andrewjwilkinsonw at gmail.com  Sun Jul 15 06:37:55 2007
From: andrewjwilkinsonw at gmail.com (andrewjwilkinsonw@gmail.com)
Date: Sun Jul 15 06:31:13 2007
Subject: [Yhc] buildbot failure in macosx_x86_dual
Message-ID: <20070715103111.E9092324962@www.haskell.org>

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/179

Buildbot URL: http://www.indiegigs.co.uk:8010/

Buildslave for this Build: markus2

Build Reason: 
Build Source Stamp: HEAD
Blamelist: Andrew Wilkinson <aw@cs.york.ac.uk>,Christopher Lane Hinson <lane@downstairspeople.org>,Goetz Isenmann,Malcolm.Wallace@cs.york.ac.uk,Neil Mitchell,Stefan O'Rear <stefanor@cox.net>,Tom Shackell <shackell@cs.york.ac.uk>,Unknown,dominic.steinitz@blueyonder.co.uk,golubovsky@gmail.com

BUILD FAILED: failed failed slave lost

sincerely,
 -The Buildbot

From naur at post11.tele.dk  Fri Jul 20 06:42:03 2007
From: naur at post11.tele.dk (Thorkil Naur)
Date: Fri Jul 20 06:38:31 2007
Subject: [Yhc] Building fresh Yhc reports: scons: *** File
	"/Users/thorkilnaur/tn/YhcDarcsRepository/yhc/build/configure.py",
	line 109, in configure
Message-ID: <200707201242.04209.naur@post11.tele.dk>

Hello,

When I say "scons" to a freshly pulled yhc, this is the response:

scons: Reading SConscript files ...
Building version 0.7.0-20070712053136-custom.
Checking for architecture... (cached) ppc
Checking for operating system... (cached) darwin
Checking for Subversion binary... (cached) "svn"
Checking for Subversion version... (cached) Found version 1.4.0.
Checking for GHC binary... (cached) "ghc"
Checking for GHC version 6.4.1 or later... (cached) Found version 6.6.2.
Checking for C header file gmp.h... yes
Checking for mpz_t integ; mpz_init (integ) in C library gmp... yes
Checking for libgmp version... 4.2.1

scons: ***
File "/Users/thorkilnaur/tn/YhcDarcsRepository/yhc/build/configure.py", line 
109, in configure

I tried the scons fullclean + depends sequence also, the result is the same. 
Interestingly, my yhc buildbot slave seems in good shape ...

Help would be very much appreciated.

Thanks and regards
Thorkil
From golubovsky at gmail.com  Fri Jul 20 08:56:49 2007
From: golubovsky at gmail.com (Dimitry Golubovsky)
Date: Fri Jul 20 08:49:48 2007
Subject: [Yhc] Thorkil, myself, who else?
Message-ID: <bcba51a0707200556k3fdf2642m3de082b3cafa767f@mail.gmail.com>

Hi,

It looks like both Thorkil and myself see very similar problems:

Mine:

scons: Reading SConscript files ...
Building version 0.7.0-20070712053136-custom.
Checking for architecture... x86
Checking for operating system... linux2
Checking for Subversion binary... "svn"
Checking for Subversion version... Found version 1.4.4.
Checking for GHC binary... "ghc"
Checking for GHC version 6.4.1 or later... Found version 6.6.1.
Checking for C header file gmp.h... yes
Checking for mpz_t integ; mpz_init (integ) in C library gmp... yes
Checking for libgmp version... 4.2.1

scons: ***
File "/home2/dima/repos/yhc/build/configure.py", line 109, in configure

See also: http://haskell.org/pipermail/yhc/2007-July/001011.html (full
message, also has debug output from scons)



Thorkil's (almost identical, even on completely different architecture):

scons: Reading SConscript files ...
Building version 0.7.0-20070712053136-custom.
Checking for architecture... (cached) ppc
Checking for operating system... (cached) darwin
Checking for Subversion binary... (cached) "svn"
Checking for Subversion version... (cached) Found version 1.4.0.
Checking for GHC binary... (cached) "ghc"
Checking for GHC version 6.4.1 or later... (cached) Found version 6.6.2.
Checking for C header file gmp.h... yes
Checking for mpz_t integ; mpz_init (integ) in C library gmp... yes
Checking for libgmp version... 4.2.1

scons: ***
File "/Users/thorkilnaur/tn/YhcDarcsRepository/yhc/build/configure.py", line
109, in configure

I'm suspecting gmp as the test fails exactly there. Does anyone have
an older gmp (3.x) to try?

PS I have gmp 3.x on an older computer. For some reason, I couldn't
build Yhc completely after darcs pull (I didn't fullclean, and I am
basically migrating my development away from that computer), but at
least scons testing of gmp did not fail.

I cannot blame on the newer gmp otherwise, as ghc works fine with it.
It seems something wrong with scons.

Thorkil: when were you able to build Yhc last time, and what was your
gmp version then?

Thanks.

-- 
Dimitry Golubovsky

Anywhere on the Web
From naur at post11.tele.dk  Fri Jul 20 09:36:13 2007
From: naur at post11.tele.dk (Thorkil Naur)
Date: Fri Jul 20 09:32:39 2007
Subject: [Yhc] Re: Thorkil, myself, who else?
In-Reply-To: <bcba51a0707200556k3fdf2642m3de082b3cafa767f@mail.gmail.com>
References: <bcba51a0707200556k3fdf2642m3de082b3cafa767f@mail.gmail.com>
Message-ID: <200707201536.14090.naur@post11.tele.dk>

Hello,

On Friday 20 July 2007 14:56, Dimitry Golubovsky wrote:
> Hi,
> 
> It looks like both Thorkil and myself see very similar problems:
> 
> Mine:
> 
> scons: Reading SConscript files ...
> Building version 0.7.0-20070712053136-custom.
> Checking for architecture... x86
> Checking for operating system... linux2
> Checking for Subversion binary... "svn"
> Checking for Subversion version... Found version 1.4.4.
> Checking for GHC binary... "ghc"
> Checking for GHC version 6.4.1 or later... Found version 6.6.1.
> Checking for C header file gmp.h... yes
> Checking for mpz_t integ; mpz_init (integ) in C library gmp... yes
> Checking for libgmp version... 4.2.1
> 
> scons: ***
> File "/home2/dima/repos/yhc/build/configure.py", line 109, in configure
> 
> See also: http://haskell.org/pipermail/yhc/2007-July/001011.html (full
> message, also has debug output from scons)
> 
> 
> 
> Thorkil's (almost identical, even on completely different architecture):
> 
> scons: Reading SConscript files ...
> Building version 0.7.0-20070712053136-custom.
> Checking for architecture... (cached) ppc
> Checking for operating system... (cached) darwin
> Checking for Subversion binary... (cached) "svn"
> Checking for Subversion version... (cached) Found version 1.4.0.
> Checking for GHC binary... (cached) "ghc"
> Checking for GHC version 6.4.1 or later... (cached) Found version 6.6.2.
> Checking for C header file gmp.h... yes
> Checking for mpz_t integ; mpz_init (integ) in C library gmp... yes
> Checking for libgmp version... 4.2.1
> 
> scons: ***
> File "/Users/thorkilnaur/tn/YhcDarcsRepository/yhc/build/configure.py", line
> 109, in configure
> 
> I'm suspecting gmp as the test fails exactly there. Does anyone have
> an older gmp (3.x) to try?
> 
> PS I have gmp 3.x on an older computer. For some reason, I couldn't
> build Yhc completely after darcs pull (I didn't fullclean, and I am
> basically migrating my development away from that computer), but at
> least scons testing of gmp did not fail.
> 
> I cannot blame on the newer gmp otherwise, as ghc works fine with it.
> It seems something wrong with scons.
> 
> Thorkil: when were you able to build Yhc last time, and what was your
> gmp version then?

There are two Yhc instances on my machine: The first is used by the buildbot. 
Last build was http://www.indiegigs.co.uk:8010/macosx_ppc_3/builds/106 
"Building version 0.7.0-20070712053136." and that build was successful.

The second instance is the one I use when I want to play with Yhc. It is 
several months ago that I upgraded it last, so that is what I was in the 
process of doing when I ran into this error. The gmp version at that time was 
4.2.1, as now. In fact, I don't think I ever had another gmp on this machine. 
So it seems that this is unlikely to be the problem.

> 
> Thanks.
> 
> -- 
> Dimitry Golubovsky
> 
> Anywhere on the Web
> 

Thanks and best regards
Thorkil
From golubovsky at gmail.com  Fri Jul 20 09:58:30 2007
From: golubovsky at gmail.com (Dimitry Golubovsky)
Date: Fri Jul 20 09:51:35 2007
Subject: [Yhc] Re: Thorkil, myself, who else?
In-Reply-To: <200707201536.14090.naur@post11.tele.dk>
References: <bcba51a0707200556k3fdf2642m3de082b3cafa767f@mail.gmail.com>
	<200707201536.14090.naur@post11.tele.dk>
Message-ID: <bcba51a0707200658p12696638y9538585b07655901@mail.gmail.com>

Hi,

On 7/20/07, Thorkil Naur <naur@post11.tele.dk> wrote:
>
> There are two Yhc instances on my machine: The first is used by the buildbot.
> Last build was http://www.indiegigs.co.uk:8010/macosx_ppc_3/builds/106
> "Building version 0.7.0-20070712053136." and that build was successful.

The two last patches (incl xxx53136) were mine, but they changed files
that are outside the building tree. And there were no patches at all
since then.

I ran into the same error when I set up a clean virtual machine with
ArchLinux, and downloaded the whole Yhc repo, on Jul 14.

Looking at the inventory file, I see this:

[Update scons build yhc, scons update and scons push to work with the
new Yhc compiler directory
Neil Mitchell**20070626130702]
[Split out the gmp_configure bit, and only do it if building Yhi
Neil Mitchell**20070626143401]
[Add a little bit more trickery to try and get GMP detection working again
Neil Mitchell**20070626144901]

these are 3 last patches where GMP and scons are mentioned.

Neil: did you encounter anything like this (scons fails on line 109 of
configure.py) if building from scratch, before or after these patches?

When enabling more debug messages in scons output, something related
to "NoneType object is not callable" or similar, I'm guessing this is
kind of null pointer exception in Python?


-- 
Dimitry Golubovsky

Anywhere on the Web
From golubovsky at gmail.com  Fri Jul 20 10:19:19 2007
From: golubovsky at gmail.com (Dimitry Golubovsky)
Date: Fri Jul 20 10:12:18 2007
Subject: [Yhc] Re: Thorkil, myself, who else?
In-Reply-To: <200707201536.14090.naur@post11.tele.dk>
References: <bcba51a0707200556k3fdf2642m3de082b3cafa767f@mail.gmail.com>
	<200707201536.14090.naur@post11.tele.dk>
Message-ID: <bcba51a0707200719w5f844a9ek7b7026672777f02a@mail.gmail.com>

Hi,

On 7/20/07, Thorkil Naur <naur@post11.tele.dk> wrote:

> There are two Yhc instances on my machine: The first is used by the buildbot.
> Last build was http://www.indiegigs.co.uk:8010/macosx_ppc_3/builds/106
> "Building version 0.7.0-20070712053136." and that build was successful.
>

Are buildbot builds incremental, or they are done from scratch every
time? Incremental builds to my knowledge do not recheck things like
gmp as this information is cached by scons.

-- 
Dimitry Golubovsky

Anywhere on the Web
From naur at post11.tele.dk  Fri Jul 20 10:32:54 2007
From: naur at post11.tele.dk (Thorkil Naur)
Date: Fri Jul 20 10:29:58 2007
Subject: [Yhc] Re: Thorkil, myself, who else?
In-Reply-To: <bcba51a0707200719w5f844a9ek7b7026672777f02a@mail.gmail.com>
References: <bcba51a0707200556k3fdf2642m3de082b3cafa767f@mail.gmail.com>
	<200707201536.14090.naur@post11.tele.dk>
	<bcba51a0707200719w5f844a9ek7b7026672777f02a@mail.gmail.com>
Message-ID: <200707201633.06216.naur@post11.tele.dk>

Hello,

On Friday 20 July 2007 16:19, Dimitry Golubovsky wrote:
> Hi,
> 
> On 7/20/07, Thorkil Naur <naur@post11.tele.dk> wrote:
> 
> > There are two Yhc instances on my machine: The first is used by the 
buildbot.
> > Last build was http://www.indiegigs.co.uk:8010/macosx_ppc_3/builds/106
> > "Building version 0.7.0-20070712053136." and that build was successful.
> >
> 
> Are buildbot builds incremental, or they are done from scratch every
> time? Incremental builds to my knowledge do not recheck things like
> gmp as this information is cached by scons.

From http://www.indiegigs.co.uk:8010/macosx_ppc_3/builds/106/step-shell/0, it 
appears that the buildbot builds are incremental. Although I don't see 
anything in that particular configure log that deals with gmp, this is very 
likely the explanation why buildbot builds can continue to work, even if 
fresh builds fail.

Maybe I should go and erase my buildbot slave's build directory, someone might 
notice ...

> 
> -- 
> Dimitry Golubovsky
> 
> Anywhere on the Web
> 

Thanks and best regards
Thorkil
From golubovsky at gmail.com  Fri Jul 20 10:50:56 2007
From: golubovsky at gmail.com (Dimitry Golubovsky)
Date: Fri Jul 20 10:43:55 2007
Subject: [Yhc] Re: Thorkil, myself, who else?
In-Reply-To: <200707201633.06216.naur@post11.tele.dk>
References: <bcba51a0707200556k3fdf2642m3de082b3cafa767f@mail.gmail.com>
	<200707201536.14090.naur@post11.tele.dk>
	<bcba51a0707200719w5f844a9ek7b7026672777f02a@mail.gmail.com>
	<200707201633.06216.naur@post11.tele.dk>
Message-ID: <bcba51a0707200750o2ebe312el72ffb410e8f1dd8b@mail.gmail.com>

Thorkil,

On 7/20/07, Thorkil Naur <naur@post11.tele.dk> wrote:

> From http://www.indiegigs.co.uk:8010/macosx_ppc_3/builds/106/step-shell/0, it
> appears that the buildbot builds are incremental. Although I don't see


> Maybe I should go and erase my buildbot slave's build directory, someone might
> notice ...

Perhaps you might try: this must force the fresh build.

At least I'd narrow this down to scons itself (tonight I'll try to see
what was done around GMP tests).

Thanks.

-- 
Dimitry Golubovsky

Anywhere on the Web
From naur at post11.tele.dk  Fri Jul 20 11:17:27 2007
From: naur at post11.tele.dk (Thorkil Naur)
Date: Fri Jul 20 11:14:01 2007
Subject: [Yhc] Re: Thorkil, myself, who else?
In-Reply-To: <bcba51a0707200750o2ebe312el72ffb410e8f1dd8b@mail.gmail.com>
References: <bcba51a0707200556k3fdf2642m3de082b3cafa767f@mail.gmail.com>
	<200707201633.06216.naur@post11.tele.dk>
	<bcba51a0707200750o2ebe312el72ffb410e8f1dd8b@mail.gmail.com>
Message-ID: <200707201717.31426.naur@post11.tele.dk>

Hello,

On Friday 20 July 2007 16:50, Dimitry Golubovsky wrote:
> Thorkil,
> 
> On 7/20/07, Thorkil Naur <naur@post11.tele.dk> wrote:
> 
> > From http://www.indiegigs.co.uk:8010/macosx_ppc_3/builds/106/step-shell/0, 
it
> > appears that the buildbot builds are incremental. Although I don't see
> 
> 
> > Maybe I should go and erase my buildbot slave's build directory, someone 
might
> > notice ...
> 
> Perhaps you might try: this must force the fresh build.

I removed the build tree and forced a build, but somehow, scons wriggled out 
of trouble: The configure log output still says something about cached stuff 
and the build has now proceeded past configuring. I have no idea where this 
cache is located.

> 
> At least I'd narrow this down to scons itself (tonight I'll try to see
> what was done around GMP tests).
> 
> Thanks.
> 
> -- 
> Dimitry Golubovsky
> 
> Anywhere on the Web
> 

Best regards
Thorkil
From golubovsky at gmail.com  Fri Jul 20 12:36:47 2007
From: golubovsky at gmail.com (Dimitry Golubovsky)
Date: Fri Jul 20 12:29:48 2007
Subject: [Yhc] Issue 143: scons failed on line 109 of configure.py (was: Re:
	Thorkil, myself, who else?)
Message-ID: <bcba51a0707200936s5265c7a4lccac7db66e0f68f2@mail.gmail.com>

I have submitted issue 143

-- 
Dimitry Golubovsky

Anywhere on the Web
From golubovsky at gmail.com  Fri Jul 20 23:30:33 2007
From: golubovsky at gmail.com (Dimitry Golubovsky)
Date: Fri Jul 20 23:23:35 2007
Subject: [Yhc] Update on Issue 143 (error in Configure)
Message-ID: <bcba51a0707202030l4de0e5f5r8511a962137b3e14@mail.gmail.com>

Hi,

I made some research of the problem. I am unable to fix it: my
knowledge of Python is extremely low.

But the problem seems to have been localized.

See http://code.google.com/p/yhc/issues/detail?id=143 - I put a
comment with larger details.

For those who wants to try - just build yhc alone, then this problem
should not occur.

That is, run "scons build yhc"

Yhi will not be built, and the problem arises only when building Yhi
(because it needs GMP runtime).

Thanks.

PS Hopefully our Python experts read this and fix the problem.

-- 
Dimitry Golubovsky

Anywhere on the Web
From naur at post11.tele.dk  Mon Jul 23 08:43:57 2007
From: naur at post11.tele.dk (Thorkil Naur)
Date: Mon Jul 23 08:40:48 2007
Subject: [Yhc] Running catch on the HughesPJ prettyprinter
Message-ID: <200707231444.04590.naur@post11.tele.dk>

Hello Neil (cc Yhc),

I am trying to run your catch on the HughesPJ prettyprinter. The serious 
reason for trying this is that I suspect that some parts of the HughesPJ 
module are actually never used. That is, certain definitions are impossible 
to reach using the exported definitions. And I guess (but I haven't 
progressed far enough to tell) that catch can be used for this, simply by 
modifying some definition that you suspect is never used to head [] or 
perhaps just error "Something" and then see if catch can find a case where 
this error is reported.

Another reason is, of course, the expected entertainment value of such an 
experiment. In the latter, I was not disappointed, as I will now describe in 
some detail:

1. Catch (http://www.cs.york.ac.uk/fp/darcs/catch/catch.htm) requires me to 
use Yhc, so I decided to upgrade my Yhc installation. That didn't work out 
particularly well, as reported separately to yhc@haskell.org. But as a 
workaround, I am simply using the Yhc that gets built by the Yhc buildbot 
slave on my machine regularly. For some reason, this still works, even if I 
am unable to build an entirely fresh Yhc.

2. Trying the catch Risers example, I got this reaction:

> $ catch Risers
> 
Executing: /Users/thorkilnaur/tn/install/catch-0.1/share/catch-0.1/examples/Regress/Risers.hs
> Compiling
> yhc: Could not parse cmd-line options: unrecognized option `-l'
>
>
> catch: Failed to 
compile, /Users/thorkilnaur/tn/install/catch-0.1/share/catch-0.1/examples/Regress/Risers.hs
> $

To correct this:

> src/Prepare/Compile.hs:    res <- system $ "yhc --hide --linkcore \"" ++ 
file ++ "\" " ++ flags

(This is the 
http://hackage.haskell.org/packages/archive/catch/0.1.1/catch-0.1.1.tar.gz 
package that you recommend using). In addition:

> Task: Overlay
> yhc: Could not parse cmd-line options: unrecognized option `-o'
>
> unrecognized option `-r'
>
> unrecognized option `-e'
>
>
> catch: Failed to compile the overlay

was fixed by:

> src/Prepare/Overlay.hs:    res <- system $ "yhc --hide --core \"" ++ prim ++ 
"\""

3. Next on the agenda, we get

> $ catch HughesPJ
> Executing: HughesPJ.hs
> Compiling
> Compiling Text.PrettyPrint.HughesPJ ( HughesPJ.hs )
> -- during after type inference/checking
> Error: Type error type clash between Prelude.Int and Prelude.Bool
> when trying to apply function at 931:26 to its 2nd argument at 
931:31-931:33.
>
> catch: Failed to compile, HughesPJ.hs
> $

This is fixed by changing HughesPJ.hs as follows:

> 931c931
> <         lay1 k _ sl _ | k+sl `seq` False = undefined
> ---
> >         lay1 k _ sl _ | (k+sl) `seq` False = undefined

And this is, of course, rather interesting, since this type error (I cannot 
see it as anything else) is neither detected by Hugs nor GHC. But that is a 
matter for further work some other time.

4. Then I get this problem:

> $ catch HughesPJ
> Executing: HughesPJ.hs
> Compiling
> Compiling Text.PrettyPrint.HughesPJ ( HughesPJ.hs )
> Loading Core for YHC.Internal
> ...
> Loading Core for PreludeAux
> Linking...
> catch: ycr/HughesPJ.yca: openBinaryFile: does not exist (No such file or 
directory)
> 
> $

I have earlier disagreed with yhc as to where it's output files were placed 
and I also reported a bug about this some time back. This seems to be 
related, although I must admit that I have not at the time of writing 
investigated further. The first part of this problem is that bare "yhc 
HughesPJ" seems to place its output .hi and .hbc files in 
"../../Text/PrettyPrint/" and this is, of course, somewhat OK if you are 
already in "$SOMEWHERE/Text/PrettyPrint/". But if you are not, I assure you 
that this is confusing.

So, instead of working with "$SOMEWHERE/HughesPJ.hs", I created 
"$SOMEWHERE/Text/PrettyPrint/HughesPJ.hs" and started working from there. And 
thus, I was able to compile with "yhc HughesPJ" and find the output .hi 
and .hbc files in the same directory as HughesPJ.hs. However, catch HughesPJ 
still couldn't find its ycr/HughesPJ.yca file. Looking around again, I found 
the yhc output, as directed by catch, in 
"$SOMEWHERE/ycr/Text.PrettyPrint.HughesPJ.yca", etc. So because HughesPJ.hs 
has a module name Text.PrettyPrint.HughesPJ, the --hide option of yhc 
performs this massaging of the directory and output file name. And, 
apparently, catch is not able to match yhc in this.

This was fixed by changing HughesPJ.hs as follows:

> 170c170
> < module Text.PrettyPrint.HughesPJ (
> ---
> > module HughesPJ (

5. And then catch starts to run. It is presently here:

> $ catch HughesPJ
> Executing: HughesPJ.hs
> Compiling
> Compiling HughesPJ         ( HughesPJ.hs )
> Loading Core for YHC.Internal
> ...
> Loading Core for PreludeAux
> Linking...
> Transformations
> Task: Overlay
> Task: Firstify
> Warning: Failed in stage Firstify
> Task: LetElim
> Task: OneArg
> Task: UniqueVars
> Task: ShortCtors
> Analysing
> Checking [1/19]: Data.Ratio.% with zero as the second argument, bad person
> Partial: "Data.Ratio.%$142"
> Answer: _
> Checking [2/19]: HughesPJ: Pattern match failure in function at 
799:5-804:51.
> Partial: "HughesPJ.HughesPJ.Prelude.580.get"
> Partial: "HughesPJ.best"

and it's been there for about an hour, working. But I am sure that you have 
also noticed the ominous "Warning: Failed in stage Firstify" which may 
indicate that there is very little chance of getting a useful result anyway. 
So I will probably just interrupt it before long.

I know you are probably busy with other things, so understand that this matter 
is not particularly critical for me. But if you have any comments to this 
situation, I would gladly hear about them.

Thanks and best regards
Thorkil
From andrewjwilkinsonw at gmail.com  Mon Jul 23 11:49:20 2007
From: andrewjwilkinsonw at gmail.com (andrewjwilkinsonw@gmail.com)
Date: Mon Jul 23 11:42:09 2007
Subject: [Yhc] buildbot failure in macosx_ppc_3
Message-ID: <20070723154209.15581324329@www.haskell.org>

The Buildbot has detected a new failure of macosx_ppc_3.
Full details are available at:
 http://www.indiegigs.co.uk:8010/macosx_ppc_3/builds/110

Buildbot URL: http://www.indiegigs.co.uk:8010/

Buildslave for this Build: macosxppc3

Build Reason: 
Build Source Stamp: HEAD
Blamelist: Neil Mitchell

BUILD FAILED: failed yhc

sincerely,
 -The Buildbot

From akmorris at gmail.com  Tue Jul 24 01:06:35 2007
From: akmorris at gmail.com (Alexis Morris)
Date: Tue Jul 24 00:59:25 2007
Subject: [Yhc] Still shrinking YHI for ARM7...question
Message-ID: <c2717f270707232206l1fd79cc2m6baf00381619982c@mail.gmail.com>

Hi all,

So far I've been able to build YHI under the ARM7 toolchain (with a target
size of 148KB) after making several small changes: In particular I have
removed all directory related primitive functions from Sytem.c and
WrapPrimitive, commented out threading code for locks, mutexes, and
semaphores, removed thread.c, and also removed all expensive printf
statements (can't use printf on target). Also Platform.h - #define NO_LIBFFI
and NO_LIBGMP have been selected and - #define NO_SHARED has been selected

So far this all compiles fine, and will fit into ROM but I have yet to test
it...I would like to figure out what else I can skim...I really want to be
able to run it from RAM (64KB) eventually.

My question at the moment is whether I can remove stuff like pretty.c, and
sanity.c (and possibly jonkers) without having a major breakdown of the
system.

TARGET := yhi_nxt

C_VM_SOURCES := \
    $(VM_DIR)/main.c \
    $(VM_DIR)/basepath.c \
    $(VM_DIR)/foreign.c \
    $(VM_DIR)/heap.c \
    $(VM_DIR)/info.c \
    $(VM_DIR)/iofuncs.c \
    $(VM_DIR)/mark.c \
    $(VM_DIR)/mutator.c \
    $(VM_DIR)/primitive.c \
    $(VM_DIR)/profile.c \
    $(VM_DIR)/stable.c \
    $(VM_DIR)/external.c \
    $(VM_DIR)/hashtable.c \
    $(VM_DIR)/hsffi.c \
    $(VM_DIR)/integer.c \
    $(VM_DIR)/jonkers.c \
    $(VM_DIR)/make.c \
    $(VM_DIR)/module.c \
    $(VM_DIR)/pretty.c \
    $(VM_DIR)/process.c \
    $(VM_DIR)/sanity.c \
    $(VM_DIR)/stopcopy.c \
    $(VM_DIR)/Array.c \
    $(VM_DIR)/Concurrent.c \
    $(VM_DIR)/FFI.c \
    $(VM_DIR)/IO.c \
    $(VM_DIR)/IORef.c \
    $(VM_DIR)/PackedString.c \
    $(VM_DIR)/Prelude.c \
    $(VM_DIR)/RuntimeAPI.c \
    $(VM_DIR)/WrapPrimitive.c \
    $(VM_DIR)/System.c \

Thanks,
-- 
</Alexis>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/yhc/attachments/20070724/6656fcd7/attachment.htm
From shackell at cs.york.ac.uk  Tue Jul 24 02:49:53 2007
From: shackell at cs.york.ac.uk (Tom Shackell)
Date: Tue Jul 24 02:42:41 2007
Subject: [Yhc] Still shrinking YHI for ARM7...question
In-Reply-To: <c2717f270707232206l1fd79cc2m6baf00381619982c@mail.gmail.com>
References: <c2717f270707232206l1fd79cc2m6baf00381619982c@mail.gmail.com>
Message-ID: <46A5A111.5000505@cs.york.ac.uk>

Hi Alexis,

Alexis Morris wrote:
> Hi all,
 > So far this all compiles fine, and will fit into ROM but I have yet to
> test it...I would like to figure out what else I can skim...I really 
> want to be able to run it from RAM (64KB) eventually.
> 
> My question at the moment is whether I can remove stuff like pretty.c, 
> and sanity.c (and possibly jonkers) without having a major breakdown of 
> the system.

>     $(VM_DIR)/profile.c \
>     $(VM_DIR)/stable.c \
>     $(VM_DIR)/pretty.c \
>     $(VM_DIR)/sanity.c \
>     $(VM_DIR)/stopcopy.c \

These should be safe to remove, indeed stopcopy isn't used at all.

>     $(VM_DIR)/Concurrent.c \
>     $(VM_DIR)/IORef.c \
>     $(VM_DIR)/PackedString.c \
>     $(VM_DIR)/RuntimeAPI.c \

These should be possible to remove, Concurrent may be a bit more tricky 
(but I think it's all optional).

 >     $(VM_DIR)/Array.c \

It is used in Numeric but you'll probably never used the function that 
uses it (hence you should be able to remove it).

>     $(VM_DIR)/WrapPrimitive.c \

You can remove any definitions made redundant by removing other things.

>     $(VM_DIR)/System.c \

Might be able to trim it down, primExitWith is essential but everything 
else is not.

You might try removing jonkers (and mark) but of course you'll lose 
garbage collection. Since you've only got a small amount of memory and 
Haskell programs allocate memory like crazy I suspect the garbage 
collector is going to be essential.

The other question is how are you loading the bytecode program? In 
standard Yhi it's loaded from the filesystem but I'm guessing the 
embedded processor doesn't have a file system? In which case I guess you 
must load it directly from memory some how. If that's true then you 
might be able to remove some of the loading code (but maybe not, depends 
on how you do it).

After that it starts getting hard to remove much more. Make sure debug 
information is not added and change gcc from "optimise for speed" to 
"optimize for size".

Hope that helps :-)


Tom
From akmorris at gmail.com  Tue Jul 24 04:13:56 2007
From: akmorris at gmail.com (Alexis Morris)
Date: Tue Jul 24 04:06:43 2007
Subject: [Yhc] Still shrinking YHI for ARM7...question
In-Reply-To: <46A5A111.5000505@cs.york.ac.uk>
References: <c2717f270707232206l1fd79cc2m6baf00381619982c@mail.gmail.com>
	<46A5A111.5000505@cs.york.ac.uk>
Message-ID: <c2717f270707240113y7d84dea3r6f85d93c02739b18@mail.gmail.com>

Hi Tom,

Thanks alot for the information. Those are great places to start. As far as
loading the bytecode goes, for now I am still looking into that, but will
have to load directly from memory, as you mentioned.

Cheers,
</Alexis>

On 7/24/07, Tom Shackell <shackell@cs.york.ac.uk> wrote:
>
> Hi Alexis,
>
> Alexis Morris wrote:
> > Hi all,
> > So far this all compiles fine, and will fit into ROM but I have yet to
> > test it...I would like to figure out what else I can skim...I really
> > want to be able to run it from RAM (64KB) eventually.
> >
> > My question at the moment is whether I can remove stuff like pretty.c,
> > and sanity.c (and possibly jonkers) without having a major breakdown of
> > the system.
>
> >     $(VM_DIR)/profile.c \
> >     $(VM_DIR)/stable.c \
> >     $(VM_DIR)/pretty.c \
> >     $(VM_DIR)/sanity.c \
> >     $(VM_DIR)/stopcopy.c \
>
> These should be safe to remove, indeed stopcopy isn't used at all.
>
> >     $(VM_DIR)/Concurrent.c \
> >     $(VM_DIR)/IORef.c \
> >     $(VM_DIR)/PackedString.c \
> >     $(VM_DIR)/RuntimeAPI.c \
>
> These should be possible to remove, Concurrent may be a bit more tricky
> (but I think it's all optional).
>
> >     $(VM_DIR)/Array.c \
>
> It is used in Numeric but you'll probably never used the function that
> uses it (hence you should be able to remove it).
>
> >     $(VM_DIR)/WrapPrimitive.c \
>
> You can remove any definitions made redundant by removing other things.
>
> >     $(VM_DIR)/System.c \
>
> Might be able to trim it down, primExitWith is essential but everything
> else is not.
>
> You might try removing jonkers (and mark) but of course you'll lose
> garbage collection. Since you've only got a small amount of memory and
> Haskell programs allocate memory like crazy I suspect the garbage
> collector is going to be essential.
>
> The other question is how are you loading the bytecode program? In
> standard Yhi it's loaded from the filesystem but I'm guessing the
> embedded processor doesn't have a file system? In which case I guess you
> must load it directly from memory some how. If that's true then you
> might be able to remove some of the loading code (but maybe not, depends
> on how you do it).
>
> After that it starts getting hard to remove much more. Make sure debug
> information is not added and change gcc from "optimise for speed" to
> "optimize for size".
>
> Hope that helps :-)
>
>
> Tom
>



-- 
</Alexis>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/yhc/attachments/20070724/98b81ae3/attachment.htm
From shackell at cs.york.ac.uk  Tue Jul 24 09:21:15 2007
From: shackell at cs.york.ac.uk (Thomas Shackell)
Date: Tue Jul 24 09:14:54 2007
Subject: [Yhc] Still shrinking YHI for ARM7...question
In-Reply-To: <c2717f270707240113y7d84dea3r6f85d93c02739b18@mail.gmail.com>
References: <c2717f270707232206l1fd79cc2m6baf00381619982c@mail.gmail.com>	
	<46A5A111.5000505@cs.york.ac.uk>
	<c2717f270707240113y7d84dea3r6f85d93c02739b18@mail.gmail.com>
Message-ID: <46A5FCCB.6000306@cs.york.ac.uk>

Alexis Morris wrote:
> Hi Tom,
> 
> Thanks alot for the information. Those are great places to start. As far 
> as loading the bytecode goes, for now I am still looking into that, but 
> will have to load directly from memory, as you mentioned.
> 
> Cheers,
> </Alexis>

Hmm yes the bytecode loading is going to be tricky I suspect ...

You could just convert the bytecode files into C source code 
representations and then load them using the module loader as usual. The 
disadvantage of this is it's a bit space inefficient. You use the static 
memory for the bytecode files and then the bytecode loader will load 
those into dynamic memory.

The method I would recommend would be to split yhi into two parts: the 
part that loads the bytecode from the file and the part that runs the 
bytecode. Essentially your 'loader' program would load the bytecode from 
the file into memory and then output that data as C source code. That C 
source code could then be compiled and linked in with the main 
interpreter (this is actually similar to how nhc98 does it).

This is rather involved and it depends on quite a bit of knowledge of 
how Yhc works internally, so I'll describe how I'd do it in detail. 
You'll have to bear with me if I go over stuff you're already familiar 
with. Also if you have your own ideas and don't want to do it this way 
that's great too :-)

I suggest you read http://haskell.org/haskellwiki/Yhc/RTS/Heap if you 
haven't already as that describes the heap layout of Yhc. Essentially 
the idea is to take the nodes loaded into the heap by the loader and 
convert them into C source code that does the same thing.

Ok lets start in main.c:init

/* initialize program */
void init(char* mainMod, Node** mainFunc, Node** _toplevel,
	  FInfo** _driver){
   /* inits */
   sanity_init();
   heap_init(G_options.heapSize);
#ifdef HAT
   hgm_init(mainMod);
#endif
   mod_init();

   /* load all globals */
   initGlobals(mainMod, mainFunc, _toplevel, _driver);

   /* initialize the threads system */
   yhi_thread_init();
   hsffi_init();

   /* finished with the module system now */
   /* mod_exit(); ... not any more, now we still need it! */
}

After calling 'initGlobals' all the modules are stored in the G_modules 
hashtable in modules.c. You can walk over this hashtable to get a list 
of all module objects, with something like:

   void process_modules(){
     for (int i = 0; i < G_modules->size; i++){
       for (HashLink* p = G_modules->table[i]; p; p = p->next){
         Module* mod = (Module*)p->value;
         process_module(mod);
       }
     }
   }

Then you need to process the Objects in each module. The code to do this 
might be something like:

   void process_module(Module* mod){
     for (int i = 0; i < mod->lookup->size; i++){
       for (HashLink* p = mod->lookup->table[i]; p; p = p->next){
          ObjectRef* ref = (ObjectRef*)p->value;
          Object* obj = ref->object;
          if (!obj){
	    // then this object was known about but never actually
             // used so skip it
             continue;
          }
          process_object(mod, p->key, obj);
       }
     }

Each Object has an Info, or a Node or both.

   void process_object(Module* mod, Char* name, Object* obj){
     if (obj->info){
       process_info(mod, name, obj->info);
     }
     if (obj->node){
       process_node(mod, name, obj->node);
     }
   }

Looking in node.h we can see that an Info has a tag, this tag says what 
kind of Info this is. There are three sensible values that you will 
actually see: I_FINFO, I_XINFO and I_CINFO.

   void process_info(Module* mod, Char* name, Info* info){
     switch(info->tag){
     case I_FINFO: process_finfo(mod, name, (FInfo*)info); break;
     case I_XINFO: process_xinfo(mod, name, (XInfo*)info); break;
     case I_CINFO: process_cinfo(mod, name, (CInfo*)info); break;
     default: abort();
     }
   }

Okay so FInfo and XInfo are very similar, so much of what applies to one 
applies to the other. If we look at 
http://haskell.org/haskellwiki/Yhc/RTS/Heap we can see that an FInfo (or 
XInfo) is laid out in memory exactly as:

    +-----------------+
    | PInfo   0 / n   |            size 0, need n
    +-----------------+
    | PInfo   1 / n-1 |            size 1, need n-1
    +-----------------+
            ...
    +-----------------+
    | PInfo   n / 0   |            size n-1, need 0
    +-----------------+
    | FInfo   ....    |            function info table

i.e. The PInfos associated with that FInfo, directly followed by the 
FInfo itself. We need to generate C source code that does the same 
thing. For example for the C source code for the PInfos and FInfo for 
the Prelude.sum function might look like:

PInfo  pinfo_Prelude_sum[] = {
	(PInfo){ { P_INFO }, 0, 1 },
	(PInfo){ { P_INFO }, 1, 0 }
};
FInfo  finfo_Prelude_sum = ...

If my memory of C serves me correctly if we compiled and linked that 
source code it it would load them into memory consecutively (and without 
gaps).

Our function to process finfos  would thus look like

   void process_finfo(Module* mod, Char* name, FInfo* finfo){
      // process pinfos
      process_pinfos(mod, name, finfo->arity, finfo->papTable);

      // write finfo structure
      fprintf(cSrcFile, "FInfo finfo_%s_2E%s = (FInfo){\n",
		mod->name, name);

      ... write all the finfo fields
   }

Now here I've just printed the mod->name and name, but in actual fact 
you'd need to escape them first to ensure they were valid C identifiers. 
This is because the module names could contain '.' and ';'(another 
separator) and object names could refer to operators (like '+').
The escaping system used by nhc was that any non-alpha-numeric was 
converted to _XX where XX was the hexadecimal of the ASCII. 'Prelude.+' 
would thus be: Prelude__2B. I've used this system in my examples but any 
non-clashing system would do.

process_finfo would write out the FInfo structure to the C source file. 
This would mostly just follow the definition in node.h, but there are a 
few tricky items in the structure.
    - papTable: this always points to the first pinfo associated with the
                finfo (i.e. PInfo 0 / n).
    - link: just use NULL it's only used inside the GC
    - module: again use NULL, only used in the reflection API
    - name: NULL is fine again, only needed for debugging etc.
    - code: you'll need to allocate a block with the instructions in it
            like

            static Byte bytecode_Prelude_2Esum[] = { 0xA4, 0x43, ... };

            then output the pointer as &bytecode_Prelude_2Esum
    - constTable: described below

The constant table is used to allow a FInfo to access other constants 
and functions. Each item in the table is a ConstItem and has an 
associated const type, you might process the constants as

    void process_constants(Module* mod, Char* name, FInfo* finfo){
      for (int i = 0; i < finfo->numConsts; i++){
        ConstType type = finfo->constTypes[i];
        ConstItem item = finfo->constItem[i];
        if (type == CI_INFO){
          process_info_constant(mod, name, (Info*)item);
        }else if (type == CI_NODE){
          process_node_constant(mod, name, (Node*)node);
        }
      }
    }

A CI_INFO links to an Info structure of some sort, and a CI_NODE links 
to a heap node. The constant table needs to contain *links* to the 
structures in memory so you'll want your generated constant table to 
look something like:

    ConstItem consttable_Prelude_2Esum = {
       &finfo_Prelude_2E_2B, &finfo_Prelude_2Esum
    };

Fortunately you can do this because every Info that the constant will 
point to will be a FInfo, XInfo or CInfo. These all store their parent 
module and their name so you can work out what the reference to them is 
called.

Okay so that does with process_finfo. process_pinfos would be something like

    void process_pinfos(Module* mod, Char* name, Int num, PInfo* pinfos){
       fprintf(cSrcFile, "PInfo pinfo_%s_2E%s[] = {\n",
		mod->name, name);
       for (int i = 0; i < num; i++){
         fprintf(cSrcFile, "(PInfo){ { I_PINFO }, %d, %d },\n",
           pinfos[i].size, pinfos[i].need);
       }
       fprintf(cSrcFile, "};\n");
    }

process_cinfo should be easy, but process_xinfo will be hard. The 
trickiest point is the ffiFunc field.
Creating a FFIFunction structure is okay but the 'funcPtr' field in
FFIFunction (see hsffi.h) is tricky. You can't output a function pointer 
as C source so you need the name of the function as it appears in the 
runtime source code. Your best option is probably to use 
primitive.c:G_primFuncs, this maps names to function pointers. Using 
this you could do a reverse lookup from pointers to function names. In 
the vast majority of cases the name of the function in the source code 
is the same as the one in G_primFuncs. If it isn't you can change the C 
function name so it is named the same, you can just use compiler errors 
from your generated C code to get it to tell you when the names are 
different.

Okay Nodes are the next tricky point, the problem with them is that the 
garbage collector expects them to be in it's malloced heap area so if 
you allocate them in static memory it'll have a tantrum. Fortunately the 
changes to stop it having a tantrum are (I think) fairly small. In 
mark.c:mrk_isMarked, change

   if (!(p >= (Node*)G_hpStart && p < (Node*)G_hp)){
     ASSERT(p >= (Node*)G_hpStart && p < (Node*)G_hp);
   }

to

   if (!(p >= (Node*)G_hpStart && p < (Node*)G_hp)){
     return true;
   }


in mark.c:mrk_mark

   ASSERT(p >= (Node*)G_hpStart && p < (Node*)G_hp);

to

   if (!(p >= (Node*)G_hpStart && p < (Node*)G_hp)){
     return true;
   }

These two changes make the mark process ignore nodes outside the heap, 
the final one is:

jonkers.c:jonk_thread, change

   ASSERT(*p >= (Node*)G_hpStart && *p <= (Node*)G_hp);

to

  if (!(*p >= (Node*)G_hpStart && *p <= (Node*)G_hp)){
    return;
  }

Now hopefully that should work but the GC is a bit temperamental, so if 
you can't get it to work then you could try loading the nodes into the 
heap in a pre-processing pass.

As for how to name the generated nodes, I would suggest just using the 
printed hexadecimal of the pointer. i.e. a Node* might be

   Node node_0x34a82b = ...

The extra complication is 'unusual nodes' such as INode, LongNode,
FloatNode, DoubleNode, StringNode. Fortunately you can tell when you've 
got one of these by looking at the infos in primitive.h. INode's always 
have the info &G_infoInt, FloatNodes always &G_infoFloat, etc. You can 
test the info of the node you've got an generate the right one.

   void process_node(Node* node){
      Info* info = NODE_INFO(node);
      if (info == &G_nodeInt){
        process_int_node((INode*)node);
      }else if (info == &G_nodeFloat){
        process_float_node((FloatNode*)node);
      }
      ...
      }else{
        // normal zero arg node case
        fprintf(cSrcFile, ...);
      }
   }

The only 'special' nodes you'll see are: G_infoInt, G_infoString, 
G_infoDouble, G_infoFloat and G_infoInteger.

So that's pretty evil, but I believe if you do that then you can load 
bytecode, in very small amounts of memory. I've included a little 
example of the generated C source code for two simple functions (one 
FInfo and one XInfo) ...

Enjoy ;-)


Tom

























-------------- next part --------------
/*

this is the C code code that might be generated for the Haskell source

sum :: [Int] -> Int
sum []     = 0
sum (x:xs) = x + sum xs

Of course you'd also need a header file declaring all these items (to allow cyclic definitions)

*/

// the PInfo and FInfos
PInfo pinfo_Prelude_2Esum[] = {
    (PInfo){ { I_PINFO }, 0, 1 },           // 0 arguments present, 1 remaining
    (PInfo){ { I_PINFO }, 1, 0 },           // 1 arguments present, 0 remaining
};
    
FInfo finfo_Prelude_2Esum = (FInfo){
        { I_FINFO },
        pinfo_Prelude_2Esum,                    // papTable
        NULL,                                   // link
        2,                                      // arity
        0,                                      // stack (unused)
        0x00,                                   // flags (FFL_NONE, unused for your application)
        NULL,                                   // module name (ignored)
        NULL,                                   // function name (ignored)
        23,                                     // code size in bytes
        &bytecode_Prelude_2Esum,                // pointer to code
        3,                                      // number of constants in the const table
        &ctypes_Prelude_2Esum,                  // pointer to constant types
        &ctable_Prelude_2Esum                   // constant table items
    };

// The bytecode for the function
UInt8 bytecode_Prelude_2Esum[] = { 
    0x43, 0xA2, 0x49 .... 
};

// the constant types
UByte ctypes_Prelude_2Esum[] = { C_INFO, C_INFO, C_NODE };

// the constant table
ConstItem ctable_Prelude_2Esum[] = {
    (ConstItem)&finfo_Prelude_2E_2B,          // Prelude.+
    (ConstItem)&finfo_Prelude_2Esum,          // Prelude.sum
    (ConstItem)&node_0x43A22917,            // a node representing the Int '0'
};

// the application of sum to zero arguments, this is shared since
// it is always the same.
Word node_0x45BB1934[] = { (Word)&pinfo_Prelude_2Esum[0] };

// a node representing the Int '0'
INode node_0x43A22917[] = (INode){ 
    { (Word)&G_infoInt },       // node info
    0                           // node value
};

/*

This is the C code for a primitive function, like Yhc.Primitive.primExitWith 

*/
PInfo pinfo_Yhc_2EPrimitive_2EprimExitWith[] = {
    (PInfo){ { I_PINFO }, 1, 0 },
    (PInfo){ { I_PINFO }, 0, 1 }
};

XInfo xinfo_Yhc_2EPrimitive_2EprimExitWith[] = {
    { I_XINFO },                                    // info tag
    pinfo_Yhc_2EPrimitive_2EprimExitWith,             // pap table
    NULL, 1, 0, NULL, NULL,                         // link, arity, stack, module, name
    &ffi_Yhc_2EPrimitive_2EprimExitWith
};

FFIFunction ffi_Yhc_2EPrimitive_2EprimExitWith[] = {
    CC_PRIMITIVE,                                          // calling convention (CC_PRIMITIVE for primitive)
    1,                                                     // arity
    { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,      // arg types (can be ignored)
      0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
      0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
      0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, },  
    0,                                                     // ret type (can also be ignored)
    &primExitWith,                                         // pointer to C function in builtin/System.c   
};  
// note you could save space here by trimming the FFIFunction to be the bare minimum that you need
// in particular the arg types are especially wasteful.

// indeed you could even trim the FInfo structure to remove the unneeded items: stack, flags, module and name
// (link is necessary however).








                 
From isaacdupree at charter.net  Thu Jul 26 11:42:30 2007
From: isaacdupree at charter.net (Isaac Dupree)
Date: Thu Jul 26 11:41:05 2007
Subject: [Yhc] pure-Haskell Integer implementation
Message-ID: <46A8C0E6.2030509@charter.net>

I was working on a re-implementation of the Integer type in pure Haskell 
earlier this summer, represented by [Int], thinking it might be useful 
as a less-broken alternative to GMP than using plain Int for Integer. 
The code turned out around 500-1000 lines.  It got pretty much working 
(in yhc, ghc, and hugs; according to QuickCheck comparing the results 
with native Integer anyway), though the code's still somewhat messy 
...and large Integer division seems to be sometimes slower than expected 
(maybe a strictness issue, haven't looked into it) ...although, all 
functions are fast for small values that fit in one Int.  Is anyone 
interested in more details or work on this?

(P.S. I wonder if I should ask any other mailing list than yhc's?)

Isaac
From ndmitchell at gmail.com  Thu Jul 26 12:19:04 2007
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Thu Jul 26 12:11:42 2007
Subject: [Yhc] pure-Haskell Integer implementation
In-Reply-To: <46A8C0E6.2030509@charter.net>
References: <46A8C0E6.2030509@charter.net>
Message-ID: <404396ef0707260919gf6582c0qed9710d6247e7a0d@mail.gmail.com>

Hi Isaac,

> (maybe a strictness issue, haven't looked into it) ...although, all
> functions are fast for small values that fit in one Int.  Is anyone
> interested in more details or work on this?

I am interested in the code! Yhc has the option to not build Integer's
into the compiler, which saves space, and eases libgmp porting issues.
This seems like the perfect middle ground. Perhaps you could release
it as a library to Hackage? Perhaps call it BigInt rather than
Integer, then Yhc in "no libgmp" mode can silently rename Integer ->
BigInt without it having to go into base.

> (P.S. I wonder if I should ask any other mailing list than yhc's?)

Perhaps libraries@ ?

I can envisage #ifdef NATIVE_INTEGER then primitives, else use your
Integer library.

Thanks

Neil
From naur at post11.tele.dk  Thu Jul 26 12:16:03 2007
From: naur at post11.tele.dk (Thorkil Naur)
Date: Thu Jul 26 12:12:15 2007
Subject: [Yhc] pure-Haskell Integer implementation
In-Reply-To: <46A8C0E6.2030509@charter.net>
References: <46A8C0E6.2030509@charter.net>
Message-ID: <200707261816.04249.naur@post11.tele.dk>

Hello,

On Thursday 26 July 2007 17:42, Isaac Dupree wrote:
> I was working on a re-implementation of the Integer type in pure Haskell 
> earlier this summer, represented by [Int], thinking it might be useful 
> as a less-broken alternative to GMP than using plain Int for Integer. 
> The code turned out around 500-1000 lines.  It got pretty much working 
> (in yhc, ghc, and hugs; according to QuickCheck comparing the results 
> with native Integer anyway), though the code's still somewhat messy 
> ...and large Integer division seems to be sometimes slower than expected 
> (maybe a strictness issue, haven't looked into it) ...although, all 
> functions are fast for small values that fit in one Int.  Is anyone 
> interested in more details or work on this?

More details, certainly. Work on it: Probably not, but for comparison with 
other approaches, this would be very useful.

> 
> (P.S. I wonder if I should ask any other mailing list than yhc's?)
> 
> Isaac
> _______________________________________________
> Yhc mailing list
> Yhc@haskell.org
> http://www.haskell.org/mailman/listinfo/yhc
> 

Thanks and best regards
Thorkil
From igloo at earth.li  Thu Jul 26 17:38:28 2007
From: igloo at earth.li (Ian Lynagh)
Date: Thu Jul 26 17:31:07 2007
Subject: [Yhc] Running catch on the HughesPJ prettyprinter
In-Reply-To: <200707231444.04590.naur@post11.tele.dk>
References: <200707231444.04590.naur@post11.tele.dk>
Message-ID: <20070726213828.GA17339@matrix.chaos.earth.li>

On Mon, Jul 23, 2007 at 02:43:57PM +0200, Thorkil Naur wrote:
> 
> This is fixed by changing HughesPJ.hs as follows:
> 
> > 931c931
> > <         lay1 k _ sl _ | k+sl `seq` False = undefined
> > ---
> > >         lay1 k _ sl _ | (k+sl) `seq` False = undefined
> 
> And this is, of course, rather interesting, since this type error (I cannot 
> see it as anything else) is neither detected by Hugs nor GHC. But that is a 
> matter for further work some other time.

    http://haskell.org/onlinereport/standard-prelude.html
says
    infixl 6  +, -
    infixr 0  $, $!, `seq`

so this should already parse like that. Perhaps yhc/catch is missing an
infix decl?


Thanks
Ian

From naur at post11.tele.dk  Fri Jul 27 03:12:04 2007
From: naur at post11.tele.dk (Thorkil Naur)
Date: Fri Jul 27 03:08:38 2007
Subject: [Yhc] Running catch on the HughesPJ prettyprinter
In-Reply-To: <20070726213828.GA17339@matrix.chaos.earth.li>
References: <200707231444.04590.naur@post11.tele.dk>
	<20070726213828.GA17339@matrix.chaos.earth.li>
Message-ID: <200707270912.14404.naur@post11.tele.dk>

Hello,

On Thursday 26 July 2007 23:38, Ian Lynagh wrote:
> On Mon, Jul 23, 2007 at 02:43:57PM +0200, Thorkil Naur wrote:
> > 
> > This is fixed by changing HughesPJ.hs as follows:
> > 
> > > 931c931
> > > <         lay1 k _ sl _ | k+sl `seq` False = undefined
> > > ---
> > > >         lay1 k _ sl _ | (k+sl) `seq` False = undefined
> > 
> > And this is, of course, rather interesting, since this type error (I 
cannot 
> > see it as anything else) is neither detected by Hugs nor GHC. But that is 
a 
> > matter for further work some other time.
> 
>     http://haskell.org/onlinereport/standard-prelude.html
> says
>     infixl 6  +, -
>     infixr 0  $, $!, `seq`
> 
> so this should already parse like that. Perhaps yhc/catch is missing an
> infix decl?

You are right, of course. There is now a Yhc issue that describes this problem 
(http://code.google.com/p/yhc/issues/detail?id=145).

> 
> 
> Thanks
> Ian
> 
> 

Thanks and best regards
Thorkil
From ndmitchell at gmail.com  Mon Jul 30 11:09:44 2007
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Mon Jul 30 11:02:10 2007
Subject: [Yhc] Update on Issue 143 (error in Configure)
In-Reply-To: <bcba51a0707202030l4de0e5f5r8511a962137b3e14@mail.gmail.com>
References: <bcba51a0707202030l4de0e5f5r8511a962137b3e14@mail.gmail.com>
Message-ID: <404396ef0707300809j245ce630te352f37daf0634b3@mail.gmail.com>

Dimitry,

> I made some research of the problem. I am unable to fix it: my
> knowledge of Python is extremely low.
>
> See http://code.google.com/p/yhc/issues/detail?id=143 - I put a
> comment with larger details.

I've just got a patch from kpreid which looks like it fixes something
in this area. Please retest and let me know if things are fixed.

Thanks

Neil
From andrewjwilkinsonw at gmail.com  Mon Jul 30 13:39:30 2007
From: andrewjwilkinsonw at gmail.com (andrewjwilkinsonw@gmail.com)
Date: Mon Jul 30 13:32:11 2007
Subject: [Yhc] buildbot failure in macosx_ppc_3
Message-ID: <20070730173210.469E232448E@www.haskell.org>

The Buildbot has detected a new failure of macosx_ppc_3.
Full details are available at:
 http://www.indiegigs.co.uk:8010/macosx_ppc_3/builds/112

Buildbot URL: http://www.indiegigs.co.uk:8010/

Buildslave for this Build: macosxppc3

Build Reason: 
Build Source Stamp: HEAD
Blamelist: Neil Mitchell

BUILD FAILED: failed yhc

sincerely,
 -The Buildbot

From naur at post11.tele.dk  Tue Jul 31 03:04:27 2007
From: naur at post11.tele.dk (Thorkil Naur)
Date: Tue Jul 31 02:56:42 2007
Subject: [Yhc] Update on Issue 143 (error in Configure)
In-Reply-To: <404396ef0707300809j245ce630te352f37daf0634b3@mail.gmail.com>
References: <bcba51a0707202030l4de0e5f5r8511a962137b3e14@mail.gmail.com>
	<404396ef0707300809j245ce630te352f37daf0634b3@mail.gmail.com>
Message-ID: <200707310904.28913.naur@post11.tele.dk>

Hello Neil,

On Monday 30 July 2007 17:09, Neil Mitchell wrote:
> Dimitry,
> 
> > I made some research of the problem. I am unable to fix it: my
> > knowledge of Python is extremely low.
> >
> > See http://code.google.com/p/yhc/issues/detail?id=143 - I put a
> > comment with larger details.
> 
> I've just got a patch from kpreid which looks like it fixes something
> in this area. Please retest and let me know if things are fixed.

That helped: I have built a freshly downloaded Yhc successfully. In addition, 
I cleared out my Yhc buildbot build tree and forced a rebuild and that seems 
healthy also.

> 
> Thanks
> 
> Neil
> 

Thank a lot and best regards
Thorkil
From golubovsky at gmail.com  Tue Jul 31 06:40:49 2007
From: golubovsky at gmail.com (Dimitry Golubovsky)
Date: Tue Jul 31 06:33:13 2007
Subject: [Yhc] Update on Issue 143 (error in Configure)
In-Reply-To: <200707310904.28913.naur@post11.tele.dk>
References: <bcba51a0707202030l4de0e5f5r8511a962137b3e14@mail.gmail.com>
	<404396ef0707300809j245ce630te352f37daf0634b3@mail.gmail.com>
	<200707310904.28913.naur@post11.tele.dk>
Message-ID: <bcba51a0707310340y699e65f2mf2b2b01e75991e4a@mail.gmail.com>

Hi,

> On Monday 30 July 2007 17:09, Neil Mitchell wrote:

> > I've just got a patch from kpreid which looks like it fixes something
> > in this area. Please retest and let me know if things are fixed.

This helped. Yhc built after scons fullclean.

But it still does not act properly when run without haskell sources on cmdline.

See issue 146

Thanks.

-- 
Dimitry Golubovsky

Anywhere on the Web