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.
00:19 dct left 01:19 coverable6 left, evalable6 left, unicodable6 left, quotable6 left, benchable6 left, statisfiable6 left, bloatable6 left, undersightable6 left, squashable6 left, greppable6 left, notable6 left, shareable6 left, nativecallable6 left, bisectable6 left, reportable6 left, committable6 left, releasable6 left, coverable6 joined 01:20 evalable6 joined, ChanServ sets mode: +v evalable6, undersightable6 joined, p6bannerbot sets mode: +v coverable6, committable6 joined, ChanServ sets mode: +v committable6, p6bannerbot sets mode: +v evalable6, nativecallable6 joined, ChanServ sets mode: +v nativecallable6, shareable6 joined 01:21 quotable6 joined, p6bannerbot sets mode: +v undersightable6, p6bannerbot sets mode: +v committable6, p6bannerbot sets mode: +v nativecallable6, p6bannerbot sets mode: +v shareable6, p6bannerbot sets mode: +v quotable6, benchable6 joined, ChanServ sets mode: +v benchable6 01:22 unicodable6 joined, ChanServ sets mode: +v unicodable6, bloatable6 joined, ChanServ sets mode: +v bloatable6, squashable6 joined, p6bannerbot sets mode: +v benchable6 01:23 p6bannerbot sets mode: +v unicodable6, p6bannerbot sets mode: +v bloatable6, notable6 joined, p6bannerbot sets mode: +v squashable6, bisectable6 joined, ChanServ sets mode: +v bisectable6 01:24 p6bannerbot sets mode: +v notable6, greppable6 joined, ChanServ sets mode: +v greppable6, releasable6 joined, reportable6 joined, ChanServ sets mode: +v reportable6, statisfiable6 joined, ChanServ sets mode: +v statisfiable6, p6bannerbot sets mode: +v bisectable6, p6bannerbot sets mode: +v greppable6 01:25 p6bannerbot sets mode: +v releasable6, p6bannerbot sets mode: +v reportable6, p6bannerbot sets mode: +v statisfiable6 03:33 Kaiepi left 03:34 Kaiepi joined 03:35 p6bannerbot sets mode: +v Kaiepi 03:58 squashable6 left 04:03 squashable6 joined, p6bannerbot sets mode: +v squashable6 04:06 Ven`` left 04:12 vendethiel- left 06:00 Kaypie joined, Kaiepi left 06:01 p6bannerbot sets mode: +v Kaypie 06:05 Kaypie left 06:06 Kaypie joined 06:07 p6bannerbot sets mode: +v Kaypie 08:32 patrickb joined, p6bannerbot sets mode: +v patrickb
Geth rakudo: JJ++ created pull request #2590:
Adds README.md to avoid deletion		 09:02
09:16 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci Rakudo build errored. JJ Merelo 'Merge branch 'master' of github.com:JJ/rakudo' 09:16
travis-ci.com/JJ/rakudo/builds/96442048 github.com/JJ/rakudo/compare/084b8...8392c46c41
09:16 travis-ci left 09:52 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci Rakudo build failed. JJ Merelo 'Adds README.md to avoid deletion 09:52
travis-ci.com/JJ/rakudo/builds/96442761 github.com/JJ/rakudo/compare/f1839...d5d818a983
09:52 travis-ci left
AlexDaniel lizmat: last week addded github.com/rakudo/rakudo/wiki/Ticket-updates 10:04
10:52 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci Rakudo build failed. JJ Merelo 'Follow @jnthn advice re #2590' 10:52
travis-ci.com/JJ/rakudo/builds/96449191 github.com/JJ/rakudo/compare/b0d5d...d7a51bf3af
10:52 travis-ci left
|Tux| Rakudo version 2018.12-165-g6d58e0b0b - MoarVM version 2018.12-19-gec8a240e3
csv-ip5xs0.935 - 0.953
csv-ip5xs-207.119 - 7.502
csv-parser21.974 - 22.397
csv-test-xs-200.435 - 0.441
test7.345 - 7.420
test-t1.818 - 1.867
test-t --race0.793 - 0.802
test-t-2030.511 - 30.736
test-t-20 --race9.535 - 9.537
 10:56
gfldex m: my $counter = 0; $counter++ for CORE::.values; say [$counter, CORE::.values.elems]; 10:59
camelia [229 758]
gfldex m: my $counter = 0; $counter++ for CORE::.values; say [$counter, CORE::.values.elems];
camelia [699 758]
gfldex why does that count so badly
and so randomly?
jnthn Hash randomization + the IterationEnd sentinel 11:00
Geth rakudo: b0d5d818a9 | (JJ Merelo)++ | 2 files
Adds README.md to avoid deletion

Because one could imply move the .gitignore thing to the general file, and this directory would be deleted. Also eliminated *.moarvm from it, since it's already in the general file.		 11:02
rakudo: 1cd7a51bf3 | (JJ Merelo)++ | 2 files
Follow @jnthn advice re #2590
synopsebot RAKUDO#2590 [closed]: github.com/rakudo/rakudo/pull/2590 Adds comment to avoid deletion
rakudo: 307ae381ea | (Jonathan Worthington)++ (committed using GitHub Web editor) | blib/Perl6/.gitignore
Merge pull request #2590 from JJ/master

Adds comment to avoid deletion
gfldex it's not just counting badly. If I iterate the list to output names of the types in CORE::, it never outputs all type objects and often stops really early.
and that used to work 11:03
lizmat gfldex: it stops as soon as it encounters IterationEnd
gfldex i see :)
lizmat m: say (1,2,IterationEnd,4,5)
camelia (1 2)
lizmat a case of DIHWIDT :-)
gfldex I shall find a workaround for that feature when I come back from $dayjob. 11:04
:->
lizmat m: say (1,2,IterationEnd,4,5).map: *.Str # perhaps ?
camelia (1 2)
lizmat ah no
grr :-)
gfldex It's been a while since I blogged so this is actually quite a welcome. 11:06
gfldex work &
jnthn I've considered making IterationEnd a special term and storing the actual implementation of it somewhere else, to avoid this. 11:27
11:34 robertle_ joined, p6bannerbot sets mode: +v robertle_ 11:36 Kaypie is now known as Kaiepi
Geth rakudo: 8ae4310e9d | (Elizabeth Mattijsen)++ | 2 files
Make Map/Hash.sort about 11x faster

  - instead of first generating a list of Pairs and sort on .key
  - create native str array of keys and sort that
  - then create Pairs on a new iterator on the native str array of keys
  - this delays the creation of Pairs until they're really needed
  - the removes the need unpack each pair to be able to sort
  - prevents unneeded Pairs from being created, e.g. %h.sort.head(100)
  - keep old logic for object hashes for now		 12:57
13:40 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Make Map/Hash.sort about 11x faster 13:40
travis-ci.org/rakudo/rakudo/builds/476345652 github.com/rakudo/rakudo/compare/3...e4310e9da2
13:40 travis-ci left
patrickb Hi everyone! 14:45
I'm (once again) working on relocatability of perl6.
jnthn o/ patrickb 14:47
yay :)
timotimo that does sound lovely
patrickb I think I arrived at the point that I have loads of questions and something working of which I don't know entirely why... 14:49
For a start: What is the --nqp-lib intended for? I currently just use it without really knowing what its intent is... 14:50
timotimo i'd expect for whenever you "use QAST:from<nqp>" or similar 14:51
oh, and parts of the compiler are written in nqp and thus use the nqp core setting for subs and such
patrickb Is it bad to give that parameter in the production perl6 runner? 14:52
timotimo does it work without it? if my assessment is correct, perl6 wouldn't work without it
patrickb It doesn't.
timotimo though tbh multiple of those paths should be able to be derived from just one path 14:53
patrickb The only place I know where rakudo makes use of the hard wired install path (that I know of) is: rakudo/src/Perl6/ModuleLoader.nqp:load_module()
And the logic using the hard wired path is overridden by --nqp-lib 14:54
My working version is in github.com/patzim/{MoarVM,nqp,raku...tree/reloc 14:57
Linux only. I haven't tried much, but simple scripts seem to work.
Some more design-y questions... 14:59
The way I currently do it is using bash in the runner scripts to determine the script folder and making all lib parameters relative to that path. 15:00
That puts the burden of the relocatability on the runner script.
The only alternative I see is to put the dynamic search for the core libraries into perl6 itself. That is complex though as there currently is no good way to determine the runtime path of a compiled script. So on the perl6 side one does not currently have a good way to determine a path to start working with. 15:02
And the runner script would still need to locate the perl6.moarvm file relative to its own location at least. 15:04
So is the approach of doing all of the actual relocatability work (i.e. determining the library paths dynamically) in the runner scripts a good idea? 15:06
timotimo do we have a bit of research written down anywhere how other langs do it?
patrickb I have looked into python.
But long story short: Most other langs don't have that problem
In the case of python: It's just a single binary. 15:07
timotimo none of them need to load a bunch of files, eh?
patrickb They do!
But they can just work from that executable files location.
That's exactly what python does.
I'll create a gist of my writeup... 15:08
give me a sec
timotimo in that case perhaps using the bash script as the "root" could be all right?
b2gills patrickb: I think that it would be preferable if the runner script was a compiled program (written in C maybe?) which uses the MoarVM library. There are several other problems associated with using a runner script. 15:11
timotimo right, that should be doable
patrickb gist.github.com/patzim/710baab43da...3b5b81c923 15:12
b2gills: I'm thinking about that too. But I'm not yet at that point. 15:13
timotimo, b2gills: The C replacement of the runner scripts, would you use libmoar.so directly or just call moar as the current runner scripts do? 15:16
15:17 squashable6 left 15:18 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Make Map/Hash.sort about 11x faster 15:18
travis-ci.org/rakudo/rakudo/builds/476345652 github.com/rakudo/rakudo/compare/3...e4310e9da2
15:18 travis-ci left
b2gills My guess (and it is only a guess) would be to use libmoar.so. That way there would be fewer steps to run a Perl 6 program. 15:19
patrickb Do we want to keep the ability to have a non-relocatable build?
timotimo you could even statically link libmoar 15:21
15:21 squashable6 joined 15:22 p6bannerbot sets mode: +v squashable6
patrickb also: The current runner scripts reference three library paths: $install/share/nqp/lib, $install/share/perl6/lib, $install/share/perl6/runtime. share/perl6/lib is empty in a clean install though. What libs would go there? Do we need that lib path? 15:27
15:28 brrt joined
jnthn timotimo: You can't do that until the extops are gone, I think... 15:29
15:29 p6bannerbot sets mode: +v brrt
timotimo d'oh, you're right 15:29
15:31 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Make Map/Hash.sort about 11x faster 15:31
travis-ci.org/rakudo/rakudo/builds/476345652 github.com/rakudo/rakudo/compare/3...e4310e9da2
15:31 travis-ci left
patrickb timotimo: Did you have a look at my small write up? 15:31
lizmat just restarted two jobs that had failed
jnthn: ^^^
timotimo patrickb: yeah, good starting point i'd say 15:34
i wonder if pypy does anything very specific different there
m: use nqp; say(nqp::p6reprname("hi")) 15:35
camelia P6opaque
timotimo m: use nqp; say(nqp::reprname("hi"))
camelia P6opaque
timotimo oh, 2018.08's changelog says p6reprname was turned into a desugar, eh?
timotimo looks at removing p6reprname from perl6_ops.c 15:36
patrickb Do we want to keep the ability to have a non-relocatable build? 15:38
timotimo "ability" :D 15:39
lizmat patrickb: I don't think anybody thought of that as a feature, but I might be wrong
timotimo i mean, i guess
15:40 brrt left
patrickb Well, we rely on non-relocatability in the runners that are used during build. 15:40
The feature of non-relocatability is that you can move the executable around independent of the installation location and it keeps working. 15:41
b2gills patrickb: I'm sure the only reason it is non-relocatable is because it was easier.
patrickb The runners during build could be replaced with environment variables to pass in the correct lib paths though... 15:42
So can I take this as a "Yes, we do not need any nonrelocatability!" 15:43
15:43 brrt joined
b2gills I say do [ what you want | what is easier ]. If it turns out to be a problem it could be dealt with later. 15:43
15:44 p6bannerbot sets mode: +v brrt
patrickb OK. I take the missing protest as a confirmation. :-) 15:44
timotimo the C-based runner could switch modes based on the presence of --blah-path flags 15:48
so it could be called directly to use its relocatable mode, or from a script just like what we currently have as "moar"
patrickb timotimo: True. That might work. 15:49
Given I'll introduce environment variables to specify the install paths, what should I call them? $PERL6_NQP_LIB, $PERL6_RUNTIME_LIB, $PERL6_LIB?
lizmat these are specific for the MOARVM backend, are they not ? 15:50
patrickb Or should I assume we have a stable file layout and go for: $PERL6_INSTALL_PATH
lizmat if they are specific to MoarVM, I guess s/PERL_6/MVM/ ? 15:51
patrickb Well, these aren't really MoarVM specific. Perl6 being build in NQP requires the NQP libraries. That should be the same on all backends. 15:52
lizmat then not :-) 15:53
patrickb What about: $NQP_HOME and $PERL6_HOME which should point to /share/nqp and /share/perl6 respectively? 15:54
timotimo we're already putting both moar and jvm stuff in the same paths, aren't we? 15:55
maybe it'd be good to make the perl6 home easier to share between different impls
15:58 brrt left
patrickb that would mean using $NQP_HOME and $PERL6_HOME 15:58
Since then I don't imply anything about what's in those folders 15:59
timotimo and PERL6_HOME could be used for (currently theoretical) other implementations 16:00
patrickb Should that be $RAKUDO_HOME or $PERL6_HOME? 16:01
timotimo maybe check both and prioritize RAKUDO_ over PERL6_? i'm barely doing better than bikeshedding right now %) 16:02
16:03 Kaiepi left 16:04 Kaiepi joined 16:05 p6bannerbot sets mode: +v Kaiepi, squashable6 left
patrickb I think $RAKUDO_HOME makes more sense actually, since multiple implementations would very likely not install into the same location... 16:05
But then the folder is actually called install/share/perl6/. Ugh! 16:06
timotimo that's the idea behind making the layout suitable for putting different compiler's stuff in the same base path 16:07
patrickb So the idea is that multiple implementations can put their stuff in share/perl6/? 16:08
timotimo right
patrickb Is that also what cpython/pypy do?
timotimo not sure about that
16:09 squashable6 joined, ChanServ sets mode: +v squashable6
patrickb So $PERL6_HOME (-> install/share/perl6) and $NQP_HOME (-> install/share/nqp) it is. Any objections? 16:09
16:09 p6bannerbot sets mode: +v squashable6
patrickb has learned how to ask questions on $perl6-dev without having to wait for answers long. 16:10
timotimo haha
patrickb There is no reason for the RPATH of moar to not be relative to the executable, right? 16:23
I.e. it is fine to just switch it over to be relative and be done with it. 16:24
mornfall i don't think that's possible? 16:25
16:25 hankache joined, p6bannerbot sets mode: +v hankache
mornfall there's $ORIGIN, but it's not universally supported IIRC 16:26
16:26 Ven`` joined
timotimo i don't know where RPATH comes from 16:26
16:26 p6bannerbot sets mode: +v Ven``
Geth rakudo/more-block-flattening: 19e4ace62d | (Jonathan Worthington)++ | src/Perl6/Optimizer.nqp
Move optimization level check a level up

So we do a bit less work if it's below that level.		 16:28
rakudo/more-block-flattening: fcfd51beba | (Jonathan Worthington)++ | src/Perl6/Optimizer.nqp
Account for the nqp::handle body getting thunked

It's not just the handlers that do, but also the handled code.
16:33 lizmat_ joined, p6bannerbot sets mode: +v lizmat_
patrickb mornfall: $ORIGIN is not universally supported? Do you know some place to read up on this? 16:35
16:35 lizmat left, lizmat_ is now known as lizmat
timotimo we're only limited by the maximum size of the environment :P 16:39
mornfall patrickb: something about -z origin needed on macos, and i don't think openbsd supports origin at all? i can't find any standard-ish document describing it anyway 16:41
(freebsd should have it and it presumably works as on glibc's ld.so)
Geth rakudo/more-block-flattening: 541a4f1628 | (Jonathan Worthington)++ | src/Perl6/Optimizer.nqp
More aggressive scope flattening

Previously, we would only ever flatten away lexical scopes if we saw that there were no declarations inside of that scope, the only special case being `$_`, which was handled specially. There was also some special mechanism in place to try and handle topic rebinds correctly.
... (24 more lines)
timotimo nice to see -^ 16:42
patrickb mornfall: I'll peek into python to see how they do it... 16:43
jnthn timotimo: Yeah, though for some reason I need to look in to, not immediately good for benchmarks. 16:46
timotimo in any case, p6reprname at least can go from the perl6_ops 16:52
jnthn D'oh, I did a thinko 17:07
And probably can easily get back the lost perf.
17:08 hankache left
Geth rakudo: 7229c674ab | (Timo Paulssen)++ | src/vm/moar/ops/perl6_ops.c
Remove Unused p6reprname Ext-Op For MoarVM

it has been turned into a desugar in the compiler a few months ago already, just not deleted from this file yet.		 17:14
rakudo: b4d114a312 | (Elizabeth Mattijsen)++ | src/core/Map.pm6
Streamline Map.gist

  - makes it about 20% faster still
  - together with the Map.sort improvements now 2.5x as fast
  - on a 500 element Map		 17:17
rakudo: edb5308155 | (Elizabeth Mattijsen)++ | src/core/Map.pm6
Remove unnecessary comma
nine There has also been a decodelocaltime op in MoarVM for quite a while
17:19 patrickz joined 17:20 p6bannerbot sets mode: +v patrickz 17:22 patrickb left
Geth rakudo: f010ef57a4 | (Elizabeth Mattijsen)++ | src/core/Rakudo/Internals.pm6
There is a nqp::decodelocaltime

So I think that means we can get rid of nqp::p6decodelocaltime		 17:23
lizmat nine timotimo ^^^
m: nqp::decodegmtime(time) # alas :-)
camelia 5===SORRY!5=== Error while compiling <tmp>
Could not find nqp::decodegmtime, did you forget 'use nqp;' ?
at <tmp>:1
------> 3nqp::decodegmtime(time)7⏏5 # alas :-)
lizmat m: use nqp; nqp::decodegmtime(time) # alas :-) 17:24
camelia ===SORRY!===
No registered operation handler for 'decodegmtime'
patrickz java seems to rely on $ORIGIN too 17:35
on 64bit linux that is
python by default does not need a separate library 17:36
17:40 robertle_ left
Geth rakudo/more-block-flattening: d2df5b805d | (Jonathan Worthington)++ | src/Perl6/Optimizer.nqp
Correct tracking of vars used in `handle` handler

We need to propagate information about this outward. A previous fix for this issue actually wasn't a real fix, and just pessimized enough in order to not run into the real problem. This fixes it properly, gaining back lost performance.		 17:44
patrickz mornfall: My little research revealed: -z origin is required on openbsd to work, but then seems to do what it should... 18:02
Any objections for me to just go that route and just see where it'll break afterwards? 18:04
AlexDaniel patrickz++ 18:23
18:59 Ven`` left 19:24 dct joined, p6bannerbot sets mode: +v dct
patrickz Any idea why Perl6/BOOTSTRAP can't be loaded like any other module in rakudo/src/Perl6/ModuleLoader.nqp load_module() ? 19:59
lizmat not much will function without it in Perl 6 20:17
patrickz I seem to have been able to work around it. The code will definitely need a review of someone knowledgeable of that area... 21:30
21:31 ExtraCrispy left
lizmat where are you trying to load it, and why ? 21:38
21:43 ExtraCrispy joined, p6bannerbot sets mode: +v ExtraCrispy 21:46 patrickz left

Powered by Cro and the Raku® Programming Language.

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

Thank you!