[IronPython] IronPython 2.6 CodePlex Source Update

merllab at microsoft.com merllab at microsoft.com
Mon Apr 5 17:53:30 CEST 2010


This is an automated email letting you know that sources 
have recently been pushed out.  You can download these newer 
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/65283.

ADDED SOURCES
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/repl_formatter.rb
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/repl_formatter.py

MODIFIED SOURCES
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/repl_formatter.rb
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/repl_formatter.py
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/init.rb
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/DynamicScriptTags.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/XamlScriptTags.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/ComInvokeBinder.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/ComFallbackMetaObject.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/ComBinderHelpers.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/ComMetaObject.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/ConvertibleArgBuilder.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/ConversionArgBuilder.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/BoolArgBuilder.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/BrowserVirtualFilesystem.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/DynamicEngine.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/agdlr.css
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/Repl.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Chiron/HttpSocket.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Chiron/App.config
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/Microsoft.Scripting.Silverlight.csproj
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/VariantArgBuilder.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/StringArgBuilder.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/UnknownArgBuilder.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/DispatchArgBuilder.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/DateTimeArgBuilder.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/ErrorArgBuilder.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Chiron/LanguageInfo.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Chiron/XapBuilder.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/DynamicApplication.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/ExtensionTypes.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Chiron/Chiron.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Chiron/HttpServer.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonOptions.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/IronPython.Modules.csproj
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/FunctionDefinition.cs
	$/IronPython/IronPython_Main/Src/IronPython/IronPython.csproj
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/BranchLabel.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Instructions/ControlFlowInstructions.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Instructions/InstructionList.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Instructions/TypeOperations.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Instructions/InstructionFactory.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Instructions/LocalAccess.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Interpreter.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/InterpretedFrame.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/LocalVariables.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/LightLambdaClosureVisitor.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/LightCompiler.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/LightDelegateCreator.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/LoopCompiler.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Utils/HashSet.cs

CHECKIN COMMENTS
--------------------------------------------------------------------------------
Changeset Id: 1712859
Date: 4/5/2010 1:36:21 AM

Silverlight fixes from PyCon and MIX
====================================

Touches IronPython/IronRuby, Microsoft.Scripting.Silverlight, and Chiron.

-------------------
IronPython/IronRuby
-------------------

- IronPython.csproj was mistakenly looking for System.Core when referencing
  System.Numerics
- IronPython.Modules.csproj and Ruby.csproj weren't using the $(SignedSym) in Silverlight
  builds, and IronPython.Modules.csproj needed a reference to System.Numerics for Silverlight 4
  builds

-------------------------------
Microsoft.Scripting.Silverlight
-------------------------------

Zip-file script-tags
++++++++++++++++++++
Script-tags now support zip-file sources, for packaging assemblies, any
other binary data, or large script libraries. The zip-file name is then
recognized as a top-level directory on the virtual file-system, so
import/require will load files out of there, as well directly opening
the file.

<script type="application/x-zip-compressed" src="foo.zip"></script>
<script type="text/python">
  import clr
  clr.AddReferenceToFile("foo/foo.dll") # gets foo.dll out of foo.zip

  import sys
  sys.path.append("foo")
  import bar # imports bar.py from foo.zip

  print open('foo/bar.py').read() # print contents of bar.py
</script>

NOTE: When using zip-file script-tags AND running on localhost
(non-internet location) AND using the binaries hosted online
(gestalt.ironpython.net, or any other internet location), the downloader
fails over to a XmlHttpRequest downloader, which has limitations with
handling binary data in Internet Explorer. While I've tried to work
around them, performance of loading a 100k+ zip file in IE comes to a
crawl. Since this scenario is only apparent during development, the
work-around is to download the DLR+Language binaries and depend on them
locally. This is not an issue when both the application and the DLR
assemblies are hosted on an internet location (foo.com and
gestalt.ironpython.net, for example), as then the Silverlight downloader
will be used, which handles binary data just fine. Let me reiterate
that this is only an issue for Internet Explorer.


Python DOM event handling
+++++++++++++++++++++++++
DOM event handling in Python is also improved by a slight change in DOM
event handling syntax:

def say_hello(*args):
    print "Hello!"

document.button.events.onclick += say_hello

Every HtmlObject has an "events" property, which allows you to hook DOM
events with the += syntax.


Deferred XAML loading
+++++++++++++++++++++
XAML script-tags now support the "defer" attribute, still creating a
Silverlight control but not loading the XAML:

<script type="application/xml+xaml" src="foo.xaml" defer="true" width="100" height="100"></script>
<script type="text/python">
  from Microsoft.Scripting.Silverlight.DynamicApplication import Current as app

  app.LoadRootVisualFromString(open("foo.xaml").read())
</script>

This allows the script to control when the Silverlight loading animation
stops.


REPL formatting per language
++++++++++++++++++++++++++++
Now the REPL has custom formatting per language; prompt color, result
inspection, etc. For example, Python's prompt is now yellow, and no
longer shows the Ruby "=>" for non "None" return values.


REPL demo mode
++++++++++++++
If demoing the build-in REPL on a projector for a decent-sized room, you
can add the "demo" ID to the body tag to double the size and fonts of the
console window.

<body id="demo">


Other fixes
+++++++++++

- REPL style fixes across IE, FF, Chrome, Safari
- Fix OOB support
- Stack overflow fix for missing DOM properties in Ruby
- Fix Safari property setting in Ruby
- FIX DLRConsole when running against unsigned binaries
- FIX both Ruby and Python "photos" sample


------
Chiron
------

Previously Chiron used the "externalUrlPrefix" setting to decide
whether or not the DLR assemblies should be put in the XAP, or
Silverlight 3's transparent platform extensions (TPEs) should be
used instead. However, only the DLR assemblies are ever used as
TPEs; the languages are either in the XAP as assemblies or downloaded
if used. So these two ideas are now split appart, mainly to allow
generating a XAP file that will work with Moonlight 2.

- 'useExtensions' toggle tells Chiron to generate a XAP file
  which loads the DLR via Silverlight's transparent platform
  extensions (if set to true), or just put the DLR assemblies
  in the XAP (if set to false).
- 'detectLanguages' toggle to tell Chiron to detect what language
  the app uses by just looking through the folder which will be zipped.
  If true, it will detect the languages and make sure the language
  assemblies are avaliable to the XAP file (either as DLLs or SLVXs,
  dependent on the useExtensions value). Otherwise, it does no
  language detection (in this case Microsoft.Scripting.Silverlight
  is responcible for doing language detection and downloading of language
  assemblies).

Also, to better support the downloading of the language binaries, urlPrefix
has been "undepricated", and externalUrlPrefix has been removed. Now *any file*
(not just DLLs or PDBs) in the localAssemblyPath will be served from the
urlPrefix URL.

Other fixes/tweaks
++++++++++++++++++

- By default it generates a XAP that can be installed OOB
- Now works as an internet-facing web-server, rather than just listening
  on localhost.
- Allows files to be cached from Chiron (use to send the no-cache header)


Note: Though the gestalt-style application model does not require Chiron to be
used by application developers, Chiron is still a very useful tool for
language developers to test Silverlight applications under their language,
since it automatically picks up new language/DLR binaries. Also, using Chiron
and generating a unique XAP per application is the only way to write OOB-enabled
applications. So Chiron will continue to be supported as a web-server and
XAP generator for dynamic language applications.


--------------
Infrastructure
--------------
- Silverlight build drops now contain dlr.js and dlr.xap
- Now support building against Silverlight 4 RC





(Shelveset: slpyconmix;REDMOND\jimmysch | SNAP CheckinId: 10647)
--------------------------------------------------------------------------------
Changeset Id: 1712319
Date: 4/3/2010 6:01:11 PM

Supports shadowing of variables.  We now undefined variables when they go out of scope and keep track of variables being redfined below the current scope.  When a variable gets boxed to a closure we now only box the relevant ranges.  Because of this LocalVariables is a more expensive data structure so I’ve made it so we don’t hold onto it after compilation – instead we flow in information such as closure size where we need it.  For closued over parameters we now we emit a parameter initialization instruction which by default does nothing.  When we box the parameter we change it into an instruction which creates a strong box around the initial parameter value.  This also removes our “BoxLocals” phase when entering a method which may have been boxing too much.

The loop compiler also gets updated – it just needs to track variables which are local to the loop.

Adds the TypeAs instruction which was missing.

Fixes a bug w/ Goto expression.  When the goto has a value but that value is void we’re not accurately tracking the stack size.



(Shelveset: InterpreterBugsFinal2;REDMOND\dinov | SNAP CheckinId: 10644)
--------------------------------------------------------------------------------
Changeset Id: 1712859
Date: 4/5/2010 1:36:21 AM

Silverlight fixes from PyCon and MIX
====================================

Touches IronPython/IronRuby, Microsoft.Scripting.Silverlight, and Chiron.

-------------------
IronPython/IronRuby
-------------------

- IronPython.csproj was mistakenly looking for System.Core when referencing
  System.Numerics
- IronPython.Modules.csproj and Ruby.csproj weren't using the $(SignedSym) in Silverlight
  builds, and IronPython.Modules.csproj needed a reference to System.Numerics for Silverlight 4
  builds

-------------------------------
Microsoft.Scripting.Silverlight
-------------------------------

Zip-file script-tags
++++++++++++++++++++
Script-tags now support zip-file sources, for packaging assemblies, any
other binary data, or large script libraries. The zip-file name is then
recognized as a top-level directory on the virtual file-system, so
import/require will load files out of there, as well directly opening
the file.

<script type="application/x-zip-compressed" src="foo.zip"></script>
<script type="text/python">
  import clr
  clr.AddReferenceToFile("foo/foo.dll") # gets foo.dll out of foo.zip

  import sys
  sys.path.append("foo")
  import bar # imports bar.py from foo.zip

  print open('foo/bar.py').read() # print contents of bar.py
</script>

NOTE: When using zip-file script-tags AND running on localhost
(non-internet location) AND using the binaries hosted online
(gestalt.ironpython.net, or any other internet location), the downloader
fails over to a XmlHttpRequest downloader, which has limitations with
handling binary data in Internet Explorer. While I've tried to work
around them, performance of loading a 100k+ zip file in IE comes to a
crawl. Since this scenario is only apparent during development, the
work-around is to download the DLR+Language binaries and depend on them
locally. This is not an issue when both the application and the DLR
assemblies are hosted on an internet location (foo.com and
gestalt.ironpython.net, for example), as then the Silverlight downloader
will be used, which handles binary data just fine. Let me reiterate
that this is only an issue for Internet Explorer.


Python DOM event handling
+++++++++++++++++++++++++
DOM event handling in Python is also improved by a slight change in DOM
event handling syntax:

def say_hello(*args):
    print "Hello!"

document.button.events.onclick += say_hello

Every HtmlObject has an "events" property, which allows you to hook DOM
events with the += syntax.


Deferred XAML loading
+++++++++++++++++++++
XAML script-tags now support the "defer" attribute, still creating a
Silverlight control but not loading the XAML:

<script type="application/xml+xaml" src="foo.xaml" defer="true" width="100" height="100"></script>
<script type="text/python">
  from Microsoft.Scripting.Silverlight.DynamicApplication import Current as app

  app.LoadRootVisualFromString(open("foo.xaml").read())
</script>

This allows the script to control when the Silverlight loading animation
stops.


REPL formatting per language
++++++++++++++++++++++++++++
Now the REPL has custom formatting per language; prompt color, result
inspection, etc. For example, Python's prompt is now yellow, and no
longer shows the Ruby "=>" for non "None" return values.


REPL demo mode
++++++++++++++
If demoing the build-in REPL on a projector for a decent-sized room, you
can add the "demo" ID to the body tag to double the size and fonts of the
console window.

<body id="demo">


Other fixes
+++++++++++

- REPL style fixes across IE, FF, Chrome, Safari
- Fix OOB support
- Stack overflow fix for missing DOM properties in Ruby
- Fix Safari property setting in Ruby
- FIX DLRConsole when running against unsigned binaries
- FIX both Ruby and Python "photos" sample


------
Chiron
------

Previously Chiron used the "externalUrlPrefix" setting to decide
whether or not the DLR assemblies should be put in the XAP, or
Silverlight 3's transparent platform extensions (TPEs) should be
used instead. However, only the DLR assemblies are ever used as
TPEs; the languages are either in the XAP as assemblies or downloaded
if used. So these two ideas are now split appart, mainly to allow
generating a XAP file that will work with Moonlight 2.

- 'useExtensions' toggle tells Chiron to generate a XAP file
  which loads the DLR via Silverlight's transparent platform
  extensions (if set to true), or just put the DLR assemblies
  in the XAP (if set to false).
- 'detectLanguages' toggle to tell Chiron to detect what language
  the app uses by just looking through the folder which will be zipped.
  If true, it will detect the languages and make sure the language
  assemblies are avaliable to the XAP file (either as DLLs or SLVXs,
  dependent on the useExtensions value). Otherwise, it does no
  language detection (in this case Microsoft.Scripting.Silverlight
  is responcible for doing language detection and downloading of language
  assemblies).

Also, to better support the downloading of the language binaries, urlPrefix
has been "undepricated", and externalUrlPrefix has been removed. Now *any file*
(not just DLLs or PDBs) in the localAssemblyPath will be served from the
urlPrefix URL.

Other fixes/tweaks
++++++++++++++++++

- By default it generates a XAP that can be installed OOB
- Now works as an internet-facing web-server, rather than just listening
  on localhost.
- Allows files to be cached from Chiron (use to send the no-cache header)


Note: Though the gestalt-style application model does not require Chiron to be
used by application developers, Chiron is still a very useful tool for
language developers to test Silverlight applications under their language,
since it automatically picks up new language/DLR binaries. Also, using Chiron
and generating a unique XAP per application is the only way to write OOB-enabled
applications. So Chiron will continue to be supported as a web-server and
XAP generator for dynamic language applications.


--------------
Infrastructure
--------------
- Silverlight build drops now contain dlr.js and dlr.xap
- Now support building against Silverlight 4 RC





(Shelveset: slpyconmix;REDMOND\jimmysch | SNAP CheckinId: 10647)



More information about the Ironpython-users mailing list