andrewjwilkinsonw | 2 Aug 13:31 2006
Picon

buildbot failure in macosx_ppc

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

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

Build Reason: 
Build Source Stamp: HEAD
Blamelist: Andrew

BUILD FAILED: failed failed slave lost

sincerely,
 -The Buildbot
andrewjwilkinsonw | 2 Aug 13:33 2006
Picon

buildbot failure in macosx_ppc

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

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

Build Reason: The web-page 'force build' button was pressed by 'Andrew Wilkinson': Test latest patch

Build Source Stamp: HEAD
Blamelist: 

BUILD FAILED: failed failed slave lost

sincerely,
 -The Buildbot
Andrew Wilkinson | 2 Aug 14:33 2006
Picon

Re: Error Building on OS X

Hi Brent,

The Yhc make files are depreceated and will be removed at some point. Please try typing 'scons' to build Yhc.

Unfortunately Yhc doesn't yet build on Mac OS X, but it's not far off working and I'm hopeful it will build soon.

Regards,
Andrew Wilkinson

On 6/30/06, Brent Fulgham <bfulg <at> pacbell.net> wrote:
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?

_______________________________________________
Yhc mailing list
Yhc <at> haskell.org
http://www.haskell.org/mailman/listinfo/yhc
andrewjwilkinsonw | 2 Aug 15:03 2006
Picon

buildbot failure in macosx_ppc

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

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

Build Reason: 
Build Source Stamp: HEAD
Blamelist: Andrew

BUILD FAILED: failed failed slave lost

sincerely,
 -The Buildbot
Neil Mitchell | 2 Aug 18:18 2006
Picon

Mac issues

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
Neil Mitchell | 2 Aug 18:30 2006
Picon

Re: Mac issues

Hi

>From http://unu.novajo.ca/simple/

Specific comments and pitfalls:

   1. The thread function sem_init is not implemented on Darwin
whereas the functions sem_open/sem_close is not implemented on Linux.
That's why there is some juggling with the initialization of the
semaphores in the code.

That seems to be the reason its not working, at a point at the correct fix.

Thanks

Neil

On 8/2/06, Neil Mitchell <ndmitchell <at> gmail.com> wrote:
> 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
>
Neil Mitchell | 3 Aug 16:44 2006
Picon

Re: Can't compile

Hi Isaac,

Me and Andrew have spent some time playing, and our buildbot for Yhc
with Mac OS X PPC gets to the end, and passes almost all of the tests
(one failing, which we're still tracking down).

Could you have another go at compiling, and let us know if you are successful?

Re: separating out the build, there are some issues with that. The
main one is that its simplest if the internal functions are invoked in
exactly the same way as the external ones - this results in less
special cases and better testing for everything. But this of course
means depending on libffi for the internal functions as well.
Fortunately libffi is available almost everywhere, at least everywhere
Python is available, so isn't a major problem.

You also refer to "better memory use" compared to Lua? Given the
following graph:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=ghc

It seems that GHC has better memory use than Lua in most of the tests,
and in general Yhc has better memory use than GHC, so (taking a wild
guess), Yhc should be less memory intensive than Lua.

Thanks

Neil

> What is Yhc doing that depends on the machine architecture? Is all this
> ctypes, libffi, endianness testing, etc, just for the Haskell Foreign
> Function Interface? Maybe it would help if I understood the organization
> of these platform-specific things (if there is any yet). (speculation) :
> Maybe it would be good to separate them out into one place so that it's
> easy to see where any such thing occurs, and check that (if things need
> to be split into cases by architecture) all supported cases are covered.
>  It would be nice to be able to build the completely-portable parts of
> Yhc (i.e. everything but the FFI) without relying on anything but a
> bytecode interpreter (ANSI C compiler for usual Yhc bytecode
> interpreter, .NET, whatever). Then we could be at least as portable as
> Lua, though maybe not as memory-efficient. :) (And I could test the
> parts of Yhc that do work for me.)
>
> Isaac
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFEzjJCHgcxvIWYTTURArHvAJsGSd5EsJ4yyB+d/HRCSkh3Byd5fQCfTltZ
> 7yLuprOydmJifhELnWhLvAo=
> =WEmd
> -----END PGP SIGNATURE-----
> _______________________________________________
> Yhc mailing list
> Yhc <at> haskell.org
> http://www.haskell.org//mailman/listinfo/yhc
>
Isaac | 3 Aug 17:55 2006
Picon

Re: Can't compile


Neil Mitchell wrote:
> Hi Isaac,
> 
> Me and Andrew have spent some time playing, and our buildbot for Yhc
> with Mac OS X PPC gets to the end, and passes almost all of the tests
> (one failing, which we're still tracking down).
> 
> Could you have another go at compiling, and let us know if you are
> successful?

These things don't look quite right
(patch)
  * Assume that if we're on ppc we're running under OS X.
(gcc argument)
-DPOWERPC_DARWIN

But I got the same errors when I specifically didn't include the
suspiciously-named patches (hooray for darcs' flexibility) :

gcc -o inst/bin/yhi src/runtime/BCKernel/external.o
src/runtime/BCKernel/hashtable.o src/runtime/BCKernel/heap.o
src/runtime/BCKernel/hsffi.o src/runtime/BCKernel/info.o
src/runtime/BCKernel/integer.o src/runtime/BCKernel/iofuncs.o
src/runtime/BCKernel/jonkers.o src/runtime/BCKernel/main.o
src/runtime/BCKernel/make.o src/runtime/BCKernel/mark.o
src/runtime/BCKernel/module.o src/runtime/BCKernel/mutator.o
src/runtime/BCKernel/pretty.o src/runtime/BCKernel/primitive.o
src/runtime/BCKernel/sanity.o src/runtime/BCKernel/stopcopy.o
src/runtime/BCKernel/profile.o src/runtime/BCKernel/foreign.o
src/runtime/BCKernel/process.o src/runtime/BCKernel/thread.o
src/runtime/BCKernel/stable.o src/runtime/BCKernel/builtin/Concurrent.o
src/runtime/BCKernel/builtin/Array.o src/runtime/BCKernel/builtin/FFI.o
src/runtime/BCKernel/builtin/IO.o src/runtime/BCKernel/builtin/Prelude.o
src/runtime/BCKernel/builtin/PackedString.o
src/runtime/BCKernel/builtin/RuntimeAPI.o
src/runtime/BCKernel/builtin/System.o
depends/ctypes/libffi/src/prep_cif.o depends/ctypes/libffi/src/cfield.o
depends/ctypes/libffi/src/powerpc/ffi_darwin.o
depends/ctypes/libffi/src/powerpc/darwin.o
depends/ctypes/libffi/src/powerpc/darwin_closure.o -lgmp
src/runtime/BCKernel/external.o: In function `dll_open':
external.c:(.text+0x31c): undefined reference to `dlopen'
src/runtime/BCKernel/external.o: In function `dll_sym':
external.c:(.text+0x364): undefined reference to `dlsym'
src/runtime/BCKernel/external.o: In function `dll_error':
external.c:(.text+0x39c): undefined reference to `dlerror'
src/runtime/BCKernel/hsffi.o: In function `hsffi_call':
hsffi.c:(.text+0x5b4): undefined reference to `ffi_call'
src/runtime/BCKernel/hsffi.o: In function `hsffi_evalContext':
hsffi.c:(.text+0x67c): undefined reference to `ffi_call'
src/runtime/BCKernel/thread.o: In function `osthread_create':
thread.c:(.text+0x2b0): undefined reference to `pthread_create'
src/runtime/BCKernel/thread.o: In function `yhi_semaphore_create':
thread.c:(.text+0x4a4): undefined reference to `sem_init'
thread.c:(.text+0x51c): undefined reference to `sem_open'
thread.c:(.text+0x530): undefined reference to `sem_unlink'
src/runtime/BCKernel/thread.o: In function `yhi_semaphore_signal':
thread.c:(.text+0x5c8): undefined reference to `sem_post'
src/runtime/BCKernel/thread.o: In function `yhi_semaphore_wait':
thread.c:(.text+0x634): undefined reference to `sem_wait'
src/runtime/BCKernel/thread.o: In function `yhi_semaphore_zero':
thread.c:(.text+0x6a0): undefined reference to `sem_trywait'
src/runtime/BCKernel/thread.o: In function `yhi_semaphore_destroy':
thread.c:(.text+0x6f4): undefined reference to `sem_destroy'
thread.c:(.text+0x710): undefined reference to `sem_close'
src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatExp':
Prelude.c:(.text+0x308): undefined reference to `exp'
src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatLog':
Prelude.c:(.text+0x390): undefined reference to `log'
src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatSqrt':
Prelude.c:(.text+0x418): undefined reference to `sqrt'
src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatSin':
Prelude.c:(.text+0x4a0): undefined reference to `sin'
src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatCos':
Prelude.c:(.text+0x528): undefined reference to `cos'
src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatTan':
Prelude.c:(.text+0x5b0): undefined reference to `tan'
src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatASin':
Prelude.c:(.text+0x638): undefined reference to `asin'
src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatACos':
Prelude.c:(.text+0x6c0): undefined reference to `acos'
src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatATan':
Prelude.c:(.text+0x748): undefined reference to `atan'
src/runtime/BCKernel/builtin/Prelude.o: In function `_primFloatPow':
Prelude.c:(.text+0x810): undefined reference to `pow'
src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleExp':
Prelude.c:(.text+0xcc8): undefined reference to `exp'
src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleLog':
Prelude.c:(.text+0xd4c): undefined reference to `log'
src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleSqrt':
Prelude.c:(.text+0xdd0): undefined reference to `sqrt'
src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleSin':
Prelude.c:(.text+0xe54): undefined reference to `sin'
src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleCos':
Prelude.c:(.text+0xed8): undefined reference to `cos'
src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleTan':
Prelude.c:(.text+0xf5c): undefined reference to `tan'
src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleASin':
Prelude.c:(.text+0xfe0): undefined reference to `asin'
src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleACos':
Prelude.c:(.text+0x1064): undefined reference to `acos'
src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoubleATan':
Prelude.c:(.text+0x10e8): undefined reference to `atan'
src/runtime/BCKernel/builtin/Prelude.o: In function `_primDoublePow':
Prelude.c:(.text+0x11a8): undefined reference to `pow'
depends/ctypes/libffi/src/prep_cif.o: In function `ffi_prep_cif':
prep_cif.c:(.text+0x390): undefined reference to `ffi_prep_cif_machdep'
collect2: ld returned 1 exit status
scons: *** [inst/bin/yhi] Error 1
scons: building terminated because of errors.

Adding "m" and "dl" to the list of libraries made some of the errors go
away but I didn't know where the other references are supposed to be
defined.

Would it be simple to set up a buildbot here? If I find out how, I'll
probably do that.

> 
> Re: separating out the build, there are some issues with that. The
> main one is that its simplest if the internal functions are invoked in
> exactly the same way as the external ones - this results in less
> special cases and better testing for everything. But this of course
> means depending on libffi for the internal functions as well.
> Fortunately libffi is available almost everywhere, at least everywhere
> Python is available, so isn't a major problem.

Ok, certainly uniform testing everywhere makes sense. And it would
obviously add some complexity (and implementation work) to allow to
replace all uses of libffi with 'error "Foreign function interface
support not compiled in"', or to have it dynamically possible to be
available or not, or other "could-be-nice" variations. :)

> You also refer to "better memory use" compared to Lua? Given the
> following graph:
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=ghc
> 
> 
> It seems that GHC has better memory use than Lua in most of the tests,
> and in general Yhc has better memory use than GHC, so (taking a wild
> guess), Yhc should be less memory intensive than Lua.
> 

Interesting -- I was assuming that Lua was designed to be good at that
sort of thing (its interpreter can be quite small) -- and GHC binaries
are infamous for being big, though that will obviously not be the same
with Yhc. Perhaps Haskell's laziness makes really low memory-use easy in
some cases.... Looking at Lua's worst memory usage compared to GHC
(nsieve), it keeps a table for all the numbers up to a maximum! (while
the haskell version uses arrays and gives ghc lots of strictness to play
with) Possibly garbage collection is harder with habitual use of tables
(which go unoptimized -- lua is designed to have a simple
implementation. Hopefully it isn't ghc's ability to heavily optimize in
a way we may not be able to :).

Isaac
Neil Mitchell | 3 Aug 19:15 2006
Picon

Re: Can't compile

Hi Isaac,

> These things don't look quite right
> (patch)
>   * Assume that if we're on ppc we're running under OS X.
> (gcc argument)
> - -DPOWERPC_DARWIN
What is your processor and architecture? I'm sure you've said already
but I've forgotten :)

> Prelude.c:(.text+0x11a8): undefined reference to `pow'
> depends/ctypes/libffi/src/prep_cif.o: In function `ffi_prep_cif':
> prep_cif.c:(.text+0x390): undefined reference to `ffi_prep_cif_machdep'
> collect2: ld returned 1 exit status
> scons: *** [inst/bin/yhi] Error 1
> scons: building terminated because of errors.
I remember that Mac seems to auto link against a lot of things, so you
don't need to specify them. I guess if you are not on Mac, then you do
need to specify these. I'll leave Andrew to work out the details...

> Would it be simple to set up a buildbot here? If I find out how, I'll
> probably do that.
If you have buildbot, scons, svn and darcs installed, then setting up
buildbot is a few lines. It would be great if you could be a buildbot,
especially if you have your computer on during the day a few times,
then we can keep tweaking things til we figure out exactly whats going
on. Thats the way we've managed to get Mac PPC working, and it all
seemed very successful.

I know Andrew was going to put up on the wiki a list of instructions
to becoming a buildbot, so hopefully he can do that, and you can set
it up, and we'll get it all working.

> Ok, certainly uniform testing everywhere makes sense. And it would
> obviously add some complexity (and implementation work) to allow to
> replace all uses of libffi with 'error "Foreign function interface
> support not compiled in"', or to have it dynamically possible to be
> available or not, or other "could-be-nice" variations. :)
Personally, I think both libffi and libgmp should be optional - which
for embeded systems reduces dependancies and gives us 100% portable C
with few dependancies (since libpthreads is already defined as
optional). I might see if I can hack this up, in a nicely modular way.
It wasn't that long ago that we didn't have libffi, so the code
probably hasn't diverged that much.

I would guess a nice split is NO_THREADS, NO_FFI, NO_GMP all of which
can be set to 1 to disable them. Currently NO_THREADS is already in
there (but in a very non-modular way).

> Interesting -- I was assuming that Lua was designed to be good at that
> sort of thing (its interpreter can be quite small) -- and GHC binaries
> are infamous for being big, though that will obviously not be the same
> with Yhc. Perhaps Haskell's laziness makes really low memory-use easy in
> some cases.... Looking at Lua's worst memory usage compared to GHC
> (nsieve), it keeps a table for all the numbers up to a maximum! (while
> the haskell version uses arrays and gives ghc lots of strictness to play
> with) Possibly garbage collection is harder with habitual use of tables
> (which go unoptimized -- lua is designed to have a simple
> implementation. Hopefully it isn't ghc's ability to heavily optimize in
> a way we may not be able to :).
GHC is in general more memory heavy, but for certain things, liked
unboxed values, it has an advantage since Yhc can't unbox things. I
guess the only way to know is to run the benchmarks using Yhc :)

Thanks

Neil
Isaac | 3 Aug 19:42 2006
Picon

Re: Can't compile


Neil Mitchell wrote:
> Hi Isaac,
> 
>> These things don't look quite right
>> (patch)
>>   * Assume that if we're on ppc we're running under OS X.
>> (gcc argument)
>> - -DPOWERPC_DARWIN
> What is your processor and architecture? I'm sure you've said already
> but I've forgotten :)

powerpc linux; specifically, at the moment,
$ uname -a
Linux moa 2.6.17-gentoo-r3 #3 Mon Jul 17 06:43:18 EDT 2006 ppc 740/750
GNU/Linux

>> Would it be simple to set up a buildbot here? If I find out how, I'll
>> probably do that.
> If you have buildbot, scons, svn and darcs installed, then setting up
> buildbot is a few lines. It would be great if you could be a buildbot,
> especially if you have your computer on during the day a few times,
> then we can keep tweaking things til we figure out exactly whats going
> on. Thats the way we've managed to get Mac PPC working, and it all
> seemed very successful.
> 
> I know Andrew was going to put up on the wiki a list of instructions
> to becoming a buildbot, so hopefully he can do that, and you can set
> it up, and we'll get it all working.

Okay, first step is to install buildbot anyway. :)

Isaac

Gmane