注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

Chun Tian (binghe)

超越自我,洞察宇宙

 
 
 

日志

 
 

如释重负  

2012-07-22 00:57:24|  分类: Lisp |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
如释重负 - 冰河 - Chun Tian (binghe)

2009 年 3 月,当我在博客上发表《Lisp 宣言》时,我刚从无缘参加 2009 年国际 Lisp 会议 (ILC '09) 的阴影里走出来没几天(前雇主不肯为我出访问 MIT 的路费),转身以业余顾问的形式受雇于 Versata 公司,通过网络参与该公司两年前收购的 Lisp 软件 Gensym G2 的后续开发工作——其中最重要的任务的就是探索其支持多核处理器的可能性。

这项工作可以说极端困难,首先整个软件由 94 万行 Common Lisp 代码写成——这仅仅是核心部分,然后通过一个 10 万行代码规模的私有 Lisp->C 转译器 (Chestnut Lisp->C Translator) 转译成 300 多万行 ANSI C 代码,然后再与另外 20 万行手写的 C 代码联合编译出最终的软件——一个 30MB 的独立可执行程序,单线程,不依赖任何第三方动态库。其软件史上支持几乎所有的 CPU 类型和操作系统。

由于最初的开发环境极其恶劣,加上对代码缺乏理解,我在前面三年里虽然做了大量准备工作,但始终无法在程序里看到真正的并发,预计的完成时间一拖再拖,拖死了好几任产品经理。当然,我一直身兼数职无法专注这个项目也是重要原因,2010 年底因为上游人事变动曾一度完全中断了相关工作,直到 2011 年 8 月在新公司重新开始把之前没完成的多线程项目捡起来。皇天不负有心人,到前天的时候终于取得了本质上的进展,在软件里首次得到了并发执行的 2 个工作线程,而且代码本身并不依赖于线程的数量。于是在三年零四个月过后,我可以高兴地说这个项目终于基本完成了。接下来就是在已完成的框架下继续优化代码和修补问题,最终的发布指日可待。从此没人可以撼动我在该领域的地位了。

我一直以来的心愿就是完成这个项目以后写论文总结过去的所有相关工作然后投给国际 Lisp 会议:一方面提高个人声望,另一方面向 Lisp 界和 Gensym 公司过去的雇员们宣布 G2 和 Chestnut 都仍然活着并且得到了良好的维护。如今这个计划终于可以付诸实施了,准备下月就开始动笔写然后赶在 ILC 2012 截止日期前投稿。三年过去,我的英语写作水平已经有所提高了,虽然时间已经很紧,但应该还是可以顺利写完并发表的,这次我很有信心。为了应对 10 月份极有可能去日本参加 ILC 2012,我要加强语言学习,近期开始把日语捡起来。本次会议的主席 KURODA Hisao 来自日本的 Mathematical Systems Inc. 公司——他们在 2009 年的时候某个项目里用了我的 SNMP 实现代码,多少欠我一个情。



去年刚进入新公司后不久从淘宝上采购的 Alpha 工作站,最近终于搞清楚如何使用并且确认 Symbolics Open Genera 2.0 可以运行了。我从淘宝商家那里不但购买了 AlphaStation DS10 工作站,最近还得到了 Tru64 Unix 4.0F 操作系统安装光盘,几个可以激活操作系统基本功能的 license,以及修复了包括显卡支持在内多种问题的补丁包。以后这台机器将成为我重要的学习和研究环境,并且将来我可能再买一台更好的双核 Alpha 工作站备用。

事实上整件事让我理解了旧版本软件的存在意义。最初买这台 Alpha 机器时我还不懂这个道理,明确要求商家给我预装最新的 Tru64 Unix 5.1B-6,结果直到前不久才意识到这个版本太新了,无法运行我的 Lisp Machine 软件,必须降到 4.0F 才行。另一方面,我也终于明白了为何近年来我再也不能使用 Linux 模拟运行它了,因为 Linux 的版本也更新了,在重新安装了一个 Debian 4.0 的虚拟机以后,终于再次确认 Open Genera 2.0 可以运行并 Save World。想玩古董软件就不能盲目追新,配套的运行环境也必须是老版本的才行。这样一来我在业余 Lisp 领域的研究方向就明确了——把 Lisp Machine 里所有尚未移植出来的那些有用的东西重新挖出来然后移植到现在平台上,让世界理解当初 MIT 那帮 Lisp 黑客们究竟达到了怎样的高度。我在软件考古学领域注定要有一番大成就了。



在反复研究 FrameMaker 的手册并不断加以实践探索以后,终于开始走向成功了。我开始理解 Structured FrameMaker 究竟做到了什么,以及我先前使用的其他排版工具做不到什么。

在传统的排版软件里,无论是 Word、LaTeX 还是 InDesign,格式化的文本在本质上是一些带有样式的文本段落串接在一起的。很多人在使用这些文字处理软件时,无论需要怎样的格式,都是随手选中一个段落——无论是标题还是正文——然后立即通过工具栏对其字体和尺寸等属性加以设置,而在下次用到同样类型的段落时要么复制已有的段落,要么照原样重新选中并设置一次,完全不考虑样式的重用。这是最低级,最差劲的使用方法。

稍微高级一些的思想是重用已有的样式。把使用过的样式保存成有意义的名字,然后在用到的时候直接将某个段落指定为命名样式。这样带来的好处不仅是快捷和全文范围内更好的样式一致性,还具有对整个文档风格整体调整的能力——只需修改样式即可让所有用到该样式的段落产生变化。这是高级用户普遍掌握了的使用方式,同时也是大部分排版软件的极限。

问题在于所有的段落样式之间都是扁平关系的。标题和正文之间显然具有某种从属关系,但软件并不知情,也无法表达这种关系。FrameMaker 在最后几个大版本里引入的 Structure Authoring 特性(结构化创作)解决了这个问题。现在 FrameMaker 可以将整个文档视为一个树状的结构,用户通过定义样式和各种样式之间的从属关系能够将整个文档按照其本身的逻辑结构分层管理。然后定义一些规则,要求文档树必须满足特定的形状才算是有效。例如我可以要求每个标题的后面必有正文,或者每个数字列表都至少有 3 项,后者任何一个插图都必须带有标题,诸如此类的规则。对于多人协作的企业级文档来说,这样的规则保证了文档的质量和外观上的一致性。但据我的观察,无论 Word、LaTeX 还是 InDesign 都做不到这一点,排版软件所关注的焦点完全不在这里。

一旦可以把文档表达成一棵树,接下来就是两个自然的发展方向:1) 为其寻求更易于维护的文档格式——XML,2) 规范具体样式的定义和使用——DocBook 或 DITA。FrameMaker 把两件事都做到了。最初的 .fm 格式是二进制的,难以进行版本管理,现在 FM 文档可以保存成 XML 格式,这样就能直接通过文本比较来看出修改的部分,也可以直接进行文本编辑。然后 DITA/DocBook/S1000D 这些基于 XML 的标准可以规范用户对 XML 标签的使用,让来自不同供应商的文档使用统一规定的标签,这样一来文档的自动化处理和内容提取就成为可能了。但是结构化的老文档已经使用了各自命名的私有样式,怎样处理呢?解决方案就是定义一张转换表,让 FrameMaker 知道文档中用户自己定义的私有样式和标准样式之间的映射关系,这样就解决了转换问题,最后再把所有排版相关的信息保存在以 CSS 为基础的格式文件里,这样就完成了文档的规范化,得到的 XML 文档既可以在 FrameMaker 里编辑维护,也可以脱离 FM 环境采用第三方工具输出成 PDF 等格式。完美的技术文档解决方案。


附:一周微博汇总:

  评论这张
 
阅读(5735)| 评论(8)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017