Excellent- applied.
--Josh
At 18:03 on 03/21/2002 EST, Michel J Lambert <[EMAIL PROTECTED]> wrote:
> Times are:
> make quicktest, after caching output: 23 seconds
> make test: 175 seconds
>
> make quicktest could screw up if:
> - you ctrl-c it, or make test (although I haven't had problems wit
Some patches committed last evening nearly took care of the problem -- at
least they appeared to make my small example appear to
work. Sometimes. :) Here's a slightly larger but better example that so
far hasn't failed to show the stack corruption problem anywhere:
TOKENIZER:
set S
On Friday 22 March 2002 08:22, Clinton A. Pierce wrote:
> Some patches committed last evening nearly took care of the problem -- at
> least they appeared to make my small example appear to
> work. Sometimes. :) Here's a slightly larger but better example that so
> far hasn't failed to show t
Works ok up to 15 items on the stack. After that I get screwy results back.
I just changed the written word to a number and added a few more to the
list. Here's what I get with a stack dump after the tokenizer:
1<--- save
all ok
30 <-- save
restore --> 30
restore --> 29
restore --> 28
resto
On Friday 22 March 2002 09:37, Joshua Nye wrote:
> Works ok up to 15 items on the stack. After that I get screwy results back.
Is that with or without my patch?
http:[EMAIL PROTECTED]/msg09093.html
--
Bryan C. Warnock
[EMAIL PROTECTED]
Missing tags and bad indents.
Index: pdds/pdd07_codingstd.pod
===
RCS file: /home/perlcvs/parrot/docs/pdds/pdd07_codingstd.pod,v
retrieving revision 1.2
diff -u -r1.2 pdd07_codingstd.pod
--- pdds/pdd07_codingstd.pod4 Mar 2002 02:
We're still all over the place with typedef name formats. We've FOO, Foo,
and foo_t. We tried to hash this out before, but we didn't come to a clear
consensus. (We got sidetracked by typedeffing pointers to typedefs.)
What's it going to be?
--
Bryan C. Warnock
[EMAIL PROTECTED]
Bryan C. Warnock:
# We're still all over the place with typedef name formats.
# We've FOO, Foo,
# and foo_t. We tried to hash this out before, but we didn't
# come to a clear
# consensus. (We got sidetracked by typedeffing pointers to typedefs.)
#
# What's it going to be?
Parrot_Foo for externa
Doh! Applied now.
But this fails now:
set S0, "test"
set I0, 234
save S0
save I0
restore S1
restore I1
end
With error message: Wrong type on top of stack!
Not sure if this is intended though. I though each type (INT,NUM,PMC,STR)
has it's own stack?
--josh
- Original Message -
From: "
Nevermind I think it's just two early in the morning for me.
- Original Message -
From: "Joshua Nye" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, March 22, 2002 10:06 AM
Subject: Re: Problems with strings on the stack (small, concise example)
> Doh! Ap
On Friday 22 March 2002 10:06, Joshua Nye wrote:
> Doh! Applied now.
>
> But this fails now:
>
> set S0, "test"
> set I0, 234
> save S0
> save I0
> restore S1
> restore I1
LIFO. Switch your restores. You're trying to pop an integer (IO) into a
string (S1).
> end
>
> With error message: Wr
On Fri, Mar 22, 2002 at 10:06:44AM -0500, Joshua Nye wrote:
> Not sure if this is intended though. I though each type (INT,NUM,PMC,STR)
> has it's own stack?
This is the expected behaviour. There are only two stacks visible at the parrot
assembly level. The scratch (or data) stack, and the contr
At 10:06 AM 3/22/2002 -0500, Joshua Nye wrote:
>Doh! Applied now.
>
>But this fails now:
>
>set S0, "test"
>set I0, 234
>save S0
>save I0
>restore S1
>restore I1
>end
>
>With error message: Wrong type on top of stack!
>
>Not sure if this is intended though. I though each type (INT,NUM,PMC,STR)
>ha
On Friday 22 March 2002 10:07, Brent Dax wrote:
> Bryan C. Warnock:
> # We're still all over the place with typedef name formats.
> # We've FOO, Foo,
> # and foo_t. We tried to hash this out before, but we didn't
> # come to a clear
> # consensus. (We got sidetracked by typedeffing pointers to t
At 08:43 AM 3/22/2002 -0500, Bryan C. Warnock wrote:
>On Friday 22 March 2002 08:22, Clinton A. Pierce wrote:
> > Some patches committed last evening nearly took care of the problem -- at
> > least they appeared to make my small example appear to
> > work. Sometimes. :) Here's a slightly larger
On Fri, Mar 22, 2002 at 10:13:41AM -0500, Jason Gloudon wrote:
> assembly level. The scratch (or data) stack, and the control flow stack. The
> push, pop, and save ops work on the scratch stack, which as you have found,
> does type-checking.
Corrections:
That should have been save, savec, and
Bryan C. Warnock:
# On Friday 22 March 2002 10:07, Brent Dax wrote:
# > Bryan C. Warnock:
# > # We're still all over the place with typedef name formats.
# > # We've FOO, Foo,
# > # and foo_t. We tried to hash this out before, but we didn't
# > # come to a clear
# > # consensus. (We got sidetrac
On Friday 22 March 2002 10:17, Clinton A. Pierce wrote:
> No no. That's always fine. Now dump the stack. That's where the joy is!
So little faith :-)
Well, you don't include dump code, so I'll cobble some together.
TOKBAIL:
bsr DUMP
end
DUMP:eq I5, 0, BAIL
On Friday 22 March 2002 10:36, Brent Dax wrote:
> # > Parrot_Foo for external names, FOO for internal names, struct
> # > parrot_foo_t for struct names. Now let's argue about if
> # Parrot_Foo is
> # > typedefed as a pointer or not. ;^)
> #
> # Oy vay!, none of which match PDD 07.
Except that
At 1:29 AM -0500 3/22/02, Bryan C. Warnock wrote:
>Fixes a couple GC problems.
Applied, thanks.
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
At 1:47 AM -0500 3/22/02, Bryan C. Warnock wrote:
>
>Defer allocation as long as possible. Make logic parallel.
Applied, thanks
--
Dan
--"it's like this"---
Dan Sugalski even s
Bryan C. Warnock:
# On Friday 22 March 2002 10:36, Brent Dax wrote:
#
# > # > Parrot_Foo for external names, FOO for internal names, struct
# > # > parrot_foo_t for struct names. Now let's argue about if
# > # Parrot_Foo is
# > # > typedefed as a pointer or not. ;^)
# > #
# > # Oy vay!, none of
Bryan, this is good stuff! One question though- in this section of the
patch:
> - /* file header comments */
> -
> - #if !defined(PARROT__H_GUARD)
> - #define PARROT__H_GUARD
> -
> - /* body of file */
> -
> - #endif /* PARROT__H_GUARD */
> +/* file header comments */
> +
> +#if !d
At 9:52 AM -0500 3/22/02, Bryan C. Warnock wrote:
>Missing tags and bad indents.
Applied, thanks.
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
On Friday 22 March 2002 11:23, Josh Wilmes wrote:
>
>
> This doesn't agree with how we've been doing cpp directive indenting in
> two ways.
I was just fixing various format problems. There's a *lot* in the PDD that
doesn't match what we're doing. Bad bad bad, on many many many people.
We n
At 10:02 AM -0500 3/22/02, Bryan C. Warnock wrote:
>We're still all over the place with typedef name formats. We've FOO, Foo,
>and foo_t. We tried to hash this out before, but we didn't come to a clear
>consensus. (We got sidetracked by typedeffing pointers to typedefs.)
All Parrot typedef'd t
On Friday 22 March 2002 11:36, Dan Sugalski wrote:
> At 10:02 AM -0500 3/22/02, Bryan C. Warnock wrote:
> >We're still all over the place with typedef name formats. We've FOO, Foo,
> >and foo_t. We tried to hash this out before, but we didn't come to a
clear
> >consensus. (We got sidetracked b
At 11:41 AM -0500 3/22/02, Bryan C. Warnock wrote:
>On Friday 22 March 2002 11:36, Dan Sugalski wrote:
>> At 10:02 AM -0500 3/22/02, Bryan C. Warnock wrote:
>> >We're still all over the place with typedef name formats. We've FOO, Foo,
>> >and foo_t. We tried to hash this out before, but we di
"Bryan C.
Warnock" To:
On Friday 22 March 2002 11:46, Dan Sugalski wrote:
> That's fine. Throw in typedefs for both ways to start, so we can do
> this incrementally, if you would.
Index: config_h.in
===
RCS file: /home/perlcvs/parrot/config_h.in,v
retriev
At 11:34 on 03/22/2002 EST, "Bryan C. Warnock" <[EMAIL PROTECTED]> wrote:
> On Friday 22 March 2002 11:23, Josh Wilmes wrote:
> >
> >
> > This doesn't agree with how we've been doing cpp directive indenting in
> > two ways.
>
> I was just fixing various format problems. There's a *lot* in th
At 11:53 AM -0500 3/22/02, Bryan C. Warnock wrote:
>On Friday 22 March 2002 11:46, Dan Sugalski wrote:
>> That's fine. Throw in typedefs for both ways to start, so we can do
>> this incrementally, if you would.
Applied, thanks.
--
Dan
-
Brent Dax <[EMAIL PROTECTED]> writes:
> Parrot_Foo for external names, FOO for internal names, struct
> parrot_foo_t for struct names.
POSIX reserves all types ending in _t. I'm not sure that extends to
struct tags, but it may still be better to use _s or something else
instead to avoid potenti
Russ Allbery:
# Brent Dax <[EMAIL PROTECTED]> writes:
# > Parrot_Foo for external names, FOO for internal names, struct
# > parrot_foo_t for struct names.
#
# POSIX reserves all types ending in _t. I'm not sure that extends to
# struct tags, but it may still be better to use _s or something else
On Friday 22 March 2002 17:53, Russ Allbery wrote:
> Brent Dax <[EMAIL PROTECTED]> writes:
>
> > Parrot_Foo for external names, FOO for internal names, struct
> > parrot_foo_t for struct names.
>
> POSIX reserves all types ending in _t. I'm not sure that extends to
> struct tags, but it may sti
On Friday 22 March 2002 18:05, Brent Dax wrote:
> Russ Allbery:
> # Brent Dax <[EMAIL PROTECTED]> writes:
> # > Parrot_Foo for external names, FOO for internal names, struct
> # > parrot_foo_t for struct names.
> #
> # POSIX reserves all types ending in _t. I'm not sure that extends to
> # struct
Brent Dax <[EMAIL PROTECTED]> writes:
> Russ Allbery:
> # POSIX reserves all types ending in _t. I'm not sure that extends to
> # struct tags, but it may still be better to use _s or something else
> # instead to avoid potential problems.
> My understanding is that it only reserves types that s
Bryan C. Warnock:
# On Friday 22 March 2002 18:05, Brent Dax wrote:
# > Russ Allbery:
# > # Brent Dax <[EMAIL PROTECTED]> writes:
# > # > Parrot_Foo for external names, FOO for internal names, struct
# > # > parrot_foo_t for struct names.
# > #
# > # POSIX reserves all types ending in _t. I'm not
"Bryan C. Warnock" wrote:
>
> On Friday 22 March 2002 17:53, Russ Allbery wrote:
> > Brent Dax <[EMAIL PROTECTED]> writes:
> >
> > > Parrot_Foo for external names, FOO for internal names, struct
> > > parrot_foo_t for struct names.
> >
> > POSIX reserves all types ending in _t. I'm not sure th
At 3:53 PM -0800 3/22/02, Brent Dax wrote:
>Bryan C. Warnock:
># > Besides, what's the probability it'll be a problem if we prefix all
># > struct names with 'parrot_'?
>#
># You don't really want to do that, do you?
>
>Yes, in fact, I do. In the general case, you will never have to use the
>'str
Dan Sugalski:
# At 3:53 PM -0800 3/22/02, Brent Dax wrote:
# >Bryan C. Warnock:
# ># > Besides, what's the probability it'll be a problem if we
# prefix all
# ># > struct names with 'parrot_'?
# >#
# ># You don't really want to do that, do you?
# >
# >Yes, in fact, I do. In the general case, you
On Fri, Mar 22, 2002 at 11:52:16AM -0500, Melvin Smith wrote:
> On Friday 22 March 2002 11:36, Dan Sugalski wrote:
> > At 10:02 AM -0500 3/22/02, Bryan C. Warnock wrote:
> > I'm up in the air as to whether any of the core routines should have
> > a Parrot prefix--I'm thinking not, as I don't think
On Sat, Mar 23, 2002 at 12:55:00AM +0100, Segher Boessenkool wrote:
> Besides, struct etc. are their own namespace, aside from the normal
> variables/functions namespace. No need for any pre/postfix at all.
Until someone wishes to embed the public headers into a C++ program.
Or finds themselves
On Friday 22 March 2002 19:40, Nicholas Clark wrote:
> On Sat, Mar 23, 2002 at 12:55:00AM +0100, Segher Boessenkool wrote:
> > Besides, struct etc. are their own namespace, aside from the normal
> > variables/functions namespace. No need for any pre/postfix at all.
>
> Until someone wishes to em
44 matches
Mail list logo
