Mac远程桌面到Linux服务器

假期结束,回到学校开始干活 :] 为了远程使用Linux服务器,折腾了一个下午。最终看来还是用vnc最简单了。 实验室有两台强劲的Linux服务器用来做研究。之前我一直都是用ssh登到服务器上去码代码,反应速度很快,感觉很不错。但是因为在做机器视觉,难免需要看远程的图片。命令行虽然快,总不能每次都把图片拷贝到本地再看,有时候需要可视化中间结果,ssh也行不通。 当本地机器是Linux系统的时候比较好办。可以用ssh加X forwarding的方法。在本地开一个X,然后把远程服务器的X指令通过ssh转发到本地的X,码代码没有什么延迟,感觉还是很不错的。 sudo X :11 vt11 2>&1 >/dev/null & 这样可以在本地新开一个X,Ubuntu下用Ctrl+Alt+F11可以切到第11个虚拟终端 回到之前的终端,开ssh和xterm xterm -display :11 -e ssh -X server-host & 然后可以切换到第11个虚拟终端来使用远程Linux服务器上的X了。 这样虽然好,但是要求本地机器上有安装X。在Windows和MacOS下虽然有解决方法,但是比较麻烦。 用VNC的话就没有这个问题,毕竟VNC的客户端是很容易找的。 当然需要先ssh登录到Linux服务器上安装vncserver sudo apt-get install vnc4server 然后启动vncserver vncserver 这样就搞定了。 在本地的Mac下可以用自带的Screen Sharing App或者著名的Chicken of the VNC连接到server-host:5901来查看和控制远程Linux桌面。 在服务器上启动了vncserver之后,可以通过修改 ~/.vnc/xstartup 这个文件,来指定远程的X启动之后要执行什么命令。我喜欢用openbox,所以我的xstartup文件就是这样子 #!/bin/sh # Uncomment the following two lines for normal desktop: # unset […]

dup, pipe 和 fork

(好久没更新了,呼…一大波死线刚刚结束…) 我几乎一直在用Bash,可是却少有接触到Unix系的系统编程,对系统调用还是知之甚少。这两天实验室里讨论了一个比较基础的问题: 在自己写的程序中,怎么样得到另一个可执行文件的输出? 比如我们有/bin/pwd这个可执行文件,我们可以在自己的程序中用 system(“/bin/pwd”); 或者是 execl(“/bin/pwd”,”.”,NULL); 调用它。 如果想要得到它的输出,应该怎么做比较好? 这个其实是作业题的范畴,涉及到了几个Unix的系统调用: #include pid_t fork(void); #include int pipe(int fildes[2]); #include int dup(int fildes); int dup2(int fildes, int fildes2); 手册里有各个函数的详细解释。 在这个例子里,pipe用来生成一对文件描述子 (file descriptor,我觉得描述子这个翻译不是很好…),往第二个描述子里写内容,从第一个里面读内容。fork用来得到一个子进程,这里,我们会让子进程来执行pwd,并且把输出写到pipe的一端,然后父进程可以从另一端读入。 但是pwd默认输出到屏幕,也就是标准输出,我们需要使用dup2,把标准输出指向pipe的一端,这样就可以完成任务了。 所以,最终的代码是这样的 #include #include #include #include int main(int argc, char **argv) { int fd[2]; int pid; pipe(fd); int rpipe = fd[0]; int wpipe = fd[1]; […]

在latex中调整hyphenation

用latex写英文论文的时候,可能会遇到断字符 (hyphenation) 在不该断开的地方断开的问题。因为英文单词长短不一,latex排版的时候为了让论文整体上看起来比较美观,可能会把落在行尾的单词从中断开,一部分留在当前这一行并且以一个短横线(-)也就是Hyphenation结尾,剩下的部分新起一行。 在英文文章的排版中,hyphenation是很重要的,特别是当行尾的单词很长的时候,如果不作断字,把单词都放在当前行就显得挤,新起一行就显得松。因为中文文章不存在这个问题,所以自己平时也没注意到。至于各个单词具体应该怎样断字,我还没有完全弄清楚,似乎也没有一个明确的规则,而且对于美式英语,英式英语也不尽相同。但是有一些简单考量一个断字点是不是正确的方法,比如,会不会造成歧义,是不是和单词的读音一致,或者是不是前/后缀之类的。 latex使用了处理断字的算法去自动的找断字的地方,而且latex会调整单词间距,使得文章看起来不会显得疏密不一致。大多数情况下,这些算法都工作得很好。但是因为断字的算法是根据某种规则来处理单词的断字,而不是依照人工事先标注的字典,所以,它仍然会出问题。或是在不该断的地方断开了,又或者是断开的地方太多了等等。在latex下可以通过调整参数和指定断字点来处理这些问题。 \hyphenpenalty=5000 \tolerance=1000 可以把这两个参数的调整加到tex文件里。hyphenpenalty的意思比较显而易见,这个值越大断字出现的就越少。tolerance越大,换行就会越少,也就是说,latex会把本该断开放到下一行的单词,整个儿的留在当前行。调这两个值就可以得到不一样的排版,有可能可以解决断字太多的问题。 如果遇到了断开的地方不对的情况,也可以手动来指定一个单词应该怎么断。 \hyphenation{hy-phen-a-tion} 这个命令告诉latex,hyphenation只能从标有短横线(-)的地方断开。 嗯,就是这些了。

橡皮鸭调试法

偶然在StackOverflow上看到Rubber duck debugging (wiki) 这个概念,有点儿意思,不过直译成橡皮鸭调试法好像比较弱啊。 按照wiki上的说法 传说中程序大师调试代码的时候会在桌上放上一只玩具橡皮鸭,调试的时候他会不断地,详细地,向鸭子解释自己的代码… 如果没有玩具小鸭子也可以考虑向其它东西倾诉..比如桌上的花花草草,键盘鼠标 (汗)。 好吧,正经地说这也是软件工程里的一个概念,一边阐述修改代码的意图一边做调试,就会更容易发现自己的错误。 类似的,有一种现象叫做Cone of Answers,不知道如何翻译这个词。这是一个常见的现象。你的朋友跑来问你一个问题,但是当他自己把问题说完,或者说到一半的时候就想出了答案走了,留下一脸茫然的你。是的,这个时候你就起到了那只橡皮鸭子的作用… 相似的概念还有不少,前面的wiki页面底部列出了好几个。总的来说,在你试图表述自己的想法的过程中,自然地在促使自己去整理思路,重新考虑问题。Thinking out loud 可能是一种不错的做法。

siri和语音对话系统

Siri最近是相当的火,朋友Sigma最近的一片文章也有讨论她用到的技术。 Siri本身是一个语音对话系统。从输入到输出,经过语音识别,对话系统到语音合成。 想起自己当年的毕业设计就是一个对话系统,再看看Siri,觉得自己的东西太naive了 :] 系统前后两端的技术已经比较成熟了。 嘈杂环境下的实时语音识别可能仍然是一个问题, 但是Siri的使用环境使得她不需要去考虑这两点。 第一,用户不太可能在很吵闹的地方对着手机喊叫,这看起来太傻了。 第二,用户不需要Siri随时都监听输入。 这样一来,输入方面,误识别率大大下降了。 我很好奇的是Siri怎样做到和说话人无关的识别。 一般来说,如果期望识别系统有一个比较好的识别率, 都需要事先针对说话人对系统做一些训练。 对于不同的个人得到相应的特征偏移。 小词汇量的连续语音识别和命令式的语音识别对这方面要求不高, 但是大词汇量下的连续语音识别却是比较依赖事先训练。 难道是米国人的发音都很标准? 对话系统的核心是从文本到文本的这一段。 也就是从已经识别出来的,用户说的话,到Siri给出对应的反馈,这个过程。 这方面的研究也有很长的历史了。比如,很著名的图灵测试。 图灵测试里,机器的目的就是通过对话骗过裁判来相信它们是人类。 铜奖的标准是在文本对话上完成这个任务,银奖则需要语音上的完美模拟, 金奖就得面对面的自然交谈了。 目前还没有机器能达到银奖水平。 Siri,和图灵测试里的程序的不同之处在于她需要提供有用的服务。 如果Siri只是在跟你打哈哈,即使内容有趣,也不会有多大的用处。 所以Siri需要真正得理解对话的内容。 这就把人工智能多年以来的很多工作整合起来了,比如自然语言理解、专家系统、 甚至到逻辑推理。 这些才是人工智能的核心内容。 Siri和生活服务的整合方面则是语义网成功的应用。这方面我不太了解。 只是早先听说语义网在小的、定制的范围内有很成功的应用, 因为这一块需要比较大量的工程上的工作。 其实想法很好理解,而且大家都想过。 大家都曾经希望对话系统能够自发地去网上找缺失的信息。 但是机器没有办法直接消化处理搜索引擎的输出。机器需要信息按照机器能理解的方式去组织。 所以就有了语义网这个概念。网络上所有的信息都需要它的标签,机器可以理解的标签。 对于任何一个词,机器可以方便地找到相关的知识。 所以机器能知道”当我谈跑步时,我谈些什么” :] 我们可以隐隐感觉到语言理解是各个问题的核心,也是人工智能的初衷之一。 我们期望能和机器交谈。 当她们的外表越来越接近我们,她们似乎也应该有同样丰富的内心。 当我们向机器提出一个问题的时候,我们希望她能够给出满意的回答。 无论她通过什么手段。无论她叫什么名字。

静态链接库

静态链接库 几个例子,使用和建立静态库的时候的几种常见情景。 首先建几个文件 a.h void testA(); a.c #include “a.h” void testA() { printf(“A”); } b.h void testB(); b.c #include “b.h” #include “a.h” void testB(){ testA(); printf(“B”); } 得到目标文件 $gcc -c a.c $gcc -c b.c 得到静态库文件 $ ar -r libba.a a.o b.o $ ar -r liba.a a.o $ ar -r libb.a b.o 得到了库libba.a libb.a liba.a 这是最终需要完成的程序。 […]

[cocoa demo]从图片中选取Frame的小工具

和设计相比,开发者的好处是遇到不好用的App就可以牛B哄哄的说: “这个不给力啊,等哪天有空的时候自己做一个吧”。 等到真正要做的时候就愣了,满脑子的按钮不知道怎么摆…. 在学校的时候,做的东西对UI的要求很低,不求美观,只要基本功能有就行了。 更不要谈什么用户体验,是不是User-Friendly之类的了。 工作的时候就大不一样了,做prototype的时候界面可能很粗糙。 但是等到Designer的东西(一般管这个叫mockup)出来,感觉就完全不一样了。 作为码农,常常觉得自己没有审美观…. 我认为完全重现mockup的效果是很重要的,尤其是一些细节。 功能上开发者可以发挥,但是在自己不擅长的领域还是不要胡闹了。 好了,扯远了…. 其实只是因为最近想学mac上的开发,然后因为有以上需求, 所以做了一个非常简单的工具作为练习。 真的很简单….不过如果你恰好有同样的需求,我觉得它还是有帮助的。 至少作为一个cocoa入门的demo,还是挺好的。 就是从mockup里框取一块区域,得到经过转换坐标的Frame。 左上的Button是用来打开图片文件的,左下的是用来切换显示的。 代码在Github上: GetFrame App下载链接: GetFrame.zip mac下的图标格式是icns 用这个网站转换图标比较方便,推荐一下: http://iconverticons.com/

[iOS]delegate和protocol

今天上班和同事讨论工程怎么组织的时候涉及到这个话题。 iOS开发上对delegate使用广泛。 记在这里,如果有新人Google到了,希望能有点帮助。 protocol和delegate完全不是一回事,放在一起说,只是因为我们经常在同一个头文件里看到这两个word。 protocol和java里interface的概念类似,是Objective-C语法的一部分。 定义protocol如下 @protocol ClassADelegate – (void)methodA; – (void)methodB; @end 那么就是定义了一组函数,这组函数放在一起叫作一个protocol,也就是协议。 函数是需要被实现的,所以如果对于class如下 @interface ClassB { } @end 就叫作ClassB conform to protocol ClassADelegate,也就是说ClassB实现了这个协议, 也就是实现了这一组函数。 有了上面这个头文件,我们就可以放心作调用 ClassB *b = [[ClassB alloc] init]; [b methodA]; [b methodB]; 而不用担心出现unrecognized selector sent to instance这种错误了。 所以protocol就是一组函数定义,是从类声明中剥离出来的一组定义。 id b = …; [b methodA]; 这种用法也常见,b是一个id类型,它知道ClassADelegate这组函数的实现。 那么delegate是什么?其实和protocol没有关系。Delegate本身应该称为一种设计模式。 是把一个类自己需要做的一部分事情,让另一个类(也可以就是自己本身)来完成。 比如ClassC @interface ClassC […]