Yukihiro Matsumoto: You can reconvert a closure back into a block, so a closure can be used anywhere a block can be used. Often, closures are used to store the status of a block into an instance variable, because once you convert a block into a closure, it is an object that can by referenced by a variable. And of course closures can be used like they are used in other languages, such as passing around the object to customize behavior of methods. If you want to pass some code to customize a method, you can of course just pass a block. But if you want to pass the same code to more than two methods -- this is a very rare case, but if you really want to do that -- you can convert the block into a closure, and pass that same closure object to multiple methods.

• 安装环境

skyscribe:~$ ruby --version
ruby 1.8.7 (2011-06-30 patchlevel 352) [i686-linux]
skyscribe:~$ irb
irb(main):001:0> puts "hello"
hello
=> nil

• 熟悉和上手

 ruby path_to_enlightenment.rb

• pattern-action 结构 借由强大的正则表达式来匹配pattern，然后执行pattern对应的操作
• Record/Field 处理模型  所有的输入数据都根据制定的record separator 分割成 record, 然后没一个record再根据field separator 分割为fields. POSIX 定义的 field separator可以为正则表达式，而gawk可以允许record separator同时为正则表达式

git clone git://gitorious.org/boost/cmake.git src
cd src
git checkout <TAG>    //TAG==1.41.0.cmake0
mkdir bld
cd bld/
cmake ../

如果需要按需编译某些库，只需用make edit_cache修改cache即可。

总算将OmniCppComplete主页上的效果给弄了出来（这里）。

根据其help提示一步一步来(装完了omnicppcomplete之后，可以:help omnicppcomplete)：

• 首先需要有ctags，并且必须是Exuberant ctags，我的Ubuntu上已经是最新版了：

skyscribe@skyscribe:~/study/vim/pics$ ctags --version
Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert
  Compiled: Aug  6 2009, 17:06:22
  Addresses: <dhiebert@users.sourceforge.net>, http://ctags.sourceforge.net
  Optional compiled features: +wildcards, +regex

• 在 ~/.vimrc 里边加入autoload taglist功能，为了方便自动更新当前tags，设置一个快捷键（这里）：

map <C-F12> :!ctags -R --c++-kinds=+p --fields=+iaS --extra=+q .<CR>
source ~/.vim/my.vim

 

这里的自动加载已有vim的功能，就用一个vim脚步来实现 (参考 vim :help glob给的例子)：

cat ~/.vim/my.vim 
let tagfiles = glob("`find ~/.vim/tagfiles -name tags -print`")
let &tags = substitute(tagfiles, "\n", ",", "g")

 

以后需要新的taglist，只需要放在~/.vim/tagfiles目录下就好了。

vim启动的时候，会自动执行~/.vimrc，从而调用my.vim，将事先准备好的taglist更新进去；这里一般放一些不太变化的静态头文件tag就可以了。

• 要有STL的intelliSense，自然要有STL C++的tags database了，这里需要生成之。

根据上一步的惯例，需要生成一个tags文件，放在~/.vim/tagfiles/的某个子目录下：

mkdir -p ~/.vim/tagfiles/gcc<ver>/
ls –l /usr/include/c++/

 

这里需要将ver换成当前系统的libstdc++版本，Ubuntu 9.10上的是4.4.1.

• 用上边的命令生成对应的tags文件：

ctags -R --c++-kinds=+p --fields=+iaS --extra=+q . -o ~/.vim/tagfiles/gcc4.4/tags /usr/include/c++/4.4

写一个简单的c++程序，在Insert Mode下，Ctrl+X， Ctrl+P，发现并不能工作，什么提示也没有；初步怀疑是对应的tag文件不对。

幸好早有人尝试过了，给出了一种办法(还是这里），可惜他的方法我试了不行，不过已经可以借用他的思路了：

• 将/usr/include/c++/4.4.1/的内容全部拷贝到一个目录下：

mkdir gcc4.4
cp -R /usr/include/c++/4.4 ./

• 写一个脚步替换所有的NAMESPACE宏定义(这里用sed完成宏替换，为了避免过于晦涩，还是放在一个临时的脚步文件里边来，便于调试吧)：

cat generate_sed.sh 
#!/bin/bash
if [ $# -eq 0 ];then
    dir=.
else
    dir=$1
fi
#Substitute scripts
cat > .edit.sed <<- EOF
s/\b_GLIBCXX_BEGIN_NAMESPACE\b\s*\(\s*(\w+)\s*\)/namespace \1{/g
s/_GLIBCXX_BEGIN_NESTED_NAMESPACE\s*\(\s*std\s*,\s*_GLIBCXX_STD_[DP]\s*\)/namespace std{/g
s/\b_GLIBCXX_END_NAMESPACE\b/}/g
s/\b_GLIBCXX_END_(NESTED_\?NAMESPACE\b/}/g
EOF
count=0
cols=`tput cols`
cols=`echo "$cols - 8"|bc`
for file in `find $dir -type f`;do
    if [ "T"$file != "T"$0 ];then
        sed -nf ".edit.sed" $file
        count=`echo "$count+1"|bc`
        echo -ne "="
        if [ `echo "$count%$cols"|bc` -eq 0 ];then
            echo " $count"
        fi
    fi
done
echo "Processed $count files!"
rm -fr .edit.sed
# Generate ctag file
ctags -R --c++-kinds=+p --fields=+iaS --extra=+q 
echo "generated tag file!"

• 再生成tag：

skyscribe@skyscribe:~/libstdc++/gcc4.4$ ./generate_sed.sh . 
==================================================================================================== 100
==================================================================================================== 200
==================================================================================================== 300
==================================================================================================== 400
==================================================================================================== 500
==================================================================================================== 600
===============================================================Processed 663 files!
generated tag file!
ls tags -lh
-rw-r--r-- 1 skyscribe skyscribe 4.2M 2010-01-10 18:21 tags
cp tags ~/.vim/tagfiles/gcc4.4/

• 到这里效果终于出来了：

上边的review窗口显示当前调用的函数信息,输入./->/:: 的时候会自动提示，也可以用CTRL+X CTRL+O 来调出提示窗口，方向键则可以选择。

其实我当初也有不少疑惑，不过通过较长时间的实践和阅读manual，总算有了个相对很清晰的认识。

• 如何使用其manual

cmake的帮助组织的还是很有规律的，了解了其规律，找自己想要的东西就会很简单，所以个人觉得这一点可能是最重要的。其help系统大概是这么几类：

• command

这个是实用过程中最长用到的，相当于一般脚步语言中的基本语法，包括定义变量，foreach，string，if，builtin command都在这里。

可以用如下这些命令获取帮助：

cmake --help-commands
这个命令将给出所有cmake内置的命令的详细帮助，一般不知道自己要找什么或者想随机翻翻得时候，可以用这个。
我一般更常用的方法是将其重定向到less里边，然后在编辑器里边搜索关键字。
 
另外也可以用如下的办法层层缩小搜索范围：
cmake --help-command-list
cmake --help-command-list | grep find
skyscribe@skyscribe:~/program/ltesim/bld$ cmake --help-command-list | grep find
find_file
find_library
find_package
find_path
find_program

cmake --help-command find_library
cmake version 2.6-patch 4
------------------------------------------------------------------------------
SingleItem 
  find_library
       Find a library. 
          find_library(<VAR> name1 [path1 path2 ...]) 
       This is the short-hand signature for the command that is sufficient in
       many cases.  It is the same as find_library(<VAR> name1 [PATHS path1
       path2 ...]) 
          find_library(
                    <VAR>
                    name | NAMES name1 [name2 ...]
                    [HINTS path1 [path2 ... ENV var]]
                    [PATHS path1 [path2 ... ENV var]]
                    [PATH_SUFFIXES suffix1 [suffix2 ...]]
                    [DOC "cache documentation string"]
                    [NO_DEFAULT_PATH]
                    [NO_CMAKE_ENVIRONMENT_PATH]
                    [NO_CMAKE_PATH]
                    [NO_SYSTEM_ENVIRONMENT_PATH]
                    [NO_CMAKE_SYSTEM_PATH]
                    [CMAKE_FIND_ROOT_PATH_BOTH |
                     ONLY_CMAKE_FIND_ROOT_PATH |
                     NO_CMAKE_FIND_ROOT_PATH]
                   )

• variable

和command的帮助比较类似，只不过这里可以查找cmake自己定义了那些变量你可以直接使用，譬如OSName，是否是Windows，Unix等。

我最常用的一个例子：

cmake --help-variable-list  | grep CMAKE | grep HOST
CMAKE_HOST_APPLE
CMAKE_HOST_SYSTEM
CMAKE_HOST_SYSTEM_NAME
CMAKE_HOST_SYSTEM_PROCESSOR
CMAKE_HOST_SYSTEM_VERSION
CMAKE_HOST_UNIX
CMAKE_HOST_WIN32
这里查找所有CMake自己定义的builtin变量；一般和系统平台相关。

如果希望将所有生成的可执行文件、库放在同一的目录下，可以如此做：

这里的target_dir是一个实现设置好的绝对路径。（CMake里边绝对路径比相对路径更少出问题，如果可能尽量用绝对路径）

# Targets directory
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${target_dir}/lib)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${target_dir}/lib)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${target_dir}/bin)

• property

Property一般很少需要直接改动，除非你想修改一些默认的行为，譬如修改生成的动态库文件的soname等。

譬如需要在同一个目录下既生成动态库，也生成静态库，那么默认的情况下，cmake根据你提供的target名字自动生成类似的libtarget.so, libtarget.a，但是同一个project只能同时有一个，因为target必须唯一。

这时候，就可以通过修改taget对应的文件名，从而达到既生成动态库也产生静态库的目的。

譬如：

cmake --help-property-list | grep NAME
GENERATOR_FILE_NAME
IMPORTED_SONAME
IMPORTED_SONAME_<CONFIG>
INSTALL_NAME_DIR
OUTPUT_NAME
VS_SCC_PROJECTNAME
skyscribe@skyscribe:~$ cmake --help-property OUTPUT_NAME
cmake version 2.6-patch 4
------------------------------------------------------------------------------
SingleItem
  OUTPUT_NAME
       Sets the real name of a target when it is built.
       Sets the real name of a target when it is built and can be used to
       help create two targets of the same name even though CMake requires
       unique logical target names.  There is also a <CONFIG>_OUTPUT_NAME
       that can set the output name on a per-configuration basis.

• module

用于查找常用的模块，譬如boost，bzip2, python等。通过简单的include命令包含预定义的模块，就可以得到一些模块执行后定义好的变量，非常方便。

譬如常用的boost库，可以通过如下方式：

# Find boost 1.40
INCLUDE(FindBoost)
find_package(Boost 1.40.0 COMPONENTS thread unit_test_framework)
if(NOT Boost_FOUND)
    message(STATUS "BOOST not found, test will not succeed!")
endif()
一般开头部分的解释都相当有用，可满足80%需求：
cmake --help-module FindBoost | head -40
cmake version 2.6-patch 4
------------------------------------------------------------------------------
SingleItem
  FindBoost
       Try to find Boost include dirs and libraries
       Usage of this module as follows:
       == Using Header-Only libraries from within Boost: ==
          find_package( Boost 1.36.0 )
          if(Boost_FOUND)
             include_directories(${Boost_INCLUDE_DIRS})
             add_executable(foo foo.cc)
          endif()
       
       
       == Using actual libraries from within Boost: ==
          set(Boost_USE_STATIC_LIBS   ON)
          set(Boost_USE_MULTITHREADED ON)
          find_package( Boost 1.36.0 COMPONENTS date_time filesystem system ... )
       
          if(Boost_FOUND)
             include_directories(${Boost_INCLUDE_DIRS})
             add_executable(foo foo.cc)
             target_link_libraries(foo ${Boost_LIBRARIES})
          endif()
       
       
       The components list needs to contain actual names of boost libraries

• 如何根据其生成的中间文件查看一些关键信息

CMake相比较于autotools的一个优势就在于其生成的中间文件组织的很有序，并且清晰易懂，不像autotools会生成天书一样的庞然大物（10000+的不鲜见）。

一般CMake对应的Makefile都是有层级结构的，并且会根据你的CMakeLists.txt间的相对结构在binary directory里边生成相应的目录结构。

譬如对于某一个target，一般binary tree下可以找到一个文件夹:  CMakeFiles/<targentName>.dir/,比如：

skyscribe@skyscribe:~/program/ltesim/bld/dev/simcluster/CMakeFiles/SIMCLUSTER.dir$ ls -l

total 84

-rw-r--r-- 1 skyscribe skyscribe 52533 2009-12-12 12:20 build.make

-rw-r--r-- 1 skyscribe skyscribe  1190 2009-12-12 12:20 cmake_clean.cmake

-rw-r--r-- 1 skyscribe skyscribe  4519 2009-12-12 12:20 DependInfo.cmake

-rw-r--r-- 1 skyscribe skyscribe    94 2009-12-12 12:20 depend.make

-rw-r--r-- 1 skyscribe skyscribe   573 2009-12-12 12:20 flags.make

-rw-r--r-- 1 skyscribe skyscribe  1310 2009-12-12 12:20 link.txt

-rw-r--r-- 1 skyscribe skyscribe   406 2009-12-12 12:20 progress.make

drwxr-xr-x 2 skyscribe skyscribe  4096 2009-12-12 12:20 src

这里，每一个文件都是个很短小的文本文件，内容相当清晰明了。build.make一般包含中间生成文件的依赖规则，DependInfo.cmake一般包含源代码文件自身的依赖规则。

比较重要的是flags.make和link.txt，前者一般包含了类似于GCC的-I的相关信息，如搜索路径，宏定义等；后者则包含了最终生成target时候的linkage信息，库搜索路径等。

这些信息在出现问题的时候是个很好的辅助调试手段。

• 文件查找、路径相关
• include

一般常用的是：

include_directories（）用于添加头文件的包含搜索路径
cmake --help-command include_directories
cmake version 2.6-patch 4
------------------------------------------------------------------------------
SingleItem
  include_directories
       Add include directories to the build.
         include_directories([AFTER|BEFORE] [SYSTEM] dir1 dir2 ...)
       Add the given directories to those searched by the compiler for
       include files.  By default the directories are appended onto the
       current list of directories.  This default behavior can be changed by
       setting CMAKE_include_directories_BEFORE to ON.  By using BEFORE or
       AFTER you can select between appending and prepending, independent
       from the default.  If the SYSTEM option is given the compiler will be
       told that the directories are meant as system include directories on
       some platforms.
link_directories()用于添加查找库文件的搜索路径
cmake --help-command link_directories
cmake version 2.6-patch 4
------------------------------------------------------------------------------
SingleItem
  link_directories
       Specify directories in which the linker will look for libraries.
         link_directories(directory1 directory2 ...)
       Specify the paths in which the linker should search for libraries.
       The command will apply only to targets created after it is called.
       For historical reasons, relative paths given to this command are
       passed to the linker unchanged (unlike many CMake commands which
       interpret them relative to the current source directory).

• library search

一般外部库的link方式可以通过两种方法来做，一种是显示添加路径，采用link_directories()， 一种是通过find_library()去查找对应的库的绝对路径。

后一种方法是更好的，因为它可以减少不少潜在的冲突。

        一般find_library会根据一些默认规则来搜索文件，如果找到，将会set传入的第一个变量参数、否则，对应的参数不被定义，并且有一个xxx-NOTFOUND被定义；可以通过这种方式来调试库搜索是否成功。

        对于库文件的名字而言，动态库搜索的时候会自动搜索libxxx.so (xxx.dll),静态库则是libxxx.a（xxx.lib），对于动态库和静态库混用的情况，可能会出现一些混乱，需要格外小心；一般尽量做匹配连接。

• rpath

所谓的rpath是和动态库的加载运行相关的。我一般采用如下的方式取代默认添加的rpath：

# RPATH and library search setting
SET(CMAKE_SKIP_BUILD_RPATH  FALSE)
SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE) 
SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/nesim/lib")
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) 

 

cat xxx.txt | grep "yyy" | wc –l

问题是这个常见的pipeline操作一般最少会起多少个进程？结果那位老兄倒是愣了半天然后目无表情。

我只好继续唠叨的解释了一下一般pipe的操作需要读取一个进程的输入，然后将输出送给下一个进程；其实我希望对方干脆利落的回答是有3个，这个问题就算是可以了；我们主要不是用脚本开发，但是如果有这个技能是能得到额外的认可的。

TL上的大虾们果然是想法众多，立马有人站出来问：我想知道答案是几个？直接让我怀疑是不是我的脑袋有问题。后来有人给出了可能是2个的情形：

      某个变态的shell可能内置了cat,使其成为一个builtin，然后自己越俎代庖的读取标准输入，并且将内容文本输出，那么进程就少一个。

起初我觉得这个解释并不能成立，但是经过几个老大的解释还是明白了他所说的情况是shell的builtin。

中间又讨论起那些可能是builtin的command，举出的例子是cd/kill/time，但是我查了一下Solaris上的，后两个都是executable，cd找到一个/usr/bin/cd 的ksh，内容如下：

#!/bin/ksh
command = `basename $0`
$command $@

这个结果本来还是挺出乎我的意料的，于是我也想当然的认为，shell里边不能直接调用syscall；

很快就得证这个揣测纯粹是错误的；以前还真没想过这个问题，查了下wikipedia、google之后得到很多意料之外的收获。

最后居然有人搬出了busybox这个大旗（做过嵌入式的大多都知道些），并声称它把vi也builtin了。

这下也很出乎我的意料，不顾我没有仔细研究过，没有什么发言权。

不过最后有人站出来说，busybox并没有内置这些想当然的vi，而是大部分也单独起进程了；在Unix的哲学里边，做这些大而全的东西其实是不被鼓励的，因为它违反unix的哲学。

话说回来，面试的时候，我之所以会问到这样的问题，也是有很真实的background的。曾经我们查过的一个很诡异的performance bottleneck就是由于shell脚步的问题引起的。

====================================================================================================

问题本身也是比较直观的（当然是“事后诸葛”了）：

     某段程序的启动脚本使用如下的东东来检测环境：

exists=`netstat -rn | grep "xx.xx.xx.xx" | wc -l`
if [ $exists -eq 0 ];then
     idx=`ifconfig -an | grep bge0 | awk -F":" '{print $2}' | uniq | sort | tail`"
     ifconfig bge0:`echo $idx + 1 | bc` plumb up
     ifconfig bge0:`echo $idx + 1 | bc` xx.xx.xx.xx netmask 255.255.255.0
fi
  

当有很多个同样的进程（>500)恰好于同一时刻跑到这个初始化点的时候，如果系统上已经存在的IP地址很多（当时的场景大概有2000+），那么netstat、ifconfig本身都变得非常耗时，加上多个进程的原因，系统中会有N多个进程在消耗着资源；

后果的严重程度是任何shell都停止响应，数十分钟都陷入假死，不得不重启电源了事。

当然的分析结果发现，真正占用的CPU都是处于kernel状态的，并且使用率超过99%，长长的pipeline带来的开销，相当一部分可能来源于互相等待CPU的进程的互相抢占。

解决的方法自然也很简单，这里不赘述了。

=========================================================================

当时以为对这个问题搞得算是比较明白了，结果拿出来一讨论，发现自己不了解的还真不少。

其中核心的部分是通过python的subproces module中的Popen来调用shell脚步完成功能性请求，并抓取执行的结果。

初一开始，test case比较少的时候（100个以内）都没有任何问题；但从某一刻起，当超过120个的时候，最后一个test case执行的时候，总是报告

                OSError： too many open files

给出的stack trace指向了Popen的communicate方法。

最简单的怀疑自然是打开文件数的限制了， ulimit  -a 发现默认的Shell的确只有256，虽然感觉应该也够用了（因为每一个case都是用单独的Popen来执行操作,完毕就应该被回收了），但还是自然将其开大一些；

                      ulimit –n 1024

重新执行，还是最后一个case失败，错误依然。

Google了一下，暂时没有头绪，只有待有时间再详细盘查一下原委了。不过在搜索答案的过程中发现了一个有意思的现象：

   有人在询问怎样将python的字符串quote成为一个可以再shell中安全使用的字符串，就有人回复说Subprocess中有一个类似的方法可以完成类似的工作为什么不用；马上有牛人站出来说，这个模块的作者大概不想维护过多的东西，因而将其隐藏了起来，而不是放开了给大家用，因为它的doc里边都没有直接说明，用的人是看了他的代码才知道有这个函数（参考这里）