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
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 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
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
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
"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
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
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
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
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
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
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
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
-
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
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
"Bryan C.
Warnock" To:
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
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 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: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 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]
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
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
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
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]
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
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
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 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
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 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 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 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
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
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
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: "
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
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]
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:
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]
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 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
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
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
44 matches
Mail list logo
