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
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
# > > th
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
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 an
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
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- asse
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 hea
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
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
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
> > Too late. I'm going there... :)
> Good for you. I was hoping transformations could make it :)
Why didn't you chime in support before, then? I feel like Aaron and I are
the only ones who are opinionated on this matter...
> Here's something I was wondering. Say you wanted to write a pow() macr
> "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 th
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'
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:
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 usi
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.
>>
>
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 wr
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 s
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 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
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!]
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,
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 nu
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/3
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
examp
"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 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
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
[E
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 chang
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
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 woul
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:
>>
>> - rem
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 re
On Fri, Mar 29, 2002 at 11:23:26PM -0700, Luke Palmer wrote:
> > Too late. I'm going there... :)
> Good for you. I was hoping transformations could make it :)
>
> Here's something I was wondering. Say you wanted to write a pow() macro
> (from a previous example) that would forward to C's pow() u
Michel J Lambert wrote in perl.perl6.language :
> Has anyone done any thinking along the
> lines of how we are implementing the Perl 6 grammer?
Simon Cozens did. I don't know the details exactly.
Note also that the grammar and the parser are not the difficult part;
the perl 5 lexer is very compl
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
36 matches
Mail list logo