From alexandre.fayolle at logilab.fr Fri Jul 1 15:47:09 2011 From: alexandre.fayolle at logilab.fr (Alexandre Fayolle) Date: Fri, 1 Jul 2011 15:47:09 +0200 Subject: [Python.NET] trouble downloading pythonnet-2.0-alpha2-clr2.0_py26 Message-ID: <201107011547.09866.alexandre.fayolle@logilab.fr> Hello, I'm trying to download pythonnet-2.0-alpha2-clr2.0_py26 from http://sourceforge.net/projects/pythonnet/files/pythonnet-2.0-alpha2- clr2.0_py26/pythonnet-2.0-alpha2-clr2.0_131_py26_UCS2.zip/download , and I get a file with the correct MD5 checksum, but which is not a zip file. It is also much smaller than the previous versions and the 2.7 build of revision 130. Could someone please upload a fixed recent version of the python2.6 build? Thanks in advance. -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, CubicWeb, Debian : http://www.logilab.fr/formations D?veloppement logiciel sur mesure : http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science From barton at BCDesignsWell.com Sat Jul 2 12:22:44 2011 From: barton at BCDesignsWell.com (Barton) Date: Sat, 02 Jul 2011 03:22:44 -0700 Subject: [Python.NET] trouble downloading pythonnet-2.0-alpha2-clr2.0_py26 In-Reply-To: <201107011547.09866.alexandre.fayolle@logilab.fr> References: <201107011547.09866.alexandre.fayolle@logilab.fr> Message-ID: <4E0EF174.9030104@BCDesignsWell.com> I'll re-zip and upload that this weekend. Thanks. -barton On 7/1/2011 6:47 AM, Alexandre Fayolle wrote: > Hello, > > I'm trying to download pythonnet-2.0-alpha2-clr2.0_py26 from > http://sourceforge.net/projects/pythonnet/files/pythonnet-2.0-alpha2- > clr2.0_py26/pythonnet-2.0-alpha2-clr2.0_131_py26_UCS2.zip/download , and I get > a file with the correct MD5 checksum, but which is not a zip file. It is also > much smaller than the previous versions and the 2.7 build of revision 130. > > Could someone please upload a fixed recent version of the python2.6 build? > > Thanks in advance. > From barton at bcdesignswell.com Sun Jul 3 01:38:56 2011 From: barton at bcdesignswell.com (Barton) Date: Sat, 02 Jul 2011 16:38:56 -0700 Subject: [Python.NET] Passing .NET objects to Python In-Reply-To: References: Message-ID: <4E0FAC10.2020300@bcdesignswell.com> The source code for the pythondotnet project has a great example of this. There is a copy [although, not quite up-to-date] of the project on the github repository which even has nUnit unit test framework built in. This project uses pure python to load the test assembly via unittest for a fairly complete test of the pythondotnet assembly itself. On 06/05/2011 03:06 PM, Meredith, Christopher wrote: > Greetings. > > I have a test framework written in C# that handles test execution, > logging, reporting, etc., and some tests for some of our hardware that > are written in Python. Ideally, I?m wanting to call Setup(), Run() and > TearDown() methods defined in Python scripts, passing them an instance > of the object I have that handles logging as a parameter (or defining it > globally from the perspective of the loaded script). Whilst I can find > methods that load entire Python scripts and call them from .NET, I can?t > seem to find anything in the documentation or defined publicly in > Python.Runtime.dll. Is this doable? Is this documented? > > Thanks, > > Chris Meredith > > Test Engineer, North American Embedded Professional Services > > Email: christopher.meredith at nuance.com > > > > > _________________________________________________ > Python.NET mailing list - PythonDotNet at python.org > http://mail.python.org/mailman/listinfo/pythondotnet From alexandre.fayolle at logilab.fr Mon Jul 4 13:43:07 2011 From: alexandre.fayolle at logilab.fr (Alexandre Fayolle) Date: Mon, 4 Jul 2011 13:43:07 +0200 Subject: [Python.NET] using pythonnet as a Windows service Message-ID: <201107041343.07581.alexandre.fayolle@logilab.fr> Hello, I'm starting to use pythonnet to integrate a .NET DLL with an existing CPython application running on Windows. The application runs as a Windows service using pywin32's pythonservice.exe. Has anyone done the mixing of pythonservice.exe and pythonnet? Thanks in advance -- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, CubicWeb, Debian : http://www.logilab.fr/formations D?veloppement logiciel sur mesure : http://www.logilab.fr/services Informatique scientifique: http://www.logilab.fr/science From oystein+pythondotnet at edge.no Mon Jul 11 11:58:28 2011 From: oystein+pythondotnet at edge.no (=?ISO-8859-1?Q?=D8ystein_Skotheim?=) Date: Mon, 11 Jul 2011 11:58:28 +0200 Subject: [Python.NET] Replaced Python.exe file causes problems for extension modules Message-ID: <4E1AC944.1000905@edge.no> Hello. I have managed to compile the SVN version of PythonDotNet against the 4.0 version of the .NET library with Visual Studio 2010 on Windows 7. I copied over clr.pyd, Python.Runtime.dll as well as new versions of python.exe and pythonw.exe into my C:\Python26 directory. I am now able to import .NET 4.0 modules after writing "import clr" :-) However, I have run into a few problems because I had to replace my Python executable. I am using a lot of packages from the PythonXY that depend on c extension modules (.pyd-files). Whenever I try to import such a module, I get the following error: Runtime Error! Program: C:\Python26\Python.exe R6034 An application has made an attempt to load the C runtime library incorrectly. Please contact the application's support team for more information. I think the reason for this is that I have compiled Python.exe with Visual Studio 2010, whereas the extension modules are compiled with Visual Studio 2008 (i.e. my Python.exe is linked against msvcrt10.dll while the extension modules are linked against msvcrt90.dll) Is there any way I can prevent this error from happening without having to recompile all the extension modules in my PythonXY distribution? The other solution would be to keep my original "Python.exe" file, but if I do that I get the following error message when I try to import the CLR module: In [1]: import clr ------------------------------------------------------------ Traceback (most recent call last): File "", line 1, in SystemError: dynamic module not initialized properly Is there any way around this? Cheers, --- ?ystein Skotheim Research Scientist, Optical Measurement Systems and Data Analysis SINTEF ICT, Trondheim, Norway From dave.hirschfeld at gmail.com Mon Jul 11 12:34:31 2011 From: dave.hirschfeld at gmail.com (Dave Hirschfeld) Date: Mon, 11 Jul 2011 10:34:31 +0000 (UTC) Subject: [Python.NET] =?utf-8?q?Replaced_Python=2Eexe_file_causes_problems?= =?utf-8?q?_for_extension=09modules?= References: <4E1AC944.1000905@edge.no> Message-ID: ?ystein Skotheim writes: > > Hello. I have managed to compile the SVN version of PythonDotNet against > the 4.0 version of the .NET library with Visual Studio 2010 on Windows > 7. I copied over clr.pyd, Python.Runtime.dll as well as new versions of > python.exe and pythonw.exe into my C:\Python26 directory. I am now able > to import .NET 4.0 modules after writing "import clr" > > However, I have run into a few problems because I had to replace my > Python executable. I am using a lot of packages from the PythonXY that > depend on c extension modules (.pyd-files). Whenever I try to import > such a module, I get the following error: > > Runtime Error! > > Program: C:\Python26\Python.exe > > > > The other solution would be to keep my original "Python.exe" file, but > if I do that I get the following error message when I try to import the > CLR module: > > In [1]: import clr > ------------------------------------------------------------ > Traceback (most recent call last): > File "", line 1, in > SystemError: dynamic module not initialized properly > > Is there any way around this? > > Cheers, > > --- > ?ystein Skotheim > Research Scientist, Optical Measurement Systems and Data Analysis > SINTEF ICT, Trondheim, Norway Sounds like you may have forgotten to edit your buildclrmodule.bat file to reference the .NET4 version of ilasm - see: http://permalink.gmane.org/gmane.comp.python.dotnet/970 I don't know that copying over the newly compiled python.exe will work (possibly for the reasons you state) however simply copying over the clr.pyd and Python.Runtime.dll to your C:\Python26 directory should work if you make the changes to the buildclrmodule.bat file. HTH, Dave From oystein+pythondotnet at edge.no Mon Jul 11 13:18:47 2011 From: oystein+pythondotnet at edge.no (=?UTF-8?B?w5h5c3RlaW4gU2tvdGhlaW0=?=) Date: Mon, 11 Jul 2011 13:18:47 +0200 Subject: [Python.NET] Replaced Python.exe file causes problems for extension modules In-Reply-To: References: <4E1AC944.1000905@edge.no> Message-ID: <4E1ADC17.4080703@edge.no> On 11.07.2011 12:34, Dave Hirschfeld wrote: >> The other solution would be to keep my original "Python.exe" file, but >> if I do that I get the following error message when I try to import the >> CLR module: >> >> In [1]: import clr >> ------------------------------------------------------------ >> Traceback (most recent call last): >> File "", line 1, in >> SystemError: dynamic module not initialized properly >> >> Is there any way around this? > Sounds like you may have forgotten to edit your buildclrmodule.bat file to > reference the .NET4 version of ilasm - see: > > http://permalink.gmane.org/gmane.comp.python.dotnet/970 > > I don't know that copying over the newly compiled python.exe will work (possibly > for the reasons you state) however simply copying over the clr.pyd and > Python.Runtime.dll to your C:\Python26 directory should work if you make the > changes to the buildclrmodule.bat file. Thanks a lot, Dave. After making the changes you suggested, it works to import the clr module with the original Python.exe file :-) Cheers, --- ?ystein Skotheim Research Scientist, Optical Measurement Systems and Data Analysis SINTEF ICT, Trondheim, Norway From craig_farrow at sil.org Mon Jul 4 08:39:58 2011 From: craig_farrow at sil.org (Craig Farrow) Date: Mon, 04 Jul 2011 14:39:58 +0800 Subject: [Python.NET] Major speed change old 2.5 -> latest 2.5 build Message-ID: <4E11603E.9080007@sil.org> Hi, I'm accessing a database through a .NET DLL and I noticed that the initial open/load function is taking 20 times as long in Python.NET 2.6 as it is in my Python.NET 2.5. When I went to check on what 2.5 version I was using I found a newer one on sourceforge; well using pythonnet-2.0-alpha2-clr2.0_py25.zip is giving the same slow speeds as the 2.6 & 2.7 versions I was trying. The 2.5 that is giving me fast times (0.8 - 1.2 seconds) versus (18-24 seconds) I got a few years ago in a package called 'pythonnet-2.0-alpha2.zip' that contained directories for 2.4 & 2.5, UCS2 & UCS4; the Python.Runtime.DLL is dated 6 Sep 2007. Any idea why the speed difference? And is it possible to get back to the fast version for 2.6 & 2.7? I'm running Windows 7, 32 bit. Thanks, Craig. From barton at bcdesignswell.com Sun Jul 17 20:47:20 2011 From: barton at bcdesignswell.com (Barton) Date: Sun, 17 Jul 2011 11:47:20 -0700 Subject: [Python.NET] Major speed change old 2.5 -> latest 2.5 build In-Reply-To: <4E11603E.9080007@sil.org> References: <4E11603E.9080007@sil.org> Message-ID: <4E232E38.5010200@bcdesignswell.com> Sounds like you are running in the interactive mode; ie opened python session interactively in a command prompt and typed import clr In which case; help(clr) # would yield: Help on module clr: NAME clr FILE (built-in) DATA AddReference = FindAssembly = ListAssemblies = getPreload = setPreload = The Preload flag is set to True in interactive mode. Its function is to load the entire namespace of the default assemblies into the interpreter's namespace (mostly for debugging). Please confirm that clr.setPreload(False) clears up your concern. Thank you -Barton On 07/03/2011 11:39 PM, Craig Farrow wrote: > Hi, > > I'm accessing a database through a .NET DLL and I noticed that the > initial open/load function is taking 20 times as long in Python.NET 2.6 > as it is in my Python.NET 2.5. > > When I went to check on what 2.5 version I was using I found a newer one > on sourceforge; well using pythonnet-2.0-alpha2-clr2.0_py25.zip is > giving the same slow speeds as the 2.6 & 2.7 versions I was trying. The > 2.5 that is giving me fast times (0.8 - 1.2 seconds) versus (18-24 > seconds) I got a few years ago in a package called > 'pythonnet-2.0-alpha2.zip' that contained directories for 2.4 & 2.5, > UCS2 & UCS4; the Python.Runtime.DLL is dated 6 Sep 2007. > > Any idea why the speed difference? And is it possible to get back to the > fast version for 2.6 & 2.7? > > I'm running Windows 7, 32 bit. > > Thanks, > > Craig. > > > _________________________________________________ > Python.NET mailing list - PythonDotNet at python.org > http://mail.python.org/mailman/listinfo/pythondotnet > From craig_farrow at sil.org Wed Jul 20 10:22:28 2011 From: craig_farrow at sil.org (Craig Farrow) Date: Wed, 20 Jul 2011 16:22:28 +0800 Subject: [Python.NET] Major speed change old 2.5 -> latest 2.5 build In-Reply-To: <4E232E38.5010200@bcdesignswell.com> References: <4E11603E.9080007@sil.org> <4E232E38.5010200@bcdesignswell.com> Message-ID: <4E269044.60407@sil.org> Barton, It is true that getPreload yields True in interactive mode and False in an application, however, that setting has no effect for me. In interactive mode with the old 2.5 whether Preload is set to True or False the db load time is just over 1 second. In the new 2.5 and 2.6 & 2.7 in both interactive mode and application mode the load time is between 14 and 18 seconds. Everything else is the same between runs; and I'm starting a fresh session for each test. Thanks for your help, Craig. 18/07/2011 2:47 a.m. d?, Barton pi?dimi?: > Sounds like you are running in the interactive mode; ie opened python > session interactively in a command prompt and typed > > import clr > > In which case; > > help(clr) # would yield: > > Help on module clr: > > NAME > clr > > FILE > (built-in) > > DATA > AddReference = > FindAssembly = > ListAssemblies = > getPreload = > setPreload = > > The Preload flag is set to True in interactive mode. Its function is > to load the entire namespace of the default assemblies into the > interpreter's namespace (mostly for debugging). > > Please confirm that > > clr.setPreload(False) > > clears up your concern. > > Thank you > -Barton > > On 07/03/2011 11:39 PM, Craig Farrow wrote: >> Hi, >> >> I'm accessing a database through a .NET DLL and I noticed that the >> initial open/load function is taking 20 times as long in Python.NET 2.6 >> as it is in my Python.NET 2.5. >> >> When I went to check on what 2.5 version I was using I found a newer one >> on sourceforge; well using pythonnet-2.0-alpha2-clr2.0_py25.zip is >> giving the same slow speeds as the 2.6 & 2.7 versions I was trying. The >> 2.5 that is giving me fast times (0.8 - 1.2 seconds) versus (18-24 >> seconds) I got a few years ago in a package called >> 'pythonnet-2.0-alpha2.zip' that contained directories for 2.4 & 2.5, >> UCS2 & UCS4; the Python.Runtime.DLL is dated 6 Sep 2007. >> >> Any idea why the speed difference? And is it possible to get back to the >> fast version for 2.6 & 2.7? >> >> I'm running Windows 7, 32 bit. >> >> Thanks, >> >> Craig. >> >> >> _________________________________________________ >> Python.NET mailing list - PythonDotNet at python.org >> http://mail.python.org/mailman/listinfo/pythondotnet >> > From bcline3078 at charter.net Sun Jul 31 00:40:37 2011 From: bcline3078 at charter.net (BCline) Date: Sat, 30 Jul 2011 15:40:37 -0700 Subject: [Python.NET] Fwd: Re: Major speed change old 2.5 -> latest 2.5 build Message-ID: <4E348865.9040706@charter.net> Still no reply to this one... -------- Original Message -------- Subject: Re: [Python.NET] Major speed change old 2.5 -> latest 2.5 build Date: Sun, 24 Jul 2011 13:06:33 -0700 From: Barton To: Craig Farrow Hi, Craig, Would you care to attach a test script to me directly with links to any non-standard dependancies? Thanks, Barton On 7/20/2011 1:22 AM, Craig Farrow wrote: > Barton, > > It is true that getPreload yields True in interactive mode and False > in an application, however, that setting has no effect for me. > > In interactive mode with the old 2.5 whether Preload is set to True or > False the db load time is just over 1 second. In the new 2.5 and 2.6& > 2.7 in both interactive mode and application mode the load time is > between 14 and 18 seconds. Everything else is the same between runs; > and I'm starting a fresh session for each test. > > Thanks for your help, > > Craig. > > 18/07/2011 2:47 a.m. d?, Barton pi?dimi?: >> Sounds like you are running in the interactive mode; ie opened python >> session interactively in a command prompt and typed >> >> import clr >> >> In which case; >> >> help(clr) # would yield: >> >> Help on module clr: >> >> NAME >> clr >> >> FILE >> (built-in) >> >> DATA >> AddReference = >> FindAssembly = >> ListAssemblies = >> getPreload = >> setPreload = >> >> The Preload flag is set to True in interactive mode. Its function is >> to load the entire namespace of the default assemblies into the >> interpreter's namespace (mostly for debugging). >> >> Please confirm that >> >> clr.setPreload(False) >> >> clears up your concern. >> >> Thank you >> -Barton >> >> On 07/03/2011 11:39 PM, Craig Farrow wrote: >>> Hi, >>> >>> I'm accessing a database through a .NET DLL and I noticed that the >>> initial open/load function is taking 20 times as long in Python.NET 2.6 >>> as it is in my Python.NET 2.5. >>> >>> When I went to check on what 2.5 version I was using I found a newer >>> one >>> on sourceforge; well using pythonnet-2.0-alpha2-clr2.0_py25.zip is >>> giving the same slow speeds as the 2.6& 2.7 versions I was trying. The >>> 2.5 that is giving me fast times (0.8 - 1.2 seconds) versus (18-24 >>> seconds) I got a few years ago in a package called >>> 'pythonnet-2.0-alpha2.zip' that contained directories for 2.4& 2.5, >>> UCS2& UCS4; the Python.Runtime.DLL is dated 6 Sep 2007. >>> >>> Any idea why the speed difference? And is it possible to get back to >>> the >>> fast version for 2.6& 2.7? >>> >>> I'm running Windows 7, 32 bit. >>> >>> Thanks, >>> >>> Craig. >>> >>> >>> _________________________________________________ >>> Python.NET mailing list - PythonDotNet at python.org >>> http://mail.python.org/mailman/listinfo/pythondotnet >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: