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 wi
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)
>
>
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,3
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
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
nwc10@colon
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 e
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 ele
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.
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 elem
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 ivtyp
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
175c175,1
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 captu
> 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 suppor
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
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
[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 reimpleme
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'
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
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#..etc#
after
m#\\\#
Also, the space being backslashed sort of bugs me. Surely there is going to be
a 'non-x' modifier? And perhaps a modifier t
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 c
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.
>
>Tha
[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#..etc#
#
# after
#
# m#\\\#
That's intentional. What will that regex do with this?
That's interpreted
--
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#..etc#
>#
># after
>#
># m#\\\#
>
>That's intentiona
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#..etc#
>
> after
>
> m#\\\#
>
> Also, the space being backslashed sort of bugs me. Surely th
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 bothe
Page 13 tells use about C decls. But it also says that the topic must
be a regex. Whilst it explains that this isn't really a problem, I'm not
sure that it justifies it. So perhaps someone can clarify why this
(hypothetical) code in not a reasonable generalization:
our $foo = 0;
sub do_somethin
You have I 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 C decls. But it als
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" (s
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 a
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 u
> Page 13 tells use about C decls. But it also says that the topic must
> be a regex. Whilst it explains that this isn't really a problem, I'm not
> sure that it justifies it. So perhaps someone can clarify why this
> (hypothetical) code in not a reasonable generalization:
Because Perl code doesn
You have I 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.
Have you already forgotten KEEP and UNDO (that we introduced in A4/E4):
our $
David Whipp wrote:
>
> 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)
That's an error. The grouping bound to a hypothetical hash has to have
either
Rich Morin wrote:
> 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.
You mean:
Robert Spier and I moved cvs.perl.org to a new server tonight.
Everything should work as usual, except maybe a bit faster. If
anything is odd, not working as it used to, working better, not
working at all, please send us mail at cvs at perl.org.
The new server is faster, spiffier and better con
40 matches
Mail list logo
