JavaScript与有限状态机

有限状态机(Finite-state machine)是一个非常有用的模型,可以模拟世界上大部分事物。 bg2013090201 简单说,它有三个特征:

  * 状态总数(state)是有限的。 * 任一时刻,只处在一种状态之中。 * 某种条件下,会从一种状态转变(transition)到另一种状态。
它对JavaScript的意义在于,很多对象可以写成有限状态机。 举例来说,网页上有一个菜单元素。鼠标悬停的时候,菜单显示;鼠标移开的时候,菜单隐藏。如果使用有限状态机描述,就是这个菜单只有两种状态(显示和隐藏),鼠标会引发状态转变。 代码可以写成下面这样:

  var menu = {
  
    // 当前状态
    currentState: 'hide',
  
    // 绑定事件
    initialize: function() {
      var self = this;
      self.on("hover", self.transition);
    },
  
    // 状态转换
    transition: function(event){
      switch(this.currentState) {
        case "hide":
          this.currentState = 'show';
          doSomething();
          break;
        case "show":
          this.currentState = 'hide';
          doSomething();
          break;
        default:
          console.log('Invalid State!');
          break;
      }
    }
  
  };
  
可以看到,有限状态机的写法,逻辑清晰,表达力强,有利于封装事件。一个对象的状态越多、发生的事件越多,就越适合采用有限状态机的写法。 另外,JavaScript语言是一种异步操作特别多的语言,常用的解决方法是指定回调函数,但这样会造成代码结构混乱、难以测试和除错等问题。有限状态机提供了更好的办法:把异步操作与对象的状态改变挂钩,当异步操作结束的时候,发生相应的状态改变,由此再触发其他操作。这要比回调函数、事件监听、发布/订阅等解决方案,在逻辑上更合理,更易于降低代码的复杂度。 下面介绍一个有限状态机的函数库Javascript Finite State Machine。这个库非常好懂,可以帮助我们加深理解,而且功能一点都不弱。 该库提供一个全局对象StateMachine,使用该对象的create方法,可以生成有限状态机的实例。

  var fsm = StateMachine.create();
  
生成的时候,需要提供一个参数对象,用来描述实例的性质。比如,交通信号灯(红绿灯)可以这样描述:

  var fsm = StateMachine.create({
  
    initial: 'green',
  
    events: [
      { name: 'warn',  from: 'green',  to: 'yellow' },
      { name: 'stop', from: 'yellow', to: 'red' },
      { name: 'ready',  from: 'red',    to: 'yellow' },
      { name: 'go', from: 'yellow', to: 'green' }
    ]
  
  });
  
交通信号灯的初始状态(initial)为green,events属性是触发状态改变的各种事件,比如warn事件使得green状态变成yellow状态,stop事件使得yellow状态变成red状态等等。 生成实例以后,就可以随时查询当前状态。
* fsm.current :返回当前状态。 * fsm.is(s) :返回一个布尔值,表示状态s是否为当前状态。 * fsm.can(e) :返回一个布尔值,表示事件e是否能在当前状态触发。 * fsm.cannot(e) :返回一个布尔值,表示事件e是否不能在当前状态触发。
Javascript Finite State Machine允许为每个事件指定两个回调函数,以warn事件为例:
* onbeforewarn:在warn事件发生之前触发。 * onafterwarn(可简写成onwarn) :在warn事件发生之后触发。
同时,它也允许为每个状态指定两个回调函数,以green状态为例:
* onleavegreen :在离开green状态时触发。 * onentergreen(可简写成ongreen) :在进入green状态时触发。
假定warn事件使得状态从green变为yellow,上面四类回调函数的发生顺序如下:onbeforewarn → onleavegreen → onenteryellow → onafterwarn。 除了为每个事件和状态单独指定回调函数,还可以为所有的事件和状态指定通用的回调函数。
* onbeforeevent :任一事件发生之前触发。 * onleavestate :离开任一状态时触发。 * onenterstate :进入任一状态时触发。 * onafterevent :任一事件结束后触发。
如果事件的回调函数里面有异步操作(比如与服务器进行Ajax通信),这时我们可能希望等到异步操作结束,再发生状态改变。这就要用到transition方法。

  fsm.onleavegreen = function(){
    light.fadeOut('slow', function() {
      fsm.transition();
    });
    return StateMachine.ASYNC;
  };
  
上面代码的回调函数里面,有一个异步操作(light.fadeOut)。如果不希望状态立即改变,就要让回调函数返回StateMachine.ASYNC,表示状态暂时不改变;等到异步操作结束,再调用transition方法,使得状态发生改变。 Javascript Finite State Machine还允许指定错误处理函数,当发生了当前状态不可能发生的事件时自动触发。

  var fsm = StateMachine.create({
    // ...
    error: function(eventName, from, to, args, errorCode, errorMessage) {
      return 'event ' + eventName + ': ' + errorMessage;
    },
    // ...
  });
  
比如,当前状态是green,理论上这时只可能发生warn事件。要是这时发生了stop事件,就会触发上面的错误处理函数。 Javascript Finite State Machine的基本用法就是上面这些,更详细的介绍可以参见它的主页。]]>

利用cx_Freeze将py文件打包成exe文件(图文)

首先,当然是给一个目标系统安装 cx_freeze。虽然 cx_freeze 是跨平台的,但没发现它支持在一个平台上打包出另一个平台的二进制文件,而且那样还得准备那个平台上的库文件。我的目标平台是 Windows XP,所以还要准备一个 Dependency Walker

其次,使用cxfreeze-quickstart向导生成配置文件setup.py。当然,如果已经有setup.py文件的话直接修改就是了。下边是一个示例:

setup.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
import sys
from cx_Freeze import setup, Executable
# Dependencies are automatically detected, but it might need
# fine tuning.
buildOptions = dict(
  packages = [], excludes = [],
  include_files = ['images', 'data.sqlite'],
)
name = 'example'
if sys.platform == 'win32':
  name = name + '.exe'
base = None
if sys.platform == "win32":
    base = "Win32GUI"
executables = [
  Executable('main.py', base = base, targetName = name,
             compress = True,
            )
]
setup(name='Example',
      version = '1.0',
      description = 'An example program',
      options = dict(build_exe = buildOptions),
      executables = executables)

当然,这里有不少我改过的地方。在buildOptions变量中我加了data.sqlite文件和images目录到include_files中去。它们会被放到生成的二进制文件相同的目录。

cx_freeze 在打包 Windows 可执行文件时并不会像 gcc 那样自动添加.exe后缀,所以我要手动加上。

Executable的调用中,要写成base='Win32GUI'这样子。cxfreeze-quickstart目前直接写在第二个参数的位置上的方法是不对的。base的默认值是Console,在 Windows 下运行时是会出现黑色的cmd.exe窗口的。参见StackOverflow: Hide console window with wxPython and cxFreeze

这样还没有完成。打包后测试发现PyQt4.QtNetwork的库文件没有打包进去,可能是因为它是从共享库中引用的,cx_freeze 没有检测到这个依赖。在程序中 import 一下就可以了。另外一个问题是,在没有安装相关库的干净的目标系统上执行时还遇到以下错误信息:

1
2
DLL load failed: 找不到指定的模块
DLL load failed: The specified module could not be found.

其上还有一个 Traceback。这是因为有些(据说主要是 Microsoft Visual C++ Redistributable 的) DLL (非 Python 模块)没有被打包进去。从 Traceback 中找到引发这个错误的 DLL(或者 pyd)文件名,将其在打包系统中使用前边提到的 Dependency Walker 打开,在左边的树形库列表中找到目标系统上可能没有的库文件,将其复制到 cx_freeze 生成二进制文件的目录中即可。比如我这里需要手动添加msvcr100.dllmsvcp100.dll

最后,打包过的程序执行时__main__模块是没有__file__属性的,所以无法通过这个变量来切换到程序所在的目录,进而读取自己的数据文件。但是,打包过的程序有sys.frozen属性,程序自身的路径存放在sys.executable中,所以程序中需要作下判断:

1
2
3
4
5
6
7
8
import os
import sys
if hasattr(sys, 'frozen'):
  me = sys.executable
else:
  me = __file__
mydir = os.path.dirname(me)

参见StackOverflow: How do I get the path of the current executed file in python?

最终打出来的可执行文件和库文件比较大,PyQt 程序总共有 40M 之多。使用 7z 压缩之后能减小到 10M 多。

]]>

如何撰写引人入胜的电子邮件主题

在电子邮件营销中,第一印象至关重要,这里的第一印象就是您的电子邮件主题。如果您的企业将电子邮件用于营销目的,须知邮件主题是订阅者决定打开并阅读您邮件的主要决定因素。提高邮件打开率可提高用户转换率和维系率,这意味着可为您的企业创造更多收益。您撰写的邮件主题所引发的读者期望与邮件内容的匹配度越高,可达成的用户转换数量就越多,长远来看订阅者的忠诚度和响应度也就越高。

牢记这一点后,下面介绍撰写电子邮件主题的几种方法,用于吸引和提高订阅者的参与度:

首先从使用最恰当的字数开始
根据最近的一项研究,六至十个词的邮件主题效果最佳,有 21% 的订阅者会打开这样的电子邮件; 16% 的订阅者会打开主题为五个词及以下的邮件 [1]。请思考电子邮件在手机、平板电脑甚至在台式机上的显示方式,这就是为何要使用最恰当的主题字数的原因。过长的主题会被隐藏一部分,从而使订阅者无法一览您邮件的主要内容。另外请牢记,有 51% 的电子邮件是在移动设备上打开的 [2],移动设备的屏幕较小,一般不能显示 50 个字符以上的邮件主题(单击此处了解有关优化移动设备电子邮件显示的更多提示内容)。

运用生动的表述来吸引和转换客户
如果您的小型企业尚未建立自己独特的品牌形象,那么现在是时候考虑了。您的订阅者是否会对俏皮、风趣的语言做出响应?还是应当直奔主题? 如果您的品牌偏重休闲,则使用表情符号是吸引眼球的绝佳方式,或者可以尝试使用只有两到三个词的邮件主题来吸引注意力。其他技巧包括:采用紧急事件语气(如促销或活动即将结束,这种方法特别有效),在电子邮件中直呼订阅者的名字。

别忘了使用邮件引文和“发件人”行
邮件引文和“发件人”行也发挥着重要作用。在移动环境和 Web 邮件环境中,邮件引文(有时被称为预览摘要)是紧随邮件主题后出现的灰显文本。如果说邮件主题将开启一扇门,邮件引文则为您提供后文内容的提示。换句话说,这里是您插入辅助信息或价值主张的绝佳位置,在邮件主题行中却不具备这么多空间。另外,“发件人”行应始终一致(通常填写您公司的名称),这一点至关重要。这样邮件订阅者就能将您添加到其通讯录中,从而避免您的邮件被归类到垃圾邮件箱。

切勿使用触发反垃圾邮件机制的敏感词
说到垃圾邮件,有数百个词条会导致您的电子邮件被归类到垃圾邮件箱。例如“免费”(以及“免 费”等变体)、“钱”、“您中奖了”、“恭喜”以及美元符号等。有多种方式可以避开使用垃圾邮件敏感词而表达同样的意思。可以尝试使用“礼品” (freebie) 代替“免费”(free),或用“祝贺” (congrats) 代替“恭喜” (congratulation)。记住,上述只是一般指导原则。与主题行中可能的垃圾邮件敏感词相比,发件人的信用度要重要得多 [3]。还有一些免费工具可用于评价电子邮件主题的质量,登录 subjectline.com 即可开始使用。

没有万能公式
如果有人发明了能生成完美电子邮件主题的傻瓜公式,这个人一定会发财的。事实证明,不同的企业适用不同的方法,通过不断尝试和犯错,您会找到最适合自己的方法。只要条件允许,请务必用 A、B 两套方案来测试电子邮件主题的效果,观察哪种方案更符合订阅者的口味。此外,务必牢记:订阅者容易对电子邮件产生疲劳感。本月有效的电子邮件主题下个月可能就不凑效了。电子邮件主题是一个移动目标,但只要您不断尝试,您的电子邮件营销策略就会始终独占鳌头。]]>

利用Squid反向代理搭建CDN缓存服务器加快Web访问速度

http://520tom.blog.51cto.com/530608/1347098

案例: Web服务器:域名www.abc.com IP:192.168.21.129 电信单线路接入 访问用户:电信宽带用户、移动宽带用户 出现问题:电信用户打开www.abc.com正常,移动用户打开www.abc.com很慢,甚至打不开 解决方案:在移动机房放置一台CDN代理服务器,通过智能DNS解析,让电信用户直接访问Web服务器、让移动用户访问CDN代理服务器,解决移动用户访问Web服务器慢的问题 具体操作: CDN代理服务器: 系统:CentOS 5.5 主机名:cdn.abc.com IP:192.168.21.160 安装Squid软件,配置反向代理搭建CDN缓存服务器 安装前准备: 1、关闭SELinux vi /etc/selinux/config #SELINUX=enforcing     #注释掉 #SELINUXTYPE=targeted  #注释掉 SELINUX=disabled  #增加 :wq  保存,关闭。 shutdown -r now重启系统

2、开启防火墙80端口(后面配置squid的端口为80) vi /etc/sysconfig/iptables 添加下面的内容 -A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT /etc/init.d/iptables restart  #重启防火墙使配置生效

3、修改主机的路由模式 vi /etc/sysctl.conf net.ipv4.ip_forward = 1    #0为关闭,1为开启路由 使用sysctl -p 命令查看 系统运维  www.osyunwei.com  温馨提醒:qihang01原创内容版权所有,转载请注明出处及原文链接 4、修改主机hosts文件,增加域名解析记录 vi /etc/hosts 192.168.21.129  www.abc.com    #添加解析记录

=========================================================================== 安装开始 1、安装Squid yum install squid   #安装(Squid 2.6) service squid start #启动 service squid restart #重启 chkconfig squid on  #设置开机启动

2、配置Squid cp /etc/squid/squid.conf /etc/squid/squid.confbak  #备份 vi  /etc/squid/squid.conf  #编辑文件 http_port 80 transparent  #设置squid端口,默认为3128,设置为80,客户端打开网站的时候不需要输入端口号 cache_mem 1024 MB   #分配内存大小 cache_dir ufs /var/spool/squid 4096 16 256 #设置缓存文件大小 cache_effective_user squid  #设置用户 cache_effective_group squid  #设置用户组 access_log /var/log/squid/access.log   #设置访问日志文件 cache_log /var/log/squid/cache.log  #设置缓存日志文件 cache_store_log /var/log/squid/store.log  #设置缓存记录文件 visible_hostname cdn.abc.com  #设置squid服务器主机名 cache_mgr root@abc.com  #设置管理员邮箱(设置为自己的邮箱地址) acl all src 0.0.0.0/0.0.0.0  #设置访问控制列表,默认开启 http_access allow all  #设置访问权限,默认注释掉的 cache_peer 192.168.21.129 parent 80 0 no-query originserver name=web  #用户访问web时,Squid向192.168.21.129的80端口发送请求 cache_peer_domain web www.abc.com  #设置web域名为www.abc.com cache_peer_access web allow all  #设置访问权限,允许所有外部客户端访问web :wq!  #保存退出 service squid stop  #停止 /usr/sbin/squid  -z  #初始化cache缓存目录 service squid start #启动 Squid反向代理服务器安装配置完成 ================================================================== 启用智能DNS解析: 如果是电信用户访问域名www.abc.com解析到192.168.21.128 如果是移动用户访问域名www.abc.com解析到192.168.21.160 CDN缓存服务器与Web服务器之间采用专线连接

]]>

关于Linux静态库和动态库的分析

http://www.cnblogs.com/hzh1024n/archive/2009/09/17/1568357.html 1.什么是库 在windows平台和linux平台下都大量存在着库。 本质上来说库是一种可执行代码的二进制形式,可以被操作系统载入内存执行。 由于windows和linux的本质不同,因此二者库的二进制是不兼容的。 本文仅限于介绍linux下的库。 2.库的种类 linux下的库有两种:静态库和共享库(动态库)。 二者的不同点在于代码被载入的时刻不同。 静态库的代码在编译过程中已经被载入可执行程序,因此体积较大。 共享库的代码是在可执行程序运行时才载入内存的,在编译过程中仅简单的引用,因此代码体积较小。 3.库存在的意义 库是别人写好的现有的,成熟的,可以复用的代码,你可以使用但要记得遵守许可协议。 现实中每个程序都要依赖很多基础的底层库,不可能每个人的代码都从零开始,因此库的存在意义非同寻常。 共享库的好处是,不同的应用程序如果调用相同的库,那么在内存里只需要有一份该共享库的实例。 4.库文件是如何产生的在linux下 静态库的后缀是.a,它的产生分两步 Step 1.由源文件编译生成一堆.o,每个.o里都包含这个编译单元的符号表 Step 2.ar命令将很多.o转换成.a,成文静态库 动态库的后缀是.so,它由gcc加特定参数编译产生。 例如:

$ gcc -fPIC -c *.c $ gcc -shared -Wl,-soname, libfoo.so.1 -o libfoo.so.1.0 *.
5.库文件是如何命名的,有没有什么规范 在linux下,库文件一般放在/usr/lib /lib下, 静态库的名字一般为libxxxx.a,其中xxxx是该lib的名称 动态库的名字一般为libxxxx.so.major.minor,xxxx是该lib的名称,major是主版本号, minor是副版本号 6.如何知道一个可执行程序依赖哪些库 ldd命令可以查看一个可执行程序依赖的共享库, 例如
# ldd /bin/lnlibc.so.6 => /lib/libc.so.6 (0×40021000)/lib/ld-linux.so.2 => /lib/ld- linux.so.2 (0×40000000)
可以看到ln命令依赖于libc库和ld-linux库 7.可执行程序在执行的时候如何定位共享库文件 当系统加载可执行代码时候,能够知道其所依赖的库的名字,但是还需要知道绝对路径 此时就需要系统动态载入器(dynamic linker/loader) 对于elf格式的可执行程序,是由ld-linux.so*来完成的,它先后搜索elf文件的 DT_RPATH段—环境变量LD_LIBRARY_PATH—/etc/ld.so.cache文件列表—/lib/,/usr/lib目录找到库文件后将其载入内存 8.在新安装一个库之后如何让系统能够找到他 如果安装在/lib或者/usr/lib下,那么ld默认能够找到,无需其他操作。 如果安装在其他目录,需要将其添加到/etc/ld.so.cache文件中,步骤如下 1.编辑/etc/ld.so.conf文件,加入库文件所在目录的路径 2.运行ldconfig,该命令会重建/etc/ld.so.cache文件 我们通常把一些公用函数制作成函数库,供其它程序使用。函数库分为静态库和动态库两种。静态库在程序编译时会被连接到目标代码中,程序运行时将不再需要该静态库。动态库在程序编译时并不会被连接到目标代码中,而是在程序运行是才被载入,因此在程序运行时还需要动态库存在。本文主要通过举例来说明在Linux中如何创建静态库和动态库,以及使用它们。在创建函数库前,我们先来准备举例用的源程序,并将函数库的源程序编译成.o文件。 第1步:编辑得到举例的程序–hello.h、hello.c和main.c; hello.h(见程序1)为该函数库的头文件。 hello.c(见程序2)是函数库的源程序,其中包含公用函数hello,该函数将在屏幕上输出”Hello XXX!”。 main.c(见程序3)为测试库文件的主程序,在主程序中调用了公用函数hello。 程序1: hello.h
#ifndef HELLO_H #define HELLO_H void hello(const char *name); #endif //HELLO_H
程序2: hello.c
#include <stdio.h> void hello(const char *name) { printf(“Hello %s!\n”, name); }
程序3: main.c
#include “hello.h” int main() { hello(“everyone”); return 0; }
第2步:将hello.c编译成.o文件; 无论静态库,还是动态库,都是由.o文件创建的。因此,我们必须将源程序hello.c通过gcc先编译成.o文件。 在系统提示符下键入以下命令得到hello.o文件。
# gcc -c hello.c #
(注1:本文不介绍各命令使用和其参数功能,若希望详细了解它们,请参考其他文档。) (注2:首字符”#”是系统提示符,不需要键入,下文相同。) 我们运行ls命令看看是否生存了hello.o文件。
# ls hello.c hello.h hello.o main.c #
(注3:首字符不是”#”为系统运行结果,下文相同。) 在ls命令结果中,我们看到了hello.o文件,本步操作完成。 下面我们先来看看如何创建静态库,以及使用它。 第3步:由.o文件创建静态库; 静态库文件名的命名规范是以lib为前缀,紧接着跟静态库名,扩展名为.a。例如:我们将创建的静态库名为myhello,则静态库文件名就是libmyhello.a。在创建和使用静态库时,需要注意这点。创建静态库用ar命令。 在系统提示符下键入以下命令将创建静态库文件libmyhello.a。
# ar cr libmyhello.a hello.o #
我们同样运行ls命令查看结果:
# ls hello.c hello.h hello.o libmyhello.a main.c #
ls命令结果中有libmyhello.a。 第4步:在程序中使用静态库; 静态库制作完了,如何使用它内部的函数呢?只需要在使用到这些公用函数的源程序中包含这些公用函数的原型声明,然后在用gcc命令生成目标文件时指明静态库名,gcc将会从静态库中将公用函数连接到目标文件中。注意,gcc会在静态库名前加上前缀lib,然后追加扩展名.a得到的静态库文件名来查找静态库文件。 在程序3:main.c中,我们包含了静态库的头文件hello.h,然后在主程序main中直接调用公用函数hello。下面先生成目标程序hello,然后运行hello程序看看结果如何。
# gcc -o hello main.c -L. -lmyhello # ./hello Hello everyone! #
我们删除静态库文件试试公用函数hello是否真的连接到目标文件 hello中了。
# rm libmyhello.a rm: remove regular file `libmyhello.a’? y # ./hello Hello everyone! #
程序照常运行,静态库中的公用函数已经连接到目标文件中了。 我们继续看看如何在Linux中创建动态库。我们还是从.o文件开始。 第5步:由.o文件创建动态库文件; 动态库文件名命名规范和静态库文件名命名规范类似,也是在动态库名增加前缀lib,但其文件扩展名为.so。例如:我们将创建的动态库名为myhello,则动态库文件名就是libmyhello.so。用gcc来创建动态库。 在系统提示符下键入以下命令得到动态库文件libmyhello.so。
# gcc -shared -fPCI -o libmyhello.so hello.o #
我们照样使用ls命令看看动态库文件是否生成。
# ls hello.c hello.h hello.o libmyhello.so main.c #
第6步:在程序中使用动态库; 在程序中使用动态库和使用静态库完全一样,也是在使用到这些公用函数的源程序中包含这些公用函数的原型声明,然后在用gcc命令生成目标文件时指明动态库名进行编译。我们先运行gcc命令生成目标文件,再运行它看看结果。
# gcc -o hello main.c -L. -lmyhello # ./hello ./hello: error while loading shared libraries: libmyhello.so: cannot open shared object file: No such file or directory #
哦!出错了。快看看错误提示,原来是找不到动态库文件libmyhello.so。程序在运行时,会在/usr/lib和/lib等目录中查找需要的动态库文件。若找到,则载入动态库,否则将提示类似上述错误而终止程序运行。我们将文件libmyhello.so复制到目录/usr/lib中,再试试。
# mv libmyhello.so /usr/lib # ./hello ./hello: error while loading shared libraries: /usr/lib/libhello.so: cannot restore segment prot after reloc: Permission denied
由于SELinux引起,
# chcon -t texrel_shlib_t /usr/lib/libhello.so # ./hello Hello everyone! #
成功了。这也进一步说明了动态库在程序运行时是需要的。 我们回过头看看,发现使用静态库和使用动态库编译成目标程序使用的gcc命令完全一样,那当静态库和动态库同名时,gcc命令会使用哪个库文件呢?抱着对问题必究到底的心情,来试试看。 先删除 除.c和.h外的 所有文件,恢复成我们刚刚编辑完举例程序状态。
# rm -f hello hello.o /usr/lib/libmyhello.so # ls hello.c hello.h main.c #
在来创建静态库文件libmyhello.a和动态库文件libmyhello.so。
# gcc -c hello.c # ar cr libmyhello.a hello.o # gcc -shared -fPCI -o libmyhello.so hello.o # ls hello.c hello.h hello.o libmyhello.a libmyhello.so main.c #
通过上述最后一条ls命令,可以发现静态库文件libmyhello.a和动态库文件libmyhello.so都已经生成,并都在当前目录中。然后,我们运行gcc命令来使用函数库myhello生成目标文件hello,并运行程序 hello。
# gcc -o hello main.c -L. -lmyhello # ./hello ./hello: error while loading shared libraries: libmyhello.so: cannot open shared object file: No such file or directory #
从程序hello运行的结果中很容易知道,当静态库和动态库同名时, gcc命令将优先使用动态库。 基本概念 库有动态与静态两种,动态通常用.so为后缀,静态用.a为后缀。 例如:libhello.so libhello.a 为了在同一系统中使用不同版本的库,可以在库文件名后加上版本号为后缀,例如: libhello.so.1.0,由于程序连接默认以.so为文件后缀名。所以为了使用这些库,通常使用建立符号连接的方式。
ln -s libhello.so.1.0 libhello.so.1 ln -s libhello.so.1 libhello.so
1、使用库 当要使用静态的程序库时,连接器会找出程序所需的函数,然后将它们拷贝到执行文件,由于这种拷贝是完整的,所以一旦连接成功,静态程序库也就不再需要了。然 而,对动态库而言,就不是这样。动态库会在执行程序内留下一个标记指明当程序执行时,首先必须载入这个库。由于动态库节省空间,linux下进行连接的缺省操作是首先连接动态库,也就是说,如果同时存在静态和动态库,不特别指定的话,将与动态库相连接。 现在假设有一个叫hello的程序开发包,它提供一个静态库libhello.a 一个动态库libhello.so,一个头文件hello.h,头文件中提供sayhello()这个函数 /* hello.h */ void sayhello(); 另外还有一些说明文档。 这一个典型的程序开发包结构 与动态库连接 linux默认的就是与动态库连接,下面这段程序testlib.c使用hello库中的sayhello()函数
/*testlib.c*/ #include <hello.h> #include <testlib.h> int main() { sayhello(); return 0; }
使用如下命令进行编译 $gcc -c testlib.c -o testlib.o 用如下命令连接: $gcc testlib.o -lhello -o testlib 连接时要注意,假设libhello.o 和libhello.a都在缺省的库搜索路径下/usr/lib下,如果在其它位置要加上-L参数 与与静态库连接麻烦一些,主要是参数问题。还是上面的例子:
$gcc testlib.o -o testlib -WI,-Bstatic -lhello
注:这个特别的”-WI,-Bstatic”参数,实际上是传给了连接器ld。指示它与静态库连接,如果系统中只有静态库当然就不需要这个参数了。 如果要和多个库相连接,而每个库的连接方式不一样,比如上面的程序既要和libhello进行静态连接,又要和libbye进行动态连接,其命令应为:
$gcc testlib.o -o testlib -WI,-Bstatic -lhello -WI,-Bdynamic -lbye
2、动态库的路径问题 为了让执行程序顺利找到动态库,有三种方法: (1)把库拷贝到/usr/lib和/lib目录下。 (2)在LD_LIBRARY_PATH环境变量中加上库所在路径。 例如动态库libhello.so在/home/ting/lib目录下,以bash为例,使用命令:
$export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/ting/lib
(3) 修改/etc/ld.so.conf文件,把库所在的路径加到文件末尾,并执行ldconfig刷新。这样,加入的目录下的所有库文件都可见。 3、查看库中的符号 有时候可能需要查看一个库中到底有哪些函数,nm命令可以打印出库中的涉及到的所有符号。库既可以是静态的也可以是动态的。nm列出的符号有很多,常见的有三种: 一种是在库中被调用,但并没有在库中定义(表明需要其他库支持),用U表示; 一种是库中定义的函数,用T表示,这是最常见的; 另外一种是所谓的“弱 态”符号,它们虽然在库中被定义,但是可能被其他库中的同名符号覆盖,用W表示。 例如,假设开发者希望知道上文提到的hello库中是否定义了 printf():
$nm libhello.so |grep printf U
其中printf U表示符号printf被引用,但是并没有在函数内定义,由此可以推断,要正常使用hello库,必须有其它库支持,再使用ldd命令查看hello依赖于哪些库:
$ldd hello libc.so.6=>/lib/libc.so.6(0x400la000) /lib/ld-linux.so.2=>/lib/ld-linux.so.2 (0x40000000)
从上面的结果可以继续查看printf最终在哪里被定义,有兴趣可以go on 4、生成库 第一步要把源代码编绎成目标代码。 以下面的代码为例,生成上面用到的hello库:
/* hello.c */ #include <stdio.h> void sayhello() { printf(“hello,world “); }
用gcc编绎该文件,在编绎时可以使用任何全法的编绎参数,例如-g加入调试代码等: gcc -c hello.c -o hello.o (1)连接成静态库 连接成静态库使用ar命令,其实ar是archive的意思
$ar cqs libhello.a hello.o
(2)连接成动态库 生成动态库用gcc来完成,由于可能存在多个版本,因此通常指定版本号:
$gcc -shared -Wl,-soname,libhello.so.1 -o libhello.so.1.0 hello.o
另外再建立两个符号连接:
$ln -s libhello.so.1.0 libhello.so.1 $ln -s libhello.so.1 libhello.so
这样一个libhello的动态连接库就生成了。最重要的是传gcc -shared 参数使其生成是动态库而不是普通执行程序。 -Wl 表示后面的参数也就是-soname,libhello.so.1直接传给连接器ld进行处理。实际上,每一个库都有一个soname,当连接器发现它正在查找的程序库中有这样一个名称,连接器便会将soname嵌入连结中的二进制文件内,而不是它正在运行的实际文件名,在程序执行期间,程序会查找拥有 soname名字的文件,而不是库的文件名,换句话说,soname是库的区分标志。 这样做的目的主要是允许系统中多个版本的库文件共存,习惯上在命名库文件的时候通常与soname相同 libxxxx.so.major.minor 其中,xxxx是库的名字,major是主版本号,minor 是次版本号]]>

gcc链接库顺序问题解决

-l library Search the library named library when linking. (The second alter- native with the library as a separate argument is only for POSIX compliance and is not recommended.) It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. Thus, foo.o -lz bar.o searches library z after file foo.o but before bar.o. If bar.o refers to functions in z, those functions may not be loaded. 出于知识产权保护的考虑,每一个项目组可能只允许看到自己的代码和别的项目组的头文件,这给CI小组带来了很头痛的事情,很多时候你不得不把库顺序来回调整。我也遇到了这样让人崩溃的情形,问题是对于liba.ar和libb.ar相互以来的情形,你可能最终采取丑陋的做法,将其中一个库在前后放两次: gcc -o out.bin liba.ar libb.ar liba.ar -lrt 否则,您将不得不面对 “xx not referenced”之类的错误。 看看gcc的帮助,有下面的选项

-Xlinker option Pass option as an option to the linker. You can use this to supply system-specific linker options which GCC does not know how to rec- ognize. If you want to pass an option that takes an argument, you must use -Xlinker twice, once for the option and once for the argument. For example, to pass -assert definitions, you must write -Xlinker -assert -Xlinker definitions. It does not work to write -Xlinker “-assert definitions”, because this passes the entire string as a single argument, which is not what the linker expects.
也就是说,-Xlinker是将连接选项传给连接器的,赶快看看ld的帮助有没有解决库顺序的选项吧: -( archives -)
–start-group archives –end-group The archives should be a list of archive files. They may be either explicit file names, or -l options. The specified archives are searched repeatedly until no new unde- fined references are created. Normally, an archive is searched only once in the order that it is specified on the command line. If a symbol in that archive is needed to resolve an undefined sym- bol referred to by an object in an archive that appears later on the command line, the linker would not be able to resolve that ref- erence. By grouping the archives, they all be searched repeatedly until all possible references are resolved. Using this option has a significant performance cost. It is best to use it only when there are unavoidable circular references between two or more archives.
不错,我们有个有点怪异的选项,-(和-),它能够强制”The specified archives are searched repeatedly” god,这就是我们要找的啦。 最终的做法:
gcc -o output.bin -Xlinker “-(” liba.ar libb.ar -Xlinker “-)” -lrt
这样可以解决库顺序的问题了!问题是,如果你的库相互间的依赖如果错综复杂的话,可能会增加连接的时间,不过,做架构设计的都应该能考虑到这些问题吧。]]>

变速箱技术路径分化 双离合对决无级变速

Img4037751181 目前,汽车市场上搭载的主流自动变速器分为四类:AMT(机械式自动变速箱)、AT(自动变速箱)、CVT(无级变速箱)、DCT(双离合变速箱)。其中,在CVT和DCT的选择上,以日产、丰田为代表的日系车企和以大众、奥迪为代表的德系车企出现了分化。 截止目前,丰田在全球范围内已有大量车型搭载了CVT,2013年搭载CVT的车型超过了100万辆,并首次在中国市场实现国产化生产;日产旗下的车型更是广泛搭载CVT,并不断地进行技术改造,以期实现更优越的操控性和燃油经济性。但与此同时,奥迪却在近日宣布未来将不再使用CVT,转而主攻DCT(内部称DSG)。 日产改良CVT变速箱 引入D-Step换挡模式 据《美国汽车新闻》8月初报道,日产汽车准备通过软件更改,赋予无级变速箱CVT(Continuously Variable Automatic Transmission)接近自动变速箱AT的驾驶感受。 CVT摒弃了传统自动变速箱耗油的液力传动装置,具备节油等优点,但由于没有固定挡位,”降档提速”等技巧并无用武之地,导致操作感下降。 为此,日产引入D-Step换挡模式,使得驾驶过程中”CVT不再那么像CVT”。在D-Step换挡模式下,CVT给司机带来传统自动变速箱的换挡感受,但实际上却并非按照级数换挡。日产通过软件变化,在4,000rpm转速条件下,根据车速早于速比变化调整传动,营造出类似换挡的体验。 D-Step换挡模式将用于2015款Versa、Versa Note、Sentra(北美版阳光)、Altima(北美版天籁)V-6、探路者(Pathfinder)和Quest等车型。此前,该换挡模式已经率先用于2013款四缸发动机的Altima,以及2014款Rogue(北美版奇骏)。 丰田S-CVT专供中国市场 可模拟8速换挡 7月30日,丰田汽车(常熟)零部件有限公司(简称TMCAP)在江苏常熟开业,工厂正式开始生产搭载于新一代卡罗拉以及雷凌车上的S-CVT变速箱。此次在华投产的变速箱是丰田第三代CVT产品,拥有更高新的技术。 新一代S-CVT专门针对中国消费者需求和中国的道路环境进行开发和调校,此款S-CVT是”专供中国市场”的产品。S-CVT中的S代表着”Smart”、”Super”以及”Sport” ,凸显该CVT的智能化的特点,能为驾驶者提供随心所欲的驾驶体验。该款S-CVT可模拟8速换挡,能够同时满足中国消费者”实现低油耗”和”追求车辆驾驶乐趣”的需求。 除了新卡罗拉以及雷凌这两款重点车型外,此款国产S-CVT变速箱未来还将搭载在丰田的埃尔法、逸致、RAV4以及普瑞维亚总共六款车型上。除此之外,TMCAP今后还将为丰田混合动力车生产变速驱动桥。 奥迪拟放弃CVT无级变速箱 主攻7速DSG 国外媒体Autoevolution于7月下旬报道称,奥迪公司将不再为旗下新车型搭载CVT变速器,未来将重点发展7速DSG双离合变速器。目前,奥迪公司已经停止了CVT变速器的相关研发工作,并计划在明年推出全新的7速双离合变速器,并将其最先装配到新一代奥迪A4车型上。 在奥迪及其母公司大众汽车,DCT被称作”直接换挡变速箱”DSG(Direct Shift Gearbox),而CVT则被称作”Multitronic”。 奥迪公司操控系统开发工程师拉夫·雷格表示,CVT变速器可以帮助车辆提升燃油经济性,但其对于改善车型操控特性的作用并不大。CVT变速箱随着发动机转速升高需要持续调整变速级数,从前该类变速箱以”无缝”换挡著称,而如今DSG也可以实现类似的特点。之前奥迪采用CVT的原因是其有利于燃油经济性,而如今新一代有级数的变速箱性能更好。 德系DCT对抗日系CVT 技术路径不同选择不一 目前,日系汽车制造商包括丰田、本田、日产等都更倾向于选择CVT,而以大众为代表的德系汽车制造商则更加倾向于选择DCT。 CVT在提高发动机效率方面更有优势,但DCT在提高变速器效率方面则更加优秀,双方所选择的技术路径不太一样,因此也很难说孰优孰劣。 据丰田技术专家解释称,在发动机扭矩较小的车辆上,更适合搭载CVT,可以更加充分地发挥发动机性能;但超过这个区域之后,DCT更加合适。 不过,两种变速器也都有自身的缺点,例如在使用的感觉上来说,CVT在实现平顺性的同时,也有可能给消费者带来很”肉”而动力不足的感觉,而DCT换挡的平顺性就显然不如CVT那么”毫无感觉”,顿挫感会比较明显。]]>

Linux创始人曾经小看 Mac OS X

img201106201216580 1997年,Steve Jobs回归,开发下一代操作系统的工作被提上日程。此刻的时代背景是像Linux这样的开源软件大行其道。随着网络的发展,使得像Red Hat、VA Linux之类的企业成为爆发户,把泡沫越吹越大。Steve Jobs承认Linux的好处,甚至在若干年后介绍Mac OS X底层的Darwin时还不忘在幻灯片上写道:Darwin是类似Linux的系统。而当时精明的Steve Job在考虑下面几个问题。 第一,NeXTSTEP的内核和外围工具中,BSD代码维护起来需要大量人力,而且各分支的BSD发展显然不如Linux快。很多功能都没有,需要Apple自己做。 第二,像Apple这样的小公司,需要借力打力。Apple的主要竞争对手是Microsoft,而开源软件的矛头也是Microsoft,如果联合起来干革命,不但能让自己得到一个好名声(Apple事后一直自称是最大的开源软件公司),也可以获得可观利益,从而对Microsoft造成压力。 第三,也是最重要的,联合各开源组织能够推动Mac OS的发展。毕竟开源软件中像GCC之类都是很成熟的项目,Apple用起来省时省力,投点钱就有大效益,多好。 所以,把Linux内核作为Mac OS X的重要组成部分的想法被这位伟大的智者想了出来。Apple之前也有开发Linux的经验,比如在Steve Jobs回归之前,Apple就和OSF合作开始把Mach内核移植到PowerPC上(Apple是最大的PowerPC玩家,而OSF是最大的 Mach玩家),并把Linux作为服务跑在Mach上。这个系统就是MkLinux,我们在后续的连载中还会提到这个系统,因为它不但对Linux的移植性作出了重要的贡献,也对后来的Mac OS X的XNU内核技术起到了相当重要的作用。 如果可以采用Linux作为系统重要组成部分,并且这个构想能够取得在开源软件界呼风唤雨的Linus Torvalds的认同,就能靠他在社区鼓动一大群开发者皈依Apple麾下,这是Apple很想看到的给力结局。有了这个指导思想,他便让秘书给 Linux的开发者Linus Torvalds发了一个邮件,问他是不是有一到两小时的时间和Steve Jobs会面。不明真相的Linus Torvalds收到邮件后相当高兴,因为这是他第一次有机会去硅谷观摩。 无果而终的会面 Apple 总部Infinity Loop终于迎来了这位稀客,Steve Jobs亲自接见,而先前任NeXT技术总监的Avie Tevanian也参加了这次会谈。不用多说,这次讨论的内容自然是还处于未知状态的Mac OS X。讨论算不上正式,但Linus Torvalds的愤青个性,却让谈判陷入僵局。 Steve Jobs自然搬出他1997年回归之际在MacWorld讲话时的那套理论,Apple虽然很颓,但骨子里是个牛逼的公司。全世界桌面领域的真正玩家就两个,一个是Apple,另一个是Microsoft,两者加起来,构成百分之百的桌面用户群。所以,Linus同学,你就从了我们吧,如果你从了我们,让我们把Mac架在Linux上,一大批桌面用户就是Linux用户啦,前景可是一片大好! 而Linus Torvalds那时候牛啊,诸多大公司如IBM、Red Hat都围着他转。他可是企业家中的大红人,像Apple这样的企业根本就不在他眼里。作为一个开源软件的革命家,在他的想象中Linux的潜在用户应该比Apple还多。他始终相信,按照目前开源软件的发展态势,自己很快就能在桌面领域分到一杯羹。而且这个命题在他这种古怪性格下的直接推论是,即使我能占领桌面领域,我也要摆出一副不在乎这个领域的态度来。所以实际上Steve Jobs的开场白就失败了。 接着,Avie Tevanian向Linus Torvalds介绍了整个计划。他们想把Mach和Linux内核合并起来作为Mac OS X的基础,我估计Linus Torvalds是听错了(因为Avie Tevanian很早就意识到相比于微内核,混合内核有明显优势),他以为Apple想把Linux作为Mach的一个服务来跑(当然我个人认为,即使是合并Mach和Linux成为混合内核,依Linus Torvalds的愤青性格,依然是不可能接受的),这正让他回想到先前和Tanenbaum教授的笔战。并且,他也知道Apple和IBM合搞的失败项目Taligent正是用Mach的。 Linus Torvalds对于微内核有他自己的看法,之前也曾在不同的地方表述过。若把关于微内核的笔战去掉限制级敏感词的话可概括成两方面。一方面,设计一个微内核和相关的服务,可能造成各种设计上的灾难。GNU/Hurd早在八十年代末就考虑尝试在Mach上写一系列Unix的服务层,结果他们始终无法搞明白到底是让这些服务先发消息到另几个服务呢,还是考虑其他方案。所以直到2011年我写这篇文章时,Hurd项目依然处于半死不活的状态。而另一方面,微内核的效率无法和传统内核相比,最简单的系统调用会涉及一系列底层服务的互相通信。所以很多研究者着手研究如何把微内核的效率提上去,结果就导致微内核变得更加复杂。能提高微内核效率的很多研究成果都已在Mach项目中实现了。而在Linus Torvalds看来这恰使Mach成为了一个非常复杂的项目,并且效率也不怎么高。 会谈时坐一旁的Avie Tevanian事实上是Mach最早的开发者之一,他热情地给Linus讲述Mac OS X系统蓝图。而Linus实际上早就不耐烦了。比如,Mac OS X中,有一个模拟层,可让用户使用经典的Mac OS程序。这个技术极类似于现在跑在Unix系统上执行Windows程序的Wine。Apple当时的考虑是这样,因为老的Mac OS在设计API时,就没有考虑到类似内存保护之类的问题,所以这层API必须废掉,Mac OS X中所有的新程序必须采用NeXT的那套更先进的API(根据我的考证,当时还没有Carbon这样的想法,而且事实上Carbon不管在API还是 ABI上都和经典Mac OS不兼容)。而短期内已有的软件又不可能快速重写迁移至Mac OS X。所以,如果用户需要使用老版Mac OS的第三方应用程序,就可以使用Apple提供的这个兼容层。但是由于刚才提到的原因,老版程序并不享受新版程序的待遇,因为模拟器本身运行多个老 Mac OS任务时,和原先老版Mac OS一样,实际上只有一个进程,没有内存保护。这样做的好处是明显的,因为一方面老的程序在Mac OS X发布之初还能用,另一方面Apple又和老技术划清了界限,逼着开发者使用新技术,技术方面的原因是最重要的。但这个看似很正确的技术在Linus Torvalds看来是古怪的,他想当然地认为,完全可以运行多个不同的模拟器进程,来执行不同的任务,使得每个任务都可以享受内存保护。这种浪漫主义情调让他无比鄙视Apple员工的智商。而事后当笔者使用早期版本的Mac OS X时,发现Linus Torvalds的想法完全是不切实际的。因为这个模拟层本来就要占用不少的内存和CPU,在处理器速度不及今日手机、内存无比精贵的90年代末,跑一堆模拟器进程无异于是和自己过不去。 Steve Jobs考虑到Linus Torvalds是开源软件的领军人物,便继续以开源为话题,动之以情,晓之以理。他告诉Linus Torvalds,我们这个系统做出来后呢,所有的Unix层(非图形界面层),都会开源,所以事实上你加入我们,也是在给开源做贡献啊!而由于在开源圈子混久了,Linus Torvalds对此丝亳不领情,他认为,有谁会想用一个底层是开源而图形界面是不开源的系统呢?所以,像笔者这样的用户被“代表”了。 Mac OS X与Linux分道扬镳 总之,这次会面完全谈崩,两人站在不同的角度去看问题,加上Steve Jobs和Linus Torvalds都是个性鲜明、唯我独尊的人,技术和商业上的考虑都不同,所以会谈中双方简直就是鸡同鸭讲。这次讨论也使得Apple放弃Linux,转而采用FreeBSD技术,并在2001年任命FreeBSD的发起者、领军人物Jordan Hubbard为BSD技术小组的经理,并在后来升为Unix技术总监。至于Apple的内核技术后来走向何方,我们下期再讲。 笔者认为,Apple和Linus Torvarlds的商谈破裂,以今天的眼光来看,是因Linus Torvarlds的自命清高和短视造成的。他不懂得尊重其他开发者的意见,并且不断抬扛。包括后来关于C++的论战。Mac OS X发布后,Linus Torvalds又数次嘲笑Mac的技术落后,并说这些他在当年和Steve Jobs开会时就预料到了。直到最近,他终于有些成熟,对Mac OS X的观点开始缓合,但还是不忘批评Mac的文件系统就是垃圾(事实上,Linux的也没好到哪去,至少Apple还搞过一阵ZFS)。这种性格最终导致在 Mac OS X和iOS大行其道的时候,Linus Torvalds连兔子汤都不曾分到。 而事实上这对Apple也是件好事。Apple重要的是利益而不是折腾,即使是开源也是利益驱动。像类似Linux开发组那样自以为是但代码又写得差的开源项目,Apple事后也遇到不少,比如GCC编译器项目组。虽然大把钞票扔进去,在先期能够解决一些问题,但时间长了这群人总和Apple过不去,并以自己在开源世界的地位恫吓之,最终Apple由于受不了这些项目组人员的态度、协议、代码质量,觉得还不如自己造轮子来得方便,因此Apple推动了类似LLVM这样宏伟的项目,并且在短短几年内,使其成为最领先的开源软件技术。这无异于扇了Linux小组、GCC小组一记响亮的耳光。]]>

1984中最恐怖的地方

“我们是死者,”他说。 “我们是死者,”裘莉亚乖乖地附和说。 “你们是死者,”他们背后一个冷酷的声音说。 他们猛地跳了开来。温斯顿的五脏六腑似乎都变成了冰块。他可以看到裘莉亚眼里的瞳孔四周发白。她的脸色蜡黄。面颊上的胭脂特别醒目,好象与下面的皮肤没有关系。 “你们是死者,”冷酷的声音又说。 当奥勃良允许温斯顿提出问题的时候的对话:

“老大哥存在吗?” “当然存在。有党存在,就有老大哥存在,他是党的化身。” “他也像我那样存在吗? ” “你不存在。”
天涯书库:http://www.tianyabook.org/book/Orwell_02/ 百度百科-1984:http://baike.baidu.com/subview/416121/5089828.htm?fromtitle=1984&fromid=204192&type=syn]]>