You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pylucene-dev@lucene.apache.org by Andi Vajda <va...@apache.org> on 2013/08/22 11:46:38 UTC
[NAG][VOTE] Release PyLucene 4.4.0-1
One more PMC vote is needed for this vote pass...
Thanks !
Andi..
---------- Forwarded message ----------
Date: Sat, 17 Aug 2013 07:52:07 -0700 (PDT)
From: Andi Vajda <va...@apache.org>
Reply-To: pylucene-dev@lucene.apache.org, Andi Vajda <va...@apache.org>
To: pylucene-dev@lucene.apache.org
Cc: general@lucene.apache.org
Subject: [VOTE] Release PyLucene 4.4.0-1
The PyLucene 4.4.0-1 release tracking the recent release of Apache Lucene 4.4.0
is ready.
A release candidate is available from:
http://people.apache.org/~vajda/staging_area/
A list of changes in this release can be seen at:
http://svn.apache.org/repos/asf/lucene/pylucene/branches/pylucene_4_4/CHANGES
PyLucene 4.4.0 is built with JCC 2.17 included in these release artifacts:
http://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/CHANGES
A list of Lucene Java changes can be seen at:
http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_4_4_0/lucene/CHANGES.txt
Please vote to release these artifacts as PyLucene 4.4.0-1.
Thanks !
Andi..
ps: the KEYS file for PyLucene release signing is at:
http://svn.apache.org/repos/asf/lucene/pylucene/dist/KEYS
http://people.apache.org/~vajda/staging_area/KEYS
pps: here is my +1
Re: Problem using generic types?
Posted by Petrus Hyvönen <pe...@gmail.com>.
Dear Andi,
Many many thanks for looking into this!
I am on travel for a week and do not have the computer with the special case with me to test. I did now however run it on the library that I am wrapping, and there get some errors in the creation of the wrapped module (orekit):
build/_orekit/__wrap__.cpp:86504:89: error: no member named
'HarmonicOscillator$Parametric$$Type' in namespace
'org::apache::commons::math3::analysis::function'
...= &::org::apache::commons::math3::analysis::function::PY_TYPE(HarmonicOs...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
/Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23: note:
expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
^
<scratch space>:63:1: note: expanded from here
HarmonicOscillator$Parametric$$Type
^
build/_orekit/__wrap__.cpp:217752:55: error: no member named
'OrekitMessages$$Type' in namespace 'org::orekit::errors'
self->parameters[0] = &::org::orekit::errors::PY_TYPE(OrekitMessages);
~~~~~~~~~~~~~~~~~~~~~~~^
/Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23: note:
expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
^
<scratch space>:9:1: note: expanded from here
OrekitMessages$$Type
^
2 errors generated.
error: command 'gcc' failed with exit status 1
The OrekitMessages is defined as a "public enum OrekitMessages implements Localizable { ..."
and the "public class HarmonicOscillator implements UnivariateDifferentiable, DifferentiableUnivariateFunction".
Maybe this says you something, I will try to test more and run my test case in .
Best Regards and again, many thanks again!
/Petrus
Re: Problem using generic types?
Posted by Petrus Hyvönen <pe...@gmail.com>.
Dear Andi,
Many many thanks for looking into this!
I am on travel for a week and do not have the computer with the special case with me to test. I did now however run it on the library that I am wrapping, and there get some errors in the creation of the wrapped module (orekit):
build/_orekit/__wrap__.cpp:86504:89: error: no member named
'HarmonicOscillator$Parametric$$Type' in namespace
'org::apache::commons::math3::analysis::function'
...= &::org::apache::commons::math3::analysis::function::PY_TYPE(HarmonicOs...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
/Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23: note:
expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
^
<scratch space>:63:1: note: expanded from here
HarmonicOscillator$Parametric$$Type
^
build/_orekit/__wrap__.cpp:217752:55: error: no member named
'OrekitMessages$$Type' in namespace 'org::orekit::errors'
self->parameters[0] = &::org::orekit::errors::PY_TYPE(OrekitMessages);
~~~~~~~~~~~~~~~~~~~~~~~^
/Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23: note:
expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
^
<scratch space>:9:1: note: expanded from here
OrekitMessages$$Type
^
2 errors generated.
error: command 'gcc' failed with exit status 1
The OrekitMessages is defined as a "public enum OrekitMessages implements Localizable { ..."
and the "public class HarmonicOscillator implements UnivariateDifferentiable, DifferentiableUnivariateFunction".
Maybe this says you something, I will try to test more and run my test case in .
Best Regards and again, many thanks again!
/petrus
On 11 Jan 2014, at 14:23 , Andi Vajda <va...@apache.org> wrote:
>
> Hi Petrus,
>
> On Mon, 30 Dec 2013, Petrus Hyvönen wrote:
>
>> Andi, great to hear that you could reproduce it. I'm very thankful if you
>> could have a look at it, I've been struggling to understand how the
>> machinery behind this works, but far from it still..
>
> I think I fixed the problem and added an improvement to generics support along the way. Please check out rev 1557423 from jcc's trunk, rebuild your module with it and let me know how it's working for you.
>
> The bug had to do with SimpleClass2's wrapper class missing its parameters slot which it should get from its superclass, SimpleClass. When calling a
> method on SimpleClass from SimpleClass2, the missing parameters in the
> wrapper's struct would cause memory to get trashed.
>
> In addition to fixing the bug, I also improved support for fixed class parameters. Now, if you change SimpleClass's return_null() method to return new Integer(12) instead, when calling it on SimpleClass2, 12 is returned instead of <Object: 12>.
>
> Andi..
>
> public class SimpleClass<T> { public SimpleClass() { System.out.println("Created SimpleClass"); }
> public T return_null() {
> return (T) new Integer(12);
> }
>
> }
>
>
>>
>> Best Regards
>> /Petrus
>>
>>
>>
>> On Mon, Dec 30, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>>
>>>
>>> On Sun, 29 Dec 2013, Petrus Hyvönen wrote:
>>>
>>> I have distilled the library that I have some trouble with and I think I
>>>> have an example that is failing due to same problem I think. I am not good
>>>> in java, but have tried to follow the logic from the library I'm wrapping.
>>>> The function of the example does not make sense in itself.
>>>>
>>>> public class SimpleClass<T> {
>>>> public SimpleClass() {
>>>> System.out.println("Created SimpleClass");
>>>> }
>>>> public T return_null() {
>>>> return null;
>>>> }
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>> public class SimpleClass2 extends SimpleClass<Integer>{
>>>>
>>>> public SimpleClass2(){}
>>>> public void testInJava(){
>>>> System.out.println(this.return_null());
>>>> }
>>>> }
>>>>
>>>>
>>>> It seems to me that there is some problem with methods inherited that
>>>> returns a generic type, failing in wrapType when this is to be wrapped.
>>>>
>>>> The python script that fails:
>>>>
>>>> a= SimpleClass()
>>>> print a.return_null()
>>>>
>>>> b = SimpleClass2()
>>>> b.testInJava()
>>>>
>>>> print b.return_null() #Fails in wrapType
>>>>
>>>> I don't know if the return null is a bad thing to do in java, but the
>>>> error
>>>> seems very similar to what I experience in the larger library. I have a
>>>> skeleton of that this is slightly larger, but not returning null, but
>>>> trying to keep the lenght of example low :)
>>>>
>>>> Any comments highly appriciated :)
>>>>
>>>
>>> I've been able to reproduce the problem.
>>> Thank you for providing an isolated test case !
>>>
>>> Andi..
>>>
>>>
>>>
>>>> best Regards
>>>> /Petrus
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Dec 27, 2013 at 6:25 PM, Andi Vajda <va...@apache.org> wrote:
>>>>
>>>>
>>>>> On Dec 27, 2013, at 17:36, Petrus Hyvönen <pe...@gmail.com>
>>>>>>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Dear Andi,
>>>>>>
>>>>>> I am working on debugging the failure and try to understand a bit how
>>>>>> JCC
>>>>>> works internally. I haven't gone very far but in case you have some
>>>>>> pointers from these early debugging sessions I would be very thankful. I
>>>>>> know it's complex, and I should try to make some smaller test cases, but
>>>>>>
>>>>> I
>>>>>
>>>>>> don't really have a grasp yet where the problem might be.
>>>>>>
>>>>>> Writing this might help me also to get some structure in my thinking :)
>>>>>>
>>>>>>
>>>>>>
>>>>>> The main crash seems to be in the last line, wrapType(), of
>>>>>> __wrap__.cpp:
>>>>>>
>>>>>> static PyObject
>>>>>>
>>>>>> *t_AbstractReconfigurableDetector_withHandler(t_
>>>>> AbstractReconfigurableDetector
>>>>>
>>>>>> *self, PyObject *arg)
>>>>>> {
>>>>>> ::org::orekit::propagation::events::handlers::EventHandler
>>>>>> a0((jobject) NULL);
>>>>>> PyTypeObject **p0;
>>>>>> ::org::orekit::propagation::events::EventDetector
>>>>>> result((jobject) NULL);
>>>>>>
>>>>>> if (!parseArg(arg, "K",
>>>>>>
>>>>>> ::org::orekit::propagation::events::handlers::
>>>>> EventHandler::initializeClass,
>>>>>
>>>>>> &a0, &p0,
>>>>>>
>>>>>> ::org::orekit::propagation::events::handlers::t_
>>>>> EventHandler::parameters_))
>>>>>
>>>>>> {
>>>>>> OBJ_CALL(result = self->object.withHandler(a0));
>>>>>> return self->parameters[0] != NULL ?
>>>>>> wrapType(self->parameters[0], result.this$) :
>>>>>> ::org::orekit::propagation::events::t_EventDetector::wrap_
>>>>>> Object(result);
>>>>>> }
>>>>>>
>>>>>> The parameters[0] does not seem to be null, but neither is it a valid
>>>>>> object, in my debugger it says 0xbaadf00d {ob_refcnt=??? ob_type=???
>>>>>> ob_size=??? ...} _typeobject *, wrapType is called and when trying
>>>>>> to
>>>>>> access the wrapfn it crashes.
>>>>>>
>>>>>> The main python lines are:
>>>>>> tmp1 = ElevationDetector(sta1Frame) #
>>>>>>
>>>>> ElevationDetector
>>>>>
>>>>>> is a java public class ElevationDetector extends
>>>>>> AbstractReconfigurableDetector<ElevationDetector>
>>>>>> hand = ContinueOnEvent().of_(ElevationDetector) # a
>>>>>> java ContinueOnEvent<ElevationDetector> object
>>>>>> elDetector = tmp1.withHandler(hand) #Crash. withHandler is a method
>>>>>> that is inherited from AbstractReconfigurableDetector to
>>>>>>
>>>>> ElevationDetector
>>>>>
>>>>>>
>>>>>> This crashes when interactively entered on the python prompt (or in
>>>>>> other
>>>>>> interactive consoles), but seems to work if executed directly without
>>>>>> interactivity. This difference makes me think that it might be something
>>>>>> with garbage collection, but don't know.
>>>>>>
>>>>>> Any comments appriciated, I know this is likely very difficult to
>>>>>> comment
>>>>>> on as it's not very encapsulated.
>>>>>>
>>>>>
>>>>> Right, so unless you can isolate this into something I can reproduce, I'm
>>>>> afraid there isn't much I can comment.
>>>>> It is quite likely that by the time you have that reproducible test case
>>>>> ready, you also have the solution to the problem. Or I might be able to
>>>>> help then...
>>>>>
>>>>> Andi..
>>>>>
>>>>>
>>>>>> Regards
>>>>>> /Petrus
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Dec 15, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Dec 15, 2013, at 5:43, Petrus Hyvönen <pe...@gmail.com>
>>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Andi,
>>>>>>>>
>>>>>>>> I see your point and have now kept in the pure python domain.
>>>>>>>>
>>>>>>>> If I run my script from the shell by "python script.py" it does not
>>>>>>>>
>>>>>>> crash. However if I execute it line-by-line in python it crashes (or in
>>>>>>> other tools such as ipython notebook).
>>>>>>>
>>>>>>>> All classes used are non-wrapped java classes, but I get the same
>>>>>>>>
>>>>>>> effect
>>>>>
>>>>>> with classes made for python subclassing.
>>>>>>>
>>>>>>>> I am getting this on both MacOSX 64-bit python and Windows 7 32-bit
>>>>>>>>
>>>>>>> python.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> elDetector =
>>>>>>>>>>>
>>>>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>>
>>>>>>>> #
>>>>>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>>>>>> #
>>>>>>>> # SIGSEGV (0xb) at pc=0x000000010005da1a, pid=3318, tid=1287
>>>>>>>> #
>>>>>>>> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
>>>>>>>>
>>>>>>> 1.7.0_45-b18)
>>>>>>>
>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
>>>>>>>>
>>>>>>> bsd-amd64 compressed oops)
>>>>>>>
>>>>>>>> # Problematic frame:
>>>>>>>> # C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>>>>>>> #
>>>>>>>>
>>>>>>>>
>>>>>>>> from the stack it seems like there is somthing happening in "wrapType"
>>>>>>>> Stack: [0x00007fff5fb80000,0x00007fff5fc00000],
>>>>>>>> sp=0x00007fff5fbff470,
>>>>>>>>
>>>>>>> free space=509k
>>>>>>>
>>>>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>>>>>>>
>>>>>>> C=native code)
>>>>>>>
>>>>>>>> C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>>>>>>> C [_orekit.so+0xa80878] wrapType(_typeobject*, _jobject*
>>>>>>>> const&)+0x58
>>>>>>>> C [_orekit.so+0x554400]
>>>>>>>>
>>>>>>>
>>>>>>> org::orekit::propagation::events::t_AbstractReconfigurableDetector
>>>>> _withHandler(org::orekit::propagation::events::t_
>>>>> AbstractReconfigurableDetector*,
>>>>>
>>>>>> _object*)+0x1c0
>>>>>>>
>>>>>>>>
>>>>>>>> First, is the generic class assignment correct as if to write "new
>>>>>>>>
>>>>>>> ContinueOnEvent<ElevationDetector>()" in java? And is it ok to use
>>>>>>>
>>>>>> regular
>>>>>
>>>>>> java objects/types?
>>>>>>>
>>>>>>>>
>>>>>>>> Any other comments to move forward highly appriciated.. Is it somehow
>>>>>>>>
>>>>>>> possible to get more log what is going wrong?
>>>>>>>
>>>>>>> You could compile the whole thing for debugging, by adding --debug
>>>>>>> after
>>>>>>> 'build' in the jcc invocation and run it with gdb.
>>>>>>>
>>>>>>> If you can isolate a reproducible crash into a small test case, I can
>>>>>>>
>>>>>> also
>>>>>
>>>>>> take a look at it.
>>>>>>>
>>>>>>> Andi..
>>>>>>>
>>>>>>>
>>>>>>>> WIth best regards
>>>>>>>> /Petrus
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 15 Dec 2013, at 2:40 , Andi Vajda <va...@apache.org> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Dec 14, 2013, at 19:14, Petrus Hyvönen <petrus.hyvonen@gmail.com
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I'm having a problem with I think might be related to generic types,
>>>>>>>>>>
>>>>>>>>> but not sure at all.
>>>>>>>
>>>>>>>>
>>>>>>>>>> I'm wrapping a orbit calculation library, which has been working
>>>>>>>>>> well
>>>>>>>>>>
>>>>>>>>> but in latest version is using generic types and I'm getting some
>>>>>>>
>>>>>> problems.
>>>>>
>>>>>> The script works when executed in plain python, but fails in ipython
>>>>>>> notebook on this last line when executed as a couple of cells.
>>>>>>>
>>>>>>>>
>>>>>>>>> What is an 'ipython notebook' ?
>>>>>>>>>
>>>>>>>>> Andi.,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> The section with problem in my script is:
>>>>>>>>>> elDetector =
>>>>>>>>>>
>>>>>>>>> ElevationDetector(sta1Frame).withConstantElevation(math.
>>>>>>> radians(5.0))
>>>>>>>
>>>>>>>> elDetector =
>>>>>>>>>>
>>>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>>
>>>>>>>>
>>>>>>>>>> In Java it would typically look something like:
>>>>>>>>>>
>>>>>>>>>> ElevationDetector detector = new ElevationDetector(topo)
>>>>>>>>>> .withConstantElevation(x)
>>>>>>>>>> .withHandler(new
>>>>>>>>>>
>>>>>>>>> ContinueOnEvent<ElevationDetector>());
>>>>>>>
>>>>>>>>
>>>>>>>>>> It produces correct results in plain python, but crashes the kernel
>>>>>>>>>>
>>>>>>>>> in
>>>>>
>>>>>> ipython if executed as cells, and in exection from spyder I get an error
>>>>>>> message:
>>>>>>>
>>>>>>>>
>>>>>>>>>> " elDetector =
>>>>>>>>>>
>>>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>>
>>>>>>>> AttributeError: 'str' object has no attribute 'wrapfn_' "
>>>>>>>>>>
>>>>>>>>>> As I have been using this setup stabely with lots of other functions
>>>>>>>>>>
>>>>>>>>> it feels like there is something with the generic type line, but I
>>>>>>> don't
>>>>>>> really know how to get any further? I'm confused by that the pauses in
>>>>>>>
>>>>>> the
>>>>>
>>>>>> execution could seem to affect the result.
>>>>>>>
>>>>>>>>
>>>>>>>>>> Any comments highly appriciated...
>>>>>>>>>>
>>>>>>>>>> Best Regards
>>>>>>>>>> /Petrus
>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> _____________________________________________
>>>>>> Petrus Hyvönen, Uppsala, Sweden
>>>>>> Mobile Phone/SMS:+46 73 803 19 00
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> _____________________________________________
>>>> Petrus Hyvönen, Uppsala, Sweden
>>>> Mobile Phone/SMS:+46 73 803 19 00
>>>>
>>>
>>
>>
>> --
>> _____________________________________________
>> Petrus Hyvönen, Uppsala, Sweden
>> Mobile Phone/SMS:+46 73 803 19 00
Re: Problem using generic types?
Posted by Petrus Hyvönen <pe...@gmail.com>.
Thanks Andi!
Rev 1563753 Builds and runs fine now on the Mac and Windows!
I need to check my Windows machine and get rid of any old versions, think it shouldn't be there but obviously it is strange that it worked..
Many thanks!
Regards
/Petrus
On 03 Feb 2014, at 2:44 , Andi Vajda <va...@apache.org> wrote:
>>
>> And I've now reproduced it by adding s SimpleClass3 class to the example you had sent in last time that looks like this:
>>
>> public class SimpleClass3 extends SimpleClass<double[]>{
>>
>> public SimpleClass3(){}
>> public void testInJava(){
>> System.out.println(this.return_null());
>> } }
>
> I think I fixed this. Please try jcc rev 1563753.
> Thanks !
>
> Andi..
>
Re: Problem using generic types?
Posted by Andi Vajda <va...@apache.org>.
On Sun, 2 Feb 2014, Andi Vajda wrote:
>
> On Sun, 2 Feb 2014, Andi Vajda wrote:
>
>>
>> On Sun, 2 Feb 2014, Petrus Hyvönen wrote:
>>
>>> Yes, the confusing thing is that it works well under windows. I compared
>>> the code in __wrap__ and it looks different in the windows version:
>>>
>>> static int t_PointVectorValuePair_init_(t_PointVectorValuePair *self,
>>> PyObject *args, PyObject *kwds)
>>> {
>>> switch (PyTuple_GET_SIZE(args)) {
>>> case 2:
>>> {
>>> JArray< jdouble > a0((jobject) NULL);
>>> JArray< jdouble > a1((jobject) NULL);
>>> PointVectorValuePair object((jobject) NULL);
>>>
>>> if (!parseArgs(args, "[D[D", &a0, &a1))
>>> {
>>> INT_CALL(object = PointVectorValuePair(a0, a1));
>>> self->object = object;
>>> break;
>>> }
>>> }
>>>
>>>
>>> So no Parameters[] stuff in windows version.. On mac I'm using java v
>>> 1.7.0_45 and 1.6.0_35 under windows. could that make a difference?
>>
>> That could also make a difference but there is a bug nonetheless.
>
> And I've now reproduced it by adding s SimpleClass3 class to the example you
> had sent in last time that looks like this:
>
> public class SimpleClass3 extends SimpleClass<double[]>{
>
> public SimpleClass3(){}
> public void testInJava(){
> System.out.println(this.return_null());
> } }
I think I fixed this. Please try jcc rev 1563753.
Thanks !
Andi..
>
> Andi..
>
>>
>> Andi..
>>
>>>
>>> I'm using a mvn downloaded version of the apache.math jar, but source is:
>>>
>>> public class PointVectorValuePair extends Pair<double[], double[]>
>>> implements Serializable {
>>> /** Serializable UID. */
>>> private static final long serialVersionUID = 20120513L;
>>>
>>> /**
>>> ...
>>> */
>>> public PointVectorValuePair(final double[] point,
>>> final double[] value) {
>>> this(point, value, true);
>>> }
>>>
>>> /**
>>> ...
>>> */
>>> public PointVectorValuePair(final double[] point,
>>> final double[] value,
>>> final boolean copyArray) {
>>> super(copyArray ?
>>> ((point == null) ? null :
>>> point.clone()) :
>>> point,
>>> copyArray ?
>>> ((value == null) ? null :
>>> value.clone()) :
>>> value);
>>> }
>>>
>>> ...
>>>
>>> full code at
>>> http://commons-math/jacoco/org.apache.commons.math3.optimization/PointVectorValuePair.java.html
>>>
>>>
>>>
>>> Regards
>>> /petrus
>>>
>>>
>>> On 02 Feb 2014, at 22:54 , Andi Vajda <va...@apache.org> wrote:
>>>
>>>
>>> On Feb 2, 2014, at 13:41, Petrus Hyvönen <pe...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> It's part of a class "PointVectorValuePair" and "PointValuePair" in the
>>> apache math commons (
>>> http://commons.apache.org/proper/commons-math/javadocs/api-3.2/org/apache/commons/math3/optimization/PointVectorValuePair.html
>>> )
>>>
>>> I have tried to reserve a bunch of things like 'Point', 'Value', 'Pair'
>>> without any difference. If I go through the __wrap__ file, it looks like
>>> this [D object to wrap is a very odd one, the other PY_TYPE wrapping seems
>>> to have 'proper' names without special characters. It's the functions
>>> PointValuePair and PointVectorValuePair that seems to have this strage
>>> class wrapping. I cannot find a class named D. From the API doc's I would
>>> guess it's trying to set a double [] type.
>>>
>>> extract from __wrap__:
>>>
>>> under namespace org {
>>> namespace apache {
>>> namespace commons {
>>> namespace math3 {
>>> namespace optimization {
>>>
>>> ...
>>>
>>> static int t_PointVectorValuePair_init_(t_PointVectorValuePair
>>> *self, PyObject *args, PyObject *kwds)
>>> {
>>> switch (PyTuple_GET_SIZE(args)) {
>>> case 2:
>>> {
>>> JArray< jdouble > a0((jobject) NULL);
>>> JArray< jdouble > a1((jobject) NULL);
>>> PointVectorValuePair object((jobject) NULL);
>>>
>>> if (!parseArgs(args, "[D[D", &a0, &a1))
>>>
>>>
>>> It could just be that you found a bug in jcc's handling of generic
>>> parameters that are arrays. I suspect you have some double[] (or worse:
>>> double[][]) somewhere in the java source.
>>> But then this should fail the same way on Windows.
>>> Can you please post the original java source for that class here ?
>>>
>>> Andi..
>>>
>>> {
>>> INT_CALL(object = PointVectorValuePair(a0, a1));
>>> self->object = object;
>>> self->parameters[0] = &::PY_TYPE([D);
>>> self->parameters[1] = &::PY_TYPE([D);
>>> break;
>>> }
>>>
>>> Regards
>>> /petrus
>>>
>>>
>>>
>>> = &::PY_TYPE([D);
>>> ^
>>> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
>>> note:
>>> expanded from macro 'PY_TYPE'
>>> #define PY_TYPE(name) name##$$Type
>>> ^
>>> build/_orekit/__wrap__.cpp:58329:44: error: use of undeclared identifier
>>> 'D$$Type'
>>> self->parameters[0] = &::PY_TYPE([D);
>>> ^
>>> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
>>> note:
>>> expanded from macro 'PY_TYPE'
>>> #define PY_TYPE(name) name##$$Type
>>> ^
>>> <scratch space>:109:1: note: expanded from here
>>> D$$Type
>>> ^
>>> build/_orekit/__wrap__.cpp:58329:55: error: expected ']'
>>> self->parameters[0] = &::PY_TYPE([D);
>>> ^
>>> build/_orekit/__wrap__.cpp:58329:52: note: to match this '['
>>> self->parameters[0] = &::PY_TYPE([D);
>>>
>>>
>>> On 02 Feb 2014, at 19:48 , Andi Vajda <va...@apache.org> wrote:
>>>
>>>
>>> On Feb 2, 2014, at 10:08, Petrus Hyvönen <pe...@gmail.com> wrote:
>>>
>>> Hi Andi and Others,
>>>
>>> The latest trunk jcc works and builds very fine on my windows machine, and
>>> happy about the extendend support of generics. But I am experiencing the
>>> problem below when building on my mac, using same wrap parameters as on
>>> the
>>> windows platform. To me it seems like some compiler problem related to
>>> macros, but don't know.
>>>
>>> Does anyone have experience of these failures?
>>>
>>> Regards
>>> /Petrus
>>>
>>>
>>> error: expected unqualified-id
>>> self->parameters[0] = &::PY_TYPE([D);
>>> ^
>>> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
>>> note:
>>> expanded from macro 'PY_TYPE'
>>> #define PY_TYPE(name) name##$$Type
>>> ^
>>> build/_orekit/__wrap__.cpp:2344:44: error: use of undeclared identifier
>>> 'D$$Type'
>>> self->parameters[0] = &::PY_TYPE([D);
>>>
>>>
>>> Take a look at the code around line 2344 in that __wrap__.cpp file and
>>> figure out what java code this corresponds to. You might be using a
>>> classname that's a C macro on some platforms - do you have a class named D
>>> for example ?
>>> If you're hitting such a name conflict, add that name to the --reserved
>>> list passed to jcc.
>>>
>>> Andi..
>>>
>>> ^
>>> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
>>> note:
>>> expanded from macro 'PY_TYPE'
>>> #define PY_TYPE(name) name##$$Type
>>> ^
>>> <scratch space>:73:1: note: expanded from here
>>> D$$Type
>>> ^
>>> build/_orekit/__wrap__.cpp:2344:55: error: expected ']'
>>> self->parameters[0] = &::PY_TYPE([D);
>>> ^
>>> build/_orekit/__wrap__.cpp:2344:52: note: to match this '['
>>> self->parameters[0] = &::PY_TYPE([D);
>>>
>>>
>>>
>>> On 14 Jan 2014, at 19:02 , Andi Vajda <va...@apache.org> wrote:
>>>
>>>
>>> Hi Petrus,
>>>
>>> On Jan 14, 2014, at 4:24, Petrus Hyvönen <pe...@gmail.com> wrote:
>>>
>>> Dear Andi,
>>>
>>> Many many thanks for looking into this!
>>>
>>> I am on travel for a week and do not have the computer with the special
>>> case with me to test. I did now however run it on the library that I am
>>> wrapping, and there get some errors in the creation of the wrapped module
>>> (orekit):
>>>
>>> build/_orekit/__wrap__.cpp:86504:89: error: no member named
>>> 'HarmonicOscillator$Parametric$$Type' in namespace
>>>
>>>
>>> I believe I fixed this bug in rev 1557613, header files for classes for
>>> inherited fixed parameters were not included as required.
>>>
>>> Andi..
>>>
>>> 'org::apache::commons::math3::analysis::function'
>>> ...=
>>> &::org::apache::commons::math3::analysis::function::PY_TYPE(HarmonicOs...
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
>>> /Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23:
>>> note:
>>> expanded from macro 'PY_TYPE'
>>> #define PY_TYPE(name) name##$$Type
>>> ^
>>> <scratch space>:63:1: note: expanded from here
>>> HarmonicOscillator$Parametric$$Type
>>> ^
>>> build/_orekit/__wrap__.cpp:217752:55: error: no member named
>>> 'OrekitMessages$$Type' in namespace 'org::orekit::errors'
>>> self->parameters[0] = &::org::orekit::errors::PY_TYPE(OrekitMessages);
>>> ~~~~~~~~~~~~~~~~~~~~~~~^
>>> /Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23:
>>> note:
>>> expanded from macro 'PY_TYPE'
>>> #define PY_TYPE(name) name##$$Type
>>> ^
>>> <scratch space>:9:1: note: expanded from here
>>> OrekitMessages$$Type
>>> ^
>>> 2 errors generated.
>>> error: command 'gcc' failed with exit status 1
>>>
>>>
>>>
>>> The OrekitMessages is defined as a "public enum OrekitMessages implements
>>> Localizable { ..."
>>> and the "public class HarmonicOscillator implements
>>> UnivariateDifferentiable, DifferentiableUnivariateFunction".
>>>
>>> Maybe this says you something, I will try to test more and run my test
>>> case
>>> in .
>>>
>>> Best Regards and again, many thanks again!
>>> /petrus
>>>
>>>
>>>
>>>
>>>
>>> On 11 Jan 2014, at 14:23 , Andi Vajda <va...@apache.org> wrote:
>>>
>>>
>>> Hi Petrus,
>>>
>>> On Mon, 30 Dec 2013, Petrus Hyvönen wrote:
>>>
>>> Andi, great to hear that you could reproduce it. I'm very thankful if you
>>> could have a look at it, I've been struggling to understand how the
>>> machinery behind this works, but far from it still..
>>>
>>>
>>> I think I fixed the problem and added an improvement to generics support
>>> along the way. Please check out rev 1557423 from jcc's trunk, rebuild your
>>> module with it and let me know how it's working for you.
>>>
>>> The bug had to do with SimpleClass2's wrapper class missing its parameters
>>> slot which it should get from its superclass, SimpleClass. When calling a
>>> method on SimpleClass from SimpleClass2, the missing parameters in the
>>> wrapper's struct would cause memory to get trashed.
>>>
>>> In addition to fixing the bug, I also improved support for fixed class
>>> parameters. Now, if you change SimpleClass's return_null() method to
>>> return
>>> new Integer(12) instead, when calling it on SimpleClass2, 12 is returned
>>> instead of <Object: 12>.
>>>
>>> Andi..
>>>
>>> public class SimpleClass<T> { public SimpleClass() {
>>> System.out.println("Created SimpleClass"); }
>>> public T return_null() {
>>> return (T) new Integer(12);
>>> }
>>>
>>> }
>>>
>>>
>>>
>>> Best Regards
>>> /Petrus
>>>
>>>
>>>
>>> On Mon, Dec 30, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>>>
>>>
>>> On Sun, 29 Dec 2013, Petrus Hyvönen wrote:
>>>
>>> I have distilled the library that I have some trouble with and I think I
>>>
>>> have an example that is failing due to same problem I think. I am not good
>>> in java, but have tried to follow the logic from the library I'm wrapping.
>>> The function of the example does not make sense in itself.
>>>
>>> public class SimpleClass<T> {
>>> public SimpleClass() {
>>> System.out.println("Created SimpleClass");
>>> }
>>> public T return_null() {
>>> return null;
>>> }
>>>
>>> }
>>>
>>>
>>>
>>> public class SimpleClass2 extends SimpleClass<Integer>{
>>>
>>> public SimpleClass2(){}
>>> public void testInJava(){
>>> System.out.println(this.return_null());
>>> }
>>> }
>>>
>>>
>>> It seems to me that there is some problem with methods inherited that
>>> returns a generic type, failing in wrapType when this is to be wrapped.
>>>
>>> The python script that fails:
>>>
>>> a= SimpleClass()
>>> print a.return_null()
>>>
>>> b = SimpleClass2()
>>> b.testInJava()
>>>
>>> print b.return_null() #Fails in wrapType
>>>
>>> I don't know if the return null is a bad thing to do in java, but the
>>> error
>>> seems very similar to what I experience in the larger library. I have a
>>> skeleton of that this is slightly larger, but not returning null, but
>>> trying to keep the lenght of example low :)
>>>
>>> Any comments highly appriciated :)
>>>
>>>
>>> I've been able to reproduce the problem.
>>> Thank you for providing an isolated test case !
>>>
>>> Andi..
>>>
>>>
>>>
>>> best Regards
>>> /Petrus
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Dec 27, 2013 at 6:25 PM, Andi Vajda <va...@apache.org> wrote:
>>>
>>>
>>> On Dec 27, 2013, at 17:36, Petrus Hyvönen <pe...@gmail.com>
>>> wrote:
>>>
>>>
>>> Dear Andi,
>>>
>>> I am working on debugging the failure and try to understand a bit how
>>> JCC
>>> works internally. I haven't gone very far but in case you have some
>>> pointers from these early debugging sessions I would be very thankful. I
>>> know it's complex, and I should try to make some smaller test cases, but
>>>
>>> I
>>>
>>> don't really have a grasp yet where the problem might be.
>>>
>>> Writing this might help me also to get some structure in my thinking :)
>>>
>>>
>>>
>>> The main crash seems to be in the last line, wrapType(), of
>>> __wrap__.cpp:
>>>
>>> static PyObject
>>>
>>> *t_AbstractReconfigurableDetector_withHandler(t_
>>>
>>> AbstractReconfigurableDetector
>>>
>>> *self, PyObject *arg)
>>> {
>>> ::org::orekit::propagation::events::handlers::EventHandler
>>> a0((jobject) NULL);
>>> PyTypeObject **p0;
>>> ::org::orekit::propagation::events::EventDetector
>>> result((jobject) NULL);
>>>
>>> if (!parseArg(arg, "K",
>>>
>>> ::org::orekit::propagation::events::handlers::
>>>
>>> EventHandler::initializeClass,
>>>
>>> &a0, &p0,
>>>
>>> ::org::orekit::propagation::events::handlers::t_
>>>
>>> EventHandler::parameters_))
>>>
>>> {
>>> OBJ_CALL(result = self->object.withHandler(a0));
>>> return self->parameters[0] != NULL ?
>>> wrapType(self->parameters[0], result.this$) :
>>> ::org::orekit::propagation::events::t_EventDetector::wrap_
>>> Object(result);
>>> }
>>>
>>> The parameters[0] does not seem to be null, but neither is it a valid
>>> object, in my debugger it says 0xbaadf00d {ob_refcnt=??? ob_type=???
>>> ob_size=??? ...} _typeobject *, wrapType is called and when trying
>>> to
>>> access the wrapfn it crashes.
>>>
>>> The main python lines are:
>>> tmp1 = ElevationDetector(sta1Frame) #
>>>
>>> ElevationDetector
>>>
>>> is a java public class ElevationDetector extends
>>> AbstractReconfigurableDetector<ElevationDetector>
>>> hand = ContinueOnEvent().of_(ElevationDetector) # a
>>> java ContinueOnEvent<ElevationDetector> object
>>> elDetector = tmp1.withHandler(hand) #Crash. withHandler is a method
>>> that is inherited from AbstractReconfigurableDetector to
>>>
>>> ElevationDetector
>>>
>>>
>>> This crashes when interactively entered on the python prompt (or in
>>> other
>>> interactive consoles), but seems to work if executed directly without
>>> interactivity. This difference makes me think that it might be something
>>> with garbage collection, but don't know.
>>>
>>> Any comments appriciated, I know this is likely very difficult to
>>> comment
>>> on as it's not very encapsulated.
>>>
>>>
>>> Right, so unless you can isolate this into something I can reproduce, I'm
>>> afraid there isn't much I can comment.
>>> It is quite likely that by the time you have that reproducible test case
>>> ready, you also have the solution to the problem. Or I might be able to
>>> help then...
>>>
>>> Andi..
>>>
>>>
>>> Regards
>>> /Petrus
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sun, Dec 15, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>>>
>>>
>>> On Dec 15, 2013, at 5:43, Petrus Hyvönen <pe...@gmail.com>
>>>
>>> wrote:
>>>
>>> Hi Andi,
>>>
>>> I see your point and have now kept in the pure python domain.
>>>
>>> If I run my script from the shell by "python script.py" it does not
>>>
>>> crash. However if I execute it line-by-line in python it crashes (or in
>>> other tools such as ipython notebook).
>>>
>>> All classes used are non-wrapped java classes, but I get the same
>>>
>>> effect
>>>
>>>
>>> with classes made for python subclassing.
>>>
>>>
>>> I am getting this on both MacOSX 64-bit python and Windows 7 32-bit
>>>
>>> python.
>>>
>>>
>>>
>>> elDetector =
>>>
>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>
>>>
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> #
>>> # SIGSEGV (0xb) at pc=0x000000010005da1a, pid=3318, tid=1287
>>> #
>>> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
>>>
>>> 1.7.0_45-b18)
>>>
>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
>>>
>>> bsd-amd64 compressed oops)
>>>
>>> # Problematic frame:
>>> # C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>> #
>>>
>>>
>>> from the stack it seems like there is somthing happening in "wrapType"
>>> Stack: [0x00007fff5fb80000,0x00007fff5fc00000],
>>> sp=0x00007fff5fbff470,
>>>
>>> free space=509k
>>>
>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>>
>>> C=native code)
>>>
>>> C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>> C [_orekit.so+0xa80878] wrapType(_typeobject*, _jobject*
>>> const&)+0x58
>>> C [_orekit.so+0x554400]
>>>
>>>
>>> org::orekit::propagation::events::t_AbstractReconfigurableDetector
>>>
>>> _withHandler(org::orekit::propagation::events::t_
>>> AbstractReconfigurableDetector*,
>>>
>>> _object*)+0x1c0
>>>
>>>
>>>
>>> First, is the generic class assignment correct as if to write "new
>>>
>>> ContinueOnEvent<ElevationDetector>()" in java? And is it ok to use
>>>
>>> regular
>>>
>>>
>>> java objects/types?
>>>
>>>
>>>
>>> Any other comments to move forward highly appriciated.. Is it somehow
>>>
>>> possible to get more log what is going wrong?
>>>
>>> You could compile the whole thing for debugging, by adding --debug
>>> after
>>> 'build' in the jcc invocation and run it with gdb.
>>>
>>> If you can isolate a reproducible crash into a small test case, I can
>>>
>>> also
>>>
>>>
>>> take a look at it.
>>>
>>>
>>> Andi..
>>>
>>>
>>> WIth best regards
>>> /Petrus
>>>
>>>
>>>
>>> On 15 Dec 2013, at 2:40 , Andi Vajda <va...@apache.org> wrote:
>>>
>>>
>>> On Dec 14, 2013, at 19:14, Petrus Hyvönen <petrus.hyvonen@gmail.com
>>> wrote:
>>>
>>>
>>>
>>> Hi,
>>>
>>> I'm having a problem with I think might be related to generic types,
>>>
>>> but not sure at all.
>>>
>>>
>>>
>>> I'm wrapping a orbit calculation library, which has been working
>>> well
>>>
>>> but in latest version is using generic types and I'm getting some
>>>
>>> problems.
>>>
>>>
>>> The script works when executed in plain python, but fails in ipython
>>>
>>> notebook on this last line when executed as a couple of cells.
>>>
>>>
>>> What is an 'ipython notebook' ?
>>>
>>> Andi.,
>>>
>>>
>>> The section with problem in my script is:
>>> elDetector =
>>>
>>> ElevationDetector(sta1Frame).withConstantElevation(math.
>>>
>>> radians(5.0))
>>>
>>> elDetector =
>>>
>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>
>>>
>>>
>>> In Java it would typically look something like:
>>>
>>> ElevationDetector detector = new ElevationDetector(topo)
>>> .withConstantElevation(x)
>>> .withHandler(new
>>>
>>> ContinueOnEvent<ElevationDetector>());
>>>
>>>
>>>
>>> It produces correct results in plain python, but crashes the kernel
>>>
>>> in
>>>
>>>
>>> ipython if executed as cells, and in exection from spyder I get an error
>>>
>>> message:
>>>
>>>
>>> " elDetector =
>>>
>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>
>>>
>>> AttributeError: 'str' object has no attribute 'wrapfn_' "
>>>
>>>
>>> As I have been using this setup stabely with lots of other functions
>>>
>>> it feels like there is something with the generic type line, but I
>>>
>>> don't
>>> really know how to get any further? I'm confused by that the pauses in
>>>
>>> the
>>>
>>>
>>> execution could seem to affect the result.
>>>
>>>
>>>
>>> Any comments highly appriciated...
>>>
>>> Best Regards
>>> /Petrus
>>>
>>>
>>>
>>> --
>>> _____________________________________________
>>> Petrus Hyvönen, Uppsala, Sweden
>>> Mobile Phone/SMS:+46 73 803 19 00
>>>
>>>
>>>
>>> --
>>> _____________________________________________
>>> Petrus Hyvönen, Uppsala, Sweden
>>> Mobile Phone/SMS:+46 73 803 19 00
>>>
>>>
>>>
>>> --
>>> _____________________________________________
>>> Petrus Hyvönen, Uppsala, Sweden
>>> Mobile Phone/SMS:+46 73 803 19 00
>
Re: Problem using generic types?
Posted by Andi Vajda <va...@apache.org>.
On Sun, 2 Feb 2014, Andi Vajda wrote:
>
> On Sun, 2 Feb 2014, Petrus Hyvönen wrote:
>
>> Yes, the confusing thing is that it works well under windows. I compared
>> the code in __wrap__ and it looks different in the windows version:
>>
>> static int t_PointVectorValuePair_init_(t_PointVectorValuePair *self,
>> PyObject *args, PyObject *kwds)
>> {
>> switch (PyTuple_GET_SIZE(args)) {
>> case 2:
>> {
>> JArray< jdouble > a0((jobject) NULL);
>> JArray< jdouble > a1((jobject) NULL);
>> PointVectorValuePair object((jobject) NULL);
>>
>> if (!parseArgs(args, "[D[D", &a0, &a1))
>> {
>> INT_CALL(object = PointVectorValuePair(a0, a1));
>> self->object = object;
>> break;
>> }
>> }
>>
>>
>> So no Parameters[] stuff in windows version.. On mac I'm using java v
>> 1.7.0_45 and 1.6.0_35 under windows. could that make a difference?
>
> That could also make a difference but there is a bug nonetheless.
And I've now reproduced it by adding s SimpleClass3 class to the example you
had sent in last time that looks like this:
public class SimpleClass3 extends SimpleClass<double[]>{
public SimpleClass3(){}
public void testInJava(){
System.out.println(this.return_null());
}
}
Andi..
>
> Andi..
>
>>
>> I'm using a mvn downloaded version of the apache.math jar, but source is:
>>
>> public class PointVectorValuePair extends Pair<double[], double[]>
>> implements Serializable {
>> /** Serializable UID. */
>> private static final long serialVersionUID = 20120513L;
>>
>> /**
>> ...
>> */
>> public PointVectorValuePair(final double[] point,
>> final double[] value) {
>> this(point, value, true);
>> }
>>
>> /**
>> ...
>> */
>> public PointVectorValuePair(final double[] point,
>> final double[] value,
>> final boolean copyArray) {
>> super(copyArray ?
>> ((point == null) ? null :
>> point.clone()) :
>> point,
>> copyArray ?
>> ((value == null) ? null :
>> value.clone()) :
>> value);
>> }
>>
>> ...
>>
>> full code at
>> http://commons-math/jacoco/org.apache.commons.math3.optimization/PointVectorValuePair.java.html
>>
>>
>>
>> Regards
>> /petrus
>>
>>
>> On 02 Feb 2014, at 22:54 , Andi Vajda <va...@apache.org> wrote:
>>
>>
>> On Feb 2, 2014, at 13:41, Petrus Hyvönen <pe...@gmail.com> wrote:
>>
>> Hi,
>>
>> It's part of a class "PointVectorValuePair" and "PointValuePair" in the
>> apache math commons (
>> http://commons.apache.org/proper/commons-math/javadocs/api-3.2/org/apache/commons/math3/optimization/PointVectorValuePair.html
>> )
>>
>> I have tried to reserve a bunch of things like 'Point', 'Value', 'Pair'
>> without any difference. If I go through the __wrap__ file, it looks like
>> this [D object to wrap is a very odd one, the other PY_TYPE wrapping seems
>> to have 'proper' names without special characters. It's the functions
>> PointValuePair and PointVectorValuePair that seems to have this strage
>> class wrapping. I cannot find a class named D. From the API doc's I would
>> guess it's trying to set a double [] type.
>>
>> extract from __wrap__:
>>
>> under namespace org {
>> namespace apache {
>> namespace commons {
>> namespace math3 {
>> namespace optimization {
>>
>> ...
>>
>> static int t_PointVectorValuePair_init_(t_PointVectorValuePair
>> *self, PyObject *args, PyObject *kwds)
>> {
>> switch (PyTuple_GET_SIZE(args)) {
>> case 2:
>> {
>> JArray< jdouble > a0((jobject) NULL);
>> JArray< jdouble > a1((jobject) NULL);
>> PointVectorValuePair object((jobject) NULL);
>>
>> if (!parseArgs(args, "[D[D", &a0, &a1))
>>
>>
>> It could just be that you found a bug in jcc's handling of generic
>> parameters that are arrays. I suspect you have some double[] (or worse:
>> double[][]) somewhere in the java source.
>> But then this should fail the same way on Windows.
>> Can you please post the original java source for that class here ?
>>
>> Andi..
>>
>> {
>> INT_CALL(object = PointVectorValuePair(a0, a1));
>> self->object = object;
>> self->parameters[0] = &::PY_TYPE([D);
>> self->parameters[1] = &::PY_TYPE([D);
>> break;
>> }
>>
>> Regards
>> /petrus
>>
>>
>>
>> = &::PY_TYPE([D);
>> ^
>> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
>> note:
>> expanded from macro 'PY_TYPE'
>> #define PY_TYPE(name) name##$$Type
>> ^
>> build/_orekit/__wrap__.cpp:58329:44: error: use of undeclared identifier
>> 'D$$Type'
>> self->parameters[0] = &::PY_TYPE([D);
>> ^
>> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
>> note:
>> expanded from macro 'PY_TYPE'
>> #define PY_TYPE(name) name##$$Type
>> ^
>> <scratch space>:109:1: note: expanded from here
>> D$$Type
>> ^
>> build/_orekit/__wrap__.cpp:58329:55: error: expected ']'
>> self->parameters[0] = &::PY_TYPE([D);
>> ^
>> build/_orekit/__wrap__.cpp:58329:52: note: to match this '['
>> self->parameters[0] = &::PY_TYPE([D);
>>
>>
>> On 02 Feb 2014, at 19:48 , Andi Vajda <va...@apache.org> wrote:
>>
>>
>> On Feb 2, 2014, at 10:08, Petrus Hyvönen <pe...@gmail.com> wrote:
>>
>> Hi Andi and Others,
>>
>> The latest trunk jcc works and builds very fine on my windows machine, and
>> happy about the extendend support of generics. But I am experiencing the
>> problem below when building on my mac, using same wrap parameters as on the
>> windows platform. To me it seems like some compiler problem related to
>> macros, but don't know.
>>
>> Does anyone have experience of these failures?
>>
>> Regards
>> /Petrus
>>
>>
>> error: expected unqualified-id
>> self->parameters[0] = &::PY_TYPE([D);
>> ^
>> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
>> note:
>> expanded from macro 'PY_TYPE'
>> #define PY_TYPE(name) name##$$Type
>> ^
>> build/_orekit/__wrap__.cpp:2344:44: error: use of undeclared identifier
>> 'D$$Type'
>> self->parameters[0] = &::PY_TYPE([D);
>>
>>
>> Take a look at the code around line 2344 in that __wrap__.cpp file and
>> figure out what java code this corresponds to. You might be using a
>> classname that's a C macro on some platforms - do you have a class named D
>> for example ?
>> If you're hitting such a name conflict, add that name to the --reserved
>> list passed to jcc.
>>
>> Andi..
>>
>> ^
>> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
>> note:
>> expanded from macro 'PY_TYPE'
>> #define PY_TYPE(name) name##$$Type
>> ^
>> <scratch space>:73:1: note: expanded from here
>> D$$Type
>> ^
>> build/_orekit/__wrap__.cpp:2344:55: error: expected ']'
>> self->parameters[0] = &::PY_TYPE([D);
>> ^
>> build/_orekit/__wrap__.cpp:2344:52: note: to match this '['
>> self->parameters[0] = &::PY_TYPE([D);
>>
>>
>>
>> On 14 Jan 2014, at 19:02 , Andi Vajda <va...@apache.org> wrote:
>>
>>
>> Hi Petrus,
>>
>> On Jan 14, 2014, at 4:24, Petrus Hyvönen <pe...@gmail.com> wrote:
>>
>> Dear Andi,
>>
>> Many many thanks for looking into this!
>>
>> I am on travel for a week and do not have the computer with the special
>> case with me to test. I did now however run it on the library that I am
>> wrapping, and there get some errors in the creation of the wrapped module
>> (orekit):
>>
>> build/_orekit/__wrap__.cpp:86504:89: error: no member named
>> 'HarmonicOscillator$Parametric$$Type' in namespace
>>
>>
>> I believe I fixed this bug in rev 1557613, header files for classes for
>> inherited fixed parameters were not included as required.
>>
>> Andi..
>>
>> 'org::apache::commons::math3::analysis::function'
>> ...=
>> &::org::apache::commons::math3::analysis::function::PY_TYPE(HarmonicOs...
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
>> /Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23:
>> note:
>> expanded from macro 'PY_TYPE'
>> #define PY_TYPE(name) name##$$Type
>> ^
>> <scratch space>:63:1: note: expanded from here
>> HarmonicOscillator$Parametric$$Type
>> ^
>> build/_orekit/__wrap__.cpp:217752:55: error: no member named
>> 'OrekitMessages$$Type' in namespace 'org::orekit::errors'
>> self->parameters[0] = &::org::orekit::errors::PY_TYPE(OrekitMessages);
>> ~~~~~~~~~~~~~~~~~~~~~~~^
>> /Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23:
>> note:
>> expanded from macro 'PY_TYPE'
>> #define PY_TYPE(name) name##$$Type
>> ^
>> <scratch space>:9:1: note: expanded from here
>> OrekitMessages$$Type
>> ^
>> 2 errors generated.
>> error: command 'gcc' failed with exit status 1
>>
>>
>>
>> The OrekitMessages is defined as a "public enum OrekitMessages implements
>> Localizable { ..."
>> and the "public class HarmonicOscillator implements
>> UnivariateDifferentiable, DifferentiableUnivariateFunction".
>>
>> Maybe this says you something, I will try to test more and run my test case
>> in .
>>
>> Best Regards and again, many thanks again!
>> /petrus
>>
>>
>>
>>
>>
>> On 11 Jan 2014, at 14:23 , Andi Vajda <va...@apache.org> wrote:
>>
>>
>> Hi Petrus,
>>
>> On Mon, 30 Dec 2013, Petrus Hyvönen wrote:
>>
>> Andi, great to hear that you could reproduce it. I'm very thankful if you
>> could have a look at it, I've been struggling to understand how the
>> machinery behind this works, but far from it still..
>>
>>
>> I think I fixed the problem and added an improvement to generics support
>> along the way. Please check out rev 1557423 from jcc's trunk, rebuild your
>> module with it and let me know how it's working for you.
>>
>> The bug had to do with SimpleClass2's wrapper class missing its parameters
>> slot which it should get from its superclass, SimpleClass. When calling a
>> method on SimpleClass from SimpleClass2, the missing parameters in the
>> wrapper's struct would cause memory to get trashed.
>>
>> In addition to fixing the bug, I also improved support for fixed class
>> parameters. Now, if you change SimpleClass's return_null() method to return
>> new Integer(12) instead, when calling it on SimpleClass2, 12 is returned
>> instead of <Object: 12>.
>>
>> Andi..
>>
>> public class SimpleClass<T> { public SimpleClass() {
>> System.out.println("Created SimpleClass"); }
>> public T return_null() {
>> return (T) new Integer(12);
>> }
>>
>> }
>>
>>
>>
>> Best Regards
>> /Petrus
>>
>>
>>
>> On Mon, Dec 30, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>>
>>
>> On Sun, 29 Dec 2013, Petrus Hyvönen wrote:
>>
>> I have distilled the library that I have some trouble with and I think I
>>
>> have an example that is failing due to same problem I think. I am not good
>> in java, but have tried to follow the logic from the library I'm wrapping.
>> The function of the example does not make sense in itself.
>>
>> public class SimpleClass<T> {
>> public SimpleClass() {
>> System.out.println("Created SimpleClass");
>> }
>> public T return_null() {
>> return null;
>> }
>>
>> }
>>
>>
>>
>> public class SimpleClass2 extends SimpleClass<Integer>{
>>
>> public SimpleClass2(){}
>> public void testInJava(){
>> System.out.println(this.return_null());
>> }
>> }
>>
>>
>> It seems to me that there is some problem with methods inherited that
>> returns a generic type, failing in wrapType when this is to be wrapped.
>>
>> The python script that fails:
>>
>> a= SimpleClass()
>> print a.return_null()
>>
>> b = SimpleClass2()
>> b.testInJava()
>>
>> print b.return_null() #Fails in wrapType
>>
>> I don't know if the return null is a bad thing to do in java, but the
>> error
>> seems very similar to what I experience in the larger library. I have a
>> skeleton of that this is slightly larger, but not returning null, but
>> trying to keep the lenght of example low :)
>>
>> Any comments highly appriciated :)
>>
>>
>> I've been able to reproduce the problem.
>> Thank you for providing an isolated test case !
>>
>> Andi..
>>
>>
>>
>> best Regards
>> /Petrus
>>
>>
>>
>>
>>
>>
>> On Fri, Dec 27, 2013 at 6:25 PM, Andi Vajda <va...@apache.org> wrote:
>>
>>
>> On Dec 27, 2013, at 17:36, Petrus Hyvönen <pe...@gmail.com>
>> wrote:
>>
>>
>> Dear Andi,
>>
>> I am working on debugging the failure and try to understand a bit how
>> JCC
>> works internally. I haven't gone very far but in case you have some
>> pointers from these early debugging sessions I would be very thankful. I
>> know it's complex, and I should try to make some smaller test cases, but
>>
>> I
>>
>> don't really have a grasp yet where the problem might be.
>>
>> Writing this might help me also to get some structure in my thinking :)
>>
>>
>>
>> The main crash seems to be in the last line, wrapType(), of
>> __wrap__.cpp:
>>
>> static PyObject
>>
>> *t_AbstractReconfigurableDetector_withHandler(t_
>>
>> AbstractReconfigurableDetector
>>
>> *self, PyObject *arg)
>> {
>> ::org::orekit::propagation::events::handlers::EventHandler
>> a0((jobject) NULL);
>> PyTypeObject **p0;
>> ::org::orekit::propagation::events::EventDetector
>> result((jobject) NULL);
>>
>> if (!parseArg(arg, "K",
>>
>> ::org::orekit::propagation::events::handlers::
>>
>> EventHandler::initializeClass,
>>
>> &a0, &p0,
>>
>> ::org::orekit::propagation::events::handlers::t_
>>
>> EventHandler::parameters_))
>>
>> {
>> OBJ_CALL(result = self->object.withHandler(a0));
>> return self->parameters[0] != NULL ?
>> wrapType(self->parameters[0], result.this$) :
>> ::org::orekit::propagation::events::t_EventDetector::wrap_
>> Object(result);
>> }
>>
>> The parameters[0] does not seem to be null, but neither is it a valid
>> object, in my debugger it says 0xbaadf00d {ob_refcnt=??? ob_type=???
>> ob_size=??? ...} _typeobject *, wrapType is called and when trying
>> to
>> access the wrapfn it crashes.
>>
>> The main python lines are:
>> tmp1 = ElevationDetector(sta1Frame) #
>>
>> ElevationDetector
>>
>> is a java public class ElevationDetector extends
>> AbstractReconfigurableDetector<ElevationDetector>
>> hand = ContinueOnEvent().of_(ElevationDetector) # a
>> java ContinueOnEvent<ElevationDetector> object
>> elDetector = tmp1.withHandler(hand) #Crash. withHandler is a method
>> that is inherited from AbstractReconfigurableDetector to
>>
>> ElevationDetector
>>
>>
>> This crashes when interactively entered on the python prompt (or in
>> other
>> interactive consoles), but seems to work if executed directly without
>> interactivity. This difference makes me think that it might be something
>> with garbage collection, but don't know.
>>
>> Any comments appriciated, I know this is likely very difficult to
>> comment
>> on as it's not very encapsulated.
>>
>>
>> Right, so unless you can isolate this into something I can reproduce, I'm
>> afraid there isn't much I can comment.
>> It is quite likely that by the time you have that reproducible test case
>> ready, you also have the solution to the problem. Or I might be able to
>> help then...
>>
>> Andi..
>>
>>
>> Regards
>> /Petrus
>>
>>
>>
>>
>>
>>
>> On Sun, Dec 15, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>>
>>
>> On Dec 15, 2013, at 5:43, Petrus Hyvönen <pe...@gmail.com>
>>
>> wrote:
>>
>> Hi Andi,
>>
>> I see your point and have now kept in the pure python domain.
>>
>> If I run my script from the shell by "python script.py" it does not
>>
>> crash. However if I execute it line-by-line in python it crashes (or in
>> other tools such as ipython notebook).
>>
>> All classes used are non-wrapped java classes, but I get the same
>>
>> effect
>>
>>
>> with classes made for python subclassing.
>>
>>
>> I am getting this on both MacOSX 64-bit python and Windows 7 32-bit
>>
>> python.
>>
>>
>>
>> elDetector =
>>
>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>
>>
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # SIGSEGV (0xb) at pc=0x000000010005da1a, pid=3318, tid=1287
>> #
>> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
>>
>> 1.7.0_45-b18)
>>
>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
>>
>> bsd-amd64 compressed oops)
>>
>> # Problematic frame:
>> # C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>> #
>>
>>
>> from the stack it seems like there is somthing happening in "wrapType"
>> Stack: [0x00007fff5fb80000,0x00007fff5fc00000],
>> sp=0x00007fff5fbff470,
>>
>> free space=509k
>>
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>
>> C=native code)
>>
>> C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>> C [_orekit.so+0xa80878] wrapType(_typeobject*, _jobject*
>> const&)+0x58
>> C [_orekit.so+0x554400]
>>
>>
>> org::orekit::propagation::events::t_AbstractReconfigurableDetector
>>
>> _withHandler(org::orekit::propagation::events::t_
>> AbstractReconfigurableDetector*,
>>
>> _object*)+0x1c0
>>
>>
>>
>> First, is the generic class assignment correct as if to write "new
>>
>> ContinueOnEvent<ElevationDetector>()" in java? And is it ok to use
>>
>> regular
>>
>>
>> java objects/types?
>>
>>
>>
>> Any other comments to move forward highly appriciated.. Is it somehow
>>
>> possible to get more log what is going wrong?
>>
>> You could compile the whole thing for debugging, by adding --debug
>> after
>> 'build' in the jcc invocation and run it with gdb.
>>
>> If you can isolate a reproducible crash into a small test case, I can
>>
>> also
>>
>>
>> take a look at it.
>>
>>
>> Andi..
>>
>>
>> WIth best regards
>> /Petrus
>>
>>
>>
>> On 15 Dec 2013, at 2:40 , Andi Vajda <va...@apache.org> wrote:
>>
>>
>> On Dec 14, 2013, at 19:14, Petrus Hyvönen <petrus.hyvonen@gmail.com
>> wrote:
>>
>>
>>
>> Hi,
>>
>> I'm having a problem with I think might be related to generic types,
>>
>> but not sure at all.
>>
>>
>>
>> I'm wrapping a orbit calculation library, which has been working
>> well
>>
>> but in latest version is using generic types and I'm getting some
>>
>> problems.
>>
>>
>> The script works when executed in plain python, but fails in ipython
>>
>> notebook on this last line when executed as a couple of cells.
>>
>>
>> What is an 'ipython notebook' ?
>>
>> Andi.,
>>
>>
>> The section with problem in my script is:
>> elDetector =
>>
>> ElevationDetector(sta1Frame).withConstantElevation(math.
>>
>> radians(5.0))
>>
>> elDetector =
>>
>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>
>>
>>
>> In Java it would typically look something like:
>>
>> ElevationDetector detector = new ElevationDetector(topo)
>> .withConstantElevation(x)
>> .withHandler(new
>>
>> ContinueOnEvent<ElevationDetector>());
>>
>>
>>
>> It produces correct results in plain python, but crashes the kernel
>>
>> in
>>
>>
>> ipython if executed as cells, and in exection from spyder I get an error
>>
>> message:
>>
>>
>> " elDetector =
>>
>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>
>>
>> AttributeError: 'str' object has no attribute 'wrapfn_' "
>>
>>
>> As I have been using this setup stabely with lots of other functions
>>
>> it feels like there is something with the generic type line, but I
>>
>> don't
>> really know how to get any further? I'm confused by that the pauses in
>>
>> the
>>
>>
>> execution could seem to affect the result.
>>
>>
>>
>> Any comments highly appriciated...
>>
>> Best Regards
>> /Petrus
>>
>>
>>
>> --
>> _____________________________________________
>> Petrus Hyvönen, Uppsala, Sweden
>> Mobile Phone/SMS:+46 73 803 19 00
>>
>>
>>
>> --
>> _____________________________________________
>> Petrus Hyvönen, Uppsala, Sweden
>> Mobile Phone/SMS:+46 73 803 19 00
>>
>>
>>
>> --
>> _____________________________________________
>> Petrus Hyvönen, Uppsala, Sweden
>> Mobile Phone/SMS:+46 73 803 19 00
>
Re: Problem using generic types?
Posted by Andi Vajda <va...@apache.org>.
On Sun, 2 Feb 2014, Petrus Hyvönen wrote:
> Yes, the confusing thing is that it works well under windows. I compared
> the code in __wrap__ and it looks different in the windows version:
>
> static int t_PointVectorValuePair_init_(t_PointVectorValuePair *self,
> PyObject *args, PyObject *kwds)
> {
> switch (PyTuple_GET_SIZE(args)) {
> case 2:
> {
> JArray< jdouble > a0((jobject) NULL);
> JArray< jdouble > a1((jobject) NULL);
> PointVectorValuePair object((jobject) NULL);
>
> if (!parseArgs(args, "[D[D", &a0, &a1))
> {
> INT_CALL(object = PointVectorValuePair(a0, a1));
> self->object = object;
> break;
> }
> }
>
>
> So no Parameters[] stuff in windows version.. On mac I'm using java v
> 1.7.0_45 and 1.6.0_35 under windows. could that make a difference?
That could also make a difference but there is a bug nonetheless.
Andi..
>
> I'm using a mvn downloaded version of the apache.math jar, but source is:
>
> public class PointVectorValuePair extends Pair<double[], double[]>
> implements Serializable {
> /** Serializable UID. */
> private static final long serialVersionUID = 20120513L;
>
> /**
> ...
> */
> public PointVectorValuePair(final double[] point,
> final double[] value) {
> this(point, value, true);
> }
>
> /**
> ...
> */
> public PointVectorValuePair(final double[] point,
> final double[] value,
> final boolean copyArray) {
> super(copyArray ?
> ((point == null) ? null :
> point.clone()) :
> point,
> copyArray ?
> ((value == null) ? null :
> value.clone()) :
> value);
> }
>
> ...
>
> full code at
> http://commons-math/jacoco/org.apache.commons.math3.optimization/PointVectorValuePair.java.html
>
>
>
> Regards
> /petrus
>
>
> On 02 Feb 2014, at 22:54 , Andi Vajda <va...@apache.org> wrote:
>
>
> On Feb 2, 2014, at 13:41, Petrus Hyvönen <pe...@gmail.com> wrote:
>
> Hi,
>
> It's part of a class "PointVectorValuePair" and "PointValuePair" in the
> apache math commons (
> http://commons.apache.org/proper/commons-math/javadocs/api-3.2/org/apache/commons/math3/optimization/PointVectorValuePair.html
> )
>
> I have tried to reserve a bunch of things like 'Point', 'Value', 'Pair'
> without any difference. If I go through the __wrap__ file, it looks like
> this [D object to wrap is a very odd one, the other PY_TYPE wrapping seems
> to have 'proper' names without special characters. It's the functions
> PointValuePair and PointVectorValuePair that seems to have this strage
> class wrapping. I cannot find a class named D. From the API doc's I would
> guess it's trying to set a double [] type.
>
> extract from __wrap__:
>
> under namespace org {
> namespace apache {
> namespace commons {
> namespace math3 {
> namespace optimization {
>
> ...
>
> static int t_PointVectorValuePair_init_(t_PointVectorValuePair
> *self, PyObject *args, PyObject *kwds)
> {
> switch (PyTuple_GET_SIZE(args)) {
> case 2:
> {
> JArray< jdouble > a0((jobject) NULL);
> JArray< jdouble > a1((jobject) NULL);
> PointVectorValuePair object((jobject) NULL);
>
> if (!parseArgs(args, "[D[D", &a0, &a1))
>
>
> It could just be that you found a bug in jcc's handling of generic
> parameters that are arrays. I suspect you have some double[] (or worse:
> double[][]) somewhere in the java source.
> But then this should fail the same way on Windows.
> Can you please post the original java source for that class here ?
>
> Andi..
>
> {
> INT_CALL(object = PointVectorValuePair(a0, a1));
> self->object = object;
> self->parameters[0] = &::PY_TYPE([D);
> self->parameters[1] = &::PY_TYPE([D);
> break;
> }
>
> Regards
> /petrus
>
>
>
> = &::PY_TYPE([D);
> ^
> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
> note:
> expanded from macro 'PY_TYPE'
> #define PY_TYPE(name) name##$$Type
> ^
> build/_orekit/__wrap__.cpp:58329:44: error: use of undeclared identifier
> 'D$$Type'
> self->parameters[0] = &::PY_TYPE([D);
> ^
> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
> note:
> expanded from macro 'PY_TYPE'
> #define PY_TYPE(name) name##$$Type
> ^
> <scratch space>:109:1: note: expanded from here
> D$$Type
> ^
> build/_orekit/__wrap__.cpp:58329:55: error: expected ']'
> self->parameters[0] = &::PY_TYPE([D);
> ^
> build/_orekit/__wrap__.cpp:58329:52: note: to match this '['
> self->parameters[0] = &::PY_TYPE([D);
>
>
> On 02 Feb 2014, at 19:48 , Andi Vajda <va...@apache.org> wrote:
>
>
> On Feb 2, 2014, at 10:08, Petrus Hyvönen <pe...@gmail.com> wrote:
>
> Hi Andi and Others,
>
> The latest trunk jcc works and builds very fine on my windows machine, and
> happy about the extendend support of generics. But I am experiencing the
> problem below when building on my mac, using same wrap parameters as on the
> windows platform. To me it seems like some compiler problem related to
> macros, but don't know.
>
> Does anyone have experience of these failures?
>
> Regards
> /Petrus
>
>
> error: expected unqualified-id
> self->parameters[0] = &::PY_TYPE([D);
> ^
> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
> note:
> expanded from macro 'PY_TYPE'
> #define PY_TYPE(name) name##$$Type
> ^
> build/_orekit/__wrap__.cpp:2344:44: error: use of undeclared identifier
> 'D$$Type'
> self->parameters[0] = &::PY_TYPE([D);
>
>
> Take a look at the code around line 2344 in that __wrap__.cpp file and
> figure out what java code this corresponds to. You might be using a
> classname that's a C macro on some platforms - do you have a class named D
> for example ?
> If you're hitting such a name conflict, add that name to the --reserved
> list passed to jcc.
>
> Andi..
>
> ^
> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
> note:
> expanded from macro 'PY_TYPE'
> #define PY_TYPE(name) name##$$Type
> ^
> <scratch space>:73:1: note: expanded from here
> D$$Type
> ^
> build/_orekit/__wrap__.cpp:2344:55: error: expected ']'
> self->parameters[0] = &::PY_TYPE([D);
> ^
> build/_orekit/__wrap__.cpp:2344:52: note: to match this '['
> self->parameters[0] = &::PY_TYPE([D);
>
>
>
> On 14 Jan 2014, at 19:02 , Andi Vajda <va...@apache.org> wrote:
>
>
> Hi Petrus,
>
> On Jan 14, 2014, at 4:24, Petrus Hyvönen <pe...@gmail.com> wrote:
>
> Dear Andi,
>
> Many many thanks for looking into this!
>
> I am on travel for a week and do not have the computer with the special
> case with me to test. I did now however run it on the library that I am
> wrapping, and there get some errors in the creation of the wrapped module
> (orekit):
>
> build/_orekit/__wrap__.cpp:86504:89: error: no member named
> 'HarmonicOscillator$Parametric$$Type' in namespace
>
>
> I believe I fixed this bug in rev 1557613, header files for classes for
> inherited fixed parameters were not included as required.
>
> Andi..
>
> 'org::apache::commons::math3::analysis::function'
> ...=
> &::org::apache::commons::math3::analysis::function::PY_TYPE(HarmonicOs...
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
> /Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23:
> note:
> expanded from macro 'PY_TYPE'
> #define PY_TYPE(name) name##$$Type
> ^
> <scratch space>:63:1: note: expanded from here
> HarmonicOscillator$Parametric$$Type
> ^
> build/_orekit/__wrap__.cpp:217752:55: error: no member named
> 'OrekitMessages$$Type' in namespace 'org::orekit::errors'
> self->parameters[0] = &::org::orekit::errors::PY_TYPE(OrekitMessages);
> ~~~~~~~~~~~~~~~~~~~~~~~^
> /Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23:
> note:
> expanded from macro 'PY_TYPE'
> #define PY_TYPE(name) name##$$Type
> ^
> <scratch space>:9:1: note: expanded from here
> OrekitMessages$$Type
> ^
> 2 errors generated.
> error: command 'gcc' failed with exit status 1
>
>
>
> The OrekitMessages is defined as a "public enum OrekitMessages implements
> Localizable { ..."
> and the "public class HarmonicOscillator implements
> UnivariateDifferentiable, DifferentiableUnivariateFunction".
>
> Maybe this says you something, I will try to test more and run my test case
> in .
>
> Best Regards and again, many thanks again!
> /petrus
>
>
>
>
>
> On 11 Jan 2014, at 14:23 , Andi Vajda <va...@apache.org> wrote:
>
>
> Hi Petrus,
>
> On Mon, 30 Dec 2013, Petrus Hyvönen wrote:
>
> Andi, great to hear that you could reproduce it. I'm very thankful if you
> could have a look at it, I've been struggling to understand how the
> machinery behind this works, but far from it still..
>
>
> I think I fixed the problem and added an improvement to generics support
> along the way. Please check out rev 1557423 from jcc's trunk, rebuild your
> module with it and let me know how it's working for you.
>
> The bug had to do with SimpleClass2's wrapper class missing its parameters
> slot which it should get from its superclass, SimpleClass. When calling a
> method on SimpleClass from SimpleClass2, the missing parameters in the
> wrapper's struct would cause memory to get trashed.
>
> In addition to fixing the bug, I also improved support for fixed class
> parameters. Now, if you change SimpleClass's return_null() method to return
> new Integer(12) instead, when calling it on SimpleClass2, 12 is returned
> instead of <Object: 12>.
>
> Andi..
>
> public class SimpleClass<T> { public SimpleClass() {
> System.out.println("Created SimpleClass"); }
> public T return_null() {
> return (T) new Integer(12);
> }
>
> }
>
>
>
> Best Regards
> /Petrus
>
>
>
> On Mon, Dec 30, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>
>
> On Sun, 29 Dec 2013, Petrus Hyvönen wrote:
>
> I have distilled the library that I have some trouble with and I think I
>
> have an example that is failing due to same problem I think. I am not good
> in java, but have tried to follow the logic from the library I'm wrapping.
> The function of the example does not make sense in itself.
>
> public class SimpleClass<T> {
> public SimpleClass() {
> System.out.println("Created SimpleClass");
> }
> public T return_null() {
> return null;
> }
>
> }
>
>
>
> public class SimpleClass2 extends SimpleClass<Integer>{
>
> public SimpleClass2(){}
> public void testInJava(){
> System.out.println(this.return_null());
> }
> }
>
>
> It seems to me that there is some problem with methods inherited that
> returns a generic type, failing in wrapType when this is to be wrapped.
>
> The python script that fails:
>
> a= SimpleClass()
> print a.return_null()
>
> b = SimpleClass2()
> b.testInJava()
>
> print b.return_null() #Fails in wrapType
>
> I don't know if the return null is a bad thing to do in java, but the
> error
> seems very similar to what I experience in the larger library. I have a
> skeleton of that this is slightly larger, but not returning null, but
> trying to keep the lenght of example low :)
>
> Any comments highly appriciated :)
>
>
> I've been able to reproduce the problem.
> Thank you for providing an isolated test case !
>
> Andi..
>
>
>
> best Regards
> /Petrus
>
>
>
>
>
>
> On Fri, Dec 27, 2013 at 6:25 PM, Andi Vajda <va...@apache.org> wrote:
>
>
> On Dec 27, 2013, at 17:36, Petrus Hyvönen <pe...@gmail.com>
> wrote:
>
>
> Dear Andi,
>
> I am working on debugging the failure and try to understand a bit how
> JCC
> works internally. I haven't gone very far but in case you have some
> pointers from these early debugging sessions I would be very thankful. I
> know it's complex, and I should try to make some smaller test cases, but
>
> I
>
> don't really have a grasp yet where the problem might be.
>
> Writing this might help me also to get some structure in my thinking :)
>
>
>
> The main crash seems to be in the last line, wrapType(), of
> __wrap__.cpp:
>
> static PyObject
>
> *t_AbstractReconfigurableDetector_withHandler(t_
>
> AbstractReconfigurableDetector
>
> *self, PyObject *arg)
> {
> ::org::orekit::propagation::events::handlers::EventHandler
> a0((jobject) NULL);
> PyTypeObject **p0;
> ::org::orekit::propagation::events::EventDetector
> result((jobject) NULL);
>
> if (!parseArg(arg, "K",
>
> ::org::orekit::propagation::events::handlers::
>
> EventHandler::initializeClass,
>
> &a0, &p0,
>
> ::org::orekit::propagation::events::handlers::t_
>
> EventHandler::parameters_))
>
> {
> OBJ_CALL(result = self->object.withHandler(a0));
> return self->parameters[0] != NULL ?
> wrapType(self->parameters[0], result.this$) :
> ::org::orekit::propagation::events::t_EventDetector::wrap_
> Object(result);
> }
>
> The parameters[0] does not seem to be null, but neither is it a valid
> object, in my debugger it says 0xbaadf00d {ob_refcnt=??? ob_type=???
> ob_size=??? ...} _typeobject *, wrapType is called and when trying
> to
> access the wrapfn it crashes.
>
> The main python lines are:
> tmp1 = ElevationDetector(sta1Frame) #
>
> ElevationDetector
>
> is a java public class ElevationDetector extends
> AbstractReconfigurableDetector<ElevationDetector>
> hand = ContinueOnEvent().of_(ElevationDetector) # a
> java ContinueOnEvent<ElevationDetector> object
> elDetector = tmp1.withHandler(hand) #Crash. withHandler is a method
> that is inherited from AbstractReconfigurableDetector to
>
> ElevationDetector
>
>
> This crashes when interactively entered on the python prompt (or in
> other
> interactive consoles), but seems to work if executed directly without
> interactivity. This difference makes me think that it might be something
> with garbage collection, but don't know.
>
> Any comments appriciated, I know this is likely very difficult to
> comment
> on as it's not very encapsulated.
>
>
> Right, so unless you can isolate this into something I can reproduce, I'm
> afraid there isn't much I can comment.
> It is quite likely that by the time you have that reproducible test case
> ready, you also have the solution to the problem. Or I might be able to
> help then...
>
> Andi..
>
>
> Regards
> /Petrus
>
>
>
>
>
>
> On Sun, Dec 15, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>
>
> On Dec 15, 2013, at 5:43, Petrus Hyvönen <pe...@gmail.com>
>
> wrote:
>
> Hi Andi,
>
> I see your point and have now kept in the pure python domain.
>
> If I run my script from the shell by "python script.py" it does not
>
> crash. However if I execute it line-by-line in python it crashes (or in
> other tools such as ipython notebook).
>
> All classes used are non-wrapped java classes, but I get the same
>
> effect
>
>
> with classes made for python subclassing.
>
>
> I am getting this on both MacOSX 64-bit python and Windows 7 32-bit
>
> python.
>
>
>
> elDetector =
>
> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>
>
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x000000010005da1a, pid=3318, tid=1287
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
>
> 1.7.0_45-b18)
>
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
>
> bsd-amd64 compressed oops)
>
> # Problematic frame:
> # C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
> #
>
>
> from the stack it seems like there is somthing happening in "wrapType"
> Stack: [0x00007fff5fb80000,0x00007fff5fc00000],
> sp=0x00007fff5fbff470,
>
> free space=509k
>
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>
> C=native code)
>
> C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
> C [_orekit.so+0xa80878] wrapType(_typeobject*, _jobject*
> const&)+0x58
> C [_orekit.so+0x554400]
>
>
> org::orekit::propagation::events::t_AbstractReconfigurableDetector
>
> _withHandler(org::orekit::propagation::events::t_
> AbstractReconfigurableDetector*,
>
> _object*)+0x1c0
>
>
>
> First, is the generic class assignment correct as if to write "new
>
> ContinueOnEvent<ElevationDetector>()" in java? And is it ok to use
>
> regular
>
>
> java objects/types?
>
>
>
> Any other comments to move forward highly appriciated.. Is it somehow
>
> possible to get more log what is going wrong?
>
> You could compile the whole thing for debugging, by adding --debug
> after
> 'build' in the jcc invocation and run it with gdb.
>
> If you can isolate a reproducible crash into a small test case, I can
>
> also
>
>
> take a look at it.
>
>
> Andi..
>
>
> WIth best regards
> /Petrus
>
>
>
> On 15 Dec 2013, at 2:40 , Andi Vajda <va...@apache.org> wrote:
>
>
> On Dec 14, 2013, at 19:14, Petrus Hyvönen <petrus.hyvonen@gmail.com
> wrote:
>
>
>
> Hi,
>
> I'm having a problem with I think might be related to generic types,
>
> but not sure at all.
>
>
>
> I'm wrapping a orbit calculation library, which has been working
> well
>
> but in latest version is using generic types and I'm getting some
>
> problems.
>
>
> The script works when executed in plain python, but fails in ipython
>
> notebook on this last line when executed as a couple of cells.
>
>
> What is an 'ipython notebook' ?
>
> Andi.,
>
>
> The section with problem in my script is:
> elDetector =
>
> ElevationDetector(sta1Frame).withConstantElevation(math.
>
> radians(5.0))
>
> elDetector =
>
> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>
>
>
> In Java it would typically look something like:
>
> ElevationDetector detector = new ElevationDetector(topo)
> .withConstantElevation(x)
> .withHandler(new
>
> ContinueOnEvent<ElevationDetector>());
>
>
>
> It produces correct results in plain python, but crashes the kernel
>
> in
>
>
> ipython if executed as cells, and in exection from spyder I get an error
>
> message:
>
>
> " elDetector =
>
> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>
>
> AttributeError: 'str' object has no attribute 'wrapfn_' "
>
>
> As I have been using this setup stabely with lots of other functions
>
> it feels like there is something with the generic type line, but I
>
> don't
> really know how to get any further? I'm confused by that the pauses in
>
> the
>
>
> execution could seem to affect the result.
>
>
>
> Any comments highly appriciated...
>
> Best Regards
> /Petrus
>
>
>
> --
> _____________________________________________
> Petrus Hyvönen, Uppsala, Sweden
> Mobile Phone/SMS:+46 73 803 19 00
>
>
>
> --
> _____________________________________________
> Petrus Hyvönen, Uppsala, Sweden
> Mobile Phone/SMS:+46 73 803 19 00
>
>
>
> --
> _____________________________________________
> Petrus Hyvönen, Uppsala, Sweden
> Mobile Phone/SMS:+46 73 803 19 00
>
Re: Problem using generic types?
Posted by Andi Vajda <va...@apache.org>.
On Sun, 2 Feb 2014, Petrus Hyvönen wrote:
> Yes, the confusing thing is that it works well under windows. I compared
> the code in __wrap__ and it looks different in the windows version:
>
> static int t_PointVectorValuePair_init_(t_PointVectorValuePair *self,
> PyObject *args, PyObject *kwds)
> {
> switch (PyTuple_GET_SIZE(args)) {
> case 2:
> {
> JArray< jdouble > a0((jobject) NULL);
> JArray< jdouble > a1((jobject) NULL);
> PointVectorValuePair object((jobject) NULL);
>
> if (!parseArgs(args, "[D[D", &a0, &a1))
> {
> INT_CALL(object = PointVectorValuePair(a0, a1));
> self->object = object;
> break;
> }
> }
>
>
> So no Parameters[] stuff in windows version.. On mac I'm using java v
> 1.7.0_45 and 1.6.0_35 under windows. could that make a difference?
>
> I'm using a mvn downloaded version of the apache.math jar, but source is:
>
> public class PointVectorValuePair extends Pair<double[], double[]>
Ah yes, there it is: extends Pair<double[], double[]>
This has got to fail the same way on Windows unless you're using an older
JCC version. I think the fix I did recently for your use case doesn't handle
arrays correctly.
Andi..
> implements Serializable {
> /** Serializable UID. */
> private static final long serialVersionUID = 20120513L;
>
> /**
> ...
> */
> public PointVectorValuePair(final double[] point,
> final double[] value) {
> this(point, value, true);
> }
>
> /**
> ...
> */
> public PointVectorValuePair(final double[] point,
> final double[] value,
> final boolean copyArray) {
> super(copyArray ?
> ((point == null) ? null :
> point.clone()) :
> point,
> copyArray ?
> ((value == null) ? null :
> value.clone()) :
> value);
> }
>
> ...
>
> full code at
> http://commons-math/jacoco/org.apache.commons.math3.optimization/PointVectorValuePair.java.html
>
>
>
> Regards
> /petrus
>
>
> On 02 Feb 2014, at 22:54 , Andi Vajda <va...@apache.org> wrote:
>
>
> On Feb 2, 2014, at 13:41, Petrus Hyvönen <pe...@gmail.com> wrote:
>
> Hi,
>
> It's part of a class "PointVectorValuePair" and "PointValuePair" in the
> apache math commons (
> http://commons.apache.org/proper/commons-math/javadocs/api-3.2/org/apache/commons/math3/optimization/PointVectorValuePair.html
> )
>
> I have tried to reserve a bunch of things like 'Point', 'Value', 'Pair'
> without any difference. If I go through the __wrap__ file, it looks like
> this [D object to wrap is a very odd one, the other PY_TYPE wrapping seems
> to have 'proper' names without special characters. It's the functions
> PointValuePair and PointVectorValuePair that seems to have this strage
> class wrapping. I cannot find a class named D. From the API doc's I would
> guess it's trying to set a double [] type.
>
> extract from __wrap__:
>
> under namespace org {
> namespace apache {
> namespace commons {
> namespace math3 {
> namespace optimization {
>
> ...
>
> static int t_PointVectorValuePair_init_(t_PointVectorValuePair
> *self, PyObject *args, PyObject *kwds)
> {
> switch (PyTuple_GET_SIZE(args)) {
> case 2:
> {
> JArray< jdouble > a0((jobject) NULL);
> JArray< jdouble > a1((jobject) NULL);
> PointVectorValuePair object((jobject) NULL);
>
> if (!parseArgs(args, "[D[D", &a0, &a1))
>
>
> It could just be that you found a bug in jcc's handling of generic
> parameters that are arrays. I suspect you have some double[] (or worse:
> double[][]) somewhere in the java source.
> But then this should fail the same way on Windows.
> Can you please post the original java source for that class here ?
>
> Andi..
>
> {
> INT_CALL(object = PointVectorValuePair(a0, a1));
> self->object = object;
> self->parameters[0] = &::PY_TYPE([D);
> self->parameters[1] = &::PY_TYPE([D);
> break;
> }
>
> Regards
> /petrus
>
>
>
> = &::PY_TYPE([D);
> ^
> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
> note:
> expanded from macro 'PY_TYPE'
> #define PY_TYPE(name) name##$$Type
> ^
> build/_orekit/__wrap__.cpp:58329:44: error: use of undeclared identifier
> 'D$$Type'
> self->parameters[0] = &::PY_TYPE([D);
> ^
> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
> note:
> expanded from macro 'PY_TYPE'
> #define PY_TYPE(name) name##$$Type
> ^
> <scratch space>:109:1: note: expanded from here
> D$$Type
> ^
> build/_orekit/__wrap__.cpp:58329:55: error: expected ']'
> self->parameters[0] = &::PY_TYPE([D);
> ^
> build/_orekit/__wrap__.cpp:58329:52: note: to match this '['
> self->parameters[0] = &::PY_TYPE([D);
>
>
> On 02 Feb 2014, at 19:48 , Andi Vajda <va...@apache.org> wrote:
>
>
> On Feb 2, 2014, at 10:08, Petrus Hyvönen <pe...@gmail.com> wrote:
>
> Hi Andi and Others,
>
> The latest trunk jcc works and builds very fine on my windows machine, and
> happy about the extendend support of generics. But I am experiencing the
> problem below when building on my mac, using same wrap parameters as on the
> windows platform. To me it seems like some compiler problem related to
> macros, but don't know.
>
> Does anyone have experience of these failures?
>
> Regards
> /Petrus
>
>
> error: expected unqualified-id
> self->parameters[0] = &::PY_TYPE([D);
> ^
> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
> note:
> expanded from macro 'PY_TYPE'
> #define PY_TYPE(name) name##$$Type
> ^
> build/_orekit/__wrap__.cpp:2344:44: error: use of undeclared identifier
> 'D$$Type'
> self->parameters[0] = &::PY_TYPE([D);
>
>
> Take a look at the code around line 2344 in that __wrap__.cpp file and
> figure out what java code this corresponds to. You might be using a
> classname that's a C macro on some platforms - do you have a class named D
> for example ?
> If you're hitting such a name conflict, add that name to the --reserved
> list passed to jcc.
>
> Andi..
>
> ^
> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
> note:
> expanded from macro 'PY_TYPE'
> #define PY_TYPE(name) name##$$Type
> ^
> <scratch space>:73:1: note: expanded from here
> D$$Type
> ^
> build/_orekit/__wrap__.cpp:2344:55: error: expected ']'
> self->parameters[0] = &::PY_TYPE([D);
> ^
> build/_orekit/__wrap__.cpp:2344:52: note: to match this '['
> self->parameters[0] = &::PY_TYPE([D);
>
>
>
> On 14 Jan 2014, at 19:02 , Andi Vajda <va...@apache.org> wrote:
>
>
> Hi Petrus,
>
> On Jan 14, 2014, at 4:24, Petrus Hyvönen <pe...@gmail.com> wrote:
>
> Dear Andi,
>
> Many many thanks for looking into this!
>
> I am on travel for a week and do not have the computer with the special
> case with me to test. I did now however run it on the library that I am
> wrapping, and there get some errors in the creation of the wrapped module
> (orekit):
>
> build/_orekit/__wrap__.cpp:86504:89: error: no member named
> 'HarmonicOscillator$Parametric$$Type' in namespace
>
>
> I believe I fixed this bug in rev 1557613, header files for classes for
> inherited fixed parameters were not included as required.
>
> Andi..
>
> 'org::apache::commons::math3::analysis::function'
> ...=
> &::org::apache::commons::math3::analysis::function::PY_TYPE(HarmonicOs...
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
> /Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23:
> note:
> expanded from macro 'PY_TYPE'
> #define PY_TYPE(name) name##$$Type
> ^
> <scratch space>:63:1: note: expanded from here
> HarmonicOscillator$Parametric$$Type
> ^
> build/_orekit/__wrap__.cpp:217752:55: error: no member named
> 'OrekitMessages$$Type' in namespace 'org::orekit::errors'
> self->parameters[0] = &::org::orekit::errors::PY_TYPE(OrekitMessages);
> ~~~~~~~~~~~~~~~~~~~~~~~^
> /Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23:
> note:
> expanded from macro 'PY_TYPE'
> #define PY_TYPE(name) name##$$Type
> ^
> <scratch space>:9:1: note: expanded from here
> OrekitMessages$$Type
> ^
> 2 errors generated.
> error: command 'gcc' failed with exit status 1
>
>
>
> The OrekitMessages is defined as a "public enum OrekitMessages implements
> Localizable { ..."
> and the "public class HarmonicOscillator implements
> UnivariateDifferentiable, DifferentiableUnivariateFunction".
>
> Maybe this says you something, I will try to test more and run my test case
> in .
>
> Best Regards and again, many thanks again!
> /petrus
>
>
>
>
>
> On 11 Jan 2014, at 14:23 , Andi Vajda <va...@apache.org> wrote:
>
>
> Hi Petrus,
>
> On Mon, 30 Dec 2013, Petrus Hyvönen wrote:
>
> Andi, great to hear that you could reproduce it. I'm very thankful if you
> could have a look at it, I've been struggling to understand how the
> machinery behind this works, but far from it still..
>
>
> I think I fixed the problem and added an improvement to generics support
> along the way. Please check out rev 1557423 from jcc's trunk, rebuild your
> module with it and let me know how it's working for you.
>
> The bug had to do with SimpleClass2's wrapper class missing its parameters
> slot which it should get from its superclass, SimpleClass. When calling a
> method on SimpleClass from SimpleClass2, the missing parameters in the
> wrapper's struct would cause memory to get trashed.
>
> In addition to fixing the bug, I also improved support for fixed class
> parameters. Now, if you change SimpleClass's return_null() method to return
> new Integer(12) instead, when calling it on SimpleClass2, 12 is returned
> instead of <Object: 12>.
>
> Andi..
>
> public class SimpleClass<T> { public SimpleClass() {
> System.out.println("Created SimpleClass"); }
> public T return_null() {
> return (T) new Integer(12);
> }
>
> }
>
>
>
> Best Regards
> /Petrus
>
>
>
> On Mon, Dec 30, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>
>
> On Sun, 29 Dec 2013, Petrus Hyvönen wrote:
>
> I have distilled the library that I have some trouble with and I think I
>
> have an example that is failing due to same problem I think. I am not good
> in java, but have tried to follow the logic from the library I'm wrapping.
> The function of the example does not make sense in itself.
>
> public class SimpleClass<T> {
> public SimpleClass() {
> System.out.println("Created SimpleClass");
> }
> public T return_null() {
> return null;
> }
>
> }
>
>
>
> public class SimpleClass2 extends SimpleClass<Integer>{
>
> public SimpleClass2(){}
> public void testInJava(){
> System.out.println(this.return_null());
> }
> }
>
>
> It seems to me that there is some problem with methods inherited that
> returns a generic type, failing in wrapType when this is to be wrapped.
>
> The python script that fails:
>
> a= SimpleClass()
> print a.return_null()
>
> b = SimpleClass2()
> b.testInJava()
>
> print b.return_null() #Fails in wrapType
>
> I don't know if the return null is a bad thing to do in java, but the
> error
> seems very similar to what I experience in the larger library. I have a
> skeleton of that this is slightly larger, but not returning null, but
> trying to keep the lenght of example low :)
>
> Any comments highly appriciated :)
>
>
> I've been able to reproduce the problem.
> Thank you for providing an isolated test case !
>
> Andi..
>
>
>
> best Regards
> /Petrus
>
>
>
>
>
>
> On Fri, Dec 27, 2013 at 6:25 PM, Andi Vajda <va...@apache.org> wrote:
>
>
> On Dec 27, 2013, at 17:36, Petrus Hyvönen <pe...@gmail.com>
> wrote:
>
>
> Dear Andi,
>
> I am working on debugging the failure and try to understand a bit how
> JCC
> works internally. I haven't gone very far but in case you have some
> pointers from these early debugging sessions I would be very thankful. I
> know it's complex, and I should try to make some smaller test cases, but
>
> I
>
> don't really have a grasp yet where the problem might be.
>
> Writing this might help me also to get some structure in my thinking :)
>
>
>
> The main crash seems to be in the last line, wrapType(), of
> __wrap__.cpp:
>
> static PyObject
>
> *t_AbstractReconfigurableDetector_withHandler(t_
>
> AbstractReconfigurableDetector
>
> *self, PyObject *arg)
> {
> ::org::orekit::propagation::events::handlers::EventHandler
> a0((jobject) NULL);
> PyTypeObject **p0;
> ::org::orekit::propagation::events::EventDetector
> result((jobject) NULL);
>
> if (!parseArg(arg, "K",
>
> ::org::orekit::propagation::events::handlers::
>
> EventHandler::initializeClass,
>
> &a0, &p0,
>
> ::org::orekit::propagation::events::handlers::t_
>
> EventHandler::parameters_))
>
> {
> OBJ_CALL(result = self->object.withHandler(a0));
> return self->parameters[0] != NULL ?
> wrapType(self->parameters[0], result.this$) :
> ::org::orekit::propagation::events::t_EventDetector::wrap_
> Object(result);
> }
>
> The parameters[0] does not seem to be null, but neither is it a valid
> object, in my debugger it says 0xbaadf00d {ob_refcnt=??? ob_type=???
> ob_size=??? ...} _typeobject *, wrapType is called and when trying
> to
> access the wrapfn it crashes.
>
> The main python lines are:
> tmp1 = ElevationDetector(sta1Frame) #
>
> ElevationDetector
>
> is a java public class ElevationDetector extends
> AbstractReconfigurableDetector<ElevationDetector>
> hand = ContinueOnEvent().of_(ElevationDetector) # a
> java ContinueOnEvent<ElevationDetector> object
> elDetector = tmp1.withHandler(hand) #Crash. withHandler is a method
> that is inherited from AbstractReconfigurableDetector to
>
> ElevationDetector
>
>
> This crashes when interactively entered on the python prompt (or in
> other
> interactive consoles), but seems to work if executed directly without
> interactivity. This difference makes me think that it might be something
> with garbage collection, but don't know.
>
> Any comments appriciated, I know this is likely very difficult to
> comment
> on as it's not very encapsulated.
>
>
> Right, so unless you can isolate this into something I can reproduce, I'm
> afraid there isn't much I can comment.
> It is quite likely that by the time you have that reproducible test case
> ready, you also have the solution to the problem. Or I might be able to
> help then...
>
> Andi..
>
>
> Regards
> /Petrus
>
>
>
>
>
>
> On Sun, Dec 15, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>
>
> On Dec 15, 2013, at 5:43, Petrus Hyvönen <pe...@gmail.com>
>
> wrote:
>
> Hi Andi,
>
> I see your point and have now kept in the pure python domain.
>
> If I run my script from the shell by "python script.py" it does not
>
> crash. However if I execute it line-by-line in python it crashes (or in
> other tools such as ipython notebook).
>
> All classes used are non-wrapped java classes, but I get the same
>
> effect
>
>
> with classes made for python subclassing.
>
>
> I am getting this on both MacOSX 64-bit python and Windows 7 32-bit
>
> python.
>
>
>
> elDetector =
>
> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>
>
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x000000010005da1a, pid=3318, tid=1287
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
>
> 1.7.0_45-b18)
>
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
>
> bsd-amd64 compressed oops)
>
> # Problematic frame:
> # C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
> #
>
>
> from the stack it seems like there is somthing happening in "wrapType"
> Stack: [0x00007fff5fb80000,0x00007fff5fc00000],
> sp=0x00007fff5fbff470,
>
> free space=509k
>
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>
> C=native code)
>
> C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
> C [_orekit.so+0xa80878] wrapType(_typeobject*, _jobject*
> const&)+0x58
> C [_orekit.so+0x554400]
>
>
> org::orekit::propagation::events::t_AbstractReconfigurableDetector
>
> _withHandler(org::orekit::propagation::events::t_
> AbstractReconfigurableDetector*,
>
> _object*)+0x1c0
>
>
>
> First, is the generic class assignment correct as if to write "new
>
> ContinueOnEvent<ElevationDetector>()" in java? And is it ok to use
>
> regular
>
>
> java objects/types?
>
>
>
> Any other comments to move forward highly appriciated.. Is it somehow
>
> possible to get more log what is going wrong?
>
> You could compile the whole thing for debugging, by adding --debug
> after
> 'build' in the jcc invocation and run it with gdb.
>
> If you can isolate a reproducible crash into a small test case, I can
>
> also
>
>
> take a look at it.
>
>
> Andi..
>
>
> WIth best regards
> /Petrus
>
>
>
> On 15 Dec 2013, at 2:40 , Andi Vajda <va...@apache.org> wrote:
>
>
> On Dec 14, 2013, at 19:14, Petrus Hyvönen <petrus.hyvonen@gmail.com
> wrote:
>
>
>
> Hi,
>
> I'm having a problem with I think might be related to generic types,
>
> but not sure at all.
>
>
>
> I'm wrapping a orbit calculation library, which has been working
> well
>
> but in latest version is using generic types and I'm getting some
>
> problems.
>
>
> The script works when executed in plain python, but fails in ipython
>
> notebook on this last line when executed as a couple of cells.
>
>
> What is an 'ipython notebook' ?
>
> Andi.,
>
>
> The section with problem in my script is:
> elDetector =
>
> ElevationDetector(sta1Frame).withConstantElevation(math.
>
> radians(5.0))
>
> elDetector =
>
> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>
>
>
> In Java it would typically look something like:
>
> ElevationDetector detector = new ElevationDetector(topo)
> .withConstantElevation(x)
> .withHandler(new
>
> ContinueOnEvent<ElevationDetector>());
>
>
>
> It produces correct results in plain python, but crashes the kernel
>
> in
>
>
> ipython if executed as cells, and in exection from spyder I get an error
>
> message:
>
>
> " elDetector =
>
> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>
>
> AttributeError: 'str' object has no attribute 'wrapfn_' "
>
>
> As I have been using this setup stabely with lots of other functions
>
> it feels like there is something with the generic type line, but I
>
> don't
> really know how to get any further? I'm confused by that the pauses in
>
> the
>
>
> execution could seem to affect the result.
>
>
>
> Any comments highly appriciated...
>
> Best Regards
> /Petrus
>
>
>
> --
> _____________________________________________
> Petrus Hyvönen, Uppsala, Sweden
> Mobile Phone/SMS:+46 73 803 19 00
>
>
>
> --
> _____________________________________________
> Petrus Hyvönen, Uppsala, Sweden
> Mobile Phone/SMS:+46 73 803 19 00
>
>
>
> --
> _____________________________________________
> Petrus Hyvönen, Uppsala, Sweden
> Mobile Phone/SMS:+46 73 803 19 00
>
Re: Problem using generic types?
Posted by Petrus Hyvönen <pe...@gmail.com>.
Hi Andi,
Yes, the confusing thing is that it works well under windows. I compared
the code in __wrap__ and it looks different in the windows version:
static int t_PointVectorValuePair_init_(t_PointVectorValuePair *self,
PyObject *args, PyObject *kwds)
{
switch (PyTuple_GET_SIZE(args)) {
case 2:
{
JArray< jdouble > a0((jobject) NULL);
JArray< jdouble > a1((jobject) NULL);
PointVectorValuePair object((jobject) NULL);
if (!parseArgs(args, "[D[D", &a0, &a1))
{
INT_CALL(object = PointVectorValuePair(a0, a1));
self->object = object;
break;
}
}
So no Parameters[] stuff in windows version.. On mac I'm using java v
1.7.0_45 and 1.6.0_35 under windows. could that make a difference?
I'm using a mvn downloaded version of the apache.math jar, but source is:
public class PointVectorValuePair extends Pair<double[], double[]>
implements Serializable {
/** Serializable UID. */
private static final long serialVersionUID = 20120513L;
/**
...
*/
public PointVectorValuePair(final double[] point,
final double[] value) {
this(point, value, true);
}
/**
...
*/
public PointVectorValuePair(final double[] point,
final double[] value,
final boolean copyArray) {
super(copyArray ?
((point == null) ? null :
point.clone()) :
point,
copyArray ?
((value == null) ? null :
value.clone()) :
value);
}
...
full code at
http://commons-math/jacoco/org.apache.commons.math3.optimization/PointVectorValuePair.java.html
Regards
/petrus
On 02 Feb 2014, at 22:54 , Andi Vajda <va...@apache.org> wrote:
On Feb 2, 2014, at 13:41, Petrus Hyvönen <pe...@gmail.com> wrote:
Hi,
It's part of a class "PointVectorValuePair" and "PointValuePair" in the
apache math commons (
http://commons.apache.org/proper/commons-math/javadocs/api-3.2/org/apache/commons/math3/optimization/PointVectorValuePair.html
)
I have tried to reserve a bunch of things like 'Point', 'Value', 'Pair'
without any difference. If I go through the __wrap__ file, it looks like
this [D object to wrap is a very odd one, the other PY_TYPE wrapping seems
to have 'proper' names without special characters. It's the functions
PointValuePair and PointVectorValuePair that seems to have this strage
class wrapping. I cannot find a class named D. From the API doc's I would
guess it's trying to set a double [] type.
extract from __wrap__:
under namespace org {
namespace apache {
namespace commons {
namespace math3 {
namespace optimization {
...
static int t_PointVectorValuePair_init_(t_PointVectorValuePair
*self, PyObject *args, PyObject *kwds)
{
switch (PyTuple_GET_SIZE(args)) {
case 2:
{
JArray< jdouble > a0((jobject) NULL);
JArray< jdouble > a1((jobject) NULL);
PointVectorValuePair object((jobject) NULL);
if (!parseArgs(args, "[D[D", &a0, &a1))
It could just be that you found a bug in jcc's handling of generic
parameters that are arrays. I suspect you have some double[] (or worse:
double[][]) somewhere in the java source.
But then this should fail the same way on Windows.
Can you please post the original java source for that class here ?
Andi..
{
INT_CALL(object = PointVectorValuePair(a0, a1));
self->object = object;
self->parameters[0] = &::PY_TYPE([D);
self->parameters[1] = &::PY_TYPE([D);
break;
}
Regards
/petrus
= &::PY_TYPE([D);
^
/Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
note:
expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
^
build/_orekit/__wrap__.cpp:58329:44: error: use of undeclared identifier
'D$$Type'
self->parameters[0] = &::PY_TYPE([D);
^
/Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
note:
expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
^
<scratch space>:109:1: note: expanded from here
D$$Type
^
build/_orekit/__wrap__.cpp:58329:55: error: expected ']'
self->parameters[0] = &::PY_TYPE([D);
^
build/_orekit/__wrap__.cpp:58329:52: note: to match this '['
self->parameters[0] = &::PY_TYPE([D);
On 02 Feb 2014, at 19:48 , Andi Vajda <va...@apache.org> wrote:
On Feb 2, 2014, at 10:08, Petrus Hyvönen <pe...@gmail.com> wrote:
Hi Andi and Others,
The latest trunk jcc works and builds very fine on my windows machine, and
happy about the extendend support of generics. But I am experiencing the
problem below when building on my mac, using same wrap parameters as on the
windows platform. To me it seems like some compiler problem related to
macros, but don't know.
Does anyone have experience of these failures?
Regards
/Petrus
error: expected unqualified-id
self->parameters[0] = &::PY_TYPE([D);
^
/Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
note:
expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
^
build/_orekit/__wrap__.cpp:2344:44: error: use of undeclared identifier
'D$$Type'
self->parameters[0] = &::PY_TYPE([D);
Take a look at the code around line 2344 in that __wrap__.cpp file and
figure out what java code this corresponds to. You might be using a
classname that's a C macro on some platforms - do you have a class named D
for example ?
If you're hitting such a name conflict, add that name to the --reserved
list passed to jcc.
Andi..
^
/Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
note:
expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
^
<scratch space>:73:1: note: expanded from here
D$$Type
^
build/_orekit/__wrap__.cpp:2344:55: error: expected ']'
self->parameters[0] = &::PY_TYPE([D);
^
build/_orekit/__wrap__.cpp:2344:52: note: to match this '['
self->parameters[0] = &::PY_TYPE([D);
On 14 Jan 2014, at 19:02 , Andi Vajda <va...@apache.org> wrote:
Hi Petrus,
On Jan 14, 2014, at 4:24, Petrus Hyvönen <pe...@gmail.com> wrote:
Dear Andi,
Many many thanks for looking into this!
I am on travel for a week and do not have the computer with the special
case with me to test. I did now however run it on the library that I am
wrapping, and there get some errors in the creation of the wrapped module
(orekit):
build/_orekit/__wrap__.cpp:86504:89: error: no member named
'HarmonicOscillator$Parametric$$Type' in namespace
I believe I fixed this bug in rev 1557613, header files for classes for
inherited fixed parameters were not included as required.
Andi..
'org::apache::commons::math3::analysis::function'
...=
&::org::apache::commons::math3::analysis::function::PY_TYPE(HarmonicOs...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
/Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23:
note:
expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
^
<scratch space>:63:1: note: expanded from here
HarmonicOscillator$Parametric$$Type
^
build/_orekit/__wrap__.cpp:217752:55: error: no member named
'OrekitMessages$$Type' in namespace 'org::orekit::errors'
self->parameters[0] = &::org::orekit::errors::PY_TYPE(OrekitMessages);
~~~~~~~~~~~~~~~~~~~~~~~^
/Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23:
note:
expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
^
<scratch space>:9:1: note: expanded from here
OrekitMessages$$Type
^
2 errors generated.
error: command 'gcc' failed with exit status 1
The OrekitMessages is defined as a "public enum OrekitMessages implements
Localizable { ..."
and the "public class HarmonicOscillator implements
UnivariateDifferentiable, DifferentiableUnivariateFunction".
Maybe this says you something, I will try to test more and run my test case
in .
Best Regards and again, many thanks again!
/petrus
On 11 Jan 2014, at 14:23 , Andi Vajda <va...@apache.org> wrote:
Hi Petrus,
On Mon, 30 Dec 2013, Petrus Hyvönen wrote:
Andi, great to hear that you could reproduce it. I'm very thankful if you
could have a look at it, I've been struggling to understand how the
machinery behind this works, but far from it still..
I think I fixed the problem and added an improvement to generics support
along the way. Please check out rev 1557423 from jcc's trunk, rebuild your
module with it and let me know how it's working for you.
The bug had to do with SimpleClass2's wrapper class missing its parameters
slot which it should get from its superclass, SimpleClass. When calling a
method on SimpleClass from SimpleClass2, the missing parameters in the
wrapper's struct would cause memory to get trashed.
In addition to fixing the bug, I also improved support for fixed class
parameters. Now, if you change SimpleClass's return_null() method to return
new Integer(12) instead, when calling it on SimpleClass2, 12 is returned
instead of <Object: 12>.
Andi..
public class SimpleClass<T> { public SimpleClass() {
System.out.println("Created SimpleClass"); }
public T return_null() {
return (T) new Integer(12);
}
}
Best Regards
/Petrus
On Mon, Dec 30, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
On Sun, 29 Dec 2013, Petrus Hyvönen wrote:
I have distilled the library that I have some trouble with and I think I
have an example that is failing due to same problem I think. I am not good
in java, but have tried to follow the logic from the library I'm wrapping.
The function of the example does not make sense in itself.
public class SimpleClass<T> {
public SimpleClass() {
System.out.println("Created SimpleClass");
}
public T return_null() {
return null;
}
}
public class SimpleClass2 extends SimpleClass<Integer>{
public SimpleClass2(){}
public void testInJava(){
System.out.println(this.return_null());
}
}
It seems to me that there is some problem with methods inherited that
returns a generic type, failing in wrapType when this is to be wrapped.
The python script that fails:
a= SimpleClass()
print a.return_null()
b = SimpleClass2()
b.testInJava()
print b.return_null() #Fails in wrapType
I don't know if the return null is a bad thing to do in java, but the
error
seems very similar to what I experience in the larger library. I have a
skeleton of that this is slightly larger, but not returning null, but
trying to keep the lenght of example low :)
Any comments highly appriciated :)
I've been able to reproduce the problem.
Thank you for providing an isolated test case !
Andi..
best Regards
/Petrus
On Fri, Dec 27, 2013 at 6:25 PM, Andi Vajda <va...@apache.org> wrote:
On Dec 27, 2013, at 17:36, Petrus Hyvönen <pe...@gmail.com>
wrote:
Dear Andi,
I am working on debugging the failure and try to understand a bit how
JCC
works internally. I haven't gone very far but in case you have some
pointers from these early debugging sessions I would be very thankful. I
know it's complex, and I should try to make some smaller test cases, but
I
don't really have a grasp yet where the problem might be.
Writing this might help me also to get some structure in my thinking :)
The main crash seems to be in the last line, wrapType(), of
__wrap__.cpp:
static PyObject
*t_AbstractReconfigurableDetector_withHandler(t_
AbstractReconfigurableDetector
*self, PyObject *arg)
{
::org::orekit::propagation::events::handlers::EventHandler
a0((jobject) NULL);
PyTypeObject **p0;
::org::orekit::propagation::events::EventDetector
result((jobject) NULL);
if (!parseArg(arg, "K",
::org::orekit::propagation::events::handlers::
EventHandler::initializeClass,
&a0, &p0,
::org::orekit::propagation::events::handlers::t_
EventHandler::parameters_))
{
OBJ_CALL(result = self->object.withHandler(a0));
return self->parameters[0] != NULL ?
wrapType(self->parameters[0], result.this$) :
::org::orekit::propagation::events::t_EventDetector::wrap_
Object(result);
}
The parameters[0] does not seem to be null, but neither is it a valid
object, in my debugger it says 0xbaadf00d {ob_refcnt=??? ob_type=???
ob_size=??? ...} _typeobject *, wrapType is called and when trying
to
access the wrapfn it crashes.
The main python lines are:
tmp1 = ElevationDetector(sta1Frame) #
ElevationDetector
is a java public class ElevationDetector extends
AbstractReconfigurableDetector<ElevationDetector>
hand = ContinueOnEvent().of_(ElevationDetector) # a
java ContinueOnEvent<ElevationDetector> object
elDetector = tmp1.withHandler(hand) #Crash. withHandler is a method
that is inherited from AbstractReconfigurableDetector to
ElevationDetector
This crashes when interactively entered on the python prompt (or in
other
interactive consoles), but seems to work if executed directly without
interactivity. This difference makes me think that it might be something
with garbage collection, but don't know.
Any comments appriciated, I know this is likely very difficult to
comment
on as it's not very encapsulated.
Right, so unless you can isolate this into something I can reproduce, I'm
afraid there isn't much I can comment.
It is quite likely that by the time you have that reproducible test case
ready, you also have the solution to the problem. Or I might be able to
help then...
Andi..
Regards
/Petrus
On Sun, Dec 15, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
On Dec 15, 2013, at 5:43, Petrus Hyvönen <pe...@gmail.com>
wrote:
Hi Andi,
I see your point and have now kept in the pure python domain.
If I run my script from the shell by "python script.py" it does not
crash. However if I execute it line-by-line in python it crashes (or in
other tools such as ipython notebook).
All classes used are non-wrapped java classes, but I get the same
effect
with classes made for python subclassing.
I am getting this on both MacOSX 64-bit python and Windows 7 32-bit
python.
elDetector =
elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x000000010005da1a, pid=3318, tid=1287
#
# JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
1.7.0_45-b18)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
bsd-amd64 compressed oops)
# Problematic frame:
# C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
#
from the stack it seems like there is somthing happening in "wrapType"
Stack: [0x00007fff5fb80000,0x00007fff5fc00000],
sp=0x00007fff5fbff470,
free space=509k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code)
C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
C [_orekit.so+0xa80878] wrapType(_typeobject*, _jobject*
const&)+0x58
C [_orekit.so+0x554400]
org::orekit::propagation::events::t_AbstractReconfigurableDetector
_withHandler(org::orekit::propagation::events::t_
AbstractReconfigurableDetector*,
_object*)+0x1c0
First, is the generic class assignment correct as if to write "new
ContinueOnEvent<ElevationDetector>()" in java? And is it ok to use
regular
java objects/types?
Any other comments to move forward highly appriciated.. Is it somehow
possible to get more log what is going wrong?
You could compile the whole thing for debugging, by adding --debug
after
'build' in the jcc invocation and run it with gdb.
If you can isolate a reproducible crash into a small test case, I can
also
take a look at it.
Andi..
WIth best regards
/Petrus
On 15 Dec 2013, at 2:40 , Andi Vajda <va...@apache.org> wrote:
On Dec 14, 2013, at 19:14, Petrus Hyvönen <petrus.hyvonen@gmail.com
wrote:
Hi,
I'm having a problem with I think might be related to generic types,
but not sure at all.
I'm wrapping a orbit calculation library, which has been working
well
but in latest version is using generic types and I'm getting some
problems.
The script works when executed in plain python, but fails in ipython
notebook on this last line when executed as a couple of cells.
What is an 'ipython notebook' ?
Andi.,
The section with problem in my script is:
elDetector =
ElevationDetector(sta1Frame).withConstantElevation(math.
radians(5.0))
elDetector =
elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
In Java it would typically look something like:
ElevationDetector detector = new ElevationDetector(topo)
.withConstantElevation(x)
.withHandler(new
ContinueOnEvent<ElevationDetector>());
It produces correct results in plain python, but crashes the kernel
in
ipython if executed as cells, and in exection from spyder I get an error
message:
" elDetector =
elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
AttributeError: 'str' object has no attribute 'wrapfn_' "
As I have been using this setup stabely with lots of other functions
it feels like there is something with the generic type line, but I
don't
really know how to get any further? I'm confused by that the pauses in
the
execution could seem to affect the result.
Any comments highly appriciated...
Best Regards
/Petrus
--
_____________________________________________
Petrus Hyvönen, Uppsala, Sweden
Mobile Phone/SMS:+46 73 803 19 00
--
_____________________________________________
Petrus Hyvönen, Uppsala, Sweden
Mobile Phone/SMS:+46 73 803 19 00
--
_____________________________________________
Petrus Hyvönen, Uppsala, Sweden
Mobile Phone/SMS:+46 73 803 19 00
Re: Problem using generic types?
Posted by Andi Vajda <va...@apache.org>.
> On Feb 2, 2014, at 13:41, Petrus Hyvönen <pe...@gmail.com> wrote:
>
> Hi,
>
> It's part of a class "PointVectorValuePair" and "PointValuePair" in the apache math commons (http://commons.apache.org/proper/commons-math/javadocs/api-3.2/org/apache/commons/math3/optimization/PointVectorValuePair.html)
>
> I have tried to reserve a bunch of things like 'Point', 'Value', 'Pair' without any difference. If I go through the __wrap__ file, it looks like this [D object to wrap is a very odd one, the other PY_TYPE wrapping seems to have 'proper' names without special characters. It's the functions PointValuePair and PointVectorValuePair that seems to have this strage class wrapping. I cannot find a class named D. From the API doc's I would guess it's trying to set a double [] type.
>
> extract from __wrap__:
>
> under namespace org {
> namespace apache {
> namespace commons {
> namespace math3 {
> namespace optimization {
>
> ...
>
> static int t_PointVectorValuePair_init_(t_PointVectorValuePair *self, PyObject *args, PyObject *kwds)
> {
> switch (PyTuple_GET_SIZE(args)) {
> case 2:
> {
> JArray< jdouble > a0((jobject) NULL);
> JArray< jdouble > a1((jobject) NULL);
> PointVectorValuePair object((jobject) NULL);
>
> if (!parseArgs(args, "[D[D", &a0, &a1))
It could just be that you found a bug in jcc's handling of generic parameters that are arrays. I suspect you have some double[] (or worse: double[][]) somewhere in the java source.
But then this should fail the same way on Windows.
Can you please post the original java source for that class here ?
Andi..
> {
> INT_CALL(object = PointVectorValuePair(a0, a1));
> self->object = object;
> self->parameters[0] = &::PY_TYPE([D);
> self->parameters[1] = &::PY_TYPE([D);
> break;
> }
>
> Regards
> /petrus
>
>
>
> = &::PY_TYPE([D);
> ^
> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23: note:
> expanded from macro 'PY_TYPE'
> #define PY_TYPE(name) name##$$Type
> ^
> build/_orekit/__wrap__.cpp:58329:44: error: use of undeclared identifier
> 'D$$Type'
> self->parameters[0] = &::PY_TYPE([D);
> ^
> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23: note:
> expanded from macro 'PY_TYPE'
> #define PY_TYPE(name) name##$$Type
> ^
> <scratch space>:109:1: note: expanded from here
> D$$Type
> ^
> build/_orekit/__wrap__.cpp:58329:55: error: expected ']'
> self->parameters[0] = &::PY_TYPE([D);
> ^
> build/_orekit/__wrap__.cpp:58329:52: note: to match this '['
> self->parameters[0] = &::PY_TYPE([D);
>
>
>> On 02 Feb 2014, at 19:48 , Andi Vajda <va...@apache.org> wrote:
>>
>>
>>> On Feb 2, 2014, at 10:08, Petrus Hyvönen <pe...@gmail.com> wrote:
>>>
>>> Hi Andi and Others,
>>>
>>> The latest trunk jcc works and builds very fine on my windows machine, and happy about the extendend support of generics. But I am experiencing the problem below when building on my mac, using same wrap parameters as on the windows platform. To me it seems like some compiler problem related to macros, but don't know.
>>>
>>> Does anyone have experience of these failures?
>>>
>>> Regards
>>> /Petrus
>>>
>>>
>>> error: expected unqualified-id
>>> self->parameters[0] = &::PY_TYPE([D);
>>> ^
>>> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23: note:
>>> expanded from macro 'PY_TYPE'
>>> #define PY_TYPE(name) name##$$Type
>>> ^
>>> build/_orekit/__wrap__.cpp:2344:44: error: use of undeclared identifier
>>> 'D$$Type'
>>> self->parameters[0] = &::PY_TYPE([D);
>>
>> Take a look at the code around line 2344 in that __wrap__.cpp file and figure out what java code this corresponds to. You might be using a classname that's a C macro on some platforms - do you have a class named D for example ?
>> If you're hitting such a name conflict, add that name to the --reserved list passed to jcc.
>>
>> Andi..
>>
>>> ^
>>> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23: note:
>>> expanded from macro 'PY_TYPE'
>>> #define PY_TYPE(name) name##$$Type
>>> ^
>>> <scratch space>:73:1: note: expanded from here
>>> D$$Type
>>> ^
>>> build/_orekit/__wrap__.cpp:2344:55: error: expected ']'
>>> self->parameters[0] = &::PY_TYPE([D);
>>> ^
>>> build/_orekit/__wrap__.cpp:2344:52: note: to match this '['
>>> self->parameters[0] = &::PY_TYPE([D);
>>>
>>>
>>>
>>>> On 14 Jan 2014, at 19:02 , Andi Vajda <va...@apache.org> wrote:
>>>>
>>>>
>>>> Hi Petrus,
>>>>
>>>>> On Jan 14, 2014, at 4:24, Petrus Hyvönen <pe...@gmail.com> wrote:
>>>>>
>>>>> Dear Andi,
>>>>>
>>>>> Many many thanks for looking into this!
>>>>>
>>>>> I am on travel for a week and do not have the computer with the special case with me to test. I did now however run it on the library that I am wrapping, and there get some errors in the creation of the wrapped module (orekit):
>>>>>
>>>>> build/_orekit/__wrap__.cpp:86504:89: error: no member named
>>>>> 'HarmonicOscillator$Parametric$$Type' in namespace
>>>>
>>>> I believe I fixed this bug in rev 1557613, header files for classes for inherited fixed parameters were not included as required.
>>>>
>>>> Andi..
>>>>
>>>>> 'org::apache::commons::math3::analysis::function'
>>>>> ...= &::org::apache::commons::math3::analysis::function::PY_TYPE(HarmonicOs...
>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
>>>>> /Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23: note:
>>>>> expanded from macro 'PY_TYPE'
>>>>> #define PY_TYPE(name) name##$$Type
>>>>> ^
>>>>> <scratch space>:63:1: note: expanded from here
>>>>> HarmonicOscillator$Parametric$$Type
>>>>> ^
>>>>> build/_orekit/__wrap__.cpp:217752:55: error: no member named
>>>>> 'OrekitMessages$$Type' in namespace 'org::orekit::errors'
>>>>> self->parameters[0] = &::org::orekit::errors::PY_TYPE(OrekitMessages);
>>>>> ~~~~~~~~~~~~~~~~~~~~~~~^
>>>>> /Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23: note:
>>>>> expanded from macro 'PY_TYPE'
>>>>> #define PY_TYPE(name) name##$$Type
>>>>> ^
>>>>> <scratch space>:9:1: note: expanded from here
>>>>> OrekitMessages$$Type
>>>>> ^
>>>>> 2 errors generated.
>>>>> error: command 'gcc' failed with exit status 1
>>>>>
>>>>>
>>>>>
>>>>> The OrekitMessages is defined as a "public enum OrekitMessages implements Localizable { ..."
>>>>> and the "public class HarmonicOscillator implements UnivariateDifferentiable, DifferentiableUnivariateFunction".
>>>>>
>>>>> Maybe this says you something, I will try to test more and run my test case in .
>>>>>
>>>>> Best Regards and again, many thanks again!
>>>>> /petrus
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On 11 Jan 2014, at 14:23 , Andi Vajda <va...@apache.org> wrote:
>>>>>>
>>>>>>
>>>>>> Hi Petrus,
>>>>>>
>>>>>>> On Mon, 30 Dec 2013, Petrus Hyvönen wrote:
>>>>>>>
>>>>>>> Andi, great to hear that you could reproduce it. I'm very thankful if you
>>>>>>> could have a look at it, I've been struggling to understand how the
>>>>>>> machinery behind this works, but far from it still..
>>>>>>
>>>>>> I think I fixed the problem and added an improvement to generics support along the way. Please check out rev 1557423 from jcc's trunk, rebuild your module with it and let me know how it's working for you.
>>>>>>
>>>>>> The bug had to do with SimpleClass2's wrapper class missing its parameters slot which it should get from its superclass, SimpleClass. When calling a
>>>>>> method on SimpleClass from SimpleClass2, the missing parameters in the
>>>>>> wrapper's struct would cause memory to get trashed.
>>>>>>
>>>>>> In addition to fixing the bug, I also improved support for fixed class parameters. Now, if you change SimpleClass's return_null() method to return new Integer(12) instead, when calling it on SimpleClass2, 12 is returned instead of <Object: 12>.
>>>>>>
>>>>>> Andi..
>>>>>>
>>>>>> public class SimpleClass<T> { public SimpleClass() { System.out.println("Created SimpleClass"); }
>>>>>> public T return_null() {
>>>>>> return (T) new Integer(12);
>>>>>> }
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Best Regards
>>>>>>> /Petrus
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Mon, Dec 30, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, 29 Dec 2013, Petrus Hyvönen wrote:
>>>>>>>>
>>>>>>>> I have distilled the library that I have some trouble with and I think I
>>>>>>>>> have an example that is failing due to same problem I think. I am not good
>>>>>>>>> in java, but have tried to follow the logic from the library I'm wrapping.
>>>>>>>>> The function of the example does not make sense in itself.
>>>>>>>>>
>>>>>>>>> public class SimpleClass<T> {
>>>>>>>>> public SimpleClass() {
>>>>>>>>> System.out.println("Created SimpleClass");
>>>>>>>>> }
>>>>>>>>> public T return_null() {
>>>>>>>>> return null;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> public class SimpleClass2 extends SimpleClass<Integer>{
>>>>>>>>>
>>>>>>>>> public SimpleClass2(){}
>>>>>>>>> public void testInJava(){
>>>>>>>>> System.out.println(this.return_null());
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It seems to me that there is some problem with methods inherited that
>>>>>>>>> returns a generic type, failing in wrapType when this is to be wrapped.
>>>>>>>>>
>>>>>>>>> The python script that fails:
>>>>>>>>>
>>>>>>>>> a= SimpleClass()
>>>>>>>>> print a.return_null()
>>>>>>>>>
>>>>>>>>> b = SimpleClass2()
>>>>>>>>> b.testInJava()
>>>>>>>>>
>>>>>>>>> print b.return_null() #Fails in wrapType
>>>>>>>>>
>>>>>>>>> I don't know if the return null is a bad thing to do in java, but the
>>>>>>>>> error
>>>>>>>>> seems very similar to what I experience in the larger library. I have a
>>>>>>>>> skeleton of that this is slightly larger, but not returning null, but
>>>>>>>>> trying to keep the lenght of example low :)
>>>>>>>>>
>>>>>>>>> Any comments highly appriciated :)
>>>>>>>>
>>>>>>>> I've been able to reproduce the problem.
>>>>>>>> Thank you for providing an isolated test case !
>>>>>>>>
>>>>>>>> Andi..
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> best Regards
>>>>>>>>> /Petrus
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Dec 27, 2013 at 6:25 PM, Andi Vajda <va...@apache.org> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Dec 27, 2013, at 17:36, Petrus Hyvönen <pe...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Dear Andi,
>>>>>>>>>>>
>>>>>>>>>>> I am working on debugging the failure and try to understand a bit how
>>>>>>>>>>> JCC
>>>>>>>>>>> works internally. I haven't gone very far but in case you have some
>>>>>>>>>>> pointers from these early debugging sessions I would be very thankful. I
>>>>>>>>>>> know it's complex, and I should try to make some smaller test cases, but
>>>>>>>>>> I
>>>>>>>>>>
>>>>>>>>>>> don't really have a grasp yet where the problem might be.
>>>>>>>>>>>
>>>>>>>>>>> Writing this might help me also to get some structure in my thinking :)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The main crash seems to be in the last line, wrapType(), of
>>>>>>>>>>> __wrap__.cpp:
>>>>>>>>>>>
>>>>>>>>>>> static PyObject
>>>>>>>>>>>
>>>>>>>>>>> *t_AbstractReconfigurableDetector_withHandler(t_
>>>>>>>>>> AbstractReconfigurableDetector
>>>>>>>>>>
>>>>>>>>>>> *self, PyObject *arg)
>>>>>>>>>>> {
>>>>>>>>>>> ::org::orekit::propagation::events::handlers::EventHandler
>>>>>>>>>>> a0((jobject) NULL);
>>>>>>>>>>> PyTypeObject **p0;
>>>>>>>>>>> ::org::orekit::propagation::events::EventDetector
>>>>>>>>>>> result((jobject) NULL);
>>>>>>>>>>>
>>>>>>>>>>> if (!parseArg(arg, "K",
>>>>>>>>>>>
>>>>>>>>>>> ::org::orekit::propagation::events::handlers::
>>>>>>>>>> EventHandler::initializeClass,
>>>>>>>>>>
>>>>>>>>>>> &a0, &p0,
>>>>>>>>>>>
>>>>>>>>>>> ::org::orekit::propagation::events::handlers::t_
>>>>>>>>>> EventHandler::parameters_))
>>>>>>>>>>
>>>>>>>>>>> {
>>>>>>>>>>> OBJ_CALL(result = self->object.withHandler(a0));
>>>>>>>>>>> return self->parameters[0] != NULL ?
>>>>>>>>>>> wrapType(self->parameters[0], result.this$) :
>>>>>>>>>>> ::org::orekit::propagation::events::t_EventDetector::wrap_
>>>>>>>>>>> Object(result);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> The parameters[0] does not seem to be null, but neither is it a valid
>>>>>>>>>>> object, in my debugger it says 0xbaadf00d {ob_refcnt=??? ob_type=???
>>>>>>>>>>> ob_size=??? ...} _typeobject *, wrapType is called and when trying
>>>>>>>>>>> to
>>>>>>>>>>> access the wrapfn it crashes.
>>>>>>>>>>>
>>>>>>>>>>> The main python lines are:
>>>>>>>>>>> tmp1 = ElevationDetector(sta1Frame) #
>>>>>>>>>> ElevationDetector
>>>>>>>>>>
>>>>>>>>>>> is a java public class ElevationDetector extends
>>>>>>>>>>> AbstractReconfigurableDetector<ElevationDetector>
>>>>>>>>>>> hand = ContinueOnEvent().of_(ElevationDetector) # a
>>>>>>>>>>> java ContinueOnEvent<ElevationDetector> object
>>>>>>>>>>> elDetector = tmp1.withHandler(hand) #Crash. withHandler is a method
>>>>>>>>>>> that is inherited from AbstractReconfigurableDetector to
>>>>>>>>>> ElevationDetector
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This crashes when interactively entered on the python prompt (or in
>>>>>>>>>>> other
>>>>>>>>>>> interactive consoles), but seems to work if executed directly without
>>>>>>>>>>> interactivity. This difference makes me think that it might be something
>>>>>>>>>>> with garbage collection, but don't know.
>>>>>>>>>>>
>>>>>>>>>>> Any comments appriciated, I know this is likely very difficult to
>>>>>>>>>>> comment
>>>>>>>>>>> on as it's not very encapsulated.
>>>>>>>>>>
>>>>>>>>>> Right, so unless you can isolate this into something I can reproduce, I'm
>>>>>>>>>> afraid there isn't much I can comment.
>>>>>>>>>> It is quite likely that by the time you have that reproducible test case
>>>>>>>>>> ready, you also have the solution to the problem. Or I might be able to
>>>>>>>>>> help then...
>>>>>>>>>>
>>>>>>>>>> Andi..
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> /Petrus
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Dec 15, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Dec 15, 2013, at 5:43, Petrus Hyvönen <pe...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Andi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I see your point and have now kept in the pure python domain.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If I run my script from the shell by "python script.py" it does not
>>>>>>>>>>>> crash. However if I execute it line-by-line in python it crashes (or in
>>>>>>>>>>>> other tools such as ipython notebook).
>>>>>>>>>>>>
>>>>>>>>>>>>> All classes used are non-wrapped java classes, but I get the same
>>>>>>>>>>>> effect
>>>>>>>>>>
>>>>>>>>>>> with classes made for python subclassing.
>>>>>>>>>>>>
>>>>>>>>>>>>> I am getting this on both MacOSX 64-bit python and Windows 7 32-bit
>>>>>>>>>>>> python.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> elDetector =
>>>>>>>>>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>>>>>>>
>>>>>>>>>>>>> #
>>>>>>>>>>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>>>>>>>>>>> #
>>>>>>>>>>>>> # SIGSEGV (0xb) at pc=0x000000010005da1a, pid=3318, tid=1287
>>>>>>>>>>>>> #
>>>>>>>>>>>>> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
>>>>>>>>>>>> 1.7.0_45-b18)
>>>>>>>>>>>>
>>>>>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
>>>>>>>>>>>> bsd-amd64 compressed oops)
>>>>>>>>>>>>
>>>>>>>>>>>>> # Problematic frame:
>>>>>>>>>>>>> # C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>>>>>>>>>>>> #
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> from the stack it seems like there is somthing happening in "wrapType"
>>>>>>>>>>>>> Stack: [0x00007fff5fb80000,0x00007fff5fc00000],
>>>>>>>>>>>>> sp=0x00007fff5fbff470,
>>>>>>>>>>>> free space=509k
>>>>>>>>>>>>
>>>>>>>>>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>>>>>>>>>>> C=native code)
>>>>>>>>>>>>
>>>>>>>>>>>>> C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>>>>>>>>>>>> C [_orekit.so+0xa80878] wrapType(_typeobject*, _jobject*
>>>>>>>>>>>>> const&)+0x58
>>>>>>>>>>>>> C [_orekit.so+0x554400]
>>>>>>>>>>>>
>>>>>>>>>>>> org::orekit::propagation::events::t_AbstractReconfigurableDetector
>>>>>>>>>> _withHandler(org::orekit::propagation::events::t_
>>>>>>>>>> AbstractReconfigurableDetector*,
>>>>>>>>>>
>>>>>>>>>>> _object*)+0x1c0
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> First, is the generic class assignment correct as if to write "new
>>>>>>>>>>>> ContinueOnEvent<ElevationDetector>()" in java? And is it ok to use
>>>>>>>>>>> regular
>>>>>>>>>>
>>>>>>>>>>> java objects/types?
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Any other comments to move forward highly appriciated.. Is it somehow
>>>>>>>>>>>> possible to get more log what is going wrong?
>>>>>>>>>>>>
>>>>>>>>>>>> You could compile the whole thing for debugging, by adding --debug
>>>>>>>>>>>> after
>>>>>>>>>>>> 'build' in the jcc invocation and run it with gdb.
>>>>>>>>>>>>
>>>>>>>>>>>> If you can isolate a reproducible crash into a small test case, I can
>>>>>>>>>>> also
>>>>>>>>>>
>>>>>>>>>>> take a look at it.
>>>>>>>>>>>>
>>>>>>>>>>>> Andi..
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> WIth best regards
>>>>>>>>>>>>> /Petrus
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 15 Dec 2013, at 2:40 , Andi Vajda <va...@apache.org> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Dec 14, 2013, at 19:14, Petrus Hyvönen <petrus.hyvonen@gmail.com
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm having a problem with I think might be related to generic types,
>>>>>>>>>>>>>> but not sure at all.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm wrapping a orbit calculation library, which has been working
>>>>>>>>>>>>>>> well
>>>>>>>>>>>>>> but in latest version is using generic types and I'm getting some
>>>>>>>>>>> problems.
>>>>>>>>>>
>>>>>>>>>>> The script works when executed in plain python, but fails in ipython
>>>>>>>>>>>> notebook on this last line when executed as a couple of cells.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> What is an 'ipython notebook' ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Andi.,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The section with problem in my script is:
>>>>>>>>>>>>>>> elDetector =
>>>>>>>>>>>>>> ElevationDetector(sta1Frame).withConstantElevation(math.
>>>>>>>>>>>> radians(5.0))
>>>>>>>>>>>>
>>>>>>>>>>>>> elDetector =
>>>>>>>>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In Java it would typically look something like:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ElevationDetector detector = new ElevationDetector(topo)
>>>>>>>>>>>>>>> .withConstantElevation(x)
>>>>>>>>>>>>>>> .withHandler(new
>>>>>>>>>>>>>> ContinueOnEvent<ElevationDetector>());
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It produces correct results in plain python, but crashes the kernel
>>>>>>>>>>>>>> in
>>>>>>>>>>
>>>>>>>>>>> ipython if executed as cells, and in exection from spyder I get an error
>>>>>>>>>>>> message:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> " elDetector =
>>>>>>>>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>>>>>>>
>>>>>>>>>>>>> AttributeError: 'str' object has no attribute 'wrapfn_' "
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As I have been using this setup stabely with lots of other functions
>>>>>>>>>>>>>> it feels like there is something with the generic type line, but I
>>>>>>>>>>>> don't
>>>>>>>>>>>> really know how to get any further? I'm confused by that the pauses in
>>>>>>>>>>> the
>>>>>>>>>>
>>>>>>>>>>> execution could seem to affect the result.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any comments highly appriciated...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best Regards
>>>>>>>>>>>>>>> /Petrus
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> _____________________________________________
>>>>>>>>>>> Petrus Hyvönen, Uppsala, Sweden
>>>>>>>>>>> Mobile Phone/SMS:+46 73 803 19 00
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> _____________________________________________
>>>>>>>>> Petrus Hyvönen, Uppsala, Sweden
>>>>>>>>> Mobile Phone/SMS:+46 73 803 19 00
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> _____________________________________________
>>>>>>> Petrus Hyvönen, Uppsala, Sweden
>>>>>>> Mobile Phone/SMS:+46 73 803 19 00
>
Re: Problem using generic types?
Posted by Petrus Hyvönen <pe...@gmail.com>.
Hi,
It's part of a class "PointVectorValuePair" and "PointValuePair" in the apache math commons (http://commons.apache.org/proper/commons-math/javadocs/api-3.2/org/apache/commons/math3/optimization/PointVectorValuePair.html)
I have tried to reserve a bunch of things like 'Point', 'Value', 'Pair' without any difference. If I go through the __wrap__ file, it looks like this [D object to wrap is a very odd one, the other PY_TYPE wrapping seems to have 'proper' names without special characters. It's the functions PointValuePair and PointVectorValuePair that seems to have this strage class wrapping. I cannot find a class named D. From the API doc's I would guess it's trying to set a double [] type.
extract from __wrap__:
under namespace org {
namespace apache {
namespace commons {
namespace math3 {
namespace optimization {
...
static int t_PointVectorValuePair_init_(t_PointVectorValuePair *self, PyObject *args, PyObject *kwds)
{
switch (PyTuple_GET_SIZE(args)) {
case 2:
{
JArray< jdouble > a0((jobject) NULL);
JArray< jdouble > a1((jobject) NULL);
PointVectorValuePair object((jobject) NULL);
if (!parseArgs(args, "[D[D", &a0, &a1))
{
INT_CALL(object = PointVectorValuePair(a0, a1));
self->object = object;
self->parameters[0] = &::PY_TYPE([D);
self->parameters[1] = &::PY_TYPE([D);
break;
}
Regards
/petrus
= &::PY_TYPE([D);
^
/Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23: note:
expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
^
build/_orekit/__wrap__.cpp:58329:44: error: use of undeclared identifier
'D$$Type'
self->parameters[0] = &::PY_TYPE([D);
^
/Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23: note:
expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
^
<scratch space>:109:1: note: expanded from here
D$$Type
^
build/_orekit/__wrap__.cpp:58329:55: error: expected ']'
self->parameters[0] = &::PY_TYPE([D);
^
build/_orekit/__wrap__.cpp:58329:52: note: to match this '['
self->parameters[0] = &::PY_TYPE([D);
On 02 Feb 2014, at 19:48 , Andi Vajda <va...@apache.org> wrote:
>
>> On Feb 2, 2014, at 10:08, Petrus Hyvönen <pe...@gmail.com> wrote:
>>
>> Hi Andi and Others,
>>
>> The latest trunk jcc works and builds very fine on my windows machine, and happy about the extendend support of generics. But I am experiencing the problem below when building on my mac, using same wrap parameters as on the windows platform. To me it seems like some compiler problem related to macros, but don't know.
>>
>> Does anyone have experience of these failures?
>>
>> Regards
>> /Petrus
>>
>>
>> error: expected unqualified-id
>> self->parameters[0] = &::PY_TYPE([D);
>> ^
>> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23: note:
>> expanded from macro 'PY_TYPE'
>> #define PY_TYPE(name) name##$$Type
>> ^
>> build/_orekit/__wrap__.cpp:2344:44: error: use of undeclared identifier
>> 'D$$Type'
>> self->parameters[0] = &::PY_TYPE([D);
>
> Take a look at the code around line 2344 in that __wrap__.cpp file and figure out what java code this corresponds to. You might be using a classname that's a C macro on some platforms - do you have a class named D for example ?
> If you're hitting such a name conflict, add that name to the --reserved list passed to jcc.
>
> Andi..
>
>> ^
>> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23: note:
>> expanded from macro 'PY_TYPE'
>> #define PY_TYPE(name) name##$$Type
>> ^
>> <scratch space>:73:1: note: expanded from here
>> D$$Type
>> ^
>> build/_orekit/__wrap__.cpp:2344:55: error: expected ']'
>> self->parameters[0] = &::PY_TYPE([D);
>> ^
>> build/_orekit/__wrap__.cpp:2344:52: note: to match this '['
>> self->parameters[0] = &::PY_TYPE([D);
>>
>>
>>
>>> On 14 Jan 2014, at 19:02 , Andi Vajda <va...@apache.org> wrote:
>>>
>>>
>>> Hi Petrus,
>>>
>>>> On Jan 14, 2014, at 4:24, Petrus Hyvönen <pe...@gmail.com> wrote:
>>>>
>>>> Dear Andi,
>>>>
>>>> Many many thanks for looking into this!
>>>>
>>>> I am on travel for a week and do not have the computer with the special case with me to test. I did now however run it on the library that I am wrapping, and there get some errors in the creation of the wrapped module (orekit):
>>>>
>>>> build/_orekit/__wrap__.cpp:86504:89: error: no member named
>>>> 'HarmonicOscillator$Parametric$$Type' in namespace
>>>
>>> I believe I fixed this bug in rev 1557613, header files for classes for inherited fixed parameters were not included as required.
>>>
>>> Andi..
>>>
>>>> 'org::apache::commons::math3::analysis::function'
>>>> ...= &::org::apache::commons::math3::analysis::function::PY_TYPE(HarmonicOs...
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
>>>> /Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23: note:
>>>> expanded from macro 'PY_TYPE'
>>>> #define PY_TYPE(name) name##$$Type
>>>> ^
>>>> <scratch space>:63:1: note: expanded from here
>>>> HarmonicOscillator$Parametric$$Type
>>>> ^
>>>> build/_orekit/__wrap__.cpp:217752:55: error: no member named
>>>> 'OrekitMessages$$Type' in namespace 'org::orekit::errors'
>>>> self->parameters[0] = &::org::orekit::errors::PY_TYPE(OrekitMessages);
>>>> ~~~~~~~~~~~~~~~~~~~~~~~^
>>>> /Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23: note:
>>>> expanded from macro 'PY_TYPE'
>>>> #define PY_TYPE(name) name##$$Type
>>>> ^
>>>> <scratch space>:9:1: note: expanded from here
>>>> OrekitMessages$$Type
>>>> ^
>>>> 2 errors generated.
>>>> error: command 'gcc' failed with exit status 1
>>>>
>>>>
>>>>
>>>> The OrekitMessages is defined as a "public enum OrekitMessages implements Localizable { ..."
>>>> and the "public class HarmonicOscillator implements UnivariateDifferentiable, DifferentiableUnivariateFunction".
>>>>
>>>> Maybe this says you something, I will try to test more and run my test case in .
>>>>
>>>> Best Regards and again, many thanks again!
>>>> /petrus
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On 11 Jan 2014, at 14:23 , Andi Vajda <va...@apache.org> wrote:
>>>>>
>>>>>
>>>>> Hi Petrus,
>>>>>
>>>>>> On Mon, 30 Dec 2013, Petrus Hyvönen wrote:
>>>>>>
>>>>>> Andi, great to hear that you could reproduce it. I'm very thankful if you
>>>>>> could have a look at it, I've been struggling to understand how the
>>>>>> machinery behind this works, but far from it still..
>>>>>
>>>>> I think I fixed the problem and added an improvement to generics support along the way. Please check out rev 1557423 from jcc's trunk, rebuild your module with it and let me know how it's working for you.
>>>>>
>>>>> The bug had to do with SimpleClass2's wrapper class missing its parameters slot which it should get from its superclass, SimpleClass. When calling a
>>>>> method on SimpleClass from SimpleClass2, the missing parameters in the
>>>>> wrapper's struct would cause memory to get trashed.
>>>>>
>>>>> In addition to fixing the bug, I also improved support for fixed class parameters. Now, if you change SimpleClass's return_null() method to return new Integer(12) instead, when calling it on SimpleClass2, 12 is returned instead of <Object: 12>.
>>>>>
>>>>> Andi..
>>>>>
>>>>> public class SimpleClass<T> { public SimpleClass() { System.out.println("Created SimpleClass"); }
>>>>> public T return_null() {
>>>>> return (T) new Integer(12);
>>>>> }
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>>>
>>>>>> Best Regards
>>>>>> /Petrus
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Mon, Dec 30, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Sun, 29 Dec 2013, Petrus Hyvönen wrote:
>>>>>>>
>>>>>>> I have distilled the library that I have some trouble with and I think I
>>>>>>>> have an example that is failing due to same problem I think. I am not good
>>>>>>>> in java, but have tried to follow the logic from the library I'm wrapping.
>>>>>>>> The function of the example does not make sense in itself.
>>>>>>>>
>>>>>>>> public class SimpleClass<T> {
>>>>>>>> public SimpleClass() {
>>>>>>>> System.out.println("Created SimpleClass");
>>>>>>>> }
>>>>>>>> public T return_null() {
>>>>>>>> return null;
>>>>>>>> }
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> public class SimpleClass2 extends SimpleClass<Integer>{
>>>>>>>>
>>>>>>>> public SimpleClass2(){}
>>>>>>>> public void testInJava(){
>>>>>>>> System.out.println(this.return_null());
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> It seems to me that there is some problem with methods inherited that
>>>>>>>> returns a generic type, failing in wrapType when this is to be wrapped.
>>>>>>>>
>>>>>>>> The python script that fails:
>>>>>>>>
>>>>>>>> a= SimpleClass()
>>>>>>>> print a.return_null()
>>>>>>>>
>>>>>>>> b = SimpleClass2()
>>>>>>>> b.testInJava()
>>>>>>>>
>>>>>>>> print b.return_null() #Fails in wrapType
>>>>>>>>
>>>>>>>> I don't know if the return null is a bad thing to do in java, but the
>>>>>>>> error
>>>>>>>> seems very similar to what I experience in the larger library. I have a
>>>>>>>> skeleton of that this is slightly larger, but not returning null, but
>>>>>>>> trying to keep the lenght of example low :)
>>>>>>>>
>>>>>>>> Any comments highly appriciated :)
>>>>>>>
>>>>>>> I've been able to reproduce the problem.
>>>>>>> Thank you for providing an isolated test case !
>>>>>>>
>>>>>>> Andi..
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> best Regards
>>>>>>>> /Petrus
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Dec 27, 2013 at 6:25 PM, Andi Vajda <va...@apache.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Dec 27, 2013, at 17:36, Petrus Hyvönen <pe...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Dear Andi,
>>>>>>>>>>
>>>>>>>>>> I am working on debugging the failure and try to understand a bit how
>>>>>>>>>> JCC
>>>>>>>>>> works internally. I haven't gone very far but in case you have some
>>>>>>>>>> pointers from these early debugging sessions I would be very thankful. I
>>>>>>>>>> know it's complex, and I should try to make some smaller test cases, but
>>>>>>>>> I
>>>>>>>>>
>>>>>>>>>> don't really have a grasp yet where the problem might be.
>>>>>>>>>>
>>>>>>>>>> Writing this might help me also to get some structure in my thinking :)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The main crash seems to be in the last line, wrapType(), of
>>>>>>>>>> __wrap__.cpp:
>>>>>>>>>>
>>>>>>>>>> static PyObject
>>>>>>>>>>
>>>>>>>>>> *t_AbstractReconfigurableDetector_withHandler(t_
>>>>>>>>> AbstractReconfigurableDetector
>>>>>>>>>
>>>>>>>>>> *self, PyObject *arg)
>>>>>>>>>> {
>>>>>>>>>> ::org::orekit::propagation::events::handlers::EventHandler
>>>>>>>>>> a0((jobject) NULL);
>>>>>>>>>> PyTypeObject **p0;
>>>>>>>>>> ::org::orekit::propagation::events::EventDetector
>>>>>>>>>> result((jobject) NULL);
>>>>>>>>>>
>>>>>>>>>> if (!parseArg(arg, "K",
>>>>>>>>>>
>>>>>>>>>> ::org::orekit::propagation::events::handlers::
>>>>>>>>> EventHandler::initializeClass,
>>>>>>>>>
>>>>>>>>>> &a0, &p0,
>>>>>>>>>>
>>>>>>>>>> ::org::orekit::propagation::events::handlers::t_
>>>>>>>>> EventHandler::parameters_))
>>>>>>>>>
>>>>>>>>>> {
>>>>>>>>>> OBJ_CALL(result = self->object.withHandler(a0));
>>>>>>>>>> return self->parameters[0] != NULL ?
>>>>>>>>>> wrapType(self->parameters[0], result.this$) :
>>>>>>>>>> ::org::orekit::propagation::events::t_EventDetector::wrap_
>>>>>>>>>> Object(result);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> The parameters[0] does not seem to be null, but neither is it a valid
>>>>>>>>>> object, in my debugger it says 0xbaadf00d {ob_refcnt=??? ob_type=???
>>>>>>>>>> ob_size=??? ...} _typeobject *, wrapType is called and when trying
>>>>>>>>>> to
>>>>>>>>>> access the wrapfn it crashes.
>>>>>>>>>>
>>>>>>>>>> The main python lines are:
>>>>>>>>>> tmp1 = ElevationDetector(sta1Frame) #
>>>>>>>>> ElevationDetector
>>>>>>>>>
>>>>>>>>>> is a java public class ElevationDetector extends
>>>>>>>>>> AbstractReconfigurableDetector<ElevationDetector>
>>>>>>>>>> hand = ContinueOnEvent().of_(ElevationDetector) # a
>>>>>>>>>> java ContinueOnEvent<ElevationDetector> object
>>>>>>>>>> elDetector = tmp1.withHandler(hand) #Crash. withHandler is a method
>>>>>>>>>> that is inherited from AbstractReconfigurableDetector to
>>>>>>>>> ElevationDetector
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This crashes when interactively entered on the python prompt (or in
>>>>>>>>>> other
>>>>>>>>>> interactive consoles), but seems to work if executed directly without
>>>>>>>>>> interactivity. This difference makes me think that it might be something
>>>>>>>>>> with garbage collection, but don't know.
>>>>>>>>>>
>>>>>>>>>> Any comments appriciated, I know this is likely very difficult to
>>>>>>>>>> comment
>>>>>>>>>> on as it's not very encapsulated.
>>>>>>>>>
>>>>>>>>> Right, so unless you can isolate this into something I can reproduce, I'm
>>>>>>>>> afraid there isn't much I can comment.
>>>>>>>>> It is quite likely that by the time you have that reproducible test case
>>>>>>>>> ready, you also have the solution to the problem. Or I might be able to
>>>>>>>>> help then...
>>>>>>>>>
>>>>>>>>> Andi..
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> /Petrus
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Sun, Dec 15, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Dec 15, 2013, at 5:43, Petrus Hyvönen <pe...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Andi,
>>>>>>>>>>>>
>>>>>>>>>>>> I see your point and have now kept in the pure python domain.
>>>>>>>>>>>>
>>>>>>>>>>>> If I run my script from the shell by "python script.py" it does not
>>>>>>>>>>> crash. However if I execute it line-by-line in python it crashes (or in
>>>>>>>>>>> other tools such as ipython notebook).
>>>>>>>>>>>
>>>>>>>>>>>> All classes used are non-wrapped java classes, but I get the same
>>>>>>>>>>> effect
>>>>>>>>>
>>>>>>>>>> with classes made for python subclassing.
>>>>>>>>>>>
>>>>>>>>>>>> I am getting this on both MacOSX 64-bit python and Windows 7 32-bit
>>>>>>>>>>> python.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> elDetector =
>>>>>>>>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>>>>>>
>>>>>>>>>>>> #
>>>>>>>>>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>>>>>>>>>> #
>>>>>>>>>>>> # SIGSEGV (0xb) at pc=0x000000010005da1a, pid=3318, tid=1287
>>>>>>>>>>>> #
>>>>>>>>>>>> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
>>>>>>>>>>> 1.7.0_45-b18)
>>>>>>>>>>>
>>>>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
>>>>>>>>>>> bsd-amd64 compressed oops)
>>>>>>>>>>>
>>>>>>>>>>>> # Problematic frame:
>>>>>>>>>>>> # C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>>>>>>>>>>> #
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> from the stack it seems like there is somthing happening in "wrapType"
>>>>>>>>>>>> Stack: [0x00007fff5fb80000,0x00007fff5fc00000],
>>>>>>>>>>>> sp=0x00007fff5fbff470,
>>>>>>>>>>> free space=509k
>>>>>>>>>>>
>>>>>>>>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>>>>>>>>>> C=native code)
>>>>>>>>>>>
>>>>>>>>>>>> C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>>>>>>>>>>> C [_orekit.so+0xa80878] wrapType(_typeobject*, _jobject*
>>>>>>>>>>>> const&)+0x58
>>>>>>>>>>>> C [_orekit.so+0x554400]
>>>>>>>>>>>
>>>>>>>>>>> org::orekit::propagation::events::t_AbstractReconfigurableDetector
>>>>>>>>> _withHandler(org::orekit::propagation::events::t_
>>>>>>>>> AbstractReconfigurableDetector*,
>>>>>>>>>
>>>>>>>>>> _object*)+0x1c0
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> First, is the generic class assignment correct as if to write "new
>>>>>>>>>>> ContinueOnEvent<ElevationDetector>()" in java? And is it ok to use
>>>>>>>>>> regular
>>>>>>>>>
>>>>>>>>>> java objects/types?
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Any other comments to move forward highly appriciated.. Is it somehow
>>>>>>>>>>> possible to get more log what is going wrong?
>>>>>>>>>>>
>>>>>>>>>>> You could compile the whole thing for debugging, by adding --debug
>>>>>>>>>>> after
>>>>>>>>>>> 'build' in the jcc invocation and run it with gdb.
>>>>>>>>>>>
>>>>>>>>>>> If you can isolate a reproducible crash into a small test case, I can
>>>>>>>>>> also
>>>>>>>>>
>>>>>>>>>> take a look at it.
>>>>>>>>>>>
>>>>>>>>>>> Andi..
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> WIth best regards
>>>>>>>>>>>> /Petrus
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On 15 Dec 2013, at 2:40 , Andi Vajda <va...@apache.org> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Dec 14, 2013, at 19:14, Petrus Hyvönen <petrus.hyvonen@gmail.com
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm having a problem with I think might be related to generic types,
>>>>>>>>>>>>> but not sure at all.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm wrapping a orbit calculation library, which has been working
>>>>>>>>>>>>>> well
>>>>>>>>>>>>> but in latest version is using generic types and I'm getting some
>>>>>>>>>> problems.
>>>>>>>>>
>>>>>>>>>> The script works when executed in plain python, but fails in ipython
>>>>>>>>>>> notebook on this last line when executed as a couple of cells.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> What is an 'ipython notebook' ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Andi.,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> The section with problem in my script is:
>>>>>>>>>>>>>> elDetector =
>>>>>>>>>>>>> ElevationDetector(sta1Frame).withConstantElevation(math.
>>>>>>>>>>> radians(5.0))
>>>>>>>>>>>
>>>>>>>>>>>> elDetector =
>>>>>>>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> In Java it would typically look something like:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ElevationDetector detector = new ElevationDetector(topo)
>>>>>>>>>>>>>> .withConstantElevation(x)
>>>>>>>>>>>>>> .withHandler(new
>>>>>>>>>>>>> ContinueOnEvent<ElevationDetector>());
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> It produces correct results in plain python, but crashes the kernel
>>>>>>>>>>>>> in
>>>>>>>>>
>>>>>>>>>> ipython if executed as cells, and in exection from spyder I get an error
>>>>>>>>>>> message:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> " elDetector =
>>>>>>>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>>>>>>
>>>>>>>>>>>> AttributeError: 'str' object has no attribute 'wrapfn_' "
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As I have been using this setup stabely with lots of other functions
>>>>>>>>>>>>> it feels like there is something with the generic type line, but I
>>>>>>>>>>> don't
>>>>>>>>>>> really know how to get any further? I'm confused by that the pauses in
>>>>>>>>>> the
>>>>>>>>>
>>>>>>>>>> execution could seem to affect the result.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> Any comments highly appriciated...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best Regards
>>>>>>>>>>>>>> /Petrus
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> _____________________________________________
>>>>>>>>>> Petrus Hyvönen, Uppsala, Sweden
>>>>>>>>>> Mobile Phone/SMS:+46 73 803 19 00
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> _____________________________________________
>>>>>>>> Petrus Hyvönen, Uppsala, Sweden
>>>>>>>> Mobile Phone/SMS:+46 73 803 19 00
>>>>>>
>>>>>>
>>>>>> --
>>>>>> _____________________________________________
>>>>>> Petrus Hyvönen, Uppsala, Sweden
>>>>>> Mobile Phone/SMS:+46 73 803 19 00
>>
Re: Problem using generic types?
Posted by Andi Vajda <va...@apache.org>.
> On Feb 2, 2014, at 10:08, Petrus Hyvönen <pe...@gmail.com> wrote:
>
> Hi Andi and Others,
>
> The latest trunk jcc works and builds very fine on my windows machine, and happy about the extendend support of generics. But I am experiencing the problem below when building on my mac, using same wrap parameters as on the windows platform. To me it seems like some compiler problem related to macros, but don't know.
>
> Does anyone have experience of these failures?
>
> Regards
> /Petrus
>
>
> error: expected unqualified-id
> self->parameters[0] = &::PY_TYPE([D);
> ^
> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23: note:
> expanded from macro 'PY_TYPE'
> #define PY_TYPE(name) name##$$Type
> ^
> build/_orekit/__wrap__.cpp:2344:44: error: use of undeclared identifier
> 'D$$Type'
> self->parameters[0] = &::PY_TYPE([D);
Take a look at the code around line 2344 in that __wrap__.cpp file and figure out what java code this corresponds to. You might be using a classname that's a C macro on some platforms - do you have a class named D for example ?
If you're hitting such a name conflict, add that name to the --reserved list passed to jcc.
Andi..
> ^
> /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23: note:
> expanded from macro 'PY_TYPE'
> #define PY_TYPE(name) name##$$Type
> ^
> <scratch space>:73:1: note: expanded from here
> D$$Type
> ^
> build/_orekit/__wrap__.cpp:2344:55: error: expected ']'
> self->parameters[0] = &::PY_TYPE([D);
> ^
> build/_orekit/__wrap__.cpp:2344:52: note: to match this '['
> self->parameters[0] = &::PY_TYPE([D);
>
>
>
>> On 14 Jan 2014, at 19:02 , Andi Vajda <va...@apache.org> wrote:
>>
>>
>> Hi Petrus,
>>
>>> On Jan 14, 2014, at 4:24, Petrus Hyvönen <pe...@gmail.com> wrote:
>>>
>>> Dear Andi,
>>>
>>> Many many thanks for looking into this!
>>>
>>> I am on travel for a week and do not have the computer with the special case with me to test. I did now however run it on the library that I am wrapping, and there get some errors in the creation of the wrapped module (orekit):
>>>
>>> build/_orekit/__wrap__.cpp:86504:89: error: no member named
>>> 'HarmonicOscillator$Parametric$$Type' in namespace
>>
>> I believe I fixed this bug in rev 1557613, header files for classes for inherited fixed parameters were not included as required.
>>
>> Andi..
>>
>>> 'org::apache::commons::math3::analysis::function'
>>> ...= &::org::apache::commons::math3::analysis::function::PY_TYPE(HarmonicOs...
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
>>> /Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23: note:
>>> expanded from macro 'PY_TYPE'
>>> #define PY_TYPE(name) name##$$Type
>>> ^
>>> <scratch space>:63:1: note: expanded from here
>>> HarmonicOscillator$Parametric$$Type
>>> ^
>>> build/_orekit/__wrap__.cpp:217752:55: error: no member named
>>> 'OrekitMessages$$Type' in namespace 'org::orekit::errors'
>>> self->parameters[0] = &::org::orekit::errors::PY_TYPE(OrekitMessages);
>>> ~~~~~~~~~~~~~~~~~~~~~~~^
>>> /Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23: note:
>>> expanded from macro 'PY_TYPE'
>>> #define PY_TYPE(name) name##$$Type
>>> ^
>>> <scratch space>:9:1: note: expanded from here
>>> OrekitMessages$$Type
>>> ^
>>> 2 errors generated.
>>> error: command 'gcc' failed with exit status 1
>>>
>>>
>>>
>>> The OrekitMessages is defined as a "public enum OrekitMessages implements Localizable { ..."
>>> and the "public class HarmonicOscillator implements UnivariateDifferentiable, DifferentiableUnivariateFunction".
>>>
>>> Maybe this says you something, I will try to test more and run my test case in .
>>>
>>> Best Regards and again, many thanks again!
>>> /petrus
>>>
>>>
>>>
>>>
>>>
>>>> On 11 Jan 2014, at 14:23 , Andi Vajda <va...@apache.org> wrote:
>>>>
>>>>
>>>> Hi Petrus,
>>>>
>>>>> On Mon, 30 Dec 2013, Petrus Hyvönen wrote:
>>>>>
>>>>> Andi, great to hear that you could reproduce it. I'm very thankful if you
>>>>> could have a look at it, I've been struggling to understand how the
>>>>> machinery behind this works, but far from it still..
>>>>
>>>> I think I fixed the problem and added an improvement to generics support along the way. Please check out rev 1557423 from jcc's trunk, rebuild your module with it and let me know how it's working for you.
>>>>
>>>> The bug had to do with SimpleClass2's wrapper class missing its parameters slot which it should get from its superclass, SimpleClass. When calling a
>>>> method on SimpleClass from SimpleClass2, the missing parameters in the
>>>> wrapper's struct would cause memory to get trashed.
>>>>
>>>> In addition to fixing the bug, I also improved support for fixed class parameters. Now, if you change SimpleClass's return_null() method to return new Integer(12) instead, when calling it on SimpleClass2, 12 is returned instead of <Object: 12>.
>>>>
>>>> Andi..
>>>>
>>>> public class SimpleClass<T> { public SimpleClass() { System.out.println("Created SimpleClass"); }
>>>> public T return_null() {
>>>> return (T) new Integer(12);
>>>> }
>>>>
>>>> }
>>>>
>>>>
>>>>>
>>>>> Best Regards
>>>>> /Petrus
>>>>>
>>>>>
>>>>>
>>>>>> On Mon, Dec 30, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>>>>>>
>>>>>>
>>>>>> On Sun, 29 Dec 2013, Petrus Hyvönen wrote:
>>>>>>
>>>>>> I have distilled the library that I have some trouble with and I think I
>>>>>>> have an example that is failing due to same problem I think. I am not good
>>>>>>> in java, but have tried to follow the logic from the library I'm wrapping.
>>>>>>> The function of the example does not make sense in itself.
>>>>>>>
>>>>>>> public class SimpleClass<T> {
>>>>>>> public SimpleClass() {
>>>>>>> System.out.println("Created SimpleClass");
>>>>>>> }
>>>>>>> public T return_null() {
>>>>>>> return null;
>>>>>>> }
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> public class SimpleClass2 extends SimpleClass<Integer>{
>>>>>>>
>>>>>>> public SimpleClass2(){}
>>>>>>> public void testInJava(){
>>>>>>> System.out.println(this.return_null());
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> It seems to me that there is some problem with methods inherited that
>>>>>>> returns a generic type, failing in wrapType when this is to be wrapped.
>>>>>>>
>>>>>>> The python script that fails:
>>>>>>>
>>>>>>> a= SimpleClass()
>>>>>>> print a.return_null()
>>>>>>>
>>>>>>> b = SimpleClass2()
>>>>>>> b.testInJava()
>>>>>>>
>>>>>>> print b.return_null() #Fails in wrapType
>>>>>>>
>>>>>>> I don't know if the return null is a bad thing to do in java, but the
>>>>>>> error
>>>>>>> seems very similar to what I experience in the larger library. I have a
>>>>>>> skeleton of that this is slightly larger, but not returning null, but
>>>>>>> trying to keep the lenght of example low :)
>>>>>>>
>>>>>>> Any comments highly appriciated :)
>>>>>>
>>>>>> I've been able to reproduce the problem.
>>>>>> Thank you for providing an isolated test case !
>>>>>>
>>>>>> Andi..
>>>>>>
>>>>>>
>>>>>>
>>>>>>> best Regards
>>>>>>> /Petrus
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Dec 27, 2013 at 6:25 PM, Andi Vajda <va...@apache.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On Dec 27, 2013, at 17:36, Petrus Hyvönen <pe...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Dear Andi,
>>>>>>>>>
>>>>>>>>> I am working on debugging the failure and try to understand a bit how
>>>>>>>>> JCC
>>>>>>>>> works internally. I haven't gone very far but in case you have some
>>>>>>>>> pointers from these early debugging sessions I would be very thankful. I
>>>>>>>>> know it's complex, and I should try to make some smaller test cases, but
>>>>>>>> I
>>>>>>>>
>>>>>>>>> don't really have a grasp yet where the problem might be.
>>>>>>>>>
>>>>>>>>> Writing this might help me also to get some structure in my thinking :)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The main crash seems to be in the last line, wrapType(), of
>>>>>>>>> __wrap__.cpp:
>>>>>>>>>
>>>>>>>>> static PyObject
>>>>>>>>>
>>>>>>>>> *t_AbstractReconfigurableDetector_withHandler(t_
>>>>>>>> AbstractReconfigurableDetector
>>>>>>>>
>>>>>>>>> *self, PyObject *arg)
>>>>>>>>> {
>>>>>>>>> ::org::orekit::propagation::events::handlers::EventHandler
>>>>>>>>> a0((jobject) NULL);
>>>>>>>>> PyTypeObject **p0;
>>>>>>>>> ::org::orekit::propagation::events::EventDetector
>>>>>>>>> result((jobject) NULL);
>>>>>>>>>
>>>>>>>>> if (!parseArg(arg, "K",
>>>>>>>>>
>>>>>>>>> ::org::orekit::propagation::events::handlers::
>>>>>>>> EventHandler::initializeClass,
>>>>>>>>
>>>>>>>>> &a0, &p0,
>>>>>>>>>
>>>>>>>>> ::org::orekit::propagation::events::handlers::t_
>>>>>>>> EventHandler::parameters_))
>>>>>>>>
>>>>>>>>> {
>>>>>>>>> OBJ_CALL(result = self->object.withHandler(a0));
>>>>>>>>> return self->parameters[0] != NULL ?
>>>>>>>>> wrapType(self->parameters[0], result.this$) :
>>>>>>>>> ::org::orekit::propagation::events::t_EventDetector::wrap_
>>>>>>>>> Object(result);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> The parameters[0] does not seem to be null, but neither is it a valid
>>>>>>>>> object, in my debugger it says 0xbaadf00d {ob_refcnt=??? ob_type=???
>>>>>>>>> ob_size=??? ...} _typeobject *, wrapType is called and when trying
>>>>>>>>> to
>>>>>>>>> access the wrapfn it crashes.
>>>>>>>>>
>>>>>>>>> The main python lines are:
>>>>>>>>> tmp1 = ElevationDetector(sta1Frame) #
>>>>>>>> ElevationDetector
>>>>>>>>
>>>>>>>>> is a java public class ElevationDetector extends
>>>>>>>>> AbstractReconfigurableDetector<ElevationDetector>
>>>>>>>>> hand = ContinueOnEvent().of_(ElevationDetector) # a
>>>>>>>>> java ContinueOnEvent<ElevationDetector> object
>>>>>>>>> elDetector = tmp1.withHandler(hand) #Crash. withHandler is a method
>>>>>>>>> that is inherited from AbstractReconfigurableDetector to
>>>>>>>> ElevationDetector
>>>>>>>>
>>>>>>>>>
>>>>>>>>> This crashes when interactively entered on the python prompt (or in
>>>>>>>>> other
>>>>>>>>> interactive consoles), but seems to work if executed directly without
>>>>>>>>> interactivity. This difference makes me think that it might be something
>>>>>>>>> with garbage collection, but don't know.
>>>>>>>>>
>>>>>>>>> Any comments appriciated, I know this is likely very difficult to
>>>>>>>>> comment
>>>>>>>>> on as it's not very encapsulated.
>>>>>>>>
>>>>>>>> Right, so unless you can isolate this into something I can reproduce, I'm
>>>>>>>> afraid there isn't much I can comment.
>>>>>>>> It is quite likely that by the time you have that reproducible test case
>>>>>>>> ready, you also have the solution to the problem. Or I might be able to
>>>>>>>> help then...
>>>>>>>>
>>>>>>>> Andi..
>>>>>>>>
>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> /Petrus
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Sun, Dec 15, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Dec 15, 2013, at 5:43, Petrus Hyvönen <pe...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Andi,
>>>>>>>>>>>
>>>>>>>>>>> I see your point and have now kept in the pure python domain.
>>>>>>>>>>>
>>>>>>>>>>> If I run my script from the shell by "python script.py" it does not
>>>>>>>>>> crash. However if I execute it line-by-line in python it crashes (or in
>>>>>>>>>> other tools such as ipython notebook).
>>>>>>>>>>
>>>>>>>>>>> All classes used are non-wrapped java classes, but I get the same
>>>>>>>>>> effect
>>>>>>>>
>>>>>>>>> with classes made for python subclassing.
>>>>>>>>>>
>>>>>>>>>>> I am getting this on both MacOSX 64-bit python and Windows 7 32-bit
>>>>>>>>>> python.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> elDetector =
>>>>>>>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>>>>>
>>>>>>>>>>> #
>>>>>>>>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>>>>>>>>> #
>>>>>>>>>>> # SIGSEGV (0xb) at pc=0x000000010005da1a, pid=3318, tid=1287
>>>>>>>>>>> #
>>>>>>>>>>> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
>>>>>>>>>> 1.7.0_45-b18)
>>>>>>>>>>
>>>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
>>>>>>>>>> bsd-amd64 compressed oops)
>>>>>>>>>>
>>>>>>>>>>> # Problematic frame:
>>>>>>>>>>> # C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>>>>>>>>>> #
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> from the stack it seems like there is somthing happening in "wrapType"
>>>>>>>>>>> Stack: [0x00007fff5fb80000,0x00007fff5fc00000],
>>>>>>>>>>> sp=0x00007fff5fbff470,
>>>>>>>>>> free space=509k
>>>>>>>>>>
>>>>>>>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>>>>>>>>> C=native code)
>>>>>>>>>>
>>>>>>>>>>> C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>>>>>>>>>> C [_orekit.so+0xa80878] wrapType(_typeobject*, _jobject*
>>>>>>>>>>> const&)+0x58
>>>>>>>>>>> C [_orekit.so+0x554400]
>>>>>>>>>>
>>>>>>>>>> org::orekit::propagation::events::t_AbstractReconfigurableDetector
>>>>>>>> _withHandler(org::orekit::propagation::events::t_
>>>>>>>> AbstractReconfigurableDetector*,
>>>>>>>>
>>>>>>>>> _object*)+0x1c0
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> First, is the generic class assignment correct as if to write "new
>>>>>>>>>> ContinueOnEvent<ElevationDetector>()" in java? And is it ok to use
>>>>>>>>> regular
>>>>>>>>
>>>>>>>>> java objects/types?
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Any other comments to move forward highly appriciated.. Is it somehow
>>>>>>>>>> possible to get more log what is going wrong?
>>>>>>>>>>
>>>>>>>>>> You could compile the whole thing for debugging, by adding --debug
>>>>>>>>>> after
>>>>>>>>>> 'build' in the jcc invocation and run it with gdb.
>>>>>>>>>>
>>>>>>>>>> If you can isolate a reproducible crash into a small test case, I can
>>>>>>>>> also
>>>>>>>>
>>>>>>>>> take a look at it.
>>>>>>>>>>
>>>>>>>>>> Andi..
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> WIth best regards
>>>>>>>>>>> /Petrus
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On 15 Dec 2013, at 2:40 , Andi Vajda <va...@apache.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Dec 14, 2013, at 19:14, Petrus Hyvönen <petrus.hyvonen@gmail.com
>>>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm having a problem with I think might be related to generic types,
>>>>>>>>>>>> but not sure at all.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> I'm wrapping a orbit calculation library, which has been working
>>>>>>>>>>>>> well
>>>>>>>>>>>> but in latest version is using generic types and I'm getting some
>>>>>>>>> problems.
>>>>>>>>
>>>>>>>>> The script works when executed in plain python, but fails in ipython
>>>>>>>>>> notebook on this last line when executed as a couple of cells.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> What is an 'ipython notebook' ?
>>>>>>>>>>>>
>>>>>>>>>>>> Andi.,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> The section with problem in my script is:
>>>>>>>>>>>>> elDetector =
>>>>>>>>>>>> ElevationDetector(sta1Frame).withConstantElevation(math.
>>>>>>>>>> radians(5.0))
>>>>>>>>>>
>>>>>>>>>>> elDetector =
>>>>>>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> In Java it would typically look something like:
>>>>>>>>>>>>>
>>>>>>>>>>>>> ElevationDetector detector = new ElevationDetector(topo)
>>>>>>>>>>>>> .withConstantElevation(x)
>>>>>>>>>>>>> .withHandler(new
>>>>>>>>>>>> ContinueOnEvent<ElevationDetector>());
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> It produces correct results in plain python, but crashes the kernel
>>>>>>>>>>>> in
>>>>>>>>
>>>>>>>>> ipython if executed as cells, and in exection from spyder I get an error
>>>>>>>>>> message:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> " elDetector =
>>>>>>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>>>>>
>>>>>>>>>>> AttributeError: 'str' object has no attribute 'wrapfn_' "
>>>>>>>>>>>>>
>>>>>>>>>>>>> As I have been using this setup stabely with lots of other functions
>>>>>>>>>>>> it feels like there is something with the generic type line, but I
>>>>>>>>>> don't
>>>>>>>>>> really know how to get any further? I'm confused by that the pauses in
>>>>>>>>> the
>>>>>>>>
>>>>>>>>> execution could seem to affect the result.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> Any comments highly appriciated...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best Regards
>>>>>>>>>>>>> /Petrus
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> _____________________________________________
>>>>>>>>> Petrus Hyvönen, Uppsala, Sweden
>>>>>>>>> Mobile Phone/SMS:+46 73 803 19 00
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> _____________________________________________
>>>>>>> Petrus Hyvönen, Uppsala, Sweden
>>>>>>> Mobile Phone/SMS:+46 73 803 19 00
>>>>>
>>>>>
>>>>> --
>>>>> _____________________________________________
>>>>> Petrus Hyvönen, Uppsala, Sweden
>>>>> Mobile Phone/SMS:+46 73 803 19 00
>
Re: Problem using generic types?
Posted by Petrus Hyvönen <pe...@gmail.com>.
Hi Andi and Others,
The latest trunk jcc works and builds very fine on my windows machine, and happy about the extendend support of generics. But I am experiencing the problem below when building on my mac, using same wrap parameters as on the windows platform. To me it seems like some compiler problem related to macros, but don't know.
Does anyone have experience of these failures?
Regards
/Petrus
error: expected unqualified-id
self->parameters[0] = &::PY_TYPE([D);
^
/Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23: note:
expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
^
build/_orekit/__wrap__.cpp:2344:44: error: use of undeclared identifier
'D$$Type'
self->parameters[0] = &::PY_TYPE([D);
^
/Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23: note:
expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
^
<scratch space>:73:1: note: expanded from here
D$$Type
^
build/_orekit/__wrap__.cpp:2344:55: error: expected ']'
self->parameters[0] = &::PY_TYPE([D);
^
build/_orekit/__wrap__.cpp:2344:52: note: to match this '['
self->parameters[0] = &::PY_TYPE([D);
On 14 Jan 2014, at 19:02 , Andi Vajda <va...@apache.org> wrote:
>
> Hi Petrus,
>
> On Jan 14, 2014, at 4:24, Petrus Hyvönen <pe...@gmail.com> wrote:
>
>> Dear Andi,
>>
>> Many many thanks for looking into this!
>>
>> I am on travel for a week and do not have the computer with the special case with me to test. I did now however run it on the library that I am wrapping, and there get some errors in the creation of the wrapped module (orekit):
>>
>> build/_orekit/__wrap__.cpp:86504:89: error: no member named
>> 'HarmonicOscillator$Parametric$$Type' in namespace
>
> I believe I fixed this bug in rev 1557613, header files for classes for inherited fixed parameters were not included as required.
>
> Andi..
>
>> 'org::apache::commons::math3::analysis::function'
>> ...= &::org::apache::commons::math3::analysis::function::PY_TYPE(HarmonicOs...
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
>> /Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23: note:
>> expanded from macro 'PY_TYPE'
>> #define PY_TYPE(name) name##$$Type
>> ^
>> <scratch space>:63:1: note: expanded from here
>> HarmonicOscillator$Parametric$$Type
>> ^
>> build/_orekit/__wrap__.cpp:217752:55: error: no member named
>> 'OrekitMessages$$Type' in namespace 'org::orekit::errors'
>> self->parameters[0] = &::org::orekit::errors::PY_TYPE(OrekitMessages);
>> ~~~~~~~~~~~~~~~~~~~~~~~^
>> /Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23: note:
>> expanded from macro 'PY_TYPE'
>> #define PY_TYPE(name) name##$$Type
>> ^
>> <scratch space>:9:1: note: expanded from here
>> OrekitMessages$$Type
>> ^
>> 2 errors generated.
>> error: command 'gcc' failed with exit status 1
>>
>>
>>
>> The OrekitMessages is defined as a "public enum OrekitMessages implements Localizable { ..."
>> and the "public class HarmonicOscillator implements UnivariateDifferentiable, DifferentiableUnivariateFunction".
>>
>> Maybe this says you something, I will try to test more and run my test case in .
>>
>> Best Regards and again, many thanks again!
>> /petrus
>>
>>
>>
>>
>>
>> On 11 Jan 2014, at 14:23 , Andi Vajda <va...@apache.org> wrote:
>>
>>>
>>> Hi Petrus,
>>>
>>> On Mon, 30 Dec 2013, Petrus Hyvönen wrote:
>>>
>>>> Andi, great to hear that you could reproduce it. I'm very thankful if you
>>>> could have a look at it, I've been struggling to understand how the
>>>> machinery behind this works, but far from it still..
>>>
>>> I think I fixed the problem and added an improvement to generics support along the way. Please check out rev 1557423 from jcc's trunk, rebuild your module with it and let me know how it's working for you.
>>>
>>> The bug had to do with SimpleClass2's wrapper class missing its parameters slot which it should get from its superclass, SimpleClass. When calling a
>>> method on SimpleClass from SimpleClass2, the missing parameters in the
>>> wrapper's struct would cause memory to get trashed.
>>>
>>> In addition to fixing the bug, I also improved support for fixed class parameters. Now, if you change SimpleClass's return_null() method to return new Integer(12) instead, when calling it on SimpleClass2, 12 is returned instead of <Object: 12>.
>>>
>>> Andi..
>>>
>>> public class SimpleClass<T> { public SimpleClass() { System.out.println("Created SimpleClass"); }
>>> public T return_null() {
>>> return (T) new Integer(12);
>>> }
>>>
>>> }
>>>
>>>
>>>>
>>>> Best Regards
>>>> /Petrus
>>>>
>>>>
>>>>
>>>> On Mon, Dec 30, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>>>>
>>>>>
>>>>> On Sun, 29 Dec 2013, Petrus Hyvönen wrote:
>>>>>
>>>>> I have distilled the library that I have some trouble with and I think I
>>>>>> have an example that is failing due to same problem I think. I am not good
>>>>>> in java, but have tried to follow the logic from the library I'm wrapping.
>>>>>> The function of the example does not make sense in itself.
>>>>>>
>>>>>> public class SimpleClass<T> {
>>>>>> public SimpleClass() {
>>>>>> System.out.println("Created SimpleClass");
>>>>>> }
>>>>>> public T return_null() {
>>>>>> return null;
>>>>>> }
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>> public class SimpleClass2 extends SimpleClass<Integer>{
>>>>>>
>>>>>> public SimpleClass2(){}
>>>>>> public void testInJava(){
>>>>>> System.out.println(this.return_null());
>>>>>> }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> It seems to me that there is some problem with methods inherited that
>>>>>> returns a generic type, failing in wrapType when this is to be wrapped.
>>>>>>
>>>>>> The python script that fails:
>>>>>>
>>>>>> a= SimpleClass()
>>>>>> print a.return_null()
>>>>>>
>>>>>> b = SimpleClass2()
>>>>>> b.testInJava()
>>>>>>
>>>>>> print b.return_null() #Fails in wrapType
>>>>>>
>>>>>> I don't know if the return null is a bad thing to do in java, but the
>>>>>> error
>>>>>> seems very similar to what I experience in the larger library. I have a
>>>>>> skeleton of that this is slightly larger, but not returning null, but
>>>>>> trying to keep the lenght of example low :)
>>>>>>
>>>>>> Any comments highly appriciated :)
>>>>>>
>>>>>
>>>>> I've been able to reproduce the problem.
>>>>> Thank you for providing an isolated test case !
>>>>>
>>>>> Andi..
>>>>>
>>>>>
>>>>>
>>>>>> best Regards
>>>>>> /Petrus
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Dec 27, 2013 at 6:25 PM, Andi Vajda <va...@apache.org> wrote:
>>>>>>
>>>>>>
>>>>>>> On Dec 27, 2013, at 17:36, Petrus Hyvönen <pe...@gmail.com>
>>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Dear Andi,
>>>>>>>>
>>>>>>>> I am working on debugging the failure and try to understand a bit how
>>>>>>>> JCC
>>>>>>>> works internally. I haven't gone very far but in case you have some
>>>>>>>> pointers from these early debugging sessions I would be very thankful. I
>>>>>>>> know it's complex, and I should try to make some smaller test cases, but
>>>>>>>>
>>>>>>> I
>>>>>>>
>>>>>>>> don't really have a grasp yet where the problem might be.
>>>>>>>>
>>>>>>>> Writing this might help me also to get some structure in my thinking :)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The main crash seems to be in the last line, wrapType(), of
>>>>>>>> __wrap__.cpp:
>>>>>>>>
>>>>>>>> static PyObject
>>>>>>>>
>>>>>>>> *t_AbstractReconfigurableDetector_withHandler(t_
>>>>>>> AbstractReconfigurableDetector
>>>>>>>
>>>>>>>> *self, PyObject *arg)
>>>>>>>> {
>>>>>>>> ::org::orekit::propagation::events::handlers::EventHandler
>>>>>>>> a0((jobject) NULL);
>>>>>>>> PyTypeObject **p0;
>>>>>>>> ::org::orekit::propagation::events::EventDetector
>>>>>>>> result((jobject) NULL);
>>>>>>>>
>>>>>>>> if (!parseArg(arg, "K",
>>>>>>>>
>>>>>>>> ::org::orekit::propagation::events::handlers::
>>>>>>> EventHandler::initializeClass,
>>>>>>>
>>>>>>>> &a0, &p0,
>>>>>>>>
>>>>>>>> ::org::orekit::propagation::events::handlers::t_
>>>>>>> EventHandler::parameters_))
>>>>>>>
>>>>>>>> {
>>>>>>>> OBJ_CALL(result = self->object.withHandler(a0));
>>>>>>>> return self->parameters[0] != NULL ?
>>>>>>>> wrapType(self->parameters[0], result.this$) :
>>>>>>>> ::org::orekit::propagation::events::t_EventDetector::wrap_
>>>>>>>> Object(result);
>>>>>>>> }
>>>>>>>>
>>>>>>>> The parameters[0] does not seem to be null, but neither is it a valid
>>>>>>>> object, in my debugger it says 0xbaadf00d {ob_refcnt=??? ob_type=???
>>>>>>>> ob_size=??? ...} _typeobject *, wrapType is called and when trying
>>>>>>>> to
>>>>>>>> access the wrapfn it crashes.
>>>>>>>>
>>>>>>>> The main python lines are:
>>>>>>>> tmp1 = ElevationDetector(sta1Frame) #
>>>>>>>>
>>>>>>> ElevationDetector
>>>>>>>
>>>>>>>> is a java public class ElevationDetector extends
>>>>>>>> AbstractReconfigurableDetector<ElevationDetector>
>>>>>>>> hand = ContinueOnEvent().of_(ElevationDetector) # a
>>>>>>>> java ContinueOnEvent<ElevationDetector> object
>>>>>>>> elDetector = tmp1.withHandler(hand) #Crash. withHandler is a method
>>>>>>>> that is inherited from AbstractReconfigurableDetector to
>>>>>>>>
>>>>>>> ElevationDetector
>>>>>>>
>>>>>>>>
>>>>>>>> This crashes when interactively entered on the python prompt (or in
>>>>>>>> other
>>>>>>>> interactive consoles), but seems to work if executed directly without
>>>>>>>> interactivity. This difference makes me think that it might be something
>>>>>>>> with garbage collection, but don't know.
>>>>>>>>
>>>>>>>> Any comments appriciated, I know this is likely very difficult to
>>>>>>>> comment
>>>>>>>> on as it's not very encapsulated.
>>>>>>>>
>>>>>>>
>>>>>>> Right, so unless you can isolate this into something I can reproduce, I'm
>>>>>>> afraid there isn't much I can comment.
>>>>>>> It is quite likely that by the time you have that reproducible test case
>>>>>>> ready, you also have the solution to the problem. Or I might be able to
>>>>>>> help then...
>>>>>>>
>>>>>>> Andi..
>>>>>>>
>>>>>>>
>>>>>>>> Regards
>>>>>>>> /Petrus
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Dec 15, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Dec 15, 2013, at 5:43, Petrus Hyvönen <pe...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Andi,
>>>>>>>>>>
>>>>>>>>>> I see your point and have now kept in the pure python domain.
>>>>>>>>>>
>>>>>>>>>> If I run my script from the shell by "python script.py" it does not
>>>>>>>>>>
>>>>>>>>> crash. However if I execute it line-by-line in python it crashes (or in
>>>>>>>>> other tools such as ipython notebook).
>>>>>>>>>
>>>>>>>>>> All classes used are non-wrapped java classes, but I get the same
>>>>>>>>>>
>>>>>>>>> effect
>>>>>>>
>>>>>>>> with classes made for python subclassing.
>>>>>>>>>
>>>>>>>>>> I am getting this on both MacOSX 64-bit python and Windows 7 32-bit
>>>>>>>>>>
>>>>>>>>> python.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> elDetector =
>>>>>>>>>>>>>
>>>>>>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>>>>
>>>>>>>>>> #
>>>>>>>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>>>>>>>> #
>>>>>>>>>> # SIGSEGV (0xb) at pc=0x000000010005da1a, pid=3318, tid=1287
>>>>>>>>>> #
>>>>>>>>>> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
>>>>>>>>>>
>>>>>>>>> 1.7.0_45-b18)
>>>>>>>>>
>>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
>>>>>>>>>>
>>>>>>>>> bsd-amd64 compressed oops)
>>>>>>>>>
>>>>>>>>>> # Problematic frame:
>>>>>>>>>> # C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>>>>>>>>> #
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> from the stack it seems like there is somthing happening in "wrapType"
>>>>>>>>>> Stack: [0x00007fff5fb80000,0x00007fff5fc00000],
>>>>>>>>>> sp=0x00007fff5fbff470,
>>>>>>>>>>
>>>>>>>>> free space=509k
>>>>>>>>>
>>>>>>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>>>>>>>>>
>>>>>>>>> C=native code)
>>>>>>>>>
>>>>>>>>>> C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>>>>>>>>> C [_orekit.so+0xa80878] wrapType(_typeobject*, _jobject*
>>>>>>>>>> const&)+0x58
>>>>>>>>>> C [_orekit.so+0x554400]
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> org::orekit::propagation::events::t_AbstractReconfigurableDetector
>>>>>>> _withHandler(org::orekit::propagation::events::t_
>>>>>>> AbstractReconfigurableDetector*,
>>>>>>>
>>>>>>>> _object*)+0x1c0
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> First, is the generic class assignment correct as if to write "new
>>>>>>>>>>
>>>>>>>>> ContinueOnEvent<ElevationDetector>()" in java? And is it ok to use
>>>>>>>>>
>>>>>>>> regular
>>>>>>>
>>>>>>>> java objects/types?
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Any other comments to move forward highly appriciated.. Is it somehow
>>>>>>>>>>
>>>>>>>>> possible to get more log what is going wrong?
>>>>>>>>>
>>>>>>>>> You could compile the whole thing for debugging, by adding --debug
>>>>>>>>> after
>>>>>>>>> 'build' in the jcc invocation and run it with gdb.
>>>>>>>>>
>>>>>>>>> If you can isolate a reproducible crash into a small test case, I can
>>>>>>>>>
>>>>>>>> also
>>>>>>>
>>>>>>>> take a look at it.
>>>>>>>>>
>>>>>>>>> Andi..
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> WIth best regards
>>>>>>>>>> /Petrus
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 15 Dec 2013, at 2:40 , Andi Vajda <va...@apache.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Dec 14, 2013, at 19:14, Petrus Hyvönen <petrus.hyvonen@gmail.com
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I'm having a problem with I think might be related to generic types,
>>>>>>>>>>>>
>>>>>>>>>>> but not sure at all.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> I'm wrapping a orbit calculation library, which has been working
>>>>>>>>>>>> well
>>>>>>>>>>>>
>>>>>>>>>>> but in latest version is using generic types and I'm getting some
>>>>>>>>>
>>>>>>>> problems.
>>>>>>>
>>>>>>>> The script works when executed in plain python, but fails in ipython
>>>>>>>>> notebook on this last line when executed as a couple of cells.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> What is an 'ipython notebook' ?
>>>>>>>>>>>
>>>>>>>>>>> Andi.,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> The section with problem in my script is:
>>>>>>>>>>>> elDetector =
>>>>>>>>>>>>
>>>>>>>>>>> ElevationDetector(sta1Frame).withConstantElevation(math.
>>>>>>>>> radians(5.0))
>>>>>>>>>
>>>>>>>>>> elDetector =
>>>>>>>>>>>>
>>>>>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> In Java it would typically look something like:
>>>>>>>>>>>>
>>>>>>>>>>>> ElevationDetector detector = new ElevationDetector(topo)
>>>>>>>>>>>> .withConstantElevation(x)
>>>>>>>>>>>> .withHandler(new
>>>>>>>>>>>>
>>>>>>>>>>> ContinueOnEvent<ElevationDetector>());
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> It produces correct results in plain python, but crashes the kernel
>>>>>>>>>>>>
>>>>>>>>>>> in
>>>>>>>
>>>>>>>> ipython if executed as cells, and in exection from spyder I get an error
>>>>>>>>> message:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> " elDetector =
>>>>>>>>>>>>
>>>>>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>>>>
>>>>>>>>>> AttributeError: 'str' object has no attribute 'wrapfn_' "
>>>>>>>>>>>>
>>>>>>>>>>>> As I have been using this setup stabely with lots of other functions
>>>>>>>>>>>>
>>>>>>>>>>> it feels like there is something with the generic type line, but I
>>>>>>>>> don't
>>>>>>>>> really know how to get any further? I'm confused by that the pauses in
>>>>>>>>>
>>>>>>>> the
>>>>>>>
>>>>>>>> execution could seem to affect the result.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> Any comments highly appriciated...
>>>>>>>>>>>>
>>>>>>>>>>>> Best Regards
>>>>>>>>>>>> /Petrus
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> _____________________________________________
>>>>>>>> Petrus Hyvönen, Uppsala, Sweden
>>>>>>>> Mobile Phone/SMS:+46 73 803 19 00
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> _____________________________________________
>>>>>> Petrus Hyvönen, Uppsala, Sweden
>>>>>> Mobile Phone/SMS:+46 73 803 19 00
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> _____________________________________________
>>>> Petrus Hyvönen, Uppsala, Sweden
>>>> Mobile Phone/SMS:+46 73 803 19 00
>>
Re: Problem using generic types?
Posted by Andi Vajda <va...@apache.org>.
On Tue, 14 Jan 2014, Petrus Hyvönen wrote:
> Andy,
>
> It works fine now. Many many thanks.
Sweet !
Andi..
>
> Regards
> /Petrus
>
> On 14 Jan 2014, at 15:02 , Andi Vajda <va...@apache.org> wrote:
>
>>
>> Hi Petrus,
>>
>> On Jan 14, 2014, at 4:24, Petrus Hyvönen <pe...@gmail.com> wrote:
>>
>>> Dear Andi,
>>>
>>> Many many thanks for looking into this!
>>>
>>> I am on travel for a week and do not have the computer with the special case with me to test. I did now however run it on the library that I am wrapping, and there get some errors in the creation of the wrapped module (orekit):
>>>
>>> build/_orekit/__wrap__.cpp:86504:89: error: no member named
>>> 'HarmonicOscillator$Parametric$$Type' in namespace
>>
>> I believe I fixed this bug in rev 1557613, header files for classes for inherited fixed parameters were not included as required.
>>
>> Andi..
>>
>>>
>
>
Re: Problem using generic types?
Posted by Petrus Hyvönen <pe...@gmail.com>.
Andy,
It works fine now. Many many thanks.
Regards
/Petrus
On 14 Jan 2014, at 15:02 , Andi Vajda <va...@apache.org> wrote:
>
> Hi Petrus,
>
> On Jan 14, 2014, at 4:24, Petrus Hyvönen <pe...@gmail.com> wrote:
>
>> Dear Andi,
>>
>> Many many thanks for looking into this!
>>
>> I am on travel for a week and do not have the computer with the special case with me to test. I did now however run it on the library that I am wrapping, and there get some errors in the creation of the wrapped module (orekit):
>>
>> build/_orekit/__wrap__.cpp:86504:89: error: no member named
>> 'HarmonicOscillator$Parametric$$Type' in namespace
>
> I believe I fixed this bug in rev 1557613, header files for classes for inherited fixed parameters were not included as required.
>
> Andi..
>
>>
Re: Problem using generic types?
Posted by Andi Vajda <va...@apache.org>.
Hi Petrus,
> On Jan 14, 2014, at 4:24, Petrus Hyvönen <pe...@gmail.com> wrote:
>
> Dear Andi,
>
> Many many thanks for looking into this!
>
> I am on travel for a week and do not have the computer with the special case with me to test. I did now however run it on the library that I am wrapping, and there get some errors in the creation of the wrapped module (orekit):
>
> build/_orekit/__wrap__.cpp:86504:89: error: no member named
> 'HarmonicOscillator$Parametric$$Type' in namespace
I believe I fixed this bug in rev 1557613, header files for classes for inherited fixed parameters were not included as required.
Andi..
> 'org::apache::commons::math3::analysis::function'
> ...= &::org::apache::commons::math3::analysis::function::PY_TYPE(HarmonicOs...
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
> /Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23: note:
> expanded from macro 'PY_TYPE'
> #define PY_TYPE(name) name##$$Type
> ^
> <scratch space>:63:1: note: expanded from here
> HarmonicOscillator$Parametric$$Type
> ^
> build/_orekit/__wrap__.cpp:217752:55: error: no member named
> 'OrekitMessages$$Type' in namespace 'org::orekit::errors'
> self->parameters[0] = &::org::orekit::errors::PY_TYPE(OrekitMessages);
> ~~~~~~~~~~~~~~~~~~~~~~~^
> /Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23: note:
> expanded from macro 'PY_TYPE'
> #define PY_TYPE(name) name##$$Type
> ^
> <scratch space>:9:1: note: expanded from here
> OrekitMessages$$Type
> ^
> 2 errors generated.
> error: command 'gcc' failed with exit status 1
>
>
>
> The OrekitMessages is defined as a "public enum OrekitMessages implements Localizable { ..."
> and the "public class HarmonicOscillator implements UnivariateDifferentiable, DifferentiableUnivariateFunction".
>
> Maybe this says you something, I will try to test more and run my test case in .
>
> Best Regards and again, many thanks again!
> /petrus
>
>
>
>
>
>> On 11 Jan 2014, at 14:23 , Andi Vajda <va...@apache.org> wrote:
>>
>>
>> Hi Petrus,
>>
>>> On Mon, 30 Dec 2013, Petrus Hyvönen wrote:
>>>
>>> Andi, great to hear that you could reproduce it. I'm very thankful if you
>>> could have a look at it, I've been struggling to understand how the
>>> machinery behind this works, but far from it still..
>>
>> I think I fixed the problem and added an improvement to generics support along the way. Please check out rev 1557423 from jcc's trunk, rebuild your module with it and let me know how it's working for you.
>>
>> The bug had to do with SimpleClass2's wrapper class missing its parameters slot which it should get from its superclass, SimpleClass. When calling a
>> method on SimpleClass from SimpleClass2, the missing parameters in the
>> wrapper's struct would cause memory to get trashed.
>>
>> In addition to fixing the bug, I also improved support for fixed class parameters. Now, if you change SimpleClass's return_null() method to return new Integer(12) instead, when calling it on SimpleClass2, 12 is returned instead of <Object: 12>.
>>
>> Andi..
>>
>> public class SimpleClass<T> { public SimpleClass() { System.out.println("Created SimpleClass"); }
>> public T return_null() {
>> return (T) new Integer(12);
>> }
>>
>> }
>>
>>
>>>
>>> Best Regards
>>> /Petrus
>>>
>>>
>>>
>>>> On Mon, Dec 30, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>>>>
>>>>
>>>> On Sun, 29 Dec 2013, Petrus Hyvönen wrote:
>>>>
>>>> I have distilled the library that I have some trouble with and I think I
>>>>> have an example that is failing due to same problem I think. I am not good
>>>>> in java, but have tried to follow the logic from the library I'm wrapping.
>>>>> The function of the example does not make sense in itself.
>>>>>
>>>>> public class SimpleClass<T> {
>>>>> public SimpleClass() {
>>>>> System.out.println("Created SimpleClass");
>>>>> }
>>>>> public T return_null() {
>>>>> return null;
>>>>> }
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> public class SimpleClass2 extends SimpleClass<Integer>{
>>>>>
>>>>> public SimpleClass2(){}
>>>>> public void testInJava(){
>>>>> System.out.println(this.return_null());
>>>>> }
>>>>> }
>>>>>
>>>>>
>>>>> It seems to me that there is some problem with methods inherited that
>>>>> returns a generic type, failing in wrapType when this is to be wrapped.
>>>>>
>>>>> The python script that fails:
>>>>>
>>>>> a= SimpleClass()
>>>>> print a.return_null()
>>>>>
>>>>> b = SimpleClass2()
>>>>> b.testInJava()
>>>>>
>>>>> print b.return_null() #Fails in wrapType
>>>>>
>>>>> I don't know if the return null is a bad thing to do in java, but the
>>>>> error
>>>>> seems very similar to what I experience in the larger library. I have a
>>>>> skeleton of that this is slightly larger, but not returning null, but
>>>>> trying to keep the lenght of example low :)
>>>>>
>>>>> Any comments highly appriciated :)
>>>>
>>>> I've been able to reproduce the problem.
>>>> Thank you for providing an isolated test case !
>>>>
>>>> Andi..
>>>>
>>>>
>>>>
>>>>> best Regards
>>>>> /Petrus
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Fri, Dec 27, 2013 at 6:25 PM, Andi Vajda <va...@apache.org> wrote:
>>>>>>
>>>>>>
>>>>>> On Dec 27, 2013, at 17:36, Petrus Hyvönen <pe...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> Dear Andi,
>>>>>>>
>>>>>>> I am working on debugging the failure and try to understand a bit how
>>>>>>> JCC
>>>>>>> works internally. I haven't gone very far but in case you have some
>>>>>>> pointers from these early debugging sessions I would be very thankful. I
>>>>>>> know it's complex, and I should try to make some smaller test cases, but
>>>>>> I
>>>>>>
>>>>>>> don't really have a grasp yet where the problem might be.
>>>>>>>
>>>>>>> Writing this might help me also to get some structure in my thinking :)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The main crash seems to be in the last line, wrapType(), of
>>>>>>> __wrap__.cpp:
>>>>>>>
>>>>>>> static PyObject
>>>>>>>
>>>>>>> *t_AbstractReconfigurableDetector_withHandler(t_
>>>>>> AbstractReconfigurableDetector
>>>>>>
>>>>>>> *self, PyObject *arg)
>>>>>>> {
>>>>>>> ::org::orekit::propagation::events::handlers::EventHandler
>>>>>>> a0((jobject) NULL);
>>>>>>> PyTypeObject **p0;
>>>>>>> ::org::orekit::propagation::events::EventDetector
>>>>>>> result((jobject) NULL);
>>>>>>>
>>>>>>> if (!parseArg(arg, "K",
>>>>>>>
>>>>>>> ::org::orekit::propagation::events::handlers::
>>>>>> EventHandler::initializeClass,
>>>>>>
>>>>>>> &a0, &p0,
>>>>>>>
>>>>>>> ::org::orekit::propagation::events::handlers::t_
>>>>>> EventHandler::parameters_))
>>>>>>
>>>>>>> {
>>>>>>> OBJ_CALL(result = self->object.withHandler(a0));
>>>>>>> return self->parameters[0] != NULL ?
>>>>>>> wrapType(self->parameters[0], result.this$) :
>>>>>>> ::org::orekit::propagation::events::t_EventDetector::wrap_
>>>>>>> Object(result);
>>>>>>> }
>>>>>>>
>>>>>>> The parameters[0] does not seem to be null, but neither is it a valid
>>>>>>> object, in my debugger it says 0xbaadf00d {ob_refcnt=??? ob_type=???
>>>>>>> ob_size=??? ...} _typeobject *, wrapType is called and when trying
>>>>>>> to
>>>>>>> access the wrapfn it crashes.
>>>>>>>
>>>>>>> The main python lines are:
>>>>>>> tmp1 = ElevationDetector(sta1Frame) #
>>>>>> ElevationDetector
>>>>>>
>>>>>>> is a java public class ElevationDetector extends
>>>>>>> AbstractReconfigurableDetector<ElevationDetector>
>>>>>>> hand = ContinueOnEvent().of_(ElevationDetector) # a
>>>>>>> java ContinueOnEvent<ElevationDetector> object
>>>>>>> elDetector = tmp1.withHandler(hand) #Crash. withHandler is a method
>>>>>>> that is inherited from AbstractReconfigurableDetector to
>>>>>> ElevationDetector
>>>>>>
>>>>>>>
>>>>>>> This crashes when interactively entered on the python prompt (or in
>>>>>>> other
>>>>>>> interactive consoles), but seems to work if executed directly without
>>>>>>> interactivity. This difference makes me think that it might be something
>>>>>>> with garbage collection, but don't know.
>>>>>>>
>>>>>>> Any comments appriciated, I know this is likely very difficult to
>>>>>>> comment
>>>>>>> on as it's not very encapsulated.
>>>>>>
>>>>>> Right, so unless you can isolate this into something I can reproduce, I'm
>>>>>> afraid there isn't much I can comment.
>>>>>> It is quite likely that by the time you have that reproducible test case
>>>>>> ready, you also have the solution to the problem. Or I might be able to
>>>>>> help then...
>>>>>>
>>>>>> Andi..
>>>>>>
>>>>>>
>>>>>>> Regards
>>>>>>> /Petrus
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Sun, Dec 15, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Dec 15, 2013, at 5:43, Petrus Hyvönen <pe...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Andi,
>>>>>>>>>
>>>>>>>>> I see your point and have now kept in the pure python domain.
>>>>>>>>>
>>>>>>>>> If I run my script from the shell by "python script.py" it does not
>>>>>>>> crash. However if I execute it line-by-line in python it crashes (or in
>>>>>>>> other tools such as ipython notebook).
>>>>>>>>
>>>>>>>>> All classes used are non-wrapped java classes, but I get the same
>>>>>>>> effect
>>>>>>
>>>>>>> with classes made for python subclassing.
>>>>>>>>
>>>>>>>>> I am getting this on both MacOSX 64-bit python and Windows 7 32-bit
>>>>>>>> python.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> elDetector =
>>>>>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>>>
>>>>>>>>> #
>>>>>>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>>>>>>> #
>>>>>>>>> # SIGSEGV (0xb) at pc=0x000000010005da1a, pid=3318, tid=1287
>>>>>>>>> #
>>>>>>>>> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
>>>>>>>> 1.7.0_45-b18)
>>>>>>>>
>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
>>>>>>>> bsd-amd64 compressed oops)
>>>>>>>>
>>>>>>>>> # Problematic frame:
>>>>>>>>> # C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>>>>>>>> #
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> from the stack it seems like there is somthing happening in "wrapType"
>>>>>>>>> Stack: [0x00007fff5fb80000,0x00007fff5fc00000],
>>>>>>>>> sp=0x00007fff5fbff470,
>>>>>>>> free space=509k
>>>>>>>>
>>>>>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>>>>>>> C=native code)
>>>>>>>>
>>>>>>>>> C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>>>>>>>> C [_orekit.so+0xa80878] wrapType(_typeobject*, _jobject*
>>>>>>>>> const&)+0x58
>>>>>>>>> C [_orekit.so+0x554400]
>>>>>>>>
>>>>>>>> org::orekit::propagation::events::t_AbstractReconfigurableDetector
>>>>>> _withHandler(org::orekit::propagation::events::t_
>>>>>> AbstractReconfigurableDetector*,
>>>>>>
>>>>>>> _object*)+0x1c0
>>>>>>>>
>>>>>>>>>
>>>>>>>>> First, is the generic class assignment correct as if to write "new
>>>>>>>> ContinueOnEvent<ElevationDetector>()" in java? And is it ok to use
>>>>>>> regular
>>>>>>
>>>>>>> java objects/types?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Any other comments to move forward highly appriciated.. Is it somehow
>>>>>>>> possible to get more log what is going wrong?
>>>>>>>>
>>>>>>>> You could compile the whole thing for debugging, by adding --debug
>>>>>>>> after
>>>>>>>> 'build' in the jcc invocation and run it with gdb.
>>>>>>>>
>>>>>>>> If you can isolate a reproducible crash into a small test case, I can
>>>>>>> also
>>>>>>
>>>>>>> take a look at it.
>>>>>>>>
>>>>>>>> Andi..
>>>>>>>>
>>>>>>>>
>>>>>>>>> WIth best regards
>>>>>>>>> /Petrus
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 15 Dec 2013, at 2:40 , Andi Vajda <va...@apache.org> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Dec 14, 2013, at 19:14, Petrus Hyvönen <petrus.hyvonen@gmail.com
>>>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I'm having a problem with I think might be related to generic types,
>>>>>>>>>> but not sure at all.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> I'm wrapping a orbit calculation library, which has been working
>>>>>>>>>>> well
>>>>>>>>>> but in latest version is using generic types and I'm getting some
>>>>>>> problems.
>>>>>>
>>>>>>> The script works when executed in plain python, but fails in ipython
>>>>>>>> notebook on this last line when executed as a couple of cells.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> What is an 'ipython notebook' ?
>>>>>>>>>>
>>>>>>>>>> Andi.,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> The section with problem in my script is:
>>>>>>>>>>> elDetector =
>>>>>>>>>> ElevationDetector(sta1Frame).withConstantElevation(math.
>>>>>>>> radians(5.0))
>>>>>>>>
>>>>>>>>> elDetector =
>>>>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> In Java it would typically look something like:
>>>>>>>>>>>
>>>>>>>>>>> ElevationDetector detector = new ElevationDetector(topo)
>>>>>>>>>>> .withConstantElevation(x)
>>>>>>>>>>> .withHandler(new
>>>>>>>>>> ContinueOnEvent<ElevationDetector>());
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> It produces correct results in plain python, but crashes the kernel
>>>>>>>>>> in
>>>>>>
>>>>>>> ipython if executed as cells, and in exection from spyder I get an error
>>>>>>>> message:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> " elDetector =
>>>>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>>>
>>>>>>>>> AttributeError: 'str' object has no attribute 'wrapfn_' "
>>>>>>>>>>>
>>>>>>>>>>> As I have been using this setup stabely with lots of other functions
>>>>>>>>>> it feels like there is something with the generic type line, but I
>>>>>>>> don't
>>>>>>>> really know how to get any further? I'm confused by that the pauses in
>>>>>>> the
>>>>>>
>>>>>>> execution could seem to affect the result.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Any comments highly appriciated...
>>>>>>>>>>>
>>>>>>>>>>> Best Regards
>>>>>>>>>>> /Petrus
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> _____________________________________________
>>>>>>> Petrus Hyvönen, Uppsala, Sweden
>>>>>>> Mobile Phone/SMS:+46 73 803 19 00
>>>>>
>>>>>
>>>>> --
>>>>> _____________________________________________
>>>>> Petrus Hyvönen, Uppsala, Sweden
>>>>> Mobile Phone/SMS:+46 73 803 19 00
>>>
>>>
>>> --
>>> _____________________________________________
>>> Petrus Hyvönen, Uppsala, Sweden
>>> Mobile Phone/SMS:+46 73 803 19 00
>
Re: Problem using generic types?
Posted by Andi Vajda <va...@apache.org>.
Hi Petrus,
On Mon, 30 Dec 2013, Petrus Hyvönen wrote:
> Andi, great to hear that you could reproduce it. I'm very thankful if you
> could have a look at it, I've been struggling to understand how the
> machinery behind this works, but far from it still..
I think I fixed the problem and added an improvement to generics support
along the way. Please check out rev 1557423 from jcc's trunk, rebuild
your module with it and let me know how it's working for you.
The bug had to do with SimpleClass2's wrapper class missing its parameters
slot which it should get from its superclass, SimpleClass. When calling a
method on SimpleClass from SimpleClass2, the missing parameters in the
wrapper's struct would cause memory to get trashed.
In addition to fixing the bug, I also improved support for fixed class
parameters. Now, if you change SimpleClass's return_null() method to return
new Integer(12) instead, when calling it on SimpleClass2, 12 is returned
instead of <Object: 12>.
Andi..
public class SimpleClass<T> {
public SimpleClass() {
System.out.println("Created SimpleClass");
}
public T return_null() {
return (T) new Integer(12);
}
}
>
> Best Regards
> /Petrus
>
>
>
> On Mon, Dec 30, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>
>>
>> On Sun, 29 Dec 2013, Petrus Hyvönen wrote:
>>
>> I have distilled the library that I have some trouble with and I think I
>>> have an example that is failing due to same problem I think. I am not good
>>> in java, but have tried to follow the logic from the library I'm wrapping.
>>> The function of the example does not make sense in itself.
>>>
>>> public class SimpleClass<T> {
>>> public SimpleClass() {
>>> System.out.println("Created SimpleClass");
>>> }
>>> public T return_null() {
>>> return null;
>>> }
>>>
>>> }
>>>
>>>
>>>
>>> public class SimpleClass2 extends SimpleClass<Integer>{
>>>
>>> public SimpleClass2(){}
>>> public void testInJava(){
>>> System.out.println(this.return_null());
>>> }
>>> }
>>>
>>>
>>> It seems to me that there is some problem with methods inherited that
>>> returns a generic type, failing in wrapType when this is to be wrapped.
>>>
>>> The python script that fails:
>>>
>>> a= SimpleClass()
>>> print a.return_null()
>>>
>>> b = SimpleClass2()
>>> b.testInJava()
>>>
>>> print b.return_null() #Fails in wrapType
>>>
>>> I don't know if the return null is a bad thing to do in java, but the
>>> error
>>> seems very similar to what I experience in the larger library. I have a
>>> skeleton of that this is slightly larger, but not returning null, but
>>> trying to keep the lenght of example low :)
>>>
>>> Any comments highly appriciated :)
>>>
>>
>> I've been able to reproduce the problem.
>> Thank you for providing an isolated test case !
>>
>> Andi..
>>
>>
>>
>>> best Regards
>>> /Petrus
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Dec 27, 2013 at 6:25 PM, Andi Vajda <va...@apache.org> wrote:
>>>
>>>
>>>> On Dec 27, 2013, at 17:36, Petrus Hyvönen <pe...@gmail.com>
>>>>>
>>>> wrote:
>>>>
>>>>>
>>>>> Dear Andi,
>>>>>
>>>>> I am working on debugging the failure and try to understand a bit how
>>>>> JCC
>>>>> works internally. I haven't gone very far but in case you have some
>>>>> pointers from these early debugging sessions I would be very thankful. I
>>>>> know it's complex, and I should try to make some smaller test cases, but
>>>>>
>>>> I
>>>>
>>>>> don't really have a grasp yet where the problem might be.
>>>>>
>>>>> Writing this might help me also to get some structure in my thinking :)
>>>>>
>>>>>
>>>>>
>>>>> The main crash seems to be in the last line, wrapType(), of
>>>>> __wrap__.cpp:
>>>>>
>>>>> static PyObject
>>>>>
>>>>> *t_AbstractReconfigurableDetector_withHandler(t_
>>>> AbstractReconfigurableDetector
>>>>
>>>>> *self, PyObject *arg)
>>>>> {
>>>>> ::org::orekit::propagation::events::handlers::EventHandler
>>>>> a0((jobject) NULL);
>>>>> PyTypeObject **p0;
>>>>> ::org::orekit::propagation::events::EventDetector
>>>>> result((jobject) NULL);
>>>>>
>>>>> if (!parseArg(arg, "K",
>>>>>
>>>>> ::org::orekit::propagation::events::handlers::
>>>> EventHandler::initializeClass,
>>>>
>>>>> &a0, &p0,
>>>>>
>>>>> ::org::orekit::propagation::events::handlers::t_
>>>> EventHandler::parameters_))
>>>>
>>>>> {
>>>>> OBJ_CALL(result = self->object.withHandler(a0));
>>>>> return self->parameters[0] != NULL ?
>>>>> wrapType(self->parameters[0], result.this$) :
>>>>> ::org::orekit::propagation::events::t_EventDetector::wrap_
>>>>> Object(result);
>>>>> }
>>>>>
>>>>> The parameters[0] does not seem to be null, but neither is it a valid
>>>>> object, in my debugger it says 0xbaadf00d {ob_refcnt=??? ob_type=???
>>>>> ob_size=??? ...} _typeobject *, wrapType is called and when trying
>>>>> to
>>>>> access the wrapfn it crashes.
>>>>>
>>>>> The main python lines are:
>>>>> tmp1 = ElevationDetector(sta1Frame) #
>>>>>
>>>> ElevationDetector
>>>>
>>>>> is a java public class ElevationDetector extends
>>>>> AbstractReconfigurableDetector<ElevationDetector>
>>>>> hand = ContinueOnEvent().of_(ElevationDetector) # a
>>>>> java ContinueOnEvent<ElevationDetector> object
>>>>> elDetector = tmp1.withHandler(hand) #Crash. withHandler is a method
>>>>> that is inherited from AbstractReconfigurableDetector to
>>>>>
>>>> ElevationDetector
>>>>
>>>>>
>>>>> This crashes when interactively entered on the python prompt (or in
>>>>> other
>>>>> interactive consoles), but seems to work if executed directly without
>>>>> interactivity. This difference makes me think that it might be something
>>>>> with garbage collection, but don't know.
>>>>>
>>>>> Any comments appriciated, I know this is likely very difficult to
>>>>> comment
>>>>> on as it's not very encapsulated.
>>>>>
>>>>
>>>> Right, so unless you can isolate this into something I can reproduce, I'm
>>>> afraid there isn't much I can comment.
>>>> It is quite likely that by the time you have that reproducible test case
>>>> ready, you also have the solution to the problem. Or I might be able to
>>>> help then...
>>>>
>>>> Andi..
>>>>
>>>>
>>>>> Regards
>>>>> /Petrus
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Dec 15, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>>>>>>
>>>>>>
>>>>>> On Dec 15, 2013, at 5:43, Petrus Hyvönen <pe...@gmail.com>
>>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Andi,
>>>>>>>
>>>>>>> I see your point and have now kept in the pure python domain.
>>>>>>>
>>>>>>> If I run my script from the shell by "python script.py" it does not
>>>>>>>
>>>>>> crash. However if I execute it line-by-line in python it crashes (or in
>>>>>> other tools such as ipython notebook).
>>>>>>
>>>>>>> All classes used are non-wrapped java classes, but I get the same
>>>>>>>
>>>>>> effect
>>>>
>>>>> with classes made for python subclassing.
>>>>>>
>>>>>>> I am getting this on both MacOSX 64-bit python and Windows 7 32-bit
>>>>>>>
>>>>>> python.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> elDetector =
>>>>>>>>>>
>>>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>
>>>>>>> #
>>>>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>>>>> #
>>>>>>> # SIGSEGV (0xb) at pc=0x000000010005da1a, pid=3318, tid=1287
>>>>>>> #
>>>>>>> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
>>>>>>>
>>>>>> 1.7.0_45-b18)
>>>>>>
>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
>>>>>>>
>>>>>> bsd-amd64 compressed oops)
>>>>>>
>>>>>>> # Problematic frame:
>>>>>>> # C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>>>>>> #
>>>>>>>
>>>>>>>
>>>>>>> from the stack it seems like there is somthing happening in "wrapType"
>>>>>>> Stack: [0x00007fff5fb80000,0x00007fff5fc00000],
>>>>>>> sp=0x00007fff5fbff470,
>>>>>>>
>>>>>> free space=509k
>>>>>>
>>>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>>>>>>
>>>>>> C=native code)
>>>>>>
>>>>>>> C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>>>>>> C [_orekit.so+0xa80878] wrapType(_typeobject*, _jobject*
>>>>>>> const&)+0x58
>>>>>>> C [_orekit.so+0x554400]
>>>>>>>
>>>>>>
>>>>>> org::orekit::propagation::events::t_AbstractReconfigurableDetector
>>>> _withHandler(org::orekit::propagation::events::t_
>>>> AbstractReconfigurableDetector*,
>>>>
>>>>> _object*)+0x1c0
>>>>>>
>>>>>>>
>>>>>>> First, is the generic class assignment correct as if to write "new
>>>>>>>
>>>>>> ContinueOnEvent<ElevationDetector>()" in java? And is it ok to use
>>>>>>
>>>>> regular
>>>>
>>>>> java objects/types?
>>>>>>
>>>>>>>
>>>>>>> Any other comments to move forward highly appriciated.. Is it somehow
>>>>>>>
>>>>>> possible to get more log what is going wrong?
>>>>>>
>>>>>> You could compile the whole thing for debugging, by adding --debug
>>>>>> after
>>>>>> 'build' in the jcc invocation and run it with gdb.
>>>>>>
>>>>>> If you can isolate a reproducible crash into a small test case, I can
>>>>>>
>>>>> also
>>>>
>>>>> take a look at it.
>>>>>>
>>>>>> Andi..
>>>>>>
>>>>>>
>>>>>>> WIth best regards
>>>>>>> /Petrus
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 15 Dec 2013, at 2:40 , Andi Vajda <va...@apache.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Dec 14, 2013, at 19:14, Petrus Hyvönen <petrus.hyvonen@gmail.com
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I'm having a problem with I think might be related to generic types,
>>>>>>>>>
>>>>>>>> but not sure at all.
>>>>>>
>>>>>>>
>>>>>>>>> I'm wrapping a orbit calculation library, which has been working
>>>>>>>>> well
>>>>>>>>>
>>>>>>>> but in latest version is using generic types and I'm getting some
>>>>>>
>>>>> problems.
>>>>
>>>>> The script works when executed in plain python, but fails in ipython
>>>>>> notebook on this last line when executed as a couple of cells.
>>>>>>
>>>>>>>
>>>>>>>> What is an 'ipython notebook' ?
>>>>>>>>
>>>>>>>> Andi.,
>>>>>>>>
>>>>>>>>
>>>>>>>>> The section with problem in my script is:
>>>>>>>>> elDetector =
>>>>>>>>>
>>>>>>>> ElevationDetector(sta1Frame).withConstantElevation(math.
>>>>>> radians(5.0))
>>>>>>
>>>>>>> elDetector =
>>>>>>>>>
>>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>
>>>>>>>
>>>>>>>>> In Java it would typically look something like:
>>>>>>>>>
>>>>>>>>> ElevationDetector detector = new ElevationDetector(topo)
>>>>>>>>> .withConstantElevation(x)
>>>>>>>>> .withHandler(new
>>>>>>>>>
>>>>>>>> ContinueOnEvent<ElevationDetector>());
>>>>>>
>>>>>>>
>>>>>>>>> It produces correct results in plain python, but crashes the kernel
>>>>>>>>>
>>>>>>>> in
>>>>
>>>>> ipython if executed as cells, and in exection from spyder I get an error
>>>>>> message:
>>>>>>
>>>>>>>
>>>>>>>>> " elDetector =
>>>>>>>>>
>>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>
>>>>>>> AttributeError: 'str' object has no attribute 'wrapfn_' "
>>>>>>>>>
>>>>>>>>> As I have been using this setup stabely with lots of other functions
>>>>>>>>>
>>>>>>>> it feels like there is something with the generic type line, but I
>>>>>> don't
>>>>>> really know how to get any further? I'm confused by that the pauses in
>>>>>>
>>>>> the
>>>>
>>>>> execution could seem to affect the result.
>>>>>>
>>>>>>>
>>>>>>>>> Any comments highly appriciated...
>>>>>>>>>
>>>>>>>>> Best Regards
>>>>>>>>> /Petrus
>>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> _____________________________________________
>>>>> Petrus Hyvönen, Uppsala, Sweden
>>>>> Mobile Phone/SMS:+46 73 803 19 00
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> _____________________________________________
>>> Petrus Hyvönen, Uppsala, Sweden
>>> Mobile Phone/SMS:+46 73 803 19 00
>>>
>>
>
>
> --
> _____________________________________________
> Petrus Hyvönen, Uppsala, Sweden
> Mobile Phone/SMS:+46 73 803 19 00
>
Re: Problem using generic types?
Posted by Petrus Hyvönen <pe...@gmail.com>.
Andi, great to hear that you could reproduce it. I'm very thankful if you
could have a look at it, I've been struggling to understand how the
machinery behind this works, but far from it still..
Best Regards
/Petrus
On Mon, Dec 30, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>
> On Sun, 29 Dec 2013, Petrus Hyvönen wrote:
>
> I have distilled the library that I have some trouble with and I think I
>> have an example that is failing due to same problem I think. I am not good
>> in java, but have tried to follow the logic from the library I'm wrapping.
>> The function of the example does not make sense in itself.
>>
>> public class SimpleClass<T> {
>> public SimpleClass() {
>> System.out.println("Created SimpleClass");
>> }
>> public T return_null() {
>> return null;
>> }
>>
>> }
>>
>>
>>
>> public class SimpleClass2 extends SimpleClass<Integer>{
>>
>> public SimpleClass2(){}
>> public void testInJava(){
>> System.out.println(this.return_null());
>> }
>> }
>>
>>
>> It seems to me that there is some problem with methods inherited that
>> returns a generic type, failing in wrapType when this is to be wrapped.
>>
>> The python script that fails:
>>
>> a= SimpleClass()
>> print a.return_null()
>>
>> b = SimpleClass2()
>> b.testInJava()
>>
>> print b.return_null() #Fails in wrapType
>>
>> I don't know if the return null is a bad thing to do in java, but the
>> error
>> seems very similar to what I experience in the larger library. I have a
>> skeleton of that this is slightly larger, but not returning null, but
>> trying to keep the lenght of example low :)
>>
>> Any comments highly appriciated :)
>>
>
> I've been able to reproduce the problem.
> Thank you for providing an isolated test case !
>
> Andi..
>
>
>
>> best Regards
>> /Petrus
>>
>>
>>
>>
>>
>>
>> On Fri, Dec 27, 2013 at 6:25 PM, Andi Vajda <va...@apache.org> wrote:
>>
>>
>>> On Dec 27, 2013, at 17:36, Petrus Hyvönen <pe...@gmail.com>
>>>>
>>> wrote:
>>>
>>>>
>>>> Dear Andi,
>>>>
>>>> I am working on debugging the failure and try to understand a bit how
>>>> JCC
>>>> works internally. I haven't gone very far but in case you have some
>>>> pointers from these early debugging sessions I would be very thankful. I
>>>> know it's complex, and I should try to make some smaller test cases, but
>>>>
>>> I
>>>
>>>> don't really have a grasp yet where the problem might be.
>>>>
>>>> Writing this might help me also to get some structure in my thinking :)
>>>>
>>>>
>>>>
>>>> The main crash seems to be in the last line, wrapType(), of
>>>> __wrap__.cpp:
>>>>
>>>> static PyObject
>>>>
>>>> *t_AbstractReconfigurableDetector_withHandler(t_
>>> AbstractReconfigurableDetector
>>>
>>>> *self, PyObject *arg)
>>>> {
>>>> ::org::orekit::propagation::events::handlers::EventHandler
>>>> a0((jobject) NULL);
>>>> PyTypeObject **p0;
>>>> ::org::orekit::propagation::events::EventDetector
>>>> result((jobject) NULL);
>>>>
>>>> if (!parseArg(arg, "K",
>>>>
>>>> ::org::orekit::propagation::events::handlers::
>>> EventHandler::initializeClass,
>>>
>>>> &a0, &p0,
>>>>
>>>> ::org::orekit::propagation::events::handlers::t_
>>> EventHandler::parameters_))
>>>
>>>> {
>>>> OBJ_CALL(result = self->object.withHandler(a0));
>>>> return self->parameters[0] != NULL ?
>>>> wrapType(self->parameters[0], result.this$) :
>>>> ::org::orekit::propagation::events::t_EventDetector::wrap_
>>>> Object(result);
>>>> }
>>>>
>>>> The parameters[0] does not seem to be null, but neither is it a valid
>>>> object, in my debugger it says 0xbaadf00d {ob_refcnt=??? ob_type=???
>>>> ob_size=??? ...} _typeobject *, wrapType is called and when trying
>>>> to
>>>> access the wrapfn it crashes.
>>>>
>>>> The main python lines are:
>>>> tmp1 = ElevationDetector(sta1Frame) #
>>>>
>>> ElevationDetector
>>>
>>>> is a java public class ElevationDetector extends
>>>> AbstractReconfigurableDetector<ElevationDetector>
>>>> hand = ContinueOnEvent().of_(ElevationDetector) # a
>>>> java ContinueOnEvent<ElevationDetector> object
>>>> elDetector = tmp1.withHandler(hand) #Crash. withHandler is a method
>>>> that is inherited from AbstractReconfigurableDetector to
>>>>
>>> ElevationDetector
>>>
>>>>
>>>> This crashes when interactively entered on the python prompt (or in
>>>> other
>>>> interactive consoles), but seems to work if executed directly without
>>>> interactivity. This difference makes me think that it might be something
>>>> with garbage collection, but don't know.
>>>>
>>>> Any comments appriciated, I know this is likely very difficult to
>>>> comment
>>>> on as it's not very encapsulated.
>>>>
>>>
>>> Right, so unless you can isolate this into something I can reproduce, I'm
>>> afraid there isn't much I can comment.
>>> It is quite likely that by the time you have that reproducible test case
>>> ready, you also have the solution to the problem. Or I might be able to
>>> help then...
>>>
>>> Andi..
>>>
>>>
>>>> Regards
>>>> /Petrus
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Dec 15, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>>>>>
>>>>>
>>>>> On Dec 15, 2013, at 5:43, Petrus Hyvönen <pe...@gmail.com>
>>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> Hi Andi,
>>>>>>
>>>>>> I see your point and have now kept in the pure python domain.
>>>>>>
>>>>>> If I run my script from the shell by "python script.py" it does not
>>>>>>
>>>>> crash. However if I execute it line-by-line in python it crashes (or in
>>>>> other tools such as ipython notebook).
>>>>>
>>>>>> All classes used are non-wrapped java classes, but I get the same
>>>>>>
>>>>> effect
>>>
>>>> with classes made for python subclassing.
>>>>>
>>>>>> I am getting this on both MacOSX 64-bit python and Windows 7 32-bit
>>>>>>
>>>>> python.
>>>>>
>>>>>>
>>>>>>
>>>>>> elDetector =
>>>>>>>>>
>>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>
>>>>>> #
>>>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>>>> #
>>>>>> # SIGSEGV (0xb) at pc=0x000000010005da1a, pid=3318, tid=1287
>>>>>> #
>>>>>> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
>>>>>>
>>>>> 1.7.0_45-b18)
>>>>>
>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
>>>>>>
>>>>> bsd-amd64 compressed oops)
>>>>>
>>>>>> # Problematic frame:
>>>>>> # C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>>>>> #
>>>>>>
>>>>>>
>>>>>> from the stack it seems like there is somthing happening in "wrapType"
>>>>>> Stack: [0x00007fff5fb80000,0x00007fff5fc00000],
>>>>>> sp=0x00007fff5fbff470,
>>>>>>
>>>>> free space=509k
>>>>>
>>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>>>>>
>>>>> C=native code)
>>>>>
>>>>>> C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>>>>> C [_orekit.so+0xa80878] wrapType(_typeobject*, _jobject*
>>>>>> const&)+0x58
>>>>>> C [_orekit.so+0x554400]
>>>>>>
>>>>>
>>>>> org::orekit::propagation::events::t_AbstractReconfigurableDetector
>>> _withHandler(org::orekit::propagation::events::t_
>>> AbstractReconfigurableDetector*,
>>>
>>>> _object*)+0x1c0
>>>>>
>>>>>>
>>>>>> First, is the generic class assignment correct as if to write "new
>>>>>>
>>>>> ContinueOnEvent<ElevationDetector>()" in java? And is it ok to use
>>>>>
>>>> regular
>>>
>>>> java objects/types?
>>>>>
>>>>>>
>>>>>> Any other comments to move forward highly appriciated.. Is it somehow
>>>>>>
>>>>> possible to get more log what is going wrong?
>>>>>
>>>>> You could compile the whole thing for debugging, by adding --debug
>>>>> after
>>>>> 'build' in the jcc invocation and run it with gdb.
>>>>>
>>>>> If you can isolate a reproducible crash into a small test case, I can
>>>>>
>>>> also
>>>
>>>> take a look at it.
>>>>>
>>>>> Andi..
>>>>>
>>>>>
>>>>>> WIth best regards
>>>>>> /Petrus
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 15 Dec 2013, at 2:40 , Andi Vajda <va...@apache.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Dec 14, 2013, at 19:14, Petrus Hyvönen <petrus.hyvonen@gmail.com
>>>>>>>> >
>>>>>>>>
>>>>>>> wrote:
>>>>>
>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm having a problem with I think might be related to generic types,
>>>>>>>>
>>>>>>> but not sure at all.
>>>>>
>>>>>>
>>>>>>>> I'm wrapping a orbit calculation library, which has been working
>>>>>>>> well
>>>>>>>>
>>>>>>> but in latest version is using generic types and I'm getting some
>>>>>
>>>> problems.
>>>
>>>> The script works when executed in plain python, but fails in ipython
>>>>> notebook on this last line when executed as a couple of cells.
>>>>>
>>>>>>
>>>>>>> What is an 'ipython notebook' ?
>>>>>>>
>>>>>>> Andi.,
>>>>>>>
>>>>>>>
>>>>>>>> The section with problem in my script is:
>>>>>>>> elDetector =
>>>>>>>>
>>>>>>> ElevationDetector(sta1Frame).withConstantElevation(math.
>>>>> radians(5.0))
>>>>>
>>>>>> elDetector =
>>>>>>>>
>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>
>>>>>>
>>>>>>>> In Java it would typically look something like:
>>>>>>>>
>>>>>>>> ElevationDetector detector = new ElevationDetector(topo)
>>>>>>>> .withConstantElevation(x)
>>>>>>>> .withHandler(new
>>>>>>>>
>>>>>>> ContinueOnEvent<ElevationDetector>());
>>>>>
>>>>>>
>>>>>>>> It produces correct results in plain python, but crashes the kernel
>>>>>>>>
>>>>>>> in
>>>
>>>> ipython if executed as cells, and in exection from spyder I get an error
>>>>> message:
>>>>>
>>>>>>
>>>>>>>> " elDetector =
>>>>>>>>
>>>>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>
>>>>>> AttributeError: 'str' object has no attribute 'wrapfn_' "
>>>>>>>>
>>>>>>>> As I have been using this setup stabely with lots of other functions
>>>>>>>>
>>>>>>> it feels like there is something with the generic type line, but I
>>>>> don't
>>>>> really know how to get any further? I'm confused by that the pauses in
>>>>>
>>>> the
>>>
>>>> execution could seem to affect the result.
>>>>>
>>>>>>
>>>>>>>> Any comments highly appriciated...
>>>>>>>>
>>>>>>>> Best Regards
>>>>>>>> /Petrus
>>>>>>>>
>>>>>>>
>>>>
>>>>
>>>> --
>>>> _____________________________________________
>>>> Petrus Hyvönen, Uppsala, Sweden
>>>> Mobile Phone/SMS:+46 73 803 19 00
>>>>
>>>
>>>
>>
>>
>> --
>> _____________________________________________
>> Petrus Hyvönen, Uppsala, Sweden
>> Mobile Phone/SMS:+46 73 803 19 00
>>
>
--
_____________________________________________
Petrus Hyvönen, Uppsala, Sweden
Mobile Phone/SMS:+46 73 803 19 00
Re: Problem using generic types?
Posted by Andi Vajda <va...@apache.org>.
On Sun, 29 Dec 2013, Petrus Hyvönen wrote:
> I have distilled the library that I have some trouble with and I think I
> have an example that is failing due to same problem I think. I am not good
> in java, but have tried to follow the logic from the library I'm wrapping.
> The function of the example does not make sense in itself.
>
> public class SimpleClass<T> {
> public SimpleClass() {
> System.out.println("Created SimpleClass");
> }
> public T return_null() {
> return null;
> }
>
> }
>
>
>
> public class SimpleClass2 extends SimpleClass<Integer>{
>
> public SimpleClass2(){}
> public void testInJava(){
> System.out.println(this.return_null());
> }
> }
>
>
> It seems to me that there is some problem with methods inherited that
> returns a generic type, failing in wrapType when this is to be wrapped.
>
> The python script that fails:
>
> a= SimpleClass()
> print a.return_null()
>
> b = SimpleClass2()
> b.testInJava()
>
> print b.return_null() #Fails in wrapType
>
> I don't know if the return null is a bad thing to do in java, but the error
> seems very similar to what I experience in the larger library. I have a
> skeleton of that this is slightly larger, but not returning null, but
> trying to keep the lenght of example low :)
>
> Any comments highly appriciated :)
I've been able to reproduce the problem.
Thank you for providing an isolated test case !
Andi..
>
> best Regards
> /Petrus
>
>
>
>
>
>
> On Fri, Dec 27, 2013 at 6:25 PM, Andi Vajda <va...@apache.org> wrote:
>
>>
>>> On Dec 27, 2013, at 17:36, Petrus Hyvönen <pe...@gmail.com>
>> wrote:
>>>
>>> Dear Andi,
>>>
>>> I am working on debugging the failure and try to understand a bit how JCC
>>> works internally. I haven't gone very far but in case you have some
>>> pointers from these early debugging sessions I would be very thankful. I
>>> know it's complex, and I should try to make some smaller test cases, but
>> I
>>> don't really have a grasp yet where the problem might be.
>>>
>>> Writing this might help me also to get some structure in my thinking :)
>>>
>>>
>>>
>>> The main crash seems to be in the last line, wrapType(), of __wrap__.cpp:
>>>
>>> static PyObject
>>>
>> *t_AbstractReconfigurableDetector_withHandler(t_AbstractReconfigurableDetector
>>> *self, PyObject *arg)
>>> {
>>> ::org::orekit::propagation::events::handlers::EventHandler
>>> a0((jobject) NULL);
>>> PyTypeObject **p0;
>>> ::org::orekit::propagation::events::EventDetector
>>> result((jobject) NULL);
>>>
>>> if (!parseArg(arg, "K",
>>>
>> ::org::orekit::propagation::events::handlers::EventHandler::initializeClass,
>>> &a0, &p0,
>>>
>> ::org::orekit::propagation::events::handlers::t_EventHandler::parameters_))
>>> {
>>> OBJ_CALL(result = self->object.withHandler(a0));
>>> return self->parameters[0] != NULL ?
>>> wrapType(self->parameters[0], result.this$) :
>>> ::org::orekit::propagation::events::t_EventDetector::wrap_Object(result);
>>> }
>>>
>>> The parameters[0] does not seem to be null, but neither is it a valid
>>> object, in my debugger it says 0xbaadf00d {ob_refcnt=??? ob_type=???
>>> ob_size=??? ...} _typeobject *, wrapType is called and when trying to
>>> access the wrapfn it crashes.
>>>
>>> The main python lines are:
>>> tmp1 = ElevationDetector(sta1Frame) #
>> ElevationDetector
>>> is a java public class ElevationDetector extends
>>> AbstractReconfigurableDetector<ElevationDetector>
>>> hand = ContinueOnEvent().of_(ElevationDetector) # a
>>> java ContinueOnEvent<ElevationDetector> object
>>> elDetector = tmp1.withHandler(hand) #Crash. withHandler is a method
>>> that is inherited from AbstractReconfigurableDetector to
>> ElevationDetector
>>>
>>> This crashes when interactively entered on the python prompt (or in other
>>> interactive consoles), but seems to work if executed directly without
>>> interactivity. This difference makes me think that it might be something
>>> with garbage collection, but don't know.
>>>
>>> Any comments appriciated, I know this is likely very difficult to comment
>>> on as it's not very encapsulated.
>>
>> Right, so unless you can isolate this into something I can reproduce, I'm
>> afraid there isn't much I can comment.
>> It is quite likely that by the time you have that reproducible test case
>> ready, you also have the solution to the problem. Or I might be able to
>> help then...
>>
>> Andi..
>>
>>>
>>> Regards
>>> /Petrus
>>>
>>>
>>>
>>>
>>>
>>>
>>>> On Sun, Dec 15, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>>>>
>>>>
>>>>>> On Dec 15, 2013, at 5:43, Petrus Hyvönen <pe...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hi Andi,
>>>>>
>>>>> I see your point and have now kept in the pure python domain.
>>>>>
>>>>> If I run my script from the shell by "python script.py" it does not
>>>> crash. However if I execute it line-by-line in python it crashes (or in
>>>> other tools such as ipython notebook).
>>>>> All classes used are non-wrapped java classes, but I get the same
>> effect
>>>> with classes made for python subclassing.
>>>>> I am getting this on both MacOSX 64-bit python and Windows 7 32-bit
>>>> python.
>>>>>
>>>>>
>>>>>>>> elDetector =
>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>> #
>>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>>> #
>>>>> # SIGSEGV (0xb) at pc=0x000000010005da1a, pid=3318, tid=1287
>>>>> #
>>>>> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
>>>> 1.7.0_45-b18)
>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
>>>> bsd-amd64 compressed oops)
>>>>> # Problematic frame:
>>>>> # C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>>>> #
>>>>>
>>>>>
>>>>> from the stack it seems like there is somthing happening in "wrapType"
>>>>> Stack: [0x00007fff5fb80000,0x00007fff5fc00000], sp=0x00007fff5fbff470,
>>>> free space=509k
>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>>> C=native code)
>>>>> C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>>>> C [_orekit.so+0xa80878] wrapType(_typeobject*, _jobject* const&)+0x58
>>>>> C [_orekit.so+0x554400]
>>>>
>> org::orekit::propagation::events::t_AbstractReconfigurableDetector_withHandler(org::orekit::propagation::events::t_AbstractReconfigurableDetector*,
>>>> _object*)+0x1c0
>>>>>
>>>>> First, is the generic class assignment correct as if to write "new
>>>> ContinueOnEvent<ElevationDetector>()" in java? And is it ok to use
>> regular
>>>> java objects/types?
>>>>>
>>>>> Any other comments to move forward highly appriciated.. Is it somehow
>>>> possible to get more log what is going wrong?
>>>>
>>>> You could compile the whole thing for debugging, by adding --debug after
>>>> 'build' in the jcc invocation and run it with gdb.
>>>>
>>>> If you can isolate a reproducible crash into a small test case, I can
>> also
>>>> take a look at it.
>>>>
>>>> Andi..
>>>>
>>>>>
>>>>> WIth best regards
>>>>> /Petrus
>>>>>
>>>>>
>>>>>
>>>>>> On 15 Dec 2013, at 2:40 , Andi Vajda <va...@apache.org> wrote:
>>>>>>
>>>>>>
>>>>>>> On Dec 14, 2013, at 19:14, Petrus Hyvönen <pe...@gmail.com>
>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm having a problem with I think might be related to generic types,
>>>> but not sure at all.
>>>>>>>
>>>>>>> I'm wrapping a orbit calculation library, which has been working well
>>>> but in latest version is using generic types and I'm getting some
>> problems.
>>>> The script works when executed in plain python, but fails in ipython
>>>> notebook on this last line when executed as a couple of cells.
>>>>>>
>>>>>> What is an 'ipython notebook' ?
>>>>>>
>>>>>> Andi.,
>>>>>>
>>>>>>>
>>>>>>> The section with problem in my script is:
>>>>>>> elDetector =
>>>> ElevationDetector(sta1Frame).withConstantElevation(math.radians(5.0))
>>>>>>> elDetector =
>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>>
>>>>>>> In Java it would typically look something like:
>>>>>>>
>>>>>>> ElevationDetector detector = new ElevationDetector(topo)
>>>>>>> .withConstantElevation(x)
>>>>>>> .withHandler(new
>>>> ContinueOnEvent<ElevationDetector>());
>>>>>>>
>>>>>>> It produces correct results in plain python, but crashes the kernel
>> in
>>>> ipython if executed as cells, and in exection from spyder I get an error
>>>> message:
>>>>>>>
>>>>>>> " elDetector =
>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>> AttributeError: 'str' object has no attribute 'wrapfn_' "
>>>>>>>
>>>>>>> As I have been using this setup stabely with lots of other functions
>>>> it feels like there is something with the generic type line, but I don't
>>>> really know how to get any further? I'm confused by that the pauses in
>> the
>>>> execution could seem to affect the result.
>>>>>>>
>>>>>>> Any comments highly appriciated...
>>>>>>>
>>>>>>> Best Regards
>>>>>>> /Petrus
>>>
>>>
>>>
>>> --
>>> _____________________________________________
>>> Petrus Hyvönen, Uppsala, Sweden
>>> Mobile Phone/SMS:+46 73 803 19 00
>>
>
>
>
> --
> _____________________________________________
> Petrus Hyvönen, Uppsala, Sweden
> Mobile Phone/SMS:+46 73 803 19 00
>
Re: Problem using generic types?
Posted by Andi Vajda <va...@apache.org>.
> On Dec 29, 2013, at 17:02, Petrus Hyvönen <pe...@gmail.com> wrote:
>
> Dear Andi,
>
> I have distilled the library that I have some trouble with and I think I
> have an example that is failing due to same problem I think. I am not good
> in java, but have tried to follow the logic from the library I'm wrapping.
> The function of the example does not make sense in itself.
>
> public class SimpleClass<T> {
> public SimpleClass() {
> System.out.println("Created SimpleClass");
> }
> public T return_null() {
> return null;
> }
>
> }
>
>
>
> public class SimpleClass2 extends SimpleClass<Integer>{
>
> public SimpleClass2(){}
> public void testInJava(){
> System.out.println(this.return_null());
> }
> }
>
>
> It seems to me that there is some problem with methods inherited that
> returns a generic type, failing in wrapType when this is to be wrapped.
>
> The python script that fails:
>
> a= SimpleClass()
> print a.return_null()
>
> b = SimpleClass2()
> b.testInJava()
>
> print b.return_null() #Fails in wrapType
>
> I don't know if the return null is a bad thing to do in java, but the error
> seems very similar to what I experience in the larger library. I have a
> skeleton of that this is slightly larger, but not returning null, but
> trying to keep the lenght of example low :)
>
> Any comments highly appriciated :)
Thank you for the effort.
I'll take a look...
Andi..
>
> best Regards
> /Petrus
>
>
>
>
>
>
>> On Fri, Dec 27, 2013 at 6:25 PM, Andi Vajda <va...@apache.org> wrote:
>>
>>
>>>> On Dec 27, 2013, at 17:36, Petrus Hyvönen <pe...@gmail.com>
>>> wrote:
>>>
>>> Dear Andi,
>>>
>>> I am working on debugging the failure and try to understand a bit how JCC
>>> works internally. I haven't gone very far but in case you have some
>>> pointers from these early debugging sessions I would be very thankful. I
>>> know it's complex, and I should try to make some smaller test cases, but
>> I
>>> don't really have a grasp yet where the problem might be.
>>>
>>> Writing this might help me also to get some structure in my thinking :)
>>>
>>>
>>>
>>> The main crash seems to be in the last line, wrapType(), of __wrap__.cpp:
>>>
>>> static PyObject
>> *t_AbstractReconfigurableDetector_withHandler(t_AbstractReconfigurableDetector
>>> *self, PyObject *arg)
>>> {
>>> ::org::orekit::propagation::events::handlers::EventHandler
>>> a0((jobject) NULL);
>>> PyTypeObject **p0;
>>> ::org::orekit::propagation::events::EventDetector
>>> result((jobject) NULL);
>>>
>>> if (!parseArg(arg, "K",
>> ::org::orekit::propagation::events::handlers::EventHandler::initializeClass,
>>> &a0, &p0,
>> ::org::orekit::propagation::events::handlers::t_EventHandler::parameters_))
>>> {
>>> OBJ_CALL(result = self->object.withHandler(a0));
>>> return self->parameters[0] != NULL ?
>>> wrapType(self->parameters[0], result.this$) :
>>> ::org::orekit::propagation::events::t_EventDetector::wrap_Object(result);
>>> }
>>>
>>> The parameters[0] does not seem to be null, but neither is it a valid
>>> object, in my debugger it says 0xbaadf00d {ob_refcnt=??? ob_type=???
>>> ob_size=??? ...} _typeobject *, wrapType is called and when trying to
>>> access the wrapfn it crashes.
>>>
>>> The main python lines are:
>>> tmp1 = ElevationDetector(sta1Frame) #
>> ElevationDetector
>>> is a java public class ElevationDetector extends
>>> AbstractReconfigurableDetector<ElevationDetector>
>>> hand = ContinueOnEvent().of_(ElevationDetector) # a
>>> java ContinueOnEvent<ElevationDetector> object
>>> elDetector = tmp1.withHandler(hand) #Crash. withHandler is a method
>>> that is inherited from AbstractReconfigurableDetector to
>> ElevationDetector
>>>
>>> This crashes when interactively entered on the python prompt (or in other
>>> interactive consoles), but seems to work if executed directly without
>>> interactivity. This difference makes me think that it might be something
>>> with garbage collection, but don't know.
>>>
>>> Any comments appriciated, I know this is likely very difficult to comment
>>> on as it's not very encapsulated.
>>
>> Right, so unless you can isolate this into something I can reproduce, I'm
>> afraid there isn't much I can comment.
>> It is quite likely that by the time you have that reproducible test case
>> ready, you also have the solution to the problem. Or I might be able to
>> help then...
>>
>> Andi..
>>
>>>
>>> Regards
>>> /Petrus
>>>
>>>
>>>
>>>
>>>
>>>
>>>> On Sun, Dec 15, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>>>>
>>>>
>>>>>> On Dec 15, 2013, at 5:43, Petrus Hyvönen <pe...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hi Andi,
>>>>>
>>>>> I see your point and have now kept in the pure python domain.
>>>>>
>>>>> If I run my script from the shell by "python script.py" it does not
>>>> crash. However if I execute it line-by-line in python it crashes (or in
>>>> other tools such as ipython notebook).
>>>>> All classes used are non-wrapped java classes, but I get the same
>> effect
>>>> with classes made for python subclassing.
>>>>> I am getting this on both MacOSX 64-bit python and Windows 7 32-bit
>>>> python.
>>>>>
>>>>>
>>>>>>>> elDetector =
>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>> #
>>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>>> #
>>>>> # SIGSEGV (0xb) at pc=0x000000010005da1a, pid=3318, tid=1287
>>>>> #
>>>>> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
>>>> 1.7.0_45-b18)
>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
>>>> bsd-amd64 compressed oops)
>>>>> # Problematic frame:
>>>>> # C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>>>> #
>>>>>
>>>>>
>>>>> from the stack it seems like there is somthing happening in "wrapType"
>>>>> Stack: [0x00007fff5fb80000,0x00007fff5fc00000], sp=0x00007fff5fbff470,
>>>> free space=509k
>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>>> C=native code)
>>>>> C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>>>> C [_orekit.so+0xa80878] wrapType(_typeobject*, _jobject* const&)+0x58
>>>>> C [_orekit.so+0x554400]
>> org::orekit::propagation::events::t_AbstractReconfigurableDetector_withHandler(org::orekit::propagation::events::t_AbstractReconfigurableDetector*,
>>>> _object*)+0x1c0
>>>>>
>>>>> First, is the generic class assignment correct as if to write "new
>>>> ContinueOnEvent<ElevationDetector>()" in java? And is it ok to use
>> regular
>>>> java objects/types?
>>>>>
>>>>> Any other comments to move forward highly appriciated.. Is it somehow
>>>> possible to get more log what is going wrong?
>>>>
>>>> You could compile the whole thing for debugging, by adding --debug after
>>>> 'build' in the jcc invocation and run it with gdb.
>>>>
>>>> If you can isolate a reproducible crash into a small test case, I can
>> also
>>>> take a look at it.
>>>>
>>>> Andi..
>>>>
>>>>>
>>>>> WIth best regards
>>>>> /Petrus
>>>>>
>>>>>
>>>>>
>>>>>> On 15 Dec 2013, at 2:40 , Andi Vajda <va...@apache.org> wrote:
>>>>>>
>>>>>>
>>>>>>> On Dec 14, 2013, at 19:14, Petrus Hyvönen <pe...@gmail.com>
>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm having a problem with I think might be related to generic types,
>>>> but not sure at all.
>>>>>>>
>>>>>>> I'm wrapping a orbit calculation library, which has been working well
>>>> but in latest version is using generic types and I'm getting some
>> problems.
>>>> The script works when executed in plain python, but fails in ipython
>>>> notebook on this last line when executed as a couple of cells.
>>>>>>
>>>>>> What is an 'ipython notebook' ?
>>>>>>
>>>>>> Andi.,
>>>>>>
>>>>>>>
>>>>>>> The section with problem in my script is:
>>>>>>> elDetector =
>>>> ElevationDetector(sta1Frame).withConstantElevation(math.radians(5.0))
>>>>>>> elDetector =
>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>>
>>>>>>> In Java it would typically look something like:
>>>>>>>
>>>>>>> ElevationDetector detector = new ElevationDetector(topo)
>>>>>>> .withConstantElevation(x)
>>>>>>> .withHandler(new
>>>> ContinueOnEvent<ElevationDetector>());
>>>>>>>
>>>>>>> It produces correct results in plain python, but crashes the kernel
>> in
>>>> ipython if executed as cells, and in exection from spyder I get an error
>>>> message:
>>>>>>>
>>>>>>> " elDetector =
>>>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>>> AttributeError: 'str' object has no attribute 'wrapfn_' "
>>>>>>>
>>>>>>> As I have been using this setup stabely with lots of other functions
>>>> it feels like there is something with the generic type line, but I don't
>>>> really know how to get any further? I'm confused by that the pauses in
>> the
>>>> execution could seem to affect the result.
>>>>>>>
>>>>>>> Any comments highly appriciated...
>>>>>>>
>>>>>>> Best Regards
>>>>>>> /Petrus
>>>
>>>
>>>
>>> --
>>> _____________________________________________
>>> Petrus Hyvönen, Uppsala, Sweden
>>> Mobile Phone/SMS:+46 73 803 19 00
>
>
>
> --
> _____________________________________________
> Petrus Hyvönen, Uppsala, Sweden
> Mobile Phone/SMS:+46 73 803 19 00
Re: Problem using generic types?
Posted by Petrus Hyvönen <pe...@gmail.com>.
Dear Andi,
I have distilled the library that I have some trouble with and I think I
have an example that is failing due to same problem I think. I am not good
in java, but have tried to follow the logic from the library I'm wrapping.
The function of the example does not make sense in itself.
public class SimpleClass<T> {
public SimpleClass() {
System.out.println("Created SimpleClass");
}
public T return_null() {
return null;
}
}
public class SimpleClass2 extends SimpleClass<Integer>{
public SimpleClass2(){}
public void testInJava(){
System.out.println(this.return_null());
}
}
It seems to me that there is some problem with methods inherited that
returns a generic type, failing in wrapType when this is to be wrapped.
The python script that fails:
a= SimpleClass()
print a.return_null()
b = SimpleClass2()
b.testInJava()
print b.return_null() #Fails in wrapType
I don't know if the return null is a bad thing to do in java, but the error
seems very similar to what I experience in the larger library. I have a
skeleton of that this is slightly larger, but not returning null, but
trying to keep the lenght of example low :)
Any comments highly appriciated :)
best Regards
/Petrus
On Fri, Dec 27, 2013 at 6:25 PM, Andi Vajda <va...@apache.org> wrote:
>
> > On Dec 27, 2013, at 17:36, Petrus Hyvönen <pe...@gmail.com>
> wrote:
> >
> > Dear Andi,
> >
> > I am working on debugging the failure and try to understand a bit how JCC
> > works internally. I haven't gone very far but in case you have some
> > pointers from these early debugging sessions I would be very thankful. I
> > know it's complex, and I should try to make some smaller test cases, but
> I
> > don't really have a grasp yet where the problem might be.
> >
> > Writing this might help me also to get some structure in my thinking :)
> >
> >
> >
> > The main crash seems to be in the last line, wrapType(), of __wrap__.cpp:
> >
> > static PyObject
> >
> *t_AbstractReconfigurableDetector_withHandler(t_AbstractReconfigurableDetector
> > *self, PyObject *arg)
> > {
> > ::org::orekit::propagation::events::handlers::EventHandler
> > a0((jobject) NULL);
> > PyTypeObject **p0;
> > ::org::orekit::propagation::events::EventDetector
> > result((jobject) NULL);
> >
> > if (!parseArg(arg, "K",
> >
> ::org::orekit::propagation::events::handlers::EventHandler::initializeClass,
> > &a0, &p0,
> >
> ::org::orekit::propagation::events::handlers::t_EventHandler::parameters_))
> > {
> > OBJ_CALL(result = self->object.withHandler(a0));
> > return self->parameters[0] != NULL ?
> > wrapType(self->parameters[0], result.this$) :
> > ::org::orekit::propagation::events::t_EventDetector::wrap_Object(result);
> > }
> >
> > The parameters[0] does not seem to be null, but neither is it a valid
> > object, in my debugger it says 0xbaadf00d {ob_refcnt=??? ob_type=???
> > ob_size=??? ...} _typeobject *, wrapType is called and when trying to
> > access the wrapfn it crashes.
> >
> > The main python lines are:
> > tmp1 = ElevationDetector(sta1Frame) #
> ElevationDetector
> > is a java public class ElevationDetector extends
> > AbstractReconfigurableDetector<ElevationDetector>
> > hand = ContinueOnEvent().of_(ElevationDetector) # a
> > java ContinueOnEvent<ElevationDetector> object
> > elDetector = tmp1.withHandler(hand) #Crash. withHandler is a method
> > that is inherited from AbstractReconfigurableDetector to
> ElevationDetector
> >
> > This crashes when interactively entered on the python prompt (or in other
> > interactive consoles), but seems to work if executed directly without
> > interactivity. This difference makes me think that it might be something
> > with garbage collection, but don't know.
> >
> > Any comments appriciated, I know this is likely very difficult to comment
> > on as it's not very encapsulated.
>
> Right, so unless you can isolate this into something I can reproduce, I'm
> afraid there isn't much I can comment.
> It is quite likely that by the time you have that reproducible test case
> ready, you also have the solution to the problem. Or I might be able to
> help then...
>
> Andi..
>
> >
> > Regards
> > /Petrus
> >
> >
> >
> >
> >
> >
> >> On Sun, Dec 15, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
> >>
> >>
> >>>> On Dec 15, 2013, at 5:43, Petrus Hyvönen <pe...@gmail.com>
> >>> wrote:
> >>>
> >>> Hi Andi,
> >>>
> >>> I see your point and have now kept in the pure python domain.
> >>>
> >>> If I run my script from the shell by "python script.py" it does not
> >> crash. However if I execute it line-by-line in python it crashes (or in
> >> other tools such as ipython notebook).
> >>> All classes used are non-wrapped java classes, but I get the same
> effect
> >> with classes made for python subclassing.
> >>> I am getting this on both MacOSX 64-bit python and Windows 7 32-bit
> >> python.
> >>>
> >>>
> >>>>>> elDetector =
> >> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
> >>> #
> >>> # A fatal error has been detected by the Java Runtime Environment:
> >>> #
> >>> # SIGSEGV (0xb) at pc=0x000000010005da1a, pid=3318, tid=1287
> >>> #
> >>> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
> >> 1.7.0_45-b18)
> >>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
> >> bsd-amd64 compressed oops)
> >>> # Problematic frame:
> >>> # C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
> >>> #
> >>>
> >>>
> >>> from the stack it seems like there is somthing happening in "wrapType"
> >>> Stack: [0x00007fff5fb80000,0x00007fff5fc00000], sp=0x00007fff5fbff470,
> >> free space=509k
> >>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
> >> C=native code)
> >>> C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
> >>> C [_orekit.so+0xa80878] wrapType(_typeobject*, _jobject* const&)+0x58
> >>> C [_orekit.so+0x554400]
> >>
> org::orekit::propagation::events::t_AbstractReconfigurableDetector_withHandler(org::orekit::propagation::events::t_AbstractReconfigurableDetector*,
> >> _object*)+0x1c0
> >>>
> >>> First, is the generic class assignment correct as if to write "new
> >> ContinueOnEvent<ElevationDetector>()" in java? And is it ok to use
> regular
> >> java objects/types?
> >>>
> >>> Any other comments to move forward highly appriciated.. Is it somehow
> >> possible to get more log what is going wrong?
> >>
> >> You could compile the whole thing for debugging, by adding --debug after
> >> 'build' in the jcc invocation and run it with gdb.
> >>
> >> If you can isolate a reproducible crash into a small test case, I can
> also
> >> take a look at it.
> >>
> >> Andi..
> >>
> >>>
> >>> WIth best regards
> >>> /Petrus
> >>>
> >>>
> >>>
> >>>> On 15 Dec 2013, at 2:40 , Andi Vajda <va...@apache.org> wrote:
> >>>>
> >>>>
> >>>>> On Dec 14, 2013, at 19:14, Petrus Hyvönen <pe...@gmail.com>
> >> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I'm having a problem with I think might be related to generic types,
> >> but not sure at all.
> >>>>>
> >>>>> I'm wrapping a orbit calculation library, which has been working well
> >> but in latest version is using generic types and I'm getting some
> problems.
> >> The script works when executed in plain python, but fails in ipython
> >> notebook on this last line when executed as a couple of cells.
> >>>>
> >>>> What is an 'ipython notebook' ?
> >>>>
> >>>> Andi.,
> >>>>
> >>>>>
> >>>>> The section with problem in my script is:
> >>>>> elDetector =
> >> ElevationDetector(sta1Frame).withConstantElevation(math.radians(5.0))
> >>>>> elDetector =
> >> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
> >>>>>
> >>>>> In Java it would typically look something like:
> >>>>>
> >>>>> ElevationDetector detector = new ElevationDetector(topo)
> >>>>> .withConstantElevation(x)
> >>>>> .withHandler(new
> >> ContinueOnEvent<ElevationDetector>());
> >>>>>
> >>>>> It produces correct results in plain python, but crashes the kernel
> in
> >> ipython if executed as cells, and in exection from spyder I get an error
> >> message:
> >>>>>
> >>>>> " elDetector =
> >> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
> >>>>> AttributeError: 'str' object has no attribute 'wrapfn_' "
> >>>>>
> >>>>> As I have been using this setup stabely with lots of other functions
> >> it feels like there is something with the generic type line, but I don't
> >> really know how to get any further? I'm confused by that the pauses in
> the
> >> execution could seem to affect the result.
> >>>>>
> >>>>> Any comments highly appriciated...
> >>>>>
> >>>>> Best Regards
> >>>>> /Petrus
> >
> >
> >
> > --
> > _____________________________________________
> > Petrus Hyvönen, Uppsala, Sweden
> > Mobile Phone/SMS:+46 73 803 19 00
>
--
_____________________________________________
Petrus Hyvönen, Uppsala, Sweden
Mobile Phone/SMS:+46 73 803 19 00
Re: Problem using generic types?
Posted by Andi Vajda <va...@apache.org>.
> On Dec 27, 2013, at 17:36, Petrus Hyvönen <pe...@gmail.com> wrote:
>
> Dear Andi,
>
> I am working on debugging the failure and try to understand a bit how JCC
> works internally. I haven't gone very far but in case you have some
> pointers from these early debugging sessions I would be very thankful. I
> know it's complex, and I should try to make some smaller test cases, but I
> don't really have a grasp yet where the problem might be.
>
> Writing this might help me also to get some structure in my thinking :)
>
>
>
> The main crash seems to be in the last line, wrapType(), of __wrap__.cpp:
>
> static PyObject
> *t_AbstractReconfigurableDetector_withHandler(t_AbstractReconfigurableDetector
> *self, PyObject *arg)
> {
> ::org::orekit::propagation::events::handlers::EventHandler
> a0((jobject) NULL);
> PyTypeObject **p0;
> ::org::orekit::propagation::events::EventDetector
> result((jobject) NULL);
>
> if (!parseArg(arg, "K",
> ::org::orekit::propagation::events::handlers::EventHandler::initializeClass,
> &a0, &p0,
> ::org::orekit::propagation::events::handlers::t_EventHandler::parameters_))
> {
> OBJ_CALL(result = self->object.withHandler(a0));
> return self->parameters[0] != NULL ?
> wrapType(self->parameters[0], result.this$) :
> ::org::orekit::propagation::events::t_EventDetector::wrap_Object(result);
> }
>
> The parameters[0] does not seem to be null, but neither is it a valid
> object, in my debugger it says 0xbaadf00d {ob_refcnt=??? ob_type=???
> ob_size=??? ...} _typeobject *, wrapType is called and when trying to
> access the wrapfn it crashes.
>
> The main python lines are:
> tmp1 = ElevationDetector(sta1Frame) # ElevationDetector
> is a java public class ElevationDetector extends
> AbstractReconfigurableDetector<ElevationDetector>
> hand = ContinueOnEvent().of_(ElevationDetector) # a
> java ContinueOnEvent<ElevationDetector> object
> elDetector = tmp1.withHandler(hand) #Crash. withHandler is a method
> that is inherited from AbstractReconfigurableDetector to ElevationDetector
>
> This crashes when interactively entered on the python prompt (or in other
> interactive consoles), but seems to work if executed directly without
> interactivity. This difference makes me think that it might be something
> with garbage collection, but don't know.
>
> Any comments appriciated, I know this is likely very difficult to comment
> on as it's not very encapsulated.
Right, so unless you can isolate this into something I can reproduce, I'm afraid there isn't much I can comment.
It is quite likely that by the time you have that reproducible test case ready, you also have the solution to the problem. Or I might be able to help then...
Andi..
>
> Regards
> /Petrus
>
>
>
>
>
>
>> On Sun, Dec 15, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>>
>>
>>>> On Dec 15, 2013, at 5:43, Petrus Hyvönen <pe...@gmail.com>
>>> wrote:
>>>
>>> Hi Andi,
>>>
>>> I see your point and have now kept in the pure python domain.
>>>
>>> If I run my script from the shell by "python script.py" it does not
>> crash. However if I execute it line-by-line in python it crashes (or in
>> other tools such as ipython notebook).
>>> All classes used are non-wrapped java classes, but I get the same effect
>> with classes made for python subclassing.
>>> I am getting this on both MacOSX 64-bit python and Windows 7 32-bit
>> python.
>>>
>>>
>>>>>> elDetector =
>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> #
>>> # SIGSEGV (0xb) at pc=0x000000010005da1a, pid=3318, tid=1287
>>> #
>>> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
>> 1.7.0_45-b18)
>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
>> bsd-amd64 compressed oops)
>>> # Problematic frame:
>>> # C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>> #
>>>
>>>
>>> from the stack it seems like there is somthing happening in "wrapType"
>>> Stack: [0x00007fff5fb80000,0x00007fff5fc00000], sp=0x00007fff5fbff470,
>> free space=509k
>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>> C=native code)
>>> C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
>>> C [_orekit.so+0xa80878] wrapType(_typeobject*, _jobject* const&)+0x58
>>> C [_orekit.so+0x554400]
>> org::orekit::propagation::events::t_AbstractReconfigurableDetector_withHandler(org::orekit::propagation::events::t_AbstractReconfigurableDetector*,
>> _object*)+0x1c0
>>>
>>> First, is the generic class assignment correct as if to write "new
>> ContinueOnEvent<ElevationDetector>()" in java? And is it ok to use regular
>> java objects/types?
>>>
>>> Any other comments to move forward highly appriciated.. Is it somehow
>> possible to get more log what is going wrong?
>>
>> You could compile the whole thing for debugging, by adding --debug after
>> 'build' in the jcc invocation and run it with gdb.
>>
>> If you can isolate a reproducible crash into a small test case, I can also
>> take a look at it.
>>
>> Andi..
>>
>>>
>>> WIth best regards
>>> /Petrus
>>>
>>>
>>>
>>>> On 15 Dec 2013, at 2:40 , Andi Vajda <va...@apache.org> wrote:
>>>>
>>>>
>>>>> On Dec 14, 2013, at 19:14, Petrus Hyvönen <pe...@gmail.com>
>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm having a problem with I think might be related to generic types,
>> but not sure at all.
>>>>>
>>>>> I'm wrapping a orbit calculation library, which has been working well
>> but in latest version is using generic types and I'm getting some problems.
>> The script works when executed in plain python, but fails in ipython
>> notebook on this last line when executed as a couple of cells.
>>>>
>>>> What is an 'ipython notebook' ?
>>>>
>>>> Andi.,
>>>>
>>>>>
>>>>> The section with problem in my script is:
>>>>> elDetector =
>> ElevationDetector(sta1Frame).withConstantElevation(math.radians(5.0))
>>>>> elDetector =
>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>>
>>>>> In Java it would typically look something like:
>>>>>
>>>>> ElevationDetector detector = new ElevationDetector(topo)
>>>>> .withConstantElevation(x)
>>>>> .withHandler(new
>> ContinueOnEvent<ElevationDetector>());
>>>>>
>>>>> It produces correct results in plain python, but crashes the kernel in
>> ipython if executed as cells, and in exection from spyder I get an error
>> message:
>>>>>
>>>>> " elDetector =
>> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>>> AttributeError: 'str' object has no attribute 'wrapfn_' "
>>>>>
>>>>> As I have been using this setup stabely with lots of other functions
>> it feels like there is something with the generic type line, but I don't
>> really know how to get any further? I'm confused by that the pauses in the
>> execution could seem to affect the result.
>>>>>
>>>>> Any comments highly appriciated...
>>>>>
>>>>> Best Regards
>>>>> /Petrus
>
>
>
> --
> _____________________________________________
> Petrus Hyvönen, Uppsala, Sweden
> Mobile Phone/SMS:+46 73 803 19 00
Re: Problem using generic types?
Posted by Petrus Hyvönen <pe...@gmail.com>.
Dear Andi,
I am working on debugging the failure and try to understand a bit how JCC
works internally. I haven't gone very far but in case you have some
pointers from these early debugging sessions I would be very thankful. I
know it's complex, and I should try to make some smaller test cases, but I
don't really have a grasp yet where the problem might be.
Writing this might help me also to get some structure in my thinking :)
The main crash seems to be in the last line, wrapType(), of __wrap__.cpp:
static PyObject
*t_AbstractReconfigurableDetector_withHandler(t_AbstractReconfigurableDetector
*self, PyObject *arg)
{
::org::orekit::propagation::events::handlers::EventHandler
a0((jobject) NULL);
PyTypeObject **p0;
::org::orekit::propagation::events::EventDetector
result((jobject) NULL);
if (!parseArg(arg, "K",
::org::orekit::propagation::events::handlers::EventHandler::initializeClass,
&a0, &p0,
::org::orekit::propagation::events::handlers::t_EventHandler::parameters_))
{
OBJ_CALL(result = self->object.withHandler(a0));
return self->parameters[0] != NULL ?
wrapType(self->parameters[0], result.this$) :
::org::orekit::propagation::events::t_EventDetector::wrap_Object(result);
}
The parameters[0] does not seem to be null, but neither is it a valid
object, in my debugger it says 0xbaadf00d {ob_refcnt=??? ob_type=???
ob_size=??? ...} _typeobject *, wrapType is called and when trying to
access the wrapfn it crashes.
The main python lines are:
tmp1 = ElevationDetector(sta1Frame) # ElevationDetector
is a java public class ElevationDetector extends
AbstractReconfigurableDetector<ElevationDetector>
hand = ContinueOnEvent().of_(ElevationDetector) # a
java ContinueOnEvent<ElevationDetector> object
elDetector = tmp1.withHandler(hand) #Crash. withHandler is a method
that is inherited from AbstractReconfigurableDetector to ElevationDetector
This crashes when interactively entered on the python prompt (or in other
interactive consoles), but seems to work if executed directly without
interactivity. This difference makes me think that it might be something
with garbage collection, but don't know.
Any comments appriciated, I know this is likely very difficult to comment
on as it's not very encapsulated.
Regards
/Petrus
On Sun, Dec 15, 2013 at 10:36 AM, Andi Vajda <va...@apache.org> wrote:
>
> > On Dec 15, 2013, at 5:43, Petrus Hyvönen <pe...@gmail.com>
> wrote:
> >
> > Hi Andi,
> >
> > I see your point and have now kept in the pure python domain.
> >
> > If I run my script from the shell by "python script.py" it does not
> crash. However if I execute it line-by-line in python it crashes (or in
> other tools such as ipython notebook).
> > All classes used are non-wrapped java classes, but I get the same effect
> with classes made for python subclassing.
> > I am getting this on both MacOSX 64-bit python and Windows 7 32-bit
> python.
> >
> >
> >>>> elDetector =
> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
> > #
> > # A fatal error has been detected by the Java Runtime Environment:
> > #
> > # SIGSEGV (0xb) at pc=0x000000010005da1a, pid=3318, tid=1287
> > #
> > # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
> 1.7.0_45-b18)
> > # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
> bsd-amd64 compressed oops)
> > # Problematic frame:
> > # C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
> > #
> >
> >
> > from the stack it seems like there is somthing happening in "wrapType"
> > Stack: [0x00007fff5fb80000,0x00007fff5fc00000], sp=0x00007fff5fbff470,
> free space=509k
> > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
> C=native code)
> > C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
> > C [_orekit.so+0xa80878] wrapType(_typeobject*, _jobject* const&)+0x58
> > C [_orekit.so+0x554400]
> org::orekit::propagation::events::t_AbstractReconfigurableDetector_withHandler(org::orekit::propagation::events::t_AbstractReconfigurableDetector*,
> _object*)+0x1c0
> >
> > First, is the generic class assignment correct as if to write "new
> ContinueOnEvent<ElevationDetector>()" in java? And is it ok to use regular
> java objects/types?
> >
> > Any other comments to move forward highly appriciated.. Is it somehow
> possible to get more log what is going wrong?
>
> You could compile the whole thing for debugging, by adding --debug after
> 'build' in the jcc invocation and run it with gdb.
>
> If you can isolate a reproducible crash into a small test case, I can also
> take a look at it.
>
> Andi..
>
> >
> > WIth best regards
> > /Petrus
> >
> >
> >
> >> On 15 Dec 2013, at 2:40 , Andi Vajda <va...@apache.org> wrote:
> >>
> >>
> >>> On Dec 14, 2013, at 19:14, Petrus Hyvönen <pe...@gmail.com>
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I'm having a problem with I think might be related to generic types,
> but not sure at all.
> >>>
> >>> I'm wrapping a orbit calculation library, which has been working well
> but in latest version is using generic types and I'm getting some problems.
> The script works when executed in plain python, but fails in ipython
> notebook on this last line when executed as a couple of cells.
> >>
> >> What is an 'ipython notebook' ?
> >>
> >> Andi.,
> >>
> >>>
> >>> The section with problem in my script is:
> >>> elDetector =
> ElevationDetector(sta1Frame).withConstantElevation(math.radians(5.0))
> >>> elDetector =
> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
> >>>
> >>> In Java it would typically look something like:
> >>>
> >>> ElevationDetector detector = new ElevationDetector(topo)
> >>> .withConstantElevation(x)
> >>> .withHandler(new
> ContinueOnEvent<ElevationDetector>());
> >>>
> >>> It produces correct results in plain python, but crashes the kernel in
> ipython if executed as cells, and in exection from spyder I get an error
> message:
> >>>
> >>> " elDetector =
> elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
> >>> AttributeError: 'str' object has no attribute 'wrapfn_' "
> >>>
> >>> As I have been using this setup stabely with lots of other functions
> it feels like there is something with the generic type line, but I don't
> really know how to get any further? I'm confused by that the pauses in the
> execution could seem to affect the result.
> >>>
> >>> Any comments highly appriciated...
> >>>
> >>> Best Regards
> >>> /Petrus
> >
>
--
_____________________________________________
Petrus Hyvönen, Uppsala, Sweden
Mobile Phone/SMS:+46 73 803 19 00
Re: Problem using generic types?
Posted by Andi Vajda <va...@apache.org>.
> On Dec 15, 2013, at 5:43, Petrus Hyvönen <pe...@gmail.com> wrote:
>
> Hi Andi,
>
> I see your point and have now kept in the pure python domain.
>
> If I run my script from the shell by "python script.py" it does not crash. However if I execute it line-by-line in python it crashes (or in other tools such as ipython notebook).
> All classes used are non-wrapped java classes, but I get the same effect with classes made for python subclassing.
> I am getting this on both MacOSX 64-bit python and Windows 7 32-bit python.
>
>
>>>> elDetector = elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x000000010005da1a, pid=3318, tid=1287
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build 1.7.0_45-b18)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode bsd-amd64 compressed oops)
> # Problematic frame:
> # C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
> #
>
>
> from the stack it seems like there is somthing happening in "wrapType"
> Stack: [0x00007fff5fb80000,0x00007fff5fc00000], sp=0x00007fff5fbff470, free space=509k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
> C [_orekit.so+0xa80878] wrapType(_typeobject*, _jobject* const&)+0x58
> C [_orekit.so+0x554400] org::orekit::propagation::events::t_AbstractReconfigurableDetector_withHandler(org::orekit::propagation::events::t_AbstractReconfigurableDetector*, _object*)+0x1c0
>
> First, is the generic class assignment correct as if to write "new ContinueOnEvent<ElevationDetector>()" in java? And is it ok to use regular java objects/types?
>
> Any other comments to move forward highly appriciated.. Is it somehow possible to get more log what is going wrong?
You could compile the whole thing for debugging, by adding --debug after 'build' in the jcc invocation and run it with gdb.
If you can isolate a reproducible crash into a small test case, I can also take a look at it.
Andi..
>
> WIth best regards
> /Petrus
>
>
>
>> On 15 Dec 2013, at 2:40 , Andi Vajda <va...@apache.org> wrote:
>>
>>
>>> On Dec 14, 2013, at 19:14, Petrus Hyvönen <pe...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> I'm having a problem with I think might be related to generic types, but not sure at all.
>>>
>>> I'm wrapping a orbit calculation library, which has been working well but in latest version is using generic types and I'm getting some problems. The script works when executed in plain python, but fails in ipython notebook on this last line when executed as a couple of cells.
>>
>> What is an 'ipython notebook' ?
>>
>> Andi.,
>>
>>>
>>> The section with problem in my script is:
>>> elDetector = ElevationDetector(sta1Frame).withConstantElevation(math.radians(5.0))
>>> elDetector = elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>>
>>> In Java it would typically look something like:
>>>
>>> ElevationDetector detector = new ElevationDetector(topo)
>>> .withConstantElevation(x)
>>> .withHandler(new ContinueOnEvent<ElevationDetector>());
>>>
>>> It produces correct results in plain python, but crashes the kernel in ipython if executed as cells, and in exection from spyder I get an error message:
>>>
>>> " elDetector = elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>> AttributeError: 'str' object has no attribute 'wrapfn_' "
>>>
>>> As I have been using this setup stabely with lots of other functions it feels like there is something with the generic type line, but I don't really know how to get any further? I'm confused by that the pauses in the execution could seem to affect the result.
>>>
>>> Any comments highly appriciated...
>>>
>>> Best Regards
>>> /Petrus
>
Re: Problem using generic types?
Posted by Petrus Hyvönen <pe...@gmail.com>.
Hi Andi,
I see your point and have now kept in the pure python domain.
If I run my script from the shell by "python script.py" it does not crash. However if I execute it line-by-line in python it crashes (or in other tools such as ipython notebook).
All classes used are non-wrapped java classes, but I get the same effect with classes made for python subclassing.
I am getting this on both MacOSX 64-bit python and Windows 7 32-bit python.
>>> elDetector = elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x000000010005da1a, pid=3318, tid=1287
#
# JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build 1.7.0_45-b18)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
#
from the stack it seems like there is somthing happening in "wrapType"
Stack: [0x00007fff5fb80000,0x00007fff5fc00000], sp=0x00007fff5fbff470, free space=509k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libpython2.7.dylib+0x5aa1a] PyObject_GetAttr+0x1a
C [_orekit.so+0xa80878] wrapType(_typeobject*, _jobject* const&)+0x58
C [_orekit.so+0x554400] org::orekit::propagation::events::t_AbstractReconfigurableDetector_withHandler(org::orekit::propagation::events::t_AbstractReconfigurableDetector*, _object*)+0x1c0
First, is the generic class assignment correct as if to write "new ContinueOnEvent<ElevationDetector>()" in java? And is it ok to use regular java objects/types?
Any other comments to move forward highly appriciated.. Is it somehow possible to get more log what is going wrong?
WIth best regards
/Petrus
On 15 Dec 2013, at 2:40 , Andi Vajda <va...@apache.org> wrote:
>
>> On Dec 14, 2013, at 19:14, Petrus Hyvönen <pe...@gmail.com> wrote:
>>
>> Hi,
>>
>> I'm having a problem with I think might be related to generic types, but not sure at all.
>>
>> I'm wrapping a orbit calculation library, which has been working well but in latest version is using generic types and I'm getting some problems. The script works when executed in plain python, but fails in ipython notebook on this last line when executed as a couple of cells.
>
> What is an 'ipython notebook' ?
>
> Andi.,
>
>>
>> The section with problem in my script is:
>> elDetector = ElevationDetector(sta1Frame).withConstantElevation(math.radians(5.0))
>> elDetector = elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>>
>> In Java it would typically look something like:
>>
>> ElevationDetector detector = new ElevationDetector(topo)
>> .withConstantElevation(x)
>> .withHandler(new ContinueOnEvent<ElevationDetector>());
>>
>> It produces correct results in plain python, but crashes the kernel in ipython if executed as cells, and in exection from spyder I get an error message:
>>
>> " elDetector = elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>> AttributeError: 'str' object has no attribute 'wrapfn_' "
>>
>> As I have been using this setup stabely with lots of other functions it feels like there is something with the generic type line, but I don't really know how to get any further? I'm confused by that the pauses in the execution could seem to affect the result.
>>
>> Any comments highly appriciated...
>>
>> Best Regards
>> /Petrus
>>
Re: Problem using generic types?
Posted by Andi Vajda <va...@apache.org>.
> On Dec 14, 2013, at 19:14, Petrus Hyvönen <pe...@gmail.com> wrote:
>
> Hi,
>
> I'm having a problem with I think might be related to generic types, but not sure at all.
>
> I'm wrapping a orbit calculation library, which has been working well but in latest version is using generic types and I'm getting some problems. The script works when executed in plain python, but fails in ipython notebook on this last line when executed as a couple of cells.
What is an 'ipython notebook' ?
Andi.,
>
> The section with problem in my script is:
> elDetector = ElevationDetector(sta1Frame).withConstantElevation(math.radians(5.0))
> elDetector = elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
>
> In Java it would typically look something like:
>
> ElevationDetector detector = new ElevationDetector(topo)
> .withConstantElevation(x)
> .withHandler(new ContinueOnEvent<ElevationDetector>());
>
> It produces correct results in plain python, but crashes the kernel in ipython if executed as cells, and in exection from spyder I get an error message:
>
> " elDetector = elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
> AttributeError: 'str' object has no attribute 'wrapfn_' "
>
> As I have been using this setup stabely with lots of other functions it feels like there is something with the generic type line, but I don't really know how to get any further? I'm confused by that the pauses in the execution could seem to affect the result.
>
> Any comments highly appriciated...
>
> Best Regards
> /Petrus
>
Problem using generic types?
Posted by Petrus Hyvönen <pe...@gmail.com>.
Hi,
I'm having a problem with I think might be related to generic types, but not sure at all.
I'm wrapping a orbit calculation library, which has been working well but in latest version is using generic types and I'm getting some problems. The script works when executed in plain python, but fails in ipython notebook on this last line when executed as a couple of cells.
The section with problem in my script is:
elDetector = ElevationDetector(sta1Frame).withConstantElevation(math.radians(5.0))
elDetector = elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
In Java it would typically look something like:
ElevationDetector detector = new ElevationDetector(topo)
.withConstantElevation(x)
.withHandler(new ContinueOnEvent<ElevationDetector>());
It produces correct results in plain python, but crashes the kernel in ipython if executed as cells, and in exection from spyder I get an error message:
" elDetector = elDetector.withHandler(ContinueOnEvent().of_(ElevationDetector))
AttributeError: 'str' object has no attribute 'wrapfn_' "
As I have been using this setup stabely with lots of other functions it feels like there is something with the generic type line, but I don't really know how to get any further? I'm confused by that the pauses in the execution could seem to affect the result.
Any comments highly appriciated...
Best Regards
/Petrus
Re: Automatic typecasting of int to float
Posted by Petrus Hyvönen <pe...@gmail.com>.
Hi,
Yes sorry it should have been float(tmp).
Yes, could be added to the java code, and if it's complex its probably not an issue in many cases.
Regards
/Petrus
On 14 Dec 2013, at 20:59 , Andi Vajda <va...@apache.org> wrote:
>
>> On Dec 14, 2013, at 16:46, Petrus Hyvönen <pe...@gmail.com> wrote:
>>
>> Hi!
>>
>> I am converting some java code to python scripts, using a JCC wrapped library.
>>
>> One thing that strikes me is that java seems to have a automatic typecast of int to float, which is not present in the JCC wrapped library.
>>
>> i.e. if a tmp=100 and obj.shift(tmp) is executed, and the method expects a float, it seems to fail in the wrapped code while working in java. Of course it can be explicitly typed obj.shift((float) tmp) but it does look as readable.
>
> In python, no, that syntax is incorrect. But you could use 100.0 instead of 100. Almost as readable. Or add an intermediate method that casts to float.
>
> Could that feature be added to jcc ? sure, but it gets complicated fast. If you control both ends of the app (the python and the java code), it's easiest to add an int overload to the shift method and call the float version.
>
> Andi..
>
>>
>> This is a minor thing, but could it be enabled so that this automatic conversion from int to floats are done if no other matching signatures are found? (I assume this is the way java works, I'm no java expert..)
>>
>> Many thanks
>> /Petrus
>>
Re: Automatic typecasting of int to float
Posted by Andi Vajda <va...@apache.org>.
> On Dec 14, 2013, at 16:46, Petrus Hyvönen <pe...@gmail.com> wrote:
>
> Hi!
>
> I am converting some java code to python scripts, using a JCC wrapped library.
>
> One thing that strikes me is that java seems to have a automatic typecast of int to float, which is not present in the JCC wrapped library.
>
> i.e. if a tmp=100 and obj.shift(tmp) is executed, and the method expects a float, it seems to fail in the wrapped code while working in java. Of course it can be explicitly typed obj.shift((float) tmp) but it does look as readable.
In python, no, that syntax is incorrect. But you could use 100.0 instead of 100. Almost as readable. Or add an intermediate method that casts to float.
Could that feature be added to jcc ? sure, but it gets complicated fast. If you control both ends of the app (the python and the java code), it's easiest to add an int overload to the shift method and call the float version.
Andi..
>
> This is a minor thing, but could it be enabled so that this automatic conversion from int to floats are done if no other matching signatures are found? (I assume this is the way java works, I'm no java expert..)
>
> Many thanks
> /Petrus
>
Automatic typecasting of int to float
Posted by Petrus Hyvönen <pe...@gmail.com>.
Hi!
I am converting some java code to python scripts, using a JCC wrapped library.
One thing that strikes me is that java seems to have a automatic typecast of int to float, which is not present in the JCC wrapped library.
i.e. if a tmp=100 and obj.shift(tmp) is executed, and the method expects a float, it seems to fail in the wrapped code while working in java. Of course it can be explicitly typed obj.shift((float) tmp) but it does look as readable.
This is a minor thing, but could it be enabled so that this automatic conversion from int to floats are done if no other matching signatures are found? (I assume this is the way java works, I'm no java expert..)
Many thanks
/Petrus
Re: [NAG][VOTE] Release PyLucene 4.4.0-1
Posted by Andi Vajda <va...@apache.org>.
On Thu, 22 Aug 2013, Steve Rowe wrote:
> +1
>
> 'make test' succeeds for me on OS X 10.8.4 with stock Python 2.7.
>
> However, when I enable either the smartcn or the spatial contrib by uncommented the lines adding them to JARS in Makefile, pylucene build fails:
Some setting is probably necessary to tell the class loader where that
resource (the dictionary) is.
Andi..
>
> ====== Smartcn enabled ======
>
> /usr/bin/python -m jcc --shared --arch x86_64 --jar lucene-java-4.4.0/lucene/build/core/lucene-core-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/analysis/common/lucene-analyzers-common-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/memory/lucene-memory-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/highlighter/lucene-highlighter-4.4.0.jar --jar build/jar/extensions.jar --jar lucene-java-4.4.0/lucene/build/queries/lucene-queries-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/queryparser/lucene-queryparser-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/sandbox/lucene-sandbox-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/analysis/smartcn/lucene-analyzers-smartcn-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/analysis/stempel/lucene-analyzers-stempel-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/grouping/lucene-grouping-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/join/lucene-join-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/facet/lucene-facet-4.4.0.jar --jar lucene-ja!
va-4.4.0/lucene/build/suggest/lucene-suggest-4.4.0.jar --include lucene-java-4.4.0/lucene/build/misc/lucene-misc-4.4.0.jar --use_full_names --package java.lang java.lang.System java.lang.Runtime --package java.util java.util.Arrays java.util.Collections java.util.HashMap java.util.HashSet java.util.TreeSet java.lang.IllegalStateException java.lang.IndexOutOfBoundsException java.util.NoSuchElementException java.text.SimpleDateFormat java.text.DecimalFormat java.text.Collator --package java.util.concurrent java.util.concurrent.Executors --package java.util.regex --package java.io java.io.StringReader java.io.InputStreamReader java.io.FileInputStream java.io.DataInputStream --exclude org.apache.lucene.sandbox.queries.regex.JakartaRegexpCapabilities --exclude org.apache.regexp.RegexpTunnel --python lucene --mapping org.apache.lucene.document.Document 'get:(Ljava/lang/String;)Ljava/lang/String;' --mapping java.util.Properties 'getProperty:(Ljava/lang/String;)Ljava/lang/String;'!
--sequence java.util.AbstractList 'size:()I' 'get:(I)Ljava/lang/Object;' org.apache.lucene.index.IndexWriter:getReader --version 4.4.0 --module python/collections.py --module python/ICUNormalizer2Filter.py --module python/ICUFoldingFilter.py --module python/ICUTransformFilter.py --files 8 --build
> While loading org/apache/lucene/analysis/cn/smart/AnalyzerProfile
> Traceback (most recent call last):
> File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 162, in _run_module_as_main
> "__main__", fname, loader, pkg_name)
> File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 72, in _run_code
> exec code in run_globals
> File "/Library/Python/2.7/site-packages/JCC-2.17-py2.7-macosx-10.8-intel.egg/jcc/__main__.py", line 107, in <module>
> cpp.jcc(sys.argv)
> File "/Library/Python/2.7/site-packages/JCC-2.17-py2.7-macosx-10.8-intel.egg/jcc/cpp.py", line 583, in jcc
> cls = findClass(className.replace('.', '/'))
> File "/Library/Python/2.7/site-packages/JCC-2.17-py2.7-macosx-10.8-intel.egg/jcc/cpp.py", line 73, in findClass
> cls = _findClass(className)
> jcc.cpp.JavaError: java.lang.ExceptionInInitializerError
> Java stacktrace:
> java.lang.ExceptionInInitializerError
> Caused by: java.lang.RuntimeException: WARNING: Can not find lexical dictionary directory! This will cause unpredictable exceptions in your application! Please refer to the manual to download the dictionaries.
> at org.apache.lucene.analysis.cn.smart.AnalyzerProfile.init(AnalyzerProfile.java:72)
> at org.apache.lucene.analysis.cn.smart.AnalyzerProfile.<clinit>(AnalyzerProfile.java:43)
>
> make: *** [compile] Error 255
>
> ===============================
>
> ======= Spatial enabled =======
> /usr/bin/python -m jcc --shared --arch x86_64 --jar lucene-java-4.4.0/lucene/build/core/lucene-core-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/analysis/common/lucene-analyzers-common-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/memory/lucene-memory-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/highlighter/lucene-highlighter-4.4.0.jar --jar build/jar/extensions.jar --jar lucene-java-4.4.0/lucene/build/queries/lucene-queries-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/queryparser/lucene-queryparser-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/sandbox/lucene-sandbox-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/analysis/smartcn/lucene-analyzers-smartcn-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/analysis/stempel/lucene-analyzers-stempel-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/spatial/lucene-spatial-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/grouping/lucene-grouping-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/join/lucene-join-4.4.0.jar --jar lucen!
e-java-4.4.0/lucene/build/facet/lucene-facet-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/suggest/lucene-suggest-4.4.0.jar --include lucene-java-4.4.0/lucene/build/misc/lucene-misc-4.4.0.jar --use_full_names --package java.lang java.lang.System java.lang.Runtime --package java.util java.util.Arrays java.util.Collections java.util.HashMap java.util.HashSet java.util.TreeSet java.lang.IllegalStateException java.lang.IndexOutOfBoundsException java.util.NoSuchElementException java.text.SimpleDateFormat java.text.DecimalFormat java.text.Collator --package java.util.concurrent java.util.concurrent.Executors --package java.util.regex --package java.io java.io.StringReader java.io.InputStreamReader java.io.FileInputStream java.io.DataInputStream --exclude org.apache.lucene.sandbox.queries.regex.JakartaRegexpCapabilities --exclude org.apache.regexp.RegexpTunnel --python lucene --mapping org.apache.lucene.document.Document 'get:(Ljava/lang/String;)Ljava/lang/String;' --mapping jav!
a.util.Properties 'getProperty:(Ljava/lang/String;)Ljava/lang/String;' --sequence java.util.AbstractList 'size:()I' 'get:(I)Ljava/lang/Object;' org.apache.lucene.index.IndexWriter:getReader --version 4.4.0 --module python/collections.py --module python/ICUNormalizer2Filter.py --module python/ICUFoldingFilter.py --module python/ICUTransformFilter.py --files 8 --build
> While loading org/apache/lucene/spatial/prefix/tree/QuadPrefixTree
> Traceback (most recent call last):
> File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 162, in _run_module_as_main
> "__main__", fname, loader, pkg_name)
> File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 72, in _run_code
> exec code in run_globals
> File "/Library/Python/2.7/site-packages/JCC-2.17-py2.7-macosx-10.8-intel.egg/jcc/__main__.py", line 107, in <module>
> cpp.jcc(sys.argv)
> File "/Library/Python/2.7/site-packages/JCC-2.17-py2.7-macosx-10.8-intel.egg/jcc/cpp.py", line 583, in jcc
> cls = findClass(className.replace('.', '/'))
> File "/Library/Python/2.7/site-packages/JCC-2.17-py2.7-macosx-10.8-intel.egg/jcc/cpp.py", line 73, in findClass
> cls = _findClass(className)
> jcc.cpp.JavaError: java.lang.NoClassDefFoundError: com/spatial4j/core/shape/Shape
> Java stacktrace:
> java.lang.NoClassDefFoundError: com/spatial4j/core/shape/Shape
> Caused by: java.lang.ClassNotFoundException: com.spatial4j.core.shape.Shape
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>
> make: *** [compile] Error 255
> ===============================
>
> On Aug 22, 2013, at 5:46 AM, Andi Vajda <va...@apache.org> wrote:
>> One more PMC vote is needed for this vote pass...
>>
>> Thanks !
>>
>> Andi..
>>
>> ---------- Forwarded message ----------
>> Date: Sat, 17 Aug 2013 07:52:07 -0700 (PDT)
>> From: Andi Vajda <va...@apache.org>
>> Reply-To: pylucene-dev@lucene.apache.org, Andi Vajda <va...@apache.org>
>> To: pylucene-dev@lucene.apache.org
>> Cc: general@lucene.apache.org
>> Subject: [VOTE] Release PyLucene 4.4.0-1
>>
>>
>> The PyLucene 4.4.0-1 release tracking the recent release of Apache Lucene 4.4.0 is ready.
>>
>> A release candidate is available from:
>> http://people.apache.org/~vajda/staging_area/
>>
>> A list of changes in this release can be seen at:
>> http://svn.apache.org/repos/asf/lucene/pylucene/branches/pylucene_4_4/CHANGES
>>
>> PyLucene 4.4.0 is built with JCC 2.17 included in these release artifacts:
>> http://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/CHANGES
>>
>> A list of Lucene Java changes can be seen at:
>> http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_4_4_0/lucene/CHANGES.txt
>>
>> Please vote to release these artifacts as PyLucene 4.4.0-1.
>>
>> Thanks !
>>
>> Andi..
>>
>> ps: the KEYS file for PyLucene release signing is at:
>> http://svn.apache.org/repos/asf/lucene/pylucene/dist/KEYS
>> http://people.apache.org/~vajda/staging_area/KEYS
>>
>> pps: here is my +1
>
>
Re: [NAG][VOTE] Release PyLucene 4.4.0-1
Posted by Steve Rowe <sa...@gmail.com>.
+1
'make test' succeeds for me on OS X 10.8.4 with stock Python 2.7.
However, when I enable either the smartcn or the spatial contrib by uncommented the lines adding them to JARS in Makefile, pylucene build fails:
====== Smartcn enabled ======
/usr/bin/python -m jcc --shared --arch x86_64 --jar lucene-java-4.4.0/lucene/build/core/lucene-core-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/analysis/common/lucene-analyzers-common-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/memory/lucene-memory-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/highlighter/lucene-highlighter-4.4.0.jar --jar build/jar/extensions.jar --jar lucene-java-4.4.0/lucene/build/queries/lucene-queries-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/queryparser/lucene-queryparser-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/sandbox/lucene-sandbox-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/analysis/smartcn/lucene-analyzers-smartcn-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/analysis/stempel/lucene-analyzers-stempel-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/grouping/lucene-grouping-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/join/lucene-join-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/facet/lucene-facet-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/suggest/lucene-suggest-4.4.0.jar --include lucene-java-4.4.0/lucene/build/misc/lucene-misc-4.4.0.jar --use_full_names --package java.lang java.lang.System java.lang.Runtime --package java.util java.util.Arrays java.util.Collections java.util.HashMap java.util.HashSet java.util.TreeSet java.lang.IllegalStateException java.lang.IndexOutOfBoundsException java.util.NoSuchElementException java.text.SimpleDateFormat java.text.DecimalFormat java.text.Collator --package java.util.concurrent java.util.concurrent.Executors --package java.util.regex --package java.io java.io.StringReader java.io.InputStreamReader java.io.FileInputStream java.io.DataInputStream --exclude org.apache.lucene.sandbox.queries.regex.JakartaRegexpCapabilities --exclude org.apache.regexp.RegexpTunnel --python lucene --mapping org.apache.lucene.document.Document 'get:(Ljava/lang/String;)Ljava/lang/String;' --mapping java.util.Properties 'getProperty:(Ljava/lang/String;)Ljava/lang/String;' --sequence java.util.AbstractList 'size:()I' 'get:(I)Ljava/lang/Object;' org.apache.lucene.index.IndexWriter:getReader --version 4.4.0 --module python/collections.py --module python/ICUNormalizer2Filter.py --module python/ICUFoldingFilter.py --module python/ICUTransformFilter.py --files 8 --build
While loading org/apache/lucene/analysis/cn/smart/AnalyzerProfile
Traceback (most recent call last):
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 162, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "/Library/Python/2.7/site-packages/JCC-2.17-py2.7-macosx-10.8-intel.egg/jcc/__main__.py", line 107, in <module>
cpp.jcc(sys.argv)
File "/Library/Python/2.7/site-packages/JCC-2.17-py2.7-macosx-10.8-intel.egg/jcc/cpp.py", line 583, in jcc
cls = findClass(className.replace('.', '/'))
File "/Library/Python/2.7/site-packages/JCC-2.17-py2.7-macosx-10.8-intel.egg/jcc/cpp.py", line 73, in findClass
cls = _findClass(className)
jcc.cpp.JavaError: java.lang.ExceptionInInitializerError
Java stacktrace:
java.lang.ExceptionInInitializerError
Caused by: java.lang.RuntimeException: WARNING: Can not find lexical dictionary directory! This will cause unpredictable exceptions in your application! Please refer to the manual to download the dictionaries.
at org.apache.lucene.analysis.cn.smart.AnalyzerProfile.init(AnalyzerProfile.java:72)
at org.apache.lucene.analysis.cn.smart.AnalyzerProfile.<clinit>(AnalyzerProfile.java:43)
make: *** [compile] Error 255
===============================
======= Spatial enabled =======
/usr/bin/python -m jcc --shared --arch x86_64 --jar lucene-java-4.4.0/lucene/build/core/lucene-core-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/analysis/common/lucene-analyzers-common-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/memory/lucene-memory-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/highlighter/lucene-highlighter-4.4.0.jar --jar build/jar/extensions.jar --jar lucene-java-4.4.0/lucene/build/queries/lucene-queries-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/queryparser/lucene-queryparser-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/sandbox/lucene-sandbox-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/analysis/smartcn/lucene-analyzers-smartcn-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/analysis/stempel/lucene-analyzers-stempel-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/spatial/lucene-spatial-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/grouping/lucene-grouping-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/join/lucene-join-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/facet/lucene-facet-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/suggest/lucene-suggest-4.4.0.jar --include lucene-java-4.4.0/lucene/build/misc/lucene-misc-4.4.0.jar --use_full_names --package java.lang java.lang.System java.lang.Runtime --package java.util java.util.Arrays java.util.Collections java.util.HashMap java.util.HashSet java.util.TreeSet java.lang.IllegalStateException java.lang.IndexOutOfBoundsException java.util.NoSuchElementException java.text.SimpleDateFormat java.text.DecimalFormat java.text.Collator --package java.util.concurrent java.util.concurrent.Executors --package java.util.regex --package java.io java.io.StringReader java.io.InputStreamReader java.io.FileInputStream java.io.DataInputStream --exclude org.apache.lucene.sandbox.queries.regex.JakartaRegexpCapabilities --exclude org.apache.regexp.RegexpTunnel --python lucene --mapping org.apache.lucene.document.Document 'get:(Ljava/lang/String;)Ljava/lang/String;' --mapping java.util.Properties 'getProperty:(Ljava/lang/String;)Ljava/lang/String;' --sequence java.util.AbstractList 'size:()I' 'get:(I)Ljava/lang/Object;' org.apache.lucene.index.IndexWriter:getReader --version 4.4.0 --module python/collections.py --module python/ICUNormalizer2Filter.py --module python/ICUFoldingFilter.py --module python/ICUTransformFilter.py --files 8 --build
While loading org/apache/lucene/spatial/prefix/tree/QuadPrefixTree
Traceback (most recent call last):
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 162, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "/Library/Python/2.7/site-packages/JCC-2.17-py2.7-macosx-10.8-intel.egg/jcc/__main__.py", line 107, in <module>
cpp.jcc(sys.argv)
File "/Library/Python/2.7/site-packages/JCC-2.17-py2.7-macosx-10.8-intel.egg/jcc/cpp.py", line 583, in jcc
cls = findClass(className.replace('.', '/'))
File "/Library/Python/2.7/site-packages/JCC-2.17-py2.7-macosx-10.8-intel.egg/jcc/cpp.py", line 73, in findClass
cls = _findClass(className)
jcc.cpp.JavaError: java.lang.NoClassDefFoundError: com/spatial4j/core/shape/Shape
Java stacktrace:
java.lang.NoClassDefFoundError: com/spatial4j/core/shape/Shape
Caused by: java.lang.ClassNotFoundException: com.spatial4j.core.shape.Shape
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
make: *** [compile] Error 255
===============================
On Aug 22, 2013, at 5:46 AM, Andi Vajda <va...@apache.org> wrote:
> One more PMC vote is needed for this vote pass...
>
> Thanks !
>
> Andi..
>
> ---------- Forwarded message ----------
> Date: Sat, 17 Aug 2013 07:52:07 -0700 (PDT)
> From: Andi Vajda <va...@apache.org>
> Reply-To: pylucene-dev@lucene.apache.org, Andi Vajda <va...@apache.org>
> To: pylucene-dev@lucene.apache.org
> Cc: general@lucene.apache.org
> Subject: [VOTE] Release PyLucene 4.4.0-1
>
>
> The PyLucene 4.4.0-1 release tracking the recent release of Apache Lucene 4.4.0 is ready.
>
> A release candidate is available from:
> http://people.apache.org/~vajda/staging_area/
>
> A list of changes in this release can be seen at:
> http://svn.apache.org/repos/asf/lucene/pylucene/branches/pylucene_4_4/CHANGES
>
> PyLucene 4.4.0 is built with JCC 2.17 included in these release artifacts:
> http://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/CHANGES
>
> A list of Lucene Java changes can be seen at:
> http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_4_4_0/lucene/CHANGES.txt
>
> Please vote to release these artifacts as PyLucene 4.4.0-1.
>
> Thanks !
>
> Andi..
>
> ps: the KEYS file for PyLucene release signing is at:
> http://svn.apache.org/repos/asf/lucene/pylucene/dist/KEYS
> http://people.apache.org/~vajda/staging_area/KEYS
>
> pps: here is my +1
Re: [NAG][VOTE] Release PyLucene 4.4.0-1
Posted by Steve Rowe <sa...@gmail.com>.
+1
'make test' succeeds for me on OS X 10.8.4 with stock Python 2.7.
However, when I enable either the smartcn or the spatial contrib by uncommented the lines adding them to JARS in Makefile, pylucene build fails:
====== Smartcn enabled ======
/usr/bin/python -m jcc --shared --arch x86_64 --jar lucene-java-4.4.0/lucene/build/core/lucene-core-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/analysis/common/lucene-analyzers-common-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/memory/lucene-memory-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/highlighter/lucene-highlighter-4.4.0.jar --jar build/jar/extensions.jar --jar lucene-java-4.4.0/lucene/build/queries/lucene-queries-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/queryparser/lucene-queryparser-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/sandbox/lucene-sandbox-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/analysis/smartcn/lucene-analyzers-smartcn-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/analysis/stempel/lucene-analyzers-stempel-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/grouping/lucene-grouping-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/join/lucene-join-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/facet/lucene-facet-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/suggest/lucene-suggest-4.4.0.jar --include lucene-java-4.4.0/lucene/build/misc/lucene-misc-4.4.0.jar --use_full_names --package java.lang java.lang.System java.lang.Runtime --package java.util java.util.Arrays java.util.Collections java.util.HashMap java.util.HashSet java.util.TreeSet java.lang.IllegalStateException java.lang.IndexOutOfBoundsException java.util.NoSuchElementException java.text.SimpleDateFormat java.text.DecimalFormat java.text.Collator --package java.util.concurrent java.util.concurrent.Executors --package java.util.regex --package java.io java.io.StringReader java.io.InputStreamReader java.io.FileInputStream java.io.DataInputStream --exclude org.apache.lucene.sandbox.queries.regex.JakartaRegexpCapabilities --exclude org.apache.regexp.RegexpTunnel --python lucene --mapping org.apache.lucene.document.Document 'get:(Ljava/lang/String;)Ljava/lang/String;' --mapping java.util.Properties 'getProperty:(Ljava/lang/String;)Ljava/lang/String;' --sequence java.util.AbstractList 'size:()I' 'get:(I)Ljava/lang/Object;' org.apache.lucene.index.IndexWriter:getReader --version 4.4.0 --module python/collections.py --module python/ICUNormalizer2Filter.py --module python/ICUFoldingFilter.py --module python/ICUTransformFilter.py --files 8 --build
While loading org/apache/lucene/analysis/cn/smart/AnalyzerProfile
Traceback (most recent call last):
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 162, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "/Library/Python/2.7/site-packages/JCC-2.17-py2.7-macosx-10.8-intel.egg/jcc/__main__.py", line 107, in <module>
cpp.jcc(sys.argv)
File "/Library/Python/2.7/site-packages/JCC-2.17-py2.7-macosx-10.8-intel.egg/jcc/cpp.py", line 583, in jcc
cls = findClass(className.replace('.', '/'))
File "/Library/Python/2.7/site-packages/JCC-2.17-py2.7-macosx-10.8-intel.egg/jcc/cpp.py", line 73, in findClass
cls = _findClass(className)
jcc.cpp.JavaError: java.lang.ExceptionInInitializerError
Java stacktrace:
java.lang.ExceptionInInitializerError
Caused by: java.lang.RuntimeException: WARNING: Can not find lexical dictionary directory! This will cause unpredictable exceptions in your application! Please refer to the manual to download the dictionaries.
at org.apache.lucene.analysis.cn.smart.AnalyzerProfile.init(AnalyzerProfile.java:72)
at org.apache.lucene.analysis.cn.smart.AnalyzerProfile.<clinit>(AnalyzerProfile.java:43)
make: *** [compile] Error 255
===============================
======= Spatial enabled =======
/usr/bin/python -m jcc --shared --arch x86_64 --jar lucene-java-4.4.0/lucene/build/core/lucene-core-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/analysis/common/lucene-analyzers-common-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/memory/lucene-memory-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/highlighter/lucene-highlighter-4.4.0.jar --jar build/jar/extensions.jar --jar lucene-java-4.4.0/lucene/build/queries/lucene-queries-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/queryparser/lucene-queryparser-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/sandbox/lucene-sandbox-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/analysis/smartcn/lucene-analyzers-smartcn-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/analysis/stempel/lucene-analyzers-stempel-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/spatial/lucene-spatial-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/grouping/lucene-grouping-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/join/lucene-join-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/facet/lucene-facet-4.4.0.jar --jar lucene-java-4.4.0/lucene/build/suggest/lucene-suggest-4.4.0.jar --include lucene-java-4.4.0/lucene/build/misc/lucene-misc-4.4.0.jar --use_full_names --package java.lang java.lang.System java.lang.Runtime --package java.util java.util.Arrays java.util.Collections java.util.HashMap java.util.HashSet java.util.TreeSet java.lang.IllegalStateException java.lang.IndexOutOfBoundsException java.util.NoSuchElementException java.text.SimpleDateFormat java.text.DecimalFormat java.text.Collator --package java.util.concurrent java.util.concurrent.Executors --package java.util.regex --package java.io java.io.StringReader java.io.InputStreamReader java.io.FileInputStream java.io.DataInputStream --exclude org.apache.lucene.sandbox.queries.regex.JakartaRegexpCapabilities --exclude org.apache.regexp.RegexpTunnel --python lucene --mapping org.apache.lucene.document.Document 'get:(Ljava/lang/String;)Ljava/lang/String;' --mapping java.util.Properties 'getProperty:(Ljava/lang/String;)Ljava/lang/String;' --sequence java.util.AbstractList 'size:()I' 'get:(I)Ljava/lang/Object;' org.apache.lucene.index.IndexWriter:getReader --version 4.4.0 --module python/collections.py --module python/ICUNormalizer2Filter.py --module python/ICUFoldingFilter.py --module python/ICUTransformFilter.py --files 8 --build
While loading org/apache/lucene/spatial/prefix/tree/QuadPrefixTree
Traceback (most recent call last):
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 162, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "/Library/Python/2.7/site-packages/JCC-2.17-py2.7-macosx-10.8-intel.egg/jcc/__main__.py", line 107, in <module>
cpp.jcc(sys.argv)
File "/Library/Python/2.7/site-packages/JCC-2.17-py2.7-macosx-10.8-intel.egg/jcc/cpp.py", line 583, in jcc
cls = findClass(className.replace('.', '/'))
File "/Library/Python/2.7/site-packages/JCC-2.17-py2.7-macosx-10.8-intel.egg/jcc/cpp.py", line 73, in findClass
cls = _findClass(className)
jcc.cpp.JavaError: java.lang.NoClassDefFoundError: com/spatial4j/core/shape/Shape
Java stacktrace:
java.lang.NoClassDefFoundError: com/spatial4j/core/shape/Shape
Caused by: java.lang.ClassNotFoundException: com.spatial4j.core.shape.Shape
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
make: *** [compile] Error 255
===============================
On Aug 22, 2013, at 5:46 AM, Andi Vajda <va...@apache.org> wrote:
> One more PMC vote is needed for this vote pass...
>
> Thanks !
>
> Andi..
>
> ---------- Forwarded message ----------
> Date: Sat, 17 Aug 2013 07:52:07 -0700 (PDT)
> From: Andi Vajda <va...@apache.org>
> Reply-To: pylucene-dev@lucene.apache.org, Andi Vajda <va...@apache.org>
> To: pylucene-dev@lucene.apache.org
> Cc: general@lucene.apache.org
> Subject: [VOTE] Release PyLucene 4.4.0-1
>
>
> The PyLucene 4.4.0-1 release tracking the recent release of Apache Lucene 4.4.0 is ready.
>
> A release candidate is available from:
> http://people.apache.org/~vajda/staging_area/
>
> A list of changes in this release can be seen at:
> http://svn.apache.org/repos/asf/lucene/pylucene/branches/pylucene_4_4/CHANGES
>
> PyLucene 4.4.0 is built with JCC 2.17 included in these release artifacts:
> http://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/CHANGES
>
> A list of Lucene Java changes can be seen at:
> http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_4_4_0/lucene/CHANGES.txt
>
> Please vote to release these artifacts as PyLucene 4.4.0-1.
>
> Thanks !
>
> Andi..
>
> ps: the KEYS file for PyLucene release signing is at:
> http://svn.apache.org/repos/asf/lucene/pylucene/dist/KEYS
> http://people.apache.org/~vajda/staging_area/KEYS
>
> pps: here is my +1