- 浏览: 3053071 次
- 性别:
- 来自: 海外
文章分类
- 全部博客 (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 2934既然装上了Visual Studio 20 ... -
自己关于VM的帖的目录
2009-04-07 14:02 69653JavaEye的blog系统只允许把帖放到单一类别下,而不能用 ... -
MIX09上关于DLR解释器消息的一段听记(3月26更新IronPython 2.6A1消息)
2009-03-23 21:09 1864John Lam在MIX 09上做了一个关于动态语言与Silv ... -
答复: C# 4 DLR & Java 7 Invokedynamic
2009-03-22 17:12 3033原帖地址:C# 4 DLR & Java 7 Invo ... -
通过get或set方法的MethodInfo获得相应的PropertyInfo的方式
2009-02-01 22:41 3564在IronPython 46307的MemberExpress ... -
同一个ParameterExpression被用在不同嵌套层次的lambda里会怎样?
2009-01-16 00:22 2613今天写代码的时候不小心写错了几个地方,把同一个Paramete ... -
CodePlex上放出DLR v0.9 beta
2008-11-27 14:34 2028之前提到过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 1468DLR官网:Dynamic Language Runtime ... -
IronPython放出RC1
2008-10-23 09:59 1858下载链接:http://www.codep ... -
新的DLR tree改变了Visitor的设计
2008-10-09 00:35 1634之前的一帖提到过访问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 1816先在Microsoft.Scripting.Actions.C ... -
LINQ与DLR的Expression tree(4):创建静态类型的LINQ表达式树节点
2008-09-27 00:18 9389(Disclaimer:如果需要转载请先与我联系;文中图片请不 ...
相关推荐
- **第15章:从其他.NET语言使用IronPython** 讨论如何在其他.NET语言中调用IronPython代码,实现语言间的互操作性。 - **第16章:使用C#扩展IronPython** 展示如何使用C#语言为IronPython添加新的功能或性能...
对于希望利用IronPython来提升开发效率、探索新的编程方式的开发者来说,《Pro IronPython》是一本不可多得的指南书籍。 #### 技术细节: - **页数**:全书共312页。 - **内容覆盖范围**:书中涵盖了IronPython的...
- 支持多种编程语言:如Visual Basic, Visual C#, IronRuby, IronPython等。 - 支持多种通信协议:如JSON、WebService、WCF等。 - 提供强大的多媒体支持。 - **开发环境搭建**: - 安装.NET Framework及...
- **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`,按回车键,即可...
- **Silverlight 2 Beta 1** 的发布带来了许多新特性,比如对多种编程语言的支持(包括Visual Basic、Visual C#、IronRuby和IronPython),以及对JSON、WebService、WCF和Sockets的支持。 #### 二、搭建开发环境与...
- **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进一步...