Vim 中文速查表/Cheatsheet(全网最完善)
春节期间整理了一份 Vim 中文速查表,免得经常东搜索西搜索的:
https://github.com/skywind3000/awesome-cheatsheets/blob/master/editors/vim.txt
看了一下,应该是现在 Vim 所有中英文速查表里最完善的一份,有时候速查表比看书搜网页高效多了。
……写自己的代码,让别人猜去吧!
春节期间整理了一份 Vim 中文速查表,免得经常东搜索西搜索的:
https://github.com/skywind3000/awesome-cheatsheets/blob/master/editors/vim.txt
看了一下,应该是现在 Vim 所有中英文速查表里最完善的一份,有时候速查表比看书搜网页高效多了。
……无数次被问道:你在终端下怎么调试更高效?或者怎么在 Vim 里调试?好吧,今天统一回答下,我从来不在 vim 里调试,因为它还不成熟。那除了命令行 GDB 裸奔以外,终端下还有没有更高效的方法?能够让我事半功倍?
当然有,选择恰当的工具和方法,让 GDB 调试效率成倍的提升并没有任何问题。当然,前提条件是你至少会在使用最原始的 GDB。
穿上各种衣服前,至少得先学会裸奔,找份简单的 GDB cheat sheet 对照一下:
生产环境中出现崩溃时,因线上服务器一般没有开发环境,也无配套源代码,所以程序崩溃后,如果你懒得把 core 文件拖回到开发机检查,可以先在线上服务器先简单gdb看一下。
GDB命令密密麻麻,常用的也就表格上那几条,比如进去以后第一步先用 bt 查看一下调用栈,info local查看一下本地变量,再配合 up/down 在整个调用栈的不同层次之间上下移动一下,检查各处局部变量的值,print 一下某个表达式,即便没代码,看下符号和反汇编,一般也能调试个七七八八。
碰到复杂点的 BUG,必须配合源代码了,那你得把 core 文件拉到开发环境中,再用 gdb 对照源代码调试,配合 list [行号] 指令查看当前运行的源代码,再配合其他方法进行调试。
那么这时候,如果调试复杂度继续上升,你需要不断的断点,每次 next / step 单步完后你都需要 list 一下前后源代码,或者用 disassemble [函数名/地址] 查看一下指令的话,不少人会感觉到抓狂,这时我们需要给裸奔的 GDB 穿条内裤了。
……不管你在终端下使用 vim/neovim, emacs, nano 或者 zsh,你都会碰到使用 ALT 键的情况(终端下叫做 meta键),而由于历史原因,大部分终端软件的默认设置都无法正确使用 ALT 键。
要在终端下正确使用 ALT键最简单的做法是:首先将终端软件的 “使用 Alt键作为 Meta键” 的功能打开,意思是如果你在终端下按下 ALT+X,那么终端软件将会发送 <ESC>x
两个字节过去,字节码为:0x27, 0x78。
哈希表性能优化的方法有很多,比如:
上面只要随便选两条你都能得到一个比 unordered_map 快不少的哈希表,类似的方法还有很多,比如使用除以质数来归一化哈希值(x86下性能最好,整数除法非常快,但非x86就不行了,arm还没有整数除法指令,要靠软件模拟,代价很大)。
哈希表最大的问题就是过分依赖哈希函数得到一个正态分布的哈希值,特别是开放寻址法(内存更小,速度更快,但是更怕哈希冲突),一旦冲突多了,或者 load factor 上去了,性能就急剧下降。
Python 的哈希表就是开放寻址的,速度是快了,但是面对哈希碰撞攻击时,挂的也是最惨的,早先爆出的哈希碰撞漏洞,攻击者可以通过哈希碰撞来计算成千上万的键值,导致 Python / Php / Java / V8 等一大批语言写成的服务完全瘫痪。
后续 Python 推出了修正版本,解决方案是增加一个哈希种子,用随机数来初始化它,这都不彻底,开放寻址法对hash函数的好坏仍然高度敏感,碰到特殊的数据,性能下降很厉害。
经过最近几年的各种事件,让人们不得不把目光从“如何实现个更快的哈希表”转移到 “如何实现一个最不坏的哈希表”来,以这个新思路重新思考 hash 表的设计。
……网上对 AVL被批的很惨,认为性能不如 rbtree,这里给 AVL 树平反昭雪。最近优化了一下我之前的 AVL 树,总体跑的和 linux 的 rbtree 一样快了:
他们都比 std::map 快很多(即便使用动态内存分配,为每个新插入节点临时分配个新内存)。
项目代码在:skywind3000/avlmini 其他 AVL/RBTREE 评测也有类似的结论,见:STL AVL Map
谣言1:RBTREE的平均统计性能比 AVL 好
统计下来一千万个节点插入 AVL 共旋转 7053316 次(先左后右算两次),RBTREE共旋转 5887217 次,RBTREE看起来少是吧?应该很快?但是别忘了 RBTREE 再平衡的操作除了旋转外还有再着色,每次再平衡噼里啪啦的改一片颜色,父亲节点,叔叔,祖父,兄弟节点都要访问一圈,这些都是代价,再者平均树高比 AVL 高也成为各项操作的成本。
谣言2:RBTREE 一般情况只比 AVL 高一两层,这个代价忽略不计
……根据 Bram 前后几个关于高效使用 Vim的视频,大家每天需要花很多时间来编辑:代码、文档、邮件、日志 等等,除去这些外,还要分时间参加会议和人沟通,每个人的时间却都是不够的,优雅使用 Vim 无外乎:
以上三点反复循环,能让你的 Vim 越来越顺手。所以重点是根据自己的工作流不断迭代。而不是象大部分教程那样教你安装一大堆插件。插件都是别人写的为了解决通用需求而提炼的东西,和每个人的具体需求都有差别。上面这三点我屡试不爽,随着时间增长,有种越来越顺手的感觉,举几个我具体碰到的例子:
比如碰到问题搜到一段代码,需要试一下,一会又看会 Chrome ,一会又切回 GVim 里去写代码,反复 ALT_TAB,有时候中间使用了一下资源管理器或者其他程序,ALT_TAB 的顺序就会被打乱,你一切换就切跑了,十分低效。
于是我用 VimScript + 内嵌 Python 写了一个功能,按快捷键可以让 GVim 在透明/不透明两种状态间自由切换:
就是 VimScript 简单封装一个函数,里面用内嵌 Python 找到 GVim 的顶层 HWND,并设置透明度。平时默认不透明,需要参考其他资料时切换成透明,参考完了又快捷键切换回来,感觉比缘来切来切去顺畅很多。
……生命在于折腾,折腾完了 Atom Editor,开始跟着陈斌大婶和 purcell的配置折腾 Emacs,比较下。很多人都在比较键位,比较插件,这是十分肤浅的,我们比较点深入的东西:
代码结构
从代码结构上来讲,Emacs的代码最多的是 elisp,C代码只是一个微内核,Vim 里C代码还是大头。当然不排除 24.X, 25.X以后 Emacs源代码里带了好几个重量级的包,而 Vim向来比较精简一些,官方没带啥大点的插件有关。去除自带插件后,Emacs的 elisp代码比例应该会下降很多,不过总体来说,Emacs有更多组件使用 elisp开发而成,也就是说可以被用户修改或者替换的地方比 Vim要多,当然速度也会相应慢一点(比如 Emacs新打开上万行的文件连续按住PageDown时cpu 100%占满),不过比较大 JB,Atom Editor来说,还是快不少。
系统接口
大框架基本类似:
Vim 有 local,Emacs有 mode,Vim有事件触发,Emacs有各种钩子,基本大框架类似的。
键位设置也都很灵活,会配置的话,可以把 Emacs键位全部弄成 Vim的,比如 Evil,或者Vim里面也可以配制成进去就自动进入插入模式,全部用 Emacs键位。
具体到比如 buffer 或者窗口里面,Emacs的窗口或者 buffer /window 属性更多一些,Vim也有一些 Emacs没有的基础设施,比如 jumplist, quickfix之类的,不过 Emacs也可以用插件实现,实现 jumplist没问题,比较独立,但每个插件实现一个类似的 quickfix的东西,实在是比较蛋疼。
……早年开发工作主要在 FreeBSD进行,2006年后来切换到 Linux下,期间穿插使用了一下 Solaris,所以我的网络库一直都是只支持这三个系统。为了让网络库支持更多平台,网上购置了一台 IBM AIX 小型机,因为其他大部分非 Linux系统,今天基本都可以在虚拟机里面安装了,而 AIX系统,你真的没法虚拟。
弄了几天以后,发现真他妈的麻烦,强大是强大,但是真的太琐碎了,相比之下,Linux/FreeBSD之流基本是傻瓜了。不看说明直接操作 AIX的话,可能连开机都麻烦,或者关机没关对,下次直接启动不了。
文字终端就没什么好拍的了,先上一张图形桌面的靓照吧:
是的你没看错,这就是 AIX 7,2012年的操作系统,就是那么的霸道,四处透着古典 Unix的味道。这样的机器今天还跑在各大银行的机房里,AIX系统管理员也拿着比 Linux系统管理员多几倍的工资,虽然工作岗位比较稀少。
……在公司机房的物理机上架设 KVM虚拟化的时候,经常需要配置网桥,先要安装网桥工具:
apt-get install bridge-utils
apt-get install uml-utilities
编辑 /etc/network/interfaces,参考下面配置加入网桥配置信息:
……前段时间折腾家中 Nas的虚拟化服务,有时候虚拟机系统时间总是快8个小时。Guest这边设好了,到了 物理机就会慢8个小时。网上说只要修改/etc/default/rcS中的 UTC=no就行了,但还是没反映,没办法,一步步找问题。发现在/etc/rcS.d/S05hwclock.sh有这样一段话:
# 2012-02-16 Roger Leigh rleigh@debian.org
# - Use the UTC/LOCAL setting in /etc/adjtime rather than
# the UTC setting in /etc/default/rcS. Additionally
# source /etc/default/hwclock to permit configuration.
……