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.
Thanks,
Shri
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Riley
Sent: Thursday, May 01, 2008 6:49 AM
To: [email protected]
Subject: Re: [Ironruby-core] Opening up our tree to external committers
On Thu, May 1, 2008 at 2:37 AM, Jimmy Schementi <[EMAIL
PROTECTED]<mailto:[EMAIL PROTECTED]>> 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?
~Jimmy
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.)
-R2
_______________________________________________
Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core
