lucene-pylucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Petrus Hyvönen <petrus.hyvo...@gmail.com>
Subject Re: Problem using generic types?
Date Mon, 30 Dec 2013 19:32:33 GMT
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 <vajda@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 <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
>>
>


-- 
_____________________________________________
Petrus Hyvönen, Uppsala, Sweden
Mobile Phone/SMS:+46 73 803 19 00

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message