Category: Programming

vim-cocoa 0.3 beta 1 released

After two days of work, here is the first beta of the 0.3 series of [vim-cocoa](http://code.google.com/p/vim-cocoa).

vim-cocoa 0.3b1 screenshot

#### What’s New?

* Updated vim to 7.2.49
* Use Core Text to replace ATSUI for text rendering
* Optimize program startup
* Support transparency option to control background transparency
* Fix cursor redraw on right clicking
* Fix CTRL + SHIFT + ? key handling ( Issue 35 )
* Mac OS X 10.5 only (Since Core Text is a 10.5 only framework)

#### Download

* [googlecode](http://vim-cocoa.googlecode.com/files/vim-cocoa-0.3b1.zip)

#### View Source

* [github](http://github.com/jjgod/vim-cocoa/tree/coretext)

候世达：如聆巴赫

翻译自: [Sounds Like Bach](http://www.unc.edu/~mumukshu/gandhi/gandhi/hofstadter.htm)

在我还年轻时 — 也就是写下《哥德尔、艾舍尔、巴赫》那时 — 曾问过自己这么个问题：“计算机程序会有写出优美音乐的那一天吗？”然后做出了如下推断：“计算机作曲程序在很长一段时间内不会产生什么有新意的成果……‘我们就快能用一台批量生产的二十块钱邮购获得的预置程序桌上型音乐盒子中那贫乏的电路写出肖邦或巴赫假如活到今日将写出的曲子’ — 这种念头，哪怕只是想一想 (事实上我的确听人如此提过)，也已是对人类心智深度的一种荒诞可耻的误估。”那时我的调子就是如此这般。

四分之一个世纪之后，我是如何看待这种推断的呢？说不准。这些问题已困扰我多年，直到现在还是没找到一个确定的解答。
Continue reading “候世达：如聆巴赫”

关于几个我参与的项目

我的一个习惯是做随机的 hacking — 也就是看心情如何，抓起一个软件的代码来改上一阵子，等问题解决了，再封起来好几个月不理。有许多朋友肯定都认为这是一个坏习惯，可惜这几乎已经成了我工作的固定方式，好像已经改不了了。

但是不少朋友仍然关注我以前参与的项目 — 它们是不是已经“死了”，所以，我觉得是时候来个小结了，以后这样的小结大概还是会继续做：

  • vim-cocoa: 很健康！我近期没有很大规模的计划，因为它对于我每天的使用已经足够了，但是我肯定会找时间把 google code 上一些积压的 issue 统一 fix 掉，或者至少 fix 掉一部分。
  • MacVim: 将 ATSUI 文本渲染器移植到 MacVim 的工作仍然在继续，下一个阶段的任务是解决特定字体的兼容性问题 — 之前我基本上只用 Monaco 测试过。当然我在 MacVim 上做的许多工作和 vim-cocoa 的是重叠的，代码也可以很大程度上复用。
  • Nally: 由于出现了 Welly 这个出色的 fork，至少在国内用户中，对 Nally 的用户需求没有那么多了，不过继续开发 Nally 的意愿仍然没有放弃，我自己如此，相信 yllan 也是如此，只不过下一步的计划想想总有点大，抽不出整块的时间来做。对我自己而言 Nally 下一步的计划是设计并实现一个足够灵活的插件架构，第一步会支持 Objective-C，然后会支持 Python, Ruby 等等脚本语言来编写 Nally 扩展。
  • Chmox: 说实话，Chmox 的代码改得并不舒服，可在我决定动手修改它的当时，那是 Mac 下唯一拿得出手的一个 CHM 阅读软件 (似乎也是当时唯一提供了源代码的 native CHM 软件)，可在现在 archmock 和 iCHM 这样出色的阅读器已经出现，而且它们要么本来就是开源软件，要么即将发布代码，所以我找不到理由再继续这个 Chmox 修正的项目。不过毫无疑问，在这个项目上花的时间一点也没有浪费，找到的一些技巧完全可以继续用于这两个新的阅读器中。
  • Mac Dictionary Kit: 是的，我知道 0.3 发布之后还是有不少问题，google code 的 issues 页面也积压了不少问题，可是最近始终提不起兴趣来修复 — 嗯，我很诚实地说，最近不想改它。

嗯，似乎单子已经够长了，本来要列下去应该还能继续列，不过想想还是算了，先做好这些吧…

State of iPhone Open Application Development (1)

七月关于 iPhone 的消息一直围绕着 2.0 firmware, iPhone 3G, official SDK 1.0 这几个关键词，而非官方关心的也只是 Pwnage Tool 2.0，却对没有 iPhone Developer Program 的开发进展甚少介绍，我想在这里做一点记录。

随着 SDK 1.0 的正式发布 (遗憾的是，因为 NDA 的存在，甚至它都算不上发布..)，iPhone 2.0 firmware 和 App Store 的上线，在 Apple 监视下的 iPhone OS/Cocoa Touch 程序开发的局限性暴露得越来越明显，saurik, NerveGas 等开发者坚持开发 Open Toolchain 的重要性也越来越明显。为什么在拥有一个如此完善的 SDK 的情况下我们还需要 Open Toolchain 和相关工具？因为:

  • Apple 严格限制了第三方应用对 API 的使用，非 Apple 自己开发的应用程序不能使用许多极为有用的 Private API，否则就是违反 SDK 的授权协议，所以第三方应用始终只能是“二等公民”。
  • App Store 的发行方式要求每次更新软件都要由 Apple 审核才能出现，而列出应用的页面对于用户 feedback 和开发者交流的功能也非常局限——毕竟这个模式根本就是 iTunes Music Store 改头换面了一点点，Album 到 Application 其实并不能做到一一映射。所以我们需要更自由的 iPhone OS 软件发行方式。
  • 软件分发要求所有只开发 Open Source/Free 应用程序的开发者都必须至少缴纳 $99 年费，这极大打击了 Open Source 开发/移植者的积极性，在 Pwnage Tool 的大环境支持下，我们完全可以跳过这个限制，自行分发软件。

因为上面这些原因，我一直非常关注 open toolchain 的开发，到了 4 月份的时候，有半个月的时间一直在跟踪 saurik 在这方面开发的结果，其结果是这篇 Upgrading the iPhone Toolchain，可惜的是因为 saurik 一直不满意用 git 来跟踪上游代码的修改，所以这篇文章其实相当难付诸实施，不过，考虑到 SDK 1.0 的发布后上游代码应该有一个相对稳定期，所以希望 saurik 能够尽快整理出更新的文档和代码来吧。

不过 saurik 在他的 Cydia repo 里提供了 iPhone 上完整的 toolchain，你可以在自己的 iPhone/iPod Touch 上用 gcc 编译，用 gdb 调试…. 当然考虑到有限的硬件资源，这种方式对很多人来说太 geeky 了，包括我。

然而，目前用官方 SDK 提供的编译器和调试器来给编写在 pwn 过的 iPhone 上免费分发的应用程序已经完全可行了，详情可以参考 saurik 的 Bypassing iPhone Code Signatures 和 246tNt 的说明。未 pwn 的 iPhone 因为目前事实上只有通过 App Store 一条路安装应用程序，所以谈怎么分发也是没有意义的。

简单的说，这种方式是因为 pwn 过的 iPhone 的内核已经被打上了 patch，弱化了签名校验——不再要求非要有 Apple 的签名了，可是签名校验依然存在，要完全去掉不大现实，所以现在你可以通过 Apple 自己提供的 codesign 工具来给应用自行签名，或者在别的平台下用 saurik 开发的 ldid 签名工具来保证通过 iPhone 的签名检查。对于大部分 Mac 开发者而言，这也只是在 Xcode 的项目中，新增一个 Build Phase 的事情，所以不会增加什么工作量。

而 246tNt 进一步延展了 saurik 的工作，分析了 entitlements 文件在签名后的 iPhone App 中对安全控制的作用，使得这种自签名的应用程序也能像有 Dev Program 的应用一样，可以用 Xcode 自带的 gdb 进行远程调试。此外，246tNt 还找出了办法对 iPhone OS 中的 SpringBoard 和 MobileInstallation 打上补丁，使得我们可以直接把应用程序用 Xcode Organizer (或者 Build and Go!) 上传到 iPhone 上，并自动开始调试。

感谢这些开发者的工作，目前我们获得的开发环境和支付了 $99 美元的 Dev Program 开发者毫无二致了。可是，分发环境还是有区别，假定我们的程序并没有做任何逾越 SDK 授权的事情，如果还希望通过 App Store 分发，那还是只能去购买 Dev Program。不过毫无疑问，对于开放的应用程序而言，Cydia 应该是更好的分发方式，考虑到因为 Pwnage Tool 2.0 的包含，Cydia 几乎已经成为了标准的应用分发方式。

(待续)

最近在写的两个东西

这两天写了两个简单的小程序，主要是满足朋友和个人需求的，还在修改中。

第一个叫 apn 的程序是给 Mac OS X 中 Address Book 中的联系人自动生成姓名发音 (Phonetic Name) 的脚本，所以它的名字就是 Assign Phonetic Name 的缩写。

这是一个 Python 写的程序，直接用到了 pyzh 项目提供的汉字拼音转换代码，通过 Scripting Bridge 提供的 API 来访问 Address Book，这样虽然相比直接调用 Objective-C 的 API 有点慢，但好处在于能充分利用 Python 语言的灵活性。

使用起来很简单，从 github 上把代码抓下来 (你可以 git clone git://github.com/jjgod/apn.git 或者下载一个打包的版本)，然后执行

$ python AssignPhoneticName.py

就会自动给你 Address Book 中没有分配过 Phonetic Name 的那些联系人分配一遍。注意因为汉字有多音字，这个程序做不到很智能，你最好在分配之后打开 Address Book 校对一遍。

第二个是给 Cocoa 程序员用的一个 NSView 的子类，叫 PYView，其作用很简单，就是在汉字上方同步的显示拼音，不过目前拼音还得自己提供。

调用的 API 很简单，比如这样:

#include "PYView.h"

NSRect viewRect = NSMakeRect(50, 250, 700, 80);
view = [[PYView alloc] initWithFrame: viewRect
                            fontName: @”FZKai-Z03″
                               color: [NSColor whiteColor]];

NSArray *pinyin1 = [NSArray arrayWithObjects: @"nǐ", @"hǎo", nil];
NSArray *pinyin2 = [NSArray arrayWithObjects: @"zhōng", @"huá",
                    @"rén", @"mín", @"gòng", @"hé", @"guó", nil];


[view appendMarkerItem: [PYMarkerItem itemWithHanzi: @"你好"
                                             pinyin: pinyin1
                                               type: 1]];
[view appendMarkerItem: [PYMarkerItem itemWithHanzi: @"中华人民共和国"
                                             pinyin: pinyin2
                                               type: 1]];

就能得到如图所示的输出结果:

PinyinView

可以从 github 上获取代码:

 git clone git://github.com/jjgod/pinyinview.git

然后参考提供的 PYViewTest 代码来使用。注意接口还在修改中。