just because it seems quiet doesn't mean that no work is happening

Right now if anyone wants to help with ponie, then there's this intermittent
segfault on exit that you might want to look into. Something, somewhere ends
up with garbage as an SV pointer that gets visited at cleanup. Stack trace
looks like this:

(gdb) where
#0  0x082238ea in Parrot_PMC_get_pointer (interp=0x845c058, pmc=0xf6d9667f)
    at src/extend.c:117
#1  0x0813e2d1 in Perl_macro_SvFLAGS (sv=0x9269980) at sv.c:1067
#2  0x0813d0ba in S_ptr_table_visit (tbl=0x84699b8, 
    f=0x813d1ac <do_clean_objs>) at sv.c:260
#3  0x0813d13b in S_visit (f=0x813d1ac <do_clean_objs>) at sv.c:280
#4  0x0813d5da in Perl_sv_clean_objs () at sv.c:368
#5  0x080b758a in perl_destruct (my_perl=0x845c048) at perl.c:406
#6  0x080b5b3e in main (argc=3, argv=0xbfffd9a4, env=0xbfffd9b4)
    at perlmain.c:88
#7  0x42017589 in __libc_start_main () from /lib/i686/libc.so.6


I'm not sure if this is actually a core perl bug, but I've never seen it
in regular perl.

I've spent the past day and bit looking at this, the failure of ODBM_File's
tests on Solaris, and coaxing all the modules in Fotango's build system
through ponie, without seeming to have a great deal to show for it. Which
is why progress can seem very slow from the outside.

Now, assuming that you *don't* want to sit grovelling around the source in
gdb (or dbx), [or don't want to simulate the experience by banging your head
against the nearest convenient wall :-)] just trying to build and test
modules against an installed ponie would be useful, and reporting here what
works, and what the compiler or test errors are when things fail.

Nicholas Clark