JyNI

[Stewori]

Submit proceeding paper for JyNI.

[cournape]

This is a pretty cool project, thanks for taking the time to write the paper !

Could you give some examples of actual extensions you could load ? I understand numpy itself is really hard, but maybe some simple, non trivial extensions could be made to work ?

[Stewori]

With release alpha 2 (out since yesterday), JyNI is able to load the original datetime module (which is a C-extension). This is no breaking news for Jython folks, because Jython features a Java-grounded implementation of that module. However, the original module provides some public C-API that is used by NumPy and that is not provided by Jython's version (since it isn't in C). So this is a mentionable step towards numpy support. Another milestone would be ctypes. I think the main issue that keeps me from loading ctypes is support for weak references. This is next on the agenda. When EuroSciPy took place, I honestly was not able to load any real-world extension known to me, mainly because JyNI had no exception-support yet. This has changed with alpha 2, but I wasn't sure whether it would be okay to mention features in the proceedings that were created after the actual deadline.

If it is okay, I would insert a section about the datetime module written from todays perspective. Is it allowed to update the capabilities-section to the state of release alpha 2 (and consequently also the roadmap section)? What is the deadline for such fixes? I hope to do it on coming weekend.

This is a pretty cool project, thanks for taking the time to write the paper ! Thanks for taking time to review it! If you like the project, consider to give it its third star on github.

Gesendet: Dienstag, 29. Oktober 2013 um 12:18 UhrVon: "David Cournapeau" notifications@github.comAn: euroscipy/euroscipy_proceedings euroscipy_proceedings@noreply.github.comCc: "Stefan Richthofer" stefan.richthofer@gmx.deBetreff: Re: [euroscipy_proceedings] JyNI (#11)

This is a pretty cool project, thanks for taking the time to write the paper !

Could you give some examples of actual extensions you could load ? I understand numpy itself is really hard, but maybe some simple, non trivial extensions could be made to work ?

— Reply to this email directly or view it on GitHub.

[pdebuyl]

Hi Stefan,

If there is some update on the project, I see no harm in including that in the proceedings paper.

Pierre

[Stewori]

I just read over the paper again and noticed that it already mentions exception support, the datetime module and ctypes (i.e. the weak reference issue):

"At least, the latest JyNI development version is already capable of using the original native CPython datetime module. In order to support ctypes, we will have to support the PyWeakRef-object."

However I admit this is hidden in the roadmap section and stated in such a marginal way that it draws not enough attention. I will move it to an own (sub)section and add some brief example code and output.

[pya]

Very interesting paper. This brings the different Python implementations closer together.

Just a few stylistic remarks. Who is "we"? The text uses "we" all the time but there is only a single author of the paper. Is this style needed to make it consistent with the other papers of the proceedings? If there is a team of developers, mentioning their names, if appropriate, or at least the fact that there is a group of about x developers, might be a good idea.

I do have a bunch of suggestions to improve upon grammar and style. What would be the best workflow to put them in?

[Stewori]

Who is "we"? The text uses "we" all the time but there is only a single author of the paper.

I am currently the only developer in fact. Only the makefile was partly done by another developer (Unfortunately, I lost contact with him). However, the "we" is of rhetorical nature. I decided to use a rhetorical "we", since the project is open for everyone to contribute. Indeed there are currently 2 forks (of unknown purpose and activity though). Further I feared, that writing everything in the "I"-form, might discourage others from joining the project. (I must admit, that someone who wants to join the project now would have a hard time, because my code has currently a rather messy form - I'm going to improve this in the future).

Is this style needed to make it consistent with the other papers of the proceedings?

It would also serve this purpose, but this is no formal/official requirement for the proceedings as far as I know. Do you think I should drop a line on my usage of "we" or even adjust the paper to use "I"?

I do have a bunch of suggestions to improve upon grammar and style. What would be the best workflow to put them in?

For me, this thread would be okay, but if it is more comfortable for you, we can also do it via email or whatever you suggest. Maybe the easiest way would be to fork https://github.com/Stewori/euroscipy_proceedings and insert comments into the rst-file.

Thanks for reviewing my paper!

[pya]

I am kind of late with this. Sorry.

I would suggest we do the next steps via email. I can add the changes to the source and you can look at the diff and decide if you like them or not. What do think? You can email me at mmueller [at] python-academy [dot] de.

[pdebuyl]

Dear Stefan, Could you follow up on this? The review process is now almost over for the proceedings. Mike, ideally it would be great to have a dump of the email review process here, so that the publicness is similar to the other papers.

Cheers,

Pierre

[Stewori]

Is there a sharp date, when the review is over? I am currently doing some editing and would need at least until tomorrow. I am adding a Tkinter example, since JyNI can now run basic Tkinter code and cournape asked for real-world examples. Additionally I am updating the GC-section, since my plans how to realize GC changed significantly. Mike is waiting for these edits before he gives further corrections. I am almost done with this and hope I can upload it tomorrow. So there was no mentionable email communication to dump here.

Cheers

Stefan

[pdebuyl]

I was mostly checking that the communication was ongoing. A few days is certainly ok :-)

[Stewori]

Okay, I just uploaded the edited version. @Mike: Feel free to start reviewing it.

[pya]

Though large parts are derived from CPython, the main Python runtime is provided by Jython and JyNI delegates most C-API calls to Jython directly or indirectly.

What does directly or indirectly mean?

[pya]

No recompilation, no forking – it just works with original Jython and original extensions.

Any requirements on the Python version to make this work?

[Stewori]

What does directly or indirectly mean?

This expresses, that not every API-call is just translated to a corresponding Jython call and sent through JNI. Many calls are completely processed on native side, for instance when dealing with mirrored objects. For instance when modifying a PyList via macro, the changes are reflected on Jython-side, but are not actively sent to Jython. When the Java PyList on Jython side is accessed, it will read the changed elements from the native counterpart.

The "directly or indirectly"-formulation is just a hint on what is explained in a later section in detail. Maybe it appears confusing at that place. I agree it might be better to rewrite the sentence somehow. Any suggestion?

Any requirements on the Python version to make this work?

I usually write the JyNI version twofolded: JyNI 2.7 alpha.2.1 means Targeted API version is 2.7, while the JyNI version is alpha.2.1. Since it is alpha, it won't already suite the targeted API (but only a subset). However the Jython version should meet JyNI's API version (i.e. 2.7). In a final production state, JyNI should be usable with almost any extension that can be used with Python 2.7 (i.e. with any Python 2 extension, since the minor version should not affect backward compatibility as far as I know). I did not mention this further because I considered it obvious that JyNI can't be expected tor run extensions with Jython 2.7 that don't even run with CPython 2.7.

Of course the native extension must be compiled for the same platform as JyNI (linux JyNI won't be able to use windows tkinter), but I believe this is an obvious requirement (that also exists for CPython).

Would you suggest, I should drop some lines on these things? In the usage section, I wrote "be sure to use Jython 2.7 beta 1 or newer". Is this an insufficient hint? (Maybe it is, if one considers potential future Jython 3.x version to fall under the description "Jython 2.7 beta 1 or newer")

Python 3 re-defines the mechanism how extensions are loaded. I planned to look into this once a Jython 3.x beta is available one day.

[Stewori]

I added an explanation of the "direct and indirect"-formulation and a small subsection about versioning and version compatibility. I think this should be a sufficient fix for the issues Mike pointed out.

[pya]

Fine with me. I am done reviewing. :)