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 | ||||||||||||||||||||||||||||||||||||||
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. |
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 | ||||||||||||||||||||||||||||||||||||||
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. |
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. |
|||||||||||||||||||||||||||||||||||||||
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] |
|
12:47 | |||||||||||||||||||||||||||||||||||||
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/2019.12.md Fix year |
20:49 | |||||||||||||||||||||||||||||||||||||
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> 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 | ||||||||||||||||||||||||||||||||||||||
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 |