FeedBurner RSS
联系博主
Email or Gtalk:
'民工技术' Category
-
一个面向对象实现的银行家算法
April 28, 2009最近完成学校《操作系统》课程的试验报告，其中的题目是用程序实现银行家算法。什么是银行家算法，这里就不详提了，具体参看Wikipedia-zh。 Wikipedia的页面里面有整个银行家算法的伪代码，加起来只有12行，很清晰地表达出整个算法的思想，然而如果你到别的地方看看一些具体的银行家算法实现，往往会被吓一跳（可以看看百度百科的词条）。 银行家算法本来并不复杂，只是其运算涉及向量、集合，实现起来还是花要一点功夫。我使用C++来实现银行家算法，为了实现和伪代码描述尽可能接近，重载对象的运算符等，最后整个算法的实现和伪代码没太大差别，也就20行的样子。 伪代码 while (P != ∅) { found = FALSE; foreach (p ∈ P) { if (Mp − Cp ≤ A) { A = A + Cp ; P = P − {p}; found = TRUE; } } if (! found) return FAIL; } return OK; C++代码 1 2 3 4 5 6 [...]
-
围观一下Linux下歌词新星：lrcShow-X 1.0.0
April 25, 2009lrcShow-X是基于pyQt、dbus等技术的一个歌词显示工具，比起此前出现过audaciois、amarok等的歌词显示脚本或者插件，lrcShow-X可谓一颗新星，首先其目前为止已经集成了一个歌词显示器需要的所有功能（参考千千静听等成熟的应用），编辑歌词、Mp3内嵌歌词等一个不缺，甚至用到被Ubuntu Jaunty发扬光大的OSD来显示。 虽然说目前并未和哪个播放器合为一体（插件形式），但不是难事，lrcShow-X通过dbus接口支持了audacious、amarok、vlc、exaile、quodlibet、qmmp等播放器，已经有人做到和amarok界面内嵌。 lrcShow-X的优秀表现，很大程度上是其内置了主流的歌词服务器，PT实际使用中觉得sogou搜出来的歌词比较出色。 目前使用lrcShow-X的使用方法略显简陋，需要启动播放器后自己在命令行内运行./lrcShow-X.py，但一点也遮蔽不了其强大的光芒。 ps: 在Ubuntu下使用lrcShow-X需要安装的包： sudo apt-get install python-gobject python-qt4 python-ibus 链接：http://www.sanfanling.cn/read.php?267下载：http://www.kde-apps.org/content/show.php?content=103055
-
ibus数据库高频词错误修正脚本
April 24, 2009使用ibus时间长了，常常突然发现有些本来常驻的首选或者常用字词突然掉到后面，甚至到了第二页，并不是被其他词挤掉，而是可能ibus的用户数据库出现错乱了。 不知道这是ibus程序的bug，还是ibus所用的SQLite数据库系统本身的问题，本来当用户输入一个拼音，ibus从用户数据库里面提出对应字的用户输入频数，决定字词的位置；如果用户第一次选择输入某个字，那么该字的记录就添加到用户数据库中，下次输入时便以此记录来提前该字的位置。理论上，在用户数据库里面一个词条的记录最多只能出现一次（多音字算多个字），然而，在实际的使用中，有时不知什么原因，某个本来常用的字被当作第一次输入再次加入到数据库当中，下次输入时，该字便作为低频字来排序，导致位置变得很后，带来不少不便。 这个Python脚本就是把这样的词条找出来，并把后来加入的记录删掉，把词条频数还原。 脚本下载：http://code.google.com/p/ptcoding/source/browse/trunk/ibus_fix (svn目录内的ibux_db_fix.py，其他的两个是测试脚本) 程序功能： 自动备份用户词库 检出用户数据库中出现了两次，但不是多音字词的词条 将后加入的词条删除 检出错词的SQL： SELECT * FROM py_phrase WHERE phrase IN (SELECT phrase FROM py_phrase GROUP BY phrase HAVING COUNT(*) = 2) 尚存缺陷： 如果同一个词条的记录出现了3次或以上，程序不能鉴别（极少可能出现，可修改脚本内的SQL语句来查询出来） 如果一个字本身是多音字，其中一个音节出现了上述情况，程序不能鉴别（貌似概率也挺低的） 如果两个记录中的用户输入频数相同，两条记录都会被删掉（倒不是坏事，影响不大） Python源码：
-
ScribeFire等XML-RPC工具发布WordPress出现HTML格式混乱的解决
April 14, 2009最近给我博客提供服务器的朋友把系统升级到新版的CentOS，习惯使用ScribeFire写博客的我遇上麻烦了：在Scribefire里面发布的任何东西格式都一团糟，发布的代码断肢缺臂，所有的HTML标记的尖括号都不翼而飞，原来的<p>就被剥光剩“p”，</p><p></p>的话就当然剩下3p了，不得不进入WordPress的后台编辑器重新修改，如此几天下来，不胜其烦。 于是在网上搜了一个中午，发现国内的形势一片大好，没任何人提到有这样的问题！！！难道是RP？后来想到，国内使用Linux主机的博客寥寥可数，在其中跟潮流使用新发行版的服务器更是少数了……因为这个问题的根源是新版libxml2库引起的！ 在这里可以看到不少生活在在水深火热中的西方人有这个问题，里面跟贴留言的人提到，在他的FC9系统里面安装libxml2-2.6.32-1.fc9没有问题，但是一升级到libxml2-2.7.1-1.fc9就不行了！而且这个问题不是最近才有的，可以看到抱怨该问题的帖子从08年10月后就出现了。 关于这个问题，考究过程是相当纠结的： WordPress 知道: XMLRPC api stripping leading angle brackets Php 知道: libxml2 2.7.1 causes breakage with character data in xml_parse() libxml2 知道 Release of libxml2-2.7.1 所有人都知道这个问题，但是距离完全修复还远着，一般用户如果能管理服务器，可以尝试把libxml2降级回2.6.3x，或者重新编译PHP，使用expat来替代libxml2的xml解析器。这两个方法对多数人来说都很不现实。在这些纠结得以解决之前，WordPress的用户一般要双手解决问题，WordPress patch for problamatic libxml2 version提供了修改wp中的三个文件的补丁方法，很明显，问题的根源是因为xml_parse()把我们文章里的HTML标记当成错误符号给吃掉了。不过对很多用户来说这依然不是个好方法，修改代码烦不说，还容易出错。 在这里推荐一般用户安装LibXML2 Fix这个WordPress插件，少快好省地搞定这个问题。当然，插件也提示说使用这个插件只是一个权宜之计，要真正修复这个问题，需要在服务器上把PHP更新到PHP 5.2.9+、libxml2 2.7.3+。
-
通过Wine使用Sogou浏览器的教育网加速代理
April 14, 2009此前用wireshark嗅探研究过Sogou浏览器的代理功能，没什么头绪，有访客留言说用Process Explorer瞧瞧Sogou的进程，今天有空看了下，果然，有一个子进程是用-proxy参数启动的，打开了本地的8081和8082端口在监听，用其他浏览器连8081，发现就是普通的透明代理，而8082则是一个自动配置代理的PAC（Javascript）。 虽然现在我的Ubuntu下已经有了一堆翻墙用的代理软件（没边、门、eTunnel……），但经常速度不甚理想，而且学校校园网的电信出口经常被挤爆，而教育网出口是空的，所以使用Sogou提供的免费教育网代理是个不错的解决办法。 把Sogou弄到Ubuntu下的Wine环境没有任何难度，把Sogou的安装文件夹全部复制到~/.wine/drive_c/sogou下，运行的很正常： pentie@pentie-desktop:~$ wine "C:\sogou\SogouExplorer.exe" -proxy fixme:win:EnumDisplayDevicesW ((null),0,0x32f3c4,0x00000000), stub! fixme:wtsapi:WTSRegisterSessionNotification Stub 0x1002a 0x00000000 fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080 fixme:mountmgr:harddisk_ioctl unsupported ioctl 2d1400 fixme:mountmgr:harddisk_ioctl unsupported ioctl 2d0c10 PID:8 PORT:8081 CPORT:8082 PAC:http://127.0.0.1:8082/proxy.pac?t=626 RET:SUCCESS 在配置Firefox的FoxyProxy，可以像平常那样添加127.0.0.1:8081作为代理，但既然提供了PAC，不妨试试：在Automatic proxy configuration URL内添入“http://127.0.0.1:8082/”，按Test，说找到PAC，解析成功！确定后右下角也出现FoxyProxy的提示。此时在Firefox中打开的网页都是通过Sogou的免费代理了！不过发觉现在的代理速度没此前那么快了。 Ubuntu中有一个工具可以配置全局代理，gnome-network-preferences，运行它可以轻松的让apt-get、telnet之类的程序通过代理来连接外网。 再一次提醒的是，Sogou浏览器代理是“透明代理”，它会转发你的真实IP，没有任何匿名功能，因为他们的服务器也在国内（北京），因此也不会有翻墙功能。 参考了别人的网志：http://dan.febird.net/2008/12/firefox.html 已知缺陷：在流量和连接数比较大时（比如刷开Google Reader），wine出来的SogouExplorer进程占用大量CPU资源，可能是某链接库匹配问题，以致这个方法的实用性不是很高。
-
为AVR写的1602A液晶屏幕驱动程序
April 12, 2009为1602ALCD屏幕实现的基本驱动功能，8位数据线，3位控制线，可自定义端口，可从LCD_Init函数设定工作方式，实现发送单字符和字符串的基本功能，带busy_wait。使用avr-gcc 编译。 代码下载：http://code.google.com/p/ptcoding/source/browse/trunk/AVR 更新：SVN目录内还有串口通讯的模块，以及串口和LCD驱动结合起来的一个试验性程序 参考资料：lcd1602a_398762.pdf（英文） ourAVR （注意两份资料的出入，前者更详细） 开发手记： 之前从天河赛格买了个1602的液晶屏，折腾了两天，终于让ATmega48驱动起来。 1602本来是一个挺简单的器件，8位数据线和3位控制线，其工作时序图初看起来挺复杂，但其实也就E端使能脉冲的事情，但是折腾下来，再一次验证了“简体中文”资料的不可靠，还有就是“这就是传说中的‘驱动程序’”。 首先我是从ourAVR网站提供的1602B液晶使用范例提供的资料入手（1602A、B好像没太大区别），借鉴了人家用ICCAVR写的代码（虽然代码是我敲的，但是基本上还是抄的），当LCD上显示出第一个字母时，还挺兴奋的，然而，这只是刚刚开始……（才100多行代码，加上看资料个把小时什么都好了。） 接下来才是噩梦般的调试，要么给黑方块，要么乱码，不稳定，这次能显示，重启就不行……还是ourAVR那篇资料提醒了我，初始化工作做的不够，写个循环发20次初始化信号，果然稳定了…… 奇怪阿，我明明按照Datasheet的数据来写的，怎么初始化不够呢？……说起1602的Datasheet，ourAVR那里提供了一份中文版，由“长沙太阳人电子有限公司”整理的，区区5页PDF，我另外Google了一份英文版的，顶，80多页，仔细一看，时序图居然有出入！转念一想，1602作为一种标准产品，一般的厂商只是兼容罢了，有多少出入还是正常的吧？不能全相信网上的Datasheet... 也从网上找了其他人写的1602驱程，51的、汇编的什么都来，有些的E使能脉冲居然是下降沿的，如此借鉴来借鉴去，折腾了两天。 最后还是被编译器“跹”了一回，比如把字符串写在发送函数的参数里就给我显示黑方块、乱码，又看了半天AVR的Flash空间、SRAM空间、EEPROM空间等的一大堆，最后才确定，是因为我使用之前《初尝Linux下的AVR单片机开发》里面的avr-objcopy -j .text参数，导致被放在.data段的字符串根本没有放到烧录文件内。 最后还有时序问题。一开始我使用了Busy Wait（读LCD的D7），认为以后就不用考虑命令时序了（LCD接受的命令有us级的一般命令ms级的两条清屏命令），结果还是乱的一团糟，最后往Busy Wait里面放了个死循环，发现程序根本都不绕进去，原来AVR芯片太快的，输出E信号后等不及LCD输出。 其他人写的驱动中，有些根本不考虑Busy标志的问题（干脆R/W接地），只要等候的时间足够，就可以保证写入的正常。在我最后写好的驱动中，我尝试把调用LCD_Busy_Wait的地方换成_delay_ms(5)，把整个LCD_Busy_Wait注释掉，这样工作起来是完全正常的，而且还省了36字节的程序，只是感觉上屏幕的反应就有那么一点的拖滞感。也可以把这个delay换成_delay_us(100)，这样没有拖滞感，但注意0x01这样的复位命令要注意要加个ms级的延时，但如果这样的延时语句多几条，程序在延时上膨胀的体积就远不止36字节了（别小看_delay_ms()，延时越久代码就越大），还不如用上Busy_Wait，这就需要应用在的来衡量了。
-
初尝Linux下的AVR单片机开发
April 2, 2009此前接触过AVR单片机，发现无论是书店里面的教材，还是网上一大堆的中文资料，无一例外都是说windows下使用WinAVR、ICCAVR之类的，Linux方面的简直只字不提，难道这就是传说中的中国国情？外国情况可很不一样，玩单片机的Geek一般都很哈Linux，做单片机开发的软件一应俱全，当然还是开源的。 昨天从淘宝重新买了条USB的下载线，回来一看是USBasp的设计，附送的光盘当然也是win下的驱动和说明了，忽略。 插上下载器，lsusb，认倒是认出来了，叫做VOIT，那怎么用呢？上网一搜，原来USBasp是德国人的设计http://www.fischl.de/usbasp/，GPL的，其中提到AVRDUDE支持USBasp，当然也有源码下载。不过我用的是Ubuntu，发挥超级牛力的时候到了：sudo apt-get install avrdude，恩，几秒钟搞定，让他们去编译吧！ Linux下做单片机开发当然首选GCC，就如这些英文教程说的，下载源码？No，No，APT has Super Cow Powers，继续sudo apt-get install gcc-avr binutils-avr avr-libc 几分钟装完，很好，估计那些下载源码回来编译的同学要去喝两个小时茶才能用了。 万事俱全，先写个单片机的HelloWorld，借用micahcarrick的源码： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 #define F_CPU 1000000UL /* 1 MHz CPU clock */ #include <util/delay.h> #include <avr/io.h> [...]
-
测试ibus输入法默认词库的流行词覆盖度
April 1, 2009这些天一直在想怎么扩充ibus输入法的词库，虽然一般使用感觉还好。在网上找到sogou提供了一个“互联网词库”，里面是搜索引擎分析出来的15万多词语，本想拿来导入到ibus，先用python测试了一下有多少词语已经在ibus的默认词库中，最后发现15万流行词中只有200多不在默认词库中，ibus词库确实挺优秀。 程序输出：（测试代码见后） seached: 157200 times. 215 phrases not in the database, written in file 'notexist' 查看notexist文件，发现除了后半部分一大堆频度为1的成语之外，只有20多个大频率词没在默认词库： （- -｜原来连“裸体”都没有？太和谐了！建议广滇驹推荐ibus为国家首选输入法） 乾坤 3561275 N, 乾隆 3088184 N, 乾净 1533219 夥伴 1052393 瞭望 984469 宏碁 979267 乾脆 953204 乾燥 624377 清乾隆 480337 乾隆皇帝 380252 N, 阿房宫 235461 乾隆年间 214986 定乾坤 210477 乾隆帝 149133 乾坤袋 143966 著色 111072 萧乾 84647 [...]
Page optimized by WP Minify WordPress Plugin