Here are a few of the more clear-cut fixes I noticed from -Wall's whinings.
Index: key.c
===
RCS file: /home/perlcvs/parrot/key.c,v
retrieving revision 1.2
diff -u -r1.2 key.c
- --- key.c 12 Dec 2001 02:52:52 - 1.2
+++
Here's a minor patch which should make purify happy. (passing in 0 for
the length was causing an "ABR" error).
cvs server: Diffing .
Index: core.ops
===
RCS file: /home/perlcvs/parrot/core.ops,v
retrieving revision 1.46
diff -u -r
Dan Sugalski wrote:
>
> At 05:40 PM 12/12/2001 -0800, Robert Spier wrote:
> >| patches integrated in soon, and a longer-term solution (i.e. a perl make)
> >| should be ready not too long after that.
> >
> >bool query {
> > Dan, you've been unclear. Is a perl5 based make system
> >where you wa
Caveats from the commit mail are roughly as follows:
Nearly-complete 'make' replacement in perl.
Non-compliant bits - Takes absolutely -NO- special flags...
- Dies on undefined macros such as $(PDISASM) in
current make
- Dies on recursive macro expansions
At 05:40 PM 12/12/2001 -0800, Robert Spier wrote:
>| patches integrated in soon, and a longer-term solution (i.e. a perl make)
>| should be ready not too long after that.
>
>bool query {
> Dan, you've been unclear. Is a perl5 based make system
>where you want to be today?
>}
Perl, yes. At the
| patches integrated in soon, and a longer-term solution (i.e. a perl make)
| should be ready not too long after that.
bool query {
Dan, you've been unclear. Is a perl5 based make system
where you want to be today?
}
-R
At 08:12 PM 12/12/2001 -0500, [EMAIL PROTECTED] wrote:
>Dan wrote:
> >># In lieu of a de-allocator for mem_allocate_aligned I vote
> >># we at least do something in the interim and I volunteer to
> >># help as soon as someone decides what it is!
> >>
> >>Maybe we can have a mem_free_aligned that s
At 05:14 PM 12/12/2001 -0800, Brent Dax wrote:
>Thinking about it, this could be implemented as a source filter.
>
> target("foo.$o", sub {print "yup"}, depends => ["bar.$o", "baz.c"]);
> #other targets here
> do_the_make_stuff();
>
>A P::RD grammar would probably handle th
Dan wrote:
>># In lieu of a de-allocator for mem_allocate_aligned I vote
>># we at least do something in the interim and I volunteer to
>># help as soon as someone decides what it is!
>>
>>Maybe we can have a mem_free_aligned that somehow figures out what the
>>starting address is. If we do that a
Michael G Schwern:
# On Wed, Dec 12, 2001 at 01:58:49PM -0500, Dan Sugalski wrote:
# > At 08:54 PM 12/12/2001 +0200, Jaen Saul wrote:
# > >Well, another small post again :)
# > >As you see, -C doesn't do anything useful on NMAKE. So
# Win32 is still
# > >broken. The -C way doesn't work.
# >
# > VM
At 07:39 PM 12/12/2001 -0500, Michael G Schwern wrote:
>On Wed, Dec 12, 2001 at 01:58:49PM -0500, Dan Sugalski wrote:
> > At 08:54 PM 12/12/2001 +0200, Jaen Saul wrote:
> > >Well, another small post again :)
> > >As you see, -C doesn't do anything useful on NMAKE. So Win32 is still
> > >broken. Th
At 04:29 PM 12/12/2001 -0800, Brent Dax wrote:
>[EMAIL PROTECTED]:
># In lieu of a de-allocator for mem_allocate_aligned I vote
># we at least do something in the interim and I volunteer to
># help as soon as someone decides what it is!
>
>Maybe we can have a mem_free_aligned that somehow figures
At 05:20 PM 12/12/2001 -0500, [EMAIL PROTECTED] wrote:
> >The only thing that needs the allocated alignment is some of the internal
> >pieces--the stack chunks and register frames, really. Everything else can
> >use a plain malloc. Well, mem_allocate, rather, which can be a wrapper
>around malloc
Now that PMCs are perl-like, it's about time to start language
development.
Currently it's sophisticated enough to be able to compile and run the
following perl{56} code:
my ($a,$b);
$b="foo";
$a=-71.5;
print $a;
print $b;
But that will change soon. There aren't any tests currently, awaiting a
On Wed, Dec 12, 2001 at 01:58:49PM -0500, Dan Sugalski wrote:
> At 08:54 PM 12/12/2001 +0200, Jaen Saul wrote:
> >Well, another small post again :)
> >As you see, -C doesn't do anything useful on NMAKE. So Win32 is still
> >broken. The -C way doesn't work.
>
> VMS is broken this way too, as is an
[EMAIL PROTECTED]:
# In lieu of a de-allocator for mem_allocate_aligned I vote
# we at least do something in the interim and I volunteer to
# help as soon as someone decides what it is!
Maybe we can have a mem_free_aligned that somehow figures out what the
starting address is. If we do that and
--- Andy Dougherty <[EMAIL PROTECTED]> wrote:
> One idiom which might work is
>
> cd foo && $(MAKE)
>
> Since lines in makefiles are handed off to the native
> shell, this will
> be dependent upon the user's native shell. I don't know
> any details,
> but I gather the various shells in Wi
>The only thing that needs the allocated alignment is some of the internal
>pieces--the stack chunks and register frames, really. Everything else can
>use a plain malloc. Well, mem_allocate, rather, which can be a wrapper
around malloc for now.
>
>Dan
Maybe we can do this for now?
-Melvin
---
At 05:04 PM 12/12/2001 -0500, [EMAIL PROTECTED] wrote:
>At minimum we should be using plain malloc() until a
>better solution or the current one is finished, else
>right now we have a glaring memory leak for ops that
>need to destroy strings.
>
>Can't the current function be at least tweaked so it
In lieu of a de-allocator for mem_allocate_aligned I vote
we at least do something in the interim and I volunteer to
help as soon as someone decides what it is!
I know GC is on the way but...
At minimum we should be using plain malloc() until a
better solution or the current one is finished, els
Here is a start for the IO skeleton. I implemented
open, close, read, write, setbuf and some constants in io.h
-Implements a simple ParrotIO PMC with null vtable
-open() takes a string for mode which is Perl-ish (<, >, >>, |, +>, +<)
Comments? Would the group prefer numeric constants here?
At 08:54 PM 12/12/2001 +0200, Jaen Saul wrote:
>Well, another small post again :)
>As you see, -C doesn't do anything useful on NMAKE. So Win32 is still
>broken. The -C way doesn't work.
VMS is broken this way too, as is anything without GNU make. We'll get your
patches integrated in soon, and a
Well, another small post again :)
As you see, -C doesn't do anything useful on NMAKE. So Win32 is still
broken. The -C way doesn't work.
---snip---
Usage: NMAKE @commandfile
NMAKE [options] [/f makefile] [/x stderrfile] [macrodefs] [targets]
Options:
/A Build all evaluated targets
/B B
We do have an RT system set up to track bugs and feature requests and todo
lists and such for Parrot. http://bugs6.perl.org. Anything broken, missing,
or odd should go in there.
Dan
--"it's like this"--
At 08:16 PM 12/12/2001 +0200, Jaen Saul wrote:
>At the state that things are now, trying to 'nmake clean' (Win32) will
>create an endless loop, eat up all your memory, and crash your computer.
D'oh! Temp patch applied. Thanks.
Dan
---
At the state that things are now, trying to 'nmake clean' (Win32) will
create an endless loop, eat up all your memory, and crash your computer. I
had about 500MB of memory available so it didn't crash mine fortunately :)
On other platforms it will just exit with an error.
I have a patch for this,
On Wed, 12 Dec 2001, Dan Sugalski wrote:
> At 10:31 AM 12/12/2001 -0500, Andy Dougherty wrote:
> >Most 'makes' do set $(MAKE), but not all of them. I seem to recall that
> >some of the SystemV-derived ones don't. (Such systems are very poorly
> >represented on p5p, let alone p6i, so reliable in
At 07:15 PM 12/12/2001 +0200, Jaen Saul wrote:
>his patch extends configure with a new syntax for preprocessing, variables
>in form ${name,arg,...}.
>The arguments can be used with $1, $2, ... in the hint string.
>The substitution is indent-preserving if the hint includes newlines in the
>form of
This patch extends configure with a new syntax for preprocessing, variables
in form ${name,arg,...}.
The arguments can be used with $1, $2, ... in the hint string.
The substitution is indent-preserving if the hint includes newlines in the
form of $n.
It also fixes the various Windows build proble
Never mind. My e-mail client stopped downloading, so I didn't know this
was already being resolved. :^)
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
"Nothing important happened today."
--George III of England's diary entry for 4-Jul-1776
Jaen Saul:
# I sent a post about the brokenness of Parrot on Windows 5
# days ago still
# no reaction... not one reply, positive or negative. Are you
# guys blind?
# I'm removing my own version of makefile.in and so the Win32
# tinderbox will
# fail builds (like it has most of the time).
# Ple
At 10:31 AM 12/12/2001 -0500, Andy Dougherty wrote:
>Most 'makes' do set $(MAKE), but not all of them. I seem to recall that
>some of the SystemV-derived ones don't. (Such systems are very poorly
>represented on p5p, let alone p6i, so reliable information may be very
>hard to come by.)
At the m
On Wed, 12 Dec 2001, Simon Cozens wrote:
> On Wed, Dec 12, 2001 at 10:06:16AM -0500, Dan Sugalski wrote:
> > I'm not sure it will, though I'm hopeful.
> > In vain, apparently. Better, but not better enough.
>
> I *think* I've fixed the fix. The
> cd foo
> make
> solution has one big pr
On Wed, Dec 12, 2001 at 03:13:45PM +, Simon Cozens wrote:
> My solution assumes (for now) that "make -C" works, and that make sets
> $(MAKE). Both of these assumptions are probably broken somewhere.
I don't think make -C is correct outside of GNU make, though ICBW. I
certainly thought I'd bee
On Wed, Dec 12, 2001 at 10:06:16AM -0500, Dan Sugalski wrote:
> I'm not sure it will, though I'm hopeful.
> In vain, apparently. Better, but not better enough.
I *think* I've fixed the fix. The
cd foo
make
solution has one big problem: Make does its work by forking and exec'ing
processe
At 03:02 PM 12/12/2001 +, Simon Cozens wrote:
>On Wed, Dec 12, 2001 at 04:47:36PM +0200, Jaen Saul wrote:
> > P.P.P.S Don't reply to this message unless you have something really
> > important to say. Go do something useful.
>
>Is "Dan has just committed something which should fix it" importan
On Wed, Dec 12, 2001 at 04:47:36PM +0200, Jaen Saul wrote:
> P.P.P.S Don't reply to this message unless you have something really
> important to say. Go do something useful.
Is "Dan has just committed something which should fix it" important enough?
> All I wanted was to know why there were no
Well, I apologize about that, I'm sorry, I may be a bit harsh, but you do
realize that I fixed it on my box and that I supplied at least some
solution/patch for all the problems (on Win32, on Un*x they wouldn't work).
It needs someone with Un*x to correct them.
As people with a free operating syst
On Tue, 11 Dec 2001, Melvin Smith wrote:
> On most UNIX flavors I can use the stat() system call and
> the {struct stat}.st_blksize member to get an idea of
> the blocksize of a regular file.
>
> I don't currently have access to anything but Linux, Solaris
> and AIX to check this one, and I'm es
I sent a post about the brokenness of Parrot on Windows 5 days ago still
no reaction... not one reply, positive or negative. Are you guys blind?
I'm removing my own version of makefile.in and so the Win32 tinderbox will
fail builds (like it has most of the time).
Please fix the problems I ment
40 matches
Mail list logo
