Perl 6 - the future is here, just unevenly distributed

IRC log for #p6dev, 2016-04-18

| Channels | #p6dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:36 teatime joined #p6dev
01:07 vendethiel joined #p6dev
01:18 geekosaur joined #p6dev
02:36 vendethiel joined #p6dev
06:25 nine_ Ok, commit https://github.com/perl6/nqp/commit/cbdf5bb71f1b3c815386e2ac949f9a4c9a73bd63 should be somewhat harmless anyway.
06:25 nine_ But please review it!
06:26 nine_ jnthn_: ^^^
06:51 RabidGravy joined #p6dev
07:44 |Tux| This is Rakudo version 2016.03-127-g617bb41 built on MoarVM version 2016.03-108-gca1a21a
07:44 |Tux| test            21.382
07:44 |Tux| test-t          12.561
07:44 |Tux| csv-parser      25.369
07:45 masak [Tux]: so, are we getting faster, or slower?
07:45 |Tux| noise
07:45 |Tux| and 108 is the same as friday
07:46 |Tux| I'll have to sit down with Liz to dig into why
08:02 brrt joined #p6dev
09:14 |Tux| joined #p6dev
10:22 jnthn nine_: It looks sensible and clean. Nice work!
10:30 nine_ jnthn: thanks! I still wonder though: since I'll need the same trick for Perl6::World, should I derive a Perl6::CompilationContext from CompilationContext or should I keep them separate?
10:30 nine_ That I can't come up with a sensible name for the accessor method that returns the Perl6::CompilationContext is probably a hint that I should use inheritance there.
10:32 jnthn nine_: Either that or CompilationContext is a role and NQP and Perl6 mix it into their implementations
10:35 nine_ Well, there's already inheritance between HLL::World and Perl6::World and the CompilationContext is just a part of the World's job. I guess what's keeping me from just using inheritance there is that I'm unsure if CompilationContext is a good name and for inheriting, I have to pull it out of HLL::World's lexical scope and make it public where names matter much more.
10:35 jnthn It already is public, no?
10:35 jnthn You didn't stick a my on it?
10:35 jnthn +    class CompilationContext {
10:35 jnthn Yeah, already public :)
10:36 nine_ Oh...then I just should stop thinking too much about that :)
10:36 jnthn :)
10:36 pmurias joined #p6dev
11:02 brrt joined #p6dev
11:04 japhb_ joined #p6dev
11:13 dalek nqp: 4fa32c2 | (Pawel Murias)++ | src/vm/js/bin/cross-compile.nqp:
11:13 dalek nqp: [js] Unbitrot after cbdf5bb71f1b3c815386e2ac949f9a4c9a73bd630.
11:13 dalek nqp: review: https://github.com/perl6/nqp/commit/4fa32c26c0
11:16 dalek nqp: 52f5701 | (Pawel Murias)++ | src/vm/js/ (2 files):
11:16 dalek nqp: [js] Have a nqp::backtracestrings that returns a NYI instead of a huge useless error.
11:16 dalek nqp: review: https://github.com/perl6/nqp/commit/52f5701715
11:16 dalek nqp: df02637 | (Pawel Murias)++ | src/vm/js/Operations.nqp:
11:16 dalek nqp: [js] Comment why we expose add_op as a method.
11:16 dalek nqp: review: https://github.com/perl6/nqp/commit/df02637f9c
11:16 dalek nqp: d1dc2e2 | (Pawel Murias)++ | src/vm/js/nqp-runtime/s (2 files):
11:16 dalek nqp: [js] Serialize the boolification spec.
11:16 dalek nqp: review: https://github.com/perl6/nqp/commit/d1dc2e279f
11:16 dalek nqp: 8268b0e | (Pawel Murias)++ | t/serialization/02-types.t:
11:16 dalek nqp: Test that the boolification spec gets serialized.
11:16 dalek nqp: review: https://github.com/perl6/nqp/commit/8268b0ee36
11:16 teatime joined #p6dev
11:27 dalek rakudo/nom: 6beddba | azawawi++ | / (2 files):
11:27 dalek rakudo/nom: Add AppVeyor (Windows 7 64-bit CI testing) along with a badge in README
11:27 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/6beddba760
11:27 dalek rakudo/nom: 1aabef8 | moritz++ | / (2 files):
11:27 dalek rakudo/nom: Merge pull request #746 from azawawi/nom
11:27 dalek rakudo/nom:
11:27 dalek rakudo/nom: Add AppVeyor (Windows 7 64-bit CI testing) along with a badge in README
11:27 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/1aabef8c89
11:28 azawawi joined #p6dev
11:30 azawawi Just discovered another chat room where Perl 6 is being secretly developed :)
11:30 azawawi hehe
11:30 moritz so secretly that http://irclog.perlgeek.de/ lists the channel :-)
11:31 azawawi it was secret to me though. please let me live the moment :)
11:31 azawawi https://ci.appveyor.com/project/rakudo/rakudo/branch/nom  # we need to activate appveyor ci on rakudo/rakudo
11:31 astj_ joined #p6dev
11:56 moritz it says "OK
11:56 moritz Project not found or access denied.
11:56 moritz "
11:56 moritz s/OK\n//
11:56 moritz and yes, I did sign up with my github account
11:58 moritz oh, I have to set up authorizatioin separate from the login
11:59 moritz and now "Project not found or access denied."
12:00 moritz ok, found my way around eventually
12:01 moritz ... but it's https://ci.appveyor.com/project/moritz/rakudo now
12:01 moritz now rakudo/rakudo
12:01 moritz weird
12:02 azawawi perfect... it is now working... moritz++
12:04 ufobat joined #p6dev
12:19 cognominal joined #p6dev
12:42 perlpilot_ joined #p6dev
13:09 vendethiel joined #p6dev
14:04 * [Coke] saw some nice REPL updates from awwaiid in Baltimore, hoping those can land before May. :)
14:12 awwaiid [Coke]: I was able to make progress and freshened the PR, it's in review/bugfix mode! https://github.com/rakudo/rakudo/pull/738
14:13 awwaiid After this PR my goals are to remove the rest of nqp:: calls from REPL.pm, and then make it so you can invoke the REPL in your code (REPL::here or MY::REPL or similar, starting a REPL in the current scope)
14:14 awwaiid I'm currently trying to talk hoelzro into not having a fallback-to-nqp-repl mode :)
14:32 vendethiel joined #p6dev
14:34 dalek roast: 372b17d | usev6++ | S03-operators/assign.t:
14:34 dalek roast: Fix test count
14:34 dalek roast: review: https://github.com/perl6/roast/commit/372b17d168
14:37 jnthn awwaiid: Why not a fallback, ooc?
14:38 jnthn awwaiid: Or, is the Perl 6 version robust enough to survive, e.g., no libreadline and so on?
14:41 hoelzro the P6 REPL can survive without readline and such; I just wanted to make sure it's pretty stable before we commit to it fully
14:41 hoelzro it's only been in nom for a few weeks
14:42 jnthn OK. What was the JVM situation?
14:42 hoelzro for the REPL?
14:42 jnthn yeah
14:42 hoelzro REPL6 doesn't currently work on the JVM ='(
14:43 jnthn That'd be one reason not to remove the fallback...
14:43 jnthn Though is the fallback just "use the existing NQP one"?
14:43 hoelzro for some reason or another, I can't assign the Perl6::Compiler object from NQP land to $!compiler in the Perl 6 REPL object
14:43 hoelzro yeah, that's the fallback
14:43 jnthn But we need to keep it for NQP to still have its REPL anyway?
14:43 jnthn So what are we actually saving?
14:44 hoelzro awwaiid's change is just removing interactive_result and interactive_exception
14:44 jnthn Or better put: what would we be elminating by "removing the fallbck"? Some detection code, or?
14:44 jnthn Ah, ok
14:45 [Coke] note that we shouldn't merge the repl changes before 2016.04
14:45 hoelzro agreed
14:45 jnthn yeah, htat'd be cutting it too close :)
14:45 hoelzro I get most of my Perl 6 work done the weekend after a release =P
14:55 awwaiid Does JVM work in general? I can try to make sure REPL6 works on JVM if y'all like. The idea is that REPL6 will be used 100% of the time, so fallback code is redundant, a code path that is never taken.
14:57 hoelzro awwaiid: REPL6 doesn't work on the JVM
14:57 hoelzro I would love to fix the underlying problem, but ENOTENOUGHJVMEXP
14:57 awwaiid because of the eval context?
14:57 hoelzro the JVM infinitely recurses when you assign Perl6::Compiler to $!compiler
14:58 hoelzro my naïve guess is the binder
14:58 awwaiid We could take the code from LREP that only depends on EVAL
14:58 hoelzro how does that code preserve the lexicals declared in the REPL?
14:58 awwaiid It creates new nested contexts
14:59 awwaiid { my $x = 5; { my $x = 2; { say $x } } }, effectively
14:59 awwaiid but transparently to the user
14:59 hoelzro ah
14:59 awwaiid well. unless they poke around in some scope things like CALLER or something
15:00 awwaiid I want to get rid of all specialness from REPL.pm, so that a user could replace it without knowing/hacking rakudo internals
15:01 hoelzro that would be nice
15:01 awwaiid I wonder if LREP works on jvm. I'll build the jvm backend in a bit ... $work time now :)
15:25 pmurias joined #p6dev
16:35 nine_ Is t/spec/S04-phasers/eval-in-begin.t known to fail? I first thought it's a regression by my BEGIN time EVAL work (you'd think that from the name, wouldn't you?), but it seems to fail on nom, too here.
16:38 * bartolin has not seen that file failing in his daily spectests
16:39 skids joined #p6dev
16:42 psch bartolin: i've looked at the NPE_sort PR and branch
16:42 psch and i'm once again scared of how much moar seems to cheat /o\
16:42 psch m: use nqp; my \indices := nqp::setelems(nqp::list, 2); my int $i; nqp::bindpos(indices, $i, nqp::decont($i)) while nqp::islt_i($i = nqp::add_i($i, 1), 2); say indices[0]
16:42 camelia rakudo-moar 1aabef: OUTPUT«(Mu)␤»
16:42 psch ^^ that Mu is behind the NPE, which is fixed in the PR
16:43 psch but p6sort on moar doesn't care
16:43 * psch commented to that effect on the GH PR itself as well
16:43 bartolin psch: yeah, me debugging tries looked similar :-)
16:43 psch i wanted to wait for appveyor before merging though
16:44 bartolin I seem to remember a similiar case from last year, I'll try to find it
16:44 psch hm, i suppose it might be the binder that somehow doesn't care too
16:44 psch or it's again some lex{,ref} magic that we just don't have on nqp-j
16:46 nine_ Oh, it _is_ a regression caused by me! Though it's the very innocent looking MoarVM patch that's causing it.
16:47 psch hm, appveyor might take something like another hour or two at least... still two r-j builds queued
16:59 bartolin oops! the commit I vaguely remembered was actually for exactly the same line of code
16:59 bartolin https://github.com/rakudo/rakudo/commit/5da0b3faed
17:00 bartolin unfortunately i didn't remember the details and it took me a while (again) to figure it out this time
17:03 psch hrm, maybe that means we should make r-j p6sort resilient enough instead..? :/
17:03 bartolin . o O ( at least I left a comment this time :-)
17:05 vendethiel joined #p6dev
17:06 psch hrm, i still don't get why moar doesn't complain about the Mu
17:06 psch m: use nqp; my @list := nqp::list_i; for Mu { nqp::bindpos_i(@list, 0, $_) }; say @list[0] # this fails as it should...
17:06 camelia rakudo-moar 1aabef: OUTPUT«X::TypeCheck::Binding exception produced no message␤  in block <unit> at /tmp/oEsCargYQ6 line 1␤␤»
17:06 * [Coke] just tried to build rakudo-jvm and was told that 2016.02 nqp was recent enough
17:06 psch but that's what p6sort does...
17:07 psch [Coke]: that's curious.  we don't track NQP_REVISION differently for the backends..?
17:07 psch fwiw, after a git clean -xdf i got nqp-j 2016.03-67-ga525da3 from Configure.pl --backends=jvm --gen-nqp
17:08 psch the version check is in perl5, isn't it?
17:08 [Coke] I removed ./install and a reconfig is doing the right thing.
17:10 psch well, one of the r-j builds on appveyor passed
17:11 psch so i guess we can merge the NPE_sort PR, to get at least a building, if not make test or make spectest clean, r-j 2016.04
17:11 psch i'm not even sure if --gen-nqp and --gen-nqp=master do different things
17:12 bartolin psch: timotimo++ was also wondering why moar had not problem here: http://irclog.perlgeek.de/perl6/2015-11-17#i_11555980
17:13 timotimo don't quote me on something that long ago! that's ancient history! :P
17:13 bartolin *g*
17:13 psch yeah, i'm really not seeing it vOv
17:14 RabidGravy joined #p6dev
17:15 timotimo bartolin: you are christian bartolomaeus?
17:15 bartolin yes, that's me
17:15 timotimo you're awesome :)
17:16 timotimo you do bug triage all the time and i don't see many people thanking you for that
17:17 bartolin thanks, I'm fine as it is :-)
17:18 timotimo OK
17:58 sortiz joined #p6dev
18:41 hankache joined #p6dev
18:54 FROGGS joined #p6dev
19:17 dalek rakudo/nom: 12abcc8 | usev6++ | src/core/Any-iterable-methods.pm:
19:17 dalek rakudo/nom: Avoid NullPointerException in method 'sort'
19:17 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/12abcc8b1e
19:17 dalek rakudo/nom: bd44009 | peschwa++ | src/core/Any-iterable-methods.pm:
19:17 dalek rakudo/nom: Merge pull request #747 from usev6/NPE_sort
19:17 dalek rakudo/nom:
19:17 dalek rakudo/nom: Avoid NullPointerException in method 'sort'
19:17 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/bd440098b8
19:17 psch AppVeyor ran out of... something.  probably time
19:25 vendethiel joined #p6dev
20:56 lizmat joined #p6dev
20:56 * lizmat waves from Dublin
20:58 [Coke] hio!
20:58 * jnthn wonders what bits of Rakudo lizmat++ will be dublin' the speed of while there... :)
21:01 lizmat well, we just missed the ferry to Liverpool  :-(
21:01 lizmat on the plus side, I'll have time to do the P6W now
21:02 [Coke] lizmat: ugh
21:05 lizmat we're now at a nice hotel: they're worse places in Dublin   :-)
21:06 lizmat [Coke] jnthn : just double checking, but there's no release yet, right ?
21:07 jnthn lizmat: No. I spent the weekend being exhausted and failed to make the MoarVM release, which clogged the rest up
21:07 jnthn lizmat: I did the MoarVM release today, though :)
21:07 lizmat ah, so progress  :-)
21:12 jnthn lizmat: Yup. http://www.moarvm.org/ has the release headlines, http://www.moarvm.org/releases.html the changelog
21:12 jnthn And I did a blog post at the tail end of last week, guess you already caught that
21:25 lizmat yes, I did
21:57 lizmat and another P6W hits the Net: https://p6weekly.wordpress.com/2016/04/18/2016-16-a-quick-one-from-dublin/
22:01 * jnthn wonders where that whole stack exec thing is coming from
22:01 lizmat ??
22:01 * lizmat assumes she missed something
22:02 jnthn lizmat: From "Building perl6 on Android in Gnuroot Debian" that I knew about thanks to the p6weekly :)
22:02 lizmat ah... ok  :-)
22:02 jnthn They had to hack the flags to get it to work, and I'm wondering if we can make it Just Work :)
22:04 jnthn The big userland takeaway from my blog post, fwiw, is that loop { EVAL 'my class ABC { }' } no longer leaks
22:05 vendethiel joined #p6dev
22:05 lizmat cool
22:09 jnthn But in the course of fixing that I built us a heap analyzer :)
22:09 lizmat I read about that  :-)
22:10 jnthn Yeah. It'll be a small goldmine of memory savings.
22:10 jnthn That at present taking on one of the Scary Refactors in MoarVM that I've put off for a while, to hopefully improve our invocation speed some.
22:11 jnthn (Which should bring across-the-board improvements)
22:11 jnthn (Since all but the fully-inlinable benchmarks invoke)
22:12 * lizmat looks forward to that!
22:15 geekosaur joined #p6dev
22:16 jnthn Me too...
22:17 jnthn Another interesting "lesson learned the hard way" is that mixing refcounted frames and tracing GC objects isn't really hard, but any programs that keep lots of closures around end up suffering, because the ref-counting doesn't play nice with the generational scheme.
22:18 lizmat and there's no way to lose the refcounting ?
22:18 jnthn Losing the refcounting is exactly what I'm working on :-)
22:19 jnthn Took a bit of work to figure out the way to lose it without losing some of the nice properties it gives.
22:20 bartolin wrt rakudo-j: I tried to fix another source of NullPointerExceptions. its not spectested yet, but I hope that will gives us back a relevant number of passing tests
22:20 jnthn bartolin++
22:20 bartolin in case someone wants to take a look: https://github.com/usev6/rakudo/commit/b74a9853355e276070cea4621085f5003ebcaae5
22:20 bartolin 'll run spectests tomorrow ...
22:22 jnthn Hm, yeah...that one works out on MoarVM because
22:22 jnthn r: say nqp::null.^name
22:22 camelia rakudo-moar bd4400: OUTPUT«===SORRY!=== Error while compiling /tmp/tmpfile␤Could not find nqp::null, did you forget 'use nqp;' ?␤at /tmp/tmpfile:1␤------> say nqp::null⏏.^name␤    expecting any of:␤        argument list␤»
22:22 camelia ..rakudo-jvm 40a953: OUTPUT«cannot connect to eval server: Connection refused␤»
22:22 bartolin btw, I enjoyed to read you last blog! jnthn++
22:22 jnthn r: use nqp; say nqp::null.^name
22:22 camelia rakudo-jvm 40a953: OUTPUT«cannot connect to eval server: Connection refused␤»
22:22 camelia ..rakudo-moar bd4400: OUTPUT«VMNull␤»
22:22 jnthn I put r-j NPEs on that one
22:22 bartolin yeah, I've seen that VMNull there
22:23 jnthn Yeah... I wonder a bit if we should introduce that concept to JVM
22:23 jnthn iirc it's just a type object with Uninstantiable REPR
22:23 jnthn Then we could potentially fix a smaller number of places to return that rather than a true Java null
22:24 jnthn And hopefully have to fix less places in the codebase, and have less risk of busting JVM
22:24 bartolin sounds good for me, but it's way above my head
22:26 * bartolin needs to sleep now o
22:27 jnthn That's a good idea. I should do the same. :)
22:27 * jnthn heads to bed o/
22:29 * lizmat joins bartolin and jnthn from afar

| Channels | #p6dev index | Today | | Search | Google Search | Plain-Text | summary