NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Friday January 23, 2009
Perl 6 Design Minutes for 14 January 2009
The Perl 6 design team met by phone on 14 January 2009. Larry, Allison, Patrick, Will, Jerry, Jesse, Richard, and Nicholas attended.
- spent the week working on pumpking stuff again
- merged in several branches that I and others had been working on
- did a lot of patch review
- planning on doing the migration to parrot.org today
- I'd said today because we had three days where we could figure it out; what works, and what doesn't, and delay it if necessary
- been doing spec work, and answering questions
- things are hectic at work right now, so I don't have a lot of time for my true vocation
- keeping my nose above water on the mailing lists and IRC channels
- removed the old
.contains method, that was standing in for the .exists modifier on hash lookups in a hash.
- mostly answering questions and hoping that someone else will clarify the specs for me, when I answer questions about functions and pod.
- trying to use my spec writing time for clarifying things that other people can't do themselves
- I have trips planned in April
- worked on getting the branch merged in that refactored variable handling in Rakudo
- got it done on Friday. It worked out well.
- ... though not for people who were relying on misfeatures of Rakudo
- I've been helping people by pointing out ways to fix it
- it's a stronger basis from which to continue
- passing 60 more tests than this time last week. 6233 now passing.
- we lost 30 when we merged the branch, but gained 90 back, so a net plus for the week
- I've closed a bunch of tickets, or put a note on that we can close when we have a test
- done over over 2 dozen. Still more that could be closed like that.
- it just takes time to find them. It feels good closing tickets that way.
- I've also been helping others
- I was going to read PGE refactors, but now figuring out what to do with
Rakudo repository is a higher priority
- it doesn't matter if Rakudo's repository moves, just that it's not in the same repository as Parrot.
- I'd rather not move it and then move it straight back.
- there have also been some discussions about moving Rakudo to git
- I don't want to go to the community and say "Oh, this week it's here" and then the next week "Oh this week's it here", and have the documentation on where to get Rakudo be constantly out of date
- let's get you cc'd on the list discussion with the admins
- we will now be figuring out a Rakudo plan for this so that we can notify the Rakudo community about the changes coming up
- I have one task assigned for Parrot this week -- rip out all the deprecated items. There are about half a dozen left; a depressing number.
- trying to get volunteers to look through and remove what is just a hack and slash
- I had dropped out of the calls about mid way last year because I didn't feel that I had anything to contribute
- before I dropped out around June 2008, we did a huge amount of TPF work on how it would improve things until I had things to say
- then I backed off, at least partly because in July 2008 my wife had a baby
- in the past month or so, I'm coming back on the radar
- we have a 5.10.1 release grant going on right now
- Dave working on it, Nick the grant manager
- I watch him commit things. I don't know more more detail than that, as I've not communicated with him recently.
- even an revised expected release date would be good
- when I was talking with him setting it up it was "late Jan, early Feb"
- would be good to know if there is updated information
- Also Hague grants. A lot of good things are happening about that.
- I took a trip last month to New York to see Ian, to say thanks, and give him an update. It was an excellent meeting. He is happy with the progress going on, feels respected as a donor, and is happy with the amount and level of communication.
- I'm looking into the legal details of splitting apart what is Parrot and Rakudo. Drawing up the assignment agreement with Roberta (the TPF lawyer)
- TPF got a nice donation from booking.com ($50,000) booking.com asked TPF to be vocal. Tell the world.
- they did not put a specific requirement on the donation. They said "we hope to support Perl 5.10 with this", but not the level of surety on it that I had with Ian on his donation.
- I'm sure that some 5.10 support will come out of that, but after that we have a general donation to work with. Could well be part of the grants through the grants committee. There is a growing desire for funding there. Even a couple of quarters there would not exhaust it, so we will figure out other good ideas for what to do with it.
- as mentioned last week, it's time for me to step back as project manager type person. Do we want a replacement project manager, or is it more a community organiser type person?
- all I did was write code last week, so I didn't have time to think
- I think we're okay without a project manager
- as long as everyone is okay with that, I'm happy not to foist someone else upon you
- I will update the world on my blog next week. It's likely to get flameage just because it contains the term "Perl 6".
- "Oh no! Perl 6 is dead. It doesn't have a project manager!"
- I wonder if I can get to Reddit number one on that
- maybe "The Perl 6 implementation efforts are so strong right now they're basically self managing to good effect."
- I might pop by the call in the future to see how you are
- it would feel much better if you went out with a major rant
- it should be "career limiting"
- rant that the implementations are doing so well without your input
- and "I'm just not useful any more"
- and rant how you've tried to kill it but it's [just too strong to die]
- I've enjoyed this. It's been fun and interesting, and I hope it's been helpful. At times it's been maddening, but that's true of any project.
- thanks for everything that you have done
- thank you for actually making it happen
Missing a discussion on
.trim and gilding the lily.
- if I wanted PHP I know where to find it
- wasn't aware that
.trim is not a Perl 5 built in
- PHP has 3000+ functions, so we have a way to go yet
- seeking to strike the right balance
- my question for the day "To what extent do unary hyperoperators descend into containers?" I think that they do, to some degree.
- also the exact definition of what
- been doing a lot of thinking on that
- that's a good question to be thinking about, from a Rakudo implementor's position
- that's why I might appear to be ignoring mailing lists
- you won't get the exact the same object back
- but a representation that compiles to the same sub?
- I think it would be good if we could
- but at some point a lot of businesses are going to say "Oh, you just made it very easy to reverse engineer my sacred code".
- I don't think we can guarantee it, but whether it's strongly encouraged, but turn offable, or similar
- at least the types of code that are idempotent, or otherwise stateless such that they can be easily reconstituted
- in some ways we already have to be able to do that to save the state of the current language, as we have to save the current grammar and all the methods on it, to do prelude snapshots, or do an eval, without having to rebuild all from scratch
- I don't know where the balance point on that is
- sounds good. Aiming at the point I'm thinking of.
- need to think about it
- do what's reasonable. not do doing something that will set the whole project back a whole year
- I mailed the list about pairs. Didn't spot a reply.
- if I iterate over a list of pairs, are the values of those pairs...?
- those are references back to the original
- likewise pairs coming out of a hash should be references
- by "References" you meant the values, as the keys are immutable?
- Tcl question
- for Parrot, I was going to have an attribute to save the high level source. It was going to return the text of the sub and let the user recompile it
- this is sane?
- I had that as a fallback, but wasn't what I really wanted to do
- it's a good degenerate solution as a minimal solution that can serve as a backstop
- but that would mean that my PBC files would have the entire source code in them
- hence my question about
.perl and subs was "Do we have to do that?"
- there's another language out there that needs to do that
- we could share infrastructure
- you run into the Deparse problem
- what you see is after the optimiser got at the code
- it might be what you want, but it's not the original source
- is it possible that the spec could say that? The default is a sane default?
- you're forgetting that one of the Perl 6 mottoes is that it exists to torture implementation on behalf of the users
- not so much that it never happens
- who defines that? I might have quit back in 2004.
- with a rant preferably. :-)
- I've finished most of the technical details of S19. It needs a re-write. It doesn't read well.
- as far as a working copy goes (from my perspective, as the implementor) it's in a good place
- there may be some ambiguities, but I've moved onto the implementation
- next deliverable is a set of spec tests
- to implement them properly I'm building a test harness, so I'm coding before I can write the tests
- eager parsing, eager meaning
.*?, as opposed to greedy, which would be
- no one likes the terminology "eager"
- pulled it from S19
- didn't want to define something as non-greedy
- found "eager" in S5.
- especially as in the rest of the language "eager" means "greedy"
- that was the term Mastering Regular Expressions uses
- lazy would be bad also
- yes, it's called Lazy
- probably okay. Eager : Lazy :: Greedy : Parsimonious.
- that is how the rest of the language treats lists. "Eager" vs "Lazy".
- in the context of regular expressions, we'd call that
? qualifier lazy
- the association doesn't immediately come to me
- it can be implemented with lazy lists. That's how Cursor.pm works.
- will take a stab at changing POD
- I'm going to be in S5, so I could
- if Jeff Friedl uses that term too, that's good
- noticed that Larry weighed in on some issue relating to preludes that I'd mentioned in S19, so it looks like that part has been approved
- well, I suggested it in the first place.
- I don't know if it makes *sense*. :-)
- maybe an alternate prelude doesn't make sense
- I don't think of preludes as actually preludes -- instead they're the surrounding lexical scope
- really we're waiting on the implementation so that we can see how it works in practice
- I'm thinking of the same way an eval works
- the outer language is serving as a prelude for that eval
- it's the same thing, except that the current language can be frozen into the file, and then you're effectively starting up again from there
- it's layers, all the way down
- the core compiler does an eval of the prelude, which brings a bunch of things into scope, which then does an eval of your code
- it's more the parse of the eval. We use this to implement
- it's not eval in the sense of recompiling each time through the loop.
- it's that eval does a sub-parse. That's what needs to be generalised
- Make good use of the ability to wrap compilations in one or more outer contexts. Whether we call it, prelude, or outer-lude
- what's the opposite of an interlude?
- environment variables also
- I considered a switch which let you set an environment variable
- this would let you do it on the same line for shells that don't provide such behavior
- same as adding it in the prelude
- except that environment variables are scoped dynamically
- another question about environment variables, which are essentially global
- can a dynamic scope override them?
- how easily within perl 6 code, just for that dynamic scope
- we speculated about connections between contextual variables and environment variables, or the globals
- I was under the impression that something was decided, and then changed
- we can give that appearance :-)
- thank you everyone for the last few years. Enjoy your call next week.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.