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
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 11:55 PM +0100 10/3/03, Piers Cawley wrote:
>>Dan Sugalski <[EMAIL PROTECTED]> writes:
>>
>>> On Thu, 2 Oct 2003, Mark A. Biggar wrote:
>>>
Austin Hastings wrote:
>>>
> But that imposes eval() pretty frequently. Better to provide
> s
At 11:55 PM +0100 10/3/03, Piers Cawley wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
On Thu, 2 Oct 2003, Mark A. Biggar wrote:
Austin Hastings wrote:
> But that imposes eval() pretty frequently. Better to provide
> some lower-level hackish way to agglutinate Blocks.
Isn't this one of the
Dan Sugalski <[EMAIL PROTECTED]> writes:
> On Thu, 2 Oct 2003, Mark A. Biggar wrote:
>
>> Austin Hastings wrote:
>
>> > But that imposes eval() pretty frequently. Better to provide
>> > some lower-level hackish way to agglutinate Blocks.
>>
>>
>> Isn't this one of the prime examples of why CPS is
Ovid wrote:
> I was running some test code with Devel::Cover and I've had no problem using
> it or generating pretty reports that make coworkers "ooh" and "ahh".
> Unfortunately, I started running my test suite on a different set of
> tests and started getting some strange errors...
I have no expe
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
Hi all,
I was running some test code with Devel::Cover and I've had no problem using it or
generating
pretty reports that make coworkers "ooh" and "ahh". Unfortunately, I started running
my test
suite on a different set of tests and started getting some strange errors (formatted
for clarity):
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
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
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 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
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
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 Thu, 2 Oct 2003, Mark A. Biggar wrote:
> Austin Hastings wrote:
> > But that imposes eval() pretty frequently. Better to provide
> > some lower-level hackish way to agglutinate Blocks.
>
>
> Isn't this one of the prime examples of why CPS is being use, it allows
> for Tail Recursion Optimizati
# 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
Austin Hastings wrote:
-Original Message-
From: Luke Palmer [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 10:23 PM
To: Jeff Clites
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: The Block Returns
Jeff Clites writes:
Speaking to the practical side, I have written code
On Fri, 3 Oct 2003, Simon Cozens wrote:
> Dunno what .= would mean now . is method call. I'm sure someone will make it
> mean something. :)
I've been saying for some time now that .= should mean exactly what one would expect
it to mean, method call and assign the result, for code like
$str .= lc
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.
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
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
On Fri, 3 Oct 2003, Simon Cozens wrote:
> [EMAIL PROTECTED] (Austin Hastings) writes:
> > eval($block) if defined $block;
>
> I prefer $block.compile.run to eval()
They're not quite equivalent -- I think eval's still wrapping a try/catch
around the call.
Adam Thomason <[EMAIL PROTECTED]> wrote:
> Ah, sorry, I stripped new files from the patch. That'll be aix.pl then, =
> attached.
Applied, thanks.
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
Simon Cozens writes:
> [EMAIL PROTECTED] (Austin Hastings) writes:
> > Frankly, I think I'd rather see:
>
> Some nits:
>
> > macro atexit($code) is parsed(/{ * }/) {
>
> Probably just
>macro atexit($code) is parsed(//) {
>
> > $block .= $code;
> $block _= $code;
$block
[EMAIL PROTECTED] (Austin Hastings) writes:
> Frankly, I think I'd rather see:
Some nits:
> macro atexit($code) is parsed(/{ * }/) {
Probably just
macro atexit($code) is parsed(//) {
> $block .= $code;
$block _= $code;
Dunno what .= would mean now . is method call. I'm sure som
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
26 matches
Mail list logo