Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dying test in S02-literals/allomorphic.t when comparing ComplexStr with infix:<eqv> #5250

Closed
p6rt opened this issue Apr 21, 2016 · 10 comments
Closed
Labels

Comments

@p6rt
Copy link

@p6rt p6rt commented Apr 21, 2016

Migrated from rt.perl.org#127949 (status was 'resolved')

Searchable as RT127949$

@p6rt
Copy link
Author

@p6rt p6rt commented Apr 21, 2016

From @usev6

This ticket is about two (skipped) tests in S02-literals/allomorphic.t which die on rakudo-j.

The (somewhat) golfed code is​:

$ perl6-j -e 'say < 8+9i > eqv ComplexStr.new(<8+9i>, "8+9i")' # True with rakudo-m
Attribute '$!re' is not a native num
  in block <unit> at -e line 1

$ perl6-j --ll-exception -e 'say < 8+9i > eqv ComplexStr.new(<8+9i>, "8+9i")'
Attribute '$!re' is not a native num
  in re (gen/jvm/CORE.setting)
  in infix​:<==> (gen/jvm/CORE.setting​:20489)
  in infix​:<==> (gen/jvm/CORE.setting​:8092)
  in infix​:<eqv> (gen/jvm/CORE.setting​:7877)
  in infix​:<eqv> (gen/jvm/CORE.setting​:1489)
  in <unit> (-e​:1)
  in <unit-outer> (-e​:1)
  in eval (gen/jvm/stage2/NQPHLL.nqp​:1198)
  in eval (src/Perl6/Compiler.nqp​:161)
  in (gen/jvm/stage2/NQPHLL.nqp​:1288)
  in command_eval (gen/jvm/stage2/NQPHLL.nqp​:1285)
  in command_eval (src/Perl6/Compiler.nqp​:29)
  in command_line (gen/jvm/stage2/NQPHLL.nqp​:1269)
  in MAIN (gen/jvm/main.nqp​:37)
  in <mainline> (gen/jvm/main.nqp​:33)
  in (gen/jvm/main.nqp)

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented Apr 21, 2016

From @usev6

On Thu Apr 21 05​:54​:59 2016, bartolin@​gmx.de wrote​:

The (somewhat) golfed code is​:

$ perl6-j -e 'say < 8+9i > eqv ComplexStr.new(<8+9i>, "8+9i")'

Actually the same error occurs with

$ perl6-j -e 'say < 8+9i >.re'
Attribute '$!re' is not a native num
  in block <unit> at -e line 1

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented Apr 21, 2016

From @usev6

On Thu Apr 21 11​:53​:14 2016, bartolin@​gmx.de wrote​:

$ perl6-j -e 'say < 8+9i >.re'
Attribute '$!re' is not a native num
in block <unit> at -e line 1

Oh, looks like rakudo-j has other problems with the attributes of ComplexStr​:

$ perl6-j 'say < 8+9i >.im'
8

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented May 1, 2016

From @peschwa

On Thu Apr 21 12​:34​:10 2016, bartolin@​gmx.de wrote​:

On Thu Apr 21 11​:53​:14 2016, bartolin@​gmx.de wrote​:

$ perl6-j -e 'say < 8+9i >.re'
Attribute '$!re' is not a native num
in block <unit> at -e line 1

Oh, looks like rakudo-j has other problems with the attributes of
ComplexStr​:

$ perl6-j 'say < 8+9i >.im'
8

The problem here lies somewhere in the generation of the accessors for Complex. We apparently cache the getattr hint for the Attributes in Complex and reuse them whenever we call the generated accessor, which results in an off-by-one error when we call the same generated accessors on a ComplexStr. Perl 6-level workaround would be to turn $.re and $.im in Complex into $!re and $!im and supplying an explicit accessor. Fixing this inside nqp-j probably involves a lot of figuring out where and how attribute hints are cached.

Note that the same problem doesn't occur with IntStr or NumStr because they don't have auto-generated accessors, and RatStr gets its accessors from the role Rational, which probably gets composed differently and thus avoids the issue. I'm not sure about the details there, to be honest.

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented May 1, 2016

The RT System itself - Status changed from 'new' to 'open'

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented May 1, 2016

From @peschwa

On Sun May 01 08​:04​:06 2016, peschwa@​gmail.com wrote​:

On Thu Apr 21 12​:34​:10 2016, bartolin@​gmx.de wrote​:

On Thu Apr 21 11​:53​:14 2016, bartolin@​gmx.de wrote​:

$ perl6-j -e 'say < 8+9i >.re'
Attribute '$!re' is not a native num
in block <unit> at -e line 1

Oh, looks like rakudo-j has other problems with the attributes of
ComplexStr​:

$ perl6-j 'say < 8+9i >.im'
8

The problem here lies somewhere in the generation of the accessors for
Complex. We apparently cache the getattr hint for the Attributes in
Complex and reuse them whenever we call the generated accessor, which
results in an off-by-one error when we call the same generated
accessors on a ComplexStr. Perl 6-level workaround would be to turn
$.re and $.im in Complex into $!re and $!im and supplying an explicit
accessor. Fixing this inside nqp-j probably involves a lot of
figuring out where and how attribute hints are cached.

Note that the same problem doesn't occur with IntStr or NumStr because
they don't have auto-generated accessors, and RatStr gets its
accessors from the role Rational, which probably gets composed
differently and thus avoids the issue. I'm not sure about the details
there, to be honest.

Here's a golf of the underlying problem​:

$ ./perl6-j foo.pl6
Attribute '$!foo' is not a native num
  in block <unit> at foo.pl6 line 13

$ cat foo.pl6
use nqp;
class A { has num $.foo; has num $.baz };
class B { has str $!bar };
class C is A is B {
  method new(Num $a, Str $b) {
  my \SELF = nqp​::create(self);
  nqp​::bindattr_n(SELF, A, '$!foo', nqp​::unbox_n($a));
  nqp​::bindattr_n(SELF, A, '$!baz', nqp​::unbox_n($a));
  nqp​::bindattr_s(SELF, B, '$!bar', nqp​::unbox_s($b));
  SELF
  }
};
C.new(5e0, "5").foo.WHAT.say

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented May 1, 2016

From [Unknown Contact. See original ticket]

On Sun May 01 08​:04​:06 2016, peschwa@​gmail.com wrote​:

On Thu Apr 21 12​:34​:10 2016, bartolin@​gmx.de wrote​:

On Thu Apr 21 11​:53​:14 2016, bartolin@​gmx.de wrote​:

$ perl6-j -e 'say < 8+9i >.re'
Attribute '$!re' is not a native num
in block <unit> at -e line 1

Oh, looks like rakudo-j has other problems with the attributes of
ComplexStr​:

$ perl6-j 'say < 8+9i >.im'
8

The problem here lies somewhere in the generation of the accessors for
Complex. We apparently cache the getattr hint for the Attributes in
Complex and reuse them whenever we call the generated accessor, which
results in an off-by-one error when we call the same generated
accessors on a ComplexStr. Perl 6-level workaround would be to turn
$.re and $.im in Complex into $!re and $!im and supplying an explicit
accessor. Fixing this inside nqp-j probably involves a lot of
figuring out where and how attribute hints are cached.

Note that the same problem doesn't occur with IntStr or NumStr because
they don't have auto-generated accessors, and RatStr gets its
accessors from the role Rational, which probably gets composed
differently and thus avoids the issue. I'm not sure about the details
there, to be honest.

Here's a golf of the underlying problem​:

$ ./perl6-j foo.pl6
Attribute '$!foo' is not a native num
  in block <unit> at foo.pl6 line 13

$ cat foo.pl6
use nqp;
class A { has num $.foo; has num $.baz };
class B { has str $!bar };
class C is A is B {
  method new(Num $a, Str $b) {
  my \SELF = nqp​::create(self);
  nqp​::bindattr_n(SELF, A, '$!foo', nqp​::unbox_n($a));
  nqp​::bindattr_n(SELF, A, '$!baz', nqp​::unbox_n($a));
  nqp​::bindattr_s(SELF, B, '$!bar', nqp​::unbox_s($b));
  SELF
  }
};
C.new(5e0, "5").foo.WHAT.say

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented Oct 6, 2016

From @usev6

This works now on JVM (fixed by psch++ with Raku/nqp@1344f28)

$ ./perl6-j -e 'say < 8+9i > eqv ComplexStr.new(<8+9i>, "8+9i")'
True

I'm closing this ticket as 'resolved'.

Loading

1 similar comment
@p6rt
Copy link
Author

@p6rt p6rt commented Oct 6, 2016

From @usev6

This works now on JVM (fixed by psch++ with Raku/nqp@1344f28)

$ ./perl6-j -e 'say < 8+9i > eqv ComplexStr.new(<8+9i>, "8+9i")'
True

I'm closing this ticket as 'resolved'.

Loading

@p6rt p6rt closed this Oct 6, 2016
@p6rt
Copy link
Author

@p6rt p6rt commented Oct 6, 2016

@usev6 - Status changed from 'open' to 'resolved'

Loading

@p6rt p6rt added the JVM label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant