From paul at lumidium.com  Mon Oct  8 13:00:53 2007
From: paul at lumidium.com (Paul Harter)
Date: Mon, 8 Oct 2007 12:00:53 +0100
Subject: [Python.NET] python 2.5
Message-ID: <f11fdacd0710080400n4850a273wb8c8da5011ffc2eb@mail.gmail.com>

Hi,

We are tring to move to python 2.5. and are having trouble getting
pythonDotNet to import using the pre-built binaries. When we use the
python.exe which is part of the pre-built binaries "import clr" can
execute without a problem. However trying to use an existing
python.exe (e.g. the standard installed one, but we also need to use
it embedded) we always get the following error:

ImportError: dynamic module does not define init function (initclr)

What magic does the included python.exe perform, or what are we doing
wrong in our installation.

We have tried:

 * copying Python.runtime.dll and clr.pyd to the python install path
(where python.exe lives), or both to the DLLs directory, or clr.pyd to
the site-packages directory and Python.runtime.dll to one of the above
locations.
 * We've also tried having them in a separate directory, and running
python.exe from that directory.

(The readme is not very explanatory on how to modify an existing
python installation).

thanks for your help

Paul & Tim

From hsu.feihong at yahoo.com  Mon Oct  8 18:42:34 2007
From: hsu.feihong at yahoo.com (Feihong Hsu)
Date: Mon, 8 Oct 2007 09:42:34 -0700 (PDT)
Subject: [Python.NET] python 2.5
In-Reply-To: <f11fdacd0710080400n4850a273wb8c8da5011ffc2eb@mail.gmail.com>
Message-ID: <352533.99912.qm@web34808.mail.mud.yahoo.com>

Hi, I ran into exactly the same problem as you but I did manage to solve it by recompiling the entire project in visual c# express. Unfortunately, I don't recall exactly what I did and I don't have my laptop handy right now, but I can find out later. 
 
 In the meantime, you can try the recompile, and, to modify an existing installation, copy the .pyd file to C:\Python25\DLLs\ and the .dll file to C:\Python25\. Then it should "just work".
 
Cheers,

Feihong

Paul Harter <paul at lumidium.com> wrote: Hi,

We are tring to move to python 2.5. and are having trouble getting
pythonDotNet to import using the pre-built binaries. When we use the
python.exe which is part of the pre-built binaries "import clr" can
execute without a problem. However trying to use an existing
python.exe (e.g. the standard installed one, but we also need to use
it embedded) we always get the following error:

ImportError: dynamic module does not define init function (initclr)

What magic does the included python.exe perform, or what are we doing
wrong in our installation.

We have tried:

 * copying Python.runtime.dll and clr.pyd to the python install path
(where python.exe lives), or both to the DLLs directory, or clr.pyd to
the site-packages directory and Python.runtime.dll to one of the above
locations.
 * We've also tried having them in a separate directory, and running
python.exe from that directory.

(The readme is not very explanatory on how to modify an existing
python installation).

thanks for your help

Paul & Tim
_________________________________________________
Python.NET mailing list - PythonDotNet at python.org
http://mail.python.org/mailman/listinfo/pythondotnet


       
---------------------------------
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythondotnet/attachments/20071008/1c260a7b/attachment.htm 

From mkozyarchuk at funddevelopmentservices.com  Tue Oct  9 04:50:02 2007
From: mkozyarchuk at funddevelopmentservices.com (Maksim Kozyarchuk)
Date: Mon, 8 Oct 2007 22:50:02 -0400
Subject: [Python.NET] python 2.5
In-Reply-To: <352533.99912.qm@web34808.mail.mud.yahoo.com>
Message-ID: <8674D71026D5C848831DB7CA34B1C758E9134B@fds1wmail01.funddevelopmentservices.com>

 

I've had a similar experience.  Out of the box binaries don't work
unless included python.exe is used.  A simple recompile of the code
using VS C# express solved this.

 

Also, attached is a slightly modified version of clrmodule.il that
allows you to load clr.pyd and Python.Runtime.dll from any directory( as
long as it's in pythonpath) 

 


Maksim

 

________________________________

From: pythondotnet-bounces at python.org
[mailto:pythondotnet-bounces at python.org] On Behalf Of Feihong Hsu
Sent: Monday, October 08, 2007 12:43 PM
To: Paul Harter; pythondotnet at python.org
Cc: tim at red56.co.uk
Subject: Re: [Python.NET] python 2.5

 

Hi, I ran into exactly the same problem as you but I did manage to solve
it by recompiling the entire project in visual c# express.
Unfortunately, I don't recall exactly what I did and I don't have my
laptop handy right now, but I can find out later. 

In the meantime, you can try the recompile, and, to modify an existing
installation, copy the .pyd file to C:\Python25\DLLs\ and the .dll file
to C:\Python25\. Then it should "just work".

Cheers,

Feihong

Paul Harter <paul at lumidium.com> wrote:

Hi,

We are tring to move to python 2.5. and are having trouble getting
pythonDotNet to import using the pre-built binaries. When we use the
python.exe which is part of the pre-built binaries "import clr" can
execute without a problem. However trying to use an existing
python.exe (e.g. the standard installed one, but we also need to use
it embedded) we always get the following error:

ImportError: dynamic module does not define init function (initclr)

What magic does the included python.exe perform, or what are we doing
wrong in our installation.

We have tried:

* copying Python.runtime.dll and clr.pyd to the python install path
(where python.exe lives), or both to the DLLs directory, or clr.pyd to
the site-packages directory and Python.runtime.dll to one of the above
locations.
* We've also tried having them in a separate directory, and running
python.exe from that directory.

(The readme is not very explanatory on how to modify an existing
python installation).

thanks for your help

Paul & Tim
_________________________________________________
Python.NET mailing list - PythonDotNet at python.org
http://mail.python.org/mailman/listinfo/pythondotnet

 

  

________________________________

Take the Internet to Go: Yahoo!Go puts the Internet in your pocket:
<http://us.rd.yahoo.com/evt=48253/*http:/mobile.yahoo.com/go?refer=1GNXI
C>  mail, news, photos & more. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythondotnet/attachments/20071008/0dd9a680/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clrmodule.il
Type: application/octet-stream
Size: 5544 bytes
Desc: clrmodule.il
Url : http://mail.python.org/pipermail/pythondotnet/attachments/20071008/0dd9a680/attachment.obj 

From paul at lumidium.com  Tue Oct  9 12:58:42 2007
From: paul at lumidium.com (Paul Harter)
Date: Tue, 9 Oct 2007 11:58:42 +0100
Subject: [Python.NET] python 2.5
In-Reply-To: <8674D71026D5C848831DB7CA34B1C758E9134B@fds1wmail01.funddevelopmentservices.com>
References: <352533.99912.qm@web34808.mail.mud.yahoo.com>
	<8674D71026D5C848831DB7CA34B1C758E9134B@fds1wmail01.funddevelopmentservices.com>
Message-ID: <f11fdacd0710090358t3b9194a3p9aa00cf4b3ebce51@mail.gmail.com>

Thanks for your help. It imports fine now.

I will try out the clrmodule.il - that will be v useful.

Paul

From lists at cheimes.de  Tue Oct 16 16:53:06 2007
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 16 Oct 2007 16:53:06 +0200
Subject: [Python.NET] python 2.5
In-Reply-To: <f11fdacd0710080400n4850a273wb8c8da5011ffc2eb@mail.gmail.com>
References: <f11fdacd0710080400n4850a273wb8c8da5011ffc2eb@mail.gmail.com>
Message-ID: <4714D052.2000002@cheimes.de>

Paul Harter wrote:
> Hi,
> 
> We are tring to move to python 2.5. and are having trouble getting
> pythonDotNet to import using the pre-built binaries. When we use the
> python.exe which is part of the pre-built binaries "import clr" can
> execute without a problem. However trying to use an existing
> python.exe (e.g. the standard installed one, but we also need to use
> it embedded) we always get the following error:
> 
> ImportError: dynamic module does not define init function (initclr)
> 
> What magic does the included python.exe perform, or what are we doing
> wrong in our installation.

(Resending because gmane didn't send this msg)

Oh, that's probably a bug in Mono. I haven't had a chance to test the
pre-built package on Windows to its full extend. I used Mono to compile
the assemblies and binaries. Python.exe and the assemblies worked
like a charm on Windows but I forgot to see if clr.pyd works, too

I'm going to investigate the problem and send a bug report to the mono
developers. Can anybody please send me a Windows binary of clr.pyd?

About embedding:
Could you please release some sample code how to embed Python.NET and
Python 2.x on Windows? I've just some C code for Mono.

Christian

From lists at cheimes.de  Tue Oct 16 19:03:57 2007
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 16 Oct 2007 19:03:57 +0200
Subject: [Python.NET] python 2.5
In-Reply-To: <f11fdacd0710160920q3190fbc7md372a86e18c05dc6@mail.gmail.com>
References: <f11fdacd0710080400n4850a273wb8c8da5011ffc2eb@mail.gmail.com>	
	<4714D052.2000002@cheimes.de>
	<f11fdacd0710160920q3190fbc7md372a86e18c05dc6@mail.gmail.com>
Message-ID: <4714EEFD.4020104@cheimes.de>

Paul Harter wrote:
> To use python.net with it is fine as long as the initial import of clr
> takes place early on in the main thread. Otherwise it doesn't work on
> multi-processor machines. I don't know why.

import clr should always be the first thing you do in an app. "import
clr" loads and initializes the Python.Runtime assembly. During the
initialization Python's __import__ hook is replaced with a custom hook
for the CLR import magic. You can get in all kinds of trouble if you
replace __import__ in a thread while another threads tries to import an
assembly. Our you can suffer from an import dead lock. It's a race
condition.

In an embedded .NET or C/C++ app you shouldn't use clr. It's better to
import the Python.Runtime assembly and call its PythonEngine::InitExt()
static method. The sample implementation in
https://pythonnet.svn.sourceforge.net/svnroot/pythonnet/trunk/pythonnet/src/monoclr/pynetinit.c
contains a working example and some helpful notes from me. I run into a
problem with threads, too.

Christian

From sanxiyn at gmail.com  Wed Oct 17 13:52:33 2007
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Wed, 17 Oct 2007 20:52:33 +0900
Subject: [Python.NET] DllMap on Mono
Message-ID: <5b0248170710170452m2b14b218h48ea88f2fb07f237@mail.gmail.com>

http://pythonnet.sourceforge.net/readme.html says:
Note that if you are running under Mono on a *nix system, you will
need to have a compatible version of Python installed. You will also
need to create a symbolic link to the copy of libpython2.x.so (in your
existing Python installation) in the PythonNet directory. This is
needed to ensure that the mono interop dll loader will find it by
name. For example:
ln -s /usr/lib/libpython2.4.so ./python24.so

Which works fine, But the "official" way to do this is to use a Mono
feature called DllMap, which is documented here:
http://www.mono-project.com/Config_DllMap

In practice, this means you create a file named
python.runtime.dll.config, with content:
<configuration>
  <dllmap dll="python24" target="libpython2.4.so.1" os="!windows"/>
</configuration>

-- 
Seo Sanghyeon

From lists at cheimes.de  Wed Oct 17 14:15:01 2007
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 17 Oct 2007 14:15:01 +0200
Subject: [Python.NET] DllMap on Mono
In-Reply-To: <5b0248170710170452m2b14b218h48ea88f2fb07f237@mail.gmail.com>
References: <5b0248170710170452m2b14b218h48ea88f2fb07f237@mail.gmail.com>
Message-ID: <4715FCC5.4060400@cheimes.de>

Sanghyeon Seo wrote:
> http://pythonnet.sourceforge.net/readme.html says:
> Note that if you are running under Mono on a *nix system, you will
> need to have a compatible version of Python installed. You will also
> need to create a symbolic link to the copy of libpython2.x.so (in your
> existing Python installation) in the PythonNet directory. This is
> needed to ensure that the mono interop dll loader will find it by
> name. For example:
> ln -s /usr/lib/libpython2.4.so ./python24.so
> 
> Which works fine, But the "official" way to do this is to use a Mono
> feature called DllMap, which is documented here:
> http://www.mono-project.com/Config_DllMap
> 
> In practice, this means you create a file named
> python.runtime.dll.config, with content:
> <configuration>
>   <dllmap dll="python24" target="libpython2.4.so.1" os="!windows"/>
> </configuration>

The documentation at http://pythonnet.sourceforge.net/readme.html is
outdated. The latest version of the readme and the latest source tree
contain a sample of a config file.

I didn't know about the possibility to define a
Python.Runtime.dll.config file. I though one has to edit either the
global config file or ~/.mono/config. I'm going to test it later and add
it to the sources if it works.

Christian

From sanxiyn at gmail.com  Thu Oct 18 06:15:16 2007
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Thu, 18 Oct 2007 13:15:16 +0900
Subject: [Python.NET] UCS2/UCS4 detection
Message-ID: <5b0248170710172115oaeb98b0v38c58795dfff4e69@mail.gmail.com>

UCS2/UCS4 detection in Makefile doesn't seem to work here.

tinuviel at debian:~/svn/pythonnet$ python -c 'import sys; print sys.maxunicode'
1114111

tinuviel at debian:~/svn/pythonnet$ make Python.Runtime.dll
cd "/home/tinuviel/svn/pythonnet/src/runtime"; \
        gmcs /define:PYTHON24,UCS2 /nologo  /unsafe /target:library \
             /out:../../Python.Runtime.dll /recurse:*.cs

Makefile uses distutils.sysconfig, but why not just check sys.maxunicode?

-- 
Seo Sanghyeon

From lists at cheimes.de  Thu Oct 18 13:26:48 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 18 Oct 2007 13:26:48 +0200
Subject: [Python.NET] UCS2/UCS4 detection
In-Reply-To: <5b0248170710172115oaeb98b0v38c58795dfff4e69@mail.gmail.com>
References: <5b0248170710172115oaeb98b0v38c58795dfff4e69@mail.gmail.com>
Message-ID: <471742F8.4090903@cheimes.de>

Sanghyeon Seo wrote:
> UCS2/UCS4 detection in Makefile doesn't seem to work here.
> 
> tinuviel at debian:~/svn/pythonnet$ python -c 'import sys; print sys.maxunicode'
> 1114111
> 
> tinuviel at debian:~/svn/pythonnet$ make Python.Runtime.dll
> cd "/home/tinuviel/svn/pythonnet/src/runtime"; \
>         gmcs /define:PYTHON24,UCS2 /nologo  /unsafe /target:library \
>              /out:../../Python.Runtime.dll /recurse:*.cs
> 
> Makefile uses distutils.sysconfig, but why not just check sys.maxunicode?

What's your full Python version, OS, distribution and the output of

$ python -c "from distutils.sysconfig import get_config_var; print
get_config_var('Py_UNICODE_SIZE')"

? It looks like Python 2.4.x and a Debian GNU/Linux distribution.

I'm using get_config_var() because it's the obvious choice. It's using
the information from pyconfig.h. It's also easier to understand and less
error prone than "(sys.maxunicode > 2<<15) and 4 or 2". I usually tend
to use the public API instead of reinventing the wheel.

Christian

From sanxiyn at gmail.com  Thu Oct 18 14:07:22 2007
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Thu, 18 Oct 2007 21:07:22 +0900
Subject: [Python.NET] UCS2/UCS4 detection
In-Reply-To: <47174284.70308@cheimes.de>
References: <5b0248170710172115oaeb98b0v38c58795dfff4e69@mail.gmail.com>
	<47174284.70308@cheimes.de>
Message-ID: <5b0248170710180507j717d17b3i2ab68e37720143dd@mail.gmail.com>

Sanghyeon Seo wrote:
> UCS2/UCS4 detection in Makefile doesn't seem to work here.

2007/10/18, Christian Heimes <christian at cheimes.de>:
> What's your full Python version, OS, distribution and the output of
>
> $ python -c "from distutils.sysconfig import get_config_var; print
> get_config_var('Py_UNICODE_SIZE')"

Debian GNU/Linux, Python package 2.4.4-6.

get_config_var() returns None. The same expression returns 4 for Python 2.5

> I'm using get_config_var() because it's the obvious choice. It's using
> the information from pyconfig.h.

Is it? The strange thing is, parse_config_h() isn't called anywhere in
this file:
http://svn.python.org/projects/python/tags/r244/Lib/distutils/sysconfig.py

Compare with:
http://svn.python.org/projects/python/tags/r251/Lib/distutils/sysconfig.py

-- 
Seo Sanghyeon

From lists at cheimes.de  Thu Oct 18 14:16:55 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 18 Oct 2007 14:16:55 +0200
Subject: [Python.NET] UCS2/UCS4 detection
In-Reply-To: <5b0248170710180507j717d17b3i2ab68e37720143dd@mail.gmail.com>
References: <5b0248170710172115oaeb98b0v38c58795dfff4e69@mail.gmail.com>	<47174284.70308@cheimes.de>
	<5b0248170710180507j717d17b3i2ab68e37720143dd@mail.gmail.com>
Message-ID: <47174EB7.1010400@cheimes.de>

Sanghyeon Seo wrote:
> Debian GNU/Linux, Python package 2.4.4-6.
> 
> get_config_var() returns None. The same expression returns 4 for Python 2.5
> 
>> I'm using get_config_var() because it's the obvious choice. It's using
>> the information from pyconfig.h.
> 
> Is it? The strange thing is, parse_config_h() isn't called anywhere in
> this file:
> http://svn.python.org/projects/python/tags/r244/Lib/distutils/sysconfig.py
> 
> Compare with:
> http://svn.python.org/projects/python/tags/r251/Lib/distutils/sysconfig.py


I'm going to investigate the problem later. It looks like you have found
a problem with Python 2.4.

Thx

Christian

From matthew.zaleski at spamcop.net  Thu Oct 18 21:07:43 2007
From: matthew.zaleski at spamcop.net (Matthew Zaleski)
Date: Thu, 18 Oct 2007 15:07:43 -0400
Subject: [Python.NET] list archives in MBOX format?
Message-ID: <20071018150743.t6ysddbmcko4gs08@webmail.spamcop.net>

I'm brand new to Python for .NET and this list.  I was wondering if  
anyone has the list archives in MBOX format.  The online archives are  
gzipped text and not MBOX files as far as I can tell.

Kudos to the developers for developing this tool.  I thought I was  
hosed and wouldn't be able to interface from CPython to .NET managed  
code easily (IronPython isn't a good option for me).


From lists at cheimes.de  Thu Oct 18 21:26:02 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 18 Oct 2007 21:26:02 +0200
Subject: [Python.NET] list archives in MBOX format?
In-Reply-To: <20071018150743.t6ysddbmcko4gs08@webmail.spamcop.net>
References: <20071018150743.t6ysddbmcko4gs08@webmail.spamcop.net>
Message-ID: <4717B34A.8050502@cheimes.de>

Matthew Zaleski wrote:
> I'm brand new to Python for .NET and this list.  I was wondering if  
> anyone has the list archives in MBOX format.  The online archives are  
> gzipped text and not MBOX files as far as I can tell.
> 
> Kudos to the developers for developing this tool.  I thought I was  
> hosed and wouldn't be able to interface from CPython to .NET managed  
> code easily (IronPython isn't a good option for me).

Do you know http://gmane.org/? It's a great interface to thousands of
mailing lists. Gmane acts as a mail to news and news to mail gateway.
I'm using it for almost all my mailing lists.

Christian

From matthew.zaleski at spamcop.net  Thu Oct 18 22:20:12 2007
From: matthew.zaleski at spamcop.net (Matthew Zaleski)
Date: Thu, 18 Oct 2007 16:20:12 -0400
Subject: [Python.NET] list archives in MBOX format?
In-Reply-To: <4717B34A.8050502@cheimes.de>
References: <20071018150743.t6ysddbmcko4gs08@webmail.spamcop.net>
	<4717B34A.8050502@cheimes.de>
Message-ID: <20071018162012.7q042mi59cggkko4@webmail.spamcop.net>

Christian Heimes wrote:
> Matthew Zaleski wrote:
>> I'm brand new to Python for .NET and this list.  I was wondering if
>> anyone has the list archives in MBOX format.  The online archives are
>> gzipped text and not MBOX files as far as I can tell.
>>
>> Kudos to the developers for developing this tool.  I thought I was
>> hosed and wouldn't be able to interface from CPython to .NET managed
>> code easily (IronPython isn't a good option for me).
>
> Do you know http://gmane.org/? It's a great interface to thousands of
> mailing lists. Gmane acts as a mail to news and news to mail gateway.
> I'm using it for almost all my mailing lists.
>
> Christian
>

gmane isn't my cup of tea for actively reading and replying.  But I  
see that gmane lets me grab the MBOX archive.  Thanks.

I am a bit confused though.  If gmane is the preferred place, why does  
the Python.NET readme send me to the other archives page?

From djlawler at aol.com  Fri Oct 19 05:14:41 2007
From: djlawler at aol.com (david lawler)
Date: Fri, 19 Oct 2007 03:14:41 +0000 (UTC)
Subject: [Python.NET] problem with inheritance?  ironpython ok,
	python.net - different
Message-ID: <loom.20071019T030200-726@post.gmane.org>

To run this script you need to get Weifen Luo's Dock Panel Suite from Source
forge - just get the pre-compiled dll at
http://sourceforge.net/project/showfiles.php?group_id=110642 and stick it in the
same directory as the script.

-----------------------------------------beginning of script

import clr

clr.AddReference('System.Windows.Forms')
clr.AddReference('System.Drawing')
clr.AddReference('WeifenLuo.WinFormsUI.Docking')

import System.Windows.Forms as Winforms
import WeifenLuo.WinFormsUI as DockSuite
from System.Drawing import (Font, Point, FontStyle, GraphicsUnit)

class EditForm(DockSuite.Docking.DockContent):

    def __init__(self):

        self.Text = "EditForm"
        self.console = Winforms.TextBox()
        self.console.Location = Point(0,0)
        self.console.Enabled = True
        self.console.Name = "EditForm console"
        self.console.Multiline = True
        self.console.WordWrap = True
        self.console.ScrollBars = Winforms.ScrollBars.Both
        self.console.Font = Font("Courier New", 10, FontStyle.Bold,
GraphicsUnit.Point, 0)
        self.console.Dock = Winforms.DockStyle.Fill
        self.Controls.Add(self.console)
        
    def OnClosing(self, ev):
        
        pass
             
class ExecuteForm(Winforms.Form):

    def __init__(self):

        self.IsMdiContainer = True
        self.DockMain = DockSuite.Docking.DockPanel()
        self.DockMain.Dock = Winforms.DockStyle.Fill
        self.Controls.Add(self.DockMain)
        self.eform = EditForm()
        self.eform.ShowHint = DockSuite.Docking.DockState.DockBottomAutoHide
        self.eform.Show(self.DockMain, DockSuite.Docking.DockState.Document)

        # Create the menu
        mainMenu1 = Winforms.MainMenu()

        editMenu = Winforms.MenuItem()
        editMenu.Text = "Edit"
        menuItemTest = Winforms.MenuItem()
        menuItemTest.Text = "Test"
        menuItemTest.Click += self.TestMenuHandler
        editMenu.MenuItems.Add(menuItemTest)

        mainMenu1.MenuItems.Add(editMenu)
        self.Menu = mainMenu1
        
    def TestMenuHandler(self, source, ev):
    
        print type(self.DockMain.ActiveContent)

form = ExecuteForm()
Winforms.Application.Run(form)

-------------------------------------------- end of script

The script runs under both IronPython and Python.net which is very cool - but
there is a different result when you select Edit - Test from the menu.  For
IronPython it prints:

<class '__main__.EditForm'>
 
for python.net you get:

<class 'WeifenLuo.WinFormsUI.Docking.DockContent'>

It seems that python.net is printing the base class rather than the class
defined in the script.  Is this a bug or am I being stupid?

Regards,

David


From lists at cheimes.de  Fri Oct 19 13:45:00 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 19 Oct 2007 13:45:00 +0200
Subject: [Python.NET] python 2.5
In-Reply-To: <f11fdacd0710080400n4850a273wb8c8da5011ffc2eb@mail.gmail.com>
References: <f11fdacd0710080400n4850a273wb8c8da5011ffc2eb@mail.gmail.com>
Message-ID: <471898BC.90900@cheimes.de>

Paul Harter wrote:
> Hi,
> 
> We are tring to move to python 2.5. and are having trouble getting
> pythonDotNet to import using the pre-built binaries. When we use the
> python.exe which is part of the pre-built binaries "import clr" can
> execute without a problem. However trying to use an existing
> python.exe (e.g. the standard installed one, but we also need to use
> it embedded) we always get the following error:
> 
> ImportError: dynamic module does not define init function (initclr)
> 
> What magic does the included python.exe perform, or what are we doing
> wrong in our installation.

I got a reply to my bug report:

https://bugzilla.novell.com/show_bug.cgi?id=334544#c4

--- Comment #4 from Paolo Molaro <lupus at novell.com>  2007-10-19 00:40:09
MST ---
ilasm doesn't support unmanaged exports, that is exporting managed
methods as unmanaged functions in a dll. This would be only useful on
windows as other systems don't use PE files for shared libraries, so
unless someone contributes the code this feature has no meaning in the
mono context.


Christian




From lists at cheimes.de  Fri Oct 19 14:23:06 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 19 Oct 2007 14:23:06 +0200
Subject: [Python.NET] problem with inheritance?  ironpython ok,
 python.net - different
In-Reply-To: <loom.20071019T030200-726@post.gmane.org>
References: <loom.20071019T030200-726@post.gmane.org>
Message-ID: <4718A1AA.5090604@cheimes.de>

david lawler wrote:
> To run this script you need to get Weifen Luo's Dock Panel Suite from Source
> forge - just get the pre-compiled dll at
> http://sourceforge.net/project/showfiles.php?group_id=110642 and stick it in the
> same directory as the script.

I'm unable to run DockSample.exe and your Python example:

With mono 1.2.5.2 from svn

Unhandled Exception: System.EntryPointNotFoundException: GetCurrentThreadId
  at (wrapper managed-to-native)
WeifenLuo.WinFormsUI.Docking.NativeMethods:GetCurrentThreadId ()
  at
WeifenLuo.WinFormsUI.Docking.DockPanel+FocusManagerImpl+LocalWindowsHook.Install
() [0x00000]
  at WeifenLuo.WinFormsUI.Docking.DockPanel+FocusManagerImpl..ctor
(WeifenLuo.WinFormsUI.Docking.DockPanel dockPanel) [0x00000]
  at (wrapper remoting-invoke-with-check) FocusManagerImpl:.ctor
(WeifenLuo.WinFormsUI.Docking.DockPanel)
  at WeifenLuo.WinFormsUI.Docking.DockPanel..ctor () [0x00000]
  at (wrapper remoting-invoke-with-check)
WeifenLuo.WinFormsUI.Docking.DockPanel:.ctor ()
  at DockSample.MainForm.InitializeComponent () [0x00000]
  at DockSample.MainForm..ctor () [0x00000]
  at (wrapper remoting-invoke-with-check) DockSample.MainForm:.ctor ()
  at DockSample.Program.Main () [0x00000]

With mono 1.2.4 (Ubuntu 7.04)

** (DockSample.exe:16336): WARNING **: Missing method
System.Windows.Forms.Form::set_RightToLeftLayout(bool) in assembly
/usr/lib/mono/gac/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll,
referenced in assembly
/home/heimes/dev/mono/dockpanel/Release/DockSample.exe

Unhandled Exception: System.MissingMethodException: Method not found:
'System.Windows.Forms.Form.set_RightToLeftLayout'.
  at <0x00000> <unknown method>
  at (wrapper remoting-invoke-with-check) DockSample.MainForm:.ctor ()
  at DockSample.Program.Main () [0x00000]

Christian

From djlawler at aol.com  Fri Oct 19 15:04:29 2007
From: djlawler at aol.com (david lawler)
Date: Fri, 19 Oct 2007 13:04:29 +0000 (UTC)
Subject: [Python.NET] problem with inheritance?  ironpython ok,
	python.net - different
References: <loom.20071019T030200-726@post.gmane.org>
	<4718A1AA.5090604@cheimes.de>
Message-ID: <loom.20071019T125010-741@post.gmane.org>

Christian Heimes <lists at ...> writes:

> 
> david lawler wrote:
> > To run this script you need to get Weifen Luo's Dock Panel Suite from Source
> > forge - just get the pre-compiled dll at
> > http://sourceforge.net/project/showfiles.php?group_id=110642 and stick it in the
> > same directory as the script.
> 
> I'm unable to run DockSample.exe and your Python example:
> ....
> Christian
> _________________________________________________
> Python.NET mailing list - PythonDotNet at ...
> http://mail.python.org/mailman/listinfo/pythondotnet
> 
> 

Ah yes - sorry - this is running on a Windows box.
DockSuite has issues on Mono
- it makes p/invoke calls into user32 in some places, see this post:
http://osdir.com/ml/gnome.winforms/2006-11/msg00019.html
Do you (or any other developer) have a way to look at this on windows?

Regards,

David



From lists at cheimes.de  Fri Oct 19 15:10:43 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 19 Oct 2007 15:10:43 +0200
Subject: [Python.NET] problem with inheritance?  ironpython ok,
 python.net - different
In-Reply-To: <loom.20071019T125010-741@post.gmane.org>
References: <loom.20071019T030200-726@post.gmane.org>	<4718A1AA.5090604@cheimes.de>
	<loom.20071019T125010-741@post.gmane.org>
Message-ID: <4718ACD3.1050402@cheimes.de>

david lawler wrote:
> Ah yes - sorry - this is running on a Windows box.
> DockSuite has issues on Mono
> - it makes p/invoke calls into user32 in some places, see this post:
> http://osdir.com/ml/gnome.winforms/2006-11/msg00019.html
> Do you (or any other developer) have a way to look at this on windows?

I really don't know when I can access a working Windows box with .NET
and VS 2005. My Windows box has a hardware problem and I don't have time
and money to fix the box until next month.

Brian seems to be very busy, too. I haven't heard from him for quite a
while.

Christian

From christian at cheimes.de  Thu Oct 18 22:45:09 2007
From: christian at cheimes.de (Christian Heimes)
Date: Thu, 18 Oct 2007 22:45:09 +0200
Subject: [Python.NET] list archives in MBOX format?
In-Reply-To: <20071018162012.7q042mi59cggkko4@webmail.spamcop.net>
References: <20071018150743.t6ysddbmcko4gs08@webmail.spamcop.net>	<4717B34A.8050502@cheimes.de>
	<20071018162012.7q042mi59cggkko4@webmail.spamcop.net>
Message-ID: <4717C5D5.4020306@cheimes.de>

Matthew Zaleski wrote:
> I am a bit confused though.  If gmane is the preferred place, why does  
> the Python.NET readme send me to the other archives page?

It's *my* favorite place. :)

The readme sends you to the official mailing list manager and archive.

Christian

From brian.lloyd at revolutionhealth.com  Fri Oct 19 18:54:51 2007
From: brian.lloyd at revolutionhealth.com (Brian Lloyd)
Date: Fri, 19 Oct 2007 12:54:51 -0400
Subject: [Python.NET] problem with inheritance? ironpython ok,
 python.net - different
In-Reply-To: <4718ACD3.1050402@cheimes.de>
Message-ID: <C33E599B.1051F%brian.lloyd@revolutionhealth.com>

> I really don't know when I can access a working Windows box with .NET
> and VS 2005. My Windows box has a hardware problem and I don't have time
> and money to fix the box until next month.
> 
> Brian seems to be very busy, too. I haven't heard from him for quite a
> while.

...but I'm still alive ;)

On the original question here - David, you've basically run into the edge
of the integration between python and .net here.

The object that gets passed to your event handler by the CLR will always
be the of actual .net class, not the python subclass. This is because
the python subclass is not a real CLR class (it is only visible in Python),
which is not the case in IronPython (python classes are bona fide CLR
classes).

Technically it would be possible to have the integration machinery track
'wrapped' instances so that a transition from Python -> CLR -> Python would
lookup and pass the wrapped instance, but that's not there today (and I'm
not sure what effect that would have on perf and memory usage).

If there's no way around it, you could implement a poor man's version of
this in your app using GCHandle to map back and forth between managed
objects and the wrapped Python instances -- but its usually easier to
find some other way around the problem ;)

hope this helps,


--------------------------
Brian Lloyd

brian.lloyd at revolutionhealth.com



From brian.lloyd at revolutionhealth.com  Fri Oct 19 20:03:51 2007
From: brian.lloyd at revolutionhealth.com (Brian Lloyd)
Date: Fri, 19 Oct 2007 14:03:51 -0400
Subject: [Python.NET] python 2.5
In-Reply-To: <471898BC.90900@cheimes.de>
Message-ID: <C33E69C7.10547%brian.lloyd@revolutionhealth.com>

y, this is known as windows-only. for mono we'd probably have to do
a regular python C extension that uses the mono hosting apis to
bootstrap the runtime.

-Brian


On 10/19/07 7:45 AM, "Christian Heimes" <lists at cheimes.de> wrote:

> Paul Harter wrote:
>> Hi,
>> 
>> We are tring to move to python 2.5. and are having trouble getting
>> pythonDotNet to import using the pre-built binaries. When we use the
>> python.exe which is part of the pre-built binaries "import clr" can
>> execute without a problem. However trying to use an existing
>> python.exe (e.g. the standard installed one, but we also need to use
>> it embedded) we always get the following error:
>> 
>> ImportError: dynamic module does not define init function (initclr)
>> 
>> What magic does the included python.exe perform, or what are we doing
>> wrong in our installation.
> 
> I got a reply to my bug report:
> 
> https://bugzilla.novell.com/show_bug.cgi?id=334544#c4
> 
> --- Comment #4 from Paolo Molaro <lupus at novell.com>  2007-10-19 00:40:09
> MST ---
> ilasm doesn't support unmanaged exports, that is exporting managed
> methods as unmanaged functions in a dll. This would be only useful on
> windows as other systems don't use PE files for shared libraries, so
> unless someone contributes the code this feature has no meaning in the
> mono context.
> 
> 
> Christian
> 
> 
> 
> _________________________________________________
> Python.NET mailing list - PythonDotNet at python.org
> http://mail.python.org/mailman/listinfo/pythondotnet

--------------------------
Brian Lloyd

brian.lloyd at revolutionhealth.com



From djlawler at aol.com  Fri Oct 19 21:21:24 2007
From: djlawler at aol.com (david lawler)
Date: Fri, 19 Oct 2007 19:21:24 +0000 (UTC)
Subject: [Python.NET] problem with inheritance? ironpython ok,
	python.net - different
References: <4718ACD3.1050402@cheimes.de>
	<C33E599B.1051F%brian.lloyd@revolutionhealth.com>
Message-ID: <loom.20071019T190221-831@post.gmane.org>

Brian Lloyd <brian.lloyd at ...> writes:

> ...but I'm still alive ;)
> 
> On the original question here - David, you've basically run into the edge
> of the integration between python and .net here.
> 
> The object that gets passed to your event handler by the CLR will always
> be the of actual .net class, not the python subclass. This is because
> the python subclass is not a real CLR class (it is only visible in Python),
> which is not the case in IronPython (python classes are bona fide CLR
> classes)......
> 

That does indeed help.  Strangely I think I even follow your points :).
I will see if there is another way that will work with both python.net and
IronPython.  The other issue I have started to look at is getting to the
GUI thread (and the controls in the main form), from other threads.  In
IronPython there is some odd 'CallTarget0' stuff to allow you to Invoke/access
data across threads.  Is there something like that in Python.net?  This is
not of vital importance - just curiosity.  I was working on a half *ssed 
IronPython 'IDE' written in IronPython and was shocked to see that the
application actually ran under Python.net but then ran into the issue I
described in the previous post as well as this other issue.  It will not be
a big deal if it does not work.

Thanks for the quick and understandable reply!

David 


From brian.lloyd at revolutionhealth.com  Fri Oct 19 21:55:12 2007
From: brian.lloyd at revolutionhealth.com (Brian Lloyd)
Date: Fri, 19 Oct 2007 15:55:12 -0400
Subject: [Python.NET] problem with inheritance? ironpython ok,
 python.net - different
In-Reply-To: <loom.20071019T190221-831@post.gmane.org>
Message-ID: <C33E83E0.1058D%brian.lloyd@revolutionhealth.com>


> That does indeed help.  Strangely I think I even follow your points :).
> I will see if there is another way that will work with both python.net and
> IronPython.  The other issue I have started to look at is getting to the
> GUI thread (and the controls in the main form), from other threads.  In
> IronPython there is some odd 'CallTarget0' stuff to allow you to Invoke/access
> data across threads.  Is there something like that in Python.net?  This is
> not of vital importance - just curiosity.  I was working on a half *ssed
> IronPython 'IDE' written in IronPython and was shocked to see that the
> application actually ran under Python.net but then ran into the issue I
> described in the previous post as well as this other issue.  It will not be
> a big deal if it does not work.
> 
> Thanks for the quick and understandable reply!
> 
> David 

IP and python.net use pretty different models for this, since python.net
has to cooperate with the std python global interpreter lock (IronPython
does not replicate the GIL in its implementation).

The GIL, in addition to the various restrictions .NET makes on interaction
with the GUI thread will probably make for some fun times and late nights
if you try to do anything too fancy ;)


--------------------------
Brian Lloyd

brian.lloyd at revolutionhealth.com



From lists at cheimes.de  Fri Oct 19 21:56:17 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 19 Oct 2007 21:56:17 +0200
Subject: [Python.NET] python 2.5
In-Reply-To: <C33E69C7.10547%brian.lloyd@revolutionhealth.com>
References: <C33E69C7.10547%brian.lloyd@revolutionhealth.com>
Message-ID: <47190BE1.2030108@cheimes.de>

Brian Lloyd wrote:
> y, this is known as windows-only. for mono we'd probably have to do
> a regular python C extension that uses the mono hosting apis to
> bootstrap the runtime.

It's already done. I've written the C extension couple of month ago to
play with the Python C API and the Mono C API. So far it works and I
haven't heard a single complain.

See
https://pythonnet.svn.sourceforge.net/svnroot/pythonnet/trunk/pythonnet/src/monoclr

Christian



From lists at cheimes.de  Fri Oct 19 22:41:15 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 19 Oct 2007 22:41:15 +0200
Subject: [Python.NET] problem with inheritance? ironpython ok,
 python.net - different
In-Reply-To: <C33E83E0.1058D%brian.lloyd@revolutionhealth.com>
References: <C33E83E0.1058D%brian.lloyd@revolutionhealth.com>
Message-ID: <4719166B.8070200@cheimes.de>

Brian Lloyd wrote:
 > IP and python.net use pretty different models for this, since python.net
> has to cooperate with the std python global interpreter lock (IronPython
> does not replicate the GIL in its implementation).
> 
> The GIL, in addition to the various restrictions .NET makes on interaction
> with the GUI thread will probably make for some fun times and late nights
> if you try to do anything too fancy ;)

It's no fun to debug a problem when .NET, the C python library and
python code meet each other. It's a constant task switch between a C#
debugger, gdb and Python. You don't want to debug it when threads join
the battle. It may take hours before you even grasp which part of your
code is causing trouble.

I wish I could exercise more patience and spare more time on the debug
support. Unfortunately Python's Py_DEBUG / Py_TRACE_REFS changes the
memory layout and API calls a lot. It would be much easier to debug
reference leaks and other problems with a debug build of Python.

I think the use case of PythonDotNet is different from IronPython's use
case. PythonDotNet doesn't aim to be another Python implementation or a
replacement for IronPython. I usually explain it as a bridge between
managed code/.NET/C# on the one side and CPython and C extensions on the
other side.
You should use IronPython if you want to do Python development under
.NET. PythonDotNet is for people who need to embed Python C extensions
in managed code or embed managed code in applications with a CPython
interface.
For example I'm experimenting with using and script a C# assembly with
Python inside Blender. So far I haven't done much but the initial
experiments are doing well.

Christian

From fuzzyman at voidspace.org.uk  Wed Oct 24 00:17:53 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 23 Oct 2007 23:17:53 +0100
Subject: [Python.NET] Experimental C Extensions from IronPython with
 Python.NET - code and article
Message-ID: <471E7311.8000204@voidspace.org.uk>

Hello all,

I've just posted the experimental code for accessing CPython extensions
from IronPython. It uses the embedding wrapper from Python.NET so I 
thought I would let you know. :-)

Blog entry:
http://www.voidspace.org.uk/python/weblog/arch_d7_2007_10_20.shtml#e862
Article: http://www.voidspace.org.uk/ironpython/cpython_extensions.shtml

Despite some serious limitations it works! I have already had matplotlib
with numpy and Tkinter working from IronPython.

We're evaluating to see if this should be the basis of our 'C Extensions 
from IronPython' project.

All the best,

Michael
http://www.manning.com/foord


From lists at cheimes.de  Wed Oct 24 01:23:52 2007
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 24 Oct 2007 01:23:52 +0200
Subject: [Python.NET] Experimental C Extensions from IronPython with
 Python.NET - code and article
In-Reply-To: <471E7311.8000204@voidspace.org.uk>
References: <471E7311.8000204@voidspace.org.uk>
Message-ID: <471E8288.7020705@cheimes.de>

Michael Foord wrote:
> I've just posted the experimental code for accessing CPython extensions
> from IronPython. It uses the embedding wrapper from Python.NET so I 
> thought I would let you know. :-)
> 
> Blog entry:
> http://www.voidspace.org.uk/python/weblog/arch_d7_2007_10_20.shtml#e862
> Article: http://www.voidspace.org.uk/ironpython/cpython_extensions.shtml
> 
> Despite some serious limitations it works! I have already had matplotlib
> with numpy and Tkinter working from IronPython.
> 
> We're evaluating to see if this should be the basis of our 'C Extensions 
> from IronPython' project.

Nice work, Michael!  :)

I've been doing some work on PythonDotNet over the last couple for
months, mostly porting it to Python 2.3, 2.5 and 2.6, getting Mono and
UCS-4 builds done and straighting out bugs. I've also played with the
idea to embed PythonDotNet in IronPython but I haven't got as far as
you. And to be honest I haven't thought that it's so easy to get the
basics done. I'm still fighting with IronPython on Mono.

I have been trying to use a different approach to exchange data between
IronPython and PythonDotNet/CPython. I used the same approach as the
processing package. It uses pickles to exchange data across multiple
Python processes.

Christian

From brian.lloyd at revolutionhealth.com  Wed Oct 24 02:23:41 2007
From: brian.lloyd at revolutionhealth.com (Brian Lloyd)
Date: Tue, 23 Oct 2007 20:23:41 -0400
Subject: [Python.NET] Experimental C Extensions from IronPython with
 Python.NET - code and article
References: <471E7311.8000204@voidspace.org.uk>
Message-ID: <1CCEDFD0D1FF43419A44DA69B60B996056C169@MI8NYCMAIL17.Mi8.com>

that looks pretty slick - congrats!
 
-Brian

________________________________

From: pythondotnet-bounces at python.org on behalf of Michael Foord
Sent: Tue 10/23/2007 6:17 PM
To: pythondotnet at python.org
Subject: [Python.NET] Experimental C Extensions from IronPython with Python.NET - code and article



Hello all,

I've just posted the experimental code for accessing CPython extensions
from IronPython. It uses the embedding wrapper from Python.NET so I
thought I would let you know. :-)

Blog entry:
http://www.voidspace.org.uk/python/weblog/arch_d7_2007_10_20.shtml#e862
Article: http://www.voidspace.org.uk/ironpython/cpython_extensions.shtml

Despite some serious limitations it works! I have already had matplotlib
with numpy and Tkinter working from IronPython.

We're evaluating to see if this should be the basis of our 'C Extensions
from IronPython' project.

All the best,

Michael
http://www.manning.com/foord

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythondotnet/attachments/20071023/f2ec6247/attachment.htm 

From sanxiyn at gmail.com  Wed Oct 24 04:54:39 2007
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Wed, 24 Oct 2007 11:54:39 +0900
Subject: [Python.NET] Experimental C Extensions from IronPython with
	Python.NET - code and article
In-Reply-To: <471E71E5.6090309@voidspace.org.uk>
References: <471E71E5.6090309@voidspace.org.uk>
Message-ID: <5b0248170710231954k5c16ccc8kd906d7ee27fc0884@mail.gmail.com>

2007/10/24, Michael Foord <fuzzyman at voidspace.org.uk>:
> I've just posted the experimental code for accessing CPython extensions
> from IronPython.
>
> Article: http://www.voidspace.org.uk/ironpython/cpython_extensions.shtml
>
> Comments, bugfixes and improvements welcomed!

* Strings from .NET come in as unicode on the CPython type

An evil workaround is to define PyStringConvert as:
def PyStringConvert(obj):
    # evil
    return PyString(obj).GetAttr('encode').Invoke()

This could be improved on Python.NET side. Any idea?

* Can't yet pass in keyword args to function calls.

This is related to the previous item, because:
>>> def f(a): pass
>>> f(**{u'a': 1})
TypeError: f() keywords must be strings

With the previous workaround in place, replace PythonObject.__call__ with:
def __call__(self, *args, **kw):
    args = ConvertToPy(args)
    kw = ConvertToPy(kw)
    return ConvertToIpy(self.real.Invoke(args, kw))

This is more straightforward than creating PyObject[].

-- 
Seo Sanghyeon

From fuzzyman at voidspace.org.uk  Wed Oct 24 14:54:47 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 24 Oct 2007 13:54:47 +0100
Subject: [Python.NET] Experimental C Extensions from IronPython
 with	Python.NET - code and article
In-Reply-To: <5b0248170710231954k5c16ccc8kd906d7ee27fc0884@mail.gmail.com>
References: <471E71E5.6090309@voidspace.org.uk>
	<5b0248170710231954k5c16ccc8kd906d7ee27fc0884@mail.gmail.com>
Message-ID: <471F4097.7090201@voidspace.org.uk>

Sanghyeon Seo wrote:
> 2007/10/24, Michael Foord <fuzzyman at voidspace.org.uk>:
>   
>> I've just posted the experimental code for accessing CPython extensions
>> from IronPython.
>>
>> Article: http://www.voidspace.org.uk/ironpython/cpython_extensions.shtml
>>
>> Comments, bugfixes and improvements welcomed!
>>     
>
> * Strings from .NET come in as unicode on the CPython type
>
> An evil workaround is to define PyStringConvert as:
> def PyStringConvert(obj):
>     # evil
>     return PyString(obj).GetAttr('encode').Invoke()
>   

Hmm.... definitely evil. :-) Maybe it could be conditional and if the 
encode fails then leave it as unicode? All adds overhead for converting 
data of course.

> This could be improved on Python.NET side. Any idea?
>
> * Can't yet pass in keyword args to function calls.
>
> This is related to the previous item, because:
>   
>>>> def f(a): pass
>>>> f(**{u'a': 1})
>>>>         
> TypeError: f() keywords must be strings
>
> With the previous workaround in place, replace PythonObject.__call__ with:
> def __call__(self, *args, **kw):
>     args = ConvertToPy(args)
>     kw = ConvertToPy(kw)
>     return ConvertToIpy(self.real.Invoke(args, kw))
>
> This is more straightforward than creating PyObject[].
>
>   

Definitely looks better. Thanks Seo.

Michael





From fuzzyman at voidspace.org.uk  Wed Oct 24 23:26:52 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 24 Oct 2007 22:26:52 +0100
Subject: [Python.NET] [python] Re: Experimental C Extensions from
 IronPython with Python.NET - code and article
In-Reply-To: <471E7FC0.5010209@cheimes.de>
References: <471E7311.8000204@voidspace.org.uk> <471E7FC0.5010209@cheimes.de>
Message-ID: <471FB89C.5020101@voidspace.org.uk>

Christian Heimes wrote:
> Michael Foord wrote:
>   
>> I've just posted the experimental code for accessing CPython extensions
>> from IronPython. It uses the embedding wrapper from Python.NET so I 
>> thought I would let you know. :-)
>>
>> Blog entry:
>> http://www.voidspace.org.uk/python/weblog/arch_d7_2007_10_20.shtml#e862
>> Article: http://www.voidspace.org.uk/ironpython/cpython_extensions.shtml
>>
>> Despite some serious limitations it works! I have already had matplotlib
>> with numpy and Tkinter working from IronPython.
>>
>> We're evaluating to see if this should be the basis of our 'C Extensions 
>> from IronPython' project.
>>     
>
> Nice work, Michael! :)
>
> I've been doing some work on PythonDotNet over the last couple for
> months, mostly porting it to Python 2.3, 2.5 and 2.6, getting Mono and
> UCS-4 builds done and straighting out bugs. I've also played with the
> idea to embed PythonDotNet in IronPython but I haven't got as far as
> you. And to be honest I haven't thought that it's so easy to get the
> basics done. I'm still fighting with IronPython on Mono.
>
> I have been trying to use a different approach to exchange data between
> IronPython and PythonDotNet/CPython. I used the same approach as the
> processing package. It uses pickles to exchange data across multiple
> Python processes.
>   

Hello Christian,

All I've done so far is a pure-python wrapper (to run under IronPython)
that uses a vanilla build of the Python.NET dlls - so it sounds like
you've done an awful lot more than me!

Using this approach *should* be more efficient than exchanging pickles
though. It already allows you to access CPython extensions though, which
is great.

If we decided to go ahead we would probably work on PyObjects to make
them behave more like their IronPython equivalents.

Our goal (whichever approach we take in the end) is to allow Python code
that uses CPython extensions run unchanged in IronPython.

If anyone is interested in this you can get the details in my blog entry:
http://www.voidspace.org.uk/python/weblog/arch_d7_2007_10_20.shtml#e862

All the best,

Michael Foord
http://www.manning.com/foord


> Christian
>
>   



From myeates at jpl.nasa.gov  Thu Oct 25 00:01:39 2007
From: myeates at jpl.nasa.gov (Mathew Yeates)
Date: Wed, 24 Oct 2007 15:01:39 -0700
Subject: [Python.NET] Experimental C Extensions from IronPython with
 Python.NET - code and article
In-Reply-To: <471E7311.8000204@voidspace.org.uk>
References: <471E7311.8000204@voidspace.org.uk>
Message-ID: <471FC0C3.2090906@jpl.nasa.gov>

This is too sweet for words. One of the main reasons I haven't moved 
over to IronPython is that I want to use numpy. Nice Going!
Mathew

Michael Foord wrote:
> Hello all,
>
> I've just posted the experimental code for accessing CPython extensions
> from IronPython. It uses the embedding wrapper from Python.NET so I 
> thought I would let you know. :-)
>
> Blog entry:
> http://www.voidspace.org.uk/python/weblog/arch_d7_2007_10_20.shtml#e862
> Article: http://www.voidspace.org.uk/ironpython/cpython_extensions.shtml
>
> Despite some serious limitations it works! I have already had matplotlib
> with numpy and Tkinter working from IronPython.
>
> We're evaluating to see if this should be the basis of our 'C Extensions 
> from IronPython' project.
>
> All the best,
>
> Michael
> http://www.manning.com/foord
>
> _________________________________________________
> Python.NET mailing list - PythonDotNet at python.org
> http://mail.python.org/mailman/listinfo/pythondotnet
>
>   



From fuzzyman at voidspace.org.uk  Thu Oct 25 00:45:14 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 24 Oct 2007 23:45:14 +0100
Subject: [Python.NET] [python] Experimental C Extensions from IronPython
 with Python.NET
In-Reply-To: <471E71E5.6090309@voidspace.org.uk>
References: <471E71E5.6090309@voidspace.org.uk>
Message-ID: <471FCAFA.2080606@voidspace.org.uk>

Hello all,

I've uploaded the download code with a slightly improved version. Thanks 
to Seo it now supports passing keyword arguments to the hosted CPython 
functions/methods.

http://www.voidspace.org.uk/ironpython/cpython_extensions.shtml

Thanks

Michael
http://www.manning.com/foord


Michael Foord wrote:
> Hello all,
>
> I've just posted the experimental code for accessing CPython extensions 
> from IronPython.
>
> Blog entry: 
> http://www.voidspace.org.uk/python/weblog/arch_d7_2007_10_20.shtml#e862
> Article: http://www.voidspace.org.uk/ironpython/cpython_extensions.shtml
>
> Comments, bugfixes and improvements welcomed!
>
> Despite some serious limitations it works! I have already had matplotlib 
> with numpy and Tkinter working from IronPython.
>
> All the best,
>
> Michael
> http://www.manning.com/foord
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "C Extensions for IronPython" group.
> To post to this group, send email to c-extensions-for-ironpython at googlegroups.com
> To unsubscribe from this group, send email to c-extensions-for-ironpython-unsubscribe at googlegroups.com
> For more options, visit this group at http://groups.google.com/group/c-extensions-for-ironpython?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>   


From fuzzyman at voidspace.org.uk  Thu Oct 25 00:52:30 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 24 Oct 2007 23:52:30 +0100
Subject: [Python.NET] [python] Re: Experimental C Extensions from
 IronPython with Python.NET - code and article
In-Reply-To: <471FC0C3.2090906@jpl.nasa.gov>
References: <471E7311.8000204@voidspace.org.uk> <471FC0C3.2090906@jpl.nasa.gov>
Message-ID: <471FCCAE.3060204@voidspace.org.uk>

Mathew Yeates wrote:
> This is too sweet for words. One of the main reasons I haven't moved 
> over to IronPython is that I want to use numpy. Nice Going!
>   
Hey - well if someone uses it I might actually maintain it... :-)

For passing lots of data in and out it will probably be highly 
inefficient, but let me know about your experiences with it.

In the long run Resolver aims to solve exactly this problem though, as 
we have customers who also want to use Numpy.

Michael
http://www.manning.com/foord

> Mathew
>
> Michael Foord wrote:
>   
>> Hello all,
>>
>> I've just posted the experimental code for accessing CPython extensions
>> from IronPython. It uses the embedding wrapper from Python.NET so I 
>> thought I would let you know. :-)
>>
>> Blog entry:
>> http://www.voidspace.org.uk/python/weblog/arch_d7_2007_10_20.shtml#e862
>> Article: http://www.voidspace.org.uk/ironpython/cpython_extensions.shtml
>>
>> Despite some serious limitations it works! I have already had matplotlib
>> with numpy and Tkinter working from IronPython.
>>
>> We're evaluating to see if this should be the basis of our 'C Extensions 
>> from IronPython' project.
>>
>> All the best,
>>
>> Michael
>> http://www.manning.com/foord
>>
>> _________________________________________________
>> Python.NET mailing list - PythonDotNet at python.org
>> http://mail.python.org/mailman/listinfo/pythondotnet
>>
>>   
>>     
>
>
> _________________________________________________
> Python.NET mailing list - PythonDotNet at python.org
> http://mail.python.org/mailman/listinfo/pythondotnet
>
>   


From lists at cheimes.de  Thu Oct 25 11:11:28 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 25 Oct 2007 11:11:28 +0200
Subject: [Python.NET] [python] Re: Experimental C Extensions from
 IronPython with Python.NET - code and article
In-Reply-To: <471FCCAE.3060204@voidspace.org.uk>
References: <471E7311.8000204@voidspace.org.uk> <471FC0C3.2090906@jpl.nasa.gov>
	<471FCCAE.3060204@voidspace.org.uk>
Message-ID: <47205DC0.6010207@cheimes.de>

Michael Foord wrote:
> Hey - well if someone uses it I might actually maintain it... :-)
> 
> For passing lots of data in and out it will probably be highly 
> inefficient, but let me know about your experiences with it.
> 
> In the long run Resolver aims to solve exactly this problem though, as 
> we have customers who also want to use Numpy.

We might be able to resolve the problem and make it more efficient. I'm
not sure if it will actually work and my C+/.NET knowledge is too
limited to implement it on my own.

Python 2.x has something called buffer()
(http://docs.python.org/api/abstract-buffer.html). It's designed for
quick memory access of Python objects. IIRC numpy is supporting the
buffer protocol, too. It *might* be possible to use the buffer protocol
to exchange data between CPython and IronPython by using unsafe code.
PythonDotNet uses unsafe code and direct access to memory all the time
to make it efficient.

I don't think it's possible to write unsafe and unmanaged code with
IronPython but with C# one could write some nice and hacky pointer
operations.

Christian

From fuzzyman at voidspace.org.uk  Fri Oct 26 16:27:15 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 26 Oct 2007 15:27:15 +0100
Subject: [Python.NET] [python] Re: Experimental C Extensions from
 IronPython with Python.NET - code and article
In-Reply-To: <47205DC0.6010207@cheimes.de>
References: <471E7311.8000204@voidspace.org.uk> <471FC0C3.2090906@jpl.nasa.gov>
	<471FCCAE.3060204@voidspace.org.uk> <47205DC0.6010207@cheimes.de>
Message-ID: <4721F943.3030800@voidspace.org.uk>

Christian Heimes wrote:
> Michael Foord wrote:
>   
>> Hey - well if someone uses it I might actually maintain it... :-)
>>
>> For passing lots of data in and out it will probably be highly 
>> inefficient, but let me know about your experiences with it.
>>
>> In the long run Resolver aims to solve exactly this problem though, as 
>> we have customers who also want to use Numpy.
>>     
>
> We might be able to resolve the problem and make it more efficient. I'm
> not sure if it will actually work and my C+/.NET knowledge is too
> limited to implement it on my own.
>
> Python 2.x has something called buffer()
> (http://docs.python.org/api/abstract-buffer.html). It's designed for
> quick memory access of Python objects. IIRC numpy is supporting the
> buffer protocol, too. It *might* be possible to use the buffer protocol
> to exchange data between CPython and IronPython by using unsafe code.
> PythonDotNet uses unsafe code and direct access to memory all the time
> to make it efficient.
>
> I don't think it's possible to write unsafe and unmanaged code with
> IronPython but with C# one could write some nice and hacky pointer
> operations.
>   

This is very interesting and could be very useful - thanks. Whichever 
approach we take we will need to investigate this.

Thanks

Michael
http://www.manning.com/foord

> Christian
>
>
>   


From luis.cota at avmltd.com  Mon Oct 29 18:52:41 2007
From: luis.cota at avmltd.com (newbie73)
Date: Mon, 29 Oct 2007 10:52:41 -0700 (PDT)
Subject: [Python.NET]  Loading custom Assembly with Assembly.Load
Message-ID: <13473068.post@talk.nabble.com>


I have attempted to load a custom .NET Assembly like this:

Assembly.LoadWithPartialName("MyAssembly")

This call executes without errors.  However, when attempting to load the
namespace, nothing appears to work.

from clr import MyNameSpace

Always returns an error:

ImportError: cannot import name MyNameSpace

Any ideas what could be wrong?  I am using .NET 2.0 and Python 2.5.

Thanks...

- Luis
-- 
View this message in context: http://www.nabble.com/Loading-custom-Assembly-with-Assembly.Load-tf4713389.html#a13473068
Sent from the Python - pythondotnet mailing list archive at Nabble.com.


From brian.lloyd at revolutionhealth.com  Mon Oct 29 18:59:50 2007
From: brian.lloyd at revolutionhealth.com (Brian Lloyd)
Date: Mon, 29 Oct 2007 13:59:50 -0400
Subject: [Python.NET] Loading custom Assembly with Assembly.Load
In-Reply-To: <13473068.post@talk.nabble.com>
Message-ID: <C34B97D6.109F0%brian.lloyd@revolutionhealth.com>

make sure that the directory of your assembly is in the pythonpath:

import sys
sys.path.append('/dir/to/my/assembly')
...

-Brian


On 10/29/07 1:52 PM, "newbie73" <luis.cota at avmltd.com> wrote:

> 
> I have attempted to load a custom .NET Assembly like this:
> 
> Assembly.LoadWithPartialName("MyAssembly")
> 
> This call executes without errors.  However, when attempting to load the
> namespace, nothing appears to work.
> 
> from clr import MyNameSpace
> 
> Always returns an error:
> 
> ImportError: cannot import name MyNameSpace
> 
> Any ideas what could be wrong?  I am using .NET 2.0 and Python 2.5.
> 
> Thanks...
> 
> - Luis

--------------------------
Brian Lloyd

brian.lloyd at revolutionhealth.com



From lists at cheimes.de  Tue Oct 30 07:54:18 2007
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 30 Oct 2007 07:54:18 +0100
Subject: [Python.NET] Loading custom Assembly with Assembly.Load
In-Reply-To: <13473068.post@talk.nabble.com>
References: <13473068.post@talk.nabble.com>
Message-ID: <fg6kes$n12$1@ger.gmane.org>

newbie73 wrote:
> I have attempted to load a custom .NET Assembly like this:
> 
> Assembly.LoadWithPartialName("MyAssembly")
> 
> This call executes without errors.  However, when attempting to load the
> namespace, nothing appears to work.
> 
> from clr import MyNameSpace
> 
> Always returns an error:
> 
> ImportError: cannot import name MyNameSpace
> 
> Any ideas what could be wrong?  I am using .NET 2.0 and Python 2.5.

You have to load the assembly first.

import clr
clr.AddReference("MyAssembly")
import MyNameSpace

Christian