Re: [IronPython] Revisiting interfaces and COM

2009-03-17 Thread Alex Willmer
2009/3/16 Dino Viehland di...@microsoft.com: The resolution of that bug was that we now expose explicitly implemented interfaces automatically if there are no naming conflicts.  But with COM it's usually a different story - the members should always just be there. Do the interop libraries use

[IronPython] Problem loading IronPython on Vista 64

2009-03-17 Thread Matt Channer
Hi! I am using IronPython 2.0.1 in a hosted environment (c# application running on 64 bit Vista). This works well when the application is compiled as a 32bit process, but I am getting the following error when running as an x64 process: *Could not load file or assembly 'Microsoft.Scripting,

Re: [IronPython] Problem loading IronPython on Vista 64

2009-03-17 Thread Curt Hagenlocher
I don't know why there would be a difference between 32-bit and 64-bit, but do you possibly have a copy of any of the IronPython bits in your GAC? As to the invalid path error, you're probably getting it from the line prefix = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);

Re: [IronPython] Problem loading IronPython on Vista 64

2009-03-17 Thread Matt Channer
Hi, The machine is pretty clean and has no dlr / ipy assemblies in the gac. fuslogvw is not showing anything for me at the moment so I need to investigate that a bit more. I think the error in the SysModule constructor is because I used AppDomain.CurrentDomain.Load(byte[]) to try and work

Re: [IronPython] Problem loading IronPython on Vista 64

2009-03-17 Thread Matt Channer
I did try Assembly.LoadFile but this returned null, maybe for the same reason that I was seeing initially - whatever that is :-) Fuslogvw now seems to be reporting binding failures (the setting I have is to Log bind failures to disk). Interestingly, none of the dlr / ipy assemblies are being

Re: [IronPython] Problem loading IronPython on Vista 64

2009-03-17 Thread Curt Hagenlocher
Your explanation for the SysModule error sounds right -- if you use Assembly.LoadFile instead, you'll probably avoid that exception. What settings are you using in fuslogvw? 2009/3/17 Matt Channer mchan...@gmail.com Hi, The machine is pretty clean and has no dlr / ipy assemblies in the gac.

Re: [IronPython] Problem loading IronPython on Vista 64

2009-03-17 Thread Curt Hagenlocher
You might want to consider logging all binds and not just failures. 2009/3/17 Matt Channer mchan...@gmail.com I did try Assembly.LoadFile but this returned null, maybe for the same reason that I was seeing initially - whatever that is :-) Fuslogvw now seems to be reporting binding failures

Re: [IronPython] gdata calendarservice.Insert

2009-03-17 Thread Dino Viehland
The method you're trying to call is generic so you need to index into it to provide the generic type: mycalsvc.Insert[type(myentry)](myposturi, myentry) We're considering adding inference for these type parameters in the future. From: users-boun...@lists.ironpython.com

Re: [IronPython] Problem loading IronPython on Vista 64

2009-03-17 Thread Matt Channer
OK - did that. Microsoft.Scripting.dll is reported in fuslogvw as being loaded successfully! The error is still reported in the application though, and there are no other binding entries for IronPython.dll and friends. If I attach to the process in VS and look at the loaded modules,

Re: [IronPython] CP Issue #21659: Subclassing unicode

2009-03-17 Thread Jeff Hardy
On Mon, Mar 16, 2009 at 7:03 PM, Dino Viehland di...@microsoft.com wrote: Does this make it work? class x(unicode):    def __init__(self, val): pass    def __new__(cls, val):            return unicode.__new__(cls, unicode(val)) x(1) I've voted for the bug and raised the priority to