Simon Glover wrote:
I've been looking into the cause of these failures, and it seems to be
yet another GC bug (or more likely another symptom of the same
underlying bug).
The problem in this case is in scratchpad_new (in sub.c). This creates a
new Scratchpad PMC, and subsequently also creat
On Fri, Dec 13, 2002 at 09:32:02AM -0800, Michael Lazzaro wrote:
>
> $obj.ID;
> $obj.IDENTITY;
FWIW, I favor the latter.
--Dks
[Sean == [EMAIL PROTECTED] on Fri, 13 Dec 2002 11:48:55 -0800 (PST)]
Jared> On to some tests, although I'm curious to see how tests of
Jared> literals turn out. Probably a lot of comparisons between
Jared> different representations of the same thing.
Sean> Warning: most of the tests won't work n
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 4:45 PM + 12/5/02, Leon Brocard wrote:
>>Leon Brocard sent the following bits through the ether:
>>
>>> Now to get the hand of the signatures...
>>
>>Ah, well, I gave up on SDL as it was a little complicated. Instead,
>>I played with curses. Plea
Piers Cawley wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
There are ways to get around that, and there are some inefficiencies
in the implementation there. I think we can work around some of
those--I am rather tempted to have invoke promise not to alter
non-parameter registers or something
Dave Storrs <[EMAIL PROTECTED]> writes:
> On Fri, Dec 13, 2002 at 09:32:02AM -0800, Michael Lazzaro wrote:
>>
>> $obj.ID;
>> $obj.IDENTITY;
>
> FWIW, I favor the latter.
I found myself mulling over:
$obj.is($other_obj);
Which seems to work reasonably well, and I'd be rather sur
Piers Cawley writes:
> I found myself mulling over:
>
> $obj.is($other_obj);
>
> Which seems to work reasonably well, and I'd be rather surprised if it
> clashed with anything with different semantics...
I quite like it. It also has the advantage of disallowing the equivalent
of:
my $sto
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #19179]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19179 >
This patch
(1) Creates a string_max_bytes() function,
as described in docs/st
On Mon, 16 Dec 2002, Steve Fink wrote:
> I'm a little confused by the va_list* stuff for sprintf*. At one
> point, people were saying that ppc does va_list differently, though
> I'm guessing that was a different compiler than gcc. Now, it seems
> like everything uses the same mechanism (and it was
On Mon, Dec 16, 2002 at 01:07:36PM +, mcharity @ vendian. org wrote:
This question is actually independent of the patch (which looks good)
>simply returns the C it is passed; C, on the
>other hand, returns three times the value that it is passed because a
>UTF8 character may occu
--- Steve Fink <[EMAIL PROTECTED]> wrote:
> blib/lib/libparrot$(SO) : blib/lib $(O_DIRS) $(O_FILES)
> - $(LD) $(LD_SHARED) $(LD_SHARED_FLAGS) $(LDFLAGS)
> $(LD_OUT)blib/lib/libparrot$(SO) $(O_FILES) $(C_LIBS)
> + $(LD) $(LD_SHARED) $(LD_SHARED_FLAGS) $(LDFLAGS)
> $(LD_OUT)blib${slash}lib${
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #19183]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19183 >
On Solaris 8, with Sun's Workshop Compiler, using Sun's supplied
5.00503, I get the fo
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #19184]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19184 >
On Solaris 8, with Sun's Workshop Compiler, using Sun's supplied
5.00503, I get the fo
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #19185]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19185 >
Here's what I get running 'make languages' with perl-5.00503:
cd jako && make && cd .
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #19187]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19187 >
On Solaris 8, with Sun's Workshop Compiler, using 64-bit long longs as
INTVAL, I get
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #19188]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19188 >
On Solaris 8, with Sun's Workshop Compiler, using 64-bit long longs as
INTVAL, I get
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #19189]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19189 >
On a Debian/SPARC system with gcc-2.95.4, and on a Solaris/SPARC
system with gcc-2.8.1
On Mon, Dec 16, 2002 at 03:25:36PM +, Andy Dougherty wrote:
> On Solaris 8, with Sun's Workshop Compiler, using Sun's supplied
> 5.00503, I get the following test failure in
>
> t/compiler/1# Failed test (t/compiler/1.t at line 306)
> # got: '7.00 9.00 4.00
>
On Mon, Dec 16, 2002 at 03:34:34PM +, Andy Dougherty wrote:
> On Solaris 8, with Sun's Workshop Compiler, using 64-bit long longs as
> INTVAL, I get the following test failure in t/src/sprintf. It looks
> like something is getting passed a 64-bit integer quantity but only taking
> the first 32
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #19191]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19191 >
This patch creates a string_nprintf(), as described in docs/strings.pod.
Specifica
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>
>> Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>>>There are ways to get around that, and there are some inefficiencies
>>>in the implementation there. I think we can work around some of
>>>those--I am rather tempted to have invoke
On Friday, December 13, 2002, at 10:59 PM, Piers Cawley wrote:
map { .[0] }
sort { $^a[1] cmp $^b[1] }
map { $_ => some_transform($_) }
grep /.../, @array
happily stays as it is; I fail to see what recasting that as
map { .[0] } <-
sort { $^a[1] cmp $^b[1] } <-
map { $_
Michael Lazzaro <[EMAIL PROTECTED]> writes:
> On Friday, December 13, 2002, at 10:59 PM, Piers Cawley wrote:
>>map { .[0] }
>>sort { $^a[1] cmp $^b[1] }
>>map { $_ => some_transform($_) }
>>grep /.../, @array
>>
>> happily stays as it is; I fail to see what recasting that as
>>
Aaron Crane <[EMAIL PROTECTED]> writes:
> Piers Cawley writes:
>> I found myself mulling over:
>>
>> $obj.is($other_obj);
>>
>> Which seems to work reasonably well, and I'd be rather surprised if it
>> clashed with anything with different semantics...
>
> I quite like it. It also has the ad
On Mon, Dec 16, 2002 at 06:47:39PM +, Piers Cawley wrote:
> Michael Lazzaro <[EMAIL PROTECTED]> writes:
>
> > Mind you (purely devil's advocate), I'm not entirely sure the R-to-L
> > syntax truly _needs_ to be in Perl6. It's true I use it all the time,
> > but I can retrain to use L-to-R meth
On Mon, 16 Dec 2002, Nicholas Clark wrote:
> Also, is the first of these a bug?
>
> $ ./perl6 -e 'print 3/undef; print "\n"'
> Can't call method "tree" on an undefined value at ./perl6 line 342.
Yes. The C function isn't fully, well, defined.
/s
# New Ticket Created by The RT System itself
# Please include the string: [perl #19192]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19192 >
I can build parrot fine on my FreeBSD box. I can re-run the tests fine with
/usr
On Mon, 16 Dec 2002, Leopold Toetsch wrote:
> Simon Glover wrote:
>
> > I've been looking into the cause of these failures, and it seems to be
> > yet another GC bug (or more likely another symptom of the same
> > underlying bug).
> >
> > The problem in this case is in scratchpad_new (in sub.
On Mon, 16 Dec 2002, Andy Dougherty wrote:
> # New Ticket Created by Andy Dougherty
> # Please include the string: [perl #19189]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=19189 >
>
>
> On a Debian/SPARC system with gc
Dave Storrs <[EMAIL PROTECTED]> writes:
> On Mon, Dec 16, 2002 at 06:47:39PM +, Piers Cawley wrote:
>> Michael Lazzaro <[EMAIL PROTECTED]> writes:
>>
>> > Mind you (purely devil's advocate), I'm not entirely sure the R-to-L
>> > syntax truly _needs_ to be in Perl6. It's true I use it all the
At 11:12 AM -0800 12/16/02, Dave Storrs wrote:
On Mon, Dec 16, 2002 at 06:47:39PM +, Piers Cawley wrote:
Michael Lazzaro <[EMAIL PROTECTED]> writes:
> Mind you (purely devil's advocate), I'm not entirely sure the R-to-L
> syntax truly _needs_ to be in Perl6. It's true I use it all the ti
"Piers Cawley" <[EMAIL PROTECTED]> wrote :
> I found myself mulling over:
>
> $obj.is($other_obj);
>
> Which seems to work reasonably well, and I'd be rather surprised if
> it clashed with anything with different semantics...
My only problem with it is the lack of symmetry. Is there any reason
"Dave Whipp" <[EMAIL PROTECTED]> writes:
> "Piers Cawley" <[EMAIL PROTECTED]> wrote :
>> I found myself mulling over:
>>
>> $obj.is($other_obj);
>>
>> Which seems to work reasonably well, and I'd be rather surprised if
>> it clashed with anything with different semantics...
>
> My only problem
"Piers Cawley" <[EMAIL PROTECTED]> wrote :
> > $a eq : ID $b # yes, I would want to generalize that
>
> I started off thinking 'well, you could just define an 'is' operator'
> and then realised we already have one. Hmm. Personally i don't have a
> problem with not having an operator for this par
--- Dave Whipp <[EMAIL PROTECTED]> wrote:
> I can imagine writing:
>
> $a eq:i $b # compare, case insensitive
> $a eq:w $b # compare, ignore whitespace differences
> $a eq:ID $b # compare identities
>
> I think that the modifier concept is too useful to be limited to the
> rx// operator.
Folks,
Just a reminder--our minimum requirements for build, at the moment,
is an ANSI89 compliant C compiler (Hosted version, I think--whatever
has a full set of headers) and perl 5.005_03. At some point we may
raise the perl minimum to 5.6.0, but not right yet. That does mean
some of the new
At 7:12 AM + 12/16/02, Piers Cawley wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
At 4:45 PM + 12/5/02, Leon Brocard wrote:
Leon Brocard sent the following bits through the ether:
Now to get the hand of the signatures...
Ah, well, I gave up on SDL as it was a little complicated
At 1:50 PM + 12/16/02, Nicholas Clark wrote:
On Mon, Dec 16, 2002 at 01:07:36PM +, mcharity @ vendian. org wrote:
This question is actually independent of the patch (which looks good)
simply returns the C it is passed;
C, on the
other hand, returns three times the value that i
At 8:33 AM -0500 12/16/02, Andy Dougherty wrote:
On Mon, 16 Dec 2002, Steve Fink wrote:
I'm a little confused by the va_list* stuff for sprintf*. At one
point, people were saying that ppc does va_list differently, though
I'm guessing that was a different compiler than gcc. Now, it seems
like
Andy Dougherty:
# On Solaris 8, with Sun's Workshop Compiler, using 64-bit long
# longs as INTVAL, I get the following test failure in
# t/src/sprintf. It looks like something is getting passed a
# 64-bit integer quantity but only taking the first 32-bits
# (i.e. an int or long) to do the prin
It would be nice if we could reach a solution that will work for the
miniparrot (no configure, ansi C89 only) case.
--Josh
At 19:17 on 12/16/2002 EST, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:33 AM -0500 12/16/02, Andy Dougherty wrote:
> >On Mon, 16 Dec 2002, Steve Fink wrote:
> >
> >>
On Mon, Dec 16, 2002 at 08:26:25PM +, Piers Cawley wrote:
> Dave Storrs <[EMAIL PROTECTED]> writes:
> > On Mon, Dec 16, 2002 at 06:47:39PM +, Piers Cawley wrote:
> >> Michael Lazzaro <[EMAIL PROTECTED]> writes:
> I haven't been arguing against his syntax for adding L to R
> pipelines, but
On Mon, Dec 16, 2002 at 03:44:21PM -0500, Dan Sugalski wrote:
> At 11:12 AM -0800 12/16/02, Dave Storrs wrote:
> >You find R2L easier to read, I find L2R
> >easier. TIMTOWDI. Perl6 should be smart enough to support both.
>
> Why?
>
> Yes, technically we can do both R2L and L2R. We can also sup
On Fri, 13 Dec 2002 12:37:47 +, Jared Rhine wrote:
> Thanks for the warning. I was aware. I picture a lot of SKIP tests.
> I'm hoping that some particular missing case will be simple enough
> that it'll be a motivator for me to dive into perl6 implementation,
> but if all I get through is tr
Dave Storrs <[EMAIL PROTECTED]> writes:
> On Mon, Dec 16, 2002 at 08:26:25PM +, Piers Cawley wrote:
>> Dave Storrs <[EMAIL PROTECTED]> writes:
>> > On Mon, Dec 16, 2002 at 06:47:39PM +, Piers Cawley wrote:
>> >> Michael Lazzaro <[EMAIL PROTECTED]> writes:
>
>> I haven't been arguing agains
I've just subscribed to the mailing lists, and I'm very excited to be a part
of this. I started reading the documentation and I've been reading through
the tests. It's making a lot of sense, which is a good thing.
My question is, has there been a decision for negative zero? Zero shouldn't be
ne
46 matches
Mail list logo
