[IronPython] Lightweight Code Generation?

[Alex Hoffman]

I'd be really interested in hearing more about your intended use of the 
LCG mechanism in 2.0.  In the past, I had intended introducing a shell 
or "interactive" mode to a "scripting" type product I had written 
(http://alintex.com/products.aspx).  The intention was to build on the 
current CodeDom functionality and use Reflection.Emit to generate 
opcodes based on parsed code at the "command line" in a similar way to 
what IronPython does now.

For example one could type in vb.net (following the example in your blog 
entry) ...

 >>> imports Systems.Windows.Forms

 >>> print 2+2
4
 >>> w = new Form

 >>> b = new Button

 >>> b.Text = "push me"

 >>> w.Controls.Add(b)

 >>> w.ShowDialog()
dialog pops up here

But I effectively abandoned that because of the imprecise syntax and 
vocab of say VB.NET (I left out how to handle the click event on button 
b above for a reason), but also because I thought that constantly 
consuming (unrecoverable) memory each time someone hit the enter key was 
unacceptable.  I guess it could be revisited in light of dynamic methods.

Alex Hoffman


Jim Hugunin wrote:

>The current use of the on disk snippets.dll is a total and absolute hack to
>make debugging easier during the development of IronPython.  As things get
>closer to a 1.0 release of IronPython, this will need to be replaced with an
>in-memory only version, plus a debugging mode for developers who have
>problems.  If you look at the code from IronPythonConsole, you'll notice
>that a try/finally is used to ensure that snippets.dll gets written even
>when an exception is going to be thrown.  This should emphasize the
>debugging nature of the current design.
>
>This situation can be made a lot better without using any new 2.0 features.
>In particular, this particular dll can easily be kept just in memory with
>barely any change to the existing code.  In fact, one of the advantages of
>continuing to use the 1.1 AssemblyBuilders is that they have this nice
>feature of either being just in-memory or being writable to disk.
>
>DynamicMethods, the new LCG mechanism in Whidbey/.NET 2.0, are a different
>story.  The HUGE benefit of these methods are that they can be garbage
>collected.  This would matter in a long running process that used eval
>occasionally, or possibly even in a short-running process that used eval a
>lot.  With AssemblyBuilders any generated code uses memory that can never be
>reclaimed.  With DynamicMethods you will get back the memory when there are
>no more references to the code as you'd hope.  The downside to
>DynamicMethods is that they can't be written to disk, which means they can
>be a PITA to debug when something goes wrong.
>
>Most of the code for building DynamicMethods is identical to the code for
>the AssemblyBuilder approach currently used; however, there will be some
>significant differences.  Perhaps the most obvious difference is that the
>current Python code generation uses CLR static fields for storing Python
>constants.  DynamicMethods are just methods, so they don't let you create
>static field, so this code generation would have to be modified to get the
>constants from somewhere else.  This is a big enough change to have some
>risk of inconsistent behavior and thus will need to be handled carefully.
>
>The huge benefit of being able to reclaim the memory from the code in a
>DynamicMethod is so important that I'm sure this feature will be enabled in
>some way in IronPython-1.0.  The exact mechanisms used will take some
>careful engineering.
>
>-Jim
>
>
>  
>
>>-----Original Message-----
>>From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-
>>ironpython.com-bounces at lists.ironpython.com] On Behalf Of J. Merrill
>>Sent: Friday, September 17, 2004 10:50 AM
>>To: users-ironpython.com at lists.ironpython.com
>>Subject: Re: [IronPython] Lightweight Code Generation?
>>
>>It would certainly be easy enough to get rid of that "single instance per
>>directory" side effect.  .NET supports in-memory-only assemblies, but
>>having the assembly on disk certainly must make it easier to do certain
>>kinds of debugging (e.g. you could run Reflector on it to see what's going
>>on, if it doesn't work the way you think it should).
>>
>>For at least that reason, I'd want to have the option to have any dynamic
>>assemblies be on-disk.  If using the new functionality would mean that
>>there'd have to be two different implementations, one to satisfy the "on-
>>disk assembly" requirement and one that uses the new functionality, that
>>would leave open the possibility that things would work differently in
>>those two scenarios -- which I'd think could make people mistrust FePy
>>completely.
>>
>>But if the new mechanisms lets you save the resulting dynamic code as an
>>assembly (if needed), it might be worth the "no .NET 1.1 framework
>>support" problems to use those new features.
>>
>>At 08:56 PM 9/16/2004, Curt Hagenlocher wrote (in part)
>>
>>    
>>
>>>Right now, FePy has to generate an assembly to contain all of
>>>its dynamic code.  It generates this assembly to the file
>>>snippets.dll.  I'm not sure if it has to generate the assembly
>>>to a file (versus in-memory), but one side effect of this is
>>>that you can only run a single instance of FePy from the same
>>>directory at the same time.
>>>
>>>Being able to generate dynamic code that lives in memory and
>>>doesn't have to be part of an on-disk assembly could be very
>>>useful.
>>>
>>>--
>>>Curt Hagenlocher
>>>curt at hagenlocher.org
>>>      
>>>
>>J. Merrill / Analytical Software Corp
>>
>>_______________________________________________
>>users-ironpython.com mailing list
>>users-ironpython.com at lists.ironpython.com
>>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>    
>>
>
>
>_______________________________________________
>users-ironpython.com mailing list
>users-ironpython.com at lists.ironpython.com
>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>  
>