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
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
Dan Sugalski writes:
* push_c_i_i_i_v has to be a varop (see my recent posting with
print_s_v.
Nope. No vararg ops! :)
It might help forestall future flamewars if you explained why.
We'll be introspective, but probably differently. We at least need
to do things in ways both perl
Dan Sugalski writes:
Speaking from on high here, bytecode is strictly identifiable as to its
characteristics. It will be as portable as a platform implementer wants it
to be. The only 'required' types of bytecode that need to be read are
32-bit integer (both big and little endian) with
Here's what I use ...
#!/usr/bin/perl -w
# parrot - compile and run parrot assembly language
$srcfile = shift or die usage: $0 PASMFILE\n;
($pbcfile = $srcfile) =~ s{\.pasm$}{.pbc}i;
system(perl assemble.pl $srcfile $pbcfile ./test_prog $pbcfile);
--
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
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
Dan Sugalski writes:
Lines 249 to 261 seem to duplicate 204 to 216.
D'oh! Thanks, fixed.
Oh man, good luck building a unit testing system for the docs :-)
Nat
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:
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
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
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
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
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:
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
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
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
--- 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
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
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
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
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
Simon Cozens writes:
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.
Excellent. Anyone else who wants to be part of the initial design
team, now is the time to speak up. If you have perl5 internals
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
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 van V writes:
FTC = FCC (= FDA = DEA = FBI = DOJ = DOA = CIA = Ma_FIA = ...)
This is so far away from being of use to the perl6-internals list,
I'm surprised to see it here.
Let's get back to design. Dan?
Nat
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
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
Steve Fink writes:
I suspect perl can do a much better job than it does now, but if you
make it a requirement, you prevent many optimizations. I think the RFC
should be very specific about when it applies and when it gets out of
the way.
I can't be more specific unless I know the
Dan Sugalski writes:
I wouldn't worry about this too much. If it's all keyed off an opcode of
some sort ("Current line info"), we could easily just strip those opcodes
out. They won't take up that much space relative to the rest of the
program, but I can see some sort of runtime overhead if
Dan Sugalski writes:
It's possible, for example, for a tied/overloaded/really-darned-strange
variable to look true but still be false. If you do:
$foo = $bar || $baz;
and both $bar and $baz are objects, the 'naive' way is to make $foo be
$bar. But it's distinctly possible that $bar
Dan Sugalski writes:
No, that's the point. But if someone explicitly strips out the debugging
info then, well, you don't get much help in debugging, now do you? :)
I buy that. It'd be nice to be able to be one step better than C,
though, and given *something* that you can use to go back to
Ken Fox writes:
The dogfood theory? One of the design goals for Perl is to make text
munging easy. Parsing falls into that category and therefore we should
use it, i.e. eat our own dogfood.
How about this. During design, we try to make the parser a module
with an interface designed so that
Tom Christiansen writes:
We've been down this route. It doesn't help the way you think it does.
These are merely wafer-thin wrappers about syscalls. It's Perl's
complete infrastructure support system you're seeing, and that you
will not reduce.
Actually, if we can split compiler from
Jarkko Hietaniemi writes:
I'm not too worried about getting the vtbl right at the first because
it will be pretty obvious how it should go once the code starts to form.
Some planning isn't that painful :-)
Yes. Especially given that vtables are an unbenchmarked change. It'd
be good to
Dan Sugalski writes:
If the vtable stuff goes into the core perl engine (and it probably will,
barring performance issues), then what could happen in the
I have a lot of questions. Please point me to the appropriate place
if they are answered elsewhere.
vtables are tables of C functions?
Larry Wall writes:
Tom Christiansen writes:
: More of this nonsense, eh?
Please don't use fighting words in here.
On the subject of fighting words, I owe everyone an apology for my
language on the subject of Perl being the only thing that can parse
Perl. I've been banging my head against
David L. Nicol writes:
Any subroutine declaration, for instance
sub Cmp:infix($$){
return uc($_[0]) cmp uc($_[1])
};
implicitly sets up a "catch unknown-keyword:Cmp" routine; that is,
it installs the name of the function in a place the clarifier will know
to
Stephen P. Potter writes:
=head1 TITLE
Perl is Tom's private domain.
That's unproductive.
Nat
Tom Christiansen writes:
further abuse as the next bandit decides to chew on you. As nobody
else said mum about that scat, I took care of it myself.
90 minutes passed on a Friday night. That doesn't mean it wasn't
going to be dealt with.
(hint: grown-ups would apologise at this point)
I'm
Dan Sugalski writes:
One of the current plans is for the parser to have access to a list of
functions that trigger autoloading modules.
Isn't dynamic loading really slow? If they're going to incur the
penalty of dynamic loading, you might as make them request that
slowdown by 'use'ing the
Perl6 RFC Librarian writes:
There has been a proposed new core function Cwant(). this seems
to be generally regarded as a good thing. Fine. If it is implemented
we should use it. Offending functions (See RFC 37) should use
Cwant() internally to determine what to return i.e; a list or a hash.
It seems to me that a perl5 program exists as several things:
- pure source code (ASCII or Unicode)
- a stream of tokens from the parser
- a munged stream of tokens from the parser (e.g., use Foo has
become BEGIN { require Foo; Foo-import })
- an unthreaded and unoptimized optree
- a
Steve Simmons writes:
This idea is both important and more general. If we go thru a huge
discussion of, say, multi-line comments and decide *not* to do it,
we don't want to have the whole thing repeated with perl 6.1, 7.0,
etc, etc. When something reaches RFC stage but is rejected, part of
Steve Fink writes:
What about updating RFCs? Should I increment the version number and send
each new revision to perl-rfc? Do I need to be careful about the RFC
number when submitting updates?
Yes and yes.
Also, I assumed the intention of the RFCs was to stimulate focused
discussion and to
Bryan C. Warnock writes:
The librarian bounced, so sending this internals way.
Sorry about that bounce. It's set up now. I'm still setting
up the repository (should have done that *before* publishing the RFC
format, I guess :-). Optimistic ETA: tomorrow. If it's not up by
then, I'll fall
Graham Barr writes:
Why would the fuzzy regex not be done this way ?
I have some small objections:
I think one regexp syntax with potentially wildly variable
interpretations is a dangerous thing. If we want fuzzy
regexp matching, either put it into the core's re engine
or make it a module
I respectfully request that one list be picked for this topic and
discussion confined to that one list even if it should occasionally
spill into the other bailiwick. Or perhaps it's a candidate for a new
working group.
If all messages are CC:ed to all lists, then simply have p5p reborn
(and the
57 matches
Mail list logo
