dalek kudo/nom: c168e7c | coke++ | docs/release_guide.pod:
Note actual release date.
00:58
kudo/nom: 143283b | coke++ | docs/announce/2016.03.md:
fix release name.
timotimo \o/ 01:02
dalek kudo/nom: bff6430 | coke++ | docs/release_guide.pod:
Breaking 6.c-errata is bad
01:06
01:11 skids joined 01:40 Ben_Goldberg joined 01:44 BenGoldberg_ joined
[Coke] wonders why MANIFEST is generated with "make manifest" 01:51
timotimo so that you don't have to do it by hand? 01:52
[Coke] ... as opposed to "make MANIFEST" 01:53
timotimo oh 01:56
dalek kudo/nom: 9a6d7f0 | coke++ | docs/release_guide.pod:
run things in the right order.
02:06
kudo/nom: 6732d2e | coke++ | docs/release_guide.pod:
recent 'Test.pm' changes require this...

  ... at least in the test of the tarball. Seems to not
matter in the build directory.
02:11 colomon joined
[Coke] 2016.03 tarballs and tags available. 02:32
02:33 synopsebot6 joined
timotimo \o/ 02:46
thank you so much for doing this for the umpteenth time in a row
02:47 ilbot3 joined
[Tux] test 21.101 07:42
test-t 12.214
csv-parser 24.843
08:12 sortiz joined 08:14 FROGGS joined 08:44 Hotkeys joined 09:03 RabidGravy joined 09:07 [Tux] joined
dalek kudo/nom: 7cc37b3 | lizmat++ | src/core/Str.pm:
Nativy needles and lengths of needles
09:32
kudo/nom: f3fe819 | lizmat++ | src/core/Iterator.pm:
Slightly optimize default Iterator.push-all

Fewer calls, and no need to keep a counter as well.
kudo/nom: c85e036 | lizmat++ | src/core/Mu.pm:
Give gimme back to the world
nine gimme gimme gimme :) 09:37
jnthn Apparently, we don't giyou any more :) 10:03
moritz
.oO( gimme gimme gimme more huhn... encrypted.google.com/search?hl=en&...QvwUIGSgA)
10:04
whoops, should have been this link: www.youtube.com/watch?v=LdserZX7Bns
nine That is....disturbing. Why do I click such links? 10:08
moritz nine: because I terribly abused your trust in my personality :-) 10:09
lizmat nine hoelzro : I guess now would be the best time to merge your branches, if you're ready of course :-) 12:15
nine I will merge the nqp branch for source names and maybe the corresponding commit in rakudo. That will give us useable backtraces at least while I continue shaving my yak. 12:17
lizmat nine++ :-) 12:20
hoelzro lizmat: thanks for the heads-up; I'll wait until after nine has finished merging 12:25
12:30 AlexDaniel joined
dalek p/relocateable-precomp: bd39fe2 | (Stefan Seifert)++ | src/HLL/Compiler.nqp:
Option for a source-name different from the actual source file

While absolute paths are useful for reading source files reliably, we don't want to save those absolute paths in precompiled files as the source files may move after precompilation. This happens when modules are packaged for Linux distributions and the build process runs with an unprivileged user while the result should be installed in a system location.
The source-name option allows for specifying a different string to use for the $?FILES variable and thus for the path to the source file in backtraces.
12:31
sortiz Can reproduce _nadim report: "Internal error: unhandled target type in sub nativecast at [NativeCall line 394] in ... at t/04-nativecall/19-function-pointers.t line 17" 12:42
lizmat sortiz: what OS are you on 12:43
?
sortiz Linux
lizmat hmmm... /me on OS X 12:44
jnthn If I had to guess that error, I'd first guess version screw
um, skew
lizmat yeah, feels like it...
jnthn As the func pointer stuff was a recent addition in Moar
lizmat sortiz: could you try running configure again ?
jnthn It could of course be a bug in that too
lizmat but then an OS dependent one ...
jnthn Well, or just check your moar version too
lizmat: Stranger things have happened ;) 12:45
lizmat jnthn: true that :)
sortiz "This is Rakudo version 2016.02-214-gc85e036 built on MoarVM version 2016.03" 12:46
dalek p: bd39fe2 | (Stefan Seifert)++ | src/HLL/Compiler.nqp:
Option for a source-name different from the actual source file

While absolute paths are useful for reading source files reliably, we don't want to save those absolute paths in precompiled files as the source files may move after precompilation. This happens when modules are packaged for Linux distributions and the build process runs with an unprivileged user while the result should be installed in a system location.
The source-name option allows for specifying a different string to use for the $?FILES variable and thus for the path to the source file in backtraces.
jnthn sortiz: OK, then not version skew. 12:48
As I'm sure the fp stuff was in 2016.03
sortiz The problem seems that the tested nativecast argument ':(--> int32)' isn't Callable (is Signature), unexpected to nativecast
And somehow my pull don't seem to include FROGGS's commit 5221023 12:52
dalek Heuristic branch merge: pushed 32 commits to rakudo/nom by hoelzro 12:58
sortiz Nuking ./install... 12:59
Ok, NativeCall is a lib, so a realclean, perl Configure..., make, make test fails. Need first 'make install'. All pass now. 13:02
nine That's odd. We've never had to make install before the make test 13:06
And we shouldn't have to.
I think commit 3e2e7f9cbe5b9d7eb53aa880992482f4e2e9fac3 broke that 13:07
sortiz NativeCall isn't in settings, so it's changes now need to be "installed" first.
lizmat aaahh... that would make sense... 13:08
nine Only since commit 3e2e7f9cbe5b9d7eb53aa880992482f4e2e9fac3 since we now use the installed NativeCall instead of the bundled one. 13:09
Better fix would have been to move the use lib 'lib'; to before the use CompileTestLib;
lizmat nine: or combine them ? 13:10
jnthn Combine? 13:12
Can you use lib 'foo', 'bar'?
lizmat use lib <foo bar> essentially, yes ?
13:12 Ven joined
jnthn I dunno, if it works ;) 13:12
m: use lib <foo bar>
camelia ( no output )
jnthn :) 13:13
Guess somebody++ made that work :)
TIL ;)
13:13 skids joined
Ven is nom known to be broken ATM? 13:14
lizmat no? 13:21
Ven I can't `use Test;` on nom ATM, fails with "EVAL is a very dangerous function" (ie no monkey pragma there) 13:25
dalek kudo/nom: 984d24a | lizmat++ | t/0 (24 files):
Make sure "make test" works without "make install"
13:27
lizmat Ven: no idea... :-(
jnthn m: use Test; 13:28
camelia ( no output )
sortiz Ven, do you "install" your new rakudo before your tests? 13:30
dalek kudo/nom: e2ac3dc | (Stefan Seifert)++ | / (7 files):
Store logical file names in precomp files

We now use logical file names for annotating sources and construct absolute paths when printing stack traces. This avoids storing absolute paths in precompiled files which is a problem for packaging modules for Linux distributions. It also allows for us to add the name of the requested module to the backtrace output, alleviating the problem with the undeciferable SHA-1 file names.
13:34
lizmat nine++ :-) 13:36
jnthn nine++ \o/
Nice to see lots of polishing, opt, etc. going in these days :) 13:37
sortiz nine++
jnthn btw, if somebody wants to RT something
m: enum Foo << :Bar(1), :Baz >>
camelia rakudo-moar 984d24: OUTPUTĀ«===SORRY!===ā¤Incompatible MROs in P6opaque reblessā¤Ā»
jnthn That's a crappy error :)
That was about the only icky thing I hit yesterday when writing the heap analyzer 13:38
m: enum Foo << :Bar(1) Baz >> # this is what I meant
camelia ( no output )
lizmat is "make spectest" supposed to run with or without "make install" ?
jnthn lizmat: I always run it without locally, fwiw
lizmat well, not recently you don't :-)
jnthn I do, and it may explain some failures :D
lizmat well, I just nuked my install dir, made from scratch, and now all tests fail in "make spectest" 13:39
jnthn all?!
lizmat because it cannot find "use Test"
jnthn wowza, I've not seen that happen
Odd
lizmat Files=1096, Tests=0, 47 wallclock secs ( 3.76 usr 2.99 sys + 276.13 cusr 51.26 csys = 334.14 CPU)
it *is* a lot faster this way :-)
probably because it found an older "Test" in a precomp somewhere ? 13:41
sortiz Test is also a lib, so should be installed :-)
lizmat well, hence my question: do we expect "make spectest" to be run after "make install" or not ? 13:42
sortiz I don't. "make test" yes, "make spectest" no. 13:44
otoh, I'm thinking that all lib modules should be versionized and it's version tested to avoid this problems. 13:48
FROGGS nine++
lizmat ok, so, do I go about adding "use lib" to all files in roast that do "use Test" ? 13:55
jnthn: ^^ ?? 13:57
jnthn lizmat: Surely not, we'd just make the harness set PERL6LIB or pass -Ilib 13:59
nine lizmat: make spectest needs a make install since commit 1bbef9894156d7d326704069ca3c031ca5b96fce
i.e. we _did_ set PERL6LIB in harness before :)
jnthn That commit claims we "don't need" it
I'm not sure I agree ;) 14:00
nine Well such is the nature of development
14:03 Ven joined
Ven nine++ 14:03
sortiz: I do make install
lizmat nine: 14:04
aha... ok, so my fault :-(
14:05 RabidGravy joined
nine lizmat: you could as easily blame jnthn who didn't write a comment on why the PERL6LIB was actually needed in commit 1917a7a2. That said, I don't see a reason to blame anyone. 14:10
dalek kudo/nom: 8df1a69 | lizmat++ | t/harness:
Make "make spectest" work without "make install"
14:11
lizmat well, I blame myself :-(
Files=1096, Tests=52141, 263 wallclock secs (13.88 usr 4.36 sys + 1587.43 cusr 147.51 csys = 1753.18 CPU) # fwiw, without make install 14:12
[Coke] nine: (make install vs. make test). it was a commit of lizmat's, I can find it if you like. 14:14
... sounds like folks are already on it. 14:15
note that it required a chance to the release instructions as well.
Ven fwiw, make spectest seems to run. but ./perl6 -e "use Test;" not :o 14:25
can't quite investigate at all, just wanted to run a script at $work :). if there's a problem reproducing it, ping me 14:26
lizmat Ven: that's to be expected
as "make spectest" uses t/harness, which sets PERL6LIB=lib
(again) 14:27
Files=1107, Tests=52216, 267 wallclock secs (14.12 usr 4.21 sys + 1618.44 cusr 150.67 csys = 1787.44 CPU) # with Inline::Perl5 installed 14:35
sortiz enough for today, o/ #p6dev 14:58
lizmat sortiz /o 15:05
15:20 stmuk joined
lizmat jnthn timotimo: I'm considering changing the interface of nqp::p6sort: instead of taking a list of indices, it would take number of indices, and return the sorted indices 15:31
any objections against that ? 15:32
jnthn lizmat: No but remember you'll need to update the JVM impl too 15:34
lizmat ah, good point 15:42
ok, so much for that idea :-( 15:47
jnthn: maybe it is an idea to move the whole p6sort logic into Rakudo::Internals ? 15:52
provided it would mean an efficiency improvement, of course :-) 15:53
jnthn Well, yeah, are you going to come out ahead is an interesting question :)
It's possible that being smarter will overcome any NQP -> Perl 6 switch slowdown :) 15:54
And you could maybe eliminate the different code paths for JVM and Moar also
lizmat which would be helpful for the JS backend as well :-) 16:02
anyways, first afk for a few hours&
jnthn aye
17:10 geekosaur joined 17:15 Skarsnik joined
dalek rakudo/relocateable-precomp: f55e28b | (Stefan Seifert)++ | src/core/CompUnit/Repository/Installation.pm: 17:44
rakudo/relocateable-precomp: Turn short-name lookup files into directories
rakudo/relocateable-precomp:
rakudo/relocateable-precomp: This may become part of CompUnit::Repository::Installation format v1.
rakudo/relocateable-precomp: Having to change any already existing files on installation of a module makes
17:45 dalek joined 17:55 AlexDaniel joined 18:15 dalek joined
masak so, a method is a QAST::Block, right? 19:14
19:14 geekosaur joined
masak but not all QAST::Block nodes are methods. what can I ask a QAST::Block to find out whether it's a method? 19:14
nine Interesting read: lwn.net/SubscriberLink/680985/f0dc962f283dd854/ 19:16
jnthn masak: $block.ann('code_object') ~~ Method 19:27
QAST itself doesn't care
But it's annotated with the thing that does :)
19:29 FROGGS joined
masak jnthn: thanks :) 19:30
nine jnthn: do you have any idea for me on what could cause this message? QAST -> MAST failed while compiling op callmethod: Code ref '' does not exist in serialization context 19:36
jnthn: I've got the EVAL to compile with an almost completely shared World. This error now comes when serializing the outer comp unit 19:37
I guess the empty name is just because the CODE object is not a named sub or method 19:46
jnthn nine: Yeah, it must be some anon code block 19:52
nine Maybe the EVAL's comp_unit itself? How _does_ that get pushed into the sc? 19:53
jnthn nine: I don't have a guess, sorry. But I could as my next step I'd get that message to output the cuid 19:55
nine: Oh, you can also gets its .node to get a line/file I guess
Well, file you know
But line can tell you which block it is
nine Oh, that'd be lovely!
jnthn Either of those can help you figure out which block it is, which may make the bug a bit less opaque
I thought <unit> went in the same as any other code ref... 19:56
I may be misremembering
nine It probably should. I just can't find the code that actually does it. 19:57
jnthn nine: iirc it gets a code object build in the comp_unit action method. 19:58
Again, totally from memory :)
So may be wildly off :)
nine Trust your memory :) 19:59
20:12 dalek joined 20:18 dalek joined
[Coke] any developers going to be at baltimore perl workshop? (I'd only expect semi-locals, I guess) 20:28
jnthn
.oO( I can't remember the last time I forgot something... )
20:29
dalek p: 642013d | (Pawel Murias)++ | src/vm/js/ (4 files):
[js] Optimize joining Chunks by writing them to a file and reading it back in.

Also add a ChunkEscape to optimize generating quoted code. Source map support needs to be fixed in subsequent commits. Pass gen/t/qregex.t again.
20:44
[Coke] adding file io seems like a weird optimization. :) 20:52
21:10 [Tux] joined
masak ok, next question: it would seem I'm getting multiple hits per method 21:17
I'm also getting QAST::Block nodes that are annotated with a Method but that have no .name -- and I don't see that in my class 21:18
why is this?
more exactly, I seem to be getting my list of methods twice. the first copy of the list is mixed up with those anon methods. 21:19
dalek p: a5232c5 | jnthn++ | src/vm/moar/QAST/QASTCompilerMAST.nqp:
Fix failure to pop compiling SC for non-precomp.

This was one cause of EVAL in Perl 6 leaking. Similar fixes are likely needed for other backends if they have a similar code path to this.
21:20
jnthn masak: Maybe you're walking both the default and void of a QAST::Want node, which mostly refer to the same sub-tree?
No idea where the anon ones come from...though, do you have accessors? 21:21
masak no. this happens to be an Actions method, with no state.
I do have subs in my methods, though.
I thought it might be them.
jnthn m: say Method.^methods 21:22
camelia rakudo-moar 8df1a6: OUTPUTĀ«(gist <anon> <anon> <anon> soft <anon> <anon> yada perl <anon> onlystar candidates unwrap wrap <anon> <anon> package leave <anon> <anon> cando <anon> <anon> <anon> <anon> multi <anon> <anon> add_phaser has-phaser phasers assuming WHY set_why perl of <anon>ā€¦Ā»
jnthn Hm, I think there's a way to ask for the location
So you could maybe work out what the anon things are
Do you have any regexes?
Those are methods too
Well, Regex to be specific
You could .WHAT === Method to rule that out 21:23
(You'll rule submethods out along with them)
masak *nod*
yeah, they're Regex object 21:24
s*
ended up only caring about those that ~~ Method and have a .name 21:27
that'll make me still see submethods 21:28
and if I never descend into QAST::Want, I don't get the list twice
where can I read more about QAST::Want? I found the source, but it doesn't tell me much. 21:29
masak makes the mistake of looking at the commit log for that file. finds his own name a couple of times. blinks. 21:35
21:35 stmuk joined
masak QAST::Want... has something to do with compile-time values? 21:36
21:36 dalek joined
moritz masak: yes 21:39
for allomorphic things
that ca either be a str or a Str, for example
timotimo the optimizer can also turn some things into want nodes 21:40
mostly (only?) when something has been constant-folded
masak any idea why it's happening to my class? or at least to all the methods in it. 21:41
jnthn masak: We use it to avoid taking closures when methods are in void context. 21:47
masak aha. 21:51
in methods, there seems to always be a header/preamble (with variables and stuff)
jnthn The optimizer looks if the second child of want is 'v' and avoids walking any further ones
masak and then there's a QAST::Op p6typecheckrv
with a QAST::Stmts
and under that, all of the method body follows
jnthn Right
masak I guess I can count on this being true always?
jnthn um 21:52
masak heh
jnthn Well, it's well within the stuff we might refactor at some point :)
masak ok, I should state my goal, too
given a method, I want to iterate through its statements
so first I need to find them
and under the *current* regime, they seem to be under the QAST::Stmts under the QAST::Op p6typecheckrv 21:53
I'm fine with things changing with future refactors of QAST
I'm curious how things are today
jnthn Well, you can rely on it today :) 21:54
But that op is a little too "late bound"
So it'll be an optimization target at some point 21:55
masak *nod*
I'll take my chances
if I write tests for this, then they will simply break when that day comes
which is goodenuf
jnthn :) 21:56
21:56 Skarsnik joined, MadcapJake joined
jnthn Enough for today, time to rest o/ 21:56
masak 'night, jnthn
what's a QAST::SpecialArg? 21:57
timotimo named arguments, or slurpies
i think the latter, actually
at least i think that's what it is?
gotta run now :S
masak :) 21:58
yeah, that makes sense
it has properties 'named' and 'flat'
lizmat decides she's too tired to do any more hacking 22:10
moritz regular named args are just QAST nodes with .named set, iirc
lizmat so good night, #p6dev!
moritz lizmat: good night, sensible decision :-)
moritz also goees to sleep
lizmat good night, moritz
masak good night lizmat; moritz 22:13
22:13 stmuk_ joined
masak this is what I have so far: a method has a .[1] which is a p6typecheckrv, which has a .[0] which is a QAST::Stmts, which has a .[0] which is a lexotic, which has a .[0] which is a p6decontrv 22:15
below that node, the actual statements are found
(excpet for a spurious first node which seems to always be a QAST::WVal)
except*
the really nice news is that the statements are actual QAST::Stmt nodes 22:16
22:19 skids joined 22:20 geekosaur joined
masak oh, it continues down for two more levels. never mind. 22:23
yay, it's working
TIL: if statements and for loops are QAST::Stmt, but while loops are QAST::Op
nested subs are QAST::Want 22:24
timotimo moritz: afaik when you call .named on a regular qast to set a name, it'll mix in SpecialArg to store the named 23:20
masak this seems true, from reading QAST::Node 23:23
ditto .flat