Call For Pumpking: Do you want a Ponie?
Two and a half years ago, Fotango announced their sponsorship of the Perl 6 effort, in the form of the "Ponie" project to port the Perl 5 runtime to the Parrot Virtual Machine. For the past year, Nicholas Clark has worked as the pumpking for Ponie as part of his work for Fotango. He's recently moved on from Fotango and it's time for Ponie to do so as well. We're currently interviewing for a new pumpking to take over his role. The Ponie pumpking needs to manage the route we take to get the Ponie source code from where it is now to its eventual goal: a Perl 5 runtime fully integrated with the Parrot virtual machine. You won't start from nothing. Nick and Artur Bergman before him have developed a plan to get us to the glorious future and have made a significant dent in that plan, but there's still a huge amount to do. You'll need to be able to work with the existing plan and expand and revise it as necessary, based on feedback and discoveries made while working through the current tasks. Ponie is an open source project. While you'll likely be doing a lot of the heavy lifting, you also need to be able to nurture the community and implementation. Contributors will be submitting patches. You'll need to work with them to refine their patches and recruit some of them as core committers. This is primarily a C hacking role rather than a Perl hacking role. (That is, you'll be coding Perl, not coding /in/ Perl.) You absolutely need a good working knowledge of C and would be well-served to have some experience managing large projects written in C. And yes, an intimate knowledge of Perl's internals would definitely come in handy. There's one thing about Ponie that might really appeal to you if you have a pretty good handle on Perl 5's internals. Ponie is the perfect opportunity to clean up and refactor the guts you hate most. It's a huge refactoring project and you'll have more than a little freedom to make things faster, cleaner, saner, more maintainable and generally _better_. If you're interested in being the next Ponie pumpking, please submit a brief bio to [EMAIL PROTECTED] We won't consider applications posted publicly. Over the coming weeks, Nicholas Clark and I will work to pick his successor. Nick and I look forward to hearing from you. Jesse --
Re: "Don't tell me what I can't do!"
On Wed, Oct 04, 2006 at 12:50:16AM -0700, chromatic wrote: > On Tuesday 03 October 2006 10:06, Aaron Sherman wrote: > > > Would there be such tools used in the core libraries? Maybe, maybe not, > > we could discuss that. If they were implemented in the core libraries > > would there be a universal "no bondage" flag that shut them off? > > Probably, since that's something that Perl tends to like doing. > > The assumption I remember from the design meetings was always "No library > designer has the knowledge or the right to tell me how fast or strict my > program has to run." Whatever B&D you do in the privacy of your own modules > is fine, but if it leaks out past encapsulation boundaries, expect that > somewhere you might offend community standards. > That's really a pity. I'd very much like the rope to be able to build 'strict::with::pride' like toolsto say nothing of being able to build my own private 'taint'. One of the things that many shops have defected from Perl to Java for is the additional handcuffs that Java provides for less-than-experienced developers. Giving me the power to control what my team, or folks using my language variant, do could be a huge win. But hey, if you don't want to use those libraries, that's cool. -j
Re: "Don't tell me what I can't do!"
On Wed, Oct 04, 2006 at 12:01:22PM -0700, chromatic wrote: > On Wednesday 04 October 2006 01:05, jesse wrote: > > > One of the things that many shops have defected from Perl to Java for > > is the additional handcuffs that Java provides for less-than-experienced > > developers. Giving me the power to control what my team, or folks using > > my language variant, do could be a huge win. > > The point is that the person writing the program decides which handcuffs or > costumes all of the code has to wear, not the person writing the libraries. > If you want to set a policy for your organization, that's fine. It is just > Not Okay for me or anyone to write a module right now that dictates exactly > the strictness of every program written in the next twenty years that uses > it. So, you're in favor of Perl 6 not having a "use strict;"? Or are you in favor of there being only one true strict? Perhaps I'm misunderstanding what you mean by "person writing the program" and "person writing the libraries." In fact, I've _gotta_ be. I'd like to be able to put my strictures in a library rather than forcing them into the main body of a program. Are you saying you don't want to let people do this? Jesse > -- c > --
Re: "Don't tell me what I can't do!"
On Wed, Oct 04, 2006 at 12:43:04PM -0700, chromatic wrote: > On Wednesday 04 October 2006 12:09, jesse wrote: > > > Perhaps I'm misunderstanding what you mean by "person writing the > > program" and "person writing the libraries." In fact, I've _gotta_ > > be. I'd like to be able to put my strictures in a library rather than > > forcing them into the main body of a program. Are you saying > > you don't want to let people do this? > > Let me rephrase. Libraries and modules can be as strict or as lax as they > like, but the program *using* those libraries and modules should always be > able to override those strictures. If you write a class in a library and > declare it as closed, that's fine -- but any program that uses the class > should always have the option of saying "Nope, not closed. I need to do > something with it." > > It's the person *using* the libraries and modules and classes who knows how > strict they need to be, how closed they need to be, and how optimized they > need to be. If any of those policies are irreversible--if they leak out of > libraries and modules and classes--then there is a problem. Ok. So, I think what you're saying is that it's not a matter of "don't let people write libraries that add strictures to code that uses those modules" but a matter of "perl should always give you enough rope to turn off any stricture imposed on you by external code." Do I have that right? > > -- c > --
Re: "Don't tell me what I can't do!"
On Wed, Oct 04, 2006 at 01:04:45PM -0700, chromatic wrote: > On Wednesday 04 October 2006 12:48, jesse wrote: > > > Ok. So, I think what you're saying is that it's not a matter of "don't let > > people write libraries that add strictures to code that uses those modules" > > but a matter of "perl should always give you enough rope to turn off any > > stricture imposed on you by external code." > > > > Do I have that right? > > Yes. You might also add "... or enable further strictures", but that sounds > like what I was trying to say. Ah. Then I'm in violent agreement. Excellent. > -- c > --
Re: pluralization idea that keeps bugging me
On Sat, Jan 26, 2008 at 02:36:32PM -0800, chromatic wrote: > > Nearly pain-free l10n and i18n *is* kind of a killer feature though. +1 > -- c > --
Re: pluralization idea that keeps bugging me
On Sat, Jan 26, 2008 at 08:58:43AM -0800, Larry Wall wrote: > Last night I got a message entitled: "yum: 1 Updates Available". > Of course, that's probably just a Python programmer giving up on doing > the right thing, but we see this sort of bletcherousness all the time. > > Any other cute ideas? > It's worth reading the perldoc for Locale::Maketext and Locale::Maketext::TPJ13. Sean Burke did some truly excellent work explain a lot of the pitfalls here. Sean built us the only solution I've yet seen that gets pluralization reasonably ok in languages with non-English-like pluralization rules without making me want to just give up and write "Updates found: 1" ;) -j
Re: [PATCH] Add .trim method
On Mon, Jan 12, 2009 at 07:01:25AM -0800, Ovid wrote: > > > > I could optionally make the following work: > > > > > > > > $string.trim(:leading<0>); > > > > $string.trim(:trailing<0>); > > Alternatively, those could be ltrim() and rtrim(). 'left' and 'right' are probably not the right names for functions which trim leading and/or trailing space, since their meanings get somewhat ambiguous if a language renders right-to-left instead of left-to-right or vice-versa -jesse
Re: Commentary on S22 (CPAN [DRAFT])
On Fri, May 29, 2009 at 11:04:38PM +0200, Daniel Carrera wrote: > Hello, > > I finished reading S22 (CPAN [DRAFT]). This synopsis is about the > package format, not about the network. I have some comments: > > 1) Instead of calling the format "JIB", how about "PAR"? It can stand > for Perl ARchive or the recursive PAR ARchive. This is more memorable. It might make sense to adopt the same naming as .jar and .epub, two very different zipfile-as-container formats. Both use a top-level directory called "META-INF". There's no particular technical reason to pick a given name, so going for something that looks familiar to people may be a win. -jesse
Re: Rukudo-Star => Rakudo-lite?
Perhaps we could name the incomplete releases "Rakudo Bikeshed". Each release could be named after a popular color of bikeshed. The first one should definitely be called "Rakudo White Bikeshed". -j
Re: Y not
On Feb 20, 2007, at 3:42 PM, Larry Wall wrote: I think the ¥ and Y operators are going to have to change to something else. The current Y has at least four strikes against it: * It's an ASCII version of a cute Unicode picture, but other than that, the picture it doesn't remind you of "zip" at all, especially in the Y form. I bet calling it "ykk" would be Wrong. Pity. -jesse PGP.sig Description: This is a digitally signed message part
Perl 6 Microgrants. Now accepting proposals.
I'm pleased to announce the inaugural Perl 6 Microgrants program. Best Practical Solutions (my company) has donated USD5,000 to The Perl Foundation to help support Perl 6 Development. Leon Brocard, representing The Perl Foundation's grants committee, will work with me to select proposals and evaluate project success. We'll be making USD500 grants to worthy Perl 6 related efforts. We're hoping to fund a range of Perl 6-related projects over the life of the grant program. Accepted grants might be for coding, documentation, testing or even writing articles about Perl 6. The program isn't tied to any one implementation of Perl 6 -- We're interested in seeing proposals related to Pugs, Perl 6 on Parrot, Perl 6 on Perl 5 or any other Perl 6 implementation. Generally, we're interested in seeing projects that can be completed in 4-6 calendar weeks. Submitting a grant proposal --- To submit a grant proposal, please email us at perl6- [EMAIL PROTECTED] with the following information: * A two to three paragraph summary of the work you intend to do * A quick bio - Who are you? Is there opensource work you've done that we should have a look at? * A brief description of what "success" will mean for your project - How will we know you're done? * Where (if anywhere) you've discussed your project in the past * Where you'll be blogging about your progress. (Twice-weekly blog posts are a requirement for getting your grant money) We'll be accepting proposals on a rolling schedule. We expect to pay out these first 10 grants over the course of the summer. Depending on how things go, we'll then either find more money for more grant programs or we'll wind up the program and move on to other endeavors. We're really excited to get rolling. Submit your proposals early and often. Don't let somebody else beat you to the punch ;) Best, Jesse PGP.sig Description: This is a digitally signed message part
Re: Perl 6 & Parrot Essentials as project documentation
On Jun 18, 2007, at 8:13 PM, Moritz Lenz wrote: Allison Randal wrote: I just signed an agreement with O'Reilly that assigns the full copyright in the book "Perl 6 and Parrot Essentials" to The Perl Foundation. The text is out-of-date, but can be updated much more rapidly than it can be rewritten from scratch. Sounds great. Does TPF have a license for it already? Allison and I discussed this today. TPF are releasing it under Artistic 2. Where do you want the text for the Perl 6 parts of the book? Maybe: <http://svn.perl.org/perl6/doc/trunk/books/p6tut> If you want many potential committers, use the pugs tree. I think the number of committers of svn.perl.org/perl6/doc is very low. I'd suggest something beneath <http://svn.pugscode.org/pugs/docs/>, perhaps essentials/ We discussed this too. I'll be branching it into pugs/docs/ tonight. (I need to write a README with license and source and copyright info) Best, Jesse P6PM Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ PGP.sig Description: This is a digitally signed message part
Re: Perl 6 & Parrot Essentials as project documentation
I'm pleased to announce that the Perl 6 parts of /Perl 6 and Parrot Essentials/ are now available at http://svn.pugscode.org/pugs/docs/tutorial/ [1] for your hacking pleasure. Thanks to Allison for navigating the sometimes murky waters of copyright assignment and licensing to get this documentation opened. I hope it will be a great base for Perl 6 hackers and documenters to build upon. If you're interested in hacking the docs and can shoot me mail within the next 24 hours, I'll sort you out a pugs commit bit. After that, ask around on #perl6 on irc.freenode.net and someone should be able to set you up. Best, Jesse [1] A "pristine" copy of the content of the book is also available in the "official" Perl Foundation SVN repository at http://svn.perl.org/perl6/doc/trunk/ books/tutorial/ PGP.sig Description: This is a digitally signed message part
Jonathan Worthington receives Perl 6 Microgrant
We're pleased to announce that we've selected Jonathan Worthington as a recipient of a Perl 6 microgrant. Jonathan is one of the top contributors to Rakudo Perl 6 and has been contributing to Parrot since 2003. The grant will be for travel and accommodation to the French Perl Workshop and the Nordic Perl Workshop. Jonathan will speak at both workshops on topics including the Rakudo Perl 6 implementation, Perl and Perl 6 as languages for academic use and the Perl 6 type system. Please join us in wishing him the best of luck with his project. We're really looking forward to seeing the details of his talks.If you're interested in submitting a Perl 6 microgrant proposal, you can find details here: http://www.nntp.perl.org/group/perl.perl5.porters/2007/03/msg122448.html Leon and Jesse PGP.sig Description: This is a digitally signed message part
Re: [RFC] CPAN6 requirements analysis
> I support the notion of distributing binaries because nobody's gonna > want to chew up their phone's battery doing unnecessary compiles. The > ecology of computing devices is different from ten years ago. And, in fact, binary distribution is something that's been done on CPAN for quite a while. A quick poke at the backpan finds things like http://backpan.perl.org/authors/id/G/GS/GSAR/DB_File-1.54-bin-x86-mswin32-bc.zip dating from over a decade a year ago. The motivations for binary distribution have changed, but the need has been there all along. The only thing I'd worry about here is making one of the big mistakes that the Java community made -- Making binary-only distribution an acceptable alternative to source distribution. Nothing should end up on the CPAN unless it's there in source form. Making binary distribution easy is a laudable goal, but it's something the existing infrastructure already supports. I'd love to see "CPAN autobuilders" which build perl modules for a givven platform and architecture and make them generally available. That'd be a lot cleaner than the current ad-hoc system which requires authors to jump through hoops. But really, that's just another CPAN-related service that could easily layer on the existing infrastructure. Best, Jesse pgpwO3tBWEibH.pgp Description: PGP signature
