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
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
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
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
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 important
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
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 been
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 problem:
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
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 $n.
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
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,
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
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---
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
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
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?
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,
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
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
---
--- 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 Win95, Win98,
[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
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 anything
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
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 for
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 out
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. The -C way
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.
#
# VMS is
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 somehow figures
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 that quite
| 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 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
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
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
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 want to be
35 matches
Mail list logo
