Can you confirm that following two warnings are likely to be a Mono
compiler bug?
/home/tinuviel/svn/ironpython/Src/Microsoft.Scripting.Core/Actions/GetMemberAction.cs(44,43):
warning CS3006: Overloaded method
`Microsoft.Scripting.Actions.GetMemberAction.Bind(params
Microsoft.Scripting.Actions.Met
Perfect. Well done!
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Wednesday, October 08, 2008 6:45 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Questions and Best Practices forScript
Runtimeand Script Engine
Absolutely - you can create a ScriptRuntimeSetup and pass that to the
ScriptRuntime constructor. That's basically:
ScriptRuntimeSetup setup = new ScriptRuntimeSetup();
Setup.LanguageSetups.Add(new LanguageSetup(assembly_qualified_name,
displayName, languageNames, fileExtensions);
If you want a
Thanks, this is very helpful and close to what I expected. We use
scripting as an event-based customization mechanism, so the scripts
typically need to be in the same app-domain so they can get their grubby
little hands all over the objects being manipulated.
Is there any code based mechanisms
We expect RC1 in about 1-2 weeks and the final release by the end of
November. Exact dates are -- as always -- subject to change.
On Wed, Oct 8, 2008 at 3:55 PM, Marty Nelson <[EMAIL PROTECTED]> wrote:
> Ok. What's the latest thinking on the schedule at this point? Will we
> at least be to RC
And yes support is great. Although, perhaps more importantly, for how
we use it, it just seems to "work", so there isn't much support we have
needed :-)
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Curt
Hagenlocher
Sent: Wednesday, October 08
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
Ok. What's the latest thinking on the schedule at this point? Will we
at least be to RC?
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Curt
Hagenlocher
Sent: Wednesday, October 08, 2008 3:21 PM
To: Discussion of IronPython
Subject: Re: [Iron
Given the open source nature of the project, you can go live with whatever
you want! The flip side of that is that support is pretty much limited to
what you get on this list. Though we'd like to think that the free support
you get from us is at least as good as what you pay for from PSS. :)
On W
We have a release scheduled for mid-December. If IP 2.0 is not
officially released, can we go live with an RC?
Thanks,
Marty Nelson
Symyx Technologies, Inc.
===
Notice: This e-mail message, together with any attachments, contains
information of Symyx Technologies, Inc. or any of i
I definitely think we can add a nice public interface in the near future -
probably even in 2.0.1. I just don't want to rush it in for 2.0 final and
especially before you have a chance to give it a shot :)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
I have a ScriptingService static class that reuses the same
ScriptRuntime instance. Is there any reason not to do this? What would
be the boundary conditions at which I would want to use a different
ScriptRuntime?
Does the call to scriptRuntime.GetEngine("py") always return the same
engine i
#1 - Great, I can manage that.
#2 - This is promising. Because I want this to work in silverlight as
well, I'll have to patch IronPython to give a public interface, but
that looks remarkably simple from what you've told me. That's fine for
enabling me to continue forward, but not for sharing my wo
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
Pytho
I'm looking at the ast stuff in IronPython.Compiler.Ast and seeing how
difficult it would be to write a python 2.5 _ast (and 2.6 ast) wrapper
over it.
Jython actually supports this now, and I don't wish to see IronPython
left behind in this area.
It looks like I should be able to handle a read-on
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 i
I would suggest not using inheritance if you can. You can just hold onto the
serializable object and delegate any work you need to be done to it. You'll be
able to pickle the object graph that contains the Python object holding onto
the non-inherited serializable object.
From: [EMAIL PROTECTE
Fair enough, thanks.
Any suggestions on how to work around this in the meantime?
On 10/8/08, Dino Viehland <[EMAIL PROTECTED]> wrote:
>
> Ok, upon looking into this some more, I'm sad to say it looks like this
> won't work right now L. We need to figure out a way to run the
> serialization for ju
Same code on IP 1.1.2 outputs:699
696
Cheers,
Davy
On Wed, Oct 8, 2008 at 7:34 AM, Davy Mitchell <[EMAIL PROTECTED]> wrote:
> Hi All,
> Basic Repro is...
>
> -form.py---
> import clr
> clr.AddReference('System.Windows.Forms')
> from System.Windows.Forms import *
> print len(dir(Form)
19 matches
Mail list logo
