RE: Misc portability cleanups

[Melvin Smith]

At 10:56 PM 3/30/2002 -0800, Brent Dax wrote:
>Melvin Smith:
># At 01:06 AM 3/31/2002 -0500, Michael G Schwern wrote:
># >On Sun, Mar 31, 2002 at 12:49:08AM -0500, Melvin Smith wrote:
>Ouch.  They actually expect you to be able to do anything useful without
>the other headers?

Grin, I agree -- go ask Mr. Gates. :)

-Melvin

RE: Misc portability cleanups

[Brent Dax]

Melvin Smith:
# At 01:06 AM 3/31/2002 -0500, Michael G Schwern wrote:
# >On Sun, Mar 31, 2002 at 12:49:08AM -0500, Melvin Smith wrote:
# > > I did some browsing of the code for potential problems in
# compiling
# > > for embedded platforms and/or general porting and here
# are some of the
# > > things I found.
# >
# >Do embedded C compilers often not conform to ANSI C 89?
#
# Yes and no, depending on your definition.
#
# ANSI C 89 specificies "free-standing environments" and "hosted"
# environments. It does not require the former to provide any
# more than these 4 -> (float.h, limits.h, stdarg.h, stddef.h), besides
# the language proper itself.
#
# To qualify as a "hosted" environment they must provide the larger
# list (stdio, stdlib, signal, string, assert, ctype, errno,
# locale, limits,
# math, setjmp, stdarg, stddef, time).
#
# WinCE on PocketPC is in my book a "free-standing" environment
# by this definition. I've also coded on the Intel 8051 MC once
# upon a time
# and I think I had some of the same issues, but its too fuzzy to
# remember now.
#
# CE is coming along though, 2.0 didn't provide stdio stuff,
# but 3.0 does
# have some limited stuff.

Ouch.  They actually expect you to be able to do anything useful without
the other headers?

It might actually be easier to just implement the headers ourselves on
platforms that don't have them...

# > > 1- assert.h and use of assert()
# > > assert is easy enough to implement we need to do this
# and not depend
# > > on its existence on the target because its not guaranteed.
# >
# >assert is part of ANSI C 89, it should always be there.  The only
# >limitation is the expression must be an int.
# >
# >
# > > 2- errno.h same thing.
# >
# >errno is also in ANSI C 89.
#
# I'm not saying we shouldn't use it or include it, just not in
# the general
# naked includes.
#
# >However, using errno to transmit error messages has bitten us in the
# >ass in Perl5.
#
# Well for one, assert is so easy to implement its really kind
# of dumb that
# the host compiler doesn't have it, but its also not worth
# fretting about,
# either.
#
# However, anywhere we use assert() is probably a candidate for using
# the Parrot exception routine anway.

Or better, the incredibly under-utilized panic routine.

--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

#define private public
--Spotted in a C++ program just before a #include

Re: Misc portability cleanups

[Melvin Smith]

At 01:06 AM 3/31/2002 -0500, Michael G Schwern wrote:
>On Sun, Mar 31, 2002 at 12:49:08AM -0500, Melvin Smith wrote:
> > I did some browsing of the code for potential problems in compiling
> > for embedded platforms and/or general porting and here are some of the
> > things I found.
>
>Do embedded C compilers often not conform to ANSI C 89?

Yes and no, depending on your definition.

ANSI C 89 specificies "free-standing environments" and "hosted"
environments. It does not require the former to provide any
more than these 4 -> (float.h, limits.h, stdarg.h, stddef.h), besides
the language proper itself.

To qualify as a "hosted" environment they must provide the larger
list (stdio, stdlib, signal, string, assert, ctype, errno, locale, limits,
math, setjmp, stdarg, stddef, time).

WinCE on PocketPC is in my book a "free-standing" environment
by this definition. I've also coded on the Intel 8051 MC once upon a time
and I think I had some of the same issues, but its too fuzzy to
remember now.

CE is coming along though, 2.0 didn't provide stdio stuff, but 3.0 does
have some limited stuff.

> > 1- assert.h and use of assert()
> > assert is easy enough to implement we need to do this and not depend
> > on its existence on the target because its not guaranteed.
>
>assert is part of ANSI C 89, it should always be there.  The only
>limitation is the expression must be an int.
>
>
> > 2- errno.h same thing.
>
>errno is also in ANSI C 89.

I'm not saying we shouldn't use it or include it, just not in the general
naked includes.

>However, using errno to transmit error messages has bitten us in the
>ass in Perl5.

Well for one, assert is so easy to implement its really kind of dumb that
the host compiler doesn't have it, but its also not worth fretting about, 
either.

However, anywhere we use assert() is probably a candidate for using
the Parrot exception routine anway.

-Melvin

Re: Misc portability cleanups

[Michael G Schwern]

On Sun, Mar 31, 2002 at 12:49:08AM -0500, Melvin Smith wrote:
> I did some browsing of the code for potential problems in compiling
> for embedded platforms and/or general porting and here are some of the
> things I found.

Do embedded C compilers often not conform to ANSI C 89?


> 1- assert.h and use of assert()
> assert is easy enough to implement we need to do this and not depend
> on its existence on the target because its not guaranteed.

assert is part of ANSI C 89, it should always be there.  The only
limitation is the expression must be an int.


> 2- errno.h same thing.

errno is also in ANSI C 89.

However, using errno to transmit error messages has bitten us in the
ass in Perl5.


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance  <[EMAIL PROTECTED]> Kwalitee Is Job One
Monkey tennis

Re: Misc portability cleanups

[Melvin Smith]

At 09:56 PM 3/30/2002 -0800, Russ Allbery wrote:
>Melvin Smith <[EMAIL PROTECTED]> writes:
>
> > 5- Other misc includes that should be wrapped in ifdefs are:
> >  sys/types.h, sys/stat.h, fcntl.h (btw parrot.h includes fcntl.h
> >  twice, once inside an ifdef and then by default).
>
>What platform doesn't have sys/types.h?  It's one of the few headers that
>I've *never* seen wrapped in ifdef even in code meant to compile on
>extremely strange systems.

WinCE for one.

It has types.h but no sys/ stuff.

-Melvin

Re: Misc portability cleanups

[Josh Wilmes]

You may be interested in the "lib_deps" target.

--Josh

At 0:49 on 03/31/2002 EST, Melvin Smith <[EMAIL PROTECTED]> wrote:

> I did some browsing of the code for potential problems in compiling
> for embedded platforms and/or general porting and here are some of the
> things I found.
> 
> 1- assert.h and use of assert()
>  assert is easy enough to implement we need to do this and not depend
>  on its existence on the target because its not guaranteed.
> 2- errno.h same thing. Any use of errno is typically a system call, so it 
> should
>  be wrapped in a platform generic way. On Win32 and WinCE we use
>  GetLastError(), on UNIX and many others we can use errno.
> 3- Use of stat and statbuf.  embed.c needs to be redone without it, period.
>  We should go ahead and call the PIO routines instead, and add to PIO 
> as needed.
>  We can implement a generic stat routine.
> 4- Configure.pl needs to prompt for targetting another environment and
>  have some specific hints file for each targettable environment.
>  For WinCE stuff it might be worth querying ENV{} for stuff like CC, 
> TARGETCPU,
>  PLATFORM, OSVERSION.
> 5- Other misc includes that should be wrapped in ifdefs are:
>  sys/types.h, sys/stat.h, fcntl.h (btw parrot.h includes fcntl.h twice, 
> once
>  inside an ifdef and then by default).
> 6- Need to check for definition of size_t and generate one if needed.
> 
> Thats enough for now; baby steps. :)
> 
> -Melvin
> 

Re: Misc portability cleanups

[Russ Allbery]

Melvin Smith <[EMAIL PROTECTED]> writes:

> 5- Other misc includes that should be wrapped in ifdefs are:
>  sys/types.h, sys/stat.h, fcntl.h (btw parrot.h includes fcntl.h
>  twice, once inside an ifdef and then by default).

What platform doesn't have sys/types.h?  It's one of the few headers that
I've *never* seen wrapped in ifdef even in code meant to compile on
extremely strange systems.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Misc portability cleanups

[Melvin Smith]

I did some browsing of the code for potential problems in compiling
for embedded platforms and/or general porting and here are some of the
things I found.

1- assert.h and use of assert()
 assert is easy enough to implement we need to do this and not depend
 on its existence on the target because its not guaranteed.
2- errno.h same thing. Any use of errno is typically a system call, so it 
should
 be wrapped in a platform generic way. On Win32 and WinCE we use
 GetLastError(), on UNIX and many others we can use errno.
3- Use of stat and statbuf.  embed.c needs to be redone without it, period.
 We should go ahead and call the PIO routines instead, and add to PIO 
as needed.
 We can implement a generic stat routine.
4- Configure.pl needs to prompt for targetting another environment and
 have some specific hints file for each targettable environment.
 For WinCE stuff it might be worth querying ENV{} for stuff like CC, 
TARGETCPU,
 PLATFORM, OSVERSION.
5- Other misc includes that should be wrapped in ifdefs are:
 sys/types.h, sys/stat.h, fcntl.h (btw parrot.h includes fcntl.h twice, 
once
 inside an ifdef and then by default).
6- Need to check for definition of size_t and generate one if needed.

Thats enough for now; baby steps. :)

-Melvin

Re: Bugfix release?

[Melvin Smith]

At 06:45 PM 3/30/2002 +, Nicholas Clark wrote:
>On Sat, Mar 30, 2002 at 10:52:35AM -0500, Melvin Smith wrote:
> > At 09:38 AM 3/30/2002 -0500, Dan Sugalski wrote:
> > >With the recent stack and GC patches, are we pretty much solid now? If 
> so,
> > >a 0.0.5 bugfix release may well be in order.
> >
> > My crashme program crashes no more, we are 10x more stable than
> > a week ago. I think Peter's patch or a variation is in order, and I'm also
> > working
> > on a new crashme :)
> >
> > Bring on 0.0.5
>
>Peter's made it foolproof, so Melvin is about to build a better fool? :-)
>Long may this arms race continue.

Who better to build a better fool but a fool? *grin*

-Melvin

Re: Bugfix release?

[Melvin Smith]

At 04:59 PM 3/30/2002 +0200, Peter Gibbs wrote:
>"Dan Sugalski" <[EMAIL PROTECTED]> wrote
>
> > With the recent stack and GC patches, are we pretty much solid now?
> > If so, a 0.0.5 bugfix release may well be in order.
>
>The one outstanding issue that I know of is the mem_realloc problem in
>add_pmc_to_free and add_header_to_free. Since the problem is actually
>endemic to mem_realloc, the best solution seems to be a replacement for
>mem_realloc that takes a Buffer*, so that an intervening GC run still leaves
>it knowing where the source is.
>In line with a previous suggestion, I propose that such a routine be called
>Parrot_reallocate.
>A patch to create such a function and use it within add_pmc_to_free and
>add_header_to_free follows; since all uses of mem_realloc are potentially at
>risk, it might be a good idea to change any such places also.

I like this patch much better. I'll commit this if there are no other comments
from the rest of the group.

-Melvin



>--
>Peter Gibbs
>EmKel Systems
>
>Index: include/parrot/resources.h
>===
>RCS file: /home/perlcvs/parrot/include/parrot/resources.h,v
>retrieving revision 1.25
>diff -u -r1.25 resources.h
>--- include/parrot/resources.h  18 Mar 2002 22:09:10 -  1.25
>+++ include/parrot/resources.h  30 Mar 2002 14:58:26 -
>@@ -31,6 +31,7 @@
>
>  void *Parrot_allocate(struct Parrot_Interp *, size_t size);
>  void *Parrot_alloc_new_block(struct Parrot_Interp *, size_t, UINTVAL);
>+void Parrot_reallocate(struct Parrot_Interp *, Buffer *, size_t);
>
>  void Parrot_new_pmc_header_arena(struct Parrot_Interp *interpreter);
>
>Index: resources.c
>===
>RCS file: /home/perlcvs/parrot/resources.c,v
>retrieving revision 1.37
>diff -u -r1.37 resources.c
>--- resources.c 30 Mar 2002 05:57:32 - 1.37
>+++ resources.c 30 Mar 2002 14:57:38 -
>@@ -18,22 +18,18 @@
>  static void add_header_to_free(struct Parrot_Interp *interpreter,
> struct free_pool *pool, void *to_add);
>
>-/* Add a string header to the free string header pool */
>+/* Add a PMC header to the free pool */
>  static void add_pmc_to_free(struct Parrot_Interp *interpreter,
>  struct free_pool *pool, void
>  *to_add) {
>PMC **temp_ptr;
>/* First, check and see if there's enough space in the free pool. If
>-   we're within the size of a STRING pointer, we make it bigger */
>+   we're within the size of a pointer, we make it bigger */
>if (pool->entries_in_pool * sizeof(PMC *) >=
>pool->pool_buffer.buflen - sizeof(PMC *)) {
>  /* If not, make the free pool bigger. We enlarge it by 20% */
>-pool->pool_buffer.bufstart = mem_realloc(interpreter,
>- pool->pool_buffer.bufstart,
>- pool->pool_buffer.buflen,
>-
>(UINTVAL)(pool->pool_buffer.buflen * 1.2));
>-pool->pool_buffer.buflen = (UINTVAL)(pool->pool_buffer.buflen * 1.2);
>-
>+size_t new_size = pool->pool_buffer.buflen * 1.2;
>+Parrot_reallocate(interpreter, &pool->pool_buffer, new_size);
>}
>
>/* Okay, so there's space. Add the header on */
>@@ -273,12 +269,8 @@
>if (pool->entries_in_pool * sizeof(STRING *) >=
>pool->pool_buffer.buflen - sizeof(STRING *)) {
>  /* If not, make the free pool bigger. We enlarge it by 20% */
>-pool->pool_buffer.bufstart = mem_realloc(interpreter,
>- pool->pool_buffer.bufstart,
>- pool->pool_buffer.buflen,
>-
>(UINTVAL)(pool->pool_buffer.buflen * 1.2));
>-pool->pool_buffer.buflen = (UINTVAL)(pool->pool_buffer.buflen * 1.2);
>-
>+size_t new_size = pool->pool_buffer.buflen * 1.2;
>+Parrot_reallocate(interpreter, &pool->pool_buffer, new_size);
>}
>
>/* Okay, so there's space. Add the header on */
>@@ -879,6 +871,25 @@
>  }
>}
>return (void *)return_val;
>+}
>+
>+/* Change the size of a buffer/string created by Parrot_allocate
>+   Input parameter is a pointer to the Buffer or String structure
>+   bufstart is updated to point to the new memory
>+   buflen is updated to the new length
>+   min(buflen,new_size) bytes are copied from old location to new location
>+*/
>+void
>+Parrot_reallocate(struct Parrot_Interp *interpreter, Buffer *buffer, size_t
>new_size) {
>+size_t copysize = (buffer->buflen > new_size ? new_size :
>buffer->buflen);
>+void *new_ptr = Parrot_allocate(interpreter, new_size);
>+if (!new_ptr) {
>+internal_exception(ALLOCATION_ERROR,
>+   "Out of memory during buffer reallocation");
>+}
>+memcpy(new_ptr, buffer->bufstart, copysize);
>+buffer->bufstart = new_ptr;
>+buffer->buflen = new_size;
>  }
>
>  /* Tag a buffer header as alive. Used by the GC system when tracing

Re: Bugfix release?

[Michel J Lambert]

> "Dan Sugalski" <[EMAIL PROTECTED]> wrote
>
> > With the recent stack and GC patches, are we pretty much solid now?
> > If so, a 0.0.5 bugfix release may well be in order.
>
> The one outstanding issue that I know of is the mem_realloc problem in
> add_pmc_to_free and add_header_to_free. Since the problem is actually
> endemic to mem_realloc, the best solution seems to be a replacement for
> mem_realloc that takes a Buffer*, so that an intervening GC run still leaves
> it knowing where the source is.
> In line with a previous suggestion, I propose that such a routine be called
> Parrot_reallocate.
> A patch to create such a function and use it within add_pmc_to_free and
> add_header_to_free follows; since all uses of mem_realloc are potentially at
> risk, it might be a good idea to change any such places also.

This patch looks good to me. It fixes the test case that was posted
earlier, and it's much better from a design standpoint than the previous
patch, which was withheld. I'm also working on code that builds off this
patch, so I'd appreciate if it was applied.

Thanks,
Mike Lambert

Re: Unicode thoughts...

[Jeff]

Dan Sugalski wrote:
> 
> At 10:07 AM -0500 3/30/02, Josh Wilmes wrote:
> >Someone said that ICU requires a C++ compiler.  That's concerning to me,
> >as is the issue of how we bootstrap our build process.  We were planning
> >on a platform-neutral miniparrot, and IMHO that can't include ICU (as i'm
> >sure it's not going to be written in pure ansi C)
> 
> If the C++ bits are redoable as C, I'm OK with it. I've not taken a
> good look at it to know how much it depends on C++. If it's mostly //
> comments and such we can work around the issues easily enough.
> 
> If its objects, well, I suppose it depends on how much it relies on them.

Looking at icu/common I see more .c files than .cpp files, and what .cpp
files there are look somewhat like wrappers around the C code. In
addition, the .cpp files appear to do such things as create iterator
wrappers, bidirectional display and normalization.

Some of the files are thicker than wrappers, but I think there's enough
code behind this C++ veneer that we can at least use it if not the
entire library.
--
Jeff <[EMAIL PROTECTED]>

RE: [preliminary PATCH] Parrot C Compiler Wrapper

[Brent Dax]

Nicholas Clark:
# On Sat, Mar 30, 2002 at 02:12:46AM -0800, Brent Dax wrote:
#
# > If you have a Unix box and ten spare minutes, please apply this to a
# > fresh checkout of Parrot, run 'make test', and tell me how well it
# > works.
#
# FreeBSD did not enjoy it:
#
# 0 Patch did not apply cleanly:
#
# Patching file Makefile.in using Plan A...
# Hunk #1 succeeded at 112.
# Hunk #2 failed at 143.

Weird.  Line endings, perhaps.

# I thought I managed to apply that bit by hand
#
# 1: use warnings; is not 5.005_03 safe:
#
# $ make test
# /usr/bin/perl vtable_h.pl
# /usr/bin/perl make_vtable_ops.pl > vtable.ops
# /usr/bin/perl pccw.pl --args="C" core_ops.c core.ops io.ops
# rx.ops vtable.ops
# Can't locate warnings.pm in @INC (@INC contains:
# /usr/libdata/perl/5.00503/mach /usr/libdata/perl/5.00503
# /usr/local/lib/perl5/site_perl/5.005/i386-freebsd
# /usr/local/lib/perl5/site_perl/5.005 .) at pccw.pl line 8.
# BEGIN failed--compilation aborted at pccw.pl line 8.
# *** Error code 2

D'oh!  Fortunately, that is the only 5.6-ism (AFAIK).

# So I stopped using 5.005_03 and switched to 5.7.3. After a
# reconfigure:
#
# $ make test
# /usr/local/bin/perl5.7.3 vtable_h.pl
# /usr/local/bin/perl5.7.3 pccw.pl --args="C" core_ops.c
# core.ops io.ops rx.ops vtable.ops
# Use of uninitialized value in hash element at pccw.pl line 35.
# cc -o --args=C -Wl,-E  -L/usr/local/lib  core_ops.c core.ops
# io.ops rx.ops vtable.ops
# cc: core_ops.c: No such file or directory
# /usr/local/bin/perl5.7.3 pccw.pl --args="CPrederef"
# core_ops_prederef.c core.ops io.ops rx.ops vtable.ops
# Use of uninitialized value in hash element at pccw.pl line 35.
# cc: core_ops_prederef.c: No such file or directory
#
# cc -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing
# -I/usr/local/include  -Wall -Wstrict-prototypes
# -Wmissing-prototypes -Winline -Wshadow -Wpointer-arith
# -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion
# -Waggregate-return -Winline -W -Wno-unused -Wsign-compare
# -I./include  -o interpreter.o -c interpreter.c
# interpreter.c:15: parrot/oplib/core_ops.h: No such file or directory
#
# 
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

#define private public
--Spotted in a C++ program just before a #include


#!perl -w

#Parrot C Compiler Wrapper
#Initial version by Brent Dax ([EMAIL PROTECTED])

#Usage:
#perl pccw.pl --args="(args)" (destfile) (sourcefiles)

use strict;

use lib 'lib';
use Parrot::Config;

my($args, $destfile, @sourcefiles);

if($ARGV[0] =~ /--args="(.*)"/) {
$args=$1;
shift;
}
else {
$args="";
}

($destfile, @sourcefiles)=@ARGV;

my %destmap=(
$PConfig{o} => sub { System("$PConfig{cc} $PConfig{ccflags} 
$PConfig{cc_warn} $PConfig{cc_inc} $args $PConfig{cc_o_out}$destfile -c @sourcefiles") 
},
$PConfig{exe}||''   => sub { System("$PConfig{ld} 
$PConfig{ld_out}$destfile $PConfig{ldflags} $args @sourcefiles") },
$PConfig{a}||'.a'   => \&handle_library,
$PConfig{so}||'.so' => \&handle_shared_lib, 
'.c'=> \&handle_generated_files
);

eval {
my($extension)=$destfile =~ /(\.\w+)$/;
$extension ||= '';
$destmap{$extension}->();
};

if($@) {
if($@ =~ /Undefined subroutine/) {
print "Don't know how to convert '$sourcefiles[0]' to '$destfile'!\n";
}
else {
die $@, "\n";
}

exit(-1);
}

exit($?);

sub handle_generated_files {
if($sourcefiles[0] =~ /ops$/) {
system("$^X ops2c.pl $args @sourcefiles");
}
elsif($sourcefiles[0] =~ /pmc$/) {
system("$^X classes/pmc2c.pl $args @sourcefiles");
}
else {
print "Don't know how to convert '$sourcefiles[0]' to '$destfile'!\n";
}
}

sub handle_shared_lib {
print "NYI";
}

sub handle_library {
print "NYI";
}

sub System {
print "$_[0]\n";
$?=system(@_);
}

Re: [preliminary PATCH] Parrot C Compiler Wrapper

[Nicholas Clark]

On Sat, Mar 30, 2002 at 02:12:46AM -0800, Brent Dax wrote:

> If you have a Unix box and ten spare minutes, please apply this to a
> fresh checkout of Parrot, run 'make test', and tell me how well it
> works.

FreeBSD did not enjoy it:

0 Patch did not apply cleanly:

Patching file Makefile.in using Plan A...
Hunk #1 succeeded at 112.
Hunk #2 failed at 143.

I thought I managed to apply that bit by hand

1: use warnings; is not 5.005_03 safe:

$ make test
/usr/bin/perl vtable_h.pl
/usr/bin/perl make_vtable_ops.pl > vtable.ops
/usr/bin/perl pccw.pl --args="C" core_ops.c core.ops io.ops rx.ops vtable.ops
Can't locate warnings.pm in @INC (@INC contains: /usr/libdata/perl/5.00503/mach 
/usr/libdata/perl/5.00503 /usr/local/lib/perl5/site_perl/5.005/i386-freebsd 
/usr/local/lib/perl5/site_perl/5.005 .) at pccw.pl line 8.
BEGIN failed--compilation aborted at pccw.pl line 8.
*** Error code 2

So I stopped using 5.005_03 and switched to 5.7.3. After a reconfigure:

$ make test
/usr/local/bin/perl5.7.3 vtable_h.pl
/usr/local/bin/perl5.7.3 pccw.pl --args="C" core_ops.c core.ops io.ops rx.ops 
vtable.ops
Use of uninitialized value in hash element at pccw.pl line 35.
cc -o --args=C -Wl,-E  -L/usr/local/lib  core_ops.c core.ops io.ops rx.ops vtable.ops
cc: core_ops.c: No such file or directory
/usr/local/bin/perl5.7.3 pccw.pl --args="CPrederef" core_ops_prederef.c core.ops 
io.ops rx.ops vtable.ops
Use of uninitialized value in hash element at pccw.pl line 35.
cc: core_ops_prederef.c: No such file or directory

cc -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -I/usr/local/include  
-Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wshadow -Wpointer-arith 
-Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Winline -W 
-Wno-unused -Wsign-compare  -I./include  -o interpreter.o -c interpreter.c
interpreter.c:15: parrot/oplib/core_ops.h: No such file or directory

http://nms-cgi.sourceforge.net/

Re: Bugfix release?

[Dan Sugalski]

At 6:45 PM + 3/30/02, Nicholas Clark wrote:
>On Sat, Mar 30, 2002 at 10:52:35AM -0500, Melvin Smith wrote:
>>  At 09:38 AM 3/30/2002 -0500, Dan Sugalski wrote:
>>  >With the recent stack and GC patches, are we pretty much solid now? If so,
>>  >a 0.0.5 bugfix release may well be in order.
>>
>>  My crashme program crashes no more, we are 10x more stable than
>>  a week ago. I think Peter's patch or a variation is in order, and I'm also
>>  working
>>  on a new crashme :)
>>
>>  Bring on 0.0.5
>
>Peter's made it foolproof, so Melvin is about to build a better fool? :-)
>Long may this arms race continue.

We can always use a higher-class of fool, that's for sure. :)
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: Unicode thoughts...

[Dan Sugalski]

At 10:07 AM -0500 3/30/02, Josh Wilmes wrote:
>Someone said that ICU requires a C++ compiler.  That's concerning to me,
>as is the issue of how we bootstrap our build process.  We were planning
>on a platform-neutral miniparrot, and IMHO that can't include ICU (as i'm
>sure it's not going to be written in pure ansi C)

If the C++ bits are redoable as C, I'm OK with it. I've not taken a 
good look at it to know how much it depends on C++. If it's mostly // 
comments and such we can work around the issues easily enough.

If its objects, well, I suppose it depends on how much it relies on them.

>At 8:45 on 03/30/2002 EST, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
>>  At 4:32 PM -0800 3/25/02, Brent Dax wrote:
>>  >I *really* strongly suggest we include ICU in the distribution.  I
>>  >recently had to turn off mod_ssl in the Apache 2 distro because I
>>  >couldn't get OpenSSL downloaded and configured.
>>
>>  FWIW, ICU in the distribution is a given if we use it.
>>
>>  Parrot will require a C compiler and link tools (maybe make, but
>>  maybe not) to build on a target platform and nothing else. If we rely
>  > on ICU we must ship with it.

-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: Bugfix release?

[Nicholas Clark]

On Sat, Mar 30, 2002 at 10:52:35AM -0500, Melvin Smith wrote:
> At 09:38 AM 3/30/2002 -0500, Dan Sugalski wrote:
> >With the recent stack and GC patches, are we pretty much solid now? If so, 
> >a 0.0.5 bugfix release may well be in order.
> 
> My crashme program crashes no more, we are 10x more stable than
> a week ago. I think Peter's patch or a variation is in order, and I'm also 
> working
> on a new crashme :)
> 
> Bring on 0.0.5

Peter's made it foolproof, so Melvin is about to build a better fool? :-)
Long may this arms race continue.

Nicholas Clark
-- 
Even better than the real thing:http://nms-cgi.sourceforge.net/

Re: Bugfix release?

[Steve Fink]

On Sat, Mar 30, 2002 at 10:47:11AM -0800, Steve Fink wrote:
> On Sat, Mar 30, 2002 at 09:38:31AM -0500, Dan Sugalski wrote:
> > With the recent stack and GC patches, are we pretty much solid now? 
> > If so, a 0.0.5 bugfix release may well be in order.
> > -- 
> 
> I'm still getting a test failure on stacks.t, in test #7. Until that's
> fixed, I'm holding off committing Michel Lambert's CGoto.pm patch.

Ok, never mind. For whatever reason, I'm not getting the test failure
anymore. I didn't think it touched any common code, but perhaps the
patch fixed it?

I just committed the patch.

Re: Bugfix release?

[Steve Fink]

On Sat, Mar 30, 2002 at 09:38:31AM -0500, Dan Sugalski wrote:
> With the recent stack and GC patches, are we pretty much solid now? 
> If so, a 0.0.5 bugfix release may well be in order.
> -- 

I'm still getting a test failure on stacks.t, in test #7. Until that's
fixed, I'm holding off committing Michel Lambert's CGoto.pm patch.

I'd also like to get my patch for core key support committed for
0.0.5, but I don't want to commit it either when tests are failing. It
is necessary for accessing command-line arguments and for the group
stuff to work in rx.ops. (And it makes PerlArrays usable, which is
very helpful for other development.)

-- 
WM ISO JOB. http://foxglove.dnsalias.org/~sfink/job.html
C, perl, networking, performance optimization, Java, XML.

Test failing!

[Steve Fink]

Test 7 of t/op/stacks.t is failing for me right now. It fails even
when I back up to version 1.25 of stacks.c, and anything earlier
doesn't compile (without backing up other files too).

[I sent this out last night, but a word of advice: don't do
development on your active mail server!]

Re: Bugfix release?

[Melvin Smith]

At 09:38 AM 3/30/2002 -0500, Dan Sugalski wrote:
>With the recent stack and GC patches, are we pretty much solid now? If so, 
>a 0.0.5 bugfix release may well be in order.

My crashme program crashes no more, we are 10x more stable than
a week ago. I think Peter's patch or a variation is in order, and I'm also 
working
on a new crashme :)

Bring on 0.0.5

-Melvin

Re: [APPLIED] Frame stack patch

[Melvin Smith]

At 09:09 AM 3/30/2002 -0500, Dan Sugalski wrote:
>At 1:03 AM -0500 3/30/02, Melvin Smith wrote:
>>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.
>
>If someone's feeling ambitious, code to check the number of unused chunks 
>may be in order--that way if we have more than N unused chunks we can free 
>the excess. (For those cases where the stack gets massively, but rarely, blown)

I almost did this but decided to call it a night.

I was thinking along the lines of a resource limit similar to the JVM
where we can pass in optimal and maximum stack sizes. We'd
just need a chunk counter in the chunk member and multiply it
times the frames per chunk. For a tuning configurable it would
be nice to modify FRAMES_PER_CHUNK at compile time.

Max stack size is a good check against spiralling death syndrome
because I can say, "Ok for this particular production app, there should
never be a possibility of a depth of 1000 frames so if we ever get
there dump a bytecode image before we get to 2000, 3000, 1
and end up thrashing the system or dumping a 1Gb core the hard way."

-Melvin

Re: Unicode thoughts...

[Josh Wilmes]

Someone said that ICU requires a C++ compiler.  That's concerning to me, 
as is the issue of how we bootstrap our build process.  We were planning 
on a platform-neutral miniparrot, and IMHO that can't include ICU (as i'm 
sure it's not going to be written in pure ansi C)

--Josh

At 8:45 on 03/30/2002 EST, Dan Sugalski <[EMAIL PROTECTED]> wrote:

> At 4:32 PM -0800 3/25/02, Brent Dax wrote:
> >I *really* strongly suggest we include ICU in the distribution.  I
> >recently had to turn off mod_ssl in the Apache 2 distro because I
> >couldn't get OpenSSL downloaded and configured.
> 
> FWIW, ICU in the distribution is a given if we use it.
> 
> Parrot will require a C compiler and link tools (maybe make, but 
> maybe not) to build on a target platform and nothing else. If we rely 
> on ICU we must ship with it.
> -- 
>  Dan
> 
> --"it's like this"---
> Dan Sugalski  even samurai
> [EMAIL PROTECTED] have teddy bears and even
>teddy bears get drunk

Re: [preliminary PATCH] Parrot C Compiler Wrapper

[Josh Wilmes]

I've been thinking along these lines, but I'd decided on a different 
approach.  I think that it's better to keep the magic to a minimum.  
Rather than relying on extensions, I was thinking about having a different 
wrapper for each task:

- lib.pl: build static library from object files

  example:
lib.pl --out=libfoo.a foo.o bar.o

- shlib.pl: build dynamic library from object files and libraries

   example:
shlib.pl --out=libfoo.so.1.1 --soname=libfoo.so.1 -Llib -llib foo.o bar.o 

- compile.pl: build .o file from .c file

   example:
compile.pl --out=foo.o -DA=B -UC foo.c

- link.pl: build executable from .o files and libraries

   example:
link.pl --out=foo -Llib -llib foo.o bar.o 

These wrappers would add compiler-specific flags only, and would accept 
compiler-neutral options only.  We'd not want to pass through arbitrary 
command line arguments to the underlying compiler, as that is bound to 
break somewhere.   So IMHO the wrapper needs to have well-defined 
arguments that it accepts, so that it can rewrite them as needed for weird 
platforms.  In the examples above, I used some familiar flags (-D, -L, 
-l), but I still would have the wrapper intercept and potentially rewrite 
them.

Note that the wrappers would always add standard flags which control 
compiler behavior (for example warnings for gcc), but would NOT add things 
like extra libraries to link in or extra defines for compilation.  Those 
should be passed on the command line for flexibility.  That is, we 
shouldn't blindly tack on ccflags or ldflags in the wrappers.

--Josh

At 2:12 on 03/30/2002 PST, "Brent Dax" <[EMAIL PROTECTED]> wrote:

> This patch adds a new utility to Parrot and modifies Makefile.in to use
> it.  The utility is for wrapping C compilers and other tools we use, so
> we can avoid putting the logic in the Makefile and can potentially use
> totally different commands on different platforms.
> 
> The patch is by no means ready to be applied to the source tree--it
> doesn't touch the shared lib stuff, an important test needs to be added
> to Configure, and I haven't even tried it on a Unix.  The ability to
> create libraries, both static and dynamic, is missing.  But you should
> be able to build your basic Parrot with this.
> 
> If you have a Unix box and ten spare minutes, please apply this to a
> fresh checkout of Parrot, run 'make test', and tell me how well it
> works.
> 
> As for the tool itself:
> 
> pccw.pl is a small script that implements a wrapper around several
> tools.  You use it like this:
> 
>   perl pccw.pl [--args="(arguments)"] (destination file) (source files)
> 
> pccw.pl examines the extension of the destination file and uses that to
> pick what to do.  If the extension is '.c', then it examines the source
> files and runs either ops2c or pmc2c as appropriate; otherwise it runs
> the appropriate compiler or linker incantations.  The --args argument is
> used to pass additional flags to the tool.
> 
> Patch is attached.  Share and enjoy.
> 
> --Brent Dax <[EMAIL PROTECTED]>
> @roles=map {"Parrot $_"} qw(embedding regexen Configure)
> 
> #define private public
> --Spotted in a C++ program just before a #include
> 

Re: Bugfix release?

[Peter Gibbs]

"Dan Sugalski" <[EMAIL PROTECTED]> wrote

> With the recent stack and GC patches, are we pretty much solid now?
> If so, a 0.0.5 bugfix release may well be in order.

The one outstanding issue that I know of is the mem_realloc problem in
add_pmc_to_free and add_header_to_free. Since the problem is actually
endemic to mem_realloc, the best solution seems to be a replacement for
mem_realloc that takes a Buffer*, so that an intervening GC run still leaves
it knowing where the source is.
In line with a previous suggestion, I propose that such a routine be called
Parrot_reallocate.
A patch to create such a function and use it within add_pmc_to_free and
add_header_to_free follows; since all uses of mem_realloc are potentially at
risk, it might be a good idea to change any such places also.

--
Peter Gibbs
EmKel Systems

Index: include/parrot/resources.h
===
RCS file: /home/perlcvs/parrot/include/parrot/resources.h,v
retrieving revision 1.25
diff -u -r1.25 resources.h
--- include/parrot/resources.h  18 Mar 2002 22:09:10 -  1.25
+++ include/parrot/resources.h  30 Mar 2002 14:58:26 -
@@ -31,6 +31,7 @@

 void *Parrot_allocate(struct Parrot_Interp *, size_t size);
 void *Parrot_alloc_new_block(struct Parrot_Interp *, size_t, UINTVAL);
+void Parrot_reallocate(struct Parrot_Interp *, Buffer *, size_t);

 void Parrot_new_pmc_header_arena(struct Parrot_Interp *interpreter);

Index: resources.c
===
RCS file: /home/perlcvs/parrot/resources.c,v
retrieving revision 1.37
diff -u -r1.37 resources.c
--- resources.c 30 Mar 2002 05:57:32 - 1.37
+++ resources.c 30 Mar 2002 14:57:38 -
@@ -18,22 +18,18 @@
 static void add_header_to_free(struct Parrot_Interp *interpreter,
struct free_pool *pool, void *to_add);

-/* Add a string header to the free string header pool */
+/* Add a PMC header to the free pool */
 static void add_pmc_to_free(struct Parrot_Interp *interpreter,
 struct free_pool *pool, void
 *to_add) {
   PMC **temp_ptr;
   /* First, check and see if there's enough space in the free pool. If
-   we're within the size of a STRING pointer, we make it bigger */
+   we're within the size of a pointer, we make it bigger */
   if (pool->entries_in_pool * sizeof(PMC *) >=
   pool->pool_buffer.buflen - sizeof(PMC *)) {
 /* If not, make the free pool bigger. We enlarge it by 20% */
-pool->pool_buffer.bufstart = mem_realloc(interpreter,
- pool->pool_buffer.bufstart,
- pool->pool_buffer.buflen,
-
(UINTVAL)(pool->pool_buffer.buflen * 1.2));
-pool->pool_buffer.buflen = (UINTVAL)(pool->pool_buffer.buflen * 1.2);
-
+size_t new_size = pool->pool_buffer.buflen * 1.2;
+Parrot_reallocate(interpreter, &pool->pool_buffer, new_size);
   }

   /* Okay, so there's space. Add the header on */
@@ -273,12 +269,8 @@
   if (pool->entries_in_pool * sizeof(STRING *) >=
   pool->pool_buffer.buflen - sizeof(STRING *)) {
 /* If not, make the free pool bigger. We enlarge it by 20% */
-pool->pool_buffer.bufstart = mem_realloc(interpreter,
- pool->pool_buffer.bufstart,
- pool->pool_buffer.buflen,
-
(UINTVAL)(pool->pool_buffer.buflen * 1.2));
-pool->pool_buffer.buflen = (UINTVAL)(pool->pool_buffer.buflen * 1.2);
-
+size_t new_size = pool->pool_buffer.buflen * 1.2;
+Parrot_reallocate(interpreter, &pool->pool_buffer, new_size);
   }

   /* Okay, so there's space. Add the header on */
@@ -879,6 +871,25 @@
 }
   }
   return (void *)return_val;
+}
+
+/* Change the size of a buffer/string created by Parrot_allocate
+   Input parameter is a pointer to the Buffer or String structure
+   bufstart is updated to point to the new memory
+   buflen is updated to the new length
+   min(buflen,new_size) bytes are copied from old location to new location
+*/
+void
+Parrot_reallocate(struct Parrot_Interp *interpreter, Buffer *buffer, size_t
new_size) {
+size_t copysize = (buffer->buflen > new_size ? new_size :
buffer->buflen);
+void *new_ptr = Parrot_allocate(interpreter, new_size);
+if (!new_ptr) {
+internal_exception(ALLOCATION_ERROR,
+   "Out of memory during buffer reallocation");
+}
+memcpy(new_ptr, buffer->bufstart, copysize);
+buffer->bufstart = new_ptr;
+buffer->buflen = new_size;
 }

 /* Tag a buffer header as alive. Used by the GC system when tracing

Re: Stack sorting

[Dan Sugalski]

At 8:58 AM -0500 3/26/02, Clinton A. Pierce wrote:
>I took one of the smaller problems from the BASIC interpreter, 
>sorting the stack, and posed it as a question on PerlMonks to see 
>how a Mongolian Horde would handle the problem.  The results are at:
>
>http://www.perlmonks.org/index.pl?node_id=153974
>
>Summary: the only apparent way to do this trick is with a variation 
>of a bubble sort (which I already had) given that there's only one 
>user stack and three stack instructions (save, restore, rotate_up). 
>A quicksort solution was posted, except that without being able to 
>randomly address the stack it's nearly as bad as a bubblesort.

Hrm. I'm not sure if random access to stack entries is worth the 
hassle, but I'm not against it either if someone would care to whip 
up a C opcode. (Suggestions for storage op names are welcome, 
and no, poke doesn't do it)

Having a stack entry swap opcode is probably in order too.

-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Bugfix release?

[Dan Sugalski]

With the recent stack and GC patches, are we pretty much solid now? 
If so, a 0.0.5 bugfix release may well be in order.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: Potential Memory Leaks

[Dan Sugalski]

At 4:43 AM -0500 3/26/02, Michel J Lambert wrote:
>Am I correct in assuming that the stacks stuff leaks memory? Both stacks.c
>and rxstacks.c allocate memory via mem_allocate_aligned, but never free
>it, relying on the GC for it (code written before the GC existed).
>
>Should these stacks be changed to use a buffers system, or should they be
>changed to free their own chunks on certain pops? Following the logic in
>register.c, which handles it's own memory of register stack chunks, I
>would guess the latter, although there might be a performance gain if it
>can reuse these chunks via the GC.

While it's a little late as there are stack patches in already, the 
stack stuff should free its memory when its done with it. (Though I 
could argue that some sort of stack chunk arena system would be in 
order. I'm not sure the complexity is warranted,t hough)

>Finally, I'd also argue for a renaming or #defining of mem_realloc to
>Parrot_reallocate, to match Parrot_allocate. At first glance, I thought
>mem_alloc punted down to the native realloc routines, and it was
>reallocing GC-managed memory. :)

Good point. Yes, we should.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: [APPLIED] Frame stack patch

[Dan Sugalski]

At 1:03 AM -0500 3/30/02, Melvin Smith wrote:
>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.

If someone's feeling ambitious, code to check the number of unused 
chunks may be in order--that way if we have more than N unused chunks 
we can free the excess. (For those cases where the stack gets 
massively, but rarely, blown)
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

RE integer stack

[Dan Sugalski]

I'm going through the current RE ops looking to see what should get 
pulled out and used as part of the generic interpreter core. There's 
an integer stack the RE code uses for speed purposes, which is a cool 
thing, but there seems to be a private one for each RE object. Do we 
need this, or would a single integer stack  as part of the core do?
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: Computed-goto Patch

[Dan Sugalski]

At 11:19 AM -0800 3/29/02, Steve Fink wrote:
>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 name
>>  - fixed pbc2c.pl
>>  - should have unix line endings
>>
>>  Please let me know if there are any other issues which need addressing.
>>
>>  Mike Lambert
>
>I looked through this, and will commit it today unless someone objects.

Go ahead and commit it.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

RE: Unicode thoughts...

[Dan Sugalski]

At 4:32 PM -0800 3/25/02, Brent Dax wrote:
>I *really* strongly suggest we include ICU in the distribution.  I
>recently had to turn off mod_ssl in the Apache 2 distro because I
>couldn't get OpenSSL downloaded and configured.

FWIW, ICU in the distribution is a given if we use it.

Parrot will require a C compiler and link tools (maybe make, but 
maybe not) to build on a target platform and nothing else. If we rely 
on ICU we must ship with it.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

[preliminary PATCH] Parrot C Compiler Wrapper

[Brent Dax]

This patch adds a new utility to Parrot and modifies Makefile.in to use
it.  The utility is for wrapping C compilers and other tools we use, so
we can avoid putting the logic in the Makefile and can potentially use
totally different commands on different platforms.

The patch is by no means ready to be applied to the source tree--it
doesn't touch the shared lib stuff, an important test needs to be added
to Configure, and I haven't even tried it on a Unix.  The ability to
create libraries, both static and dynamic, is missing.  But you should
be able to build your basic Parrot with this.

If you have a Unix box and ten spare minutes, please apply this to a
fresh checkout of Parrot, run 'make test', and tell me how well it
works.

As for the tool itself:

pccw.pl is a small script that implements a wrapper around several
tools.  You use it like this:

perl pccw.pl [--args="(arguments)"] (destination file) (source files)

pccw.pl examines the extension of the destination file and uses that to
pick what to do.  If the extension is '.c', then it examines the source
files and runs either ops2c or pmc2c as appropriate; otherwise it runs
the appropriate compiler or linker incantations.  The --args argument is
used to pass additional flags to the tool.

Patch is attached.  Share and enjoy.

--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

#define private public
--Spotted in a C++ program just before a #include


Index: MANIFEST
===
RCS file: /home/perlcvs/parrot/MANIFEST,v
retrieving revision 1.132
diff -u -r1.132 MANIFEST
--- MANIFEST20 Mar 2002 06:27:35 -  1.132
+++ MANIFEST30 Mar 2002 09:53:36 -
@@ -250,6 +250,7 @@
 packout.c
 parrot.c
 pbc2c.pl
+pccw.pl
 pdump.c
 platforms/generic.c
 platforms/generic.h
Index: Makefile.in
===
RCS file: /home/perlcvs/parrot/Makefile.in,v
retrieving revision 1.141
diff -u -r1.141 Makefile.in
--- Makefile.in 21 Mar 2002 23:47:22 -  1.141
+++ Makefile.in 30 Mar 2002 09:53:37 -
@@ -112,6 +112,8 @@
 LD = ${ld}
 PERL = ${perl}
 
+PCCW = $(PERL) pccw.pl
+
 
 ###
 #
@@ -141,17 +143,17 @@
 ${make_set_make}
 
 .c$(O):
-   $(CC) $(CFLAGS) ${cc_o_out}$@ -c $<
+   $(PCCW) $@ $<
 
 all : $(TEST_PROG) docs
 
 mops: examples/assembly/mops${exe} examples/mops/mops${exe}
 
 libparrot$(A) : $(O_FILES)
-   $(AR_CRS) $@ $(O_FILES)
+   $(PCCW) $@ $(O_FILES)
 
 $(TEST_PROG): test_main$(O) $(GEN_HEADERS) $(O_FILES) lib/Parrot/OpLib/core.pm 
lib/Parrot/PMC.pm
-   $(LD) ${ld_out}$(TEST_PROG) $(LDFLAGS) $(O_FILES) test_main$(O) $(C_LIBS)
+   $(PCCW) $(TEST_PROG) $(O_FILES) test_main$(O) $(C_LIBS)
 
 lib_deps_object: $(O_FILES)
$(PERL) lib_deps.pl object $(O_FILES)
@@ -253,7 +255,7 @@
$(PERL) pbc2c.pl examples/assembly/mops.pbc > examples/assembly/mops.c
 
 examples/assembly/mops${exe}: examples/assembly/mops$(O) $(O_FILES)
-   $(LD) $(LDFLAGS) ${ld_out}examples/assembly/mops${exe} 
examples/assembly/mops$(O) $(O_FILES) $(C_LIBS)
+   $(PCCW) examples/assembly/mops${exe} examples/assembly/mops$(O) $(O_FILES) 
+$(C_LIBS)
 
 examples/assembly/life.pbc: examples/assembly/life.pasm assemble.pl
cd examples && cd assembly && $(MAKE) life.pbc PERL=$(PERL) && cd .. && cd ..
@@ -262,7 +264,7 @@
$(PERL) pbc2c.pl examples/assembly/life.pbc > examples/assembly/life.c
 
 examples/assembly/life${exe}: examples/assembly/life$(O) $(O_FILES)
-   $(LD) $(LDFLAGS) ${ld_out}examples/assembly/life${exe} 
examples/assembly/life$(O) $(O_FILES) $(C_LIBS)
+   $(PCCW) examples/assembly/life${exe} examples/assembly/life$(O) $(O_FILES) 
+$(C_LIBS)
 
 ###
 #
@@ -273,7 +275,7 @@
 examples/mops/mops$(O): examples/mops/mops.c
 
 examples/mops/mops${exe}: examples/mops/mops$(O) platform$(O)
-   $(LD) $(LDFLAGS) ${ld_out}examples/mops/mops${exe} examples/mops/mops$(O) 
platform$(O) $(C_LIBS)
+   $(PCCW) examples/mops/mops${exe} examples/mops/mops$(O) platform$(O) $(C_LIBS)
 
 
 ###
@@ -345,12 +347,12 @@
 core_ops$(O): $(GENERAL_H_FILES) core_ops.c
 
 core_ops.c $(INC)/oplib/core_ops.h: $(OPS_FILES) ops2c.pl lib/Parrot/OpsFile.pm 
lib/Parrot/Op.pm
-   $(PERL) ops2c.pl C $(OPS_FILES)
+   $(PCCW) --args="C" core_ops.c $(OPS_FILES)
 
 core_ops_prederef$(O): $(GENERAL_H_FILES) core_ops_prederef.c
 
 core_ops_prederef.c $(INC)/oplib/core_ops_prederef.h: $(OPS_FILES) ops2c.pl 
lib/Parrot/OpsFile.pm lib/Parrot/Op.pm
-   $(PERL) ops2c.pl CPrederef $(OPS_FILES)
+   $(PCCW) --args="CPrederef" core_ops_prederef.c $(OPS_FILES)
 
 warnings$(O): $(H_FILES)
 
--- /dev/null   Sat Mar 30 02:01:34 2002
+++ pccw.pl Sat Mar 30 01: