date:20080331

[IronPython] FW: IronPython Studio 1.0 for Isolated and Integrated VS Shell

2008-03-31 Thread Harry Pierson

Ken Levy from the Visual Studio extensibility team just blogged about the 1.0 
new release of IronPython Studio (http://codeplex.com/IronPythonStudio). As is 
pointed out below, this new version supports the integrated VS08 Shell, which 
means that if you already have VS08 installed, IPy Studio will just snap right 
into it. If you don't have VS08, you can download the VS08 shell for free 
(directions on the site)

Harry Pierson
PM, IronPython
[EMAIL PROTECTED]
http://devhawk.net




http://blogs.msdn.com/vsxteam/archive/2008/03/31/ironpython-studio-1-0-for-isolated-and-integrated-vs-shell.aspx

IronPython is now available in for both integrated and isolated VS Shell, see 
blog post for details.

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Mixing Languages with the DLR

2008-03-31 Thread Jimmy Schementi

I totally agree =) Unfortuantely, IronRuby on Rails is the high priority task 
for John Lam and his merry men for the next month or two, but language interop 
hopefully won't be too long after.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:users-
> [EMAIL PROTECTED] On Behalf Of Michael Foord
> Sent: Monday, March 31, 2008 2:22 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Mixing Languages with the DLR
>
> Jimmy Schementi wrote:
> > I know this works between Jscript and Python. Ruby doesn't yet play
> by
> > the rules for method lookup. Fire up dlrconsole and see for yourself:
>
> Ok - something for us to watch. Allowing users to script Resolver One
> spreadsheets with Ruby could be fun.
>
> Michael
> http://www.ironpythoninaction.com
>
> >
> > http://dynamicsilverlight.net/see/dlrconsole
> >
> > js> function foo() {
> > js| return 42
> > js| }
> > py> a = foo()
> > py> a
> > 42.0
> > js> a
> > 42.0
> >
> > How it works? I believe it's something to do with sharing scopes, but
> > you can take a look @
> > http://dynamicsilverlight.net/see/dlrconsole.zip. Everything is in
> > /app/app.py
> >
> > John, any idea when Ruby will play nicely with other languages?
> >
> > ~Jimmy
> >
> > On 3/30/08 8:25 AM, "Michael Foord" <[EMAIL PROTECTED]>
> wrote:
> >
> > Hello all,
> >
> > A quick question on mixing languages with the DLR. If we have an
> > execution scope that we have executed code in - can we execute
> > code from
> > another language in the same scope?
> >
> > If this is trivially easy (just use a different engine to execute
> the
> > code in the same scope) then we could make Resolver One
> scriptable in
> > the DLR language of your choosing... (Why anyone would want to
> use
> > anything other than Python I don't know).
> >
> > Michael
> > http://www.ironpythoninaction.com
> > ___
> > Users mailing list
> > Users@lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> > -
> ---
> >
> > ___
> > Users mailing list
> > Users@lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
>
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Mixing Languages with the DLR

2008-03-31 Thread Michael Foord

Jimmy Schementi wrote:
> I know this works between Jscript and Python. Ruby doesn’t yet play by 
> the rules for method lookup. Fire up dlrconsole and see for yourself:

Ok - something for us to watch. Allowing users to script Resolver One 
spreadsheets with Ruby could be fun.

Michael
http://www.ironpythoninaction.com

>
> http://dynamicsilverlight.net/see/dlrconsole
>
> js> function foo() {
> js| return 42
> js| }
> py> a = foo()
> py> a
> 42.0
> js> a
> 42.0
>
> How it works? I believe it’s something to do with sharing scopes, but 
> you can take a look @ 
> http://dynamicsilverlight.net/see/dlrconsole.zip. Everything is in 
> /app/app.py
>
> John, any idea when Ruby will play nicely with other languages?
>
> ~Jimmy
>
> On 3/30/08 8:25 AM, "Michael Foord" <[EMAIL PROTECTED]> wrote:
>
> Hello all,
>
> A quick question on mixing languages with the DLR. If we have an
> execution scope that we have executed code in - can we execute
> code from
> another language in the same scope?
>
> If this is trivially easy (just use a different engine to execute the
> code in the same scope) then we could make Resolver One scriptable in
> the DLR language of your choosing... (Why anyone would want to use
> anything other than Python I don't know).
>
> Michael
> http://www.ironpythoninaction.com
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
> 
>
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Semi-blocking bug in IP 2B1

2008-03-31 Thread Dino Viehland

There's actually a bunch of issues tangled together here but you're right, 
changing that statement would make the frames more usable...  There's actually 
some thoughts that our dynamic stack trace support should be pulled up entirely 
into IronPython and that might just happen.

The other issues are just related to how we generally produce frames.  For 
example if you do:

try:
raise ZeroDivisionError
except:
# start extracting frames from sys.exc_info()

In CPython you get a bunch of frames from above the except block and in 
IronPython you get no frames.  Turns out the inspect module does this and the 
latest Django in source control relies on that working :).

So to fix that bug requires that we always take a full stack trace when we get 
the frames.  And that of course kills exception handling perf in a quite 
significant way (it gets 3x more expensive to throw an exception, and it's 
already really expensive).   So we should bring this back w/o having the -D 
flag enabled, and we might also want to change how we track frames in general 
to do something better and more consistent w/ CPython.  But we can't push that 
down into the DLR so there's a non-trivial amount of work here.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher
Sent: Monday, March 31, 2008 9:20 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Semi-blocking bug in IP 2B1

LambdaCompiler.Statements.cs basically says "if (Options.DebugMode && 
Options.DynamicStackTraceSupport) EmitGetCurrentLine()".  Maybe this should be 
"or" instead of "and"?
On Mon, Mar 31, 2008 at 9:13 AM, Dino Viehland <[EMAIL PROTECTED]> wrote:
It's actually something that's on our radar - it feels worse to me too.  It's 
something I plan on taking a look at before 2.0 final ships.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL 
PROTECTED]] On Behalf Of Michael Foord
Sent: Monday, March 31, 2008 9:04 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Semi-blocking bug in IP 2B1

Curt Hagenlocher wrote:
> On Mon, Mar 31, 2008 at 8:10 AM, Michael Foord
> <[EMAIL PROTECTED]> wrote:
>
>> In general, error reporting/tracebacks seem to be much worse in
>> IronPython 2. If I have time I will try and produce a repro...
>>
>
> If you run with a -D flag, you get much better error reporting.  This
> is equivalent to setting (ScriptRuntime).GlobalOptions.DebugMode =
> true in a hosting scenario.
>
> (Thanks to Jimmy Schementi's post on the IronRuby list for pointing me at 
> this.)
>

Ok - and thanks. But we generate and execute code at runtime and need
good error reporting for our users. If there is a performance
implication we wouldn't want to have to set this flag just to be able to
give our users useful tracebacks! The IP traceback handling is generally
fine for us - but I haven't *confirmed* that IP 2 is worse - it just
feels worse...

We have bigger problems anyway. Now I have ironed out the obvious
problems, Resolver One runs on IP 2 but the user interface is completely
broken. That is all pure-Python code so I have some digging to do... :-)

Michael

> --
> Curt Hagenlocher
> [EMAIL PROTECTED]
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Semi-blocking bug in IP 2B1

2008-03-31 Thread Curt Hagenlocher

LambdaCompiler.Statements.cs basically says "if (Options.DebugMode &&
Options.DynamicStackTraceSupport) EmitGetCurrentLine()".  Maybe this should
be "or" instead of "and"?
On Mon, Mar 31, 2008 at 9:13 AM, Dino Viehland <[EMAIL PROTECTED]>
wrote:

> It's actually something that's on our radar - it feels worse to me too.
>  It's something I plan on taking a look at before 2.0 final ships.
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] On Behalf Of Michael Foord
> Sent: Monday, March 31, 2008 9:04 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Semi-blocking bug in IP 2B1
>
> Curt Hagenlocher wrote:
> > On Mon, Mar 31, 2008 at 8:10 AM, Michael Foord
> > <[EMAIL PROTECTED]> wrote:
> >
> >> In general, error reporting/tracebacks seem to be much worse in
> >> IronPython 2. If I have time I will try and produce a repro...
> >>
> >
> > If you run with a -D flag, you get much better error reporting.  This
> > is equivalent to setting (ScriptRuntime).GlobalOptions.DebugMode =
> > true in a hosting scenario.
> >
> > (Thanks to Jimmy Schementi's post on the IronRuby list for pointing me
> at this.)
> >
>
> Ok - and thanks. But we generate and execute code at runtime and need
> good error reporting for our users. If there is a performance
> implication we wouldn't want to have to set this flag just to be able to
> give our users useful tracebacks! The IP traceback handling is generally
> fine for us - but I haven't *confirmed* that IP 2 is worse - it just
> feels worse...
>
> We have bigger problems anyway. Now I have ironed out the obvious
> problems, Resolver One runs on IP 2 but the user interface is completely
> broken. That is all pure-Python code so I have some digging to do... :-)
>
> Michael
>
>
>
> > --
> > Curt Hagenlocher
> > [EMAIL PROTECTED]
> > ___
> > Users mailing list
> > Users@lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
>
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Semi-blocking bug in IP 2B1

2008-03-31 Thread Dino Viehland

I've created a bug for this - 
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=15882

Given that it's a pretty bad regression I'll take a look at it after I finish 
up the work I'm doing on startup perf right now.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Monday, March 31, 2008 8:10 AM
To: Resolver Developers; Discussion of IronPython
Subject: [IronPython] Semi-blocking bug in IP 2B1

Hello all,

There is a bug in dictionaries in IronPython 2 beta 1. I found this
trying to port Resolver One to IP 2. Whilst I can work round it in this
case I wonder how many times this bug will bite us in our code base:

 >>> d = dict()
 >>> d[0, 0] = 3
 >>> del d[0, 0]
Traceback (most recent call last):
  File , line unknown, in Initialize##345
TypeError: __delitem__() takes exactly 1 argument (2 given)

In general, error reporting/tracebacks seem to be much worse in
IronPython 2. If I have time I will try and produce a repro...

Michael

--
Michael Foord
Senior Software Engineer, Resolver Systems Ltd.
[EMAIL PROTECTED]
+44 (0) 20 7253 6372

We're hiring! http://www.resolversystems.com/jobs/
17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79 Registered in England and Wales as company number 
5467329.
Registered address: 843 Finchley Road, London NW11 8NA, UK

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] IP 2 Hosting

2008-03-31 Thread Michael Foord

Dino Viehland wrote:
> Exactly, it's beta 1 - therefore the idea is that the API is basically fixed 
> and we should see mostly bug fixes and tuning from here on out.
>
> It's not beta 2 yet! :)
>
> I think TrueDivision is another reason for us to expose a Python specific 
> hosting API (yeah, I realize that conflicts with what I just said 
> somewhat...).
>   

The more general DLR hosting API is much less suitable for Resolver One 
of course and a Python specific API would be very nice. If I get far 
enough I will try and post a bunch of questions about what is the *best* 
way of doing various things that we do with engines/scopes (beyond the 
questions I have already sent...). :-)

Thanks

Michael

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
> Sent: Saturday, March 29, 2008 10:51 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] IP 2 Hosting
>
> Curt Hagenlocher wrote:
>   
>> On Sat, Mar 29, 2008 at 10:32 AM, Michael Foord
>> <[EMAIL PROTECTED]> wrote:
>>
>> 
>>> In the old days a beta used to mean the API was fixed and it was only
>>> bugfixes that would go in... <0.5 wink>
>>>
>>>   
>> heh
>>
>> It seems to me that B1 is more consistent with the various published
>> DLR hosting specs than A9 was -- which suggests that the API churn for
>> the Microsoft.Scripting namespace is dying down.
>>
>> 
>
> Cool - I was just being rude.
>
> Any ideas on switching on TrueDivision for the scope?
>
> Michael
>
>
>
>   
>> --
>> Curt Hagenlocher
>> [EMAIL PROTECTED]
>> ___
>> Users mailing list
>> Users@lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>> 
>
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Semi-blocking bug in IP 2B1

2008-03-31 Thread Dino Viehland

It's actually something that's on our radar - it feels worse to me too.  It's 
something I plan on taking a look at before 2.0 final ships.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Monday, March 31, 2008 9:04 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Semi-blocking bug in IP 2B1

Curt Hagenlocher wrote:
> On Mon, Mar 31, 2008 at 8:10 AM, Michael Foord
> <[EMAIL PROTECTED]> wrote:
>
>> In general, error reporting/tracebacks seem to be much worse in
>> IronPython 2. If I have time I will try and produce a repro...
>>
>
> If you run with a -D flag, you get much better error reporting.  This
> is equivalent to setting (ScriptRuntime).GlobalOptions.DebugMode =
> true in a hosting scenario.
>
> (Thanks to Jimmy Schementi's post on the IronRuby list for pointing me at 
> this.)
>

Ok - and thanks. But we generate and execute code at runtime and need
good error reporting for our users. If there is a performance
implication we wouldn't want to have to set this flag just to be able to
give our users useful tracebacks! The IP traceback handling is generally
fine for us - but I haven't *confirmed* that IP 2 is worse - it just
feels worse...

We have bigger problems anyway. Now I have ironed out the obvious
problems, Resolver One runs on IP 2 but the user interface is completely
broken. That is all pure-Python code so I have some digging to do... :-)

Michael

> --
> Curt Hagenlocher
> [EMAIL PROTECTED]
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Creating Python classes in IP2

2008-03-31 Thread Curt Hagenlocher

On Mon, Mar 31, 2008 at 8:54 AM, Slide <[EMAIL PROTECTED]> wrote:
> I use the following for finding a class that implements a certain interface.
>
> [...]
>
> Is there a way that is more portable between the different languages?

It looks like the DLR doesn't try to abstract "classness".  And given
that the semantics of a "class" vary so much between Python, Ruby and
Javascript, this isn't really a surprise.

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Semi-blocking bug in IP 2B1

2008-03-31 Thread Michael Foord

Curt Hagenlocher wrote:
> On Mon, Mar 31, 2008 at 8:10 AM, Michael Foord
> <[EMAIL PROTECTED]> wrote:
>   
>> In general, error reporting/tracebacks seem to be much worse in
>> IronPython 2. If I have time I will try and produce a repro...
>> 
>
> If you run with a -D flag, you get much better error reporting.  This
> is equivalent to setting (ScriptRuntime).GlobalOptions.DebugMode =
> true in a hosting scenario.
>
> (Thanks to Jimmy Schementi's post on the IronRuby list for pointing me at 
> this.)
>   

Ok - and thanks. But we generate and execute code at runtime and need 
good error reporting for our users. If there is a performance 
implication we wouldn't want to have to set this flag just to be able to 
give our users useful tracebacks! The IP traceback handling is generally 
fine for us - but I haven't *confirmed* that IP 2 is worse - it just 
feels worse...

We have bigger problems anyway. Now I have ironed out the obvious 
problems, Resolver One runs on IP 2 but the user interface is completely 
broken. That is all pure-Python code so I have some digging to do... :-)

Michael

> --
> Curt Hagenlocher
> [EMAIL PROTECTED]
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] IP 2 Hosting

2008-03-31 Thread Dino Viehland

Exactly, it's beta 1 - therefore the idea is that the API is basically fixed 
and we should see mostly bug fixes and tuning from here on out.

It's not beta 2 yet! :)

I think TrueDivision is another reason for us to expose a Python specific 
hosting API (yeah, I realize that conflicts with what I just said somewhat...).

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Saturday, March 29, 2008 10:51 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IP 2 Hosting

Curt Hagenlocher wrote:
> On Sat, Mar 29, 2008 at 10:32 AM, Michael Foord
> <[EMAIL PROTECTED]> wrote:
>
>> In the old days a beta used to mean the API was fixed and it was only
>> bugfixes that would go in... <0.5 wink>
>>
>
> heh
>
> It seems to me that B1 is more consistent with the various published
> DLR hosting specs than A9 was -- which suggests that the API churn for
> the Microsoft.Scripting namespace is dying down.
>

Cool - I was just being rude.

Any ideas on switching on TrueDivision for the scope?

Michael



> --
> Curt Hagenlocher
> [EMAIL PROTECTED]
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Creating Python classes in IP2

2008-03-31 Thread Slide

I use the following for finding a class that implements a certain interface.

IAttributesCollection attrs =
IronPython.Runtime.Types.PythonModuleOps.Get__dict__(__main__);
foreach (KeyValuePair attr in attrs)
{
IronPython.Runtime.Types.PythonType attr_type =
attr.Value as IronPython.Runtime.Types.PythonType;
if (attr_type != null)
{
foreach (IronPython.Runtime.Types.PythonType
dt in attr_type.BaseTypes)
{
if (dt.UnderlyingSystemType != null &&
dt.UnderlyingSystemType == typeof(T))
{
CodeContext context = new
CodeContext(__main__.Scope, _context, new ModuleContext(__main__));
inst = (T)attr_type.CreateInstance(context);
break;
}
}
}
}


Is there a way that is more portable between the different languages?

On Sun, Mar 30, 2008 at 4:53 AM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 30, 2008 at 2:59 AM, Paul Turbett <[EMAIL PROTECTED]> wrote:
>  >
>  > I've looked through the DLR hosting spec, and experimented a bit, but I
>  > can't see how to get the same thing working with DLR hosting. So, how do
>  > I create instances of python classes from C#?
>
>  This is what works for me:
>
> ScriptRuntime runtime = ScriptRuntime.Create();
> ScriptEngine engine = runtime.GetEngine("py");
>
> // These next two lines are needed if you expect to be able to import 
> System
> // without manually loading the assembly through Python
> // runtime.LoadAssembly(typeof(string).Assembly);
> // runtime.LoadAssembly(typeof(System.Diagnostics.Debug).Assembly);
>
> // File foo.py contains class Foo
> ScriptScope scope = runtime.ExecuteFile("foo.py");
> object theClass;
> scope.TryGetVariable("Foo", out theClass);
> object theValue = PythonCalls.Call(theClass);
>
>  --
>  Curt Hagenlocher
>  [EMAIL PROTECTED]
>
>
> ___
>  Users mailing list
>  Users@lists.ironpython.com
>  http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>



-- 
slide-o-blog
http://slide-o-blog.blogspot.com/
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Semi-blocking bug in IP 2B1

2008-03-31 Thread Curt Hagenlocher

On Mon, Mar 31, 2008 at 8:10 AM, Michael Foord
<[EMAIL PROTECTED]> wrote:
>
> In general, error reporting/tracebacks seem to be much worse in
> IronPython 2. If I have time I will try and produce a repro...

If you run with a -D flag, you get much better error reporting.  This
is equivalent to setting (ScriptRuntime).GlobalOptions.DebugMode =
true in a hosting scenario.

(Thanks to Jimmy Schementi's post on the IronRuby list for pointing me at this.)

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] Semi-blocking bug in IP 2B1

2008-03-31 Thread Michael Foord

Hello all,

There is a bug in dictionaries in IronPython 2 beta 1. I found this 
trying to port Resolver One to IP 2. Whilst I can work round it in this 
case I wonder how many times this bug will bite us in our code base:

 >>> d = dict()
 >>> d[0, 0] = 3
 >>> del d[0, 0]
Traceback (most recent call last):
  File , line unknown, in Initialize##345
TypeError: __delitem__() takes exactly 1 argument (2 given)

In general, error reporting/tracebacks seem to be much worse in 
IronPython 2. If I have time I will try and produce a repro...

Michael

-- 
Michael Foord
Senior Software Engineer, Resolver Systems Ltd.
[EMAIL PROTECTED]
+44 (0) 20 7253 6372

We're hiring! http://www.resolversystems.com/jobs/
17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79 Registered in England and Wales as company number 
5467329.
Registered address: 843 Finchley Road, London NW11 8NA, UK

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] More IP2 Equivalents - setting argv and search path

2008-03-31 Thread Michael Foord

Curt Hagenlocher wrote:
> On Mon, Mar 31, 2008 at 4:51 AM, Michael Foord
> <[EMAIL PROTECTED]> wrote:
>   
>> I saw a post on the list recently about
>> "ScriptEngine.SetScriptSourceSearchPaths", but this doesn't seem to
>> exist in 2b1.
>> 
>
> I'm looking at it in 2b1 right now...
>   
Yeah - oops. Takes an array of strings. :-)

Michael

> --
> Curt Hagenlocher
> [EMAIL PROTECTED]
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] More IP2 Equivalents - setting argv and search path

2008-03-31 Thread Curt Hagenlocher

On Mon, Mar 31, 2008 at 4:51 AM, Michael Foord
<[EMAIL PROTECTED]> wrote:
>
> I saw a post on the list recently about
> "ScriptEngine.SetScriptSourceSearchPaths", but this doesn't seem to
> exist in 2b1.

I'm looking at it in 2b1 right now...

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] More IP2 Equivalents - setting argv and search path

2008-03-31 Thread Michael Foord

Hello all,

I'm searching for more IronPython 2 equivalents and wondering if anyone 
on list knows. :-)

With IronPython 1 we would set 'sys.argv' with:

engine.Sys.argv = List.Make(args);

(I think List here is the PythonList.)

We would also add paths to sys.path for an engine with:

engine.AddToPath(path);

I'm currently doing this by generating strings of 'sys.path.append(...)' 
and executing the code which is a bit clumsy. :-)

I saw a post on the list recently about 
"ScriptEngine.SetScriptSourceSearchPaths", but this doesn't seem to 
exist in 2b1.

Thanks

Michael
   

-- 
Michael Foord
Senior Software Engineer, Resolver Systems Ltd.
[EMAIL PROTECTED]
+44 (0) 20 7253 6372

We're hiring! http://www.resolversystems.com/jobs/
17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79 Registered in England and Wales as company number 
5467329.
Registered address: 843 Finchley Road, London NW11 8NA, UK

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] IronPython 2 Exception Handling from C#

2008-03-31 Thread Michael Foord

Hello guys,

I'm being lazy. Can anyone help translate the following IronPython 1 
hosting code to the IP 2b1 API nearest equivalent. (I have already 
translated the code to execute the file - it is the exception handling 
code I need help with):

try
{
engine.Sys.argv = List.Make(args);
ScriptSource source = 
engine.CreateScriptSourceFromFile(Path.Combine(rootDir, (string)args[0]);
source.Execute();
}
catch (PythonSystemExitException e)
{
object o;
return e.GetExitCode(out o);
}
catch (Exception e)
{
Console.Write(engine.FormatException(e));
return 1;
}
finally
{
PythonEngine.DumpDebugInfo();
}
return 0;

Thanks (in advance...)

Michael

-- 
Michael Foord
Senior Software Engineer, Resolver Systems Ltd.
[EMAIL PROTECTED]
+44 (0) 20 7253 6372

We're hiring! http://www.resolversystems.com/jobs/
17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79 Registered in England and Wales as company number 
5467329.
Registered address: 843 Finchley Road, London NW11 8NA, UK

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] FW: IronPython Studio 1.0 for Isolated and Integrated VS Shell

Re: [IronPython] Mixing Languages with the DLR

Re: [IronPython] Mixing Languages with the DLR

Re: [IronPython] Semi-blocking bug in IP 2B1

Re: [IronPython] Semi-blocking bug in IP 2B1

Re: [IronPython] Semi-blocking bug in IP 2B1

Re: [IronPython] IP 2 Hosting

Re: [IronPython] Semi-blocking bug in IP 2B1

Re: [IronPython] Creating Python classes in IP2

Re: [IronPython] Semi-blocking bug in IP 2B1

Re: [IronPython] IP 2 Hosting

Re: [IronPython] Creating Python classes in IP2

Re: [IronPython] Semi-blocking bug in IP 2B1

[IronPython] Semi-blocking bug in IP 2B1

Re: [IronPython] More IP2 Equivalents - setting argv and search path

Re: [IronPython] More IP2 Equivalents - setting argv and search path

[IronPython] More IP2 Equivalents - setting argv and search path

[IronPython] IronPython 2 Exception Handling from C#

18 matches

Site Navigation

Mail list logo

Footer information