building on linux, mono 2.8.1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

building on linux, mono 2.8.1

Laszlo Sebo
Hi there,


I've been trying to get Python.Net working for the last couple weeks on linux (using rev 110), and so far i haven't had much luck. Maybe i am using libraries that are not yet supported, so any help would be appreciated.

I am using centOS 5.5, and python 2.5.1 64bit. I am using the latest (2.8.1) version of mono.

To get python.net to build, i had to modify a couple of files, as by default it wouldn't build. First I had to build and install  glib (2.26.1), then do the following:

Add these lines to the setup.py (most likely my glib installation wasn't doing its setup properly)
kw["include_dirs"].append('/usr/local/include/glib-2.0')
kw["include_dirs"].append('/usr/local/lib/glib-2.0/include')
Then edit the pynetclr.h file and add this line:
#include <gmodule.h>

Then edit the makefile for monoclr:
add include files to PY_CFLAGS variable: -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include
MONO_LIBS = $(shell pkg-config --libs mono-2)
MONO_CFLAGS = $(shell pkg-config --cflags mono-2)
add clrpython.o to clr.so make: -dynamiclib pynetinit.o clrmod.o clrpython.o -o clr.so
remove -lpython from the PY_LIBS listing
After this everything built without errors. However... the clr.so files don't quite work :)

I get 3 behaviours:
  • if i use the clr.so in the root folder: import clr; import System; => segmentation fault
  • if i use the clr.so in the monoclr folder: ImportError: /usr/local/lib/python2.5/site-packages/clr.so: cannot dynamically load executable
  • if i use the clr.so in the root folder, and also copy the libpython2.5.so in the site-packages folder: import clr => segmentation fault
Not sure what i'm doing wrong to be honest. I'll try to roll back mono a couple versions, and try that (2.4.3 maybe).

I have a feeling i am missing something very obvious here...

Any pointers would be appreciated!


cheers,
laszlo sebo

_________________________________________________
Python.NET mailing list - [hidden email]
http://mail.python.org/mailman/listinfo/pythondotnet
Reply | Threaded
Open this post in threaded view
|

Re: building on linux, mono 2.8.1

Laszlo Sebo
A small update. I went back a couple of versions on mono, to see if that's got anything to do with my problems.

Starting from a clean VM. I simplified the build process a bit as well.

I managed to get clr.so working fine with python2.5.5 and using mono2.4.3, when running it using the standalone python installation.


However, when i try to import clr into an embedded python (like the one in Nuke5.2 for example), i get the following error:

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) <0x00023>
  at Python.Runtime.Runtime.Initialize () <0x00303>
  at Python.Runtime.PythonEngine.Initialize () <0x0004b>
  at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff                               >

Native stacktrace:

        /usr/local/lib/libmono.so.0 [0x2aaab409088d]
        /usr/local/lib/libmono.so.0 [0x2aaab40c0a33]
        /lib64/libc.so.6 [0x39568302d0]
        /usr/local/lib/libpython2.5.so(PyInt_FromLong+0x1c) [0x2aaab48fdf5c]
        [0x40fad6a0]


I noticed that Ulrich Elk had this issue about 2 years ago, and Brian Lloyd's first reaction was "are you on a 64bit machine?". Well, i am :-)
All the libraries i use are 64b (at least i think so, i built most requirements myself).

( http://mail.python.org/pipermail/pythondotnet/2008-April/000795.html )



cheers,
laszlo




On 06/12/2010 5:22 PM, Laszlo Sebo wrote:
Hi there,


I've been trying to get Python.Net working for the last couple weeks on linux (using rev 110), and so far i haven't had much luck. Maybe i am using libraries that are not yet supported, so any help would be appreciated.

I am using centOS 5.5, and python 2.5.1 64bit. I am using the latest (2.8.1) version of mono.

To get python.net to build, i had to modify a couple of files, as by default it wouldn't build. First I had to build and install  glib (2.26.1), then do the following:

Add these lines to the setup.py (most likely my glib installation wasn't doing its setup properly)
kw["include_dirs"].append('/usr/local/include/glib-2.0')
kw["include_dirs"].append('/usr/local/lib/glib-2.0/include')
Then edit the pynetclr.h file and add this line:
#include <gmodule.h>

Then edit the makefile for monoclr:
add include files to PY_CFLAGS variable: -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include
MONO_LIBS = $(shell pkg-config --libs mono-2)
MONO_CFLAGS = $(shell pkg-config --cflags mono-2)
add clrpython.o to clr.so make: -dynamiclib pynetinit.o clrmod.o clrpython.o -o clr.so
remove -lpython from the PY_LIBS listing
After this everything built without errors. However... the clr.so files don't quite work :)

I get 3 behaviours:
  • if i use the clr.so in the root folder: import clr; import System; => segmentation fault
  • if i use the clr.so in the monoclr folder: ImportError: /usr/local/lib/python2.5/site-packages/clr.so: cannot dynamically load executable
  • if i use the clr.so in the root folder, and also copy the libpython2.5.so in the site-packages folder: import clr => segmentation fault
Not sure what i'm doing wrong to be honest. I'll try to roll back mono a couple versions, and try that (2.4.3 maybe).

I have a feeling i am missing something very obvious here...

Any pointers would be appreciated!


cheers,
laszlo sebo

    


_________________________________________________
Python.NET mailing list - [hidden email]
http://mail.python.org/mailman/listinfo/pythondotnet
Reply | Threaded
Open this post in threaded view
|

Re: building on linux, mono 2.8.1

Laszlo Sebo
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


On 07/12/2010 7:08 PM, Laszlo Sebo wrote:
A small update. I went back a couple of versions on mono, to see if that's got anything to do with my problems.

Starting from a clean VM. I simplified the build process a bit as well.

I managed to get clr.so working fine with python2.5.5 and using mono2.4.3, when running it using the standalone python installation.


However, when i try to import clr into an embedded python (like the one in Nuke5.2 for example), i get the following error:

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) <0x00023>
  at Python.Runtime.Runtime.Initialize () <0x00303>
  at Python.Runtime.PythonEngine.Initialize () <0x0004b>
  at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff                               >

Native stacktrace:

        /usr/local/lib/libmono.so.0 [0x2aaab409088d]
        /usr/local/lib/libmono.so.0 [0x2aaab40c0a33]
        /lib64/libc.so.6 [0x39568302d0]
        /usr/local/lib/libpython2.5.so(PyInt_FromLong+0x1c) [0x2aaab48fdf5c]
        [0x40fad6a0]


I noticed that Ulrich Elk had this issue about 2 years ago, and Brian Lloyd's first reaction was "are you on a 64bit machine?". Well, i am :-)
All the libraries i use are 64b (at least i think so, i built most requirements myself).

( http://mail.python.org/pipermail/pythondotnet/2008-April/000795.html )



cheers,
laszlo




On 06/12/2010 5:22 PM, Laszlo Sebo wrote:
Hi there,


I've been trying to get Python.Net working for the last couple weeks on linux (using rev 110), and so far i haven't had much luck. Maybe i am using libraries that are not yet supported, so any help would be appreciated.

I am using centOS 5.5, and python 2.5.1 64bit. I am using the latest (2.8.1) version of mono.

To get python.net to build, i had to modify a couple of files, as by default it wouldn't build. First I had to build and install  glib (2.26.1), then do the following:

Add these lines to the setup.py (most likely my glib installation wasn't doing its setup properly)
kw["include_dirs"].append('/usr/local/include/glib-2.0')
kw["include_dirs"].append('/usr/local/lib/glib-2.0/include')
Then edit the pynetclr.h file and add this line:
#include <gmodule.h>

Then edit the makefile for monoclr:
add include files to PY_CFLAGS variable: -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include
MONO_LIBS = $(shell pkg-config --libs mono-2)
MONO_CFLAGS = $(shell pkg-config --cflags mono-2)
add clrpython.o to clr.so make: -dynamiclib pynetinit.o clrmod.o clrpython.o -o clr.so
remove -lpython from the PY_LIBS listing
After this everything built without errors. However... the clr.so files don't quite work :)

I get 3 behaviours:
  • if i use the clr.so in the root folder: import clr; import System; => segmentation fault
  • if i use the clr.so in the monoclr folder: ImportError: /usr/local/lib/python2.5/site-packages/clr.so: cannot dynamically load executable
  • if i use the clr.so in the root folder, and also copy the libpython2.5.so in the site-packages folder: import clr => segmentation fault
Not sure what i'm doing wrong to be honest. I'll try to roll back mono a couple versions, and try that (2.4.3 maybe).

I have a feeling i am missing something very obvious here...

Any pointers would be appreciated!


cheers,
laszlo sebo



_________________________________________________
Python.NET mailing list - [hidden email]
http://mail.python.org/mailman/listinfo/pythondotnet
Reply | Threaded
Open this post in threaded view
|

Re: building on linux, mono 2.8.1

Laszlo Sebo
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


_________________________________________________
Python.NET mailing list - [hidden email]
http://mail.python.org/mailman/listinfo/pythondotnet
Reply | Threaded
Open this post in threaded view
|

Re: building on linux, mono 2.8.1

Tribble, Brett

Your long self-conversation is the most interesting thing to happen to this list in a long time…

 

From: pythondotnet-bounces+btribble=[hidden email] [mailto:pythondotnet-bounces+btribble=[hidden email]] On Behalf Of Laszlo Sebo
Sent: Wednesday, December 08, 2010 5:45 PM
To: [hidden email]
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

 


_________________________________________________
Python.NET mailing list - [hidden email]
http://mail.python.org/mailman/listinfo/pythondotnet
Reply | Threaded
Open this post in threaded view
|

Re: building on linux, mono 2.8.1

Christian Heimes-2
In reply to this post by Laszlo Sebo
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

_________________________________________________
Python.NET mailing list - [hidden email]
http://mail.python.org/mailman/listinfo/pythondotnet
Reply | Threaded
Open this post in threaded view
|

Re: building on linux, mono 2.8.1

Laszlo Sebo
In reply to this post by Tribble, Brett
Not a lot of traffic lately, eh? :-)

In all honesty, i think python.net is a godsend. We have been using it as a core part of our pipeline for a long time now. It enables us full .net integration into a lot of tools that have python embedded in them. It allowed us to write most of our pipeline code in c# and fully reuse it in several different applications with practically no change.

We are now working on integrating linux into our pipeline, so it's crucial for us to get this working, if possible :-)

In the meantime, i have found that one of our target client applications (Nuke), has it's own libpython.so and if i link to that, all seems to work just dandy! Huge relief! Sadly, our other target, Maya, seems to be linking python statically... So I hope i can figure out how to get this integrated somehow...


cheers,
laszlo


On 08/12/2010 7:47 PM, Tribble, Brett wrote:

Your long self-conversation is the most interesting thing to happen to this list in a long time…

 




_________________________________________________
Python.NET mailing list - [hidden email]
http://mail.python.org/mailman/listinfo/pythondotnet
Reply | Threaded
Open this post in threaded view
|

Re: building on linux, mono 2.8.1

Laszlo Sebo
 > 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 - [hidden email]
http://mail.python.org/mailman/listinfo/pythondotnet
Reply | Threaded
Open this post in threaded view
|

Re: building on linux, mono 2.8.1

Dirk Krause
In reply to this post by Laszlo Sebo

I’ll chime in with a quick comment on this:

 

I evaluated python.net some time ago (for an OpenSimulator based project some time ago) and it worked like a charm.

 

Unfortunately we had to stop this project for various reasons, but I have to say: it’s projects like these that keep the fun going.

 

Great work, guys!!

 

Best,

  Dirk

 

Von: pythondotnet-bounces+dirk.krause=[hidden email] [mailto:pythondotnet-bounces+dirk.krause=[hidden email]] Im Auftrag von Laszlo Sebo
Gesendet: Donnerstag, 9. Dezember 2010 21:00
An: [hidden email]
Betreff: Re: [Python.NET] building on linux, mono 2.8.1

 

Not a lot of traffic lately, eh? :-)

In all honesty, i think python.net is a godsend. We have been using it as a core part of our pipeline for a long time now. It enables us full .net integration into a lot of tools that have python embedded in them. It allowed us to write most of our pipeline code in c# and fully reuse it in several different applications with practically no change.

We are now working on integrating linux into our pipeline, so it's crucial for us to get this working, if possible :-)

In the meantime, i have found that one of our target client applications (Nuke), has it's own libpython.so and if i link to that, all seems to work just dandy! Huge relief! Sadly, our other target, Maya, seems to be linking python statically... So I hope i can figure out how to get this integrated somehow...


cheers,
laszlo


On 08/12/2010 7:47 PM, Tribble, Brett wrote:

Your long self-conversation is the most interesting thing to happen to this list in a long time…

 

 

 


_________________________________________________
Python.NET mailing list - [hidden email]
http://mail.python.org/mailman/listinfo/pythondotnet
Reply | Threaded
Open this post in threaded view
|

Re: building on linux, mono 2.8.1

Tribble, Brett
In reply to this post by Laszlo Sebo
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=[hidden email] [mailto:pythondotnet-bounces+btribble=[hidden email]] On Behalf Of Laszlo Sebo
Sent: Thursday, December 09, 2010 12:06 PM
To: [hidden email]
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 - [hidden email]
http://mail.python.org/mailman/listinfo/pythondotnet

_________________________________________________
Python.NET mailing list - [hidden email]
http://mail.python.org/mailman/listinfo/pythondotnet
Reply | Threaded
Open this post in threaded view
|

Re: building on linux, mono 2.8.1

Laszlo Sebo
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=[hidden email] [mailto:pythondotnet-bounces+btribble=[hidden email]] On Behalf Of Laszlo Sebo
> Sent: Thursday, December 09, 2010 12:06 PM
> To: [hidden email]
> 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 - [hidden email]
> http://mail.python.org/mailman/listinfo/pythondotnet
>

_________________________________________________
Python.NET mailing list - [hidden email]
http://mail.python.org/mailman/listinfo/pythondotnet
Reply | Threaded
Open this post in threaded view
|

Re: building on linux, mono 2.8.1

Brian Lloyd-3
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 <[hidden email]> 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 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:[hidden email]=ea.com@python.org] On Behalf Of Laszlo Sebo
Sent: Thursday, December 09, 2010 12:06 PM
To: [hidden email]
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 - [hidden email]
http://mail.python.org/mailman/listinfo/pythondotnet


_________________________________________________
Python.NET mailing list - [hidden email]
http://mail.python.org/mailman/listinfo/pythondotnet



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


_________________________________________________
Python.NET mailing list - [hidden email]
http://mail.python.org/mailman/listinfo/pythondotnet
Reply | Threaded
Open this post in threaded view
|

Re: building on linux, mono 2.8.1

Christian Heimes-2
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

_________________________________________________
Python.NET mailing list - [hidden email]
http://mail.python.org/mailman/listinfo/pythondotnet
Reply | Threaded
Open this post in threaded view
|

Re: building on linux, mono 2.8.1

Tribble, Brett
I'm not a huge GIT lover, but it seems to have the most inertia behind it right now, so that would be my preference should the change be made...


-----Original Message-----
From: pythondotnet-bounces+btribble=[hidden email] [mailto:pythondotnet-bounces+btribble=[hidden email]] On Behalf Of Christian Heimes
Sent: Monday, December 13, 2010 9:32 AM
To: [hidden email]
Subject: Re: [Python.NET] building on linux, mono 2.8.1

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

_________________________________________________
Python.NET mailing list - [hidden email]
http://mail.python.org/mailman/listinfo/pythondotnet

_________________________________________________
Python.NET mailing list - [hidden email]
http://mail.python.org/mailman/listinfo/pythondotnet
Reply | Threaded
Open this post in threaded view
|

Re: building on linux, mono 2.8.1

Barton
In reply to this post by Brian Lloyd-3
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 <[hidden email]> 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 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:[hidden email]=ea.com@python.org] On Behalf Of Laszlo Sebo
Sent: Thursday, December 09, 2010 12:06 PM
To: [hidden email]
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 - [hidden email]
http://mail.python.org/mailman/listinfo/pythondotnet


_________________________________________________
Python.NET mailing list - [hidden email]
http://mail.python.org/mailman/listinfo/pythondotnet



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

_________________________________________________ Python.NET mailing list - [hidden email] http://mail.python.org/mailman/listinfo/pythondotnet

_________________________________________________
Python.NET mailing list - [hidden email]
http://mail.python.org/mailman/listinfo/pythondotnet