Fix BigNum to python long long issue

[peter-wangxu]

This bug fixes the issue when passing ruby BigNum as a parameter of python function

[peter-wangxu]

@halostatue @raineszm Please review this critical fix.

I am going to publish this package with a new name since I am unable to include the fixes in rubypython.

Let me know if you have any concern of this.

[halostatue]

I can’t really speak for @raineszm, but a couple of things:

1. The bitbucket repo has traditionally been the main place where issues and development was tracked. I see now that @raineszm has marked the project unmaintained.

2. If you are regularly using RubyPython, I’d be happy to make you a co-maintainer as I honestly have not needed this in a very long time, and I suspect that @raineszm would rather see this project in the hands of someone who is going to use and maintain it than stagnated. I know that I would.

3. If you want to make a clean break and keep using pybridge as the name (good name, I think), I think that’s something we can start redirecting people to.

Basically, it sounds like you’re using RubyPython and that alone qualifies you to be a maintainer on this project: are you interested?

[raineszm]

I agree with @halostatue. I don't really have the time or expertise to maintain this project at this point. I honestly haven't used ruby for anything in a number of years. That being said if people are getting use out of the project I would love to see it getting proper support.

So in short I'm fully on board with both options.

[peter-wangxu]

That will be awesome if i can be the maintainer of this github repo. Definitely i will keep an eye on the it always. How about also allowing me for the package management on rubygems so that i can publish new release via rubygems?

[halostatue]

OK. I need your primary email address (the one you signed up for RubyGems.org) for RubyGems permissions. I’m my username at gmail. Drop me a note and I’ll do the necessary configuration changes.

After doing the short-term release you want to do, I strongly recommend creating an organization (say, rubypython) and moving the repository there (which I can facilitate since it’s moving it from my list) and then forking back here to make it the primary and updating the documentation.

I’ll turn on issues and port them over from BitBucket tonight.

[halostatue]

I’m going to do a bit of preemptive action because there’s already an organization called rubypython, so I’m going to register an organization called pybridge with the intention of moving rubypython to that organization.

[peter-wangxu]

great. my mail is: [redacted]

[halostatue]

I redacted your email and added you to the gem.

[halostatue]

For information from the Python side: zmq.Context.instance has a default argument, which should be an integer. You get this error if you call, e.g. {{{zmq.Context.instance(None)}}} in pure Python.

To further complicate matters, the {{{Context}}} class is defined in a Cython file - i.e. it isn't loaded directly as a Python module, but automatically translated into C code and compiled.

[halostatue]

I'm starting work on RubyPython again and have a 0.7 release bookmark. I've added an spec/issues/cython to help track this issue. I don't necessarily see a way around it, but will probably get involved in the Cython community to understand this, or build a non-Cython extension (that does the same thing) to see if this is a problem outside of Cython.

We know it will be a problem for some compiled modules because they hold on to references when they shouldn’t (and there may be something involving atexit as a possible solution for those modules).

[halostatue]

I've started looking into this and RubyPython is in fact calling the correct method both times. However, something is going wrong in the Client class's init method within the IPython code. I'm assuming that you are using the DrQueueIPython module. Below is the Python traceback: {{{ File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/DrQueue/client.py", line 23, in init self.ip_client = IPClient() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/IPython/parallel/client/client.py", line 244, in init context = zmq.Context.instance() File "context.pyx", line 72, in zmq.core.context.Context.instance (zmq/core/context.c:957)

}}} which then culminates in the error that you posted. I'm investigating this further, but for now you may want to try avoiding restarting the interpreter. That is, structure your application as {{{

application initialization

RubyPython.start ...

main code logic

...

application cleanup

RubyPython.stop }}}

[halostatue]

Thanks for the work testing. I figured that was the cause but I wasn't completely sure. This is probably related to the crash that occurs when the python interpreter version is changed within one ruby thread. RubyPython is unable to unload Python extensions when the interpreter stops. Therefore the module loaded in the first interpreter invocation may still be present in the second and that might be causing the issues. Frankly I'm not sure what would cause the default argument to be stored incorrectly as I'm not sure how such things are handled in Cython.

[halostatue]

I've been unable to find a solution to this problem except for:

• Starting the RubyPython interpreter only once
• Or forking a new process each time the interpreter starts

I unfortunately do not know much about Cython so I don't really know the source of this issue. Additionally, I have been unable to find anyway to truly unload compiled Python extensions from the Python interpreter. So at the moment moment I sadly have no workaround.

[halostatue]

Thanks for the work testing. I figured that was the cause but I wasn't completely sure. This is probably related to the crash that occurs when the python interpreter version is changed within one ruby thread. RubyPython is unable to unload Python extensions when the interpreter stops. Therefore the module loaded in the first interpreter invocation may still be present in the second and that might be causing the issues. Frankly I'm not sure what would cause the default argument to be stored incorrectly as I'm not sure how such things are handled in Cython.

[halostatue]

Should we consider changing the behaviour of RubyPython for 1.0 to prevent starting the interpreter more than once without forking? I know it's useful to be able to do if all you're doing is pure Python, but unless we can figure out a way to detect the use of a C extension for Python, I don't see a way to make this work.

[halostatue]

This is either a problem with RubyPython or Cython.

If I create the simple Cython module containing only:

{{{

!cython

cdef class C:

@classmethod
def foo(cls, a=5):
    print cls, a

}}} and installed it as 'c', I can reproduce the error with: {{{

!ruby

require "rubygems" require "rubypython"

RubyPython.start cmod = RubyPython.import('c') cmod.C.foo RubyPython.stop RubyPython.start cmod = RubyPython.import('c') cmod.C.foo RubyPython.stop }}} Which has the output: {{{ <type 'c.C'> 5 <type 'c.C'> <type 'c.C'> }}}

So at the second invocation of the interpreter, classmethods on Cython classes are wrong. I don't know if it's RubyPython or Cython that is doing something incorrect, but that's the actual issue here.

[halostatue]

I've also added a ticket for the IPython developers in order to try to find out the problem together: https://github.com/ipython/ipython/issues/488

Thanks & regards, kaazoo

[halostatue]

Is there a workaround for this problem? Would it help to unload all loaded modules before stopping RubyPython? I need to use RubyPython for a RubyOnRails application and would like to use it in different helper methods.

Regards, kaazoo

[peter-wangxu]

Hi @halostatue I finished my local testing of my patch, and ready to publish a new version in rubygems of it.

Let me know if you have any comment here.

[halostatue]

Well, crap. Lots of missing comments went here instead of the issue to which they actually belong. Oh, well.

If you feel the version is good, please feel free. As they said often on Star Trek: “You have the conn.”