Perl 6 - the future is here, just unevenly distributed

IRC log for #phasers, 2010-06-15

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

All times shown according to UTC.

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

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