weekly Rakudo status meetings with phase transitions: Tue 19:00 UTC | IR clogs at irclog.perlgeek.de/phasers/today
Set by moderator on 8 June 2010.
06:57 masak joined 12:41 ciphertext joined 14:54 bphillips joined 15:04 bphillips left 17:17 mberends joined
pmichaud === Part 1: Report 18:12
- I've been mostly working on a new list and iterator impl
- Thanks to some help and comments from TimToady++, we now have a new model based on immutable iterators
- I wrote a draft document for the design and discussion at docs.google.com/Doc?docid=0AeZqZQ8w...&hl=en
- Since then, I've pretty much been focused on the implementation
- It's going well, down to about 500 failing tests (or less)
- The new implementation seems *much* more robust and correct about laziness, flattening, and memory management, items, and lists
- I've also been able to eliminate a bunch of redundant or convoluted code
- Some highlights: + gather, map, sort, etc. all return true lazy lists, all of type List + Positional is now a true role in the core settings + Many of the issues with postcircumfix:<[ ]> have been resolved + (I still need to update postcircumfix:<{ }>, however.) + Hashes now properly flatten in list context
=== End of Part 1
=== Part 2: Rakudo Star timing 18:16
- We need to make some decisions about Rakudo Star (R*) timing
- First, I'll note that I consider any delays in Rakudo Star release timing
to be entirely my responsibility. AFAICT, everyone else has done
incredible work over the last few months, and the remaining big items
are on my shoulders.
- That said, I'm willing to go along with any consensus opinion about R* release
- Some background:
+ Parrot 2.5.0 was released today
+ There are probably still some additional PAST and nqp-rx features we'd
like to have in place for R* to support closures, fully backtracking
regexes, better character class management in regexes, etc.
+ All of these additional desirable features will likely not be in the
Rakudo compiler in time for a Thursday release.
- So, I see that we're left with some less-than-perfect options:
1. We can make a compiler release on Thursday that is missing some
highly desirable features, and create R* based on that.
2. We can make a compiler release on Thursday, and then create another
"interim" release shortly thereafter that allows us to still make
a June release date for R*.
3. We can choose to release R* based on a compiler/parrot that aren't
official releases. 18:17
4. We can hold the R* release until after the July Parrot and Rakudo
compiler releases, missing the 2Q2010 goal but hopefully delivering
a far superior rollout than we can do in June. (The likely dates
for this option would be July 23 or 24. It could happen at OSCON.)
5. Other options you may dream up.
- I'm not much in favor of #1, and #2 through #4 are about equal to me
at the moment. So, what do you all think?
=== End of Part 2
=== Part 3
- As I review the Rakudo source code and commit logs, I've started to log notes in docs/review-notes.txt in the list branch.
- My intent is that this will be a set of implementation review items that can be briefly discussed during #phasers each week.
- I could use RT for this, but I wanted something quick and lightweight. If something ends up not being quick/lightweight that probably means it deserves a RT ticket (and that's okay).
- The current list is at github.com/rakudo/rakudo/blob/list/...-notes.txt if anyone wants to preview questions and begin formulating responses.
=== End of Part 3
(end of report)
18:18 diakopter joined 18:20 ash__ joined
[particle] re: pmichaud part 2; i am for #2 (release rakudo compiler as scheduled with separate rakudo * release date tbd). this allows a continuation of the existing "thursday following parrot" release cycle for the compiler, and separates r* release cycle from rakudo compiler release cycle from the start. 18:21
pmichaud [particle]: that's not what #2 really means
it's always been intended that R* will have separate release dates from the compiler
the question is whether we should do *another* compiler release just before the release of R* 18:22
[particle] ah, yes, i see, you'll reed another inter-monthly rakudo compiler release
pmichaud correct.
[particle] i still think that's the best solution
moritz_ Pm-5: Can someone point to the specification or explain the logic
behind Parcel.ACCEPTS?
it used to be that empty parcel == Nil, and Nil was undefined
so in order for Nil ~~ Nil to work, that weird construct was used
pmichaud (I know that it's to handle Nil, I'm just not sure this is how it's to be handled.)
moritz_ the spec has changed since 18:23
[particle] the first R* release is exceptional enough to force an upstream off-cycle rakudo release.
moritz_ and it's safe to rewrite to something saner now
pmichaud okay
have the tests been updated?
moritz_ not sure 18:24
pmichaud I had to put that code back in just so I could pass the nil.t tests.
moritz_ they might be very wrong 18:25
will try to review them soonish
mberends my priorities are seldom about the features inside the Rakudo core, because it already contains more than enough for me. I'm more interested in stability, speed, memory efficiency and the distribution we build around the core. Therefore I would prefer options 1 or 2, and focus on maximally enabling application development.
moritz_ oh, one more option...
make a parrot 2.5.1 release with just the additions that Rakudo * needs
pmichaud mberends: the missing features are pretty important in some respects. as in, fundamental.
moritz_: we'd have to convince the Parrot team for that; I'm not sure it's a good precedent. 18:26
(I'm not opposed to it, though.)
[particle] i believe parrot would be happy to make an off-cycle release for r*, but i'm not sure it's necessary
pmichaud [particle]: for some of the key features it may be.
moritz_ aye, they seemd pretty supportive
pmichaud some of our "really ought to have" features will need to be in nqp-rx 18:27
anyway, an interim Parrot release can be option #6
option #7 is to have a "prerelease R*" sometime in June, with the official R* release in July
i.e., the prerelease R* would basically enable us to claim to have met a 2Q2010 goal. 18:28
(and give all of the people who are looking for something in June something to look at)
[particle] i think we need a wiki page for all these options
Tene My preference is #4, or I guess #7
mberends likes #7 too
Tene I'd like #7 if we included information on what specific sort of feedback we're looking for from the community. 18:29
pmichaud #4 might have an advantage that we'd then have R* based on a "supported" Parrot release.
Tene like #7 better, that is.
pmichaud (#7 has this as well)
I can start a public editable google doc
[particle] i don't really like #7, we've been pushing r* as useable perl 6 from the start
it feels like breaking a promise 18:30
pmichaud I agree, releasing prematurely feels like going against "underpromise and overdeliver" to me.
[particle] aye
Tene Well, if we release it as an attempt to get some other parts right first before the main release, it's a bit different. 18:33
Packaging, module inclusion, whatever.
[particle] yes, an integration-test release is acceptable, but not for public consumption 18:34
Tene "Here is the current code, along with all the non-code bits that will be included unless someone tells us otherwise, to get feedback on the non-code bits"
[particle] certainly not something to market
pmichaud docs.google.com/Doc?docid=0AeZqZQ8w...&hl=en # editable summary 18:35
TimToady I think there's little shame in missing by only a month
[particle] rakudo protostar :)
pmichaud rakudo star cloud. :-)
moritz_ I'm against 7 18:36
it will be *so* hard to market right
pmichaud TimToady: Aye, I've been thinking that as well. Missing by one month, given circumstances, isn't really all that bad.
TimToady we can always blame you :)
pmichaud You can, indeed.
moritz_ I have just one request
pmichaud (and I'm happy to accept/shoulder blame.)
moritz_ if we delay rakudo * by a once, make a definitive date *now*
so that we don't have to handwave "well, not June, by July" 18:37
TimToady well, there are are still externalish deps
pmichaud one note about July is that I'll be on family vacation July 9-16.
[particle] again, underpromise
pmichaud I do expect to have good connectivity (and some time) during that time, and I'd ->hope<- that we have the bulk of things in place before the 9th.
s/hope/expect/ 18:38
yes, the summer calendar has not been our friend. June releases are too early in the month, and July releases are too late (i.e., we miss the opportunity to release at something like OSCON)
PerlJam concurs with moritz fwiw 18:39
pmichaud if we wanted an OSCON-timed release, we could release the July compiler on the 20th or 21st
and then R* on the 22nd or 23rd
(i.e., push the rakudo compiler release up a day or two) 18:40
I think I'd prefer to not have the compiler release and the R* release on the same day.
to emphasize their difference.
I'm fine with us declaring a definitive date.
[particle] agreed
and you don't really want to set a precedent that R* and rakudo releases will continue to be same-day 18:41
Tene If we want to underpromise, we could promise august.
[particle] s/precedent/expectation/
Tene Then we still have the option open to release at oscon
pmichaud I'd really like to not extend into August, for many reasons :)
Tene And we'd be overdelivering. 18:42
pmichaud We could promise a date later in July, then release early, yes.
PerlJam When's oscon?
pmichaud Jul 19-23
Parrot 2.6.0 releases on Jul 20
Rakudo 2010.07 would normally occur on Jul 22
PerlJam bummer
pmichaud Jul 23 is a little late to make an OSCON splash -- things are usually shutting down by the last day 18:43
PerlJam: yeah, the calendar really works against us in June+July of this year. April would've been awesome. :)
PerlJam I say release them on the same day.
Tene There's also the option of making a slightly early release of Parrot
PerlJam just this once.
pmichaud I'm _really_ reluctant to do that. 18:44
yes, it would be just this once, but unfortunately it ends up being the expectation setter.
If we were to pick a July date (and go with underpromise/overdeliver) I'd say July 29. 18:45
PerlJam Then set the date for the next release too.
(obviously not on a rakudo release day)
pmichaud I'd rather release the compiler a day or two early than release on the same day.
and the compiler release notes do say that we can release a bit early :-)
there's very little that's magic about the 2-day requirement, it's an approximation. 18:46
PerlJam so ... are people going to talk about the R* release at oscon?
It's not going to have the same impact in future tense.
pmichaud I think people will talk, yes (more)
PerlJam and you lose some advertisement ability
(I think)
pmichaud here's my current leaning (but I'd prefer to wait to commit until other #phasers have a chance to comment 18:47
I think we announce July 29
TimToady otoh, we're still aiming for early adopters here, so a slow buildup isn't so bad
pmichaud then, if by July 9 we think we're comfortable with an earlier release, we plan for compiler release on the 20th, and R* on the 22nd.
if by July 9 we're not comfortable, we stick with the 29th and don't try to make a big deal of it 18:48
PerlJam TimToady: heh ... slow buildup ... we're talking about days when Perl 6 has been "building up" for years :)
pmichaud yeah, I don't want to make too big a splash
Tene I like that plan.
[particle] pmichaud: where are the nqp-rx proposed/expected changes kept? i don't see them in review-notes.txt
pmichaud [particle]: they're not there -- review notes is more about code that already exists than about to-do items. 18:49
the main thing needed in nqp-rx is backtracking subrules and better character class support in regexes
it will take me a day or so to get both of those ready
(I've already sketched out both, just need time for impl and testing) 18:50
PerlJam pmichaud: I like that plan. It has the option of surprise.
Tene I seem to be getting less burned-out recently, so I might be able to do some work soon.
pmichaud there's a lot to commend that plan, yes. It does mean I go into YAPC::NA w/o R*, but I can live with that.
(since it's not likely to happen by Monday anyway)
PerlJam pmichaud: but that's your opportunity to announce Jul 29 18:51
[particle] have folks started developing a release document for r*?
PerlJam [particle]: see github.com/rakudo/star/blob/master/README :-) 18:52
[particle] well, there's broad initial support from parrot folks for the possibility of an off-cycle release for r*
18:52 masak joined
pmichaud [particle]: that's useful. 18:53
Tene I *do* like the idea of getting together the packaging, presentation, assorted other bits together ahead of time, and that would be something nice to show to people at YAPC::NA. As well, it would be nice to get any issues with those parts ironed out before announcing.
[particle] i'll bring it up in parrotsketch, or make sure someone else does if i can't attend
Tene: that's what i'm thinking... the proto r* release can be made available to folks at yapc::na 18:54
that's like a friends&family release of r*
PerlJam [particle]: but one they put together themselves?
[particle] no, it requires work from the rakudo team to start working on a distro 18:55
the directions don't need to be perfect, and neither does the distro
pmichaud maybe working on R* packaging would be a good thing to do at yapc::na :-)
s/at/during/
[particle] there will be a room available all week at the con for p6 and parrot hacking
pmichaud i.e., have some focused hackathon sessions or bof sessions to discuss it and put together the plan and flesh out the repo
[particle] pmichaud: agreed, that'd be great 18:56
pmichaud currently I'll only be there Mon-Thu.
(I'm returning to DFW thursday night, so will be there Thu day)
[particle] 'twould be nice to have a leg up by having some basic outline for new folks to start working from 18:57
i'm there mon-wed
7p flight wednesday
Tene I really need to look into trying to attend yapc::na. 18:58
19:00 takadonet joined
masak right. 19:00
so now we start, yes?
moritz_ hi 19:01
sorear wow, I actually made a #phasers for once. Hi!
PerlJam greets sorear
moritz_ masak: want to report wrt your gsoc project?
sorear postpones backlogging to attend
masak sure.
as usual, weekly reports can be found on my blog.
use.perl.org/~masak/journal 19:02
but since you're here... :)
last week was dominated by porting of the existing Str.encode/Buf.decode code to Parrot's brand new ByteBuffer.
I expected to do more, but got distracted by $real-life, and a fun weekend hackathon. 19:03
still doing well with the grant schedule, though.
no real blockages.
.eor 19:04
moritz_ great
so 19:05
has everbody read pmichaud's report in the backlog?
masak halfway through it :)
done. :) 19:06
moritz_ so 19:07
afaict, we need to discuss these things today
1) date of June release (wait for the list merge, or not?)
2) Rakudo * release date (options 1...7) 19:08
3) pmichaud's review list
anything else I've missed?
pmichaud see also my google doc 19:09
PerlJam What's the likelyhood of list merge happening tomorrow?
pmichaud "by tomorrow?" Very high likelihood.
19:09 colomon joined
colomon bluederm 19:09
moritz_ hi colomon 19:10
colomon o/
sorry I'm late, dentist appt
moritz_ there's a mighty backlog in here already (pmichaud++ pre-pasted)
colomon backlogging.
PerlJam Then I'm for holding the R* release until the list merge. (even if it won't be held up)
[particle] any way to ||ize the rest of the list merge? iirc it's <500 failing tests 19:11
moritz_ [particle]: my attempts to fix some of them clearly showed that it wasn't efficient; spending my time in other Perl 6 corners seemd much more productive 19:12
[particle] noted. 19:13
moritz_ so
R* release
we have currently 7 options
maybe we just start by each of us listing the options we like 19:14
pmichaud I can delegate parts of the list merge
(for efficiency)
19:10 <PerlJam> Then I'm for holding the R* release until the list merge. (even if it won't be held up)
moritz_ is OK with 2, 4, 6. 4 preferred
pmichaud (that doesn't really make sense)
PerlJam pmichaud: just ignore the parenthetical :) 19:15
masak moritz_: I see 1..5 being numbered in the backlog. don't see 6 and 7.
moritz_ masak: they came later; see here for a sumamry: docs.google.com/Doc?docid=0AeZqZQ8...&hl=en
pmichaud docs.google.com/Doc?docid=0AeZqZQ8w...&hl=en
PerlJam pmichaud: the point is that I think the list merge is something significant that the release can be pegged to. (IMHO) 19:16
pmichaud PerlJam: right. But not R* :-)
PerlJam oh!
right. I had R* on the brain for a second 19:17
wrt the R* release I'm for #4 with the schedule that Pm mentioned earlier (Jul 29, but if all goes well we decide on Jul 9 to move the Rakudo release up to Jul 20 and the R* release to Jul 22) 19:18
masak I find I'm not of a strong opinion as to the options. I do seem to be gravitating to either 2 or 4, though. 6 if needed. I do not like 1 or 7
colomon I'm also against 1 and 7 19:20
masak backlogging -- I see I'm not first in disliking 7. good.
colomon At this point, I'm against 2. Much as I'd like to see it happen, there's just too much more that should go in there for a decent release. 19:21
PerlJam yeah, #7 is the "steal the thunder and turn it into a wimper" option if you ask me :)
colomon 4 or 6 work for me.
masak I see 6 as mostly orthogonal to the rest of the list, and by-need. 19:22
[particle] there must be a better way to vote on these
moritz_ do we actually need a vote?
pmichaud I'm looking for consensus opinion :-)
masak seems we're almost decided on the right one :)
moritz_ is anybody in strong dislike of 4 (July release of R*)?
[particle] these are overlapping options 19:23
like, 2 could depend on 6
pmichaud sure, these aren't non-overlapping. each one just gets at a central point. 19:24
[particle] anyway, i think july r* release is the way to go, as discussed previously.
pmichaud notes jnthn is absent. :-|
anyone massively opposed to July R* ? 19:25
[particle] standard parrot release cycle, standard rakudo release cycle, R* release at or before july 29
moritz_ nobody spoke up when I asked the same question :-)
pmichaud moritz_: right, I'm repeating the question just to make sure people see it :)
colomon I do think we should set a hard date for it now. (OR at least before an announcement.)
PerlJam colomon: before YAPC!
pmichaud if we say July R*, I declare July 29.
[particle] colomon: ^^
moritz_ pmichaud++ 19:26
colomon +1
mberends +1
pmichaud if things look particularly healthy in early July, we may try moving a week sooner. If not, no biggie.
[particle] if requested, parrot will make an off-cycle release in support of R*
pmichaud parrot won't need to.
[particle] keep it in your back pocket
pmichaud (but it's very nice to know that ... right) 19:27
since parrot is leading up to supported release anyway, I don't expect significant shifts from parrot -- mainly minor improvements (all of which help R*)
okay, let's go with July 29. I give jnthn++ the option of a strong veto, however, if he's in significant disagreement. 19:28
(since he's not here at the moment)
moritz_ ok
pmichaud I _will_ write up a blog post explaining the new date. 19:29
jnthn oh hai
Tene HAI!
takadonet !
TimToady pick a number
jnthn sorry sorry sorry...I screwed up the timezone.
pmichaud ah, just in time to throw MONKEY_WRENCH exception into the works!
jnthn away from home 19:30
er, I guess I better backlog :-)
diakopter see you in 15
pmichaud jnthn: we'll see you in about 30
(long backlog :)
moritz_ shall we temporarily move to the review notes then? 19:31
pmichaud wfm
moritz_ docs/review-notes.txt in list branch
pmichaud I'll lead.
masak github.com/rakudo/rakudo/blob/list/...-notes.txt 19:32
pmichaud For #1, I think it can be broken into 1 or more RT tickets. I'd like someone else to pick that up.
(I'll break into tickets)
(someone else investigate and fix or report back)
moritz_ +1 to PIR-based testing 19:33
pmichaud For #2, I was surprised that &reducewith and the like are public in the setting. I think we either need a way to make them public in the spec or we need to privatize them somehow.
jnthn pmichaud: At least negate is mentioned in the spec.
colomon I feel strongly that hyper (or something very much like it) ought to be in the spec.
pmichaud so is &reduce, itself.
note that hyper is a keyword.
jnthn I changed the name of it after it showed up in the spec alongside the description.
pmichaud well, not a keyword, but it's a built-in. 19:34
colomon pmichaud: I have no objections whatsoever to renaming it. :)
moritz_ would like to put them into a namespace
colomon (The helper sub, I mean.)
jnthn The others don't appear in the spec, but my (maybe mistaken) impression from TimToady++ was that there should be keyword versions of them too.
pmichaud sure, I'm for that also if we can do it.
moritz_ so that people *can* use the helper subs if they want
jnthn However, that doesn't mean the names as they stand now are good.
moritz_ and spec them to be there
jnthn On a related issue, I'd be interested in us designating a namespace where we should put guts-y things. 19:35
TimToady infix hyper helpers might be named dwim-strict or some such
if dwimmery isn't just parameterized
jnthn TimToady: We've got those as named parameters at the moment.
moritz_ so that they can also be overridden if needed, but aren't accidentally overridden when somebody declares an 'only sub reduce { }' and wonders why [+] breaks
pmichaud designated namespace for guts-y things: Rakudo
or Perl6::Rakudo 19:36
or Rakudo::Compiler
or ALLCAPS::SOMETHING
colomon reduce is spec, reducewith is the [+] helper
pmichaud can't the [+] helper use reduce?
i.e., should reduce (spec) be made more like the helper?
moritz_ it needs to deal with associativity
and chainging op
the normal reduce can't do that 19:37
colomon and triangle
moritz_ right
pmichaud can't or simply doesn't?
colomon normal reduce could be extended, I suppose.
jnthn Well, if we're fine with giving normal a bunch of extra adverbs... :-)
TimToady there does seem to be trend that all the helpers are "with"
Tene jnthn: *sufficiently* gutsy things should go in the _perl6 HLL namespace, according to some speculation in the past.
colomon TimToady: I think that just happened... but maybe jnthn or moritz_ schemed it out? 19:38
moritz_ colomon: I think somebody picked up 'zipwidth' from haskell, or so
PerlJam TimToady: reverseargs, sequentialargs? Are those helpers?
pmichaud I'm fine with a "with" suffix, although there's also a pattern with nextwith and callwith and the like iirc
TimToady well, crosswith and zipwith were certainly intentional....
colomon good point. 19:39
pmichaud at this point is there a consensus that it makes sense for helpers like these to be in the setting?
if yes, I can note that and it's just up to spec and language folks to work out the details :-) 19:40
[particle] GUTS::Rakudo
colomon my gut feeling is they should be spec.
TimToady I'd like all the meta-ops to really just be sugar for HOP
pmichaud or, perhaps they belong in a HELPERS:: namespace, if part of spec and not just the compiler :-)
okay, TimToady's last comment tells me they belong.
naming to be worked out over time. :) 19:41
colomon \\o/
TimToady maybe there's something better than "with"
colomon yeah, they certainly could use some cleaning up. :)
pmichaud Pm-3: I was wondering about the dual-specification for Junction.new; sometimes :any, :all, :none adverbs, sometimes :type(...) 19:42
is that just for convenience of various pieces of code?
moritz_ it semes the constructor supports both, right?
jnthn pmichaud: convenience.
pmichaud currently, yes.
jnthn /laziness
pmichaud: I think :all, :any are a nicer interface
But it's a pain when creating a junction when you already have a variable holding the type. 19:43
masak seems like redundance with little gain.
I'd go with just :type.
jnthn I don't care
Just spec something and clean it up.
Currently nothing is spec'd. :-)
So I did what was convenient. 19:44
(for the implementor ;-))
pmichaud convenient can be +1 at times, yes :)
okay, that answers my question. I know how to respond in the file then.
jnthn Anyway, there's no strong reason.
:type is easier
:all/:any etc are nicer because they catch typos better.
Well, or could
pmichaud (basically, we probably should clarify spec and then clean up, doesn't have to happen immediately)
could use an enum.
jnthn EBOOTSTRAPPINGHATE 19:45
But yeah, we could.
pmichaud Pm-4: My mind went loopy when thinking about Cool again -- I was surprised that "Iterable is Cool"
jnthn Heh, we can provide an enum and then just accept Any as Int in the signature. :-)
Thus neatly side-stepping the bootstrapping fun 19:46
OTOH, we currently can't write enums in the setting because the enum setup code is, er, in the setting.
moritz_ pmichaud: that was mostly because iterators leaked out in so many corners
jnthn Maybe we need a three-stage compiler. <duck>
pmichaud jnthn: oh, it wouldn't surprise me if we eventually get there. :)
jnthn :-) 19:47
It may ease some pains at some point.
moritz_ pmichaud: if they appear only in "weird" circumstances in the new model, they don't need to be Cool
jnthn I'm not in a hurry though. :-)
pmichaud moritz_: okay. I was just unsure if there was a known strong reason for Iterable to be ~~ Cool.
I guess if we expect @a.sin to do something it makes sense, though. 19:48
moritz_ pmichaud: every user-exposed, built-in types are Cool, unless there's a strong reason for them not to be
pmichaud I'll buy that.
moritz_ Cool is the new Cool! 19:49
pmichaud that's an excellent summary line for Cool, thanks.
(couldn't remember it.)
last one -- Pm-5
based on earlier comments from moritz++, it looks like Parcel.ACCEPTS may be based on an earlier spec
the main question is in dealing with ~~ Nil
but it would also be responsible for handling the case of ~~ (3,4) 19:50
is it possible that Parcel.ACCEPTS is really the same as List.ACCEPTS ?
moritz_ might very well be
TimToady well, if Parcel is simply an immutable List... 19:51
pmichaud currently I don't have Parcel as an immutable List
it really wants to be slightly different, I think -- a bit more fundamental.
TimToady immutable in the sense that it's a list of syntactic args that are known at compile time 19:52
moritz_ so (1, foo(), 3) is not a Parcel?
or do you have a strange idea of "known"? :-) 19:53
TimToady but ~~ () could probably be List.ACCEPTS
pmichaud that's a Parcel, definitely.
TimToady and it has 3 args
pmichaud currently we have self.Seq.Accepts
i.e., the parcel flattens and then does Accepts
but if the $topic has zero elements, we do something special with it 19:54
TimToady what would ~~ (1, (2, 3), 4) accept?
Nil is just ()
pmichaud I don't know. In general there doesn't seem to be a bright line deciding when a Parcel flattens versus when it keeps its elements unflattened
(with respect to certain method calls) 19:55
TimToady parcels only flatten when bound flat
pmichaud earlier we had the case of
TimToady or when forced by .flat
pmichaud (<1 2>, 3).join(',')
TimToady I suspect join implies a .flat 19:56
pmichaud right
so, some methods imply flat, others don't
TimToady but I'm not sure if .ACCEPTS is one of those
pmichaud right, thus my comment about no bright deciding lne :)
*line
we also have the case of (1, @a, 4) 19:57
er
~ (1, @a, 4)
arggggh
~~ (1, @a, 4)
TimToady is there a use case for matching nested parcels?
and is it a good enough case to break expectations of flattening
19:58 takadonet left
pmichaud I can't think of one at the moment. Or if someone did need to do that, it can be done with $(...) or (...).item 19:58
or even .slice
TimToady agreed, and I lean toward .flat semantics by default for .ACCEPTS
pmichaud okay.
TimToady I think it's what most naive users will expect
pmichaud and then for the case of 19:59
TimToady and perhaps :() can do elsewise
pmichaud sub foo() { return; }; my $x = foo(); if $x ~~ Nil { ... }
does Parcel (Nil) need to do something special to handle that?
jnthn TimToady: :() ? 20:00
TimToady sig matching
jnthn $foo ~~ :() coerces $foo to a Capture and it'd better have no positionals or nameds. :-) 20:01
TimToady pmichaud: taking your example backwards
$x ~~ Nil coerces $x to .list or some such 20:02
and I don't think Any ~~ ()
or Mu
my $x = () is supposed to init $x to Any
so I think ~~ Nil really only be have exactly like ~~ ()
no magic
pmichaud wfm
is there a way to test for a "void return", then? 20:03
TimToady only be's have :)
sure, put it in a list context
pmichaud my $x = foo().list
okay.
wfm. 20:04
TimToady my @x = foo(); if @a ~~ () works fine
pmichaud That's all the questions I have for this week. I'll update the .txt file and add more as I find them.
TimToady or more likely just if @a
pmichaud or even if @x :-)
TimToady another one that works fine: my $x := foo(); if $x ~~ () 20:05
masak surely `if @x ~~ ()` would be equivalent to `if !@x`, not `if @x` ?
pmichaud thanks all for the quick answers. there's nothing that says the questions I put in the review document have to wait for #phasers -- I just wanted a place where I could do some interactive query/response on a schedule.
TimToady masak: I just said that
oh, right 20:06
pmichaud masak++
TimToady
.oO(stupid n't key) :P
moritz_ so
TimToady I just saidn't that!
masak TimToady: :P
moritz_ anything else we need to discuss in scope of this week's #phasers meeting?
jnthn I the whole backlog. 20:07
pmichaud jnthn: have you been able to review the backlog yet? any comments?
jnthn comments:
On pm's initial statement - I was always fine with and actually expecting us to generally pick revisions for distribution releases on a "whatever works" basis, and that we'd keep compiler releases on a separate, unrelated, monthly schedule. We should be enforcing that compiler monthlies and distribution releases are different things. OTOH, using a non-released Parrot would be wrong.
#7 is "no way".
Would prefer not to have the Parrot folks have to deliver an off-schedule release, especially since the July date was already given.
I think that making a crappy release that's not quite there and with a bunch of weaknesses would give a worst lasting impression that another month of delay. 20:08
*worse
*than
So I say we take the month or so extra to pollish what we have.
pmichaud wfm 20:09
TimToady blames the Intelligent(?) Designer
pmichaud from a personal perspective, I basically lost 12 weeks of development time
jnthn Finish the major missing ROADMAP items, focus on the things likely to annoy newcomers, and start *soon* making our distribution.
(As in, getting it into shape.)
pmichaud a june release date means we pushed back the planned release only 8 weeks 20:10
while it would be nice, it's proving to be about 2 weeks shorter than I needed :)
jnthn Yes, I agree.
pmichaud so while I wasn't expecting this outcome, it seems more and more like july release is the way to go
[particle] @pmichaud <== $dr-pepper 20:11
TimToady well, there could still be unforeseen interactions in the new feature set, so you may get your two weeks back...
pmichaud okay, unless others object in the next day or so, that's the plan
jnthn +1
pmichaud as I mentioned earlier, I will write something up about this during this week 20:12
(i.e., pre yapc-na)
jnthn pmichaud: Please do blog about it. I'm comfortable you'll do it well, but it'd be good to have a good solid post out about it sooner rather than later.
OK, great.
pmichaud I agree, we want to stay ahead of the discussion :)
masak +1 to pmichaud blogging about it.
pmichaud that's all of the #phasers I had for today
jnthn pmichaud: Yes, that's the point I was trying to make. 20:13
moritz_ nice
masak thanks! y'all rock!
20:25 masak left 20:31 mberends left 20:33 eternaleye joined 23:04 eternaleye 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!