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.
samcv japhb: ah i see it does. ok nevermind then 00:08
sounds like we could do that then
samcv ok i don't understand this in docs.perl6.org/type/IO::Handle :exclusive means .open will fail if the file already exists 07:14
:x same as specifying :mode<wo>, :create, :exclusive
ok so it fails if the file exists, but you are opening it for read? 07:15
err write sorr
i was misreading hah. nevermind
Geth rakudo/js: 5fe0140cfd | (Paweł Murias)++ | src/core/Str.pm6
[js] Make new comb variant support NFG
 09:17
Zoffix spectest just hung on me on my home box (been ages since I ran one on this box, so no idea if that's a recent phenomenon). Doesn't show any failed test files. Just sat there until I hit CTRL+C and then said everything successful 10:37
Zoffix tries again
lizmat Zoffix: see if there are any "moarvm" processes still running, and then kill those (gently) 10:38
you might find out which one was hanging then
Zoffix "kill those (gently)"... Programmers have the strangest of phrases :D 10:39
lizmat I mean: not kill -9 10:42
jnthn
.oO( killing me softly with SIGTERM )
ilmari jnthn++ 10:43
Zoffix no hang this time 10:47
It got scared of all the kill talk :P
lizmat :-) 10:48
Geth rakudo: 49baea7009 | (Elizabeth Mattijsen)++ | src/Perl6/Optimizer.nqp
Refactor the "for range/sequence { }" optimization

  - generalize it to a flexible step
  - less mixing up of what's the start and end of the loop
  - should make it easier to allow for "for 1,3...10 { }" optimization		 10:58
dogbert2 where is [Tux]? 11:42
lizmat [Tux] is offline until much later today for $work at client 12:04
pmurias jnthn: on the js backend for performance reasons (it's slow enough already :( ) I use NFG semantics for ops in only some places 12:18
jnthn: it has for example nqp::substrnfg and nqp::eq_snfg op variants 12:19
jnthn: currently I'm inserting them using #?if !js #?endif and #?if js #?endif 12:20
jnthn: but I feel if I want to merge those will become an annoyance to maintain
jnthn Depends how widespread they are; I can't believe we're touching such primitives as eq and substr very often... 12:21
pmurias jnthn: do you think marking them at use would be acceptable? 12:22
so we had some form that would processed into nqp::substr on moar and nqp::substrnfg on the js
jnthn But...when *don't* we want NFG semantics? 12:23
pmurias on the moar backend we want them everywhere 12:24
jnthn In Perl 6 we want them everywhere :P
Maybe one way would be to map substr in the Perl 6 ops to the NFG impl, and substr in NQP to the cheating one?
jnthn Ops are already possible to override by HLL 12:25
pmurias I'll have to think that over 12:27
regex on js backend work on the cheating offsets semantics so I sometimes want to use cheating ops when interacting with them 12:28
Geth rakudo: 8978702888 | (Elizabeth Mattijsen)++ | src/Perl6/Optimizer.nqp
Optimize "for 1,3...9" and "for 9,7...1"

A little more introspection allows those cases to be handle by the
  "for ^10" optimization as well. Makes these sequences a *lot* faster:
for 1,3...999999 about 150x. Of course, smaller sequences will profit less.		 12:38
dogbert2 jnthn: do you have any additional opts up your sleeve? 12:40
jnthn Well, loads of ideas, at least. :-) Probably none coming today, alas; got some other things I should work on :) 12:43
jnthn happily notes that everything he's currently working on is either written in Perl 6 or written for Perl 6... :) 12:44
lizmat afk until very late& 13:03
pmurias jnthn: other thought from yesterday, what would it take use if statements instead of the horrible nqp::if(...) in the setting? 13:28
would a pragma to stop the implicit variables $_ from being created be enought to do that without a performance penalty?
pmurias hmm, a pragma could do that without depending on the optimizer... 13:34
Zoffix pmurias: but isn't it the new scope that's the bigger issue and not the $_ or other magic vars in a block? 13:44
pmurias: FWIW, `… if 42` does get converted to a basic `nqp::if` already
timotimo && also gets converted to nqp::if as well, if i'm not mistaken 13:45
Zoffix Yes, and || to nqp::unless
and // to nqp::defor 13:46
pmurias Zoffix: I assumed the optimizer can remove the scope but it seems to leave the magic vars in
Zoffix: but the pragma could just avoid the scope from being created 13:47
timotimo it can only remove the scope under certain circumstances
like "no lexical variables defined in there that other scopes close over, or that are prevented from turning into locals some other way" 13:48
Zoffix pmurias: the way you describe it sounds like a nicely gun-shaped footgun. i.e. devs adding variables or something else inside the braces and not noticing some pragma above that effectively disables the braces
I'd say it doesn't really solve the readability issue with nqp::if's 13:49
The pragma I mean, not auto-optimization.
Zoffix &
pmurias why doesn't it solve the readaiblity issue?
Zoffix pmurias: because you have to read the pragma along with the block to understand the program. 13:50
I don't see how that's better than simply using a comma instead of a `;` to end statements.
Which is what nqp::if( comes down to,r eally
[TuxCM] Rakudo version 2018.09-40-g897870288 - MoarVM version 2018.09-90-gb5eb48c2e
csv-ip5xs-207.639 - 8.213
csv-parser21.051 - 21.449
csv-test-xs-200.431 - 0.432
test7.713 - 8.218
test-t1.823 - 1.854
test-t --race0.821 - 0.855
test-t-2032.906 - 33.130
test-t-20 --race11.766 - 12.023
 13:51
dogbert2 hmm, now new record today then :( 13:53
pmurias we would have something like nopaste.xyz/?753ef02b7e22a3ba#V7hL...LgHphb6To= vs nopaste.xyz/?517450f12f7b150f#VoS/...oMrzfkE2E= 13:58
the nqp::isge_i could be turned into >= but that's a separate issue 13:59
so less like crap 14:04
(no offense towards whoever wrote the example piece of code that's just what nqp::ifs look like ;) ) 14:05
patrickb Hey! I'm still looking into making perl6 relocatable. Following some thoughts about that. 14:20
Relocatable p6 requires determining the installation path at runtime. 14:21
patrickb $*EXECUTABLE is no good way to retrieve the installation path, because creating a symlink to the perl6 executable already breaks that path. 14:21
patrickb The only way I can think of is to use the path of the executable (moar.exe / main.jar (Is it called that way on JVM?)) and work from there. 14:22
patrickb Google tells me retrieving the location of the current executable in C requires quite a lot of platform specific special casing (stackoverflow.com/a/933996/1975049). 14:23
Given I've implemented the logic to retrieve the installation path in all the backends, then I'd need a way to communicate that to the HLL. Would a new NQP op be the right way to do that?
Or is there another way to get to the install path in the frontend that is readily available? 14:24
Ulti yup if you're being generous to Perl 5 14:26
Ulti ^ that moment you realise you are about a week back in the log 14:26
patrickb Ah! Was just starting to wonder. :-P 14:27
timotimo patrickb: maybe binding an hll symbol is simpler, check bindhllsym and ... curhllsym i guess? for that 14:42
ah, gethllsym, bindhllsym and if you just want to use the current hll, that's getcurhllsym and bindcurhllsym 14:43
patrickb Binding HLL symbols is what makes the special $* (e.g. $*PROGRAM) variables work? 14:44
timotimo no, that's the sub DYNAMIC in the core setting i'd expect 14:45
hll symbols are basically a plain-old hash that gets accessed with a specific API and that is bound to the HLL (which sometimes changes, like between nqp code and perl6 code)
P6EX is one example of an hllsym being used 14:46
timotimo BBL
pmurias patrickb: a new op seems like an ok solution 14:49
patrickb: the problem with binding a HLL symbol is that you would have to hardcode a HLL 14:50
Zoffix pmurias: but where's the pragma you mentioned that would have the block be ignored? 15:02
jnthn pmurias: It largely just needs the static optimizer to be a bit smarter/more aggressive, which is something I'm going to need soon anyway to make the upcoming PEA stuff more effective 15:03
No hacky weird pragmas, please. We already *have* a workaround, we ain't going to be adding workarounds to workaround the workaround :P 15:04
Zoffix Yes, +2 for no hacky weird pragmas
pmurias: it's this: gist.github.com/zoffixznet/d97470f...0e52ce5660 vs. gist.github.com/zoffixznet/abfcceb...c94229fe0b 15:05
pmurias: the block version may be easier to read, but the pragma is very easy to miss.
The NQP version is nice and neat :)
jnthn Once we can lower normal assignable lexical variables to locals (for now it's restricted to parameters and bound variables) then I think we'll be able to flatten a lot more scopes.
Plus $_ becoming a simple lexical from 6.d onwards will probably also help 15:06
patrickb commute& 15:09
pmurias jnthn: if the optimizer can handle it better that way 15:10
jnthn hah, OK, maybe there is going to be one more optimization today :) 16:02
jnthn I spotted that the attribute scalar assignment in BUILDALL wasn't using the assignment spesh plugin. That's seemingly worth a lot. 16:06
diakopter 90% a lot? 16:08
jnthn m: say 0.79 / 1.1 16:08
camelia 0.718182
jnthn 1.26x as fast as Perl 5.22 on my machine 16:09
diakopter u should add a gofaster op to moarvm 16:10
pmurias is the jvm backend supposed to be building? 16:10
a recentish commit removed the call to nqp::p6settypes and the jvm backend still uses it 16:11
Geth rakudo: 14fa3b6963 | (Jonathan Worthington)++ | src/Perl6/World.nqp
Use spesh plugin for BUILDALL assignments

This gets an assignment-using benchmark running in 72% of the time it used to take, which is a surprisingly large win.
jnthn pmurias: oops...
I wonder if that was me, but I don't think so...
de4e82259 16:12
nine: ^^ :)
pmurias is working on reparing that 16:13
jnthn pmurias++
pmurias js is still using that, and the jvm backend should hold out bit till the truffle one is ready ;) 16:14
diakopter jnthn: I'm curious about an NQP version of the benchmark vs p5 16:16
Zoffix My NQP version is loads slower than p6 version :P gist.github.com/zoffixznet/55c8198...ec7c61afde 16:26
Zoffix p5.20 is 2.71x as fast than nqp and 1.2x as fast as p6 16:27
That's on 2018.09-35-g2fd8ffe
jnthn Zoffix: At lesat the p6 case should now be better on HEAD :) 16:29
Zoffix gets some HEAD 16:30
Zoffix And nqp case is slower because it ain't got spesh plugins in use? 16:31
jnthn Probably 'cus its BUILDALL isn't code-gen'd 16:32
Zoffix Aye, this version runs in 0.243s on HEAD: gist.github.com/zoffixznet/90c3c48...4d1a3e6c49 vs 4s for the other one 16:34
Zoffix the diff between p6 and p5 is within noise now on HEAD 16:36
jnthn++ this is pretty amazing!
jnthn Only within noise on your machine? Darn. 16:36
I like my machine better. :P 16:37
Zoffix :D
Zoffix m: dd (1.742 + 1.781 + 1.703 + 1.739)/4 - (1.715+1.751+1.756+1.706)/4 16:38
camelia 0.00925
Zoffix p6 is 9ms slower than p5 on average :)
I guess the actual code is faster, given how much slower our startup time is? (I'm measuring with `time`)
jnthn Yes, if our startup time was less that'd help too 16:39
Zoffix jnthn: I really hope there will be a nice blog post at the end of these optimizations :)
jnthn My measurements are with a harness, but yes, they incldue startup
I'm thinking more of a bunch of smaller blog posts covering the individual optimizations 16:40
Zoffix Great.
jnthn just discovered a useless sink operation was being done on some nosink-marked nodes...like, every void-context array and hash assignment
spesh inlines those into approximately nothingness, alas, so it's not a huge win
But still, smaller code and faster pre-spesh 16:41
Geth rakudo: 2136e73521 | (Jonathan Worthington)++ | src/Perl6/Actions.nqp
Don't wrap nosink-marked nodes with a sink

This gets rid of the sink operations that were bogusly being placed on `@a[1] = 42` and `%h<k> = 42` assignments.		 16:42
ilmari poor github.com/a, their notifications must be a mess 16:44
dogbert11 jnthn: can you see anything obvious here? gist.github.com/dogbert17/ac5834e7...2aef653be9 16:45
Zoffix :)
dogbert11 a possible clue is that I can't repro if MVM_JIT_DISABLE=1 16:46
jnthn dogbert11: Nothing obvious, no 16:56
jnthn Hm, found a case of seemingly mis-aggregated statistics leading to some bad decision making in array assignment...guess that can be tomorrow's mystery or something 17:03
patrickb *back 17:10
jnthn afk 17:10
patrickb I'd like to have some outside opinion on my current approach of relocatability in p6. In short: Add an op that returns the installation path determined via the executable path (moar). Then make use of that op in nqp / p6 to locate stuff. (Probably by setting config<prefix> and config<libdir> or something). 17:20
Is that a viable approach? Better ideas?
pmurias patrickb: seems viable 17:21
pmurias patrickb: did you conisder determining the installation path based on the path to the moar file that's being executed (not saying it's a better idea) 17:23
s/conisder/consider
patrickb pmurias: That's what I want to do.
pmurias patrickb: I mean the .mbc file (not expressing myself clearly) 17:24
patrickb hm...
patrickb you mean share/perl6/runtime/perl6.moarvm ? 17:26
The path to that file is currently passed to moar from a wrapper script. 17:27
And when running nqp it's a different file.
pmurias just a random suggestion, on rakudo.js I load stuff relative to rakudo.js because the node can be in some random location 17:29
patrickb Then one could implement that op differently on JS. 17:31
The idea is that the op returns the installation path, not the path to the executable. 17:32
pmurias patrickb: seems sane 17:45
Geth rakudo: ddb5f8fc4a | (Paweł Murias)++ | src/Perl6/Metamodel/BOOTSTRAP.nqp
Put in nqp::p6settypes on not moar backends

This reverts parts of commit de4e82259be36ac9c97b56d594591ea796a1b131.		 17:57
patrickb afk 17:59
nine pmurias: thanks again for fixing up my mess! 18:51
pmurias is src/core/ShapedArray.pm6 autogenerated? 18:57
[Coke] don't think so 19:00
jnthn I think *something* to do with shaped arrays is now
nine src/core/native_array.pm6 is auto generated 19:02
Zoffix pmurias: I think the numberd files are. There are a bunch of scripts in build: ~/R/rakudo (master)$ ls tools/build/make* 19:14
oR MAYBE it's just native
samcv question. it seems we default to uppercase hex in all cases except with buffers 19:25
samcv m: "hello".encode('utf16').say 19:26
camelia utf16:0x<68 65 6c 6c 6f>
samcv m: "hello".encode('utf16')>>.base(16).say
camelia (68 65 6C 6C 6F)
samcv but .base and others will use uppercase. this may or may not be intentional
Zoffix vaguely recalls consistifying this somewhere; or maybe there was a ticket 19:28
Geth rakudo/js: 224 commits pushed by 17 authors
review: github.com/rakudo/rakudo/compare/5...2ca5bd3d8b		 20:17
pmurias Zoffix: github.com/perl6/roast/blob/master...rat.t#L492 works by accident 21:43
Irrational.new uses div_I to box an numbers as UInt which would fail if div_I didn't do caching
because nqp::div_I can't box the result as UInts under normal circumstances 21:44
lizmat weekly: cry.nu/perl6/adding-and-improving-...in-moarvm/ 23:38
notable6 lizmat, Noted!

Powered by Cro and the Raku® Programming Language.

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

Thank you!