# New Ticket Created by Nicholas Clark
# Please include the string: [perl #30737]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=30737
in platform.c I see:
int
Parrot_signbit(double x)
{
union {
double
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;
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 by
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 this seems to be
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 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:
#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() isn't
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
... 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
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
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 dependency.
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
located in
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,
13 matches
Mail list logo
