Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See
also debian's apt-get.
Which brings me to my pet peeve- I think it's time to start doing binary
packaging in CPAN, for those who don't want to bother with compilation.
That has interesting implications for how we deal
On Wed, Jun 05, 2002 at 01:44:07PM -0400, Andy Dougherty wrote:
because lib/Parrot/Makefile.PL contains
WriteMakefile(
'NAME' = 'Parrot::PakFile2',
'VERSION_FROM' = 'PakFile2.pm', # finds $VERSION
and PakFile2.pm says (among other things)
require
Index: core.ops
===
RCS file: /home/perlcvs/parrot/core.ops,v
retrieving revision 1.147
diff -u -r1.147 core.ops
--- core.ops5 Jun 2002 01:56:08 - 1.147
+++ core.ops5 Jun 2002 20:27:41 -
-2731,6 +2731,38
On Wed, Jun 05, 2002 at 12:07:26PM -0700, Sean O'Rourke wrote:
Another thing to toss into the discussion, preferably sooner rather than
later: continuations. From what I can tell, implementing continuations
relies on having an arbitrary graph of stack frames, and garbage
collecting them when
At 4:48 PM +0200 6/5/02, Jerome Vouillon wrote:
My feeling is that the current implementations of stacks are not
adequate:
- the control stacks store too many registers at once;
The control stack doesn't store any registers at all. I presume
you're talking about the four register frame stacks.
This is supposed to have one of those bug ID thingies, isn't it, so that it
doesn't get lost?
All tests successful, 9 subtests skipped.
Files=19, Tests=359, 190 wallclock secs (162.14 cusr + 22.67 csys = 184.81 CPU)
nwc10@colon [parrot5005]$ grep ^PERL Makefile
PERL = /usr/bin/perl
On Wed, Jun 05, 2002 at 12:07:26PM -0700, Sean O'Rourke wrote:
language feature, and that they will rarely be used. I'm sympathetic to
that point of view, having never felt the lack of continuations in my
brief programming life, but if that's the way we want to go, we should at
least be
My feeling is that the current implementations of stacks are not
adequate:
- the control stacks store too many registers at once;
- the generic stack is typed, so it is slow;
- none of these stacks provide any support for register
spilling/reload: there is no opcode to get or set the
n-th
Warning, if this message is too long, please skim to the bottom and read
the part marked IDEA, lest it get lost in the rant.
rant
Why make keyed access of arrays any more complicated than it
needs to be?
The Ix regs are for optimization, so it seems natural
for Ix or ICx simply return the i-th
Index: jakoc
===
RCS file: /cvs/public/parrot/languages/jako/jakoc,v
retrieving revision 1.16
diff -u -u -p -r1.16 jakoc
--- jakoc 28 Jan 2002 20:21:38 - 1.16
+++ jakoc 4 Jun 2002 20:26:45 -
-1895,7 +1895,7 sub do_add
According to README,
You'll also need Perl 5.005 or above, compiled to support
the types you wish to support in Parrot. (Parrot will
make, but you'll be unable to assemble anything.) You can find
what types are support by typing 'perl -V', and examining the
values for
At 04:48 PM 6/5/2002 +0200, Jerome Vouillon wrote:
My feeling is that the current implementations of stacks are not
adequate:
- the control stacks store too many registers at once;
They are register windows, so I think they work fine for that purpose.
It doesn't mean the control stack must be
This clarifies some semantics of the get_string and substr vtables.
Index: docs/pdds/pdd02_vtables.pod
===
RCS file: /home/perlcvs/parrot/docs/pdds/pdd02_vtables.pod,v
retrieving revision 1.10
diff -r1.10 pdd02_vtables.pod
Another thing to toss into the discussion, preferably sooner rather than
later: continuations. From what I can tell, implementing continuations
relies on having an arbitrary graph of stack frames, and garbage
collecting them when they can no longer be reached. Putting continuations
on top of a
I just read through A5 (wow, that's long), and I agree with most of it.
Some of it's really cool. Here's what makes me uneasy: The fact that a
grammar rule auto-captures into a variable of its name.
Is this efficient? If I'm writing a syntax-directed translator, I usually
don't need to
For the record, you will hear no disagreement from me. I recognize that
this is a HARD problem. Nonetheless, I think it's an important one, and
solving it (even imperfectly, by only supporting well-defined platforms)
would be a major coup.
I'd like to take that even further: just
As always, most of it is great. so only the niggles get discussed.
On page 7, the following example is given:
$oldpos = pos $string;
$string =~ m/... ( .pos == $oldpos ) .../;
This implies that match position is associated with the string. This worries
me. If 2 threads are matching on
At 4:52 PM -0700 6/5/02, David Whipp wrote:
As always, most of it is great. so only the niggles get discussed.
On page 7, the following example is given:
$oldpos = pos $string;
$string =~ m/... ( .pos == $oldpos ) .../;
This implies that match position is associated with the string.
On Tue, Jun 04, 2002 at 01:11:58PM -0700, David Wheeler wrote:
On 6/4/02 12:59 PM, Steve Simmons [EMAIL PROTECTED] claimed:
Actually, for 6PAN I think they should have to pass. And maybe we
need a bug submission setup, and status checks, and . . . OK, OK, I'll
stop now. They're nice
[For those of you coming in late, here's the relevent thread from
perl6-language
http:[EMAIL PROTECTED]/msg10024.html
]
Some of you may or may not be aware that I hate waiting, especially when
it's about good ideas for Perl 6. Some of you may also be aware of the
CPANPLUS project to
On Tue, Jun 04, 2002 at 04:15:02PM -0400, John Siracusa wrote in
response to me:
Frankly, I'd argue that nothing in 6PAN ought to be in alpha/beta state.
. . .
Nah, I think it's useful to be able to upload unstable versions to 6PAN to
get the widest possible audience of testers. It's a
On 6/5/02 2:59 PM, Steve Simmons wrote:
Sticking just to the disk-intensive issue for a moment --
[...]
With the new one, we seem to have agreed that `most recent' will be
used, not `first found'. That means that every tree must be probed,
and probed with globs or sub-searches to match the
hmm.
Just read (skimmed) apocalypse 5, had one concern - it looks like we are on a
serious collision course with parsing the various *mls.
before:
m#a href=aimg src=sss!banner..etc#
after
m#\a\ href=a\\img\ src=sss\\!banner\#
Also, the space being backslashed sort of bugs me. Surely there
At 2:59 PM -0400 6/5/02, Steve Simmons wrote:
My seat of the pants number say our current tools (which use DBI to
access databases) spend about as 10% of their CPU and wall clock time
in compilation. This is measured by deliberately running the tools
with an error (bad switch) vs running it
At 12:55 AM -0400 6/5/02, Josh Wilmes wrote:
Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See
also debian's apt-get.
Which brings me to my pet peeve- I think it's time to start doing binary
packaging in CPAN, for those who don't want to bother with compilation.
That has
[EMAIL PROTECTED]:
# Just read (skimmed) apocalypse 5, had one concern - it looks
# like we are on a serious collision course with parsing the
# various *mls.
#
# before:
#
# m#a href=aimg src=sss!banner..etc#
#
# after
#
# m#\a\ href=a\\img\ src=sss\\!banner\#
That's intentional. What
--
On Wed, 5 Jun 2002 13:21:39
Brent Dax wrote:
[EMAIL PROTECTED]:
# Just read (skimmed) apocalypse 5, had one concern - it looks
# like we are on a serious collision course with parsing the
# various *mls.
#
# before:
#
# m#a href=aimg src=sss!banner..etc#
#
# after
#
# m#\a\
On Wed, 5 Jun 2002 [EMAIL PROTECTED] wrote:
Just read (skimmed) apocalypse 5, had one concern - it looks like we are on a
serious collision course with parsing the various *mls.
before:
m#a href=aimg src=sss!banner..etc#
after
m#\a\ href=a\\img\ src=sss\\!banner\#
Also, the
On Wed, Jun 05, 2002 at 12:55:36AM -0400, Josh Wilmes wrote:
Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See
also debian's apt-get.
Which brings me to my pet peeve- I think it's time to start doing binary
packaging in CPAN, for those who don't want to bother
You have Ino idea how often that would have been useful. It's a great
exception safety mechanism... like C++'s resource aquisition is
initialization thingy, but without having to write a class for every
variable.
On Wed, 5 Jun 2002, David Whipp wrote:
Page 13 tells use about Clet decls.
A few coding style errors have crept in lately. The attached patch should
fix the majority of them. I didn't touch the MANIFEST errors mentioned,
though.
--Josh
$ make check_source | grep ERROR | grep -v '^languages/'
byteorder.c:35 (ERROR) Improper indenting for # if INTVAL_SIZE == 4
First, a slight clarification: if I say:
m:w/ %foo := [ (\w+) = (\w+) [ , (\w+) ]* ] /
does this give me a hash of arrays? (i.e. is the rhs of a hash processed as
a scalar context)
When I look at this, I see a common pattern: the join/split concept. It
feels like there should be a standard
I'd like to be able to use REs to generate lists of strings. For
example, it might be nice to create a loop such as:
for $i (sort(p:p5|[0-9A-F]{2}|)) { # p operator for production?
and have $i walk from '00' through 'FF'. Or whatever.
I created a specialized macro-preprocessor several
Luke Palmer wrote:
I just read through A5 (wow, that's long), and I agree with most of it.
Some of it's really cool. Here's what makes me uneasy: The fact that a
grammar rule auto-captures into a variable of its name.
Is this efficient? If I'm writing a syntax-directed translator, I
34 matches
Mail list logo
