Working Group Summaries online
http://dev.perl.org/summary/ Each established list/working group has a spot on this page. Weekly/Bi-weekly summaries will be posted as they arrive. Currently, only the two summaries from last week (Aug 31) are online. Earlier summaries will be posted as I find them in the archives (or as they are forwarded to me :-). Please cc perl6-librarian on future working group summaries. Comments welcome. Z.
Re: code repository
On Thu, Sep 07, 2000 at 05:31:37PM -0400, Bennett Todd wrote: 2000-09-07-17:11:50 Dan Sugalski: That's certainly possible, but since the reason we're gathered here together working on trying to launch perl6 is a collective belief that perl5 has become unmaintainable for further development, [...] and the reasons for that lack of maintainability are *entirely* due to the codebase, *NOT* tools used to maintain that codebase. [...] given how many branches are active, perforce seems to be a win. Given that it's only available to people who happen to run supported platforms, OK. That pegged the fud-o-meter. The list of supported platforms listed on http://www.perforce.com/perforce/loadprog.html is hovering around fifty, including boutique architectures for Linux, NetBSD and FreeBSD, as well as three versions of VMS, two architectures of BeOS, Amiga OS, four versions of Solaris/SunOS, [...] So, to summarize: 1) Perl6 development will be *open* to anyone able to diff, patch and send/receive those patches. 2) A very small number of developers will have write-access to the master Perl6 repository. This is comparable to most other open source projects using BitKeeper, CVS or Perforce. 3) Those developers prefer Perforce and should not be forced to use CVS because non-committers prefer it. 4) Perforce clients are *freely available* and *supported* on a wide range of platforms. No, it's not open source, and that is regrettable. 5) The use of Perforce is a pragmatic choice. If the requested features *were* available with CVS, then CVS would be used instead of Perforce. 6) An anon CVS interface to the Perl6 source tree should be made available for public consumption, synchronization, etc. How this is implemented is left as an exercise for those with the tuits. [*] Is there anything more to be said about Perforce vs. CVS that *isn't* FUD? Z. *: Sarathy tells me that Perforce sucks at maintaining thousands of anonymous checkouts, while CVS doesn't mind at all. This is a perfect reason to use anon CVS vs. Perforce, but does not require that Perforce be ditched in favor of CVS, only that an anon CVS gateway be maintained.
Re: The Future - grim.
On Sun, Sep 10, 2000 at 09:58:14PM +0100, Alan Burlison wrote: I don't believe in magic. I'm an engineer by profession, not an astrologer. However, I will predict endless arguments when some of the less than coherent proposals are rejected. The RFC process was intended to bring out both good and bad suggestions. On the positive side, there's interest in currying. On the negative side, we have some half baked proposals, some of which frequently appear on p5p every year or so. At least with an RFC archive, those fruitless flame wars can be stopped quickly by citing a relevant rejected RFC than they are today by saying "go look in the mailing list archives." [...] I suggest you do the blindingly obvious - look at the current p5p'ers, figure out who has contributed in each area of interest and ask those folks to form a team to work on the same area in p6. If new people want to contribute, fine, but they should be integrated into an existing team rather than be sent off to 'do their own thing'. A possible suggestion is an apprenticeship approach - ask potential contributers to take on a substantial but not critical-path part of the work, get them to complete it and then have it reviewed by the other members of the team (you are going to code reviews - right?) If everyone is happy then they can be invited in. From this, I can extract these action items: 1) Set up p6 development like other open source projects, where there is a "core team" responsible for the progress of Perl6 or a component of Perl6. These people have write access to the source repository (whatever it may be). 2) Set up an explicit path for sometimes contributors to submit patches, new code, new docs and new tests. 3) Set up an explicit path for apprenticeship. This should lead to membership in the core team for trusted apprentices who have proven themselves as being capable and reliable. Code/doc reviews are one metric for proving oneself to the core team. 4) Set up closed mailing lists for the core team to post onto, that are made available through read-only open subscription to the community at large. These lists should have a policy established to accept worthwhile postings from non-core members (simple forwarding works; moderation works). What we're doing about that: * pushing the output through Larry [Yes, this addresses only part of the problem. Any suggestions for other ways to solve this?] The RFC mountain is way, way too high to be climbed by just one person, let alone the output of the various mailing lists. What about a litlle good old-fashioned dictatorship, or at least a Junta? All of the RFCs have mailing lists associated with them, and all of the mailing lists have chairpeople leading discussion. Why not ask these chairpeople to start a Last Call process, whereby any unmaintained RFCs can be marked as "unmaintained and withdrawn" by the relevant WGC. That should cull out a bunch that haven't been updated since being posted one month ago. Especially the dubious ones. It would have been nicer to institute this policy from the start, but no one expected to get 200 RFCs in just over one month, either. Z.
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
On Fri, Sep 15, 2000 at 04:11:27PM -0600, Nathan Torkington wrote: Mark-Jason Dominus writes: I think it would be a step in the right direction if the WG chairs actually required RFC authors to maintain their RFCs. In preparation for the end-run of RFCing, how about we compile a list of "developing" RFCs that haven't been touched in more than a week, and contact the authors to say "last chance, please finish up your RFC now." Such a program would be easy to write (praise be to Date::Parse) and would hopefully prod authors into incorporating feedback and closing out their RFCs. Good idea? [time passes] I didn't use Date::Parse, but I did look for all RFCs still stting at v1 status. Since they're numbered chronologically, I cut off the bottom (anything submitted after 9/7). There are 100 RFCs in the list that follows. Code and data upon request. Z. - RFC : 3 v1; [Developing] Title: messages.rfc - An RFC to discussing the wisdom of allowing run time error and warning messages to be modified at run time Maint: Corwin Brust [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 1 Aug 2000 RFC : 7 v1; [Developing] Title: Higher resolution time values Maint: Gisle Aas [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 2000-08-02 RFC : 9 v1.0; [Developing] Title: Highlander Variable Types Maint: Andy Wardley [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 01 Aug 2000 RFC : 11 v1; [Developing] Title: Examples encoded with =also for|begin|end POD commands Maint: Barrie Slaymaker [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 02 Aug 2000 RFC : 12 v1; [Developing] Title: variable usage warnings Maint: Steve Fink [EMAIL PROTECTED] for now List : [EMAIL PROTECTED] Date : 2 Aug 2000 RFC : 13 v1; [Developing] Title: Creation of Copyright and Licensing Working Group Maint: SBradley M. Kuhn Elt[EMAIL PROTECTED]gt List : [EMAIL PROTECTED] Date : 2 Aug 2000 RFC : 15 v1; [Developing] Title: Stronger typing through tie. Maint: Michael Fowler [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 02 August 2000 RFC : 16 v1; [Developing] Title: Keep default Perl free of constraints such as warnings and strict. Maint: Daniel Chetlin [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 3 Aug 2000 RFC : 18 v1; [Developing] Title: Immediate subroutines Maint: Jean-Louis Leroy List : [EMAIL PROTECTED] Date : 04 Aug 2000 RFC : 19 v1; [Developing] Title: Rename the Clocal operator Maint: J. David Blackstone [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 4 Aug 2000 RFC : 20 v1; [Developing] Title: Overloadable and || Maint: Jean-Louis Leroy List : [EMAIL PROTECTED] Date : 04 Aug 2000 RFC : 21 v1.00; [Developing] Title: Replace Cwantarray with a generic Cwant function Maint: Damian Conway [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 4 August 2000 RFC : 22 v1.00; [Developing] Title: Builtin switch statement Maint: Damian Conway [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 4 August 2000 RFC : 24 v1.00; [Developing] Title: Semi-finite (lazy) lists Maint: Damian Conway [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 4 August 2000 RFC : 25 v1.00; [Developing] Title: Multiway comparisons Maint: Damian Conway [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 4 August 2000 RFC : 27 v1; [Developing] Title: Coroutines for Perl Maint: Tom Scola [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 04 Aug 2000 RFC : 28 v1 ; [Developing] Title: Perl should stay Perl. Maint: Simon Cozens [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : Aug 4 2000 RFC : 31 v1.00; [Developing] Title: Co-routines Maint: Damian Conway [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 4 August 2000 RFC : 32 v1; [Developing] Title: A method of allowing foreign objects in perl Maint: Dan Sugalski [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : August 02, 2000 RFC : 35 v1; [Developing] Title: A proposed internal base format for perl variables Maint: Dan Sugalski [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : August 04, 2000 RFC : 36 v1; [Developing] Title: Structured Internal Representation of Filenames Maint: Jarkko Hietaniemi [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 04 Aug 2000 RFC : 40 v1; [Developing] Title: Module Scope Control Maint: Bryan C. Warnock [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 5 Aug 2000 RFC : 43 v1; [Developing] Title: Integrate BigInts (and BigRats) Support Tightly With The Basic Scalars Maint: Jarkko Hietaniemi [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 05 Aug 2000 RFC : 44 v1; [Developing] Title: Bring Documentation Closer To Whatever It Documents Maint: Jarkko Hietaniemi [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 05 Aug 2000 RFC : 46 v1; [Developing] Title: Use features of portable, free compilers and libraries Maint: John Tobey [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 5 Aug 2000 RFC : 47 v1; [Developing] Title: Universal Asynchronous I/O Maint: Uri Guttman [EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 05 Aug 2000
Re: *REALLY*, it's getting close here...
On Thu, Sep 28, 2000 at 07:56:49PM -0700, Daniel Chetlin wrote: On Fri, Sep 29, 2000 at 12:56:44AM +0100, Simon Cozens wrote: Why isn't there a documentation w/g? Yes, this is a hint. My RFC 240 garnered exactly 0 responses, so there doesn't seem to be much of an interest. I was trying to decide today whether I should freeze or withdraw. I agree that there should be a documentation w/g, but I personally believe it is premature to set up such a group, since there is no perl6 to document. Z.
Improving Perl6 RFCs (was: ...)
On Wed, Oct 04, 2000 at 11:00:55PM +0100, Simon Cozens wrote: On Wed, Oct 04, 2000 at 03:42:57PM -0500, Jarkko Hietaniemi wrote: Too many RFCs live in a vacuum by not not explaining in enough detail what is the problem they are trying to solve, but instead go ahead and pull new/backward-incompatible syntax and/or keywords and/or semantics out of thin air. This skirts, but does not *quite* touch on, the *REAL* failure of the RFC process. The real failure, as I see it, is this: We can only tell whether an RFC is officially good or officially stoopid when Larry casts his vote on it. And that only happens once all the RFCs have been completed. *This* RFC process was about brainstorming, and about totally rethinking what Perl can be. It was designed to get the bizarre ideas out there (like currying and lazy evaluation) to see how we could best extend Perl. The *next* RFC process (assuming there is one for the development of p6) will need to strongly discourage wild brainstorming and strongly encourage Real Work (tm), including real proposals on how to solve hard problems, which will find their way into implementation. It sounds like your request is to add a CFV mechanism to RFCs, once there are teams working on the various aspects of Perl6. Suggestions? (Hint: think about core teams.) This makes it nearly impossible to build ideas on top of previous RFCs, since you don't know if you're building on rock or sand; Assume the 362 RFCs in the repository don't exist. Assume that the few that are being accepted are part of a new RFC effort. And assume that those are solid, or are easily made solid. To be more specific: Perl isn't something you can separate out into discrete blocks; two proposals are very, very infrequently independent. There are going to be people focusing on QA, and others focusing on regexes. Discussing why one QA proposal has merit is orthogonal to its use on writing test cases for regexes. Once that QA proposal is accepted, it intertwines itself into regex test cases. Z.
Re: Now and then
On Wed, Oct 11, 2000 at 09:41:30AM -0600, Nathan Torkington wrote: Then again, remember the hassles we had with the perl6-* lists? Nobody knew how to deal with topics that overlapped lists. You had to know all the groups to decide which it was appropriate for. Are these big enough hassles to suggest that perhaps the perl5-porters All In One list wasn't such a bad idea after all? Perhaps. Even though there was a lot of traffic, much of it was easy to follow because a significant proportion of it was consistently titled - RFC ## (v#): Add XYZ into Perl. That traffic is also easy to find in the archives. That will probably be less of an issue with a strong lack of RFC activity during the implementation phase. It very well could be that anyone doing serious work is going to subscribe to perl6-all, and the perl6-* lists exist for those who just want to listen. Z.
On Working groups, WGC, etc.
The FreeBSD Core team has just finished electing their next core team. Only "significant" contributors to the project were allowed to vote, and those elected hold office for a fixed term (two years). The Core Team of nine members determine the project's goals and directions. Many open source projects seem to work in a similar manner. Announcement of the election: http://daily.daemonnews.org/view_story.php3?story_id=1263 [Old] Core Team description: http://www.freebsd.org/handbook/staff.html Contributors (e.g. Cast of Thousands): http://www.freebsd.org/handbook/staff-committers.html List of responsible parties: http://www.freebsd.org/handbook/staff-who.html Z.
Re: how the FreeBSD project gets its core members
On Fri, Oct 13, 2000 at 05:00:10PM -0500, Jarkko Hietaniemi wrote: On Fri, Oct 13, 2000 at 04:35:42PM -0500, Jarkko Hietaniemi wrote: http://www.bsdtoday.com/2000/October/News306.html Oops, sorry about that, didn't read Ziggy's message first... No worries. These BSD guys are onto something. Here's another report from daemonnews, talking about the election process in more detail. Apparently, FreeBSD was getting stagnant, and this election is a way for them to get new blood and more community involvement in the project. http://www.daemonnews.org/200010/dadvocate.html Z.
Re: how the FreeBSD project gets its core members
On Sat, Oct 14, 2000 at 10:33:57PM -0700, Stephen Zander wrote: One question: how does an individual become a committer in the first place? This question becomes of upmost significance to folks like David Grove :) Submitting patches that are accepted into the tree are a huge part of it. Here's a page from the website: http://www.freebsd.org/tutorials/committers-guide/article.html and the relevant section: http://www.freebsd.org/tutorials/committers-guide/conventions.html That page doesn't discuss the process of going from user-with-patches to committer-with-mentor. Z.
Re: I18N of Perl 6 (was: how the FreeBSD project gets its core members)
On Mon, Oct 16, 2000 at 12:05:14AM +0100, Simon Cozens wrote: On Sun, Oct 15, 2000 at 04:59:50PM -0400, Jorg Ziefle wrote: Detailed information should follow soon. Should I write an RFC to discuss about, though I would come a bit late? :( RFC 313 not good enough for you? :) I think that's a pre-requisite for Jorg's idea. Even when (er, if) RFC 313 is accepted, someone's got to maintain the localized strings. That's mostly the issue Jorg had brought up. While it's still useful to translate perl*.pod today, it's important that we design/build Perl6 to be localized from Day 1. Z.
Re: how the FreeBSD project gets its core members
On Mon, Oct 16, 2000 at 10:37:27PM -0700, Nathan Wiger wrote: - The core team appeared to be doing too much, meddling in affairs which didn't concern them. http://www.freebsd.org/FAQ/misc.html#AEN4823 Q: Why should I care what color the bikeshed is? A: The really, really short answer is that you shouldn't. [ annecdote about everyone arguing about the bikeshed, but no one arguing about the nuclear power plant next door. The bikeshed is easily understood, meaningless, and the source of endless arguing. The power plant is huge, complicated and confusing, so no one comments about it. ] :-) Z.
Re: The new api groups
On Tue, Nov 14, 2000 at 12:58:25PM -0500, Dan Sugalski wrote: (Though I don't think we really need more than a few weeks to get a good set of working RFCs for this, though of course they'll get amended and expanded as work proceeds) I'd like to see a revised set of RFC guidelines specifically for the api groups. The Brainstorming process that we encouraged in August/September isn't going to be as useful for talking about possible directions for internals. Internals RFCs should be about getting the plan for the internals mapped out, not revisiting the same tired discussions on vtbls, threaded bytecode or femtosecond opcode dispatchers. Specifically, I'd like to see stricter acceptance/rejection criteria for RFCs inclusion in the library. Z.
Re: Guidelines for internals proposals and documentation
On Wed, Nov 15, 2000 at 04:42:58PM +, Nicholas Clark wrote: On Wed, Nov 15, 2000 at 11:35:56AM -0500, Adam Turoff wrote: All PDDs (like RFCs) need to start with 'Status: Developing' by default. Since statuses like 'Standard', 'Rejected', etc. have Real Meaning (tm), there should be some review in place (by a WGC, principal, etc.). Statuses like 'Withdrawn' and 'Superceded' should be accepted from PDD authors/teams. They don't need to start with "Developing" if they start with status "Experimental" or "Proposed" The real issue is that there needs to be at least one default status that the author can assign. With RFCs, Developing referred to the RFC, and with PDDs, they refer to the underlying design/interface/implementation. I think I misread Dan's re-interpretation of 'Developing'. This is a community process. I'm uncomfortable leaving such decisions to such a small number of people. How about nominating/electing a If PDDs start as "Proposed" without needing any approval does this remove the problem of a small group having a stranglehold? No, because Dan has proposed a 'core team' of sorts, where any one of the (at least) three team members cast a final vote (towards 'standard' or 'rejected'). Keep in mind that this isn't "Dan's Perl API" (or Nat's, or Larry's), but "Our Perl API". I'd be more comfortable if at least two people (from a group of 4) were involved in making any decision that carries weight, or if there were a process of rotating the WGC as necessary to avoid Pumpking Burnout (tm). Z.
Re: Guidelines for internals proposals and documentation
On Wed, Nov 15, 2000 at 04:20:58PM -0500, Dan Sugalski wrote: I want perl 6's internal API to have the same sort of artistic integrity that the language has. That's not, unfortunately, possible with everyone having equal say. I'd like it to be otherwise, but that's just not possible with people involved. There are many people who have good taste and experience where the Perl API is concerned. Forcing those people to come to a majority vote on every PDD isn't going to fly. The answer isn't to reduce that set of people to one person; Larry doesn't scale exponentially. The point is definitely *not* to do any sort of consolidation of power. Anyone reasonably sane, capable, and interested is welcome to chair any of the internals design lists and/or be responsible for shepherding a PDD to solidity. That's fine with me. (In fact I'd be thrilled if the design was handled by a host of folks that weren't me) There are only a small number of people who can bless/unbless a PDD into a standard or forcibly withdraw it from consideration. It's good that there's a small number (1) is involved, but it's bad that each of those people can singlehandedly bless/unbless something. From p5p, we saw that if 2 or 3 people objected to a proposal/idea/patch, it was probably flawed in some way. OTOH, if 3 or 4 of those same people saw merit in a proposal/idea/patch, then it was probably worthy of consideration[*]. This is one of the ways where p5p worked well (and where the RFC process failed). We should formalize this for the Perl6 API process. The first order of business should be to determine the process by which PDDs become accepted/rejected/mentored/etc. Next, we find the people with good taste and spare tuits to accept/reject/mentor proposals through the process. Z. *: This is the audience-participation variant of "throw it at the pumpking and see if he accepts it."
Re: State of PDD 0
On Tue, Feb 20, 2001 at 05:42:01PM -0500, Dan Sugalski wrote: At 02:38 PM 2/20/2001 -0800, Ask Bjoern Hansen wrote: How should the submission process work? As for the RFC's? Sounds good to me. Any additional constraints on acceptance criteria? PDD 0 describes an acceptable baseline on rejection (return incomplete submissions), but I daresay that we want something more strict. For example, I doubt that we want or need three competing PDDs on Async I/O developing in the Standard track, but multiple PDDs on the same topic would be welcome if they were Experimental (or even Informational). Would any other constraints help to promote discussion moving forward? The goal isn't to be burdensome on people actually volunteering their time, but to cut down on the crosstalk that doesn't lead to Real Work(tm). Z.
Re: State of PDD 0
On Wed, Feb 21, 2001 at 07:44:51PM +, David Mitchell wrote: Also, if we go down the 'have a competition to see who can write the best PDD on subject X' path, can we replace the 'TBD' in unnumbered PDDs with a short string chosen by the author? This allows us to (hopefully) unqiuely refer to a document during disussions, but when a final winner is chosen and given a number, the offical library can still pretend the losers never existed, unless people look in the 'losers' section. EG PDD-dapm-GC rather than PDD-TDB for my attempt at garbage collection or whatever. There are advantages with using simple enumeration for RFCs/PDDs. (I'll beat that dead horse only upon request.) The disadvantage of switching to a more descriptive naming scheme is that any identification attached to a PDD upon receipt must be final; a PDD cannot be renumbered/renamed once it has been accepted into the archives. To do so would make it more difficult to search the archives for discussion about an idea -- searching on PDD-std-vtbl won't find the threads that lead to that standard, when it was called PDD-sugalski-vtbl. Perhaps a more descriptive prefix/suffix notation on PDDs would improve upon the anonymous nature of RFCs/PDDs, so long as a core name is assigned to a document never changes. Z.
Not revisiting the RFC process (was: RFC 362...)
On Mon, Feb 19, 2001 at 07:20:33PM -0800, Edward Peschko wrote: As much as I'd like to respond to some of these points, I'll refrain from it now, I'll let my RFCs speak for themselves. Ed, The RFC process that we started this summer is formally and intentionally closed. Your post, regardless of it's formatting, naming or intent, will not be accepted into the RFC archive. =head1 TITLE The RFC project should be ongoing and more adaptive. First, Dan Sugalski has accurately summarized the nature of the process, describing the current state of 'pause' we find ourselves in. http:[EMAIL PROTECTED]/msg00707.html Second, recent discussion of Bryan Warnock's PDD 0 addresses the issue of adaptability of the Perl 6 process. The thread (from this week) starts here: http:[EMAIL PROTECTED]/msg00712.html =head1 ABSTRACT The RFC process should not have had an artificial deadline; it should be an adaptive process that should last the entire development cycle of perl6 and perhaps after. Again, the RFC process is closed. If you have ideas on how we can improve the quality of documents yet-to-be-written (e.g. the PDD series) or the process of obtaining such documents, then please focus on work that remains to be done, not artifacts that don't need to be polished. Z.
Re: Not revisiting the RFC process (was: RFC 362...)
On Thu, Feb 22, 2001 at 12:00:45PM -0800, Edward Peschko wrote: As I stated in the original post, there is no reason *not* to keep the process open. In an attempt to keep my previous message concise, I seem to have neglected a few key points: 1) The RFC was a free-for-all brainstorming process. Intentionally. 2) RFCs were not intended to be the basis for designing the language or describing/creating the implementation. They were intended to collect comments on the aspects of Perl5 that should/could be fixed in Perl6, or cool new features that cannot be reasonably added into Perl5 but could be integrated into Perl6. 3) The RFC process was designed to be a limited call for ideas for Larry to consider in a language design. The deadline was integral to the process, and decided before RFC collection began. The RFC's would be a very good tool to sift discussions, let ideas flow, and not to revisit discussions in the future. 4) The RFCs have demonstrated that they are a very poor tool for starting and continuing a productive, forward moving discussion. Many of these issues are addressed in PDD 0 and Dan's thoughts on the PDD process. [...] Dan Sugalski replied that the RFC process *was* going to be ongoing, so I was willing to have it hit the next 'cutoff'. The formal (more-formal-than-p5p) document gathering process will be ongoing. That is one reason (of many) why the PDD series is emphatically not a series of RFCs. We made mistakes with the RFC process and don't want to repeat them. Hell, I was going to make an RFC searcher, commentor, and so forth that could be re-used for PPD. I have no interest in making such an engine if PPD only exists, because I think that PPD by itself is clearly insufficient to handle the needs of the perl community. There's nothing stopping you, but the RFC archive is closed and will likely not be reopened (save for some minor details in the queue). It's primary value is in cataloging a series of ideas of what Perl could or should become. So I ask you - *why* make an artificial deadline? What's the point? The deadline was not artificial. It was by design. Do you really think that RFC's as they stand equal all the large issues that are going to be faced with perl6? No, and there's nothing wrong with that. I'm sorry, but this pisses me off. You've got to realize that for a lot of us, our time is intermittent and our commitment can only be sporadic. All the more reason to focus on building the future, not polishing the past. I, for one, was busy in transitioning to another state when the whole perl6 design thing happened last year. So hell - I plan on giving my contribution now. What's better - that, or twiddling our thumbs? If you want to contribute, patch bleadperl, or make a contribution on what we're doing today. Z.
Re: Perl, the new generation
On Tue, May 15, 2001 at 03:41:15PM -0600, Nathan Torkington wrote: Stephen P. Potter writes: It seems to me that recently (the last two years or so) and especially with 6, perl is no longer the SAs friend. It is no longer a fun litle language that can be easily used to hack out solutions to problems. It is now (becoming) a full featured language, quite at the expense of its heritage. And yet there are a zillion programs from perl4 and earlier that still work in perl5. In what way can you not use Perl to solve sysadmin problems or hack out fun solutions to problems? I do those two things all the time. I don't think backwards compatibility is the point here. I picked up Camel 1 recently, and it was quite amazing how different Perl4 *felt*. It's like Perl was being pitched as a good language for writing standalone programs or utilities of standalone programs (the type a sysadmin would use). It didn't feel like it was being offered as the kind of language to write things like Class::Contract, Inline::C, AxKit, SOAP::Lite or the all-singing-all-dancing CGI.pm. Where are we now? Perl5 is a bigger language and Perl6 is proposed to be bigger still. There are people who complain about Perl5 because they can't keep it all in their heads, unlike C, sh and Python (and to some extent, Perl4). When we moved from 4 to 5, so people thought we should continue developing 4 without all the useless new stuff, like OO and threads and etc. I wonder more and more if they weren't right. I wonder if as 6 develops if we shouldn't split off the old 4 syntax and have two languages. If you want to do it, do it. I vomit at the thought of a language without data structures or modules, though, and I wouldn't be surprised if others did too. It's not so much that Perl shouldn't have data structures or modules. I think what Stephen is saying (and he's not the only one) is that the bare minimum amount of Perl you *must* know to be productive is increasing. Either that, or we're giving the impression that it's increasing. Many people don't want to get bogged down in how the details of Unicode, upperclass level CS topics or Perl's unique syntactical peculiarities to parse a damn log file (or find and use a CPAN module that does it). Z.
Re: Perl, the new generation
On Fri, May 18, 2001 at 08:08:40PM +0100, Simon Cozens wrote: On Fri, May 18, 2001 at 12:55:55PM -0400, Stephen P. Potter wrote: Atoms- Unicode. If everything is Unicode, you're going to have to grok Unicode (at least tangentally) to be able to use perl. Bah. Rubbish, no more than you need to grok Unicode to use Perl 5.6. Do you know what data of yours 5.6 is storing in Unicode? No. Do you care? No. Do you need to? No. One of the big selling points about Java is that it's always use Unicode natively from day 1, yet I've never seen a Unicode Primer for programmers starting out with Java book/site/article/paper/certification. Unicode is just *there*. Much like oxygen and nitrogen. The tangential deviation necessary to grok unicode to use Perl is perhaps .01 degrees away from the previous learning curve. Using Perl to grok Unicode is a little different. :-) Z.
[ANNOUNCE] Apprenticeship Hour at YAPC::NA
As some of you may have noticed from the YAPC schedule[1], I'll be hosting the Perl Apprenticeship Hour next week. I'm STILL looking for brief descriptions of projects that are looking for some help, including: * documentation* tools * tutorials* bugfixes * modules * enhancements to existing code * websites * collaborative efforts * test code* program suites If you plan to attend YAPC::America next week, and have: - an idea for a project, but need extra tuits - an idea for a project that would be a good way to mentor a beginner - an idea for a project, don't have time to do it, and don't have a lot of time to explain it then please send a brief description ASAP to [EMAIL PROTECTED]. The apprenticeship hour will be run much like mjd's Lightning Talks, where presenters will have ~5 minutes next Wednesday to discuss an idea for a project. Thanks, Z. [1] http://www.yapc.org/America/talks.shtml#schedule
Perl Doesn't Suck
What follows is a long, detailed summary of an attempt to install JDK 1.2.2 on FreeBSD today. FreeBSD/JDK 1.2.2 is an unsupported configuration for Sun, although patches exist to get the JDK to work under FreeBSD. Skip to the last two paragraphs if you want to see how this installation compares to a standard Perl installation, and what this means for Perl. Please read the rest if you want to see what a 'simple' installation took for this version of Java. (Note: JDK 1.1.8 is supported, but JDK 1.2.2 isn't, and some software requires JDK 1.2.2 (Java2)). Comments welcome. Z. --- I recently had occasion to upgrade Java on my FreeBSD installation at home. I have both the Java Runtime Environment (JRE), v1.1.8 and Kaffe 1.0.6. I deal with XSLT a lot, so keeping these around is a necessity when dealing with XSLT engines, such as Michael Kay's Saxon and James Clark's xt. The JRE apparently comes directly from Sun and contains only the virtual machine required to execute Java programs. It lacks things like documentation and javac, the Java compiler (written in Java). JRE 1.1.8 implements the Java 1.1 specification, which appears to be useful, but out of date compared to the current Java 2 specification (JDK 1.2 and above), and the imminent Java 1.3 release. (I'm going on memory here; there's so much *stuff* on java.sun.com, it's quite difficult to easily determine whether Java 1.3 is shipping, in a late beta cycle or in an early PR cycle.) As the name would imply, the JRE is just that - a runtime environment. Unfortunately, it's not the kind of run anywhere environment you would expect from Java. To be fair, it's only Java 1.1, and that's OK. But it's insufficient for running applets in my favorite web browser du jour, Konqueror. So I installed an Open Source reimplementation of Java 1.1, Kaffe. Now, whenever I visit java.sun.com, Konqueror loads and runs the applets through Kaffe, and I get a familiar grey box which says Loading Applet. And a core file from Kaffe whenever it's invoked. But Kaffe also runs Java programs without a hitch, just like the JRE. (Note: Kaffe may not be fully compliant, but it runs what it's supposed to run, and it doesn't crash, except within Konqueror and running applets.) At this point, you probably think this is another rant about Java being a bad language, unsuitable for software development, or an example of immature software being thrust upon the uncaring public. It's not. Java is a fine environment, and until today, I never had to think about it, even though I use programs written in Java every day. The fact that Saxon is implemented in Java is an unimportant fact that sits buried in a Makefile or two. It's as unimportant a detail as cvsup being implemented in Modula-3. In a sense, that's the hallmark of good software -- it should do a job, do it well, and stay out of the way. The JRE and Kaffe do that with Java 1.1 software. If only Java 2 would be so unobtrusive. I installed Java 1.2.2 today because I want to start using other XML technologies, like SVG. The Apache XML project is working on a project called Batik that will do pretty much anything with images in the SVG format. All I really want to do is generate SVG files using XSLT, and translate vectorized SVG files into rasterized PNG images. Batik promises to do that, and much, much more. As I said before, I'm running FreeBSD. This should be a simple pair of commands: 'cd /usr/ports/java/jdk12-beta; make install'. The native JDK 1.2 port appeared within the last few weeks or so; previously, to run JDK 1.2 applications, the Linux JDK needed to be run, and that was one too many levels of emulation to consider. So I start with the obvious. And it doesn't work. To install the jdk12-beta port, the JDK sources and patches need to be downloaded manually; this is because of some licensing issues with Sun, where the sources are available only to registered developers. Annoyed, I register and get the sources, and then the patches. Due to poor web design on Sun's site, it took a while to actually find the links for downloading the sources -- it's almost like Sun doesn't want you to find them. Getting the patches was easier, although it also involved a clickwrap check, since the patches are only available to developers who have registered with Sun's developer program. (Who *else* would be interested in patches to the JDK?) Having downloaded, about 18MB of software, I start the build process. Yes, the JDK sources are about 18MB. Compressed. Now time to let the port build itself. The wonderful thing about ports is that build and runtime dependencies will be checked, and installed as required. After downloading, extracting and patching the 18MB JDK 1.2.2 sources, the very next thing that happens is that the full JDK 1.1.8 is installed as a build dependency (Sun's JDK, as binaries, including 'javac'). Then the Linux version of the JDK
Re: Perl Doesn't Suck
On Fri, Jun 29, 2001 at 01:18:07PM -0500, Elaine -HFB- Ashton wrote: Adam Turoff [[EMAIL PROTECTED]] quoth: * *Nevertheless, a degenerate case for installing Perl never requires *transfers or temporary disk space measured in quarter gigabytes. Sure it can. Allow me to clarify: a degenerate case for installing a *single* *specific* version of Perl never requires transfers or temporary disk space measured in quarter gigabytes. Mirroring all of CPAN is not a pre-requisite for installing a version of Perl, multiple versions of Perl, etc. *Worst-case-to-worst-case, Perl doesn't suck, and it's doing much *better than Java. I wonder which is easier to support post-install. Perl can suck and often does for the newcomer who, when faced with trying to wade through all the XML modules on CPAN trying to figure out which one is which for what purpose, can be quite frustrated with getting things to work as advertised. That's not the issue here. Chris and I are talking about the case where a user finds a piece of software requiring (Perl|Java) and need to install the language distribution as well as the software requiring that distribution (or, a simpler case of installing a specific version of a language distribution). Wading through CPAN is not an issue here. Everything can suck given enough scrutiny. Surely. And if you want to believe that Perl sucks, please do. While installing Java this week, I stumbled across the installation experience and supported platforms aspects of a language and found that Perl is doing remarkably well, even if no one takes the time to say so. I chronicled my experiences in detail to show how bad it can be, and to highlight how remarkably well-engineered and supported Perl is by comparison. Z.
Re: Perl Doesn't Suck
On Fri, Jun 29, 2001 at 05:20:40PM -0400, [EMAIL PROTECTED] wrote: There's the trick, Solaris is Sun's Blessed Platform. As a Linux/PowerPC user, I know how Ziggy feels. I'm almost totally ignored by Sun and I'd imagine I'd have just as much trouble getting it working as he did. This is the issue in a nutshell. Let's not mix business issues with technical ones. Let's not mix cluster management with simple end-user installation. Let's not mix businesses losing millions by the microsecond with the guy who just wants his little website to just *work*. [*] Personally, I don't really care what my support options are at 4am, who I can pay to rouse out of bed, or whose pager I can pay to page. I want technology that works, not technology with a glitzy sales presentation and more hype than the Beatles. I don't want technology that's unnaturally bound to customer support to make it work. I want something that works, as advertised, and works reliably enough for me to adopt it (perhaps after making a few patches). Plenty of companies find lots of work playing in Sun's (or Oracle's or Microsoft's ) view of the world. That does not define the world of computing. Not by a longshot. Let's not forget that the mainframe never died, even after 20 years predicting it's imminent demise. Remember too that the proprietary, commercially supported client/server programming languages focused on mainstream platforms like Win3.1+Sybase are now a footnote to history. This is especially sad with Java, which promised to be write-once run-anywhere, and continues to fail to deliver on that promise. This is especially nice with Perl, which has delivered on write-once run-anywhere without promising it, and has done so for more than a decade. Doubly so when Perl's single-implementation standard gives predictable results pretty much everywhere, while Java is subject to multiple JVMs which can be differently buggy. But yes, module installation can be made easier. We're working on it. There are always improvements to be made, even with Perl. But where we are today, Perl doesn't suck. Z. *: What good is that multi-billion dollar business doing? Who knows. What good is that little guy doing? Who knows, but it might be the next version of the OED, a realtime snapshot of the company's PL, or satellite data that reaches you quicker.
Re: Perl DOC BOF
On Sun, Jul 29, 2001 at 12:48:54AM -0400, Bryan C . Warnock wrote: Okay, fun's over. Back to work. There was a Perl Documentation BOF that was scheduled for 6:30 Friday; however, it seems none of the folks who showed up actually called it, and none of the folks who called it actually showed up. (Or showed up fairly late - after I had already left.) What was it about? I'm working on some comprehensive Perl 6 reference material for the group, but would like to take into consideration any upcoming changes to how docs are done. Ziggy? You posted the note, but I don't remember for whom. Um. Wow. Casey and I didn't think anyone had seen the notice. The idea was that a few of us interested in the Perl Documentation Project (similarity to the Linux Doc Proj completely intentional) should get together and talk about a few organizational issues. A few people were interested in the PDP at the conference, but by Friday, we thought the message wasn't getting out in enough detail to have a fruitful discussion. Issues that need to be resolved include: 0. Licensing (Casey favors OPL, Bradley strongly urges FDL, with a reliance on copyright law, and I'm the simple son who knows not how to ask...) 1. Target Audience 2. Format (quick to read, quick to write docs that link together; 2 paragraph intro that becomes a daily tip) 3. Document Types (tutorial, howto, faq, what else do we need?) 4. Key areas of focus (perl5 newbies, perl6, whatever) That was it. This discussion will probably take place online sometime in the next month. Z.
