Skip Menu |

This queue is for tickets about the Inline-Python CPAN distribution.

Report information
The Basics
Id: 55503
Status: resolved
Priority: 0/
Queue: Inline-Python
People
Owner: Nobody in particular
Requestors: jcmdev0 [...] gmail.com
Cc:
AdminCc:
Bug Information
Severity: Important
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Fri Mar 12 12:07:42 2010 jcmdev0 [...] gmail.com - Ticket created
Subject: Perl -> Python type bug after some data operations
Sometimes Inline::Python seems to be interpretting an array of floating point values as an array of integers. I have not yet looked at the Inline::Python code, but I have attached a small test case that demonstrates the behavior.
Subject: inline-float-bug.pl
use Inline Python => <<END; def pyprint(*args): print args END my @a = (0.1,0.2,0.3,0.4); pyprint \@a; # Correct output map($a[$_]+$a[$_], 0..$#a); pyprint \@a; # Incorrect output (all zeros) @a = map($_*1.0, @a); pyprint \@a; # Correct output
  Fri Mar 12 13:28:55 2010 jcmdev0 [...] gmail.com - Correspondence added
From: jcmdev0 [...] gmail.com
On Fri Mar 12 12:07:42 2010, jcmdev0 wrote: Show quoted text
> Sometimes Inline::Python seems to be interpretting an array of floating > point values as an array of integers. I have not yet looked at the > Inline::Python code, but I have attached a small test case that > demonstrates the behavior.
Transposing the integer and float checks in py2pl.c seems to correct the issue. (Patch supplied). I modified the 21arrayref.t (patch supplied) to include a test that fails without the change and succeeds with it. I'm not sure how to create an automated test to ensure integer behavior. Looking at the -debug output for the patched version, it still identifies an array of integers as an array of integers.
Subject: integer_float_transpose.patch
--- Inline-Python-0.34.orig/py2pl.c 2010-01-22 05:29:59.000000000 -0800 +++ Inline-Python-0.34/py2pl.c 2010-03-12 10:08:05.000000000 -0800 @@ -296,11 +296,6 @@ } } - /* An integer */ - else if (SvIOKp(obj)) { - Printf(("integer\n")); - o = PyInt_FromLong((long) SvIV(obj)); - } /* A floating-point number */ else if (SvNOKp(obj)) { PyObject *tmp = PyString_FromString(SvPV_nolen(obj)); @@ -316,6 +311,11 @@ } Py_DECREF(tmp); } + /* An integer */ + else if (SvIOKp(obj)) { + Printf(("integer\n")); + o = PyInt_FromLong((long) SvIV(obj)); + } /* A string */ else if (SvPOKp(obj)) { STRLEN len;
Subject: integer_float_transpose_test.patch
--- Inline-Python-0.34.orig/t/21arrayref.t 2010-03-08 01:39:48.000000000 -0800 +++ Inline-Python-0.34/t/21arrayref.t 2010-03-12 10:10:19.000000000 -0800 @@ -1,4 +1,4 @@ -use Test::More tests => 9; +use Test::More tests => 11; use Inline Config => DIRECTORY => './blib_test'; use Inline::Python qw(py_call_function); @@ -36,6 +36,13 @@ is((perl_list(Foo->new))[2], 3); +my @b = (0.1,0.2,0.3,0.4); +is((bounce_array(\@b))[0], 0.1); + +map($b[$_]+$b[$_], 0..$#b); +is((bounce_array(\@b))[1], 0.2); + + package Foo; sub new {
  Fri Mar 12 17:10:21 2010 nine [...] detonation.org - Correspondence added
On Fri Mar 12 12:07:42 2010, jcmdev0 wrote: Show quoted text
> Sometimes Inline::Python seems to be interpretting an array of
floating Show quoted text
> point values as an array of integers. I have not yet looked at the > Inline::Python code, but I have attached a small test case that > demonstrates the behavior.
Thank you very much for report test cases and patch. It looks good, but I've found out that if one uses SvNOK and SvIOK instead of SvNOKp and SvIOKp, the tests also pass. This is one of the situations where I really would like to talk to the original author, why he did things in this way. But I'll run the question with some wise guys and should release on of the two working versions soon.
  Fri Mar 12 17:10:23 2010 The RT System itself - Status changed from 'new' to 'open'
  Mon Mar 15 13:12:33 2010 jcmdev0 [...] gmail.com - Correspondence added
From: jcmdev0 [...] gmail.com
On Fri Mar 12 17:10:21 2010, NINE wrote: Show quoted text
> On Fri Mar 12 12:07:42 2010, jcmdev0 wrote:
> > Sometimes Inline::Python seems to be interpretting an array of
> floating
> > point values as an array of integers. I have not yet looked at the > > Inline::Python code, but I have attached a small test case that > > demonstrates the behavior.
> > Thank you very much for report test cases and patch. It looks good, but > I've found out that if one uses SvNOK and SvIOK instead of SvNOKp and > SvIOKp, the tests also pass. This is one of the situations where I > really would like to talk to the original author, why he did things in > this way. > > But I'll run the question with some wise guys and should release on of > the two working versions soon.
I don't have much experience with the perl internals. After reading through perlguts, it seems like the SvIOK/SvNOK approach is recommended and is probably less of a hack than what I submitted. Thanks for looking into my bug report.
  Wed Mar 31 05:06:14 2010 nine [...] detonation.org - Correspondence added
Just uploaded Inline::Python 0.35 with a fix for this.
  Wed Mar 31 05:06:16 2010 nine [...] detonation.org - Status changed from 'open' to 'resolved'