> ------------Original Message-------------
> From: "Clinton Pierce" <cli...@geeksalad.org>
> To: "Dan Sugalski" <d...@sidhe.org>
> Date: Fri, Jul-4-2003 4:24 PM
> Subject: Re: [ANNOUNCE] Parrot is feature-frozen until Wednesday
>
> > It crashes rather badly in a number of spots on OS X, unfortunately.
> > I've also noticed that we have no Win32 systems in the tinderbox. Are
> > we building OK on Win32 anywhere?
>
> I don't have a stable/spare Win32 box to donate as tinder... but.
>
> Win32 build seems okay as of last night. One eye-catching error at the end of the build is:
>
> link -out:imcc.exe -nologo -nodefaultlib -release -machine:x86 imcparser.obj imcl
> exer.obj imc.obj stacks.obj symreg.obj instructions.obj cfg.obj sets.obj debug.obj optimiz
> er.obj pbc.obj main.obj parser_util.obj jit.obj ../../blib/lib/libparrot_s.lib oldnames.lib
> kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.l
> ib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib o
> dbccp32.lib msvcrt.lib
> # the chmod doesn't work here, so move imcc and make it again :-(
> '#' is not recognized as an internal or external command,
> operable program or batch file.
> NMAKE : fatal error U1077: '#' : return code '0x1'
> Stop.
>
> But everything else *looks* okay.
>
> Some tests fail though. The summary is:
>
> Failed Test Status Wstat Total Fail Failed List of Failed
> --------------------------------------------------------------------------------
> t/op/stacks.t 2 512 43 2 4.65% 3, 6
> t/pmc/intlist.t 1 256 9 1 11.11% 6
> t/pmc/io.t 2 512 4 2 50.00% 3-4
> t/pmc/nci.t 4 1024 10 4 40.00% 2, 6, 8, 10
> t/src/manifest.t 3 768 4 3 75.00% 2-4
> t/src/sprintf.t 1 256 2 1 50.00% 2
> 10 subtests skipped.
> Failed 6/49 test scripts, 87.76% okay. 13/751 subtests failed, 98.27% okay.
> NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0xff'
> Stop.
>
> Given today's off-and-on power situation in Southeast Michigan, I have no tuits round or otherwise to dive in futher.
>
>
I must somehow have missed this announce. But anyway, I'd like to have
the IO-subsystem fixed, before a release is done.
Are there any patches under construction currently?
I think, putting the IO PMCs into the ParrotIOTable would do it for now.
leo
> Clinton Pierce <cli...@geeksalad.org> wrote:
> >> Subject: Re: [ANNOUNCE] Parrot is feature-frozen until Wednesday
>
> I must somehow have missed this announce.
Me too.
> But anyway, I'd like to have
> the IO-subsystem fixed, before a release is done.
Yes, but its a combination of IO-subsystem/Memory-Managment. The
IO-subsystem is just a very good trigger for this kind of problems
because its the first PMC that uses timely destruction.
> Are there any patches under construction currently?
At the moment I have just a patch under construction to remove the
INTVAL Filehandles like print I0, P0. Don't know if we want to keep
this ops around for the next release.
> I think, putting the IO PMCs into the ParrotIOTable would do it for now.
I tried something like this in the first versions of my ParrotIO->PMC
transition. It turn out that the memory system is not initialized when
the IO-system opens its file-descriptors. So I used a PIO_F_SHARED
hack to prevent the standard ios from getting closed. Maybe its better
to just change the initialisation of the memory system before the
IO-system, but this might have impact on the whole memory subsystem.
It turns out that memory and the IO-system are much more coupled than
it first seems.
bye
boe
--
Juergen Boemmels boem...@physik.uni-kl.de
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
> At the moment I have just a patch under construction to remove the
> INTVAL Filehandles like print I0, P0. Don't know if we want to keep
> this ops around for the next release.
These ops are redundant, when all io ops are PMC based. We probably need
just 2 opcodes that translate fd's to PMCs and vv to be abled to pass
fd's on to C library functions.
>> I think, putting the IO PMCs into the ParrotIOTable would do it for now.
> I tried something like this in the first versions of my ParrotIO->PMC
> transition. It turn out that the memory system is not initialized when
> the IO-system opens its file-descriptors. So I used a PIO_F_SHARED
> hack to prevent the standard ios from getting closed. Maybe its better
> to just change the initialisation of the memory system before the
> IO-system, but this might have impact on the whole memory subsystem.
Ah. yes. I think, we can change init/deinit order. What we need is a
PIO_eprintf() that can be used early in interpreter startup, when IO and
or memory subsystems are not running yet. But we have this already, so I
don't see a problem here.
Then we could initialize the memory subsystem and then IO. So the IO
subsystem could e.g. use a list instead of the table.
> It turns out that memory and the IO-system are much more coupled than
> it first seems.
Yes. As there are major changes necessary to repair it really, we can
for now just leave it as it is.
> bye
> boe
leo
Me three. Which is unfortunate, considering I made it.
Clinton Pierce appears to have somehow dug up an old email message
from soon before 0.0.10 was frozen. There is no freeze now or in the
near future -- much too much stuff in flux right now. Although as I
mentioned before, I regard the imcc/parrot integration as very worthy
of a new release, so I probably will want to make one before too long.
Given that both objects and exceptions might conceivably be in a
usable state before too long, it might even be 0.1.0 instead of
0.0.11.