lucene-pylucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Vajda <va...@apache.org>
Subject Re: Problem using generic types?
Date Sun, 29 Dec 2013 17:13:32 GMT

> On Dec 29, 2013, at 17:02, Petrus Hyvönen <petrus.hyvonen@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 <vajda@apache.org> wrote:
>> 
>> 
>>>> On Dec 27, 2013, at 17:36, Petrus Hyvönen <petrus.hyvonen@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 <vajda@apache.org> wrote:
>>>> 
>>>> 
>>>>>> On Dec 15, 2013, at 5:43, Petrus Hyvönen <petrus.hyvonen@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 <vajda@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

Mime
View raw message