蛋疼的linux下安装graphviz的过程

1. 先下载了http://www.graphviz.org/pub/graphviz/stable/SOURCES/graphviz-2.38.0.tar.gz，安装后写了个测试例子：

#test1.dot
digraph example2 {
    Server1 -> Server2; Server2 -> Server3; Server3 -> Server1; }

执行测试程序：
dot test1.dot -Tpng -o test1.png
显示错误：
Format: "png" not recognized. Use one of: canon cmap cmapx cmapx_np dot fig gd gif hpgl imap imap_np ismap mif mp pcl pic plain plain-ext ps ps2 svg vml vtx wbmp xdot

2. 尝试安装graphviz-gd库
yum install graphviz.x86_64
yum install graphviz-gd.x86_64
无效

3. 尝试安装libpng & gd库：
wget "http://prdownloads.sourceforge.net/libpng/libpng-1.6.17.tar.gz?download"
下载 https://codeload.github.com/libgd/libgd/tar.gz/gd-2.1.0
无效

4. 根据一篇帖子，选择安装低版本的graphviz:
    http://weibo.com/p/23041868f23d9f0102vfbw?pids=Pl_Official_CardMixFeed__4&feed_filter=1&sudaref=www.google.com.hk
然后：
http://www.graphviz.org/pub/graphviz/stable/SOURCES/graphviz-2.26.0.tar.gz
安装后再执行
dot test1.dot -Tpng -o test1.png
出现错误：
Could not find/open font
shit

5. 认真看http://www.graphviz.org/Download..php提供的资源，然后下载：
   http://www.graphviz.org/Misc/fonts.tgz
然后修改dot文件：
digraph example2 {
    fontpath="/data/temp/ttf";
    Server1 -> Server2; Server2 -> Server3; Server3 -> Server1; }
再次执行测试：
dot test1.dot -Tpng -o test1.png

终于好了！

python xmind库初体验

1. *.xmind文件其实是一个zip文件，解压后是一堆XML文件；
2. xmind-python这个库操作XMIND的节点后，保存的时候无法保存样式……（郁闷）
3. 直接把XMIND文件解压缩，然后读写XML文件，应该可以实现带样式的保存（猜测的，时间有限，无法实验）
4. xmind-python的API很简单，看example.py就够了

python: 解决两例UnicodeDecodeError错误

1. 使用string.Template
在safe_substitute({"key":"value"})的时候出现UnicodeDecodeError错误，把字典的内容打印出来，发现有一个key是：  'key':u'value'
value里面都是ASCII码，只是碰巧是unicide类型。
于是写个循环把字典转换一下：
dict_temp = {}
for key in dict_param:
value = dict_param[key]
if type(key)==types.UnicodeType:
key = key.encode('utf-8')
if type(value)==types.UnicodeType:
value = value.encode('utf-8')
dict_temp[key] = value
dict_param = dict_temp
然后解决！

2. 在使用 '%s'%(param)格式化字符串的时候出现UnicodeDecodeError
所有param中没有UnicodeString类型，于是在
if __name__=='__main__':
     #在这里加上
      reload(sys)
      sys.setdefaultencoding('utf-8')

然后解决

web.py作为fast cgi部署到nginx上

部署方法都来自这个帖子：http://webpy.org/cookbook/fastcgi-nginx
我只是对一些细节进行补充说明

#perl 的正则表达式库
wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.33.tar.gz
tar -zxvf pcre-8.33.tar.gz
cd pcre-8.33
./configure && make && make install
#openssl，注意，只有1.0.0才能和nginx一起编译通过
wget http://www.openssl.org/source/openssl-1.0.0.tar.gz
tar -zxvf openssl-1.0.0.tar.gz
#不用编译openssl
cd nginx-1.4.2
./configure --sbin-path=/usr/local/nginx/nginx --conf-path=/usr/local/nginx/nginx.conf --pid-path=/usr/local/nginx/nginx.pid --without-select_module --without-poll_module --with-http_ssl_module --with-http_spdy_module --with-http_gunzip_module --with-http_gzip_static_module --with-openssl=/data/temp/openssl-1.0.0
make && make install
#
wget http://www.saddi.com/software/flup/dist/flup-1.0.1.tar.gz
tar -zxvf flup-1.0.1.tar.gz
cd flup-1.0.1
python setup.py build && python setup.py install

#

wget http://www.lighttpd.net/download/spawn-fcgi-1.6.3.tar.gz

tar -zxvf spawn-fcgi-1.6.3.tar.gz

cd spawn-fcgi-1.6.3 && make && make install

#下面配置nginx

location / {

        fastcgi_param REQUEST_METHOD $request_method;

        fastcgi_param QUERY_STRING $query_string;

        fastcgi_param CONTENT_TYPE $content_type;

        fastcgi_param CONTENT_LENGTH $content_length;

        fastcgi_param GATEWAY_INTERFACE CGI/1.1;

        fastcgi_param SERVER_SOFTWARE nginx/$nginx_version;

        fastcgi_param REMOTE_ADDR $remote_addr;

        fastcgi_param REMOTE_PORT $remote_port;

        fastcgi_param SERVER_ADDR $server_addr;

        fastcgi_param SERVER_PORT $server_port;

        fastcgi_param SERVER_NAME $server_name;

        fastcgi_param SERVER_PROTOCOL $server_protocol;

        fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;

        fastcgi_param PATH_INFO $fastcgi_script_name;

        fastcgi_pass 127.0.0.1:9002;

}

#配置static目录

    location /static/ {

        root /path/to/www;

        if (-f $request_filename) {

           rewrite ^/static/(.*)$  /static/$1 break;

        }

    }

#启动spawn-fcgi

#vi my_web.py

# 加上 

#!/usr/bin/env python

# -*- coding: utf-8 -*-

#注意文件本身不能是utf-8编码的

chmod +x my_web.py

chown -R user_0:users  my_web/

spawn-fcgi -d /data/my_web -f /data/my_web/my_web.py -a 127.0.0.1 -p 9002 -u user_0 -g users -F 5

换成nginx后，整个站点快了好多，爽多了！

javascript: 破坏引用导致的BUG

用代码来解释：
var g_array = [1,2,3];
function MyClass(arr){
   this.make_bug = function(){
      arr = [4,5,6];
   }

   this.remove_one = function(){
      arr.shift(0);
   }
}

//
var obj = MyClass(g_array);
obj.make_bug();
obj.remove_one();
//可以发现，全局数组根本没有被更改
//因为make_bug里面，破坏了对全局数组的引用

一个坑：crontab中使用sudo

最近，一个进程总是无法被crontab拉起，加了日志观察后，发现这一句错误信息：
sudo: sorry, you must have a tty to run sudo

google一下发现这篇帖子：http://gcoder.blogbus.com/logs/49929050.html

解决办法为：
vi /etc/sudoers
#注释掉 Defaults    requiretty

搞定！

为什么64位下用python调用C库发生了崩溃

在64位下，把一些库封装成C函数，然后编译成so文件供python调用，结果发生了崩溃。
今天试验后发现：如果C函数返回void*等类型，把返回值赋值到python变量后被截断，只剩下低32位的值。
因此，如果C函数中的指针在0xffffffff以上的地址的时候，返回到python中就会被截断。如果再继续使用这个被截断后的地址值，就会发生崩溃。

下面是模拟崩溃的代码：
//C
void* create_object()
{
    return new int(0);
}

void free_object(void* obj)
{
    delete (int*)obj;
}

#python中这样调用
so = cdll.LoadLibrary('xxxx.so')
obj = so.create_object()  #这里被截断
so.free_object(obj)       #这里发生崩溃

=====================================================
解决办法也比较简单，不要通过返回值传递指针，而通过指针参数返回：

void create_object(uint64_t* out)
{
    *out = (uint64_t)new int(0);
}

void free_object(void* obj)
{
    delete (int*)obj;
}



#python中这样调用
so = cdll.LoadLibrary('xxxx.so')
obj = ctypes.c_ulonglong(0)
so.create_object(ctypes.byref(obj))
obj = ctypes.c_void_p(obj.value)
so.free_object(obj)


这里要注意：发现python中的对象的地址都在0xffffffff之内，所以使用byref没发现问题。
byref是否会截断指针，这个还没试验出来。