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 th
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
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, a
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, M
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 cam
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
>
>(runnin
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 b
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
At 10:06 PM 4/13/2002 -0400, Dan Sugalski wrote:
>At 5:35 PM -0400 4/13/02, Clinton A. Pierce wrote:
>>I'm fighting a now-you-see-it now-you-don't kind of bug and I was
>>wondering if there's a way to completely turn off garbage collection and
>>memory re-use for debugging?
>
>Yes. The sweepoff
At 9:26 AM -0700 4/14/02, Robert Spier wrote:
> >>> 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
At 1:24 PM -0400 4/14/02, Clinton A. Pierce wrote:
>At 10:06 PM 4/13/2002 -0400, Dan Sugalski wrote:
>>At 5:35 PM -0400 4/13/02, Clinton A. Pierce wrote:
>>>I'm fighting a now-you-see-it now-you-don't kind of bug and I was
>>>wondering if there's a way to completely turn off garbage
>>>collectio
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 18:11:
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 e
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 transcoding is done before making the result string,
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 bufu
[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 on
> > 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 parti
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 mummer
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'l
> 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
w
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
27 matches
Mail list logo
