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
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
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
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
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]
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
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,
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
] 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
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
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
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
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:
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
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
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
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
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:
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
')
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 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
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
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
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
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
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
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
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
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
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]
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
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
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
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
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:
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
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
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
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:
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
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
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
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
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:
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
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
, 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
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
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
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
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
701 - 800 of 1614 matches
Mail list logo
