RednaxelaFX
- 浏览: 3039565 次
- 性别:
- 来自: 海外
-
文章分类
- 全部博客 (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 2916既然装上了Visual Studio 20 ... -
自己关于VM的帖的目录
2009-04-07 14:02 69328JavaEye的blog系统只允许把帖放到单一类别下，而不能用 ... -
MIX09上关于DLR解释器消息的一段听记（3月26更新IronPython 2.6A1消息）
2009-03-23 21:09 1846John Lam在MIX 09上做了一个关于动态语言与Silv ... -
答复: C# 4 DLR & Java 7 Invokedynamic
2009-03-22 17:12 3013原帖地址：C# 4 DLR & Java 7 Invo ... -
通过get或set方法的MethodInfo获得相应的PropertyInfo的方式
2009-02-01 22:41 3536在IronPython 46307的MemberExpress ... -
同一个ParameterExpression被用在不同嵌套层次的lambda里会怎样？
2009-01-16 00:22 2595今天写代码的时候不小心写错了几个地方，把同一个Paramete ... -
CodePlex上放出DLR v0.9 beta
2008-11-27 14:34 1996之前提到过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 1441DLR官网：Dynamic Language Runtime ... -
IronPython放出RC1
2008-10-23 09:59 1839下载链接：http://www.codep ... -
新的DLR tree改变了Visitor的设计
2008-10-09 00:35 1616之前的一帖提到过访问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 1794先在Microsoft.Scripting.Actions.C ... -
LINQ与DLR的Expression tree（4）：创建静态类型的LINQ表达式树节点
2008-09-27 00:18 9361（Disclaimer：如果需要转载请先与我联系；文中图片请不 ...
相关推荐
- **第15章：从其他.NET语言使用IronPython** 讨论如何在其他.NET语言中调用IronPython代码，实现语言间的互操作性。 - **第16章：使用C#扩展IronPython** 展示如何使用C#语言为IronPython添加新的功能或性能...
对于希望利用IronPython来提升开发效率、探索新的编程方式的开发者来说，《Pro IronPython》是一本不可多得的指南书籍。 #### 技术细节： - **页数**：全书共312页。 - **内容覆盖范围**：书中涵盖了IronPython的...
- **IronPython**：探索IronPython在.NET环境中的集成方式及其实用价值。 ##### 6\. Ajax技术的应用 - **基本概念**：介绍Ajax技术的原理及其在Web开发中的作用。 - **实战案例**：通过具体实例演示如何利用Ajax...
- **动态类型**：C# 4.0引入了`dynamic`关键字，允许在运行时进行类型绑定，极大地简化了与非.NET库如JavaScript或IronPython的交互。 - **多目标参数**：C# 4.0支持可选参数和命名参数，使函数调用更加灵活，减少...
### Python在物联网中的应用与发展综述 #### 一、物联网概览 ...无论是对于初学者还是专业开发者来说，Python都是一个值得深入探索的技术方向。随着物联网技术的不断创新和发展，Python也将迎来更多的发展机遇。
- **IronPython**: 运行于 .NET 平台的 Python 解释器。 - **PyPy**: 基于 JIT 技术的 Python 解释器，提高了执行效率。 #### 6. 位和字节的关系？ - **位**: 计算机中最小的数据单位，只有 0 或 1 两种状态。 - *...
- **IronPython**：运行在.NET平台上的Python解释器。 **安装Python解析器**： 1. **下载**：访问Python官方网站 (https://www.python.org/) 下载最新稳定版本（如Python 3.7）的安装包。 2. **安装**：选择自定义...
- **IronPython**：使Python能在.NET平台上运行。 #### 第一个Python程序 1. **打开终端**：可以通过快捷键`Win+R`打开命令提示符或终端。 2. **启动Python**：在命令行中输入`python`或`python3`，按回车键，即可...
- **IronPython**：在.NET平台上运行的Python解释器。 #### 6. 位和字节的关系？ - **位**：计算机中最小的数据单位，只能表示0或1。 - **字节**：由8位组成的基本存储单位。 #### 7. b、B、KB、MB、GB的关系？ ...
2. **全栈开发**：Meteor.js允许开发者使用同一种语言（JavaScript）进行前后端开发，降低了开发复杂性，提高了开发效率。 3. **Blaze模板引擎**：Meteor内置Blaze模板引擎，可以方便地实现视图层与数据层的绑定，...
1. **Emgu CV**: Emgu CV是OpenCV的.NET版本，它允许.NET开发者使用C#、VB.NET或IronPython等语言来编写计算机视觉程序。Emgu CV提供了一个全面的API，包括图像处理、特征检测、模式识别等功能。 2. **人脸识别**: ...
IronPython 1.0 是一个重要的开源项目，它将Python编程语言与.NET Framework相结合，让开发者可以在.NET平台上使用Python进行开发。这个版本的发布对于Python社区和.NET开发者来说都具有里程碑式的意义，因为它打破...
而对于需要与Java或.NET生态紧密集成的应用，则可以考虑使用Jython或IronPython。无论选择哪种解释器，理解它们的工作原理都将帮助开发者更好地利用Python的强大功能。希望本文能够为读者提供有益的信息，并激发更多...
标签中的"IronPython"指的是这个.NET版本的Python实现，"Python"是脚本语言，"VS2010"表明这是在Visual Studio 2010环境下使用的工具。 压缩包内的文件可能包括了IronPython的库文件、文档、示例代码以及其他必要的...
IronPython是一种基于Python编程语言的开源实现，它允许开发者在.NET Framework上运行Python代码，并能够无缝集成到.NET环境中。这个“IronPython简单程序源码”很可能是为了展示如何在Visual Studio 2008中使用Iron...
这使得.NET开发者能轻松上手，同时也支持动态语言运行时（DLR），便于使用IronPython和IronRuby等语言。 3. **数据绑定和MVVM模式**：数据绑定是Silverlight中的关键特性，它简化了UI与后台数据的交互。Model-View-...
动态语言运行时（Dynamic Language Runtime，DLR）是.NET框架的一个重要组件，它支持动态语言如IronPython和IronRuby在.NET平台上运行。通过学习这一部分，读者将了解如何利用DLR与现有C#代码进行交互，并探索动态...
2. Dynamic Language Runtime (DLR)：DLR是.NET Framework 4.0对动态编程语言的支持，如IronPython和IronRuby等，使得动态语言在.NET平台上运行更加顺畅。 3. Entity Framework：这个版本的Entity Framework进一步...