Adam Thomason <[EMAIL PROTECTED]> wrote:
> gdb works, but ddd doesn't, so the snippet in jit.pod doesn't work.
You don't need ddd, this works in gdb too. You just have to load the
produced object file and then step into the jit code.
> Adam Thomason
leo
Simon Glover <[EMAIL PROTECTED]> wrote:
> This code (a simplified version of the last test in t/op/number.t)
> set N31, 12.5
> print N31
> print "\n"
> null N31
> print N31
> print "\n"
> end
> 12.5
> 2.0
> when run under the JIT. However, the othe
Adam Thomason <[EMAIL PROTECTED]> wrote:
> Ah, sorry, I stripped new files from the patch. That'll be aix.pl then, =
> attached.
Applied, thanks.
leo
Summary of my parrot 0.0.11.2 configuration:
configdate='Thu Oct 2 13:50:07 2003'
Platform:
osname=linux, archname=i686-linux-ld
jitcapable=1, jitarchname=i386-linux,
jitosname=LINUX, jitcpuarch=i386
execcapable=1
perl=/home/scog/local/bin/perl
Compiler:
cc='gcc', cc
leo -- appending myconfig to bug reports can't harm - never.
Inspired by this bit of wisdom, (and my own earlier silliness with a
useless backtrace), I've updated Aldo's patch faq to cover submissions
to Parrot in general. I suggest it should go in docs.
http://www.parrotcode.org/patchfaq can t
Do we currently have anything that looks at the "/*=for foo bar baz" docs
embedded in the C code? I see it's in some (but not all) of the C files,
and I wanted to double-check the rules as I'm starting the extension code
stuff, but I can't find anything that processes the embedded docs.
# New Ticket Created by Michael Scott
# Please include the string: [perl #24103]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=24103 >
> leo -- appending myconfig to bug reports can't harm - never.
Inspired by this bit of
On Friday, Oct 3, 2003, at 16:12 Europe/Berlin, Dan Sugalski wrote:
Do we currently have anything that looks at the "/*=for foo bar baz"
docs
embedded in the C code? I see it's in some (but not all) of the C
files,
and I wanted to double-check the rules as I'm starting the extension
code
stuff,
On Friday, Oct 3, 2003, at 16:58 Europe/Berlin, Dan Sugalski wrote:
When (says the man with poor access to his mail archives at the moment
:)?
21st Sept 2003
I just heard from Steven R. Loomis (ICU) about this. They have a better
solution which will go into ICU 2.8.
For those interested, it turns out that gcc -MMD writes out the
dependency file by itself, therefore redirecting stdout, which contains
preprocessed text, to the file was wrong.
Here's
Simon Glover <[EMAIL PROTECTED]> wrote:
> null N31
> when run under the JIT. However, the other null ops all seem to work
> properly.
Fixed. The long double was the problem.
> Simon
leo
I have started to access struct members.
The init_pmc (and set_pmc) can now have an initializer:
/* Initialize the struct with some data. This should be an array
* of triples of
* - datatype (enum from datatypes.h)
* - count
* - offset
*/
Before continuing here (o
I've checked in the first part of the extension code for Parrot. It lives
in extend.c, is (not yet) documeted in docs/extend.pod with inline docs in
the code.
Current scheme:
Extenders include parrot/extend.h *only*. Extenders use the routines in
extend.c *only* and, if I've done my work right, t
Okay, it's time to start in, at least a little, on safe mode for parrot.
While there's a *lot* to ultimately do, the initial part, a paranoid set
of ops and a runloop that understands it, is relatively simple. What we
need is someone to thump the code that generates the core_ops.c files (and
their
Dan --
Here's a first version that works with the regular core.
You have to explicitly define PARANOID, or the added code
won't get compiled.
I imagine this will have to be adapted to work with the other
core types, but I wanted to throw this out as a starting point.
I'll leave it up to you whet
15 matches
Mail list logo
