Re: [IronPython] DebugMode

2008-07-05 Thread Dino Viehland
It enables generation of PDBs and causes the code to be compiled in debug mode (w/o optimizations) so that it can be reasonably debugged. W/o it you won't be able to debug code from a .NET debugger. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of

Re: [IronPython] DebugMode

2008-07-07 Thread Dino Viehland
PROTECTED] On Behalf Of Michael Foord Sent: Saturday, July 05, 2008 10:15 AM To: Discussion of IronPython Subject: Re: [IronPython] DebugMode Dino Viehland wrote: It enables generation of PDBs and causes the code to be compiled in debug mode (w/o optimizations) so that it can be reasonably

Re: [IronPython] Publishing a Module when Embedding

2008-07-08 Thread Dino Viehland
You can just expose a DLR Scope object directly - which is what IronPython does for modules internally. The name PythonModule is unfortunately a little confusing - it's actually a PythonScopeExtension where we can store additional data about the Scope (e.g. if import clr has occurred). We'll

Re: [IronPython] How to get a System.Exception inside a IronPython except: clause

2008-07-08 Thread Dino Viehland
There's a clsException property that we add to Python exceptions that will give you the CLR Exception for the corresponding Python Exception. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Eloff Sent: Tuesday, July 08, 2008 4:37 PM To: Discussion of

Re: [IronPython] Code Formatting on CodePlex Issues

2008-07-09 Thread Dino Viehland
I usually click on edit and I get back the original form of the text. I realize that's not going to work for people who can't edit bugs but the good news is the formatting is preserved, it just doesn't show up when you look at it as HTML. -Original Message- From: [EMAIL PROTECTED]

Re: [IronPython] Possible bug with with statement

2008-07-09 Thread Dino Viehland
Definitely a bug - it also repros on the desktop CLR. It repros with just: from __future__ import with_statement with file('hello.txt', 'w') as f: raise Exception so it looks like the exception code path is broken. The underlying problem is that we end up trying to dynamically convert

Re: [IronPython] upgrading to ip 2b3 in Resolver One

2008-07-09 Thread Dino Viehland
Another way to do this is to create a ScriptSource which is of kind Statements: ScriptRuntime sr = ScriptRuntime.Create(); ScriptEngine engine = sr.GetEngine(py); ScriptSource source = engine.CreateScriptSourceFromFile(test.py, Encoding.Default,

Re: [IronPython] How to get a System.Exception inside a IronPython except: clause

2008-07-09 Thread Dino Viehland
around that is to rearrange code so that those conditions are met. Is there anything that can (should?) be done about that? -Dan On Tue, Jul 8, 2008 at 6:39 PM, Dino Viehland [EMAIL PROTECTED] wrote: There's a clsException property that we add to Python exceptions that will give you the CLR

Re: [IronPython] Publishing a Module when Embedding

2008-07-10 Thread Dino Viehland
] Publishing a Module when Embedding Michael Foord wrote: Dino Viehland wrote: You can just expose a DLR Scope object directly - which is what IronPython does for modules internally. Bah, damn - I meant to try that before posting and then forgot! Hmmm... although from inside Python code run

Re: [IronPython] repr on c# class

2008-07-10 Thread Dino Viehland
This is 1.x, correct? You should implement the ICodeFormattable interface. That is also present in 2.0 but in 2.0 it's no longer required that you implement it for it to work, you can just define a method named __repr__. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamil

Re: [IronPython] Python Generation

2008-07-11 Thread Dino Viehland
PROTECTED] or [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] On Mon, Jun 30, 2008 at 7:33 PM, Dino Viehland [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: You could take a look at IronPython 1.x's CodeDom support in IronPython.CodeDom.Provider. From there you can get the generator and throw

Re: [IronPython] Using Python special methods in C#

2008-07-13 Thread Dino Viehland
Srivatsn's blog is an important piece of the puzzle, but the more general answer is implementing the __*__ method directly should always work. If it doesn't then it's a bug - like where __repr__ wasn't working w/o implementing the interface until recently. But there is a good reason to not

Re: [IronPython] Add/remove python function to C# event in C#

2008-07-13 Thread Dino Viehland
objOrType.someEvent += somePythonFunctionOrCallableObject And objOrType.someEvent -= somePythonFunctionOrCallableObject Should just work. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Eloff Sent: Sunday, July 13, 2008 4:37 PM To:

Re: [IronPython] Add/remove python function to C# event in C#

2008-07-13 Thread Dino Viehland
of IronPython Subject: Re: [IronPython] Add/remove python function to C# event in C# On Sun, Jul 13, 2008 at 7:20 PM, Dino Viehland [EMAIL PROTECTED] wrote: Ahh I see what you mean now. If you're doing this from the hosting APIs you can use the ObjectOperations class to do the conversion

Re: [IronPython] Object Pooling of IronPython 2.0 engine

2008-07-17 Thread Dino Viehland
We don't have any support for object pooling built-in. Have you considered having 1 ScriptRuntime/ScriptEngine for all requests? You could load compile each piece of code once (so cache any ScriptSource's/CompiledCode objects), and then create a new ScriptScope for each execution to run the

Re: [IronPython] IronPython.Hosting.EngineOptions.ClrDebuggingEnabled in IronPython 2.0 Beta 3

2008-07-21 Thread Dino Viehland
The ScriptRuntimeSetup class has a DebugMode flag that can be set. When you do ScriptRuntime.Create you can pass it the ScriptRuntimeSetup object that you created. FYI configuration is going through some reviews and changes so this will soon be slightly different but you'll do the same basic

Re: [IronPython] os.system

2008-07-23 Thread Dino Viehland
They're in the nt module - usually w/ CPython the os module, which is written in Python, loads the appropriate module (nt/unix/etc...) and delegates to that. In IronPython 2.0 nt now implements both popen* and system. In 1.x we only support popen* and not system. From: [EMAIL PROTECTED]

Re: [IronPython] IronPython Post 2.0 Roadmap

2008-07-23 Thread Dino Viehland
The only problem w/ the existing Type and MemberInfo classes is that they all require inheritance demands to inherit from them. That prevents us from subclassing them in anything core because it won't work in Silverlight or other partial trust scenarios. But it is something we've been working

Re: [IronPython] Switching Mailing List to CodePlex

2008-07-24 Thread Dino Viehland
I believe the advantage would be the discussions would be accessible from the web site as well as the mailing list. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Thursday, July 24, 2008 1:25 AM To: Discussion of IronPython Subject:

Re: [IronPython] Garbage collection of imported modules

2008-07-25 Thread Dino Viehland
It's not just tied to debug because there's also performance reasons to generate it as an uncollectible type. In 1.x there is a -X:GenerateAsSnippets command line option which forces the modules to be collectible (you could also programmatically set Options.GenerateModulesAsSnippets to true).

[IronPython] imports .NET classes...

2008-07-25 Thread Dino Viehland
We've recently been discussing a bug ( http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=16323 ) internally and thought we'd get some broader input on it. Just so you don't have to click on this link this bug is all about how properties get imported and additionally how we deal

Re: [IronPython] Using Python special methods in C#

2008-07-28 Thread Dino Viehland
') from example import Example e = Example() e('r') Traceback (most recent call last): File stdin, line 1, in module TypeError: Example is not callable e.__call__('r') r 3 Michael Dino Viehland wrote: Srivatsn's blog is an important piece of the puzzle, but the more general answer

[IronPython] Protected members breaking change...

2008-07-28 Thread Dino Viehland
We're soon (post-Beta 4) going to be making a breaking change which will alter how protected members are exposed. Currently outside Silverlight or other partial trust scenarios you can access protected members on any type. For example today you can do: import clr # required for

Re: [IronPython] IAttributesInjector

2008-07-29 Thread Dino Viehland
It's located in Microsoft.Scripting.dll (not to be confused w/ Microsoft.Scripting.Core.dll). The way you use this is you apply the assembly level attribute like: [assembly: ExtensionType(typeof(String), typeof(MyStringExtensions))] And then you define MyStringExtensions: public static class

Re: [IronPython] difference b/w ironpython 1 and 2.

2008-07-29 Thread Dino Viehland
The high level differences are: CPython 2.5 compatibility DLR support New hosting APIs New dispatch/binding infrastructure The beginnings of x-lang dynamic lang support Tons of bug fixes general Python compatibility work

Re: [IronPython] PythonEngine

2008-07-29 Thread Dino Viehland
PythonEngine has been replaced w/ the DLR hosting APIs. You'll want to do something more like: ScriptRuntime sr = ScriptRuntime.Create(); sr.Globals[x] = _x; ScriptEngine se = sr.GetEngine(py); There is a spec available for the hosting APIs at

Re: [IronPython] how to convert this code in py 2.0

2008-07-31 Thread Dino Viehland
Or RuntimeHelpers.GetDynamicStackFrames to get the line number information for exceptions that occur at runtime. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dody Gunawinata Sent: Thursday, July 31, 2008 3:12 AM To: Discussion of IronPython Subject: Re: [IronPython] how to

Re: [IronPython] Sandboxing using AppDomains

2008-08-01 Thread Dino Viehland
One thing I’ll point out is in 2.0 we’ve done a bunch of work to make working with a remote app domain pretty easy. You can create the ScriptRuntime in the remote domain and get back a ScriptEngine which lives in the remote domain. All of the calls on the hosting APIs use serializable / MBRO

Re: [IronPython] Performance issue when calling a function with **kw

2008-08-05 Thread Dino Viehland
On my machine it is about 40% faster in 2.0 than 1.1.1 but still about 2x slower than CPython: Current 2.0 bits: (0.930676873737, 3.53996855746) 1.1.1: (1.07254462509, 6.25653658496) CPython 2.5.2: (0.83603013790858893, 1.8179086308455403) -Original Message- From: [EMAIL PROTECTED]

Re: [IronPython] IronPython.Runtime.Exceptions.ImportException: No module named System

2008-08-05 Thread Dino Viehland
You need to add the DLLs you want to be available for importing. We used to add System/mscorlib for you but don't anymore. I suggest doing yourScriptRuntime.LoadAssembly(typeof(System.Diagnostics.Debug).Assembly); -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On

Re: [IronPython] NWSGI 0.4 released

2008-08-05 Thread Dino Viehland
Just out of curiosity what version of Django? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Hardy Sent: Tuesday, August 05, 2008 7:53 PM To: Discussion of IronPython Subject: [IronPython] NWSGI 0.4 released To coincide with the release of

Re: [IronPython] NWSGI 0.4 released

2008-08-05 Thread Dino Viehland
Oh, and regarding your blog which insists I sign in to post :) You can set MultipleActiveResultSets=True in the connection string to get around the cursor problem. That's what I did w/ my provider when I was working on Django compat over at

Re: [IronPython] Roadmap and updates

2008-08-05 Thread Dino Viehland
Yeah, regarding the bugs... We do have a current backlog (~50) of untriaged bugs. We're continuing to go through them and hopefully we'll make good progress at our team meeting on Friday. Our plan for 2.0 is to fix all Medium High Priority bugs on CodePlex so that's the key thing to watch

Re: [IronPython] Roadmap and updates

2008-08-06 Thread Dino Viehland
FYI one thing that might help on the debugging side is the -X:ExceptionDetail command line option to ipy.exe. This is particular useful if you're getting something like a NullReferenceException or IndexError's because usually it leads right to the culprit. In this case that displays this

Re: [IronPython] Roadmap and updates

2008-08-06 Thread Dino Viehland
There's really two reasons. The first is that we try to match CPython for our output including our error messages. The second is that the exception is usually triggered from user code and that can be understood by looking at the stack trace w/o a bunch of internal Python implementation

Re: [IronPython] Deprecation warning on Windows Form Double Buffered

2008-08-07 Thread Dino Viehland
The warning is overly aggressive in this case - the warning is removed for the next release and your code will still work so you can ignore it. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davy Mitchell Sent: Thursday, August 07, 2008 12:54 PM To: Discussion of IronPython

Re: [IronPython] Who's who in IronPython world

2008-08-08 Thread Dino Viehland
And of course not to forget Jim Hugunin :) He's now the architect for GO, DLR, and some general VS languages input as well. Also our team is no longer part of the CLR - we're now in the Visual Studio org. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf

Re: [IronPython] Horrible performance regression of exec on IP2

2008-08-11 Thread Dino Viehland
This is probably because we'll interpret code that is executed using exec. So anything very computationally heavy will be slow in exec. Maybe we need a way to disable that. If you want to see what it'd be like if we weren't interpreting you could use compile() first. -Original

Re: [IronPython] Horrible performance regression of exec on IP2

2008-08-11 Thread Dino Viehland
:[EMAIL PROTECTED] On Behalf Of Seo Sanghyeon Sent: Monday, August 11, 2008 2:00 PM To: Discussion of IronPython Subject: Re: [IronPython] Horrible performance regression of exec on IP2 2008/8/12 Dino Viehland [EMAIL PROTECTED]: This is probably because we'll interpret code that is executed using

Re: [IronPython] Horrible performance regression of exec on IP2

2008-08-11 Thread Dino Viehland
not likely to happen in 2.0 :(. -Original Message- From: Tomas Matousek Sent: Monday, August 11, 2008 2:04 PM To: Discussion of IronPython; Dino Viehland Subject: RE: [IronPython] Horrible performance regression of exec on IP2 The heuristics for function definitions won't actually be a good

Re: [IronPython] int64/long incompatibility in dictionary lookup

2008-08-12 Thread Dino Viehland
I don't think it's a known issue - but it's because we don't have code that unifies the Int64's hashing w/ long's hashing though. We should probably add that for a smoother .NET interop story. I've filed this as CodePlex bug #17799

Re: [IronPython] int64/long incompatibility in dictionary lookup

2008-08-12 Thread Dino Viehland
by their Int64 IDs, so this happens a lot. We can work around it by casting to long, but it's very error prone, since we need to do it in several places. In short, would be very happy if you could unify the hashing for 2.0 thanks On Tue, Aug 12, 2008 at 11:34 PM, Dino Viehland [EMAIL PROTECTED

Re: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1

2008-08-14 Thread Dino Viehland
Awesome information! I'll start taking a look through all of this and let you know what I can improve. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Thursday, August 14, 2008 6:15 AM To: Discussion of IronPython Subject:

Re: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1

2008-08-14 Thread Dino Viehland
BTW time.clock() is what I usually use to measure which works on both CPython and IronPython. On Ipy we use the .NET Stopwatch class which uses a high resolution counter if it's available. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord

Re: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1

2008-08-14 Thread Dino Viehland
IronPython displays it when it starts up on the first line: ... on .NET 2.0.50727.3031 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Thursday, August 14, 2008 2:34 PM To: Discussion of IronPython Subject: Re: [IronPython]

Re: [IronPython] IronPython 2 Beta 4 and .Net 3.5

2008-08-15 Thread Dino Viehland
You'll need to alias Microsoft.Scripting.Core.dll when you're building a 3.5 project. From the command line this is Csc /reference:MSCore=Microsoft.Scripting.Core.dll ... And then you can refer to these namespaces as starting w/ MSCore. Alternately you can leave out the System.Core

Re: [IronPython] Patched, profiling IronPython executable?

2008-08-15 Thread Dino Viehland
FastCallable's certainly the right spot if anything will come close. My main concern is that it'll probably leave a lot of stuff out... In 2.0 this is actually easier. You could modify the DLR in MetaAction.cs to wrap every single dynamic operation - whether that be addition, calling

Re: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1

2008-08-15 Thread Dino Viehland
Ok, I looked into a bunch of these and here's what I've discovered so far and other random comments... Exceptions (10): 40% slower IP1: 4703 IP2: 6125 Py: 266 I haven't looked at this one yet. I do know that we have a number of bug fixes for our exception handling which will

Re: [IronPython] defined in multiple assemblies (framework 3.5)

2008-08-18 Thread Dino Viehland
The only thing I can think of is to explicitly provide the list of assemblies (which I believe you can do through config) and exclude System.Core - of course that only works if you're not using any of the new features. I haven't tried it though so maybe that doesn't work :(... But I do

Re: [IronPython] IP 2: Execute multiple expression in different scopes

2008-08-19 Thread Dino Viehland
Is there a reason ObjectOperations.Call(scope.GetVariable(Process), args) doesn't work? Once you have the function in hand you can call using this and it takes a params array. That params array will be splatted for the call expanding to however many arguments there are there. -Original

Re: [IronPython] defined in multiple assemblies (framework 3.5)

2008-08-19 Thread Dino Viehland
Ok, another thought... can you GAC the DLR assemblies and then add an updated compilers tag to web.config which includes the alias? Something like: system.codedom compilers compiler language=c#;cs;csharp extension=.cs type=Microsoft.CSharp.CSharpCodeProvider, System,

Re: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1

2008-08-19 Thread Dino Viehland
on there. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Friday, August 15, 2008 11:41 AM To: Discussion of IronPython Subject: Re: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1 Dino Viehland wrote: Ok, I looked into a bunch

Re: [IronPython] defined in multiple assemblies (framework 3.5)

2008-08-19 Thread Dino Viehland
9:40 AM To: Dino Viehland Cc: Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) Yikes.. Error19Metadata file 'Microsoft.Scripting.Core.dll' could not be found. This is weird. compiler language=c#;cs;csharp extension=.cs warningLevel=4

Re: [IronPython] defined in multiple assemblies (framework 3.5)

2008-08-19 Thread Dino Viehland
To: Dino Viehland Cc: Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) hmm..still not working. ASP.Net reads those four qualifier as four additional assemblies. Error10Source file 'Version=1.0.0.4000,' could not be found Error11Source

Re: [IronPython] defined in multiple assemblies (framework 3.5)

2008-08-19 Thread Dino Viehland
:\Microsoft.Scripting.Core.dll Where C:\ is some directory where you decide to stash the DLL. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dody Gunawinata Sent: Tuesday, August 19, 2008 10:24 AM To: Dino Viehland Cc: Discussion of IronPython Subject: Re: [IronPython] defined in multiple

Re: [IronPython] defined in multiple assemblies (framework 3.5)

2008-08-19 Thread Dino Viehland
AM To: Dino Viehland Cc: Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) Nope. This compiles well but it won't be available for code behind. ASP.Net can only compiles dll located either on the GAC or under /bin directory. If I put

Re: [IronPython] defined in multiple assemblies (framework 3.5)

2008-08-19 Thread Dino Viehland
Sent: Tuesday, August 19, 2008 11:09 AM To: Dino Viehland Cc: Discussion of IronPython Subject: Re: [IronPython] defined in multiple assemblies (framework 3.5) assemblies add assembly=System.Core, Version=3.5.0.0http://3.5.0.0, Culture=neutral, PublicKeyToken

Re: [IronPython] defined in multiple assemblies (framework 3.5)

2008-08-19 Thread Dino Viehland
I'm continuing to look into it... We're going to have conflicting names because Microsoft.Scripting.Core includes a superset of the functionality in the v3.5 System.Core - and changing that would complicate our internal builds quite a bit. But hopefully we can find a way to get the aliases

Re: [IronPython] Performance of IronPython 2 Beta 4 and IronPython 1

2008-08-19 Thread Dino Viehland
. that was really bugging us. looks like 2.0b5 is where we'll start seriously looking at switching to 2.0. do you know when it's expected? On Tue, Aug 19, 2008 at 7:09 PM, Dino Viehland [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: The fixes for these (specifically the ones I said I had fixes

Re: [IronPython] defined in multiple assemblies (framework 3.5)

2008-08-19 Thread Dino Viehland
in Microsoft.Scripting.Core (if it's actually possible. Hopefully there's no internal classes being used) Dody G. On Tue, Aug 19, 2008 at 9:38 PM, Dino Viehland [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: I'm continuing to look into it... We're going to have conflicting names because Microsoft.Scripting.Core

Re: [IronPython] Re strict imports

2008-09-02 Thread Dino Viehland
To avoid the link demands you can mark your assembly as being SecurityTransparent - see http://blogs.msdn.com/shawnfa/archive/2005/08/31/458641.aspx. That will force link demands from your assembly to turn into full demands which will fail when they hit the untrusted script code. And full

Re: [IronPython] Re strict imports

2008-09-02 Thread Dino Viehland
is rather crippling. Unfortunately the application I'm building will be run by the type of people that have too much time on their hands, I'm not sure how to plug that kind of hole without resorting to filtering each file for 'naughty' commands. --- LC On Tue, Sep 2, 2008 at 9:10 PM, Dino Viehland

Re: [IronPython] Problem calling proper version of function

2008-09-02 Thread Dino Viehland
We never have strong typing so we'll never see the difference between GetInterface() and GetClass(). Instead we'll always just see that we have a MyClass and do the lookup based upon that. The worst case scenario here is you'll need to do IMyInterface.MyProperty.GetValue(instance). OTOH if

Re: [IronPython] Re strict imports

2008-09-02 Thread Dino Viehland
, Sep 2, 2008 at 9:49 PM, Dino Viehland [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: To allow access to the imports the next step in this will be providing your own PlatformAdapationLayer. You'll need to subclass ScriptHost and specify that type as the HostType for a ScriptRuntimeSetup. Your

Re: [IronPython] -X:SaveAssemblies

2008-09-05 Thread Dino Viehland
The big reason the DLR doesn't currently handle it all is that languages are ultimately responsible for how they load the code back - for example IronPython will load the code after it's been AddReference'd. Combine that with wanting a consistent interface which both takes and returns

Re: [IronPython] -X:SaveAssemblies

2008-09-05 Thread Dino Viehland
, 2008 2:21 PM To: Dino Viehland; 'Discussion of IronPython'; 'Curt Hagenlocher' Cc: 'IronRuby' Subject: RE: [IronPython] -X:SaveAssemblies Okay, understood, although I'd think the DLR could just create an abstract base class with various Save/Load methods? The logic in pyc.py is not incredibly

Re: [IronPython] sdlsdk-0.3.0 - cannot import struct?

2008-09-05 Thread Dino Viehland
Can you import _struct? We recently did the work to get this compliant w/ 2.5. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Eloff Sent: Friday, September 05, 2008 2:23 PM To: Discussion of IronPython Subject: [IronPython] sdlsdk-0.3.0 - cannot

Re: [IronPython] How to do ScriptEngine.FormatException now?

2008-09-05 Thread Dino Viehland
It's been moved into a service - you now can do engine.GetServiceExceptionOperations() which gives FormatException and other exception features. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Eloff Sent: Friday, September 05, 2008 7:01 PM To:

Re: [IronPython] irc.rb

2008-09-06 Thread Dino Viehland
You'll probably want to track down where #globalScope is defined and make sure the newly defined variable is getting added to the list of variables in a Scope expression. If there's no scope expression you can just add one and give it the original body the #globalScope var. Hopefully it's

Re: [IronPython] Reopening closed issues

2008-09-08 Thread Dino Viehland
I've re-opened the bugs. On the Silverlight one there may be nothing we can do about it - HTTP doesn't have a dir or ls command so I believe we can only ask for the files by name and get them or not. In general I'd say opening a new bug might be the best way to get our attention but sending

Re: [IronPython] CodeContext

2008-09-08 Thread Dino Viehland
I don't know if I missed a conclusion to this but there is a general way to get a CodeContext. A CodeContext is just a Scope and a LanguageContext. You can new up an empty scope and you can get a LanguageContext from HostingHelpers.GetLanguageContext. But all of this breaks the remoting

Re: [IronPython] Reopening closed issues

2008-09-09 Thread Dino Viehland
Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Eloff Sent: Tuesday, September 09, 2008 2:43 PM To: Discussion of IronPython Subject: Re: [IronPython] Reopening closed issues On Mon, Sep 8, 2008 at 11:22 AM, Dino Viehland [EMAIL PROTECTED] wrote: On the Silverlight one

Re: [IronPython] Reopening closed issues

2008-09-09 Thread Dino Viehland
To: Discussion of IronPython Subject: Re: [IronPython] Reopening closed issues Dino Viehland wrote: In Silverlight we don't have access to the local file system. Instead we the DLR's PlatformAdaptionLayer, which IronPython 2.x builds upon for file access, and that is redirected to the web

Re: [IronPython] Reopening closed issues

2008-09-09 Thread Dino Viehland
: [IronPython] Reopening closed issues Dino Viehland wrote: I thought we were going directly to the web server but I could be wrong. Looking at the code it's not too clear to me - we go to Application.GetResourceStream(uri). I'm not sure whether that's a resource in the XAP or if that's the URI

Re: [IronPython] Regression with importing in pre b5

2008-09-09 Thread Dino Viehland
Do you have more info on this one? I've setup a package structure like: test\ __init__.py: print 'test.__init__' import interface interface.py: print 'test.interface' import templates templates\

Re: [IronPython] Regression with importing in pre b5

2008-09-09 Thread Dino Viehland
is allowable in some cases, then it may be worth fixing this bug. I'm willing to put in the effort required to make a reproduction if you still want to fix this, just let me know. -Dan On Tue, Sep 9, 2008 at 6:53 PM, Dino Viehland [EMAIL PROTECTED] wrote: Do you have more info on this one? I've

Re: [IronPython] Regression with importing in pre b5

2008-09-10 Thread Dino Viehland
Ok, I've confirmed the repro works in B3 but is broken in B4. Indeed it looks like we're just more compatible w/ CPython than we were before. I'm going to go ahead and close the bug. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland Sent

Re: [IronPython] Usage of IronPython 2 Parser

2008-09-10 Thread Dino Viehland
Here's how to do it for both beta 4 beta 5 in Python: import clr clr.AddReference('IronPython') clr.AddReference('Microsoft.Scripting') clr.AddReference('Microsoft.Scripting.Core') from IronPython.Compiler import Parser # beta 4 from Microsoft.Scripting.Hosting import HostingHelpers from

Re: [IronPython] SOAPAction header

2008-09-10 Thread Dino Viehland
Can you post the equivalent VB.NET code? My first guess would be there's an attribute somewhere which is carrying the action - but it is just a guess. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of O'Leary, Jim Sent: Wednesday, September 10, 2008 9:47 AM To:

Re: [IronPython] Can't get asynchronous delegates to work

2008-09-11 Thread Dino Viehland
You're hitting a CLR bug. Here's an explanation of the issue: http://lists.ironpython.com/pipermail/users-ironpython.com/2008-May/007073.html and here's a potential work around: http://lists.ironpython.com/pipermail/users-ironpython.com/2008-May/007078.html It looks like they're still working

Re: [IronPython] unicode problem with vmware api

2008-09-11 Thread Dino Viehland
.NET only has unicode strings as well so that's likely not the problem - it's really just a problem when dealing w/ pre-existing Python code not other .NET code. Could something earlier be different? You might be able to get some ideas by looking at diagMgr.BrowseDiagnosticLog.__doc__ if you

[IronPython] SVN access to IronPython source...

2008-09-16 Thread Dino Viehland
As of a couple of days ago the CodePlex team enabled SVN access for all projects: http://blogs.msdn.com/codeplex/archive/2008/09/14/codeplex-launches-support-for-tortoisesvn.aspx Which of course includes IronPython. So if you don't have TFS, or you're running on some OS where it's not

Re: [IronPython] Named Tuple and IronPython 2

2008-09-19 Thread Dino Viehland
Not too long ago I prototyped a frames implementation including making _getframe work - but it doesn't include locals in the frames. I guess in this case it would work just fine. The downside is it results in a 50% perf degrade on Pybench when calling recursive functions. But we're already

Re: [IronPython] Operations.GetMemberx in b5

2008-09-21 Thread Dino Viehland
Thanks for reporting this - it's definitely a big regression. We switched ObjectOperations from using IOldDynamicObject to IDynamicObject and it looks like we missed a spot that needed to be changed (we need to manually insert the conversions ourselves now). For the time being you can just

Re: [IronPython] IP2b5 - error in calling bound method from C#?

2008-09-22 Thread Dino Viehland
FYI this is the same as bug #18345 - http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=18345 We'll fix this for the RC. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ronnie Maor Sent: Monday, September 22, 2008 6:39 AM To: Discussion of IronPython Subject: Re:

Re: [IronPython] ArgumentTypeException when accessing C# objects, need help!

2008-09-23 Thread Dino Viehland
This is probably due to a loader context issue. Effectively what's happening is your clr.AddReference() from your Python script is probably ultimately doing a LoadFile (putting the assembly into a special context) and otherwise your assembly is getting loaded normally - so you end up w/ two

Re: [IronPython] Getting the full path to a file from a file object

2008-09-24 Thread Dino Viehland
We recently added nt._getfullpathname which could be used as long as the current working directory isn't changing. But other than that I'm not aware of one. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Hardy Sent: Wednesday, September 24, 2008

Re: [IronPython] IPyb5 performance

2008-09-29 Thread Dino Viehland
, the only way I found to get the default scope was through CompiledCode.DefaultScope. Expected it to be accessible directly from the engine. Is there are reason it's not? (or have I just missed it) thanks Ronnie On Mon, Sep 29, 2008 at 2:55 AM, Dino Viehland [EMAIL PROTECTED]mailto:[EMAIL PROTECTED

Re: [IronPython] Getting exception line number?

2008-09-29 Thread Dino Viehland
You can Microsoft.Scripting.Runtime.ExceptionHelpers.GetStackFrames on the Exception object and you'll get back an enumerable of DynamicStackFrame's. That will give you function names, filenames, and line numbers. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Sent:

Re: [IronPython] blocker: objects deleted when they shouldn't be

2008-09-29 Thread Dino Viehland
-- even if it's wildly wrong, it still gives me a framework to work within ;). Cheers William Dino Viehland wrote: Very cool bug and great analysis - thanks for reporting this. BTW That code lives in MetaPythonType.Calls now. It seems like this logic needs to be moved

Re: [IronPython] What happened to source drops?

2008-09-29 Thread Dino Viehland
-comp perf fixes in this week. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Monday, September 29, 2008 2:15 PM To: Discussion of IronPython Subject: Re: [IronPython] What happened to source drops? Dino Viehland wrote: It looks like

Re: [IronPython] What happened to source drops?

2008-09-29 Thread Dino Viehland
: [IronPython] What happened to source drops? Dino Viehland wrote: They're checked in so they'll be in the next source push. There are some perf problems that I have fixes for though that aren't checked in (e.g. import decimal in pre-compiled currently allocates ~550MB of memory) - but you

Re: [IronPython] How to run ScriptCode from ScriptCode.LoadFromAssembly?

2008-09-29 Thread Dino Viehland
My guess is you're hitting a bug I already have a fix for. What's probably happening is we're burning the SymbolID into the compiled code and then when you run it we have the value inappropriately associated with the wrong string. This should be fixed in the latest sources which were just

Re: [IronPython] Syntax Checking

2008-10-02 Thread Dino Viehland
In 2.0 you can call GetCodeProperties on a ScriptSource and it'll give you an indication of how the code is. You can also call ScriptSource.Compile w/ an ErrorListener which can get more detailed information about the failures. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leo

Re: [IronPython] Serializing IronPython classes

2008-10-06 Thread Dino Viehland
I would strongly encourage you to use cPickle or pickle instead of .NET serialization. In 2.0 all .NET serializable types can also be pickled - they define __reduce_ex__ which handles this. First off we should be setting the serializable bit on subclasses that are serializable - that's just a

Re: [IronPython] Serializing IronPython classes

2008-10-07 Thread Dino Viehland
information. On 10/7/08, Dino Viehland [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: Ahh, that sounds like a bad bug, but I think I know what's causing it - we're hitting the new.NET serialization support because __reduce_ex__ is now defined for you :) Can you add an override that dispatches

Re: [IronPython] IPy2b5 Performance

2008-10-07 Thread Dino Viehland
FYI after fixing this it looks like 2.0 is about 2x faster on my machine: 10:51:23.06 C:\Product\0\Merlin\Main ipyr x.py 0.100372393698 10:51:46.32 C:\Product\0\Merlin\Main C:\Product\Released\IronPython-1.1\ipy.exe x.py 0.222078504391 (note I'm using time.clock() which is more precise than

Re: [IronPython] Yield Prolog Benchmarks

2008-10-07 Thread Dino Viehland
Cool, it then looks like the next biggest bottleneck is our isinstance implementation (taking about 20% of the time). Certainly seems like something that deserves optimization and I can probably make some easy improvements and get them into 2.0. -Original Message- From: [EMAIL

Re: [IronPython] Serializing IronPython classes

2008-10-08 Thread Dino Viehland
PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Sent: Wednesday, October 08, 2008 6:06 AM To: Discussion of IronPython Subject: Re: [IronPython] Serializing IronPython classes Fair enough, thanks. Any suggestions on how to work around this in the meantime? On 10/8/08, Dino Viehland [EMAIL

Re: [IronPython] Problem Importing WinForms IPY2.0 B5

2008-10-08 Thread Dino Viehland
Thanks for the bug report. I've opened bug #18849 to track the issue - http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=18849 The fix is actually trivial so I expect it to be in the RC - we're just pass the wrong bools values (they should be flipped) to the ReflectedEvent ctor

<    3   4   5   6   7   8   9   10   11   12   >