[IronPython] SystemExitException ?

2008-11-21 Thread Orestis Markou 

Hello,

In Resolver, we have our own RSIronPython.exe that sets up the 
environment (PATH and other things) and executes a program. It's not 
interactive - just a wrapper aroung ExecuteProgram, really.


We used to do this:

try
{
ScriptSource source = 
engine.CreateScriptSourceFromFile(Path.Combine(currentDir, 
(string)args[0]));

source.ExecuteProgram();
}
catch (SystemExitException e)
{
object o;
return e.GetExitCode(out o);
}
catch (Exception e)
{
ExceptionOperations eo = engine.GetServiceExceptionOperations();
Console.Write(eo.FormatException(e));
return 1;
}
return 0;

But then we realised that we always returned 0, because 
SystemExitException was never raised, even if a PythonScript did an 
exlicit sys.exit or raised SystemExit. So we now return the result of 
source.ExecuteProgram().


I'm just wondering if we should care about SystemExitException (a quick 
grep of the source is indicating that it's only used in 
PythonCommandLine), or if it's handled for us at a lower level.


Thanks,
Orestis
--
Orestis Markou
Software Engineer,
Resolver Systems Ltd.
[EMAIL PROTECTED]
+44 (0) 20 7253 6372

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

Re: [IronPython] SystemExitException ?

2008-11-21 Thread Tomas Matousek 
It's handled for you in ExecuteProgram and the exit code is returned. It's this 
handling that makes the difference between Execute and ExecuteProgram. 
ExecuteProgram is designed to process any program exit mechanism that the 
language has so that the host doesn't need to care and could be language 
independent.

Tomas

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Orestis Markou
Sent: Friday, November 21, 2008 5:24 AM
To: Discussion of IronPython
Subject: [IronPython] SystemExitException ?

Hello,

In Resolver, we have our own RSIronPython.exe that sets up the
environment (PATH and other things) and executes a program. It's not
interactive - just a wrapper aroung ExecuteProgram, really.

We used to do this:

try
{
 ScriptSource source =
engine.CreateScriptSourceFromFile(Path.Combine(currentDir,
(string)args[0]));
 source.ExecuteProgram();
}
catch (SystemExitException e)
{
 object o;
 return e.GetExitCode(out o);
}
catch (Exception e)
{
 ExceptionOperations eo = engine.GetServiceExceptionOperations();
 Console.Write(eo.FormatException(e));
 return 1;
}
return 0;

But then we realised that we always returned 0, because
SystemExitException was never raised, even if a PythonScript did an
exlicit sys.exit or raised SystemExit. So we now return the result of
source.ExecuteProgram().

I'm just wondering if we should care about SystemExitException (a quick
grep of the source is indicating that it's only used in
PythonCommandLine), or if it's handled for us at a lower level.

Thanks,
Orestis
--
Orestis Markou
Software Engineer,
Resolver Systems Ltd.
[EMAIL PROTECTED]
+44 (0) 20 7253 6372

___
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] (ironclad) is it possible to get the current ScriptEngine?

2008-11-21 Thread William Reade 
Thanks again Dino: it's all working and checked in, and it was all much 
easier than I expected. No problems with SourceUnits, but I don't try to 
do anything remotely complex with them, so others' mileage may vary.


Dino Viehland wrote:

Oh, and instead of ScriptSource you can use SourceUnit.  You might find there's 
too much stuff marked internal w/ SourceUnit so any issues you run into here 
would be interesting to hear.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William Reade
Sent: Thursday, November 20, 2008 9:50 AM
To: Discussion of IronPython
Subject: Re: [IronPython] (ironclad) is it possible to get the current 
ScriptEngine?

It seems I don't actually use the engine for very much, so this sounds
pretty plausible -- context.SystemState can replace Python.GetSysModule,
and HostingHelpers.GetLanguageContext goes away entirely :).

However, I can't see any obvious way to create a ScriptScope
(engine.CreateScope) or a ScriptSource
(engine.CreateScriptSourceFromString) -- even if I just dupe IronPython
code, it seems I'll still need an actual PythonEngine to construct 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)/ScriptDomainManager and work with
those directly.  ScriptEngine/ScriptRuntime are wrappers around those
which expose the friendly API and provide the easy remoting features.

You can get to the LanguageContext via a CodeContext.  You can get a
CodeContext by just defining it as the 1st parameter on a .NET method
which we'll be calling at some point.

For example our ModuleLoader class for pre-compiled code has a
load_module method which receives a CodeContext.  It then uses it to
call back into the current PythonContext and create a new module.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of William Reade
Sent: Thursday, November 20, 2008 5:36 AM
To: Discussion of IronPython
Subject: [IronPython] (ironclad) is it possible to get the current
ScriptEngine?

Hi all

At the moment, when a user types 'import ironclad', I create a new
ScriptEngine and set that up to allow .pyd imports; I then abuse
path_hooks to use the new engine to do the imports, and copy them into
the original engine's sys.modules. Clearly, this is evil and wrong on
any number of levels, but so far it's been (just barely) good enough.

However, if I can find out which ScriptEngine is executing the code (so
I can pass that into the Python25Mapper), I can greatly simplify
ironclad.py and, hopefully, solve another user's problem (which, I
believe, is related to sys.path not being shared between the two engines
(quite rightly so, ofc ;))).

So: is there any way I can get a reference to the executing engine from
within IronPython code? It feels as if it should be possible, but
whenever I look into it I end up chasing my tail...

William
___
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
___
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] SystemExitException ?

2008-11-21 Thread Orestis Markou 

Thanks! So we'll remove SystemExitException handling.

Tomas Matousek wrote:

It's handled for you in ExecuteProgram and the exit code is returned. It's this 
handling that makes the difference between Execute and ExecuteProgram. 
ExecuteProgram is designed to process any program exit mechanism that the 
language has so that the host doesn't need to care and could be language 
independent.

Tomas

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Orestis Markou
Sent: Friday, November 21, 2008 5:24 AM
To: Discussion of IronPython
Subject: [IronPython] SystemExitException ?

Hello,

In Resolver, we have our own RSIronPython.exe that sets up the
environment (PATH and other things) and executes a program. It's not
interactive - just a wrapper aroung ExecuteProgram, really.

We used to do this:

try
{
 ScriptSource source =
engine.CreateScriptSourceFromFile(Path.Combine(currentDir,
(string)args[0]));
 source.ExecuteProgram();
}
catch (SystemExitException e)
{
 object o;
 return e.GetExitCode(out o);
}
catch (Exception e)
{
 ExceptionOperations eo = engine.GetServiceExceptionOperations();
 Console.Write(eo.FormatException(e));
 return 1;
}
return 0;

But then we realised that we always returned 0, because
SystemExitException was never raised, even if a PythonScript did an
exlicit sys.exit or raised SystemExit. So we now return the result of
source.ExecuteProgram().

I'm just wondering if we should care about SystemExitException (a quick
grep of the source is indicating that it's only used in
PythonCommandLine), or if it's handled for us at a lower level.

Thanks,
Orestis
--
Orestis Markou
Software Engineer,
Resolver Systems Ltd.
[EMAIL PROTECTED]
+44 (0) 20 7253 6372

___
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


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

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

Re: [IronPython] Blocker: subclasses of float have trouble with __int__ and __str__

2008-11-21 Thread Dino Viehland 
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] Blocker: subclasses of float have trouble with __int__ 
and __str__

Hello guys,

On the latest code drop (43741) it seems that something is broken in subclasses 
of floats.

class MyFloatType(float):
  def __new__(cls):
return float.__new__(cls, 0.0)

  def __repr__(self):
return MyFloat

  __str__ = __repr__

MyFloat = MyFloatType()
int(MyFloat)
TypeError: expected int, got p

This is one can be worked around by having an __int__ defined. However,

str(MyFloat)
'0.0'
repr(MyFloat)
'MyFloat'


Subclassing longs and ints in a similar way has the correct behaviour.

This is nasty and a blocker for us.

We've raised this as Issue 19675



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

[IronPython] Importing in a background thread

2008-11-21 Thread Dan Eloff 
I'm curious why importing in a background thread fails completely in
Silverlight (well anything builtin and anything already loaded works).
There seems to be many ways of hacking together a crude working import
function using exec, imp, or the hosting api. This would lead me to
believe that there's nothing blocking import from working in threads
on Silverlight.

I've been hacking all day with Kamil's parallel importer, and using
some crude hacks, I've managed to get quite far with it. Most every
obstacle being an incompatibility between my import function and
Python import semantics (which are not simple, especially with regard
to nested packages!) So I've given up for now, but I'd like to be able
to revisit this later if __import__ works. There seems to be no other
optimization I can do that would give as much speedup to load time.

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

Re: [IronPython] Importing in a background thread

2008-11-21 Thread Dino Viehland 
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 by if __import__ works?  And how does importing in a 
background thread fail?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Eloff
Sent: Friday, November 21, 2008 7:02 PM
To: Discussion of IronPython
Subject: [IronPython] Importing in a background thread

I'm curious why importing in a background thread fails completely in
Silverlight (well anything builtin and anything already loaded works).
There seems to be many ways of hacking together a crude working import
function using exec, imp, or the hosting api. This would lead me to
believe that there's nothing blocking import from working in threads
on Silverlight.

I've been hacking all day with Kamil's parallel importer, and using
some crude hacks, I've managed to get quite far with it. Most every
obstacle being an incompatibility between my import function and
Python import semantics (which are not simple, especially with regard
to nested packages!) So I've given up for now, but I'd like to be able
to revisit this later if __import__ works. There seems to be no other
optimization I can do that would give as much speedup to load time.

-Dan
___
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