from:"Petrus Hyvönen"

Re: Experience with JCC >=3.9.9 and windows

2022-02-07 Thread Petrus Hyvönen

Hi,

I just got some response on this through conda-forge community, that this
would be due that the DLL resolution order was changed in 3.8 (but
temporary reverted in conda-forge python).

https://github.com/conda-forge/python-feedstock/issues/552

I will try to test this,  if correct it will need to also go into the
generation of wrapper code I would assume.

Best Regards
/Petrus





On Tue, Dec 28, 2021 at 10:33 PM Petrus Hyvönen 
wrote:

> Short update, I have now debugged the python 3.9.9 (not working) and 3.9.7
> (working) side by side. It seems like there is a difference in behavior of
> the "import jcc._jcc3 as _jcc3" in __init__.py of jcc that triggers the
> find_spec() method in the _distutils_hack module. The return of this
> function seems to behave differently in the different python versions (from
> what I can find). I am not fully understanding this import magics, but
> could be that there is an issue with setuptools or something completely
> different :)
>
> Regards
> /Petrus
>
>
> On Tue, Dec 28, 2021 at 4:41 PM Petrus Hyvönen 
> wrote:
>
>> Hi,
>>
>> I am trying to build JCC (3.11) for conda-forge packaging and is
>> struggling a bit with building JCC for windows platform when version is
>> 3.9.9 or higher (3.10). The odd thing is that 3.9.7 is working, which is
>> using (to my current knowledge) the same other packages as 3.9.9 and other
>> settings. I do think the PATH's and such is right, otherwise 3.9.7 wouldn't
>> work (in principle)
>>
>> Likely some minor issue I've not noticed - but just to check - does
>> someone else have similar issues with building on windows? Or got it to
>> work would be good to know?
>>
>> For linux and mac it all builds well on 3.9.9 as well as 3.10.
>>
>> >>> import jcc
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File "C:\\lib\site-packages\jcc\__init__.py", line 31, in 
>> import jcc._jcc3 as _jcc3
>>
>> ImportError: DLL load failed while importing _jcc3: The specified module
>> could not be found.
>>
>> Probably something simple that I haven't been able to track down.
>> Speculating in some changes in python for 3.9.9, there are some minor
>> changes in importlib but what I can see it shouldn't affect (
>> https://bugs.python.org/issue45765).
>>
>> Any feedback welcome :)
>>
>> 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

Re: Experience with JCC >=3.9.9 and windows

2021-12-28 Thread Petrus Hyvönen

Short update, I have now debugged the python 3.9.9 (not working) and 3.9.7
(working) side by side. It seems like there is a difference in behavior of
the "import jcc._jcc3 as _jcc3" in __init__.py of jcc that triggers the
find_spec() method in the _distutils_hack module. The return of this
function seems to behave differently in the different python versions (from
what I can find). I am not fully understanding this import magics, but
could be that there is an issue with setuptools or something completely
different :)

Regards
/Petrus


On Tue, Dec 28, 2021 at 4:41 PM Petrus Hyvönen 
wrote:

> Hi,
>
> I am trying to build JCC (3.11) for conda-forge packaging and is
> struggling a bit with building JCC for windows platform when version is
> 3.9.9 or higher (3.10). The odd thing is that 3.9.7 is working, which is
> using (to my current knowledge) the same other packages as 3.9.9 and other
> settings. I do think the PATH's and such is right, otherwise 3.9.7 wouldn't
> work (in principle)
>
> Likely some minor issue I've not noticed - but just to check - does
> someone else have similar issues with building on windows? Or got it to
> work would be good to know?
>
> For linux and mac it all builds well on 3.9.9 as well as 3.10.
>
> >>> import jcc
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "C:\\lib\site-packages\jcc\__init__.py", line 31, in 
> import jcc._jcc3 as _jcc3
>
> ImportError: DLL load failed while importing _jcc3: The specified module
> could not be found.
>
> Probably something simple that I haven't been able to track down.
> Speculating in some changes in python for 3.9.9, there are some minor
> changes in importlib but what I can see it shouldn't affect (
> https://bugs.python.org/issue45765).
>
> Any feedback welcome :)
>
> 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

Experience with JCC >=3.9.9 and windows

2021-12-28 Thread Petrus Hyvönen

Hi,

I am trying to build JCC (3.11) for conda-forge packaging and is struggling
a bit with building JCC for windows platform when version is 3.9.9 or
higher (3.10). The odd thing is that 3.9.7 is working, which is using (to
my current knowledge) the same other packages as 3.9.9 and other settings.
I do think the PATH's and such is right, otherwise 3.9.7 wouldn't work (in
principle)

Likely some minor issue I've not noticed - but just to check - does someone
else have similar issues with building on windows? Or got it to work would
be good to know?

For linux and mac it all builds well on 3.9.9 as well as 3.10.

>>> import jcc
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\\lib\site-packages\jcc\__init__.py", line 31, in 
import jcc._jcc3 as _jcc3

ImportError: DLL load failed while importing _jcc3: The specified module
could not be found.

Probably something simple that I haven't been able to track down.
Speculating in some changes in python for 3.9.9, there are some minor
changes in importlib but what I can see it shouldn't affect (
https://bugs.python.org/issue45765).

Any feedback welcome :)

Best Regards
/Petrus



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

Re: [jira] [Commented] (PYLUCENE-51) "AttributeError: module" when running doctest

2019-10-20 Thread Petrus Hyvönen

Many thanks Andi :)


> On 17 Oct 2019, at 20:11 , Andi Vajda  wrote:
> 
> 
> Added __module__ to JArray() types in rev 1868563.
> 
> On Thu, 17 Oct 2019, Petrus Hyvönen (Jira) wrote:
> 
>> 
>>   [ 
>> https://issues.apache.org/jira/browse/PYLUCENE-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16953958#comment-16953958
>>  ]
>> 
>> Petrus Hyvönen commented on PYLUCENE-51:
>> 
>> 
>> Many Thanks for looking into this, most classes seems to have this property 
>> now but the JArray_* seems to use some other mechanism and do not have this?
>> 
>>> "AttributeError: __module__" when running doctest
>>> -
>>> 
>>>Key: PYLUCENE-51
>>>URL: https://issues.apache.org/jira/browse/PYLUCENE-51
>>>Project: PyLucene
>>> Issue Type: Bug
>>>Environment: Ubuntu 19.04, Python 3.7
>>>   Reporter: Clément Jonglez
>>>   Priority: Major
>>> 
>>> Dear all,
>>> I am using the Orekit Python wrapper by [~petrush] . I am running into 
>>> errors & warnings when trying to run tests with doctest. When collecting 
>>> tests, it analyzes the classes (all the 1000+ wrapped Java classes it 
>>> seems) and runs into the following error:
>>> {noformat}
>>> [...]/lib/python3.7/site-packages/pytest_doctestplus/plugin.py:137: in 
>>> collect
>>> for test in finder.find(module):
>>> [...]/lib/python3.7/site-packages/pytest_doctestplus/plugin.py:425: in find
>>> extraglobs)
>>> [...]/lib/python3.7/doctest.py:932: in find
>>> self._find(tests, obj, name, module, source_lines, globs, {})
>>> [...]/lib/python3.7/doctest.py:993: in _find
>>> self._from_module(module, val)):
>>> [...]/lib/python3.7/doctest.py:960: in _from_module
>>> return module._name_ == object._module_
>>> E AttributeError: _module_{noformat}
> ??> In doctest 
> ([https://github.com/python/cpython/blob/master/Lib/doctest.py#L959]), the
>>> {code:java}
>>> inspect.isclass(object) {code}
>>> condition at line 959 returns `True`, and therefore doctest tries to access 
>>> the object's __module__ attribute, which does not seem to exist.
>>> Besides, pytest prints a warning for each Java class being wrapped, also 
>>> because they have no __module__ attribute (this is one example of 1000+ 
>>> warnings):
>>> {noformat}
>>> [...]/lib/python3.7/importlib/bootstrap.py:219: DeprecationWarning: builtin 
>>> type ExtendedKalmanFilter has no __module_ attribute
>>> return f(*args, **kwds){noformat}
>>> This phenomenon is new because 6 months ago I could run pytest & doctest 
>>> successfully with Orekit. I could not find which module contains the change 
>>> that broke stuff since then though.
>>> To reproduce the phenomenon, you can check out 
>>> [https://github.com/GorgiAstro/poliastro/blob/orekit-validation/src/poliastro/tests/tests_twobody/test_propagation.py#L164]
>>> I was trying to validate some poliastro features using the Orekit python 
>>> wrapper. So this code requires poliastro, it is available on conda-forge.
>>> Cheers
>>> Clément
>> 
>> 
>> 
>> --
>> This message was sent by Atlassian Jira
>> (v8.3.4#803005)

Re: [ANNOUNCE] Apache PyLucene 8.1.1

2019-09-11 Thread Petrus Hyvönen

Great news, and thanks Andi for the work on this!

The conda JCC package is now updated to this version
https://github.com/conda-forge/jcc-feedstock

With Best Regards
/Petrus


On Wed, Sep 11, 2019 at 8:38 PM Andi Vajda  wrote:

>
> I am pleased to announce the availability of Apache PyLucene 8.1.1.
>
> Apache PyLucene, a subproject of Apache Lucene, is a Python extension for
> accessing Apache Lucene Core. Its goal is to allow you to use Lucene's text
> indexing and searching capabilities from Python. It is API compatible with
> Lucene 8.x Core, version 8.1.1.
>
> For changes in this release, please review:
> http://svn.apache.org/repos/asf/lucene/pylucene/tags/pylucene_8_1_1/CHANGES
>
> http://svn.apache.org/repos/asf/lucene/pylucene/tags/pylucene_8_1_1/jcc/CHANGES
> http://lucene.apache.org/core/8_1_1/changes/Changes.html
>
> Apache PyLucene is available from the following download page:
>
> http://www.apache.org/dyn/closer.cgi/lucene/pylucene/pylucene-8.1.1-src.tar.gz
>
> When downloading from a mirror site, please remember to verify the
> downloads
> using signatures found on the Apache site:
> https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
>
> For more information on Apache PyLucene, visit the project home page:
>http://lucene.apache.org/pylucene
>
> Andi..
>


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

Re: [VOTE] Release PyLucene 8.1.1 (rc2)

2019-07-05 Thread Petrus Hyvönen

Hi,

I would like to encourage PMC members to vote, please?

For me +1 for release (user, not PMC)

Best Regards
/Petrus


On Sun, Jun 23, 2019 at 7:50 PM Aric Coady  wrote:

> +1.  rc builds available:
>
> - docker pull coady/pylucene:rc
> - brew install —devel coady/tap/pylucene
>
> > On Jun 22, 2019, at 5:17 PM, Andi Vajda  wrote:
> >
> >
> > The PyLucene 8.1.1 (rc2) release tracking the recent release of
> > Apache Lucene 8.1.1 is ready.
> >
> > A release candidate is available from:
> >  https://dist.apache.org/repos/dist/dev/lucene/pylucene/8.1.1-rc2/
> >
> > PyLucene 8.1.1 is built with JCC 3.6, included in these release
> artifacts.
> >
> > JCC 3.6 supports Python 3.3+ (in addition to Python 2.3+).
> > PyLucene may be built with Python 2 or Python 3.
> >
> > Please vote to release these artifacts as PyLucene 8.1.1.
> > Anyone interested in this release can and should vote !
> >
> > Thanks !
> >
> > Andi..
> >
> > ps: the KEYS file for PyLucene release signing is at:
> > https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
> > https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS
> >
> > pps: here is my +1
>
>

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

Re: [jira] [Commented] (PYLUCENE-47) Type matching in methods with same number of arguments

2019-04-19 Thread Petrus Hyvönen

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

Re: JCC strange behaviour

2019-04-08 Thread Petrus Hyvönen

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  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, ))
> >
> >{
> >
> >  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, ))
> >
> >{
> >
> >  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: (TimeStampedP

Re: JCC strange behaviour

2019-04-07 Thread Petrus Hyvönen

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?

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, ))

{

  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, ))

{

  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, , ,
::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, ))
{
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, ,
, ::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, ))
{
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  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 
> 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 Pytho

Re: JCC strange behaviour

2019-04-05 Thread Petrus Hyvönen

Sorry should be "JCC 3.3 version" in end of first section.

On Sat, Apr 6, 2019 at 12:04 AM Petrus Hyvönen 
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

JCC strange behaviour

2019-04-05 Thread Petrus Hyvönen

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

Re: [jira] [Resolved] (PYLUCENE-46) dir module paramter

2019-03-04 Thread Petrus Hyvönen

Thanks Andi..

On Mon, Mar 4, 2019 at 11:44 PM Andi Vajda (JIRA)  wrote:

>
>  [
> https://issues.apache.org/jira/browse/PYLUCENE-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Andi Vajda resolved PYLUCENE-46.
> 
> Resolution: Fixed
>
> > __dir__ module paramter
> > 
> >
> > Key: PYLUCENE-46
> > URL: https://issues.apache.org/jira/browse/PYLUCENE-46
> > Project: PyLucene
> >  Issue Type: Bug
> >     Environment: Windows, Python3.7, JCC 3.4
> >Reporter: Petrus Hyvönen
> >Priority: Minor
> >
> > Hi,
> > Since Python 3.7 the __dir__ module attribute is part of the API to
> return the values that shall be presented from the "dir" python command.
> > [https://www.python.org/dev/peps/pep-0562/]
> > [https://docs.python.org/3/reference/datamodel.html#object.__dir__]
> > The top level module of wrapped libraries use this variable name for the
> path to the module location, which confuses some IDE's. "TypeError: 'str'
> object is not callable"
> > The best would be if this module __dir__() returned the names of the top
> level wrapped classes, but renaming the variable should solve the IDE
> problem.
> >
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
>


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

Re: Some questions on implementing java interfaces

2019-01-20 Thread Petrus Hyvönen

Hi Andy,

Thanks for your email, it answers my questions. I am doing a bunch of java
classes with extension points, and as it is sometimes hard to judge if a
default method may be needed as extension point in some scenario, I am
rather tending towards putting an extension point and let the user of the
library run the default code if they don't want to implement it (by
accessing the interface method direclty).

Best Regards
/Petrus




On Sat, Jan 19, 2019 at 11:56 PM Andi Vajda  wrote:

>
>   Hi Petrus,
>
> On Sat, 19 Jan 2019, Petrus Hyvönen wrote:
>
> > I am working on wrapping a number of (java) interfaces as python classes
> > (through JCC).
> >
> > Typically I have an "Interface" and make a class "PythonInterface",
> where I
> > take the methods and make public nativec mehtods of them. In some cases
> my
> > Interfaces has methods of same name but different parameters. What are
> the
> > best way to implement this, how does JCC behave in those cases, would
> both
> > "point" to the same python function. The alternative I have is to make
> > separate native functions and somehow separate the names of the similar
> > methods. Le me know if you have some expeience.
>
> To "implement" a Java interface from Python you first need an extension
> point Java class that actually implements this interface.
> For example, see java/org/apache/pylucene/util/PythonComparable.java
> in the PyLucene sources.
> It works just like a Java class you wish to "extend" from Python, you
> first
> need an extension point Java class that actually extends the class.
>
> If you have overloads of Java methods (ie, methods with the same name but
> different parameters) you should provide Java implementations that call a
> different native method, with a particular name, for each overload
> signature. For example, the remove() method in
> java/org/apache/pylucene/util/PythonList.java defines two native methods,
> removeAt(int) and removeObject(Object) that are called by Java
> implementations (or overrides) of the remove(int) and remove(Object)
> methods defined on java.util.List, respectively.
>
> > My second questions is on default implementation in interfaces. Some of
> the
> > default methods in the interface are unlikely to be needed to
> reimplement.
> > I have so far however put all methods as public native in the wrapping
> > class. It seems like it is possible to call the default code from python
> by
> > calling the interface directly "Interface.method(self, param)" and
> reducing
> > the effort needed on the python side. Any thoughts on this?
>
> Interface default methods are like static methods on Java classes, they
> should get wrapped by JCC just the same. If you have no reason to override
> them from Python, don't add a native "implementation".
>
> Andi..
>
> >
> > Thankful for any feedback,
> > 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

Some questions on implementing java interfaces

2019-01-19 Thread Petrus Hyvönen

Hi all,

I am working on wrapping a number of (java) interfaces as python classes
(through JCC).

Typically I have an "Interface" and make a class "PythonInterface", where I
take the methods and make public nativec mehtods of them. In some cases my
Interfaces has methods of same name but different parameters. What are the
best way to implement this, how does JCC behave in those cases, would both
"point" to the same python function. The alternative I have is to make
separate native functions and somehow separate the names of the similar
methods. Le me know if you have some expeience.

My second questions is on default implementation in interfaces. Some of the
default methods in the interface are unlikely to be needed to reimplement.
I have so far however put all methods as public native in the wrapping
class. It seems like it is possible to call the default code from python by
calling the interface directly "Interface.method(self, param)" and reducing
the effort needed on the python side. Any thoughts on this?

Thankful for any feedback,
Regards
/Petrus


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

Re: [jira] [Commented] (PYLUCENE-41) JArray type issue

2018-06-04 Thread Petrus Hyvönen

Hi Andi,

Do you have a suggestion of where to start chasing this issue? Is it on the
definition of objects in java that makes them uncastable, or...

Seems like others do not use this feature of creating two dimensional
arrays, or are there other methods of creating them?

All the best,
/Petrus


On Mon, Mar 19, 2018 at 10:30 PM, Petrus Hyvönen (JIRA) 
wrote:

>
> [ https://issues.apache.org/jira/browse/PYLUCENE-41?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=16405482#comment-16405482 ]
>
> Petrus Hyvönen commented on PYLUCENE-41:
> 
>
> Hi,
>
>
>
> Yes, it's the assignment to the object array that is an issue. This
> assignment worked in JCC 3.0 release version somehow.
>
> Regards
>
> /Petrus
>
>
>
> > JArray type issue
> > -
> >
> > Key: PYLUCENE-41
> > URL: https://issues.apache.org/jira/browse/PYLUCENE-41
> > Project: PyLucene
> >  Issue Type: Bug
> > Environment: windows 7, python 3
> >Reporter: Petrus Hyvönen
> >Priority: Major
> >
> > Hi,
> >
> > In JCC 3.0 release version and early(2.7) it is possible to make a
> double array by:
> >
> > {{mask = JArray('object')(5)}}
> > {{for i in range(5)}}
> >  {{mask[i] = JArray('double')([1.0, 2.0])}}
> > It gives in the <=3.0 following type of 'mask'
> > JArray[, , ...
> > for svn version it gives a 'TypeError: JArray[1.0, 2.0]' in the
> assignment to mask[i]
> >
> > Not sure this is a bug or a change of how to do things.
> > Best Regards
> > /Petrus
> >
> >
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
>



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

Re: [jira] [Commented] (PYLUCENE-38) JCC build error under recents versions of clang.

2018-05-26 Thread Petrus Hyvönen

Hi,

Yes, I’m using anaconda and have set up automated builds for JCC packages 
(win/mac/linux) for it at:
https://github.com/conda-forge/jcc-feedstock 


I do not remember seeing your issue in the build, but check your compile 
parameters to the ones in the build script:
https://github.com/conda-forge/jcc-feedstock/blob/master/recipe/build.sh 


The version that is in that feedstock is the 3.0 release version, the current 
svn version (as of feb) built as well but had some issues with object casting 
so have not put that on the feedstock.

If you don’t need to build it yourself you can install it with conda search jcc 
--channel conda-forge

With Best Regards
/Petrus



> On 26 May 2018, at 2:39 , Andi Vajda (JIRA)  wrote:
> 
> 
>[ 
> https://issues.apache.org/jira/browse/PYLUCENE-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16491436#comment-16491436
>  ] 
> 
> Andi Vajda commented on PYLUCENE-38:
> 
> 
> Please subscribe to pylucene-dev@lucene.apache.org to discuss this.
> The pylucene-38 bug here is irrelevant.
> 
> You seem to be using Anaconda ? Guessing from your 
> /Users/mithun/miniconda3/lib/python3.6 path ?
> I believe others have reported issues with Anaconda ?? (on the mailing list).
> I don't know what environment and would suggest you start with using a plain 
> python environment to start with PyLucene.
> 
>> JCC build error under recents versions of clang.
>> 
>> 
>>Key: PYLUCENE-38
>>URL: https://issues.apache.org/jira/browse/PYLUCENE-38
>>Project: PyLucene
>> Issue Type: Bug
>>Environment: macOS
>>   Reporter: A. Coady
>>   Priority: Major
>> 
>> {code:none}
>> jcc3/sources/JArray.cpp:315:66: error: ordered comparison between pointer 
>> and zero ('PyObject *' (aka '_object *') and 'int')
>>PyList_Type.tp_as_sequence->sq_inplace_concat(list, arg) < 0)
>> ^ ~
>> jcc3/sources/JArray.cpp:330:64: error: ordered comparison between pointer 
>> and zero ('PyObject *' (aka '_object *') and 'int')
>>PyList_Type.tp_as_sequence->sq_inplace_repeat(list, n) < 0)
>>~~ ^ ~
>> {code}
>> Comparisons between NULL and integers have been elevated from a warning to 
>> an error in recent versions of clang.  And presumably the error handling 
>> wasn't working anyway.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)

Re: [nag][VOTE] Release PyLucene 7.2.0 (rc1)

2018-01-08 Thread Petrus Hyvönen

Just to encourage, Please PMC's vote so we can have a fresh release of JCC also!

Many Thanks for you efforts,
/Petrus


> On 4 Jan 2018, at 11:29 , Andi Vajda  wrote:
> 
> 
> Two more PMC votes are needed to make this release !
> Thanks !
> 
> -- Forwarded message --
> Date: Thu, 21 Dec 2017 03:50:08 -0800 (PST)
> From: Andi Vajda 
> To: pylucene-dev@lucene.apache.org
> Cc: gene...@lucene.apache.org
> Subject: [VOTE] Release PyLucene 7.2.0 (rc1)
> 
> 
> The PyLucene 7.2.0 (rc1) release tracking the upcoming release of
> Apache Lucene 7.2.0 is ready.
> 
> A release candidate is available from:
>  https://dist.apache.org/repos/dist/dev/lucene/pylucene/7.2.0-rc1/
> 
> PyLucene 7.2.0 is built with JCC 3.1 included in these release artifacts.
> 
> JCC 3.1 supports Python 3.3+ (in addition to Python 2.3+).
> PyLucene may be built with Python 2 or Python 3.
> 
> Please vote to release these artifacts as PyLucene 7.2.0.
> Anyone interested in this release can and should vote !
> 
> Thanks !
> 
> Andi..
> 
> ps: the KEYS file for PyLucene release signing is at:
> https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
> https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS
> 
> pps: here is my +1

Note/Bug JCC, dots in pathnames

2017-09-22 Thread Petrus Hyvönen

Hi,

Not sure this is a bug or just a note, there seems to be some issues with
running JCC in a directory that contains dots. I agree this is not a
recommended thing for paths in general, but can happen sometimes.

I think its the line 1677 in python.py that gets problems:
shutil.copy2(module.split('.')[0] + '.py', modulePath)

I'm not sure what this section of code does, but maybe joining all parts
but the last would work, like

'.'.join(module.split('.')[:-1])

Regards
/Petrus



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

Plans for release of current svn?

2017-09-04 Thread Petrus Hyvönen

Dear Andi,

Are there plans for releasing a new version soon with the bugs that are
fixed in current svn?

The reason for asking is that i'm finalizing some automated build versions
for anaconda python distribution and would prefer to have these bugs fixed
and not release beta versions.

Currenly got 3.0 release working:
https://github.com/conda-forge/staged-recipes/pull/3770

Best Regards & Many Thanks,
/Petrus


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

Compiler directive for PRIxMAX macro

2017-08-30 Thread Petrus Hyvönen

Hi,

I'm trying to make some automated builds for JCC in conda-forge and ran
into some compiler problems with the PRIxMAX macro on linux. For some
compilers it seems like one should set the __STDC_FORMAT_MACROS flag.

I did this by providing -D__STDC_FORMAT_MACROS in JCC_CFLAGS envirnoment
variable, but maybe one should add a #define __STDC_FORMAT_MACROS prior to
inttypes.h import in jcc.cpp. Don't know if this would give other problems
to other compilers..

The problem with this is described in:
https://stackoverflow.com/questions/14535556/why-doesnt-priu64-work-in-this-code

Best Regards
/Petrus

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

Building jcc 3.0 under linux / anaconda python

2017-04-14 Thread Petrus Hyvönen

Hi,

First, again - many thanks to all of you who made jcc work with python 3,
this is a great thing!

Now playing with linux building and I am using anaconda python distribution
and it seems like the link library for python is called libpython3.6m.so
instead of the libpython3.6 that other python seems to use and setup.py
assume. I have another called libpython3.

If I remove this extra_links_args it seems to build fine, as well as if I
add a "m" to the end:

   elif platform == 'linux':
#kwds["extra_link_args"] = \
#lflags + ['-lpython%s.%s' %(sys.version_info[0:2])]
kwds["force_shared"] = True# requires jcc/patches/patch.43

The -m seems to indicate how python was built:
http://stackoverflow.com/questions/16675865/difference-between-python3-and-python3m-executables

Not sure if there is a danger in removing this, as long as it builds fine?

Best Regards
/Petrus






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

Re: [VOTE] Release PyLucene 6.5.0 (rc2) (now with Python 3 support)

2017-04-04 Thread Petrus Hyvönen

Hi, the JCC from the rc2 runs (as expected) fine for my application under
both 2.7 and 3.6.

On Fri, Mar 31, 2017 at 11:56 AM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> +1 to release; I ran my same "first 100K Wikipedia documents" smoke test,
> on Python 3.5.2, Java 1.8.0_121, Ubuntu 16.04.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Thu, Mar 30, 2017 at 3:27 PM, Andi Vajda <va...@apache.org> wrote:
>
> >
> > A few fixes were needed in JCC for better Windows support.
> > The PyLucene 6.5.0 rc1 vote is thus cancelled.
> >
> > I'm now calling for a vote on PyLucene 6.5.0 rc2.
> >
> > The PyLucene 6.5.0 (rc2) release tracking the recent release of
> > Apache Lucene 6.5.0 is ready.
> >
> > A release candidate is available from:
> >   https://dist.apache.org/repos/dist/dev/lucene/pylucene/6.5.0-rc2/
> >
> > PyLucene 6.5.0 is built with JCC 3.0 included in these release artifacts.
> >
> > JCC 3.0 now supports Python 3.3+ (in addition to Python 2.3+).
> > PyLucene may be built with Python 2 or Python 3.
> >
> > Please vote to release these artifacts as PyLucene 6.5.0.
> > Anyone interested in this release can and should vote !
> >
> > Thanks !
> >
> > Andi..
> >
> > ps: the KEYS file for PyLucene release signing is at:
> > https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
> > https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS
> >
> > pps: here is my +1
> >
>



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

Re: [VOTE] Release PyLucene 6.5.0 (rc1) (now with Python 3 support)

2017-03-30 Thread Petrus Hyvönen

Hi,

My current diff to the svn is below (as in the chain of mails). Now i get
it to wrap my library in both 2.7, 3.5 and 3.6.

/Regards


Index: jcc2/__init__.py
===
--- jcc2/__init__.py (revision 1789413)
+++ jcc2/__init__.py (working copy)
@@ -20,7 +20,7 @@
 from windows import add_jvm_dll_directory_to_path
 add_jvm_dll_directory_to_path()

-from jcc2.config import SHARED
+from jcc.config import SHARED
 if SHARED:
 path = os.environ['Path'].split(os.pathsep)
 eggpath =
os.path.abspath(os.path.dirname(os.path.dirname(__file__)))
Index: jcc3/sources/functions.cpp
===
--- jcc3/sources/functions.cpp (revision 1789413)
+++ jcc3/sources/functions.cpp (working copy)
@@ -300,7 +300,7 @@
 #if defined(_MSC_VER) || defined(__SUNPRO_CC)
 int __parseArgs(PyObject *args, char *types, ...)
 {
-int count = PY_SIZE((PyTupleObject *) args);
+int count = Py_SIZE((PyTupleObject *) args); //WAS PY_SIZE
 va_list list, check;

 va_start(list, types);
Index: jcc3/sources/jcc.cpp
===
--- jcc3/sources/jcc.cpp (revision 1789413)
+++ jcc3/sources/jcc.cpp (working copy)
@@ -195,11 +195,11 @@

 static PyObject *t_jccenv_strhash(PyObject *self, PyObject *arg)
 {
-static const size_t hexdig = sizeof(uintmax_t) * 2;
-uintmax_t hash = (uintmax_t) PyObject_Hash(arg);
+unsigned long long hash = (unsigned long long) PyObject_Hash(arg);
+static const size_t hexdig = sizeof(hash) * 2;
 char buffer[hexdig + 1];

-sprintf(buffer, "%0*"PRIxMAX, (int) hexdig, hash);
+sprintf(buffer, "%0*llx", (int) hexdig, hash);
 return PyUnicode_FromStringAndSize(buffer, hexdig);
 }

Index: setup.py
===
--- setup.py (revision 1789413)
+++ setup.py (working copy)
@@ -158,7 +158,7 @@
 'sunos5': ['-L%(sunos5)s/jre/lib/i386' %(JDK), '-ljava',
'-L%(sunos5)s/jre/lib/i386/client' %(JDK), '-ljvm',
'-R%(sunos5)s/jre/lib/i386:%(sunos5)s/jre/lib/i386/client'
%(JDK)],
-'win32': ['/LIBPATH:%(win32)s/lib' %(JDK), 'Ws2_32.lib', 'jvm.lib'],
+'win32': ['/LIBPATH:%(win32)s/lib' %(JDK), 'Ws2_32.lib',
'jvm.lib','/DLL'],
 'mingw32': ['-L%(mingw32)s/lib' %(JDK), '-ljvm'],
 'freebsd7': ['-L%(freebsd7)s/jre/lib/i386' %(JDK), '-ljava',
'-lverify',
  '-L%(freebsd7)s/jre/lib/i386/client' %(JDK), '-ljvm',



On Thu, Mar 30, 2017 at 5:36 PM, Petrus Hyvönen <petrus.hyvo...@gmail.com>
wrote:

> Hi,
>
> I was trying the python 2.7 build and I think the line 23 in
> jcc2/__init__.py should be:
>
> from jcc.config import SHARED
>
> (instead of from jcc2.config import..)
>
> Regards
> /Petrus
>
>
> On Thu, Mar 30, 2017 at 9:10 AM, Petrus Hyvönen <petrus.hyvo...@gmail.com>
> wrote:
>
>> Hi,
>>
>> With this version of of t_jccenv_strhash I can build both JCC and wrap
>> the library I'm using!
>>
>> Regards
>> /Petrus
>>
>>
>>
>>>
>>>
>>>> static PyObject *t_jccenv_strhash(PyObject *self, PyObject *arg)
>>>> {
>>>>unsigned long long hash = (unsigned long long) PyObject_Hash(arg);
>>>>static const size_t hexdig = sizeof(hash) * 2;
>>>>char buffer[hexdig + 1];
>>>>
>>>>sprintf(buffer, "%0*llx", (int) hexdig, hash);
>>>>return PyUnicode_FromStringAndSize(buffer, hexdig);
>>>> }
>>>>
>>>> BTW this function should be also copied to the py2 directory where we
>>>> still use int allthough PyObject_Hash returns already long on python
>>>>
>>>>> 2.x.
>>>>>
>>>>
>>>> cu,
>>>> Rudi
>>>>
>>>>
>>>>
>>
>>
>> --
>> _
>> Petrus Hyvönen, Uppsala, Sweden
>> Mobile Phone/SMS:+46 73 803 19 00 <073-803%2019%2000>
>>
>
>
>
> --
> _
> Petrus Hyvönen, Uppsala, Sweden
> Mobile Phone/SMS:+46 73 803 19 00 <073-803%2019%2000>
>



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

Re: [VOTE] Release PyLucene 6.5.0 (rc1) (now with Python 3 support)

2017-03-30 Thread Petrus Hyvönen

Hi,

I was trying the python 2.7 build and I think the line 23 in
jcc2/__init__.py should be:

from jcc.config import SHARED

(instead of from jcc2.config import..)

Regards
/Petrus


On Thu, Mar 30, 2017 at 9:10 AM, Petrus Hyvönen <petrus.hyvo...@gmail.com>
wrote:

> Hi,
>
> With this version of of t_jccenv_strhash I can build both JCC and wrap the
> library I'm using!
>
> Regards
> /Petrus
>
>
>
>>
>>
>>> static PyObject *t_jccenv_strhash(PyObject *self, PyObject *arg)
>>> {
>>>unsigned long long hash = (unsigned long long) PyObject_Hash(arg);
>>>static const size_t hexdig = sizeof(hash) * 2;
>>>char buffer[hexdig + 1];
>>>
>>>sprintf(buffer, "%0*llx", (int) hexdig, hash);
>>>return PyUnicode_FromStringAndSize(buffer, hexdig);
>>> }
>>>
>>> BTW this function should be also copied to the py2 directory where we
>>> still use int allthough PyObject_Hash returns already long on python
>>>
>>>> 2.x.
>>>>
>>>
>>> cu,
>>> Rudi
>>>
>>>
>>>
>
>
> --
> _
> Petrus Hyvönen, Uppsala, Sweden
> Mobile Phone/SMS:+46 73 803 19 00 <073-803%2019%2000>
>



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

Re: [VOTE] Release PyLucene 6.5.0 (rc1) (now with Python 3 support)

2017-03-30 Thread Petrus Hyvönen

Hi,

With this version of of t_jccenv_strhash I can build both JCC and wrap the
library I'm using!

Regards
/Petrus



>
>
>> static PyObject *t_jccenv_strhash(PyObject *self, PyObject *arg)
>> {
>>unsigned long long hash = (unsigned long long) PyObject_Hash(arg);
>>static const size_t hexdig = sizeof(hash) * 2;
>>char buffer[hexdig + 1];
>>
>>sprintf(buffer, "%0*llx", (int) hexdig, hash);
>>return PyUnicode_FromStringAndSize(buffer, hexdig);
>> }
>>
>> BTW this function should be also copied to the py2 directory where we
>> still use int allthough PyObject_Hash returns already long on python
>>
>>> 2.x.
>>>
>>
>> cu,
>> Rudi
>>
>>
>>


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

Re: [VOTE] Release PyLucene 6.5.0 (rc1) (now with Python 3 support)

2017-03-29 Thread Petrus Hyvönen

Hi,

Yes, there are windows users :)

I've ran a quick test, it builds fine on python 2.7 but I'm getting some
linker error under python 3.6 and 3.5 (didn't try lower).

The linker error states:

jcc3/sources/jcc.cpp(202): error C3688: invalid literal suffix 'PRIxMAX';
literal operator or literal operator template
'operator ""PRIxMAX' not found
jcc3/sources/jcc.cpp(202): error C2664: 'int sprintf(char *const ,const
char *const ,...)': cannot convert argument 2 fr
om 'int' to 'const char *const '
jcc3/sources/jcc.cpp(202): note: Conversion from integral type to pointer
type requires reinterpret_cast, C-style cast o
r function-style cast
error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio
14.0\\VC\\BIN\\amd64\\cl.exe' failed with exit status 2

the jcc.cpp code is:
static PyObject *t_jccenv_strhash(PyObject *self, PyObject *arg)
{
static const size_t hexdig = sizeof(uintmax_t) * 2;
uintmax_t hash = (uintmax_t) PyObject_Hash(arg);
char buffer[hexdig + 1];

sprintf(buffer, "%0*"PRIxMAX, (int) hexdig, hash);
return PyUnicode_FromStringAndSize(buffer, hexdig);
}

I don't understand the PRIxMAX stuff there, what does it mean?

MANY thanks for working with the Python 3 port...

Regards
/Petrus


On Wed, Mar 29, 2017 at 10:43 PM, Andi Vajda <va...@apache.org> wrote:

>
> > On Mar 29, 2017, at 13:36, Ruediger Meier <sweet_...@gmx.de> wrote:
> >
> > On Wednesday 29 March 2017, Andi Vajda wrote:
> >
> >>> Regarding that release candidate. There are still one or two minor
> >>> issues on Linux
> >>
> >> I'm aware of the fsct that the -lpython... link line for shared mode
> >> on linux needs editing depending on the versions of python used. Are
> >> there other issues on linux ?
> >
> > No other issues. I've fixed -lpython for myself like this
> > https://github.com/rudimeier/jcc/commit/b4a7987ebeeb96d6c71b7635160f79
> 8303715877
> >
> > but you probably want do avoid the .so version earlier like you did for
> > OSX. You may fix it blindly as you prefer and I could test it.
> >
> >>> and Windows I think. I will test again and report soon.
> >>
> >> I have no access to windows anymore. We (Apache committers) used to
> >> get a MSDN free subscription but that program was apparently
> >> discontinued. If you have access to windows, thank you for trying out
> >> PyLucene and JCC there !
> >
> > I could somehow organize a windows for testing, though it would be
> > painful for me. ;) I would do it shortly before final release if nobody
> > else does it.
>
> Don't bother. If there are no windows users willing to test this then we
> don't need to support windows anymore.
>
> > So far I believe that the patch here in my last comment would do it
> > https://github.com/rudimeier/jcc/issues/1
> > (It was also part of tommykoch's port)
>
> Ok, I'll take another look...
>
> Andi..
>
> >
> > cu,
> > Rudi
>
>


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

Re: Installing PyLucene

2017-01-04 Thread Petrus Hyvönen

Dear Thomas,

I would be very interested in a python 3 port of JCC. I am not a very
skilled developer, looked at starting a development based on the old
python-3 version but it's beyond my current skills.

I would be happy to help and test and review the JCC patches, I think your
patches would be a valuable contribution to JCC.

With Best Regards
/Petrus

On Wed, Jan 4, 2017 at 9:13 AM, Thomas Koch <k...@orbiteam.de> wrote:

> > NameError: global name 'WindowsError' is not defined
>
> Note that PyLucene currently lacks official Python3 support!
> We've done a port of PyLucene 3.6 (!) to support Python3 and offered the
> patches needed to JCC and PyLucene for use/review on the list - but didn't
> get any feedback so far.
> cf. https://www.mail-archive.com/pylucene-dev@lucene.apache.
> org/msg02167.html <https://www.mail-archive.com/
> pylucene-dev@lucene.apache.org/msg02167.html>
>
> Regards,
> Thomas
>
-- 
_____
Petrus Hyvönen, Uppsala, Sweden
Mobile Phone/SMS:+46 73 803 19 00

Re: [POLL] What should happen to PyLucene now?

2016-07-02 Thread Petrus Hyvönen

Hi,

I'm a user of JCC only. I would like to see a python-3 version but I do not
have the skills / time to do it myself unfortunately. I can help in testing.

I have looked at other alternative for JCC but none seems to provide the
integration such well, the "import" statement also is difficult in an
dynamic integration.

Many Thanks
/Petrus

On Fri, Jul 1, 2016 at 11:32 AM, Jan Høydahl <jan@cominvent.com> wrote:

> Hi
>
> As you all know not much has happened with PyLucene lately.
> So I’m throwing out this poll to check the sentiment of the community.
>
> Question: What should happen to PyLucene now?
>
> [ ]  I’m happy with the last 4.x release, no need for new releases
> [ ]  Please, a new 6.x release (but I can’t contribute)
> [ ]  I’ll help make a new release happen, if I get some help!
> [X]  Only care about the JCC part
> [ ]  Close down the sub project
> [ ]  Don’t care. I’m no longer a user
> [ ]  Other:
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
> Lucene commiter & PMC member

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

Re: Current state of PyLucene

2015-11-16 Thread Petrus Hyvönen

Hi,

Just want to jump in and state my interest in the JCC part of it. I'm not
using pylucene but using another library wrapped with JCC, which is working
well.

My coding skills are not really there to help much out, but for what it is
worth I can at least state my appreciation for this project, which is to a
very large degree (totally in last years?) Andi's work. I have not been
responding in the voting for releases since i'm neither a user of pylucene
or part of any organized group.

As mentioned earlier, JCC for python 3 would be high on my wishlist. :)

Regards

On Mon, Nov 16, 2015 at 7:28 PM, Andi Vajda <va...@apache.org> wrote:

>
> > On Nov 15, 2015, at 22:54, Jeff Breidenbach <j...@jab.org> wrote:
> >
> > I don't understand this. Lucene is the dominant open source
> > search software, and Python continues to gain popularity.
> > Why is there a decline in interest?
>
> Dunno. The PMC lives in Java land and doesn't pay much attention. And I
> stopped nagging them. As for users, there are plenty of them (?) but they
> don't participate or otherwise show interest by voting for releases.
>
> Andi..

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

Re: Python 3

2015-06-23 Thread Petrus Hyvönen

Hi,

Just a heads-up, I'm not a PyLucene user but a frequent user of JCC in
another context wrapping scientific libraries in java. I would appreciate a
Python 3 compatible JCC in the future, most libraries are now Python 3
compatible and I think in the future this will be the python standard for
scientific computing. Of my stack that I use today I think JCC is the only
library requiring python 2.

My programming skills are limited, but can provide debugging support :)

Regards
/Petrus



On Mon, Jun 1, 2015 at 6:55 PM, Andi Vajda va...@apache.org wrote:


 On Mon, 1 Jun 2015, Johan Jonkers wrote:

  Hello everyone,

 I was wondering if there are plans to support python 3 for PyLucene. I
 know there is an experimental Python 3 version of JCC but it is from 2010 I
 think, so a bit outdated. We would like to migrate from python 2.7 to 3.0
 but we need PyLucene to work for that. Any information on this matter, like
 perhaps a roadmap?, would be appreciated.


 Two things need to happen:
   - the python 3 port of JCC needs to be revived (patches are welcome)
   - the Lucene team needs to vote on releases for another release of
 PyLucene to actually happen.

 I prepared a PyLucene release candaidate for version 4.10.4 on March 10th
 and called for a release vote then.

 Only one PyLucene user responded and _no_ Lucene PMC members (besides
 myself) voted on it. Without votes, no PyLucene releases can happen.

 As it is, the project is dormant for lack of interest.

 Andi..


 Regards,

 Johan





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

Re: Remote (java) debugging w JCC?

2015-05-17 Thread Petrus Hyvönen

Hi,

Sometimes writing an email helps you to seek the source..

Yes, it works,

The vmargs parameter takes also a sequence of things, so:

.initVM(vmargs=['-agentlib:jdwp=transport=dt_socket,server=y,address=8000','-Xdebug'])

remote debugging from eclipse to JVM seems to work fine with breakpoints
etc.

Sorry for the noise.. :)
Regards
/Petrus


On Sun, May 17, 2015 at 9:58 PM, Petrus Hyvönen petrus.hyvo...@gmail.com
wrote:

 Hi,

 I'm trying to find some potential bugs in the java code I've wrapped and
 thought about the possibilities to connect a remote debugger to the JVM.

 I am no java expert but found that JVM's can be debugged when started with
 some jvm arguments. Such as string is for example
 -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=4242. I have
 tried to feed this to the vmargs, but I get an error and think it's because
 the initVM splits the input string on commas to separate arguments.

 Do you know if there is a way to trick around this split?

 Does anyone on the list have experience on remote debugging of JCC wrapped
 java, if it can work at all?

 Many thanks for feedback
 /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

Re: Set path to JRE / JDK in code

2015-01-21 Thread Petrus Hyvönen

Hi,

It is primary on my wrapped library that this applies, for so it can be
easily installed.

Yes on windows the JRE is found using the PATH. I haven't been able to
locate where this is done, as I would prefer to use a direct variable or
separate environment variable for this to keep it boxed from the system
variables.

I have however found a way now that works fine based on updating the PATH
as a first thing in the __init__.py file in the wrapped library by
prepending:

import os
os.environ[PATH] = rmypath\jre\bin\server + os.pathsep +
os.environ[PATH]

the installer takes care of updating the path to the right place later on.

Many thanks
/Petrus



On Tue, Jan 20, 2015 at 7:14 PM, Andi Vajda va...@apache.org wrote:


 On Tue, 20 Jan 2015, Petrus Hyvönen wrote:

  Hi,

 I'm trying to package a wrapped library together with a non system-wide
 java JDK so that it can be easily installed.

 Can I somehow direct which JDK to use besides using JCC_JDK and putting
 the
 JRE in the PATH (I'm currently under windows)? The JCC_JDK could be
 patched
 in the setup.py but the PATH JRE that is accessed during running the
 wrapped library I don't understand where it is accessed, or how to patch
 this?


 So you're asking how to control where to pickup the JRE DLLs (on Windows)
 at runtime ? If I remember correctly, on Windows you just set the Path
 environment variable, no ?

  For example it would be good to have this in the config.py file if
 possible?


 If you're sure config.py is run _before_ any JRE DLL is loaded, you might
 be able to change the Path fron there too.

 Andi..



 Any thoughts or someone who's done this already?

 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

Re: How does JCC choose which java version to use?

2014-03-21 Thread Petrus Hyvönen

Hi,

I guess Andi is the best to answer, but just to make sure that you have set
the JCC_JDK variable set. JCC tries to find it by itself but if it's set it
uses JCC_JDK as the path to the java.

Regards
/Petrus





On Fri, Mar 21, 2014 at 3:27 PM, Toivo Henningsson 
toivo.hennings...@modelon.com wrote:

  Hi!



 How does JCC choose which java version to use?

 I've had some users that had troubles (on linux) because they had both
 java 6 and java 7 installed,

 and it seems that JCC was invoking java 6 while the .class files that JCC
 was used on were created with java 7.



 Is there some way to influence which java version that JCC picks up?



 Best regards,

 Toivo



 *Toivo Henningsson, PhD*

 Software Engineer

 Simulation  Optimization RD


 Phone direct: +46 46 286 22 11

 Email: toivo.hennings...@modelon.com


 [image: Description: Description: Modelon_2011_Gradient_RGB_400]
--

 Modelon AB
 Ideon Science Park
 SE-223 70 Lund, Sweden

 Phone: +46 46 286 2200
 Fax: +46 46 286 2201


 Web: http://www.modelon.com




  This email and any attachments are intended solely for the use of the
 individual or entity to whom it is addressed and may be confidential and/or
 privileged. If you are not one of the named recipients or have received
 this email in error, (i) you should not read, disclose, or copy it, (ii)
 please notify sender of your receipt by reply email and delete this email
 and all attachments, (iii) Modelon does not accept or assume any liability
 or responsibility for any use of or reliance on this email.




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

Re: Problem using generic types?

2014-02-02 Thread Petrus Hyvönen

Hi Andi and Others,

The latest trunk jcc works and builds very fine on my windows machine, and 
happy about the extendend support of generics. But I am experiencing the 
problem below when building on my mac, using same wrap parameters as on the 
windows platform. To me it seems like some compiler problem related to macros, 
but don't know.

Does anyone have experience of these failures?

Regards
/Petrus


error: expected unqualified-id
  self-parameters[0] = ::PY_TYPE([D);
   ^
/Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
 note: 
  expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
  ^
build/_orekit/__wrap__.cpp:2344:44: error: use of undeclared identifier
  'D$$Type'
  self-parameters[0] = ::PY_TYPE([D);
   ^
/Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
 note: 
  expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
  ^
scratch space:73:1: note: expanded from here
D$$Type
^
build/_orekit/__wrap__.cpp:2344:55: error: expected ']'
  self-parameters[0] = ::PY_TYPE([D);
  ^
build/_orekit/__wrap__.cpp:2344:52: note: to match this '['
  self-parameters[0] = ::PY_TYPE([D);



On 14 Jan 2014, at 19:02 , Andi Vajda va...@apache.org wrote:

 
  Hi Petrus,
 
 On Jan 14, 2014, at 4:24, Petrus Hyvönen petrus.hyvo...@gmail.com wrote:
 
 Dear Andi,
 
 Many many thanks for looking into this! 
 
 I am on travel for a week and do not have the computer with the special case 
 with me to test. I did now however run it on the library that I am wrapping, 
 and there get some errors in the creation of the wrapped module (orekit):
 
 build/_orekit/__wrap__.cpp:86504:89: error: no member named
   'HarmonicOscillator$Parametric$$Type' in namespace
 
 I believe I fixed this bug in rev 1557613, header files for classes for 
 inherited fixed parameters were not included as required.
 
 Andi..
 
   'org::apache::commons::math3::analysis::function'
   ...= 
 ::org::apache::commons::math3::analysis::function::PY_TYPE(HarmonicOs...
 ~~~^
 /Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23:
  note: 
   expanded from macro 'PY_TYPE'
 #define PY_TYPE(name) name##$$Type
   ^
 scratch space:63:1: note: expanded from here
 HarmonicOscillator$Parametric$$Type
 ^
 build/_orekit/__wrap__.cpp:217752:55: error: no member named
   'OrekitMessages$$Type' in namespace 'org::orekit::errors'
 self-parameters[0] = 
 ::org::orekit::errors::PY_TYPE(OrekitMessages);
~~~^
 /Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23:
  note: 
   expanded from macro 'PY_TYPE'
 #define PY_TYPE(name) name##$$Type
   ^
 scratch space:9:1: note: expanded from here
 OrekitMessages$$Type
 ^
 2 errors generated.
 error: command 'gcc' failed with exit status 1
 
 
 
 The OrekitMessages is defined as a public enum OrekitMessages implements 
 Localizable { ...
 and the public class HarmonicOscillator implements 
 UnivariateDifferentiable, DifferentiableUnivariateFunction. 
 
 Maybe this says you something, I will try to test more and run my test case 
 in .
 
 Best Regards and again, many thanks again!
 /petrus
  
 
 
 
 
 On 11 Jan 2014, at 14:23 , Andi Vajda va...@apache.org wrote:
 
 
 Hi Petrus,
 
 On Mon, 30 Dec 2013, Petrus Hyvönen wrote:
 
 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..
 
 I think I fixed the problem and added an improvement to generics support 
 along the way. Please check out rev 1557423 from jcc's trunk, rebuild your 
 module with it and let me know how it's working for you.
 
 The bug had to do with SimpleClass2's wrapper class missing its parameters 
 slot which it should get from its superclass, SimpleClass. When calling a
 method on SimpleClass from SimpleClass2, the missing parameters in the
 wrapper's struct would cause memory to get trashed.
 
 In addition to fixing the bug, I also improved support for fixed class 
 parameters. Now, if you change SimpleClass's return_null() method to return 
 new Integer(12) instead, when calling it on SimpleClass2, 12 is returned 
 instead of Object: 12.
 
 Andi..
 
 public class SimpleClassT { public SimpleClass() { 
 System.out.println(Created SimpleClass); }
public T return_null() {
return (T) new Integer(12);
}
 
 }
 
 
 
 Best Regards
 /Petrus
 
 
 
 On Mon, Dec 30, 2013

Re: Problem using generic types?

2014-02-02 Thread Petrus Hyvönen

Hi,

It's part of a class PointVectorValuePair and PointValuePair in the apache 
math commons 
(http://commons.apache.org/proper/commons-math/javadocs/api-3.2/org/apache/commons/math3/optimization/PointVectorValuePair.html)

I have tried to reserve a bunch of things like 'Point', 'Value', 'Pair' without 
any difference. If I go through the __wrap__ file, it looks like this [D object 
to wrap is a very odd one, the other PY_TYPE wrapping seems to have 'proper' 
names without special characters. It's the functions PointValuePair and 
PointVectorValuePair that seems to have this strage class wrapping.  I cannot 
find a class named D. From the API doc's I would guess it's trying to set a 
double [] type.

extract from __wrap__:

under namespace org {
  namespace apache {
namespace commons {
  namespace math3 {
namespace optimization {

...

  static int t_PointVectorValuePair_init_(t_PointVectorValuePair *self, 
PyObject *args, PyObject *kwds)
  {
switch (PyTuple_GET_SIZE(args)) {
 case 2:
  {
JArray jdouble  a0((jobject) NULL);
JArray jdouble  a1((jobject) NULL);
PointVectorValuePair object((jobject) NULL);

if (!parseArgs(args, [D[D, a0, a1))
{
  INT_CALL(object = PointVectorValuePair(a0, a1));
  self-object = object;
  self-parameters[0] = ::PY_TYPE([D);
  self-parameters[1] = ::PY_TYPE([D);
  break;
}

Regards
/petrus



 = ::PY_TYPE([D);
   ^
/Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
 note: 
  expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
  ^
build/_orekit/__wrap__.cpp:58329:44: error: use of undeclared identifier
  'D$$Type'
  self-parameters[0] = ::PY_TYPE([D);
   ^
/Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
 note: 
  expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
  ^
scratch space:109:1: note: expanded from here
D$$Type
^
build/_orekit/__wrap__.cpp:58329:55: error: expected ']'
  self-parameters[0] = ::PY_TYPE([D);
  ^
build/_orekit/__wrap__.cpp:58329:52: note: to match this '['
  self-parameters[0] = ::PY_TYPE([D);


On 02 Feb 2014, at 19:48 , Andi Vajda va...@apache.org wrote:

 
 On Feb 2, 2014, at 10:08, Petrus Hyvönen petrus.hyvo...@gmail.com wrote:
 
 Hi Andi and Others,
 
 The latest trunk jcc works and builds very fine on my windows machine, and 
 happy about the extendend support of generics. But I am experiencing the 
 problem below when building on my mac, using same wrap parameters as on the 
 windows platform. To me it seems like some compiler problem related to 
 macros, but don't know.
 
 Does anyone have experience of these failures?
 
 Regards
 /Petrus
 
 
 error: expected unqualified-id
 self-parameters[0] = ::PY_TYPE([D);
  ^
 /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
  note: 
 expanded from macro 'PY_TYPE'
 #define PY_TYPE(name) name##$$Type
 ^
 build/_orekit/__wrap__.cpp:2344:44: error: use of undeclared identifier
 'D$$Type'
 self-parameters[0] = ::PY_TYPE([D);
 
 Take a look at the code around line 2344 in that __wrap__.cpp file and figure 
 out what java code this corresponds to. You might be using a classname that's 
 a C macro on some platforms - do you have a class named D for example ?
 If you're hitting such a name conflict, add that name to the --reserved list 
 passed to jcc.
 
 Andi..
 
  ^
 /Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
  note: 
 expanded from macro 'PY_TYPE'
 #define PY_TYPE(name) name##$$Type
 ^
 scratch space:73:1: note: expanded from here
 D$$Type
 ^
 build/_orekit/__wrap__.cpp:2344:55: error: expected ']'
 self-parameters[0] = ::PY_TYPE([D);
 ^
 build/_orekit/__wrap__.cpp:2344:52: note: to match this '['
 self-parameters[0] = ::PY_TYPE([D);
 
 
 
 On 14 Jan 2014, at 19:02 , Andi Vajda va...@apache.org wrote:
 
 
 Hi Petrus,
 
 On Jan 14, 2014, at 4:24, Petrus Hyvönen petrus.hyvo...@gmail.com wrote:
 
 Dear Andi,
 
 Many many thanks for looking into this! 
 
 I am on travel for a week and do not have the computer with the special 
 case with me to test. I did now however run it on the library that I am 
 wrapping, and there get some errors in the creation of the wrapped module 
 (orekit):
 
 build

Re: Problem using generic types?

2014-02-02 Thread Petrus Hyvönen

Hi Andi,

Yes, the confusing thing is that it works well under windows. I compared
the code in __wrap__ and it looks different in the windows version:

 static int t_PointVectorValuePair_init_(t_PointVectorValuePair *self,
PyObject *args, PyObject *kwds)
  {
switch (PyTuple_GET_SIZE(args)) {
 case 2:
  {
JArray jdouble  a0((jobject) NULL);
JArray jdouble  a1((jobject) NULL);
PointVectorValuePair object((jobject) NULL);

if (!parseArgs(args, [D[D, a0, a1))
{
  INT_CALL(object = PointVectorValuePair(a0, a1));
  self-object = object;
  break;
}
  }


So no Parameters[] stuff in windows version.. On mac I'm using java v
1.7.0_45 and 1.6.0_35 under windows. could that make a difference?

I'm using a mvn downloaded version of the apache.math jar, but source is:

public class PointVectorValuePair extends Pairdouble[], double[]
implements Serializable {
/** Serializable UID. */
private static final long serialVersionUID = 20120513L;

/**
 ...
 */
public PointVectorValuePair(final double[] point,
final double[] value) {
this(point, value, true);
}

/**
...
 */
public PointVectorValuePair(final double[] point,
final double[] value,
final boolean copyArray) {
super(copyArray ?
  ((point == null) ? null :
   point.clone()) :
  point,
  copyArray ?
  ((value == null) ? null :
   value.clone()) :
  value);
}

...

full code at
http://commons-math/jacoco/org.apache.commons.math3.optimization/PointVectorValuePair.java.html



Regards
/petrus


On 02 Feb 2014, at 22:54 , Andi Vajda va...@apache.org wrote:


On Feb 2, 2014, at 13:41, Petrus Hyvönen petrus.hyvo...@gmail.com wrote:

Hi,

It's part of a class PointVectorValuePair and PointValuePair in the
apache math commons (
http://commons.apache.org/proper/commons-math/javadocs/api-3.2/org/apache/commons/math3/optimization/PointVectorValuePair.html
)

I have tried to reserve a bunch of things like 'Point', 'Value', 'Pair'
without any difference. If I go through the __wrap__ file, it looks like
this [D object to wrap is a very odd one, the other PY_TYPE wrapping seems
to have 'proper' names without special characters. It's the functions
PointValuePair and PointVectorValuePair that seems to have this strage
class wrapping.  I cannot find a class named D. From the API doc's I would
guess it's trying to set a double [] type.

extract from __wrap__:

under namespace org {
namespace apache {
  namespace commons {
namespace math3 {
  namespace optimization {

...

static int t_PointVectorValuePair_init_(t_PointVectorValuePair
*self, PyObject *args, PyObject *kwds)
{
  switch (PyTuple_GET_SIZE(args)) {
   case 2:
{
  JArray jdouble  a0((jobject) NULL);
  JArray jdouble  a1((jobject) NULL);
  PointVectorValuePair object((jobject) NULL);

  if (!parseArgs(args, [D[D, a0, a1))


It could just be that you found a bug in jcc's handling of generic
parameters that are arrays. I suspect you have some double[] (or worse:
double[][]) somewhere in the java source.
But then this should fail the same way on Windows.
Can you please post the original java source for that class here ?

Andi..

  {
INT_CALL(object = PointVectorValuePair(a0, a1));
self-object = object;
self-parameters[0] = ::PY_TYPE([D);
self-parameters[1] = ::PY_TYPE([D);
break;
  }

Regards
/petrus



= ::PY_TYPE([D);
 ^
/Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
note:
expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
^
build/_orekit/__wrap__.cpp:58329:44: error: use of undeclared identifier
'D$$Type'
self-parameters[0] = ::PY_TYPE([D);
 ^
/Users/petrus/anaconda/envs/_build/lib/python2.7/site-packages/jcc/sources/macros.h:66:23:
note:
expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
^
scratch space:109:1: note: expanded from here
D$$Type
^
build/_orekit/__wrap__.cpp:58329:55: error: expected ']'
self-parameters[0] = ::PY_TYPE([D);
^
build/_orekit/__wrap__.cpp:58329:52: note: to match this '['
self-parameters[0] = ::PY_TYPE([D);


On 02 Feb 2014, at 19:48 , Andi Vajda va...@apache.org wrote:


On Feb 2, 2014, at 10:08, Petrus Hyvönen petrus.hyvo...@gmail.com wrote:

Hi Andi

Re: Problem using generic types?

2014-02-02 Thread Petrus Hyvönen

Thanks Andi! 

Rev 1563753 Builds and runs fine now on the Mac and Windows!

I need to check my Windows machine and get rid of any old versions, think it 
shouldn't be there but obviously it is  strange that it worked..

Many thanks!

Regards
/Petrus


On 03 Feb 2014, at 2:44 , Andi Vajda va...@apache.org wrote:

 
 And I've now reproduced it by adding s SimpleClass3 class to the example you 
 had sent in last time that looks like this:
 
 public class SimpleClass3 extends SimpleClassdouble[]{
 
 public SimpleClass3(){}
   public void testInJava(){
   System.out.println(this.return_null());
   } }
 
 I think I fixed this. Please try jcc rev 1563753.
 Thanks !
 
 Andi..

Re: Problem using generic types?

2014-01-14 Thread Petrus Hyvönen

Dear Andi,

Many many thanks for looking into this! 

I am on travel for a week and do not have the computer with the special case 
with me to test. I did now however run it on the library that I am wrapping, 
and there get some errors in the creation of the wrapped module (orekit):

build/_orekit/__wrap__.cpp:86504:89: error: no member named
  'HarmonicOscillator$Parametric$$Type' in namespace
  'org::apache::commons::math3::analysis::function'
  ...= ::org::apache::commons::math3::analysis::function::PY_TYPE(HarmonicOs...
~~~^
/Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23:
 note: 
  expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
  ^
scratch space:63:1: note: expanded from here
HarmonicOscillator$Parametric$$Type
^
build/_orekit/__wrap__.cpp:217752:55: error: no member named
  'OrekitMessages$$Type' in namespace 'org::orekit::errors'
self-parameters[0] = ::org::orekit::errors::PY_TYPE(OrekitMessages);
   ~~~^
/Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23:
 note: 
  expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
  ^
scratch space:9:1: note: expanded from here
OrekitMessages$$Type
^
2 errors generated.
error: command 'gcc' failed with exit status 1



The OrekitMessages is defined as a public enum OrekitMessages implements 
Localizable { ...
and the public class HarmonicOscillator implements UnivariateDifferentiable, 
DifferentiableUnivariateFunction. 

Maybe this says you something, I will try to test more and run my test case in .

Best Regards and again, many thanks again!
/petrus
 




On 11 Jan 2014, at 14:23 , Andi Vajda va...@apache.org wrote:

 
 Hi Petrus,
 
 On Mon, 30 Dec 2013, Petrus Hyvönen wrote:
 
 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..
 
 I think I fixed the problem and added an improvement to generics support 
 along the way. Please check out rev 1557423 from jcc's trunk, rebuild your 
 module with it and let me know how it's working for you.
 
 The bug had to do with SimpleClass2's wrapper class missing its parameters 
 slot which it should get from its superclass, SimpleClass. When calling a
 method on SimpleClass from SimpleClass2, the missing parameters in the
 wrapper's struct would cause memory to get trashed.
 
 In addition to fixing the bug, I also improved support for fixed class 
 parameters. Now, if you change SimpleClass's return_null() method to return 
 new Integer(12) instead, when calling it on SimpleClass2, 12 is returned 
 instead of Object: 12.
 
 Andi..
 
 public class SimpleClassT { public SimpleClass() { 
 System.out.println(Created SimpleClass); }
public T return_null() {
return (T) new Integer(12);
}
 
 }
 
 
 
 Best Regards
 /Petrus
 
 
 
 On Mon, Dec 30, 2013 at 10:36 AM, Andi Vajda va...@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 SimpleClassT {
 public SimpleClass() {
 System.out.println(Created SimpleClass);
 }
   public T return_null() {
   return  null;
   }
 
 }
 
 
 
 public class SimpleClass2 extends SimpleClassInteger{
 
 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 va...@apache.org wrote:
 
 
 On Dec 27, 2013, at 17:36, Petrus Hyvönen petrus.hyvo...@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

Re: Problem using generic types?

2014-01-14 Thread Petrus Hyvönen

Dear Andi,

Many many thanks for looking into this! 

I am on travel for a week and do not have the computer with the special case 
with me to test. I did now however run it on the library that I am wrapping, 
and there get some errors in the creation of the wrapped module (orekit):

build/_orekit/__wrap__.cpp:86504:89: error: no member named
  'HarmonicOscillator$Parametric$$Type' in namespace
  'org::apache::commons::math3::analysis::function'
  ...= ::org::apache::commons::math3::analysis::function::PY_TYPE(HarmonicOs...
~~~^
/Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23:
 note: 
  expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
  ^
scratch space:63:1: note: expanded from here
HarmonicOscillator$Parametric$$Type
^
build/_orekit/__wrap__.cpp:217752:55: error: no member named
  'OrekitMessages$$Type' in namespace 'org::orekit::errors'
self-parameters[0] = ::org::orekit::errors::PY_TYPE(OrekitMessages);
   ~~~^
/Users/petrus/anaconda/lib/python2.7/site-packages/JCC-2.18-py2.7-macosx-10.5-x86_64.egg/jcc/sources/macros.h:66:23:
 note: 
  expanded from macro 'PY_TYPE'
#define PY_TYPE(name) name##$$Type
  ^
scratch space:9:1: note: expanded from here
OrekitMessages$$Type
^
2 errors generated.
error: command 'gcc' failed with exit status 1



The OrekitMessages is defined as a public enum OrekitMessages implements 
Localizable { ...
and the public class HarmonicOscillator implements UnivariateDifferentiable, 
DifferentiableUnivariateFunction. 

Maybe this says you something, I will try to test more and run my test case in .

Best Regards and again, many thanks again!
/Petrus

Re: Problem using generic types?

2013-12-30 Thread Petrus Hyvönen

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 va...@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 SimpleClassT {
 public SimpleClass() {
 System.out.println(Created SimpleClass);
 }
public T return_null() {
return  null;
}

 }



 public class SimpleClass2 extends SimpleClassInteger{

 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 va...@apache.org wrote:


  On Dec 27, 2013, at 17:36, Petrus Hyvönen petrus.hyvo...@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
 AbstractReconfigurableDetectorElevationDetector
 hand = ContinueOnEvent().of_(ElevationDetector)   # a
 java ContinueOnEventElevationDetector 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 va...@apache.org wrote:


  On Dec 15, 2013, at 5:43, Petrus Hyvönen petrus.hyvo...@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

Re: Problem using generic types?

2013-12-27 Thread Petrus Hyvönen

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
AbstractReconfigurableDetectorElevationDetector
hand = ContinueOnEvent().of_(ElevationDetector)   # a
java ContinueOnEventElevationDetector 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.

Regards
/Petrus






On Sun, Dec 15, 2013 at 10:36 AM, Andi Vajda va...@apache.org wrote:


  On Dec 15, 2013, at 5:43, Petrus Hyvönen petrus.hyvo...@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=0x00010005da1a, 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: [0x7fff5fb8,0x7fff5fc0],  sp=0x7fff5fbff470,
  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
 ContinueOnEventElevationDetector() 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 va...@apache.org wrote:
 
 
  On Dec 14, 2013, at 19:14, Petrus Hyvönen petrus.hyvo...@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

Re: Problem using generic types?

2013-12-15 Thread Petrus Hyvönen

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=0x00010005da1a, 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: [0x7fff5fb8,0x7fff5fc0],  sp=0x7fff5fbff470,  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 
ContinueOnEventElevationDetector() 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?

WIth best regards
/Petrus



On 15 Dec 2013, at 2:40 , Andi Vajda va...@apache.org wrote:

 
 On Dec 14, 2013, at 19:14, Petrus Hyvönen petrus.hyvo...@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 
 ContinueOnEventElevationDetector());
 
 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

Automatic typecasting of int to float

2013-12-14 Thread Petrus Hyvönen

Hi!

I am converting some java code to python scripts, using a JCC wrapped library.

One thing that strikes me is that java seems to have a automatic typecast of 
int to float, which is not present in the JCC wrapped library.

i.e. if a tmp=100 and obj.shift(tmp) is executed, and the method expects a 
float, it seems to fail in the wrapped code while working in java. Of course it 
can be explicitly typed obj.shift((float) tmp) but it does look as readable.

This is a minor thing, but could it be enabled so that this automatic 
conversion from int to floats are done if no other matching signatures are 
found? (I assume this is the way java works, I'm no java expert..) 

Many thanks
/Petrus

Re: Automatic typecasting of int to float

2013-12-14 Thread Petrus Hyvönen

Hi,

Yes sorry it should have been float(tmp).


Yes, could be added to the java code, and if it's complex its probably not an 
issue in many cases.

Regards
/Petrus


On 14 Dec 2013, at 20:59 , Andi Vajda va...@apache.org wrote:

 
 On Dec 14, 2013, at 16:46, Petrus Hyvönen petrus.hyvo...@gmail.com wrote:
 
 Hi!
 
 I am converting some java code to python scripts, using a JCC wrapped 
 library.
 
 One thing that strikes me is that java seems to have a automatic typecast of 
 int to float, which is not present in the JCC wrapped library.
 
 i.e. if a tmp=100 and obj.shift(tmp) is executed, and the method expects a 
 float, it seems to fail in the wrapped code while working in java. Of course 
 it can be explicitly typed obj.shift((float) tmp) but it does look as 
 readable.
 
 In python, no, that syntax is incorrect. But you could use 100.0 instead of 
 100. Almost as readable. Or add an intermediate method that casts to float.
 
 Could that feature be added to jcc ? sure, but it gets complicated fast. If 
 you control both ends of the app (the python and the java code), it's easiest 
 to add an int overload to the shift method and call the float version.
 
 Andi..
 
 
 This is a minor thing, but could it be enabled so that this automatic 
 conversion from int to floats are done if no other matching signatures are 
 found? (I assume this is the way java works, I'm no java expert..) 
 
 Many thanks
 /Petrus

Problem using generic types?

2013-12-14 Thread Petrus Hyvönen

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.

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 
ContinueOnEventElevationDetector());

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

Error when java exception

2013-02-04 Thread Petrus Hyvönen

Hi,

I have some strange error when an java exception occurs in the wrapped
library 'orekit', the exception text is not printed and a python error
NameError: global name 'StringWriter' is not defined occurs in __init__.py

I am using the --use_full_names option, latest JCC from SVN.

It is in the __init__.py file, mine looks like:

import os, sys

if sys.platform == 'win32':
  import jcc, _orekit
else:
  import _orekit

__dir__ = os.path.abspath(os.path.dirname(__file__))

class JavaError(Exception):
  def getJavaException(self):
return self.args[0]
  def __str__(self):
writer = StringWriter()
self.getJavaException().printStackTrace(PrintWriter(writer))
return \n.join((super(JavaError, self).__str__(), Java
stacktrace:, str(writer)))

class InvalidArgsError(Exception):
  pass

_orekit._set_exception_types(JavaError, InvalidArgsError)

VERSION = 6.0.0
CLASSPATH = [os.path.join(__dir__, orekit-6.0-SNAPSHOT.jar),
os.path.join(__dir__, commons-math3-3.1.1.jar)]
CLASSPATH = os.pathsep.join(CLASSPATH)
_orekit.CLASSPATH = CLASSPATH
_orekit._set_function_self(_orekit.initVM, _orekit)

from _orekit import *


With the error:

C:\Users\phy\Desktop\WinPy\WinPython-32bit-2.7.3.3\python-2.7.3\lib\site-packages\orekit\__init__.pyc
in __str__(self)
 13 return self.args[0]
 14   def __str__(self):
--- 15 writer = StringWriter()
 16 self.getJavaException().printStackTrace(PrintWriter(writer))
 17 return \n.join((super(JavaError, self).__str__(), Java
stacktrace:, str(writer)))

NameError: global name 'StringWriter' is not defined


If I manually add an from java.io import StringWriter, PrintWriter in the
__str__ function it seems to work (not if on module level, no idea why).
Could it be that the last line in __init__.py, from orekit import * is
related to the non-full-names option?

my build string, if interesting is as follows:
python -m jcc  --use_full_names --shared --python orekit --version 6.0.0
--jar orekit-6.0-SNAPSHOT.jar --jar commons-math3-3.1.1.jar --package
java.util  java.util.Arrays  java.util.List  java.util.ArrayList
 java.util.Collection  java.util.Collections java.util.Set java.util.Map
java.util.HashMap java.util.Date --package java.io java.io.InputStream
java.io.StringWriter java.io.StringReader --package java.lang
java.lang.System --package
org.apache.commons.math3.geometry.euclidean.threed.Vector3D --reserved
INFINITE --reserved ERROR --reserved OVERFLOW --reserved NO_DATA --reserved
min --reserved max --reserved mean --build --wininst

Any comments appriciated
Regards
/Petrus

Re: Error when java exception

2013-02-04 Thread Petrus Hyvönen




 Hopefully fixed in rev 1442394.
 Petrus, please try it out and let me know if it's _really_ fixed.



JCC  my wrapped library rebuilt, old removed, my previously failed example
works now as it should (reports the details of the exception). Many Thanks.

I see you also made modifications related to this in cpp.py. I don't
understand it really but  is the StringWriter in cpp.py row 54 imported
somehow?

Best Regards,
/Petrus




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

JCC and one-folder python

2012-12-07 Thread Petrus Hyvönen

Hi,

This might be obvious to many on this list, but for some it might be of
interest. When my friend was going to try my JCC wrapped library on a
Windows computer we had lots of trouble, I don't know if it was java
versions, compilers or just bad luck.

I have now found the WinPython, no-install, single folder windows python
distribution, and made a JCC + java engine encapsluated in it. Now I can
zip that and transfer it to another computer.

My recipie is:
Install WinPython from:
http://code.google.com/p/winpython/

take the java engine you are using, like C:\Program Files
(x86)\Java\jdk1.6.0_35 and copy it to the winpython tools folder, rename it
to jdk

Add in the winpython scripts/env.bat:

set
PATH=%WINPYDIR%\..\tools\jdk\jre\bin\client;%WINPYDIR%\..\tools\jdk\bin;%WINPYDIR%\..\tools\jdk\lib;%PATH%
set JAVA_HOME=%WINPYDIR%\..\tools\jdk
set JAVAHOME=%WINPYDIR%\..\tools\jdk
set JCC_JDK=%WINPYDIR%\..\tools\jdk

start a console using the cmd.bat in scripts, and build your JCC as an egg.
Use the WinPython installer to install the egg.

in the same console, wrap your java libraries, install as eggs.

This gives a no-install copy of my setup, including JCC and wrapped
library. Probably it cannot be distributed due to the java engine license
(i think?), but good for moving between computers/reinstalls and such.

Regards
/Petrus

Re: Editing the PyLucene web site

2012-06-28 Thread Petrus Hyvönen

Hi,

Attached is a patch for content/pylucene/jcc/features.mdtext, tested with 
build_site script.



I do not get the automatic code formatting to work by indenting 4 spaces, so I 
have manually wrapped the code sections in codepre tags, but the result is 
the same.

Regards
/Petrus



On 20 jun 2012, at 18:54, Andi Vajda wrote:

 
 Hi Petrus,
 
 On Tue, 19 Jun 2012, Petrus Hyvönen wrote:
 
 Attached is an diff update to the mdtext files with jcc documentation.
 
 I didn't manage to get the site build system to work, I think a perl 
 markdown module is needed, which I get build error when installing.
 
 If you don't tell me what error, it's that much harder to help you.
 
 However there are some mdtext editors around, so I just updated some of the 
 text in there, please check that it looks ok before activating.
 
 I took a quick look and your changes did not have much effect.
 Please test your changes using the CMS build system.
 For example, it seems that your addition of ``` line 23 in features.mdtext 
 had no effect.
 
 It's going to be very difficult to do this blind.
 
 Did you follow all the steps listed in in LUCENE-2748 comment I sent you a 
 link to, in particular, what's described at 
 http://www.apache.org/dev/cmsref.html#local-build, especially these steps 
 listed there ?
 $ cd /path/to/cms/build/tree
 $ export MARKDOWN_SOCKET=`pwd`/markdown.socket PYTHONPATH=`pwd`
 $ python markdownd.py
 
 Thanks for trying but if I end up spending more time debugging what you send 
 me than doing it myself, the situation is even worse and going nowhere :-(
 
 Cheers !
 
 Andi..
 
 
 Best Regards
 /Petrus
 
 
 
 On 18 jun 2012, at 01:17, Andi Vajda wrote:

Re: Editing the PyLucene web site

2012-06-19 Thread Petrus Hyvönen

Hi,

Attached is an diff update to the mdtext files with jcc documentation.

I didn't manage to get the site build system to work, I think a perl markdown 
module is needed, which I get build error when installing.

However there are some mdtext editors around, so I just updated some of the 
text in there, please check that it looks ok before activating.

Best Regards
/Petrus



On 18 jun 2012, at 01:17, Andi Vajda wrote:

 
 Hi Petrus,
 
 On Sun, 17 Jun 2012, Petrus Hyvönen wrote:
 
 Thanks for your response.
 
 Sorry about the topic, my intention was not to hijack the thread, used an 
 old message to get the list address...
 
 Send me instructions and I'll clean up the page.
 
 The new site's source is checked into svn:
  http://svn.apache.org/repos/asf/lucene/cms/trunk
 
 Check this out into a directory of yours.
 The pylucene directory is under content/pylucene.
 
 To build a copy of the site to review and debug your edits, please refer to 
 this comment in the Lucene issue tracking the transition, LUCENE-2748:
 https://issues.apache.org/jira/browse/LUCENE-2748?focusedCommentId=13080471page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13080471
 
 Once you're satisfied with your changes, send a patch to the pylucene-dev 
 mailing list and I'll apply them.
 
 Thanks !
 
 Andi..
 
 
 Regards
 /Petrus
 
 
 On 17 jun 2012, at 18:39, Andi Vajda wrote:
 
 Please, don't hijack a thread, start a new one when switching topics. Your 
 questions below have nothing to do with building on Python 2.4.
 
 On Jun 17, 2012, at 5:39, Petrus Hyvönen petrus.hyvo...@gmail.com wrote:
 
 I am trying to clean up my wrap script and comes to some questions.
 
 Is there a way to see if a method or constructor is now wrapped due to 
 that any of its inputs/outputs are not wrapped? (to make sure that I 
 haven't missed any --package)
 
 Use dir() on the wrapper class to see what got wrapped. But to get a 
 definite answer you need to look at the generated source code to know about 
 all the overloads of a Java method that got wrapped.
 
 If i --package java.io does that mean that all classes in that package 
 such as java.io.InputStream is automatically packaged?
 
 No, only if it is used by any of the classes or jars you explicitely asked 
 be wrapped.
 
 BTW, it seems like the formatting of the docs has become a bit corrupted 
 at: http://lucene.apache.org/pylucene/jcc/readme.html
 
 Yes, the software behind the site was switched and a bunch of work is 
 needed to fix the content up. Volunteers are welcome to help out with this. 
 If you'd like to contribute I can send you instructions.
 
 Andi..
 
 
 Many thanks
 /Petrus

Re: building JCC on Python 2.4

2012-06-17 Thread Petrus Hyvönen

Dear Andi,

I am trying to clean up my wrap script and comes to some questions. 

Is there a way to see if a method or constructor is now wrapped due to that any 
of its inputs/outputs are not wrapped? (to make sure that I haven't missed any 
--package)

If i --package java.io does that mean that all classes in that package such 
as java.io.InputStream is automatically packaged?

BTW, it seems like the formatting of the docs has become a bit corrupted at: 
http://lucene.apache.org/pylucene/jcc/readme.html 

Many thanks
/Petrus

Question on non-visible inherited methods.

2012-02-21 Thread Petrus Hyvönen

Hi,

First, my java and object oriented knowledge is limited, so this can
be caused by that. Thanks for your patience :)
I am trying to wrap an external library.

I get the object through sun = CelestialBodyFactory.getSun() which works.

I am missing a method on sun. The method is available when I do the
same thing through jython access of the jar.

The missing method (getPVCoordinates) is in java inherited through an interface
( https://www.orekit.org/static/apidocs/org/orekit/bodies/CelestialBody.html )

The JCC class .cpp file is #including the super-class.h, but the
method is not listed in the different interface descriptions.

Which mechanisms are selecting not to wrap a method? Not packaging the
return type is excluding it, are there other exclusions?

Best Regards
/Petrus

Re: Typecasting in JCC (i think..)

2012-01-31 Thread Petrus Hyvönen

Hi,

Is there a way of specifying which java SDK to link to? On my windows
7 machine it wants to use Java SDK 1.7 but I would like to keep it at
SDK 1.6? Is this possible?

Regards

JCC crash when building

2011-12-12 Thread Petrus Hyvönen

Hi Jason,

I was using  visual studio c++ 2008 (express, or what the free version
was called). But note from my previous mails that I didn't get it to
work properly in the end when using the module - but I was compiling
on a 64-bit system, using a  32-bit python system (pythonxy). When
compiling on my 32/32 bit system and using in 64-bit, I have no
troubles.

Regars
/Petrus


On Sun, Dec 11, 2011 at 3:52 AM, Jason Ni jason.ni...@gmail.com wrote:
 Hi Petrus,

 I also plan to compile JCC and use it in 64-bit win7. Could you please tell
 me what version of MS VC++ compiler do you use?

 Thanks.

 -Jason


 On 2011/9/9 14:59, Petrus Hyvönen wrote:

 Now I installed Microsoft Visual C++ compiler and JCC builds and works
 fine
 both with python 2.6, 2.7 in 64-bit win7.

 Many thanks
 /Petrus


 On Thu, Sep 8, 2011 at 10:35 PM, Bill Janssenjans...@parc.com  wrote:

 Petrus Hyvönenpetrus.hyvo...@gmail.com  wrote:

 Thanks, I tried now to uninstall Java 7 completely, and recompile JCC,

 same

 problem.

 I should maybe mention that I'm on 64-bit Windows 7, and a 32 bit python
 (python xy)

 I've done a fair amount of building PyLucene with mingw, and I have been
 unable to make that particular combination work, myself.  I think you
 need to re-build Python as 64-bit, to make progress here.

 Bill







--
_
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

JCC fails w Java 7 win 7 64 bit

2011-09-30 Thread Petrus Hyvönen

Just a little note in case someone is troubleshooting.. Sorry that I can't
provide more details.

It seems that JCC initVM() crashes the python thread when Java 7 (1.7.0) is
installed on a win 7 64 bit. Building JCC works fine. Using an old version
(built to Java 6) works, as well as removing Java 7 and rebuilding JCC. This
applies for both 2.11 and 2.10.

Best regards
/Petrus

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

Fwd: [Orekit Developers] Distribution of orekit-python egg

2011-09-09 Thread Petrus Hyvönen

Hi JCC developers,

As this discussion could be of potential interest of others who makes python
modules using jcc I cross post it.

I am really not experienced in the licensing issues of open source, closed
source etc.

A JCC generated external java library .egg, do contain some JCC code, is
there something I need to do to ensure that the JCC license is fulfilled?

In my case the wrapped library is also in apache, so I guess it should not
be an issue to put the egg under apache?

Regads
/Petrus

-- Forwarded message --
From: Petrus Hyvönen petrus.hyvo...@gmail.com
Date: Fri, Sep 9, 2011 at 10:33 AM
Subject: Re: [Orekit Developers] Distribution of orekit-python egg
To: orekit-develop...@orekit.org


Hi Luc,

Good to hear, I think it is good with an easy-entry to the orekit through
python.

I really don't know much about the licensing stuff.

- My work in this process is rather minimal, issuing the right command line
parameters.
- The JCC tool that I use for wrapping is under apache 2.0 license as well.
http://pypi.python.org/pypi/JCC/
- orekit and common maths library are included in the egg. (common math
assumed to be under apache as well)

Microsoft compiler has been used in the process, but as I understand this
does not affect the licensing?

Please send me the paper and I can understand it better, I am not really
clear right now what the actual content of the authorization is about.

Regards
/Petrus




On Fri, Sep 9, 2011 at 10:04 AM, MAISONOBE Luc luc.maison...@c-s.fr wrote:

 Hi Petrus,

 Petrus Hyvönen petrus.hyvo...@gmail.com a écrit :


  Hi,

 This is mostly a legal/policy question,

 Would the license of orekit allow and would it be preferred that I create
 some python eggs (python installer packages) for orekit?


 The license allow it and it would be interesting to do.



  I am using JCC to
 wrap orekit java library so it is accessible from standard python. All
 instructions needed are on the orekit wiki.

 After an update to python 2.7 and rebuilding of the wrapping, I realized
 that there is some caveats involved on at least windows operating system
 (such that you need microsoft visual C installed) to create the wrapping,
 but not to run it.  When built I can easily make the eggs that could be
 put
 on the orekit or other webpage and easily installed, without the need of
 that compiler etc.


 If you want it and if you choose to have all additional wrapping code and
 packaging distributed under the sames terms as Orekit, i.e. the Apache 2
 Software License, then yes, we could host them here in the main Orekit site.
 You would of course be credited for that. Before we can really distribute
 your work, we would ask you to sign a Individual Contributor License
 Agreement which basically say you authorize us to distribute what you did.
 We follow exactly the same process as the Apache Software Foundation for
 that. I can send you the template of the paper.

 Thanks
 Luc



 Let me know what you think
 /Petrus




 --**--**
 This message was sent using IMP, the Internet Messaging Program.





-- 
_
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

Re: JCC crash when building

2011-09-07 Thread Petrus Hyvönen

Thanks, I tried now to uninstall Java 7 completely, and recompile JCC, same
problem.

I should maybe mention that I'm on 64-bit Windows 7, and a 32 bit python
(python xy)

Regards
/Petrus


On Wed, Sep 7, 2011 at 9:04 PM, Andi Vajda va...@apache.org wrote:


 I'm sorry, I'm not ignoring you, but since I don't run Windows much and
 mingw not at all, I can't help you. It is very likely you've got some DLLs
 mixed up indeed.

 Maybe someone with mingw experience here can chime in ?

 Andi..


 On Tue, 6 Sep 2011, Petrus Hyvönen wrote:

  Hi again,

 python -m jcc --find-jvm-dll crashes as well.

 jcc.path gives me following:

 ['C:\\Python27\\lib\\site-**packages\\jcc-2.10-py2.7-**win32.egg',
 'C:\\MinGW32-xy\\bin',
 'C:\\Python27\\Lib\\site-**packages\\PyQt4',
 'C:\\Program Files (x86)\\MiKTeX 2.9\\miktex\\bin',
 'C:\\Windows\\system32',
 'C:\\Windows',
 'C:\\Windows\\System32\\Wbem',
 'C:\\Windows\\System32\\**WindowsPowerShell\\v1.0\\',
 'C:\\Program Files\\Intel\\WiFi\\bin\\',
 'C:\\Program Files\\Common Files\\Intel\\WirelessCommon\\**',
 'C:\\Program Files\\TortoiseHg\\',
 'C:\\Program Files\\TortoiseSVN\\bin',
 'C:\\Program Files (x86)\\Java\\jdk1.6.0_26\\bin'**,
 'C:\\Program Files (x86)\\QuickTime\\QTSystem\\',
 'C:\\Program Files (x86)\\Git\\cmd',
 'C:\\Program Files (x86)\\Java\\jdk1.7.0\\jre\\**bin\\client',
 'c:\\Program Files\\java\\jdk1.7.0\\bin',
 'C:\\Python27\\Lib\\site-**packages\\PyQt4',
 'C:\\Windows\\System32',
 'C:\\Program Files (x86)\\Java\\jre7\\bin\\**client',
 'C:\\Python27',
 'C:\\Python27\\DLLs',
 'C:\\Python27\\Scripts',
 'C:\\Python27\\Lib\\site-**packages\\vtk',
 'C:\\Python27\\gnuplot\\**binary',
 'C:\\Program Files (x86)\\pythonxy\\console',
 'C:\\Program Files (x86)\\pythonxy\\SciTE-2.26',
 'C:\\MinGW32-xy\\bin',
 'C:\\Program Files (x86)\\pythonxy\\swig',
 'C:\\Program Files (x86)\\pythonxy\\gettext\\bin'**]

 Your expertise is, as always, very appriciated :)

 On Tue, Sep 6, 2011 at 8:05 PM, Petrus Hyvönen petrus.hyvo...@gmail.com
 **wrote:

  Dear all,

 I reinstalled my python xy environment, from 2.6 to python 2.7 and need
 to
 compile jcc and my java modules.

 Compiling jcc went well with python setup.py build --compiler=mingw32, no
 errors reported and installs fine.

 I had initially lots of troubles with No module named _jcc errors, but
 this was caused by trying to run python -m jcc in jcc build dir, and it
 imports the wrong jcc. Several trouble reports on the net possible caused
 by
 this.

 Anyway, my current issue is when trying to build my java wrapper. When
 performing the python -m jcc --jar orekit.jar ... command, jcc crashes
 python silently. It does not seem to matter which jar I use.

 Somehow this kind of errors is often from incompatible libraries. How is
 it
 with java, i have both v6 and v7 installed, and in the compilation it
 seems
 to use v7, which client I have in the PATH. Could there be somthing
 related
 to java versions? What other things can mess up? :)

 Regards
 /Petrus

 --
 __**___
 Petrus Hyvönen, Uppsala, Swedenv
 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

Problems building JCC

2011-07-04 Thread Petrus Hyvönen

Hi,

This is likely another faq but,

I've moved to a windows 7 machine (64bit) and trying to compile jcc. mingw32
compiler, JDK, JRE installed. I'm getting a libjcc.a - No such file or
directory error. javac is available at the command prompt.

Building with:

python setup.py build --compiler=mingw32

Any help highly appriciated.
/Petrus


writing build\temp.win32-2.6\Release\jcc\sources\jcc.def
C:\Program Files (x86)\pythonxy\mingw\bin\g++.exe -mno-cygwin -mdll -static
--en
try _DllMain@12 -Wl,--out-implib,build\lib.win32-2.6\jcc\jcc.lib
--output-lib bu
ild\temp.win32-2.6\Release\jcc\sources\libjcc.a --def
build\temp.win32-2.6\Relea
se\jcc\sources\jcc.def -s build\temp.win32-2.6\Release\jcc\sources\jcc.o
build\t
emp.win32-2.6\Release\jcc\sources\jccenv.o -LC:\Python26\libs
-LC:\Python26\PCbu
ild -lpython26 -lmsvcr90 -o build\lib.win32-2.6\jcc.dll -LC:\Program Files
(x86
)\Java\jdk1.6.0_26/lib -ljvm -Wl,-S -Wl,--out-implib,jcc\jcc.lib
g++: build\temp.win32-2.6\Release\jcc\sources\libjcc.a: No such file or
director
y
error: command 'g++' failed with exit status 1

Re: JCC usage failure

2011-06-09 Thread Petrus Hyvönen

Thank you for the support,

Finally I manage to get it working by reserving some words, and minimizing
the number of wrapped methods by just including those that I specifically
need:

python -m jcc --jar orekit-5.0.jar --include commons-math-2.2.jar --package
java.io --package org.apache.commons.math.geometry  --shared  --python
orekit --reserved INFINITE --reserved NO_DATA --reserved ERROR --install
--build

Is there a way to influence the docstrings generated (__doc__ function?), or
is there any way of converting from a javadoc to docstrings of the wrapped
library? :)

Thanks  Regards
/Petrus



On Fri, Jun 3, 2011 at 5:39 PM, Andi Vajda va...@apache.org wrote:


 On Jun 3, 2011, at 1:21, Petrus Hyvönen petrus.hyvo...@gmail.com wrote:

  Hi,
 
  I am trying to use JCC to wrap a java library (orekit.org), and have
  successfully done so on the mac platform. As I also use windows I try to
 do
  the same there.
 
  JCC compiles fine on both platforms (using --compiler=mingw32 on win,
 using
  the python xy distribution with mingw v4.5.2).
 
  the wrapper is successfully created on mac by
 
  on windows I needed to add the .__main__ for jcc:
 
  python -m jcc.__main__ --jar orekit-5.0.jar --jar commons-math-2.2.jar
  --include orekit-data.zip --shared  --python orekit --install --files
  separate --build
 
  the build goes on for some time and fails with extract below. Does anyone
  has some experience with this failure, and where does one start to solve
 it,
  is it the compiler, jcc? I have also tried with a fresh install with
 mingw32
  but no difference.
 
  Any help or directions appricated.
  /Petrus
 

 This is very likely to be caused by some variable name coming from your
 java sources that is defined as a macro by the header files coming from your
 compiler. To work this around add the variable name to the reserved word
 list by adding it to the jcc command line via the --reserved flag.
 To find which variable it is look at the error messages below and at the
 code they refer to. For example, Dfp.h, line 109 or Dfp.cpp, line 22.

 Andi..

  In file included from
 build\_orekit\org\apache\commons\math\dfp\Dfp.cpp:3:0:
  build\_orekit/org/apache/commons/math/dfp/Dfp.h:109:38: error: expected
  unqualified-id before numeric constant
  build\_orekit\org\apache\commons\math\dfp\Dfp.cpp:22:32: error: expected
  unqualified-id before numeric constant
  build\_orekit\org\apache\commons\math\dfp\Dfp.cpp: In static member
 function
  'static _jclass*
 org::apache::commons::math::dfp::Dfp::initializeClass()':
  build\_orekit\org\apache\commons\math\dfp\Dfp.cpp:100:79: error: lvalue
  required as left operand of assignment
  build\_orekit\org\apache\commons\math\dfp\Dfp.cpp: In static member
 function
  'static void
 org::apache::commons::math::dfp::t_Dfp::initialize(PyObject*)':
  build\_orekit\org\apache\commons\math\dfp\Dfp.cpp:476:101: error:
 expected
  unqualified-id before numeric constant
  error: command 'gcc' failed with exit status 1




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

JCC usage failure

2011-06-03 Thread Petrus Hyvönen

Hi,

I am trying to use JCC to wrap a java library (orekit.org), and have
successfully done so on the mac platform. As I also use windows I try to do
the same there.

JCC compiles fine on both platforms (using --compiler=mingw32 on win, using
the python xy distribution with mingw v4.5.2).

the wrapper is successfully created on mac by

on windows I needed to add the .__main__ for jcc:

python -m jcc.__main__ --jar orekit-5.0.jar --jar commons-math-2.2.jar
--include orekit-data.zip --shared  --python orekit --install --files
separate --build

the build goes on for some time and fails with extract below. Does anyone
has some experience with this failure, and where does one start to solve it,
is it the compiler, jcc? I have also tried with a fresh install with mingw32
but no difference.

Any help or directions appricated.
/Petrus


In file included from build\_orekit\org\apache\commons\math\dfp\Dfp.cpp:3:0:
build\_orekit/org/apache/commons/math/dfp/Dfp.h:109:38: error: expected
unqualified-id before numeric constant
build\_orekit\org\apache\commons\math\dfp\Dfp.cpp:22:32: error: expected
unqualified-id before numeric constant
build\_orekit\org\apache\commons\math\dfp\Dfp.cpp: In static member function
'static _jclass* org::apache::commons::math::dfp::Dfp::initializeClass()':
build\_orekit\org\apache\commons\math\dfp\Dfp.cpp:100:79: error: lvalue
required as left operand of assignment
build\_orekit\org\apache\commons\math\dfp\Dfp.cpp: In static member function
'static void org::apache::commons::math::dfp::t_Dfp::initialize(PyObject*)':
build\_orekit\org\apache\commons\math\dfp\Dfp.cpp:476:101: error: expected
unqualified-id before numeric constant
error: command 'gcc' failed with exit status 1

60 matches

Mail list logo