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
