From @usev6

I unfudged some of the skipped tests with commit Raku/roast@0aa3fde915

The only test not passing (fudged 'todo') fails because of the following​:

$ perl6-j -e 'say <0x01/0x02>'
Attempt to divide by zero using div
  in block <unit> at -e​:1

This works, though​:

$ perl6-j -e 'say 0x01/0x02'
0.5

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

From @peschwa

On Thu Jul 09 12​:23​:19 2015, bartolin@​gmx.de wrote​:

I unfudged some of the skipped tests with commit
Raku/roast@0aa3fde915

The only test not passing (fudged 'todo') fails because of the
following​:

$ perl6-j -e 'say <0x01/0x02>'
Attempt to divide by zero using div
in block <unit> at -e​:1

This works, though​:

$ perl6-j -e 'say 0x01/0x02'
0.5

<psch> m​: say <0b01/0b10>
<camelia> rakudo-moar 383db0​: OUTPUT«Attempt to divide by zero using div
in block <unit> at /tmp/qoDweZP96K​:1␤␤Actually thrown at​:
in block <unit> at /tmp/qoDweZP96K​:1␤␤»
<psch> j​: say <0b01/0b10>
<camelia> rakudo-jvm 383db0​: OUTPUT«Attempt to divide by zero using div
in block <unit> at /tmp/qq7oHJ2fdO​:1␤␤Actually thrown at​:
in block <unit> at /tmp/qq7oHJ2fdO​:1␤␤»
<psch> m​: say <0b01+1i>
<camelia> rakudo-moar 383db0​: OUTPUT«0+1i␤»

Which is to say nqp-j and nqp-m have the same problem, the latter just cheats a tad more convincingly. Decoding of angle-quoted Rat and Complex literals currently happens via coercion methods in the backend (i.e. coerce_{s2n,s2i,n2s,i2s} on JVM in org.perl6.nqp.runtime.Ops, I didn't check what exactly Moar does, but the lack of 0b and 0o literal support strongly suggests a similar cause), in constrast to actual Rat and Complex literals which are constructed by infix​:</> and postfix​:<i> respectively. Seeing as q​:w// at it's core is still a quoting operator and operates on strings I suggest deferring this bug until we have C<val()> and handling the decoding that way.

From @peschwa

On Sun Aug 16 17​:42​:39 2015, peschwa@​gmail.com wrote​:

On Thu Jul 09 12​:23​:19 2015, bartolin@​gmx.de wrote​:

I unfudged some of the skipped tests with commit
Raku/roast@0aa3fde915

The only test not passing (fudged 'todo') fails because of the
following​:

$ perl6-j -e 'say <0x01/0x02>'
Attempt to divide by zero using div
in block <unit> at -e​:1

This works, though​:

$ perl6-j -e 'say 0x01/0x02'
0.5

<psch> m​: say <0b01/0b10>
<camelia> rakudo-moar 383db0​: OUTPUT«Attempt to divide by zero using
div
in block <unit> at /tmp/qoDweZP96K​:1␤␤Actually thrown at​:
in block <unit> at /tmp/qoDweZP96K​:1␤␤»
<psch> j​: say <0b01/0b10>
<camelia> rakudo-jvm 383db0​: OUTPUT«Attempt to divide by zero using
div
in block <unit> at /tmp/qq7oHJ2fdO​:1␤␤Actually thrown at​:
in block <unit> at /tmp/qq7oHJ2fdO​:1␤␤»
<psch> m​: say <0b01+1i>
<camelia> rakudo-moar 383db0​: OUTPUT«0+1i␤»

Which is to say nqp-j and nqp-m have the same problem, the latter just
cheats a tad more convincingly. Decoding of angle-quoted Rat and
Complex literals currently happens via coercion methods in the backend
(i.e. coerce_{s2n,s2i,n2s,i2s} on JVM in org.perl6.nqp.runtime.Ops, I
didn't check what exactly Moar does, but the lack of 0b and 0o literal
support strongly suggests a similar cause), in constrast to actual Rat
and Complex literals which are constructed by infix​:</> and
postfix​:<i> respectively. Seeing as q​:w// at it's core is still a
quoting operator and operates on strings I suggest deferring this bug
until we have C<val()> and handling the decoding that way.

Some discussion with ShimmerFairy++ followed​:

< psch> and i'm thinking we're doing wrong in letting the backends handle that conversion
< psch> which is what i'm about to write into the ticket because i'm obviously getting a bit tired :)
< ShimmerFairy> psch​: if there's something in the spec showing that (I'm sure there is), then that's just a bug in Rat literals for P6 :)
< psch> i think the bug is actually "we don't have &val yet"
< ShimmerFairy> Not really, since <1/2> is just a literal Rat, and I know there's a parsing rule for it
< ShimmerFairy> m​: say <1/2>; say <1/2>.WHAT
<+camelia> rakudo-moar f185e0​: OUTPUT«0.5␤(Rat)␤»
< psch> right, but the parsing of nu and de relies on backends knowing the rakudo Int(Str) conversion rules
< ShimmerFairy> A quick look tells me there's nothing in the spec to suggest <0x1/0x2> should work, surprisingly
< psch> hm
< ShimmerFairy> Although the parser is set up to allow it :)
< psch> std​: <0x1/0x2>
<+camelia> std 28329a7​: OUTPUT«ok 00​:00 134m␤»
< psch> std​: < 0x1/0x2 >
<+camelia> std 28329a7​: OUTPUT«ok 00​:00 134m␤»
< ShimmerFairy> In reality it should be taking the ast of $&lt;nu&gt; and $&lt;de>, not making its own constants out of numifying the matched strings
< psch> the bit with space next to the angle brackets is the one that could use val(), as i just read in S02...

From @usev6

The code examples from this ticket work now​:

$ perl6-j -e 'say <0x01/0x02>'
0.5

$ perl6-j -e 'say <0b01/0b10>'
0.5

There are passing tests in S02-literals/numeric.t

I'm closing this ticket as 'resolved'.

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