[IronPython] Lightweight Code Generation?

[Alex Hoffman]

Have a long session - you'll see that "gobs" of memory can be consumed.

However, it's true that increasing memory usage in an interactive 
session might be acceptable in some scenarios.  But in others it might 
not.  That's especially the case if the product doesn't come from 
Microsoft ;)

My concern was not really the short interactive session, but related to 
providing a solution for integrated scripting (called embedded scripting 
in Python?).  Where one can add functionality to an application through 
scripting at runtime.  If one provided a .NET language (including 
Python) "script control", one would have to supply it with a warning not 
to modify the script too much!  Either that or implement a second 
AppDomain recycling scheme that meant that the script was effectively 
operating in a sandbox.

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".

To give you some idea, the whole VSA (Visual Tools for Applications) 
product effectively died at the hands of this issue (and a changing ASP 
market).  It meant that Microsoft had to forget a run time scripting 
environment and instead release a design time scripting solution - 
Visual Studio Tools For Office.  It's such a big issue that VBA is still 
their strategic integrated scripting solution years after .NET's release.

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

Alex Hoffman


J. Merrill wrote:

>I agree that it's unfortunate to lose memory at each press of the Enter key, but we are not talking about gobs and gobs of memory, are we?  The usefulness of the interactive mode is so much greater than the few MB of unrecoverable memory that would accumulate during a very long session.  (Even if we can't recover the memory, if it gets paged out and never comes back it should not have a great impact.)  
>
>I for one would trade "you need to exit and start again every 3 hours" for the ability to work in the dynamic, interactive, "hold the data in your hands" mode that (Iron)Python provides.  The fact that we can use a great deal of what .NET has to offer (and eventually will be able to use it all) while writing in Python is great.
>
>The fact the MS seems to have made a poor implementation decision in the 1.x framework -- one that decrees that no code that's been loaded into an AppDomain can be unloaded without destroying the entire AppDomain -- should not prevent us from having a productive environment.  
>
>Taking advantage of -- and perhaps enhancing prior to release -- the new functionality would be great.  However, there are other things that I think are more important to be ready for an eventual 1.0 release of FePy.
>
>Jim is perhaps uniquely positioned to have an impact on the future course of the new capabilities.  Hopefully the issues he mentioned in his other post can be resolved by changes to the CLR -- now that he's on the team.
>
>At 03:19 AM 10/8/2004, Alex Hoffman wrote (in part)
>  
>
>>But I effectively abandoned that ... because I thought that constantly consuming (unrecoverable) memory each time someone hit the enter key was unacceptable. 
>>    
>>
>
>
>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
>  
>