NCI, undef and structures

[Ron Blaschke]

Just had a look at the following test failures on Windows.
t\pmc\nci.t 2 512 56 2 3.57% 3 46

I have added the test output below. It may not look that way at first
sight, but the failures are a result of missing exported symbols in
libnci_test.dll (which remembers me of my proposal of tagging the
symbols directly in the source and create the .def by grepping for
them).

Anyway, I'd like to ask for some help, as I am not (yet) up to speed
with parrot's internals. The following sample is a simplified version
of t/pmc/nci.t #3, and prints "-83.000000". Shouldn't things
blow up, instead of printing the value?

-snip-
.include "datatypes.pasm"

.sub test @MAIN
# address of nci_dlvar_float
.local pmc nci_dlvar_float
# returns undef on missing symbol
#nci_dlvar_float = dlvar libnci_test, "nci_dlvar_float"
new nci_dlvar_float, .Undef

# the contained structure pointer
.local pmc nci_dlvar_float_decl
nci_dlvar_float_decl = new ResizablePMCArray
push nci_dlvar_float_decl, .DATATYPE_FLOAT
push nci_dlvar_float_decl, 0
push nci_dlvar_float_decl, 0
assign nci_dlvar_float, nci_dlvar_float_decl

N2 = nci_dlvar_float[0]
print N2
print "\n"

end
.end
-snap-

-test failures snip-
t\pmc\nci....NOK 3# got: 'libnci_test was successfully loaded
# -83.000000
# -3330.000000
# -33300.000000
# -333000.000000
# -3330000.000000
# -33300000.000000
# '
# expected: 'libnci_test was successfully loaded
# -333.000000
# -3330.000000
# -33300.000000
# -333000.000000
# -3330000.000000
# -33300000.000000
# '

t\pmc\nci....NOK 46# got: 'created a callback sub
# loaded a function that takes a callback
# external data: -55546
# external data: -555460
# external data: -5554600
# external data: -55546000
# external data: -555460000
# external data: -1259632704
# external data: 288574848
# external data: -1409218816
# external data: -1207286272
# marked callback as synchronous
# external data: 812039168
# external data: -469542911
# external data: -400461813
# external data: 290349167
# external data: -1391475625
# external data: -1029854361
# external data: -1708609017
# external data: 93779015
# external data: 937790151
# '
# expected: 'created a callback sub
# loaded a function that takes a callback
# external data: 10
# external data: 100
# external data: 1000
# external data: 10000
# external data: 100000
# external data: 1000000
# external data: 10000000
# external data: 100000000
# external data: 1000000000
# marked callback as synchronous
# external data: 1
# external data: 11
# external data: 111
# external data: 1111
# external data: 11111
# external data: 111111
# external data: 1111111
# external data: 11111111
# external data: 111111111
# '
-test failures snap-

Ron

[Leopold Toetsch]

Ron Blaschke <mailin...@rblasch.org> wrote:
> assign nci_dlvar_float, nci_dlvar_float_decl

This calls Undef::assign, which morphs the Undef to the RHS type. So the
Undef becomes an array and

> N2 = nci_dlvar_float[0]

this succeeds.

leo

[Ron Blaschke]

>> N2 = nci_dlvar_float[0]

> this succeeds.

I see. Does this morphing work as designed? Creating an array out of
an undef feels somewhat wrong.

I guess the lesson here is: Don't mess with Undef, it's ... undefined.
;-)

Ron

[Leopold Toetsch]

Ron Blaschke <mailin...@rblasch.org> wrote:

> I see. Does this morphing work as designed? Creating an array out of
> an undef feels somewhat wrong.

Yes and yes ;)
A longer answer is: all operators currently need an existing LHS. The
canonical way is:

lhs = new Undef
lhs = a <op> b

While we AFAIK don't have ops yet, where an array is created and the
morphing to an array is needed, Perl6 hyper operators are just doing that.
So the functionality is correct.

> I guess the lesson here is: Don't mess with Undef, it's ... undefined.

Or for the test case: check the return result of C<dlfunc>.

> Ron

leo

[Ron Blaschke]

Leopold Toetsch wrote:
> Ron Blaschke <mailin...@rblasch.org> wrote:

>> I see. Does this morphing work as designed? Creating an array out of
>> an undef feels somewhat wrong.

> Yes and yes ;)
> A longer answer is: all operators currently need an existing LHS.

[snip]

Thanks for explaining things.

>> I guess the lesson here is: Don't mess with Undef, it's ... undefined.
> Or for the test case: check the return result of C<dlfunc>.

Thought so, too. I'll open a ticket.

Ron