Re: Segfault on Win32, the
Vladimir Lipsky <[EMAIL PROTECTED]> wrote: > Some time ago I mentioned I'd been gettin' one more segfault while the > Parrot debug mode was on. In fact, it proved to be an effect of the > same cause -- we have global resources sharable among interpreters, > that we try to free more than once. This time it's encoding_array. If > you're going to disable the encoding_array freeing for now, just make > sure you disable the chartype_array one either. Did you recheck that after my fix to vtable freeing? My patch covered encoding and chartype too. > 0x4C56 leo
Re: Segfault on Win32, the
From: "Leopold Toetsch" <[EMAIL PROTECTED]> > Did you recheck that after my fix to vtable freeing? My patch covered > encoding and chartype too. No, I didn't. Did you fix the Parrot_loadbc function name? If didn't, I'll have a go for Parrot_set_PackFile() > leo 0x4C56 Happy .~. /V\ // \\ /( )\ ^`~'^ 2004 keeps comin'
Re: get_pmc_keyed() in PerlString?
At 9:04 PM +0100 12/2/03, Sterling Hughes wrote: Hey, I'm right now looking at getting a proper implementation of array/string offsets done for the PHP compiler. Here's the problem, in PHP you can access indices of both string's an array's in the same way, meaning: [Snip PHP treating strings as character arrays] To have this available easily using Perl's types, get_pmc_keyed() would need to be implemented in the PerlString PMC. Currently (for the sake of nice looking mandelbrot demos), we just assume is a native string and do the offset from that string (which parrot/imc does support.) Should PerlString support a get_pmc_keyed() method (according to Perl 5/6 semantics), or is this a point where its about time to start implementing our own PMCs? This... could be a problem. Perl, using a perl string as an array, should treat it as a symbolic reference if that's enabled. And, strictly speaking, if PHP is handed a PerlInteger it ought to treat it the same way as a PerlString. Or not, but it'd be reasonable as they're really facets of the same base type. I can see a number of solutions here, some of which involve compiler hackery. The thing that first springs to mind is to have the PHP compiler emit a check of some sort before use, and either do array access or substring access. That's got a certain appeal to it, as it means we don't have to do anything. :) (Well, not true--we have to provide sufficient easily queryable metadata to tell if a variable is more or less an array, or a string, but we ought to so that anyway) If that's not a reasonable option, and I can see it not being so, that makes things somewhat more interesting. Definitely calls for at least one custom PMC for PHP, and potentially an automatic wrapping function to throw a PHPStringWrapper (or whatever) around anything stringlike that comes back from an 'external' function call. That requires a bit more work on parrot's part, though, and, while I'd like to do this at some point (for JVM and .NET native library wrapping) I hadn't intended to do it yet, for lack of time and need. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Sorry 'bout the object delay
At 3:29 PM +0100 12/7/03, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: I got mugged by the flu, [ ... ] [ ... ] Objects'll be the death of me, I swear... I don't hope, that this is anyhow related to my checkins, Nah--objects just hate me. :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [RfC] Testing for null
At 1:21 PM -0500 12/3/03, Melvin Smith wrote: We should have 1 recommended way for testing NULL registers. If we support get_bool() then lets make sure it works for REAL NULL pmc registers as well as PMCNULL. If not, code will appear to work correctly on a "safe" core but will seg fault on some other. Also, I see no reason not to use PMCNULL in all cores now. Okay, lets do this: Add an isnull branch op: isnull Px, destination Leave the Null PMC as something with every vtable entry pitching a for. The Null PMC is the "this register/array entry/hash entry is full of crap and you're lucky I'm not segfaulting, dammt!" alternative to a real NULL pointer. Add in an undef PMC. A subset of PerlUndef, with the automatic morphing to other perl base types. It notes that we have an actual PMC, but one with garbage contents. We should have an interpreter flag that indicates what Undef should do when its contents are accessed (Though I'm really tempted to have undef return actively random data) more or less equivalent to perl's -w flag. (Which notes whether undef quietly returns a value, throws a warning, or pitches a fatal exception) The two can be looked at as: Null - the register/aggregate entry doesn't point to anything Undef - the register/aggregate entry points to a PMC, but the PMC isn't initialized That'd seem to cover it, at least until the SQL folks pop up with inquiries about SQL's NULL and three-value logic, but I'm still sick so I think I'll hide from that for a while. I can see having an isundef op equivalent to the isnull op. If someone wants to make even a token argument for it, throw it in. Juergen Boemmels <[EMAIL PROTECTED]> wrote: Hi, I'm curently playing around with open calls returning a PMCNULL instead of a half valid IO-Object. But the main problem with that is that there is currently no way for the byte-code to detect such a case. C tests for PMCNULL too and is usable. * A PMCNULL has false semantics. This may be done by letting get_boolean return FALSE, or by adding a test to if_p_ic op: if(!PMC_IS_NULL($1) && $1->vtable->get_boolean($1)) Or the null.pmc gets a valid get_bool() vtable slot returning 0. OTOH when PMCNULL is a real NULL, this will fail then. * Have a special op for this if_null and unless_null which exlusively test for NULL. Probably better. boe leo -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Determining PMC memory addresses
At 9:18 AM -0700 12/3/03, Cory Spencer wrote: > We're already using 'eq' to perform equality testing, and in the interests of maintaining a consistent design I would choose to stick with something eq-related as opposed to changing it to 'same'. eqaddr/eqval? eq_addr/eq_val? eq_address/eq_value? So just to follow up on this thread, was there any preference at all for the name of the opcode performing equality testing of PMC memory addresses? I needed the functionality for the code I'm working on, so I've created a patch implementing an "eq_addr" opcode... Make it eq_addr. We'll go with that scheme for the other comparisons (eq_str, eq_num) as well. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Missing branch instructions?
At 12:15 PM +0100 12/7/03, Leopold Toetsch wrote: Pete Lomax <[EMAIL PROTECTED]> wrote: ... only to find there are no such equivalents for ne, gt, and ge. I've added these missing ops now. *But* there are a lot more missing: Yeah, we need all the comparison operators for PMCs in both numeric and string versions. I'd like to throw a _str and _num suffix on them, so we have: eq_str lt_num cmp_str and so on. I think, at this point, that I'm OK with restricting the eq/lt/whatever unqualified versions to same-type comparisons--i.e.: eq I5, 13 lt S5, "Foo" and have them do the obvious thing (numeric or string comparison). Cross-type comparisons without PMCs won't be allowed, so if you want this: lt S5, 12 you'll need to either get the integer contents of S5 or turn 12 into a string, so it's a two-op sequence. Not too onerous. (int/float mixes are still OK, they're obvious) Unqualified eq/cmp/lt are OK for two PMC operations, and call the underlying unqualified comparison check, but I'd bet that's rarely used. A Perl compiler will probably emit only the _str or _int variants. The opcode replacement inside imcc can emit an error or warning, if the opcodes have the wrong operands, and can replace the opcodes with the plain variants without _str or _int suffix, if there is no matching opcode. Odds are most compilers will go for the explicit string or numeric comparisons, or MMD on type to figure out which to use, but we can leave that to the compiler writers. (Enough people have been burned with the whole "my numbers sorted weird" issue to explicitly specify numeric or string comparisons pretty much everywhere) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Missing branch instructions?
On Mon, 8 Dec 2003 11:35:59 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: >At 12:15 PM +0100 12/7/03, Leopold Toetsch wrote: >>Pete Lomax <[EMAIL PROTECTED]> wrote: >>> ... only to find there are no such equivalents for ne, gt, and ge. >> >>I've added these missing ops now. *But* there are a lot more missing: > >Yeah, we need all the comparison operators for PMCs in both numeric >and string versions. This needs quite careful thought. >I'd like to throw a _str and _num suffix on >them, so we have: > > eq_str > lt_num > cmp_str I disagree/don't see the point, pls read on. > >and so on. I think, at this point, that I'm OK with restricting the >eq/lt/whatever unqualified versions to same-type comparisons--i.e.: > >eq I5, 13 >lt S5, "Foo" > >and have them do the obvious thing (numeric or string comparison). AFIAK, this happens quite reasonably now. >Cross-type comparisons without PMCs won't be allowed, Agreed, that's been my (short-term) experience. >so if you want this: > >lt S5, 12 > >you'll need to either get the integer contents of S5 or turn 12 into >a string, so it's a two-op sequence. Not too onerous. (int/float >mixes are still OK, they're obvious) Yes, 1) get length of string, 2) compare integers. (or whatever) > >Unqualified eq/cmp/lt are OK for two PMC operations, I'm not convinced at all here. PMC comparison ops, afaict, are based solely on the pmc instance/address Here's a snippet to play with: $P1 = new Array $P1 = 2 $P1[0] = 1 $P1[1] = 1 $P2 = new Array $P2 = 2 $P2[0] = 1 $P2[1] = 1 # eq $P1, $P2, _L3 eq "fred", "fred", _L3 print "error \"fred\"!=\"fred\"" _L3: Is $P1=$P2? > and call the >underlying unqualified comparison check, but I'd bet that's rarely >used. Well, that's what I'm doing: eq_i_i_*, eq_n_n_*, and eq_s_s_*, I'm using directly; the rest are going though a check/cast types routine. >Odds are most compilers will go for the explicit string or numeric >comparisons, or MMD on type to figure out which to use, but we can >leave that to the compiler writers. (Enough people have been burned >with the whole "my numbers sorted weird" issue to explicitly specify >numeric or string comparisons pretty much everywhere)
Re: Missing branch instructions?
Pete Lomax writes:
> I'm not convinced at all here. PMC comparison ops, afaict, are based
> solely on the pmc instance/address
>
> Here's a snippet to play with:
>
> $P1 = new Array
> $P1 = 2
> $P1[0] = 1
> $P1[1] = 1
> $P2 = new Array
> $P2 = 2
> $P2[0] = 1
> $P2[1] = 1
> # eq $P1, $P2, _L3
> eq "fred", "fred", _L3
> print "error \"fred\"!=\"fred\""
> _L3:
>
>
> Is $P1=$P2?
Nope. Mostly because classes/array.pmc says:
/* == operation */
INTVAL is_equal (PMC* value) {
/* XXX */
return 0;
}
:-)
Luke
Re: [RfC] Testing for null
On Monday, December 8, 2003, at 10:03 , Dan Sugalski wrote: At 1:21 PM -0500 12/3/03, Melvin Smith wrote: We should have 1 recommended way for testing NULL registers. If we support get_bool() then lets make sure it works for REAL NULL pmc registers as well as PMCNULL. If not, code will appear to work correctly on a "safe" core but will seg fault on some other. Also, I see no reason not to use PMCNULL in all cores now. Okay, lets do this: Add an isnull branch op: isnull Px, destination How about this to test if Px is really null? null Py eq_addr Px, Py — Gordon Henriksen [EMAIL PROTECTED]
