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
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:
> >
> >>
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
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
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 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
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
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
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.
# 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, 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
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
# 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
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
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
>
# 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
# 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 #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 #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 #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 #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
--- 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${
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
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
# 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
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
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
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
28 matches
Mail list logo
