Hi, folks. As has probably been obvious to most of you, I've been
really busy with my O'Reilly day job and haven't had time to attend to
Perl 6 and Parrot business. With no prompting, Allison Randal stepped
forward and has been taking on more and more of the day-to-day running
of the show.
Piers Cawley writes:
I got some mail from a publisher off the back of my 'Not Just for
Damians' article asking if I'd like to write a perl 6 book for them.
Must reply really.
Sure, I'd be glad to write about perl 6. Do you also want to know
the next Lotto numbers, who'll win the Grand
Simon Cozens writes:
As mentioned in my other mail, I also edit perl.com for O'Reilly and
Associates, who probably do have commercial interest in the development
of Perl.
The other ORA editors keep asking me should we sign more Perl 5
books? Is Perl 6 going to kill our sales? and I keep
Terrence Brannon writes:
And then just write a RTL-JVM and RTL-CRL converter?
I think it's time to collet these questions into a FAQ. Any volunteers?
Nat
I haven't seen much activity surrounding this. I figured there'd be a
flood with everyone writing support for their own favourite data
types. What's up?
Nat
I want to see a document that says how Parrot implementers should
write tests for the features they implement. Does *anyone* understand
how to do this? If so, could you please step forward and write such a
document and become a hero.
I imagine a test writing HOW-TO would cover:
* structure
John Siracusa writes:
I think we're due out in reasonably good alpha/beta shape for the summer.
Heh, the phrase suitable vague springs to mind... :)
There's a good reason for that, for why I've tried hard to avoid
giving promises of when things would be ready. Have you seen Apache 2
and
Dan Sugalski writes:
Okay, here's a tentative list 'o stuff that is in the works for Parrot 0.03
(and possibly 0.04):
*) Scalar PMCs
*) Simple I/O
*) Multiple interpreter thread creation
*) A simple arena allocation system
*) Garbage collection
Sweet! I guess Simon and you should
Simon Cozens writes:
On Wed, Sep 19, 2001 at 01:22:04PM +0200, H. Merijn Brand wrote:
Can't open perl script t/harness: No such file or directory
MANIFEST? (using most recent parrot-nightly)
Don't use parrot-nightly; use the snapshots from cvs.perl.org
So parrot-nightly will only be
I wanted to be able to say
eq I1, 15, label1, label2
That is, to compare against a constant. I've implemented versions of
the comparison opcodes that let you compare against constants. This
is my first patch to Parrot. Be merciful :-)
Nat
(also working on test system ... stay tuned)
Gibbs Tanton - tgibbs writes:
I will try to watch things as they go in and make coding standard
changes immediately from now on so we don't have such a massive
change.
Alternatively, pumpkings could refuse to apply patches that don't
conform. One or two goes around and people will learn to
Gibbs Tanton - tgibbs writes:
It seems to me that this might eventually get out of hand...could there
possibly be some way to automate the generation of a family of opcodes? For
example:
Hear hear, the same thing occurred to me. The way that there are
separate functions for each argument
Simon Cozens writes:
So maybe the best thing would be for people to send patches to the
list and Cc [EMAIL PROTECTED]
I wonder if, when RT comes online, we could use that to manage the
patches. In other words, patches become open to do items, which are
cleared when the patches are
Andy Dougherty writes:
#include config.h
rather than
#include config.h
Isn't the correct solution to this problem to say
#include parrot/config.h
That is, include the subdirectory prefix in all #includes. You -I the
directory containing parrot/, and that avoids randomly located
Simon Cozens writes:
I am in two minds here. I want to have Parrot_... prefices on
functions even if they're *not* completely necessary /pour
encourager les autres/. However, I don't want to go the way of
opening up everything in a public API righht now, because once
you've exported a
Bryan C. Warnock writes:
It's not a prioirty, but it's so much easier to walk the correct path from
the start. Since it's all Parrot, it's even easier.
I agree. How about this: when the code is available (i.e., this
afternoon), why don't you sit down with whoever else feels
passionately
Bryan C. Warnock writes:
Like I said, just things to keep in mind. There's a slight difference
between designing and coding Parrot as an interpreter backend, and coding it
as a backend to Perl that other languages can use. (I'm in favor of the
latter, though public opinion seems to favor
Sam Tregar writes:
If our PMC is a string and has a vtable which implements Perl-like
string operations, this will return the length of the string. If, on the
other hand, the PMC is an array, we might get back the number of
elements in the array. (If that's what we want it to do.)
Ok,
Simon and Dan have been teasing you, I know. I'm holding them back
from releasing what they have until:
1) We have a CVS server running. (Ask has done this and is now
working on anonymous access).
2) We have a bugtracking system. (We're currently thinking of
Bugzilla).
3) We have a
Dan Sugalski writes:
Needless to say, this makes the optimizer's job... interesting. On the
other hand, it does allow for some really powerful things to be done by
code at runtime.
The big thing I want it for is so I can write nats_settings.pm:
# nats_settings.pm - turn on strict and
We're about to have a tarball of basic interpreter source (no compiler
yet, only an assembler). Dan's already run into portability problems,
and once it comes out we're going to need to start working on the
configuration and build system.
Jarkko, are you still interested in leading this? (I'm
Simon Cozens writes:
I was using .pas and .pac. Gotta think about 8.3ness, unfortunately.
.pas is generally Pascal.
I also think it's important we choose extensions based around their
humour potential. With that in mind, I propose:
.par for Parrot source, and .pao for Parrot Objects would
I'd like to keep the code on Sourceforge from the get-go. I don't
have much experience with Sourceforge, though, and would like to talk
to someone who has. Which bits work well? Which bits aren't worth
the effort? Any tips or tricks to pass on?
Thanks,
Nat
Dan Sugalski writes:
Doing it properly in a module is significantly more of a pain than doing it
in the core. Faking it with a module means a fair amount of (reasonably
slow) perl code, doing it in the core requires a few extra lines of C code
in the method dispatch opcode function.
This is from the latest python-dev summary. It might be of interest
to folks considering how to store strings.
* Adding .decode() method to Unicode * Marc-Andre Lemburg asked for
opinions on adding a .decode method to unicode objects:
Kirrily 'Skud' Robert writes:
I would like to set up a perl6-modules to discuss this topic, which I
believe is separate from the question of what goes into the standard
library.
After talking with Skud, it sounds like it's not yet perl6 specific.
I'd suggest a
[EMAIL PROTECTED]
list for
Anyone seen this? It has a little of the flavour of what we're
going to do.
http://xlang.sourceforge.net/
Nat
Bryan C. Warnock writes:
What are we going to do with the myriad mailing lists the RFC process
spawned? Are they going to be recycled come design/implementation time, or
are they closed/dead/gone. http://dev.perl.org/lists has them all listed as
current (even though deadlines expired
Not to speak for Dan, but there's no code yet to review or learn from.
I'd love to see someone set up a perl *5* apprentice program, and
Mark-Jason Dominus has some ideas on how it might work. For perl6,
though, we're not yet at a place where I think it makes sense. Right
now there's so little
Stephen P. Potter writes:
For example, take a look at Camel1. It was a small book; you could carry
it around without building up huge biceps. You could reasonable read it in
a couple of days and get started with perl. I tried to get us to maintain
that in Camel2, but it grew to almost 700
Stephen P. Potter writes:
| You don't need to know any of the modules in CPAN to use perl, but once
| you learn how to use search.cpan.org, your productivity will most
| probably increase dramatically. Just like knowing how to use the
| documentation will make you more productive.
The
Stephen P. Potter writes:
Objection, your honor! This is a logical extention of part of the
discussion. If we're discussing what is wrong with perl5 to make perl6
better differentiating between philosophies is quite on target.
The corner of the discussion about search.cpan.org and broken
Stephen P. Potter writes:
Atoms- Unicode. If everything is Unicode, you're going to have to grok
Unicode (at least tangentally) to be able to use perl.
Others have well dealt to this.
RFC 161- Everything becomes an object. Filehandles are more object
oriented in Perl6, and the special
Dave Storrs writes:
While it may be true that beginners don't need to use a particular
feature--or even know about it--how will they know that until they have
studied it?
Documentation. A curriculum, roadmap, suggested path, whatever. Nate
Wiger's working on a man page to explain
Ariel Scolnicov writes:
Am I the only one here who's confused?
How does the printing happen in the correct order? I mean, if I said
my $x = Post order: show($root, $post)\n;
print $x;
then (I hope) we're agreed printing would happen in the *wrong* order
(first the output of
Dan Sugalski writes:
People think they *must* know all the core bits of a language, and they
think that consists of all the stuff we ship with perl. (And, let's face
it, we ship a *lot* of stuff with perl) It's like you're not allowed to
know only a part of a language anymore--that's
Dave Storrs writes:
SARCASM=EXTREME
Everyone, please try to stop the downhill descent of the conversation.
This is not just Dave, but others in the thread too.
I'm trying to understand what people fear, and why they fear it, so
that I know how to respond. Ridiculing, inflaming, or
Bryan C. Warnock writes:
I think the biggest fear isn't that Perl is going to grow out of its niche,
but that it's going to outgrow it. It's great that Perl has been able to
expand to be so many things to so many people, but not at the expense of
forgetting its roots - of the whole Right
Dave Storrs writes:
1) One of the great strengths of Perl is that its learning curve
is very shallow but very long. Adding more stuff to the language makes
the curve steeper, because you need to hold more in your head as you learn
it.
I see those as orthogonal. I can add more to the
Stephen P. Potter writes:
This is quite a simple little script. The majority of the changes
that are being talked about won't ever show up in this. It'd be
nice if you could show something a little more complex.
The point I was making is that the perl4 stuff won't change
significantly.
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
Damian's writing a series of articles parallel to Larry's Apocalypses.
These Exegesis articles will show full perl6 programs, with
commentary exlaining the new features.
The first Exegesis (numbered 2, to keep in sync with Larry) shows a
perl6 version of a binary tree program from the Perl
Edward Peschko writes:
Ok, question here. Are these exegesises 'blessed'? What is open to
debate on this?
As Simon says, ask whatever questions you want.
print Post order: ; show($root,$post); print \n;
would be better off written as:
print Post order: show($root, $post)\n;
wouldn't
Simon Cozens writes:
On Tue, May 15, 2001 at 03:47:36PM -0700, Mark Koopman wrote:
i think that's the idea...they have similar meanings, so they should do
similar things. hey it's the English language, i'll leave it up to someone
else to come up with the 7 other ways to prove ownership of
Edward Peschko writes:
Exactly. This has not been finalized in an Apocalypse - hence the question
whether or not it has been 'blessed'.
So - has this decision been made?
I've heard Larry saying things that make me think strict and -w
will not be on by default. I'll leave it to him to
Dave Storrs writes:
at first I was alarmed and a bit appalled at a lot of the
changes...e.g., the 'HASH $tree is rw' parameter declaration.
Jesus, I thought if I wanted a typed languaged, I'd use C++.
The more I read, however, the more I became convinced that these
were actually elegant
Michael G Schwern writes:
It might be useful to draw up a list of functions and features which
we don't plan on changing? Maybe just run through each Perl 5 man
page and highlight everything that will still be the same and post
this somewhere?
Damian's converted a program from the Cookbook
Michael G Schwern writes:
5.6.0 style was jarring enough (and fairly well justified). Its been
so long since we've had an integer increment that it should be fairly
shocking.
And we can always think of a scheme for codenames, and have that
scheme be the theme for perl6.
Hmm, if perl5 was
Nathan Torkington writes:
Here's a program I use to count messages in my mailfile:
My point being that perl6 is not a bizarre froofroo language bearing
no relationship to perl5, and that all the good stuff from perl5 will
be alive and kicking in perl6. I think a lot of the panic here
Here's a program I use to count messages in my mailfile:
#!/usr/bin/perl -w
while () {
if (($who) = /^From\s+\S+\s+\S+\s+(\S+\s+\S+)/) {
@r = reverse split ' ', $who;
$r[0] = sprintf(%02d, $r[0]);
$count{@r}++;
}
}
foreach (sort keys %count) {
printf(%s:
Michael G Schwern writes:
$foo has true doesn't flow as well as $foo is true. Dunno quite
what the other expected uses are.
$foo has truth; # :-)
This leads naturally to:
$foo has the_buddha_nature;
$foo has ten_days_to_live;
$foo has meddled_in_my_affairs_one_too_many_times! # !
Larry's Second Apocalypse (that's part 2 of his travels through the
Camel writing about what will change in perl 6) is on the web at:
http://www.perl.com/
Enjoy!
Nat
Larry Wall writes:
wanted, you still get the length. If you're worried about the delayed
operation, you can force numeric context with $x = +@tmp;, just as you
can force string context with a unary ~.
How often are you likely to do this? Speaking as a reader of code,
I've always hated unary
I don't think that extreme positions (minimalist! bloater!)
helps here. I think the important question to ask about any given
feature is: what will it let me do? Features with no good answer to
this question obviously have no place in core. Attempting to align
with one or another
Andy Dougherty wrote:
Yes, precisely. I often have one-liners embedded in larger shell scripts.
Most of those survived the perl4-perl5 transition intact. I'd hope the
same can be said for the perl5-perl6 transition.
This is exactly the situation that Larry mentioned on Wednesday as
an
Not a comment at all on it? Was I accidentally unsubscribed to
perl6-language?
*tap* *tap* is this thing on?
Nat
Title: http://dev.perl.org/rfc/73.html
[25]RFC 73: All Perl core functions should return objects
[...]
I'm thinking that the solution is better abstract type support
for data values that happen to be represented internally by C
structs. We get bogged down when we try to translate
Peter Scott wrote:
Some of us got to reading Damian's design for Perl 5+i which was announced
at the same time and are suffering from blown minds after learning how fast
he wrote the thing.
Consider how blown his mind is after WRITING it :-)
Oh, and who put him up to that, eh?
I'm sure I'd
Larry's approaching perl6 through the Programming Perl book (the Camel).
He's going chapter by chapter through the Camel, writing documents about
the perl6 equivalent concepts. These missives are known as "Apocalypses",
for reasons best known to Larry. :-)
He's churning through the RFCs,
Larry's approaching perl6 through the Programming Perl book (the Camel).
He's going chapter by chapter through the Camel, writing documents about
the perl6 equivalent concepts. These missives are known as "Apocalypses",
for reasons best known to Larry. :-)
He's churning through the RFCs,
What bothers me about the idea of reopening the RFC proces is that the
RFCs we have are already overwhelming. I think one reason we haven't
seen anything from Larry yet is that the RFCs cover an enormous area,
but in a disconnected and difficult to summarize and use form.
I don't think there's
Bryan C. Warnock writes:
Ask, all, are we reusing perl6-rfc as the submittal address, or will there
be a new one (perl-pdd)?
I'm in favour of renaming to reflect the new use of the list. Dan?
Nat
Dan Sugalski writes:
I've been thinking since I sent my last mail on this that we might actually
want to leave the two (PDD RFC) separate. Keep on with the RFCs for
'external' things, and PDD for the actual internals implementation of things.
Ultimately, I think we're going to need at
Espen Harlinn writes:
I'm trying to locate information about the Perl 6 Language, i.e. what
changes are proposed to the Perl language and so on.
Can anyone point me in the right direction ???
In case anyone else is wondering:
http://dev.perl.org/
Nat
Kirrily Skud Robert writes:
Wasn't he meant to be keeping us up to date with snippets of what he's
doing/thinking about? I recall Nat posting a couple of months ago that
he'd talked to Larry and Larry had said he'd do this.
I think the problem is that the RFCs aren't really a list of the
Simon Cozens writes:
okay. i quit.
Well, hm. I'd rather we actually made something positive out of this.
Apologizing would be a good place to start. As many folks have
pointed out, it's hard to find capable intelligent volunteers.
And you just chased one away, a reprehensible act of
Simon Cozens writes:
I did say that I retracted my remarks.
Just speaking for myself, I'd rather see an apology. A retraction
is impersonal, but an apology implies you regret it.
If I appear to be hounding you about it, it's because I'm appalled. I
expect sensitivity and courtesy from
Jarkko Hietaniemi writes:
True, but you can't do any of all that without knowing the platform
accurately (nontrivial and requires core mod or XS). Once that's
done, the rest is just a matter of extending File::Spec
(trivial and pure Perl).
Trivial? *cough* *snigger*
If it was
Chris Nandor writes:
(Indeed, it is quite unfortunate that there are so many modules on CPAN
that have chosen Artistic-only or GPL-only.)
I think it is unfortunate that anyone would think someone else's choice of
license is unfortunate. :)
I can't even remember the topic we're supposed to
Chris Nandor writes:
Seeing as how the RFC process is done, I don't think there is a conclusion
to be had in this forum, at this point.
And I have trouble seeing how watching you and Brad go back and forth
is going to do anything other than raise my blood pressure :-) Perhaps
it's time for
John van V writes:
If perl.org is unacceptable for some reason I can easily create a
mailing list on puny.vm.org
Thanks for the offer, but I don't think we'll need it. I think we're
hampered right now by the fact that we don't know much about what
perl6 is going to look like. Until we get
--- start of forwarded message ---
# CFP in English, followed by French (see below) #
Third North American YAPC: First Call for Participation
Yet Another Society
calls for your participation in
Damian Conway writes:
I once wrote a C++-based regex engine (much simpler than Perl's!)
just like this.
I once brutalized Henry Spencer's engine into telling me when I was
on my way to a match. This was for a UI: I wanted to be able to say
that the input should only match this RE, and if they
I browsed this books on the shelves at Barnes and Noble and remember
mocking it because of the section on "what makes a successful
language" (orthogonal, minimal, clearly defined, ...).
While we won't be using C++, it looks like this might be an
interesting read if you're interested in learning
John Porter writes:
Perl6 ought to support pluggable sort algorithms, just as Perl
now supports pluggable comparison functions.
By "pluggable" you mean that sort() should be overridable?
Nat
Here's a quote from Jim McCarthy's "Dynamics of Software Development"
that seems relevant given the recent fracas on perl6-language-regexp:
Someone once asked me, "What's the hardest thing about software
development?"
I didn't hesitate. "Getting people to think."
Believe it or not, most
I just got off the phone with Larry. He's been laid up for three
weeks with a trip to Japan followed by a virus from Japan. He's on
his feet again, and continuing to work through the RFCs.
He's changing the way he's doing it. Now he's going to try to find
clusters of RFCs on a particular
Andy Dougherty writes:
Now matter how we slice it, it's going to be very hard for the first
person to twist perl6 to parse something that is both complex and very
different from Perl6. And I'm unconvinced that this difficulty ought to
hold up the entire process. It would be quite ironic if
Nicholas Clark writes:
Would it be sane to get the parser to return suitable information on the
source to let a syntax analyser (such as a highlighting editor) know that
character positions 5123 to 5146 are a qq() string (So it can change the
font or the colour or whatever)
I think the
Tom Christiansen writes:
We may have to "agree to disagree".
I shan't be doing that.
I think you should, or at least agree to take it private and report
back to the list once you both come to a decision. Once you've stated
your position twice, there's not really much point in saying it a
Deven T. Corzine writes:
I haven't even SEEN an example where the current behavior is actually
preferable than my proposed behavior, have you? (And I'd expect at least a
FEW, though I suspect there are probably more counterexamples.)
I think the biggest problem with your idea is that it
Simon Cozens writes:
This is not a design document; it's a meta-design document - that is, it
tells us what things we need to design, the things we need to consider
during the design process of the Perl 6 internals.
Thank you!
Why does string Ceval have to screw everything up?
It doesn't.
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
David Grove writes:
3. We seem to be creating a class system. Nate, this is one that I can see
as a must-be, so I'm not going in _that_ direction. But let's still
consider ourselves equal, regardless of rank, ok? Otherwise, perl 6 is a
wash, because it's just as much about community as it is
David Grove writes:
What does it take to be considered of "master" status in a certain area
Basically this: if you're good at doing something and want/need
someone to help with it, then you should be able to ask for an
apprentice.
I'd say not to get too hung up on "master" and "apprentice", as
Bradley M. Kuhn writes:
Java is portable and gives us OO, but it's slow and ugly.
I am probably the biggest proponent of the "use Java to implement Perl"
camp.
Java is only somewhat portable.
One concern that I have about the data structure design thus far (and I
believe I wrote an RFC
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
Nice. An apprentice is an administrative assistant with a career
path. If people are happy to do this, we'd be happy to use them. The
chairs proved weak at reporting on their list's activities (I know I
was) so being able to delegate that to someboy who wanted to do it and
help, would be good.
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
Filipe Brandenburger writes:
I want to contribute to the Perl 6 effort, with ideas
and mainly with coding in C/C++.
Thanks for your interest. Here's the current state of play:
Larry is putting together, at Larry speed :-), an idea of what the
language will look like (all preliminaries show
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
How about we do this to design the architecture and API:
perl6-internals-design is for a team
--- start of forwarded message ---
From: Ken MacLeod [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Orchard/C 0.2.3 preview release available
Date: 15 Nov 2000 09:38:56 -0600
Half of the Perl interface into Orchard/C is complete, you can now
call C functions and return C objects to
John Porter writes:
David Grove wrote:
This branch of the discussion is getting us nowhere fast.
Nat
Dan, Jarkko, etc. How about we try to identify the big units we'll be
working on?
parser
optimizer
bytecode
runtime dispatcher (w/knowledge of dynaloading)
data-types
regex
memory
My idea of development is something like this:
* identify the units/modules
* map relationships
Simon Cozens writes:
http://www.perl.com/pub/2000/11/perl6rfc.html
Agree 100% to every point.
I don't. A constructive critique of the Perl 6 RFC process might be
useful. This onslaught of negativity is not.
The Perl 6 RFC process got people talking about the future, and we
have a
Ken Fox writes:
Nathan Torkington wrote:
Robustness
Portability
Maintainability
Testability
Reusability
Speed
Simplicity
Size
Hey, whoa. Aren't we pre-maturely optimizing the development
process?
Not in deciding priorities. These are factors of architecture
Another angle is to collect a set of mantras, design principles
if you will, something like:
Avoid copying.
Avoid premature optimization.
Be extensible.
Be orthogonal. Orthogonal be.
Be portable.
Be scalable.
Quite right. This is the standard
Simon Cozens writes:
On Thu, Nov 02, 2000 at 02:01:45PM +, David Grove wrote:
Absolutely and double the vulgarity. I can't imagine that the article was
posted at all. Several of us (you guys) have _some_ pull at O'Reilly...
please suggest that the article be pulled.
Of course,
David Grove writes:
I'm not suggesting censorship. I'm questioning O'Reilly's position.
I don't think this has anything to do with O'Reilly--Mark wrote the
article, and it's on perl.com because of that. Our rebuttal will
also go there. O'Reilly hasn't got anything to gain by putting the
Here's the rest of my transcription of Larry's talk. He hasn't had
time to proofread it, so I'm posting it now in the interest of getting
it out. Ask, please add it to your page at dev.perl.org. When you
do, please send mail to pudge and mjd so they can announce the
completed transcription on
1 - 100 of 228 matches
Mail list logo
