[jira] [Commented] (PYLUCENE-47) Type matching in methods with same number of arguments
[ https://issues.apache.org/jira/browse/PYLUCENE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16824421#comment-16824421 ] Petrus Hyvönen commented on PYLUCENE-47: Many thanks Andi... > Type matching in methods with same number of arguments > -- > > Key: PYLUCENE-47 > URL: https://issues.apache.org/jira/browse/PYLUCENE-47 > Project: PyLucene > Issue Type: Bug >Reporter: Petrus Hyvönen >Priority: Major > Attachments: build_and_wrap_Test_parameters_v3.zip, > java-example-test-parameters-v2.2.zip, java-example-test-parameters.zip, > pylucene-47-including-constructors.patch > > > If the same number of arguments are used in a method and the arguments are > positively matched also on subclasses of the argument. The order of testing > in the generated code will matter and give unpredictable results. > A test case is attached below. It should fail in most cases but with a piece > of luck the order of tests in the generated code may get right and it will > work (1/24 chance if at random). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PYLUCENE-47) Type matching in methods with same number of arguments
[ https://issues.apache.org/jira/browse/PYLUCENE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823602#comment-16823602 ] Andi Vajda commented on PYLUCENE-47: Fixed in rev 1857978 (the attached test passes both with python2 and python3). Thank you for the patch and the test case. I had to expand on your patch considerably to make the comparisons really deterministic as that was one part of the bug, it would only happen sometimes... based on the original order of the signatures returned by java and the order of comparisons in python's sort. I also wanted to do the rank compare only when it's actually needed as it's not free. > Type matching in methods with same number of arguments > -- > > Key: PYLUCENE-47 > URL: https://issues.apache.org/jira/browse/PYLUCENE-47 > Project: PyLucene > Issue Type: Bug >Reporter: Petrus Hyvönen >Priority: Major > Attachments: build_and_wrap_Test_parameters_v3.zip, > java-example-test-parameters-v2.2.zip, java-example-test-parameters.zip, > pylucene-47-including-constructors.patch > > > If the same number of arguments are used in a method and the arguments are > positively matched also on subclasses of the argument. The order of testing > in the generated code will matter and give unpredictable results. > A test case is attached below. It should fail in most cases but with a piece > of luck the order of tests in the generated code may get right and it will > work (1/24 chance if at random). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [jira] [Commented] (PYLUCENE-47) Type matching in methods with same number of arguments
Hi,
I uploaded a patch that now also uses the rank function for constructors as
well as a testcase.
I need to think a bit on the Interface stuff and how this matches the class
tests. A java class implements a specific set of interfaces I think, so in
the "class" hierarchy we don't need to consider this or? An extract of
generated code in the selection for the test case:
switch (PyTuple_GET_SIZE(args)) {
case 1:
{
::org::jcc::test::Cat a0((jobject) NULL);
::org::jcc::test::Cat result((jobject) NULL);
if (!parseArgs(args, "k", ::org::jcc::test::Cat::initializeClass, ))
{
OBJ_CALL(result = self->object.getNewOne(a0));
return ::org::jcc::test::t_Cat::wrap_Object(result);
}
}
{
::org::jcc::test::Feline a0((jobject) NULL);
::org::jcc::test::Feline result((jobject) NULL);
if (!parseArgs(args, "k", ::org::jcc::test::Feline::initializeClass, ))
{
OBJ_CALL(result = self->object.getNewOne(a0));
return ::org::jcc::test::t_Feline::wrap_Object(result);
}
}
So itn that case it will matter how the parseArgs function matches, but
methods that are implemented as part of an interface would be handled just
like any method I assume?
But Interfaces themselves are possible to "wrap" as well I think? Maybe
this is where this is needed for pure interface hierarchies?
I will spend some more thinking on this, not a java expert..
Regards
/Petrus
On Thu, Apr 18, 2019 at 8:00 PM Andi Vajda (JIRA) wrote:
>
> [
> https://issues.apache.org/jira/browse/PYLUCENE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821358#comment-16821358
> ]
>
> Andi Vajda commented on PYLUCENE-47:
>
>
>
>
> In that case, my comment makes no sense, sorry for the noise.
>
>
> Not in terms of isAssignableFrom() but in terms of how many interfaces a
> parameter class implements (in essence, the interface hierarchy is a
> parallel class hierarchy, with multiple super-interfaces allowed).
> Counting
> those may give us some signal as to how deep a parameter class is and help
> with sorting.
>
>
> Yes, we have the same bug there.
>
> Andi..
>
>
> > Type matching in methods with same number of arguments
> > --
> >
> > Key: PYLUCENE-47
> > URL: https://issues.apache.org/jira/browse/PYLUCENE-47
> > Project: PyLucene
> > Issue Type: Bug
> >Reporter: Petrus Hyvönen
> >Priority: Major
> > Attachments: java-example-test-parameters-v2.2.zip,
> java-example-test-parameters.zip, pylucene-47-2.patch, pylucene-47-3.patch
> >
> >
> > If the same number of arguments are used in a method and the arguments
> are positively matched also on subclasses of the argument. The order of
> testing in the generated code will matter and give unpredictable results.
> > A test case is attached below. It should fail in most cases but with a
> piece of luck the order of tests in the generated code may get right and it
> will work (1/24 chance if at random).
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
>
--
_
Petrus Hyvönen, Uppsala, Sweden
Mobile Phone/SMS:+46 73 803 19 00
[jira] [Commented] (PYLUCENE-47) Type matching in methods with same number of arguments
[ https://issues.apache.org/jira/browse/PYLUCENE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821358#comment-16821358 ] Andi Vajda commented on PYLUCENE-47: In that case, my comment makes no sense, sorry for the noise. Not in terms of isAssignableFrom() but in terms of how many interfaces a parameter class implements (in essence, the interface hierarchy is a parallel class hierarchy, with multiple super-interfaces allowed). Counting those may give us some signal as to how deep a parameter class is and help with sorting. Yes, we have the same bug there. Andi.. > Type matching in methods with same number of arguments > -- > > Key: PYLUCENE-47 > URL: https://issues.apache.org/jira/browse/PYLUCENE-47 > Project: PyLucene > Issue Type: Bug >Reporter: Petrus Hyvönen >Priority: Major > Attachments: java-example-test-parameters-v2.2.zip, > java-example-test-parameters.zip, pylucene-47-2.patch, pylucene-47-3.patch > > > If the same number of arguments are used in a method and the arguments are > positively matched also on subclasses of the argument. The order of testing > in the generated code will matter and give unpredictable results. > A test case is attached below. It should fail in most cases but with a piece > of luck the order of tests in the generated code may get right and it will > work (1/24 chance if at random). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [jira] [Commented] (PYLUCENE-47) Type matching in methods with same number of arguments
On Wed, 17 Apr 2019, Petrus Hyvönen (JIRA) wrote: Petrus Hyvönen commented on PYLUCENE-47: Thanks for looking at this. I am not sure I understand your comments/questions. I don't think it is possible to have method overloading based on return type, so not sure what the return type could be used for? In that case, my comment makes no sense, sorry for the noise. Do you know how the matching handles interfaces with parameters? Would isAssignableFrom match on them? Not in terms of isAssignableFrom() but in terms of how many interfaces a parameter class implements (in essence, the interface hierarchy is a parallel class hierarchy, with multiple super-interfaces allowed). Counting those may give us some signal as to how deep a parameter class is and help with sorting. I realized that the sorting is likely also necessary for constructors, in case you have overloaded constructors for a class... Seems possible to use almost identical code where the sorting in cpp.py is done for the constructors. Yes, we have the same bug there. Andi..
[jira] [Commented] (PYLUCENE-47) Type matching in methods with same number of arguments
[ https://issues.apache.org/jira/browse/PYLUCENE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819386#comment-16819386 ] Andi Vajda commented on PYLUCENE-47: I took at your patch and it makes sense (thanks!) Would it make sense to include the return type of the method in the rang calculation ? Would it make sense to then continue sorting, as a third criteria, on the rang of interfaces each parameter and return type class implements ? Andi.. > Type matching in methods with same number of arguments > -- > > Key: PYLUCENE-47 > URL: https://issues.apache.org/jira/browse/PYLUCENE-47 > Project: PyLucene > Issue Type: Bug >Reporter: Petrus Hyvönen >Priority: Major > Attachments: java-example-test-parameters-v2.2.zip, > java-example-test-parameters.zip, pylucene-47-2.patch, pylucene-47-3.patch > > > If the same number of arguments are used in a method and the arguments are > positively matched also on subclasses of the argument. The order of testing > in the generated code will matter and give unpredictable results. > A test case is attached below. It should fail in most cases but with a piece > of luck the order of tests in the generated code may get right and it will > work (1/24 chance if at random). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PYLUCENE-47) Type matching in methods with same number of arguments
[ https://issues.apache.org/jira/browse/PYLUCENE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817252#comment-16817252 ] Petrus Hyvönen commented on PYLUCENE-47: Uploaded new patch and testcase where order is based on number of superclasses. > Type matching in methods with same number of arguments > -- > > Key: PYLUCENE-47 > URL: https://issues.apache.org/jira/browse/PYLUCENE-47 > Project: PyLucene > Issue Type: Bug >Reporter: Petrus Hyvönen >Priority: Major > Attachments: java-example-test-parameters-v2.2.zip, > java-example-test-parameters.zip, pylucene-47-2.patch, pylucene-47-3.patch > > > If the same number of arguments are used in a method and the arguments are > positively matched also on subclasses of the argument. The order of testing > in the generated code will matter and give unpredictable results. > A test case is attached below. It should fail in most cases but with a piece > of luck the order of tests in the generated code may get right and it will > work (1/24 chance if at random). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PYLUCENE-47) Type matching in methods with same number of arguments
[ https://issues.apache.org/jira/browse/PYLUCENE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817012#comment-16817012 ] Petrus Hyvönen commented on PYLUCENE-47: Updated test case to include methods with more than one parameter. > Type matching in methods with same number of arguments > -- > > Key: PYLUCENE-47 > URL: https://issues.apache.org/jira/browse/PYLUCENE-47 > Project: PyLucene > Issue Type: Bug >Reporter: Petrus Hyvönen >Priority: Major > Attachments: java-example-test-parameters-v2.zip, > java-example-test-parameters.zip > > > If the same number of arguments are used in a method and the arguments are > positively matched also on subclasses of the argument. The order of testing > in the generated code will matter and give unpredictable results. > A test case is attached below. It should fail in most cases but with a piece > of luck the order of tests in the generated code may get right and it will > work (1/24 chance if at random). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
