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
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
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
Did you set DebugMore = 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.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yongming
Sent:
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
This is all still on 1.x, right? It looks like #1 is fixed in 2.0 (we are
locking but on the wrong object in 1.x).
#2 is still broken in 2.x though as well.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamil Dworakowski
Sent: Monday, October 13,
Dworakowski
Sent: Monday, October 13, 2008 9:07 AM
To: Discussion of IronPython
Subject: Re: [IronPython] parallel importing
Would that be easy to backport fix for #2 to 1.x branch?
On Mon, Oct 13, 2008 at 5:00 PM, Dino Viehland [EMAIL PROTECTED] wrote:
This is all still on 1.x, right? It looks
The tutorial will be updated for the RC. But the code should now be:
from System.Runtime.InteropServices import DispatchWrapper, UnknownWrapper
c = clr.StrongBox[object](DispatchWrapper(None))
a.GetCharacter(cid.Value, c)
c.Value.Show(0, reqid)
c.Value.Think(IronPython Tutorial, reqid)
That's
.
Is there something to setup before?
Rainer
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Dino Viehland
Gesendet: Montag, 13. Oktober 2008 07:15
An: Discussion of IronPython
Betreff: Re: [IronPython] Debugging IronPython script code
Oh, sorry, it looks like it needs to be a bool, not true
splash screen, and then the
next two display an already running dialog.
Any chance of getting the .net people to help out with this?
--
Vernon Cole
On Mon, Oct 13, 2008 at 10:00 AM, Dino Viehland [EMAIL
PROTECTED]mailto:[EMAIL PROTECTED] wrote:
This is all still on 1.x, right? It looks like #1
Could you provide a patch?
On Mon, Oct 13, 2008 at 5:31 PM, Dino Viehland [EMAIL PROTECTED] wrote:
Making the code changes is easy - the hard part is really doing a new 1.x
release and all of the sign off work that entails. We haven't ruled it out
but we sure would like to avoid
Harry's currently pushing on the lawyers to get this through although he's been
a little distracted by PDC. I certainly hope we can take this back in 2.1 but
I can't promise anything. The good news is that a Michael points out this is
the exact sort of thing we want to take back first.
In
Wow, I'm surprised it's documented as being thread unsafe in CPython, but it's
good to know.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ronnie Maor
Sent: Monday, October 13, 2008 1:57 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Problem with random module in IPY
of IronPython
Subject: Re: [IronPython] What's the situation on being able to accept patches?
On Mon, Oct 13, 2008 at 3:50 PM, Dino Viehland [EMAIL PROTECTED] wrote:
In the mean time I would assume you just need the FunctionDefinition and
Expression exposed off of GeneratorExpression
of IronPython
Subject: Re: [IronPython] parallel importing
Could you provide a patch?
On Mon, Oct 13, 2008 at 5:31 PM, Dino Viehland [EMAIL PROTECTED] wrote:
Making the code changes is easy - the hard part is really doing a new 1.x
release and all of the sign off work that entails. We haven't
This is because we're not firing the module changed event. This seems like a
bug, we should probably use a special dictionary here. You can call
ScopeOps.SetMember() and it'll also deliver the event.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan
I believe the fix for this is simple if you want to give it a shot. In
ClrModule.cs in BuildPackageMap there is a loop that looks like:
do {
if (pkgName != string.Empty) {
fullName = pkgName + . + fullName;
}
PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Beckius
Sent: Thursday, October 23, 2008 1:47 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Error only from Test Case
We're NUnit and TypeMock.
On Thu, Oct 23, 2008 at 4:38 PM, Dino Viehland [EMAIL PROTECTED]mailto:[EMAIL
Is the exception you're seeing Error while invoking Item? Just want to make
sure I'm seeing the same thing and the actual exception is cut off in your
snippet below.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zaur Shibzoukhov
Sent: Monday, October
Oh, and I'm not sure if this is by design or not (I'll need to ping the DLR
team), but it seems you can do:
wd.Variables.Item('foo')
instead.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Monday, October 27, 2008 7:44 AM
You might find Dynamic / DynamicObject to be more useful for doing simple
method-missing style calls. IDynamicObject gives you a lot of power you might
not need - but then again you can do some pretty cool things with it too.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dody
Currently you can't see module globals in the debugger but we are working on
improving the VS experience. You should be able to see locals that are defined
in a function though today.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Tuesday, October 28,
No - we've briefly spoke about having our 3.0 release be the next version to
require a new CLR version and that would be CLR 4 where we get DLR support
baked in - but there's nothing concrete yet.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael
We're picking the ObjectHandle overload for some reason. You can use
.Overloads to select the correct overload. I'm actually surprised you don't
get a different type error saying the call is ambiguous so I'll have to take a
deeper look to understand that.
-Original Message-
From:
Thanks Michael, I've opened a bug to fix this:
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19278
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Friday, October 31, 2008 4:52 AM
To: Discussion of IronPython
Just one other comment on top of what Curt said. You might more properly think
of Main as IronPython 3k. Main includes a ton of renames and other breaking
made in Microsoft.Scripting.Core/System.Core that will end up in .NET 4.0.
We're still working on what we want to do for 2.1 (and input
We try to import from the file system before we attempt to import from the DLR
(which includes both globals .NET namespaces). So in this case we'll pick up
foobar from disk because presumably these 2 engines both share the entry in
sys.path where foobar lives.
I think long term this logic is
.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Friday, October 31, 2008 9:53 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython 2: Oddity with Hosting API from within
IronPython
Dino Viehland wrote:
If you also have those
confusing...
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Friday, October 31, 2008 9:40 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython 2: Oddity with Hosting API from within
IronPython
Dino Viehland wrote:
We try
On Fri, Oct 31, 2008 at 10:30 AM, Dino Viehland [EMAIL
PROTECTED]mailto:[EMAIL PROTECTED] wrote:
Just one other comment on top of what Curt said. You might more properly think
of Main as IronPython 3k. Main includes a ton of renames and other breaking
made in Microsoft.Scripting.Core/System.Core
To: Discussion of IronPython
Subject: Re: [IronPython] 2.1 Branch in Codeplex Sources
Dino Viehland wrote:
There will certainly be some 2.6 features. But we still haven't quite
figured out what 2.1 is yet. So if there's a particular 2.6 feature,
or if you'd just like us to see us do them all, let us
I pinged Tomas on this and he thinks this is by design and I'm tending to agree
(even though it is just a side effect of us using a StreamWriter). You can
always pass a Stream and a TextWriter instead to get full control over this
behavior.
Good test though and I'll follow up w/ Bill to make
Ultimately it's because we don't have Unicode and byte strings - we get little
incompatibilities like this popping up every now and then due to that.
I'm guessing this particular one could come back to behavior in the str.decode
w/ raw_unicode_escape or unicode_escape. I say that because the
...
import imp
foo = imp.new_module('foo')
...
is a step in the right direction.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher
Sent: Monday, November 03, 2008 10:45 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Loading Python modules from Silverlight
What’s the problem w/ declaring a lambda inside an exec?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth Miller
Sent: Monday, November 03, 2008 10:53 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Loading Python modules from Silverlight Isolated
Storage
It was
Another option, assuming it's possible, would be to exec the function
definition as well as the lambda.
Also I would expect exec ... in locals() would work the same as in
dict(locals()). Which might also be problematic if you expect to see changes
in the closure:
def f():
a = 1
d =
Thanks for the report. I've opened CodePlex bug #19350 to track this
(http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19350).
I believe the fix is actually pretty simple and we'll discuss whether we'll
take it for 2.0 final at our Friday team meeting. If you want to try out
If it's an object defined in Python you can usually attach methods directly to
the object or it's Python type. But otherwise we have no support for
automatically adding .NET extension methods to existing types currently. It is
a frequent request and we will probably get to it at some point.
In this case widget is the string hello world so it won't work. If it was
instead something like:
class x(object): pass
a = x()
...
Then in C# you could do:
widget = scope.GetVariable(a)
then you could do engine.Operations.SetMember(widget, foo, () = hello
world);
and then back in Python:
It's because when I initially looked at WindowsError it sure seemed like 22 was
the error code that was always used :). If you do:
for i in xrange(100):
print WindowsError(i, i).errno
on CPython You'll see a large amount of the errno's are set to 22 (including 0
and 1) - apparently I
I would suggest getting a snap shot of the call stacks when this is happening
if that's possible. I can't pin anything down but I wonder if you could have
an STA object or something that otherwise requires message pumping. That
message pumping could happen while you're doing a Monitor.Enter
only got a single failure
over dozens of runs, and it turned out I'd got the logging wrong,
so I didn't find out anything useful :(.
Dino Viehland wrote:
I would suggest getting a snap shot of the call stacks when
this is happening if that's possible. I can't pin
Thanks, I've filed this as CodePlex #19363
(http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19363)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William Reade
Sent: Thursday, November 06, 2008 8:58 AM
To: Discussion of IronPython
The short answer is no – we realize frames is a common request and I do have a
prototype implementation of them. We’re still working on our 2.1 planning but
it might be available there w/ a command line option or it might be something
we could port to 2.0.1.
The longer answer would be
anything useful :(.
Dino Viehland wrote:
I would suggest getting a snap shot of the call stacks when this is happening
if that's possible. I can't pin anything down but I wonder if you could have
an STA object or something that otherwise requires message pumping. That
message pumping could happen
By custom class you mean a class you've written? And then you want it to
light up with dynamic languages?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marty Nelson
Sent: Thursday, November 06, 2008 7:18 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Extension
PROTECTED] On Behalf Of Dino Viehland
Sent: Thursday, November 06, 2008 7:20 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Extension methods in python
By custom class you mean a class you’ve written? And then you want it to
“light up” with dynamic languages?
From: [EMAIL PROTECTED
:
I'll look into that along with everything else :).
Dino Viehland wrote:
Do you know if numpy is using COM anywhere? Or does Ironclad use COM
for any of its interop?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of William Reade
Sent: Thursday
I'd start w/ -X:ExceptionDetail to get the full stack trace. Presumably
there's something higher up the stack then the MatchCaller on the stack.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davy Mitchell
Sent: Saturday, November 08, 2008 6:19 AM
To:
.
Cheers,
Davy
On Sat, Nov 8, 2008 at 5:39 PM, Dino Viehland [EMAIL PROTECTED]mailto:[EMAIL
PROTECTED] wrote:
I'd start w/ -X:ExceptionDetail to get the full stack trace. Presumably
there's something higher up the stack then the MatchCaller on the stack.
-Original Message-
From: [EMAIL
I think it's largely intentional. In v1 we exposed namespaces as modules and
also did ugly things like supported merging of namespaces and modules. In V2
we did a bunch of cleanup there and moved the former Python code into the outer
layer of the DLR. That involved also making the namespaces
I think you want to do:
rancore.Repository.ElementRepository.CreateAdapterForPath[str][str](...)
or:
rancore.Repository.ElementRepository.CreateAdapterForPath[str].Overloads[str][str](...)
or:
rancore.Repository.ElementRepository.CreateAdapterForPath[str][str].Overloads[str](...)
I think
12, 2008 at 2:01 PM, Dino Viehland [EMAIL PROTECTED]mailto:[EMAIL
PROTECTED] wrote:
Instead of doing:
ScriptScope scope = engine.CreateScope();
Console.WriteLine(DateTime.Now);
source.Execute(scope);
do:
source.Compile().Execute
AddReference(str) will first try Assembly.Load and then try
Assembly.LoadWithPartialName - this should mean that trying w/ the strong name
won't do anything because LoadWithPartialName will do that for you. This is
kind of the one-stop shopping for loading assemblies in the GAC or the app
difference I found on how the script is called from python and
DLR.
Any comments?
regards,
wilfredo
On Wed, Nov 12, 2008 at 2:56 PM, Dino Viehland [EMAIL PROTECTED]mailto:[EMAIL
PROTECTED] wrote:
CompiledCode exposes the default scope it executes in via the DefaultScope
property. So hold onto
Instead of doing:
ScriptScope scope = engine.CreateScope();
Console.WriteLine(DateTime.Now);
source.Execute(scope);
do:
source.Compile().Execute()
and your code should then run in an optimized default scope for the code - just
like it does
get the default scope (from ScriptEngine or ScriptSource) to be
able to get the delegate?
regards,
wilfredo
On Wed, Nov 12, 2008 at 2:01 PM, Dino Viehland [EMAIL PROTECTED]mailto:[EMAIL
PROTECTED] wrote:
Instead of doing:
ScriptScope scope = engine.CreateScope
Actually I'd say modifying built-in types is unpythonic - for example you can't
do object.xyz = 42. We could choose to break this rule for types we don't
share between Python .NET, and it probably wouldn't be a lot of work, but I'm
hesitant to have the two sets of types treated differently.
] Some thoughts on namespaces, extension methods
On Wed, Nov 12, 2008 at 4:19 PM, Dino Viehland [EMAIL PROTECTED] wrote:
Actually I'd say modifying built-in types is unpythonic - for example you
can't do object.xyz = 42. We could choose to break this rule for types we
don't share between
at 5:39 PM, Dino Viehland [EMAIL PROTECTED]mailto:[EMAIL
PROTECTED] wrote:
The only thing that immediately pops out at me as being different is we also
set ModuleOptions.ModuleBuiltins in the command line case - but I wouldn't
expect it to make such a large difference. But try setting
This is the script I used for compiling the standard library:
import clr
import System
def get_files(dir):
if 'lib-tk' in dir: return ()
if '.\\test' in dir: return ()
res = [file for file in System.IO.Directory.GetFiles(dir, '*.py')]
dirs =
Thanks for opening those initial bugs Vernon! I've gone ahead and created the
full list of 2.6 feature based upon the 2.6 what's new document. If anyone
sees anything I missed feel free to open the bug and/or respond to this thread.
And please vote on your favorite issues.
19522: 2.6: from
You could store the value in a clr.StrongBox[int] and pass that instead and it
should work. The way you're calling increment now it's always passing in the
value and returning a tuple of prevValue, newValue.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
This is definitely possible but it'd be a hack and would have some odd corner
cases. In terms of Python the problem here is we could find out the func_code
(MethodInfo's in .NET speak) but not the actual function object. We could
maintain a mapping which would let us get back to function
Yep, we missed this again when we re-wrote precompilation support :( I have
another pyc update I need to make and I'll update it to set sys.argv as well.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oren Held
Sent: Tuesday, November 18, 2008 2:29 AM
Thanks for the report. We should be defining __index__ on the .NET primitive
numeric types as well. Filed as 19657 -
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19657
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Jones
Sent: Wednesday, November 19,
Yeah, that's pretty bad... I've filed this as 19658 -
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19658. Thanks
for reporting this.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Wednesday, November 19, 2008
Ok in that case I've closed mine :)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Wednesday, November 19, 2008 8:49 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython 2 Bug: Module Name Lookup Broken
Dino Viehland
It's not really possible to get back to the ScriptEngine - but you also
probably don't need to. You probably want to get back to the
LanguageContext(PythonContext)/ScriptDomainManager and work with those
directly. ScriptEngine/ScriptRuntime are wrappers around those which expose
the friendly
Interesting, the docs would seem to indicate our behavior is correct:
For user-defined classes which do not define __contains__() and do define
__getitem__(), x in y is true if and only if there is a non-negative integer
index i such that x == y[i], and all lower integer indices do not raise
Oh, on the formatting - CodePlex actually preserves the white space it just
doesn't display it. It's annoying but I'm not aware of a way to make it
actually display other than clicking Edit which I think only we can do :(.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn
.
Am I missing something obvious?
William Reade wrote:
Thanks Dino -- I'll see what I can do with that :)
Dino Viehland wrote:
It's not really possible to get back to the ScriptEngine - but you
also probably don't need to. You probably want to get back to the
LanguageContext(PythonContext
.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Thursday, November 20, 2008 3:34 PM
To: Discussion of IronPython
Subject: Re: [IronPython] in operator calls __getitem__ on class that has
__len__ and __iter__ defined
Michael Foord wrote:
Dino
them.
Am I missing something obvious?
William Reade wrote:
Thanks Dino -- I'll see what I can do with that :)
Dino Viehland wrote:
It's not really possible to get back to the ScriptEngine - but you
also probably don't need to. You probably want to get back to the
LanguageContext(PythonContext
System.Windows.Threading.Dispatcher.BeginInvoke in Silverlight has an overload
which takes a System.Action. In .NET 3.5 it seems to only have overloads which
take Delegate. So on the desktop CLR we don't have any idea of what type of
delegate to convert it to vs. Silverlight we know to go to
We're going to fix this bug a couple of others (in addition to the couple fixed
in the current sources) and release an RC2.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Jones
Sent: Thursday, November 20, 2008 4:33 AM
To: users@lists.ironpython.com
Subject: [IronPython]
If you're getting crazy and are willing to experiment you could also look at IL
rewriting compiled modules so they target Silverlight. In theory it's just
updating what assembly name we're targeting.
Maybe I've just not been following the Silverlight threads close enough but
what do you mean
with the item-like access to COM objects in IP 2.0?
Whether it will return to []-like access (as in RC 1) or it will
remain .Item(...)?
IMHO RC 1 way is more preferred.
Best regards,
Zaur
2008/10/27 Dino Viehland [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]:
Oh, and I'm not sure if this is by design
Does it also repro under a debugger? Given it's a full 5 seconds could you
pause the app when this is happening to see what the actual stacks are?
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Glenn Jones [EMAIL
PROTECTED]
Sent: Tuesday, November 25,
Thanks for opening this - I'm going to look at this and the other subclassing
issues and see how scary the fix(es) are.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Eloff
Sent: Monday, December 01, 2008 11:15 AM
To: Discussion of IronPython
Thanks for reporting opening the bug. The fix for this is likely fairly easy
but I don't think we'd spin a new 2.0 build for just this issue because it
isn't really blocking anything as you have a work around.
That being said it would certainly be something we'd fix for 2.0.1 and we don't
Ok, I think the problem here is two-fold. First there's no public default
constructor - only a private one. So you need to pick between the Stream
overload or the StreamResourceInfo, Uri overload. You're apparently trying to
choose the Stream overload.
Which brings me to the 2nd problem.
of base class constructor?
- blocker
On Mon, Dec 1, 2008 at 2:43 PM, Dino Viehland [EMAIL PROTECTED] wrote:
Ok, I think the problem here is two-fold. First there's no public default
constructor - only a private one. So you need to pick between the Stream
overload or the StreamResourceInfo
We don't always remember what we've wired up though. If you give us a delegate
which matches the type exactly we'll just go ahead and hook it up (to avoid
adding an extra level of indirection). Only if you give us some random
callable object will we remember it. It'd be easy enough for us to
The closest we have to this currently is what the console does w/ live objects.
I think you could also find some examples of this in IronPython Studio
(http://www.codeplex.com/IronPythonStudio) but there's nothing that's too
sophisticated right now.
From: [EMAIL PROTECTED] [mailto:[EMAIL
This is bug #20021 -
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=20021
You should be able to declare the ctor public. It shouldn't be an error to do
that but you'll get an FxCop warning if you run FxCop.
I checked a fix for this in today into the Main branch (which is
AddNumbers
class. I don't want the script writers to be able to save this class
instance, and it would be 'ugly' if they had to call .GetReturn() to
get the return value of the command.
And I don't want the call to Do to be explicit.
I sound really picky...
Dino Viehland wrote:
Do you mean you'd
to an instance of an object.
print mytestRun.Field.Item['RN_USER_01']
None
I couldn't decipher the error so I couldn't figure out what I'm doing
wrong.
I suspect the folks on this list can. =)
Dino Viehland wrote:
Does:
mytestRun.Field.Item['RN_USER_01'] = 'abc'
work?
-Original Message
)
at
Microsoft.Scripting.Runtime.OptimizedScriptCode.InvokeTarget(LambdaExpression
code, Scope scope)
at Microsoft.Scripting.ScriptCode.Run(Scope scope)
at
IronPython.Hosting.PythonCommandLine.c__DisplayClass1.RunOneInteractionb__0()
SystemError: Object reference not set to an instance of an object.
Dino Viehland wrote:
What's the stack trace
The immediate question would be does fixing this unblock all other Django
issues? If there's going to be a long tail of other bugs then it'd be better
to just fix them all for 2.0.1.
If you want to try this out the fix is easy, in PythonDictionary.cs replace the
line:
801 - 900 of 1614 matches
Mail list logo
