Ron Blaschke [EMAIL PROTECTED] wrote:
I have looked into the t/library/streams.t failures on win32 (Ticket
#31921). They arise from the \r\n line separator on Windows.
Can you please elaborate a bit more on the exact problem of the test:
* is the test testing wrong things?
* does Parrot
Jack J. Woehr [EMAIL PROTECTED] wrote:
[20:53:51 [EMAIL PROTECTED]:/usr/local/src/PerlSource/parrot]$ perl
Configure.pl --prefix=/usr/local/uplevel --cc=gcc --cxx=gcc
[ ... ]
Determining your minimum pointer alignmentCan't
determine alignment!
[20:53:56
On Sunday 07 November 2004 09:48, Leopold Toetsch wrote:
* where exactly is the mismatch coming from?
Unix uses \n to indicate end-of-line, windows uses \r\n. The problem is,
that the perlhist.txt file is checked in as a text file. I'll recommit it
as a binary file in the hope that it fixes the
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #32354]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32354
Hi,
this patch updates 'perlhist.txt', which is used as a test case in
On Tue, Nov 02, 2004 at 09:22:36AM -0500, Andy Dougherty wrote:
On Mon, 1 Nov 2004, James deBoer wrote:
Some systems, notable Debian, ship perldoc and perl as seperate
packages. The presence of Perl does not imply the presence of perldoc.
This patch will test to see if perldoc actually
I would like to suggest that we define:
multi sub *infix:+(...) {...}
Will always generate a warning (not just for Cinfix:+, but for any
operator) if used outside of a class definition or if used inside a
class definition where the current class does not appear in the list of
parameters.
Leopold Toetsch wrote:
Configure::Data-set(ptr_alignment = 4);
return;
Thanks, that configured, building now
--
Jack J. Woehr # Ordinator consistetvr,
PO Box 51, Golden, CO 80402 # redintegrandvs tandem
http://www.well.com/~jax # tangenda qvodvis
Okay, I now configured
perl Configure.pl --prefix=/usr/local/uplevel --cc=gcc --cxx=gcc
--icuplatform=sparc-sun-solaris2.9
The build bombs in:
string_set_data_directory: ICU data files not found(apparently) for
directory [/usr/local/uplevel/blib/lib/icu/2.6.1]make: ***
On Sun, Nov 07, 2004 at 01:17:28PM -0700, Jack J. Woehr wrote:
Okay, I now configured
perl Configure.pl --prefix=/usr/local/uplevel --cc=gcc --cxx=gcc
--icuplatform=sparc-sun-solaris2.9
The build bombs in:
string_set_data_directory: ICU data files not found(apparently) for
On Nov 5, 2004, at 9:40 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
a) As Sam says, in Python y**z is just shorthand for
y.__pow__(z)--they will compile down to exactly the same thing
(required for Python to behave correctly).
I don't think so (and you can replace with add,
On Nov 5, 2004, at 10:03 AM, Sam Ruby wrote:
Jeff Clites wrote:
a) As Sam says, in Python y**z is just shorthand for
y.__pow__(z)--they will compile down to exactly the same thing
(required for Python to behave correctly). Since __pow__ isn't
special, we don't need anything to support it that
On Nov 4, 2004, at 5:24 AM, Sam Ruby wrote:
[Referring to infix operators as an alternate syntax for a named method
call]
What's the downside of compiling this code in this way? If you are a
Python programmer and all the objects that you are dealing with were
created by Python code, then not
Nicholas Clark wrote:
On Sun, Nov 07, 2004 at 01:17:28PM -0700, Jack J. Woehr wrote:
Okay, I now configured
perl Configure.pl --prefix=/usr/local/uplevel --cc=gcc --cxx=gcc
--icuplatform=sparc-sun-solaris2.9
The build bombs in:
string_set_data_directory: ICU data files
On Nov 7, 2004, at 2:25 AM, Jens Rieks wrote:
On Sunday 07 November 2004 09:48, Leopold Toetsch wrote:
* where exactly is the mismatch coming from?
Unix uses \n to indicate end-of-line, windows uses \r\n. The
problem is,
that the perlhist.txt file is checked in as a text file. I'll
recommit it
[missed cc-ing the list when I sent this originally]
On Nov 5, 2004, at 10:39 AM, Brent 'Dax' Royal-Gordon wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
There are a
myriad of interesting mathematical types and operations, but they
don't
need dedicated ops to support them.
But we're not talking
On Nov 7, 2004, at 3:20 PM, Jack J. Woehr wrote:
Nicholas Clark wrote:
On Sun, Nov 07, 2004 at 01:17:28PM -0700, Jack J. Woehr wrote:
Okay, I now configured
perl Configure.pl --prefix=/usr/local/uplevel --cc=gcc
--cxx=gcc --icuplatform=sparc-sun-solaris2.9
The build bombs in:
# New Ticket Created by Stephane Payrard
# Please include the string: [perl #32356]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32356
There is now a call to set the core and another to set the other
flags. I
On Sun, Nov 07, 2004 at 02:57:04PM -0800, Jeff Clites wrote:
On Nov 7, 2004, at 3:20 PM, Jack J. Woehr wrote:
Nicholas Clark wrote:
On Sun, Nov 07, 2004 at 01:17:28PM -0700, Jack J. Woehr wrote:
Okay, I now configured
perl Configure.pl --prefix=/usr/local/uplevel --cc=gcc
Rereading this excellent summary, I note that I did not keep
people posted on my problem.
Stephane Payrard asked about some problems he had encountered creating
the magical all in one Siva PMC. Leo provided a helpful prod towards
LVALUE_CAST. The other problems may or may not
Hurrah, even more use of «». But that is okay, as I have nearly half of
my terminals configured now, so that I can input and view them.
I don't understand why it is needed, though. Why wasn't infix:+ good
enough?
infix:«+» and infix:{'+'} are more linenoise, and IMHO it's far from
elegant.
On Mon, Nov 08, 2004 at 12:32:11AM +0100, Juerd wrote:
Hurrah, even more use of . But that is okay, as I have nearly half of
my terminals configured now, so that I can input and view them.
Excellent! As soon as you have the other half configured you'll be
ready for perl6 (and by that time
On Sun, Nov 07, 2004 at 06:19:05PM -0600, Jonathan Scott Duff wrote:
: It eliminates the hackish division of circumfix operators by making
: each side explicit. This is an improvement if you ask me.
More importantly, it avoids having to enumerate a list of characters
that have to be backslashed.
On Sun, Nov 07, 2004 at 12:40:45PM -0500, Aaron Sherman wrote:
: I would like to suggest that we define:
:
: multi sub *infix:+(...) {...}
:
: Will always generate a warning (not just for Cinfix:+, but for any
: operator) if used outside of a class definition or if used inside a
: class
What pasm is supposed to correspond to this snippet of Python code
(assume this is inside a function, so these can be considered to be
local variables):
a = 7
b = 12
c = a + b
Just a basic compilation question, brought to mind by a recent thread,
because the answer
Nicholas Clark wrote:
So I think that deleting the empty directory /usr/local/uplevel for the
duration of the build should solve your problem.
Removed the dir, finished the build, recreated the dir, and make install worked.
Now on to actually *trying out* Parrot ... as a former ANSForth
(In my opinion, the line-ending issue isn't a problem for Parrot in
terms of this test--it's legitimate to expect that you can process a
particular file, not matter what platform you happen to be on, and no
matter if the file happens to have been created on another platform.)
Also, the proper
Jack J. Woehr [EMAIL PROTECTED] wrote:
Okay, I now configured
perl Configure.pl --prefix=/usr/local/uplevel --cc=gcc --cxx=gcc
--icuplatform=sparc-sun-solaris2.9
The build bombs in:
string_set_data_directory: ICU data files not found(apparently) for
directory
Nicholas Clark [EMAIL PROTECTED] wrote:
I don't like the build blowing up on me when there is no perldoc, and on
some machines that I use I'm not in a position to change this.
So, as opinions aren't really matching, let's try this approach:
The configure step from that patch doesn't bail out,
On Nov 7, 2004, at 12:10 PM, Leopold Toetsch wrote:
Jack J. Woehr [EMAIL PROTECTED] wrote:
Okay, I now configured
perl Configure.pl --prefix=/usr/local/uplevel --cc=gcc --cxx=gcc
--icuplatform=sparc-sun-solaris2.9
The build bombs in:
string_set_data_directory: ICU data files not
29 matches
Mail list logo