Geth_ roast: tbrowder++ created pull request #604:
New test for pod leading declarator user-format capability
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
01:20 Altai-man_ joined 01:23 sena_kun left 01:57 kalkin-- joined 02:01 kalkin- left 03:01 bisectable6 left, sourceable6 left, benchable6 left, nativecallable6 left, releasable6 left, committable6 left, bloatable6 left, statisfiable6 left, squashable6 left, reportable6 left, greppable6 left, quotable6 left, coverable6 left, shareable6 left, unicodable6 left, notable6 left 03:02 nativecallable6 joined, bisectable6 joined, greppable6 joined, coverable6 joined, benchable6 joined 03:03 statisfiable6 joined, quotable6 joined, sourceable6 joined, unicodable6 joined, shareable6 joined, releasable6 joined, notable6 joined, committable6 joined 03:04 squashable6 joined, bloatable6 joined, reportable6 joined 03:21 sena_kun joined 03:23 Altai-man_ left
Geth_ rakudo: vrurg++ created pull request #3375:
Fix the order of DESTROY invocation.
roast: vrurg++ created pull request #605:
Adjust tests to correspond with fixed DESTROY order
roast: vrurg++ created pull request #606:
Adjust tests to correspond with fixed DESTROY order (fixed)
04:02 benjif1 joined 04:03 benjif1 left
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.
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.
04:17 vrurg_ is now known as vrurg
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)
04:33 AlexDaniel joined, AlexDaniel left, AlexDaniel joined 05:20 Altai-man_ joined 05:23 sena_kun left 06:23 statisfiable6 left, benchable6 left, quotable6 left, shareable6 left, greppable6 left, coverable6 left, bisectable6 left, committable6 left, bloatable6 left, unicodable6 left, squashable6 left, nativecallable6 left, sourceable6 left, releasable6 left, notable6 left, reportable6 left, notable6 joined, bisectable6 joined, nativecallable6 joined, committable6 joined, squashable6 joined 06:24 quotable6 joined, statisfiable6 joined, bloatable6 joined, unicodable6 joined 06:25 benchable6 joined, greppable6 joined, releasable6 joined, coverable6 joined, sourceable6 joined, reportable6 joined 06:26 shareable6 joined 07:21 sena_kun joined 07:23 Altai-man_ left 07:58 AlexZahatski joined 08:00 AlexZahatski is now known as Zag, Zag is now known as aZag 08:32 aZag left 08:40 AlexDani` joined 08:43 AlexDaniel left 08:49 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined 09:20 Altai-man_ joined 09:23 sena_kun left 09:58 kalkin-- is now known as kalkin0-, kalkin0- is now known as kalkin-
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
11:21 sena_kun joined 11:23 Altai-man_ left 11:39 masak_ is now known as masak
[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
13:20 Altai-man_ joined 13:23 sena_kun left 13:42 bobv joined 14:59 [Tux] left 15:06 [Tux] joined 15:21 sena_kun joined 15:23 Altai-man_ left 15:47 leont joined 16:15 bobv left 17:21 Altai-man_ joined 17:22 sena_kun left 18:43 evalable6 left 18:44 evalable6 joined 19:20 sena_kun joined 19:23 Altai-man_ left
sena_kun rba++ 20:46
20:47 Xliff joined
Geth_ rakudo/release-2019.12: 9806457202 | Altai-man++ | docs/announce/
Fix year
21:20 Altai-man_ joined 21:23 sena_kun left
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>
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>
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,205) 22:13
jnthn Hmm, cute...also in S02?
lizmat well, handwavy 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,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, "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>
at <tmp>:1
------> 030b17⏏5e0
expecting any of:
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
23:21 sena_kun joined 23:23 Altai-man_ left
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