Joshua Gatcomb <[EMAIL PROTECTED]> wrote:
> 2. Almost everything but the most trivial JITed code
> was coredumping.
That's then caused by turning USE_CGP on. Strange. Cygwin gcc must
produce different code then somehow, which breaks things. If you are
using gcc 3.0 or above, -mno-accumulate-outg
Dennis Rieks <[EMAIL PROTECTED]> wrote:
> On Friday 16 July 2004 14:40, Leopold Toetsch wrote:
>> Dennis Rieks <[EMAIL PROTECTED]> wrote:
>> > Hi,
>> >
>> > on my win32 tinderbox there is an missing file pmc_default.h while
>> > compiling src/py_func.c, maybe an wrong -I include path? This file is
On Friday 16 July 2004 14:40, Leopold Toetsch wrote:
> Dennis Rieks <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > on my win32 tinderbox there is an missing file pmc_default.h while
> > compiling src/py_func.c, maybe an wrong -I include path? This file is
> > located in parrot/classes
>
> No missing de
At 9:40 PM +0200 7/19/04, Leopold Toetsch wrote:
Below [1] is a small test program, which basically shows the speed of
calling generators aka coroutines. But *what* I want to discuss isn't
restricted to calling coroutines. Its the same (more or less) with
calling any subroutine-like thingy, being i
... I hope is (inline) attached below
leo
1) Indroduction
Below [1] is a small test program, which basically shows the speed of
calling generators aka coroutines. But *what* I want to discuss isn't
restricted to calling coroutines. Its the same (more or less) with
calling any subroutine-like thing
As is part of my daily (to be read work day) routine,
I do a make realclean, a fresh CVS checkout, rebuild
parrot.
This morning I was noticing 2 problems
1. object tests 40-45 were blowing up - thanks to
Nicholas for pointing it out and Leo for fixing it
2. Almost everything but the most trivia
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> #2 0x000cbd58 in Parrot_default_destroy (interpreter=0x1000200, pmc=0x1017bb8) at
> classes/default.c:189
> #3 0x001f92dc in Parrot_deleg_pmc_destroy (interpreter=0x1000200, pmc=0x1017bd0) at
> classes/deleg_pmc.c:143
Should be fixed now. destroy() i
On Thu, 2004-07-15 at 22:46, Dan Sugalski wrote:
> And language builtin namespaces in general. We need a standard, and
> now's as good a time as any, so...
>
> All language-specific builtin functions go into the _core_Language
> namespace. (So for Python it's _core_Python, Perl 5 is _core_Perl5,
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> in platform.c I see:
> int
> Parrot_signbit(double x)
> This is buggy.
This is generated platform code and overridable in platform/*/math.c
Better code for _signbit is of course welcome.
> Nicholas Clark
leo
On Mon, 19 Jul 2004, Nicholas Clark wrote:
> int
> Parrot_signbit(double x)
> {
>union {
>double d;
>int i[2];
>} u;
>u.d = x;
> #if PARROT_BIGENDIAN
>return u.i[0] < 0;
> #else
>return u.i[1] < 0;
> #endif
> }
> This is buggy. Even on an IEEE platform (which t
The platform-specific function can be autogenerated, if the build and
runtime systems are the same, with the attached file. [It's not a patch
because I'm clueless about the config system and have no idea where it
would go.]
--Andy
>>> [EMAIL PROTECTED] 2004-07-19 08:55:54 >>>
# New Ticket Created
I was finding that t/pmc/objects.t tests 40-45 were failing with a SIGBUS.
Running t/pmc/objects_40.imc
The stack backtrace revealed that the cause was jumping to a garbage address
in the call node->function in Parrot_exit:
void Parrot_exit(int status) {
handler_node_t *node, *next_node;
# New Ticket Created by Nicholas Clark
# Please include the string: [perl #30737]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=30737 >
in platform.c I see:
int
Parrot_signbit(double x)
{
union {
double d;
13 matches
Mail list logo
