Re: [IronPython] My takes on C Extensions for IronPython

2007-10-18 Thread Paolo Molaro
I'll just reply here and try to summarize some things.

On 10/18/07 Seo Sanghyeon wrote:
 It's certainly more than 200 lines, and it's not completely trivial
 because some parts of Python/C API are C macros, not C functions.
 (Reference counting is the most important, but also getting
 type(=vtable) of Python objects and like.)
 
 The good news is that this part is already developed, debugged, and
 pretty much finished -- for Python 2.3 to 2.6, and for wide and narrow
 unicode builds of Python. Get it here (~ 1600 lines):

That code has each dllimport method spanning 5 lines of code.
I don't consider a cut and pasted [DllImport()] attribute as
something that is hard to write:)
So this complete work that covers 4 major versions of python
is less than 200 p/invokes. It's missing a few structure definitions.
Nothing an intern can't write in an afternoon.
My point still stands: interoperating with the C code is not an issue.

 I understand MC++ or Managed C++ is used to refer related
 technologies, but in the narrow sense it is a compiler that shipped
 with .NET 1.x which produced mix of managed and x86 code. I
 believe .NET 2.x compiler, i.e. C++/CLI is what is currently
 discussed.

Yes, Managed C++ referes to the old broken and already abandoned
technology, but it's sometimes used also to refer to the new C++/CLI
lanaguage, likely because C++/CLI is not a really good name:)

 It would be nice to be able to compile without Microsoft tools, but I
 don't think it's essential. If assembly compiled with C++/CLI /
 clr:pure can be made to run on Mono that's fine.

First, someone should investigate if clr:pure actually provides seamless
integration with C code. I doubt it works, but I'll wait for someone
using windows to confirm this.
The issue then is that, even if the above would work, the MS C++/CLI compiler
will emit code that depends on the windows ABI (specifically always
considering long to be 32 bits, they even put this in the standard, sigh).
What this means for people not familiar with low-level details, is that
such code is not portable and hence won't work on Linux 64 bit systems
(this is always assuming the interoperability with C code works at all
even on 32 bit systems). So, while it's not essential that this code be
built with non-Microsoft tools, only the MS tools are able to compile
that code and they compile it incorrectly (and as the C++/CLI standard
requires, sadly, so there is no chance this will be ever fixed).

 Also Mono page doesn't mention this, but GCC backend to emit CLI code
 *is* complete and working. It's available right now from GCC SVN. But
 it's yet another project, not Google Summer of Code attempts. This
 project is backed by STMicroelectronics, a big corporation, probably
 for its own use.
 http://gcc.gnu.org/projects/cli.html
 
 Remember, Mono doesn't need to be the sole provider of non-Microsoft
 CLI tools. :) I believe GCC/CLI can be made to help this project.

See above for the portability issues: they'd have to either not follow
the standard or to produce non-working code. Also the gcc CLI backend
is not really complete and even if it were it doesn't mean that C++/CLI
would be any easier to implement on top of it.
My estimate is that C++/CLI on top of gcc will require at least 4-5
years, if someone implements it at all (there is not much demand for it,
there are the portability and standard issues I mentioned above and by
that time Mono will have an extension to semalessly dllimport C++ code,
lowering demand for C++/CLI even more).
In 4-5 years Microsoft itself will pull the plug on C++/CLI, so I think
basing a new design on it is a mistake.

Anyway, I'm not the one who's going to write the code, so more power to
people that will, I just wanted to make people aware that using
managed C++ or C++/CLI will prevent the sw to work on anything but
windows with the .net runtime.

Happy hacking!

lupus

-- 
-
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


Re: [IronPython] Need a Good Embedded Example

2007-10-18 Thread Michael Foord
Hello Joshua,

I'll take a look at this.

It is really easy for IronPython 1 and everything has changed for IP 2 
(and the docs are not exactly complete).

It just takes a bit of exploration. You need to be able to set some 
globals in the default module (where you can make your .NET objects 
available to IP code - and then pull the globals back out after 
executing the Python).

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

Joshua J. Pearce wrote:
 OK, please forgive my earlier vagueness. What I want to do is as follows:

 pe = PythonEngine.CurrentEngine;

 //create a instance of my applications business logic layer class
 myAppService = new AppService(_token);

 //I want to be able to somehow make methods from the myAppService 
 class available to be called from Iron Python code.
 //I know I could import the AppService dll and create my own instance 
 in the IP engine, but that's way too much overhead.

 //How can I say: Hey, pe, here is a method on my object, 
 myAppService, that I want you to make available when you execute a 
 command?

 Thanks,

 -Josh Pearce




 On 10/17/07, *JoeSox* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:

 On 10/17/07, Joshua J. Pearce [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:
  I am looking for an embedded IronPython 2.0 example beyond the
 simple hello
  world one I quoted before.
 
  What I want to know is:
 
  1) How to get variable output from the script back to my c# code.

 I have a quick section in this article...
 http://www.codeproject.com/useritems/pswrdgeniron.asp

 You can view the source here...
 
 http://pswrdgen.googlecode.com/svn/trunk/pswrdgeniron/pswrdgeniron/Form1.cs
 
 http://pswrdgen.googlecode.com/svn/trunk/pswrdgeniron/pswrdgeniron/Form1.cs

 
 Microsoft.Scripting.ScriptDomainManager.CurrentManager.Host.DefaultModule.SetVariable

  2) How to call scripts with multiple statements.

 multiple statements? Do you mean call the methods in an imported
 script?

  3) Do all variables need to be set on the script object, or can
 their
  declaration just be part of the script code?

 It depends what you are doing and how your app is designed.

  4) Is there a good and simple example anywhere that shows how to
 host the
  IronPython engine in a c# app and let users manipulate your
 program objects
  via ipy scripts?

 My article above.

  5) How can I expose c# methods to as IPY functions?

 Not sure I understand your question here. Can't you have a c# method
 then do something like pe.Execute(my py code here)?
 --
 Later, JoeSox
 ___
 Users mailing list
 Users@lists.ironpython.com mailto:Users@lists.ironpython.com
 http://lists.ironpython.com/listinfo.cgi/users-ironpython.com




 -- 
 Joshua Pearce
 

 ___
 Users mailing list
 Users@lists.ironpython.com
 http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
   

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


Re: [IronPython] My takes on C Extensions for IronPython

2007-10-18 Thread Sanghyeon Seo
2007/10/18, Paolo Molaro [EMAIL PROTECTED]:
 My point still stands: interoperating with the C code is not an issue.

Agreed.

 Also the gcc CLI backend
 is not really complete and even if it were it doesn't mean that C++/CLI
 would be any easier to implement on top of it.

I'm not interested in C++/CLI, and I don't think it's needed for CPython anyway.

-- 
Seo Sanghyeon
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


Re: [IronPython] Need a Good Embedded Example

2007-10-18 Thread Michael Foord
Joshua J. Pearce wrote:
 Joesox,

 Thank you very much! Now, what if I the getcount() method was actually 
 getcount(string arg1), is there a way to call it from within the IP 
 script? Or do I need to parse the IP script ahead of time, and call 
 the function myself? That would be like writing my own scripting 
 language, so I hope there is a way to call the method from within IP 
 scripts.
 You should be able to place objects into the 'user scope' using the 
same SetVariable technique. That way the user can call methods on these 
objects from their code.

ScriptDomainManager.CurrentManager.Host.DefaultModule.SetVariable(SomeName,
SomeObject);

SomeObject is then available to user code as SomeName...

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




 Many thanks!

 - Josh Pearce

 On 10/18/07, *JoeSox* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:

 On 10/17/07, Joshua J. Pearce [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:
  OK, please forgive my earlier vagueness. What I want to do is as
 follows:
 
  pe = PythonEngine.CurrentEngine ;
 
  //create a instance of my applications business logic layer class
  myAppService = new AppService(_token);
 
  //I want to be able to somehow make methods from the
 myAppService class
  available to be called from Iron Python code.
 
  //I know I could import the AppService dll and create my own
 instance in the
  IP engine, but that's way too much overhead.
 
  //How can I say: Hey, pe, here is a method on my object,
 myAppService, that
  I want you to make available when you execute a command?


 What are the return values of myAppService.ServiceMethod()?
 Depending upon these values, you will need to handle them before
 sending them to the pe.

 So it sounds like you need something like:

 public int COUNT;

 private void MyIPGetCount()
 {
   //Call your Service method and assign return value to a global
   COUNT = myAppService.getcount ();

   //Create variable bridge from C# to IronPython engine
   //I like to pretend I am just using a IP command line to help
 figure out what I need to do
   pe.ExecuteCommand(PyCount = 0);

   //Set the IronPython bridge variables...
   
 ScriptDomainManager.CurrentManager.Host.DefaultModule.SetVariable(PyCount,
 COUNT);
 pe.ExecuteCommand(PyCountTwo = PyCount);
 }

 This is a simplified version of what I am guess what you need to do
 but there you go.
 --
 Later, JoeSox
 ___
 Users mailing list
 Users@lists.ironpython.com mailto:Users@lists.ironpython.com
 http://lists.ironpython.com/listinfo.cgi/users-ironpython.com




 -- 
 Joshua Pearce
 

 ___
 Users mailing list
 Users@lists.ironpython.com
 http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
   

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


Re: [IronPython] Need a Good Embedded Example

2007-10-18 Thread JoeSox
On 10/18/07, Joshua J. Pearce [EMAIL PROTECTED] wrote:
 Ah, because I am trying to use Iron Python as a scripting language for my
 application. I want to expose a limited subset of my appservice functions to
 the scripting language,and let users write scripts.

Personally, I would just use Python as the scripting for a number of reasons.
1) IronPython is a .Net library not a language
2) IronPython supports Python language modules (to a certain point)
3) Possibly provides compatibility to CPython and IronPython

I believe this would be a better design for your application and be
better in the long run, esp. as IronPython grows and changes rapidly.
This is mainly why I designed pswrdgen and pswrdgeniron this way.
However, just my two cents and not fully aware of your apps specific details.
-- 
Later, JoeSox
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython

2007-10-18 Thread Paolo Molaro
On 10/17/07 Tony Djordjevski wrote:
  You do need to write C code as the API is a C API. I didn't list in the
  last mail because the C implementation of these functions is not a
  difference between the C# impl and the C++ impl of the rest of the code.
  The dllimport declarations I mentioned above would pinvoke to these C
  functions.
 
 Those C functions you speak about will need to execute managed code.
 
 So, either way, what needs to be done is to allow Reverse P/Invoke or 
 some form of DllExport.  Assuming this project is successful, native 
 C/C++ will have to, at some point, execute managed code.
 
 There are only two ways that I know of that you can accomplish this in .NET:
 1. C++ Interop
 2. Modifying a compiled assembly

or 3, the easiest of all: using function pointers in the C code which
the runtimes will generate automatically when passing a delegate
to a p/invoked method.
Besides being trivial compared to both 1 and 2, it works on Mono and it
works on the MS CLR.
Happy hacking!

lupus

-- 
-
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython

2007-10-18 Thread Tony Djordjevski


Paolo Molaro wrote:
 On 10/17/07 Tony Djordjevski wrote:
 You do need to write C code as the API is a C API. I didn't list in the
 last mail because the C implementation of these functions is not a
 difference between the C# impl and the C++ impl of the rest of the code.
 The dllimport declarations I mentioned above would pinvoke to these C
 functions.
 Those C functions you speak about will need to execute managed code.

 So, either way, what needs to be done is to allow Reverse P/Invoke or 
 some form of DllExport.  Assuming this project is successful, native 
 C/C++ will have to, at some point, execute managed code.

 There are only two ways that I know of that you can accomplish this in .NET:
 1. C++ Interop
 2. Modifying a compiled assembly
 
 or 3, the easiest of all: using function pointers in the C code which
 the runtimes will generate automatically when passing a delegate
 to a p/invoked method.
 Besides being trivial compared to both 1 and 2, it works on Mono and it
 works on the MS CLR.
 Happy hacking!
 
 lupus
 

You're right.  I actually forgot about that one, hence my post.

Best Regards,
Tony
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


Re: [IronPython] Need a Good Embedded Example

2007-10-18 Thread Joshua J. Pearce
My application is ASP.NET, I hardly think integrating CPython is going to be
a better choice.

I really hope I can be clear this time and not encourage suggestions to do
all kinds of other stuff that what I am asking about, so here it goes:

Is is possible to 'expose' c# methods that exist in the same scope as an IPY
engine, to that engine so that an arbitrary one of those methods might be
called by python code code that that engine executes?

Thanks,

Josh Pearce

On 10/18/07, JoeSox [EMAIL PROTECTED] wrote:

 On 10/18/07, Joshua J. Pearce [EMAIL PROTECTED] wrote:
  Ah, because I am trying to use Iron Python as a scripting language for
 my
  application. I want to expose a limited subset of my appservice
 functions to
  the scripting language,and let users write scripts.

 Personally, I would just use Python as the scripting for a number of
 reasons.
 1) IronPython is a .Net library not a language
 2) IronPython supports Python language modules (to a certain point)
 3) Possibly provides compatibility to CPython and IronPython

 I believe this would be a better design for your application and be
 better in the long run, esp. as IronPython grows and changes rapidly.
 This is mainly why I designed pswrdgen and pswrdgeniron this way.
 However, just my two cents and not fully aware of your apps specific
 details.
 --
 Later, JoeSox
 ___
 Users mailing list
 Users@lists.ironpython.com
 http://lists.ironpython.com/listinfo.cgi/users-ironpython.com




-- 
Joshua Pearce
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


Re: [IronPython] Need a Good Embedded Example

2007-10-18 Thread JoeSox
On 10/18/07, Joshua J. Pearce [EMAIL PROTECTED] wrote:
 My application is ASP.NET, I hardly think integrating CPython is going to be 
 a better choice.

You never mentioned you were using ASP.NET. You have mentioned C#.

 Is is possible to 'expose' c# methods that exist in the same scope as an IPY
 engine,

Can you clarify what you mean by this line for me?  Can you provide a
C# method  that exists in the same scope as an IPY engine?

There must be a custom interface, how would an outside script know
about a custom method outside it's scope without an custom interface?
Michael and myself have both provided examples.

If you have a C# method it must be represented by something else in
the script or python code that IronPythonEngine is using, then update
the script or python code loaded in the IronPythonEngine using the
examples provided.

Since I have not seen your source, I don't know why you believe
importing the AppService dll and create your own instance in the IP
engine will be too much overhead.  That sounds like the bet way to go
but I am not familiar with your source.
Good Luck!
-- 
Later, JoeSox
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


Re: [IronPython] Need a Good Embedded Example

2007-10-18 Thread Joshua J. Pearce
I am very sorry! I just noticed this:

ScriptDomainManager.CurrentMan
ager.Host.DefaultModule.SetVariable(SomeName,
SomeObject);

SomeObject is then available to user code as SomeName...

That is exactly what I want to do!!!

Thank you very much!



On 10/18/07, JoeSox [EMAIL PROTECTED] wrote:

 On 10/18/07, Joshua J. Pearce [EMAIL PROTECTED] wrote:
  My application is ASP.NET, I hardly think integrating CPython is going
 to be a better choice.

 You never mentioned you were using ASP.NET. You have mentioned C#.

  Is is possible to 'expose' c# methods that exist in the same scope as an
 IPY
  engine,

 Can you clarify what you mean by this line for me?  Can you provide a
 C# method  that exists in the same scope as an IPY engine?

 There must be a custom interface, how would an outside script know
 about a custom method outside it's scope without an custom interface?
 Michael and myself have both provided examples.

 If you have a C# method it must be represented by something else in
 the script or python code that IronPythonEngine is using, then update
 the script or python code loaded in the IronPythonEngine using the
 examples provided.

 Since I have not seen your source, I don't know why you believe
 importing the AppService dll and create your own instance in the IP
 engine will be too much overhead.  That sounds like the bet way to go
 but I am not familiar with your source.
 Good Luck!
 --
 Later, JoeSox
 ___
 Users mailing list
 Users@lists.ironpython.com
 http://lists.ironpython.com/listinfo.cgi/users-ironpython.com




-- 
Joshua Pearce
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com