On Mon, Jul 15, 2002 at 12:34:52AM -0400, Melvin Smith wrote:
> At 09:27 PM 7/14/2002 -0700, Brent Dax wrote:
>
> Wow, Brent lives! :)
>
> >Here's the rules, roughly as they stand right now:
> >
> >-Functions start with Parrot_[a-z] or just [a-z].
> >-Typedefed names start with P
On Tuesday 16 July 2002 01:02 am, Melvin Smith wrote:
> >It's also unnecessary. It isn't like there aren't perfectly good
> >alternatives--what's wrong with "Parrot__"?
>
> Well, what's wrong with Parrot_ ?
There's nothing wrong with Parrot_ -- as long as it isn't used *everywhere*.
A good thing
At 11:08 AM 7/15/2002 -0700, Damien Neil wrote:
>On Mon, Jul 15, 2002 at 12:34:52AM -0400, Melvin Smith wrote:
> > >The last four are reserved by various C and C++ standards.
> >
> > I always hear this, but in real life it is never much of a problem.
> > Especially
> > with a namespace like [Parro
On Mon, Jul 15, 2002 at 12:34:52AM -0400, Melvin Smith wrote:
> >The last four are reserved by various C and C++ standards.
>
> I always hear this, but in real life it is never much of a problem.
> Especially
> with a namespace like [Parrot]
It is a good idea to avoid using the reserved identif
Brent Dax writes:
>[EMAIL PROTECTED]:
># Good stuff. Didn't you also send out a draft PDD about how
># types should
># be named and managed in parrot at one point? I, for one,
>
>At one point I sent out a patch to PDD7 that handled type naming.
(I don't know what happened to this specific pa
Paul Kienzle:
# On Mon, Jul 15, 2002 at 02:26:55AM +, Ashley Winters wrote:
# > On Monday 15 July 2002 02:25 am, Brent Dax wrote:
# > > -C library wrappers: This is Parrot's version of the
# function, so
# > > it makes sense to prefix it with Parrot_.
# > >
# > > The third category I can se
On Mon, Jul 15, 2002 at 02:26:55AM +, Ashley Winters wrote:
> On Monday 15 July 2002 02:25 am, Brent Dax wrote:
> > -C library wrappers: This is Parrot's version of the function, so it
> > makes sense to prefix it with Parrot_.
> >
> > The third category I can see having a prefix of plat_ (fo
Brent Dax wrote:
> If people want that scheme, speak now or forever hold your peace.
Sounds reasonable to me. (FWIW)
> > _Parrot
> > _parrot
> > __Parrot
> > __parrot
>
> The last four are reserved by various C and C++ standards.
Damn, I forgot about that. I'm a C coder from Way Ba
At 09:27 PM 7/14/2002 -0700, Brent Dax wrote:
Wow, Brent lives! :)
>Here's the rules, roughly as they stand right now:
>
> -Functions start with Parrot_[a-z] or just [a-z].
> -Typedefed names start with Parrot_[A-Z] or just [A-Z].
> -Macros and constants start with PARROT
John Porter:
# Brent Dax wrote:
# > Ashley Winters:
# > > c. parrot_sprintf
# >
# > Lowercase is always the hallmark of struct names, i.e.
# > parrot_string_t.
#
# Ehhh... you yourself said something about plat_ and misc_
# as (theoretical) alternatives.
#
# Anyway, it's a silly rule. Upper-c
Brent Dax wrote:
> Ashley Winters:
> > c. parrot_sprintf
>
> Lowercase is always the hallmark of struct names, i.e.
> parrot_string_t.
Ehhh... you yourself said something about plat_ and misc_
as (theoretical) alternatives.
Anyway, it's a silly rule. Upper-case (and lower-case) are
going to h
Ashley Winters:
# On Monday 15 July 2002 02:25 am, Brent Dax wrote:
# > -C library wrappers: This is Parrot's version of the
# function, so it
# > makes sense to prefix it with Parrot_.
# >
# > The third category I can see having a prefix of plat_ (for
# platform)
# > or some such, and perhap
[EMAIL PROTECTED]:
# Good stuff. Didn't you also send out a draft PDD about how
# types should
# be named and managed in parrot at one point? I, for one,
At one point I sent out a patch to PDD7 that handled type naming.
# would love to
# see a PDD that described C-level nanming and namespa
On Monday 15 July 2002 02:25 am, Brent Dax wrote:
> -C library wrappers: This is Parrot's version of the function, so it
> makes sense to prefix it with Parrot_.
>
> The third category I can see having a prefix of plat_ (for platform) or
> some such, and perhaps the second could have misc_, but I
John Porter:
# Brent Dax wrote:
# > > 2. What does having a Parrot_ prefix signify, considering
# > > both the opcodes and the embed api use it?
# >
# > It signifies one of the following:
# > -This function is externally visible.
# > -This function belongs to Parrot at large, and not any particul
Brent Dax wrote:
> > 2. What does having a Parrot_ prefix signify, considering
> > both the opcodes and the embed api use it?
>
> It signifies one of the following:
> -This function is externally visible.
> -This function belongs to Parrot at large, and not any particular
> subsystem (e.g. Par
Brent,
Good stuff. Didn't you also send out a draft PDD about how types should
be named and managed in parrot at one point? I, for one, would love to
see a PDD that described C-level nanming and namespace management in
general.
--Josh
At 3:11 on 07/14/2002 PDT, "Brent Dax" <[EMAIL PROTECTE
Ashley Winters:
# 1. Why is test_main.c not named main.c?
Because parrot.exe was originally named test_prog.exe, so at the time it
made sense for it to be called test_main.c.
# 2. What does having a Parrot_ prefix signify, considering
# both the opcodes and
# the embed api use it? It's hard to
Hrm, I had intended to put my questions at the end. I hit Send early.
Questions:
1. Why is test_main.c not named main.c?
2. What does having a Parrot_ prefix signify, considering both the opcodes and
the embed api use it? It's hard to distinguish between them.
3. What source files implement wh
I'm trying to pay attention to the difficulties I have understanding parrot so
I can give some decent n00b feedback before I know the code like the back of
my hand.
First, test_main.c is a totally non-obvious location for parrot.exe's main().
I dismissed it out of hand when I did grep ^main. I
20 matches
Mail list logo
