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 yo
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 time,
[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 breakfa
# New Ticket Created by jryan
# Please include the string: [perl #16144]
# in the subject line of all future correspondence about this issue.
# 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 expressi
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.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=16144 >
>
>
> Small speed patch for ass
From: Larry Wall [EMAIL PROTECTED]
> (Had an interesting typo there. I put => insteaqd of ->.
> I wonder how much trouble that sort of thing is gonna cause.
> Maybe pairs can be disallowed or warned about where a pointy
> sub might be expected.)
I foresee a lot of problems. To my Perl5 eyes,
[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
> }
> }
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
Nicholas Clark:
> Specifically:
> Why are we back to a single file assembler in pure perl?
> Why is it being proposed to be split up again?
> Are we going round in circles, or do the changes represent a spiral?
My design decisions for what *I* did, in rewriting the original assembler:
1) De-b
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
hou
[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:
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 wi
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 t
[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 Turin
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 prot
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
[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 will
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 a
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
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 addres
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
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,
>
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
--- h
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 filehan
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
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 usera
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
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 f
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
@@ -4
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 b
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: /cvs
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 Parr
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 obje
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 cal
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 optimizatio
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 t
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
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:
> > He
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 caus
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.
>
>He
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 Perl
At 9:48 PM +0100 8/12/02, Nicholas Clark wrote:
>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;
>>
At 11:10 PM -0400 8/12/02, Melvin Smith wrote:
>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 proto
At 11:13 PM -0400 8/12/02, Clinton A. Pierce wrote:
>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 p
Okay, I'm going to be away from email probably until the end of the
week. I may end up dumping a lot of docs at that point--while I'll be
away from mail I'll still have power and, well, have laptop will
twiddle. :)
Please don't let good patches languish while I'm gone, and if someone
could th
At 1:10 PM -0600 8/12/02, Jonathan Sillito wrote:
>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 int
[EMAIL PROTECTED] (Jeff) writes:
> Note that translation from BNF to Parse::RecDescent is -not- the final
> aim of the transformation tool, but this should match most common
> BNF-like grammars, and may even handle things like the official Ruby
> EBNF grammar.
Schuyler Erle wrote one of these age
58 matches
Mail list logo
