Your long self-conversation is the most interesting thing to happen to this list in a long time... From: pythondotnet-bounces+btribble=ea.com@python.org [mailto:pythondotnet-bounces+btribble=ea.com@python.org] On Behalf Of Laszlo Sebo Sent: Wednesday, December 08, 2010 5:45 PM To: pythondotnet@python.org Subject: Re: [Python.NET] building on linux, mono 2.8.1 At the risk of having a long conversation here with myself... :) It appears that the crash happens in intobject.c of python, at the PyObject *PyInt_FromLong(long ival) function, when it tries to increment the reference counter: Py_INCREF(v); When python.net calls this function first, it calls it with the value of 0, which falls into a special handled range of integers that are dealt with in a small_ints[] array. However, that array never go initialized, so the reference counter crashes. The array would normally be initialized by calling _PyInt_Init(void). Sooo... just to test my theory, i exposed that function and called it explicitly from Python.Runtime.Initialize() and low and behold, import clr now works just fine! So i'll now go on a hunt, and make sure everything is initialized properly, i'm guessing some main init function isn't being called somewhere when using python.net from an embedded python. cheers, laszlo On 08/12/2010 1:35 PM, Laszlo Sebo wrote: Made a little bit of progress, but am now back to square one.. :) Basically, seems that the python embedded in nuke uses UCS4 instead of UCS2 which is the default when building python. So the python so's i had were using UCS2 while Nuke's internal python was using UCS4. I rebuilt python using the --enable-unicode=ucs4 flag, then rebuilt python.net. I hit another wall fairly soon, the mono config (dll remap) file wasn't being initialized, so i would be getting missing msvcrt dll errors on import clr. To fix that, i had to uncomment this line in pynetinit.c: //mono_config_parse(NULL); However, now i am back to the previous error i had: Stacktrace: at (wrapper managed-to-native) Python.Runtime.Runtime.PyInt_FromLong (intptr) <0x00060> at (wrapper managed-to-native) Python.Runtime.Runtime.PyInt_FromLong (intptr) <0xffffffff> at Python.Runtime.Runtime.PyInt_FromInt32 (int) <0x0006b> at Python.Runtime.Runtime.Initialize () <0x00433> at Python.Runtime.PythonEngine.Initialize () <0x00073> at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff> oh well... anybody managed to get python.net working with UCS4 python? cheers, laszlo

Sadly, our other target, Maya, seems to be linking python statically... So I hope i can figure out how to get this integrated somehow...

Actually, scratch that. It seems like it has it's own .so as well. Time for some testing.... cheers, laszlo

We have been using it in maya on windows as well for a long time actually. We do have some event calling mechanisms as all of our custom GUI is implemented in the .net assemblies, and they communice with maya using some event hooks & delegate functions. It seems to work well, as long as we are careful. In the meantime, i got python.net working with the latest version of mono (2.8.1). Do you guys mind if i check in some minor changes to the source? I could post an svn patch here first. cheers, laszlo On 09/12/2010 7:54 PM, Tribble, Brett wrote:

Maya works fine with python.net. We use it all the time. Just remember that Maya is very particular as to how it handles multithreading, raising events, and the like. There is some info in the Maya Python SDK regarding how to deal with Python threading and Maya, and it seems to work with .NET callbacks as well. I've found that is seems best to add a flag to your .NET assembly that enables/disable events so that you can shut them off quickly before you end up with stacked event callbacks and resulting Maya crashes. If you're not raising events that percolate into Maya, then you probably don't need to worry about this.

-----Original Message----- From: pythondotnet-bounces+btribble=ea.com@python.org [mailto:pythondotnet-bounces+btribble=ea.com@python.org] On Behalf Of Laszlo Sebo Sent: Thursday, December 09, 2010 12:06 PM To: pythondotnet@python.org Subject: Re: [Python.NET] building on linux, mono 2.8.1

...

Sadly, our other target, Maya, seems to be linking python statically... So I hope i can figure out how to get this integrated somehow...

Actually, scratch that. It seems like it has it's own .so as well. Time for some testing....

cheers, laszlo

_________________________________________________ Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet

Am 12.12.2010 07:25, schrieb Brian Lloyd:

Hi all - I've recently taken a position that is MUCH more open-source friendly. Now that I don't have to have lawyers parse everything, what do you think about moving this whole thing to github? I don't know that I'll have much more time to devote to the project near term, but I would really like to lower the barrier-to-entry for folks with a vested interest in this project to contribute (and divest myself and others of of managing the SF project).

Unless anyone objects I think we should migrate the repo to github and redirect SF there...

I'm generally +1 for a DVCS but why git? I prefer to eat my own food and stick to a Python based DVCS like hq. Christian

I found github to be easy enough to use. The gitExtensions for VS didn't always play nicely, but were workable. That said, I'm still very reliant on TSVN and enjoy the hard work those guys have done on making Windows integration work sooo well. On 12/11/2010 10:25 PM, Brian Lloyd wrote:

Hi all - I've recently taken a position that is MUCH more open-source friendly. Now that I don't have to have lawyers parse everything, what do you think about moving this whole thing to github? I don't know that I'll have much more time to devote to the project near term, but I would really like to lower the barrier-to-entry for folks with a vested interest in this project to contribute (and divest myself and others of of managing the SF project).

Unless anyone objects I think we should migrate the repo to github and redirect SF there...

Thoughts?

- Brian

On Fri, Dec 10, 2010 at 1:30 PM, Laszlo Sebo <laszlo.sebo@primefocusworld.com <mailto:laszlo.sebo@primefocusworld.com>> wrote:

We have been using it in maya on windows as well for a long time actually. We do have some event calling mechanisms as all of our custom GUI is implemented in the .net assemblies, and they communice with maya using some event hooks & delegate functions.

It seems to work well, as long as we are careful.

In the meantime, i got python.net <http://python.net> working with the latest version of mono (2.8.1). Do you guys mind if i check in some minor changes to the source? I could post an svn patch here first.

cheers, laszlo

On 09/12/2010 7:54 PM, Tribble, Brett wrote:

Maya works fine with python.net <http://python.net>. We use it all the time. Just remember that Maya is very particular as to how it handles multithreading, raising events, and the like. There is some info in the Maya Python SDK regarding how to deal with Python threading and Maya, and it seems to work with .NET callbacks as well. I've found that is seems best to add a flag to your .NET assembly that enables/disable events so that you can shut them off quickly before you end up with stacked event callbacks and resulting Maya crashes. If you're not raising events that percolate into Maya, then you probably don't need to worry about this.

-----Original Message----- From: pythondotnet-bounces+btribble=ea.com <http://ea.com>@python.org <http://python.org> [mailto:pythondotnet-bounces+btribble <mailto:pythondotnet-bounces%2Bbtribble>=ea.com <http://ea.com>@python.org <http://python.org>] On Behalf Of Laszlo Sebo Sent: Thursday, December 09, 2010 12:06 PM To: pythondotnet@python.org <mailto:pythondotnet@python.org> Subject: Re: [Python.NET] building on linux, mono 2.8.1

> Sadly, our other target, Maya, seems to be linking python statically... So I hope i can figure out how to get this integrated somehow...

Actually, scratch that. It seems like it has it's own .so as well. Time for some testing....

cheers, laszlo

_________________________________________________ Python.NET mailing list - PythonDotNet@python.org <mailto:PythonDotNet@python.org> http://mail.python.org/mailman/listinfo/pythondotnet

_________________________________________________ Python.NET mailing list - PythonDotNet@python.org <mailto:PythonDotNet@python.org> http://mail.python.org/mailman/listinfo/pythondotnet

-- Brian Lloyd http://livingsocial.com <http://livingsocial.com/> (c) 540.845.2975

_________________________________________________ Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet

Am 09.12.2010 02:44, schrieb Laszlo Sebo:

The array would normally be initialized by calling _PyInt_Init(void). Sooo... just to test my theory, i exposed that function and called it explicitly from Python.Runtime.Initialize() and low and behold, import clr now works just fine!

So i'll now go on a hunt, and make sure everything is initialized properly, i'm guessing some main init function isn't being called somewhere when using python.net from an embedded python.

This happens when you use a "python" binary that isn't linked against libpython*.so. For example Debian and Ubuntu build a shared library but the python exe is statically linked against libpython.a. I hit the same bug when I coded the initial port to Mono about three years ago. Try "ldd $(which python2.6) | grep libpython". If it doesn't show the Python shared library then you have to create your own binary. A statically typed exe calls only _PyInt_Init() in its own data segment. "import clr" loads the shared library which doesn't anything with the exe. You end up with two interpreters in one program. This should be documented in the Python.NET sources somewhere. The sources should also contain an example or Makefile that creates a dynamically linked python binary for you. Python 2.5 support on Linux with UCS4 used to be stable and mature, since it was my major testing and deployment platform. But the current state of Python.NET on Linux is ... well ... not so good. ;) Christian