Thank you !
Andi..
> On Apr 9, 2019, at 00:25, Petrus Hyvönen <petrus.hyvo...@gmail.com> wrote:
>
> Hi,
>
> I did a test case and filed an issue for it in the JIRA, test case uploaded
> there.
>
> Best Regards
> /Petrus
>
>
> On Mon, Apr 8, 2019 at 9:00 AM Petrus Hyvönen <petrus.hyvo...@gmail.com>
> wrote:
>
>> Hi Andi,
>>
>> I will write a small test case for this.
>>
>> I think the best solution would be to sort the comparisons of types by
>> inheritance within the same number of parameters, but not sure how complex
>> this could end up. Maybe the IsInstanceOf method could be used to check if
>> there are such dependencies between the input parameters and then put the
>> ones lowest "level" first in the test. As I understand this would only be
>> needed at compile time, unless there are some dynamic types that will make
>> it very complex.
>>
>> Another alternative i guess would be to use very strict typing rules so it
>> really needs to be the same class of the types but that may affect how a
>> library is used alot.
>>
>> With Best Regards
>> /Petrus
>>
>>
>>> On Sun, Apr 7, 2019 at 10:50 PM Andi Vajda <va...@apache.org> wrote:
>>>
>>>
>>>> On Sun, 7 Apr 2019, Petrus Hyvönen wrote:
>>>>
>>>> Hi,
>>>>
>>>> I am getting inconsistent results and think I may be onto something. I
>>> am
>>>> doing builds both locally and in a online build server, where there
>>> should
>>>> be no old versions around. But both locally and there the results
>>> between
>>>> different runs varies even on same platforms. Sometimes I get the right
>>>> return type and for some builds and the same function returns its
>>> parents
>>>> for other build (same platform).
>>>>
>>>> I have looked at the generated code and there seems to be a difference
>>> in
>>>> the order of the parameter checking from the working vs non-working (no
>>> big
>>>> statistical ground however).
>>>>
>>>> For the working one, the child class type is checked before the parent.
>>>> Could it be that the parseArgs function gets a positive match when
>>>> comparing child with the parent?
>>>
>>> I think I understand what's going on but I'm not sure and having a small
>>> piece of code to reproduce the problem would help.
>>>
>>> Namely, when you have more than one overload for a given method that is
>>> valid for a given call then the order in which they're considered is
>>> probably (I didn't check) in the order the method signatures were
>>> returned
>>> by Java during the JCC compile. JCC sorts the overloads by number of args
>>> but then *does not* sort them by, say, lowest subclass in the tree first.
>>> This could be tricky, or even undecidable (or make things slower at
>>> runtime
>>> by trying to find the lowest match based on your python call - at the
>>> moment, the first valid match is returned).
>>>
>>> It is a bug for it to be random, however, so I think I should be able to
>>> get
>>> JCC to always succeed or fail in the same way, and not let the order of
>>> methods as returned by Java during compilation by JCC determine the
>>> behaviour.
>>>
>>> I could be wrong about this (the order returned by Java could be
>>> deterministic and well chosen and later broken by JCC, for example, I
>>> didn't
>>> yet check).
>>>
>>> You can help in getting this resolved by creating a small example that
>>> exhibits this bug (multiple overloads of a method that differ only in
>>> which
>>> piece of a subclass tree is used).
>>>
>>> You can also workaround this problem by using different method names to
>>> avoid such confusion with overloads (if that is indeed the problem).
>>>
>>> Andi..
>>>
>>>>
>>>> Faulty return type (returns PVCoordinates type on
>>> TimeStampedPVCoordinates
>>>> input)
>>>>
>>>>
>>>>
>>>> ::org::orekit::utils::PVCoordinates a0((jobject) NULL);
>>>>
>>>> ::org::orekit::utils::PVCoordinates result((jobject) NULL);
>>>>
>>>>
>>>>
>>>> if (!parseArgs(args, "k",
>>>> ::org::orekit::utils::PVCoordinates::initializeClass, &a0))
>>>>
>>>> {
>>>>
>>>> OBJ_CALL(result = self->object.transformPVCoordinates(a0));
>>>>
>>>> return ::org::orekit::utils::t_PVCoordinates::wrap_Object
>>>> (result);
>>>>
>>>> }
>>>>
>>>> }
>>>>
>>>> {
>>>>
>>>> ::org::orekit::utils::TimeStampedPVCoordinates a0((jobject)
>>> NULL
>>>> );
>>>>
>>>> ::org::orekit::utils::TimeStampedPVCoordinates
>>> result((jobject)
>>>> NULL);
>>>>
>>>>
>>>>
>>>> if (!parseArgs(args, "k",
>>>> ::org::orekit::utils::TimeStampedPVCoordinates::initializeClass, &a0))
>>>>
>>>> {
>>>>
>>>> OBJ_CALL(result =
>>> self->object.transformPVCoordinates(a0)); //
>>>> Här är det det räknas ut
>>>>
>>>> return ::org::orekit::utils::t_TimeStampedPVCoordinates::
>>>> wrap_Object(result);
>>>>
>>>> }
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>> And corresponding code in a build that works: (TimeStampedPVCoordinates
>>> as
>>>> parameter gets return type TimeStampedPVCoordinates)
>>>>
>>>> static PyObject *t_Transform_transformPVCoordinates(t_Transform *self,
>>>> PyObject *args)
>>>> {
>>>> switch (PyTuple_GET_SIZE(args)) {
>>>> case 1:
>>>> {
>>>> ::org::orekit::utils::FieldPVCoordinates a0((jobject) NULL);
>>>> PyTypeObject **p0;
>>>> ::org::orekit::utils::FieldPVCoordinates result((jobject) NULL);
>>>>
>>>> if (!parseArgs(args, "K",
>>>> ::org::orekit::utils::FieldPVCoordinates::initializeClass, &a0, &p0,
>>>> ::org::orekit::utils::t_FieldPVCoordinates::parameters_))
>>>> {
>>>> OBJ_CALL(result = self->object.transformPVCoordinates(a0));
>>>> return ::org::orekit::utils::t_FieldPVCoordinates::wrap_Object(result);
>>>> }
>>>> }
>>>> {
>>>> ::org::orekit::utils::TimeStampedPVCoordinates a0((jobject) NULL);
>>>> ::org::orekit::utils::TimeStampedPVCoordinates result((jobject) NULL);
>>>>
>>>> if (!parseArgs(args, "k",
>>>> ::org::orekit::utils::TimeStampedPVCoordinates::initializeClass, &a0))
>>>> {
>>>> OBJ_CALL(result = self->object.transformPVCoordinates(a0));
>>>> return ::org::orekit::utils::t_TimeStampedPVCoordinates::wrap_Object
>>>> (result);
>>>> }
>>>> }
>>>> {
>>>> ::org::orekit::utils::TimeStampedFieldPVCoordinates a0((jobject) NULL);
>>>> PyTypeObject **p0;
>>>> ::org::orekit::utils::TimeStampedFieldPVCoordinates result((jobject)
>>> NULL);
>>>>
>>>> if (!parseArgs(args, "K",
>>>> ::org::orekit::utils::TimeStampedFieldPVCoordinates::initializeClass,
>>> &a0,
>>>> &p0,
>>> ::org::orekit::utils::t_TimeStampedFieldPVCoordinates::parameters_))
>>>> {
>>>> OBJ_CALL(result = self->object.transformPVCoordinates(a0));
>>>> return
>>> ::org::orekit::utils::t_TimeStampedFieldPVCoordinates::wrap_Object
>>>> (result);
>>>> }
>>>> }
>>>> {
>>>> ::org::orekit::utils::PVCoordinates a0((jobject) NULL);
>>>> ::org::orekit::utils::PVCoordinates result((jobject) NULL);
>>>>
>>>> if (!parseArgs(args, "k",
>>>> ::org::orekit::utils::PVCoordinates::initializeClass, &a0))
>>>> {
>>>> OBJ_CALL(result = self->object.transformPVCoordinates(a0));
>>>> return ::org::orekit::utils::t_PVCoordinates::wrap_Object(result);
>>>> }
>>>> }
>>>> }
>>>>
>>>> I guess there could be a zillion other reasons as well, but this would
>>> fit
>>>> with the random character on when it would work.
>>>>
>>>> I have tried to understand the parseArgs function but it is hard.
>>>>
>>>> Any comments welcome...
>>>>
>>>> With Best Regards
>>>> /Petrus
>>>>
>>>>
>>>>> On Sat, Apr 6, 2019 at 3:58 AM Andi Vajda <va...@apache.org> wrote:
>>>>>
>>>>> Are you sure you're running the code you think you're running ? Your
>>>>> description sounds like an old version of something may be picked up
>>>>> instead.
>>>>>
>>>>> Andi..
>>>>>
>>>>>> On Apr 5, 2019, at 15:04, Petrus Hyvönen <petrus.hyvo...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am having some confusing time with a wrapped class.
>>>>>>
>>>>>> The class "Transform" has a function transformPVCoordinates() that has
>>>>>> different options for input parameters. One of these are
>>>>>> TimeStampedPVCoordinates. It is supposed to return a
>>>>>> TimeStampedPVCoordinates object but returns instead a PVCoodinates
>>> object
>>>>>> that is its parent class. I cannot cast this to
>>> TimeStampedPVCoordinates,
>>>>>> gets an error. On most systems. On python 2.7 it works and only 3.6
>>> under
>>>>>> linux (testing for max, linux and win). It worked also in Python 3.7
>>> on
>>>>>> mac/windows for the JCC 3.0 version.
>>>>>>
>>>>>> I've checked the code being generated, and the return type and
>>> parameter
>>>>>> type of TimeStampedPVCoord are there, both in c code and .h file.
>>>>>>
>>>>>> How/where is the matching of parameters from python call done? I get a
>>>>>> feeling that the parent class is somehow used, but not shure how to
>>>>>> troubleshoot this...
>>>>>>
>>>>>> 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
>>
>
>
> --
> _____________________________________________
> Petrus Hyvönen, Uppsala, Sweden
> Mobile Phone/SMS:+46 73 803 19 00
