New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

callbacks on "this" with Java libraries don't... usually... work #201

Closed
aparrish opened this Issue May 4, 2016 · 4 comments

Comments

Projects
None yet
2 participants
@aparrish
Contributor

aparrish commented May 4, 2016

I feel like there was a note about this behavior somewhere in the documentation at some point, but I can't find it now, so apologies if this is a known issue...

Here's a Python translation of the serverEvent() example from the Net library:

add_library('net')

port = 10002
my_server = None

def setup():
    global server
    size(400, 400)
    background(0)
    my_server = Server(this, port)

def draw():
    pass    

def serverEvent(some_server, some_client):
    print "got a client", some_client.ip()

This example runs happily but does not execute the serverEvent method when a new client connects (tested using telnet localhost 10002—the corresponding program in Java Processing works fine, printing out the new client line as expected). I've tested similar code with a number of other libraries that use callbacks like this (e.g., oscP5).

I suspect the reason for this is that the Net library uses class.getMethod() to discover the appropriate method to call at run-time, and (a) functions you define in your Processing.py sketch don't become methods in the PAppletJythonDriver object; and (b) they wouldn't have the right method signatures anyway.

For better or worse, the design pattern of "define a function with a particular name and pass this when calling the library constructor" is very well established in Processing Libraryland, so it would be nice to be able to use libraries that use this pattern in Processing.py. It would be nice if there were a way to support libraries that use this design pattern without hacking support for each of them into the Processing.py source code (e.g., as was done with the Serial library). Thoughts/ideas?

@jdf

This comment has been minimized.

Show comment
Hide comment
@jdf

jdf May 5, 2016

Owner

This bug conflates two unrelated issues. The passing of this works as expected, but introspection for names does not. The only way to support that is to have the Python Mode applet runner provide the expected functions and forward them to any Python implementation in the sketch, as is done already for the video and serial libraries (see https://github.com/jdf/processing.py/blob/master/runtime/src/jycessing/PAppletJythonDriver.java#L520).

There is no way to do such a thing on the fly, without modifying byte code. That's not impossible, but it's a large-scope project, perhaps suitable to a master's degree-level summer project.

Owner

jdf commented May 5, 2016

This bug conflates two unrelated issues. The passing of this works as expected, but introspection for names does not. The only way to support that is to have the Python Mode applet runner provide the expected functions and forward them to any Python implementation in the sketch, as is done already for the video and serial libraries (see https://github.com/jdf/processing.py/blob/master/runtime/src/jycessing/PAppletJythonDriver.java#L520).

There is no way to do such a thing on the fly, without modifying byte code. That's not impossible, but it's a large-scope project, perhaps suitable to a master's degree-level summer project.

@jdf jdf closed this May 5, 2016

@aparrish

This comment has been minimized.

Show comment
Hide comment
@aparrish

aparrish May 5, 2016

Contributor

Thanks for the response! I guessed that you might have bad news for me on this one. :/ I really just wanted to be able to use oscP5... I'll find a workaround.

Contributor

aparrish commented May 5, 2016

Thanks for the response! I guessed that you might have bad news for me on this one. :/ I really just wanted to be able to use oscP5... I'll find a workaround.

@jdf

This comment has been minimized.

Show comment
Hide comment
@jdf

jdf May 5, 2016

Owner

Do me a favor: for each library (such as oscP5) that you find is incompatible with Python Mode, please file a bug, and I'll do what I can to hack around their design (including providing functions at specified names). I won't be able to do all of them, but I can certainly do everything reasonable.

Owner

jdf commented May 5, 2016

Do me a favor: for each library (such as oscP5) that you find is incompatible with Python Mode, please file a bug, and I'll do what I can to hack around their design (including providing functions at specified names). I won't be able to do all of them, but I can certainly do everything reasonable.

@aparrish

This comment has been minimized.

Show comment
Hide comment
@aparrish

aparrish May 5, 2016

Contributor

sounds good!

Contributor

aparrish commented May 5, 2016

sounds good!

This was referenced May 13, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment