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
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
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 bot
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:
> I've just checked this in because the disassembler has come adrift
> from the assembler. I don't know if this is the right fix, because
> it feels like a hack, but it seems to work well enough for me to
> debug some failing tests.
Maybe one of the tests should be to disasse
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
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
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
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.)
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:
http://mail.python.org/pipermail/python-dev/2001-Jun
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 d
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
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
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
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
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
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
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 t
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 want
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 o
--- 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 Pe
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
Ken Fox writes:
> Nathan Torkington wrote:
> > Robustness
> > Portability
> > Maintainability
> > Testability
> > Reusability
> > Speed
> > Simplicity
> > Size
>
> Hey, whoa. Aren't we pre-maturely optimizing the
> 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 standa
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 be
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 optimiza
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
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
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
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 i
Simon Cozens writes:
> > Nice!
> Efficient!
> Practical!
>
> Choose two.
I take this oblique comment to mean that it'd bloat the op-tree too
much?
I was thinking of this over lunch. I want to be able to strip the
instruction sequence of line number, package, etc. information, in the
name of a
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 r
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
David L. Nicol writes:
> This handwringing naysaying is depressing.
Yes, it's depressing to find out there are problems in one's grand
plans. However, I'm very glad that people (including Tom) are
pointing out problems *before* we commit to a course of action.
Nat
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? P
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)
>
Tom Christiansen writes:
> Your coquettish plot to reveal the desperate yearning of your
> nethermost alimentary canal for multiply redundant new egresses is
> neither charming nor
And that's offensive. Please act like a grown-up. Stephen cast the
first stone, but that's no excuse for you to re
Stephen P. Potter writes:
> =head1 TITLE
>
> Perl is Tom's private domain.
That's unproductive.
Nat
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 kno
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 agains
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 m
Ok, time to head back to planet Earth and the story of perl6.
Back to the grindstone!
Nat
(party pooper)
Tom Christiansen writes:
> >There are a number of good reasons to do this from an internals standpoint,
> >enough that I'd like to do it.
>
> Is one allowed to know that number, and those reasons? :-)
No idea what the internals reasons are. Here are my reasons:
* the current socket(), bind(),
Perl6 RFC Librarian writes:
> There has been a proposed new core function C. 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
> C internally to determine what to return i.e; a list or a hash.
This imp
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 thr
Chaim Frenkel writes:
> GB> As Chip says, human intuition is a very bad benchmark.
>
> Does the cache hit/miss depend on the nearness of the code or simply
> on code path? Obviously having the checked version be a wrapper of
> the base op and near it on the same page would be a VM win.
This soun
John Tobey writes:
> I am furthermore *not* suggesting dropping support for non-Unix or
> non-GCC platforms. I am merely saying that that is not where our
> focus should be.
Is there some problem with the current perl5 treatment of gcc that
you're trying to address? If not, then I don't see the
John Tobey writes:
> OK. Ask, cancel that request. Sorry.
In the future, it's best to address your list requests directly
to the working group chair. They'll decide and ask Ask. In fact,
asking Ask could probably be done offline.
Nat
Bradley M. Kuhn writes:
> I wrote http://tmtowtdi.perl.org/rfc/13.pod to propose that we create a
> licensing working group. It needs someone in authority to create the
> working group. Unfortunately, I have yet to find out how the process works
> to create new top-level working groups.
>
> 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 an
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
Jonathan Scott Duff writes:
> > In the future, if you want to submit an RFC mail it to
> > [EMAIL PROTECTED] only.
>
> http://tmtowtdi.perl.org/rfc/meta/ says that you should send your RFCs to
> [EMAIL PROTECTED] rather than [EMAIL PROTECTED]
They go to the same place. However, I meant to onl
I'm about to push the button that will send my private set of RFCs
off to the archive and mail them to perl6-announce. Fingers crossed.
The RFC archive is at http://tmtowtdi.perl.org/rfc/
If I've screwed up your RFC, please let me know.
If I've forgotten your RFC, please send it to [EMAIL PROT
Ask Bjoern Hansen writes:
> http://tmtowtdi.perl.org/rfc/
> (will soon be http://dev.perl.org/rfc/)
I'm working on it right now, so things will appear and disappear.
I'll post when it's stable. Please hold :-)
Nat
Ken Fox writes:
> pipeline stalls, cache misses and a whole bunch of interesting things. One
> of the reasons Perl performed well is that it spent a lot of time in what
> they called native code, i.e. not decoding and dispatching ops.
One thing we could do is look at the op paths produced by perl
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 tha
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 ba
Tim Bunce writes:
> > >The word "pluggable" gives me the willies. I feel like things like
> > >REs should have one blessed implementation and set of capabilities.
>
> The key point here is *one blessed implementation*.
(nat as nat)
When I said that, I was keeping in mind that we might have mul
Dominic Dunlop writes:
> Pluggable regex engines would make supporting (say) core and optional
> regex language features easier.
(Nat qua Nat speaking)
The word "pluggable" gives me the willies. I feel like things like
REs should have one blessed implementation and set of capabilities. I
don'
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
80 matches
Mail list logo
