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. I
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 Nat
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 of
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 sh
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
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
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
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)
In
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 definiti
Andy Dougherty writes:
> > #include "config.h"
> > rather than
> > #include
Isn't the correct solution to this problem to say
#include
That is, include the subdirectory prefix in all #includes. You -I the
directory containing parrot/, and that avoids randomly located
config.h files from b
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 s
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 ab
I'm happy to say that, in preparation for the release of the first
piece of Parrot code, Simon Cozens has stepped forward to hold the
source pumpkin.
Simon's responsible for the contents of the internal and external
source distribution. He'll update the CVS repository with patches
submitted by t
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 fa
I'm happy to say that, in preparation for the release of the first
piece of Parrot code, Simon Cozens has stepped forward to hold the
source pumpkin.
Simon's responsible for the contents of the internal and external
source distribution. He'll update the CVS repository with patches
submitted by t
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 w
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 bui
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.)
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 un
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
>From newsforge:
nile writes, "Today, dLoo released the complete architecture of an
extensible peer-to-peer programming language. Unlike traditional languages,
this language is defined on the Internet. Its syntax and semantics can be
extended by posting additional pieces of the language. As de
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.
Wo
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:
http://mail.python.org/pipermail/python-dev/2001-Jun
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
Dan Sugalski writes:
> Okay--Parrot Object Code. (If I was feeling cleverer at the moment, I'd
> come up with a name that has a snappier acronym. Alas I'm not... :)
p-code. The p stands for Parrot :-)
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 ex
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 d
Daniel S. Wilkerson writes:
> Therefore, if it isn't a back-end and it isn't a front-end, what is it?!
> Perl6 seems to be a "nothing sandwich". Not that this is bad, Zen is this
> way.
Simon's done a good job of explaining this, but I'll try too.
You're right, we're designing many things. Lar
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
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:
> | 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.
>
> Th
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 7
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
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 t
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 so
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 Rig
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
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 exaggera
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 c
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 owners
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";
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 eleg
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, quit
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 Cook
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.
T
Jarkko Hietaniemi writes:
> Yea, verily. I have more than once stared for more seconds than I
> care to admit being completely baffled at why my C compiler doesn't
> appreciate
>
> print "foo = $foo\n";
If I had a dollar for every time I've put $ on C variables, I'd have
enough to buy Wil
Chaim Frenkel writes:
> Those are all major typo inducing changes.
>
> You'll need alternative micro-code loads for your fingers, when
> switching between clients and when editing scripts that pre-date Perl
> 6.
So we can't change Perl, because changes have to be learned?
So now the changes are
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'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(
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 Cookbo
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
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
Edward Peschko writes:
> I think its really time to have a vote on this, I think that all
> that has been said about this issue has been said...
It's definitely not time for a vote. Larry'll take what's been said
by both sides and make a decision, just one of a zillion different
decisions that h
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 una
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 philosoph
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 e
Better late than never! Chip's provided the slides for last year's
Topaz talk at TPC5.
Nat
(Ask, could you put them on dev.perl.org? Thanks!)
topaz-v2.pdf
Glenn Linderman wrote:
> New RFC ideas?
Please, dear God, no. :-)
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 tran
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
Not a comment at all on it? Was I accidentally unsubscribed to
perl6-language?
*tap* *tap* is this thing on?
Nat
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, looking
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, looking
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 a
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 l
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
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
t
David L. Nicol writes:
> Is there a budget? Apprenticeship makes all kinds of sense when
> there is actually a money flow into the guild; the carrot of eventual
> credentials is too weak for me and many lesser poetasters.
>
> Could O'Reilly and Microsoft divert some funds to actually paying pe
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 everyo
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 de
Dan Sugalski writes:
> I'm fine with silly things, it's dangerous things I don't much care for.
> Which isn't to say I'm against loading remote program code, I just think
> this isn't the way to do it.
use autoload { Bar => 'uddi://blah/some/Bar' };
(here I take a big swill from the web servic
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 w
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 of
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 suppo
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 m
--- 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
YA
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 the
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 h
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
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 topic
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 peopl
Another point re: the parsing process. I think it should be possible
for any of the steps or extensions to be defined as C code or as Perl
code. We're already shooting to have C subs isomorphic with Perl subs
so this shouldn't be a problem, just something to keep in mind.
Nat
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 pr
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
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
Jarkko Hietaniemi writes:
> Couldn't the be an option (a modifier) to do this? Then if someone
> asks to wait until all the electrons spin down, so be it...
Only if we can get MjD's wordy regex modifiers:
/a.*?b/{heatdeath}
Nat :-)
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 re
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 C have to screw everything up?
It doesn't.
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 questi
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 a
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
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 web
1 - 100 of 309 matches
Mail list logo
