<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:D="DAV:" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z="urn:schemas-microsoft-com:" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
        {page:Section1;}
 /* List Definitions */
 @list l0
        {mso-list-id:1683363295;
        mso-list-type:hybrid;
        mso-list-template-ids:2097595808 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>IronPython has the following scheme for loading Python modules:<o:p></o:p></span></p>

<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>1.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>IronPython looks for all the PythonModuleAttribute custom
attributes inside any assembly registered with IronPython using &#8220;clr.AddReference(assemblyName)&#8221;
which is similar to &#8220;require&#8221; in Ruby. The assembly-level
attributes point to all the Python modules available inside the assembly. For
eg, &#8220;</span><span style='font-size:10.0pt;font-family:"Courier New"'>[<span
style='color:blue'>assembly</span>: <span style='color:#2B91AF'>PythonModuleAttribute</span>(<span
style='color:#A31515'>&quot;nt&quot;</span>, <span style='color:blue'>typeof</span>(IronPython.Modules.<span
style='color:#2B91AF'>PythonNT</span>))]</span><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>&#8221; indicates that the &#8220;PythonNT&#8221;
C# type implements the &#8221;nt&#8221; Python module. A single assembly can
contain multiple Python modules.<o:p></o:p></span></p>

<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>2.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>On startup, IronPython registers IronPython.Modules.dll
automatically. Hence, all Python modules from the dll become accessible.<o:p></o:p></span></p>

<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>3.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>

<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>4.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Accessible modules are put on a stand-by list. They get
activated only if the user does &#8220;import someModule&#8221; which is
similar to &#8220;require&#8221; in Ruby. Until then, the user is not exposed
to the fact that the modules are accessible.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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&#8217;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.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Thanks,<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Shri<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:9.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><a
href="http://blogs.msdn.com/ironpython/archive/2008/02/25/ironpython-ironruby-and-f-openings-in-dev-test-and-pm.aspx"><span
style='color:blue'>Want to work on IronPython, IronRuby, F#</span></a>? </span><span
style='font-size:1.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Visit
http://blogs.msdn.com/ironpython/</span><span style='font-size:9.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
ironruby-core-bounces@rubyforge.org [mailto:ironruby-core-bounces@rubyforge.org]
<b>On Behalf Of </b>Ryan Riley<br>
<b>Sent:</b> Thursday, May 01, 2008 6:49 AM<br>
<b>To:</b> ironruby-core@rubyforge.org<br>
<b>Subject:</b> Re: [Ironruby-core] Opening up our tree to external committers<o:p></o:p></span></p>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<div>

<p class=MsoNormal>On Thu, May 1, 2008 at 2:37 AM, Jimmy Schementi &lt;<a
href="mailto:Jimmy.Schementi@microsoft.com">Jimmy.Schementi@microsoft.com</a>&gt;
wrote:<o:p></o:p></p>

</div>

<div>

<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>

<p class=MsoNormal>Splitting into different DLLs complicate things for
Silverlight.<br>
<br>
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 &quot;could&quot; 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).<br>
<br>
Are there other options for how to get DLLs onto a client machine?<br>
<br>
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.<br>
<br>
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?<br>
<br>
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?<br>
<span style='color:#888888'><br>
~Jimmy</span><o:p></o:p></p>

</blockquote>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<div>

<p class=MsoNormal>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&nbsp;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 &quot;not dynamic&quot; comment, but again, I'm
not too familiar with multi-file assemblies.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>(Also, apologies for the duplicate in the other thread.)<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal>-R2<o:p></o:p></p>

</div>

</div>

</div>

</div>

</body>

</html>