questions from a new PythonNet user
Hi there, I've just started working with PythonNet and I have a few questions about getting it built and running. Any help would be appreciated, here is my current situation and questions. Sorry for the long email but I figured details can only help you help me. I would like to be able to download and build PythonNet from scratch on Windows XP (32-bit) and on Ubuntu. If I have to build the .net assemblies on XP for use in Ubuntu that's fine. On Ubuntu I have python 2.5.2, gcc 4.3.2, and mono 1.9.1. I have the python dev and mono dev things installed as well, and my /etc/mono/config file is populated with the extra bits from the pythonnet distribution. On Windows I have Visual Studio Pro 2008 and python 2.5.2. On both platforms I have the latest (r100) from svn, and on Ubuntu I also have the pythonnet-2.0-alpha2 distribution. On Ubuntu once I put the svn-retrieved setup.py I was able to rebuild the pythonnet-2.0-alpha2 version of clr.so to be a 64-bit library; once I had done this and set my GAC I was able to use "mono python.exe" (or simply python.exe) and make a .net System.Drawing.Point object and get its field values. Yay... except that starting python and doing "import clr" made a heroic effort and then died. I'm using python2.5-UCS4 because in python, "len(u'\U00010800')" returns 1, is that correct? Anyway, the error text is attached. I can't get very far building the .net components checked out from svn because from what I can tell ilasm2 doesn't like some of the #define and #include and etc. in the code. Is it possible to build everything with Mono or no? On Windows I can build everything with no errors or warnings under VS Pro. Pity mostly I want to use it under unix. I believe the assemblies should work but there's this nasty little bit of .il that ends up 32- or 64-bit specific. So I need to know how to target 64-bit from a 32-bit host and I'm not entirely sure what to configure in this case. I can see how to configure for different python versions and UCS2/4, so that's not a problem. If I can get guidance on targeting 32- or 64- by inclusion of the proper .il file, I think I can build all the different versions I need of the .net stuff and then I just need to be able to build (or possibly just invoke) a working built version of clr.so over on the unix side. I suppose the first question is, Why are there no apparent build instructions in the distribution? It seems that there are more than half a dozen build configurations (python 2.3, 4, 5, and 6, plus UCS2/4 distinctions for 5 and 6, plus clr.so/.dll being built for a 32- or 64-bit system) and a couple of possible build environments (VS or Mono+make), so breaking this all down for first timers would really, really be appreciated. If I've just missed them, I apologize, but the only thing I've been able to find so far is http://feihonghsu.blogspot.com/2008/02/installing-pythonnet-20-alpha-2-on.ht... and http://feihonghsu.blogspot.com/2008/02/pythonnet-20-for-net-sp1_15.html which are _great_ but they are at an unaffiliated web site, are only Visual Studio instructions, and don't cover targeting 32/64 bit. I should also mention that if there really aren't official build instructions I will happily write some up (cribbing somewhat from Mr. Feihong Hsu if he agrees) as soon as I have a clear understanding of the process and can do it successfully, and I'll stick that into svn if I can or post it to the mailing list for a dev to add if I can't. How actively maintained is PythonNet at the moment? It looks like since the project was made to work patches have become infrequent, which I will take to mean that things work reasonably well. But this putative .net SP1 patch ( http://mail.python.org/pipermail/pythondotnet/2008-January/000771.html ) was not apparently folded into SVN, was there a reason for this? The distribution at http://sourceforge.net/project/showfiles.php?group_id=162464 is missing setup.py, is this an oversight (I notice it is in the svn distribution)? Finally, is there active development towards a 2.0 final, or has the project hit a bit of a plateau with 2.0 alpha2? Thank you very much for your time, hamilton $ python Python 2.5.2 (r252:60911, Oct 5 2008, 19:29:17) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import clr Stacktrace:
at (wrapper managed-to-native) Python.Runtime.Runtime.Py_Initialize () <0x00057> at (wrapper managed-to-native) Python.Runtime.Runtime.Py_Initialize () <0xffffffff> at Python.Runtime.Runtime.Initialize () <0x00070> at Python.Runtime.PythonEngine.Initialize () <0x00019> at (wrapper runtime-invoke) Python.Runtime.PythonEngine.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff> Native stacktrace: /usr/lib/libmono.so.0 [0x7f1442c5661d] /usr/lib/libmono.so.0 [0x7f1442c76a1d] /lib/libpthread.so.0 [0x7f14446ff0f0] /lib/libc.so.6(cfree+0x43) [0x7f1443d6df53] /usr/lib/libpython2.5.so(PyString_InternInPlace+0xbb) [0x7f14411cdf1b] /usr/lib/libpython2.5.so(PyString_InternFromString+0x22) [0x7f14411d05c2] /usr/lib/libpython2.5.so(PyType_Ready+0xa5) [0x7f14411e29e5] /usr/lib/libpython2.5.so(_Py_ReadyTypes+0x74) [0x7f14411c3b84] /usr/lib/libpython2.5.so(Py_InitializeEx+0x6b) [0x7f144123598b] [0x418e2a37] Debug info from gdb: (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 0x7f1444b176e0 (LWP 13719)] [New Thread 0x418c0950 (LWP 13721)] [New Thread 0x418f5950 (LWP 13720)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) 0x00007f1443dd1482 in select () from /lib/libc.so.6 3 Thread 0x418f5950 (LWP 13720) 0x00007f14446fe851 in nanosleep () from /lib/libpthread.so.0 2 Thread 0x418c0950 (LWP 13721) 0x00007f14446fb2d9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 1 Thread 0x7f1444b176e0 (LWP 13719) 0x00007f1443dd1482 in select () from /lib/libc.so.6 Thread 3 (Thread 0x418f5950 (LWP 13720)): #0 0x00007f14446fe851 in nanosleep () from /lib/libpthread.so.0 #1 0x00007f1442d21212 in ?? () from /usr/lib/libmono.so.0 #2 0x00007f14446f73ea in start_thread () from /lib/libpthread.so.0 #3 0x00007f1443dd8c6d in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 2 (Thread 0x418c0950 (LWP 13721)): #0 0x00007f14446fb2d9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f1442d240a5 in ?? () from /usr/lib/libmono.so.0 #2 0x00007f1442d2635b in ?? () from /usr/lib/libmono.so.0 #3 0x00007f1442d374ae in ?? () from /usr/lib/libmono.so.0 #4 0x00007f1442cbd133 in ?? () from /usr/lib/libmono.so.0 #5 0x00007f1442cdac5b in ?? () from /usr/lib/libmono.so.0 #6 0x00007f1442d35873 in ?? () from /usr/lib/libmono.so.0 #7 0x00007f1442d51c92 in ?? () from /usr/lib/libmono.so.0 #8 0x00007f14446f73ea in start_thread () from /lib/libpthread.so.0 #9 0x00007f1443dd8c6d in clone () from /lib/libc.so.6 #10 0x0000000000000000 in ?? () Thread 1 (Thread 0x7f1444b176e0 (LWP 13719)): #0 0x00007f1443dd1482 in select () from /lib/libc.so.6 #1 0x00007f14427985ac in g_spawn_sync () from /usr/lib/libglib-2.0.so.0 #2 0x00007f1442798988 in g_spawn_command_line_sync () from /usr/lib/libglib-2.0.so.0 #3 0x00007f1442c566c6 in ?? () from /usr/lib/libmono.so.0 #4 0x00007f1442c76a1d in ?? () from /usr/lib/libmono.so.0 #5 <signal handler called> #6 0x00007f1443d6df53 in free () from /lib/libc.so.6 #7 0x00007f14411cdf1b in PyString_InternInPlace () from /usr/lib/libpython2.5.so #8 0x00007f14411d05c2 in PyString_InternFromString () from /usr/lib/libpython2.5.so #9 0x00007f14411e29e5 in PyType_Ready () from /usr/lib/libpython2.5.so #10 0x00007f14411c3b84 in _Py_ReadyTypes () from /usr/lib/libpython2.5.so #11 0x00007f144123598b in Py_InitializeEx () from /usr/lib/libpython2.5.so #12 0x00000000418e2a37 in ?? () #13 0x00000000013a7e60 in ?? () #14 0x00000000013a8db8 in ?? () #15 0x0000000000000000 in ?? () #0 0x00007f1443dd1482 in select () from /lib/libc.so.6 ================================================================= Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. ================================================================= Aborted $
On Fri, Nov 14, 2008 at 8:38 PM, Hamilton Link <helink@sandia.gov> wrote:
...
I suppose the first question is, Why are there no apparent build instructions in the distribution?
Hi there - unfortunately I think the problem is that it would take a large effort to come up with a build process that works reliably for all possible platforms (mono, win32), python versions, unicode requirements, build toolchains, etc. Consequently, the docs are kind of all over the place. Thus far, while python.net has been useful for some people, I don't think the user community is large enough yet for any group of people to get together to put together anything really comprehensive in terms of distribution tools or docs.
It seems that there are more than half a dozen build configurations (python 2.3, 4, 5, and 6, plus UCS2/4 distinctions for 5 and 6, plus clr.so/.dll being built for a 32- or 64-bit system) and a couple of possible build environments (VS or Mono+make), so breaking this all down for first timers would really, really be appreciated. If I've just missed them, I apologize, but the only thing I've been able to find so far is
http://feihonghsu.blogspot.com/2008/02/installing-pythonnet-20-alpha-2-on.ht... and http://feihonghsu.blogspot.com/2008/02/pythonnet-20-for-net-sp1_15.html which are _great_ but they are at an unaffiliated web site, are only Visual Studio instructions, and don't cover targeting 32/64 bit. I should also mention that if there really aren't official build instructions I will happily write some up (cribbing somewhat from Mr. Feihong Hsu if he agrees) as soon as I have a clear understanding of the process and can do it successfully, and I'll stick that into svn if I can or post it to the mailing list for a dev to add if I can't.
If you're willing to write some, I'm willing to give you whatever access you need to get them in svn ;) If anyone thinks a lighter weight tool would help, we could set up a mediawiki instance or something as well...
How actively maintained is PythonNet at the moment?
It looks like since the project was made to work patches have become infrequent, which I will take to mean that things work reasonably well. But this putative .net SP1 patch ( http://mail.python.org/pipermail/pythondotnet/2008-January/000771.html ) was not apparently folded into SVN, was there a reason for this?
I can only speak for myself as the original author -- for my part, the project that allowed me to do the original work on this is ancient history. While I have an ongoing geeky interest and have on occasion been able to do small spurts of work, its unlikely I will be able to work on this substantively in the near future. To their credit, many of the folks who have used the system have stepped up to contribute changes when they have run up against problems. I have, and will continue to, give those folks access to sourceforge etc. to improve the platform as they are able. But my impression is that where we are now is a situation where people can "scratch their own itch", but there is no organized effort to track the .NET or mono platform changes going forward. My opinion is that it will take an invested champion to make that happen. FWIW, Resolver and others seem to be using some of the code and concepts from python.net to further use of native extensions with IronPython -- that may also be a good avenue to explore if you're looking for long-term supportability (and I'm sure resolver would welcome the help!) -Brian
Brian Lloyd wrote:
On Fri, Nov 14, 2008 at 8:38 PM, Hamilton Link <helink@sandia.gov <mailto:helink@sandia.gov>> wrote:
...
I suppose the first question is, Why are there no apparent build instructions in the distribution?
Hi there - unfortunately I think the problem is that it would take a large effort to come up with a build process that works reliably for all possible platforms (mono, win32), python versions, unicode requirements, build toolchains, etc. Consequently, the docs are kind of all over the place.
Thus far, while python.net <http://python.net> has been useful for some people, I don't think the user community is large enough yet for any group of people to get together to put together anything really comprehensive in terms of distribution tools or docs.
If you're willing to write some, I'm willing to give you whatever access you need to get them in svn ;) If anyone thinks a lighter weight tool would help, we could set up a mediawiki instance or something as well...
Python.net serves a niche's niche's niche, so I don't expect it will ever have too many users. But SVN access would be great, thanks. I will try to put in a README of some sort that combines the relevant documentation I can find plus whatever works for me into a (disclaimer-ed) set of build instructions. Also if I am able to do a before/after test of the .net SP1 patch would anyone mind if I committed that into the repository? Also, if the SP1 patch and anything else goes in to the trunk (and if I can figure out how to do it) I will package a new distro that includes the setup.py script and the patches and I'll put it on sourceforge as alpha 3 or some such. But don't hold your breath until it's already done, 'k?
How actively maintained is PythonNet at the moment?
I have, and will continue to, give those folks access to sourceforge etc. to improve the platform as they are able. But my impression is that where we are now is a situation where people can "scratch their own itch", but there is no organized effort to track the .NET or mono platform changes going forward. My opinion is that it will take an invested champion to make that happen.
FWIW, Resolver and others seem to be using some of the code and concepts from python.net <http://python.net> to further use of native extensions with IronPython -- that may also be a good avenue to explore if you're looking for long-term supportability (and I'm sure resolver would welcome the help!)
-Brian
Well, for what it's worth, for the near future I have a vested interest in making sure python.net works on linux, windows, and os x. IronPython isn't an option for me. Other good news is that mono now claims approximate 2.0 compliance and so the underpinnings of the CLR shouldn't change for a good while yet, minimizing portability issues. The bad news is most of my time is being spent on other projects than this one. Beyond extensive testing we'll see what happens. I can't promise I'll be in a place to debug any problems, since I'm not really a python programmer. And I _really_ can't promise upgrades for python 2.6 (if it doesn't already work... haven't tried it) or python 3.x. h
Getting a new "official" distribution up would be great - on this end, I know Joe Frayne and myself have provided several patches that let Python.net run on 64bit, fixes bugs, etc, some of which others seem to have run into when just downloading the alpha2 zip... John -----Original Message----- From: pythondotnet-bounces+jburnett=blizzard.com@python.org [mailto:pythondotnet-bounces+jburnett=blizzard.com@python.org] On Behalf Of Hamilton Link Sent: Monday, December 01, 2008 4:04 PM To: Brian Lloyd Cc: pythondotnet@python.org Subject: Re: [Python.NET] questions from a new PythonNet user Brian Lloyd wrote:
On Fri, Nov 14, 2008 at 8:38 PM, Hamilton Link <helink@sandia.gov <mailto:helink@sandia.gov>> wrote:
...
I suppose the first question is, Why are there no apparent build instructions in the distribution?
Hi there - unfortunately I think the problem is that it would take a large effort to come up with a build process that works reliably for all possible platforms (mono, win32), python versions, unicode requirements, build toolchains, etc. Consequently, the docs are kind of all over the place.
Thus far, while python.net <http://python.net> has been useful for some people, I don't think the user community is large enough yet for any group of people to get together to put together anything really comprehensive in terms of distribution tools or docs.
If you're willing to write some, I'm willing to give you whatever access you need to get them in svn ;) If anyone thinks a lighter weight tool would help, we could set up a mediawiki instance or something as well...
Python.net serves a niche's niche's niche, so I don't expect it will ever have too many users. But SVN access would be great, thanks. I will try to put in a README of some sort that combines the relevant documentation I can find plus whatever works for me into a (disclaimer-ed) set of build instructions. Also if I am able to do a before/after test of the .net SP1 patch would anyone mind if I committed that into the repository? Also, if the SP1 patch and anything else goes in to the trunk (and if I can figure out how to do it) I will package a new distro that includes the setup.py script and the patches and I'll put it on sourceforge as alpha 3 or some such. But don't hold your breath until it's already done, 'k?
How actively maintained is PythonNet at the moment?
I have, and will continue to, give those folks access to sourceforge etc. to improve the platform as they are able. But my impression is that where we are now is a situation where people can "scratch their own itch", but there is no organized effort to track the .NET or mono platform changes going forward. My opinion is that it will take an invested champion to make that happen.
FWIW, Resolver and others seem to be using some of the code and concepts from python.net <http://python.net> to further use of native extensions with IronPython -- that may also be a good avenue to explore if you're looking for long-term supportability (and I'm sure resolver would welcome the help!)
-Brian
Well, for what it's worth, for the near future I have a vested interest in making sure python.net works on linux, windows, and os x. IronPython isn't an option for me. Other good news is that mono now claims approximate 2.0 compliance and so the underpinnings of the CLR shouldn't change for a good while yet, minimizing portability issues. The bad news is most of my time is being spent on other projects than this one. Beyond extensive testing we'll see what happens. I can't promise I'll be in a place to debug any problems, since I'm not really a python programmer. And I _really_ can't promise upgrades for python 2.6 (if it doesn't already work... haven't tried it) or python 3.x. h _________________________________________________ Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet
participants (3)
-
Brian Lloyd -
Hamilton Link -
John Burnett