The attached patch fixes a bunch of bugs. They are:
>From before, rolled into this patch:
+ Creates a new flag, immortal, which is intended for GC use only, so it
shouldn't be set in the init() function. This is used to prevent the GC
from dod'ing the object.
+ PerlString now stores the string po
> Wow, you've got a couple of major patches floating around that are
> getting ignored. I don't feel so bad now. :-)
Yeah, that's why I'm combining all the GC patches into one big patch, in
the hopes it'll make it more appliable.
The only things I've sent out and am awaiting feedback for are the
I've been using clintp's pasm test script for much of my testing, which is
supposed to be an infix expression evaluator. I've been stress-testing
parrot and finding bugs by putting increasingly-large expressions into the
pasm file for it to evaluate.
Attached is a .pasm file which causes some str
At 3:28 AM -0500 3/29/02, Michel J Lambert wrote:
> > Wow, you've got a couple of major patches floating around that are
>> getting ignored. I don't feel so bad now. :-)
>
>Yeah, that's why I'm combining all the GC patches into one big patch, in
>the hopes it'll make it more appliable.
I apolog
I believe this is correct...
$ diff -u parrot/docs/parrot.pod parrot-coke/docs/parrot.pod
--- parrot/docs/parrot.pod Wed Mar 13 13:02:25 2002
+++ parrot-coke/docs/parrot.pod Thu Mar 28 23:27:17 2002
@@ -87,8 +87,8 @@
Parrot is developed and maintained by the members of the
C<[EMAIL PROTE
Applied, with slight tweaking to make sure we keep simon in there :)
--Josh
At 23:29 on 03/28/2002 EST, Will Coleda <[EMAIL PROTECTED]> wrote:
> --B99DD6E33AE5206FD2C4A8AF
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> I believe this is correct.
Dan Sugalski writes:
: At 12:59 PM + 3/28/02, Piers Cawley wrote:
: >Wouldn't it be nice if you could do:
: >
: >class Foo {
: > ...
: >
: > &{intern('{}')} := method ($self: $key) is lvalue {
: > ...
: > }
: >}
: >
: >So, later, you could do:
: >
: >$obj = Foo.new;
: >
: >
"Michel J Lambert" <[EMAIL PROTECTED]> wrote:
> Attached is a .pasm file which causes some string data to be written into
> the middle of the string_pool->pool_buffer list of entries, such that when
> it tries to dereference foo in new_pmc_header, it's pointing to garbage
> memory. 0x20202020 for
At 03:25 AM 3/29/2002 -0500, Michel J Lambert wrote:
>The attached patch fixes a bunch of bugs. They are:
I've reviewed this one and I'd like to apply it the GC
portion, but I'm not sure about the PMC patch.
Are you sure the following is correct?
RCS file: /cvs/public/parrot/classes/perlnum.pmc
For example:
op puts(in STR) {
if (($1) && string_length($1)) {
PIO_write(interpreter, PIO_STDOUT(interpreter), ($1)->bufstart,
string_length($1));
}
goto NEXT();
}
Everywhere else the code treats NULL as if it were the empty string.
Melvin Smith:
# At 03:25 AM 3/29/2002 -0500, Michel J Lambert wrote:
# >The attached patch fixes a bunch of bugs. They are:
#
# I've reviewed this one and I'd like to apply it the GC
# portion, but I'm not sure about the PMC patch.
#
# Are you sure the following is correct?
#
# RCS file: /cvs/publ
At 10:28 AM 3/29/2002 -0800, Brent Dax wrote:
># Aren't they redundant?
>The cache.* is intended to just be *shortcuts* to commonly-accessed
>data, *not* pointers to completely different data. That's why it's
>referred to as a "cache".
Ok, clear enough. Even clearer would be a comment in pmc.h
At 10:17 AM 3/29/2002 -0800, Steve Fink wrote:
>For example:
>
> op puts(in STR) {
> if (($1) && string_length($1)) {
> PIO_write(interpreter, PIO_STDOUT(interpreter), ($1)->bufstart,
> string_length($1));
> }
> goto NEXT();
> }
>
>Everywhere else t
On Fri, Mar 29, 2002 at 03:25:19AM -0500, Michel J Lambert wrote:
> The attached patch fixes a bunch of bugs. They are:
>
> >From before, rolled into this patch:
> + Creates a new flag, immortal, which is intended for GC use only, so it
> shouldn't be set in the init() function. This is used to p
At 07:57 PM 3/29/2002 +0200, you wrote:
>"Michel J Lambert" <[EMAIL PROTECTED]> wrote:
>
> > Attached is a .pasm file which causes some string data to be written into
> > the middle of the string_pool->pool_buffer list of entries, such that when
> > it tries to dereference foo in new_pmc_header, i
On Thu, Mar 28, 2002 at 12:18:48AM -0500, Michel J Lambert wrote:
> Attached are my revised files. pbc2c.pl uses Parrot::OpTrans::Compiled,
> and this patch uses Parrot::OpTrans::CGoto. It also fixed the issues with
> the last patch:
>
> - removed inadvertant keyed commenting
> - fixed #include n
On Fri, Mar 29, 2002 at 10:28:09AM -0800, Brent Dax wrote:
> Let's say my data pointer points to this struct:
>
> typedef struct parrot_subroutine_t {
> opcode_t *bytecode;
> STRING *name;
> proto*prototype;
> (a bunch of other s
This patch obsoletes my previous two key-related patches. It's a large
patch that does a bunch of things, so I'd like somebody to give an
opinion before I commit it.
- Changes KEY to contain a KEY_PAIR* instead of a KEY_PAIR**
- Changes the MAKE_KEY macro to work within an expression
- Changes
The two patches in this thread are obsoleted by the 'core key support'
patch I just posted.
At 11:12 AM 3/29/2002 -0800, Steve Fink wrote:
>On Fri, Mar 29, 2002 at 03:25:19AM -0500, Michel J Lambert wrote:
> > The attached patch fixes a bunch of bugs. They are:
>It looks good to me, with one caveat. 'immortal' sounds wrong to me,
>since that has another (useful) meaning -- the Java VM, f
> So then the above line:
>
> ># + SELF->data = value->cache.struct_val;
>
> Should be
>
> ># + SELF->data = value->data;
>
> Correct?
Those look good. Thanks for the catch.
Steve: wrt to the immortal name choice, if you like, I can submit a patch
changing the name to immune...I'm no
The following was applied by Dan, but from what I can tell, seems to have
become unapplied since.
Mike Lambert
Bryan C. Warnock wrote:
> Date: Fri, 22 Mar 2002 01:47:02 -0500
> From: Bryan C. Warnock <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [PATCH] stacks.c
>
> Defer allocation as
It won't go in cleanly any more:
patching file stacks.c
Hunk #1 FAILED at 108.
Hunk #2 FAILED at 153.
Hunk #3 succeeded at 227 (offset 46 lines).
Hunk #4 succeeded at 243 with fuzz 1 (offset 46 lines).
2 out of 4 hunks FAILED -- saving rejects to file stacks.c.rej
If you can submit a patch agai
> It won't go in cleanly any more:
How about the below patch?
Mike Lambert
Index: stacks.c
===
RCS file: /cvs/public/parrot/stacks.c,v
retrieving revision 1.26
diff -u -r1.26 stacks.c
--- stacks.c29 Mar 2002 20:14:42 -
> I've applied portions of this patch. I omitted the parts which use the
> "byte" type, which isn't going to work on all platforms.
I've changed these to use 'char'. Hopefully that will be more portable.
Mike Lambert
Index: misc.c
===
Applied, all tests passing.
--Josh
At 20:31 on 03/29/2002 EST, Michel J Lambert <[EMAIL PROTECTED]> wrote:
> > It won't go in cleanly any more:
>
> How about the below patch?
>
> Mike Lambert
>
>
> Index: stacks.c
> ===
> RCS
Good enuff, thanks! Applied.
--Josh
At 20:36 on 03/29/2002 EST, Michel J Lambert <[EMAIL PROTECTED]> wrote:
> > I've applied portions of this patch. I omitted the parts which use the
> > "byte" type, which isn't going to work on all platforms.
>
> I've changed these to use 'char'. Hopefully
> > - Transformation: they can look inside the structure of their arguments.
>
> Ok, here's where I think you don't want to go. I understand the power,
Too late. I'm going there... :)
Letting it sit in my mind for a few days, I have a couple new ideas,, or
rather, ideas I've read about elsewhere
Frame stacks now keep their size, no use in freeing the chunks; if we
reached a frame depth N once, we will typically reach N many more times.
-Melvin
> Too late. I'm going there... :)
Good for you. I was hoping transformations could make it :)
Here's something I was wondering. Say you wanted to write a pow() macro
(from a previous example) that would forward to C's pow() unless the
exponent was an integer, in which case it would optimize to
30 matches
Mail list logo
