Perl 6 - the future is here, just unevenly distributed

IRC log for #p6dev, 2016-04-04

| Channels | #p6dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:12 AlexDaniel joined #p6dev
00:13 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:38 vendethiel joined #p6dev
01:07 vendethiel joined #p6dev
01:35 vendethiel joined #p6dev
01:47 ilbot3 joined #p6dev
01:47 Topic for #p6dev is now Perl 6 language and compiler development
04:32 vendethiel joined #p6dev
04:50 geekosaur joined #p6dev
06:56 stmuk_ I never liked "grep" despite typing it nearly everyday
07:50 hankache joined #p6dev
07:56 RabidGravy joined #p6dev
07:58 nine As long as we're bikeshedding, I could live with "grab" ;)
08:12 jnthn Has TimToady indicated a desire to change it?
08:13 jnthn Becasue that's the only way it's going to happen, and given there was a 15 year window to do it...
08:23 nine jnthn: I'm pretty sure he hasn't :)
08:36 jnthn I thought not ;)
08:36 vendethiel joined #p6dev
09:06 vendethiel joined #p6dev
09:11 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␤»
09:43 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:44 jnthn And I note that in the backlog on *this* channel, TimToady was also -1 to it. So, the issue is closed.
10:00 lizmat jnthn: so the problems with utf8-c8 are fixed and [Tux] can be happy ?
10:02 jnthn lizmat: The RT'd bug with utf8-c8 is fixed... ;)
10:03 lizmat fair enough...  :-)
10:12 jnthn lizmat: I hope to get to that configurable newline translation shortly too :)
10:12 lizmat :-)
10:27 lizmat P6W: https://p6weekly.wordpress.com/2016/04/04/2016-14-wow-zoffix/
10:32 stmuk_ lizmat++
10:35 timotimo wow, so early
10:36 timotimo 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:37 vendethiel joined #p6dev
10:53 jnthn lizmat: Also I got a huge performance improvemnet in when reading very long lines with .get (and for $foo.lines { })
10:53 jnthn lizmat: So if you have a single line of text that's about 10MB long then it was something like 100x faster :)
10:54 jnthn lizmat: Though I'll mention that in my weekly post (which I'll write today...)
10:54 jnthn (And so can link it next time :))
10:55 timotimo lizmat: http://blogs.perl.org/users/sylvain_colinet/2016/03/rewriting-gumbo-binding---a-gptrixie-demo.html skarsnik really wanted this to go in; how to best add it? put a little "Edit:" section? "Update:"?
10:56 jnthn Oh, and lizmat++ for the weekly :)
10:56 timotimo yes, quite the pluspluses :D
11:14 [Coke] lizmat++ weeklies and just daily effort. Danke!
11:16 hankache lizmat++ merci :)
11:30 vendethiel joined #p6dev
11:59 vendethiel joined #p6dev
12:29 [Coke] so, to move the #perl6 chat here..
12:29 [Coke] I object to putting development/bleeding edge stuff in nom.
12:30 [Coke] 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 [Coke] and nom can be like our "develop" branch in a gitflow setup
12:31 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.
12:31 lizmat unrelated to this discussion:
12:31 [Coke] so if we need better project management to make this happen, now's the time.
12:31 * lizmat goes cycling
12:32 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)
12:33 timotimo [Coke]: i'm not sure if you saw; the js stuff is in pmurias' rakudo fork
12:34 AlexDaniel joined #p6dev
12:34 [Coke] with a confusingly similar name to rakudo/rakudo :)
12:34 timotimo yeah
12:35 timotimo 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 #p6dev
12:38 timotimo right; i was just refering to making it say "pmurias" on channel, so we can tell what comes from what repo
12:40 pmurias joined #p6dev
12:46 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 #p6dev
13:18 dalek rakudo/js: 2709d73 | (Pawel Murias)++ | / (3 files):
13:18 dalek rakudo/js: [js] Start work on compiling rakudo to js.
13:18 dalek rakudo/js: review: https://github.com/rakudo/rakudo/commit/2709d73632
13:21 [Coke] If we're going to have CLAs, we probably shouldn't hand out commit bits without them.
13:21 [Coke] Seems to defeat the point.
13:37 skids joined #p6dev
13:42 dalek rakudo/nom: 8ce7c70 | hoelzro++ | src/core/REPL.pm:
13:42 dalek rakudo/nom: REPL6: move linenoise and readline mixing in into subs
13:42 dalek rakudo/nom:
13:42 dalek rakudo/nom: This is to make the code cleaner, but also to to pave the
13:42 dalek rakudo/nom: way for changing the line editor load order more easily
13:43 timotimo poor dalek
13:43 dalek joined #p6dev
14:13 vendethiel joined #p6dev
14:52 hoelzro =( sorry dalek
14:52 hoelzro my commits always break dalek
14:53 vendethiel joined #p6dev
15:16 lizmat afk for the next day or so&
15:23 [Coke] ~~
15:28 vendethiel joined #p6dev
15:50 sortiz joined #p6dev
16:38 vendethiel joined #p6dev
16:41 geekosaur joined #p6dev
16:42 pmurias joined #p6dev
16:50 nine Sometimes I think it's easier to read MoarMV's code than rakudo's
17:28 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:34 vendethiel joined #p6dev
17:47 hankache joined #p6dev
17:57 masak skids: in the 007 test suite, we use a DSL that looks a bit like Lisp for such syntactic relief.
17:57 masak 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 #p6dev
18:30 stmuk joined #p6dev
18:43 geekosaur joined #p6dev
18:47 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:51 nine 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
19:03 masak depends what other parts expect it to be a comp_unit, I guess...
19:51 nine What exactly is "dynamic compilation"?
20:08 nine 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␤»
20:08 nine So EVAL'ed Perl 6 code is ForeignCode?!
20:17 pyrimidine joined #p6dev
20:22 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:34 nine I think for the first time in weeks, I actually have a hypothesis that's worth testing
20:37 nine 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:38 nine 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:40 nine 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.
21:29 AlexDaniel joined #p6dev
21:59 lizmat joined #p6dev
22:34 vendethiel joined #p6dev
22:44 skids joined #p6dev
23:08 vendethiel joined #p6dev
23:20 TimToady joined #p6dev
23:52 vendethiel joined #p6dev

| Channels | #p6dev index | Today | | Search | Google Search | Plain-Text | summary