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 pasi
"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
t/op/number...
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/ http://p
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
retrievin
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 en
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 execu
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 -W
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 to
enable/disable it with a specific pragma?
Ilya
> -Original Message-
> From: Sterin, Ilya [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 01,
On Tue, Jan 01, 2002 at 02:46:44PM +0100, Sebastian Bergmann wrote:
> By the way: How do I build a debug version of Parrot, so that I could
> provide a stacktrace?
You'll kick yourself.
perl Configure.pl -debugging
--
`First Up Against The Wall When The Revolution Comes! Woohoo!
S
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;
Test
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 some
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, so
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 hav
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] h
> -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 hav
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
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.p
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
> >
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, is
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 to
>enable/disable it with a specific pragma?
Might happen. Larry's talked about it on and off, and if you
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
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 20
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
+++ runops_cores.c
> -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 PR
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
---
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
t/op/integerok
> -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]]
>
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: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 S
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
> >
"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
*** encodings/s
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 PROTECTE
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
"mi
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
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 `mm
"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:\home>perl -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
I don't know if these functions might be obsolete, but here's a
simple patch to add the missing prototypes if they are not.
Fixes this warning:
register.c:429: warning: no previous prototype for `Parrot_push_on_stack'
register.c:436: warning: no previous prototype for `Parrot_pop_off_stack'
In
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.
Index: Makefile.in
===
RCS file: /cvs/public/parrot/Makefile.in,v
retrieving revision 1.95
diff -c -r1.95 Makefile.in
*** Makefile.in 31 Dec 2001 22:37:26 - 1.95
--- Makefile.in 1 Jan 2002 19:46:26 -
***
*** 350,35
At 02:19 PM 1/1/2002 -0500, Josh Wilmes wrote:
>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 prototype
>
>pdump.c: In function `main':
>pdump.c:55: warning: passing arg 2 of `mmap' as unsigned due
At 02:33 PM 1/1/2002 -0500, Josh Wilmes wrote:
>I don't know if these functions might be obsolete, but here's a
>simple patch to add the missing prototypes if they are not.
Applied, thanks.
Dan
--"it's like this"---
Jason Diamond wrote:
> The attached files fix the 'nmake clean' problems on Win32
Works, thanks a bunch.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
At 11:47 AM 1/1/2002 +, Tim Bunce wrote:
>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
At 09:48 AM 1/1/2002 -1000, David & Lisa Jacobs wrote:
>Index: Makefile.in
Applied, thanks.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
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
d
At 10:19 AM 1/1/2002 -1000, David & Lisa Jacobs wrote:
>Got rid of unneeded tmp var and eliminated const from encode prototype since
>it does make changes to the string.
Applied, thanks.
Dan
--"it's like this"--
Another correction to string_transcode; this function now seems to work okay
(tested using a dummy 'encode' op added to my local copy of core.ops)
Peter Gibbs
EmKel Systems
Index: string.c
===
RCS file: /home/perlcvs/parrot/string.c
I don't know if this is the way to go on principal, and I definitely feel
that passing flags around in environment variables and unadorned on command
lines is a messy hack, but I wanted to run the test suite with the JIT.
So I did this:
--- Makefile~ Tue Jan 1 20:10:58 2002
+++ MakefileTu
The attached patch makes it possible to build the mops target on Win32.
docs/Makefile still needs to be removed from CVS.
Jason.
mops.patch
Description: Binary data
All who have time, specifically Win32, please test this
patch for compilation. I currently don't have a Win32
environment to test with. Anyone with non-Linux please test.
What this patch does:
-Implements initial IO stack framework (pushing/popping layers)
-Implements an initial "layer" for the
Oops. The patch helps.
-Melvin
diff -urN tmp/parrot/MANIFEST parrot/MANIFEST
--- tmp/parrot/MANIFEST Tue Jan 1 11:58:13 2002
+++ parrot/MANIFEST Tue Jan 1 16:40:01 2002
@@ -79,6 +79,8 @@
include/parrot/trace.h
include/parrot/unicode.h
interpreter.c
+io/io.c
+io/io_os.c
jit/i386
On Tuesday 01 January 2002 01:53 pm, Dan Sugalski wrote:
> 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 plat
On Tuesday 01 January 2002 02:19 pm, Josh Wilmes wrote:
> 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'
On Tuesday 01 January 2002 03:19 pm, David & Lisa Jacobs wrote:
> Got rid of unneeded tmp var and eliminated const from encode prototype
> since it does make changes to the string.
My fault. I got const bass ackwards again.
The only syntax more screwed up than C declarations is the syntax for
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
c:\perl6\parrot\io\io.
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 (tes
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
+++ tes
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, Janu
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) : warnin
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
> -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
> > >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,
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 STDO
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; 'Jaso
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 this"
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 Sugalsk
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
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 2
At 11:04 PM 1/1/2002 -0500, Melvin Smith wrote:
>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.
Works. Thanks, and applied.
I just did a cvs up and it seems to be testing ok on my cygwin system...
David
- Original Message -
From: "Dan Sugalski" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 01, 2002 5:09 PM
Subject: interp failures in the new IO system
> Dunno if this is affecting anyone
At 06:25 PM 1/1/2002 -1000, David & Lisa Jacobs wrote:
>I just did a cvs up and it seems to be testing ok on my cygwin system...
Yup, there's a patch in now.
>- Original Message -
>From: "Dan Sugalski" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Tuesday, January 01, 2002 5:09 PM
This patch changes the makefiles to call LD rather than CC where
appropriate.
This doesn't address the linking of shared libs. I'll look into that next.
Index: Configure.pl
===
RCS file: /home/perlcvs/parrot/Configure.pl,v
retrie
Huh- this sneaked into my patch. Looks like docs/Makefile should be removed
from CVS, since it's autogenerated now.
--Josh
> Index: docs/Makefile
> ===
> RCS file: /home/perlcvs/parrot/docs/Makefile,v
> retrieving revision 1.4
>
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 S0
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 -00
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
... 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 Par
- 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 t
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,
97 matches
Mail list logo
