Re: [IronPython] Zlib
On 8/25/06, Dino Viehland [EMAIL PROTECTED] wrote: I've opened bug #2590 ( http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPythonWorkItemId=2590) to track this.We have another compression request bug already (PEP 273 zip archive module support) and these two would go hand-in-hand.No ETA on when we'd get to this though, but most likely sooner than supporting pyd's :). What's the best way for me to supply the on-record opinion that PYD support should have a very very low priority compared to other things? :) -- Curt Hagenlocher [EMAIL PROTECTED] ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Case Sensitive Imports
On 1/5/07, Michael Foord [EMAIL PROTECTED] wrote: IronPython is case-insensitive with regards to imports, whereas CPython is not. I'm going to guess that this is platform-specific, and that you happen to be running CPython on a filesystem that's not case-sensitive. -- Curt Hagenlocher [EMAIL PROTECTED] ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Interface in IronPython
If you mean a CLR interface, you will have to define it in a C# or VB.NETassembly and then derive from that interface in IronPython. There's not currently any way to define a CLR interface from IronPython. On 3/12/07, Ed Fialkowski [EMAIL PROTECTED] wrote: Hi all, I'm pretty much totally new to IronPython and have come to the point that I need an interface to interact with a co-worker's code, but I can't seem to find any documents or discussion on syntax for writing an interface. Does anyone know of a link that talks about interfaces in IronPython or feel like explaining one too me? :) Any advice would be greatly appreciated. Thanks. -Ed ___ 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] Patent concerns
On 6/1/07, Tim Roberts [EMAIL PROTECTED] wrote: The license associated with IronPython is quite specific about patent rights. Microsoft treats its licenses very seriously. In my opinion, there's nothing to worry about here. People who are simply *using* IronPython are covered by the license. The originally-expressed concern was that looking at the IronPython source code might contaminate a developer such that, if the same developer later worked on a different project with similar architecture, it might open that project up to claims of violating a Microsoft patent. I am not a lawyer, but this seems highly unlikely. Independent rediscovery does not protect you from claims of patent infringement, only from copyright infringement. -- Curt Hagenlocher [EMAIL PROTECTED] ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Patent concerns
On 6/1/07, M. David Peterson [EMAIL PROTECTED] wrote: On 6/1/07, Curt Hagenlocher [EMAIL PROTECTED] wrote: Independent rediscovery does not protect you from claims of patent infringement, only from copyright infringement. Unless I am misreading, it seems you are suggesting that the protection comes in the form of copyright, not patent, and therefore could present a problem. Have I misinterpreted? Let's say, for the sake of argument, that I want to contribute source code to the ZincPython project. There are two ways that my work could cause legal problems: it might infringe on someone's patent, or it might be copied wholesale from someone else's work. For patent infringement, it doesn't really matter where the code came from -- I wrote it, I copied it, I channeled it from a 12,000-year-old programmer named Klaatu -- if it infringes, it infringes. In order for copyright violation to have happened, on the other hand, I have to actually have had access to the code being copied. Some projects apparently try to protect themselves from *claims* of copyright violation by asking that their donors refrain from looking at similar or related (and usually competing) source code. Now that I think about it, though, reading someone else's source code might expose me to a clever idea that (unbeknownst to me) is patented -- thereby increasing the risk that I inadvertently infringe on a patent when I independently reimplement similar functionality. I guess I'm just biased against that idea because brilliant technique so rarely seems important to me. -- Curt Hagenlocher [EMAIL PROTECTED] ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Patent concerns
On 6/3/07, John J Lee [EMAIL PROTECTED] wrote: This is not a case of some accidental, unknowing infringement, Gutierrez asserts. There is an overwhelming number of patents being infringed. This is a public statement made purely for PR purposes and probably shouldn't be used to imply anything about real-world law. -- Curt Hagenlocher [EMAIL PROTECTED] ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Hosting IronPython 2.X in .NET app
On 7/10/07, Dino Viehland [EMAIL PROTECTED] wrote: Major things we know we still have to do include yield expressions (sorry, there's probably a technical term for them) Closures :P. -- Curt Hagenlocher [EMAIL PROTECTED] ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Hosting IronPython 2.X in .NET app
On 7/10/07, Curt Hagenlocher [EMAIL PROTECTED] wrote: On 7/10/07, Dino Viehland [EMAIL PROTECTED] wrote: Major things we know we still have to do include yield expressions (sorry, there's probably a technical term for them) Closures :P. Doh! I'm so retarded that I misspelled generators :(. Apparently I've been reading too much about Ruby lately... -- Curt Hagenlocher [EMAIL PROTECTED] ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] dir and urllib (utter newbie questions)
On 7/14/07, David Seruyange [EMAIL PROTECTED] wrote: I'm very new to Python and had a few questions. Does dir() only work from the ipy interpreter? If I attempt the following: from System import * dir() It sucesssfully prints everything available but when I try the two lines of code from a script and run: ipy test.py Nothing prints. That's because dir() doesn't print anything. It merely returns a list of values that the interpreter prints. When you run it from the file, there isn't a command line interpreter printing the results of any expressions. If you said print dir() instead of just dir(), your program would do what you expect. One more question: does urllib come with Iron Python? None of the standard Python library comes with IronPython, but the intent for IronPython is that it should support the standard Python library, so you could just download CPython and try to use it. Alternatively, check out http://fepy.sourceforge.net/ as a one-stop-shop. -- Curt Hagenlocher [EMAIL PROTECTED] ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Py 2.5 bindings for SVN 1.4.4
On 7/24/07, Jon Nicholson [EMAIL PROTECTED] wrote: I'd like to use IronPython 1.1 to write a deployment script for an upcoming web project. All of the files for the site are stored in an SVN repository. I'm wondering if IronPython is capable of interfacing with the Python 2.5 bindings for SVN 1.4.4. I would guess not, as that's almost certainly reliant on C extensions. What you probably want are .NET bindings for SVN. There don't seem to be any official ones, but you might try the project at http://www.pumacode.org/projects/svndotnet/ -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] System.Reflection.Assembly finding python modules but no classes..
On 7/27/07, Matt Williams [EMAIL PROTECTED] wrote: This code is attempting to instantiate my IronPython classes dynamically from Microsoft.ApplicationBlocks.UIProcess.GenericFactory. It would appear that the factory is making calls to load the IronPython assembly, then using reflection to load/instantiate and return the specified class. Unfortunately, this won't work because Python classes aren't CLR classes -- they can't be, because Python classes are mutable in ways that CLR classes aren't. To load a Python-implemented class via reflection, you'd have to front-end it with a CLR class implemented in C#/VB/etc. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] M2Cryto
On 7/27/07, Garabatus Raptus [EMAIL PROTECTED] wrote: I would like to use M2Crypto (a wrapper for OpenSSL) with Ironpython. Any idea of how can I integrate it with Ironpython? This is an extension to CPython written in C, which is therefore not compatible with IronPython. Depending on your application's requirements, you may be able to use the SslStream class that's built into the .NET Framework instead. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET can see Python classes?
On 8/5/07, Bryan [EMAIL PROTECTED] wrote: i to would like to do this. i don't understand a part of this. i understand creating a CLR interface and i understand creating a python file that has a class that derives from the CLR interface. but how does the CLR code instantiate the derived class and access the Python code through the interface? where does this instance come from? You would have to interact directly with the IronPython engine from the CLR code in order to get an instance of the class. Something like the code that Ori posted earlier in the thread would work for that. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Using blocks separators instead of indentation
On 8/13/07, Ori [EMAIL PROTECTED] wrote: OK I got the point. I have to use several statements in a single line. For exmpale, something like: i = 1; if (i =1): i = 0 is there a way to do it? Is there a replacement to the newline char? This is legal Python: a = 1; b = 2 if a != b: print 'different' I don't know *why* someone would want to write code like this unless they've been programming for such a short time that they've never had to go back and change something that they wrote over a year ago. I find this style unreadable. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Using blocks separators instead of indentation
On 8/13/07, Ori [EMAIL PROTECTED] wrote: Thanks but I did not ask if it is ugly or not. I just need it. Is there a way to do it? In my email, I also gave two examples of legal Python code with more than one statement per line. In general, you can put any number of commands on the same line using a semi-colon as separator. That means that the following is legal Python: print 'hello'; print 'goodbye'; print 'up'; print down However, conditional and looping constructs that contain a colon -- that is, if, for, while, etc. -- are limited to one per line, and the statement ending in a colon must be the first one on the line. That is, the first of these lines is legal Python and the second and third are not. if 1: print 'goodbye'; print 'hello' print 'hello'; if 1: print 'goodbye' if 1: print 'goodbye'; else: print 'hello' -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] -X:PreferComDispatch
2007/10/3, Martin [EMAIL PROTECTED]: Reason I'm asking if IronPython doesn't require interop assemblies to access COM objects then the issue of supporting pythong standard libraries become atleast less of an issue? There's feature compatibility (both products support COM) and source compatibility (my COM-using app runs unchanged under either CPython or IronPython). Whether or not feature compatibility is sufficient is presumably going to be up to the community and the way it votes for changes. On 10/3/07, Sanghyeon Seo [EMAIL PROTECTED] wrote: I can't see how two are related, given that Python standard library doesn't use COM. There is COM support in the Pythonwin extensions. Some people might consider this to be part of the standard library under Windows, even though it's not an official part of Python. -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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
On 10/12/07, Giles Thomas [EMAIL PROTECTED] wrote: What is the best architecture? We're thinking of this as being a bit of C# managed code to interface with the C extension, and a thin Python wrapper on top. The module's existing C extension and Python code would sandwich this layer. Let us know if this is a silly idea :-) My two cents would be this: using Managed C++, try for source compatibility first. It will almost certainly be less work than binary compatibility -- especially given your restricted test case -- and you're not likely to do much coding that wouldn't be needed for binary compatibility anyway. -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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
On 10/17/07, Paolo Molaro [EMAIL PROTECTED] wrote: As python extensions use a C API, I don't see how Managed C++ would provide source compatibility. Managed C++ would be an ill-advided method, IMHO. [...] You'd have two components: the C API headers and some C code (this is required in any case) is the first. Then you need an assembly that translates from the C API to the IronPython model. You can write this in nice C# + a few dllimports or with the ugly managed C++ (assuming managed C++ can actually consume the python headers). MC++ lets you create a single module that contains both normal machine code and MSIL, and takes care of the transitions between the two. There's no reason you can't compile the existing C code and link it directly with the MC++ wrapper -- which is exactly what I originally meant. A Managed C++ implementation would be pretty useless for a mono port, but I think it would be pretty useless for the .net runtime, as you need to expose a C API anyway. Of course, if Managed C++ isn't supported by Mono, that's probably a sufficiently good reason not to take this approach. -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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
On 10/17/07, Giles Thomas [EMAIL PROTECTED] wrote: Curt - how does MC++ relate to using P/Invoke? That is, is it P/Invoke plus some clever packaging stuff to allow you to produce a single assembly with both machine code and MSIL, or is there more to it than that? Or is it something completely different? I'd guess they share some internals -- why write the same thunking code twice, after all. But their usage patterns are sufficiently different that I'd argue the internals don't really matter. P/Invoke requires you to declare everything explicitly, while the goal for MC++ is to make interop as transparent as possible. -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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
On 10/17/07, Giles Thomas [EMAIL PROTECTED] wrote: I must admit I'd also misunderstood how a MC++ option would work, in the same way as Paolo Molaro, but this sounds really useful. Is there any particular resource you'd recommend for learning more about it? Perhaps you should read this link first: http://www.mono-project.com/CPlusPlus I've obviously given the impression that I have quite a bit more experience with MC++ than is actually the case. Although I spent some time studying the technology for possible use, my real-world experience with it is pretty limited. A good friend made extensive use of it at his previous job. They reported lots of problems under 1.0 and 1.1, but were quite happy with the robustness and syntactical improvements made for 2.0. He says that -- for integrating a legacy C or C++ codebase into the CLR environment -- he would use it again in a heartbeat. But I would expect that Mono-compatibility is especially critical for this project. -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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
On 10/17/07, Paolo Molaro [EMAIL PROTECTED] wrote:
The python API requires a couple dozen structure definitions plus a few
dozen dllimport declarations. This can be about 200 lines of trivial
to write declarative stuff.
I'm having trouble understanding what you mean by this. Let's say I've got
an extension method that looks like this:
PyObject * ModifyColumns(PyObject * self, PyObject * args)
{
PyObject * columns;
if (!PyArg_ParseTuple(args, O, columns))
{
return NULL;
}
if (!PySequence_Check(columns))
{
PyErr_SetString(PyExc_ValueError, parameter must be a sequence);
return NULL;
}
PyObject * result = PyTuple_New(PySequence_Length(columns));
for (int i = 0; i PySequence_Length(columns); i++)
{
PyObject * value = PySequence_GetItem(sequence, i);
// Do something to value
// And make sure you don't screw up the reference count
PySequence_SetItem(result, i, value);
}
return result;
}
In order to use this extension from IronPython, I need C implementations of
each of those API functions. The PySequence_ methods should to be able to
understand CLR arrays or any other IEnumerable-like object. I'm not sure
what PyTuple_New should return, but whatever it is will need to have
PyObject*-like semantics.
How does DllImport fit into this picture? How can I avoid implementing all
these functions in C or C++?
--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] [python] Re: Announcement: Project to get someCPython C extensions running under IronPython
On 10/17/07, Joe Mason [EMAIL PROTECTED] wrote:
On 10/17/07, Keith J. Farmer [EMAIL PROTECTED] wrote:
Forgive my non-C-ness (it's been a long time since I wrote a native
module
for Python), but aren't you now buying into a major re-implementation of
all
the native Python standard library into C#?
Couldn't the C/C# API just use IronPython objects and methods to
implement the Python standard library?
Yes, that would be the idea.
I think it's best when thinking about the architecture to have a specific
example to refer to. With that in mind, I'm going to repeat some code I
wrote earlier in the thread (with a few modifications).
PyObject * ReverseSequence(PyObject * self, PyObject * args)
{
PyObject * columns;
if (!PyArg_ParseTuple(args, O, columns))
{
return NULL;
}
if (!PySequence_Check(columns))
{
PyErr_SetString(PyExc_ValueError, must be a sequence);
return NULL;
}
int length = PySequence_Length(columns);
PyObject * result = PyTuple_New(length);
for (int i = 0; i length; i++)
{
PyObject * value = PySequence_GetItem(sequence, i);
// Don't remember if I need to INCREF value
PySequence_SetItem(result, length - i - 1, value);
}
return result;
}
Obviously, this isn't a real-world example, but it does show a few
requirements for the compatibility layer.
1) The code expects a sequence. What kind of data should we be allowed to
pass to it from IronPython?
2) The code returns a tuple. How will this tuple be translated into a CLR
object for consumption by IronPython?
--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] [python] Re: Announcement: Project to getsomeCPython C extensions running under IronPython
On 10/17/07, Keith J. Farmer [EMAIL PROTECTED] wrote: A larger worry I have is the possibility that some of this will end up being unsafe code, at which point you will have difficulties in full trust scenarios, such as web servers. This project will by definition be producing unsafe code. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] [python] Re: Announcement: Project togetsomeCPython C extensions running under IronPython
On 10/17/07, Keith J. Farmer [EMAIL PROTECTED] wrote: See my earlier email. I think you **could** keep it in C, compile into pure IL. At that point you have to deal with pointer-driven algorithms (eg, NumPy), but you could generate safe code. The basic data type in a CPython extension is a PyObject *. That asterisk there is an old-fashioned way of saying unsafe code. :) -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] thread.interrupt_main() not implemented
Ah!
On 10/19/07, Dino Viehland [EMAIL PROTECTED] wrote:
And we implement that using Thread.Abort (which is the only way we really
have to interrupt a thread at an arbitrary point in time) J When the user
catches it they'll see it as a KeyboardInterruptException, and we'll do the
right thing for Thread.ResetAbort().
If you want to get the exact behavior we cause with Ctrl-C it's actually:
import clr
clr.AddReference('Microsoft.Scripting')
from Microsoft.Scripting.Shell import KeyboardInterruptException
main.Abort(KeyboardInterruptException())
in v1.x it's:
import clr
clr.AddReference('IronPython')
from IronPython.Runtime.Exceptions import PythonKeyboardInterruptException
main.Abort(PythonKeyboardInterruptException())
and then the user can catch it as a they'd catch a normal keyboard
interrupt. I think the only reason we don't have this implemented by
default is that in some situations (e.g. outside the console) we won't
actually know what the main thread is.
*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Curt Hagenlocher
*Sent:* Friday, October 19, 2007 10:17 AM
*To:* Discussion of IronPython
*Subject:* Re: [IronPython] thread.interrupt_main() not implemented
thread.interrupt_main has somewhat different semantics than Thread.Abort;
it basically triggers a keyboard interrupt on the main thread -- this is, of
course, an exception that can be caught and handled by user code on that
thread.
On 10/19/07, *Dino Viehland* [EMAIL PROTECTED] wrote:
I think you could work around this by remembering the main .NET thread
and calling Abort on it:
from System import Threading
main = Thread.CurrentThread
# and then later on…
main.Abort()
But I'd suggest that interrupting a thread at an arbitrary point is a
little dangerous (as it may have some state which isn't entirely consistent
that it's trying to update).
*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Clems no
*Sent:* Friday, October 19, 2007 8:37 AM
*To:* users@lists.ironpython.com
*Subject:* [IronPython] thread.interrupt_main() not implemented
Hello,
When i want to use thread.interrupt_main() in iron python script, i've got
this error:
NotImplementedError: interrupt_main not implemented
Is there an equivalent in ironpython?
Thanks,
cbr.
___
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
___
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
On 10/19/07, Giles Thomas [EMAIL PROTECTED] wrote: Paolo Molaro wrote: You can use a struct that contains all the needed delegates and pass that on the p/invoke call. I guess that's a bit cleaner, as is Curt's COM version. But I was really hoping to be able to avoid the init call from the managed side entirely. Hypothetically, you could muck about with the unmanaged interfaces to the managed code execution engine and pull in the information that way. How much of the MSCOREE-exposed functionality does Mono implement? Mind you, I don't actually think this is a good idea. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] thread.interrupt_main() not implemented
thread.interrupt_main has somewhat different semantics than Thread.Abort; it basically triggers a keyboard interrupt on the main thread -- this is, of course, an exception that can be caught and handled by user code on that thread. On 10/19/07, Dino Viehland [EMAIL PROTECTED] wrote: I think you could work around this by remembering the main .NET thread and calling Abort on it: from System import Threading main = Thread.CurrentThread # and then later on… main.Abort() But I'd suggest that interrupting a thread at an arbitrary point is a little dangerous (as it may have some state which isn't entirely consistent that it's trying to update). *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Clems no *Sent:* Friday, October 19, 2007 8:37 AM *To:* users@lists.ironpython.com *Subject:* [IronPython] thread.interrupt_main() not implemented Hello, When i want to use thread.interrupt_main() in iron python script, i've got this error: NotImplementedError: interrupt_main not implemented Is there an equivalent in ironpython? Thanks, cbr. ___ 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] Announcement: Project to get some CPython C extensions running under IronPython
On 10/19/07, Giles Thomas [EMAIL PROTECTED] wrote: A question - if we were trying to produce something that, at a source level, looked like the CPython extensions API, is there any easy way that we could get that to be able to call back to IronPython? I can imagine something like an init() function on the managed side that could pass a number of delegates over to the unmanaged code so that they could be called back at a later point, but is there a more elegant solution? You could define a COM / COM-like interface (or set of interfaces), implement them in C# and pass them to the C code. This is definitely cleaner but has the disadvantage of a tighter binding between the two parts and a potentially much more painful versioning story. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Import decimal failure with Turkish Locale (IP 1.1)
On 10/31/07, Michael Foord [EMAIL PROTECTED] wrote: The issue is because one of the method names is '_round_ceiling'. In the Turkish locale, the uppercase version of this is ROUND_CEİLİNG (in Turkish uppercase of i is I with a dot on top of it). Obviously the lookup of the corresponding global fails. In CPython the name is a byte-string, and so '.upper' just uses the ascii uppercase rather than the locale sensitive version - so we see failing to import 'decimal.py' as an IronPython bug. As this badly impacts Resolver we would *love* to see this fixed soon... Why not change decimal.py to use ToUpperInvariant()? Are you sharing the file with CPython? -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Tests and IronPython hosting
I'm trying to test some IronPython-hosting code, which is proving a little
tricky because of the inability to create multiple engines. Is there anyway
to reset the engine to a just-initialized state, or to destroy it and
create a new one? Alternatively, is there a straightforward way to delete a
(published) ScriptModule through the API? Or is engine.Execute('del
sys.modules['module_name']) my best bet in this regard?
--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Another trivial bug
On 11/12/07, Dino Viehland [EMAIL PROTECTED] wrote: I guess now is as good as any time to announce that we're going to support multiple instances of engines in a single app domain. I'm spectacularly happy about this; thanks for letting us know! :) -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Deleting a module from the host
I created and published the module myself using ScriptDomainManager.CurrentManager.CreateModule and ScriptDomainManager.CurrentManager.PublishModule. Hmm... I just noticed for the first time the naming inconsistency there between Module and ScriptScope. To back up a step, I'm trying to TDD an integration layer between a C# app and some Python components, and I want to be able to basically undo the test actions so it won't influence the next test. If I understand the recent DLR hosting docs correctly, at some point I should be able to accomplish the same thing by creating new ScriptRuntimes instead -- but it looks like IronPython is not yet close to allowing this. When you consider that there might be published ScriptScopes in many different languages then, yeah, it really complicates the potential relationship between the global object (that's global per runtime, yes?) and sys.modules. I would certainly want to be able to use DLR modules (sorry, ScriptScopes) from Python without worrying about their implementation language. How can I get a reference to them if not through sys.modules? How do they get loaded in the first place? What's role does the Python loader and its extensibility mechanisms play when Python code causes a Javascript module to be loaded? Plenty of fun questions! On Jan 4, 2008 9:23 AM, Dino Viehland [EMAIL PROTECTED] wrote: Unfortunately the answer is it depends, and it's probably not supported in Alpha 7 L The depends part is how the module got there and it all revolves around the design we've come up with for the hosting of multiple languages. We have a global object per ScriptRuntime which is (currently) a ScriptScope. That scope holds onto a bunch of name/value bindings (where a value could be another nested ScriptScope) and this is the closest concept (in the DLR) we have to a module. The idea then is that each language exposes the global object via its own mechanism picking something that makes the most sense for that language. IronPython is going to expose the global object via import much like it exposes other modules and .NET namespaces. But that doesn't mean sys.modules goes away, or that sys.modules becomes the global object. Instead what we're currently planning on doing is having import fallback to the global object just as it falls back to the namespaces today. (As I type this I realize it does complicate this scenario – so I'll ask if this sound crazy or like a bad idea? Should we instead try to merge them and have sys.modules == global object? That has its own potential quirks but they could be dealt with.) So that gives two different locations where modules can be published: Either in the global object or in sys.modules. Therefore how you added the module effects how the module gets removed. If the user did import foo and we pulled up a .py file it'll end up being in sys.modules. If we pulled up a .js file from the DLR then it'll be in the global object. Further complicating things is the fact that the global object isn't really implemented yet. There's some remnants of the old cross-language module support we had early on but that's not really the global object. So for now in Alpha 7 I think the answer is that you execute the code. There's also one more future possibility: And that is that to expose Python specific functionality we may need to have a PythonEngine class or something that lets you do things that aren't part of the least common denominator. There accessing sys.modules would be a likely piece of functionality to have. *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Curt Hagenlocher *Sent:* Friday, January 04, 2008 6:03 AM *To:* Discussion of IronPython *Subject:* [IronPython] Deleting a module from the host In a previous alpha of IPY 2.0, I deleted modules by saying PythonEngine.CurrentEngine.SystemState.modules.Remove(moduleName) (which is almost a direct analog of del sys.modules[moduleName]). What's the best approach in Alpha 7? And will this change as IronPython continues to migrate to the DLR? I suppose I could literally execute Python code to do what I want, but it seems so inelegant... -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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] Deleting a module from the host
On Jan 4, 2008 3:26 PM, Dino Viehland [EMAIL PROTECTED] wrote: Then the ScriptRuntime would ask the host to load the ScriptScope and depending on the host it'd search the web server, the file system, the database, etc… for the appropriately named file, and load it with the appropriate engine. So it would be the host that would both load the source and determine the engine, and the default Pythonic behavior (for the Python engine) would be available by using a standard Python host? PublishModule (I suspect you mean it's on ScriptEngine) No, I'm using it on ScriptDomainManager.CurrentManager -- I don't see one implemented on ScriptEngine in the latest drop. There's a bug in ScriptDomainManager.GetPublishedModules that I've started running into; guess I'll post it to Codeplex. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Hosting and globals
On Jan 8, 2008 6:58 AM, Slide [EMAIL PROTECTED] wrote: I am trying to update my application to use the Hosting APIs from alpha 7, one thing that I can't seem to figure out is how to access globals to add stuff from my application to be used by the script. What kind of reference do you have to the script from the hosting code? If you've got a ScriptScope for the module, you can just say PythonEngine.CurrentEngine.SetVariable(module, varName, varValue) where module is the ScriptScope. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Hosting and globals
On Jan 8, 2008 8:27 AM, Slide [EMAIL PROTECTED] wrote: So, if I have a module and inside that module I have an import statement. Does that imported module reside below the ScriptScope of the module I created? No, each module is its own ScriptScope. When you import one module from another in Python, you're really doing two things: 1) Load the module if it's not already loaded 2) Create a reference to that module in the current module There's nothing like a hierarchical relationship here. Adding them in the way you mention does not add them to globals. There isn't really such a thing as a global global in Python in the sense of (say) a C++ global variable. Globals are always scoped to the module they're in. The closest thing there is to this in Python is the list of loaded modules -- and even that can be manipulated, given that it's really just a dictionary contained within the sys module. If you've done the equivalent of poking a = 1 into module foo, you can access this value from __main__ by saying from foo import a. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Clearing context
On Jan 9, 2008 8:54 AM, Slide [EMAIL PROTECTED] wrote: If I change this file and try reloading my script, it takes the modifications just fine and runs the new code. If I modify mymod, but not the main script, I get the old code from mymod run. Is there something I can do to force it to reload the imported scripts as well? There's no straightforward and reliable way to track usage, so the only thing you could do generically is to reload *all* your modules. One thing you could do would be to say import mymod in any other module using mymod. After a reload of mymod, you could then iterate over sys.modules and reload any module containing the symbol mymod. It's not foolproof, but it's probably good enough. Another alternative would be to change your code to look like this: class MyClass(SomeNameSpace.IMyInterface): def SomeFunc(self): from mymod import myfunc myfunc() That way, the import gets re-run each time you run SomeFunc, and you'll always get the latest version of the module. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Clearing context
On Jan 9, 2008 9:42 AM, Lee Culver [EMAIL PROTECTED] wrote: class MyClass(SomeNameSpace.IMyInterface): def SomeFunc(self): from mymod import myfunc myfunc() That way, the import gets re-run each time you run SomeFunc, and you'll always get the latest version of the module. This will not re-import mymod every time the function is run. Once you run from foo import bar or import foo then the foo module is loaded into python and will not be reloaded from python without an explicit call to the reload function. Poor wording on my part, sorry. What I should have said was that the myfunc symbol will be reimported from the mymod module at that point in time, and will therefore pick up any changes to mymod that have been made -- including changes made by a reload. I did not mean to imply that mymod itself would be reloaded. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Clearing context
On Jan 9, 2008 2:45 PM, Tim Roberts [EMAIL PROTECTED] wrote: This is an important point, and I still don't think you have it exactly right. When you say including changes made by a reload, that really should say ONLY IF the module has been reloaded. Unless you reload it, the mymod that is in the module cache will never change, and therefore SomeFunc will always get the same version of myfunc(). There are many ways to update module contents; reloading is only one of them. If I said (from hypothetical module foo): import mymod mymod.myfunc = lambda obj: obj + 1 I will successfully have modified the value of myfunc without doing a reload. And saying from mymod import myfunc will pickup the new function that's been assigned to that symbol. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] [python] [IronPythonStudio] Namespace Classes andAssembly Files
On Jan 30, 2008 9:25 AM, Pigneri, Rocco [EMAIL PROTECTED] wrote: Ah, ha! I think I may have found the culprit! If I have the following import sequences in the follwing order, then only FormTwo is available: from FormOne import * from FormTwo import * However, if they are in this order, then only FormOne is available: from FormTwo import * from FormOne import * It seems that only the last class statement that is evaluated/imported is retained. Are you importing FormOne from FormTwo and/or vice versa? Pythonic namespace collisions are far less likely if you keep things in their namespaces. This is another way of saying that from X import * is potentially evil and should be used very carefully. Try saying import FormOne and then qualify the class as FormOne.FormOne. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] [python] [IronPythonStudio] Namespace ClassesandAssembly Files
On Jan 30, 2008 10:29 AM, Pigneri, Rocco [EMAIL PROTECTED] wrote: It sounds like instead, I need to do this: import FormOne import FormTwo f = FormOne.Forms.FormOne() f2 = FormTWo.Forms.FormTwo() Is this correct? Exactly. When you said from FormOne import *, you introduced the symbol Forms into the current namespace with the value of FormOne.Forms. When you then said from FormTwo import *, you replaced the symbol Forms with the value of FormTwo.Forms. As you suggest, Python's import statement is not like the C# using statement. A Pythonic import will introduce new symbols into the local namespace at run time. The C# using statement is simply a directive to the compiler to tell it which namespaces to search in for symbols that are otherwise undefined in the local scope. It literally does not emit any IL code that is executed at runtime. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Distinguishing DLR object from CLR object
Is there a straightforward and reliable way from within IronPython to tell
if a particular object is a CLR object' or a DLR object? I can make a
guess for just IronPython by saying
isPythonObject = clr.GetClrType(type(obj)).FullName.startswith('IronPython')
but this is both ugly and unreliable.
--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Distinguishing DLR object from CLR object
On Jan 30, 2008 3:31 PM, Dino Viehland [EMAIL PROTECTED] wrote: If by DLR object you mean an object which has dynamic behavior beyond just it's type you can check to see if it implements IDynamicObject. But there really isn't anything considered to be a DLR object. Yes. I wasn't very happy with the categorization, but couldn't think of a better way to express what I meant. Your answer was exactly what I wanted: clr.GetClrType(Microsoft.Scripting.IDynamicObject).IsAssignableFrom(type(obj)) -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Template argument type inference
Is it expected that the DLR and/or IronPython will eventually try to infer
template arguments when calling a generically-defined functions?
PS F:\IPCE-r7\ipy2 *.\ipy.exe*
IronPython 2.0 Alpha (2.0.0.800) on .NET 2.0.50727.1433
Copyright (c) Microsoft Corporation. All rights reserved.
*import clr*
*clr.AddReferenceByPartialName('xunit')
* *from Xunit import Assert
* *Assert.Equal(1, 1)
*Traceback (most recent call last):
File , line unknown, in ##137
TypeError: Equal() takes at least 2147483647 arguments (2 given)
*Assert.Equal[type(1)](1, 1)
*
Should I file a CodePlex issue for that rather unintuitive error message?
--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Assemblies loaded by default
When I run IronPython interactively, I automatically get System.dll loaded: PS f:\IronPython-2.0A8 *.\ipy.exe* IronPython 2.0 Alpha (2.0.0.800) on .NET 2.0.50727.1433 Copyright (c) Microsoft Corporation. All rights reserved. *import System* *System.DateTime* type 'DateTime' But when I run an IronPython script through the hosting api, I don't: C# source contains: SourceUnit source = PythonEngine.CurrentEngine.CreateScriptSourceFromFile( Class1.py); IScriptScope m = PythonEngine.CurrentEngine.CreateScope(); PythonEngine.CurrentEngine.Execute(m, source); Class1.py contains: import clr import System Output is: IronPython.Runtime.Exceptions.ImportException : No module named System What do I need to do to my embedding host to make sure it's preloading the same assemblies as the interactive console? -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Assemblies loaded by default
Ah, excellent; this helped me to find the source file: src\IronPython\Hosting\PythonCommandLine.cs It actually loads the assemblies for both string and System.Diagnostics.Debug. Thanks! On Feb 3, 2008 11:41 PM, Srivatsn Narayanan [EMAIL PROTECTED] wrote: I think this is all the IronPython interepreter loads: ScriptDomainManager.CurrentManager.LoadAssembly( typeof(string).Assembly); //mscorlib.dll ScriptDomainManager.CurrentManager.LoadAssembly( typeof(System.Diagnostics.Debug).Assembly); //System.dll Srivatsn -- *From:* [EMAIL PROTECTED] [ [EMAIL PROTECTED] On Behalf Of Curt Hagenlocher [ [EMAIL PROTECTED] *Sent:* Sunday, February 03, 2008 9:38 PM *To:* Discussion of IronPython *Subject:* [IronPython] Assemblies loaded by default When I run IronPython interactively, I automatically get System.dllloaded: PS f:\IronPython-2.0A8 *.\ipy.exe* IronPython 2.0 Alpha (2.0.0.800) on .NET 2.0.50727.1433 Copyright (c) Microsoft Corporation. All rights reserved. *import System* *System.DateTime* type 'DateTime' But when I run an IronPython script through the hosting api, I don't: C# source contains: SourceUnit source = PythonEngine.CurrentEngine.CreateScriptSourceFromFile (Class1.py); IScriptScope m = PythonEngine.CurrentEngine.CreateScope(); PythonEngine.CurrentEngine.Execute(m, source); Class1.py contains: import clr import System Output is: IronPython.Runtime.Exceptions.ImportException : No module named System What do I need to do to my embedding host to make sure it's preloading the same assemblies as the interactive console? -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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] Decorators on classes
Oh! I didn't realize that about 2.6. There is indeed a big difference between a Python runtime decorator and a .NET compile time attribute; in fact, the similarities are superficial at best. .NET attributes are totally static, so there's no way to modify a .NET class definition to add them. The IronPython engine would have to recognize particular class-level Pythonic annotations and use that information to emit a new CLR class to represent the Python class. It already emits CLR classes as needed to represent Python classes. By as needed, I mean that a specific CLR base class plus a specific set of CLR interfaces will uniquely determine a class to be emitted by IronPython. This class is cached so that -- once generated -- any new Python class definition that matches this set of (CLR base class plus interfaces) will reuse the same CLR class definition. What you'd have to change is to put the class-level attributes onto the generated CLR class, then change caching so that the key is (CLR base class plus interfaces plus attributes). It's definitely doable, but raises intriguing questions about purity. And you'd also need to consider the impact on the larger DLR. Method-level attributes are an entirely different matter. On Feb 4, 2008 10:58 AM, Michael Foord [EMAIL PROTECTED] wrote: Class decorators will be in Python 2.6 - but there is a big difference between a Python runtime decorator and .NET compile time attributes. Is it possible to attach attributes at runtime using the reflection API? Michael http://www.manning.com/foord Keith J. Farmer wrote: Can I resurrect this forgotten soul? http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPythonWorkItemId=13583 Having just finished working on LINQ to SQL, I'm convinced that future LINQ providers will be making heavy use of .NET attributes not just on properties, but on classes themselves. Being able to express these attributes in IronPython is a tremendous bonus. That there be one and only one way to express these is paramount. ___ 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 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Exporting Python code as an assembly
After a bit of spare-time hacking this weekend, I've got a proof-of-concept program that takes a Python class and exports it as a (statically-defined) assembly. It uses Pythonic function annotations to signal attributes and input and output types to the wrapper generator. You end up with something like this def Test(object): @ClrAttribute(Xunit.FactAttribute) def WorthlessTest(self): Xunit.Assert.Equal[type(1)](1, 1) @ClrAccepts(System.String, System.Int32) @ClrReturns(System.Int32) def CalculateValue(self, s, i): return len(s) + i The program takes this source and spits out a DLL containing the class Test which implements WorthlessTest and CalculateValue. The class itself contains a reference to the actual Python object, and each of the public functions simply delegates to the Pythonic implementation. I'm still working on cleaning up the source a little before releasing it, but was wondering if anyone had some feedback on the design as described so far. What should be changed or implemented in order for this to be more useful to you? Thanks, -Curt -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Exporting Python code as an assembly
The assemblies call into the IronPython engine (version 2) to load and execute the script. Currently, the script is loaded from the file system, but I'd eventually like to support embedding any required scripts as resources in the assembly, so that the whole thing can be distributed as a single neat package. On Feb 4, 2008 10:55 AM, Michael Foord [EMAIL PROTECTED] wrote: The interface is pretty much exactly what I had in mind for a similar system. What do the statically defined assemblies do - do they call into the IronPython engine - and if so, for IronPython 1 or 2? If not then are you just compiling Python to static assemblies? To my mind the former is more interesting than the latter... (Although both are interesting of course...) Michael http://www.manning.com/foord Curt Hagenlocher wrote: After a bit of spare-time hacking this weekend, I've got a proof-of-concept program that takes a Python class and exports it as a (statically-defined) assembly. It uses Pythonic function annotations to signal attributes and input and output types to the wrapper generator. You end up with something like this def Test(object): @ClrAttribute(Xunit.FactAttribute) def WorthlessTest(self): Xunit.Assert.Equal[type(1)](1, 1) @ClrAccepts(System.String, System.Int32) @ClrReturns(System.Int32) def CalculateValue(self, s, i): return len(s) + i The program takes this source and spits out a DLL containing the class Test which implements WorthlessTest and CalculateValue. The class itself contains a reference to the actual Python object, and each of the public functions simply delegates to the Pythonic implementation. I'm still working on cleaning up the source a little before releasing it, but was wondering if anyone had some feedback on the design as described so far. What should be changed or implemented in order for this to be more useful to you? Thanks, -Curt -- Curt Hagenlocher [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ 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 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Decorators on classes
Here's an implementation idea that may require less work at the expense of less-elegant syntax. class X(object, clr.AttributeBase(System.SerializableAttribute)) pass NewTypeMaker would look for base classes of whatever built-in type is returned by clr.AttributeBase and would use that information to decorate the generated type. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Exporting Python code as an assembly
On Feb 4, 2008 11:07 AM, Michael Foord [EMAIL PROTECTED] wrote: Curt Hagenlocher wrote: The assemblies call into the IronPython engine (version 2) to load and execute the script. Currently, the script is loaded from the file system, but I'd eventually like to support embedding any required scripts as resources in the assembly, so that the whole thing can be distributed as a single neat package. Great - you beat me to it. :-) If you make this open source then I'll be happy to help on it. I'm thinking of putting it on Codeplex. Be warned that I prefer ILGenerator to CodeDOM, probably because I'm reliving the glory years of assembly language programming. 6502 4eva! :) The current implementation is written in Python. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Decorators on classes
On Feb 4, 2008 3:29 PM, Michael Foord [EMAIL PROTECTED] wrote: It is rather ugly. :-) Thanks; I thought so myself. Would this technique have anything to offer for attributes on methods and properties (etc). It's hard to see how, but it's been a while since I looked at that part of the source. I'm pretty sure that the CLR class itself needs to be emitted entirely by the contents of the one class statement -- and well before the first method is defined. Which means that none of the properties or methods of the class could influence codegen. Frankly, I don't think that attributes on methods or properties are realistic -- at least, not as part of the original class definition. What I think you'd be looking at is the ability to define a class wrapper that wraps the initially-defined dynamic class with a new statically-defined class that allows you to put attributes on methods and properties. Hmm... where have I heard that recently... :) -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Decorators on classes
On Feb 4, 2008 2:27 PM, Dino Viehland [EMAIL PROTECTED] wrote: As other people have pointed out decorators are a runtime concept and I don't think we get to change that. So consider a class decorator You could theoretically have a slightly alternate parsing mode that recognizes a specific class decorator name before the class definition is closed (and therefore before codegen). In other words, the following definition @ClrAttribute(System.SerializableAttribute) class X(ISomething, object): treats the decorator differently if it matches one of the special-case names. The change in parsing could be triggered by something like from future import clr_hacks. On Feb 4, 2008 2:32 PM, Keith J. Farmer [EMAIL PROTECTED] wrote: CPythonista outrage over not being able to read something they could never run is rather silly. :) You're clearly having trouble envisioning the following Slashdot headline: Microsoft inflicts 'embrace and extend' on Python. Silly or not, perceptions are hugely important. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Exporting Python code as an assembly
On Feb 5, 2008 5:50 AM, Giles Thomas [EMAIL PROTECTED] wrote: Would it be hugely tricky to get it working in IP 1.1 as well as 2.0, do you think? I'm imagining some kind of --target:1.1 flag to the tool. I can't imagine that this would be a problem. It's been a while since I played with the hosting-level interfaces of 1.1, but I seem to recall that (at the level in question) they're largely isomorphic with what's currently in 2.0. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Exporting Python code as an assembly
On Feb 5, 2008 9:15 AM, Pigneri, Rocco [EMAIL PROTECTED] wrote: To make using these UI controls easier, it would be great if property statements could be turned into static properties either automatically or via a flag. Yes, one of the thoughts I had was that you should be able to run such a tool in a greedy mode (which tries to wrap everything) and a precision mode (which only wraps what you tell it to). -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Exporting Python code as an assembly
You can download my work-in-progress from http://hagenlocher.org/software/ClrWrapper.zip The source consists of the three files ClrBuilder.py, ClrWrapper.py and MakeModule.py. There are also two demo files: Xtest.py and WcfServer.py. The program can currently be run as follows: PS F:\IronPython-2.0A8 *.\ipy.exe MakeModule.py Xtest.py* This will produce a file called Xtest.dll. At this point, the application doesn't require any of the standard Python library files. It's only been tried with the Alpha 8 binaries -- and in fact, the hosting interfaces for IronPython still aren't entirely stable so there's no guarantee that the DLLs produced will work with Alpha 9. Xtest.py is a trivial application that implements a single xunit-compatible unit test PS F:\IronPython-2.0A8 *.\xunit.console.exe Xtest.dll /noshadow* . Total tests: 1, Failures: 0, Skipped: 0, Time: 0.275 seconds WcfServer.py theoretically implements a WCF server, though I haven't gotten as far as actually testing the output yet. (The generated code passes the eyeball compiler.) Code quality is unimpressive; your mileage may vary. And I've got to get back to my day job for a few hours now :). -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Exporting Python code as an assembly
On Feb 5, 2008 1:24 PM, Tim Riley [EMAIL PROTECTED] wrote: I was testing out the code provided and when I tested it using the example I got the following error. [snip] IOError: Could not add reference to assembly xunit.dll Sorry, you need xunit for that -- it's not part of IronPython. Xunit is a kind of next generation NUnit for unit testing, and I recommend it highly. You can find it at http://www.codeplex.com/xunit -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Easy Access to the DLR from C#
For the five people here who aren't on it, the following link was posted to the IronRuby mailing list: http://blogs.msdn.com/charlie/archive/2008/01/25/future-focus.aspx -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] staticmethod / classmethod and setattr
This is really more of a Python question than an IronPython question, but I'm not currently on any non-Iron Python lists. :) The following definition results in an error under both CPython 2.5 and IronPython. Decorating a method as static or class prevents attributes being set on the resulting definition. def decorate(obj): obj.decorated = True return obj class X: @decorate @staticmethod def foo(): pass Does anyone know the why of this behavior? I can work around this problem by declaring the decorators in the opposite order, but it seems like an odd imposition to put on the consumers of the code in question. I'm worried that I'm missing something about the expected semantics of these standard functions. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Exporting Python code as an assembly
I've created a project on CodePlex now. It's still in setup mode; send me email and I'll add you to the project there. The only real change I've made since the Feb 5 version are support for static and class methods. And if the class defines a static or class method named Main, I set that as the entry point. On Feb 5, 2008 12:00 PM, Curt Hagenlocher [EMAIL PROTECTED] wrote: You can download my work-in-progress from http://hagenlocher.org/software/ClrWrapper.zip The source consists of the three files ClrBuilder.py, ClrWrapper.py and MakeModule.py. There are also two demo files: Xtest.py and WcfServer.py. The program can currently be run as follows: PS F:\IronPython-2.0A8 *.\ipy.exe MakeModule.py Xtest.py* This will produce a file called Xtest.dll. At this point, the application doesn't require any of the standard Python library files. It's only been tried with the Alpha 8 binaries -- and in fact, the hosting interfaces for IronPython still aren't entirely stable so there's no guarantee that the DLLs produced will work with Alpha 9. Xtest.py is a trivial application that implements a single xunit-compatible unit test PS F:\IronPython-2.0A8 *.\xunit.console.exe Xtest.dll /noshadow* . Total tests: 1, Failures: 0, Skipped: 0, Time: 0.275 seconds WcfServer.py theoretically implements a WCF server, though I haven't gotten as far as actually testing the output yet. (The generated code passes the eyeball compiler.) Code quality is unimpressive; your mileage may vary. And I've got to get back to my day job for a few hours now :). -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] PythonType.CreateInstance not calling __init__
The following code creates a Python class foo with a single method __init__. It then gets the class object. string code = class foo(object):\n\tdef __init__(self):\n\t\tprint 'hello world'\n; SourceUnit scriptSource = PythonEngine.CurrentEngine.CreateScriptSourceFromString(code, SourceCodeKind.File); IScriptScope scope = PythonEngine.CurrentEngine.CreateScope(); PythonEngine.CurrentEngine.Execute(scope, scriptSource); object obj2; scope.TryGetVariable(foo, out obj2); PythonType theClass = obj2 as PythonType; I then use PythonType.CreateInstance to create the object. LanguageContext language = LanguageContext.FromEngine( PythonEngine.CurrentEngine); Scope scope2 = new Scope(language); CodeContext context = new CodeContext(scope2, language); object foo = theClass.CreateInstance(context, new object[0]); At this point foo contains an object with the Python type foo. However, the __init__ method was never called. What am I doing wrong? -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] PythonType.CreateInstance not calling __init__
A little more poking suggests that CreateInstance._ctor is really the equivalent of __new__ and not __init__. I changed the code to say PythonTypeOps.TypeCaller ctor = new PythonTypeOps.TypeCaller(theClass); object foo = ctor.Call(context); and all is now well with the world. On Feb 9, 2008 9:17 AM, Curt Hagenlocher [EMAIL PROTECTED] wrote: The following code creates a Python class foo with a single method __init__. It then gets the class object. string code = class foo(object):\n\tdef __init__(self):\n\t\tprint 'hello world'\n; SourceUnit scriptSource = PythonEngine.CurrentEngine.CreateScriptSourceFromString(code, SourceCodeKind.File); IScriptScope scope = PythonEngine.CurrentEngine.CreateScope(); PythonEngine.CurrentEngine.Execute(scope, scriptSource); object obj2; scope.TryGetVariable(foo, out obj2); PythonType theClass = obj2 as PythonType; I then use PythonType.CreateInstance to create the object. LanguageContext language = LanguageContext.FromEngine( PythonEngine.CurrentEngine); Scope scope2 = new Scope(language); CodeContext context = new CodeContext(scope2, language); object foo = theClass.CreateInstance(context, new object[0]); At this point foo contains an object with the Python type foo. However, the __init__ method was never called. What am I doing wrong? -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] urllib.urlretrieve with IronPython 2a8
This is in Codeplex as work item 10518
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=10518
The item was marked as a duplicate of 10825, which has been marked as
resolved in 1.1.1. However, I am able to reproduce the problem with 1.1,
1.1.1 and alpha 8.
On Feb 18, 2008 10:54 AM, Dino Viehland [EMAIL PROTECTED]
wrote:
Certainly sounds like a bug - did this work before alpha 8?
-Original Message-
From: [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Sunday, February 17, 2008 6:27 AM
To: Discussion of IronPython
Subject: [IronPython] urllib.urlretrieve with IronPython 2a8
IronPython 2.0 Alpha (2.0.0.800) on .NET 2.0.50727.1433
Copyright (c) Microsoft Corporation. All rights reserved.
import urllib
urllib.urlretrieve('
http://python-twitter.googlecode.com/files/python-twitte
r-0.5.tar.gz', 'python-twitter.tar.gz')
Traceback (most recent call last):
File System, line unknown, in Read
File System, line unknown, in Receive
File System, line unknown, in Receive
File c:\Python24\Lib\urllib.py, line 248, in retrieve
File System, line unknown, in Read
File , line unknown, in ##269
File c:\Python24\Lib\urllib.py, line 89, in urlretrieve
IOError: Unable to read data from the transport connection: Cannot
access a disp
osed object.
Object name: 'System.Net.Sockets.Socket'..
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on
win32
Type help, copyright, credits or license for more information.
import urllib
urllib.urlretrieve('
http://python-twitter.googlecode.com/files/python-twitte
r-0.5.tar.gz', 'python-twitter.tar.gz')
('python-twitter.tar.gz', httplib.HTTPMessage instance at 0x01864E40)
___
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
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] urllib.urlretrieve with IronPython 2a8
I should amend this to say that I can *inconsistently* reproduce it. The
URL in the original sample always fails with that error, but
http://www.microsoft.com has been succeeding for me more often than not.
On Feb 18, 2008 2:38 PM, Curt Hagenlocher [EMAIL PROTECTED] wrote:
This is in Codeplex as work item 10518
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=10518
The item was marked as a duplicate of 10825, which has been marked as
resolved in 1.1.1. However, I am able to reproduce the problem with 1.1,
1.1.1 and alpha 8.
On Feb 18, 2008 10:54 AM, Dino Viehland [EMAIL PROTECTED]
wrote:
Certainly sounds like a bug - did this work before alpha 8?
-Original Message-
From: [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Sunday, February 17, 2008 6:27 AM
To: Discussion of IronPython
Subject: [IronPython] urllib.urlretrieve with IronPython 2a8
IronPython 2.0 Alpha (2.0.0.800) on .NET 2.0.50727.1433
Copyright (c) Microsoft Corporation. All rights reserved.
import urllib
urllib.urlretrieve('
http://python-twitter.googlecode.com/files/python-twitte
r-0.5.tar.gz', 'python-twitter.tar.gz')
Traceback (most recent call last):
File System, line unknown, in Read
File System, line unknown, in Receive
File System, line unknown, in Receive
File c:\Python24\Lib\urllib.py, line 248, in retrieve
File System, line unknown, in Read
File , line unknown, in ##269
File c:\Python24\Lib\urllib.py, line 89, in urlretrieve
IOError: Unable to read data from the transport connection: Cannot
access a disp
osed object.
Object name: 'System.Net.Sockets.Socket'..
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on
win32
Type help, copyright, credits or license for more information.
import urllib
urllib.urlretrieve('
http://python-twitter.googlecode.com/files/python-twitte
r-0.5.tar.gz', 'python-twitter.tar.gz')
('python-twitter.tar.gz', httplib.HTTPMessage instance at 0x01864E40)
___
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
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] urllib.urlretrieve with IronPython 2a8
On Feb 18, 2008 3:11 PM, Michael Foord [EMAIL PROTECTED] wrote:
On 18/02/2008, Curt Hagenlocher [EMAIL PROTECTED] wrote:
I should amend this to say that I can *inconsistently* reproduce it. The URL
in the original sample always fails with that error, but
http://www.microsoft.com
has been succeeding for me more often than not.
Hmmm... could be a difference in the default socket timeout, or when the
socket
object is created (?). Whatever the cause I think the bug should be reopened.
One difference between the two is that www.microsoft.com actually has
an HTTP redirect involved, while the failing version does not.
Here's a simpler way to reproduce the problem:
import httplib
h = httplib.HTTP('www.google.com')
h.putrequest('GET', '/')
h.endheaders()
a, b, c = h.getreply()
fp = h.getfile()
fp.read(1024*8)
This fails with the same disposed object error, but replacing google
with microsoft makes it work correctly. Any business/political
implications thereof are left as an exercise to the reader ;).
--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] urllib.urlretrieve with IronPython 2a8
On Feb 18, 2008 3:34 PM, Curt Hagenlocher [EMAIL PROTECTED] wrote:
Here's a simpler way to reproduce the problem:
import httplib
h = httplib.HTTP('www.google.com')
h.putrequest('GET', '/')
h.endheaders()
a, b, c = h.getreply()
fp = h.getfile()
fp.read(1024*8)
Turning debugging on at a Python level reveals a crucial difference
between the sites. Sites for which the HTTP header contains
Connection: close fail, while sites for which the HTTP header
contains Connection: keep-alive stay open.
Is it possible that CPython's socket.close method won't actually close
the socket while there's still a makefile'd file attacked to the
underlying OS socket? And that IronPython's will? Because that's the
only explanation I can come up with.
--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] urllib.urlretrieve with IronPython 2a8
On Feb 18, 2008 4:12 PM, Curt Hagenlocher [EMAIL PROTECTED] wrote: Is it possible that CPython's socket.close method won't actually close the socket while there's still a makefile'd file attacked to the underlying OS socket? And that IronPython's will? Because that's the only explanation I can come up with. It is and it will. CPython basically dups the socket handle when you call makefile, while IronPython does not. That's the cause of this bug. By the way, the docstring for the IronPython socket class claims that makefile isn't implemented. This is apparently only half-true. :P -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] ironptython xml-rpc how?
On Thu, Feb 21, 2008 at 4:35 AM, [EMAIL PROTECTED] wrote:
File System, line unknown, in Read
IOError: Unable to read data from the transport connection: Cannot access
a disposed object.
Object name: 'System.Net.Sockets.Socket'..
This is a known issue in IronPython. You can work around it by using
Seo's implementation of the socket module. If you're not already
using it, download IronPython Community Edition from
http://fepy.sourceforge.net. Then to replace the built-in socket
module, you'll need to do something like this:
import os, sys, imp
sys.modules['socket'] = module = imp.new_module('socket')
execfile('..\\lib\\socket.py', module.__dict__)
import xmlrpclib
server = xmlrpclib.Server('http://localhost:4567')
month = server.getMonth(2002, 8)
I've tested this and it works.
(Code shamelessly stolen from Birsch's recent BeautifulSoup example.)
--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] returning inherited classes to .NET
The page in question doesn't seem to show what you describe -- deriving a Python class from a C# class. Maybe you could show us your sample code? On Thu, Feb 21, 2008 at 7:39 PM, Howland-Rose, Kyle [EMAIL PROTECTED] wrote: Hi all, I am following http://www.ironpython.info/index.php/Using_Python_Classes_from_.NET but using VB. In VB I declare a class and derive a python 1.1 class from it but when I return it I get the exception: Unable to cast object of type ' IronPython.NewTypes.WebControlLibrary.ChildControl_1' to type ' WebControlLibrary.ChildControl'. The page referenced above just seems to cast the python class instance to the C# class instance but this does not work for me in VB. Any help would be appreciated :) Thanks, Kyle Allens Arthur Robinson online: http://www.aar.com.au This email is confidential and may be subject to legal or other professional privilege. It is also subject to copyright. If you have received it in error, confidentiality and privilege are not waived and you must not disclose or use the information in it. Please notify the sender by return email and delete it from your system. Any personal information in this email must be handled in accordance with the Privacy Act 1988 (Cth). * Allens Arthur Robinson online: http://www.aar.com.au This email is confidential and may be subject to legal or other professional privilege. It is also subject to copyright. If you have received it in error, confidentiality and privilege are not waived and you must not disclose or use the information in it. Please notify the sender by return email and delete it from your system. Any personal information in this email must be handled in accordance with the Privacy Act 1988 (Cth). * ___ 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 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] FW: returning inherited classes to .NET
My apologies; I wasn't reading the code correctly. That's probably a sign
that I should be going to bed. :) Have you tried simplifying your version
just a little bit by running it directly rather than through
ASP.NEThttp://asp.net/
?
On Thu, Feb 21, 2008 at 8:43 PM, Howland-Rose, Kyle
[EMAIL PROTECTED] wrote:
Hi Curt,
Thanks for replying. When I view the link I see the following:
The .NET code creates the Test class and then runs the python code
which imports the Test class a subclasses it to create python class
X.
Class X is then called and cast to type Test and assigned to the
value obj.
Is this what you are looking at?
My code is pretty much identical. The VB looks like:
Public MustInherit Class ChildControl
Public Function Control() As WebControl
Return Nothing
End Function
Public Function GetValue() As String
Return Nothing
End Function
Public Function SetValue(ByVal value As Object) As String
Return Nothing
End Function
End Class
Class IPReflection
Private Shared Instance As IPReflection = Nothing
Private PyEngine As PythonEngine
Private PyModule As EngineModule
Public Shared Function Inst() As IPReflection
If Instance Is Nothing Then
Instance = New IPReflection
End If
Return Instance
End Function
Private Sub New()
Dim path As String = HttpContext.Current.Request.MapPath(.)
PyEngine = New PythonEngine
PyEngine.AddToPath(path)
PyModule = PyEngine.CreateModule
PyEngine.DefaultModule = PyModule
PyEngine.ExecuteFile(HttpContext.Current.Request.MapPath(CustomControls
.py))
End Sub
Public Function GetChildControl() As ChildControl
Return
CType(Operations.Ops.Call(PyModule.Globals(GetControl)), ChildControl)
End Function
End Class
And the python looks like:
import clr
import sys
clr.AddReference('System')
import System
sys.path.append(sys.path[0] + /bin)
clr.AddReferenceToFile(WebControlLibrary.dll)
clr.AddReference('System.Web')
from System.Web.UI.WebControls import Label
from WebControlLibrary import ChildControl
class LabelChildControl(ChildControl):
def __init__(self):
self.control = Label()
def Control(self):
return self.control
def GetControl():
return LabelChildControl()
Thanks again,
Kyle
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Curt
Hagenlocher
Sent: Friday, 22 February 2008 3:08 PM
To: Discussion of IronPython
Subject: Re: [IronPython] returning inherited classes to .NET
The page in question doesn't seem to show what you describe -- deriving
a Python class from a C# class. Maybe you could show us your sample
code?
On Thu, Feb 21, 2008 at 7:39 PM, Howland-Rose, Kyle
[EMAIL PROTECTED] wrote:
Hi all,
I am following
http://www.ironpython.info/index.php/Using_Python_Classes_from_.NET
http://www.ironpython.info/index.php/Using_Python_Classes_from_.NET
but using VB.
In VB I declare a class and derive a python 1.1 class from it
but when I return it I get the exception:
Unable to cast object of type
'IronPython.NewTypes.WebControlLibrary.ChildControl_1' to type
'WebControlLibrary.ChildControl'.
The page referenced above just seems to cast the python class
instance to the C# class instance but this does not work for me in VB.
Any help would be appreciated :)
Thanks,
Kyle
Allens Arthur Robinson online: http://www.aar.com.au
http://www.aar.com.au/
This email is confidential and may be subject to legal or other
professional privilege. It is also subject to copyright. If you have
received it in error, confidentiality and privilege are not waived and
you must not disclose or use the information in it. Please notify the
sender by return email and delete it from your system. Any personal
information in this email must be handled in accordance with the Privacy
Act 1988 (Cth).
*
Allens Arthur Robinson online: http://www.aar.com.au
http://www.aar.com.au/
This email is confidential and may be subject to legal or other
professional privilege. It is also subject to copyright. If you have
received it in error, confidentiality and privilege are not waived and
you must not disclose or use the information in it. Please notify the
sender by return email and delete it from your system. Any personal
information in this email must be handled in accordance with the Privacy
Act 1988 (Cth
Re: [IronPython] FW: FW: FW: returning inherited classes to .NET
Ah, no. I was thinking that you would modify your VB code to launch it as a
console app (for instance) rather than from inside of ASP.NET -- and see if
you still get the same error.
On Thu, Feb 21, 2008 at 10:07 PM, Howland-Rose, Kyle
[EMAIL PROTECTED] wrote:
Thanks for your help so late Curt (not that I need a quick answer at
all).
I am sure I am missing something big-time here and talking as
cross-purposes, but, to my mind the reason I don't have a problem when
running from the command line is because all I am doing is running the
ipy.exe on the file which loads some assemblies, creates a class
definition and a function definition and then terminates without even
instantiating the class. Is this what you mean by running it directly?
Thanks again,
Kyle
--
*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Curt Hagenlocher
*Sent:* Friday, 22 February 2008 4:55 PM
*To:* Discussion of IronPython
*Subject:* Re: [IronPython] FW: FW: returning inherited classes to .NET
If you're only getting the error under ASP.NET http://asp.net/, then
it's highly likely that you're loading multiple copies of the same assembly,
which is why the CLR can't cast your Python class back to the VB base -- it
literally considers them to be two different classes. This may be related
to the way ASP.NET http://asp.net/ makes shadow copies of your files,
but there could be other reasons as well (none of which, unfortunately, come
to mind right now).
Using an interface instead of a base class would give you the same
results.
On Thu, Feb 21, 2008 at 9:44 PM, Howland-Rose, Kyle
[EMAIL PROTECTED] wrote:
It runs fine from the command line but then it does not do much ...
yet. For the moment I am simplifying it by removing IP :(
I wanted to so some moderately heavy reflection which to my thinking
should be easier from IP but I will use VB for now.
I assume I *should* be able to return a derived python class to VB?
Alternatively I could implement an interface. How can IP implement a .NET
interface?
(All pointers to pre-existing doco warmly received :)
Thanks
Kyle
--
*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Curt Hagenlocher
*Sent:* Friday, 22 February 2008 4:29 PM
*To:* Discussion of IronPython
*Subject:* Re: [IronPython] FW: returning inherited classes to .NET
My apologies; I wasn't reading the code correctly. That's probably a
sign that I should be going to bed. :) Have you tried simplifying your
version just a little bit by running it directly rather than through
ASP.NET http://asp.net/?
On Thu, Feb 21, 2008 at 8:43 PM, Howland-Rose, Kyle
[EMAIL PROTECTED] wrote:
Hi Curt,
Thanks for replying. When I view the link I see the following:
The .NET code creates the Test class and then runs the python code
which imports the Test class a subclasses it to create python class
X.
Class X is then called and cast to type Test and assigned to the
value obj.
Is this what you are looking at?
My code is pretty much identical. The VB looks like:
Public MustInherit Class ChildControl
Public Function Control() As WebControl
Return Nothing
End Function
Public Function GetValue() As String
Return Nothing
End Function
Public Function SetValue(ByVal value As Object) As String
Return Nothing
End Function
End Class
Class IPReflection
Private Shared Instance As IPReflection = Nothing
Private PyEngine As PythonEngine
Private PyModule As EngineModule
Public Shared Function Inst() As IPReflection
If Instance Is Nothing Then
Instance = New IPReflection
End If
Return Instance
End Function
Private Sub New()
Dim path As String = HttpContext.Current.Request.MapPath(.)
PyEngine = New PythonEngine
PyEngine.AddToPath(path)
PyModule = PyEngine.CreateModule
PyEngine.DefaultModule = PyModule
PyEngine.ExecuteFile(HttpContext.Current.Request.MapPath
(CustomControls
.py))
End Sub
Public Function GetChildControl() As ChildControl
Return
CType(Operations.Ops.Call(PyModule.Globals(GetControl)),
ChildControl)
End Function
End Class
And the python looks like:
import clr
import sys
clr.AddReference('System')
import System
sys.path.append(sys.path[0] + /bin)
clr.AddReferenceToFile(WebControlLibrary.dll)
clr.AddReference('System.Web')
from System.Web.UI.WebControls import Label
from WebControlLibrary import ChildControl
class LabelChildControl(ChildControl):
def __init__(self):
self.control = Label()
def Control(self):
return self.control
def GetControl
Re: [IronPython] FW: FW: FW: returning inherited classes to .NET
I built a test executable and was able to reproduce this. And when I
changed
clr.AddReferenceToFile(WebControlLibrary.dll)
to
clr.AddReference(WebControlLibrary)
it worked as expected.
On Fri, Feb 22, 2008 at 6:02 AM, Curt Hagenlocher [EMAIL PROTECTED]
wrote:
Ah, no. I was thinking that you would modify your VB code to launch it as
a console app (for instance) rather than from inside of
ASP.NEThttp://asp.net/-- and see if you still get the same error.
On Thu, Feb 21, 2008 at 10:07 PM, Howland-Rose, Kyle
[EMAIL PROTECTED] wrote:
Thanks for your help so late Curt (not that I need a quick answer at
all).
I am sure I am missing something big-time here and talking as
cross-purposes, but, to my mind the reason I don't have a problem when
running from the command line is because all I am doing is running the
ipy.exe on the file which loads some assemblies, creates a class
definition and a function definition and then terminates without even
instantiating the class. Is this what you mean by running it
directly?
Thanks again,
Kyle
--
*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Curt Hagenlocher
*Sent:* Friday, 22 February 2008 4:55 PM
*To:* Discussion of IronPython
*Subject:* Re: [IronPython] FW: FW: returning inherited classes to .NET
If you're only getting the error under ASP.NET http://asp.net/, then
it's highly likely that you're loading multiple copies of the same assembly,
which is why the CLR can't cast your Python class back to the VB base -- it
literally considers them to be two different classes. This may be related
to the way ASP.NET http://asp.net/ makes shadow copies of your files,
but there could be other reasons as well (none of which, unfortunately, come
to mind right now).
Using an interface instead of a base class would give you the same
results.
On Thu, Feb 21, 2008 at 9:44 PM, Howland-Rose, Kyle
[EMAIL PROTECTED] wrote:
It runs fine from the command line but then it does not do much ...
yet. For the moment I am simplifying it by removing IP :(
I wanted to so some moderately heavy reflection which to my thinking
should be easier from IP but I will use VB for now.
I assume I *should* be able to return a derived python class to VB?
Alternatively I could implement an interface. How can IP implement a .NET
interface?
(All pointers to pre-existing doco warmly received :)
Thanks
Kyle
--
*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Curt Hagenlocher
*Sent:* Friday, 22 February 2008 4:29 PM
*To:* Discussion of IronPython
*Subject:* Re: [IronPython] FW: returning inherited classes to .NET
My apologies; I wasn't reading the code correctly. That's probably
a sign that I should be going to bed. :) Have you tried simplifying your
version just a little bit by running it directly rather than through
ASP.NET http://asp.net/?
On Thu, Feb 21, 2008 at 8:43 PM, Howland-Rose, Kyle
[EMAIL PROTECTED] wrote:
Hi Curt,
Thanks for replying. When I view the link I see the following:
The .NET code creates the Test class and then runs the python code
which imports the Test class a subclasses it to create python
class
X.
Class X is then called and cast to type Test and assigned to the
value obj.
Is this what you are looking at?
My code is pretty much identical. The VB looks like:
Public MustInherit Class ChildControl
Public Function Control() As WebControl
Return Nothing
End Function
Public Function GetValue() As String
Return Nothing
End Function
Public Function SetValue(ByVal value As Object) As String
Return Nothing
End Function
End Class
Class IPReflection
Private Shared Instance As IPReflection = Nothing
Private PyEngine As PythonEngine
Private PyModule As EngineModule
Public Shared Function Inst() As IPReflection
If Instance Is Nothing Then
Instance = New IPReflection
End If
Return Instance
End Function
Private Sub New()
Dim path As String = HttpContext.Current.Request.MapPath(.)
PyEngine = New PythonEngine
PyEngine.AddToPath(path)
PyModule = PyEngine.CreateModule
PyEngine.DefaultModule = PyModule
PyEngine.ExecuteFile(HttpContext.Current.Request.MapPath
(CustomControls
.py))
End Sub
Public Function GetChildControl() As ChildControl
Return
CType(Operations.Ops.Call(PyModule.Globals(GetControl)),
ChildControl)
End Function
End Class
And the python looks like:
import clr
import sys
clr.AddReference('System')
import System
Re: [IronPython] Hosting IronPython 2.0 Alpha 8
Here's a snippet that I'm using under A8. I can't promise that everything
is right, but it works correctly for how I'm using it.
// Load Class1.py into a new scope
SourceUnit source =
PythonEngine.CurrentEngine.CreateScriptSourceFromFile(Class1.py);
IScriptScope m = PythonEngine.CurrentEngine.CreateScope();
PythonEngine.CurrentEngine.Execute(m, source);
// Get the class object for Class1
object value;
m.TryGetVariable(Class1, out value);
object theClass = (value as PythonType);
// Instantiate Class1
LanguageContext language = LanguageContext.FromEngine(
PythonEngine.CurrentEngine);
Scope scope = new Scope(language);
CodeContext context = new CodeContext(scope, language);
object theValue = new PythonTypeOps.TypeCaller(theClass).Call(context2,
new object[0]);
// Call the Clone function on the new instance
object theFunction =
PythonEngine.CurrentEngine.Operations.GetMember(theValue,
Clone);
object result = PythonEngine.CurrentEngine.Operations.Call(theFunction,
new object[] { s, i });
result = PythonEngine.CurrentEngine.Operations.ConvertToint(result);
On Fri, Feb 22, 2008 at 6:51 AM, Fernando Correia
[EMAIL PROTECTED] wrote:
I am trying out IronPython hosting on C#. I found out an article about
hosting with 2.0 Alpha 6:
http://blogs.msdn.com/rdawson/archive/2007/11/29/hosting-ironpython-2-0-alpha-6-via-the-dlr.aspx
But those instructions don't seem to work with 2.0 Alpha 8. I've searched
the Web but I couldn't find updated instructions.
If someone can give me a pointer, I'd appreciate.
___
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] Hosting IronPython 2.0 Alpha 8
Sorry... the type of theClass should actually be PythonType and not
object.
On Fri, Feb 22, 2008 at 8:18 AM, Curt Hagenlocher [EMAIL PROTECTED]
wrote:
Here's a snippet that I'm using under A8. I can't promise that everything
is right, but it works correctly for how I'm using it.
// Load Class1.py into a new scope
SourceUnit source =
PythonEngine.CurrentEngine.CreateScriptSourceFromFile(Class1.py);
IScriptScope m = PythonEngine.CurrentEngine.CreateScope();
PythonEngine.CurrentEngine.Execute(m, source);
// Get the class object for Class1
object value;
m.TryGetVariable(Class1, out value);
object theClass = (value as PythonType);
// Instantiate Class1
LanguageContext language = LanguageContext.FromEngine(
PythonEngine.CurrentEngine);
Scope scope = new Scope(language);
CodeContext context = new CodeContext(scope, language);
object theValue = new PythonTypeOps.TypeCaller(theClass).Call(context2,
new object[0]);
// Call the Clone function on the new instance
object theFunction =
PythonEngine.CurrentEngine.Operations.GetMember(theValue,
Clone);
object result = PythonEngine.CurrentEngine.Operations.Call(theFunction,
new object[] { s, i });
result = PythonEngine.CurrentEngine.Operations.ConvertToint(result);
On Fri, Feb 22, 2008 at 6:51 AM, Fernando Correia
[EMAIL PROTECTED] wrote:
I am trying out IronPython hosting on C#. I found out an article about
hosting with 2.0 Alpha 6:
http://blogs.msdn.com/rdawson/archive/2007/11/29/hosting-ironpython-2-0-alpha-6-via-the-dlr.aspx
But those instructions don't seem to work with 2.0 Alpha 8. I've
searched the Web but I couldn't find updated instructions.
If someone can give me a pointer, I'd appreciate.
___
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] Returning inherited classes to .NET
It's a feature. clr.AddReferenceToFile ends up calling Assembly.LoadFileunder the covers, which lets you load multiple versions of the same assembly. If this isn't the behavior you want, you should use a differently variant of AddReference (such as clr.AddReference). Each variant has its uses; this one's don't correspond well with your intentions. On Sun, Feb 24, 2008 at 2:22 PM, Howland-Rose, Kyle [EMAIL PROTECTED] wrote: Awesome, thanks Curt. Do you have any idea as to whether this is a bug or a feature? -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Curt Hagenlocher *Sent:* Saturday, 23 February 2008 1:33 AM *To:* Discussion of IronPython *Subject:* Re: [IronPython] FW: FW: FW: returning inherited classes to .NET I built a test executable and was able to reproduce this. And when I changed clr.AddReferenceToFile(WebControlLibrary.dll) to clr.AddReference(WebControlLibrary) it worked as expected. On Fri, Feb 22, 2008 at 6:02 AM, Curt Hagenlocher [EMAIL PROTECTED] wrote: Ah, no. I was thinking that you would modify your VB code to launch it as a console app (for instance) rather than from inside of ASP.NEThttp://asp.net/-- and see if you still get the same error. On Thu, Feb 21, 2008 at 10:07 PM, Howland-Rose, Kyle [EMAIL PROTECTED] wrote: Thanks for your help so late Curt (not that I need a quick answer at all). I am sure I am missing something big-time here and talking as cross-purposes, but, to my mind the reason I don't have a problem when running from the command line is because all I am doing is running the ipy.exe on the file which loads some assemblies, creates a class definition and a function definition and then terminates without even instantiating the class. Is this what you mean by running it directly? Thanks again, Kyle -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Curt Hagenlocher *Sent:* Friday, 22 February 2008 4:55 PM *To:* Discussion of IronPython *Subject:* Re: [IronPython] FW: FW: returning inherited classes to .NET If you're only getting the error under ASP.NET http://asp.net/, then it's highly likely that you're loading multiple copies of the same assembly, which is why the CLR can't cast your Python class back to the VB base -- it literally considers them to be two different classes. This may be related to the way ASP.NET http://asp.net/ makes shadow copies of your files, but there could be other reasons as well (none of which, unfortunately, come to mind right now). Using an interface instead of a base class would give you the same results. On Thu, Feb 21, 2008 at 9:44 PM, Howland-Rose, Kyle [EMAIL PROTECTED] wrote: It runs fine from the command line but then it does not do much ... yet. For the moment I am simplifying it by removing IP :( I wanted to so some moderately heavy reflection which to my thinking should be easier from IP but I will use VB for now. I assume I *should* be able to return a derived python class to VB? Alternatively I could implement an interface. How can IP implement a .NET interface? (All pointers to pre-existing doco warmly received :) Thanks Kyle -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Curt Hagenlocher *Sent:* Friday, 22 February 2008 4:29 PM *To:* Discussion of IronPython *Subject:* Re: [IronPython] FW: returning inherited classes to .NET My apologies; I wasn't reading the code correctly. That's probably a sign that I should be going to bed. :) Have you tried simplifying your version just a little bit by running it directly rather than through ASP.NET http://asp.net/? On Thu, Feb 21, 2008 at 8:43 PM, Howland-Rose, Kyle [EMAIL PROTECTED] wrote: Hi Curt, Thanks for replying. When I view the link I see the following: The .NET code creates the Test class and then runs the python code which imports the Test class a subclasses it to create python class X. Class X is then called and cast to type Test and assigned to the value obj. Is this what you are looking at? My code is pretty much identical. The VB looks like: Public MustInherit Class ChildControl Public Function Control() As WebControl Return Nothing End Function Public Function GetValue() As String Return Nothing End Function Public Function SetValue(ByVal value As Object) As String Return Nothing End Function End Class Class IPReflection Private Shared Instance As IPReflection = Nothing Private PyEngine As PythonEngine Private
Re: [IronPython] FW: Returning inherited classes to .NET
http://blogs.msdn.com/haibo_luo/archive/2007/09/25/5130072.aspx On Sun, Feb 24, 2008 at 4:00 PM, Howland-Rose, Kyle [EMAIL PROTECTED] wrote: Is there a good place to read about these variants? I was using this one because I did not want to use the GAC and AddReference failed just using WebControlLibrary presumably because I needed to add the dll's path to a path list somewhere. -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Curt Hagenlocher *Sent:* Monday, 25 February 2008 10:31 AM *To:* Discussion of IronPython *Subject:* Re: [IronPython] Returning inherited classes to .NET It's a feature. clr.AddReferenceToFile ends up calling Assembly.LoadFile under the covers, which lets you load multiple versions of the same assembly. If this isn't the behavior you want, you should use a differently variant of AddReference (such as clr.AddReference). Each variant has its uses; this one's don't correspond well with your intentions. On Sun, Feb 24, 2008 at 2:22 PM, Howland-Rose, Kyle [EMAIL PROTECTED] wrote: Awesome, thanks Curt. Do you have any idea as to whether this is a bug or a feature? -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Curt Hagenlocher *Sent:* Saturday, 23 February 2008 1:33 AM *To:* Discussion of IronPython *Subject:* Re: [IronPython] FW: FW: FW: returning inherited classes to .NET I built a test executable and was able to reproduce this. And when I changed clr.AddReferenceToFile(WebControlLibrary.dll) to clr.AddReference(WebControlLibrary) it worked as expected. On Fri, Feb 22, 2008 at 6:02 AM, Curt Hagenlocher [EMAIL PROTECTED] wrote: Ah, no. I was thinking that you would modify your VB code to launch it as a console app (for instance) rather than from inside of ASP.NEThttp://asp.net/-- and see if you still get the same error. On Thu, Feb 21, 2008 at 10:07 PM, Howland-Rose, Kyle [EMAIL PROTECTED] wrote: Thanks for your help so late Curt (not that I need a quick answer at all). I am sure I am missing something big-time here and talking as cross-purposes, but, to my mind the reason I don't have a problem when running from the command line is because all I am doing is running the ipy.exe on the file which loads some assemblies, creates a class definition and a function definition and then terminates without even instantiating the class. Is this what you mean by running it directly? Thanks again, Kyle -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Curt Hagenlocher *Sent:* Friday, 22 February 2008 4:55 PM *To:* Discussion of IronPython *Subject:* Re: [IronPython] FW: FW: returning inherited classes to .NET If you're only getting the error under ASP.NET http://asp.net/, then it's highly likely that you're loading multiple copies of the same assembly, which is why the CLR can't cast your Python class back to the VB base -- it literally considers them to be two different classes. This may be related to the way ASP.NET http://asp.net/ makes shadow copies of your files, but there could be other reasons as well (none of which, unfortunately, come to mind right now). Using an interface instead of a base class would give you the same results. On Thu, Feb 21, 2008 at 9:44 PM, Howland-Rose, Kyle [EMAIL PROTECTED] wrote: It runs fine from the command line but then it does not do much ... yet. For the moment I am simplifying it by removing IP :( I wanted to so some moderately heavy reflection which to my thinking should be easier from IP but I will use VB for now. I assume I *should* be able to return a derived python class to VB? Alternatively I could implement an interface. How can IP implement a .NET interface? (All pointers to pre-existing doco warmly received :) Thanks Kyle -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Curt Hagenlocher *Sent:* Friday, 22 February 2008 4:29 PM *To:* Discussion of IronPython *Subject:* Re: [IronPython] FW: returning inherited classes to .NET My apologies; I wasn't reading the code correctly. That's probably a sign that I should be going to bed. :) Have you tried simplifying your version just a little bit by running it directly rather than through ASP.NET http://asp.net/? On Thu, Feb 21, 2008 at 8:43 PM, Howland-Rose, Kyle [EMAIL PROTECTED] wrote: Hi Curt, Thanks for replying. When I view the link I see the following: The .NET code creates the Test class and then runs the python code which
Re: [IronPython] Exporting Python code as an assembly
On Tue, Feb 26, 2008 at 9:04 AM, Dino Viehland [EMAIL PROTECTED] wrote: What's MakeModule.py? That's from the project I started at http://www.codeplex.com/coils. Suma, you might consider getting a copy of the Codeplex tools and using them to download the most recent changes; I know I've fixed some things since the original version. Also, make sure you're using 2.0 Alpha 8 of IronPython. Unfortunately, I'm leaving on an email-less vacation in a few hours and don't have the time to offer any further assistance. I'll be back in three weeks and you can feel free to contact me then. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Exporting Python code as an assembly (Curt Hagenlocher)
On 3/3/08, Suma Talya [EMAIL PROTECTED] wrote: Do we need to have py file also in the same directory along with dll? Yes, that is correct. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] 2.0B1 Hosting: Creating Python Types
On Mon, Mar 17, 2008 at 5:26 PM, Dino Viehland [EMAIL PROTECTED] wrote: CodeContext isn't actually internal but it's also not available to you via the hosting APIs. Does this mean that we shouldn't be creating CodeContexts? I'm using the class IronPython.Runtime.Operations.PythonTypeOps+TypeCaller to construct new objects from Python types. This process requires a CodeContext, which I'm currently building from scratch as needed. (The same approach could be used with the PythonType IronPython.Runtime.Builtin.file in order to build a Python file object a little more efficiently.) -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] 2.0B1 Hosting: Creating Python Types
On Wed, Mar 19, 2008 at 12:34 PM, Tarun Kapoor [EMAIL PROTECTED] wrote: Curt - at pycon, I heard that you are working on a CLR wrapper project. Under which python code will be have automatically generated wrappers and that way they can called in C# more easily... Can you pls provide some details on how the project is going ? I've just gotten back from vacation and will resume work on the project once I recover from the twin devils of jet lag and the backlog. I can't make any specific promises about progress right now, but I'm definitely committed to making some :). -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] 2.0B1 Hosting: Creating Python Types
On Wed, Mar 19, 2008 at 1:11 PM, Tarun Kapoor [EMAIL PROTECTED] wrote: If you need any help let me know. I am up for it. It is personally going to help me a lot, so I have vested interests in the project :) Is there a project webpage by the way, where I can read etc? It's on CodePlex at http://www.codeplex.com/coils. Feel free to provide feedback or sign up :). The existing code works against 2.0A8; it will updated for 2.0B1 by the end of the week. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] urllib.urlretrieve with IronPython 2a8
I noticed that this still isn't fixed in 2.0b1, so I took another look at socket.cs and realized that my analysis was slightly off. There's already a mechanism to track duplicated sockets in the form of the handleToSocket mapping. However, this mechanism isn't taken into account when deciding whether or not to Close() the BCL Socket object. Bottom line: I believe this bug can be fixed simply by moving the call to _socket.Close() from socket.close into socket.RemoveHandleSocketMapping, and only calling it when sockets.Count reaches zero. On Mon, Feb 18, 2008 at 9:19 PM, Dino Viehland [EMAIL PROTECTED] wrote: This is a great analysis - based upon this I think it'll be pretty easy to fix this. I'll take a look at it tomorrow and respond back. -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Curt Hagenlocher Sent: Monday, February 18, 2008 4:19 PM To: Discussion of IronPython Subject: Re: [IronPython] urllib.urlretrieve with IronPython 2a8 On Feb 18, 2008 4:12 PM, Curt Hagenlocher [EMAIL PROTECTED] wrote: Is it possible that CPython's socket.close method won't actually close the socket while there's still a makefile'd file attacked to the underlying OS socket? And that IronPython's will? Because that's the only explanation I can come up with. It is and it will. CPython basically dups the socket handle when you call makefile, while IronPython does not. That's the cause of this bug. By the way, the docstring for the IronPython socket class claims that makefile isn't implemented. This is apparently only half-true. :P -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] urllib.urlretrieve with IronPython 2a8
Nope; got it wrong again. I'll just supply a patch once I get this working. On Fri, Mar 21, 2008 at 2:36 PM, Curt Hagenlocher [EMAIL PROTECTED] wrote: I noticed that this still isn't fixed in 2.0b1, so I took another look at socket.cs and realized that my analysis was slightly off. There's already a mechanism to track duplicated sockets in the form of the handleToSocket mapping. However, this mechanism isn't taken into account when deciding whether or not to Close() the BCL Socket object. Bottom line: I believe this bug can be fixed simply by moving the call to _socket.Close() from socket.close into socket.RemoveHandleSocketMapping, and only calling it when sockets.Count reaches zero. On Mon, Feb 18, 2008 at 9:19 PM, Dino Viehland [EMAIL PROTECTED] wrote: This is a great analysis - based upon this I think it'll be pretty easy to fix this. I'll take a look at it tomorrow and respond back. -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Curt Hagenlocher Sent: Monday, February 18, 2008 4:19 PM To: Discussion of IronPython Subject: Re: [IronPython] urllib.urlretrieve with IronPython 2a8 On Feb 18, 2008 4:12 PM, Curt Hagenlocher [EMAIL PROTECTED] wrote: Is it possible that CPython's socket.close method won't actually close the socket while there's still a makefile'd file attacked to the underlying OS socket? And that IronPython's will? Because that's the only explanation I can come up with. It is and it will. CPython basically dups the socket handle when you call makefile, while IronPython does not. That's the cause of this bug. By the way, the docstring for the IronPython socket class claims that makefile isn't implemented. This is apparently only half-true. :P -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Latest DLR Hosting Spec?
Is the file at http://compilerlab.members.winisp.net/dlr-spec-hosting.pdf still the latest publically-available version of the spec? The PDF was created on Jan 3, 08 but otherwise contains no versioning information. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Question about serialization
Ooh, I was unaware of __reduce__ and __reduce_ex__; thanks. On Wed, Mar 26, 2008 at 8:36 AM, Dino Viehland [EMAIL PROTECTED] wrote: Unfortunately I don't think what you want will work. If it's your .NET class you could implement __reduce_ex__ and I think we'd pick it up and use that for the serialization. But if it's some arbitrary framework class then you'll run into trouble. On IronPython 2.0 you could have an extension class w/ the __reduce_ex__ function, have an ExtensionTypeAttribute that links the .NET base class and the extension class, and then call RuntimeHelpers.RegisterAssembly and we'd pick up the extension method. Also, we do have a feature request for this on CodePlex: http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13401 Voting on it would raise its priority and we'd be more likely to do it sooner rather than later. *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Paul Turbett *Sent:* Wednesday, March 26, 2008 4:56 AM *To:* Discussion of IronPython *Subject:* Re: [IronPython] Question about serialization Thanks Michael for the advice. Must appreciated. Unfortunately I hasn't worked out yet tho :( I can use pickle from C# using Evaluate, or from within a Python class, on a pure Python object. However any attempt at pickling a python object that derives from a C# base result in an exception like this: Cannot convert MyObject(MyObject object at 0x002B) to Int32 Exploring further, I came across Ops.GetDynamicType() and Ops.GetAttrsNames() which I thought might be helpful to get the attributes of an object and serialize it somehow (manually), but GetAttrNames requires an ICallerContext, and I can't see how to get one of those. It seems that whilst serializing .NET classes is trivial, and serializing python classes is trivial, serializing something that touches both is proving quite difficult. Any further suggestions gratefully received! Thanks, Paul Michael Foord wrote: Paul Turbett wrote: Hi, I'm using IP as a scripting engine in a C# app. I have various Python classes that derive from a C# base class, and have there own additional data functionality. I would like to be able to serialize instances of the Python classes from the C# host for persistence across sessions. Using the standard BinaryFormatter with the Serializable attribute is not working - I get an error about the python class not being marked as serializable (the C# base class is marked as serializable though). How can I serialize python objects from C#? Should I use reflection to roll my own serializer, or is there something in one of the lesser documented assemblies like Ops I should use? Typically for serializing Python objects you would use pickle [1]. The 'dumps' function returns a string (make sure you use the text protocol for IronPython). You could then execute code inside the Python engine to serialize / deserialize objects. I've not tried this for instances that inherit from C# base classes - but it should work fine. :-) Michael Foord http://www.ironpythoninaction.com .. [1] http://docs.python.org/lib/module-pickle.html I'm using IP 1.1.1 (but will move to 2.0 if that will help). Any pointers advice greatly appreciated! Thanks, Paul ___ 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 ___ 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] Question about serialization
I was thinking that Python's lack of a global namespace for classes would be a problem -- but of course it's not because you'd actually be looking in the CLR namespace. So you could just fail the deserialize if the CLR base class doesn't already exist. It would still be nice to be able to auto-load an assembly when the base class is strongly-named. On Wed, Mar 26, 2008 at 8:42 AM, Dino Viehland [EMAIL PROTECTED] wrote: My guess is you'd restrict it only to .NET objects which are marked as being serializable. Then you'd ask the object to serialize it's self and then stuff that into the pickle stream along w/ the extra Python info. That's probably include a type name which you'd just load and see what you got – much like how cPickle does an import and uses what it gets when it's loading a global. *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Curt Hagenlocher *Sent:* Wednesday, March 26, 2008 8:31 AM *To:* Discussion of IronPython *Subject:* Re: [IronPython] Question about serialization This is an interesting problem. Python's pickle writes out enough data to rebuild the object entirely -- including the class definition, if the object is a user-defined type. How do you accurately write out a class definition for a C# base class? Would you restrict it to strongly named classes? On Wed, Mar 26, 2008 at 4:55 AM, Paul Turbett [EMAIL PROTECTED] wrote: Thanks Michael for the advice. Must appreciated. Unfortunately I hasn't worked out yet tho :( I can use pickle from C# using Evaluate, or from within a Python class, on a pure Python object. However any attempt at pickling a python object that derives from a C# base result in an exception like this: Cannot convert MyObject(MyObject object at 0x002B) to Int32 Exploring further, I came across Ops.GetDynamicType() and Ops.GetAttrsNames() which I thought might be helpful to get the attributes of an object and serialize it somehow (manually), but GetAttrNames requires an ICallerContext, and I can't see how to get one of those. It seems that whilst serializing .NET classes is trivial, and serializing python classes is trivial, serializing something that touches both is proving quite difficult. Any further suggestions gratefully received! Thanks, Paul Michael Foord wrote: Paul Turbett wrote: Hi, I'm using IP as a scripting engine in a C# app. I have various Python classes that derive from a C# base class, and have there own additional data functionality. I would like to be able to serialize instances of the Python classes from the C# host for persistence across sessions. Using the standard BinaryFormatter with the Serializable attribute is not working - I get an error about the python class not being marked as serializable (the C# base class is marked as serializable though). How can I serialize python objects from C#? Should I use reflection to roll my own serializer, or is there something in one of the lesser documented assemblies like Ops I should use? Typically for serializing Python objects you would use pickle [1]. The 'dumps' function returns a string (make sure you use the text protocol for IronPython). You could then execute code inside the Python engine to serialize / deserialize objects. I've not tried this for instances that inherit from C# base classes - but it should work fine. :-) Michael Foord http://www.ironpythoninaction.com .. [1] http://docs.python.org/lib/module-pickle.html I'm using IP 1.1.1 (but will move to 2.0 if that will help). Any pointers advice greatly appreciated! Thanks, Paul ___ 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 ___ 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 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Accessing search path through ScriptEngine
The script engine allows you to set the search path by calling ScriptEngine.SetScriptSourceSearchPaths, but it neither lets you query the existing path nor amend it -- just set it outright. Is this intentional? -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IP 2 Hosting
Some of those look like names from A9, which have changed in B1. The easiest way to evaluate an expression from scratch seems to be as follows: ScriptEngine engine = ScriptRuntime.Create().GetEngine(py); ScriptScope scope = engine.CreateScope(); ScriptSource source = engine.CreateScriptSourceFromString(1 + 1, SourceCodeKind.Expression); int result = source.Executeint(scope); On Sat, Mar 29, 2008 at 10:00 AM, Michael Foord [EMAIL PROTECTED] wrote: Hello guys, I'm trying to do some simple examples of hosting with IronPython 2. Boy you made things more complicated than IronPython 1. :-) Unfortunately the DLR hosting spec document is out of date. I have a couple of questions (but will keep exploring). The simplest use case is just to evaluate an expression and return a result. The hosting spec document mention 'ScriptRuntime.Execute(text)'. This may or may not be the right way to evaluate an expression, but in any case it has been removed. An alternative is: engine = PythonEngine.CurrentEngine # a ScriptEngine unit = engine.CreateSourceUnitFromString(code, id) result = unit.Execute() Which is straightforward enough, however I can't see a way to set TrueDivision using this technique. (What is the 'id' by the way?) I can see that TrueDivision is a setting on IronPython.Runtime.ModuleOptions and IronPython.Runtime.PythonModule. Can I set this on the engine somehow? All the alternative seem to lead down a rabbit warren of 'create this object - which requires this object - which you construct from another object - which...'. I don't know which path to follow down the rabbit hole... :-) Any suggestions to save me from madness? Michael ___ 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] IP 2 Hosting
On Sat, Mar 29, 2008 at 10:51 AM, Michael Foord [EMAIL PROTECTED] wrote: Cool - I was just being rude. Hey, I feel your pain! I'd swear that I've rewritten more hosting code than I've written... Any ideas on switching on TrueDivision for the scope? This is what I was able to puzzle out. I have no idea how correct it is. ScriptSource source = engine.CreateScriptSourceFromString(import foo, SourceCodeKind.Statements); ScriptScope scriptScope = runtime.ExecuteSourceUnit(source); Scope scope = scriptScope.GetVariableScope(foo); PythonModule extension = (PythonModule)scope.GetExtension(scope.Language.ContextId); extension.TrueDivision = true; It looks like you can set this globally by doing something like this: ((IronPython.PythonEngineOptions)engine.Options).DivisionOptions = IronPython.PythonDivisionOptions.New; -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Snippets in Trackback
The snippets represent executable code that's generated dynamically by the DLR from your Python source. Do you have a small piece of sample code that reproduces the failure? On Sat, Mar 29, 2008 at 1:28 PM, Davy Mitchell [EMAIL PROTECTED] wrote: Hi All, IPY2.0 B1 Vista SP1 I keep seeing reference to 'Snippets' in IP Tracebacks on different bits of code. Can't find anything on codeplex so assume it *probably* something wrong this end. I don't have a 'Snippets' module AFAIK. Typical example C:\Code\OSProjectsipy wpf5.py Traceback (most recent call last): File Snippets, line unknown, in Initialize File PresentationFramework, line unknown, in Load Is it just me or :-) -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com ___ 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] Snippets in Trackback
This works for me once I fix the mismatched XML tag (and the mail-induced line breaks). And when I don't, I get pretty explicit error messages as the text of the exception: SystemError: The 'DockPanel' start tag on line 4 does not match the end tag of 'DockPanelTest'. Line 5, position 3. -or- SyntaxError: EOL while scanning single-quoted string What was the exception that you were getting? On Sat, Mar 29, 2008 at 11:42 PM, Davy Mitchell [EMAIL PROTECTED] wrote: This has the desired effect: import clr clr.AddReference(System.Xml) clr.AddReference(PresentationFramework, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35) clr.AddReference(PresentationCore, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35) from System.IO import StringReader from System.Xml import XmlReader from System.Windows.Markup import XamlReader, XamlWriter from System.Windows import Window, Application xaml = Window xmlns=http://schemas.microsoft.com/winfx/2006/xaml/presentation; Title=Test Width=600 Height=400 DockPanel /DockPanelTest /Window xr = XmlReader.Create(StringReader(xaml)) win = XamlReader.Load(xr) Application().Run(win) On Sat, Mar 29, 2008 at 8:34 PM, Curt Hagenlocher [EMAIL PROTECTED] wrote: The snippets represent executable code that's generated dynamically by the DLR from your Python source. Do you have a small piece of sample code that reproduces the failure? On Sat, Mar 29, 2008 at 1:28 PM, Davy Mitchell [EMAIL PROTECTED] wrote: Hi All, IPY2.0 B1 Vista SP1 I keep seeing reference to 'Snippets' in IP Tracebacks on different bits of code. Can't find anything on codeplex so assume it *probably* something wrong this end. I don't have a 'Snippets' module AFAIK. Typical example C:\Code\OSProjectsipy wpf5.py Traceback (most recent call last): File Snippets, line unknown, in Initialize File PresentationFramework, line unknown, in Load Is it just me or :-) -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com ___ 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 -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com ___ 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] Creating Python classes in IP2
On Sun, Mar 30, 2008 at 2:59 AM, Paul Turbett [EMAIL PROTECTED] wrote: I've looked through the DLR hosting spec, and experimented a bit, but I can't see how to get the same thing working with DLR hosting. So, how do I create instances of python classes from C#? This is what works for me: ScriptRuntime runtime = ScriptRuntime.Create(); ScriptEngine engine = runtime.GetEngine(py); // These next two lines are needed if you expect to be able to import System // without manually loading the assembly through Python // runtime.LoadAssembly(typeof(string).Assembly); // runtime.LoadAssembly(typeof(System.Diagnostics.Debug).Assembly); // File foo.py contains class Foo ScriptScope scope = runtime.ExecuteFile(foo.py); object theClass; scope.TryGetVariable(Foo, out theClass); object theValue = PythonCalls.Call(theClass); -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Snippets in Trackback
On Sun, Mar 30, 2008 at 5:20 AM, Davy Mitchell [EMAIL PROTECTED] wrote: A better example is the single line 'self.test' saved to to test2.py ipy test2.py C:\Code\OSProjectsipy test2.py Traceback (most recent call last): File Snippets, line unknown, in Initialize NameError: name 'self' is not defined I imagine this is just a temporary glitch in 2.0b1, as IronPython 1.1.1 shows the right line: PS F:\IPCE-r7\ipy .\ipy.exe test2.py Traceback (most recent call last): File F:\IPCE-r7\ipy\test2.py, line 1, in Initialize NameError: name 'self' not defined -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] More IP2 Equivalents - setting argv and search path
On Mon, Mar 31, 2008 at 4:51 AM, Michael Foord [EMAIL PROTECTED] wrote: I saw a post on the list recently about ScriptEngine.SetScriptSourceSearchPaths, but this doesn't seem to exist in 2b1. I'm looking at it in 2b1 right now... -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Semi-blocking bug in IP 2B1
On Mon, Mar 31, 2008 at 8:10 AM, Michael Foord [EMAIL PROTECTED] wrote: In general, error reporting/tracebacks seem to be much worse in IronPython 2. If I have time I will try and produce a repro... If you run with a -D flag, you get much better error reporting. This is equivalent to setting (ScriptRuntime).GlobalOptions.DebugMode = true in a hosting scenario. (Thanks to Jimmy Schementi's post on the IronRuby list for pointing me at this.) -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Creating Python classes in IP2
On Mon, Mar 31, 2008 at 8:54 AM, Slide [EMAIL PROTECTED] wrote: I use the following for finding a class that implements a certain interface. [...] Is there a way that is more portable between the different languages? It looks like the DLR doesn't try to abstract classness. And given that the semantics of a class vary so much between Python, Ruby and Javascript, this isn't really a surprise. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Semi-blocking bug in IP 2B1
LambdaCompiler.Statements.cs basically says if (Options.DebugMode Options.DynamicStackTraceSupport) EmitGetCurrentLine(). Maybe this should be or instead of and? On Mon, Mar 31, 2008 at 9:13 AM, Dino Viehland [EMAIL PROTECTED] wrote: It's actually something that's on our radar - it feels worse to me too. It's something I plan on taking a look at before 2.0 final ships. -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Monday, March 31, 2008 9:04 AM To: Discussion of IronPython Subject: Re: [IronPython] Semi-blocking bug in IP 2B1 Curt Hagenlocher wrote: On Mon, Mar 31, 2008 at 8:10 AM, Michael Foord [EMAIL PROTECTED] wrote: In general, error reporting/tracebacks seem to be much worse in IronPython 2. If I have time I will try and produce a repro... If you run with a -D flag, you get much better error reporting. This is equivalent to setting (ScriptRuntime).GlobalOptions.DebugMode = true in a hosting scenario. (Thanks to Jimmy Schementi's post on the IronRuby list for pointing me at this.) Ok - and thanks. But we generate and execute code at runtime and need good error reporting for our users. If there is a performance implication we wouldn't want to have to set this flag just to be able to give our users useful tracebacks! The IP traceback handling is generally fine for us - but I haven't *confirmed* that IP 2 is worse - it just feels worse... We have bigger problems anyway. Now I have ironed out the obvious problems, Resolver One runs on IP 2 but the user interface is completely broken. That is all pure-Python code so I have some digging to do... :-) Michael -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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 ___ 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] Restricting IronPython/DLR in a Sandbox?
(I think) I can repro this with the following code:
static void Main() {
AppDomainSetup info = new AppDomainSetup();
info.ApplicationBase = System.Environment.CurrentDirectory;
info.ApplicationName = Test;
Evidence evidence = new Evidence();
evidence.AddHost(new Zone(SecurityZone.Internet));
AppDomain newDomain = AppDomain.CreateDomain(test, evidence, info);
ScriptRuntime runtime = ScriptRuntime.Create(newDomain);
}
System.MethodAccessException was unhandled
Message=RemoteRuntimeFactory..ctor(
Microsoft.Scripting.Hosting.ScriptRuntimeSetup)
Source=mscorlib
StackTrace:
at System.Reflection.MethodBase.PerformSecurityCheck(Object obj,
RuntimeMethodHandle method, IntPtr parent, UInt32 invocationFlags)
at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr,
Binder binder, Object[] args, CultureInfo culture, Object[]
activationAttributes)
at System.Activator.CreateInstance(Type type, BindingFlags
bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[]
activationAttributes)
at System.Activator.CreateInstance(String assemblyName, String
typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder,
Object[] args, CultureInfo culture, Object[] activationAttributes, Evidence
securityInfo, StackCrawlMark stackMark)
at System.Activator.CreateInstance(String assemblyName, String
typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder,
Object[] args, CultureInfo culture, Object[] activationAttributes, Evidence
securityInfo)
at System.AppDomain.CreateInstance(String assemblyName, String
typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder,
Object[] args, CultureInfo culture, Object[] activationAttributes, Evidence
securityAttributes)
at System.AppDomain.CreateInstanceAndUnwrap(String assemblyName,
String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder
binder, Object[] args, CultureInfo culture, Object[] activationAttributes,
Evidence securityAttributes)
at System.AppDomain.CreateInstanceAndUnwrap(String assemblyName,
String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder
binder, Object[] args, CultureInfo culture, Object[] activationAttributes,
Evidence securityAttributes)
at
Microsoft.Scripting.Hosting.ScriptRuntime.RemoteRuntimeFactory.CreateRuntime(AppDomain
domain, ScriptRuntimeSetup setup)
at Microsoft.Scripting.Hosting.ScriptRuntime.CreateInternal(AppDomain
domain, ScriptRuntimeSetup setup)
at Microsoft.Scripting.Hosting.ScriptRuntime.Create(AppDomain domain)
at ConsoleApplication7.Program.Main() in
C:\Users\CurtH\Documents\Visual Studio
2008\Projects\ConsoleApplication1\ConsoleApplication7\Program.cs:line 27
at System.AppDomain._nExecuteAssembly(Assembly assembly, String[]
args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence
assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException:
On Tue, Apr 1, 2008 at 1:33 PM, Dino Viehland [EMAIL PROTECTED]
wrote:
Can you give us the full stack trace of the exception that gets thrown
and also what version of the CLR are you running against?
It may be the case that partial trust will require the latest and greatest
patch of .NET as there have been some changes to enable reflection /
reflection emit to work better in partial trust. But it could also be a DLR
or IronPython bug when running in partial trust on the desktop CLR.
*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Sho List
*Sent:* Tuesday, April 01, 2008 12:43 PM
*To:* users@lists.ironpython.com
*Subject:* [IronPython] Restricting IronPython/DLR in a Sandbox?
Hello IronPythoners,
I am using the IronPython 2 Beta 1 on .Net 2.0.
My goal is to create a restricted sandbox for scripts to run in using the
DLR. I have searched high and low and have not found a solution utilizing
the latest python beta release and DLR. It would seem this is something that
should be straightforward to accomplish as the DLR's
ScriptRuntime.Createtakes an AppDomain as an overload. And indeed, my Python
engine and runtime
are loaded in the remote AppDomain, however I can only get it to work when
the AppDomain has FullTrust permissions. Anything lower (say Intranet Zone
and the like) and it throws a Method Access Exceptions on the
ScriptRuntime.Create method.
I have tried creating the AppDomain like so:
AppDomain.CreateDomain(name, defaultEvidence, appDomainSetup,
defaultPermissions,
Re: [IronPython] Restricting IronPython/DLR in a Sandbox?
For what it's worth, I got that result on 2.0.50727.1434. On Tue, Apr 1, 2008 at 3:52 PM, Sho List [EMAIL PROTECTED] wrote: Thanks Curt, that code does reproduce the exception I am getting. I am running on 2.0.50727.312 Thanks! -- More immediate than e-mail? Get instant access with Windows Live Messenger.http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refresh_instantaccess_042008 ___ 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] InvalidProgramException testing hosting under NUnit
This indicates that your executable directory does not contain
IronPython.Modules.dll.
On Thu, Apr 3, 2008 at 7:35 PM, Paul Turbett [EMAIL PROTECTED] wrote:
Hi
Was there ever a solution to this problem? I'm getting the same thing,
though not with NUnit. To port my IP interface from 1.1 to 2.0 (beta 1), I
created a separate test application, which worked fine. However I'm merging
the code into my real application, but I'm not able to create a
ScriptEngine.
_runtime = ScriptRuntime.Create();
string[] languages = _runtime.GetRegisteredLanguageIdentifiers(); //
finds 18 languages, including py
_engine = _runtime.GetEngine(py); // --- throws an exception
Microsoft.Scripting.Runtime.InvalidImplementationException was unhandled
Message=Type 'IronPython.Runtime.PythonContext' doesn't provide a
suitable public constructor or its implementation is faulty.
Source=Microsoft.Scripting
StackTrace:
at Microsoft.Scripting.Utils.ReflectionUtils.CreateInstance[T](Type
actualType, Object[] args)
at
Microsoft.Scripting.Runtime.ScriptDomainManager.LanguageRegistration.LoadLanguageContext(ScriptDomainManager
manager)
at
Microsoft.Scripting.Runtime.ScriptDomainManager.TryGetLanguageContext(String
languageId, LanguageContext languageContext)
at Microsoft.Scripting.Hosting.ScriptRuntime.TryGetEngine(String
languageId, ScriptEngine engine)
at Microsoft.Scripting.Hosting.ScriptRuntime.GetEngine(String
languageId)
at Utilities.OSEPython..ctor(FileStream log) in
C:\Projects\Utils\PythonEngine.cs:line 121
at Utilities.PythonFactory.Create(Boolean log) in
C:\Projects\Utils\PythonEngine.cs:line 70
...
Not sure if it's important, but the application uses a few assemblies, and
the IP wrapper classes are in a separate assembly to where they are used.
Thanks, Paul
Fernando Correia wrote:
2008/3/12, Dino Viehland [EMAIL PROTECTED] [EMAIL PROTECTED]:
There's an inner exception here (probably from Importer.cs in MakeImportSite)
but there isn't much info on it. Could you run it under a debugger and get
that original stack trace? It's not clear to me why we would blow up there.
Thanks for your help.
Sorry for some text in Portuguese below. I hope it doesn't get in the way.
The exception occurs within class ReflectionUtils, method CreateInstanceT.
Line 127 is:
return (T)Activator.CreateInstance(actualType, args);
This in turns ends up calling the constructor public
PythonContext(ScriptDomainManager/*!*/ manager) in class
PythonContext.
Line 120 is:
_importer = new Importer(this);
A step into this line will cause the exception.
The stack trace of the innermost exception
([System.InvalidProgramException] = {Common Language Runtime detectou
um programa inválido.}) is:
em
Microsoft.Scripting.RuntimeHelpers.CreateSimpleCallSite[T0,T1,T2,T3,T4,R]()
em IronPython.Runtime.Importer.MakeImportSite() na
C:\Temp\IronPython v2.0 Alpha
8\IronPython-2.0A8-Src\IronPython-2.0A8\Src\IronPython\Runtime\Importer.cs:linha
74
em IronPython.Runtime.Importer..cctor() na C:\Temp\IronPython v2.0
Alpha
8\IronPython-2.0A8-Src\IronPython-2.0A8\Src\IronPython\Runtime\Importer.cs:linha
49
The stack trace of the outermost exception (base
{System.ApplicationException} = {Uma exceção foi acionada pelo
destino de uma chamada.}) is:
em System.RuntimeMethodHandle._InvokeConstructor(Object[] args,
SignatureStruct signature, IntPtr declaringType)
em System.RuntimeMethodHandle.InvokeConstructor(Object[] args,
SignatureStruct signature, RuntimeTypeHandle declaringType)
em System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
em System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr,
Binder binder, Object[] args, CultureInfo culture, Object[]
activationAttributes)
em System.Activator.CreateInstance(Type type, BindingFlags
bindingAttr, Binder binder, Object[] args, CultureInfo culture,
Object[] activationAttributes)
em System.Activator.CreateInstance(Type type, Object[] args)
em Microsoft.Scripting.Utils.ReflectionUtils.CreateInstance[T](Type
actualType, Object[] args) na C:\Temp\IronPython v2.0 Alpha
8\IronPython-2.0A8-Src\IronPython-2.0A8\Src\Microsoft.Scripting\Utils\ReflectionUtils.cs:linha
127
___
Users mailing [EMAIL
PROTECTED]://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
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] URLLIB Issue
In CPython 2.5.2, the prototype of _fileobject.__init__ is this: def __init__(self, sock, mode='rb', bufsize=-1, close=False): The close flag controls whether or not the socket should be closed when the file is closed. As such, this may be directly related to CodePlex issue 10825 -- and indicates that the solution I suggested for that issue is again totally wrong. :) On Fri, Apr 4, 2008 at 3:10 PM, Dino Viehland [EMAIL PROTECTED] wrote: I haven't seen this one before – the repro seems to be as simple as: import socket socket._fileobject(None, close='abc') but it's not clear to me what providing close does. Urllib2 seems to be passing True – does anyone know what it does? My guess is it causes the socket to be passed in but it's not documented. If that was what it does it'd be easy enough to fix. *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Davy Mitchell *Sent:* Friday, April 04, 2008 2:41 PM *To:* Discussion of IronPython *Subject:* [IronPython] URLLIB Issue Hello List, Has this been covered before? Trailed Codeplex and mailing list :-) import encodings import twitter api = twitter.Api() statuses = api.GetPublicTimeline() print [s.user.name for s in statuses] Produces: Traceback (most recent call last): File it.py, line 4, in Initialize File C:\Code\OSProjects\twitter.py, line 923, in GetPublicTimeline File C:\Code\OSProjects\twitter.py, line 1435, in _FetchUrl File C:\python25\lib\urllib2.py, line 381, in open File C:\python25\lib\urllib2.py, line 398, in _open File Snippets.debug, line unknown, in _call_chain File C:\python25\lib\urllib2.py, line 360, in _call_chain File C:\python25\lib\urllib2.py, line 1107, in http_open File C:\python25\lib\urllib2.py, line 1096, in do_open TypeError: _fileobject() got an unexpected keyword argument 'close' CPython works as expected. Thanks, Davy -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel http://needgod.com ___ 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
