Re: Markup wars (was Re: Proposal for groups)

[Alan Burlison]

Russ Allbery wrote:

> I've fiddled with this before and can do text to HTML; the rest is just a
> question of picking different backends and shouldn't be *too* hard.  All
> the heuristics for parsing text are inherently fragile, but if you follow
> a standard text formatting style, it works reasonably well.

Which is precisely the reason for suggesting XML - it doesn't rely on
'fragile heuristics' to get the parsing right.  POD suffers from the
same problem to some extent, and I really can't see how typing =head1 is
better than typing  - well apart from being one character
shorter, that is.

However, having previously been told to shut up on this subject, I now
will.

Alan Burlison

Re: Markup wars (was Re: Proposal for groups)

[Jarkko Hietaniemi]

On Wed, Dec 06, 2000 at 03:59:32PM -0800, Russ Allbery wrote:
> Bennett Todd <[EMAIL PROTECTED]> writes:
> 
> > My own personal favourite for archival format would be to stick with POD
> > until and unless we can cons up something even Plainer than POD. I've
> > got this dream that someday we'll be able to take something --- perhaps
> > based on Damian's Text::Autoformat --- and use it to parse purely plain
> > ASCII text, formatted nicely for screen display, with no markup at all,
> > and garnish it with markup allowing it to be automatically translated
> > into nice sexy HTML, or SGML according to various other DTDs, or XML, or
> > POD, or the man or mandoc troff macros, or LaTeX, or whatever.
> 
> I've fiddled with this before and can do text to HTML; the rest is just a
> question of picking different backends and shouldn't be *too* hard.  All
> the heuristics for parsing text are inherently fragile, but if you follow
> a standard text formatting style, it works reasonably well.

For more ideas there is the PolyglotMan (nee RosettaMan),
http://polyglotman.sourceforge.net/

> -- 
> Russ Allbery ([EMAIL PROTECTED]) 

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: Markup wars (was Re: Proposal for groups)

[Russ Allbery]

Bennett Todd <[EMAIL PROTECTED]> writes:

> My own personal favourite for archival format would be to stick with POD
> until and unless we can cons up something even Plainer than POD. I've
> got this dream that someday we'll be able to take something --- perhaps
> based on Damian's Text::Autoformat --- and use it to parse purely plain
> ASCII text, formatted nicely for screen display, with no markup at all,
> and garnish it with markup allowing it to be automatically translated
> into nice sexy HTML, or SGML according to various other DTDs, or XML, or
> POD, or the man or mandoc troff macros, or LaTeX, or whatever.

I've fiddled with this before and can do text to HTML; the rest is just a
question of picking different backends and shouldn't be *too* hard.  All
the heuristics for parsing text are inherently fragile, but if you follow
a standard text formatting style, it works reasonably well.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: Markup wars (was Re: Proposal for groups)

[Nathan Torkington]

Bennett Todd writes:
> Would you accept a restatement of: as long as whatever it is can be
> translated into a common format, we can work with it, and the
> composition of the actual words is far more important than niggling
> over choices in preferred markup style?

Sure, but that begs the question of what is common, and that's yet
another flamewar.

Even if people wanted to write the docs in XML, I'd be happy to have
docs.  We can always PODify them if XML proves troublesome.  It's
having no docs that is the situation we want to avoid.

There are also many documentation needs.  I don't think we need to
distribute the design docs as manpages, but we need to distribute
the user docs as manpages.  When we get to user docs, we'll need to
consider the ultimate destinations for the manpages.  Until that
point, it's all talk with nothing behind it.

Nat

Markup wars (was Re: Proposal for groups)

[Bennett Todd]

2000-12-05-13:02:56 Nathan Torkington:
> I say that the person who *does* the work deserves the right to
> choose what format it is in. So long as we can make navigable
> webpages out of it, that person can write on a Commodore 64 for
> all I care.

Would you accept a restatement of: as long as whatever it is can be
translated into a common format, we can work with it, and the
composition of the actual words is far more important than niggling
over choices in preferred markup style?

My own personal favourite for archival format would be to stick
with POD until and unless we can cons up something even Plainer
than POD. I've got this dream that someday we'll be able to take
something --- perhaps based on Damian's Text::Autoformat --- and
use it to parse purely plain ASCII text, formatted nicely for
screen display, with no markup at all, and garnish it with markup
allowing it to be automatically translated into nice sexy HTML, or
SGML according to various other DTDs, or XML, or POD, or the man
or mandoc troff macros, or LaTeX, or whatever. But it remains a
dream, a fantasy, and I'd say until it's executed, POD rules for a
redistributable format; and if folks want to contribute substantial
piles of useful docs in other formats, we can convert 'em into POD.

-Bennett

 PGP signature

Re: Proposal for groups

[Nathan Torkington]

Simon Cozens writes:
> Yes, we should really postpone the inevitable markup language war until
> we have something to mark up.

You channeled my very thoughts, Simon.

I say that the person who *does* the work deserves the right to choose
what format it is in.  So long as we can make navigable webpages out
of it, that person can write on a Commodore 64 for all I care.

Nat

Re: Proposal for groups

[Chaim Frenkel]

> "BMK" == Bradley M Kuhn <[EMAIL PROTECTED]> writes:

BMK> If we do this, please also make 
BMK> or something like that, which is a list that simply redistributes
BMK> mail from  to its subscribers.  In other
BMK> words, only  post would go there, but no
BMK> subscriber could post.

Just be careful about the perl6-all redirection. Don't allow registration
on both redirection lists.

Hmm, How would this work? Headers would be re-written? How would 'critical'
comments get to the -internals-design list?


-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

Re: Proposal for groups

[Sam Tregar]

On Tue, 5 Dec 2000, Alan Burlison wrote:

> How about writing the documents in XML and having a 'perl specification'
> DTD?
> ...
> Death to POD!

Can we *please* not re-fight this war?  I know you remember the last
couple incarnations of XML VS POD.  Just replay them in your mind and
enjoy the show.  Spare us the angst.

-sam

Re: Proposal for groups

[Jarkko Hietaniemi]

On Tue, Dec 05, 2000 at 10:23:46AM +, Tim Bunce wrote:
> On Tue, Dec 05, 2000 at 09:20:29AM +, Simon Cozens wrote:
> > On Tue, Dec 05, 2000 at 09:16:23AM +, Alan Burlison wrote:
> > > I still think that with the correct
> > > DTD writing the specs in XML would be doable.
> >  
> > DocBook strikes me as being made for this sort of thing.
> 
> As someone who had the option of writing a book in DocBook or POD
> I can tell you that it simply would not have happened in DocBook.
> My co-author had used DocBook for a previous book and would rather
> have his hands cut off than use it again. Having looked at it myself

I have very similar opinions about DocBook.  XML is not for human
production or consumption.

> I had to agree with him. Nice in theory. Good for an internal format
> perhaps. But to author docs in it? No way.

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: Proposal for groups

[Alan Burlison]

Simon Cozens wrote:

> > I still think that with the correct
> > DTD writing the specs in XML would be doable.
> 
> DocBook strikes me as being made for this sort of thing.

Yak! no.  DocBook is for specifying published document layout and is
pretty huge - far too weighty for what we want.  I'm thinking more along
the lines of a DTD that specifically couched in terms of what we are
documenting rather than how it should be rendered,



int myfunct(mystruct_t *msp);



This function...


http://some.mail.archive/..." />


This could be extended ad nauseam to include all sorts of attibutes and
entities, e.g. module, file, algorithm, pre and post conditions, test
conditions etc.

I think probably the best thing is to draft an initial design doc in POE
(Plain Old English) and see if it makes any sense to tag the various
bits.

Alan Burlison

Re: Proposal for groups

[Simon Cozens]

On Tue, Dec 05, 2000 at 10:23:46AM +, Tim Bunce wrote:
> As someone who had the option of writing a book in DocBook or POD
> I can tell you that it simply would not have happened in DocBook.

Horses for courses. My next book is going to be in DocBook, and I 
do a bunch of documentation in it every so often.

> But this isn't what we're here to design...
 
Yes, we should really postpone the inevitable markup language war until
we have something to mark up.

-- 
BASH is great, it dumps core and has clear documentation.  -Ari Suntioinen

Re: Proposal for groups

[Tim Bunce]

On Tue, Dec 05, 2000 at 09:20:29AM +, Simon Cozens wrote:
> On Tue, Dec 05, 2000 at 09:16:23AM +, Alan Burlison wrote:
> > I still think that with the correct
> > DTD writing the specs in XML would be doable.
>  
> DocBook strikes me as being made for this sort of thing.

As someone who had the option of writing a book in DocBook or POD
I can tell you that it simply would not have happened in DocBook.
My co-author had used DocBook for a previous book and would rather
have his hands cut off than use it again. Having looked at it myself
I had to agree with him. Nice in theory. Good for an internal format
perhaps. But to author docs in it? No way.

I'd like to see pod improved in some small but significant ways.

I also remember saying a couple of years ago that I thought all the
pod-to-foo translators should be built on top of a small fast
pod-to-xml translator implemented in C/XS. XML would then be
doing what it's good at and very appropriate for.

But this isn't what we're here to design...

Tim.

Re: Proposal for groups

[Simon Cozens]

On Tue, Dec 05, 2000 at 09:16:23AM +, Alan Burlison wrote:
> I still think that with the correct
> DTD writing the specs in XML would be doable.
 
DocBook strikes me as being made for this sort of thing.

-- 
Facts do not cease to exist because they are ignored.
-- Aldous Huxley

Re: Proposal for groups

[Alan Burlison]

Adam Turoff wrote:

> 
> Say What?
> 

Say XML - ex em ell :-)

> We need a better POD, not a cumbersome machine-to-machine interchange
> format for writing docs.

The main problem with POD is that we have to write the tools to do
anything with it.  Witness the endless hacking/cursing/hacking/cursing
cycle on the existing POD tools.  Do we really want to continue? 
Personally I think POD sucks bigtime, although I'm sure hordes of people
will now spring up to defend it.  I still think that with the correct
DTD writing the specs in XML would be doable.

Alan Burlison

Re: Proposal for groups

[Adam Turoff]

On Tue, Dec 05, 2000 at 08:21:23AM +, Alan Burlison wrote:
> How about writing the documents in XML and having a 'perl specification'
> DTD?  With a bit of careful thought we will be able to do all sorts of
> interesting stuff - for example if we tag function definitions we can
> start cross-checking other documents and even the code for consistency
> with the spec.
> 
> Death to POD!


Say What?


We need a better POD, not a cumbersome machine-to-machine interchange
format for writing docs.

Consider:

=use article
=use table
=use list

=title Ode to Dr. Geisel
=author Foo Barr <[EMAIL PROTECTED]>
=date $Date$
=revision $Version$

=section Introduction

Imber totum diem flut urceatim semper pluit.  [1]

=section Overview

Tadet intus nos manere: numquam potest sol splendere.  [2]

=list
* A
* B
** B 1
*** B 1 a
*** B 1 B
=end

=table
=title Sample table
a   b   c   d
1   2   3   4
=end

Posted as an example that not all POD needs to be cluttered
with =over 4 and =item *, not as an end-all proposal for a 
better POD.

Z.

1: Cattus Petasatus, p1
2: ibid

Re: Proposal for groups

[Alan Burlison]

Nathan Torkington wrote:

> Alan Burlison writes:
> > seem a very optimal way to go about it.  How about a design document
> > (format to be decided) and a 'design + commentary' document which is the
> > design document with the condensed email discussion inserted into it as
> > the commentary.  That way there is a design spec for the implementation,
> 
> Cool.  You're volunteering to edit it?

Hah!  You don't ensnare me that easily, Mr. Torkington! ;-)

How about writing the documents in XML and having a 'perl specification'
DTD?  With a bit of careful thought we will be able to do all sorts of
interesting stuff - for example if we tag function definitions we can
start cross-checking other documents and even the code for consistency
with the spec.

Death to POD!

Alan Burlison

Re: Proposal for groups

[Alan Burlison]

-- Adam Turoff wrote:

> Are you asking for a Design Document (tm) to be published/updated
> along with an Annotated Design Document (tm)?  Sounds like what Tim
> Bray did for the XML Spec at http://www.xml.com/axml/testaxml.htm.

Wow - I hadn't seen that - neat.  I expect this was generated by writing
a DTD for the spec and then transforming the document into the frameset
and html files.  That would be the obvious way to do it.  That way when
writing the document the commentary could be kept inline, which would
make it much easier for the author.

Alan Burlison

Re: Proposal for groups

[Bradley M. Kuhn]

Nathan Torkington <[EMAIL PROTECTED]> wrote:
> How about we do this to design the architecture and API:
> 
> perl6-internals-design is for a team of no more than 10 people.  These
> people should have experience either with perl5 or with a similar
> system.  Mail to this list goes to perl6-internals-design and to
> perl6-internals.

One minor suggestion:

If we do this, please also make  or
something like that, which is a list that simply redistributes mail from
 to its subscribers.  In other words, only
 post would go there, but no subscriber could post.

Rationale:

Some people who aren't on the design team may want to follow the progress,
but aren't particularly interested in the public  list.

-- 
Bradley M. Kuhn  -  http://www.ebb.org/bkuhn

 PGP signature

Re: Proposal for groups

[Nathan Torkington]

Alan Burlison writes:
> seem a very optimal way to go about it.  How about a design document
> (format to be decided) and a 'design + commentary' document which is the
> design document with the condensed email discussion inserted into it as
> the commentary.  That way there is a design spec for the implementation,

Cool.  You're volunteering to edit it?

Nat

Re: Proposal for groups

[Sam Tregar]

On Sat, 2 Dec 2000, Nathan Torkington wrote:

>  * it's difficult for the design to happen through the questions

Is that really true?  Have we tried?  As far as I can tell we've got a
lot of well-intentioned people that for whatever reason are spending very
little time making Perl 6 happen.

Let me explain why I think this is a useful comment instead of just
slander from the sidelines.  I'm somone who's reasonably knowledgeable
about compiler technology and about Perl internals.  Still, I'm not so
expert that I feel comfortable leading the design of the Perl 6 internals.
I'd hoped to be involved as a skilled helper - able to develop and
debug proposed systems.  The problem is that I can't be of much use until
the people that really are qualified to design this stuff start producing
designs.

So, here's my opinion: we have enough structure.  All the people are here
that are going to show up.  Now it's time to do the work and that means
the experts have got to dedicate some serious time to sketching out the
skeleton of this beast.  Once you've done that then I think you'll find
there are more people around to add the needed muscles, skin and brains.

If you need to go off in a room alone to that, well, I guess that's your
option.  I just don't think you've actually given the existing structure
much of a trial yet.

-sam



>
> How about we do this to design the architecture and API:
>
> perl6-internals-design is for a team of no more than 10 people.  These
> people should have experience either with perl5 or with a similar
> system.  Mail to this list goes to perl6-internals-design and to
> perl6-internals.
>
> perl6-internals is a public access list, where folks can feel free to
> question and kibitz.  The design team will probably want to have a few
> people on the public list as well.  This is where the consciousness of
> the rest of us can be raised.  We can see what they're doing, ask
> questions, and make suggestions.  Because the meta discussion happens
> off the -design list, designers will be able to tune it out if they
> have to focus on the task at hand.
>
> This lets us satisfy these goals:
>  * open process, both for visible and participation
>  * small team doing the design (elephant is a mouse designed by
>committee, etc)
>
> Make sense?
>
> Nat
>

Re: Proposal for groups

[Jarkko Hietaniemi]

As another example of a process that seems to be working well (as far
as I can tell by being a lurker) check out the xml-dist-app mailing list
archives at http://lists.w3.org/Archives/Public/xml-dist-app/

They have a draft up in the web [1] and the Subject lines directly
refer to such and such sections of the draft.   When you discuss an
issue it's unambiguous what you are talking about.

Of course, as almost always, "working well" is a direct function of
the editors time and skill...

[1] http://www.w3.org/2000/xp/Group/

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: Proposal for groups

[Adam Turoff]

On Mon, Dec 04, 2000 at 07:56:21AM +, Alan Burlison wrote:
> How are you going to publish the design?  Asking people to follow email
> discussions and try to piece together what is proposed from that doesn't
> seem a very optimal way to go about it.  How about a design document
> (format to be decided) and a 'design + commentary' document which is the
> design document with the condensed email discussion inserted into it as
> the commentary.  

Are you asking for a Design Document (tm) to be published/updated
along with an Annotated Design Document (tm)?  Sounds like what Tim
Bray did for the XML Spec at http://www.xml.com/axml/testaxml.htm.  

Perl6 should produce something like that as part of the design process.

Z.

Re: Proposal for groups

[Jarkko Hietaniemi]

> I'm planning to write (in my copious free time) an
> open-source-licensed book on the implementation and design of Perl
> 6, which should capture for posterity the sense of the discussions
> we will have had while hammering out the design:

This reminds me of:

Hmm, doubtful.  The source code generally wasn't there when I needed it.
-- Larry Wall when asked if he learned Perl from the perl source

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: Proposal for groups

[Simon Cozens]

On Mon, Dec 04, 2000 at 07:56:21AM +, Alan Burlison wrote:

> How about a design document (format to be decided) and a 'design +
> commentary' document which is the design document with the condensed email
> discussion inserted into it as the commentary.  That way there is a design
> spec for the implementation, but also the 'why we did it that way' is
> captured for posterity. Mailing lists are OK for having the discussion, but
> aren't very good for recording it for posterity.  I'm inspired by the perl5
> digest produced by Simon, which I think is a really, really useful thing -
> you can use it to get the essence of what went on and why, and then drill
> down to the meat if you need to.

I'm planning to write (in my copious free time) an open-source-licensed book
on the implementation and design of Perl 6, which should capture for posterity
the sense of the discussions we will have had while hammering out the design:

Several models were discussed for garbage collection, but XXX turned out
to be the best for our purposes, because . YYY initially looked good,
but had the disadvantage that , and it was felt that . We also
considered ZZZ, but all agreed that .

-- 
The sky already fell.  Now what?  -- Steven Wright

Re: Proposal for groups

[Alan Burlison]

Nathan Torkington wrote:

> This lets us satisfy these goals:
>  * open process, both for visible and participation
>  * small team doing the design (elephant is a mouse designed by
>committee, etc)

How are you going to publish the design?  Asking people to follow email
discussions and try to piece together what is proposed from that doesn't
seem a very optimal way to go about it.  How about a design document
(format to be decided) and a 'design + commentary' document which is the
design document with the condensed email discussion inserted into it as
the commentary.  That way there is a design spec for the implementation,
but also the 'why we did it that way' is captured for posterity. 
Mailing lists are OK for having the discussion, but aren't very good for
recording it for posterity.  I'm inspired by the perl5 digest produced
by Simon, which I think is a really, really useful thing - you can use
it to get the essence of what went on and why, and then drill down to
the meat if you need to.

Alan Burlison

Re: Proposal for groups

[Uri Guttman]

> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:

  DS> At 12:32 PM 12/3/00 -0500, Casey R. Tweten wrote:
  >> Today around 5:24pm, Simon Cozens hammered out this masterpiece:
  >> 
  >> : On Sat, Dec 02, 2000 at 09:23:42PM -0700, Nathan Torkington
  >> wrote: : > perl6-internals-design is for a team of no more than 10
  >> people.  : : And we decide those ten... how? :)
  >> 
  >> Ideas in no particular order ( and not limiting to 10 ):
  >> 
  >> * Working group chairs * Larry * Contributors and Authors of the
  >> Perl 5 core * People in the AUTHORS file of Perl 5 * Just moderate
  >> posting to the list

  DS> You forgot:

  DS> * Secret vote of the Perl Cabal...

i hope none of the cabal live in florida.

:)

uri


-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

Re: Proposal for groups

[Simon Cozens]

On Sat, Dec 02, 2000 at 09:23:42PM -0700, Nathan Torkington wrote:
> I think I see two problems:
>  * a lot of people want to know what's going on, but not all have the
>experience to be able to follow it
>  * it's difficult for the design to happen through the questions

AMEN.

> perl6-internals-design is for a team of no more than 10 people.  These
> people should have experience either with perl5 or with a similar
> system. 

This was actually going to be a Perl 5 thing, but I mention it in the hope
that people will add $two and $two together and get the necessary five. :) 

Looking back over the perl5 Changes file recently, I was shocked and disturbed
to find how *few* people were contributing to the internals - not just the
platform-specific stuff or the Perl library, but the core C files in the Perl
distribution, and the real guts at that. (??.[ch] and friends)

Maybe there just isn't very much interesting work to do, or maybe nobody
understands it at all, but to produce a list of twenty people who have been
regularly contributing to various areas of the internals, I had to go all the
way back to August. Here are the twenty people I found prominently working on
the internals, in the Changes file since August: (in no particular order)

Alan, Jarkko, Dan, Andy, Dominic, Sarathy, Merijn, Hugo, Ilya,
Nick Clark, Nick I-S, me, John Tobey, Yitzchak, Robin, Casey,
Jens, Spider, Mike, Benjamin Stuhl.

Eight of those twenty haven't posted to perl6-* since my records began.
(September) The rest might want to think hard about how much they want to help
out. :) 

[ Of course, there have very obviously been people on perl6-internals saying
good and useful things who have not been involved in perl 5, and I'm not
looking down on them - I just don't have hard, verifiable data on *exactly*
how useful they are. :) ]

As for me, I hate this "self-selection" thing because it forces me to be
immodest. Oh well, better get used to it: Me. I think I'd be useful.

I'd also like to propose another mailing list (Yay! YAML!) to which people can
copy messages from the -design list and ask for clarification on technical
things they don't understand:

To: [EMAIL PROTECTED]
From: Simon Cozens <[EMAIL PROTECTED]>
Subject: Re: Parse tree tiling

Clever Bastard wrote in perl6-internals-design:
> ... degrees of freedom of a spline ...

Uh, what's a spline?

-- 
Simon:  `hello kitty' douche. If you are getting some and you know what
hello kitty is... Well, you're an exceptionally lucky man.
  -- Megahal, trained on IRC.

Re: Proposal for groups

[Ask Bjoern Hansen]

On Sun, 3 Dec 2000, Casey R. Tweten wrote:

> Today around 1:16pm, Ask Bjoern Hansen hammered out this masterpiece:
> 
> : On Sun, 3 Dec 2000, Simon Cozens wrote:
> : 
> : > On Sat, Dec 02, 2000 at 09:23:42PM -0700, Nathan Torkington wrote:
> : > > perl6-internals-design is for a team of no more than 10 people. 
> : >  
> : > And we decide those ten... how? :)
> : 
> : The ~ten who thinks they have the skills and dares to step forward
> : and volunteer?
> 
> What if you feel you can obtain the skills, with out too many of those
> process delaying questions, and still be and asset?

You can optain the skills in the process and exercising them on the
perl6-internals list.
 
> Of course, that would mean that 10 slots would not be enough, no
> doubt.


 - ask

-- 
ask bjoern hansen - 
more than 70M impressions per day, 

Re: Proposal for groups

[Casey R. Tweten]

Today around 1:16pm, Ask Bjoern Hansen hammered out this masterpiece:

: On Sun, 3 Dec 2000, Simon Cozens wrote:
: 
: > On Sat, Dec 02, 2000 at 09:23:42PM -0700, Nathan Torkington wrote:
: > > perl6-internals-design is for a team of no more than 10 people. 
: >  
: > And we decide those ten... how? :)
: 
: The ~ten who thinks they have the skills and dares to step forward
: and volunteer?

What if you feel you can obtain the skills, with out too many of those
process delaying questions, and still be and asset?

Of course, that would mean that 10 slots would not be enough, no
doubt.

-- 
print(join(' ', qw(Casey R. Tweten)));my $sig={mail=>'[EMAIL PROTECTED]',site=>
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig->{site})+6),"\n";
print map{$_.': '.$sig->{$_}."\n"}sort{$sig->{$a}cmp$sig->{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce 

Re: Proposal for groups

[Ask Bjoern Hansen]

On Sun, 3 Dec 2000, Simon Cozens wrote:

> On Sat, Dec 02, 2000 at 09:23:42PM -0700, Nathan Torkington wrote:
> > perl6-internals-design is for a team of no more than 10 people. 
>  
> And we decide those ten... how? :)

The ~ten who thinks they have the skills and dares to step forward
and volunteer?


 - ask

-- 
ask bjoern hansen - 
more than 70M impressions per day, 

Re: Proposal for groups

[Nicholas Clark]

On Sun, Dec 03, 2000 at 12:22:23PM -0600, Jarkko Hietaniemi wrote:
>   * MI6

my impression was that both Mossad and the French secret service have been
fingered in more things than MI6. This could mean MI6 do less, or they do
it better.

I think you also forgot the First Church of Christ Scientist and the
Church of the Latter Day Saints in your list of organisations.

Do we need a sub list perl6-conspiracy-theories so that we can keep the
main lists free for other discussions?

Nicholas Clark

Re: Proposal for groups

[Nathan Torkington]

Simon Cozens writes:
> On Sat, Dec 02, 2000 at 09:23:42PM -0700, Nathan Torkington wrote:
> > perl6-internals-design is for a team of no more than 10 people. 
>  
> And we decide those ten... how? :)

Self-selecting.  Who has the necessary experience to bring to the
table and wants to be part of that team?

Nat

Re: Proposal for groups

[John Porter]

Jarkko Hietaniemi wrote:
>   * Operation Bluebook

Or rather:

* Aliens -- e.g. Vegans. (And no, I don't mean strict vegetarians.
Well, o.k., them too.  :-)

* Elians
* The Meat And Dairy Industry
* The Logging Industry
* Whaling Nations
* Sealand
* Hollywood
* the Hezbollah


>   * the Triads

Do you mean:

* The Trilateral Commission


>   * the Freemasons

And/Or:

* The OTO


>   * the Illuminati

Sure.  And what about:

* The Drug Cartels
* The Media
* Joggers  :-)


-- 
John Porter

A cop knelt and kissed the feet of a priest,
and a queer threw up at the sight of that.

Re: Proposal for groups

[Jarkko Hietaniemi]

On Sun, Dec 03, 2000 at 01:04:19PM -0500, John Porter wrote:
> Dan Sugalski wrote:
> > You forgot:
> > * Secret vote of the Perl Cabal...
> > ;-)
> 
> And also:
> 
> * Behind-the-scenes string-pulling by corporate interests.

I'd like to add the obvious

* CIA
* the 'Family'
* Air Force
* Operation Bluebook
* NSA
* MI6
* OPEC
* the Communists
* FSB (formerly KGB)
* the Triads
* Catholic Church
* the Jesuits
* the Freemasons
* Chapter 17
* the Knights Templar
* the Illuminati

> -- 
> John Porter

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: Proposal for groups

[John Porter]

Dan Sugalski wrote:
> You forgot:
> * Secret vote of the Perl Cabal...
> ;-)

And also:

* Behind-the-scenes string-pulling by corporate interests.

-- 
John Porter

Re: Proposal for groups

[Dan Sugalski]

At 12:32 PM 12/3/00 -0500, Casey R. Tweten wrote:
>Today around 5:24pm, Simon Cozens hammered out this masterpiece:
>
>: On Sat, Dec 02, 2000 at 09:23:42PM -0700, Nathan Torkington wrote:
>: > perl6-internals-design is for a team of no more than 10 people.
>:
>: And we decide those ten... how? :)
>
>Ideas in no particular order ( and not limiting to 10 ):
>
>* Working group chairs
>* Larry
>* Contributors and Authors of the Perl 5 core
>* People in the AUTHORS file of Perl 5
>* Just moderate posting to the list

You forgot:

* Secret vote of the Perl Cabal...

;-)

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Proposal for groups

[Casey R. Tweten]

Today around 5:24pm, Simon Cozens hammered out this masterpiece:

: On Sat, Dec 02, 2000 at 09:23:42PM -0700, Nathan Torkington wrote:
: > perl6-internals-design is for a team of no more than 10 people. 
:  
: And we decide those ten... how? :)

Ideas in no particular order ( and not limiting to 10 ):

* Working group chairs
* Larry
* Contributors and Authors of the Perl 5 core
* People in the AUTHORS file of Perl 5
* Just moderate posting to the list


I am not standing behind any of the above suggestions, just throwing
them out there.

-- 
print(join(' ', qw(Casey R. Tweten)));my $sig={mail=>'[EMAIL PROTECTED]',site=>
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig->{site})+6),"\n";
print map{$_.': '.$sig->{$_}."\n"}sort{$sig->{$a}cmp$sig->{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce 

Re: Proposal for groups

[Simon Cozens]

On Sat, Dec 02, 2000 at 09:23:42PM -0700, Nathan Torkington wrote:
> perl6-internals-design is for a team of no more than 10 people. 
 
And we decide those ten... how? :)

-- 
We *have* dirty minds. This is not news.
- Kake Pugh