[Ironpython-users] Meta-Questions (Was: Commercial Support / Bugfixes for Ironpython)

[Markus Schaber]

Hi,



Just three Meta-Topics:



Does this list prefer the "Internet"-style (Plain-Text, and the replies interleaved with the quoted paragraphs), or "Outlook"-style (HTML/RTF and TOFU)?



When googling for "IronPython Mailing List", the first hit is http://lists.ironpython.com/listinfo.cgi/users-ironpython.com - but this list seems to be replaced by the new one from python.org since 2011. While I like the fact that the old archives are still online, I'd suggest that you add some explanation and link on that page (maybe in the "About Users" part at the top) which points to the new list at python.org.



And it seems that there is no form of commercial support or contracted development available for IronPython and the DLR right now, correct?


Best regards

Markus Schaber
-



> Von: Curt Hagenlocher [mailto:curt at hagenlocher.org]

> > Von: Markus Schaber

> > > Von: Curt Hagenlocher [mailto:curt at hagenlocher.org]





> > > > On Thu, Oct 18, 2012 at 8:52 AM, Markus Schaber <m.schaber at 3s-software.com<mailto:m.schaber at 3s-software.com>> wrote:

> > > > > Is it possible to hire some of the IronPython Core developers for bugfixes, or is there commercial support available?





> > > > > Especially http://ironpython.codeplex.com/workitem/31764 is a major issue for some of our users, they fight with Out of Memory exceptions during automated test runs which fire hundreds of IronPython scripts.

> > > > > For us, it might be cheaper and faster to pay an expert for this task, than trying to solve it on our own.

> > > > This doesn't directly address your question, but as I recall,

> DefineDynamicAssembly is only used under very particular circumstances. It

> can be avoided most of the time in non-debug usage of IronPython. The only

> way to release some of the memory usage forced by DefineDynamicAssembly is

> to tear down the AppDomain and create a new one. This is a CLR issue.

> > > > Disclaimer: I haven't worked on this code in about three years.

> > > Thank you for your answer. Maybe it is possible to utlilise the

> Collectible Assemblies introduced with .NET 4.0





> (http://msdn.microsoft.com/en-us/library/dd554932%28v=vs.100%29.aspx) -

> they should be fully GC-able...

> > > We can also live with an explicit "Dispose()"-Method to clean up

> artifacts of old scripts, if that helps further...

> > I don't want to make it sound like I know more than I do; the discussion

> on work item 20399 makes it clear that I don't accurately remember all of

> the specifics around this issue. But I do recall that we looked at using

> collectible assemblies and decided against it. We were still committed to

> supporting .NET 2.0 at the time, so that was one factor. But the real

> problem is having a realistic idea of when to stop emitting methods into

> assembly 1 and start emitting them into assembly 2. Having small

> granularity -- too many assemblies -- is a bad thing (for reasons I no

> longer remember). But putting too many methods into a single assembly

> increases the chance that the assembly will never be collected because one

> of its types are still in use.

>

> > Running each independent script in its own AppDomain is painful and may

> have performance consequences. But ultimately, it gives you the best

> control over resource management.

> On Thu, Oct 18, 2012 at 9:16 AM, Markus Schaber <m.schaber at 3s-<mailto:m.schaber at 3s-software.com>

> software.com<mailto:m.schaber at 3s-software.com>> wrote:

>

> In our case, it would be possible to use one collectible assembly for one

> ScriptEngine.

>

> Using a separate AppDomain would endanger compatibility with 3rd-party

> plugins providing functionality to the plugins - they need to update to

> MarshalByRefObject or serializable objects, and we usually have strict

> backwards guarantees. But maybe that's the only really workable way. (And

> maybe we find a way to dynamically create and transparently inject

> MarshalByRefObject-Wrappers into our official script interfaces.)

>

> Just a total different thought, though:

>

> Right now, we create a different ScriptEngine for most script runs. The

> reason is that we want to have a clean environment for each script,

> without any artifacts from the previous script run.

>

> Maybe there is a more lightweight approach to achieve this goal. Is there

> a way to (re-)create such clean environments using the same script engine?

> (I hope that this could give us the advantage of re-using the generated

> code when the same script is re-run, or the same module is re-imported -

> reducing the leak to a bloat.)

>

> Just using a new ScriptScope seems not to be enough, AFAICS, as - for

> example - sys.modules needs to be re-set (and the modules contents

> themselves might have been manipulated by the scripts after importing

> them).

>

> A clean way to "Reset" an existing ScriptEngine would be at least a

> partial solution - this way, we still would need several Engines (for

> scripts triggering other scripts), but we could at least recycle them.

>

>

> Another idea might be a purely interpreted mode - AFAIR, IronRuby provides

> such a mode, while IronPython does not...



___________________________
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50

Email: m.schaber at 3s-software.com<mailto:m.schaber at 3s-software.com> | Web: http://www.3s-software.com <http://www.3s-software.com/>
CoDeSys internet forum: http://forum.3s-software.com<http://forum-en.3s-software.com/>
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20121024/98e63cde/attachment.html>