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:03 dogbert17 left
ugexe bartolin: looks like the config revamp might have missed asmtree or jna 00:04
01:09 AlexDani` joined 01:14 AlexDaniel left 01:34 Kaiepi left 02:38 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined 02:43 Kaiepi joined
Kaiepi i may have optimized feed operators by 800% 02:43
praying make test and make spectest pass
they also work with lazy lists with the changes i made 02:45
MasterDuke cool
Geth rakudo: Kaiepi++ created pull request #2896:
Optimize feed operators and make them work with lazy lists		 04:58
Kaiepi \o/ 04:59
05:08 epony left 05:17 releasable6 left 05:21 releasable6 joined
bartolin ugexe: yeah, I think it's jna that was missing. I intended to add it back with github.com/perl6/nqp/commit/aac9f52958 but I missed the new submodule. This should fix it: github.com/vrurg/nqp-configure/pull/4 05:27
^^ vrurg
05:32 robertle left 05:41 epony joined
gfldex MasterDuke: --optimize=0 does not help. 05:58
Geth rakudo: ea94966da3 | usev6++ | 2 files
Require Java 9 for JVM backend
 06:02
06:20 AlexDaniel left
bartolin hmm, travis fails to install oracle-java9-installer. so the jvm builds will fail early. maybe we need to add 'language "java"' to the travis config. I won't have time to look into this, probably. but since failures with the jvm builds are allowed, I hope this doesn't cause any trouble 06:23
or maybe we could change the dist from trusty to xenial? from what I read xenial comes with java 11 by default. If no-one objects, I'd like to try that out later today or tomorrow. 06:29
blog.travis-ci.com/2018-11-08-xenial-release
07:15 robertle joined
discord6 <Vendethiel> Kaiepi: Super excited to see this go through! I’m a big fan of the feed operators and them getting that much faster is just great 07:23
Kaiepi :) 07:26
lizmat Files=1262, Tests=107941, 412 wallclock secs (30.15 usr 7.39 sys + 2922.39 cusr 260.76 csys = 3220.69 CPU) 07:44
08:01 patrickb joined
timotimo Kaiepi: the equivalent code works differently fwiw; if you give the @ variable a name and output its .elems at the end, you get different results 08:25
lizmat hmmm... where does the rakudo.org repo live ?
timotimo github.com/perl6/rakudo.org
lizmat aaah
timotimo probably because of ease of contributing to the perl6 org compared to rakudo? 08:26
Kaiepi: can you test the two code pieces with your changes as well and see if the elems counts are the same respectively? 08:27
Kaiepi timotimo, i get 100 for both
timotimo timo@schmand ~> perl6 -e 'my Instant $b = now; my @a <== map { $_ ** 2 } <== 1..100 for 1..10000; say @a.elems' 08:28
1000000
Kaiepi oh whoops
timotimo of course that could be a bug :) 08:31
Kaiepi moving the `my @ <== map { $_ ** 2 } <== 1..100` to its own sub still runs faster than `my @ = (1..100).map({ $_ ** 2 })`, though not to the same degree 08:33
6.7806517s vs. 7.0336823s
timotimo is just putting parenthesis around it the same? 08:34
Kaiepi no
it still outputs 1000000 elems
timotimo parenthesis before "my" and before "for"?
Kaiepi (my @ <== map { $_ ** 2 } <== 1..100) for 1..100000 08:35
i'll need to benchmark again on HEAD
i'll try upping the loop to 100000 for better results 08:38
timotimo, is this code accurate? hastebin.com/ejuritoban.coffeescript 08:52
actually i don't see anywhere where the two ways of generating the list could differ in this so i'll go ahead and comment on the pullreq 09:08
lizmat hmmm... me just had a hang on "ok 76 - No hang or crash using react to consume channels" in t/spec/S17-supply/syntax.t 09:40
of course, cannot reproduce :-(
Geth rakudo: ec97878005 | (Elizabeth Mattijsen)++ | 2 files
Fix List.perl for lazy lists

  - fixes #2892
  - now shows first 100 elements of lazy list, like with .gist
  - postfixes .lazy for lazy lists
  - removed hack from dd for handling lazy lists		 10:03
synopsebot RAKUDO#2892 [open]: github.com/rakudo/rakudo/issues/2892 dd fails on lazy lists
rakudo: lizmat self-assigned Change order in USAGE when %*SUB-MAIN-OPTS<named-anywhere> is set github.com/rakudo/rakudo/issues/2246
b9f899541b | (Jonathan Worthington)++ | src/Perl6/World.nqp

This situation could occur in the case of a begin-time EVAL that had a code expression that contained an immediate QAST block. This led to the failed $_ lookup reported in #2779, meaning that compilation of that module no longer fails. Unfortunately, that isn't enough to make it actually work, but it's a step closer.		 10:08
10:44 brrt joined 10:50 brrt left 10:55 brrt joined
|Tux| Rakudo version 2019.03.1-392-gec9787800 - MoarVM version 2019.05-7-gf8743c112
csv-ip5xs0.727 - 0.734
csv-ip5xs-205.818 - 6.024
csv-parser20.948 - 21.257
csv-test-xs-200.424 - 0.431
test6.878 - 6.975
test-t1.693 - 1.733
test-t --race0.778 - 0.792
test-t-2029.081 - 29.672
test-t-20 --race9.025 - 9.069
 11:06
12:29 squashable6 left 12:33 squashable6 joined 12:52 brrt left
vrurg AlexDaniel`: ping? 13:36
.tell AlexDaniel` VERSION is in tools/templates; the submodule isn't in Perl Foundation because I had no access to it. I wish to see it under perl6. 13:52
yoleaux vrurg: I'll pass your message to AlexDaniel`.
13:55 brrt joined 14:01 skids joined
synopsebot RAKUDO#2779 [open]: github.com/rakudo/rakudo/issues/2779 [ecosystem modules] Regression in WWW
rakudo: d4afd48054 | (Elizabeth Mattijsen)++ | t/02-rakudo/11-deprecated.t
Remove PREVIEW as instructed in comment

Fixes #2866		 14:23
synopsebot RAKUDO#2866 [open]: github.com/rakudo/rakudo/issues/2866 Are tests for version deprecation correct?
15:04 brrt left 15:08 brrt joined 15:15 patrickb left 15:17 robertle left 15:35 brrt left 16:02 brrt joined 16:46 robertle joined 16:57 vrurg left 17:06 TimToady left 17:21 brrt left 17:22 vrurg joined
gfldex Could somebody run gist.github.com/gfldex/dc47e3c4981...0f3e6b7b5e and check if this is reproducible? 17:57
lizmat Cannot invoke this object (REPR: Null; VMNull) 18:02
in method <anon> at /Users/liz/Github/rakudo.moar/gfldex/warn-in-add_method.pm6 (warn-in-add_method) line 2
in block <unit> at warn-in-add_method.p6 line 7
gfldex: that what you mean ?? ^^
gfldex lizmat: tyvm, thats the one
vrurg Cannot invoke this object (REPR: Null; VMNull)
Is it the line number which matters? Because for me it's 6 18:03
lizmat: BTW, can you review R#2852 18:04
synopsebot R#2852 [open]: github.com/rakudo/rakudo/pull/2852 Add revision 6.e and improve multi-revision support
vrurg ?
lizmat vrurg: will try, am pretty unfamiliar with that piece of code 18:05
vrurg lizmat: I'm only worried if CORE.<letter>.setting loading order is correct. 18:06
lizmat vrurg: sorry, don't feel confident to judge that... have asked jnthn to do a review 18:08
gfldex filed as #2897 18:09
vrurg Thanks! AlexDaniel pointed me in your and jnthn direction.
gfldex Is there a price for funky bugs? :->
vrurg has lost count of 'cannot invoke this object' bugs encountered... 18:10
:(
lizmat fwiw, I think masak already has that trophy :-)
gfldex I can't argue with that. :) 18:11
vrurg lizmat: I would also like to ask for commit access. Have signed and sent CLA yesterday. 18:22
lizmat vrurg: cool! as soon as we get the green light, someone will give you access 18:23
which won't be me, as I don't have that power
vrurg jnthn then. Who has the power of creating new repos in perl6? Anyone with commit ability? 18:25
Because nqp-configure repo must be moved under perl6. 18:26
lizmat I think moritz can do that (also) 18:59
Geth rakudo: b5d529c7e9 | (Elizabeth Mattijsen)++ | src/core/Exception.pm6
Create exception for illegal uses of Junctions
 19:01
rakudo: 358d59fdae | (Elizabeth Mattijsen)++ | 2 files
Don't allow junctions as keys for Hash/Map initializations

In light of #2865
synopsebot RAKUDO#2865 [open]: github.com/rakudo/rakudo/issues/2865 All Junctions behave the same when used to define a hash key
19:02 brrt joined
lizmat just added #2899 19:25
vrurg: #2898 looks to be lacking information ? 19:26
vrurg lizmat: Accidentaly pressed enter while typing subject. 19:27
Filling in with information right now.
lizmat [okidoki
vrurg But that's really weird case. To fire it requires both nested loops and threads put together. 19:28
Kaiepi for my feed operators pullreq, while i was looking through the ecosystem for modules that would break, i found that my changes break using feed operators to assign to hashes 19:29
to fix this, i could call the STORE method instead of binding, but that's slow
how should i approach this?
use STORE only for vars that are Associative? 19:30
lizmat github.com/rakudo/rakudo/issues/2899
I think we need to look at feed operators more thoroughly
I think they were largely missed during the GLR
Kaiepi looks like i opened a can of worms 19:31
<<== and ==>> are still unimplemented
lizmat yeah, can of something is right :-)
the implementation of feed operators also predates any concurrent operations afaik 19:32
vrurg "Hello my friends! My name is Pandora and this is my first post of my unboxing videoblog"...
lizmat Kaiepi: by changing 'append' to 'STORE' in Actions, I get 1 spectest fail + 3 TODO's passed 19:35
Kaiepi with my branch or master? 19:36
testing on my branch i get one failure, but that's the lazy list one and that's supposed to fail with these changes 19:42
lizmat on master 19:43
afk& 19:48
vrurg lizmat: what does GLR abbreviation means? 19:50
gfldex vrurg: Great List Refactor 19:57
vrurg gfldex: thanks!
20:08 ufobat__ joined 20:10 brrt` joined 20:12 brrt left, ufobat_ left
Kaiepi i think i'll be changing my pullreq to "make feed operators rfc compliant" 20:13
since implementing <<== and ==>> from a cursory glance at the rfc is really simple
i'll need to read it more thouroughly though 20:14
no clue how to go about implementing @(*) support though, i'm not familiar enough with the grammar
lizmat Kaiepi: fwiw, I've always thought of the feed operators as a "sequence" of iterators with the pointy end pulling 20:37
jnthn I think the idea in part was that each stage would get its own worker and they'd do a parallel producer/consumer thing.
lizmat with each iterator producing values in its own thread 20:38
Kaiepi the current implementation doesn't do that, correct?
lizmat indeed... afaik the current implementation predates post-GLR iterators *and* threads 20:39
yeah, from git blame looks like the only thing changed after the GLR is a "push" to an "append" 20:41
and the rest goes back to before 2011 20:42
Kaiepi how would i go about implementing that?
lizmat the way jnthn would do that (probably) is to codegen the blocks into parameters to a global sub, e.g. &FEED 20:43
then call .STORE on the pointy end of the feed operator with the result of the call to FEED with the blocks 20:44
and implement &FEED to do the right thing :-)
jnthn Probably more like a method on Rakudo::Internals that sets up the pipeline with Channel between them 20:47
In theory we can then wire the pieces together by calling .Seq on the Channel on the consuming side 20:48
And then iterate the result and .send it 20:49
21:04 robertle left
Kaiepi is there any code that does something similar to what i'm supposed to be doing? 21:07
21:10 robertle joined, brrt`` joined
lizmat not afaik... 21:11
21:12 brrt` left
lizmat Kaiepi: but I would suggest first implementing it outside of the core as a FOO sub that takes the blocks and sets up the pipeline of channels 21:12
that saves about 100 seconds for each edit / compile / try run 21:13
Kaiepi wdym by blocks, the QAST stuff?
jnthn Just like: -> @foo { map { blah }, @foo } 21:14
lizmat sub FOO(*@a) { } where @a is an array of blocks
jnthn And yes, what lizmat said on the receiving end :)
21:15 skids left
discord6 <Vendethiel> also always understood ==>>/<<== as append 21:17
<Vendethiel> Much like unix > vs >>
Geth nqp: 094c439b1e | usev6++ | .travis.yml
Try to use Xenial for Travis

On Xenial gcc-6 seems to be the default gcc version. Also, openjdk should be available out of the box.		 21:18
21:19 travis-ci joined
travis-ci NQP build errored. usev6 'Try to use Xenial for Travis 21:19
travis-ci.org/perl6/nqp/builds/532510838 github.com/perl6/nqp/compare/f404a...4c439b1ed2
21:19 travis-ci left
Geth nqp: d6d0ef921f | usev6++ | .travis.yml
Fix typo in travis config
 21:20
Kaiepi ok i think i get what you mean
something like QAST::Op.new( :op('callmethod'), :name('EVALUATE-FEED'), $*W.find_symbol(['Rakudo', 'Internals']), @stages ) ? 21:22
lizmat Kaiepi: yeah, something like that I think 21:23
yeah
the @stages is compile time, so you don't need a slurpy on the EVALUATE-FEED side 21:24
sleep&
21:38 travis-ci joined
travis-ci NQP build failed. usev6 'Fix typo in travis config' 21:38
travis-ci.org/perl6/nqp/builds/532511566 github.com/perl6/nqp/compare/094c4...d0ef921f6b
21:38 travis-ci left 21:41 brrt`` left
bartolin ^^ I guess that's still the missing jar. 21:41
21:43 brrt`` joined
Geth rakudo: ee73c88336 | usev6++ | .travis.yml
Try to use Xenial for Travis

On Xenial gcc-6 seems to be the default gcc version. Also, openjdk should be available out of the box.		 21:55
21:58 brrt`` left
vrurg jnthn: are you gone already? 22:19
bartolin: sorry, I pulled the fix but wasn't able to make a PR for it yet. 22:20
bartolin vrurg: no problem, I just wanted to make sure it wasn't related to my recent changes (Java 9 and travis config). 22:22
vrurg bartolin: I hoped to to find somebody today to get commit access and be able to do the fixes directly. No luck yet. ;) 22:27
jnthn vrurg: Mentally, yes ;)
vrurg jnthn: I wanted to ask you exactly that: can you give me the commit access? 22:28
jnthn vrurg: Ah, yes; I saw a CLA from you. 22:29
And it was cc'd to Will, which I think is correct procedure
vrurg I did what AlexDaniel instructed patrickb to do. Unless something was missed. 22:30
Actually, I need it for nqp too since both are now sharing same Configure.pl subsystem. 22:32
japhb vrurg: What does the new Configure subsystem change? 22:52
vrurg The primary task was to simplify adding new revision letters. Turned into a macro expansion on top of the existing configuration variables expansion. And, eventually, most (if not all) of the generation scripts can be (and some already have been) replaced with templates. 22:54
Which I consider great for the unification purposes because we currently have a zoo of perl5/nqp/perl6 scripts.
More info is here: github.com/rakudo/rakudo/pull/2816 22:55
Ah, and I merged common parts of NQP and Rakudo Configure.pl into a single module used by both now.
Also support for development in forked repositories. I.e. one can fork moarvm, nqp, and rakudo and use only these before merging back. 22:58
jnthn vrurg: Going to sleep now, will sort out access stuff for you tomorrow. Nudge me if I forget. 23:06
vrurg jnthn: Thanks! And good night!
jnthn Thanks o/

Powered by Cro and the Raku® Programming Language.

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

Thank you!