00:38 colomon joined 01:06 colomon joined 01:21 vendethiel joined 02:11 vendethiel joined
awwaiid I'm tracing through to understand how eval in the REPL works, via some nqp::say statements in nqp/src/HLL/Compiler.nqp method eval. I'm just modifying the one that rakudo grabbed for me when it built itself. But my changes don't seem to be sticking, even when I do a make inside of nqp/ and then one in the main rakudo/ dir. Any tips? 02:41
I tried make clean in both and that didn't help 02:42
03:19 geekosaur joined
skids awwaid: maybe cd into the nqp subdir and git commit? 03:26
Also, delete the nqp binary
04:02 vendethiel joined 04:25 geekosaur joined 04:43 vendethiel joined
nine awwaiid: did you do a "make install" in the nqp/ dir? 06:10
06:43 vendethiel joined
Woodi about ForeignCode things nine++ described: is such system a good-one ? or is there from historical research/development reasons ? anyway, got idea: what about internal (p6 comunity) "blog" for such findings ? :) or some more permament then logs medium 06:59
07:47 RabidGravy joined
jnthn ForeignCode just means "this thing didn't have a Perl 6 code object, so we faked one up so you can use it a bit like a Perl 6 code object" 08:56
Just a part of the usual hllize thing. 08:57
psch Woodi: permanence isn't something i'd worry about wrt the clog, structure is 08:58
Woodi: but that's also again time that someone has to spend on blogging instead of hacking 08:59
sure, a p6dev weekly (or maybe monthly, or maybe just interesting discussion summarized and structured) would be neat, but who's gonna write it..? :)
fwiw, for the jvminterop i had wondered if attaching a more meaningful signature to a ForeignCode would be feasible 09:00
because we then could use the Binder a bit more meaningfully when trying to call Java methods 09:02
10:13 btyler joined
Woodi psch: belive me, devs time is my looking-stupid-ramblings priority. also not forcing them to artificial or rigid or non-voluntary schemas. just seeing that some unobtrusive, almoust no time taking bag of notes could be usefull. you have something interesting and what ? ignore: possibly; docs: no; blog: no; faq: no; irc logs: grepping years of text isn't. so something can be invented :) also ignored until 10:26
not invented...
Woodi shuts up
psch Woodi: as i said, i think the idea has merit. someone just has to actually do it :) 10:31
jnthn One of the few times a large amount of internals docs got written was for the Rakudo/NQP internals course 10:39
nine (conference driven documenting)++ 10:44
All Inline::Perl5 examples were written for conference talks.
jnthn nine: Actually, that was a case of "generous sponsor hired me (through $dayjob) to write and deliver the course" 10:45
nine sponsor++ 10:46
timotimo sponsor++ # again and again
jnthn Had that not been the case then it would likely not have happened, or woulda come at the cost of me having time for no Perl 6 development work for at least a month 'cus I was spending it all writing the tutorial.
I've done my share of conference driven dev also, of course ;-) 10:47
Though it's often for live demos... :) 10:48
dalek p: 64e50da | (Pawel Murias)++ | src/vm/js/ (2 files):
[js] Implement nqp::setdebugtypename.
11:29 pmurias joined
pmurias jnthn: if I implement nqp::p6* ops directly in nqp-js will it cause trouble? 11:30
jnthn pmurias: Why do that, ooc? 11:38
It'd probably not be a *technical* problem, but it would make a change that currently only needs changes in the Rakudo repo also need changes in the NQP one
lunch, bbi20 11:39
12:17 pmurias joined
awwaiid nine: make install helps, thanks! 12:25
dalek kudo/nom: cb27a19 | hoelzro++ | src/core/REPL.pm:
REPL6: Disable REPL6 on JVM

Currently, trying to initialize the compiler object in the REPL causes a java.lang.StackOverflowError.
kudo/nom: 600eb53 | hoelzro++ | docs/line-editor.pod:
Add some docs on the REPL and line editors
13:10 geekosaur joined 13:24 pmurias joined, [Tux] joined 13:27 |Tux| joined 13:28 skids joined 15:24 teatime joined 15:29 vendethiel joined 16:09 lizmat joined 16:29 pmurias joined
dalek p: 875e3ad | (Pawel Murias)++ | src/vm/js/RegexCompiler.nqp:
[js] Fix compiling a pass regex node with a dynamic name.
p: f0939b3 | (Pawel Murias)++ | t/nqp/66-pararole.t:
Test token ::($method) {...}.
17:29 lizmat_ joined, _z joined
lizmat irclog.perlgeek.de/perl6/2016-04-05#i_12290598 18:35
making Hash.gist give {} breaks a few spectests that depend on .gist
unrelated to Hash per se 18:36
before I commit this patch, do we agree that Hash.gist should have {} like Array.gist has [] ?
m: say []; say {} 18:37
camelia rakudo-moar 600eb5: OUTPUT«[]␤␤»
18:38 FROGGS joined
lizmat masak: ^^^ ?? 18:38
18:39 vendethiel joined
sortiz lizmat, +1 # My 2¢ 18:40
[Coke] m: my %a; say %a; 18:41
camelia rakudo-moar 600eb5: OUTPUT«␤»
[Coke] yah, seems reasonable to me to add.
lizmat m: dd ¾ 18:43
camelia rakudo-moar 600eb5: OUTPUT«0.75␤»
masak I am happy about how much of github.com/masak/data-pretty is now done by vanilla Rakudo. 18:54
{} for hashes (though I don't seem to have included that as something to fix in data-pretty) would be a step in that same, right direction
if you're looking for prior art, Python already has it that way 18:55
though it is an interesting question whether this constitutes a breaking API change, and requires some sort of deprecation
skids -errata maybe?
lizmat well, having tests depend on the behaviour of .gist, is just a red flag to me, really 18:56
jnthn Well, given it regresses spectests, we should be a bit cautious
Tests depending on .perl output is fairly clear-cut 18:57
Whereas "say" is used a lot for actual output.
lizmat so, I would then change the tests to use .perl instead of .gist
btyler masak: all the way to Python for prior art? what about good old Data::Dumper? :P
jnthn lizmat: Uh...no :P 18:58
lizmat: I'm saying we have to be careful *because* the tests test .gist
lizmat: And that means we claimed that gist working this was is something we support
masak btyler: Data::Dumper is another good example, though the Perl 6 analogue to that would be .perl, not .gist
btyler fair point, given the eval-ability
jnthn So it's on the "can we get away with it" territory
I somewhat suspect we can 18:59
masak btyler: in Python, they don't have .gist -- instead all data structures just stringify to something sensible already :P
lizmat well, if I thought we shouldn't do this, I wouldn't have tried it, or bring it up here :-)
jnthn masak: uh... __str__ vs __repr__? :)
masak jnthn: I stand corrected 19:00
jnthn lizmat: I guess we can see what ecosystem fallout there is :)
masak jnthn: though overall I still feel that Python wins in terms of sensible stringifications
jnthn lizmat: I mean, I like the change...I just want a little caution on such things so we don't end up in a position where people are like "gah they said the language was stable then busted my code" :) 19:01
If I had to guess, the fallout of this one will be rather low, though.
So I think, let's try it and see if the ecosystem should get annoyed with us. :) 19:02
19:22 teatime joined 19:29 hankache joined
dalek kudo/nom: c12d407 | (Salvador Ortiz)++ | src/Perl6/Metamodel/DefiniteHOW.nqp:
Add .shortname to DefiniteHOW

Since DefiniteNOW don't "does" Metamodel::Naming. it needs a shortname method, unconditionally used by Mu.gist
See irclog.perlgeek.de/perl6/2016-02-01#i_11970457 Test:
  <sortiz> m: Int:D.gist
  <camelia> rakudo-moar a5fe34: OUTPUT«Method 'shortname' not found for invocant of class 'Perl6::Metamodel::DefiniteHOW'␤ in block <unit> at /tmp/3vJXmqV_i_ line 1␤␤»
rakudo/nom: a331b5b | moritz++ | src/Perl6/Metamodel/DefiniteHOW.nqp:
rakudo/nom: Merge pull request #701 from salortiz/Definite-shortname
ast: e7fb85a | moritz++ | S12-coercion/coercion-types.t:
RT #127841: .gist on coercion type objects
kudo/nom: 6a2ff75 | lizmat++ | src/core/Hash.pm:
Curlify Hash.gist, like Array.gist is bracketed
b2gills lizmat: I fixed PR #686 so that it cleanly applies 20:04
dalek kudo/nom: 0fafd86 | (Brad Gilbert)++ | src/core/operators.pm:
Fix permutations(1) with early IterationEnd

If the loop is run it would try to produce a second value causing it to attempt to access @!a[-1]
kudo/nom: c8ec5ac | lizmat++ | src/core/operators.pm:
Merge pull request #686 from b2gills/patch-4

Fix permutations(1) with early IterationEnd
ast: ff44772 | (Brad Gilbert)++ | S32-list/permutations.t:
Test permutations(1) and (1,).permutations

This is an edge case that regularly gets overlooked
roast: d64d2eb | (Brad Gilbert)++ | S32-list/permutations.t:
roast: Test permutations(0) and ().permutations
skids Hrm, could someone look at PR#732 and roast PR#110 if permutations/combinations are about to be touched? 20:20
20:24 pmurias joined
lizmat good night, #perl6! 20:26
skids o/
21:16 travis-ci joined
travis-ci Rakudo build errored. lizmat 'Merge pull request #686 from b2gills/patch-4 21:16
travis-ci.org/rakudo/rakudo/builds/120990156 github.com/rakudo/rakudo/compare/6...ec5aca8bb4
21:16 travis-ci left, awwaiid joined
psch as a heads up, the travis failure is about github being on maintenance 21:45
22:24 _z joined 22:34 skids joined
b2gills I can finally remove the workaround in this code golf: codegolf.stackexchange.com/posts/7.../revisions 22:45
23:04 lizmat joined