[perl #33603] Undef != Undef
# New Ticket Created by Simon Glover # Please include the string: [perl #33603] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=33603 This code: new P0, .Undef new P1, .Undef eq P0, P1, L1 print not L1: print ok\n end prints not ok. Should it? If Parrot considers every Undef PMC to be distinct, it's going to make tasks like comparing arrays with large numbers of undefined elements much fiddlier than it should be. For instance, the fact that Undef != Undef means that this code: new P0, .ResizablePMCArray set P0, 1 clone P1, P0 eq P0, P1, L1 print not L1: print ok print \n end prints not ok. Simon
Re: Win32 dynclasses build issues
Jonathan Worthington [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] wrote: I assume that the dynamic python lib has to export public symbols. You could run one of the failing tests with a debugger and check the Parrot_load_lib() steps. OK, you were right. Once I inserted __declspec(dllexport) into the declaration of Parrot_lib_python_group_load, Parrot_dlsym returned the address of the function in the DLL and it was called. I'll fix up a patch to get that inserted. VTABLE *vtable = Parrot_base_vtables[base_type]; Because Parrot_base_vtables was null. My python_group.dll is almost 2MB in size. I'm thinking that when it's being linked, it is linking a separate copy of Parrot (from libparrot_s.lib, which I added to the link line to make the build not complain about missing symbols). That means different globals, which leads to the problem. Might my analysis be correct, and any ideas on where to go from here? Yep, that's correct. I had that during my first experiments with loadable classes in linux too. Studying linker flags up and down led to the current link flag settings -Wl,-E for gcc. You have to convince the linker that unknown symbols in the shared library have to be resolved against libparrot dynamically, when the library is loaded, instead of duplicating globals and pulling in functions from that libparrot. This may work with some linker flags, via the .def file or by some __declspec() magic. You might have a look at perl5 source, albeit I don't know, if shared libs are supported for Win32. Reading docs and/or asking in a win programming newsgroup might help too. Jonathan leo
Re: [perl #33603] Undef != Undef
Simon Glover [EMAIL PROTECTED] wrote: This code: new P0, .Undef new P1, .Undef eq P0, P1, L1 print not L1: print ok\n end prints not ok. Should it? That depends ;) ... If Parrot considers every Undef PMC to be distinct, it's going to make tasks like comparing arrays with large numbers of undefined elements much fiddlier than it should be. Yep. Currently there is no chance to change that. The semantics of unary and binary operators need an existing destination PMC. Usual code for infix '+' is: $P0 = new Undef $P0 = a + b So *currently* the Undefs have to be distinct. But as outlined several times, the current behavior isn't that one that HLLs have. Overloaded operators are functions (multi subs) that return new values. For consistency we really should do the same with operators. Additionally we currently can't have singletons as a result of an operator. This isn't only a serious restriction but can additionally be much more expensive then the Undef issue. We should have: $P0 = cmp a, b with the return result being a singleton True of False PMC. Now a HLL compiler is forced to emit: $I0 = cmp a, b $P0 = new Boolean $P0 = $I0 which is three times the code size and it needs a new PMC for each compare. For instance, the fact that Undef != Undef means that this code: new P0, .ResizablePMCArray set P0, 1 clone P1, P0 eq P0, P1, L1 print not L1: print ok print \n end prints not ok. This is a different issue. The ResizablePMCArray doesn't properly inherit the is_equal multi method from FixedPMCArray and as far as I can see, there is no Undef involved at all. Empty array slots are filled with PMCNULL, which is a singleton. The example works for FixedPMCArray. Simon leo
Re: [perl #33603] Undef != Undef
Leopold Toetsch wrote:
Simon Glover [EMAIL PROTECTED] wrote:
This code:
new P0, .Undef
new P1, .Undef
eq P0, P1, L1
print not
L1: print ok\n
end
prints not ok. Should it?
That depends ;)
... If Parrot considers every Undef PMC to
be distinct, it's going to make tasks like comparing arrays with
large numbers of undefined elements much fiddlier than it should be.
Yep. Currently there is no chance to change that.
If the desire is that two new .Undef values are to be considered equal,
then the attached patch achieves that.
- Sam Ruby
? undef.patch
Index: undef.pmc
===
RCS file: /cvs/public/parrot/classes/undef.pmc,v
retrieving revision 1.10
diff -u -r1.10 undef.pmc
--- undef.pmc 19 Oct 2004 01:25:35 - 1.10
+++ undef.pmc 31 Dec 2004 15:16:50 -
@@ -77,6 +77,15 @@
return 0;
}
+ INTVAL is_equal (PMC* value) {
+MMD_Undef: {
+ return 1;
+}
+MMD_DEFAULT: {
+ return 0;
+}
+ }
+
}
/*
Re: [perl #33603] Undef != Undef
On Fri, 31 Dec 2004, Leopold Toetsch wrote:
Simon Glover [EMAIL PROTECTED] wrote:
new P0, .ResizablePMCArray
set P0, 1
clone P1, P0
eq P0, P1, L1
print not
L1: print ok
print \n
end
prints not ok.
This is a different issue. The ResizablePMCArray doesn't properly
inherit the is_equal multi method from FixedPMCArray and as far as I can
see, there is no Undef involved at all. Empty array slots are filled
with PMCNULL, which is a singleton. The example works for FixedPMCArray.
In the case of the ResizablePMCArray, the Undef comes into it because
of this loop in is_equal():
for (j = 0; j n; ++j) {
PMC *item1, *item2;
item1 = DYNSELF.get_pmc_keyed_int(j);
item2 = VTABLE_get_pmc_keyed_int(INTERP, value, j);
if (item1 == item2)
continue;
if (!mmd_dispatch_i_pp(INTERP, item1, item2, MMD_EQ))
return 0;
}
and this code in get_pmc_keyed_int:
data = PMC_data(SELF);
if (data[key] == PMCNULL)
data[key] = pmc_new(INTERP, enum_class_Undef);
return data[key];
When is_equal calls get_pmc_keyed_int to do the comparison, it creates
and returns an Undef PMC, rather than simply returing PMCNULL, and
since Undef != Undef, this ultimately causes the comparison to fail.
In the case of FixedPMCArray, the test passes because the
implementation of get_pmc_keyed_int doesn't have the test for PMCNULL
-- instead, it just does:
data = (PMC **)PMC_data(SELF);
return data[key];
Hence, if the entry is PMCNULL, the code actually returns PMCNULL,
and since PMCNULL == PMCNULL, the comparison succeeds and the test
passes.
I guess the real question is should we be creating that Undef PMC;
i.e. should fetching an undefined element return a fully-fledged
Undef value, or simply a PMCNULL, which may later be promoted to a
real Undef?
Simon
