# New Ticket Created by Simon Glover
# Please include the string: [perl #22867]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=22867 >
Based on the documentation in core.ops, I would expect this code:
set S15, "a\n"
On Tue, 1 Jul 2003, Dan Sugalski wrote:
> This dies on 9 tests on OS X, and I think from the complaints that
> valgrind will also be very unhappy, but I'm putting it in so it can
> be thumped by other folks as well as me.
I think I might have figured out why valgrind's unhappy. We're
currently
On Monday, June 30, 2003, at 02:07 pm, Fergal Daly wrote:
On Wednesday 25 June 2003 20:15, Adrian Howard wrote:
Add an explicit "test script finished" footer?
But how does the footer-adder know that the correct number of tests
ran. You
would need to declare a plan to run x additional extensions
* Jonadab the Unsightly One ([EMAIL PROTECTED]) [01 Jul 2003 23:41]:
> Iain Truskett <[EMAIL PROTECTED]> writes:
> > Not the only one. And with Parrot being able to execute
> > Z-code, it might be sane to port Inform to Parrot!
> Did you mean port Inform to run on Parrot, or port Inform
> to comp
At 8:06 PM +0200 7/1/03, Juergen Boemmels wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
This dies on 9 tests on OS X, and I think from the complaints that
valgrind will also be very unhappy, but I'm putting it in so it can be
thumped by other folks as well as me.
The tinderboxens are very unh
? include/parrot/platform_interface.h
Index: embed.c
===
RCS file: /cvs/public/parrot/embed.c,v
retrieving revision 1.69
diff -u -r1.69 embed.c
--- embed.c 1 Jul 2003 15:41:00 - 1.69
+++ embed.c 1 Jul 2003 17:59:34 -
@@ -220,9
"Andy Dougherty" <[EMAIL PROTECTED]> wrote:
> The problem is that with a clean build tree, there are no *.o files
> down in languages/imcc/ at the point when that target is reached.
> Hence make doesn't have anything to expand *.o as, and quite reasonably
> complains. If, however, there is even a
At 1:18 AM +0100 7/1/03, Alan Burlison wrote:
Rafael Garcia-Suarez wrote:
Hmm, I'm only a lurker, but that looks *very* suspect to me. Some
compilers may choose to reorder even without optimization turned
on. I'd say that it is a bug in Parrot if it requires
optimization to be off for this co
At 1:41 PM + 7/1/03, "J¸rgen" "Bmmels" (via RT) wrote:
this is the first step of the IO-system away from the mem_sys_alloc/free
memory-managment system to a full-fledged PMC-based system.
In this patch only the ParrotIO structures are transformed to a
PMC. This is simply done by wrapping the P
On Tue, Jul 01, 2003 at 10:04:41AM -0400, Andy Dougherty wrote:
> The problem is that with a clean build tree, there are no *.o files
> down in languages/imcc/ at the point when that target is reached.
> Hence make doesn't have anything to expand *.o as, and quite reasonably
> complains. If, howev
On Tue, 1 Jul 2003, Leopold Toetsch wrote:
> Andy Dougherty <[EMAIL PROTECTED]> wrote:
> > On Mon, 30 Jun 2003, Leopold Toetsch wrote:
>
> >> Attached is a minimum patch to build imcc as the parrot executable
>
> >languages/imcc/*.o
>
> > languages/imcc/*.o doesn't match anything
>
Iain Truskett <[EMAIL PROTECTED]> writes:
> Not the only one. And with Parrot being able to execute Z-code, it
> might be sane to port Inform to Parrot!
Did you mean port Inform to run on Parrot, or port Inform to compile
to parrot? If the former, that should be no problem. If the latter,
I'm n
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #22864]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=22864 >
Hello,
this is the first step of the IO-system away from the mem_sys_alloc/free
memor
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Simon Glover <[EMAIL PROTECTED]> wrote:
> > I'm getting failures in tests 1 & 2 in t/pmc/io.t; however, both tests
> > seem to run fine if I run them in the debugger.
>
> valgrind does indicate, that there are unitialized items in many
> parts of io
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Should the "raise" opcode produce resumable exceptions?
There is no problem with resuming after an opcode. E.g. when C
is:
invokecc Px # call exception handler
and the handler returns by C i.e. via the return
continuation, execution just resumes
This is taken from this week's summary, but I thought this post would fit
best in this thread.
>
> Tentative valclone patch
> Luke Palmer has been thinking about value and reference objects. He
> wondered if there was any value in a "valclone" operator alongside
"set"
> and "clone" wh
This is taken from this week's summary, but I thought this post would fit
best in this thread.
>
> Tentative valclone patch
> Luke Palmer has been thinking about value and reference objects. He
> wondered if there was any value in a "valclone" operator alongside
"set"
> and "clone" wh
17 matches
Mail list logo
