Perl 6 - the future is here, just unevenly distributed

IRC log for #rakudosketch, 2010-04-20

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

All times shown according to UTC.

Time Nick Message
11:30 [particle]1 joined #rakudosketch
12:03 sorear joined #rakudosketch
14:02 sorear joined #rakudosketch
14:23 sorear joined #rakudosketch
15:00 colomon joined #rakudosketch
15:01 masak joined #rakudosketch
15:07 masak I won't be able to make it this time either (gasp). but my report goes something like this: I've submitted many RT tickets lately, and plan on submitting many more.
15:08 masak I'm also listed for two "Really important items" in the ROADMAP, at least as co-implementor.
15:08 masak I'll be happy to work on those, but will probably need at least initial hand-holding from jnthn++.
15:08 masak .eor
15:38 jnthn masak: thanks.
15:38 jnthn :-)
15:39 jnthn masak: I think bkeeler++ has done a lot of the lexical variables, and is blocking on input from Pm.
15:39 masak \o/ bkeeler++
15:39 jnthn masak: The auto-viv one though, nobody worked on that yet.
15:40 masak probably needs to start with a re-think of the so-called Proxy class.
15:42 jnthn Nod
15:43 jnthn I think that was expected to be a temporary measure anyway.
15:50 masak sort of a proxy for the real thing, eh?
15:51 jnthn ;-)
18:30 mberends joined #rakudosketch
18:45 diakopter joined #rakudosketch
18:59 CokeBot9000 Hey, I updated a single spec test this week.
19:00 jnthn o/
19:00 mberends \o
19:00 jnthn OK, who's about?
19:01 jnthn masak++ left a report earlier.
19:02 mberends let's not talk about the past as much as the future
19:02 jnthn Indeed.
19:03 jnthn I'm just glancing the ROADMAP. :-)
19:03 jnthn Probably the biggest worry I have at the moment is:
19:03 jnthn 1 **    complete lazy lists in Seq and Array (colomon, bkeeler, jnthn, pmichaud, others)
19:03 jnthn That one.
19:04 jnthn Of the others, they're either in progress, relatively easy or at least a known quantity.
19:04 * colomon reporting in.
19:04 jnthn o/ colomon
19:04 jnthn This one...I think there's still some design-level issues.
19:05 colomon The lazy lists things isn't just the scariest, it's also the biggest, IMO.
19:05 colomon jnthn: absolutely still design issues.
19:05 jnthn OK. :-(
19:05 PerlJam greets
19:06 jnthn colomon: I wonder if trying to create a wiki page of current known issues with design and implementation, so at least we can give some list of the known problems, whould help.
19:06 colomon We do have that patch sitting around for lazy Seq and Array, which needs a good close looking at.  My apologies for not getting to that yet.
19:06 jnthn Do you have a link handy?
19:06 colomon wiki page, or just a quick file in the in Rakudo file tree somewhere?
19:06 jnthn I don't mind either way
19:06 colomon http://rt.perl.org/rt3/Public/Bug/Display.html?id=74008
19:06 jnthn Well
19:06 jnthn Thing is that anyone can edit the wiki
19:06 colomon The tab has been sitting open in my browser for more than a week.
19:06 jnthn Only committers can do the file
19:07 colomon jnthn: good point.
19:07 pmichaud joined #rakudosketch
19:07 colomon perhaps the scariest thing about this issue is that it seemed to be scaring off pmichaud...
19:08 jnthn I don't have much of a grasp on it either. :-(
19:08 jnthn I mean, I understand some of the problems, but solutions, well...that's trickier.
19:09 smash_ joined #rakudosketch
19:09 * jnthn has opened up the lazy Seq/Array patch too.
19:10 pmichaud are we talking about the list issues?
19:10 jnthn pmichaud: Yes
19:10 pmichaud ah.  I wasn't scared off by it, I got real-life distracted :-|
19:10 pmichaud I still intend to clean all of that up, fsvo "clean"
19:10 jnthn pmichaud: It's in some ways the most immediately concerning priority 1 issue in the ROADMAP for many of us.
19:11 bkeeler joined #rakudosketch
19:11 bkeeler Heyas
19:11 jnthn oh hai
19:11 pmichaud yes, and it's likely to have effects throughout the codebase :-(
19:11 colomon pmichaud++
19:11 pmichaud anyway, I'll plan to take a look at it this week.
19:11 jnthn pmichaud: Yes, it may cause some pain.
19:12 colomon and absolutely will have effects everywhere, I imagine.
19:12 colomon but that just makes it a higher priority.
19:12 jnthn Well, yes. It's better to have the pain now.
19:12 jnthn Than closer to R*.
19:12 jnthn That's why I started on the lexical setting stuff.
19:12 colomon honestly, from my biased POV, if we can get lists nailed down, I'd be pretty comfortable releasing what we have otherwise as R*.
19:13 pmichaud I need to look at the roadmap (and perhaps someone(s) could update it for me?)
19:13 colomon though it would be awesome if chromatic or someone could come through with a patch to reduce memory usage.  :)
19:13 jnthn I wouldn't go that far, but I would agree it's probably the thing that'd create the most pain from a user perspective.
19:13 jnthn pmichaud: The ROADMAP is up to date already, afaik.
19:14 jnthn pmichaud: We've been keeping it that way. :-)
19:14 pmichaud jnthn:  +1
19:14 pmichaud okay, I'll go take a look there then.
19:14 jnthn On:
19:14 jnthn 1 **    improved error messages and failure modes (B, all)
19:14 jnthn At a parse level, we're often doing quite well there now.
19:15 jnthn The big issue is runtime errors which lack the line numbers. :-|
19:15 jnthn If we can nail those to a good degree, at say we're doing well on this one.
19:16 jnthn We've got a lot of the STD errors in place, including much of the obs stuff.
19:16 pmichaud for the runtime errors, is that mainly getting some decent code to follow up annotations?
19:16 jnthn pmichaud: Yeah
19:16 jnthn pmichaud: And maybe some Parrot bugs too.
19:16 jnthn pmichaud: I don't know how bad it is.
19:16 pmichaud I think the tricky part it figuring out the names to report or not report in the backtrace
19:16 jnthn Yeah
19:17 jnthn To some degree you can go on "is it a routine"
19:17 jnthn It's a reasonable heuristic, anyway.
19:17 pmichaud well, I was also hoping to be able to provide something in the compiler tools that is more hll-generic
19:17 pmichaud but perhaps Rakudo wouldn't be using that anyway
19:17 jnthn pmichaud: We could always take the "do something in Rakudo and if you like it, it can be stolen down to NQP level" or some such.
19:18 pmichaud well, not if the "do something in Rakudo" is checking for ~~ Routine.
19:18 jnthn Well, no, but if we have a mechanism where a certain method gets called once per block then we could just subclass the one method in Rakudo
19:18 pyrimidine joined #rakudosketch
19:19 pmichaud Parrot's inability to easily create subclasses of Sub is often a pain.  :-(
19:19 jnthn And have the overall walking of the annotations for each Parrot-level stack frame done in the compiler tools.
19:19 jnthn Well, we ain't any more. We're wrapping them. :-)
19:19 pmichaud jnthn: +1, I'll think on that a bit.
19:19 pmichaud jnthn: *we're* wrapping them, yes, but other HLLs typically aren't (yet)
19:19 jnthn True.
19:19 jnthn pmichaud: How far did you get looking at moritz_++'s patch?
19:20 * jnthn didn't see whether that ended with moritz_ having things to go away and hack on or not.
19:20 pmichaud a good distance; it uses a few globals and lookups where I'd prefer to see things method-based
19:20 jnthn OK
19:20 pmichaud I need to figure out where the "promote capture to array" function should go.
19:20 jnthn nod.
19:21 jnthn One other thing I wanted to ask about:
19:21 jnthn 1 *     array/hash vivification (masak, jnthn, pmichaud)
19:21 jnthn You gave this one star which in theory means it's not a lot of work.
19:21 jnthn But I'm not quite sure exactly what you had in mind.
19:21 jnthn Can you remember/explain, then one of us maybe can work on that?
19:22 pmichaud it wasn't a lot of work at the time.  but now it's a bit more work, because the definition of Nil/Any/Mu has changed a bit since then
19:22 jnthn Ah.
19:22 pmichaud a related question is whether we have WHENCE working yet
19:22 jnthn No
19:22 pmichaud without WHENCE, whatever we do now is a workaround
19:22 jnthn Is the Real Solution to put WHENCE back correctly?
19:23 pmichaud TimToady++ keeps saying that WHENCE is the standard answer for vivification issues, yes.
19:23 jnthn He does, but I'm not sure I always follow. :-)
19:23 jnthn I guess what I struggle on is: is this somehow "in-place" or not?
19:23 pmichaud I figured it out at one point but have forgotten it today.
19:23 pmichaud what does "in-place" mean?
19:23 jnthn I mean, my $a; $a<x> = 42;
19:23 pmichaud right.
19:23 jnthn In this is $a now a Hash?
19:24 pmichaud So, $a starts out as the Any protoobject.
19:24 jnthn If so, how'd that happen? :-)
19:24 jnthn *nod*
19:24 pmichaud subscripting it returns something that has a WHENCE that when assigned to causes $a to become a Hash.
19:25 pmichaud something like that
19:25 jnthn I guess since assignment calls !STORE it's just like any other method call triggering the WHENCE?
19:25 pmichaud yes.
19:26 jnthn OK. Here's The Problem I See.
19:26 jnthn $a<x> = 42;
19:26 pmichaud however, last time we were discussing this on #perl6 (back in Feb I think) we noted a few corner cases that cause issues.
19:26 jnthn Calls $a.postcircumfix:<{ }>('x')
19:26 jnthn Which may decalarref $a
19:26 jnthn And then we lost the container.
19:26 jnthn But maybe not
19:27 jnthn Because it goes through !postcircumfix sub first
19:27 jnthn So perhaps we get away with it there. :-)
19:27 pmichaud relying on !postcircumfix sub is likely wrong.
19:27 jnthn Well, throwing away the container on invocants is likely wrong too...
19:27 jnthn We only do it for langauge interop.
19:27 pmichaud it's okay if we lose the container -- the value object probably needs to mutate (i.e., 'copy' opcode)
19:27 * jnthn is very confused
19:28 jnthn my $a; # now $a has the Any proto-object in
19:28 jnthn We can't go and copy over the proto-object!
19:28 pmichaud $a may need to be a copy of the protoobject then.
19:28 jnthn Er
19:29 jnthn I fear that'll hurt too
19:29 jnthn my $a; say $a === Any
19:29 pmichaud agreed; this is where I remember the discussion leaving off :)
19:29 jnthn Ah.
19:29 jnthn Well
19:30 jnthn I think we will break *far* too much - and incur a lot of cost - if we take the "copy the proto-object" route.
19:30 pmichaud agreed.
19:30 jnthn I'm sure we've got a _lot_ of code in Rakudo that relies on that not happening.
19:30 pmichaud personally, I'm wondering if the autovivify hash/array is really that desirable.
19:31 jnthn I think the main use case is more like my %h; %h<a><b><c> = 42
19:31 pmichaud yeah, and that's the part where I remind myself "yes, it's probably desirable"  :-|
19:32 jnthn In a sense, the "descalarref the invocant" may already mean we have a bug, fwiw.
19:32 jnthn sub foo($x is rw:) { ... }
19:32 jnthn I'll bet that is broken in Rakudo today.
19:32 jnthn erm, method
19:32 jnthn not sub
19:33 pmichaud oh?
19:33 pmichaud does $x is rw: there man that we're affecting the container?
19:33 pmichaud *mean
19:33 jnthn Well, is rw normally does.
19:33 pmichaud yes, but not with method calls.
19:33 jnthn sub foo($x is rw) { $x = 42; }; my $a; foo($a); say $a;
19:33 pmichaud right, but that's not via a method call.
19:33 jnthn That affects $a
19:33 jnthn It's not
19:34 jnthn I guess what I'm asking is: should "is rw" on an invocant work?
19:34 pmichaud so that
19:34 pmichaud method foo($x is rw:) {    $x = ... }
19:34 pmichaud would cause foo($a) to potentially change $a ?
19:34 jnthn Yes
19:35 pmichaud you're saying that doesn't work now?  ;-)
19:35 pmichaud I bet it does.
19:35 jnthn No
19:35 jnthn > class A { method foo($x is rw:) { $x = 42 } }
19:35 jnthn > my $y = A.new; say $y; $y.foo; say $y;
19:35 jnthn A()<0x4375284>
19:35 jnthn Cannot assign to readonly value
19:35 jnthn It doesn't
19:35 jnthn Because when we make a method call
19:35 jnthn We do
19:35 pmichaud ahhhhh
19:35 jnthn yes, that. :-)
19:35 jnthn We did it for hll interop.
19:35 jnthn Because our wrapper PMCs were causing an upset.
19:35 colomon isn't $a.foo the interesting call in question?
19:35 pmichaud well, if you want to get rid of the descalarref on method calls, I don't have an issue with that.  :-)
19:36 jnthn Me either, apart from I probably break IO.pm and some ability to call methods on various Parrot PMCs that leak into Rakudo.
19:36 pmichaud yes, it's likely to cause lots of issues.
19:36 jnthn Not Object in general
19:36 jnthn Well, it did, which is why we had to take this route.
19:36 jnthn :-(
19:37 pmichaud this feels to me like a similar situation to "do not WANT"
19:37 pmichaud er, want()
19:37 jnthn ;-)
19:38 pmichaud i.e., we're hitting upon a fundamental contradiction in what we expect methods to be able to do and what we can do with vivification
19:38 jnthn Oh
19:38 pmichaud but I haven't been able to convince myself of that yet
19:38 jnthn I know.
19:38 * jnthn cackles evily and wonders if to tell or jsut try and commit... :-)
19:38 pmichaud or that it's a language problem and not a we're-writing-this-in-Parrot problem
19:39 * pmichaud readies his +2 wand of reverting
19:39 colomon jnthn: JFDI!
19:39 jnthn dynop that only does it if it's a core PMC other than Object.
19:39 jnthn ;-)
19:39 jnthn (does the unwrap, that is)
19:40 jnthn So we only bother if we've got a Parrot PMC.
19:40 jnthn erm
19:40 jnthn A non-Object one.
19:40 pmichaud that sounds like the test is in the wrong place
19:40 jnthn Our nasty case is the IO PMC, for example.
19:40 jnthn Well, where's the Right Place?
19:40 pmichaud don't know yet
19:40 jnthn I can't say I *like* it
19:40 pmichaud but we want to deal with PMCs from other HLLs, too.
19:40 jnthn But I don't like what we have now either.
19:40 pmichaud not just Parrot Core PMCs
19:41 pmichaud I have to go pick up kid from school... bbiaw
19:41 jnthn OK
19:41 colomon o/
19:41 jnthn o/
19:41 bkeeler \o
19:41 bkeeler Interesting conversation!
19:42 jnthn pmichaud: (for when you're back) The alternative is flip it. If we know it's a Perl 6 object we don't deref it. :-)
19:42 PerlJam So ... who's doing Rakudo #28?
19:42 jnthn And assume it's not otherwise and we get the itner-op
19:42 jnthn bkeeler: Well, I think I understand a bit more how to do auto-viv properly now...
19:42 jnthn :-)
19:42 jnthn Or at least the issues.
19:42 jnthn PerlJam: Good question.
19:42 bkeeler Sounds like it
19:43 jnthn I seem to remember somebody saying they would if nobody else stepped up
19:43 jnthn Oh
19:43 jnthn moritz_++
19:43 jnthn Because he was asking for suggestions of release name.
19:44 jnthn Which, if anybody has one, would be most welcome.
19:44 PerlJam heh,  that would be my sticking point ... what to call it.
19:44 colomon If we've got releasing down to the point where the name is the hard part, we're doing well.  :)
19:44 jnthn ;-)
19:44 jnthn Well, yes, that is something of a win. :-)
19:45 jnthn Aside from stuff already mentioned, does anyone have any concerns/blockers to bring up?
19:45 bkeeler Not here
19:45 bkeeler Other than the usual wondering when I can get some pm time for my patch :)
19:45 colomon the role issues I've bumped into doing the Numeric stuff, as I mentioned last night.
19:46 PerlJam do we have a target set of must-haves for R*?
19:46 jnthn colomon: OK, if you're about, let's work on that one together after #rs?
19:46 colomon jnthn: that would be great.
19:46 jnthn colomon: I'm done with $dayjob things for today. :-)
19:46 colomon I need to do some $work as well, but hopefully I can multitask.
19:46 jnthn PerlJam: ROADMAP's "Really important items"
19:46 mberends PerlJam: http://wiki.github.com/rakudo/rakudo/whats-going-into-rakudo
19:47 jnthn Yes, that page also. :-)
19:47 PerlJam so the roadmap hasn't much changed?
19:47 jnthn No
19:47 jnthn Other than, we did some bits of it. :-)
19:48 PerlJam Is there any indication of "doneness" in the ROADMAP?
19:48 colomon PerlJam: no.
19:48 jnthn Not much
19:48 jnthn I did put some notes in against a couple of things
19:49 jnthn But they've been moved to completed now.
19:49 jnthn By the way, if anybody is up for a straightforward, but useful task, we have:
19:49 jnthn 1 ***   get the Advent examples running again (all)
19:50 jnthn Obviously getting them running could be tricky. ;-)
19:50 jnthn But at the moment afaik we don't know if they run
19:50 PerlJam aye, that's what I was going to tackle :)
19:50 jnthn Collecting the examples together and finding out, or even making them into some kinda test suite, would be awesome.
19:50 jnthn PerlJam++
19:50 jnthn I have no idea how close or far we are on that one.
19:50 jnthn But I'd love to know.
19:51 PerlJam me too
19:51 jnthn \o/
19:51 colomon PerlJam++
19:51 jnthn Talking of stuff we plan to do...some "what's the focus in the next week"
19:51 jnthn I plan to start tackling:
19:52 jnthn 1 **    lexical classes and roles (jnthn)
19:52 jnthn Dealing with the role bug colomon++ is hitting will be a nice lead-in for that I guess. :-)
19:54 jnthn mberends: How's the module installation-y bits coming along? I have vague memories of a blocker?
19:54 pmichaud (back, have a thought about vivify)
19:54 mberends yes, no progress there yet.
19:55 jnthn mberends: Ah, you hit a Rakudo bug.
19:55 mberends sometimes it says: Method 'exists' not found for invocant of class 'Proxy'
19:55 * jnthn remembers now
19:55 jnthn mberends: Ah, ouch.
19:55 pmichaud Proxy should go away when we have WHENCE ;-)
19:56 jnthn That...may be related to...right. ;-)
19:56 jnthn pmichaud: Your thought?
19:56 pmichaud my $a;  $a<b> = 42;
19:56 pmichaud with "my $a;",  $a becomes some sort of ObjectRef to Any
19:57 pmichaud instead of directly pointing at Any
19:57 pmichaud then we can copy over the ObjectRef
19:57 pmichaud i.e., the ObjectRef mutates, not the protoobject
19:57 pmichaud still have to work out some of the details there
19:58 jnthn Does that change anything that much from now though, where we have a Perl6Scalar there?
19:58 pmichaud yes
19:59 pmichaud currently with "my $a", $a is a container PMC that objectrefs the Any protoobject
19:59 pmichaud I'm proposing it become a container PMC that objectrefs an ObjectRef that objectrefs the Any protoobject
19:59 pmichaud and that method invocations are smart enough to not go all the way to the protoobject in this instance
19:59 pmichaud (or that postcircumfix:<{ }> is smart enough.)
20:00 pmichaud as I said, still some details to work out, but it resolves the "make copies of Any" issue
20:00 pmichaud and keeps the value separate from the container
20:00 jnthn I'm struggling to see how that's better than us relying on the "is rw" semantics.
20:00 jnthn And being able to just replace what's in the container.
20:00 pmichaud well, if we can get "is rw" to work, I'd guess we go with that.
20:01 jnthn I'd be more comfortable with that.
20:01 pmichaud me too.
20:01 jnthn And I think I can (and we probably should otherwise it's a bug.)
20:01 pmichaud I just don't know how hard that's going to be.
20:01 jnthn Maybe I should just try and make it work, and if in 30 minutes I have a solution, great, and if after a couple of horus I don't, we consider it hard. :-)
20:02 pmichaud wfm
20:02 jnthn On a related topic, I wondered if you had your plan for binding anywhere?
20:02 jnthn I seem to recall that did involve the copy op and twiddling with references?
20:02 pmichaud no
20:02 pmichaud oh, wait, yes.
20:03 pmichaud essentially,  $a := $b  simply replaces the existing value of $a with an ObjectRef to $b
20:03 pmichaud (and does typechecks)
20:03 pmichaud it's the same thing we normally do in parameter binding, mainly
20:03 jnthn That is, replaces the container PMC with?
20:03 pmichaud no, not the container PMC
20:04 pmichaud at least I think not the container PMC
20:04 pmichaud (thinking)
20:04 pmichaud oh yes, I suppose it could be the container PMC
20:04 jnthn .oO( this is why I was nervous to do this -- pmichaud++ explained it to me once and it seemed correct and very workable, but I forgot the details :/ )
20:04 pmichaud anyway, the container PMC retains its properties
20:05 jnthn nod
20:05 pmichaud and just becomes an ObjectRef to another container PMC
20:05 jnthn I think the copy op does cause that anyway.
20:05 pmichaud (just like with parameter binding)
20:05 jnthn *nod*
20:05 jnthn OK, wfm.
20:06 jnthn OK, any more, or are we done with #rs this week? We've been going an hour now. :-)
20:07 pmichaud sounds like my major task for the week is lists
20:07 bkeeler pmichaud: Did you have time to look at the regex interpolation stuff?
20:07 jnthn pmichaud: Any tuits you have to spend on that would be deeply appreciated.
20:07 pmichaud bkeeler: yes, I did.
20:07 jnthn pmichaud++
20:07 pmichaud bkeeler: it needs a refactoring -- much of what you have in rakudo belongs in the regex engine (in nqp-rx)
20:07 bkeeler Excellent
20:07 pmichaud bkeeler: I'll be happy to walk through it with you sometime (now not good time, unfortunately)
20:08 bkeeler OK.  Any idea when a good time would be?
20:08 pmichaud when are you generally available?
20:08 bkeeler I'm pretty flexible
20:08 pmichaud okay
20:09 bkeeler The only time I can't make is tomorrow morning
20:09 pmichaud the general idea will be to have a PAST::Regex node that understands arbitrary past interpolation
20:09 pmichaud tomorrow morning is bad for me also
20:10 pmichaud tomorrow afternoon is a bit hectic also :-(
20:10 pmichaud so, tomorrow evening, or thursday afternoon
20:10 pmichaud (thursday morning is bad for me also)
20:10 bkeeler Tomorrow evening works for me
20:10 pmichaud okay.  Perhaps around 21:00 utc?  or later?
20:11 pmichaud (what tz are you in?)
20:11 bkeeler Pacific
20:11 pmichaud oh, later would be better than.
20:11 pmichaud (checking schedule)
20:11 colomon pmichaud: While I have a good bit of $work that needs to be dealt with in the next three days, I'd be up for helping out with lists.  To the extent that I can, of course.
20:11 pmichaud colomon: I'm not likely to do much on it before tomorrow evening, and perhaps not until thursday evening
20:12 pmichaud next couple of days are packed with $otherstuff :-|
20:12 colomon understood.
20:13 pmichaud bkeeler:  pick a time after 5pm pdt?
20:13 bkeeler How about 6 PDT?
20:14 pmichaud wfm, it's on my calendar now
20:14 bkeeler Great!
20:14 jnthn \o/
20:15 moritz_ oh dammit, I've missed another meeting
20:15 jnthn moritz_: It's OK, we only gave you LOADS of work.
20:15 bkeeler tsk tsk
20:15 jnthn ;-)
20:15 moritz_ anyway, if somebody could review the 'cool' branch, that would be cool
20:15 jnthn Oh
20:15 jnthn I'd...forgotten we'd not merged that!
20:15 * jnthn remembers working out a fix for it...
20:15 pmichaud has anyone bumped PARROT_REVISION yet for 2.3.0?
20:16 jnthn moritz_: Does it pass all the tests that master does?
20:16 jnthn pmichaud: Not yet
20:16 jnthn I can do that, if nobody else already has?
20:16 pyrimidine not to butt in unceremoniously, but
20:16 pyrimidine takadonet and I have been reimplementing .trans, and the regex var interpolation work would help tremendously there
20:16 moritz_ jnthn: it did when I finished the work on it... right now it probably needs merging from master
20:16 pmichaud pyrimidine: rsn, then :)
20:16 moritz_ with the exception of a few faulty tests
20:17 moritz_ that assume that Str inherits from Any directly
20:17 moritz_ (I'll fix the tests)
20:17 jnthn Ok.
20:17 pyrimidine thx, pmichaud.  no hurries, real life first
20:17 jnthn moritz_: Is it essentially just moving methods into Cool from Any and changing what some things inherit from?
20:17 moritz_ jnthn: yes
20:17 moritz_ no rocket science, really
20:17 jnthn moritz_: OK, then it's probably very easy for me to glance over.
20:18 jnthn If I can remember the git incantation :-)
20:19 moritz_ git diff origin/master origin/cool # modulo noise
20:19 bkeeler Is there a way to get github to do that in its nicely colored diff format?
20:20 moritz_ bkeeler: not sure... but git diff can do color too
20:20 jnthn I'm currently doing a build with 2.3.0
20:20 jnthn If tests go fine will commit the bump.
20:21 jnthn moritz_: Anything else for #rs?
20:21 jnthn Otherwise I think we're about done. :-)
20:21 colomon feels like a productive meeting.
20:21 moritz_ jnthn: haven't backlogged yet...
20:21 jnthn Aye
20:21 moritz_ but probably note
20:22 moritz_ *not
20:22 jnthn OK.
20:22 jnthn Well, thanks everyone. :-)
20:22 jnthn Let's try for same time, same day next week.
20:22 bkeeler Same bat-time, same bat-#channel
20:22 jnthn \o
20:23 bkeeler \o
20:23 bkeeler left #rakudosketch
20:23 mberends o/
20:23 mberends left #rakudosketch
20:53 pmichaud left #rakudosketch

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