Geth_ roast: tbrowder++ created pull request #604:
New test for pod leading declarator user-format capability		 00:52
roast: 945b67793d | (Tom Browder)++ (committed using GitHub Web editor) | 2 files
New test for pod leading declarator user-format capability (#604)

  * Add test for user-formatted pod leading declarator blocks
  * Correct test for new pod leading decl user-format capability\n\nadd it to the list of required tests		 00:53
Geth_ rakudo: vrurg++ created pull request #3375:
Fix the order of DESTROY invocation.		 03:41
roast: vrurg++ created pull request #605:
Adjust tests to correspond with fixed DESTROY order		 03:52
roast: vrurg++ created pull request #606:
Adjust tests to correspond with fixed DESTROY order (fixed)		 03:58
Geth_ rakudo: f2a416133f | (Vadim Belman)++ | src/Perl6/Metamodel/Finalization.nqp
Fix the order of DESTROY invocation.

Make it correspond to S12-construction/destruction.t, i.e. from subclass to parent classes; or, in other wosrds, reverse to (R)MRO.		 04:16
rakudo: 9a571b6851 | (Vadim Belman)++ (committed using GitHub Web editor) | src/Perl6/Metamodel/Finalization.nqp
Merge pull request #3375 from vrurg/fix-DESTROY-order

Fix the order of DESTROY invocation.
roast: 30329959d0 | (Vadim Belman)++ | S12-construction/destruction.t
Unfudge test for destruction.

The order is now fixed.
Also, change the test to remove deprecated `undefine` and to base test result not on fixed number of loops but on some physical timeout (5 seconds as for now). This way I seemingly got rid of test flapping.
roast: 596695790e | (Vadim Belman)++ | S12-construction/roles-6e.t
Fix test for destructors in roles

It was based on incorrect direct order whereas in fact it must use reverse order to constructors. Also, test is now based on physical timeout of 5 seconds to detect a destructors invocation.
roast: 4e5c8a8d20 | (Vadim Belman)++ (committed using GitHub Web editor) | 2 files
Merge pull request #606 from vrurg/fix-DESTROY-order

Adjust tests to correspond with fixed DESTROY order (fixed)
lizmat Files=1294, Tests=109647, 209 wallclock secs (28.19 usr 8.29 sys + 2952.50 cusr 265.87 csys = 3254.85 CPU) 11:02
[Tux] Rakudo version 2019.11-291-g9a571b685 - MoarVM version 2019.11-97-geb13ccad1
csv-ip5xs0.744 - 0.790
csv-ip5xs-206.484 - 6.854
csv-parser22.909 - 23.190
csv-test-xs-200.419 - 0.439
test7.368 - 7.928
test-t1.896 - 1.940
test-t --race0.846 - 0.901
test-t-2029.917 - 31.402
test-t-20 --race9.205 - 9.292
 12:47
sena_kun rba++ 20:46
Geth_ rakudo/release-2019.12: 9806457202 | Altai-man++ | docs/announce/2019.12.md
Fix year
 20:49
lizmat m: dd 0x_11 21:49
camelia 17
lizmat m: dd :16<_11> 21:50
camelia 5===SORRY!5=== Error while compiling <tmp>
Malformed radix number
at <tmp>:1
------> 3dd :16<7⏏5_11>
expecting any of:
number in radix notation
lizmat can someone explain me the rationale of this difference ?
I think either both should be an error, or both should be ok
jnthn: ^^ ??
jnthn m: say 1_2 22:01
camelia 12
jnthn m: say _12
camelia 5===SORRY!5=== Error while compiling <tmp>
Undeclared name:
_12 used at line 1
jnthn m: say 12_
camelia 5===SORRY!5=== Error while compiling <tmp>
Confused
at <tmp>:1
------> 3say 127⏏5_
jnthn Those semantics (_ must be internal - between digits) match how I expected it to work. It's a little odd it allows a _ right after the x 22:02
m: say 0x12_
camelia 5===SORRY!5=== Error while compiling <tmp>
Confused
at <tmp>:1
------> 3say 0x12_7⏏5<EOL>
jnthn m: say 0x1_2
camelia 18
jnthn m: say 0x_12
camelia 18
jnthn Curious; agree that's inconsistent.
Unless the x is counted as a digit somehow, but... :) 22:03
Maybe check if S02 had an opinion. Also I suspect the grammar parsing this is all the way down in NQP's HLL::Grammar 22:06
lizmat :-( /me looks at specs 22:07
jnthn I think it's actually written using the grammar language rather than being defined in some low-level way. Been probably years since I last looked at it though, so I may remember wrong :) 22:08
I'm also curious if I faithfully translit this behavior into the comma parser...
lizmat what I'm trying to do now, is to unite val parsing 22:09
jnthn haha, yes, I did :)
lizmat so that we don't have to maintain at least 2 versions of that code
so Comma doesn't allow for leading or trailing underscore ?
or does it? 22:10
jnthn It allows 0x_1
Like Rakudo
But not _1 and 1_ or 0x1_
So it seems to match just what Rakudo does
lizmat A single underscore is allowed only between any two digits in a literal
number, where the definition of digit depends on the radix. (A single
underscore is also allowed between a radix prefix and a following digit, as
explained in the next section.) Underscores are not allowed anywhere else in
any numeric literal, including next to the radix point or exponentiator, or
at the beginning or end.
jnthn Aha...and 0x is a radix prefix. 22:11
lizmat yeah, so 0x_42 should be ok, but _42 not
jnthn Yes
OK, so it's at least in line with what S02 says
I guess perhaps the rationale is it lets you get a bit more visual separation on the prefix
lizmat yeah, I guess 22:12
jnthn I'd argue that still doesn't imply that :16<_1> need work, though
Since there's no radix prefix in the number there
lizmat also working on :2{ 01101001 11001101 } making Blob.new(105,205) 22:13
jnthn Hmm, cute...also in S02?
lizmat well, handwavy
design.raku.org/S02.html#Blob_literals 22:14
jnthn uff, wow, sub-byte blobs... 22:15
lizmat I think that predates on what a Blob actually meant
so I'm going for a whitespace delimited list of byte values 22:16
jnthn That does feel a bit more useful...
lizmat :10{ 1 2 3 4 }
would be a Blob.new(1,2,3,4)
:16{ 00 ff 0f f0 } 22:17
m: 0b1.1e10 22:31
camelia 5===SORRY!5=== Error while compiling <tmp>
Malformed postfix call
at <tmp>:1
------> 030b1.7⏏051e10
lizmat m: dd <0b1.1e10> 22:32
camelia "0b1.1e10"
lizmat m: dd <0b1.1>
camelia RatStr.new(1.5, "0b1.1")
lizmat m: 0b1.1
camelia 5===SORRY!5=== Error while compiling <tmp>
Malformed postfix call
at <tmp>:1
------> 030b1.7⏏051
lizmat jnthn: 0b1.1 vs <0b1.1> seem inconsistent
m: 0b1e0 22:34
camelia 5===SORRY!5=== Error while compiling <tmp>
Confused
at <tmp>:1
------> 030b17⏏5e0
expecting any of:
whitespace
lizmat m: dd <0b1e0>
camelia "0b1e0"
Xliff lizmat: Why would you want an exponent specifier with a binary literal? 23:09
Conflates bases, really.
0b1 being binary and e0 being decimal'
lizmat yeah, that was a thinko
Xliff :) 23:10
lizmat also, "e" is ambiguous with 0x
Xliff Would it make sense to make "e" magical and have it mutate by the literal base?
0x1e1 would be 0x10 23:11
0b1e2 would be 0b10
But then those technically become Nums, right?
So... now I'm not certain if that makes sense at all. 23:12
jnthn Well, e in the main language always means floating point 23:27
There is some justification for being able to write those in binary or hex
Xliff OK 23:28
jnthn (Namely, that's how they are represented in memory, so if for some reason you want to absolutely nail the exact value without any conversion from decimal...)
I know some (mainstream) language relatively recently added support for that; forget which 23:29
Xliff Ah. That would be nice.
Probably Python.
Yeah... python has 'e' in floating point literals. 23:31
C has hex binary exponent using 'P' 23:32

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!