[Ironruby-core] Opening up our tree to external committers

Shri Borde Shri.Borde at microsoft.com
Fri May 2 02:56:17 EDT 2008

IronPython has the following scheme for loading Python modules:

1.       IronPython looks for all the PythonModuleAttribute custom attributes inside any assembly registered with IronPython using "clr.AddReference(assemblyName)" which is similar to "require" in Ruby. The assembly-level attributes point to all the Python modules available inside the assembly. For eg, "[assembly: PythonModuleAttribute("nt", typeof(IronPython.Modules.PythonNT))]" indicates that the "PythonNT" C# type implements the "nt" Python module. A single assembly can contain multiple Python modules.

2.       On startup, IronPython registers IronPython.Modules.dll automatically. Hence, all Python modules from the dll become accessible.

3.       Python loads site.py on startup. The site.py that ships with IronPython looks inside a specific folder and registers all assemblies in that folder. So a user can drop an assembly in this folder, and all the Python modules in the assembly will become accessible. I believe Seo uses this to good measure in FePy to make his own set of Python modules available to users.

4.       Accessible modules are put on a stand-by list. They get activated only if the user does "import someModule" which is similar to "require" in Ruby. Until then, the user is not exposed to the fact that the modules are accessible.

Could a similar scheme work for IronRuby? All the small IronRuby libraries owned by external committers could live in an assembly like IronRuby.Libraries.Staging.dll, and this could be placed in some well-known folder relative to IronRuby.dll. Size should not be much of an issue in Silverlight as you would expect that the IronRuby runtime and libraries would be cached on the user's machine most of the time. If it does become an issue, we can later break up IronRuby.Libraries.Staging.dll into smaller pieces. Once the DLR gets more stable, IronRuby.Libraries.Staging.dll can be merged into IronRuby.Libraries.dll.

Want to work on IronPython, IronRuby, F#<http://blogs.msdn.com/ironpython/archive/2008/02/25/ironpython-ironruby-and-f-openings-in-dev-test-and-pm.aspx>? Visit http://blogs.msdn.com/ironpython/

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ryan Riley
Sent: Thursday, May 01, 2008 6:49 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Opening up our tree to external committers

On Thu, May 1, 2008 at 2:37 AM, Jimmy Schementi <Jimmy.Schementi at microsoft.com<mailto:Jimmy.Schementi at microsoft.com>> wrote:
Splitting into different DLLs complicate things for Silverlight.

On the desktop you can have the assembly loading be dynamic with a foo.rb wrapper for a library. However, Silverlight (today) requires the DLL would have to be downloaded to the client first before loading. In other words, the AppManifest.xaml (and the XAP, but that's optional) would have to know about ALL the IronRuby Library DLLs you "could" want to use. We automate the generation of this file and XAP, so that tool (Chiron) would need to know this. While this isn't a direct problem, it does make the # of assemblies you need to include with your app go from 2 to n. Splitting could potentially save download size, but figuring out which DLLs to include is hard (see below).

Are there other options for how to get DLLs onto a client machine?

To get this option out of the way, we can't bake this logic (download an assembly when you require it) into our Silverlight integration, or even push the responsibility on the libraries themselves. Downloading in SL requires asynchronous requests, and we can't pause user code to do this (aka. Continuations). We could technically implement it by hacking on XmlHttpRequest directly to get synchronous support, but ugh. If network connection gets flakey your browser hangs ... not very pleasant.

Do we introduce a config.rb to Silverlight that lets you define the closure of all the assemblies you'll need? This file gets loaded first, it triggers the downloads the necessary assemblies, and then load the real program?

Again, the AppManifest solution will work, but it's not very dynamic-language-esc, and becomes more apparent if we split the libraries out. I'm just brainstorming for better solutions to this. Ideas?


Wouldn't this, then, lend itself toward a solution towards that proposed by /M:D? I don't know multi-file assemblies that well, but it seems the best solution in that, iirc, only the .netmodules needed are loaded as they are called, but they're already linked by the primary assembly. This might be more complicated to maintain and cleanly build; I don't know. I also don't quite understand the "not dynamic" comment, but again, I'm not too familiar with multi-file assemblies.

(Also, apologies for the duplicate in the other thread.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080501/e61eadb8/attachment.html>

More information about the Ironruby-core mailing list