And even after that there's still more bugs of yours to fix! :)
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
Sent: Thursday, May 07, 2009 3:54 PM
To: Discussion of IronPython
Subject: Re:
Where does ironpython_console.py come from? There is no IronPythonConsole
class anymore so knowing what exactly the .py file is trying to do would be
helpful. But likely you want to map existing things we're looking for into the
Microsoft.Scripting.Hosting.Shell namespace which lives in
to see which module I am refering to see
http://ipython.scipy.org/moin/PyReadline/Intro
*cheers
And thank you
On Wed, May 6, 2009 at 10:39 AM, Dino Viehland
di...@microsoft.commailto:di...@microsoft.com wrote:
Where does ironpython_console.py come from? There is no IronPythonConsole
class
This one’s a little more complex. It looks like there’s no longer a writable
IConsole property. Instead it looks like you need to create a
PythonCommandLine object and then pass in a ScriptEngine, an IConsole, and a
ConsoleOptions object. That’d look something like:
import clr
: Wednesday, May 06, 2009 4:37 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Assertion failure in IPy 2.6 while running
Django
On Sun, May 3, 2009 at 3:59 PM, Dino Viehland di...@microsoft.com
wrote:
Do you happen to know what baseName is when the assertion is hit?
Hit this again
On Wed, May 6, 2009 at 2:48 PM, Dino Viehland
di...@microsoft.commailto:di...@microsoft.com wrote:
This one’s a little more complex. It looks like there’s no longer a writable
IConsole property. Instead it looks like you need to create a
PythonCommandLine object and then pass in a ScriptEngine
'set_Output'
On Wed, May 6, 2009 at 5:31 PM, Dino Viehland
di...@microsoft.commailto:di...@microsoft.com wrote:
The last line should probably be:
cmdLine.Run(Python.CreateEngine(), IronPythonWrapper(), PythonConsoleOptions())
I thought IronPythonWrapper was an instance but it looks like it’s
] Compiling IronPythonConsole.exe
hmm I did a search through the code there is no set_Output and I searched
Output and set_ as separate search nothing... Now I am confused
Anyway I really appreciate your help :-)
*cheers
Andrew
On Wed, May 6, 2009 at 6:32 PM, Dino Viehland
di...@microsoft.commailto:di
We have an active bug against our new bytes implementation for 2.6. Currently
if you do:
b'***'[0]
you get back 42 as an int. This matches the 3.0 behavior of bytes but in
CPython 2.6 you get back '*'.
We could choose to match either form and then we could change it for 3.0. But
because
Sent: Tuesday, May 05, 2009 4:58 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Mercurial Status
On Mon, May 4, 2009 at 2:13 PM, Dino Viehland di...@microsoft.com
wrote:
You mention bug #22258 - is Mercurial using byte array notation
wherever
they intend to have a non-Unicode
!
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Tuesday, May 05, 2009 2:50 PM
To: Discussion of IronPython
Subject: Re: [IronPython] bytes behavior on 2.6...
Dino Viehland wrote:
We have an active
You mention bug #22258 - is Mercurial using byte array notation wherever
they intend to have a non-Unicode string? I'm just curious because there
may be a lot of other subtle Unicode issues. For example:
foo = open('foo', 'w+b')
b = buffer(u'hello world', 6)
foo.write(b)
foo.close()
in CPython
This is actually a CLR bug. A simple repro of the issue is below if anyone is
curious.
The CLR team has resolved this bug as Won't Fix and says a workaround is
available. The
only workaround I can think of is explicitly queueing the work item to the
thread pool and
provide an object for you
...@lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Monday, May 04, 2009 3:18 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Making asynchronous calls in IronPython
This is actually a CLR bug. A simple repro of the issue is below if
anyone is curious.
The CLR team has resolved this bug
Do you happen to know what baseName is when the assertion is hit?
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
Sent: Sunday, May 03, 2009 1:19 PM
To: Discussion of IronPython
Subject: [IronPython]
My guess this is due to ngen. Normally after the .NET framework installs
there's a ngen service waiting to run in the background and compile all of
the .NET framework.
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of
Yes - I've opened a bug (22235 -
http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22235).
I want to generally improve the doc strings everywhere. I've slowly
been pushing on this and my ultimate goal is to get all of the doc
strings moved into XML comments and then we can read them
You mention CreateEngine but are you also creating multiple runtimes? You're
only allowed 1 ScriptEngine of a given type per ScriptRuntime. So you should
create a new ScriptRuntime and then get the Python engine for each runtime and
then be isolated.
From: users-boun...@lists.ironpython.com
30, 2009 9:08 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Dino Viehland wrote:
You mention CreateEngine but are you also creating multiple runtimes?
You're only allowed 1 ScriptEngine of a given type per
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Dino Viehland wrote:
You mention CreateEngine but are you also creating multiple runtimes?
You're only allowed 1 ScriptEngine of a given type per ScriptRuntime
would you use to process them?
On Thu, Apr 30, 2009 at 10:54 AM, Dino Viehland
di...@microsoft.commailto:di...@microsoft.com wrote:
Yes - I've opened a bug (22235 -
http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22235).
I want to generally improve the doc strings everywhere. I've
, April 30, 2009 9:47 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Dino Viehland wrote:
And this works for me:
I just did the equivalent, from *inside* IronPython which may make a
difference, with the 'os
Based upon the feedback from the mailing list here's the 2.6 release plan and
list of new features:
http://ironpython.codeplex.com/Wiki/View.aspx?title=2.6%20Release%20Plan
Let me know if you have any questions or think there's areas we should include
more info on.
...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Thursday, April 30, 2009 9:28 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
And this works for me:
using System;
using
then we'll include it.
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Thursday, April 30, 2009 12:26 PM
To: Discussion of IronPython
Subject: Re: [IronPython] 2.6 Release Plan
Dino Viehland
-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Thursday, April 30, 2009 12:58 PM
To: Discussion of IronPython
Subject: Re: [IronPython] 2.6 Release Plan
Michael Foord wrote:
Dino Viehland wrote:
Both of those are just oversights
Michael just brought this up on another thread but I thought I'd make it
obvious.
Let us know what bugs you particularly want to see fixed in 2.0.2. Nominate
them here and we'll collect the list and try to fix as many as possible.
___
Users mailing
On 18222 - I think ctypes will drive some changes to our buffer support
making it more real. Right now it's close to useless :) There is some
way for us to make types marshalable via COM ourselves so I think
we'll be able to fix it eventually. I'm surprised that it's more of
a problem than
Yep, we're going to make it available via a command line option. The
Interesting question is what does IPython need from frames? Does it
need locals (which frequently won't be available), globals, the function
or code, or something else?
I think bug 1042 is the one to vote on:
There was some internal work going on w/ running a remote console
and it looks like this change was related to that. In
Microsoft.Scripting.Hosting.Shell there's a comment added to its
RunOneInteraction w/ the same change:
/// We check if the code read is an interactive command or
] On Behalf Of Dino Viehland
Sent: Wednesday, April 29, 2009 11:13 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Expression printing in interactive mode
There was some internal work going on w/ running a remote console
and it looks like this change was related
...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
Sent: Monday, April 27, 2009 4:49 PM
To: Discussion of IronPython
Subject: Re: [IronPython] pywin32 on Iron Python?
On Mon, Apr 27, 2009 at 1:30 PM, Dino Viehland di...@microsoft.com
wrote:
Sorry Jeff, you're
Check to see if the object implements IPythonObject.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Ivan Porto Carrero
Sent: Tuesday, April 28, 2009 10:38 AM
To: Discussion of IronPython; ironruby-core
Subject: Re: [IronPython] Telling .NET
Not to rain on Jeff's parade but I too have been working on a CTypes
implementation. I'll probably check the initial version into 2.6 in the
next few days but there's still a lot more to go before it's a solid
implementation.
As of right now running test\test_ctypes.py reports 358 tests run w/
: Monday, April 27, 2009 12:03 PM
To: Discussion of IronPython
Subject: Re: [IronPython] pywin32 on Iron Python?
On Mon, Apr 27, 2009 at 12:41 PM, Dino Viehland di...@microsoft.com
wrote:
Not to rain on Jeff's parade but I too have been working on a CTypes
implementation. I'll probably check
...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Tuesday, April 21, 2009 2:41 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Compiling with Pyc for Silverlight
Dino Viehland wrote:
You're compiling to a DLL and then trying to import (vs compiling to
an EXE)?
Yes - it's
: Tuesday, April 21, 2009 4:02 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Compiling with Pyc for Silverlight
Dino Viehland wrote:
Do you have a simple repro XAP you can send me and I'll take a look?
I'm not entirely sure I'll know what's going on as CoreCLR isn't the
CLR I'm
In theory there's just 1 IL re-write that's required for this to work. And
that should be replacing the references to mscorlib/IronPython to point at the
Silverlight versions. There's no way to directly have the written binaries
target Silverlight because Reflection Emit has no
...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Monday, April 20, 2009 12:43 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Compiling with Pyc for Silverlight
Dino Viehland wrote:
In theory there's just 1 IL re-write that's required for this to
work. And that should be replacing
Of Michael Foord
Sent: Monday, April 20, 2009 1:24 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Compiling with Pyc for Silverlight
Dino Viehland wrote:
An easy starting point would be to use ildasm + a Python script +
ilasm. There's also CCI (just released on CodePlex last
You're compiling to a DLL and then trying to import (vs compiling to an EXE)?
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Monday, April 20, 2009 3:07 PM
To: Discussion of IronPython
Yeah, I saw that too :(
I think we can definitely add a message for None so that this gets
better. At the very least we can report all of the types of arguments
that we received so the None is at least in your face. In general we
want to improve all of our error messages as they're frequently
).
Thanks again,
Alex
On Tue, Apr 14, 2009 at 11:16 AM, Dino Viehland
di...@microsoft.commailto:di...@microsoft.com
wrote:
For kwargs you need to decorate the function w/ a ParamDictionary
attribute such as:
public void __init__(CodeContext/*!*/ context, object o,
[ParamDictionary
There is an implicit conversion from PythonType - Type. So
(Type)(PythonType)o will work here. Alternately you can just strongly type a
function in C# as taking a Type and call that from Python and the conversion
will happen automatically.
-Original Message-
From:
This is fixed now so pre-compilation is working again in the current 2.6
sources.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Davy Mitchell
Sent: Tuesday, March 31, 2009 1:52 PM
To: Discussion of IronPython
Subject: [IronPython] PYC and 2.6
What DLLs you want to be loaded? The reason I ask is that .NET assembly
loading doesn't really work on the basis of the current working directory -
instead it looks at the app base which by default is where your EXE is located.
We do modify sys.path so that IronPython can load things outside
/Public/hello.zip
cd hello\build\ and die.exe will run
cd hello and run .\build\die.exe and it will fail
Thanks,
Davy Mitchell
On Mon, Apr 6, 2009 at 4:18 PM, Dino Viehland di...@microsoft.com
wrote:
What DLLs you want to be loaded? The reason I ask is that .NET
assembly
loading
You can do:
import clr
from System.IO import File
clr.AddReference(Assembly.Load(File.ReadAllBytes(assemblyName)))
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Samuel Tjokrosoesilo
Sent: Thursday, April 02, 2009 10:43 AM
To: Discussion of
Yeah there is apparently an issue here, Resolver reported it to me the other
day off-line. We've been changing our code gen rather significantly and it
looks like our existing test coverage isn't hitting whatever the issue is here.
I'll probably look at it tomorrow.
From:
Why do you need to cast to the base class? All of the members you need should
already be there.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Carolyn Johnston
(MSNAR)
Sent: Thursday, March 26, 2009 3:47 PM
To: Users@lists.ironpython.com
could probably use
a delegate that takes an object[], but BuiltinFunction contains that
code already, and it is a lot more optimized than I could manage. Plus
it's less code for me to write :).
- Jeff
On Sat, Mar 21, 2009 at 11:45 AM, Dino Viehland di...@microsoft.com
wrote:
If you only
signatures for
the same method name. This could presumably be simulated by replacing the
method group in Python with a new method group that contained all the original
infos plus the new one.
On Mon, Mar 23, 2009 at 11:11 AM, Dino Viehland
di...@microsoft.commailto:di...@microsoft.com wrote:
Do
: Subclassing unicode
On Mon, Mar 16, 2009 at 7:03 PM, Dino Viehland di...@microsoft.com
wrote:
Does this make it work?
class x(unicode):
def __init__(self, val): pass
def __new__(cls, val):
return unicode.__new__(cls, unicode(val))
x(1)
I've voted for the bug
It's actually a CLR bug - we can't call this method from a dynamic method. We
could probably add a workaround and force it to always be called via reflection.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Curt Hagenlocher
Sent: Friday, March
The documentation for using the hosting APIs is available here:
http://dlr.codeplex.com/Wiki/View.aspx?title=Docs%20and%20specsreferringTitle=Home
as dlr-hosting-spec.doc
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On
Do you have IronPython.Modules.dll next to IronPython.dll?
IronPython.Modules.dll contains the implementation of thread.
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Jonatan Nilsson
Sent: Wednesday, March 18,
Also make sure you have IronPython.Modules.dll next to IronPython.dll (if
you're hosting IronPython instead of just running from the command line).
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Michael Foord
The method you're trying to call is generic so you need to index into it to
provide the generic type:
mycalsvc.Insert[type(myentry)](myposturi, myentry)
We're considering adding inference for these type parameters in the future.
From: users-boun...@lists.ironpython.com
The resolution of that bug was that we now expose explicitly implemented
interfaces automatically if there are no naming conflicts. But with COM it's
usually a different story - the members should always just be there. Do the
interop libraries use explicit interface implementation (if they
Does this make it work?
class x(unicode):
def __init__(self, val): pass
def __new__(cls, val):
return unicode.__new__(cls, unicode(val))
x(1)
I've voted for the bug and raised the priority to medium. I've left it
proposed until we triage it as a team (we triage bugs every
It works on CPython 2.6 at least. You should only have to override __new__ if
you wanted to support different arguments than str/unicode.__new__ supports.
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Michael
This is fixed in 2.6 and we can backport the fix to 2.0. Could you open a bug
on CodePlex? If you want to add the fix locally you just need to add the lock
statement below to NewTypeMaker.StoreOverriddenMethods:
lock(PythonTypeOps._functions) {
foreach (BuiltinFunction bf
The fact that we allow setting to the dictionary when we shouldn't be much to
worry about - it is just odd. In either case we still have a .NET type defined
something like:
class NewType : YourBaseTypeHere {
public PythonDictionary __dict__;
public object[] __slots__;
I can't run it right now but if these are happening on the finalizer thread
then this has most likely been fixed in the 2.6 branch already. The issue is
that when a generator is not run to exhaustion we need to call close() on it
which causes an exception to be thrown. But we can avoid the
This one is technically by design. The python code which calls __import__/does
import is the one that gets tainted with the ability to see clr attributes. We
have discussed changing the design so that import clr is recognized at
compile time and works like from __future__ ... instead of being
This is the correct behavior. We expose protected members as normal members
that throw when the instance isn't a subclass defined in Python. But they need
to exist on the base class so that you can do things like super calls to them.
-Original Message-
From:
-
boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Saturday, March 07, 2009 11:51 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Patching __import__ can break .NET attribute
access
Dino Viehland wrote:
This one is technically by design. The python code which calls
or not?
On Mar 7, 7:49 pm, Dino Viehland di...@microsoft.com wrote:
This is the correct behavior. We expose protected members as normal
members that throw when the instance isn't a subclass defined in
Python. But they need to exist on the base class so that you can do
things like super calls to them
You can create the DataSeries object for them and include it in each call? Or
can you do something like:
def Init():
return DataSeries()
and only call their Init function once?
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of
-
boun...@lists.ironpython.com] On Behalf Of Dody Gunawinata
Sent: Thursday, February 26, 2009 12:07 AM
To: Dino Viehland
Cc: Discussion of IronPython
Subject: Re: [IronPython] Please vote up this DLR memory leak bug
Microsoft.Scripting2.Core is a namespace copy of the IP source code -
based
that instance.
CallTarget solved my problem... Do you know any other methodology that works
better then CallTarget?
Thank you,
António Piteira
2009/2/22 Dino Viehland di...@microsoft.commailto:di...@microsoft.com
Depending on what you're doing you might be better off using Funcobject
instead
Can you run w/ the -X:ExceptionDetail command line option the for the import
Crypt / from Crypto import * and report back the stack trace you get?
I'm not sure that I'll be of much use but if it's somewhere in IronPython
instead of IronClad it might be an IronPython bug.
-Original
Just some comments on this as there's a few issues intertwined here:
1. Optimized code - this is currently the default and part of the
original problem. If you execute code in optimized mode we generate an
uncollectible type. In 2.6 I'm switching the default to be non-optimized and I
Depending on what you're doing you might be better off using Funcobject
instead of CallTarget0. CallTarget0 is more of a Python implementation detail
and could change w/ major IronPython versions - or even be replaced w/
Funcobject. it's primary purpose is to be the delegate for calling a
, February 19, 2009 9:55 AM
To: Discussion of IronPython
Subject: Re: [IronPython] how to use an enum from a hosted script
Dino Viehland wrote:
Generally what you'd do is:
import clr
clr.AddReference('yourdll')
from MyNamespace import NotificationTypeEnum
I have no idea where
It sounds like you're hitting a bug in the codedom round tripping support.
IronPython Studio is really more of a sample and leaves much to be desired so
it's likely you'll hit many more. Michael Foord who has done tons of winforms
development I believe recommends designing it in C# and then
Awesome, thanks for tracking this down. This looks trivial to fix - we're just
missing a lock statement. I've added the lock to my next change that will go
in (probably today).
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On
Or if your program has no UI components you can start with the -X:MTA option
and the warning won't get issued.
Unfortunately the 2nd you hit a different warning it's likely you'll have the
same problem. So the underlying problem looks like we're somehow picking up a
different linecache.py or
.
pj
On Mon, Feb 9, 2009 at 7:49 PM, Dino Viehland di...@microsoft.com wrote:
If I setup this as you describe from the command line it just works:
x\
subdir\
__init__.py
mymodule.py:
import clr
...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Saturday, February 07, 2009 6:04 AM
To: Discussion of IronPython
Subject: Re: [IronPython] repr() results with uint, etc.
Dino Viehland wrote:
And the correct change to the source code would be adding
There's no existing functionality to do this but we could add __repr__
overloads onto the built-in types. They would presumably return something like:
System.UInt32(1)
or:
UInt32(1)
Could you open a bug?
-Original Message-
From: users-boun...@lists.ironpython.com
And the correct change to the source code would be adding __repr__ methods to
the various *Ops types (Int16Ops, UInt16Ops, etc...) which return the correct
formatting. Presumably by updating the scripts that generate these types.
OTOH there's nothing particularly unsafe about your changes
is a nasty hack and
we'd rather not do it :)
Regards,
Orestis Markou
Resolver Systems Ltd.
Dino Viehland wrote:
Yep, and I'm happy to move back to the old behavior - being consistent w/
ourselves and broken seems better than being inconsistent w/ ourselves and
broken :)
-Original Message
(informal) documentation for the
parser/compiler?
Eyvind.
-Opprinnelig melding-
Fra: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] På vegne av Dino Viehland
Sendt: 4. februar 2009 18:04
Til: Discussion of IronPython
Emne: Re: [IronPython] Getting hold
What do you mean by 'existing'? Do you want the class definitions which the
current statement is nested in? Do you want to get to an arbitrary class
definition somewhere in the AST?
Currently we don't maintain any of this but there's no reason you couldn't
modify PythonAst.TransformToAst so
) support for numpy using
our Ironclad project.
We're releasing the beta tomorrow: this has a few performance
problems (which are being addressed - many thanks to Dino Viehland
for helping with this!) but is otherwise functionally complete.
If you're interested in trying it out, drop me
that is a great plan. Having no P/Invokes makes it much more
platform agnostic.
On Wed, Feb 4, 2009 at 2:20 PM, Dino Viehland di...@microsoft.com wrote:
Current thinking is that IronPython 3k will be the 1st version that will
take a dependency on .NET 4.0 so we'll have to wait until
You're right that it worked in 1.0 - but of course in 1.0 we would also end up
with an arbitrary ordering between engines. For example you could have:
Engine 1:
Sys.path = C:\
Contains Foo.dll
Engine 2:
Sys.Path = D:\
Contains Foo.dll
Which
Foord
Sent: Friday, January 30, 2009 3:30 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Two engines and clr.AddReference don't work together.
Dino Viehland wrote:
You're right that it worked in 1.0 - but of course in 1.0 we would also end
up with an arbitrary ordering between engines
You can always provide your own stream which is aware of what the current
output window is. It could store this in a thread static or just some variable
that you update whenever the active window changes. You can set that via
ScriptRuntime.IO.OutputStream. You could conceptually do the exact
: Friday, January 30, 2009 6:41 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Redirecting stdout/stderr, but with context
Dino Viehland wrote:
You can always provide your own stream which is aware of what the current
output window is. It could store this in a thread static or just
Of Renaud Durand
Sent: Wednesday, January 21, 2009 8:12 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Calling a Python function (compiled into an assembly)
from C# using delegates.
That is the point. I don't want to do that from a file but from an Assembly
(dll).
2009/1/21 Dino Viehland di
'Microsoft.Linq.Expressions.ParameterExpression' in
Assembly 'Microsoft.Scripting.Core, Version=0.9.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' is not marked as serializab
le.
Marc
On Wed, Jan 21, 2009 at 5:57 PM, Dino Viehland di...@microsoft.com
wrote:
Can you run w
An alternate plan would be to run your script in another app domain. Then you
can just unload the app domain and all shared state will be cleared. The
hosting APIs make this pretty easy to do as well.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On
Good places to look would be:
ExceptionHelpers.UpdateStackTrace is where the frame should be
remembered
PythonOps.CreateTraceBack should be where we actually pull the current
set of frames for exceptions and build up the stack trace
You should be able to just copy and paste throwing error sink into your own
version, it's pretty simple:
internal class ThrowingErrorSink : ErrorSink {
public static new readonly ThrowingErrorSink/*!*/ Default = new
ThrowingErrorSink();
private ThrowingErrorSink() {
}
Strangely I don't see one - this is frequently asked for so I'm a little
surprised :)
I have a plan on how to enable this (and some other .NET scenarios) in the next
major release. My current thinking is to support this via meta-classes and
providing a new method on type which lets you
Are there other exceptions being thrown, potentially somewhere on the stack
below game\models\__init__.py on line 144? Maybe we're calling a built-in
function somewhere that's calling back into your code and is doing something
funky with the exception tracking. Can you run this under VS and
are
slower when executed from dlls, so the same slow down might be
triggered by sth else.
On Wed, Dec 17, 2008 at 3:21 AM, Dino Viehland di...@microsoft.com
wrote:
My guess would be that we're pushing the PythonContext._callSplatSite
outside of the sweet spot in DLR site caches.
You could
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
601 - 700 of 1614 matches
Mail list logo
