Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
Geth roast: 7e0b791fa3 | (Zoffix Znet)++ | S32-num/rat.t
[v6.d REVIEW] Throw out Rational parametarization propspec

The OP tests are invalid, as you cannot instantiate a UInt. We can't really take a subclass of Int because we have defaults on `nu`/`de` args that are Ints. And currently R#2322 blocks the native parametarizations, we got no POV to spec with.
  [1] github.com/rakudo/rakudo/issues/2322		 00:16
synopsebot R#2322 [open]: github.com/rakudo/rakudo/issues/2322 Type capture in role parametarization doesn't work with natives and defaults
Zoffix .tell pmurias thanks. I reverted that propspec in github.com/perl6/roast/commit/7e0b791fa3
yoleaux Zoffix: I'll pass your message to pmurias.
Geth roast: cde1f26f61 | (Zoffix Znet)++ | S03-junctions/autothreading.t
[v6.d REVIEW] Don't spec order in Junction.perl

Orig: github.com/perl6/roast/commit/45b159756		 01:09
roast: 96ec9e60be | (Zoffix Znet)++ | S04-statements/sink.t
[v6.d REVIEW] Explain significance of ws in .= tests

Orig: github.com/perl6/roast/commit/da9a389b2		 01:12
Geth roast: 7900eda8f0 | (Zoffix Znet)++ | S17-lowlevel/atomic.t
[v6.d REVIEW] Fix typo in test description
 01:20
roast: 37a969cf86 | (Zoffix Znet)++ | S17-lowlevel/atomic.t
[v6.d REVIEW] Remove trailing whitespace
roast: bb5fb2ae0b | (Zoffix Znet)++ | S24-testing/3-output.t
[v6.d REVIEW] Loosen spec of `#` quoting in TAP

We might end up removing the "add extra space" thing as it confuses users and probably was a hackish idea in the first place.
  github.com/perl6/roast/commit/423cc68bf		 01:32
Geth roast: 3b8be1568f | (Zoffix Znet)++ | S12-methods/qualified.t
[v6.d REVIEW] Polish .:: tests

Orig: github.com/perl6/roast/commit/5d970e144		 01:43
samcv i think we need a way to check the endianess of the system. i don't think there's any official way to do this yet. please someone correc me if there is 06:27
TimToady well...since we depend on perl being out there, you can always run perl -E 'say unpack("n", pack "i", 42)' which will not return 42 on a little endian machine, though unpack "v" will 06:48
samcv hah 06:51
well i can technically also write utf16 to a file and then read it as a buf. but that doesn't actually check that the BOM is correct for that endianess
this was something that'd go into roast btw
TimToady well, I wasn't entirely serious :) 06:52
samcv hahaha
cygx m: say $*VM.config<be> 06:58
camelia 0
cygx samcv: ^ or were you looking for something else? 06:59
samcv m: say $*VM.config<le> 07:00
camelia (Any)
samcv cygx: assuming that gives me whether or not it's big endian then that works
cygx it should - moarvm needs to know endianness so it can decode bytecode 07:01
samcv yep i know that. i just didn't know if it was exposed 07:02
unless you mean rakudo itself needs to know?
TimToady 'course, perl didn't assume simple big or little endian, since it runs on some mix-endian machines... 07:04
so it has a 'byteorder' that can be 12345678 or 87654321 or 56781234 or... 07:06
cygx not sure if rakudo does anything with it - afaik it's just used to set MVM_BIGENDIAN in config.h
cross-platform computing used to be more fun - mixed order, integer padding, non-octet bytes... 07:08
samcv as far as i remember bytes have no endianess at least as far as C is concerned 07:10
essentially not exposed and the machine could implement it anyway they want
cygx endianness only makes sense if there's a smaller addressable subunit 07:13
cygx in C, you can't address individual bits, but have to use shifts etc, which are defined in terms of mathematical operations 07:13
cygx so agreed, no byte endianness as far as C is concerned 07:14
samcv s/byte/bit
TimToady I thought there were difference for the :4 subfields and such
*ces
but maybe the standards folks ironed all that out 07:15
samcv that doesn't allow you as the programmer to tell the order though right?
TimToady it does if you have unions :)
samcv ah ok :) i hadn't thought of that 07:18
cygx TimToady: you're right, how bitfields are packed can be considered a type of endianness 07:20
it's wholly implementation-defined, though
cygx o/ 07:49
Geth roast: be320b5eb3 | (Paweł Murias)++ | S05-mass/properties-general.t
[js] Copy rakudo.moar fudge as we keep it's behavior for now
 11:03
|Tux| Rakudo version 2018.09-43-gddb5f8fc4 - MoarVM version 2018.09-92-g1325e4ca6
csv-ip5xs0.911 - 0.935
csv-ip5xs-208.045 - 8.045
csv-parser20.423 - 21.502
csv-test-xs-200.424 - 0.431
test8.557 - 8.798
test-t1.791 - 1.843
test-t --race0.818 - 0.837
test-t-2030.797 - 31.598
test-t-20 --race11.833 - 11.960
 11:32
Zoffix jnthn: yesteray you said: "Probably 'cus its BUILDALL isn't code-gen'd."... Is that the same stuff lizmat did in Rakudo? Where we gen a bunch of QAST for some common object instantiation things? 12:10
jnthn: is it a worthy pursuit for NQP? For example, `nqp::create(QAST::Op)` is 4.14 faster than QAST::Op.new
I imagine we have a ton of such .new's and it'd be a fairly big compilation time win, no? 12:11
("4.14x as fast" I meant)
ZOFVM: Files=1310, Tests=153194, 160 wallclock secs (25.59 usr 3.46 sys + 3470.12 cusr 158.16 csys = 3657.33 CPU) 12:19
Geth nqp: af49187006 | (Zoffix Znet)++ | tools/build/MOAR_REVISION
[MoarVM Bump] Brings 2 commits

MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...2-g1325e4c 1325e4c Make *_I ops in interp.c consistent faea0ae Convert expmod_I to allocate in called function
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...2-g1325e4c
rakudo: 698c5ff71e | (Zoffix Znet)++ | tools/build/NQP_REVISION
[NQP Bump] af49187 [MoarVM Bump] Brings 2 commits

NQP bump brought: github.com/perl6/nqp/compare/2018....9-gaf49187
MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...2-g1325e4c 1325e4c Make *_I ops in interp.c consistent faea0ae Convert expmod_I to allocate in called function
rakudo: version bump brought these changes: github.com/perl6/nqp/compare/2018....9-gaf49187
4a968059c2 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Rat.pm6
Zoffix .ask lizmat would NQP benefit from the same BUILDALL gen you did in Rakudo? I imagine we create a ton of QAST objects. A plain `nqp::create(QAST::Op)` is 4.14x as fast as `QAST::Op.new`. I don't know if it could be genned when attributes are present, but it smells like there could be a nice win for compilation time (at least of Rakudo) 12:31
yoleaux Zoffix: I'll pass your message to lizmat.
timotimo QAST's creation is kind of complex, but it's possible to write a whole lot of code to make it faster 12:40
Zoffix timotimo: how to find out why a method didn't turn green in the profile? 12:42
after 100000 iterations
timotimo oh, heret oo
timotimo it's red, you say? 12:43
jnthn Zoffix: Potentially, yes, though QAST::Node already has its own carefully coded setup path, I think 12:44
timotimo it's not 100% inlined, though :P
Geth roast: 0f95942b73 | (Zoffix Znet)++ | S32-num/rat.t
No `Inf`s in huge rat stringification

Closes github.com/rakudo/rakudo/issues/1996 R#1996		 14:42
synopsebot R#1996 [open]: github.com/rakudo/rakudo/issues/1996 Crazy Rats stringify as 0.00000…000Inf
Geth rakudo: 8bd3e5024b | (Jonathan Worthington)++ | src/core/Array.pm6
Improve array assignment inlinability

Prior to this, the ASSIGN-POS method was too large to inline on MoarVM, but it's really quite helpful for performance if it does inline. Since MoarVM doesn't factor in the size of nested inlines, however, then it's possible to get below the inline limit by splitting some of the code out into a private method, as done by this commit.		 15:52
[Coke] sneaky 15:58
SqrtNegInf m: for 0.1, 0.2 ... 1 -> $a { say $a } 16:20
camelia ===SORRY!===
This type (QAST::WVal) does not support positional operations
SqrtNegInf It seems like sequences with 'for' can no longer contain decimals? 16:20
m: for 1.0, 2.0 ... 4.0 -> $a { say $a }
camelia ===SORRY!===
This type (QAST::WVal) does not support positional operations
SqrtNegInf This change happened sometime yesterday. 16:21
timotimo oh, that's bad 16:22
bisectable6: for 0.1, 0.2 ... 1 -> $a { say $a }
bisectable6 timotimo, Bisecting by exit code (old=2015.12 new=8bd3e50). Old exit code: 0
timotimo, bisect log: gist.github.com/26de1c45dcfe2aec4b...ba5495664a 16:23
timotimo, (2018-09-26) github.com/rakudo/rakudo/commit/89...cd6de16f2c
Zoffix bisect: 2018.06,HEAD for 1.0, 2.0 ... 4.0 -> $a { say $a } 16:23
bisectable6 Zoffix, Using old=2018.06 new=HEAD in an attempt to DWIM
Zoffix, Bisecting by exit code (old=2018.06 new=8bd3e50). Old exit code: 0
timotimo Zoffix: i just did that :)
bisectable6 Zoffix, bisect log: gist.github.com/18f02652648a49d3ed...002db13bed
Zoffix, (2018-09-26) github.com/rakudo/rakudo/commit/89...cd6de16f2c
Zoffix log-lag :) 16:24
timotimo somewhere in there it's doing a [x] on something that it didn't check for types before
timotimo if get_bound($op[1], 0) -> @rt { # right side ok 16:25
if nqp::istype(@rt[0],QAST::IVal) { # and is an int
could be this part
timotimo that get_bound misbehaves here 16:25
or rather: having rats rather than ints is not what it expects and the return type differs?
oh, the only changes there are comments 16:26
SqrtNegInf One more data point, explicit rationals do work.
m: for 1/10, 2/10 ... 1 -> $a { say $a }
camelia 0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
timotimo it might come from accessing the [0][2] and [1][2] of the $list in the lower half of the code 16:26
SqrtNegInf And there is a work-around, flat/slip 16:27
timotimo SqrtNegInf: we should be able to fix this in a jiffy
SqrtNegInf m: for |0.1, 0.2 ... 1 -> $a { say $a }
camelia 0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Zoffix I call dibs!
timotimo Zoffix: will you fix it or should i try?
ok :)
Zoffix fixed 16:31
timotimo Zoffix++ 16:33
SqrtNegInf Nice. Bugs fixed while-U-wait...
Zoffix just gonna stresstest and push 16:35
Zoffix Though there are still bugs with that opts 16:38
c: 2018.06,HEAD my @a; for 1.0 ... 3 -> $a { @a.push: $a }; dd @a
committable6 Zoffix, ¦2018.06: «Array @a = [1.0, 2.0, 3.0]␤» ¦HEAD(8bd3e50): «Array @a = [1, 2, 3]␤»
Zoffix ZOFFLOP: t/spec/S09-typed-arrays/native-int.t 16:40
Geth rakudo: 2af789d796 | (Zoffix Znet)++ | src/Perl6/Optimizer.nqp
Fix QAST crash in `for …` opt with Rats

Bug find: colabti.org/irclogger/irclogger_log...09-27#l369
We incorrectly assumed we'll always have a QAST::Want in places, but when Rats are involved, we get a QAST::WVal there instead.
Fix by watching for ::Wants explicitly		 16:42
roast: 3337a7d798 | (Zoffix Znet)++ | MISC/bug-coverage.t
Cover Rats in `for …`

Covers bug fixed in github.com/rakudo/rakudo/commit/2af789d796 and adds two fudges for a wrong-result-type bug yet to be fixed		 16:43
Zoffix (dibs on the other bug too :P)
travis-ci Rakudo build passed. Jonathan Worthington 'Improve array assignment inlinability 16:55
travis-ci.org/rakudo/rakudo/builds/434172352 github.com/rakudo/rakudo/compare/4...d3e5024b88
Zoffix .ask jnthn is it deliberate that the range of optimized values doesn't include the endpoints? I.e. that comparators are `>`/`<` instead of `>=`/`<=`? github.com/rakudo/rakudo/commit/1a...453281R893 16:55
yoleaux Zoffix: I'll pass your message to jnthn.
samcv i have tried adding a BOM for utf16 in method open but i'm having issues when we open for append github.com/samcv/rakudo/commit/e52...c2e4459ab8 17:19
if we open for append, i get self.tell() as 0 even when there is data in the file and it ends up writing more BOM. not sure if it only seeks in the file sometime later? though not sure what is going on here 17:20
i'll be gone for an hour and a half, but wanted to ask in case anyone sees this and knows what is going on
geekosaur on posix, it effectively seeks to the end first on every write 17:24
append doesn't mean "seek to end first", it means "all writes forced to be appended to the current end of file" 17:25
travis-ci Rakudo build passed. Zoffix Znet 'Fix QAST crash in `for …` opt with Rats 17:42
travis-ci.org/rakudo/rakudo/builds/434196785 github.com/rakudo/rakudo/compare/8...f789d796a2
timotimo that's how concurrent appends "work" i guess 18:02
geekosaur yep. there's also an atomicity guarantee if the write buffer is below some system dependent size 18:22
Zoffix ASDLK:>U<ASV LTRAYDSEhtgnsdfcb 18:28
Cannot look up attributes in a VMNull type object my ass
God, the 85+s compile time of rakudo is awful 18:30
TimToady samcv: perhaps check the filesize rather than the current location? 18:35
geekosaur fstat() is for a reason :)
Zoffix m: for 1, 2 ^… 10 {} 18:54
camelia 10
in block <unit> at <tmp> line 1
Zoffix wat
Zoffix R#2325 19:00
synopsebot R#2325 [open]: github.com/rakudo/rakudo/issues/2325 [LTA] Inconsistencies/bugs with parsing of excluded sequence op
TimToady how is it even printing that? 19:06
oh, it's the ... listop
TimToady m: say (1, 2 ^??? 10).perl 19:08
camelia 10
(1, one(2, 0))
in block <unit> at <tmp> line 1
Zoffix Ah, lol 19:08
TimToady istr that we decided excluding the beginning didn't make a lot of sense for ... due to ambiguity with how much of the initial list to exclude 19:09
TimToady but the failure mode is definitely a bit of a WAT 19:10
samcv TimToady: yeah we can do that too. i was just wondering what was happening 19:14
Geth rakudo: f8d91b9e22 | (Zoffix Znet)++ | src/Perl6/Optimizer.nqp
Fix wrong type of result in `for 1.5 … 2.5 {}`

The get_bound() coerces to Int, with which we could get away for opts like `for ^1.5`, but with the new opts, we have to be more strict in what we accept, or we generate an incorrect sequence.
Fix by typechecking the value we have is an Int, instead of coercing stuff. This de-optimizes things that where coercion was acceptable
  (e.g. doing `for ^1.5`).		 19:15
rakudo: 996742e507 | (Zoffix Znet)++ | t/08-performance/02-qast-rewrites.t
Cover new `for` opts
roast: 1065bc8156 | (Zoffix Znet)++ | MISC/bug-coverage.t
More cover for `for` opts

Rakudo fix: github.com/rakudo/rakudo/commit/f8d91b9e22
samcv TimToady: .tell doesn't seem to do anything until it actually writes bytes 19:19
geekosaur correct
wen you open the file you're at its beginning. 19:20
wen you write, the file offset si forced to the current end of file,t hen the write takes place
samcv yep
geekosaur if your'e open O_RDWR|O_APPEND, youan seek anywhere ad read, but the next write will again force the offset to the current end of file
this is for support of log files (including e.g. database transaction logs) 19:21
samcv yeah that makes total sense 19:22
Geth rakudo: 60d64e10a2 | (Zoffix Znet)++ | t/08-performance/02-qast-rewrites.t
Check `for ^10 .reverse {}` opt is done
 19:25
Zoffix TimToady: are you open to blessing an official alias name for the language for 6.d release? I'm gonna gather some of the suggestions I've seen, and hoping to do some marketing research to could perhaps advise the choice. This will be ready October 9th and if we do get an alias name, I want to know what it is in advance of the 6.d release, to prepare some brochures and stuff. 19:32
Geth rakudo: bab9a8d791 | (Zoffix Znet)++ | t/08-performance/02-qast-rewrites.t
Cover more `for` opts

Per github.com/rakudo/rakudo/commit/60...t-30680316		 19:34
lizmat Zoffix++ 19:35
Zoffix buggable: 6.d 19:37
buggable Zoffix, Diwali is in 40 days, which is 5 weeks, 4 days, 4 hours, 22 minutes, and 3 seconds. Need to review 125 commits per day (879/week) to complete. Need 2 teaser flyers. Still have 2 TODO features costing 8 hours. Still have 0.3 policies to write. Still have ~95% of ChangeLog to do.
Geth rakudo: 06dfbf0273 | (Elizabeth Mattijsen)++ | 2 files
BEGINnify nqp::getcurhllsym('default_cont_spec')

Because we don't need to look that up each time at runtime		 20:44
nige TimToady, just saw Zoffix mention the alias for the 6.d release. Here are some of the names I've collected: nigelhamilton.com/perl-branding-proposal.html 20:50
travis-ci Rakudo build passed. Zoffix Znet 'Cover more `for` opts 21:08
travis-ci.org/rakudo/rakudo/builds/434284315 github.com/rakudo/rakudo/compare/6...b9a8d79178
Geth rakudo: 8c4546bb58 | (Elizabeth Mattijsen)++ | src/core/array_operators.pm6
Make [42] use the new Scalar initialization setup

Completely inlines `for ^1_000_000 -> int $_ { [42] }` without any allocations whatsoever: 99.11% of frames got inlined in --profile.		 21:11
Zoffix hopes people won't all pile on on TimToady now 21:18
Zoffix We had over a year worth of discussion threads. They're all logged and will be presented. 21:19
AlexDaniel Yeah no need, I'm pretty sure Zoffix will do the best job possible at this
nige agreed - I hope the link above is helpful (that's all) 21:21
AlexDaniel it's nice to see this moving forward somewhat, Zoffix++
I'm also so tired with that issue that I'll take *any* alias. I hope others feel the same :) 21:27
nige (still hopes that TimToady would come up with one) 21:29
lizmat has expressed her opinion in the past and refrains from expressing it again as it hasn't changed 21:32
travis-ci Rakudo build passed. Elizabeth Mattijsen 'BEGINnify nqp::getcurhllsym('default_cont_spec') 22:06
travis-ci.org/rakudo/rakudo/builds/434314754 github.com/rakudo/rakudo/compare/b...dfbf0273cf
Zoffix AlexDaniel: same here. I'll take anything that isn't tied to perl 22:27
jnthn . 22:35
yoleaux 16:55Z <Zoffix> jnthn: is it deliberate that the range of optimized values doesn't include the endpoints? I.e. that comparators are `>`/`<` instead of `>=`/`<=`? github.com/rakudo/rakudo/commit/1a...453281R893
jnthn Zoffix: Umm...I can't immediately think of a reason. 22:36
I wonder if we can do it with 64-bit numbers even 22:37
Or at least, do that on MoarVM and JVM...I dunno about js in that reguard 22:38
MasterDuke ugh, i'm trying to rebase my wip range optimization to HEAD, it's not an easy merge 22:53

Powered by Cro and the Raku® Programming Language.

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

Thank you!