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

Powered by Cro and the Raku® Programming Language.

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

Thank you!