C:\Programme\Perl\bin\perl.exe -MExtUtils::Command -e rm_f -r blib
Unrecognized switch: -r (-h will show valid options).
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
Not sure if this has already been discussed, but I though this would be
a cool option, especially since I've ran into a few cases where this
would have been very usefull.
Using a scalar (string) with an address to another variable and be able
to dereference it. This proves very usefull when
Sterin, Ilya wrote:
I haven't done any testing yet, though.
It compiles here, too. But 'nmake test' runs as far as
t/op/basic..ok
t/op/bitwiseok
t/op/debuginfo..ok
t/op/hacks..ok
t/op/integerok
t/op/interp.ok
t/op/macro..ok
Sebastian Bergmann wrote:
C:\Programme\Perl\bin\perl.exe -MExtUtils::Command -e rm_f -r blib
Unrecognized switch: -r (-h will show valid options).
'nmake clean' suffers from the same problem, I just noticed.
--
Sebastian Bergmann
http://sebastian-bergmann.de/
I suspect that the length of the output buffer for string_transcode should
be based on the output encoding, not on the input encoding.
Peter Gibbs
EmKel Systems
Index: string.c
===
RCS file: /home/perlcvs/parrot/string.c,v
On Mon, Dec 31, 2001 at 06:53:29AM -1000, David Lisa Jacobs wrote:
From: Dan Sugalski [EMAIL PROTECTED]
Agreed. I'll probably have the encoding structure provide the
terminating
bytes. As a side note don't we also have to split UTF-16 into UTF-16BE
and
UTF-16LE (big endian and little
Sebastian Bergmann wrote:
and then test_parrot.exe crashes.
By the way: How do I build a debug version of Parrot, so that I could
provide a stacktrace? Using MSVC's debugger with the test_parrot.exe
that nmake produces unusable results, because no debugging information
is in the
On Mon, Dec 31, 2001 at 10:39:54AM -0500, Dan Sugalski wrote:
Folks,
I've just made a few minor changes to configure.pl regarding the switches
for gcc. Now instead of -Wall being the defaults, it's:
-Wall -ansi -pedantic -Wtraditional -Wstrict-prototypes
-Wmissing-prototypes -Winline
On Tue, Jan 01, 2002 at 04:00:22AM -0800, Sterin, Ilya wrote:
Using a scalar (string) with an address to another variable and be able
to dereference it. This proves very usefull when pasing dynamic strings
with addresses embeded in them. I don't believe this is available in
current perl
If you're doing 386 assembler, this should work
Index: Configure.pl
===
RCS file: /home/perlcvs/parrot/Configure.pl,v
retrieving revision 1.60
diff -r1.60 Configure.pl
98a99
$jitarchname =~ s/i[456]86/i386/i;
Not sure, I'll have to take a look at the module, but would it be
usefull to include in the standard distro, since this one is not
included. I was thinking more of a pragma type usage, sort of like
symbolic references can be turned on and off. Or maybe I just feel the
sudden urge because of
On Tue, Jan 01, 2002 at 11:38:16AM -0800, Sterin, Ilya wrote:
Not sure, I'll have to take a look at the module, but would it be
usefull to include in the standard distro
Please, no. That definitely counts as more than enough rope.
included. I was thinking more of a pragma type usage, sort
At 10:57 PM 12/31/2001 -0500, Bryan C. Warnock wrote:
...there's *two* of them!
It's in there. Thanks.
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED]
-Original Message-
From: Simon Cozens [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 01, 2002 8:54 AM
To: Sterin, Ilya
Cc: [EMAIL PROTECTED]
Subject: Re: Using stringified address
On Tue, Jan 01, 2002 at 11:38:16AM -0800, Sterin, Ilya wrote:
Not sure, I'll have to take
Simon Cozens wrote:
You'll kick yourself.
perl Configure.pl -debugging
perl Configure.pl --debugging
seems to have no effect on Win32, as of now.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift:
At 11:33 PM 12/31/2001 -0500, Bryan C. Warnock wrote:
Index: MANIFEST
In, thanks.
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED]
-Original Message-
From: Simon Cozens [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 01, 2002 8:54 AM
To: Sterin, Ilya
Cc: [EMAIL PROTECTED]
Subject: Re: Using stringified address
On Tue, Jan 01, 2002 at 11:38:16AM -0800, Sterin, Ilya wrote:
Not sure, I'll have to take
On Tue, Jan 01, 2002 at 11:58:48AM -0800, Sterin, Ilya wrote:
I still can't understand why is this such a bad thing, especially if you
can check for it with pragmas. I guess I've been reading all this stuff
about how dangerous and bad this is, with no explanation. I mean a lot
of things are
At 05:24 PM 1/1/2002 +0100, Sebastian Bergmann wrote:
Simon Cozens wrote:
You'll kick yourself.
perl Configure.pl -debugging
perl Configure.pl --debugging
seems to have no effect on Win32, as of now.
Odd. It should add debugging flags. The hints file hints/mswin32.pl only
At 06:12 AM 1/1/2002 -0500, Chip Turner wrote:
Well, looks like the body of the message I send mysteriously
disappeared, much to my chagrin. Here it is. Patch included inline,
as well.
Applied, thanks.
Dan
--it's
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 07:30 AM 12/30/2001 -1000, David Lisa Jacobs wrote:
From: Dan Sugalski [EMAIL PROTECTED]
At 08:33 PM 12/29/2001 -1000, David Lisa Jacobs
wrote:
GC will manage all the memory. Everything managed
should either be hung
off
a PMC or an
Dan and Nick --
[and I did laugh out loud when I finally realised what cunning tricks it is
doing to replace the deref function with the pointer to the opcode function,
and return the same address so that the run loop calls the real function at
that point]
It is rather clever, isn't it?
At 09:30 AM 1/1/2002 -0800, Benjamin Stuhl wrote:
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 07:30 AM 12/30/2001 -1000, David Lisa Jacobs wrote:
From: Dan Sugalski [EMAIL PROTECTED]
At 08:33 PM 12/29/2001 -1000, David Lisa Jacobs
wrote:
GC will manage all the memory.
cc -Wall -I./include -DHAS_JIT -o encodings/singlebyte.o -c encodings/singlebyte.c
encodings/singlebyte.c:63: warning: initialization from incompatible pointer type
encodings/singlebyte.c:65: warning: initialization from incompatible pointer type
I'm not sure why there is only const on one of
This patch shuts up this one:
cc -Wall -I./include -DHAS_JIT -o trace.o -c trace.c
trace.c: In function `trace_op_dump':
trace.c:71: warning: enumeration value `PARROT_ARG_OP' not handled in switch
Nicholas Clark
--- trace.c~Sun Dec 30 12:05:20 2001
+++ trace.c Tue Jan 1 17:47:12
This shuts this one up
cc -Wall -I./include -DHAS_JIT -o runops_cores.o -c runops_cores.c
runops_cores.c: In function `runops_slow_core':
runops_cores.c:49: warning: implicit declaration of function `trace_op'
Nicholas Clark
--- runops_cores.c.orig Thu Dec 27 23:24:45 2001
+++
-Original Message-
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 01, 2002 9:59 AM
To: Sterin, Ilya; [EMAIL PROTECTED]
Subject: RE: Using stringified address
At 11:09 AM 1/1/2002 -0800, Sterin, Ilya wrote:
Ok, I understand that this hasn't been
At 11:25 AM 1/1/2002 -0500, Bryan C. Warnock wrote:
If you're doing 386 assembler, this should work
In, thanks.
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL
Mine pass fine...
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
D:\Perl\bin\perl.exe t/harness
t/op/basic..ok
t/op/bitwiseok
t/op/debuginfo..ok
t/op/hacks..ok
At 03:23 PM 1/1/2002 +, Nicholas Clark wrote:
The appended patch silences the warnings in what I believe is a correct way
[opcode_t will never have more than 32 bits of information, will it?
In, thanks. (And no, it won't)
Dan
-Original Message-
From: Sterin, Ilya [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 01, 2002 1:12 PM
To: 'Dan Sugalski'; [EMAIL PROTECTED]
Subject: RE: Using stringified address
-Original Message-
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
Sent:
At 05:27 PM 1/1/2002 +, Nicholas Clark wrote:
but that is a more fundamental change than removing the warning by changing
just 1 file (as appended).
Applied, thanks.
Dan
--it's like this---
Dan
At 04:59 PM 1/1/2002 +, Nicholas Clark wrote:
This shuts this one up
cc -Wall -I./include -DHAS_JIT -o runops_cores.o -c runops_cores.c
runops_cores.c: In function `runops_slow_core':
runops_cores.c:49: warning: implicit declaration of function `trace_op'
Applied, thanks.
At 05:12 PM 1/1/2002 +, Nicholas Clark wrote:
This patch shuts up this one:
cc -Wall -I./include -DHAS_JIT -o trace.o -c trace.c
trace.c: In function `trace_op_dump':
trace.c:71: warning: enumeration value `PARROT_ARG_OP' not handled in switch
Applied, thanks.
At 01:11 PM 1/1/2002 -0800, Sterin, Ilya wrote:
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
At 11:09 AM 1/1/2002 -0800, Sterin, Ilya wrote:
Ok, I understand that this hasn't been implemented due to
the believe
that it's a dangerous feature (Programming Perl). But would
it be ok
Sterin, Ilya wrote:
Mine pass fine...
Current CVS, same crash: http://www.sebastian-bergmann.de/parrot.txt
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
This patch eliminates extraneous 0 tests (because they are unsigned).
David
Index: encodings/singlebyte.c
===
RCS file: /cvs/public/parrot/encodings/singlebyte.c,v
retrieving revision 1.8
diff -c -r1.8 singlebyte.c
***
Actually, I started down this road as well, but thought it would make more
sense to make the opcode_t unsigned. This would allow us to keep it a
consistent size across platforms if we want.
Thoughts?
David
- Original Message -
From: Chip Turner [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
At 08:40 AM 1/1/2002 -1000, David Lisa Jacobs wrote:
This patch eliminates extraneous 0 tests (because they are unsigned).
Applied, thanks.
Dan
--it's like this---
Dan Sugalski
I wonder if it matters what current perl version you are using?
Also what VC++ and Service Pack are you using as well as your OS.
Here is mine...
Windows 2000 Professional SP2
ActivePerl 5.6.1
VC++ 6.0 Enterprise SP5
It might not be any of the above, but I thought lets eliminate all other
At 08:46 AM 1/1/2002 -1000, David Lisa Jacobs wrote:
Actually, I started down this road as well, but thought it would make more
sense to make the opcode_t unsigned. This would allow us to keep it a
consistent size across platforms if we want.
I'd rather opcode_t stays signed--that gives us two
This silences these warnings:
test_main.c: In function `main':
test_main.c:165: warning: passing arg 6 of `mmap' with different width due to p
rototype
pdump.c: In function `main':
pdump.c:55: warning: passing arg 2 of `mmap' as unsigned due to prototype
pdump.c:55: warning: passing arg 6 of
Sterin, Ilya wrote:
I wonder if it matters what current perl version you are using?
Also what VC++ and Service Pack are you using as well as your OS.
MS Windows 2000 Profession, SP-2
MS VisualStudio 6 SP-4 (installing SP-5 soon)
c:\homeperl -V
Summary of my perl5 (revision 5 version 6
The attached files fix the 'nmake clean' problems on Win32 (and hopefully
other non-Unix platforms). Makefile.in needs to be added to parrot/docs.
parrot/docs/Makefile needs to be removed.
Jason.
Makefile.in
Description: Binary data
clean.patch
Description: Binary data
At 11:32 AM 1/1/2002 -0800, Jason Diamond wrote:
The attached files fix the 'nmake clean' problems on Win32 (and hopefully
other non-Unix platforms). Makefile.in needs to be added to parrot/docs.
parrot/docs/Makefile needs to be removed.
Applied, thanks.
Got rid of unneeded tmp var and eliminated const from encode prototype since
it does make changes to the string.
David
Index: encodings/singlebyte.c
===
RCS file: /cvs/public/parrot/encodings/singlebyte.c,v
retrieving revision 1.9
Here's my output:
cl -nologo -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT
-DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DPERL_MSVCRT_READFIX-I./i
nclu
de -Foio/io.obj -c io/io.c
io.c
io\io.c(323) : warning C4033: 'PIO_close' must return a value
On Tue, Jan 01, 2002 at 10:05:44PM +, Nicholas Clark wrote:
So, what's going wrong, and why all the segvs?
I figured it was better to start by wondering about the prederef code.
But I might just go to bed instead. Or fix compiler warnings. or perl5
The first segv is the ret in this (test
At 06:07 PM 1/1/2002 -0500, [EMAIL PROTECTED] wrote:
Oops. The patch helps.
Applied, thanks.
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED]
there are quite a few warnings due to index being
defined in string.h:
char*rindex (const char *, int) ;
include/parrot/vtable.h:31: warning: declaration of `index' shadows global declaration
include/parrot/vtable.h:33: warning: declaration of `index' shadows global declaration
In an attempt to just keep knocking off warnings..
Index: test_main.c
===
RCS file: /cvs/public/parrot/test_main.c,v
retrieving revision 1.28
diff -u -p -r1.28 test_main.c
--- test_main.c 1 Jan 2002 19:49:11 - 1.28
+++
Funny, besides the SP-5, which I would bet does not matter, we have
identical configs?
I'll try to rerun the tests in a minute again, though I've already
successfully ran them twice.
Ilya
-Original Message-
From: Sebastian Bergmann [mailto:[EMAIL PROTECTED]]
Sent: Tuesday,
io_os.c(127) : error C2065: 'F_GETFL' : undeclared identifier
With the latest CVS, after the ParrotIO patch.
Ilya
At 03:33 PM 1/1/2002 -0800, Jason Diamond wrote:
Here's my output:
cl -nologo -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT
-DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DPERL_MSVCRT_READFIX-I./i
nclu
de -Foio/io.obj -c io/io.c
io.c
io\io.c(323) : warning C4033:
Small patch to return a value in io.c PIO_close().
323c323
return 1; ---
return;
Oooopss, sorry. Disregard this, since Melvin just submitted the actual
correct version:-)
Ilya
-Original Message-
From: Sterin, Ilya [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 01, 2002 8:59 PM
To: [EMAIL PROTECTED]
Subject: io.c problem and patch
Small patch to return
-Original Message-
From: Melvin Smith [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 01, 2002 5:58 PM
To: Jason Diamond; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: ParrotIO : Please test this [PATCH] for breakage
At 03:33 PM 1/1/2002 -0800, Jason Diamond wrote:
io\io_os.c(127) : error C2065: 'F_GETFL' : undeclared
identifier NMAKE
: fatal error U1077: 'cl' : return code '0x2' Stop.
With the #if 0 you can get a compile, can you test this simple pasm code?
puts This is STDOUT\n
end
Btw, I checked over Perl5 source, they of
At 09:46 PM 1/1/2002 -0500, Melvin Smith wrote:
io\io_os.c(127) : error C2065: 'F_GETFL' : undeclared
identifier NMAKE
: fatal error U1077: 'cl' : return code '0x2' Stop.
With the #if 0 you can get a compile, can you test this simple pasm code?
puts This is STDOUT\n
It compiled fine with #if 0, but now interp1.t hangs.
Ilya
P.S. I have to step away for a few, but I'll be back to test the rest
in an hour or so.
-Original Message-
From: Melvin Smith [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 01, 2002 6:46 PM
To: Sterin, Ilya; 'Jason
Dunno if this is affecting anyone else, but I'm finding the test suite
hangs on cygwin with the new IO code in the interp tests. That's mine and
sort of busted, but something to keep in mind.
Dan
--it's like
At 10:09 PM 1/1/2002 -0500, Dan Sugalski wrote:
Dunno if this is affecting anyone else, but I'm finding the test suite
hangs on cygwin with the new IO code in the interp tests. That's mine and
sort of busted, but something to keep in mind.
Dan
At 10:22 PM 1/1/2002 -0500, Melvin Smith wrote:
See if this helps the freeze...
FWIW, I just got VC++ working on my Win2000 and the test worked ok.
No joy, sorry.
Dan
--it's like this---
Dan Sugalski
At 10:30 PM 1/1/2002 -0500, Dan Sugalski wrote:
At 10:22 PM 1/1/2002 -0500, Melvin Smith wrote:
See if this helps the freeze...
FWIW, I just got VC++ working on my Win2000 and the test worked ok.
No joy, sorry.
I just stubbed the test out so the tinderbox clients won't wedge too hard
on it.
This fixes the freeze by only initializing ParrotIO once. Also added
a little sanity check in the layer push sub. This is just a kludge, I'll work
on per Interpreter IO stack when we discuss it a little more.
-Melvin
--- io.c.orig Tue Jan 1 21:54:35 2002
+++ io.cTue Jan 1 21:53:29
Here is a short list of TODOs that I came up with for STRINGs. First, do
these look good to people? And second, what is the preferred method for
keeping track of these (patch to the TODO file, entries in bug tracking
system, mailing list, etc.
* Add set ops that are encoding aware (e.g., set
This is just a small simplification.
David
Index: string.c
===
RCS file: /cvs/public/parrot/string.c,v
retrieving revision 1.35
diff -c -r1.35 string.c
*** string.c 1 Jan 2002 17:53:50 - 1.35
--- string.c 2 Jan 2002 05:09:45
On Sun, Dec 30, 2001 at 10:11:38AM -0500, Gregor N. Purdy wrote:
Bryan --
Mixed modes for *.pl scripts in the main directory. Should all probably be
0644.
Changing them directly in the repository should help.
$ chmod 0644 *.pl,v
Done.
-R
An updated TODO list is needed. As is maybe a reminder on bugs.perl.org.
bugs6.perl.org
The things that I want to happen for 0.0.4 are not sexy. They are
I've added the 0.0.4 goals to
http://www.parrotcode.org/todo
-R
-Original Message-
From: Sterin, Ilya [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 01, 2002 10:05 PM
To: 'Melvin Smith'; 'Jason Diamond'; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: ParrotIO : Please test this [PATCH] for breakage
It compiled fine with #if 0,
... seems not to be missing some files.
nmake testclean
nmake realclean
cvs upd -dAP
? pdump.ilk
? pdump.pdb
? test_parrot.ilk
? test_parrot.pdb
? vc60.pdb
? classes/vc60.pdb
cvs server: Updating .
cvs server: Updating Parrot
cvs server: Updating Parrot/Jit
cvs server: Updating
- Original Message -
From: David Lisa Jacobs [EMAIL PROTECTED]
* Add transcoding ops (this might be a specific case of the previous e.g.,
set S0, S1, unicode, utf-16)
Note that there is still a bug in string_transcode as of string.c 1.35; I
have repeated a patch below. I tested this
From: Peter Gibbs [EMAIL PROTECTED]
* Add size of string termination to encodings (i.e., how many 0 bytes)
Should string termination be required? If strings are assumed to be
terminated, it seems to me that precludes buffer re-use (copy-on-write)
for
substrings. On the other hand, passing
73 matches
Mail list logo
