我家抽油烟机的烟囱原来是个装饰!

难怪英国抽油烟机不给力呢,原来它就从来没把烟抽出去过!!

今天做饭把抽油烟机的灯泡憋了一个,传承我极其背运的传统,顺带保险丝也给烧了。Google了一把发现要把钉在墙上的烟囱卸下来,因为英国电器的保险丝在插头上,然而插头一般藏在了烟囱里(界个设计也够可以,不怕油烟导致短路吗?)。一番DIY后成功将烟囱卸下,果然找到了插头和里面的保险丝。临时把电暖气的保险丝换上,抽油烟机恢复工作。明天要去买个新保险丝和灯泡。

不过这个烟囱拆的。。。只看见原来烟囱顶端没有洞!!它是个死的。油烟它从来就没出去过!!!

Advertisements

[译文]英国政府资助论文将强制提供开放获取

原文 RCUK announces new Open Access policy
译文发表于Yeeyan 24/07/2012.
翻译原因:自身相关。

2012年7月16日

英国研究理事会于今日(2012年7月16日)公布了一项关于开放获取的新政策。根据由Janet Finch教授(英国女骑士Dame)领导的全国工作小组在扩大研究成果出版物获取途径的调查结果,该政策支持并显著改变了现有研究委员会在(出版物)开放获取问题上的相关政策。

英国生物技术和生物科学研究会主席Douglas Kell教授评论道:“扩大现有研究成果的获取途径能显著推进各种科学研究的进步,确保英国在这些领域的领先地位。我很高兴地看到研究会改变了政策,确保了更多人能够获得这些领先研究(成果)并用于推动知识经济的增长和英国更广泛的福利。”

英国研究理事会影响小组(扩大其影响的工作小组)主席和英国研究理事会在开放获取问题全国工作小组的代表,Astrid Wissenburg博士评论:“由于研究理事会将公众财富投资到研究,理事会应全力推动研究成果对公众的开放。这不仅仅是对其他研究者,还包括潜在的商业使用者、非盈利组织和各公众领域、以及普通民众。在其他的基金会(HEFCE高等教育资助委员会、DFID英国国际发展部、和Wellcome基金会)的协同努力下,(针对所有这些基金会资助的项目,)该项新政策明确指明了一个可持续的、可负担的并透明的研究成果开放获取的发展方向。”

这项新政策规定,所有在2013年4月1日之后提交发表的成果,如果其通过同行评议的论文结果来源于全部或部分由英国研究理事会(包括其下所有的7个分会)资助的项目,(论文)就必须发表在符合理事会开放获取政策的刊物上,标明资助的详细信息并提供获得相关数据、采样和模型的途径。

政策详细规定了判别期刊是否符合开放获取标准的方法。政策允许通过(作者)支付来提供开放获取,也允许在强制版权期后将文章放入特定方向或研究机构的数据库来提供获取。并且,当需要付费提供开放获取时,该政策强制使用普通创造性贡献协议(CC-BY Creative Commons ‘Attribution’ license),该协议在标明原作者的前提下,允许其他人修改、继续开发和发布在该协议下发表的成果(包括商业目的的)。

英国研究理事会将提供对英国各高等研究机构、独立研究机构和研究理事会下的研究部门提供资助来支付那些开放获取的费用。同时,各研究机构也应建立并维护自己的财政来资助发表。研究理事会将和各研究机构协商确定开放获取支付的细节并建立合适的机制确保资金的运作。和其他的资助基金一起,我们将密切跟踪这些政策,查看其效果已确保实现开放获取的最终目标。

[译文] 血与钱

Eliza Strickland

副标题:日本的自动取款机已经在扫描你的血管了。这是否是通向无现金和无卡时代的开始呢?

原文 Eliza Strickland. “Blood and money,” IEEE Spectrum, vol. 49, no. 6, pp. 32-37, June 2012.
译文发表于Yeeyan 15/07/2012.
翻译原因:扫描手掌血管易识别身份的ATM系统,着实让我吃惊了一把。


日本一桩极为臭名昭著的ATM诈骗案发生在一家位于群马县丛山之中的高档高尔夫俱乐部内。2004年,包括一名俱乐部员工在内的一伙小偷于更衣室内安装了些微型相机以获取俱乐部会员衣柜的4位密码。当会员出去“交际”时,他们便打开会员的衣柜并用扫描装置复制他们的银行卡。

这些坏蛋将卡片磁条上的信息复制到空白卡片上。然后就在ATM机上测试这些复制卡,检查有多少会员将衣柜密码也用作他们银行账户密码。结果是:很多。当警察最终在2005年1月逮捕这7名小偷时,他们已经从300多名受害者那里窃取了3亿多日圆了(近400万美元)。

在日本这样守规矩的社会里,如此大的ATM诈骗案是大新闻。而在2005年,这起发生在高尔夫俱乐部的案子只是当年801起ATM案件中的一件,而在 2003年还只有90件。案件数量的突增震动了日本政府,他们要求银行去想办法对付ATM诈骗并命令银行自己掏腰包去赔偿受害者。银行于是向高科技公司求助,比如日立和富士通。结果发现,解决该问题的办法早就有了。

如果将你的手掌放在强光前面你会看见如网状的众多蓝色血管缠绕着你的手掌直至手指。这微妙的血管分叉和分布对每个人都是唯一的,和虹膜上的纹路以及你的指纹一样。日立和富士通都已经花费了多年研究如何商业使用血管分布识别身份。

在这项生物技术帮助下,日本的8万多台ATM机已经做到了当前能达到的防骗最高级别。并由于该技术的效果非常好,世界上的其他国家,比如巴西、波兰和土耳其(以后还会有更多),最近都将日立和富士通的血管扫描使用到他们的ATM机上。根据欧洲ATM安全小组的报告,发生在2010下半年的ATM诈骗已经达到2300万欧元。在美国,由于安全系数低的磁条卡仍在广泛使用,ATM诈骗据损失估计更大。尽管每年诈全世界骗损失的具体数值难以统计,McAfee的安全专家Robert Siciliano估计至少每年1亿美元。

能消除ATM诈骗已经非常厉害了,但这项技术的支持者还有更具野心的计划。少部分银行已经不再使用密码。有一家大胆的日本银行甚至在准备让他们的客户彻底抛弃卡片。这些改变都将我们推向了研究者们所憧憬的未来预想:你可以通过在商店扫描你的手掌来购买糖果。这种景像现在还只能在科幻中看到。实现这种生物识别支付系统的技术挑战是ATM认证系统所不能比拟的。但是工程师们正开始解决这些技术难题,预示了我们正走向人类文明的另一个里程碑:对使用了多世纪之久的货币实现更高层次的抽象。


一排排灰色的ATM占满了京都银行处理中心大楼的第6层。要进入这里,访问者需要用他们的临时身份卡刷开至少6道安全门,并且他们只能带入一支笔和几张纸。在这里,银行的技术人员会为他们在京都地区的1000多台ATM测试新程序和安全软件。

京都银行的执行经理北山裕司(Yuji Kitayama)带领着访问者走向安装了日立生产的手指血管扫描的ATM。“为了应对泛滥的ATM诈骗”,北山裕司说,“日本所有的银行都开始从磁条卡转向使用嵌入芯片的‘智能卡’。但京都银行希望用更多的安全技术来保护他的顾客和名声,所以我们使用了手指血管扫描。”

这并不是最炫的技术,但是个进步。这种生物装置能被很容易地集成到机器中。顾客也不用显著改变他们的使用习惯。当插入银行卡后,会有绿光提示你将手指放入一个集成在ATM机上的塑料槽。近红外光束会从槽的两边照射你的手指,同时槽底的相机会拍摄你的手指血管并和你注册的血管记录比对。如果比对成功,显示屏会在一秒内提示确认,你便能输入密码和继续你的交易。京都银行从2005年开始使用这项生物技术。到现在已有300万客户选择使用该技术。

北山裕司接着解释到,一旦银行决定添加一个生物系统,他们会系统地比较各种可用技术,考虑它们的安全程度、准确性和易用性。除了血管扫描,其他的可选技术还有指纹扫描,声音、面部和虹膜识别。指纹扫描看起来是是明显的方案。该技术非常成熟,指纹扫描仪也很便宜并易于使用。不过它还不够安全。“指纹很容易被伪造”,北山裕司说。连混事的侦探都知道如何从表面提取指纹。老道的窃匪可以用硅胶或橡胶复制指纹。

并且,如果所有的方法都失败了,我们知道铁了心的罪犯会将手指真地砍下来。前几年马来西亚发生了一起严重案件,一伙小偷将一人的手指砍下来来偷他的奔驰车,因为该车装了指纹识别点火系统。顾客会由于这种可能性而拒绝使用。“银行不希望给顾客制造任何危险情况”,北山裕司很婉转地说。

声音和面部识别技术很便宜也很好用,但他们还远不够成熟。感个冒或者糟糕些的光都能毁掉它的精确性。虹膜扫描需要一个相机精确检查眼部的微观结构。这种系统很安全也非常精确。但是它需要顾客很小心地将脑袋对准并保持睁眼。北山裕司说,该认证过程对于那些只想尽快取钱然后走人的银行顾客来说显得慢了些。

反过来看,血管扫描很快而且足够精确。北山裕司指出:“手指的血管也非常难被盗用。”即使一个小偷真的把人的手指砍下来,要达到目的他还需要保持该器官的血液流通。


日立和富士通的系统都使用相同的基本运行原理。在你体内流淌的血液都含有血红素,正是它们将肺部的氧气运输到全身的各个组织。送回到心脏的血液则包含去氧的血红素,它们能吸收近红外波段的光。手掌的其他部分则会让近红外光通过。所以用近红外光照射手掌所产生的图像上,较暗的细线表明了血管(吸收光则暗)的位置。

两个公司的系统选择照射手掌的不同位置:日立选择手指,富士通则选择手掌。他们的光照方式也不一样。日立让光透过手指以在另一侧成象。富士通则用传感器记录没有被血管吸收而被手掌反射回,遍布整个手掌的光。

在日立公司,该技术最先起源于公司的医学成像研究实验室。后来他们的金融服务部门才产生了兴趣,因为他们的分析员们认为该技术对银行系统会有帮助。但是医学研究小组的相机不能产生足够清晰的图像来完成可靠的身份识别,所以最终该挑战落到了图像处理小组身上。他们能否将该研究转变成可用产品呢?

日立中心研究实验室坐落在东京郊外的一片绿葱葱的园区内。他们的首席研究员長坂昭夫(Akio Nagasaka)演示了这个挑战。他展示了一张图片,显示了一个幽灵样的灰色手指被模糊点缀的血管包围。他指着手指较厚也较暗的部分说:“图片上的光线分布一般是不均匀的。传统的图像过滤方法并不足以解析血管(分布)的模式。”

对于具体他的小组是如何解决该问题的,長坂昭夫不愿多说,毕竟,这是一个版权技术。不过他和他的小组所发表的学术论文暗示他们并没采用指纹分析的传统技术。并没有去比较纹路里的细微差别(他们称之为细节结构)。相反,日立的小组发明了一种搜寻纹路的方法来对付模糊的灰色图像。该方法用软件扫描图像以寻找黑色暗点(血管部分),然后逐像素地跟随这些暗点以尝试构成线条。当程序尝试足够长的时间,它就能给出一个血管的(分布)模式。

该小组已研究如何使用CMOS传感器来减小光学系统的体积。他们正在研究的下一代传感器将只有15毫米×10毫米的大小,和女人的指甲一样大。另一项令该技术更具商业可行性的突破,長坂昭夫说,是建造一个开放式单元。该单元能从两侧照射手指并从底部用CMOS传感器成像。银行认为该方法更易于使用:“你可以看见你将要放手指的地方,并且你知道那里并没有口香糖残留物,”長坂昭夫解释道。

除了卫生,另一个重点考虑因素就是隐私。调查显示用户并不希望银行持有他们的生物信息。并且,如果黑客真的渗入了数据库,这项生物系统的实验只能就此结束了。至少为了那些账户被窃的用户——他们并不能重新获得一套血管纹路。所以日立发明了一个叫做卡片匹配的系统。用户的银行卡存储了生物特征,这样传感器所拍摄的图片是和卡片(上的数据)比较。富士通也是用了类似的系统,这样用户就不会失去对他们的生物信息的控制。如果卡片被盗了,即使是最老练的黑客也很难获取生物信息。这是由于卡片被配置成只能读入ATM的传感器数据,而并不会将数据传到任何外部机器(译者:这样岂不是更容易被黑,造一个永远返回ATM匹配成功的卡片即可了。。。)。


在将来我们是否真的把我们的血管特征当钱包用从而丢弃我们的银行卡、信用卡、借记卡、会员卡、密码、驾驶证甚至钞票?这将会是个商业革命同时带给消费者巨大的便利。不过研究者们的态度仍然是皱皱眉头说这日子还远着呢。尽管如此,富士通所进行的研究看起来已经非常像迈出了通向这目标的第一步了。

在富士通于川崎市的研究总部内,生物统计研究主任新崎卓(Takashi Shinzaki)拿出了一个比手掌大一些的盒子。他把他的手掌放到盒子的上方同时用三个手指按下了一个发绿光的面板。这样,盒内的传感器就能收集他的手掌血管数据,同时面板也收集他的指纹信息。富士通于去年公布了这个“多模型”系统。

这样的复杂系统在现在使用血管信息的ATM上还不需要。那些系统依靠一对一匹配,传感器收集的数据仅和保存在银行卡上的信息比较。这是一个相对简单的技术,系统只需要验证声称是你的人的确是你。不过如果我们要抛弃所有的银行卡和密码,那就需要一个能将客户的信息和存入系统的所有客户信息相比较的系统。这就是一对多比较,比一对一比较复杂得多。在这里,系统必须能快速并精确地获得你的生物特征并在不知道你是谁的情况下在后台数以百万计的可能匹配中找到你。并且,这必须在一到两秒内完成。

富士通在搜索时间上取得了重大进步。在富士通实验室,新崎卓的软件能在1.34秒内从500万预存记录中正确搜索出他的记录。“我们正在设计一个能搜索1000万用户记录的系统,”他自豪地说。

新崎卓这样解释该系统的高速:该系统将他的三个指纹和手掌血管信息融合,然后计较并抛弃所有和他的指纹或手掌血管纹路存在巨大差别的记录。“使用该预选择我们能很快地将可能目标从500万缩小到1万,”他解释说。然后,一个更精确但较慢的比较程序将仔细地匹配这些剩下的记录以找到新崎卓的记录。这个过程大量使用了并行处理技术。所有的比较工作别分配到富士通的7台服务器完成。

技术并不是这里唯一的挑战。在银行和用户同意将他们的钱和生物信息放入这个超前系统前,他们都需要反复确认系统的可靠性。所有使用生物信息系统的银行现在都是用一对一的匹配方式,只有一少部分在土耳其和巴西的银行勇于放弃使用密码。但现在有一家日本银行敢于迈出这勇敢的一步,踏入无卡取款的世界。今年九月,大垣共立銀行(the Ogaki Kyoritsu Bank)将引入一套使用富士通技术的ATM系统。使用该系统的客户不使用银行卡,而使用他们的生日、手掌和一个密码来操作他们的账户。为了获得这些便利,用户需要放弃一些隐私信息。因为没有了银行卡,用户的生物记录都需保存在银行的中心数据库内。

研究者认为这样的系统会变得更普遍。在富士通,新崎卓发现日本在2011年的三重灾难——地震、海啸和核泄漏事故,让30多万人流离失所。他们中的很多是在恐惧中逃离他们的家园。“很多人丢了银行卡并且没有任何身份证明,”新崎卓说。“如果那时我们有一家银行能仅靠生物信息工作,那么银行就能在那时继续服务这些顾客。”

新崎卓补充道,日本的银行确实帮助了这些顾客,即使他们没有任何身份证明。“很多银行能提供最多达10万日元,”他说。但在这混乱的灾后处理中,少部分不诚实的顾客设法到银行获得了不应属于他们的钱。(在这样的情况下,)一个血管扫描系统将能很快的将他们绳之于法。

如果生物技术更广泛的使用取决于说服银行,那么这样保护银行免于诈骗损失的好处将是最好的卖点。并且日立和富士通都致力于提供更快和更可靠的(生物特征)比较。日本人或许将成为世界上最早将钱包融入身体一部分(他们的血与肉)的民族。

【本译文仅用于学习和交流目的。如有侵犯版权,请联系博主。】
[This translation is freely published here for the purposes of study and pleasure. If there is any copyright conflict, please contact the author of this blog.]

Enforce the destruction order using shared_ptr (C++)

In recent development of C++/Tcl library, a user reported a crash when using the Tcl interpreter as a global object. From the error report and the function calling stack I had no idea what was wrong until this user provided a clue that it may be caused by the wrong destruction order of global objects. Finally it is verified true. I have just fixed this problem using boost::shared_ptr< >. As the nature of this issue is so weird, it is recorded accordingly.

For the following code:

// code1.cpp
int a = 1;
int b = 2;

int main() {
  int c = a+b;
  return 0;
}

global variables a and b will be constructed in the order of how they are defined, and they will be destroyed in the reversed order (b then a) when the whole program is being terminating.

However, things will turn complicated when multiple global variables are defined in multiple objects. For example, we could have another global variable int d defined in "code2.cpp". Then suppose we need to link these two object files into one executive using

g++ code1.o code2.o -o test_run

In this case, the construction order of a, b and d will depends on the order by which the objects files are linked and the internal order defined by the compiler. While the destruction order is still the reserved order of how they are constructed.

This would cause no problem if all global variables are defined separately without any connections. However, errors will come out when they call each other in the definition. For the following codes, there must be a wrong value initialization for either b or d:

// code1.cpp ===================
int a = 1;
int b = d;

int main() {
  int c = a+b;
  return 0;
}

// code2.cpp ===================
int d = a;

The thing is: if code1.o is linked before code2.o, d is not defined in int b = d; else if code2.o is linked before code1.o, a is not defined when int d = a. You can see here, there is some limitations of using global variables.

Now is the time to introduce the problem I encountered in the C++/Tcl library.

This library provides an interpreter class to users who can add extra commands, variables even objects to an embedded tcl script interpreter. To make things easy and hide the complicated tcl C API interfaces, all extra objects added to tcl are recorded globally using a map (multiple interpreter can co-exist at the same time linked to the same or multiple embedded Tcl interpreter). However, this user (who reported the crash) declared interpreter as a global object, meaning both the interpreter and the global map (recording all extra tcl objects) are in the global namespace. Unfortunately, the compiler used by this user released the map before interpreters, which causeed crashes.

To fix this problem, I must enforce a destruction order, making sure maps are valid when interpreters are released (as they are, in the destruction method, trying to clean the tcl objects defined by them).

the original code could like these:

// cpptcl.h ===================
class interpreter {
public:
  // some methods to define extra tcl objects
  void def_fun(...);
  void def_obj(...);
  void def_var(...);
  void ~interpreter();
};

// cpptcl.cpp ===================
...

// the global map definition
class global_map_type {
......
}

global_map_type gmap;  // the global map

void interpreter::def_fun(...) {
  gmap.def_fun(this, ...);   // use the global gmap
}

void interpreter::def_obj(...) {
  gmap.def_obj(this, ...);   // use the global gmap
}

void interpreter::def_var(...) {
  gmap.def_var(this, ...);   // use the global gmap
}

// destructor
interpreter::~interpreter() {
  // undef all objects defined by this interpreter
  for(...) gmap.undef_fun(this, ...);
  for(...) gmap.undef_obj(this, ...);
  for(...) gmap.undef_var(this, ...);
}

// main.cpp ===================

interpreter i0;   // global interpreters
interpreter i1;   // global interpreters

main() {
 ....
}

The two interpreters i0 and i1 may call gmap in the destructor when gmap is already released.

Well, I try to fix this using boost::shared_ptr as smart pointer can increase the ref count of a pointer and release the object only when no one is referencing it. The new code will be (only cpptcl.h and cpptcl.cpp are changed):

// cpptcl.h ===================

// a forward declaration
class global_map_type;

class interpreter {
public:
  // some methods to define extra tcl objects
  void def_fun(...);
  void def_obj(...);
  void def_var(...);
  void ~interpreter();
private:
  boost::shared_ptr<global_map_type> map_;  // to increase the pointer reference
};

// cpptcl.cpp ===================
...

// the global map definition
class global_map_type {
......
}

// global_map_type gmap;  // the global map
// now define it as a pointer
boost::shared_ptr<global_map_type> gmap(new global_map_type());

void interpreter::def_fun(...) {
  // gmap.def_fun(this, ...);   // use the global gmap
  if(map_.use_count() == 0) map_ = gmap;  // do the ref count incr if not done yet
  gmap->def_fun(this, ...);   // use the global gmap
}

void interpreter::def_obj(...) {
  // gmap.def_obj(this, ...);   // use the global gmap
  if(map_.use_count() == 0) map_ = gmap;  // do the ref count incr if not done yet
  gmap->def_obj(this, ...);   // use the global gmap
}

void interpreter::def_var(...) {
  // gmap.def_var(this, ...);   // use the global gmap
  if(map_.use_count() == 0) map_ = gmap;  // do the ref count incr if not done yet
  gmap->def_var(this, ...);   // use the global gmap
}

// destructor
interpreter::~interpreter() {
  // undef all objects defined by this interpreter
  // for(...) gmap.undef_fun(this, ...);
  for(...) gmap->undef_fun(this, ...);
  // for(...) gmap.undef_obj(this, ...);
  for(...) gmap->undef_obj(this, ...);
  // for(...) gmap.undef_var(this, ...);
  for(...) gmap->undef_var(this, ...);
}

In this way, every time a new interpreter tries to define an extra object in tcl, it will increase the global map ref count. Before all interpreters being released, the ref count for the global map will be larger than one, prohibiting it being released. In other words, the destruction order of global objects is enforced. The only pain here is I cannot do the ref count incr (or copy the smart pointer) inside the construction method of interpreter, as at that time, it is uncertain whether the global map is constructed. If not, the copied smart pointer is an empty one which will not increase the ref count.

怎么办?我是个动植物杀手…

无奈了,除了一只乌龟自己跑掉了外,从小到大经我手的动物和植物下场都不怎么样,连仙人掌都能被我浇死。

现在住的房子的前任留下了棵植物,到今天我查了才知道应该是棵白鹤芋。原来放浴室的,从北京回来后觉得植物怎么能放浴室呢,于是挪到我西边的窗台。晒了半个月,发现靠着窗户的叶子全枯了,才发现犯了错误。把枯叶子剪了,赶紧挪回浴室(明显上一任主人比我明白多了)。

可这还不算什么。都快一个月了,我就看着花的叶子从中心开始,一片一片的变黄。想想可能是前一段晒了,于是勤浇水(又错了!)没改进,又觉得是不是没肥了,把喝完的牛奶瓶冲冲水凑活浇了。叶子更黄了…

今天终于记起来了,洗完澡google了一把,查出来是棵白鹤芋,喜阴高温和湿空气。google上还说叶子黄可能是太阴了或者烂根了。然后说要把枯叶子剪了。于是动手剪叶子。过程中为了方便就把花盆从套盆中取出来,这才发现里面全是水,而且泛着腐烂牛奶的气味。现在满屋都是这股令人想puke的气味(自作孽啊)…

唉,现在是叶子剪了,不用套盆了(这样我能知道浇多了),然后放到客厅里没阳光直射但还暖和的地方。希望它还能活,不然我手上又多条罪帐。连花草都养不活的人,怎么办。

C++/Tcl :更容易地在C++中嵌入Tcl

才发现原来在C++程序中嵌入一个完整的script语言环境不是那么的困难。鉴于项目需要,我决定将Tcl语言解释器嵌到我的代码里,加上一个非常简单的输入流处理,就实现了一个动态Tcl命令行用户接口。

稍微说一下语言解释器。一般来说script语言,也就是脚本语言是解释执行的。但并不是所有的脚本语言都能用于嵌入。有些太大了不好嵌入,比如python,有些则基本不适合用于嵌入,比如Javascript。现在用的最多的一个是Tcl,另一个是较新的Lau。据说Lau在游戏里面用的很多,一般用作后台命令行解释。我自己受限于以往的类似软件多使用Tcl,因此还是继续使用Tcl的向后兼容新会好一些。

Tcl的C/C++接口使用C标准,提供了约50来个API函数。C/C++程序可以使用这些API运行Tcl解释器,任意扩展Tcl命令集,查看和修改Tcl变量,以及设定事件触发回调函数(这仅仅是我关心的功能,还有其他的一堆)。

但这些函数并不怎么好用,基本都是指针操作,而且文档看起来也不是那么好懂。一番搜索之后我发现了个好库,C++/Tcl,这个库将一部分的Tcl API用C++封装,并使用Tcl和Boost库实现了资源自动管理和释放,以及自动函数类型匹配,支持最多达9个参数的函数和对象扩展。

不过它还缺了两个我必须使用的功能,即在Tcl环境中修改我程序的环境变量和设定Tcl变量事件的回调。如果没有这些,Tcl就像是一个与世隔绝的封闭嵌入式解释器,没什么实际功能。

于是,我在Github上开了个新分支并在原有基础上增加了这两个功能。这是我第一次如此大规模的使用STL来构建自己的库,居然还动用了boost/preprocessor预处理来减少代码量。我已经更新了文档,并给出了最新功能的使用范例。具体链接如下:

文档:wsong83.github.com/cpptcl
代码:github.com/wsong83/cpptcl

如有bug或功能请求,欢迎发信,提供patch就更好了。

[译文]杀害丁氏一家的嫌疑犯在摩洛哥被捕

原文 Ding murders: Suspect arrested in Morocco, BBC England News 08/07/2012
译文发表于Yeeyan 9/07/2012
翻译原因:看看英国警察,别人虽然慢,但是这种一丝不苟破案的精神也已经让中国警察汗颜了吧。

一个据信是去年杀害英国北安普顿丁氏一家的被通缉商人已经在摩洛哥被捕。丁继峰(音译)、妻子海伦、两个12岁和18岁的女儿爱丽丝和星于2011年5月发现被害。

北安普顿警察十分肯定被摩洛哥当局逮捕的人正是52岁曾居住于考文垂的嫌疑犯杜安祥(音译)。警探于上周发现杜安详正居住在丹吉尔(摩洛哥北部城市)。北 安普顿警方对马德里(西班牙)的外出询查相信对嫌犯的逮捕起到了关键作用。警方和内政部(英国)将马上开始着手引渡嫌犯的正式申请。不过警方发言人仍说嫌 犯的身份在引渡工作完成前并不能完全确认。

国际刑警组织帮助

丁氏一家是在被刺身亡后两天于他们在北安普顿Wootton的家中发现的。当年5月1日,所有的四名家庭成员都发现被刺伤致死。警察相信遇害的日期是4月 29日,正是英国皇家婚礼的当天。北安普顿警方表示,从那以后的一年里,他们在国际刑警组织与英国严重及有组织犯罪调查局的帮助下将对杜的搜捕扩大到了世 界范围。43个英国不同警局和国际刑警组织和180国家进行了接触。对数千人进行了包括现场调查、信息请求、情报搜集和问询在内的走访调查。超过5000 小时的闭路摄像片段被提取。到今年4月,警方跟踪调查了380个嫌疑人并实施了9次抓捕,其中一些曾被认为就是嫌疑犯杜。