Friday April 10, 2009
Perl 6 Design Minutes for 01 April 2009
The Perl 6 design team met by phone on 01 APril 2009. Allison, Patrick, Will, and Nicholas attended.
- "I knew you were going to pick on me first..."
- I worked on improving Perl 5 regular expression support in PGE, which enabled the
:p5 modifier for regular expressions in Rakudo, which got us about 400-500 more passing tests. It's a cheap way of getting passing tests.
- There are about 600 left, 1200 in total.
- Also been answering questions online.
- Today, working on improving Unicode handling in PGE and Rakudo.
- The basic assumption is that ICU is available, and that we're doing the conversion there.
- This will get another huge chunk of tests passing, that are waiting on that.
- I started the PGE refactors, to catch up with Synopsis 5.
- Ready for next set, which will bring in things such as protoregexps.
- Nothing Perl 6ish.
- Trying to help clean up docs in Parrot.
- Realised today that I was doing it the wrong way, doing it manually, when we have a perfectly good tool to do it.
- There's a macport for Parrot 1.0, which I can't take credit for, but it's out there.
- I realize now that I need a devel version of it.
- Hopefully with that I can get back onto partcl.
- Feel free to add the dev tools.
- It's easier to update an existing package.
- Linux loves you to subdivide into lots of little packages. I don't think that other OSes go that far.
- The trick will be to keep it as 1.0 but marked as updated.
- Parrot 1.0 packages are now in Debian, in unstable. Very nice.
- Working on other packaging stuff, such as the the rpath problem.
- There are a few more little pieces that I'd like to see done before
submitting updated packages to Debian, such as
target=parse for the HLL compiler.
- Note that that's getting a major refactor.
- We can't get that into an updated 1.0 release.
- The patches for
Data::Dumper from Barney, I'll see if I can get them in.
- Pycon was very productive.
- Python was really really welcoming to the alternate implementation.
- Lots of little things on Pynie. Ramping up to getting started.
- Getting familiar with the implementation.
- Larry's been found; he's at MIT, giving his talk in about 5 minutes'
time. They've pasted a live URL on #perl6, plus video should be available afterwards.
- My question relates to what was said on #parrotsketch.
- Does Parrot need ICU?
- Question is, "does it need a deprecation cycle?"
- In one sense, it's adding something, so no.
- But it's removal of working without a package.
- Is it a 2.0 thing?
- We should put in a notice for 1.5.
- Rakudo could say "if you want to run the spec tests, you need ICU".
- How do we stop false reports from people who don't have ICU?
- In your configure process, check Parrot config, see if ICU is installed.
- If not, disable those tests. If you want to, don't even compile without it.
- Disabling the tests is really tough, because they're spread thought the suite.
- Then make it a requirement for Rakudo and check very early.
- It would be nice if there was an option to Parrot's Configure to say "Require ICU", else the only time we find out is after we've built Parrot.
--with-icu but that's to specify where to find ICU, not to mandate its use.
- For your process, because you already have the automated the pull down the parrot packages, can you add "pull down ICU"?
- For ICU that's not trivial.
- Right now ICU is not required for Linux, because Parrot wouldn't build with ICU present on Linux a month ago (on AMD 64). Right now it's disabled. Once we get that resolved, the packaging will require ICU.
- Having dependencies via the packaging system is really easy.
- That still causes issues for people who are running Rakudo from other-than-prepackaged Parrot, which is the vast majority [of Rakudo users] for the foreseeable future.
- Adding dependencies [to Parrot] will move people to a packaged Parrot, as pain level of compiling [from source] becomes higher.
- Agree, but not workable for Rakudo for 6 months.
- Okay, so we don't make it a requirement for 6 months.
- That's okay for parrot, but where does Rakudo go? The options become "You have to live with the latest packaged parrot, which means you have to live without features X Y Z", or you have to build Parrot, and only then can it tell you that you don't have ICU.
- Just have to configure, and then check that.
- Right now, we just configure and make. Changing to "configure, check results, make" -- yes we can do that.
- Have an option "I really don't want ICU", go ahead anyway.
- With appropriate warnings of "you will get some test failures"
- Expect ICU support to be good, or mandatory as of 1.5?
- Not mandatory until 2.0. But 1.5 is when it's okay to start breaking things if ICU is not installed.
- I wasn't planning to break stuff.
- That's how I think about deprecations.
- Right now, you only get a problem if you try to do something that absolutely has to have ICU, at which point we throw an exception.
- That works okay for PGE and PCT, but for Rakudo, we have thousands of tests.
- Because Perl 6 was designed for Unicode.
- But also Pugs folks went overboard. I think in some cases they automated generating tests by raiding the Unicode database.
- One checkin I'm working on today should get us another 1800.
- We could get 10,000 this month.
- I look at the graph of spec tests and our green is less than half of the total test suite. I want to fix that.