标签 Python 下的文章

VIM“重装上阵”

国内很多学习Python的人都喜欢看"A Byte of Python",这是一本由印度小伙儿Swaroop C H写的书,之所以受到大家关注和欢迎,想必其简单而实用的写作风格是其中的重要原因吧,作为入门书很适合。我的Laptop中就有一本中文翻译版,不过书中用的还是Python 2.3.4版本。本月3日(2008-12-3)Python 3.0 Release版祭出,Swaroop C H也在其站点上增加了A Byte of Python for 3.0版。在下载新版"A Byte of Python"的同时,我又发现了Swaroop C H的另外一部作品"A Byte of VIM"。

刚工作的时候,一直用原始的VI(非VIM)在Unix上写代码,之所以选择原始的VI是因为部门里的老同事都使用它,VIM用的人不多,刚出校门的我还十分不适应VI的操作(在VIsual Studio上用IDE惯了),形成VI习惯还是很痛苦的,学习过程似乎没有什么成就感。看着其他一起入司的同事使用VIM的各种"奇技淫巧"分割窗口、折叠代码、自动补齐、通过快捷键在代码文件间跳来跳去,我却仍没有一些想深入学习的感觉(也许当时将精力都投到Java上了吧^_^)。

今年一直在努力通过各种方法(双显示器分布式编译等)提高自己的工作效率,提升工作效率是大势所趋,随着工作责任的增多,工作任务相应的也要多起来,时间还是那些,这就需要你在短时间内高效的完成工作。我们能做的除了做好时间管理、理顺工作流程外,对于个体来说采用更高效的工具以及熟练掌握这些工具就是高效工作的一个突破口了。眼下对于我来说重要的就是让VIM"重装上阵"(工作多年了,还是用使用VI的方法去使用VIM这个强大的工具,有些说不过去了^_^)。

与VI相比,VIM显然更强大,让人惊异于网上的各种VIM的插件和辅助软件,将这些结合在一起后,似乎一个无所不能的IDE就这样诞生了,也许这就是Unix文化的魅力所在吧。Swaroop C H的"A Byte of VIM",特别是其中的"VIM, Programmer's Editor"一节中将一个程序员应该常用到的插件和辅助软件都集中在了一起,从头到尾读一遍,你就会能体会到VIM的强大。关于如何使用VIM高效编辑的最好的Guide类文档当属Vim的Founder Bram Moolenaar所写的"Seven habits of effective text editing"了,目前该文档已经进化到2.0了。Bram在文中的一句话我觉得对学习Vim则是很有指导意义:"Learning every feature of Vim might make you the great award of Vim, but it will not be very effective. And it will be impossible to make everything a habit." 在VIM纷繁芜杂的功能中找到符合自己的实用功能并形成编辑习惯才是最高效的。

部门服务器上的VIM依旧停留在6.3版本,很多我需要的VIM新功能都不支持。为了不影响大家使用,我还是决定在自己的用户目录下重新编译一个VIM,最新版7.2,这样自己可以按照自己的需求定制。在SunFreeWare网站下载Vim7.2 For SPRAC Solaris 9的源码包,解压后发现VIM的目录组织很清晰整洁,Configure & Make,编译过程很顺利也,甚至连一个Warning都没有,10分钟编译完毕。Make install到自己指定的目录(需要在Configure的时候使用–prefix参数),修改path。再一执行Vim,版本已经变成了7.2了。

Ctags一直在使用,不过发现系统里的Ctags版本较低,为了能更好的配合Vim 7.2,我还是下载了一个Ctags 5.7版本源码,重新编译了一个自己用的CTags。在测试项目顶层Ctags -R生成tags文件,测试了一把,一切OK。

Taglist以前一直没有用过,下载其最新版taglist_45.zip,在本地$VIM_INSTALL_HOME/share/vim/vim72解压,
  inflating: plugin/taglist.vim      
  inflating: doc/taglist.txt
在测试项目里打开一个源文件,命令栏下输入: TlistToggle,Vim打开一个新的窗口,显示你当前Vim Buffer里的宏、Typedef、Functions、Variables等。你可以使用"Ctrl+w, Ctrl+w"在两个窗口间切换,对于函数较多较长、size较大的源文件的编辑有很大效率提升,list窗口中的内容也是普通文本,可以用各种搜索功能定位函数或变量,然后回车跳转到主窗口的相应源码。

Ctags和Taglist都功能有限,CScope才是集大成于一身,Vim内置了8种CScope的查询操作,比如你可以查询到当前光标下的函数被哪些方法调用,这个功能相当实用。由于我们服务器上没有CScope,我下载了源码编译,结果很不顺利,总是报错,无法解决,无奈只能让管理员在主机上用已经做好的安装包安装一个了。然后下载
cscope_maps.vim,将之放入.vim/plugin下面,cscope_maps.vim将冗长的cscope命令映射为热键了,便于使用。安装好后打开Vim,使用热键,vim在状态栏中居然提示不支持cs命令。Help了一下CScope,发现Vim默认编译时是不支持CScope的,需要重新Configure,重新Make,这次configure就要加上–enable-cscope选项了。另外CScope单独执行时会用你默认的编辑器打开相应文件,你可以通过在shell里设置‘EDITOR’环境变量来指定编辑器。

有了CTags、Taglist和CScope,你的Vim将呈现出丰富多彩的界面。窗口多了,别晕了。

Vim新版支持了内置的补全功能,通过Ctrl+N or Ctrl+P可在补全列表中前后选择;内置的补全功能会在当前缓冲区、其它缓冲区,以及当前文件所包含的头文件中查找以光标前关键字开始的单词,也是平时用的最多的补全功能。

Snippets,看到这个单词也许使用TextMate的人最为熟悉不过了,通过敲击几个关键字符+TAB间即可帮助你展开一些最常用的代码,减少输入的重复工作,比如for, while, if以及C++等面向对象语言中的class结构,你只需要输入内容即可。Snippets同样是通过插件snippetsEmu的形式提供到Vim中的。只需要Vim网站下载两个文:snippy_bundles.vba和snippy_plugin.vba,千万不要别扩展名给蒙住了,这两个文件不是Windows上的那个VBA脚本文件,而估计是vimball文件,下载后分别用vim打开,然后执行"source %"即可。VIM会在.vim/下的after和plugin下放入若干文件,用以支持Snippets功能。你可以打开~/.vim/after/ftplugin/c_snippets.vim,看看它对C语言都有哪些Snippets,如果觉得不符合你的习惯可以修改之。随意打开一个C源文件,输入do+TAB,可以看到:
do
{
       
} while ();
光标停留在中央,待你输入内容;输入后,点击Tab,光标会跳到下一个中,待输入完内容,再TAB,则最后一个消失,输入完毕。是不是也很强大:)

Vim的Quickfix模式是我以前没用到的,Quickfix这个就好比Visual Studio的“输出窗口”,build过程出现的错误都会在里面列表显示,你在这个窗口里将光标切换,主窗口就会显示对应的错误位置。前提你要在Vim内执行Make,一般我会使用:cw打开quickfix窗口,用cn和cp在quickfix中的错误行中切换。

其实以上每一个新功能都很复杂,形成习惯需要一个过程,但是一旦形成了习惯,你的效率将会有大幅提高。

使用Scons改造现有项目

今天是冬至,也是入冬以来感觉最冷的一天,毫不夸张的说:你一张嘴,牙就冻上了。上午LP在家收拾卫生,我继续用Scons改造现有的项目。下午出去理发,头发长长了后,似乎会造成思维迟钝^_^。

试验性的用Scons改造现有的project,过程中对Scons了解又多了一些。上篇文章对Scons的性能没有给出定论,经过对Scons的深入后,发现Scons在执行初始时的性能的确不够快,这是因为Scons启动后,会对全部SConstruct以及下面子目录中的SConscript进行分析,子目录越多Sconscript文件个数越多,性能也就越差。但是这种分析也有一个优点,就是能帮你提前发现你SConscript中的一些“语义”错误,比如如果你在编译两个基础库,一个叫add,一个叫sub,这个基础库源码分别分布在两个目录add和sub中,编译后将分别生成libadd.a和libsub.a的库文件,但是如果你马虎了,在编写SConscript时将target都写成了'add'或都写成了'sub',则Scons会在执行gcc之前就帮你找出这个"语义"错误,提示如下:
/export/home1/tony_bai/xxlib>scons -f SC*t
scons: Reading SConscript files …
scons: *** Multiple ways to build the same target were specified for: /export/home1/tony_bai/xxlib/lib/libsub.a  (from ['/export/home1/tony_bai/xxlib/add/libsub.a'] and from ['libsub.a'])
File "/export/home1/tony_bai/xxlib/sub/SConscript", line 3, in

Scons脚本基本写的差不多了,编译也ok了,但是编译出来的可执行程序在执行时却出现了问题:提示找不到某.so文件。而用项目"原配"的Makefile编译出来的可执行程序却执行的很好,没有类似问题,百思不得其解。将.so文件所在目录放到"LD_LIBRARY_PATH"中,问题得以解决,但这更加深了对这一现象的质疑。起初我一直以为是Scons在编译选项上不规范造成的,而Scons使用gcc -G -o xx.so xx.o来编译也的确有值得的怀疑点,-G选项是我从未见过的gcc编译选项,查了半天手册也没有对该参数的说明,遂放弃。上工具吧!先用ldd对编译出来的可执行文件进行分析,我们先来假设用Scons编译出来的可执行程序名字为Bin-scons,用"原配"Make编译出来的可执行程序名字为Bin-make。ldd将列出可执行文件中动态依赖的库的名字,并在本机定位出各个动态库的位置。对Bin-scons和Bin-make分别ldd的结果却让我大吃一惊,Bin-scons的ldd结果很正常,xx.so出现在list中,并且其位置为我刚刚加入到LD_LIBRARY_PATH中的那个目录;但是Bin-make的ldd结果中却不见了xx.so的踪影,这是怎么回事呢?回头翻看Makefile,并且又执行了多遍Make,项目的Makefile明明是构造了xx.so,在生成Bin-make时链接了xx.so,并且Bin-make中使用了xx.so中提供的接口。再次仔细对比Make和Scons编译.so时的差别,这回发现了些许不同的地方,"原配"的make在编译.so时,除了用了-shared -fPIC之外,还用了"-c"选项,而从Scons日志中只能看到gcc -G -o libxx.so xx.pic.o,显然Scons先控制gcc将xx.c编译为xx.pic.o,再由xx.pic.o构成libxx.so,而且我发现用Scons和Make编译出的.so文件大小居然不同。显然"-c"对两个编译过程带来了影响。一般来说,我们在编译一个动态库时是不会使用"-c"的,这里先不论项目Makefile写的是否ok,单说"-c"会给编译过程带来什么吧。打开gcc的"–verbose"开关,我们来试试使用和不使用"-c"gcc都做了些什么。还是以add.c为例,将add.c编译为libadd.so。

gcc -o libadd.so -shared -fPIC -c add.c –verbose
执行结果:
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/specs
Configured with: ../configure –with-as=/usr/ccs/bin/as –with-ld=/usr/ccs/bin/ld –disable-nls
Thread model: posix
gcc version 3.2
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/cc1 -lang-c -v -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=0 -D__GXX_ABI_VERSION=102 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc -D__sun -D__unix -Asystem=unix -Asystem=svr4 -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D__WCHAR_TYPE__=long int -D__WINT_TYPE__=long int -D__GCC_NEW_VARARGS__ -Acpu=sparc -Amachine=sparc add.c -quiet -dumpbase add.c -version -fPIC -o /var/tmp//cca0mHxn.s
GNU CPP version 3.2 (cpplib) (sparc ELF)
GNU C version 3.2 (sparc-sun-solaris2.9)
        compiled by GNU C version 3.2.
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "/usr/local/sparc-sun-solaris2.9/include"
#include "…" search starts here:
#include search starts here:
 /usr/local/include
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/include
 /usr/include
End of search list.
 /usr/ccs/bin/as -V -Qy -s -K PIC -o libadd.so /var/tmp//cca0mHxn.s
/usr/ccs/bin/as: Sun WorkShop 6 update 2 Compiler Common 6.2 Solaris_9_CBE 2001/04/02

gcc -o libadd.so -shared -fPIC add.c –verbose
执行结果:
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/specs
Configured with: ../configure –with-as=/usr/ccs/bin/as –with-ld=/usr/ccs/bin/ld –disable-nls
Thread model: posix
gcc version 3.2
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/cc1 -lang-c -v -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=0 -D__GXX_ABI_VERSION=102 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc -D__sun -D__unix -Asystem=unix -Asystem=svr4 -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D__WCHAR_TYPE__=long int -D__WINT_TYPE__=long int -D__GCC_NEW_VARARGS__ -Acpu=sparc -Amachine=sparc add.c -quiet -dumpbase add.c -version -fPIC -o /var/tmp//ccz128Nl.s
GNU CPP version 3.2 (cpplib) (sparc ELF)
GNU C version 3.2 (sparc-sun-solaris2.9)
        compiled by GNU C version 3.2.
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "/usr/local/sparc-sun-solaris2.9/include"
#include "…" search starts here:
#include search starts here:
 /usr/local/include
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/include
 /usr/include
End of search list.

 /usr/ccs/bin/as -V -Qy -s -K PIC -o /var/tmp//ccoU5RTD.o /var/tmp//ccz128Nl.s
/usr/ccs/bin/as: Sun WorkShop 6 update 2 Compiler Common 6.2 Solaris_9_CBE 2001/04/02
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/collect2 -V -G -dy -z text -Y P,/usr/ccs/lib:/usr/lib -Qy -o libadd.so /usr/local/lib/gcc-lib/sparc-sun-
solaris2.9/3.2/crti.o /usr/ccs/lib/values-Xa.o /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/crtbegin.o -L/usr/local/lib/gcc-lib/sparc-sun-
solaris2.9/3.2 -L/usr/ccs/bin -L/usr/ccs/lib -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/../../.. /var/tmp//ccoU5RTD.o -lgcc_s -lgcc_s
/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/crtend.o /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/crtn.o
ld: Software Generation Utilities – Solaris Link Editors: 5.9-1.276

对比这两次的执行结果,我们可以发现,使用了-c的编译过程实际上不是一个完整的共享库(动态库.so)的构建过程,而只是一个带有"-shared, -fPIC"的目标文件(.o)的编译过程,缺少gcc crt目标文件的链接过程,只是目标文件被命名为libadd.so了。这恰恰能解释我们前面提到了两点疑问了。为什么ldd Bin-make时没有发现其依赖xx.so以及Bin-make执行时一切ok,没有报“找不到xx.so”,这一切都是因为xx.so实际上是以.o形式存在的一个文件,在构建Bin-make链接xx.so时,实际上做到是静态链接而不是动态链接,xx.so中的接口代码都已经存在于Bin-make中了,所以ldd无法找到对xx.so的依赖,Bin-make执行时也无需找到xx.so了。看来这是项目Makefile中的一个问题了,只是这个"问题"隐藏太久而未能被发现罢了。

从收音机中得知"冬至"这天应该吃饺子,晚上和LP煮了两包水饺,热腾腾的,吃得直打饱嗝^_^。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! 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