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
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
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
> 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
===
> 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 -
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
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
> 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
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
The two patches in this thread are obsoleted by the 'core key support'
patch I just posted.
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
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
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
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 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 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
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
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
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.
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
"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
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.
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
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'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
> 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
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
27 matches
Mail list logo
