You can set DebugMode = true on a ScriptRuntimeSetup object. If you're using
the Python class you can pass a Dictionary object to CreateRuntime with Debug
= true and we'll set it for you.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Worbis
Sent: Sunday, October 12,
Auftrag von Dino Viehland
Gesendet: Sonntag, 12. Oktober 2008 21:21
An: Discussion of IronPython
Betreff: Re: [IronPython] Debugging IronPython script code
You can set DebugMode = true on a ScriptRuntimeSetup object. If you're using
the Python class you can pass a Dictionary object to CreateRuntime
as external
code.
So is there a possibility to have VS show the script code?
Rainer
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Dino Viehland
Gesendet: Sonntag, 12. Oktober 2008 21:21
An: Discussion of IronPython
Betreff: Re: [IronPython] Debugging IronPython script code
You can set
The difference is whether or not you're the owner of the array. If you've
accepted the array from some public location, even if it was a params method,
someone else could own the array and continue to modify it. If you've created
the array yourself or can guarantee it won't change then it can
It sure looks like it - are there more though? I'd expect one for each action
kind. The methods differ in generic arity and the type of array they accept so
at the very least the error string is wrong even if it is bad style to differ
that way.
-Original Message-
From: [EMAIL
: [IronPython] Warning CS3006
2008/10/11 Dino Viehland [EMAIL PROTECTED]:
It sure looks like it - are there more though? I'd expect one for each
action kind. The methods differ in generic arity and the type of array they
accept so at the very least the error string is wrong even if it is bad
I think if you're not replacing Globals on the script runtime you can fetch the
namespace from the ScriptRuntime.Globals scope.
If that doesn't work for some reason you can always new up a
TopNamespaceTracker, load assemblies into it, and get the namespace trackers
from it. You'll need to get
);
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Friday, October 10, 2008 1:12 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Can I pre-add namespaces?
I think if you're not replacing Globals on the script runtime you can fetch the
namespace from
);
scriptSource.Execute(scope);
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Friday, October 10, 2008 2:25 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Can I pre-add namespaces?
That seems like a good solution, the perf should
scriptSource = engine.CreateScriptSourceFromString(
import System\r\n + script, SourceCodeKind.Statements);
scriptSource.Execute(scope);
From: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] [mailto:[EMAIL
PROTECTED]mailto:[EMAIL PROTECTED]] On Behalf Of Dino
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
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
You're right on #1 - for other nodes you could also look at how the parser
creates them (or ask if there's something particularly tricky).
For #2 there isn't a good way to do this right now. You could cheat and do it
with private reflection for the time being. First you need to create a
to wait until the legal hurdles with
accepting community contributions have been cleared.
#3 - Sounds good, it's C# so fortuantly the compiler will flag most of
the breakages for me.
Thanks,
-Dan
On Wed, Oct 8, 2008 at 4:26 PM, Dino Viehland [EMAIL PROTECTED] wrote:
You're right on #1 - for other
Each ScriptRuntime is isolated from each other. So the reasons to use multiple
ones would come down to wanting to set different global options, have scripts
belonging to different users running, have scripts running on multiple threads
which are isolated, etc...It can also be useful to run
deployed types and assemblies via
the server portion of our product, if there was something exposed we can
manipulate against the API, that would be better.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Wednesday, October 08
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
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
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
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
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
, 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
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:
-- 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
-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
: [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
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
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
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
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:
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
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
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
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
.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
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
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
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:
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
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
: [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
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\
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
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
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
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
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
, 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
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
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:
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
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
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
, 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
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
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,
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
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
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
:\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
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
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
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
. 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
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
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
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
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
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
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:
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
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]
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
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
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
:[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
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
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
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
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
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
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]
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
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
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
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
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
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
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
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
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
')
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
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
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).
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
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:
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]
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
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
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
801 - 900 of 1614 matches
Mail list logo
