RednaxelaFX
- 浏览: 3019366 次
- 性别:
- 来自: 海外
-
文章分类
- 全部博客 (430)
- Programming Languages (23)
- Compiler (20)
- Virtual Machine (57)
- Garbage Collection (4)
- HotSpot VM (26)
- Mono (2)
- SSCLI Rotor (1)
- Harmony (0)
- DLR (19)
- Ruby (28)
- C# (38)
- F# (3)
- Haskell (0)
- Scheme (1)
- Regular Expression (5)
- Python (4)
- ECMAScript (2)
- JavaScript (18)
- ActionScript (7)
- Squirrel (2)
- C (6)
- C++ (10)
- D (2)
- .NET (13)
- Java (86)
- Scala (1)
- Groovy (3)
- Optimization (6)
- Data Structure and Algorithm (3)
- Books (4)
- WPF (1)
- Game Engines (7)
- 吉里吉里 (12)
- UML (1)
- Reverse Engineering (11)
- NSIS (4)
- Utilities (3)
- Design Patterns (1)
- Visual Studio (9)
- Windows 7 (3)
- x86 Assembler (1)
- Android (2)
- School Assignment / Test (6)
- Anti-virus (1)
- REST (1)
- Profiling (1)
- misc (39)
- NetOA (12)
- rant (6)
- anime (5)
- Links (12)
- CLR (7)
- GC (1)
- OpenJDK (2)
- JVM (4)
- KVM (0)
- Rhino (1)
- LINQ (2)
- JScript (0)
- Nashorn (0)
- Dalvik (1)
- DTrace (0)
- LLVM (0)
- MSIL (0)
最新评论
-
mldxs：
虽然很多还是看不懂，写的很好！
虚拟机随谈（一）：解释器，树遍历解释器，基于栈与基于寄存器，大杂烩 -
HanyuKing：
Java的多维数组 -
funnyone：
Java 8的default method与method resolution -
ljs_nogard：
Xamarin workbook - .Net Core 中不 ...
LINQ的恶搞…… -
txm119161336：
allocatestlye1 顺序为 // Fields o ...
最近做的两次Java/JVM分享的概要
刚才写代码的时候又是在不停查文档，甚是心烦。一怒，拿出IronPython，类似这样：
我可不想为了印证记忆中对.NET的正则表达式的模糊印象而去写C#代码->编译->运行->发现错误->修改->再编译->……这种时候用IronPython正顺手。
使用IronPython时，打开.NET大门的方法就是神奇的import clr。接下来通过clr对象来添加.NET程序集的引用，就可以开始用.NET的类库了（mscorlib是默认引入的）。整个使用体验相当流畅，刚启动解释器的时候比较卡的时间也减少了（虽然还是比CPython刚启动时慢，没办法）。
=====================================================================
我这IronPython是从CodePlex的DLR项目编译出来的，同一个Debug目录下还有IronRuby 0.4.0.0，于是干脆用IronRuby也试一次：
Well……看来不太对劲。虽然程序集也正确引入了，类型和方法也都正确加载执行了，但methods返回的方法列表里没有.NET的方法。这真够郁闷的，以前的版本明明可以的啊。好一段时间没玩IronRuby，这.NET interop怎么好像退化了 OTL
Anyway。使用IronRuby时，打开.NET大门的神奇方法是require 'mscorlib'。然后可以用强名称来引入别的.NET程序集，而标准库里的一些程序集是默认引入的，例如System.dll，所以上面我没有显式引入这个程序集。然后.NET命名空间要跟随Ruby代码习惯用::来分隔，基本上没别的大问题了。需要使用.NET的可变长度参数的方法时，可以对Ruby数组调用to_clr_array方法，跟JRuby非常类似。
=====================================================================
就目前而言，IronPython的完成度远在IronRuby之上。如果你也想现在就用Iron-*语言来探索.NET的话，我会推荐IronPython。不过IronPython 2.6现在还是暂时别用，bug多多……过不久等2.6出正式版之后再用吧～现在用IronPython 2.0.1稳定。
至于一个不是出自微软的Iron-*语言，IronScheme，它使用的DLR是非常老的版本，性能肯定是比不过微软的两个Iron-*语言。不过就其对R6RS的实现来说，它还是值得一试的，毕竟“实现了什么语义”比起“如何实现”更值得一般程序员所关注。
jython 2.5我希望作者能象他承诺的那样，能支持twisted。 其他倒没什么，没有ide也就算了。貌似最新的eclipse plguin也是 jython 2.1时候的东西了。
另一方面，Jython其实是受到Java/JVM的原始设计拖累而使得许多事情不好办。DVM正是解决这种“拖累”的实验项目。现在可以肯定的说，MethodHandle进入到JDK7了，而它与.NET一直有的delegate是如此的相似……呵呵，不看不知道，一看吓一跳。
当JVM变得更容易接受Java以外的其它语言时，JVM平台上的这些语言项目肯定会得到更好的发展的。
Java的创新思维似乎已死...总不能每次都看看.net就知道java下个版本会有什么，enum? foreach? auto-boxing? methodhanlder...
奇怪，为什么著名的perl竟然没有ironperl？ 当然因为Microsoft当activestate的后台老板。。。。也许不想砸他们的饭碗
Java从语言角度而言，我倒不希望再加入什么特别的语法糖果了，让更多的变革留给scala更好些。java优势在于
中规中矩，劣势可能也在于此。我倒是对jvm和gc的改善比较关注，hehe。
不尽然……让我模拟一次这过程：
C#：
这里写错了一点，因为我没有写using System;所以会找不到Console这个类。保存文件，编译，发现错误，修改，再编译。假设编译过了，但运行发现结果不对，判断是正则表达式写错了，那么再打开文件，编译，保存，编译，运行来看结果。
IronPython：
一上来先打开ipy，一个交互式解释器环境。
在ipy里输入System.Text.RegularExpressions，解释器报错，说'System'未定义。怎么办呢？
不用关掉ipy，还在刚才的同一个环境里，输入import clr：
再试那个命名空间发现还没引入进来。然后继续在ipy里输入import System：
现在试那个命名空间得到了正确的结果，于是就进一步把代码写下去：
现在看到正则表达式匹配失败了。仍然在同一个ipy里，继续试：
好！匹配成功了。
于是所谓REPL就是像这样的过程：read-eval-print loop。整个过程都不用离开交互式解释器环境，想到啥就写啥，马上就能看到对不对。然后把整个buffer复制出来整理一下，代码就写好了。
那个叫JDK7而不是Java7。我承认我是在咬文嚼字，不过Sun至今并没有提交Java7的JSR，所以……
DVM就是块实验田而已，里面的idea不保证会得到实现，实现的东西不保证会进入未来的JDK。但至少还是有这么块实验田，让人多少能感受到希望（=v=
Microsoft的试验田不知道在哪里...我转了好几圈想找C# 4.0的Spec和CLR 4.0的Spec.
那个叫JDK7而不是Java7。我承认我是在咬文嚼字，不过Sun至今并没有提交Java7的JSR，所以……
DVM就是块实验田而已，里面的idea不保证会得到实现，实现的东西不保证会进入未来的JDK。但至少还是有这么块实验田，让人多少能感受到希望（=v=
这就是JVM上的MOP（meta-object protocol），跟DLR的MOP对应。
一直在整理一份资料，现有JVM+invokedynamic相关+dynalang（+ASM？） = 现有CLI+DLR。需要整理的头绪很多，一时半会儿是出不来了 T T
如果说integration is innovation的话，那Java的innovation还没死。点子的来源也不是.NET一个，而是众多主流语言实现。
例如DVM里还有immediate wrappers types，这就是LISP、Ruby等都有的fixnum，其实就是tagged pointer的一种应用。这玩儿在CLR里还没有，也有很多人怨念着呢。
DVM里的runtime support for multimethods，也就是方法的多重分发，也是CLR还不支持的东西。VS2010 CTP里的C# 4通过dynamic特性支持了multimethod，但后来又决定缩回去了，采用更静态的绑定方式。
Continuation支持也是……这个我很是怨念，CLR没有内建的continuation支持。
当然，DVM里可以算得上借鉴.NET的东西也不少：MethodHandle（delegate）、invokedynamic（calli）、AnonymousClass（DynamicMethod）、TailCall（.tail），之类的。现在语言发展的大趋势就是互相借鉴，这是好事～
大部分还是proto,priority放的都是med，未来会不会出现在JDK还不得而知。
Runtime support for closures 这个可能根本就不会实现吧？
有人很有爱的在.NET上实现了一个叫Tycho的东东，基本上是一个Perl 6的实现。
Iron-*嘛，没足够的资源所以只能把关注点集中在最热的几个上面了。结果就是IronPython、IronRuby、VBx（已死）、Managed JScript（生死未卜）。
如果说integration is innovation的话，那Java的innovation还没死。点子的来源也不是.NET一个，而是众多主流语言实现。
例如DVM里还有immediate wrappers types，这就是LISP、Ruby等都有的fixnum，其实就是tagged pointer的一种应用。这玩儿在CLR里还没有，也有很多人怨念着呢。
DVM里的runtime support for multimethods，也就是方法的多重分发，也是CLR还不支持的东西。VS2010 CTP里的C# 4通过dynamic特性支持了multimethod，但后来又决定缩回去了，采用更静态的绑定方式。
Continuation支持也是……这个我很是怨念，CLR没有内建的continuation支持。
当然，DVM里可以算得上借鉴.NET的东西也不少：MethodHandle（delegate）、invokedynamic（calli）、AnonymousClass（DynamicMethod）、TailCall（.tail），之类的。现在语言发展的大趋势就是互相借鉴，这是好事～
另一方面，Jython其实是受到Java/JVM的原始设计拖累而使得许多事情不好办。DVM正是解决这种“拖累”的实验项目。现在可以肯定的说，MethodHandle进入到JDK7了，而它与.NET一直有的delegate是如此的相似……呵呵，不看不知道，一看吓一跳。
当JVM变得更容易接受Java以外的其它语言时，JVM平台上的这些语言项目肯定会得到更好的发展的。
Java的创新思维似乎已死...总不能每次都看看.net就知道java下个版本会有什么，enum? foreach? auto-boxing? methodhanlder...
奇怪，为什么著名的perl竟然没有ironperl？ 当然因为Microsoft当activestate的后台老板。。。。也许不想砸他们的饭碗
呵呵，这就是一家公司做的好处，决策的过程要远好于开源社区。唯一的问题，就是公司的战略方向是否正确了。至少，看起来微软的战略方向还是比较偏向于动态语言的。
Da Vinci Machine/JDK7（注意我不是说Java7）也是在“一家公司”，也就是Sun的控制下。
我觉得Jython在许多方面进度落后是受到关注它并且向其贡献代码的人不够多，长时间只有一两个人在维护，现在还活着就已经不简单了。这是Colin老大说到的一方面。但我们可以看到，就Jython现在还活着的部分看，其前端ANTLR、后端ASM、底下的执行引擎JVM、与外部交互用的JNA，都是开源的（JVM至少“有开源的选择”）。没有开源社区的间接支持，Jython现在肯定已经挂了。
另一方面，Jython其实是受到Java/JVM的原始设计拖累而使得许多事情不好办。DVM正是解决这种“拖累”的实验项目。现在可以肯定的说，MethodHandle进入到JDK7了，而它与.NET一直有的delegate是如此的相似……呵呵，不看不知道，一看吓一跳。
当JVM变得更容易接受Java以外的其它语言时，JVM平台上的这些语言项目肯定会得到更好的发展的。
最近Jython的项目维护者Frank Wierzbicki在Lang.NET 2009上介绍了项目状况。现在Jython还是采用只编译，不解释的执行方式，总是把Python源码编译为JVM字节码后才执行。这种方式影响到启动速度，近期IronPython已经转用解释到编译的渐变过程；Jython还在等DVM的成果出来……
呵呵，这就是一家公司做的好处，决策的过程要远好于开源社区。唯一的问题，就是公司的战略方向是否正确了。至少，看起来微软的战略方向还是比较偏向于动态语言的。
需要LINQ的时候用Mono的CSharpRepl确实美妙，外加还可以绘图啊什么的，Miguel真是高啊～
不过单纯是想查看类库的API，确认其行为时，还是Python（和Ruby）方便些。这些语言的语法，特别是做反射的时候很方便。.GetType().GetMethods()还是嫌麻烦了 =v=
嗯嗯，dir美啊 T T
最近Jython的项目维护者Frank Wierzbicki在Lang.NET 2009上介绍了项目状况。现在Jython还是采用只编译，不解释的执行方式，总是把Python源码编译为JVM字节码后才执行。这种方式影响到启动速度，近期IronPython已经转用解释到编译的渐变过程；Jython还在等DVM的成果出来……
IronPython 2.6 Beta DEBUG (2.6.0.1) on .NET 2.0.50727.3082
Type "help", "copyright", "credits" or "license" for more information.
>>> import clr
>>> clr.AddReference('System')
>>> import System
>>> System
<module 'System' (CLS module, 2 assemblies loaded)>
>>> R = System.Text.RegularExpressions.Regex
>>> r = R('abc')
>>> s = '123abcd456'
>>> dir(r)
['CacheSize', 'CompileToAssembly', 'Equals', 'Escape', 'GetGroupNames', 'GetGroupNumbers', 'GetHashCode', 'GetObjectData', 'GetType', 'GroupNameFromNumber', 'GroupNumberFromName', 'InitializeReferences', 'IsMatch', 'Match', 'Matches', 'MemberwiseClone', 'Options', 'ReferenceEquals', 'Replace', 'RightToLeft', 'Split', 'ToString', 'Unescape', 'UseOptionC', 'UseOptionR', '__class__', '__delattr__', '__doc__', '__format__', '__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', '__subclasshook__', 'capnames', 'caps', 'capsize', 'capslist', 'factory', 'pattern', 'roptions']
>>> m = r.Match(s)
>>> dir(m)
['Captures', 'Empty', 'Equals', 'GetHashCode', 'GetType', 'Groups', 'Index', 'Length', 'MemberwiseClone', 'NextMatch', 'ReferenceEquals', 'Result', 'Success', 'Synchronized', 'ToString', 'Value', '__class__', '__delattr__', '__doc__', '__format__', '__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', '__subclasshook__']
>>> m.Success
True
>>> m.Index
3
>>> m.ToString()
'abc'
>>>
我可不想为了印证记忆中对.NET的正则表达式的模糊印象而去写C#代码->编译->运行->发现错误->修改->再编译->……这种时候用IronPython正顺手。
使用IronPython时，打开.NET大门的方法就是神奇的import clr。接下来通过clr对象来添加.NET程序集的引用，就可以开始用.NET的类库了（mscorlib是默认引入的）。整个使用体验相当流畅，刚启动解释器的时候比较卡的时间也减少了（虽然还是比CPython刚启动时慢，没办法）。
=====================================================================
我这IronPython是从CodePlex的DLR项目编译出来的，同一个Debug目录下还有IronRuby 0.4.0.0，于是干脆用IronRuby也试一次：
IronRuby 0.4.0.0 on .NET 2.0.50727.3082 Copyright (c) Microsoft Corporation. All rights reserved. >>> require 'mscorlib' => true >>> System::Text::RegularExpressions => System::Text::RegularExpressions >>> R = System::Text::RegularExpressions::Regex => System::Text::RegularExpressions::Regex >>> r = R.new 'abc' => abc >>> s = '123abcd456' => "123abcd456" >>> r.methods.sort => ["==", "===", "=~", "__id__", "__send__", "class", "clone", "display", "dup", "eql?", "equal?", "extend", "freeze", "frozen?", "hash", "id", "inspect", "instance_eval", "instance_of?", "instance_variable_defined?", "instance_variable_get", "instance_variable_set", "instance_variables", "is_a?", "kind_of?", "method", "methods", "nil?", "object_id", "private_methods", "protected_methods", "public_methods", "respond_to?", "send", "singleton_methods", "taint", "tainted?", "to_a", "to_s", "type", "untaint"] >>> r.class => System::Text::RegularExpressions::Regex >>> m = r.match s => abc >>> m.class => System::Text::RegularExpressions::Match >>> m.methods.sort => ["==", "===", "=~", "__id__", "__send__", "class", "clone", "display", "dup", "eql?", "equal?", "extend", "freeze", "frozen?", "hash", "id", "inspect", "instance_eval", "instance_of?", "instance_variable_defined?", "instance_variable_get", "instance_variable_set", "instance_variables", "is_a?", "kind_of?", "method", "methods", "nil?", "object_id", "private_methods", "protected_methods", "public_methods", "respond_to?", "send", "singleton_methods", "taint", "tainted?", "to_a", "to_s", "type", "untaint"] >>> m.index => 3 >>> m.length => 3 >>> m.success => true >>> m.to_s => "abc" >>>
Well……看来不太对劲。虽然程序集也正确引入了，类型和方法也都正确加载执行了，但methods返回的方法列表里没有.NET的方法。这真够郁闷的，以前的版本明明可以的啊。好一段时间没玩IronRuby，这.NET interop怎么好像退化了 OTL
Anyway。使用IronRuby时，打开.NET大门的神奇方法是require 'mscorlib'。然后可以用强名称来引入别的.NET程序集，而标准库里的一些程序集是默认引入的，例如System.dll，所以上面我没有显式引入这个程序集。然后.NET命名空间要跟随Ruby代码习惯用::来分隔，基本上没别的大问题了。需要使用.NET的可变长度参数的方法时，可以对Ruby数组调用to_clr_array方法，跟JRuby非常类似。
=====================================================================
就目前而言，IronPython的完成度远在IronRuby之上。如果你也想现在就用Iron-*语言来探索.NET的话，我会推荐IronPython。不过IronPython 2.6现在还是暂时别用，bug多多……过不久等2.6出正式版之后再用吧～现在用IronPython 2.0.1稳定。
至于一个不是出自微软的Iron-*语言，IronScheme，它使用的DLR是非常老的版本，性能肯定是比不过微软的两个Iron-*语言。不过就其对R6RS的实现来说，它还是值得一试的，毕竟“实现了什么语义”比起“如何实现”更值得一般程序员所关注。
分享到：
评论
21 楼
mathgl
2009-05-19
RednaxelaFX 写道
兼容性是Jython 2.5关注的重点，外加来自JRuby的FFI支持，对使用了C extension的Python库的支持应该比IronPython好。
在启动速度上，Jython可以得益于JVM初段的解释执行，从而减缓刚开始的编译压力。但各JVM的实现策略不同，这种解释执行是得不到保证的。Jython 2.5自身并没有采取任何特别方法来提高启动速度，但以后的版本肯定会有这方面的工作。现在这个版本更多的是“Jython的复活”版本。
IronPython运行在CLI上，而现在桌面上两种主要的CLI实现，CLR和Mono都是直接JIT而不解释的，这层上IronPython的启动速度本来就吃了点亏。现在IronPython通过DLR的解释器来做自适应编译，可以看作是弥补启动速度慢的措施。2.6现在相当的不能行……只能等。
Jython与IronPython都达到稳定的运行状态时，还是后者的throughput比较大。不过许多时候脚本不太关注throughput，所以这算不算IronPython的优势也不好说。
IronRuby现在还在“早期”，还没进入“production ready”行列；JRuby则已经相当成熟了。这暂时还没法放在一个层次上来比。用生产要求来看现在的IronRuby的话那就是“不可用”。
微软到底是怎么看待对C extension支持的，我一直没看出所以然来。通过P/Invoke，在.NET上要做个合理的FFI出来应该比JVM那边要容易才对。但现在我们并没有看到DLR里有相关支持，却对COM有特别改进过的支持。对微软来说，对使用了C extension的现有库的支持看来是被忽视的内容。
在启动速度上，Jython可以得益于JVM初段的解释执行，从而减缓刚开始的编译压力。但各JVM的实现策略不同，这种解释执行是得不到保证的。Jython 2.5自身并没有采取任何特别方法来提高启动速度，但以后的版本肯定会有这方面的工作。现在这个版本更多的是“Jython的复活”版本。
IronPython运行在CLI上，而现在桌面上两种主要的CLI实现，CLR和Mono都是直接JIT而不解释的，这层上IronPython的启动速度本来就吃了点亏。现在IronPython通过DLR的解释器来做自适应编译，可以看作是弥补启动速度慢的措施。2.6现在相当的不能行……只能等。
Jython与IronPython都达到稳定的运行状态时，还是后者的throughput比较大。不过许多时候脚本不太关注throughput，所以这算不算IronPython的优势也不好说。
IronRuby现在还在“早期”，还没进入“production ready”行列；JRuby则已经相当成熟了。这暂时还没法放在一个层次上来比。用生产要求来看现在的IronRuby的话那就是“不可用”。
微软到底是怎么看待对C extension支持的，我一直没看出所以然来。通过P/Invoke，在.NET上要做个合理的FFI出来应该比JVM那边要容易才对。但现在我们并没有看到DLR里有相关支持，却对COM有特别改进过的支持。对微软来说，对使用了C extension的现有库的支持看来是被忽视的内容。
jython 2.5我希望作者能象他承诺的那样，能支持twisted。 其他倒没什么，没有ide也就算了。貌似最新的eclipse plguin也是 jython 2.1时候的东西了。
20 楼
mathgl
2009-05-19
ray_linn 写道
RednaxelaFX 写道
另一方面，Jython其实是受到Java/JVM的原始设计拖累而使得许多事情不好办。DVM正是解决这种“拖累”的实验项目。现在可以肯定的说，MethodHandle进入到JDK7了，而它与.NET一直有的delegate是如此的相似……呵呵，不看不知道，一看吓一跳。
当JVM变得更容易接受Java以外的其它语言时，JVM平台上的这些语言项目肯定会得到更好的发展的。
Java的创新思维似乎已死...总不能每次都看看.net就知道java下个版本会有什么，enum? foreach? auto-boxing? methodhanlder...
奇怪，为什么著名的perl竟然没有ironperl？ 当然因为Microsoft当activestate的后台老板。。。。也许不想砸他们的饭碗
Java从语言角度而言，我倒不希望再加入什么特别的语法糖果了，让更多的变革留给scala更好些。java优势在于
中规中矩，劣势可能也在于此。我倒是对jvm和gc的改善比较关注，hehe。
19 楼
RednaxelaFX
2009-05-19
sslaowan 写道
C#代码->编译->运行->发现错误->修改->再编译->...
IronPython->运行->发现错误->修改->运行->发现错误->修改
是这个区别吗？
IronPython->运行->发现错误->修改->运行->发现错误->修改
是这个区别吗？
不尽然……让我模拟一次这过程：
C#：
using System.Text.RegularExpressions;
class Test {
static void Main(string[] args) {
var regex = new Regex(@"^c");
var str = "abcdefg";
Console.WriteLine(regex.Match(str).Value); // 注意这行
}
}
这里写错了一点，因为我没有写using System;所以会找不到Console这个类。保存文件，编译，发现错误，修改，再编译。假设编译过了，但运行发现结果不对，判断是正则表达式写错了，那么再打开文件，编译，保存，编译，运行来看结果。
IronPython：
一上来先打开ipy，一个交互式解释器环境。
IronPython 2.6 Beta DEBUG (2.6.0.1) on .NET 2.0.50727.3082 Type "help", "copyright", "credits" or "license" for more information. >>> System.Text.RegularExpressions Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'System' is not defined >>>
在ipy里输入System.Text.RegularExpressions，解释器报错，说'System'未定义。怎么办呢？
不用关掉ipy，还在刚才的同一个环境里，输入import clr：
IronPython 2.6 Beta DEBUG (2.6.0.1) on .NET 2.0.50727.3082 Type "help", "copyright", "credits" or "license" for more information. >>> System.Text.RegularExpressions Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'System' is not defined >>> import clr >>> System.Text.RegularExpressions Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'System' is not defined >>>
再试那个命名空间发现还没引入进来。然后继续在ipy里输入import System：
IronPython 2.6 Beta DEBUG (2.6.0.1) on .NET 2.0.50727.3082 Type "help", "copyright", "credits" or "license" for more information. >>> System.Text.RegularExpressions Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'System' is not defined >>> import clr >>> System.Text.RegularExpressions Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'System' is not defined >>> import System >>> System.Text.RegularExpressions <module 'RegularExpressions' (CLS module from System, Version=2.0.0.0, Culture=n eutral, PublicKeyToken=b77a5c561934e089)> >>>
现在试那个命名空间得到了正确的结果，于是就进一步把代码写下去：
IronPython 2.6 Beta DEBUG (2.6.0.1) on .NET 2.0.50727.3082
Type "help", "copyright", "credits" or "license" for more information.
>>> System.Text.RegularExpressions
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'System' is not defined
>>> import clr
>>> System.Text.RegularExpressions
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'System' is not defined
>>> import System
>>> System.Text.RegularExpressions
<module 'RegularExpressions' (CLS module from System, Version=2.0.0.0, Culture=n
eutral, PublicKeyToken=b77a5c561934e089)>
>>> R = System.Text.RegularExpressions.Regex
>>> r = R('^c')
>>> s = 'abcde'
>>> r.Match(s)
<System.Text.RegularExpressions.Match object at 0x000000000000002B>
>>> m = _
>>> m
<System.Text.RegularExpressions.Match object at 0x000000000000002B>
>>> m.Value
''
>>> m.Success
False
>>>
现在看到正则表达式匹配失败了。仍然在同一个ipy里，继续试：
IronPython 2.6 Beta DEBUG (2.6.0.1) on .NET 2.0.50727.3082
Type "help", "copyright", "credits" or "license" for more information.
>>> System.Text.RegularExpressions
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'System' is not defined
>>> import clr
>>> System.Text.RegularExpressions
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'System' is not defined
>>> import System
>>> System.Text.RegularExpressions
<module 'RegularExpressions' (CLS module from System, Version=2.0.0.0, Culture=n
eutral, PublicKeyToken=b77a5c561934e089)>
>>> R = System.Text.RegularExpressions.Regex
>>> r = R('^c')
>>> s = 'abcde'
>>> r.Match(s)
<System.Text.RegularExpressions.Match object at 0x000000000000002B>
>>> m = _
>>> m
<System.Text.RegularExpressions.Match object at 0x000000000000002B>
>>> m.Value
''
>>> m.Success
False
>>> m = r.Match(s, 2, 3)
>>> m.Success
True
>>> m.Value
'c'
>>>
好！匹配成功了。
于是所谓REPL就是像这样的过程：read-eval-print loop。整个过程都不用离开交互式解释器环境，想到啥就写啥，马上就能看到对不对。然后把整个buffer复制出来整理一下，代码就写好了。
18 楼
sslaowan
2009-05-19
C#代码->编译->运行->发现错误->修改->再编译->...
IronPython->运行->发现错误->修改->运行->发现错误->修改
是这个区别吗？
IronPython->运行->发现错误->修改->运行->发现错误->修改
是这个区别吗？
17 楼
RednaxelaFX
2009-05-19
对了，刚才看到了一篇blog：Dismal performance with IronPython
这篇blog中作者提到他的代码在IronPython上运行甚至会比CPython慢到100x的级别。有兴趣的话可以看看。
Microbenchmark与实际代码果然还是甚有差距。
这篇blog中作者提到他的代码在IronPython上运行甚至会比CPython慢到100x的级别。有兴趣的话可以看看。
Microbenchmark与实际代码果然还是甚有差距。
16 楼
RednaxelaFX
2009-05-19
兼容性是Jython 2.5关注的重点，外加来自JRuby的FFI支持，对使用了C extension的Python库的支持应该比IronPython好。
在启动速度上，Jython可以得益于JVM初段的解释执行，从而减缓刚开始的编译压力。但各JVM的实现策略不同，这种解释执行是得不到保证的。Jython 2.5自身并没有采取任何特别方法来提高启动速度，但以后的版本肯定会有这方面的工作。现在这个版本更多的是“Jython的复活”版本。
IronPython运行在CLI上，而现在桌面上两种主要的CLI实现，CLR和Mono都是直接JIT而不解释的，这层上IronPython的启动速度本来就吃了点亏。现在IronPython通过DLR的解释器来做自适应编译，可以看作是弥补启动速度慢的措施。2.6现在相当的不能行……只能等。
Jython与IronPython都达到稳定的运行状态时，还是后者的throughput比较大。不过许多时候脚本不太关注throughput，所以这算不算IronPython的优势也不好说。
IronRuby现在还在“早期”，还没进入“production ready”行列；JRuby则已经相当成熟了。这暂时还没法放在一个层次上来比。用生产要求来看现在的IronRuby的话那就是“不可用”。
微软到底是怎么看待对C extension支持的，我一直没看出所以然来。通过P/Invoke，在.NET上要做个合理的FFI出来应该比JVM那边要容易才对。但现在我们并没有看到DLR里有相关支持，却对COM有特别改进过的支持。对微软来说，对使用了C extension的现有库的支持看来是被忽视的内容。
在启动速度上，Jython可以得益于JVM初段的解释执行，从而减缓刚开始的编译压力。但各JVM的实现策略不同，这种解释执行是得不到保证的。Jython 2.5自身并没有采取任何特别方法来提高启动速度，但以后的版本肯定会有这方面的工作。现在这个版本更多的是“Jython的复活”版本。
IronPython运行在CLI上，而现在桌面上两种主要的CLI实现，CLR和Mono都是直接JIT而不解释的，这层上IronPython的启动速度本来就吃了点亏。现在IronPython通过DLR的解释器来做自适应编译，可以看作是弥补启动速度慢的措施。2.6现在相当的不能行……只能等。
Jython与IronPython都达到稳定的运行状态时，还是后者的throughput比较大。不过许多时候脚本不太关注throughput，所以这算不算IronPython的优势也不好说。
IronRuby现在还在“早期”，还没进入“production ready”行列；JRuby则已经相当成熟了。这暂时还没法放在一个层次上来比。用生产要求来看现在的IronRuby的话那就是“不可用”。
微软到底是怎么看待对C extension支持的，我一直没看出所以然来。通过P/Invoke，在.NET上要做个合理的FFI出来应该比JVM那边要容易才对。但现在我们并没有看到DLR里有相关支持，却对COM有特别改进过的支持。对微软来说，对使用了C extension的现有库的支持看来是被忽视的内容。
15 楼
jjx
2009-05-19
实际用起来，我倒是觉的jython源代码的兼容程度更高，导入和启动都比ironpython 快
ironpython只要启用site.py后，启动就会比较慢，导入模块，也是比较慢的，今天编译2.6感觉有些许改善，但还是不如人意。 2.6现在的代码居然将collections改成_collections了，frame的支持倒是有了，但__slot__的兼容性还是存在，跑sqlalchemy时，还是有许多的错误。 jython表现就好多了
ironruby 现在也能跑rails，但实际感觉很慢，错误也比较多，基本没有可用性
总体来说，感觉ms对兼容这些存在应用兴趣不大，只是将其作为演示的考虑,花点时间hack一下，同jruby,jython的不遗余力保持兼容的做法还是有很大不同的
ironpython只要启用site.py后，启动就会比较慢，导入模块，也是比较慢的，今天编译2.6感觉有些许改善，但还是不如人意。 2.6现在的代码居然将collections改成_collections了，frame的支持倒是有了，但__slot__的兼容性还是存在，跑sqlalchemy时，还是有许多的错误。 jython表现就好多了
ironruby 现在也能跑rails，但实际感觉很慢，错误也比较多，基本没有可用性
总体来说，感觉ms对兼容这些存在应用兴趣不大，只是将其作为演示的考虑,花点时间hack一下，同jruby,jython的不遗余力保持兼容的做法还是有很大不同的
14 楼
RednaxelaFX
2009-05-18
微软的实验田有很多在MSR和与各大学合作的项目里，sigh。
C# 4的spec还没定稿，VS10 beta前都没指望看到草稿。但传闻这周就有希望看到beta了，一起等吧～
CLR 4...这玩儿会有spec么？CLR 2之后微软都没更新过ECMA-335，好长时间了。当然这期间CLR的表面没多少变化也是事实。CLR 4不知道会不会是更新ECMA-335的契机呢。
DLR的spec倒是公开了草稿，在这里：http://dlr.codeplex.com/Wiki/View.aspx?title=Docs%20and%20specs
C# 4的spec还没定稿，VS10 beta前都没指望看到草稿。但传闻这周就有希望看到beta了，一起等吧～
CLR 4...这玩儿会有spec么？CLR 2之后微软都没更新过ECMA-335，好长时间了。当然这期间CLR的表面没多少变化也是事实。CLR 4不知道会不会是更新ECMA-335的契机呢。
DLR的spec倒是公开了草稿，在这里：http://dlr.codeplex.com/Wiki/View.aspx?title=Docs%20and%20specs
13 楼
ray_linn
2009-05-18
RednaxelaFX 写道
ray_linn 写道
实际上Java 7里只有Lightweight bytecode loading，其他priority放的都是med，未来会不会出现在JDK还不得而知。
那个叫JDK7而不是Java7。我承认我是在咬文嚼字，不过Sun至今并没有提交Java7的JSR，所以……
DVM就是块实验田而已，里面的idea不保证会得到实现，实现的东西不保证会进入未来的JDK。但至少还是有这么块实验田，让人多少能感受到希望（=v=
Microsoft的试验田不知道在哪里...我转了好几圈想找C# 4.0的Spec和CLR 4.0的Spec.
12 楼
RednaxelaFX
2009-05-18
ray_linn 写道
实际上Java 7里只有Lightweight bytecode loading，其他priority放的都是med，未来会不会出现在JDK还不得而知。
那个叫JDK7而不是Java7。我承认我是在咬文嚼字，不过Sun至今并没有提交Java7的JSR，所以……
DVM就是块实验田而已，里面的idea不保证会得到实现，实现的东西不保证会进入未来的JDK。但至少还是有这么块实验田，让人多少能感受到希望（=v=
ray_linn 写道
http://dynalang.sourceforge.net/ 这个有点意思。
这就是JVM上的MOP（meta-object protocol），跟DLR的MOP对应。
一直在整理一份资料，现有JVM+invokedynamic相关+dynalang（+ASM？） = 现有CLI+DLR。需要整理的头绪很多，一时半会儿是出不来了 T T
11 楼
ray_linn
2009-05-18
RednaxelaFX 写道
ray_linn 写道
Java的创新思维似乎已死...总不能每次都看看.net就知道java下个版本会有什么，enum? foreach? auto-boxing? methodhanlder...
如果说integration is innovation的话，那Java的innovation还没死。点子的来源也不是.NET一个，而是众多主流语言实现。
例如DVM里还有immediate wrappers types，这就是LISP、Ruby等都有的fixnum，其实就是tagged pointer的一种应用。这玩儿在CLR里还没有，也有很多人怨念着呢。
DVM里的runtime support for multimethods，也就是方法的多重分发，也是CLR还不支持的东西。VS2010 CTP里的C# 4通过dynamic特性支持了multimethod，但后来又决定缩回去了，采用更静态的绑定方式。
Continuation支持也是……这个我很是怨念，CLR没有内建的continuation支持。
当然，DVM里可以算得上借鉴.NET的东西也不少：MethodHandle（delegate）、invokedynamic（calli）、AnonymousClass（DynamicMethod）、TailCall（.tail），之类的。现在语言发展的大趋势就是互相借鉴，这是好事～
大部分还是proto,priority放的都是med，未来会不会出现在JDK还不得而知。
Runtime support for closures 这个可能根本就不会实现吧？
10 楼
ray_linn
2009-05-18
http://dynalang.sourceforge.net/ 这个有点意思。
9 楼
RednaxelaFX
2009-05-18
ray_linn 写道
奇怪，为什么著名的perl竟然没有ironperl？ 当然因为Microsoft当activestate的后台老板。。。。也许不想砸他们的饭碗
有人很有爱的在.NET上实现了一个叫Tycho的东东，基本上是一个Perl 6的实现。
Iron-*嘛，没足够的资源所以只能把关注点集中在最热的几个上面了。结果就是IronPython、IronRuby、VBx（已死）、Managed JScript（生死未卜）。
8 楼
RednaxelaFX
2009-05-18
ray_linn 写道
Java的创新思维似乎已死...总不能每次都看看.net就知道java下个版本会有什么，enum? foreach? auto-boxing? methodhanlder...
如果说integration is innovation的话，那Java的innovation还没死。点子的来源也不是.NET一个，而是众多主流语言实现。
例如DVM里还有immediate wrappers types，这就是LISP、Ruby等都有的fixnum，其实就是tagged pointer的一种应用。这玩儿在CLR里还没有，也有很多人怨念着呢。
DVM里的runtime support for multimethods，也就是方法的多重分发，也是CLR还不支持的东西。VS2010 CTP里的C# 4通过dynamic特性支持了multimethod，但后来又决定缩回去了，采用更静态的绑定方式。
Continuation支持也是……这个我很是怨念，CLR没有内建的continuation支持。
当然，DVM里可以算得上借鉴.NET的东西也不少：MethodHandle（delegate）、invokedynamic（calli）、AnonymousClass（DynamicMethod）、TailCall（.tail），之类的。现在语言发展的大趋势就是互相借鉴，这是好事～
7 楼
ray_linn
2009-05-18
RednaxelaFX 写道
另一方面，Jython其实是受到Java/JVM的原始设计拖累而使得许多事情不好办。DVM正是解决这种“拖累”的实验项目。现在可以肯定的说，MethodHandle进入到JDK7了，而它与.NET一直有的delegate是如此的相似……呵呵，不看不知道，一看吓一跳。
当JVM变得更容易接受Java以外的其它语言时，JVM平台上的这些语言项目肯定会得到更好的发展的。
Java的创新思维似乎已死...总不能每次都看看.net就知道java下个版本会有什么，enum? foreach? auto-boxing? methodhanlder...
奇怪，为什么著名的perl竟然没有ironperl？ 当然因为Microsoft当activestate的后台老板。。。。也许不想砸他们的饭碗
6 楼
RednaxelaFX
2009-05-17
cajon 写道
RednaxelaFX 写道
最近Jython的项目维护者Frank Wierzbicki在Lang.NET 2009上介绍了项目状况。现在Jython还是采用只编译，不解释的执行方式，总是把Python源码编译为JVM字节码后才执行。这种方式影响到启动速度，近期IronPython已经转用解释到编译的渐变过程；Jython还在等DVM的成果出来……
呵呵，这就是一家公司做的好处，决策的过程要远好于开源社区。唯一的问题，就是公司的战略方向是否正确了。至少，看起来微软的战略方向还是比较偏向于动态语言的。
Da Vinci Machine/JDK7（注意我不是说Java7）也是在“一家公司”，也就是Sun的控制下。
我觉得Jython在许多方面进度落后是受到关注它并且向其贡献代码的人不够多，长时间只有一两个人在维护，现在还活着就已经不简单了。这是Colin老大说到的一方面。但我们可以看到，就Jython现在还活着的部分看，其前端ANTLR、后端ASM、底下的执行引擎JVM、与外部交互用的JNA，都是开源的（JVM至少“有开源的选择”）。没有开源社区的间接支持，Jython现在肯定已经挂了。
另一方面，Jython其实是受到Java/JVM的原始设计拖累而使得许多事情不好办。DVM正是解决这种“拖累”的实验项目。现在可以肯定的说，MethodHandle进入到JDK7了，而它与.NET一直有的delegate是如此的相似……呵呵，不看不知道，一看吓一跳。
当JVM变得更容易接受Java以外的其它语言时，JVM平台上的这些语言项目肯定会得到更好的发展的。
5 楼
cajon
2009-05-17
RednaxelaFX 写道
最近Jython的项目维护者Frank Wierzbicki在Lang.NET 2009上介绍了项目状况。现在Jython还是采用只编译，不解释的执行方式，总是把Python源码编译为JVM字节码后才执行。这种方式影响到启动速度，近期IronPython已经转用解释到编译的渐变过程；Jython还在等DVM的成果出来……
呵呵，这就是一家公司做的好处，决策的过程要远好于开源社区。唯一的问题，就是公司的战略方向是否正确了。至少，看起来微软的战略方向还是比较偏向于动态语言的。
4 楼
ray_linn
2009-05-16
说到linq，今天在想如何从交错数组里选出包含输入数组的那一行，同样心烦
3 楼
RednaxelaFX
2009-05-16
ray_linn 写道
用 mono shell如何，可以用来跑linq
需要LINQ的时候用Mono的CSharpRepl确实美妙，外加还可以绘图啊什么的，Miguel真是高啊～
不过单纯是想查看类库的API，确认其行为时，还是Python（和Ruby）方便些。这些语言的语法，特别是做反射的时候很方便。.GetType().GetMethods()还是嫌麻烦了 =v=
mathgl 写道
这和我用jython，差不多，大多数时候就是用那个 dir的
嗯嗯，dir美啊 T T
最近Jython的项目维护者Frank Wierzbicki在Lang.NET 2009上介绍了项目状况。现在Jython还是采用只编译，不解释的执行方式，总是把Python源码编译为JVM字节码后才执行。这种方式影响到启动速度，近期IronPython已经转用解释到编译的渐变过程；Jython还在等DVM的成果出来……
2 楼
mathgl
2009-05-16
这和我用jython，差不多，大多数时候就是用那个 dir的
发表评论
-
对象的重量
2011-08-21 17:15 0http://domino.research.ibm.com/ ... -
IronRuby 1.1系的自适应执行（解释/编译的混合模式）
2010-10-29 14:12 0IronRuby自身的compiler部分基本上还是保持不变的 ... -
Expression Tree中的Constant被编译后放到哪里去了？
2010-02-28 16:21 0Expression.Constant()可以放任意对象进去作 ... -
拿ETv2来生成方法体的两种阳春办法
2009-09-22 06:03 0System.Type System.Reflection.E ... -
C#的语言结构到Expression Tree v2的映射
2009-05-21 03:11 0在.NET Framework 4 Beta 1中，Expre ... -
.NET Framework 4.0 Beta 1里的Expression Tree一例
2009-05-20 10:23 2884既然装上了Visual Studio 20 ... -
自己关于VM的帖的目录
2009-04-07 14:02 68860JavaEye的blog系统只允许把帖放到单一类别下，而不能用 ... -
MIX09上关于DLR解释器消息的一段听记（3月26更新IronPython 2.6A1消息）
2009-03-23 21:09 1806John Lam在MIX 09上做了一个关于动态语言与Silv ... -
答复: C# 4 DLR & Java 7 Invokedynamic
2009-03-22 17:12 2975原帖地址：C# 4 DLR & Java 7 Invo ... -
通过get或set方法的MethodInfo获得相应的PropertyInfo的方式
2009-02-01 22:41 3506在IronPython 46307的MemberExpress ... -
同一个ParameterExpression被用在不同嵌套层次的lambda里会怎样？
2009-01-16 00:22 2563今天写代码的时候不小心写错了几个地方，把同一个Paramete ... -
CodePlex上放出DLR v0.9 beta
2008-11-27 14:34 1946之前提到过DLR会在CodePlex上拥有自己独立的项目页面， ... -
IronRuby (r170)中respond_to?的实现
2008-11-13 23:29 0IronRuby.Libraries/Builtins/Ker ... -
DLR中的binder的演变
2008-11-11 23:29 0从模糊的“标准消息”转变为明确完整的MetaObject Pr ... -
DLR即将在Codelex开设独立的站点
2008-10-29 23:01 1411DLR官网：Dynamic Language Runtime ... -
IronPython放出RC1
2008-10-23 09:59 1794下载链接：http://www.codep ... -
新的DLR tree改变了Visitor的设计
2008-10-09 00:35 1586之前的一帖提到过访问DLR tree所使用的visitor的实 ... -
对比DLR
2008-10-08 04:32 0Managed JScript: // // AST: E ... -
目前DLR执行一棵DLR tree的过程（针对10月3日的ChangeSet 41087）
2008-10-07 01:46 1741先在Microsoft.Scripting.Actions.C ... -
LINQ与DLR的Expression tree（4）：创建静态类型的LINQ表达式树节点
2008-09-27 00:18 9315（Disclaimer：如果需要转载请先与我联系；文中图片请不 ...
相关推荐
iron-speed-designer-10 微软.NET多层网络应用快速开发工具，无论是行业应用还是跨行业应用，Iron Speed Designer都可以将你从繁重的编码工作中解脱出来，并缩短开发周期。
.net-buildpack 用于运行.NET应用程序的Cloud ... 在.NET 4.5 / IronFoundry.NET（Windows 2012堆栈）下运行的控制台应用程序 文献资料 运行时间 （功能性） CLR（即将推出） 货柜 构架 卷入 我们正在积极寻找
Atom-ironpython-stubs.zip,通用ironpython/.net库的自动完成存根铁蟒树桩,atom是一个用web技术构建的开源文本编辑器。
iron-icons, 一组用于铁 icon的图标 演示和API文档 <图标>iron-icons 是一个实用工具导入，包含 iron-icon 元素。iron-iconset-svg 元素的定义，以及缺省 icon 集合的导入。iron-icons 目录还包括可以
Iron-Clad Java presents the processes required to build robust and secure applications from the start and explains how to eliminate existing security bugs. Best practices for authentication, access ...
The greatest challenge in product security today is the fact that security quality is difficult for consumers to evaluate. A product with little security design consideration and a weak security ...
资源分类：Python库 所属语言：Python 资源全名：iron-worker-utils-0.1.1.tar.gz 资源来源：官方 安装方法：https://lanzao.blog.csdn.net/article/details/101784059
iron-redux-master.rar
主要介绍了使用IronPython把Python脚本集成到.NET程序中的教程,现在刚刚被微软开源的.NET重新成为业界热点、本文介绍了使Python和.NET交互的IronPython，需要的朋友可以参考下
开源项目-iron-io-functions.zip,IronFunctions: language agnostic open-source alternative to AWS Lambda written in Go
iron-redux-使您的redux代码完全类型安全并且非常整洁！ 产品特点 iron-redux提供帮助功能，以创建类型安全的redux类型，redux操作和redux状态，而无需依靠打字稿的类型推断能力进行任何额外的类型定义。 尝试使用...
Iron-OCR-Image-to-Text-in-CSharp-master_c#验证码识别_ocrc#中文_OCR_IronOCR_csharp_源码.zip
python库。 资源全名：iron-core-1.1.1.tar.gz
IronPython-2.7.7-win.zip IronPython-2.7.7-win.zip IronPython-2.7.7-win.zip
<iron>显示相对于另一个元素定位的固定位置容器内的内容。 请参阅：， 。 用法 安装 npm install --save @polymer/iron-dropdown 在HTML文件中 < html > < head > < script type =" module " >...
该元素负责浏览器在键盘事件方面的差异，并使用一种表达性语法来过滤按键。 请参阅：， 。用法安装npm install --save @polymer/iron-a11y-keys-behavior在聚合物3元素中import { PolymerElement , ...
Iron - 一个快速和易用的 NoSQL 数据存储框架包含RxJava支持
铁输入> <iron>使用Polymer.IronValidatorBehavior向<input>添加双向绑定和自定义验证器。 请参阅：， 。用法安装npm install --save @polymer/iron-input在一个html文件中< html > < head > <...
铁基添加物对褐煤热解过程中硫变迁的影响，田继林，付春慧，本实验以一种含较高有机硫的中国褐煤为研究对象，使用固定床石英反应器对其进行程序升温热解实验，通过机械混合法将铁（前驱体分
iron-grid, 一种用于聚合物的反应式网格 #Demo Plunker<iron-grid> <div class="xs12 s9 m6 l3 xl3"></div> <div class="xs12 s9 m6 l3