JRuby 1.0丰收在望

JRuby团队正全力准备JRuby 1.0的发布,性能相比0.9.8提升两倍,并完全支持Rails的ActiveRecord,使得MySQL上的Rails应用得以顺利运行。

自从约一个月以前JRuby 0.9.8发布以后,与JRuby进展的相关消息似乎变得消声匿迹了。但是,来自JRuby阵营的最新消息让我们的疑团烟消云散:整个JRuby团队正在快马加鞭,希望赶在JavaOne开始之前发布JRuby 1.0

\

在他的最新博客文章中,Charles Nutter向大家展示了第一个产品级发布将带来的一些令人振奋的改进。其中,性能的提升非常引人瞩目:

\\
……目前主干代码的性能比0.9.8版的性能提升了两倍(……)。此外,编译器支持的语法构造几乎达到0.9.8版的两倍,且每天它都朝着更快更稳定的方向迈进。即便仍属解释执行,事实上有不少benchmark显示它比MRI(Ruby的C语言版本)运行得还要快。
\

另外一条重磅消息是,目前Rails的ActiveRecord已经完全被JRuby支持。剩下的最后一些不能通过的测试最终也已得到修复,所有单元测试都大亮绿灯。现在JRuby上已经能够安全运行使用MySQL的Rails应用程序。

\

InfoQ对JRuby团队成员Ola Bini进行采访,详细了解了最新ActiveRecord里程碑的相关信息:

\

JRuby团队从什么时候开始着手对ActiveRecord的支持工作?

\
老实说我们并没有那么做。除了在测试中寻找bug以外,对ActiveRecord本身我们什么都没动。自打去年六月,我们开始入手ActiveRecord-JDBC项目(下文中简称AR-JDBC)。

这个项目是一个仅在JRuby中可用的ActiveRecord适配器,使ActiveRecord可以与JDBC(标准的Java数据库连接框架)一起工作。这个项目是非常有意义的,因为JRuby不可能使用Rails使用的常规驱动程序。因此我们已经让AR-JDBC正常工作一段时间了。在发布0.9.8时我们就打算宣布对Rails的支持,不过当时还是存在一些不能通过的Rails单元测试;实际上这些问题绝大部分出现在ActiveRecord(在1100个测试中大约出现50-60个错误和故障)。于是上周我决定首先为MySQL解决这些问题,随后AR-JDBC和JRuby就得到几处修正。正如原来声明中所说,我们非常高兴地宣布MySQL已经得到完全支持。

\

最难以实现的功能有哪些?

\
我认为最棘手的事情有两样:首先就是ActiveRecord测试。在很多地方这些测试是非常不错的,但是还有一些测试依赖于hash排序和另外一些更稀奇古怪的东西。这就搞得我们很难判断那到底是一个真正的故障或者只是一个实现得比较诡异的测试。其次,ActiveRecord对来自数据库的数据、quoting和其它方面进行了大量处理。要搞定这些并不是一件容易的事情,对于日期和时间信息尤其如此。但是,这些测试对于问题的修正非常有用。
\

JRuby接下去的开发工作会是什么?

\
目前我们努力的方向是性能和正确性。希望能在五月的某天发布1.0,到那是我们的目标就是更高的速度和正确性了。=)我们所做的是修复所有发现的bug,尝试确定Java整合最终将变成什么样子,此外就是Java字节码编译器了。所以说,五月份的时候,JRuby就是一股不容小觑的力量了。
\

提一个八卦问题:你最近刚刚接受了ThoughtWorks的工作机会。关于你在ThoughtWorks里与JRuby相关的项目,你能不能向大家透露一些口风?

\
啊,这还不能说。我要到6月4日才正式入职,在那之前我只是非正式地给几个项目帮忙,但大部分还不能公之于众。我现在可以说的是,在我的ThoughtWorks工作正式开始以后,我将着手于JRuby和Ruby的一些很不错的事情上。
「LLM那些事」系列第 4 篇《上下文窗口的边界》,文章连接:https://blog.csdn.net/houwenjin/article/details/163999753。 演示什么:在「预测」Sheet 的黄色格子里输入一句话(默认「来泡一杯」),四个「模型」——分别只统计最后 1 / 2 / 3 / 4 个字的 n-gram 查表——同时预测下一个字。同一个输入,看的上下文越长,候选越少、预测越确定: ┌────────────────┬──────────┬───────────────┬──────┐ │ 只看最后几个字 │ 用的前缀 │ 候选下一字数 │ 预测 │ ├────────────────┼──────────┼───────────────┼──────┤ │ 1 个 │ 杯 │ 3(茶/子/水) │ 模糊 │ ├────────────────┼──────────┼───────────────┼──────┤ │ 2 个 │ 一杯 │ 2(茶/水) │ 收窄 │ ├────────────────┼──────────┼───────────────┼──────┤ │ 3 个 │ 泡一杯 │ 1(茶) │ 确定 │ ├────────────────┼──────────┼───────────────┼──────┤ │ 4 个 │ 来泡一杯 │ 1(茶) │ 确定 │ └────────────────┴──────────┴───────────────┴──────┘
源码下载地址: https://pan.quark.cn/s/a4b39357ea24 笔记本的散热风扇管理 ---------------------------------------- 09 November 2006. 对于版本20061109的变更概述如下: 1) ACPI CA核心子系统:在源操作数是一个操作区域的场景下,对负载ASL操作符进行了优化。仅需映射操作区域内存,而不是执行逐字节读取。 (区域必须为SystemMemory类型,见下文。)修正了源操作数为区域字段的负载ASL操作符问题。也允许缓冲区对象作为源操作数。 BZ 480 解决了负载ASL操作符允许源操作数为任意类型操作区域的问题。现被限制为仅SystemMemory类型的区域,符合ACPI规范。 BZ 481 对新表管理器代码进行了额外的清理和优化。AcpiEnable将在所有必需的ACPI表未加载时失败(FADT, FACS, DSDT)。 BZ 477 在acobject.h中添加了#pragma pack(8/4),以确保此头文件中的结构始终编译为对齐。ACPI_OPERAND_OBJECT已被手动优化为对齐,并在字节打包时无法工作。示例代码和数据大小:这些是Microsoft Visual C++ 6.0 32位编译器生成的、与操作系统无关的acpica.lib的大小。调试版本的代码包含调试输出跟踪机制,具有更大的代码和数据大小。上一个版本:非调试版本:78.1K代码,17.1K数据,95.2K总计 调试版本:155.4K代码,63.1K数据,218.5K总计 当前版本:非调试版本:77.9K代码,17.0K数据,94.9K总计 调试版本:155.2K代码,63.1K数据,...
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值