Index: interpreter.c
===
RCS file: /home/perlcvs/parrot/interpreter.c,v
retrieving revision 1.71
diff -u -r1.71 interpreter.c
--- interpreter.c 18 Feb 2002 08:26:03 - 1.71
+++ interpreter.c 24 Feb 2002 05:19:21 -
On Saturday 23 February 2002 23:35, Brent Dax wrote:
> The Magic Word in this case is "embedders".
>
> a) We can't reserve "any symbol starting with 'P'" to Parrot. That's a
> little too wide a scope.
Well, Phuck.
> b) I'd rather not have embedders worrying about "is this a value type or
> a po
Bryan C. Warnock:
# On Saturday 23 February 2002 23:20, Brent Dax wrote:
# > The Right Answer is probably to change all the STRING*s in
# the core to
# > Parrot_Strings. However, there are two problems with that:
#
# I think that's the recommended school of thought, although
# I've always
# prefe
On Saturday 23 February 2002 23:20, Brent Dax wrote:
> The Right Answer is probably to change all the STRING*s in the core to
> Parrot_Strings. However, there are two problems with that:
I think that's the recommended school of thought, although I've always
preferred *not* to typedef the final
Bryan C. Warnock:
# On Saturday 23 February 2002 23:10, Brent Dax wrote:
# > struct foo_t {
# > int i;
# > };
# >
# > typedef struct foo_t * FooPtr;
# > typedef struct foo_t FOO;
# >
# > void bar(FooPtr);
# >
# > void bar(FOO *x) {
# > x->i++;
# >
On Saturday 23 February 2002 23:10, Brent Dax wrote:
> struct foo_t {
> int i;
> };
>
> typedef struct foo_t * FooPtr;
> typedef struct foo_t FOO;
>
> void bar(FooPtr);
>
> void bar(FOO *x) {
> x->i++;
> }
>
> int main() {
Dan Sugalski:
# At 10:43 PM -0500 2/23/02, Josh Wilmes wrote:
# >So indent needs to be told about non-standard type
# (typedefs) to work best.
# >The problem is that some of the parrot code does this:
# >
# >#define CHARTYPE struct parrot_chartype_t
# >#define ENCODING struct parrot_encoding_t
# >
The problem, as I understand it, is that you end up with two names for the
same underlying type, but you can't convert between them without a cast.
Which sort of defeats the reason for these "shortcut names".
--Josh
At 22:47 on 02/23/2002 EST, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:
At 10:43 PM -0500 2/23/02, Josh Wilmes wrote:
>So indent needs to be told about non-standard type (typedefs) to work best.
>The problem is that some of the parrot code does this:
>
>#define CHARTYPE struct parrot_chartype_t
>#define ENCODING struct parrot_encoding_t
>#define STRING struct parrot_s
So indent needs to be told about non-standard type (typedefs) to work best.
The problem is that some of the parrot code does this:
#define CHARTYPE struct parrot_chartype_t
#define ENCODING struct parrot_encoding_t
#define STRING struct parrot_string_t
#define Parrot_CharType struct parrot_chart
At 2:22 on 02/24/2002 GMT, Simon Cozens <[EMAIL PROTECTED]> wrote:
> If you're prepared to fix the output up manually, feel free to run indent on
> your local copy, fix it up, and then mail me a diff; or we can get you commit
> access.
Commit access would be the easiest way to get this done, as
At 21:14 on 02/23/2002 EST, Josh Wilmes <[EMAIL PROTECTED]> wrote:
> - it introduced spaces before the parens on calls to
> mem_sys_memcpy
> string_*
>This is due to the fact that my run_indent.pl program needed to pick
>up #defined types. So it's picking up macros which are
On Saturday 23 February 2002 20:31, Dan Sugalski wrote:
> Well, what I was thinking was we could have a section that marked all
> the legitimate jump destinations. We could then vet this destination
> table at load time for safe interpreters to make sure that the
> destinations really were proper
Josh Wilmes:
> I'd like to go ahead and ask for
> ./run_indent.pl `egrep '*\.[ch]$' MANIFEST | egrep -v \
>'global_setup.c|packfile.c|mops.c|io.h'`
> to be applied to CVS.
I'd rather not, to be honest; as you've found, indent is a useful starting
point, but it needs a human
This just makes it ignore files which say "DO NOT EDIT" (auto-generated
stuff)
--Josh
[josh-012.pach]
Index: check_source_standards.pl
===
RCS file: /home/perlcvs/parrot/check_source_standards.pl,v
retrieving revision 1.1
diff -u
I'd like to go ahead and ask for
./run_indent.pl `egrep '*\.[ch]$' MANIFEST | egrep -v \
'global_setup.c|packfile.c|mops.c|io.h'`
to be applied to CVS.
I've noted some glitches in indent's output, summarized below. However, I
think it's easier to fix these afterwards than
At 6:59 PM -0500 2/23/02, Bryan C. Warnock wrote:
>On Saturday 23 February 2002 13:12, Dan Sugalski wrote:
>> We also need a PDD for the bytecode file format.
>
>Halfway converted. Er, quarterway, maybe.
Cool.
> > I also want all the potential jump destinations to be marked
>> somewhere for
On Sat, 2002-02-23 at 13:12, Dan Sugalski wrote:
> At 12:22 PM -0500 2/23/02, Melvin Smith wrote:
> >At 11:53 AM 2/23/2002 +, Simon Cozens wrote:
> >>I was very lucky recently to attend a talk by Ganesh Sittampalam
> >>introducing Microsoft .NET and the Common Language Runtime. A lot of
> >>wh
This patch adds a script called "run_indent.pl" which runs the GNU indent
program to reformat code to conform to PDD 7. It also patches PDD 7 to
reflect what is being done.
[josh-011.patch]
Index: MANIFEST
===
RCS file: /home/perl
On Saturday 23 February 2002 13:12, Dan Sugalski wrote:
> We also need a PDD for the bytecode file format.
Halfway converted. Er, quarterway, maybe.
> I also want all the potential jump destinations to be marked
> somewhere for the safe mode interpreter, which is another section in
> the byteco
On Sat, Feb 23, 2002 at 04:47:29PM -0500, Dan Sugalski wrote:
> Okay, folks, time to sync up your CVS trees. I've put in an arena
> allocator for string headers. No checking for dead ones or GC yet, so
> it still leaks like a sieve, but it leaks much faster.
:-)
> FWIW, things speed up from 80
At 12:22 PM -0500 2/23/02, Melvin Smith wrote:
>At 11:53 AM 2/23/2002 +, Simon Cozens wrote:
>>I was very lucky recently to attend a talk by Ganesh Sittampalam
>>introducing Microsoft .NET and the Common Language Runtime. A lot of
>>what CLR is trying to do is quite similar to what we're doing
At 6:57 on 02/23/2002 CST, Brian Lee Ray <[EMAIL PROTECTED]> wrote:
> However, a null pointer constant, expressed as either 0 or (void*)0 (and the
> definition of NULL must be one of the above), can be safely compared with
> or assigned to either a function pointer or a data pointer. Consider t
At 11:53 AM 2/23/2002 +, Simon Cozens wrote:
>I was very lucky recently to attend a talk by Ganesh Sittampalam
>introducing Microsoft .NET and the Common Language Runtime. A lot of
>what CLR is trying to do is quite similar to what we're doing with
>Parrot, so I thought it would be a good idea
- Original Message -
From: "Nicholas Clark" <[EMAIL PROTECTED]>
To: "Brian Lee Ray" <[EMAIL PROTECTED]>
Cc: "Josh Wilmes" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, February 23, 2002 5:32 AM
Subject: Re: [PATCH] Bowing to necessity (was Re: [PATCH]Macro bulletproofing )
>
> >An integral constant expression with the value 0, or such an
> > expression cast to type void *, is called a null pointer
> > constant.
> Function pointers are not data pointers.
>
> [And thinking about it, that excerpt doesn't say that. I hope its context did,
> else I'd accu
I was very lucky recently to attend a talk by Ganesh Sittampalam
introducing Microsoft .NET and the Common Language Runtime. A lot of
what CLR is trying to do is quite similar to what we're doing with
Parrot, so I thought it would be a good idea to briefly recap what's
going on with CLR.
The CLR
On Sat, Feb 23, 2002 at 03:21:08AM -0600, Brian Lee Ray wrote:
>
> From: "Josh Wilmes" <[EMAIL PROTECTED]>
> > Using NULL where a function pointer is expected is considered an error by
> > tcc, and a mandatory warning by lcc. It is my understanding that
> conversion
> > between data pointers an
From: "Josh Wilmes" <[EMAIL PROTECTED]>
>
> Good stuff! However, regarding the function pointer thing, i've got
compilers
> (tcc and lcc) which disagree with you.
>
> Using NULL where a function pointer is expected is considered an error by
> tcc, and a mandatory warning by lcc. It is my unders
29 matches
Mail list logo
