OpsFile hints - one more (perlish) task
Opcodes normally have a specifier that indicates, if a register is
written to or only used, e.g.
null (out PMC)
An C register gets a new value at that point, the register
allocator can reuse this register because the old contents got
discarded. This information is necessary for the register allocator.
Now we have some opcodes, that implicitely set new values on a range of
registers or silently use a register (it has to exist).
clearp # set P0..P31 to PMCNULL
poptopi # set I16..I31 from I register stack
callmethod # use existing P0, P2, S0
callmethodcc # use existing P0, P2, S0, create new P1
There are currently some hacks inside imcc[1], to handle some of these
opcodes but opcodes change faster then the code, so I'd rather have this
autogenerated from e.g.:
op clearp () :base_core,out=P0-P31
op callmethodcc :object_base,in=P0,P2,S0,I0-I4,out=P1,I0-I4
I'm not sure yet, if register stack store operations do need a hint:
pushbottomp# doesn't care if a register is valid or not
OTOH the equivalent pop definitely sets all P0..P15.
So that's part one - annotate the opsfiles.
2) is parse this information and generate bitmasks for the C
structure defined in F.
That would be something like:
int {in,out}_{I,S,P,N}_argdir; # 1 bit per register per in/out
per kind
Thanks,
leo
[1] s. imcc/instructions.c: 87 ff
Re: MMD vtable functions in bytecode
Dan Sugalski <[EMAIL PROTECTED]> wrote: > So, I'm doing these, because I need 'em, and we might as well get the > things in now. For the record, these things will be called as > functions (not methods), with three parameters, so the signature > looks like: A short question WRT implementation: shouldn't all MMD functions just use one function slot? You now seem to duplicate the whole table. When a C function is inserted, it could be a CSub[1] PMC. When a bytecode function is registered it overrides the existing (or default) slot and gets called instead. Both functions could be called by C. The invoke vtable of the function does the right thing. One further question: the C opcode is supposed to explicitely run the function, isn't it? Is it needed? Why not just do: $P0 = $P1 + $P2 # call MMD func if registerd [1] The current CSub PMC looks totally bogus and seems to be unused. S. classes/nci.pmc::invoke. The CSub should have the same invoke call. leo
Re: Behaviour of PMCs on assignment
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote: > Dan Sugalski wrote: >> This becomes a bit less efficient when we're looking at intermediate >> values of expressions. Something like: >> >>a = b + c + d >> >> turns to >> >>new $P0, SomeIntermediateType >>add $P0, b, c >>add a, $P0, d > Well...how about this: > 1. Have all vtable methods which take a dest return a PMC *. > 2. If dest is NULL, it's filled with the appropriate type before > anything else is done. *Strong NAK* :) The register allocator has to track the life span of each variable and temp. If the life of a register ends at one point, this register is reused: # a = b + c + d $P0 = $P1 + $P2 # (1] $P3 = new PerlUndef # (2) $P3 = $P0 + $P4 Let's assume that C<$P1> or C<$P2> are also temps and not reused beyond instruction (1). With that in mind $P3 is assigned to the same Parrot register as one of this temps. With the Parrot Calling Conventions we did effectively cut down the assignable register range to P16..P31 (using registers in the low range is possible but not easy). So back to your proposal: Above example could look like: $P0 = $P1 + $P2 $P3 = $P0 + $P4 Now the register allocator does of course not know, *if* the C<$P3> is C at runtime. It has to assume that it isn't. No register can be reused, the register allocator would run short of registers after very few instructions. > (I believe PMC > registers are initialized to NULL, That's a wrong assumption too. They are intially PMCNULL in @MAIN. But when you call a subroutine, the registers are just that, what they used to be in the caller. It could work, if the sequence is: $P0 = $P1 + $P2 null $P3 $P3 = $P0 + $P4 The C opcode cuts the life range of C<$P3> because of its C specifier. But now we have the runtime overhead in each such vtable method (test for PMCNULL) and one additional function argument to pass. leo
Re: Behaviour of PMCs on assignment
Dan Sugalski <[EMAIL PROTECTED]> wrote: > This becomes a bit less efficient when we're looking at intermediate > values of expressions. Something like: > a = b + c + d > turns to > new $P0, SomeIntermediateType > add $P0, b, c > add a, $P0, d > and we need to create that $P0 temp beforehand. While that's fine, it > leave things to the compiler to figure out what the intermediate type > should be, and often ends up creating two temps instead of one. Well, yes. It's up to the compiler. Perl6 would insert $P1 = new PerlUndef and Pie-Thon would have a C or such. Why should it create two temps? > Moreover, it's distinctly possible that the temp that's created isn't > the right type, as the compiler may not know what the intermediate > expression will return. The C something has to morph itself into an appropriate type IMHO. > I see three options: I think its really up to the HLL compiler to generate a suitable LHS PMC that (accompanied by appropriate assign vtables) does the right thing. To you have examples, which indicate that this isn't possible? leo
Re: Windows tinder builds
Dan Sugalski wrote: If that works better, great. The hack fix apparently didn't, at least according to the tinder builds. Had a massive think-o about the meaning of --define. The version now in CVS should work. (Tested it on my own box--had to add make, gcc, and perl to Cygwin, but it builds nicely. (I was previously just using Cygwin to get at its X server. (This message is starting to look like Lisp.))) -- Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: Behaviour of PMCs on assignment
Dan Sugalski wrote:
This becomes a bit less efficient when we're looking at intermediate
values of expressions. Something like:
a = b + c + d
turns to
new $P0, SomeIntermediateType
add $P0, b, c
add a, $P0, d
Well...how about this:
1. Have all vtable methods which take a dest return a PMC *.
2. If dest is NULL, it's filled with the appropriate type before
anything else is done.
3. At the end of the method, there's a "return dest;".
Thus, an op like add should be written like:
op add(inout PMC, in PMC, in PMC) {
$1=VTABLE_add(interpreter, $2, $3, $1); /* or whatever */
}
This does mean checking if dest == NULL at the beginning of each vtable
function, but other than that, it's fairly clean. It might even be
possible for pmc2c to insert this code automagically. (I believe PMC
registers are initialized to NULL, so it should Just Work most of the
time, and there's always the null_p op when you need to do it explicitly.)
--
Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Behaviour of PMCs on assignment
This has come up before and the discussion always semi-warnocks, but it's time to bring it up again. All the vtable operations that do PMC things are three-arg versions--they get both the args and the destination PMCs passed in. This is done specifically for speed reasons, as the assumption is that, for example, the add vtable method for a PMC represents the expression: a = b + c turns to add a, b, c in which case b's add function does the math and hand the result to a via it's set vtable function, which is fine. A has the option of overriding the assignment if that's necessary, for example if its tied to a backing store of some sort. Fine. The addition may create a temporary PMC, but there's really no way around that if we're to maintain the proper API. This becomes a bit less efficient when we're looking at intermediate values of expressions. Something like: a = b + c + d turns to new $P0, SomeIntermediateType add $P0, b, c add a, $P0, d and we need to create that $P0 temp beforehand. While that's fine, it leave things to the compiler to figure out what the intermediate type should be, and often ends up creating two temps instead of one. Moreover, it's distinctly possible that the temp that's created isn't the right type, as the compiler may not know what the intermediate expression will return. I see three options: 1) Have a version of the binary vtable methods that create the destination PMC 2) Make a universal assignment PMC that takes on the characteristics of the RHS of the assignment 3) Have a "this PMC intentionally left blank" flag to mark blank PMCs and have vtable methods check that first #1 doubles the number of vtable entries. Ick. #2 has the most overhead #3 leaves it to the vtable methods to check, which is error prone. (Though if the #2 and #3 schemes were implemented with the same PMC there'd be a good fallback) Discussion time, folks. Pointing out things I've missed wouldn't be out of line either... -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Windows tinder builds
At 9:19 PM +0100 3/26/04, Leopold Toetsch wrote:
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
Done. (Done hackishly, but done.)
A bit too hackish IMHO. The Configure --define switch can take multiple
arguments, separated by commas.
A hint equivalent could be:
Configure::Data->set {
D_inet_aton => 1
D_xxx => 1
};
both should finally expand to the same PARROT_DEF_XXX define.
If that works better, great. The hack fix apparently didn't, at least
according to the tinder builds.
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Windows tinder builds
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> Done. (Done hackishly, but done.)
A bit too hackish IMHO. The Configure --define switch can take multiple
arguments, separated by commas.
A hint equivalent could be:
Configure::Data->set {
D_inet_aton => 1
D_xxx => 1
};
both should finally expand to the same PARROT_DEF_XXX define.
leo
Re: parrot crash...
Will Coleda <[EMAIL PROTECTED]> wrote:
> #3 0x001a8c6c in Parrot_Continuation_mark (interpreter=0x923400,
> pmc=0x984588) at continuation.c:53
Seems to be dead context.
Does this help?
--- parrot/classes/continuation.pmc Mon Mar 22 13:38:09 2004
+++ parrot-leo/classes/continuation.pmc Fri Mar 26 21:04:51 2004
@@ -52,8 +52,10 @@
*/
void mark () {
+#if 0
struct Parrot_Sub * cc = (struct Parrot_Sub*)PMC_sub(SELF);
mark_context(INTERP, &cc->ctx);
+#endif
}
/*
--- parrot/classes/coroutine.pmcWed Mar 24 18:02:16 2004
+++ parrot-leo/classes/coroutine.pmcFri Mar 26 21:08:45 2004
@@ -74,7 +74,7 @@
struct Parrot_Coroutine *c = (struct Parrot_Coroutine *)PMC_sub(SELF);
mark_stack(INTERP, c->co_control_stack);
/* mark_stack(INTERP, c->co_pad_stack); */
-SUPER();/* mark rest */
+mark_context(INTERP, &c->ctx);
}
}
Languages testing
Another job for the intrepid configure and/or makefile hacker. Right now, there's a languages-test target in the top level makefile. This is good. Unfortunately, the way it works is... sub-good. What it does is do a "make test" in the languages directory, and that target runs each language test in turn. Not bad in itself, but it has two problems: 1) tinderbox clients pick up the language test as OK, even when its not. (cf the sprite/languages tinder build) 2) The language tests stop on the first language that dies hard, which at the moment is perl 6 So, what I'd like is for someone to figure a way to get all the languages test harnesses together under a single master harness, so all the languages will have their tests run all the time, and so tinderbox is happy with the results. (Get the first part done and I'll work out the tinder part--that's doable) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[CVS ci] pmc-accessors-3
I finally applied the long missing bits of a patch by Gordon Henriksen - thanks again. So the macros C and C are already history. PObj_bufstart(b) and PObj_buflen(b) is now the way to go. leo
Re: Windows tinder builds
Dan Sugalski wrote: At 7:26 PM +0100 3/26/04, Leopold Toetsch wrote: --define=inet_aton Quick hack to use inet_aton instead of inet_pton Sounds like a job for a hints file. :) Done. (Done hackishly, but done.) -- Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: Windows tinder builds
At 7:26 PM +0100 3/26/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: The cygwin build sorta kinda works OK, but the link fails because of a missing _inet_pton. I seem to remember this cropping up in the past and I thought we'd gotten it fixed, but apparently not. Kind of fixed: $ perl Configure.pl --help ... --define=inet_aton Quick hack to use inet_aton instead of inet_pton Sounds like a job for a hints file. :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Windows tinder builds
Dan Sugalski <[EMAIL PROTECTED]> wrote: > The cygwin build sorta kinda works OK, but the link fails because of > a missing _inet_pton. I seem to remember this cropping up in the past > and I thought we'd gotten it fixed, but apparently not. Kind of fixed: $ perl Configure.pl --help ... --define=inet_aton Quick hack to use inet_aton instead of inet_pton leo
Windows tinder builds
I finally figured out why the windows machine wasn't showing in the tinderbox, and fixed that. (System dates. D'oh!) We now have (again) a reliable windows machine building parrot for test, both under Cygwin and Visual Studio/.NET (though it builds a native executable there rather than a .NET one) The VS/.NET build works fine, though three of the tests fail for odd reasons. Those look like potential test harness errors. The cygwin build sorta kinda works OK, but the link fails because of a missing _inet_pton. I seem to remember this cropping up in the past and I thought we'd gotten it fixed, but apparently not. Anyway, these are set for hourly builds at half-hour offsets, so if you check in any significant changes it'd be advisable to take a look at the results. For those that don't know, all the tinderbox info is web-accessable at http://tinderbox.perl.org/tinderbox/bdshowbuild.cgi?tree=parrot -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: CPAN Upload: A/AB/ABERGMAN/ponie-2.tar.gz - Ponie Development Release 2
Leopold Toetsch wrote: >Steve Hay <[EMAIL PROTECTED]> wrote: > > >>HANDLE __stdcall WSAAsyncGetServByName(HWND hWnd, u_int wMsg, >>const char * name, >>const char * proto, >>char * buf, int obj.u._b._buflen); >> >> > > > >>In fact, just running this: >> >> > > > >>#include "parrot/parrot.h" >> >> > >#undef buflen > > > >>#include "EXTERN.h" >>#include "config.h" >>#undef HAS_OFF64_T >>#include "perl.h" >> >> > >before including perl.h should do it for now. > Thanks - that works a treat. The parrot build nearly worked OK now, but unfortunately it fell at the last hurdle: link -out:parrot.exe -nologo -nodefaultlib -debug -machine:x86 -debug imcc\main.obj blib/lib/libparrot_s.lib oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib libparrot_s.lib(perl5xpvhv.obj) : error LNK2001: unresolved external symbol __imp__win32_malloc libparrot_s.lib(perl5lv.obj) : error LNK2001: unresolved external symbol __imp__win32_malloc libparrot_s.lib(perl5av.obj) : error LNK2001: unresolved external symbol __imp__win32_malloc libparrot_s.lib(perl5xpvhv.obj) : error LNK2001: unresolved external symbol __imp__win32_abort libparrot_s.lib(perl5lv.obj) : error LNK2001: unresolved external symbol __imp__win32_abort libparrot_s.lib(perl5av.obj) : error LNK2001: unresolved external symbol __imp__win32_abort libparrot_s.lib(perl5xpvhv.obj) : error LNK2001: unresolved external symbol __imp__win32_printf libparrot_s.lib(perl5av.obj) : error LNK2001: unresolved external symbol __imp__win32_printf parrot.exe : fatal error LNK1120: 3 unresolved externals NMAKE : fatal error U1077: 'link' : return code '0x460' Stop. I've seen this sort of name munging problem on Win32 before, but I can't quite figure out what's wrong here. I think it's usually something to do with object files or libraries that were compiled using different MS C run-time libraries being linked together, but as far as I can see everything was compiled with the same options. Those options include -MD, which is correct for linking against msvcrt.lib. Any ideas what's wrong? Any Win32 gurus out there? - Steve Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: threads.t on NetBSD
Nick Kostirya <[EMAIL PROTECTED]> wrote: > I have built Parrot on NetBSD with GNU Portable Threads. > All (except SKIP) threads.t tests is successful, > BUT "interp identity" and "thread - kill". > Test "interp identity" sleep perpetual after printing ok1 and ok2. Strange. Actually no PASM thread is started here. Could you attach a debugger and look, where it hangs? > Test "thread - kill" running perpetual using 100% CPU. That's clear. The thread is spinning in this loop: lp: noop branch lp As pth(3) doesn't preempt threads, it runs forever. Please try this: lp: sleep 0.1 branch lp > Nick. leo
Re: Optimizations for Objects
At 4:34 PM +0100 3/26/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: At 6:46 PM +0100 3/17/04, Leopold Toetsch wrote: Or: after the 1st delegate lookup create a JITed stub Which is swell, except for that pesky can't-guarantee-a-JIT thing... :) I've running that now for the C<__init> call. In the absence of C<__init> the vtable function is replaced by C. When C<__init> is present a JITed function stub gets called that calls the PASM w/o method lookup. Speedup for missing C<__init> is 100%[1], with C<__init> around 10% [2] It doesn't work for superclasses' C<__init> yet though. Is it more "swell" or "pesky"? Depends on whether it requires the JIT or not. :) FWIW, I figure the way to do this fast is to have two extra slots in the class object, one for constructors and one for destructors. The class can fill 'em in at construct time, and the object constructor/destructor stuff can just walk through the list. Saves us the hassle of doing all the lookups at runtime. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: CPAN Upload: A/AB/ABERGMAN/ponie-2.tar.gz - Ponie Development Release 2
Steve Hay <[EMAIL PROTECTED]> wrote: > HANDLE __stdcall WSAAsyncGetServByName(HWND hWnd, u_int wMsg, > const char * name, > const char * proto, > char * buf, int obj.u._b._buflen); > In fact, just running this: > #include "parrot/parrot.h" #undef buflen > #include "EXTERN.h" > #include "config.h" > #undef HAS_OFF64_T > #include "perl.h" before including perl.h should do it for now. > It looks like the buflen expansion comes from this in > parrot/include/parrot/pobj.h: > /* BEGIN DEPRECATED BUFFER ACCESSORS */ Yep. > It could do with being more than just deprecated ;) Work in progress ;) leo
Re: Optimizations for Objects
Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 6:46 PM +0100 3/17/04, Leopold Toetsch wrote: >>Or: after the 1st delegate lookup create a JITed stub > Which is swell, except for that pesky can't-guarantee-a-JIT thing... :) I've running that now for the C<__init> call. In the absence of C<__init> the vtable function is replaced by C. When C<__init> is present a JITed function stub gets called that calls the PASM w/o method lookup. Speedup for missing C<__init> is 100%[1], with C<__init> around 10% [2] It doesn't work for superclasses' C<__init> yet though. Is it more "swell" or "pesky"? [1] new Px, Iclass in a loop [2] oo2.pasm bench leo
threads.t on NetBSD
I have built Parrot on NetBSD with GNU Portable Threads. All (except SKIP) threads.t tests is successful, BUT "interp identity" and "thread - kill". Test "interp identity" sleep perpetual after printing ok1 and ok2. Test "thread - kill" running perpetual using 100% CPU. Than I can help? Nick.
Re: [perl #27962] [PATCH] bad error message for split.
On Fri, Mar 26, 2004 at 09:23:25AM -0500, Dan Sugalski wrote: : At 11:01 PM -0500 3/25/04, Will Coleda wrote: : >Would a patch be accepted that let split work on non empty strings : >(not treated as REs) as a stopgap until RE support? : : Yep. Especially since we'll be revising P6 split to do that as part of its functionality anyway. We're gonna try really hard not to confuse regexes and strings in P6... Larry
Re: Safety and security
On Fri, Mar 26, 2004 at 09:26:45AM -0500, Dan Sugalski wrote: : Yup. Subroutines and methods are privilege boundaries, and code with : extra rights may call into less privileged code safely. We need to : work out the mechanism though. One thing you'll have to do in that case is disable the ability to peek outward into your dynamic scope for various tidbits, such as $CALLER::_. Larry
Re: Dependency cleanup in generated makefile
At 10:12 AM + 3/26/04, Harry Jackson wrote: Dan Sugalski wrote: I've fixed up the dependency problem in the makefile generation that was getting in the way of multithreaded makes. Shouldn't cause any problems, but it never hurts to double-check these things elsewhere. Was that were "make -jN" was failing. I tried to get this running for ages and got absolutely nowhere with it, it was like walking in a minefield. Yep. That now works for me, though it exposes some issues in the classes/ makefile. It's safe, for now, but make executes it N times for some odd reason. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Safety and security
At 2:57 PM +0100 3/26/04, James Mastros wrote: Larry Wall wrote: Do bear in mind that Perl can execute bits of code as it's compiling, so if a bit of code is untrustworthy, you shouldn't be compiling it in the first place, unless you've prescanned it to reject C, C, and other macro definitions, or (more usefully) have hooks in the compiler to catch and validate those bits of code before running them. In other words, the compiler must be sure to run immediate bits of code with the same restrictions as it would run the real code. This isn't a parrot issue per say; it's a compiler issue, and I don't see how it requires additional mechinisims for parrot, unless possibly it's running one pbc (the compiler itself) with one set of restrictions/quotas, and another bytecode segment (pbc generated during the compile) with another set. I think we were planning on that anyway (to allow libraries to be more trusted then the code that calls them, and callbacks to be less trusted). Yup. Subroutines and methods are privilege boundaries, and code with extra rights may call into less privileged code safely. We need to work out the mechanism though. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #27962] [PATCH] bad error message for split.
At 11:01 PM -0500 3/25/04, Will Coleda wrote: Would a patch be accepted that let split work on non empty strings (not treated as REs) as a stopgap until RE support? Yep. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Safety and security
Larry Wall wrote: Do bear in mind that Perl can execute bits of code as it's compiling, so if a bit of code is untrustworthy, you shouldn't be compiling it in the first place, unless you've prescanned it to reject C, C, and other macro definitions, or (more usefully) have hooks in the compiler to catch and validate those bits of code before running them. In other words, the compiler must be sure to run immediate bits of code with the same restrictions as it would run the real code. This isn't a parrot issue per say; it's a compiler issue, and I don't see how it requires additional mechinisims for parrot, unless possibly it's running one pbc (the compiler itself) with one set of restrictions/quotas, and another bytecode segment (pbc generated during the compile) with another set. I think we were planning on that anyway (to allow libraries to be more trusted then the code that calls them, and callbacks to be less trusted). -=- James Mastros
Re: parrot crash...
Ah, good call. Adding -G causes the code to complete with no crash. (This also clears the two hurdles in the test suite I mentioned elsewhere.) (debugger) - I'm not sure I can get anything more helpful out of the debugger than the crash log (with stack trace) from an earlier post - Here's the backtrace, though (when run without -G) (gdb) backtrace #0 0x0002d310 in pobject_lives (interpreter=0x923400, obj=0x) at src/dod.c:179 #1 0x001067ec in mark_pmc_register_stack (interpreter=0x923400, chunk=0x9afb80) at src/register.c:129 #2 0x0010f294 in mark_context (interpreter=0x923400, ctx=0x947350) at src/sub.c:102 #3 0x001a8c6c in Parrot_Continuation_mark (interpreter=0x923400, pmc=0x984588) at continuation.c:53 #4 0x0002e38c in mark_special (interpreter=0x923400, obj=0x984588) at src/dod.c:114 #5 0x0002d358 in pobject_lives (interpreter=0x923400, obj=0x984588) at src/dod.c:199 #6 0x0002de74 in trace_mem_block (interpreter=0x923400, lo_var_ptr=3221223824, hi_var_ptr=3221221840) at src/dod.c:889 #7 0x001946f4 in trace_system_stack (interpreter=0x923400) at src/cpu_dep.c:117 #8 0x001946ac in trace_system_areas (interpreter=0x923400) at src/cpu_dep.c:98 #9 0x0002d578 in trace_active_PMCs (interpreter=0x923400, trace_stack=1) at src/dod.c:297 #10 0x0002e04c in Parrot_do_dod_run (interpreter=0x923400, flags=1) at src/dod.c:1028 #11 0x0010aef0 in more_traceable_objects (interpreter=0x923400, pool=0x923dc0) at src/smallobject.c:110 #12 0x0010b028 in get_free_object (interpreter=0x923400, pool=0x923dc0) at src/smallobject.c:176 #13 0xef0c in get_free_pmc (interpreter=0x923400, pool=0x923dc0) at src/headers.c:53 #14 0x00029ca0 in get_new_pmc_header (interpreter=0x923400, base_type=46, constant=0) at src/pmc.c:104 #15 0x00029fd0 in pmc_new_noinit (interpreter=0x923400, base_type=46) at src/pmc.c:208 #16 0x0003af64 in Parrot_newsub_p_ic_ic (cur_opcode=0x9c61b8, interpreter=0x923400) at ops/core.ops:508 #17 0x00111ddc in runops_slow_core (interpreter=0x923400, pc=0x9c61b8) at src/runops_cores.c:146 #18 0xaa10 in runops_int (interpreter=0x923400, offset=689) at src/interpreter.c:833 #19 0xaad8 in runops_ex (interpreter=0x923400, offset=689) at src/interpreter.c:863 #20 0xad04 in runops (interpreter=0x923400, offset=689) at src/interpreter.c:935 #21 0xea20 in Parrot_runcode (interpreter=0x923400, argc=2, argv=0xbcd8) at src/embed.c:692 #22 0x378c in main (argc=2, argv=0xbcd8) at imcc/main.c:556 #23 0x1d60 in _start (argc=3, argv=0xbcd4, envp=0xbce4) at /SourceCache/Csu/Csu-45/crt.c:267 #24 0x1be0 in start () On Friday, March 26, 2004, at 03:39 AM, Leopold Toetsch wrote: Will Coleda <[EMAIL PROTECTED]> wrote: I'm still seeing both bugs, with a cvs update, make realclean; perl Configure.pl, make. (if I do a cvs diff in my repo, the only changed files are tcl related.) What other intel do you need to help duplicate the bugs? Try with -G to turn off DOD/GC. Run it in the debugger ... leo -- Will "Coke" Coledawill at coleda dot com
Re: [perl #27969] [BUG] ParrotIO crash
Leopold Toetsch <[EMAIL PROTECTED]> writes: > > Causes a crash, instead of raising an exception. > > as probably any other IO opcode. Proper error handling for IO is much > work and a lot of fun. > > Patches welcome. These were things I wanted to do quite a while ago, but then I got a new job, moved too a new town, had no connection to the internet. At the moment I work through a huge backlog of mails and try to get familar with the recent changes of the code. So don't hold your breath. bye boe -- Juergen Boemmels[EMAIL PROTECTED] 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
Re: Dependency cleanup in generated makefile
Dan Sugalski wrote: I've fixed up the dependency problem in the makefile generation that was getting in the way of multithreaded makes. Shouldn't cause any problems, but it never hurts to double-check these things elsewhere. Was that were "make -jN" was failing. I tried to get this running for ages and got absolutely nowhere with it, it was like walking in a minefield. Harry -- Regards, Harry Jackson.
Re: [perl #27969] [BUG] ParrotIO crash
Will Coleda <[EMAIL PROTECTED]> wrote: > This rather dodgy bit of code > .sub main >$S0 = read $P1, 1 >end > .end > Causes a crash, instead of raising an exception. as probably any other IO opcode. Proper error handling for IO is much work and a lot of fun. Patches welcome. leo
Re: parrot crash...
Will Coleda <[EMAIL PROTECTED]> wrote: > I'm still seeing both bugs, with a cvs update, make realclean; perl > Configure.pl, make. (if I do a cvs diff in my repo, the only changed > files are tcl related.) > What other intel do you need to help duplicate the bugs? Try with -G to turn off DOD/GC. Run it in the debugger ... leo
