I am LAZY bones? AN ancient AND boring SITE

给python增加IPC模块

前天介绍了linux进程间通信──消息队列,由于消息队列是linux内核提供的功能,所以理所当然地,C语言用起来最为方便:直接include一个sys/msg.h就可以了,所以之前的文章,我也是用C语言来做演示的.
那么我喜欢的Python能不能用IPC呢?能不能像C一样用消息队列呢?
其实,Python的内置模块里,并没有对IPC的支持,但是好在python的可扩展性超强,我们可以用swig来为python增加一个IPC模块.方法如下:
下载这个tar包(修改自这里),解压到任意目录,得到 ipc.h ipc.i Makefile 3个文件,如果你不是用的python2.6,需要修改一下 Makefile 里的路径(python3系列未测试).然后

make && make install

这样,你就可以在python里 import ipc模块了.
还是贴示例代码,保存为ipc_msg.py,并加可执行权限:

#!/usr/bin/env python
import sys,ipc
 
if len(sys.argv)==5 and sys.argv[3][0]=='s':
    ipc_key=int(sys.argv[1])
    msg_id = ipc.msgget(ipc_key,0666|ipc.IPC_CREAT)
    if 0 > msg_id:
        sys.exit(1)
    mbuf = ipc.msgbuf()
    mbuf.mtype = int(sys.argv[2])
    mbuf.mtext = sys.argv[4]
    if 0 > ipc.msgsnd(msg_id,mbuf,len(mbuf.mtext),0):
        sys.exit(3)
    print 'Send Success.'
elif len(sys.argv)==4 and sys.argv[3][0]=='r':
    ipc_key=int(sys.argv[1])
    mbuf = ipc.msgbuf()
    msg_id = ipc.msgget(ipc_key,0666)
    if 0 > msg_id:
        sys.exit(1)
    msg_len=ipc.msgrcv(msg_id,mbuf,2048,int(sys.argv[2]),ipc.IPC_NOWAIT)
    if 0 > msg_len:
        print 'No message received.'
        sys.exit(3)
    else:
        print 'Recv Success.(%d bytes):'% msg_len
        print mbuf.mtext
elif len(sys.argv)==3 and sys.argv[2][0]=='c':
    ipc_key=int(sys.argv[1])
    id_dsp = ipc.msqid_ds()
    msg_id = ipc.msgget(ipc_key,0666)
    if 0 > msg_id:
        sys.exit(1)
    if 0 > ipc.msgctl(msg_id,ipc.IPC_RMID,id_dsp):
        sys.exit(2)
else:
    print "usage: \n%s key type s message --to send message\n\
%s key type r --to receive\n\
%s key c --to clear queue"\
        %(sys.argv[0],sys.argv[0],sys.argv[0])

运行结果:

lily@LLY:~/test/ipc$ ipcs -q
 
------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages    
 
lily@LLY:~/test/ipc$ ./ipc_msg.py 1 2 s abc
Send Success.
lily@LLY:~/test/ipc$ ipcs -q
 
------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages    
0x00000001 65536      lily       666        3            1           
 
lily@LLY:~/test/ipc$ ./ipc_msg.py 1 2 r
Recv Success.(3 bytes):
abc
lily@LLY:~/test/ipc$ ipcs -q
 
------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages    
0x00000001 65536      lily       666        0            0           
 
lily@LLY:~/test/ipc$ ./ipc_msg.py 1 c
lily@LLY:~/test/ipc$ ipcs -q
 
------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages    
 
lily@LLY:~/test/ipc$

怎么样?和之前的C语言版本一模一样吧?

gentoo的内核升级到2.6.30 fglrx加载失败

昨天sync,发现有 sys-kernel/gentoo-sources-2.6.30 可用了,我没忍住,就升级上去了,其他的倒是没啥感觉,就是加载不了fglrx了…
虽然ati-drivers在我修改了一下ebuild以后,已经成功安装上去了,fglrx.ko也生成了,但是却加载不了,导致compiz不能用了.
modprobe fglrx的时候,提示:
FATAL: Error inserting fglrx (/lib/modules/2.6.30-gentoo-lly/video/fglrx.ko): Unknown symbol in module, or unknown parameter (see dmesg)
然后,dmesg里有这样两行:
fglrx: Unknown symbol flush_tlb_page
fglrx: Unknown symbol pci_enable_msi
应该是内核做了该动了.不知道有没有针对2.6.30的patch…不然,难道我要去用开源驱动了?

PS: 今天又发现了 sys-kernel/gentoo-sources-2.6.30-r1 orz…

linux进程间通信──消息队列

linux自古以来就是一个多任务多用户的操作系统,所以linux的进程间通信(Inter-Process Communication──IPC)就显得非常重要了。
IPC是一种标准的Unix通讯机制,目前有以下几种通讯方式:管道(Pipe)、信号量(Semaphore)、互斥体(Mutex)、共享内存(Shared Memory)和消息队列(Message Queue),当然也有其他的方式,比如文件系统和dbus等。
今天我就来介绍一种简单实用的进程间通信方式:消息队列(Message Queue)。
首先说说消息队列的优缺点:
1.消息队列只适用于单台主机的进程间通信,如果是不同主机,需要用socket等其他方式,也就不属于IPC的范畴了。
2.消息队列可以实现异步通信,这似乎是优点,但说是它缺点也是可以的:通讯往往不是实时的。
3.消息队列有大小限制,通常只用于小数据量的发送。系统对用户的大小限制可以通过 ulimit -q 命令进行查询。
4.消息队列可以实现阻塞调用和非阻塞调用。
5.实现简单,且可移植性好。

下面通过一个实例来进行说明,以下文件保存成 ipc_msg.c:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/msg.h>
 
int main(int argc, char *argv[]){
	int ipc_key,msg_id,msg_len;
	long mtype;
	void * mbuf;
	if(argc==5 && argv[3][0]=='s'){
		ipc_key=atoi(argv[1]);
		mtype=atol(argv[2]);
		msg_len=strlen(argv[4]);
		if ( 0>(msg_id=msgget(ipc_key, 0666|IPC_CREAT)))return 1;
		if ( NULL==(mbuf=malloc(msg_len+sizeof(long)+1)) )return 2;
		memcpy(mbuf, (void *)&mtype, sizeof(long) );
		memcpy(mbuf+sizeof(long), (void *)argv[4], msg_len );
		if ( 0>msgsnd(msg_id, (struct msgbuf *)mbuf, msg_len, 0) )return 3;
		printf("Send Success.n");
	}else if(argc==4 && argv[3][0]=='r'){
		ipc_key=atoi(argv[1]);
		mtype=atol(argv[2]);
		if ( 0>(msg_id=msgget(ipc_key, 0666)))return 1;
		if ( NULL==(mbuf=malloc(4096)) )return 2;
		if ( 0>(msg_len=msgrcv(msg_id,(struct msgbuf *)mbuf, 4000, mtype, IPC_NOWAIT))){
			printf("No message received.n");
			return 3;
		}
		printf("Recv Success.(%d bytes):n",msg_len);
		printf("%sn",(char *)(mbuf+sizeof(long)));
	}else if(argc==3 && argv[2][0]=='c'){
		ipc_key=atoi(argv[1]);
		if ( 0>(msg_id=msgget(ipc_key, 0666)))return 1;
		if ( 0>msgctl(msg_id,IPC_RMID,(struct msqid_ds *)mbuf) )return 2;
	}else{
		printf("usage:"
			"%s key type s message --to send messagen"
			"%s key type r --to receiven"
			"%s key c --to clear queuen"
			,argv[0],argv[0],argv[0]);
	}
	return 0;
}

以上程序,实现了发数据到消息队列和从消息队列收取数据的功能。
第一个参数需要是一个整形数值,表示消息队列的Key;
第二个参数是一个长整形的数值,表示消息的Type,Key+Type 可以唯一确定一个先进先出的消息队列。
第三个参数如果是‘s’则把第四个参数发到指定消息队列,如果是‘r’则从指定消息队列收取消息,并打印。
另外,如果第二个参数是‘c’,则把Key对应的队列删除。
让我们来运行一下试试:

$ gcc -o ipc_msg ipc_msg.c
#编译
$ ipcs -q
 
------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages    
#一开始系统中没有消息队列。
$ ./ipc_msg  1 2 s abc
Send Success.
#发送了一个内容为abc的消息
$ ipcs -q
 
------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages    
0x00000001 262144     lily       666        3            1           
#发送了一个消息以后,队列里有消息了,key是1,有3个字节。
$ ./ipc_msg  1 2 r
Recv Success.(3 bytes):
abc
#从消息队列成功收到消息了。
$ ipcs -q
 
------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages    
0x00000001 262144     lily       666        0            0           
#收完以后,空的消息队列仍然存在,不会自动消失。
 
$ ./ipc_msg  1 c
#删除队列
$ ipcs -q
 
------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages    
#成功删除了,回到原始状态。

本文以GNU自由文档许可证发表.

趣站: lmgtfy

lmgtfy 这几个字母放在一起,估计没几个人能看出是什么意思,其实它就是 Let me google it for you 的缩写.
http://lmgtfy.com/ 就是这样一个简单而好玩的网站: 比如,如果有人论坛里问 li2z 是什么?然后你不是很想回答,想让他自己去google,你就可以给他这个链接,相信他一看就会明白了,哈哈.当然你还可以用网站内置的tinyurl接口实现url的压缩等.
网站的主人显然是个web2.0爱好者,因此,你还可以follow网站的twitter,或者观看实时搜索直播不过..真的是实时的么?

XP也很牛

几天前,据说微软要派人到我们公司查盗版系统(我就奇怪了,我们公司又不大,怎么就被盯上了呢?)…
哈哈,这对我倒是没啥大的影响,因为我平时都是用linux工作的.
但是我还是有装着个一个XP的,虽然很少用,基本上就是偶尔打几盘游戏.那我到底是删了XP还是留着呢?
干脆就让我来做个试验吧:我把XP的系统分区(NTFS格式)mount上,把windows目录和ntldr、NTDETECT.COM等记个文件都tar成了一个包…并删掉了,Documents and Setting和Program Files等几个目录换个名字.但是保留分区不动.
这样应该查不出的我windows了吧~
但是,几天过去了,也没看到微软的人来,看来又是忽悠忽悠咱老百姓的,今天我把那些文件都恢复了,tar包也解开,grub项加回去,再试着启动XP,居然还真能启动,哈哈~牛了~
不过有这么几个问题:
tar以后,删除再恢复的文件,丢失了 只读/隐藏 等属性.
tar完删除windows目录的时候,会有少数文件删不掉.可以mv改个名字,忽略掉.
这样以后的系统稳定性未知,没事还是别瞎试验了.

测试base64加密的文章

呃…在这个举国上下都非常紧张的敏感时期,很多博主(指目前还没被墙掉的博主)肯定都想说点啥而不敢说吧?
受lerosua之前用base64来写博文的启发,本文来探讨一个更加方便的加密方法.
lerosua的方法,缺点比较明显,就是对阅读者不够友好,linux用户还可以很方便地复制文字来base64 -d,win用户基本上都要打开一个在线解码base64的网站来解码了.于是我就想能不能把解码的功能放在同一个页面里,用户只需按一下按钮即可看到真实内容.
下面是演示:
点击查看全文 »

python用着太顺手了

(此文纯属自言自语,基本可以忽略,呵呵.)
python用着太顺手了,其实是很久以前就有这种感觉,最近印象比较深的一次就是在做Project Euler的第一题的时候,那题比较简单,要求1000以内所有能被3或5整除的自然数之和.这题其实用什么语言都不复杂,但是用python的话,只需要一行:

sum([n for n in range(1000) if n%3==0 or n%5==0])

接近自然语言的表达看起来好舒服,而且也相当简洁.
然后今天,我又更新了一下gmbox,基本上把CLI重新写了一遍,又有同样的感觉了.gmbox的命令行,分交互式和非交互式两种,刚好用cmd和optparse两个内置模块轻松搞定.而且cmd模块支持欢迎界面/自定义提示符/readline库;optparse支持长短选项和混杂无序的选项,并自动生成帮助界面.真是太爽了.这两种模式加起来才140行左右的代码.去掉文件头,只有120行…
以后继续学习python.哈…

bones7456 WP theme 微调

看到Matrix 67的blog的主题,觉得有一点很不错:就是右侧的最新评论那里,一开始是每个评论只占据一行的位置,只有在鼠标放上去的时候,才会把内容展开.
这样的好处很明显:平时节省页面空间,布局也更漂亮,鼠标放上去的时候显示出该有的信息,也不影响使用.
于是,有样学样,把这一小细节学习了过来(呃..好吧,其实就是抄了过来…).
在实现上,没去动WP带的dynamic_sidebar函数,而是偷懒了一下,在页面基本展开完以后,用js处理了一下style,并添加事件函数.看现在是不是更好看了?
之前我都只敢放5个最新评论,因为再多,就不美观了.现在放10个也不是问题.
如果你也喜欢并想试试本WP主题,可以到这里下载最新的代码.
:-)

gentoo升级后的若干问题

半个月前的某一天,我正在对gentoo进行常规更新的时候,记得当时emerge到了wine,突然屏幕一黑,机器就保护性关机了…用手一摸CPU附近,那是相当地热…
于是,最近一段时间都没有升级过gentoo.
直到后来,我把本本后盖打开,清理了一下里面的灰尘.听风扇的噪音,明显比之前小了很多了,温度也没那么夸张了.于是又开始升级了,一看已经积累了108个包要编译了.这还是我mask掉新内核的结果.
编译之后,nautilus 到了2.26.3,晚上下班后,重启进系统,就发现不对劲了,一堆的窗口把窗口列表塞满了… 后来经过试验发现,只要我一把 /apps/nautilus/preferences/show_desktop 这个勾去掉,就会启动N多个nautilus的窗口,下面的窗口列表里瞬间被挤满了..并且还在不断增加,直到内存耗尽…
问了keke他的情况刚好和我相反,是勾上那个勾勾才会出问题…这个估计是nautilus的bug了,没时间深究,等上头更新了,现在就先看着本不想看到的桌面吧…

还有一个好玩的问题,就是我的音量调节的图标没了,之前还以为是 gnome-volume-manager 这个包的问题,后来TX提醒我才想起这个volume是卷(磁盘分区)的意思,和音量根本没关系,汗了…这算不算英文词汇的匮乏呢?
其实,那个音量调节的applet是在 gnome-base/gnome-applets 里面的.重新编译了一下,又可以用了.而且,那调音量的滚动条变横着了…我怎么觉得还是没竖的好看呢?

====20090630更新====
nautilus疯狂打开窗口的问题终于好了…难道是昨天编译了gnome-base/gnome-session-2.26.1-r1的原因?不管怎么样,我的桌面总算又干净了~

测试一下你的网站打开有多快

一个网站好不好,内容固然是最重要的,但是也不能忽视了其他指标,例如:打开速度.按照一般公认的说法,如果一个普通的页面,打开需要8秒以上,那么就极有可能被用户关掉了,我觉得最好是能在5秒以内,嘿嘿.
那么站长门肯定会关心一下自己的网站打开到底有多快了.于是,拿个秒表,一手点浏览器的刷新按钮,一手启动秒表…测试几次,打开计算器取平均值? 这也太土了,测试结果也不够精确,这么程序化的工作,当然要交给程序去做. 于是就有了这个简单实用的小(web)程序: WebWait. 打开页面,输入url,点击”Time It!”按钮,默认地,它就会帮你打开5次页面,每次间隔1分钟,记下时间,并算好平均值给你.当然,测试几次,还有测试间隔都是可以设置的.
例如, li2z.cn 的打开速度就是:
2.11s