标签 C 下的文章

Hello,Common Lisp

Paul Graham不愧被誉为Lisp的超级推手,他的煽动力真的是很强悍。这不才刚刚看完一遍他编写的《黑客与画家》后,我就决定将Common Lisp作为今年计划学习的那门新语言,而且从现在就开始。

去年曾囫囵吞枣般的学习过Haskell,一门通用且庞大的纯函数式编程语言。在惊叹于Haskell如此与众不同且功能强大的同时,也为Haskell Monad那魔鬼般的蹩脚语法所苦恼,而Monad的引入就是为了隔离副作用,并让你可以利用些过程式命令式语言解决问题的范式。

原以为Common Lisp也是一门函数式编程语言,应该与Haskell很像,但在看了《ANSI Common Lisp》一书后的前几章后我才发现其实不是那么回事儿。Common Lisp设计初衷其实是一门支持多范式的通用语言。除了语法上更接近于函数式编程范式外,你完全可以用Common Lisp写出具有过程式特点的代码(而且看起来也很容易)。另外Common Lisp Object System(CLOS)还给你提供了OO范式的选择。与Haskell相比,对于我这个C程序员来讲,Common Lisp带来思维跳跃似乎更小些,更有利于后续的学习和使用。

与Haskell的强类型和静态类型(即使你不显式指出类型,Haskell也会根据一些上下文的clue推导出类型,如果它发现类有不匹配,那么编译期间就会报错)不同,Common Lisp是动态类型和弱类型的,当然你也可以显式声明类型,但这么做也仅有利于编译器对代码的速度优化,并不能阻止什么。如:
> (declaim (type fixnum count))
> NIL
> (format t count)
*** – EVAL: variable COUNT has no value
> (setf count "hello lisp")
> "hello lisp"
> (format t count)
> hello lisp
> NIL

看到了吧,即使我们显式声明了count为fixnum类型,我们依然可以用字符串为其赋值。

Lisp语法十分简单:万物皆在括号内,无论代码还是数据。Lisp一直因括号泛滥而被诟病,不过对于我来说还好,也许是因为在C语言中也没少使用括号的缘故吧。另外现在的编辑器都支持高亮括号匹配,这样只要你细心些,写代码时基本不会出现因括号不匹配导致的一些问题。

编程语言影响思维习惯,但思维的转变不是一蹴而就的,也就是说用惯了C、Python等语言后,再去学习类似Common Lisp这类语言的确有些困难。遇到某问题时,或多或少还会首先以过程式的思维去考虑。另外Common Lisp也确实不是一门“小语言”,和Haskell一样,Common Lisp也很庞大,这也使得这些语言的学习曲线陡增。
  
之前一直认为Lisp也是一门解释性的语言,类似Python采用解析器的方式执行,性能不会很快。后来经了解后才得知诸多编译器(如CLisp)都是将源代码编译为某种格式的字节中间码,这样不仅性能得到了提升,可移植性还得到了兼顾。当然Lisp性能与C比起来还是要差出至少一个数量级的。Common Lisp的编译器我装了两个:CLisp和SBCL,目前来看似乎后者的开发更活跃一些。我个人则更多地使用CLisp。

这里必须得承认的是Lisp语言的应用还是比较小众的,甚至很多程序员都没有听说过有Lisp这门语言的存在。在实际商业开发中更是很少见到用Lisp实现的系统,这方面Haskell也有着同样的”感受“。不过近几年Lisp各种方言大有回升之势,Lisper们需要是耐心和时间。如果要想了解如何利用Common Lisp进行一些实际系统的开发,那么你就不能放过Peter Seibel于2005年编写的《Practical Common Lisp》一书。后来出版的《Real World Haskell》想必也是学习Peter Seibel试图为Haskell开发者们找到一条实际应用之道吧。

但有关Common Lisp的入门书,我还是觉得Paul Graham的《Ansi Common Lisp》更适合,另外在这之前可以先拜读一下Paul Graham的文章"The Roots of Lisp",这将对Lisp的学习大有裨益。

既然本文的主题为Hello,Common Lisp,那最后还是按学习新语言的惯例,在这里向大家展示一下用Common Lisp是如何编写Hello World的吧:

;; HelloWorld.lisp

(defun hello-world ()
  (format t "hello, world!"))

(hello-world)

让BuildBot服务于多个项目

多数公司不会仅有一个项目,当你为一个项目引入持续集成实践后,其他项目就会接踵而来。这时你会重新考量BuildBot,考虑如何让BuildBot可以服务于多个项目。

如果你有足够的主机资源和人力资源,那为每个项目单独搭建一套CI环境是再好不过的了,每个项目都有专人维护CI环境,各个项目的配置互不干扰。不过对于一些公司来说,这显然有些浪费,BuildBot Master的资源消耗是不大的,我们完全可以使用一套BuildBot Master来服务于多个项目,至少BuildBot是可以支持这样做的。

CI环境中,我们首要关注的就是源码库。多个项目可能各自使用单独的源码库,也可能共享一个源码库并通过目录隔离和识别。无论怎样,我们都可以通过BuildBot Master的配置来满足我们的要求。

如果说多个项目共享一个源码库或是一个项目下的多个子系统放在一个源码库中,这时我们在配置change_source时指定一个变更监测器即可,这个监测器的监测范围从源码库的根路径开始。以Subversion源码库为例,我们可以这样来配置:

c['change_source'] = [SVNPoller("svn://10.0.0.1:3000",
                                svnuser='tony',
                                svnpasswd='tony',
                                pollinterval=60,
                                split_file=change_path_split)]

我们通过change_path_split来拆分变更文件的路径,假设SVN库结构是这样的:
svn://10.0.0.1:3000
       – foo_proj
           – trunk
               – main/main.c
           – branches
           – tags
       – bar_proj
           – trunk
               – main/main.c
           – branches
           – tags

我们可以这样来实现change_path_split:

def change_path_split(path):
        pieces = path.split('/')
        if pieces[0] == ‘foo_proj’ and pieces[1] == 'trunk':
            return ('foo_proj/trunk', '/'.join(pieces[2:]))
        elif pieces[0] == ‘bar_proj’ and pieces[1] == 'trunk':
            return ('bar_proj/trunk', '/'.join(pieces[2:]))
        else:
            return None

不同项目下的文件变更,会导致change_path_split返回不同的值,而change_path_split返回值会被用于匹配不同的Scheduler:

c['schedulers'].append(Scheduler(name="foo-ci-plan",
                                 branch='foo_proj/trunk',
                                 treeStableTimer=5,
                                 builderNames=["foo-redhat-builder", "foo-x86-solaris-builder"])

c['schedulers'].append(Scheduler(name="bar-ci-plan",
                                 branch='bar_proj/trunk',
                                 treeStableTimer=5,
                                 builderNames=["bar-redhat-builder", "bar-x86-solaris-builder"])

上面各个Scheduler的branch属性会与change_path_split返回值元组中的第一个元素匹配,这样foo-ci-plan便是foo_proj的scheduler,而bar-ci-plan则是bar_proj的scheduler。这样某个项目路径下的文件变更只会触发对应的scheduler开始工作,不会出现误触发。

如果多个项目或一个项目的多个模块使用不同的源码库,同理,我们可以为c['change_source']赋予多个SVNPoller,例如:
c['change_source'] = [SVNPoller("svn://10.0.0.1:3000",
                                svnuser='tony',
                                svnpasswd='tony',
                                pollinterval=60,
                                split_file=change_path_split),

                      SVNPoller("svn://10.0.0.1:4000",
                                svnuser='tony',
                                svnpasswd='tony',
                                pollinterval=60,
                                split_file=another_change_path_split)]

与Scheduler的匹配方式也与上述描述一致,这里就不重复说明了。

不同项目的干系人多不相同,那么集成的结果是如何准确地反馈给项目各自对应的干系人呢?以Mail反馈通知为例,我在BuildBot手册中找到了两种方式,一种方式是通过设置Scheduler的owner属性,然后指定MailNotifier的sendToInterestedUsers=True,意图让BuildBot将Mail通知发到owner list中的每个邮件地址,但经测试后发现,这种方式似乎不好用,不知道是否是BuildBot对该功能的实现上存在问题。

另外一种方式则是配置多个MailNotifier。每个MailNotifier中指定对应builder的名称列表,并通过extraRecipients指定这些Builder对应的项目的干系人Mail地址列表,例如:

c['status'].append(mail.MailNotifier(fromaddr="foo-buildbot@buildbot.net",
                                     extraRecipients=["foo1@buildbot.net", "foo2@buildbot.net"],
                                     builders=['foo-x86-solaris-builder', 'foo-redhat-builder'],
                                     useTls=False,
                                     sendToInterestedUsers=False,
                                     relayhost="smtp.buildbot.net",
                                     smtpUser='tony',
                                     smtpPassword='tony',
                                     smtpPort=25))

c['status'].append(mail.MailNotifier(fromaddr="bar-buildbot@buildbot.net",
                                     extraRecipients=["bar1@buildbot.net", "bar2@buildbot.net"],
                                     builders=['bar-x86-solaris-builder', 'bar-redhat-builder'],
                                     useTls=False,
                                     sendToInterestedUsers=False,
                                     relayhost="smtp.buildbot.net",
                                     smtpUser='tony',
                                     smtpPassword='tony',
                                     smtpPort=25))

这样foo的builders构建的结果将发到foo1和foo2;而bar的builders构建结果将反馈到bar1和bar2。

多个项目共享一套BuildBot Master有利有弊,其不足之处可能有如下几点:
1、项目过多时,可能存在潜在的性能问题
2、Master的配置被多个项目共享,存在潜在的Conflict问题;
3、另外master.cfg可能size过大,也不利于阅读和维护。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats