- Yhc - Haskell.org

BOOM!!!!!
by Thomas Davie 14 Aug '06

14 Aug '06

gcc -o depends/ctypes/libffi/src/x86/ffi.o -c -DX86 -Wall -I. -I/usr/ local/include -Idepends/ctypes/libffi/include -Idepends/ctypes/libffi/ src/x86 -Idepends/ctypes/libffi/include -Idepends/ctypes/libffi/src/ x86 -Idepends/ctypes/libffi depends/ctypes/libffi/src/x86/ffi.c depends/ctypes/libffi/src/x86/ffi.c: In function 'ffi_prep_args': depends/ctypes/libffi/src/x86/ffi.c:108: warning: implicit declaration of function 'bcopy' depends/ctypes/libffi/src/x86/ffi.c:108: warning: incompatible implicit declaration of built-in function 'bcopy' depends/ctypes/libffi/src/x86/ffi.c: In function 'ffi_prep_args_raw': depends/ctypes/libffi/src/x86/ffi.c:395: warning: incompatible implicit declaration of built-in function 'bcopy' gcc -I. -I/usr/local/include -Idepends/ctypes/libffi/include - Idepends/ctypes/libffi/src/x86 -Idepends/ctypes/libffi/include - Idepends/ctypes/libffi/src/x86 -Idepends/ctypes/libffi -c -o depends/ ctypes/libffi/src/x86/sysv.o depends/ctypes/libffi/src/x86/sysv.S depends/ctypes/libffi/src/x86/sysv.S:38:Unknown pseudo-op: .type depends/ctypes/libffi/src/x86/sysv.S:38:Rest of line ignored. 1st junk character valued 102 (f). depends/ctypes/libffi/src/x86/sysv.S:131:Unknown pseudo-op: .size depends/ctypes/libffi/src/x86/sysv.S:131:Rest of line ignored. 1st junk character valued 102 (f). depends/ctypes/libffi/src/x86/sysv.S:136:Unknown pseudo-op: .type depends/ctypes/libffi/src/x86/sysv.S:136:Rest of line ignored. 1st junk character valued 102 (f). depends/ctypes/libffi/src/x86/sysv.S:158:Missing operand value assumed absolute 0. depends/ctypes/libffi/src/x86/sysv.S:158:junk `[.-1b]' after expression depends/ctypes/libffi/src/x86/sysv.S:159:junk `@PLT' after expression depends/ctypes/libffi/src/x86/sysv.S:194:Unknown pseudo-op: .size depends/ctypes/libffi/src/x86/sysv.S:194:Rest of line ignored. 1st junk character valued 102 (f). depends/ctypes/libffi/src/x86/sysv.S:206:Unknown pseudo-op: .type depends/ctypes/libffi/src/x86/sysv.S:206:Rest of line ignored. 1st junk character valued 102 (f). depends/ctypes/libffi/src/x86/sysv.S:259:Unknown pseudo-op: .size depends/ctypes/libffi/src/x86/sysv.S:259:Rest of line ignored. 1st junk character valued 102 (f). depends/ctypes/libffi/src/x86/sysv.S:262:unknown section type: @progbits depends/ctypes/libffi/src/x86/sysv.S:262:Rest of line ignored. 1st junk character valued 46 (.). scons: *** [depends/ctypes/libffi/src/x86/sysv.o] Error 1 scons: building terminated because of errors. this is not a system V machine! this is an x86-darwin machine. Bob

2 1

Buildbot setup
by Thomas Davie 13 Aug '06

13 Aug '06

Hi, Can I get two buldbot username and passwords One should be tatd2/pass and will have ppc-darwin and i386-darwin machines building. The other should be twig/pass and will have centos-i386 building. Bob

1 0

Re: [Yhc] Problem building on Mac OS X
by Brent Fulgham 13 Aug '06

13 Aug '06

On Jul 2, 2006, at 10:20 PM, Goetz Isenmann wrote: >> File "./build/tools/haskell.py", line 163: >> haskellLibrary = SCons.Builder.Builder(action = >> SCons.Defaults.ArAction, >> Chaz:~/Projects/Yhc/yhc-devel brent$ > > I had to change > > { > hunk ./build/tools/haskell.py 163 > - haskellLibrary = SCons.Builder.Builder(action = > SCons.Defaults.ArAction, > + haskellLibrary = SCons.Builder.Builder(action = > SCons.Action.Action("$ARCOM"), > } > > to build with scons 0.96.92 (on freebsd). > -- > Goetz Isenmann Thank you -- this helped quite a bit. I did get a bit further: ghc -i./src/compiler98 -idepends/cpphs -c depends/cpphs/Text/ ParserCombinators/HuttonMeijer.hs -o depends/cpphs/Text/ ParserCombinators/HuttonMeijer.o Getting dependencies for src/compiler98/Bind.hs. An error ocurred running `ghc -M -optdep-f -optdepsrc/ compiler98/.Bind.hs.dep src/compiler98/Bind.hs`: >Could not find module `RenameLib': > use -v to see a list of the files searched for > (imported from src/compiler98/Bind.hs) > Dependencies will not be calculated. ghc -i./src/compiler98 -idepends/cpphs -c src/compiler98/Bind.hs -o src/compiler98/Bind.o src/compiler98/Bind.hs:11:0: Failed to load interface for `State': Could not find module `State': use -v to see a list of the files searched for scons: *** [src/compiler98/Bind.o] Error 1 scons: building terminated because of errors. Chaz:~/Projects/Yhc/yhc-devel brent$ ======= Details: Chaz:~/Projects/Yhc/yhc-devel brent$ ghc -v Glasgow Haskell Compiler, Version 6.4.2, for Haskell 98, compiled by GHC version 6.4.2 Using package config file: /opt/local/lib/ghc-6.4.2/package.conf Using package config file: /Users/brent/.ghc/powerpc-darwin-6.4.2/ package.conf Hsc static flags: -static *** Deleting temp files Deleting: ghc-6.4.2: no input files Usage: For basic information, try the `--help' option. Chaz:~/Projects/Yhc/yhc-devel brent$

2 1

Linux PowerPC Buildbot slave set up
by Isaac 12 Aug '06

12 Aug '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I decided to run the buildbot in a chroot (bind-mounting required directories like /bin, /usr, and so on) to give my system (now Ubuntu "Dapper Drake" on my old G3 powerpc) a bit of protection, and that seems to be working. Soon after getting the buildbot working, though, and with GHC plugging away at Yhc's code, my machine decided to lock up. Gkrellm is great, I can see green cpu usage for "nice" processes (such as I made the buildbot slave), and I saw that I had about 200 megabytes of swap usage at that point. Well I'm not giving up, just warning that my computer seems a bit unreliable! :) (plus, can't wait till Yhc can compile itself for doubled testing and lower resource usage (hmm, proper testing shouldn't start with an old alpha version, but self-compilation and using the self-compiled version to get the exact same results[1] should be a good test in general) ... or could a standard way to use hugs be set up perhaps, rather than necessarily doing the testing using the resource-hungry ghc?) Isaac [1] Unfortunately compilation isn't always necessarily referentially transparent, particularly when date-of-compilation preprocessor symbols are used. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE3K1WHgcxvIWYTTURAkLyAJ9Hu9LJgQdUyqXG/4YHnV9mlKtjBgCgkOFs kSUGGJOnfpE9mOMaFwpWzOE= =NBu9 -----END PGP SIGNATURE-----

2 1

Re: [Yhc] Can't compile
by Neil Mitchell 10 Aug '06

10 Aug '06

Hi Isaac, Your message wasn't sent to the mailing list as well, just me, so I'm forwarding it. Gmail makes it pretty easy to figure out whats happening, but I still don't understand why :) If you can find any docs on mailman that should describe how/why things are working. I have also sent it to our build engineer who will hopefully solve your problem :) Thanks Neil > > We've made some tweaks to Yhc, so it might work for you, if it doesn't > > email us again with lots of exclamation marks :) > > If something goes wrong I have a habit of cleanly starting the process > from the beginning: > > darcs get http://www.cs.york.ac.uk/fp/darcs/yhc-devel > cd yhc-devel > scons > > ... > gcc -Wall -I. -Idepends/ctypes/libffi/include > - -Idepends/ctypes/libffi/src/x86 -Idepends/ctypes/libffi/include > - -Idepends/ctypes/libffi/src/powerpc -Idepends/ctypes/libffi -c -o > depends/ctypes/libffi/src/cfield.o depends/ctypes/libffi/src/cfield.c > In file included from depends/ctypes/libffi/include/ffi.h:63, > from depends/ctypes/libffi/src/cfield.c:1: > depends/ctypes/libffi/src/x86/ffitarget.h:64: error: 'FFI_DEFAULT_ABI' > undeclared here (not in a function) > scons: *** [depends/ctypes/libffi/src/cfield.o] Error 1 > scons: building terminated because of errors. > > > !!!!!!!!!!!!!!!!!! ;-) > This bit seemingly shouldn't be there: -Idepends/ctypes/libffi/src/x86 > > By the way, I'm in the middle of upgrading my system to gcc 4.1.1 and > glibc 2.4. That doesn't look relevant here though. Also, I removed the > useless old strange Gentoo libffi installation (by emerge --unmerge), so > that definitely shouldn't be messing anything up now. > > Isaac > > P.S. the way mailing lists work is confusing me: my best guess is that I > should be using "Reply [to] all" but I can't predict the results of that > (e.g. was this message sent to the mailing list? I hope so.... and how > can I tell if a message I receive was actually sent to the list) I > haven't succeeded in finding any sort of "howto use mailing lists" on > the web... surely there must be help somewhere for innocent little > Thunderbird users who don't know how these things are supposed to work? > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFEyj0gHgcxvIWYTTURAtQYAJ9LSRNv8UygQ7W37OxcztpCC0dwxgCcDWHp > hNHKm/XpjHTB4pdaF2EFG7I= > =GPal > -----END PGP SIGNATURE----- >

3 17

build failure on FreeBSD 6.1
by David Frech 09 Aug '06

09 Aug '06

Folks - I tried this a week ago and it got farther, but the problem is the same: the configure script doesn't look in /usr/local/include for gmp.h etc. And it calls uname with funny options too. Here is the build output: [david@stubb ~/yhc-devel]$ scons scons: Reading SConscript files ... Checking for architecture... x86 Checking for operating system... uname: illegal option -- o usage: uname [-aimnprsv] Checking for Scons binary... "/usr/local/bin/scons" Checking for Scons version... Found version 0.96.1.D001. Checking for Darcs binary... "/usr/local/bin/darcs" Checking for Darcs version... Found version 1.0.5 (release) . Checking for Subversion binary... "/usr/local/bin/svn" Checking for Subversion version... Found version 1.3.0. Checking for GHC binary... "/usr/local/bin/ghc" Checking for GHC version 6.4.1 or later... Found version 6.4.1. Checking for C header file gmp.h... no Error. libgmp must be installed and gmp.h made accessible before you can compile Yhc. [david@stubb ~/yhc-devel]$ locate gmp.h /home/david/Haskell/ghc-6.4.1/ghc/includes/gmp.h /home/david/Haskell/ghc-6.4.1/ghc/rts/gmp/gmp.h /home/david/yhc-devel/_darcs/current/src/runtime/BCKernel/msvc/gmp/gmp.h /home/david/yhc-devel/src/runtime/BCKernel/msvc/gmp/gmp.h /usr/include/netinet/igmp.h /usr/local/include/gmp.h /usr/local/lib/ghc-6.4.1/include/gmp.h /usr/obj/usr/src/tmp/usr/include/netinet/igmp.h /usr/src/sys/netinet/igmp.h Cheers, - David -- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw

2 4

some ideas for revamping numeric bytecodes
by Robert Dockins 07 Aug '06

07 Aug '06

Hello, A few weeks ago I was thinking about the strange situation with Yhc's numeric primitives. Some of them are in the bytecode set, and some are handled through the FFI (at least I think that's what's happening). Thinking about it led me to decide it would be better to somehow represent all the numeric primitives as bytecode operations. So, I wrote up a proposal. Anyone who is interested can check it out at: http://haskell.org/haskellwiki/Image:Num-bytecodes.txt The ideas are about 3/4 baked (which is to say, somewhat more than half-baked ;-) ) I think the integer stuff is pretty good, and the floating point is OK. I'm less sure about the pointer stuff. At any rate, I thought I'd share the proposal so it doesn't become completely lost in the dark recesses of my home directory. Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

2 2

Haskell Int{8,16,32...} types, config.h
by Isaac 07 Aug '06

07 Aug '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I decided to look in the generated "config.h" file to see what was there. Some of it seems like it could be improved. /* first of all get constants for Int8, Int16, Int32, etc ... */ #if SIZEOF_CHAR == 1 # define INT8_TYPE char #else # error "can't find type matching int8" #endif #if SIZEOF_SHORT == 2 # define INT16_TYPE short #else # error "can't find type matching int16" #endif and so on. These are not as portable as they could be. A C standard defines headers that have int8_t, uint8_t, int16_t, uint16_t, and so on. These types are guaranteed by the standard, no matter what sizes "short", "int", and so on are. This is potentially more portable across architectures, but potentially less portable across compilers: C99 defines these headers (both <inttypes.h> and <stdint.h>, but inttypes.h is a superset including stuff we don't need to include). GCC has supported these headers since a long time, but I don't know about other compilers. Using these would also require getting rid of the hack of using macros and attaching "unsigned" to get the unsigned version -- rather, the uintN_t version can be used. If the headers are not available enough yet among C compilers, the configuration could still use them "if possible". Furthermore, since the only use (according to grep ;-)) of testing to find out the size of various C types is in these #if SIZEOF_SHORT, etc., all those configuration tests would not need to be done if stdint.h or inttypes.h was available. If we need to know the exact sizes of floating-point types, however, we are out of luck using this route -- these are "int" headers only. Do we need to do anything with floating-point types but distinguish "float" and "double"? It seems both C and Haskell only offer those two named types (well, C also has "long double" which we already ignore), and Haskell numeric literals are always Integer or Rational, not fundamentally floating-point, so the size of the floating-point types shouldn't affect the bytecode(?) (and sizeof(float) and sizeof(double) can be used if the size of memory to allocate is needed in some place in the interpreter, and various weird properties of floats and doubles can be found in the C89 <float.h>, or perhaps other places, if needed) Regards, Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE0l87HgcxvIWYTTURAuCfAJ4gcFIHZWZWJvVs2HATQb7dNRRghACfWYi+ cHmpGdme96q5ENSYD7zE/cE= =QLC+ -----END PGP SIGNATURE-----

4 6

Error Building on OS X
by Brent Fulgham 03 Aug '06

03 Aug '06

I just grabbed the sources from SVN today, and attempted to build. It failed with the attached errors. I was wondering if anyone else had successfully built under OS X? Thanks, -Brent ========= Build Log ============= make -C BCKernel gcc -g -o ../../../inst/bin/yhi obj/hashtable.o obj/module.o obj/ iofuncs.o obj/main.o obj/primitive.o obj/pretty.o obj/heap.o obj/ mutator.o obj/integer.o obj/mark.o obj/jonkers.o obj/sanity.o obj/ external.o obj/info.o obj/make.o obj/foreign.o obj/process.o obj/ thread.o obj/ffi.o obj/stable.o obj/Prelude.o obj/IO.o obj/FFI.o obj/ System.o obj/PackedString.o obj/Concurrent.o obj/Array.o -lm - lpthread -ldl -lgmp ../libffi/.libs/libffi.a /usr/bin/ld: multiple definitions of symbol _hsffi_call obj/ffi.o definition of _hsffi_call in section (__TEXT,__text) obj/FFI.o definition of _hsffi_call in section (__TEXT,__text) /usr/bin/ld: multiple definitions of symbol _hsffi_finalizeAllWaiting obj/ffi.o definition of _hsffi_finalizeAllWaiting in section (__TEXT,__text) obj/FFI.o definition of _hsffi_finalizeAllWaiting in section (__TEXT,__text) /usr/bin/ld: multiple definitions of symbol _hsffi_init obj/ffi.o definition of _hsffi_init in section (__TEXT,__text) obj/FFI.o definition of _hsffi_init in section (__TEXT,__text) /usr/bin/ld: multiple definitions of symbol _hsffi_loadExternal obj/ffi.o definition of _hsffi_loadExternal in section (__TEXT,__text) obj/FFI.o definition of _hsffi_loadExternal in section (__TEXT,__text) /usr/bin/ld: multiple definitions of symbol _hsffi_waitForFFI obj/ffi.o definition of _hsffi_waitForFFI in section (__TEXT,__text) obj/FFI.o definition of _hsffi_waitForFFI in section (__TEXT,__text) /usr/bin/ld: can't locate file for: -lgmp collect2: ld returned 1 exit status make[2]: *** [../../../inst/bin/yhi] Error 1 make[1]: *** [kernel] Error 2 make: *** [runtime] Error 2

3 2

Mac issues
by Neil Mitchell 02 Aug '06

02 Aug '06

Hi, I've been trying to debug the mac ppc, which fails with: src/runtime/BCKernel/thread.c:126: failed assertion `rval==0' The reason is that sem_init returns -1, to indicate error, and an error number that indicates ENOSYS: The function sem_init() is not supported by this implementation. See http://www.opengroup.org/onlinepubs/007908799/xsh/sem_init.html for more details. Of course, I have no idea why sem_init isn't supported, or why its required for a non-threading example, or anything else - just this might help someone else debug this error. Thanks Neil

1 1