Update Vimpress 已经升级到2.x版本,使用、配置都有改进,请关注在vim.org的插件页面: Vimpress had been updated to 2.x, usage and configurations are now different, read the officle page in vim.org: http://www.vim.org/scripts/script.php?script_id=3510 VimRepress is a broken fixed version of vimpress, a vim plugin to manage your wordpress. The name VimRepress is given by Justin Sattery described it a "A mod of a mod of a [...]
给自己架了个Wiki http://wiki.apt-blog.net作为自己的知识管理工具。虽然这个博客本来就是工具之一,也累积了快两年了,但经常碰到有些小东西,不值得为之写篇博客,很有用,但用完就忘记。个人wiki适合做写细小的笔记,当累积一定的时候还可以整理成博客。 Wiki我选择了用Python的MoinMoin,一定程度上受CPYUG社区 ZoomQuiet 大妈的推荐影响,首次试用感觉非常impresive,所以就定了。再加上 GraphViz 工具的支持,实在的强大。 在vps上服务,肯定是无视apache的,内存有限。之前架设过用来上Twitter奶瓶腿,是Nginx + php-cgi的方案,nginx是必须的。 Python跟web前端的架构方式有太多选择了,五花八门,MoinMoin的发行包里面都提供了moin.cgi moin.scgi moin.ajp moin.fcgi moin.wsgi等多种启动方式。MoinMoin里面全部通过内置的flup作为中间件提供这些接口,目前我仅尝试使用了fastcgi和wsgi。 虽然解压了moin的源码包就可以直接运行里面的wikiserver.py来本地访问了,但在服务器上通常是由nginx/lighttpd等服务来综合转发。php的话是通过spawn-fcgi启动一些php-cgi的进程,服务器接受到动态的请求就通过本地socket跟php-cgi通讯,返回的结果展现回给客户。php-cgi是使用FastCGI协议的。 MoinMoin 源码当中wiki/server/moin.fcgi就是一个类似php-cgi功能的fastcgi服务,类似地可以使用spawn-fcgi来启动moin.fcgi,作为后端的处理进程。 Running MoinMoin Wiki with Nginx via FastCGI and Flup该文章很形象解释了fastcgi的角色,以及提供了一段很方便的服务脚本来启动spawn-fcgi。 Client ----> Nginx Web Frontend -----------+ | fastcgi_pass \|/ +-------------------------+ moin.fcgi | spawn-fcgi-moin.socket | spawn-fcgi ---------------> | or | | localhost:port | +-------------------------+ 但是文章当中的nginx配置不完整,而且复杂了,这是我的配置: server { listen 80; [...]
Vim has been so graceful that I like to have any text editing work done in her, especially coding and blogging. As a Firefox user, I previously use scribefire to write to my wordpress blog, actually I was working with HTML, I don't like WYSIWYG editing, which always creates dirty codes. However, scribefire is not [...]
此前文章《最简单方法远程调试Python多进程子程序》利用了Unix管道文件以及简单的bash来配合调试多进程子程序,但也因此没法跨平台支持windows下的子进程调试,这次简单使用socket接口写了个模块,利用类文件对象传给Pdb的构造,因此不仅可以跨平台,甚至跨机器,跨网络调试都没问题(通常不会这么BT的)。 使用方法,用回之前的例子: 先在终端运行调试服务端: python -c "import rm_pdb; rm_pdb.server()" 在另外的终端运行这个文件: multiproces_debug.py 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 #!/usr/bin/python import multiprocessing import pdb import rm_pdb def child_process(): print "Child-Process" rm_pdb.pdb().set_trace() var = "debug me!" def main_process(): print "Parent-Process" p [...]
Python 2.6新增的multiprocessing,即多进程,给子进程代码调试有点困难,比如python自带的pdb如果直接在子进程代码里面启动会抛出一堆异常,原因是子进程的stdin/out/err等文件都已关闭,pdb无法调用。据闻winpdb、Wing IDE的调试器能够支持这样的远程调试,但似乎过于重量级(好吧前者比后者要轻多了,但一样要wxPython的环境,再说pdb的灵活可靠它们难以比拟)。 其实只需稍作改动即可用pdb继续调试子进程的代码,思路来自这个博客:子进程的stdin/out/err关闭了,那可以自己重新按/dev/stdout的名称打开来用。当然这指*nix下,win下要麻烦一些,后面再说。 pdb支持自定义输出输入的文件,我再稍作改动,使用fifo管道(Named Pipe)来完成pdb的输出输入的重定向,这样的好处是,可以同时对父子进程调试! multiproces_debug.py 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 #!/usr/bin/python import multiprocessing import pdb def child_process(): print "Child-Process" pdb.Pdb(stdin=open('p_in', 'r+'), stdout=open('p_out', 'w+')).set_trace() var = "debug me!" def main_process(): print "Parent-Process" p = multiprocessing.Process(target = [...]
这篇笔记相对Python来说,有点底层,先来解释几个名词: C-Python: 或者CPython,指C实现的Python虚拟机的基础API。最通用的Python就是是基于C实现的,它的底层API称为C-Python API,所有Python代码的最终变成这些API以及数据结构的调用,才有了Python世界的精彩; Cython:准确说Cython是单独的一门语言,专门用来写在Python里面import用的扩展库。实际上Cython的语法基本上跟Python一致,而Cython有专门的“编译器”先将Cython代码转变成C(自动加入了一大堆的C-Python API),然后使用C编译器编译出最终的Python可调用的模块。 GIL:Global Interpreter Lock,是Python虚拟机的多线程机制的核心机制,翻译为:全局解释器锁。其实Python线程是操作系统级别的线程,在不同平台有不同的底层实现(如win下就用win32_thread, posix下就用pthread等),Python解释器为了使所有对象的操作是线程安全的,使用了一个全局锁(GIL)来同步所有的线程,所以造成“一个时刻只有一个Python线程运行”的伪线程假象。GIL是个颗粒度很大的锁,它的实现跟性能问题多年来也引起过争议,但到今天它还是经受起了考验,即使它让Python在多核平台下CPU得不到最大发挥。 GIL的作用很简单,任何一个线程除非获得锁,否则都在睡眠,而如果获得锁的线程一刻不释放锁,别的线程就永远睡眠下去。对于纯Python线程,这个问题不大,Python代码会通过解释器实时转换成微指令,而解释器给他们算着,每个线程执行了一定的指令数后就要把机会让给别的线程。这个过程中操作系统的调度作用比较微妙,不管操作系统怎么调度,即使把有锁线程挂起到后台,尝试唤醒没锁的,解释器也不给他任何执行机会,所以Python对象很安全。 所以一般来说,做纯Python的编程不需要考虑到GIL,它们是不同层面的东西,但是模块级别的C-Python、Cython等C层面的代码,跟Python虚拟机是平起平坐的,所以GIL很可能需要考虑,特别那些代码涉及IO阻塞、长时间运算、休眠等情况的时候(否则整个Python都在等这个耗时操作的返回,因为他们没获得锁,急也没办法)。 想体现这个过程,很简单,考虑下面的代码,一段纯Python和一段纯C的循环,每次print一段文字就睡眠一秒。 1 2 3 4 5 6 7 void _c_loop ( void ) { while(1) { printf("Print from C loop\n"); sleep(1); } } 1 2 3 4 def _py_loop(): while True: print "Print from Python loop" time.sleep(1) 先不管他们是如何揉合到同一Python进程里面,两个进程分别执行了这两个函数后,他们应该以大概相互间隔着输出文字;但实际情况是,Print from Python loop这句出现了一次之后(先启动了纯Python线程,否则它连启动的机会都没),剩下的输出全都是Print from C [...]
昨天的技术沙龙上,清风大妈Zoom.Quiet给大家提了个“很基础很基本”的问题,什么是pythonic? 自己没特地做过功课,但pythonic这个词不陌生,应该见过几次,但是要说具体是什么,确实很空白。说起python,我首先想起来的是其很让人愉悦的编码体验,一些很常用的封装让人感觉很“惊艳”,比如说,for line in open('file'):ooxxooxx,替代了C++、Java等里面的readline,更不会让人产生在C里面打开文件时候那种恐惧感;还有一些很贴心的细节就是,高度对象化,比如说gtk的TreeViewModel,可以直接送给SQL cursor的execute,直接把用户界面的数据写入到数据库里面去……因为都是list。 像这样的“愉悦感”,就是我理解的pythonic。昨天会场上有人的答案是:“简洁,优雅,高效”,获得比较多人的认可(得到了奖品带大妈签名的《可爱的Python》一本)。 回来后看了看华蟒用户组的首页,呃,很明显写着嘛:申明 pythonic == "大道至简",也八九不离十了。 这两天也是这个邮件组里面有人讨论实现小时候铅笔盒上的九九乘法表,最获得大家认可的答案是: print "".join([('%s*%s=%s%s' % (y,x,x*y,'\n' if x==y else '\t')) for x in range(1,10) for y in range(1,10) if x >= y]) 看了犯晕,这很明显跟python给人“惊艳感”的做法背道而驰的,但怎么会这么多人认可呢……同时想起咋们群主“逆”说一直没搞懂的一句算素数的python: print reduce(lambda l,y:not 0 in map(lambda x:y % x, l) and l+[y] or l,xrange(2,1000), [] ) 这叫做pythonic?既不简洁,又不优雅,更不高效,充其量作为一个脑力游戏,还不如玩玩数独! 玩小聪明一直都是天朝人的传统,人家孔乙己还会“茴”字的N个写法呢,但这类小聪明,着实应该远离python。
paste.ubuntu.org.cn是国内很多linuxer喜爱的“在线剪贴板”,在跟网友交流时把代码、截图等发在这里,然后把网址发送给对方即可,而且对多种常见代码支持语法高亮,功能简单贴心。(不用像某网友在这个博客上篇帖子里面那样,在留言里面贴一大堆乱哄哄的代码……=。=) 虽说方便,但平时要发送文件时候还是要打开浏览器,再贴代码或者选择文件,多少有点繁琐,所以打算用python写个上传脚本,跟nautilous结合的话,上传截图就方便多了。 首先问球猫要了个ubpaste的perl的脚本,虽然我不懂perl,但发现上传部分只有10来行代码嘛……看来挺简单的,可能用urllib随便弄一下就可以了……结果发现,不行!paste.ubuntu.org.cn用的是mutipart/form协议方式的上传,而python标准库里面没有直接支持这种协议(perl却有……而且自动支持……所以几行代码搞定=。=)…… 查了一下资料后自己写了个class来实现mutipart的boundary,才知道用http来发送文件,特别是上传大文件是这么麻烦的事情……不过还好,不算很复杂,但是整个脚本下来居然有150行代码了……=。= 现在还不能直接拿来当nautilous script用,因为第一个参数是读入文字而不是文件,还在犹豫用bash来重新封装(使用curl一行就搞定上面所说的上传了)……[懒ing]
Page optimized by WP Minify WordPress Plugin