[IronPython] Lightweight Code Generation?

[Andrew Deren]

I meant to send the below to the list, but somehow it got sent only to Jim,
so maybe someone else could answer that too.

Would you know where I can find more info on dynamic methods? One thing I'm
especially looking for is a way to call other dynamically created methods
from one. Is it even possible?
If I have a script that defines custom functions, I would need to emit those
too. Would I create separate DynamicMethod for each one of them?

Thanks.

-----Original Message-----
From: users-ironpython.com-bounces at lists.ironpython.com
[mailto:users-ironpython.com-bounces at lists.ironpython.com] On Behalf Of Jim
Hugunin
Sent: Saturday, October 09, 2004 12:08 PM
To: 'Alex Hoffman'; users-ironpython.com at lists.ironpython.com
Subject: RE: [IronPython] Lightweight Code Generation?

Alex Hoffman write:
> Unfortunately unloading an assembly from the primary AppDomain surely
> goes beyond any member of the CLR team's influence.  It is core to the
> architecture of the CLR - not a feature that can just be bolted on or
> included in the "next release".

Unloading assemblies is a big issue and one that I'm unlikely to change in
the very near future.  Here's a link to my boss's blog where he talks about
this issue:
  http://blogs.msdn.com/jasonz/archive/2004/05/31/145105.aspx

I agree that there is potentially value in hosting embedded scripts in a
separate AppDomain with restricted permissions in order to increase
reliability.  I really like to ability to monitor scripts and kill them if
they use too much memory or time.  One of the many tasks on my giant todo
list is to write a hosting example that shows how separate AppDomains can be
used effectively to host a scripting solution.  Until I do that, I can't
really comment on how much of a problem this is in practice.

> As mentioned it's maybe worth a revisit given LCG and dynamic properties.

LCG is the right way to fix this problem in the near term.  Once again, I'll
send you off to one of my co-worker's blogs for a concrete example:
  http://blogs.msdn.com/joelpob/archive/2004/03/31/105282.aspx

It should be a trivial matter to support this form of generation as an
option in IronPython that is used only on systems that support
DynamicMethod.  This would mean that 1.1 systems would have an interactive
interpreter with a memory leak, but that on 2.0 that same interactive
interpreter would stop leaking making it viable in a greater range of
circumstances.

-Jim


_______________________________________________
users-ironpython.com mailing list
users-ironpython.com at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com