Looks like we've got a slew of gcc3 issues (which don't show up on the
tinderboxes, cause nobody's running a gcc3 box.)
rspier@bear ~/projects/parrot$ make test
perl t/harness
t/op/basic..ok
t/op/bitwiseok
t/op/debuginfo..ok
t/op/hacks..ok
t/op/ifunless...ok
Bryan C. Warnock wrote:
Oh, in which case, I agree with you. ;-)
Oh, woops. :) For some reason I was assuming you were arguing against
my patch.
Anyways, below is a revised and simpler patch that implements the same
semantics as before, but using Dan's new DOD_block_level and
GC_block_level
At 11:47 PM -0700 4/13/02, Robert Spier wrote:
Looks like we've got a slew of gcc3 issues (which don't show up on the
tinderboxes, cause nobody's running a gcc3 box.)
What sub-version of GCC 3?
--
Dan
--it's like
On Sun 14 Apr 2002 16:01, Dan Sugalski [EMAIL PROTECTED] wrote:
At 11:47 PM -0700 4/13/02, Robert Spier wrote:
Looks like we've got a slew of gcc3 issues (which don't show up on the
tinderboxes, cause nobody's running a gcc3 box.)
What sub-version of GCC 3?
FWIW bleadperl compiles OK with
At 6:37 AM -0400 4/14/02, Mike Lambert wrote:
Bryan C. Warnock wrote:
Oh, in which case, I agree with you. ;-)
Oh, woops. :) For some reason I was assuming you were arguing against
my patch.
Which is applied. I'd rather enforce the No allocations until
mem_setup_allocator is done,
At 9:30 PM -0400 4/13/02, Jeff wrote:
Hopefully that'll get your attention.
In the interests of accomplishing something this millennium, I'm
planning to tag version 0.0.5 at some time around 12:01am EST Monday,
April 15. I'll be watching mail up until the deadline, so if nobody
complains, Monday
Dan Sugalski wrote:
At 11:47 PM -0700 4/13/02, Robert Spier wrote:
Looks like we've got a slew of gcc3 issues (which don't show up on the
tinderboxes, cause nobody's running a gcc3 box.)
What sub-version of GCC 3?
3.0.4
(running on a relatively stock Pentium2 / RH7.2 system.)
This came out
At 8:58 AM -0700 4/14/02, Robert Spier wrote:
Dan Sugalski wrote:
At 11:47 PM -0700 4/13/02, Robert Spier wrote:
Looks like we've got a slew of gcc3 issues (which don't show up on the
tinderboxes, cause nobody's running a gcc3 box.)
What sub-version of GCC 3?
3.0.4
(running on a
At 11:12 AM +0200 4/9/02, Peter Gibbs wrote:
I don't think we are in a position yet to prove much of anything as regards
real-world Perl programs, but just one data point as an example - using
examples/assembly/life.pasm (changed to 5000 generations)
10% speedup in some circumstances. OK, I'm
What sub-version of GCC 3?
3.0.4
Damn. Do the failing tests segfault?
I didn't look that closely. Some of them definitely are spitting out
wrong data. (Very odd.)
I didn't notice any Segmentation Fault warnings in the output though, so
I'd guess no, unless it's being trapped by the
At 5:26 PM -0700 4/13/02, Larry Wall wrote:
Well, Perl 5 doesn't really support compact arrays of known size, and
those are the only kind that are easy to think about when it comes to
vectorization.
Actually, I can think of other possibilities. For instance, aren't
some string operations (e.g.,
pasm.el
Description: application/emacs-lisp
Index: core.ops
===
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.120
diff -u -r1.120 core.ops
--- core.ops 14 Apr 2002 02:05:46 - 1.120
+++ core.ops 14 Apr 2002
ok, please pardon the inconvience but everytime i send mail to
perl6-internals the body of my message disappears...
anyway, here's what i meant to say:
[original email]
i have written a simple emacs mode, providing highlighting,
indentation, and compilation, for dealing with .pasm files, it's
Marco- i went ahead and added your pasm.el file under parrot/editor/.
I'm not familiar enough with the ops to commit your other patch- i'll leave
that for someone else.
--Josh
At 20:21 on 04/14/2002 +0200, Marco Baringer [EMAIL PROTECTED] wrote:
ok, please pardon the inconvience but
In message [EMAIL PROTECTED]
Tom Hughes [EMAIL PROTECTED] wrote:
I have developed patch for this in the form of a new routine
which returns a nul terminated C style string given a parrot
string as argument. It does this by making sure buflen is at
least one greater than bufused and
[Follow up to my previous post]
lib/Parrot/Assembler.pm creates all string constants with chartype = 0,
which, by virtue of the sequence of the enums in include/parrot/chartype.h
means unicode. So all string constants are type: unicode, encoding:
singlebyte.
I am not going to try and fix this
I have developed patch for this in the form of a new routine
which returns a nul terminated C style string given a parrot
string as argument. It does this by making sure buflen is at
least one greater than bufused and then stuffing a nul in that
byte.
This isn't a particularly
At 08:55 PM 4/14/2002 +0200, Peter Gibbs wrote:
The specific problem Clinton mentioned is yet another infant mortality
problem, this time in string_concat. I don't know what the current decision
is on handling these situations, but this one can be avoided by optimising
the code anyway. If the
At 08:55 PM 4/14/2002 +0200, Peter Gibbs wrote:
The specific problem Clinton mentioned is yet another infant mortality
problem, this time in string_concat. I don't know what the current decision
is on handling these situations, but this one can be avoided by optimising
the code anyway. If the
On Sat, Apr 13, 2002 at 05:07:37PM -0700, Larry Wall wrote:
Of course, one of the big reasons we went with $self was the pun:
my $self = shift;
which we won't have now. Unless we always hide the invocant and
force you to say
my $self = invocant;
or some such mummery. But
Jeff wrote:
Hopefully that'll get your attention.
In the interests of accomplishing something this millennium, I'm
planning to tag version 0.0.5 at some time around 12:01am EST Monday,
April 15. I'll be watching mail up until the deadline, so if nobody
complains, Monday evening I'll run
As a follow-up, I found one bug. Rather odd it is. The symptom is loading
a program, doing a LIST
and seeing only part of the code. Dumping the
string-which-contains-the-code you can see the entire program in it (unlike
the earlier described bug). The problem was in here:
Clint, in
One of the features I like about Eiffel is what Meyer calls the Uniform
Access principle...It sounds as though Perl 6 is heading towards supporting
this. Have we actually got there?
That's the intention, yes.
The details still need to be nutted out, but it seems very likely that if you
Yes, subroutine variables *are* like underwear.
But parameter names *aren't* like underwear.
Because they're not (primarily) subroutine variables.
So they're like the labels on the knobs, dials, and buttons of your favourite
elctronic device. They're part of the *interface*, not (primarily) part
24 matches
Mail list logo
