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
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
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
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
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
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
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
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:
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
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
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
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
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,
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!]
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
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
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
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
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
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
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:
#
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
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
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
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
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
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
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
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
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
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
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
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
33 matches
Mail list logo
