Re: [IronPython] Issue about string.upper and string.lower

There were no issues with making this change revealed by our tests. The change is in our 2.1 branch internally so should so up externally really soon. I suspect we'll discuss backporting it to 2.0.1 at one of our team meetings but unless we hear about some issues this causes then I personally

[IronPython] test...

This is just a test... there were some issues with the mailing list today, just verifying that it should be back now. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Loading IronPython.dll from memory

I snipped a little extra - my code is really: Dictionary runtimeOptions = new Dictionary(); runtimeOptions["Debug"] = true; m_runtime = IronPython.Hosting.Python.CreateRuntime(runtimeOptions); m_runtime.LoadAssembly(typeof(String).Assembly); // Add reference to System m_runtime.LoadAssembly(typeof

Re: [IronPython] Loading IronPython.dll from memory

Jeff Slutter wrote: [I can work around this, but I'm curious if there is a solution] Due to some crazy requirements, I'm trying to load my assemblies from memory. I have setup an Assembly Resolver with: AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(ResolveInternalAssembly);

[IronPython] Loading IronPython.dll from memory

[I can work around this, but I'm curious if there is a solution] Due to some crazy requirements, I'm trying to load my assemblies from memory. I have setup an Assembly Resolver with: AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(ResolveInternalAssembly); And it gets called.

[IronPython] ASP.Net IronPython Refresh

Does anybody know when the IronPython for ASP.Net gets updated for the final version of IronPython 2.0? -- nomadlife.org ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] weird performance issue

Oh, if you also want to get a list of call stacks to PythonContext.Call and send those our way that'd be useful as well. In general we only want to hit that when the overall cost of whatever we're doing will dwarf any overhead of that one call. And we certainly have more calls to it then we sh

Re: [IronPython] weird performance issue

Here's the simplest version of the fix, it's just updating one file so properties get their own call sites. I'll work on a more involved fix that I'll get into 2.1 soon and probably into 2.0.1 a few days later. Note this diff is from 2.1 but I've updated the names of things that have changed s

Re: [IronPython] DLR spec document

We recently created a separate codeplex project for the DLR and that will host the latest DLR documents (including the Hosting spec). Please see this - http://www.codeplex.com/dlr/Wiki/View.aspx?title=Docs%20and%20specs&referringTitle=Home This page is guaranteed to contain the latest DLR docume

Re: [IronPython] weird performance issue

There is one difference between pre-compiled & compiled at runtime: Global accesses will be a little bit slower with compiled files. That's because the files need to support being loaded into multiple ScriptRuntime's where if we compile it they don't. Other than that they should be basically t

[IronPython] DLR spec document

Hi all, the Hosting API spec from http://blogs.msdn.com/ironpython/archive/2008/03/16/dlr-resources.aspx seems to contain insinuations that it is not up-to-date. I was wondering if this actually stands and how much we should depend on it. Thanks very much, Orestis -- Orestis Markou Software

Re: [IronPython] weird performance issue

Also: It seems that even normal properties are slower than methods. This became apparent when we had property access in tight loops. The weird thing is that this also happens only when using compiled dlls. Is there something inherently different with compiled python files? Perhaps some optimiz

Re: [IronPython] weird performance issue

Thanks Dino, it looks like you are right. I print whenever _supportAdding == false. It happens a lot with the snippet executed, whereas it doesn't happen at all with the snippet commented out. We also discovered that the slow down only occurs when we compile code to dlls (no _supportAdding == fals

Re: [IronPython] Change in stack traces

I'm guessing the comparison to CPython here is a comparison to code that has been exec'd or eval'd. You can pass a PythonCompilerOptions to scriptSource.Compile with ModuleOptions.ExecOrEvalCode and you should then get the 1.x/CPython behavior. From: users-boun...@lists.ironpython.com [mailto

[IronPython] Change in stack traces

Hi all, Another observation from the Resolver One upgrade: When we run the following: engine = Python.CreateEngine() scope = engine.CreateScope() script = """ def Fn(): raise Exception Fn() """ source = engine.CreateScriptSourceFromString(script, 'aname', Source

Re: [IronPython] IronPython and file descriptors

Just a quick note: you can't necessarily just P/invoke out to msvcrt, because CPython was built with msvcr71. Sorry :(. Tom Wright wrote: I'm not sure about sockets. The only example I have found in the wild so far is with files in PIL. The python implementation seems to have socket.fileno()

Re: [IronPython] Newbie: convert string to python expression??

You should definitely use a separate context, or you will get bitten by it later on. To debug similar things, use the tried and true print: print the context before you execute something, and after. In your case: print 'before', context print eval(result, context) print 'after', context Also

Re: [IronPython] Invalid construct in DLR's MSBuild file?

2008/12/16 Curt Hagenlocher : > This looks like a problem in quite a few of our csproj files. Could you > open up a bug report on CodePlex for this? Done. http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=20262 -- Seo Sanghyeon ___ User