00:12 AlexDaniel joined
AlexDaniel I'd love to see some alternative to “grep”. Just so that I don't have to explain what grep is to non-unixers 00:13
00:38 vendethiel joined 01:07 vendethiel joined 01:35 vendethiel joined 01:47 ilbot3 joined 04:32 vendethiel joined 04:50 geekosaur joined
stmuk_ I never liked "grep" despite typing it nearly everyday 06:56
07:50 hankache joined 07:56 RabidGravy joined
nine As long as we're bikeshedding, I could live with "grab" ;) 07:58
jnthn Has TimToady indicated a desire to change it? 08:12
Becasue that's the only way it's going to happen, and given there was a 15 year window to do it... 08:13
nine jnthn: I'm pretty sure he hasn't :) 08:23
jnthn I thought not ;) 08:36
08:36 vendethiel joined 09:06 vendethiel joined
psch m: my $b = BagHash.new(<a b c>); my $g = $b.grab(2); say $b.perl 09:11
camelia rakudo-moar 868d8b: OUTPUT«("c"=>1).BagHash␤»
jnthn Anyway, -1 from me to yet more churn. I'm not going to read up on the discussion, just note that, as pumpking, I'm a bit tired of people thinking that such fundementals are still "in play" at this point in time. 09:43
And I note that in the backlog on *this* channel, TimToady was also -1 to it. So, the issue is closed. 09:44
lizmat jnthn: so the problems with utf8-c8 are fixed and [Tux] can be happy ? 10:00
jnthn lizmat: The RT'd bug with utf8-c8 is fixed... ;) 10:02
lizmat fair enough... :-) 10:03
jnthn lizmat: I hope to get to that configurable newline translation shortly too :) 10:12
lizmat :-)
P6W: p6weekly.wordpress.com/2016/04/04/...ow-zoffix/ 10:27
stmuk_ lizmat++ 10:32
timotimo wow, so early 10:35
maybe it'd be good to point out to readers of the perl weekly that they may not have seen last week's p6weekly yet 10:36
10:37 vendethiel joined
jnthn lizmat: Also I got a huge performance improvemnet in when reading very long lines with .get (and for $foo.lines { }) 10:53
lizmat: So if you have a single line of text that's about 10MB long then it was something like 100x faster :)
lizmat: Though I'll mention that in my weekly post (which I'll write today...) 10:54
(And so can link it next time :))
timotimo lizmat: blogs.perl.org/users/sylvain_coline...-demo.html skarsnik really wanted this to go in; how to best add it? put a little "Edit:" section? "Update:"? 10:55
jnthn Oh, and lizmat++ for the weekly :) 10:56
timotimo yes, quite the pluspluses :D
[Coke] lizmat++ weeklies and just daily effort. Danke! 11:14
hankache lizmat++ merci :) 11:16
11:30 vendethiel joined 11:59 vendethiel joined
[Coke] so, to move the #perl6 chat here.. 12:29
I object to putting development/bleeding edge stuff in nom.
if we're going to stick with releasing from nom, we should be putting anything that isn't going to be done before the release into a feature branch. 12:30
and nom can be like our "develop" branch in a gitflow setup
jnthn [Coke]: My original proposal was that nom stays as development, and we do CD to master 12:31
[Coke] Historicalyl we have not been great at reviewing branches, but historically we didn't have a 6.c release in the wild.
lizmat unrelated to this discussion:
[Coke] so if we need better project management to make this happen, now's the time.
lizmat goes cycling
timotimo have a good cycle :) 12:32
[Coke] jnthn: as long as we're not putting bleeding edge stuff into the "nearly the release" branch, that's fine. I don't particularly care what they are called (though I have a slight pref to using the gitflow names)
timotimo [Coke]: i'm not sure if you saw; the js stuff is in pmurias' rakudo fork 12:33
12:34 AlexDaniel joined
[Coke] with a confusingly similar name to rakudo/rakudo :) 12:34
timotimo yeah
i wonder if the github hook sends something that'd let us differentiate 12:35
moritz sure, but it's the hook configuration that decides where messages should go
12:36 brrt joined
timotimo right; i was just refering to making it say "pmurias" on channel, so we can tell what comes from what repo 12:38
12:40 pmurias joined
moritz timotimo: see #perl6; the solution seems to be that pmurias develops in the main repo in a branch for now 12:46
timotimo OK
12:51 vendethiel joined
dalek kudo/js: 2709d73 | (Pawel Murias)++ | / (3 files):
[js] Start work on compiling rakudo to js.
 13:18
[Coke] If we're going to have CLAs, we probably shouldn't hand out commit bits without them. 13:21
Seems to defeat the point.
13:37 skids joined
dalek rakudo/nom: 8ce7c70 | hoelzro++ | src/core/REPL.pm: 13:42
rakudo/nom: REPL6: move linenoise and readline mixing in into subs
rakudo/nom:
rakudo/nom: This is to make the code cleaner, but also to to pave the
rakudo/nom: way for changing the line editor load order more easily
timotimo poor dalek 13:43
13:43 dalek joined 14:13 vendethiel joined
hoelzro =( sorry dalek 14:52
my commits always break dalek
14:53 vendethiel joined
lizmat afk for the next day or so& 15:16
[Coke] ~~ 15:23
15:28 vendethiel joined 15:50 sortiz joined 16:38 vendethiel joined 16:41 geekosaur joined 16:42 pmurias joined
nine Sometimes I think it's easier to read MoarMV's code than rakudo's 16:50
skids I think it's kind of crazy we end up with all this QAST::Node.new() word salad. Hopefully at some point optimizable syntactic relief will be possible there. 17:28
17:34 vendethiel joined 17:47 hankache joined
masak skids: in the 007 test suite, we use a DSL that looks a bit like Lisp for such syntactic relief. 17:57
it used to help more than it currently does, basically because the Lisp got more wordy as the project grew more ordered.
18:25 Ven joined 18:30 stmuk joined 18:43 geekosaur joined
nine Why is <unit> a closure when we explicitly oppose that? $unit.blocktype('declaration_static'); # Do not want closure semantics on this outermost scope. 18:47
I also wonder if we even need a complete comp_unit for an EVAL that runs at compile time. Wouldn't it suffice to compile the code to a block and run that immediately? There's so much machinery that doesn't make sense for a compile time EVAL 18:51
masak depends what other parts expect it to be a comp_unit, I guess... 19:03
nine What exactly is "dynamic compilation"? 19:51
m: use nqp; my $compiler := nqp::getcomp("perl6"); my $compiled := $compiler.compile("1", :outer_ctx(nqp::getattr(nqp::decont(CALLER::), PseudoStash, <$!ctx>)), :global(GLOBAL)); say $compiled.^name; 20:08
camelia rakudo-moar 0e95cd: OUTPUT«ForeignCode␤»
nine So EVAL'ed Perl 6 code is ForeignCode?!
20:17 pyrimidine joined
nine Now I finally understand what the stub is for and why it never gets run! We do actually run the fixup code somewhere 20:22
I think for the first time in weeks, I actually have a hypothesis that's worth testing 20:34
We create a closure for the comp_unit's mainline with a stub code object and fixup code that replaces the stub with the real block. The stub is added to the SC. We run the comp_unit which causes the fixup code to run which replaces the stub. Later, we try to serialize the comp_unit and fail because the actual code block was never added to the SC. Only the stub was. 20:37
I've been so close to this for weeks but only today I had the ~ 5 hours of quiet, almost uninterrupted quality time to really dig through the compilation code from start to finish to finally understand this. 20:38
What's been so confusing is that we e.g. have a deserialize_frame and run it despite never serializing the comp_unit object in this case. 20:40
21:29 AlexDaniel joined 21:59 lizmat joined 22:34 vendethiel joined 22:44 skids joined 23:08 vendethiel joined 23:20 TimToady joined 23:52 vendethiel joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!