Leopold Toetsch wrote:
> Ron Blaschke <[EMAIL PROTECTED]> 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.
Ron Blaschke <[EMAIL PROTECTED]> 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 b
While we AFAIK
Leopold Toetsch wrote:
> Ron Blaschke <[EMAIL PROTECTED]> 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.
I see. Does this morphing
Ron Blaschke <[EMAIL PROTECTED]> 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
Just had a look at the following test failures on Windows.
t\pmc\nci.t 2 512562 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
