[Tux] This is Rakudo version 2016.04-204-ge239f6e built on MoarVM version 2016.04-134-g9879233 06:19
test 20.111
test-t 13.240
csv-parser 35.028
dalek kudo/nom: 28b7408 | niner++ | tools/build/Makefile- (2 files):
Mark repositories as version 1 at install time

The only part missing was the version file.		 07:56
nine And of course it quits before the much more interesting commit:
Add a basic packaging tool for modules 07:57
This script can be used for installing dists which don't need a build step or for which the build has been run manually.
More importantly, it can be used as part of the module packaging process. It can install a dist into a temporary repository while creating (precomp-) files that can be dropped into the real destination repo during package installation.
For example, run the following commanads:
VENDOR=$(perl6 -e 'CompUnit::RepositoryRegistry.repository-for-name("vendor").prefix.print')
perl6 install-dist.pl --for vendor --to /tmp/vendor /path/to/module
sudo cp /tmp/vendor/* $VENDOR # or package /tmp/vendor up 07:58
review: github.com/rakudo/rakudo/commit/28...1e01f7f2e9
RabidGravy cool 08:13
dalek p: 43e3696 | usev6++ | src/vm/jvm/runtime/org/perl6/nqp/io/SyncHandle.java:
Only get new data from readBuffer

While using nqp::readallfh after a call to nqp::readlinechompfh there seemed to be old data in readBuffer -- and we copied that instead of only new data.		 09:12
p: c043ac3 | usev6++ | t/nqp/019-file-ops.t:
Add another test for nqp::readlinefh
p: f198ea5 | usev6++ | src/vm/jvm/runtime/org/perl6/nqp/io/SyncHandle.java:
Look in readBuffer before reading from Channel

  [js] Serialize hllOwner.
psch nine: with ^^^ that locally i get "setcodeobj can only be used with a CodeRef", which is where you were at with the work r-j workaround, wasn't it? 09:13
s/ work// 09:14
nine yes, indeed 09:17
psch i'm somewhat annoyed that install-core-dist.pl is so jdb-resilient
like, there's a point somewhere in its execution where it stops doing anything when run under jdb 09:18
although not completely reliable, which i guess means threading weirdness vOv
nine Could be similiar to perl6-gdb-m. We do run precompilation in separate processes and capture stdout and stderr. Seems to confuse debuggers. 09:19
psch ah, yes, CUPR:199 09:21
i guess i'll try running perl6-jdb-server from there instead of $*EXECUTABLE
hrm, that doesn't work. i end up with two java -Xdebug processes listening on the same port :/ 10:03
nine Can you attach to a running process? 10:05
Maybe add some sleep 30 to the to-be-compiled module to give you some time
psch well, perl6-jdb-server suspends until a debugger is attached 10:07
...actually, it's probably smarter to implicitly precompile the module that breaks, isn't it 10:08
but afaict every dependency starts it's own process..? 10:11
which means i either have to add the port as an arg to perl6-jdb-server or edit the script before running it 10:12
hm, can i get the name of the module somehow in .precompile? 10:18
p: 3e10591 | (Pawel Murias)++ | / (2 files):
Test serializing a type with a hllOwner.
p: 021c409 | (Pawel Murias)++ | src/vm/js/bin/run_tests.pl:
[js] Fix run_tests.pl after the rename.
nine $source-name should give it away 10:54
psch turns out i didn't need that, anyway 11:44
guessing "it's NativeCall" was sufficient... :)
nine: the breakage is somewhere downwards from PrecompilationDependency::File.deserialize 11:45
nine Yes, the EVAL
psch yeah, the CodeRef is null
...you probably knew that vOv 11:46
anyway, jdb-fu doesn't help there i suppose, at least not during loading of the dependency
nine This patch is somewhat revealing: gist.github.com/niner/6b79af9b3ddb...1e5ae6898f 11:53
psch ...i'm not seeing it 12:35
nine The EVAL in question is evaluating "CompUnit::DependencySpecification.new(:short-name<NativeCall::Types>)". This happens several times during a install-core-dist.pl run. The first 2 times it works, the third time breaks. 12:48
There is a difference between the working QAST trees and the breaking.
Especially the I think post_deserialize frames in the beginning 12:49
psch i'm getting exactly one QAST dump here 12:50
nine That's....odd. Have to try it myself then. I'm on a different machine right now 12:54
psch there's three "Oops!!!" in there, fwiw 12:55
one "cannot stringify", two "cannot invoke"
nine psch: indeed, on this machine I only get a single QAST and it's the broken one. 13:20
psch: I hope I can still reproduce the situation I described earlier on my desktop at home. Might give us valuable insight. 13:21
Do you see the - QAST::Op(bindcurhllsym) - QAST::SVal(GLOBAL) - QAST::WVal(NQPMu) in the [post_deserialize], too? That alone doesn't look right... 13:22
psch yeah, that's here too 13:24
and yes, i agree. NQPMu as GLOBAL seems wrong
lizmat good *, #perl6-dev 14:15
lizmat notes the backlog URL misses an "l" in the topic 14:16
timotimo oh, indeed it does
lizmat moritz++ 14:17
dalek p: d2a5791 | (Pawel Murias)++ | src/NQP/Optimizer.nqp:
Stop the optimizer from breaking nqp code using takedispatcher and getlexouter.
 15:09
p: baf5c0a | (Pawel Murias)++ | t/nqp/100-dispatcher.t:
Avoid a now not needed optimizer bug workaround in test.
p: 1ff50c8 | (Pawel Murias)++ | src/vm/js/Operations.nqp:
[js] Implement nqp::getlexouter.
p: 6010bd6 | (Pawel Murias)++ | t/nqp/101-lexpad-stuff.t:
Test nqp::ctx, nqp::ctxcaller and nqp::getlexouter.
 15:17
timotimo pmurias: this work is really worth a lot; adding tests makes everything better! 15:18
nine psch: this is the QAST when the EVAL works: gist.github.com/niner/5b9eb2808757...3fb8ef7590 15:36
lizmat nine: I'm working on the P6W: could you summarize the work that you just merged ? 15:37
===SORRY!=== 15:45
Function 'NativeCall::Types::void' needs parens to avoid gobbling block (or perhaps it's a class that's not declared or available in this scope?)
^^^ make install on JVM
is that a known issue ?
nine lizmat: that should be fixed on nqp master
lizmat ah, ok
is there a reason not to bump ?
nine The build still does not finish :/ 15:46
PrecompilationStore overhaul
Redesigned the way precompilation files and the accompanying dependency information is stored so we no longer have to file lock the PrecompilationStore for read access (i.e. loading modules). This also rids us of needing write access to the standard repositories, meaning that you no longer get permission errors with a system wide rakudo installation.
We can now store the result of dependency verification necessary when (probably unrelated) modules were installed since a file was precompiled, speeding up module loading in the common case.
For the first time, it's now possible to package modules for Linux distributions, including the precompiled files.
lizmat: ^^^
lizmat nine++ 15:47
nine++ # for making my work easier :-)
nine Summing it up like this, I see that it really was a "fix all things at once" kind of endeavour :) 15:48
timotimo mhhh 15:49
dalek kudo/nom: e39ce3d | niner++ | tools/install-dist.pl:
Fix stupid editing mistake in install-dist.pl

Thanks to vendethiel++ for spotting this.		 16:17
lizmat hmmm... looks like Travis doesn't know about #perl6-dev yet 17:41
timotimo yeah, i think froggs' travis user account is used for that 17:48
he'd probably have to flip the switch
do you know what's up with him?
ugexe github.com/rakudo/rakudo/blob/nom/...is.yml#L25 17:49
lizmat And another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2016/05/17/...-progress/ 18:09
bartolin lizmat++ 18:23
hoelzro lizmat++ 18:25
nine Thanks lizmat++! 18:28
RabidGravy yay! 18:56
[Coke] lizmat++ <teal'c>indeed</teal'c> 19:12
cognominal lizmat++ 19:16
nine psch: # TODO: use the Moar code-path here on all backends. The issue was discovered close to release, so only the Moar backend - that really needs this - is being updated for now. 20:00
psch: github.com/rakudo/rakudo/blob/nom/....nqp#L3101
psch: This FixupList is part of the failing QAST
psch ohh, yeah, i've seen that a few times 20:01
i think i even tried porting it once
i mean, the comment and code 20:02
so, wait
the *class* FixupList doesn't work on r-j? 20:03
dalek ast: 4773808 | usev6++ | S03-operators/buf.t:
Unfudge passing tests for JVM, RT #126530
nine psch: no idea. I just noticed that it shows up in the failing QAST. Maybe completely unrelated, but we do have a failure and a TODO, so it seems prudent to investigate 20:06
psch: though I may just have across something that is closer to the error message
psch nine: great. i've not really found any approach to figure that out. if you have anything that needs a different pair of eyes, make a noise :) 20:10
dalek ast: a85c4b4 | usev6++ | S03-operators/buf.t:
Add test for RT #126529
 20:16
ast: 7073efe | usev6++ | S03-operators/buf.t:
Tweak test for RT #126529
 20:21
ast: fb10313 | usev6++ | S (3 files):
Unfudge some more tests for JVM
 20:55
psch bartolin++ 20:56
looks like the Binder fix actually did something
still not sure how to solve #126493
'cause, like, that's the case that explicitly *isn't* fixed there... :)
bartolin looks like a nqp bump would make it possible to run spectests for r-j again \o/ 21:02
bartolin has absolutely no idea how a fix for #126493 would look like :-/
psch ("there" means "the place i last patched the jvm Binder", for clarity) 21:08
fwiw, 'make test' has somewhat higher priority in my mind than 'make spectest', but seeing as nine++ is already on that we might as well bump now 21:09
as in, 'make test' is currently blocked by NativeCall not precompiling right
bartolin true. on the other hand I'd really like to be able to run my daily stresstests again. mainly because it makes it much easier to catch regressions 21:11
dalek ast: 54bbc00 | usev6++ | S02-types/hash_ref.t:
Another passing test for JVM
 21:21
psch bartolin: ...i don't really see how that's the other hand :)
my point is "we can run spectest with bump, but can't without, so we should bump"
bartolin :-) 21:22
psch bartolin: 2016.04-108-g6010bd6 is the right one, isn't it? 21:23
bartolin I just wanted to explain why my priorities were a bit different from yours. but it's late here, so I'll head to bed ...
psch doesn't really want to build and start spectest right now
bartolin mom, looking
psch that's 'git describe' for master HEAD, fwiw 21:25
bartolin hmm, I never did that version bump thing, so I'm not sure 21:26
maybe you can just leave it for tomorrow?
psch yeah, sure :)
bartolin ++psch :-) 21:27
psch heads off o/ 21:28

Powered by Cro and the Raku® Programming Language.

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

Thank you!