相信很多人在看完GNU Radio模块开发方面的文档之后，会出现“好麻烦啊”这样的想法。这也难怪，光是教学性质的gr-howto-write-a-block模块，就拥有7个子目录，108个文件。所以有一些同学是直接通过修改howto模块来开发自己的模块的，以此来减少一些体力劳动。
好在在CGRAN上收集的项目中，我发现了这个方便的工具devtools：
This project aims to provide tools, helper, scripts and scriplets to aid the development of GNU Radio.
简而言之，devtools通过提供名为modtool.py的工具，为各位开发者提供了一个快速生成模块骨架的手段。关于这个工具的简要介绍，可以参考这里，余下部分将简要介绍如何生成一个source模块的。
在Ubuntu 11.04平台编译GNU Radio第三方的gr-chancoding模块时，出现了这个莫名的错误。主要的错误信息有：
1 | Error: #error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS" |
当时我就错愕了，Ubuntu在不济，也不至于改到失去Boost的线程能力吧…肯定是我打开的方法错了。
Google搜索标题所示的错误信息之后，看到了这个链接：使用 GCC 4.7 编译 Passenger得到如下解释：
根据其提供的信息显示该BUG出现的原因是GCC 4.6之前都定义了GLIBCXX_HAVE_GTHR_DEFAULT，而 GCC 4.7 之后改为定义_GLIBCXX_HAS_GTHREADS。这个改动破坏了Boost代码中的判断逻辑，从而错误的定义了 BOOST_DISABLE_THREADS，而非 BOOST_HAS_THREADS。
此刻才恍然大悟，之前为了体验C++11各种特性，在这台Ubuntu 11.04上通过launchpad源安装了GCC 4.7，导致了Boost傲娇…
于是，用update-alternatives把g++改回4.5，一切就正常了。
从娃娃抓起，让大家从小苦逼，天朝已经输出价值观喽……
现在无论是IT码农们还是设计师们，都开始把魔爪伸向了下一代，闲逛的时候发现三本书：
还有一个更发指的在线教程：
Python Tutorials for Kids 8+，8岁呀…本应该是每天轻松搞定作业然后花大把大把时间去扔沙包踢足球下河游泳的岁月…还好我爸不是程序员…
Design Dossier: Graphic Design for Kids
人家作者说了：_
_
It is never too early to corral kids into the design world. The earlier you start, the more literate they will be.不过相对于上面那几本书，这个要好多了，至少不用敲代码…
最后是上面这本书的作者的最新力作……
Design Dossier: Architecture for kids
亲，配套模型哦印刷精美哦
虽然是写给小孩看的，但是我觉得类似我这样的建筑白痴看看也不错…
对了，最后这本的详细介绍见：Architecture for Ages 10 and Older
_
_
我一直觉得Event Studio的开发者们是一票活雷锋，不管是他们那O疼的水印(往矢量图中打水印，亲！你们都是人才)，还是他们的Real-time Mantra。所谓Real-time Mantra其实是如下一系列文档的集合(大部分是可供匿名下载的pdf，剩下的是在线HTML文档)：
学黑客，去蓝翔！
学厨师，去新东方！
……
学Web，去W3Schools！
除了最后一句，其它都是说笑的;)
Adobe是一家伟大的公司，无数的产品总能带给大家惊喜，今天又一次认识到了这一点。刚刚在浏览BBS TeX版的这篇文章《[ChinaTex]定制一个IPhone主题幻灯片》的时候从说明文档中看到这样一句话：
In order to have colors that fit together nicely, we recommend using a tool for creating color palettes, e.g., http://kuler.adobe.com/#create/fromacolor.
顺着链接进去转了一下，十分惊艳：
在这个界面中，你可以指定一个规则，然后用鼠标在采色盘中调节Base Color，就能得到一个颜色集，总之调到你满意为止。不过我更倾向于kuler提供的另外一个选项，也就是其他设计师上传的配色方案：
不懂平面设计的(比如我)，用这个会比较好，选得分高又顺眼的就对了。
btw：web和slides一样，丑陋的配色会吓走访问者，不过直接用开源的一些前端模板更省事一些，比如到这里去找：Open Web Design。
最近在用GDI+重写一个示波器控件(Oscilloscope Control)，原因是这个控件是用WTL写的，无法兼容于MFC的主界面程序。期间看到一个使用GDI+的双缓冲(Double buffering)解决方案：
01 RECT rc;
02 this->GetClientRect(&rc);
03 04 Bitmap bmp(rc.right, rc.bottom, PixelFormat32bppARGB);
05 Graphics* graph = Graphics::FromImage(&bmp);
06 07 Pen pen(Color(255, 0, 0, 255));
08 SolidBrush brush(Color(255, 0, 0, 255));
09 FontFamily ff(L"微软雅黑");
10 Font f(&ff, 28, FontStyleRegular, UnitPixel);
11 PointF pf(rc.left+5, rc.top+5);
12 13 graph->DrawString(L"GDI+ 示例程序", -1, &f, pf, &brush);
14 15 Graphics graphics(lpDrawItemStruct->hDC);
16 graphics.DrawImage(&bmp, 0, 0);也就是先在Bitmap中使用Graphics进行绘图，绘图完毕后再一次性绘制到HDC上。
但是我发现设计到字符串的输出的时候，直接将字符串输出到HDC上 与先绘制到Bitmap上再使用DrawImage将Bitmap输出到HDC 这两种方法有非常大的差别，如下两图：
因为鄙校奇特的上网方式，在不用代理的情况下，每位同学同一时间只能使用一个vpn账号在一台电脑上连接外网，所以我想在某些电脑上直接使用纯ipv6网络环境，如此就可以省去部署代理带来的密钥分配的麻烦。但是非常可惜，在只有纯ipv6网络的Ubuntu下，Firefox和Chromium都是罢工的，即使在纯ipv6环境的Windows下，两者也常常罢工；同时，这也会影响纯ipv6环境中Ubuntu在线用户的设定……
通过Google搜索发现，有人还在mozilla这边提交了bug：Cannot sign in to google account. Page stalls at waiting for account.google.com。在纯ipv6环境下的Ubuntu上面试了几次，发现只要是https协议的链接，两者都打不开，但是w3m就毫无压力，所以怀疑是Firefox和Chromium在证书方面遇到问题，于是修改两者的证书验证选项：
For firefox:
unselect checkbox of ``Options—>Advanced—>Encryption—>Certificates—>Validation—>Use the Online Certificate Status Protocol(OCSP) to confirm the current validity of certificates’’
For Chromium:
unselect checkbox of ``Options—>Under the Hood—>HTTPS/SSL—>Check for server certificate revocation’’
这样设置之后两者登陆https站点的障碍就立马消除了，Ubuntu下的在线用户也可以成功设定了，但是确实是存在安全风险的。最好的解决方案还是期待广大CA早日向ipv6过渡 ;)
texlive与ctex-kit的搭配，应该是我接触过的最简单、优雅的Linux TeX中文方案，水木TeX版置底推荐的也是这个。
但是以前在Ubuntu下安装的过程依然有些不上路子，因为诸如Debian、Ubuntu在内的各大Linux发行版软件仓库中，texlive的版本一度十分古老，所以假如想很顺利的用上texlive+ctex-kit的话，大家不得不自己下载texlive的镜像来安装。这样做的一个最直接的问题就是当你需要安装诸如apt源当中的vim-latexsuite的时候，你需要手工构建一个空包，欺骗包管理工具，让它以为你已经从apt源里面安装了texlive，这个方法多少有些快糙猛……
即使到了今天，我尝试过Ubuntu 11.10 beta 2之后，事情依然没有改观，Ubuntu官方的文档上时这么写的：
Note: As of July 2011 the texlive package that ships with Ubuntu (TeX Live 2009) is lagging two years behind the current TeX Live release (TeX Live 2011). If you want the latest version of TeX Live, you can install it directly from the TeX Live website (this does not interfere with the packages in Ubuntu).所以我还是选择了从iso直接安装，以下是安装步骤：
首先，为了能使用texlive自带的聊胜于无的图形安装界面，Ubuntu用户需要安装perl-tk这个软件包(当然，喜欢文本安装的同学可以跳过这一步)：
sudo apt-get install perl-tk
对于大陆教育网的用户来说，ipv6网络真是好东西，不仅免费，速度还一级棒，兼顾自动翻墙，texlive的镜像也可以从中科大的镜像下载：
http://mirrors6.ustc.edu.cn/CTAN/systems/texlive/Images/texlive2011.iso
1 | cd /home/foo/bar> mkdir CDROM> sudo mount -t iso9660 /path/to/your/texlive2011.iso /home/foo/bar/CDROM |
1 | sudo -i cd /home/foo/bar/CDROM> ./install-tl --gui=wizard |
然后，接下来的事情就比较简单了，一路下一步，直到完成。
因为texlive 2011的可执行程序默认是安装在/usr/local/texlive/2011/bin/i386-linux下的，所以需要修改path环境变量才能直接在shell中调用。
1 | export PATH=$PATH:/usr/local/texlive/2011/bin/i386-linux |
这一行最好是加到你的~/.bashrc中去，以后省得麻烦。
1 | mkdir -p ~/texmf/tex/latex |
自此，ctex-kit就装好了，非常简单。
从这里找到字体下载的链接：
它们分别是：
在用户主目录下建立如下子目录：
1 | ~/.fonts/adobefonts/ |
将Adobe的四款字体解压到该子目录，安装字体：
1 | cd ~/.fonts/adobefonts/ |
安装完成后可以用
1 | fc-list :lang=zh|grep -v 'Adobe' |
检查一下
1 | \documentclass[adobefonts]{ctexart} |
在命令行下用 xelatex test.tex 进行编译，如果顺利的话，就得到了pdf文件。
Note:
之前一直想从screen迁移到tmux上来，因为后者相比较前者而言对脚本的支持更好，我可以轻松的将常用的几个窗口(window)打包成一个会话(session)，然后可以轻松的在一个脚本中将整个会话启动。但是一直下不定决心，因为screen有encoding功能，而tmux没有：
encoding enc [enc]
Tell screen how to interpret the input/output. The first argument sets the
encoding of the current window. Each window can emulate a different encoding.
The optional second parameter overwrites the encoding of the connected terminal.
It should never be needed as screen uses the locale setting to detect the encod‐
ing. There is also a way to select a terminal encoding depending on the termi‐
nal type by using the "KJ" termcap entry.Supported encodings are eucJP, SJIS, eucKR, eucCN, Big5, GBK, KOI8-R, CP1251,
UTF-8, ISO8859-2, ISO8859-3, ISO8859-4, ISO8859-5, ISO8859-6, ISO8859-7,
ISO8859-8, ISO8859-9, ISO8859-10, ISO8859-15, jis.See also "defencoding", which changes the default setting of a new window.
简言之，encoding可以让你为不同的窗口(window)设置不同的字符集编码(charset)，并根据你的设定自动进行编码转换(当然，并不仅限于此，后面会细说)，对于我们这些使用Linux服务器在天朝教育网挂各大BBS站的同学而言，这个功能是十分重要的，因为大陆的BBS都是GBK编码的(据我所知是这样的)，但是自己的Linux服务器的系统locale一般都是UTF-8，以前曾经写过一些screen后台挂站的文章：
有同学可能要说了，如果要转码的话，用luit不就行了？比如``luit –encoding GBK ssh –1 guest@bbs.seu.edu.cn’’，单纯从转码的角度来说，luit确实是足够强劲了，这里先岔开来介绍一下luit:
Luit is a filter that can be run between an arbitrary application and a UTF-8 terminal emulator. It will convert application output from the locale’s encoding into UTF-8, and convert terminal input from UTF-8 into the locale’s encoding.
但是，luit在putty和gnome-terminal下面处理ASCII艺术(ASCII art or ANSI art)的时候是让人失望的，比如如下两幅截图：
左图是用luit登陆BBS时的惨状，右图是使用screen登陆BBS时的美景，真是对比出差距，不服不行啊……
其实我一开始也纳闷，按道理这两软件在对问题的处理上，都是先打开两个PTY，一个是对子程序的，以后是输出给用户的，然后自己通过在中间倒腾数据的时候做了相应的转码，怎么差距这么大呢……原来是screen在处理这些图形字符(line drawing characters)的时候，人为的给每个图形字符后面加了一个空格(有兴趣的同学可以翻翻screen的源代码，真相在encoding.c这个文件的recode_char_dw函数中；或者自己抓包看看)，所以图形变美观了。至于为什么要交空格，这个要涉及到GBK编码的字符宽度问题，本来这些图形字符在GBK中应该是和汉字等宽的，结果转UTF-8之后变得和英文字母等宽了，要是不补这个空格的话就会和luit一样乱套了，所以前面说screen干的不仅仅局限在狭义的转字符集编码，还把这个问题也考虑进去了。
好了，这么一说，screen太牛了，就算原生脚本支持不太好，用shell脚本(参见：Run script that sends commands to the screen session it is being run in)凑合一下也行啊，可惜screen在encoding上有一个bug，当你想设置encoding之后的窗口中输入图形字符(比如``※’’)的时候，这个符号会变成两个问号??，这可把我郁闷坏了，之前忍了好久了……其实这个bug在07年得时候就有人提交了，但是screen官方一直没动静，我翻了翻源代码，问题应该是处在encoding.c文件中的WinSwitchEncoding函数中，里面对字符宽度的计算出了问题，直接把这类图形字符变成了两个问号??，有兴趣的同学修改一下交给patch给开发者吧，功德无量啊~~
有了“变问号”和“原生脚本支持不足”这两点，已经足够让人又造轮子的打算了。不过我写这个工具之前还是用Google搜了一遍，确保没有重复的造轮子，用了如下关键词：screen tmux encoding’’，luit encoding tmux’’，``BBS ANSI tmux’’等等等等。
确实没有找到现成的轮子，然后我就用python写了这个工具(里面包含了pexpect_ng.py文件，从pexpect修改而来)，里面对图形字符的处理和screen一样，用正则表达式在每个图形字符之后加一个空格；名字现在叫做seu_bbs，但是其实把seu_bbs.py这个文件中第159行的bbs.seu.edu.cn’’改成你喜欢的BBS域名比如bbs.newsmth.org’’，用来登陆任何华语BBS应该是不成问题的。文件打包在这里：seu_bbs.py 0.3版 <挂站必备工具>，里面也有一些介绍，这里不罗嗦了，贴一下。./seu_bbs.py -h的输出：
usage: seu_bbs.py [-h] [-a] [-e CHARSET] [-u USERNAME] [-t TIMEOUT] [-v]
convert charset of BBS to locale
optional arguments:
-h, –help show this help message and exit
-a whether or not seu_bbs.py take whole window.[default
disable]
-e CHARSET, –encoding CHARSET
Set up seu_bbs.py to use CHARSET encoding.[default
GB18030]
-u USERNAME, –username USERNAME
Set up seu_bbs.py to use USERNAME login bbs.[default
guest]
-t TIMEOUT, –timeout TIMEOUT
Do someting when idle(unit is seconds, negtive value
will be ignored).[default -1]
-v, –version
这个工具目前还是有一些问题的，在从BBS的GBK转码为UTF-8的过程中，个别字符序列会转换不成功，我还没有详细的去调试到底是什么字符(估计是控制字符或者图形字符)导致转码失败，不过python内置的unicode函数倒是可以比较漂亮的忽略这个别转码错误，所以暂时就不管了，以后有时间再说吧。同时这个脚本的存在可以取代以往使用expect进行挂站，所以是完全的绿色版啊(除了需要python版本新于2.3以外)
最后要在赞一下pexpect模块的作者，代码的可读性太棒了！
btw:关于screen和tmux的比较，有两篇文章已经讲的很好了：