Mac中的ls命令可以使用-G参数彩色化输出的文件列表，需要配置LSCOLORS环境变量定义颜色，具体配置方法可以输入man ls查看。 不过，我查到这篇文章：http://linfan.info/blog/2012/02/27/colorful-terminal-in-mac/ 这篇文章的博主推荐安装Linux使用的GNU Coreutils替换Mac的ls命令，因为： Coreutils提供了配置工具，定义颜色代码更加方便； Coreutils包含的不仅仅是ls，同时作为Linux用户，他更习惯于使用GNU的各种shell工具。 （好吧，其实我也是一样） Coreutils的安装与配置方法如下： 通过Homebrew安装Coreutils 1 brew install xz coreutils 注：Coreutils并不依赖于xz，但它的源码是用xz格式压缩的，安装xz才能解压。 生成颜色定义文件 1 gdircolors --print-database > ~/.dir_colors 在~/.bash_profile配置文件中加入以下代码 1 2 3 4 5 if brew list | grep coreutils > /dev/null ; then PATH="$(brew --prefix coreutils)/libexec/gnubin:$PATH" alias ls='ls -F --show-control-chars --color=auto' eval `gdircolors -b $HOME/.dir_colors` fi gdircolor的作用就是设置ls命令使用的环境变量LS_COLORS（BSD是LSCOLORS），我们可以修改~/.dir_colors自定义文件的颜色，此文件中的注释已经包含各种颜色取值的说明。 grep高亮显示关键字: 这个很简单，加上–color参数就可以了，为了使用方便，可以在~/.bash_profile配置文件中加上alias定义。 1 2 3 alias grep='grep --color' alias egrep='egrep --color' alias fgrep='fgrep --color' Vim语法高亮: 在Vim中输入命令:syntax on激活语法高亮，若需要Vim启动时自动激活，在~/.

美赛成绩出来了，应该算是相比去年来说算是进步了很多吧。 去年苦逼的只拿到了Successfully Participation，今年查到成绩的时候还是小激动了一下：Meritorious Winner。 不过后来听到居然有大神拿到了Outstanding Winner，瞬间感觉自己仍然还是弱渣一枚，做什么都是渣，欣喜感荡然无存= =。 说来也奇，今年比赛的时候我和队友居然都错误的把一个四天的比赛认为只有三天，结果提前了24小时就提交了论文，现在想想觉得也很惊悚。 事实上距离比赛结束（2月10号）才两个月不到的时间，但我已经完全想不起来比赛论文写了什么东西了。 查完成绩后回寝室看了看这两篇论文，感觉差距还是超级的大，大一满怀论文信手拈来的那种激情已经完全不存在了。 遂先回过头来看大一的那篇《The Ultimate Brownie Pan》，无论从排版上的品位还是最后模型的建立，都只觉得稚嫩与无知。 刚才重读了今年的这篇论文《A Study in Keep-Right-Except-To-Pass Rule》（你有没有觉得这篇名字的命名借鉴了Sherlock..回答正确..=-=）更多的是在理论上的一些思考，甚至我现在再回过去读这篇论文发现已经不太能看懂自己的观点了。当然，今年这片在整片论文的排版上下了很大的功夫，直接导致了我这两个月都毫无写论文的欲望。 于是我慢慢理解了那些评委面对上万份的论文，究竟耐下了多少性子审核了这么大一堆论文。因为我自己再回过头去看我自己的论文（30多页），都觉得毫无耐心，几乎是一路翻看过去的。 大一大二这两年论文写了不少，真正获得认同的文章却没有几篇，综合起来看，凡是激情澎湃洋洋洒洒敲下来的论文，基本上都属于废材系列，没有一篇是别人同意靠谱的。相反这些在短时间内逼出来的文章，倒是含金量不少？说不准了。 好吧，想想自己还是弱渣一枚，滚去图书馆看书去了..

Python Version: 2.7 We use python for rapid development. Mainly using the matrix operations, so we quickly introduce python collection type and control structure. List 1 2 3 4 >>> wow=[] >>> wow.append(1) >>> wow.append('nice hat') >>> wow python has arryay data type, which similar to c/cpp/java/…, can contain only one type of data. This array type is faster than list when you are looping. Dicthinaries 1 2 3 4 >>> wow={} >>> wow['name']='euryugasaki' >>> wow[123]=456 >>> wow Set 1 2 3 4 5 6 7 8 >>> Set1 = [1,2,3,4,5,6,7,8,9] >>> pSet1 = set(Set1) >>> pSet1 >>> pSet2 = set([4,5,6,7]) >>> pSet2 >>> pSet1-pSet2 >>> pSet1|pSet2 >>> pSet1&pSet2 if 1 2 3 4 5 >>> val=10 >>> if val<9: print "hehe" >>> if val<9: .

前段时间做了个无聊的事情，算了算我大概学会使用了多少门编程语言，最后的结果是：十二门。（C, C++, Objective-C, Mathematica, Maple, Linux Shell, Java, Matlab, Lua, Python, assembly, R.) 然而细细一想又觉得很不靠谱，因为真正我自己觉得可能算是精通的的语言只有两门：Mathematica（我把它简称为MM） 和 Objective-C（我把它简称为OC）。 OC学起来很快，它和C++、Java这些面向对象的语言十分类似，不过，差距也显得比较突兀，我自己的学习顺序是:C -> C++ -> Java -> OC，好在我在学习OC之前对Java有了一个较为全面的了解，加之对C++一些肤浅的理解，算是稍微理解了一些OC的范式与模板了。 OC采用的是一种叫做“Messaging Structure”而非"Function Calling"的机制。我们可以对比一下下面的代码： 1 2 3 // Function Calling (c++) Person *person = new Person; person-&gt;walk(parameter1, parameter2); 1 2 3 #pragma mark Messaging Structure (oc) Person *person = [Person new]; [person walkWith:parameter1 and:parameter2]; 他们一个比较本质的区别在于，使用Messaging Structure的语言，运行时所应执行的代码是由运行环境决定的，而使用函数调用的语言，则是由编译器决定的。如果调用的函数是多态的，那么运行时就需要一种叫做“Virtual Table”的机制来检查到底应该执行哪个寒素实现。采用消息结构的语言，不论是否多态，总是在运行时才会去查找所需执行的方法。其实，编译器都不会去关心接受消息的对象是什么类型。接受消息的对象问题也需要再运行时处理，其实这样的一个过程就是我们所熟知的“Dynamic Binding”。 OC的重要工作都是由运行期组件而非编译器完成的。举个例子，运行期组件里面含有全套内存管理的方法，运行期组件本质上就是一种与开发者所编代码相链接的一个所谓的"Dynamic Library"，其代码能把开发者编写的所有程序粘合起来。这样的话，只要更新相应的运行期组件，马上就可以获得性能的提升，而那些很多工作都是处于编译期完成的语言（比如C++），想要获得类似的性能提升，就需要重新编译了。 下面配一张动态绑定这一特性，c++的OOP和其他语言的OOP的态度。

→ → 明早没课嘿嘿嘿嘿 第一次写app是打砖块，因为好像人生中第一个玩的游戏就是打砖块= =，所以看了点知识就开始下手了，感触比较深刻的是不真机调试有些bug还真不知道。。今天晚上趁着写FlappyFlat脑子比较热，熟悉了一下以前写的源码，顺便就改了改代码，算是把目前已知的Bug清理完毕了。算是比较完整的版本了。。目测以后不会去屌这个了。。 今天第二次写app，是现在这股FlappyBird热，看到别人写app，突然自己也想试一试，再加上寒假整个荒废，干脆写一个来祭奠逝去的寒假。 构思了约莫十分钟，后来越写越奇葩，越写越觉得要处理的东西多，比如说重力啊，块在上下过程运动时候的旋转啊，管子间距的随机生成啊，渲染管子在视图层的运动啊等等。 但是感触最较多还是编程本身，语言仅仅只是语法，各类API就好比单词，所谓开发经验，估计就是所谓的API掌握的熟练度了，这次代码逻辑上实现估计不过一个小时可能，除开在脑子里纠结混乱的逻辑，估计真正编码时间应该只有半个小时不到。那还有两个小时花在哪里去了呢。。没错，查文档= =记不住API真是太糟糕了。虽然花了三个小时，但是Bug仍然存在，重力方面好像我自己想的模拟方法达不到原版的那种粘滞感，估计是摸你得太真实了把，不过短期内不想碰它了= = p.s. 还是老实系统搞一遍好了，高级特性神马的完全就没有用到啊，这种简单玩意儿都要花这么长时间，弱成渣啊。 版本号:0.2.0 （无尽版） 更新以下功能： 增加社交化功能，统计历史砖块数，显示您击败了全球多少小伙伴； 随机生成的关卡难度，砖块打得越多，小球速度越大，难度越高； 两次都没有击中砖块时，惩罚玩家，增加随机多个砖块； 有一定几率触发智能模式：闪现，此模式下砖块具备闪现能力，砖块当预测到自身将被击中时，有一定几率完成闪现； 有一定几率触发智能模式：无尽，此模式下砖块具备无尽能力，每当有砖块被击中时，有几率增加随机多个砖块； 更多玩法求提意见。 历史版本： 版本号:0.1.1 修复若干Bug 版本号:0.1.0 初步完成

在Mac中，不支持卸载器，所以像这种pkg安装的奇葩软件，到底在哪些地方安装了也就不得而知。 不过幸运的是，官网上都写出了这个安装文件的安装位置，所以我们来看一下怎么才能卸载它。 官网上一开始说用户想要卸载掉这个占用高达几个G的软件的用户，一般是下下来看看怎么样，另一方面是可能想要升级到新版本（2013），所以不知道怎么把原来的版本（2012）卸载掉。 首先，我们需要卸载掉Tex： 官网上说，我们可以在 1 2 /usr/local/texlive/2013 中找到2013版本的卸载位置 /usr/local/texlive/2012 中找到2012版本的卸载位置 而且，2013的版本完完整整的安装在那个目录下，但是我们怎样才能打开这个文件夹呢，因为Mac是Unix系统，/usr中被隐藏一般情况下是看不到的，所以我们可以在终端中输入 open /usr/local/texlive来打开这个路径。（我们可以使用sudo rm -r来删掉整个目录，期间会请求root权限） 一般情况下，我们还可以看到texlive目录下还有一个目录叫做texmf-local，官网上说这只是一个空得目录树，如果你有强迫症，那么，删掉它就彻底完事了。 第二步需要卸载图形界面的程序： 这个步骤非常简单，只需要删除掉： 1 /Applications/Tex 目录下的文件就可以了。 如果你没有强迫症，那么整个卸载工作就完成了。 如果你有强迫症，那么我们还将继续： 第三步 我们需要卸载掉Tex得Distribution Data Structure，官网上声称这个空间非常非常的小，你删除它没有任何意义，但是，我们既然是强迫症患者，那么删除它就显得十分的必要了。 我们在删掉 1 /libray/tex 这个目录之前，一定要注意检查这个目录里面的每个文件，官方给出我们一个警告，这个数据结构，很可能存放了你删掉这个目录后就可能再也找不到的文件，所以我们需要逐个删除这个目录下中不是快捷方式存在的文件。 最后一步 最后这步是最恶心的，我们需要打开MacTex.pkg这个安装包（删掉了的再去下载吧= =），我们需要在最上面的菜单栏里找到“显示文件”，然后就会出现完整的安装文件位置。我们要做的，就是查找文件的相关内容和ImageMagick，删掉它们，大功告成。 官网：http://www.tug.org/mactex/uninstalling.html 图文版：http://pan.baidu.com/s/1gd20JWB

Cocos2d-X.org是cocos2d-x的官网，我们可以在官网上下载到它的最新版本，据说现在正在测试的版本3.0相比2.0会有比较大的改动，所以我们这里直接下载的3.0版本。 下载完毕后，我们可以知道这样一个readme的文件，如图所示。 这里面已经写好了如何去创建一个cocos2d-x的工程，所以我们按照他所说的，运行这个py脚本，得到一个新的窗口，如图所示。 创建完成后，我们打开mac平台下的xcode工程文件，如图所示。 打开工程后，可以看到Xcode不支持lua的高亮形式，我们等会儿采用LDT进行lua脚本的编写，我们先尝试编译一下这个工程，因为是第一次编译，所以会花较长时间，如图。 我们把LDT的workspace切换到工程的目录下，然后删除掉Resources里面多余的文件。 删除完成后，我们使用LDT创建一个名为main.lua（ 写上一行代码：print(“hello lua”) ）的文件，并在Xcode里面更改调用的文件，可以看到在控制台处，输出了Lua的调用结果。 下面我们试一下使用cocos2d来添加一个文本到屏幕上，如图示。

我们直接来看代码： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 -- 函数闭包来实现面向对象 -- 运行速度略慢与复制表的方式, 不过可以忽略不计 function Car(name) local self = {} -- 函数内部的一个local value local function init() self.name = name end self.introCar = function() print("hello "..self.name) end init() return self end -- 构造了一个Car对象 local p = Car("bengchi") p:introCar() -- 继承的实现，如果我们假设Plane可以继承自Car的话 function Plane(name) local self = Car(name) -- local function init() --也可以复写 -- end self.

我们直接来看代码： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 -- 我们定义一个对象People（其实是一个表） People = {} -- 定义成员函数方式1 --function People.

我们直接来看代码： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 -- 定义一个Table Config = {hello = "hello lua", world = "world"} -- 一个被叫做Config的Table被定义出来，键值hello索引的值是"hello lua"，类推 Config.words = "hello" -- 键值为words索引的值为"hello" Config.num = 100 -- 键值为num索引的值为100 Config["name"] = "zhangsan" print(Config.words) -- 访问形式1 本质是键值 print(Config["words"]) -- 访问形式2 print(Config.name) -- 更多的例子 print(Config.