00:36 teatime joined 01:07 vendethiel joined 01:18 geekosaur joined 02:36 vendethiel joined
nine_ Ok, commit github.com/perl6/nqp/commit/cbdf5b...4c9a73bd63 should be somewhat harmless anyway. 06:25
But please review it!
jnthn_: ^^^ 06:26
06:51 RabidGravy joined
|Tux| This is Rakudo version 2016.03-127-g617bb41 built on MoarVM version 2016.03-108-gca1a21a 07:44
test 21.382
test-t 12.561
csv-parser 25.369
masak [Tux]: so, are we getting faster, or slower? 07:45
|Tux| noise
and 108 is the same as friday
I'll have to sit down with Liz to dig into why 07:46
08:02 brrt joined 09:14 |Tux| joined
jnthn nine_: It looks sensible and clean. Nice work! 10:22
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
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.
jnthn nine_: Either that or CompilationContext is a role and NQP and Perl6 mix it into their implementations 10:32
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?
You didn't stick a my on it?
+ class CompilationContext {
Yeah, already public :)
nine_ Oh...then I just should stop thinking too much about that :) 10:36
jnthn :)
10:36 pmurias joined 11:02 brrt joined 11:04 japhb_ joined
dalek p: 4fa32c2 | (Pawel Murias)++ | src/vm/js/bin/cross-compile.nqp:
[js] Unbitrot after cbdf5bb71f1b3c815386e2ac949f9a4c9a73bd630.
 11:13
p: 52f5701 | (Pawel Murias)++ | src/vm/js/ (2 files):
[js] Have a nqp::backtracestrings that returns a NYI instead of a huge useless error.
 11:16
p: df02637 | (Pawel Murias)++ | src/vm/js/Operations.nqp:
[js] Comment why we expose add_op as a method.
p: d1dc2e2 | (Pawel Murias)++ | src/vm/js/nqp-runtime/s (2 files):
[js] Serialize the boolification spec.
p: 8268b0e | (Pawel Murias)++ | t/serialization/02-types.t:
Test that the boolification spec gets serialized.
11:16 teatime joined
dalek kudo/nom: 6beddba | azawawi++ | / (2 files):
Add AppVeyor (Windows 7 64-bit CI testing) along with a badge in README
 11:27
kudo/nom: 1aabef8 | moritz++ | / (2 files):
Merge pull request #746 from azawawi/nom

Add AppVeyor (Windows 7 64-bit CI testing) along with a badge in README
11:28 azawawi joined
azawawi Just discovered another chat room where Perl 6 is being secretly developed :) 11:30
hehe
moritz so secretly that irclog.perlgeek.de/ lists the channel :-)
azawawi it was secret to me though. please let me live the moment :) 11:31
ci.appveyor.com/project/rakudo/rak...branch/nom # we need to activate appveyor ci on rakudo/rakudo
11:31 astj_ joined
moritz it says "OK 11:56
Project not found or access denied.
"
s/OK\n//
and yes, I did sign up with my github account
oh, I have to set up authorizatioin separate from the login 11:58
and now "Project not found or access denied." 11:59
ok, found my way around eventually 12:00
... but it's ci.appveyor.com/project/moritz/rakudo now 12:01
now rakudo/rakudo
weird
azawawi perfect... it is now working... moritz++ 12:02
12:04 ufobat joined 12:19 cognominal joined 12:42 perlpilot_ joined 13:09 vendethiel joined
[Coke] saw some nice REPL updates from awwaiid in Baltimore, hoping those can land before May. :) 14:04
awwaiid [Coke]: I was able to make progress and freshened the PR, it's in review/bugfix mode! github.com/rakudo/rakudo/pull/738 14:12
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:13
I'm currently trying to talk hoelzro into not having a fallback-to-nqp-repl mode :) 14:14
14:32 vendethiel joined
dalek ast: 372b17d | usev6++ | S03-operators/assign.t:
Fix test count
 14:34
jnthn awwaiid: Why not a fallback, ooc? 14:37
awwaiid: Or, is the Perl 6 version robust enough to survive, e.g., no libreadline and so on? 14:38
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
it's only been in nom for a few weeks
jnthn OK. What was the JVM situation? 14:42
hoelzro for the REPL?
jnthn yeah
hoelzro REPL6 doesn't currently work on the JVM ='(
jnthn That'd be one reason not to remove the fallback... 14:43
Though is the fallback just "use the existing NQP one"?
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
yeah, that's the fallback
jnthn But we need to keep it for NQP to still have its REPL anyway?
So what are we actually saving?
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?
Ah, ok
[Coke] note that we shouldn't merge the repl changes before 2016.04 14:45
hoelzro agreed
jnthn yeah, htat'd be cutting it too close :)
hoelzro I get most of my Perl 6 work done the weekend after a release =P
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:55
hoelzro awwaiid: REPL6 doesn't work on the JVM 14:57
I would love to fix the underlying problem, but ENOTENOUGHJVMEXP
awwaiid because of the eval context?
hoelzro the JVM infinitely recurses when you assign Perl6::Compiler to $!compiler
my naïve guess is the binder 14:58
awwaiid We could take the code from LREP that only depends on EVAL
hoelzro how does that code preserve the lexicals declared in the REPL?
awwaiid It creates new nested contexts
{ my $x = 5; { my $x = 2; { say $x } } }, effectively 14:59
but transparently to the user
hoelzro ah
awwaiid well. unless they poke around in some scope things like CALLER or something
I want to get rid of all specialness from REPL.pm, so that a user could replace it without knowing/hacking rakudo internals 15:00
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
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:35
bartolin has not seen that file failing in his daily spectests 16:38
16:39 skids joined
psch bartolin: i've looked at the NPE_sort PR and branch 16:42
and i'm once again scared of how much moar seems to cheat /o\
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]
camelia rakudo-moar 1aabef: OUTPUT«(Mu)␤»
psch ^^ that Mu is behind the NPE, which is fixed in the PR
but p6sort on moar doesn't care 16:43
psch commented to that effect on the GH PR itself as well
bartolin psch: yeah, me debugging tries looked similar :-)
psch i wanted to wait for appveyor before merging though
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
or it's again some lex{,ref} magic that we just don't have on nqp-j
nine_ Oh, it _is_ a regression caused by me! Though it's the very innocent looking MoarVM patch that's causing it. 16:46
psch hm, appveyor might take something like another hour or two at least... still two r-j builds queued 16:47
bartolin oops! the commit I vaguely remembered was actually for exactly the same line of code 16:59
github.com/rakudo/rakudo/commit/5da0b3faed
unfortunately i didn't remember the details and it took me a while (again) to figure it out this time 17:00
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
psch hrm, i still don't get why moar doesn't complain about the Mu 17:06
m: use nqp; my @list := nqp::list_i; for Mu { nqp::bindpos_i(@list, 0, $_) }; say @list[0] # this fails as it should...
camelia rakudo-moar 1aabef: OUTPUT«X::TypeCheck::Binding exception produced no message␤ in block <unit> at /tmp/oEsCargYQ6 line 1␤␤»
[Coke] just tried to build rakudo-jvm and was told that 2016.02 nqp was recent enough
psch but that's what p6sort does...
[Coke]: that's curious. we don't track NQP_REVISION differently for the backends..? 17:07
fwiw, after a git clean -xdf i got nqp-j 2016.03-67-ga525da3 from Configure.pl --backends=jvm --gen-nqp
the version check is in perl5, isn't it? 17:08
[Coke] I removed ./install and a reconfig is doing the right thing.
psch well, one of the r-j builds on appveyor passed 17:10
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
i'm not even sure if --gen-nqp and --gen-nqp=master do different things
bartolin psch: timotimo++ was also wondering why moar had not problem here: irclog.perlgeek.de/perl6/2015-11-17#i_11555980 17:12
timotimo don't quote me on something that long ago! that's ancient history! :P 17:13
bartolin *g*
psch yeah, i'm really not seeing it vOv
17:14 RabidGravy joined
timotimo bartolin: you are christian bartolomaeus? 17:15
bartolin yes, that's me
timotimo you're awesome :)
you do bug triage all the time and i don't see many people thanking you for that 17:16
bartolin thanks, I'm fine as it is :-) 17:17
timotimo OK 17:18
17:58 sortiz joined 18:41 hankache joined 18:54 FROGGS joined
dalek kudo/nom: 12abcc8 | usev6++ | src/core/Any-iterable-methods.pm:
Avoid NullPointerException in method 'sort'
 19:17
kudo/nom: bd44009 | peschwa++ | src/core/Any-iterable-methods.pm:
Merge pull request #747 from usev6/NPE_sort

Avoid NullPointerException in method 'sort'
psch AppVeyor ran out of... something. probably time
19:25 vendethiel joined 20:56 lizmat joined
lizmat waves from Dublin 20:56
[Coke] hio! 20:58
jnthn wonders what bits of Rakudo lizmat++ will be dublin' the speed of while there... :)
lizmat well, we just missed the ferry to Liverpool :-( 21:01
on the plus side, I'll have time to do the P6W now
[Coke] lizmat: ugh 21:02
lizmat we're now at a nice hotel: they're worse places in Dublin :-) 21:05
[Coke] jnthn : just double checking, but there's no release yet, right ? 21:06
jnthn lizmat: No. I spent the weekend being exhausted and failed to make the MoarVM release, which clogged the rest up 21:07
lizmat: I did the MoarVM release today, though :)
lizmat ah, so progress :-)
jnthn lizmat: Yup. www.moarvm.org/ has the release headlines, www.moarvm.org/releases.html the changelog 21:12
And I did a blog post at the tail end of last week, guess you already caught that
lizmat yes, I did 21:25
and another P6W hits the Net: p6weekly.wordpress.com/2016/04/18/...om-dublin/ 21:57
jnthn wonders where that whole stack exec thing is coming from 22:01
lizmat ??
lizmat assumes she missed something
jnthn lizmat: From "Building perl6 on Android in Gnuroot Debian" that I knew about thanks to the p6weekly :) 22:02
lizmat ah... ok :-)
jnthn They had to hack the flags to get it to work, and I'm wondering if we can make it Just Work :)
The big userland takeaway from my blog post, fwiw, is that loop { EVAL 'my class ABC { }' } no longer leaks 22:04
22:05 vendethiel joined
lizmat cool 22:05
jnthn But in the course of fixing that I built us a heap analyzer :) 22:09
lizmat I read about that :-)
jnthn Yeah. It'll be a small goldmine of memory savings. 22:10
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.
(Which should bring across-the-board improvements) 22:11
(Since all but the fully-inlinable benchmarks invoke)
lizmat looks forward to that! 22:12
22:15 geekosaur joined
jnthn Me too... 22:16
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:17
lizmat and there's no way to lose the refcounting ? 22:18
jnthn Losing the refcounting is exactly what I'm working on :-)
Took a bit of work to figure out the way to lose it without losing some of the nice properties it gives. 22:19
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++
bartolin in case someone wants to take a look: github.com/usev6/rakudo/commit/b74...003ebcaae5
'll run spectests tomorrow ...
jnthn Hm, yeah...that one works out on MoarVM because 22:22
r: say nqp::null.^name
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␤»
..rakudo-jvm 40a953: OUTPUT«cannot connect to eval server: Connection refused␤»
bartolin btw, I enjoyed to read you last blog! jnthn++
jnthn r: use nqp; say nqp::null.^name
camelia rakudo-jvm 40a953: OUTPUT«cannot connect to eval server: Connection refused␤»
..rakudo-moar bd4400: OUTPUT«VMNull␤»
jnthn I put r-j NPEs on that one
bartolin yeah, I've seen that VMNull there
jnthn Yeah... I wonder a bit if we should introduce that concept to JVM 22:23
iirc it's just a type object with Uninstantiable REPR
Then we could potentially fix a smaller number of places to return that rather than a true Java null
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
bartolin needs to sleep now o 22:26
jnthn That's a good idea. I should do the same. :) 22:27
jnthn heads to bed o/
lizmat joins bartolin and jnthn from afar 22:29

Powered by Cro and the Raku® Programming Language.

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

Thank you!