Nicholas Clark wrote:
... I'd find it a lost easier to redo the
trivial cut and past by copying what you did with your patch in front of me,
Please don't forget the $str_re in _annotate_contents, it's still/again
broken for 5.005.
Nicholas Clark
TIA,
leo
What Dan says. If you're interested, there are at least three options:
- a fairly well-developed compiler for perl 5 regexes (languages/regex).
- a less well-developed compiler built into the prototype Perl 6 compiler
(languages/perl6)
- a set of regex ops in rx.ops, suitable for starting
Hey,
I re-added the GC_DEBUG define today, and weeded out a bunch of issues.
For those who don't remember, GC_DEBUG (currently in parrot.h) causes
various limits and settings and logic to be setup such that GC bugs occur
relatively soon after the offending code. It allocates one header at
a
[EMAIL PROTECTED] (Dan Sugalski) writes:
Well, we've got a pretty good description of perl 6's regexes courtesy
of A5. Anyone care to take a shot at either modifying the regex
compiler to deal with them, or writing a perl 6 regex compiler?
I did *say* at YAPC that I wrote one before
# New Ticket Created by jryan
# Please include the string: [perl #16144]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=16144
Small speed patch for assemble.pl here...
Benchmarks that I've done show that the new
On Mon, Aug 12, 2002 at 01:56:49PM +, jryan wrote:
# New Ticket Created by jryan
# Please include the string: [perl #16144]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=16144
Small speed patch for
[EMAIL PROTECTED] (Nicholas Clark) writes:
Well, I find assemble.pl too slow, so I like speed.
Good grief. Maybe someone should implement it in XS; then as well as being
fast, we'd avoid duplicating code from the core, and we'd have the basis of
a bytecode emission library that things compiling
On Fri, Aug 09, 2002 at 03:09:29PM -0400, Chris Dutton wrote:
This one actually came to me just the other night. Would it be possible
in Perl 6 to create anonymous classes? Something like:
my $foo_class = class {
method new {
# yada yada yada
}
}
my
Another one...
class Foo is Bar;
method a {
setup();
}
1;
# EOF
(Is the 1 still required? I think I heard Damian say it was going away.)
The question is, is this valid, if Bar defines a sub/static method
'setup'?
Is my instict right that 'sub' in a class is a 'class/static method' in
the
On Mon, Aug 12, 2002 at 04:01:13PM +0100, Simon Cozens wrote:
[EMAIL PROTECTED] (Nicholas Clark) writes:
Well, I find assemble.pl too slow, so I like speed.
Good grief. Maybe someone should implement it in XS; then as well as being
fast, we'd avoid duplicating code from the core, and we'd
Mike,
I tried to have a look at the lexicals and subs issues but I am finding
that with the GC_DEBUG flag set to 1, I *always* get a segmentation
fault, even for simple pasm files like :
set I0, 12
end
or just:
end
Is there something I am doing wrong? I did a fresh checkout about an
[EMAIL PROTECTED] wrote:
Question: if the compiler *doesn't* raise an error, what happens? How would
the following code be interpreted, even insanely? An endless loop perhaps?
while something() = $_ { ... }
Changing the closure to use »=« instead of »-« yields with current P6C:
Can't
On Sat, Aug 10, 2002 at 07:30:19PM -0400, Chris Dutton wrote:
The only problem I could see, and I wanted to wait for at least one
other opinion before mentioning this, is rewriting the above as:
my $foo_class $foo_obj = $foo_class.new;
I'm not exactly sure what you're trying to do with
On Mon, 12 Aug 2002, Simon Cozens wrote:
It's my opinion that it went from there back to pure-Perl because people here
are happier handling pure Perl than XS. Jeff may have to correct me on that.
I moved it back to pure-Perl because there were something like half of the
tinderboxes failing to
[EMAIL PROTECTED] (Daniel Grunblatt) writes:
I moved it back to pure-Perl because there were something like half of the
tinderboxes failing to assemble anything.
Ah, right. Yeah, the tinderboxes are good slaves but really bad masters.
Here's a more interesting question: which parts of Parrot
Steve Find said on August 09, 2002 6:24 PM:
Anyone happen to know where pushdown automata fit in this list? Can
they handle context-sensitive, just context-free, or some other
subset?
Mark Reed said on August 09, 2002 7:60 PM:
To recognize a context-sensitive language I think you need a Turing
On 12 Aug 2002, Simon Cozens wrote:
Here's a more interesting question: which parts of Parrot are enshrined,
and which are prototypes, ready to be thrown away? For instance, I'd
say much of languages/* is all proof-of-concept prototype stuff; imcc
may not be. The assembler I'd call a
On 12 Aug 2002, Simon Cozens wrote:
[EMAIL PROTECTED] (Daniel Grunblatt) writes:
I moved it back to pure-Perl because there were something like half of the
tinderboxes failing to assemble anything.
Ah, right. Yeah, the tinderboxes are good slaves but really bad masters.
True, but I was
[EMAIL PROTECTED] (Daniel Grunblatt) writes:
The assembler is a bit outdated, it shouldn't be too difficult to bring it
up to date, I just don't have enough time latetly. But it did work fine
and is easy to extend it. Why do you think it should be thrown away?
It's in Perl?
--
MISTAKES:
Is indexing a PerlHash by an integer something that is supposed
to be valid? Likewise for indexing a PerlArray by a string?
Currently both of these are allowed, but as it stands my keyed
access patch breaks this. Obviously indexing either by a PerlScalar
will still work as the PerlScalar PMC
jryan (via RT) [EMAIL PROTECTED] writes:
--- assemble_old.pl 2002-08-04 21:00:02.0 -0400
+++ assemble.pl 2002-08-12 00:03:56.0 -0400
@@ -263,8 +263,8 @@ sub preprocess {
}
elsif(/^\.constant \s+
($label_re) \s+
-
Dan, some time ago you mentioned that you were preparing a position doc
on issues raised in the 'maybe-PATCH: sub/continuation/dlsym/coroutine
clean-up' thread. Are you nearly ready with that doc? Does this patch
(i.e. a scratchpad pmc) fit into what you have in mind?
Sorry to be harassing you
On Mon, Aug 12, 2002 at 03:56:27AM -0400, Mike Lambert wrote:
- hashes (these were recently rewritten to use indices, a step forward,
but they aren't 100% clean yet)
I know of at least one remaining problem with these, but...
Anyone more well-versed in these departments than I care to take a
On Monday, August 12, 2002, at 01:27 PM, Allison Randal wrote:
On Sat, Aug 10, 2002 at 07:30:19PM -0400, Chris Dutton wrote:
The only problem I could see, and I wanted to wait for at least one
other opinion before mentioning this, is rewriting the above as:
my $foo_class $foo_obj =
On Mon, 12 Aug 2002, Steve Fink wrote:
farther yet. Oh, and I do have your recent patch to set
interpreter-lo_var_ptr early.
How early is early? It looks like setting lo_var_ptr in Parrot_runcode
instead of runops should be necessary/sufficient. If not, does
initializing it to the address of
On 12 Aug 2002, Simon Cozens wrote:
[EMAIL PROTECTED] (Daniel Grunblatt) writes:
The assembler is a bit outdated, it shouldn't be too difficult to bring it
up to date, I just don't have enough time latetly. But it did work fine
and is easy to extend it. Why do you think it should be
[EMAIL PROTECTED] (Daniel Grunblatt) writes:
Oh, no, I was talking about languages/parrot_compiler/. Sorry.
Oh, I hadn't seen that. I can't work out what it is; it seems to be a
device for generating Couldn't find operator errors. Is there any,
dare I say it, documentation for it?
--
Going to
On 12 Aug 2002, Simon Cozens wrote:
[EMAIL PROTECTED] (Daniel Grunblatt) writes:
Oh, no, I was talking about languages/parrot_compiler/. Sorry.
Oh, I hadn't seen that. I can't work out what it is; it seems to be a
device for generating Couldn't find operator errors. Is there any,
dare I
On Mon, Aug 12, 2002 at 03:56:27AM -0400, Mike Lambert wrote:
Here is a workaround for one hash related GC bug.
--
Jason
Index: hash.c
===
RCS file: /cvs/public/parrot/hash.c,v
retrieving revision 1.19
diff -u -r1.19 hash.c
---
Hi there,
I'm rather new with Parrot, and I wanted to play with it a little. I'm
playing with parrot 0.0.7, I did *not* fetch the last CVS version.
I have a problem when I'm trying to read a file.
I looked at parrot_assembly.pod and saw:
open px, sy
Open the file Y on
On Mon, Aug 12, 2002 at 12:34:28PM -0700, Sean O'Rourke wrote:
On Mon, 12 Aug 2002, Steve Fink wrote:
farther yet. Oh, and I do have your recent patch to set
interpreter-lo_var_ptr early.
How early is early? It looks like setting lo_var_ptr in Parrot_runcode
instead of runops should be
On Mon, Aug 12, 2002 at 04:04:40PM -0400, Jason Gloudon wrote:
On Mon, Aug 12, 2002 at 03:56:27AM -0400, Mike Lambert wrote:
Here is a workaround for one hash related GC bug.
Nice catch. That, in combination with the patch I just posted, fixes
all but 4 of the failures for me.
Anyone more well-versed in these departments than I care to take a look at
the potential problems? Just change GC_DEBUG in parrot.h, and you can be
on your way. :)
I can't get to it because parrot doesn't survive past initialization
for me. When it creates the Array PMC for userargv, it
On Mon, 12 Aug 2002, Jerome Quelin wrote:
Thus, I thought this one was the one I wanted. So:
LOAD:
read S0, 256
chopn S0, 1 # trailing newline
open I10, S0, r
eq I10, 0, ERR_IO
set S1, # Accumulator
LOAD_READ:
read S1, I10, 256
On Mon, Aug 12, 2002 at 04:23:14PM -0400, Mike Lambert wrote:
Weird. I had to move the lo_var_ptr initialization code to runcode instead
of runops, in order to avoid collecting the ARGV pmc. The new code looks
like:
void *dummy_ptr;
PMC *userargv;
You sure? That's what I thought at first
On Mon, Aug 12, 2002 at 04:04:40PM -0400, Jason Gloudon wrote:
On Mon, Aug 12, 2002 at 03:56:27AM -0400, Mike Lambert wrote:
Here is a workaround for one hash related GC bug.
^^
+ volatile Buffer *for_gc;
/* hash-buffer.flags |= BUFFER_report_FLAG; */
I committed the following patch. assemble.pl now doesn't take heat-death-of-
the-universe to run on 5.005_03.
Nicholas Clark
--
Even better than the real thing:http://nms-cgi.sourceforge.net/
--- assemble.pl.origSun Aug 11 09:45:10 2002
+++ assemble.pl Mon Aug 12 21:36:50 2002
On Mon, Aug 12, 2002 at 09:48:56PM +0100, Nicholas Clark wrote:
This is a case of a temporary allocated value being only in a CPU register?
Not in this case. The link to the hash structure from the PMC is not
established, which prevents the custom mark routine in the PMC from identifying
the
Here is another way of resolving this, as I mentioned in the last message.
Having new_hash() initialize the PMC's data pointer so that the hash is
immediately visible to the collector.
--
Jason
Index: parrot/hash.c
===
RCS file:
The last patch had an issue I didn't see on the test I was working against.
mark_hash() assumes the buffer_pool is always initialized, but with the patch
this is no longer the case.
--
Jason
Index: parrot/hash.c
===
RCS file:
Here is one additional check...
-Jason (The other one)
On Mon, 2002-08-12 at 19:23, Jason Gloudon wrote:
The last patch had an issue I didn't see on the test I was working against.
mark_hash() assumes the buffer_pool is always initialized, but with the patch
this is no longer the case.
--
At 01:10 PM 8/12/2002 -0600, Jonathan Sillito wrote:
1) The Parrot_Sub struct in sub.h has its own user_stack and
control_stack. Why is this necessary?
Probably an artifact of my failed experiments. :)
Originally Dan said subs would need their own stacks. Either way,
they should be part of
At 10:04 PM 8/12/2002 +0200, Jerome Quelin wrote:
I looked at parrot_assembly.pod and saw:
open px, sy
Open the file Y on filehandle X
read px, py, pz
Issue a read on the filehandle in y, and put the
result in PMC X. PMC Z is the sync object.
At 06:56 PM 8/12/2002 +0100, Simon Cozens wrote:
Here's a more interesting question: which parts of Parrot are enshrined,
and which are prototypes, ready to be thrown away? For instance, I'd
say much of languages/* is all proof-of-concept prototype stuff; imcc
may not be. The assembler I'd call a
On Mon, 12 Aug 2002, Melvin Smith wrote:
4) Parrot_Coroutine's 'init' is not longer used and can go away, I guess
I could remove it in a future patch ... ok so that's not a question
I wish this wouldn't go away. I think passing the constructor argument
for any PMC is a good optimization. How
At 08:14 PM 8/12/2002 -0700, Sean O'Rourke wrote:
On Mon, 12 Aug 2002, Melvin Smith wrote:
4) Parrot_Coroutine's 'init' is not longer used and can go away, I guess
I could remove it in a future patch ... ok so that's not a question
I wish this wouldn't go away. I think passing the
Sorry, this version now includes the missing modifications to hash.h.
-Jason
On Mon, 2002-08-12 at 21:02, Jason Greene wrote:
Here is one additional check...
-Jason (The other one)
On Mon, 2002-08-12 at 19:23, Jason Gloudon wrote:
The last patch had an issue I didn't see on the test
One more safety check (fixes another crash bug). Hopefully this is the
last patch patch.
-Jason
On Mon, 2002-08-12 at 22:38, Jason Greene wrote:
Sorry, this version now includes the missing modifications to hash.h.
-Jason
On Mon, 2002-08-12 at 21:02, Jason Greene wrote:
Here is
Along with a conversion tool that should help speed up the overall
process of converting a BNF grammar to Parse::RecDescent format. If you
want to use the tool, please note that the combined Python grammar
available on http://www.python.org/doc/current/ref/grammar.txt has a few
bugs that will
At 6:56 PM +0100 8/12/02, Simon Cozens wrote:
[EMAIL PROTECTED] (Daniel Grunblatt) writes:
I moved it back to pure-Perl because there were something like half of the
tinderboxes failing to assemble anything.
Ah, right. Yeah, the tinderboxes are good slaves but really bad masters.
Here's a
At 7:51 PM +0100 8/12/02, Tom Hughes wrote:
Is indexing a PerlHash by an integer something that is supposed
to be valid? Likewise for indexing a PerlArray by a string?
Currently both of these are allowed, but as it stands my keyed
access patch breaks this. Obviously indexing either by a
51 matches
Mail list logo
