Mac OS X 配置环境变量

/etc/profile;/etc/bashrc 是针对系统所有用户的全局变量,只有root用户才能修改这两个文件,对一般用户来说是他们是只读的。一般用户要想修改它们,可以在命令前加sudo,意思是以Root身份执行,比如:sudo vi /etc/profile ,然后按照提示输入密码即可。

Mac OS X 10.3之后默认的是Bourne Shell。因此,对于一般用户而言,通常我们建议去修改~/.bash_profile来设置环境变量,它是用户级的设置,只对当前用户有效。

增加环境变量

操作步骤:
1. 打开Terminal(终端)
2. 输入:vi ~/.bash_profile
3. 设置PATH:export PATH=/usr/local/mysql/bin:$PATH
4. 输入::wq //保存并退出vi
5. 修改立即生效:source ~/.bash_profile
6. 查看环境变量的值:echo $PATH

删除环境变量

unset DYLD_LIBRARY_PATH,其中DYLD_LIBRARY_PATH(环境变量名)
删除环境变量之后需要先logout,关闭terminal,再重新打开terminal

恢复系统默认环境变量

PATH=$(getconf PATH),执行此命令将环境变量恢复到系统初始值

爬虫(spider/crawl)原理

学习了很多爬虫的原理和模块划分后,发现很多项目的原理以及组件划分似乎都是类似的,所以虽然这篇文章的原名不是介绍爬虫原理,但内容时机上就是介绍通用爬虫的基本原理和流程以及工作组件划分 – SpiderDuck:Twitter的实时URL抓取器
英文原文已经被twitter移除了,大家且看且珍惜吧。

正文:

推文中常常含有指向 web 各种内容的链接,包括图像、视频、新闻文章以及博客帖。SpiderDuck 是Twitter 的一项用于对这些链接进行实时抓取、解析下载内容并提取有趣的元数据的服务,并且,它使得其它的 Twitter 服务能够在数秒钟内即可使用这些数据。

Twitter 的许多的团队都需要访问链接的内容,尤其是需要用实时内容来改进 Twitter 的产品。比如:
搜索:需要对解析后的 URL 建立索引并改进搜索质量;
客户端:需要在推文旁边同时显示某些类型的媒体内容,比如照片;
发推按钮:用以统计每条 URL 到底被共享了多少次;
信任与安全部门:用以帮助检测恶意软件和垃圾信息;
分析:发掘关于 Twitter 上被共享的链接的统计汇总信息。
背景

SpiderDuck 出现之前,Twitter 有一个用发送 HEAD 请求和跟踪跳转来解析所有推文中的 URL 的服务。这个服务很简单,也满足了公司当时的需求,但是它有几项限制:
它解析 URL,但是并不真正的下载内容。解析信息被存在内存中缓存里但是并没有永久地保存在磁盘上。这意味着如果内存中的缓存实例被重启的话,数据就都会丢失。
它没有实现现代抓取机器人的“礼貌性”,比如访问频率限制和遵守 robots.txt 的指示等等。
显然,我们需要建造一个能够克服上述限制并满足公司的长远目标的真正的 URL 抓取器。我们最初的想法使用某个开源的抓取代码,或以其为基础,但是我们意识到几所有能用的开源抓取器都有两个我们不需要的特征:
它们都是递归抓取器。也就是说,它们是被设计来抓取页面并递归抓取从页面里面提取出来的所有链接的。递归抓取给爬虫的调度和长期队列的维护带来了很多复杂性,在我们情况下并不必要。
它们被优化来进行大批量抓取。我们需要的是快速的、实时的 URL 抓取。
因此,我们决定设计一个能够满足 Twitter 的实时需要的新系统,并能够随其增长水平扩展。为了避免重新发明轮子,我们把新系统大部分建立在了开源的模块之上,从而可以继续利用开源社区的贡献。

这是 Twitter 的工程问题里面很典型的一个——它们和其它大型互联网公司的问题很类似,但是要求所有东西都能够实时工作又带来了独特而有趣的挑战。

系统概览

这里是讲述 SpiderDuck 如何工作的概览。下图画出了它的主要部件。

SpiderDuck:Twitter的实时URL抓取器
Kestrel:这是一个在 Twitter 广泛使用的,用以对新进推文进行排队的消息队列系统。

Scheduler:这些工作单元决定是否要抓取一个 URL,计划抓取时间,并跟踪重定向跳转(如果有的话)。抓取之后,它会解析下载的内容,提取元数据(metadata),并把元数据写回 Metadata Store,把原始数据写入 Content Store。每个 scheduler 都独立工作;也就是说,我们可以把任意数量的 scheduler 加入到系统中,随推文和 URL 的数量增加水平地扩展系统。

Fetcher:这些是用于维护短期 URL 抓取队列的 Thrift 服务器,它们发送实际的 HTTP 抓取请求并实现速率控制和处理 robots.txt。就像 scheduler 一样,它们可以随抓取速率水平扩展。

Memcached:这是 fetcher 使用的分布式缓存,用以临时存储 robots.txt 文件。

Metadata Store:这是一个基于 Cassandra 的分布式散列表,用以存储网页的元数据和以 URL 索引的解析信息,以及系统最近遇到的每个 URL 的抓取状态。这个存储为 Twitter 所有的需要实时访问 URL 数据的客户服务。

Content Store:这是一个 HDFS 集群,用以存储下载的内容和所有的抓取信息。

现在我们将更详细地介绍 SpiderDuck 的两个主要部件——URL Scheduler 和 URL Fetcher。

URL Scheduler-URL 调度器)

下面的图表画出了 SpiderDuck Scheduler 里面的几个处理阶段。
SpiderDuck:Twitter的实时URL抓取器
就像 SpiderDuck 的大部分一样,Scheduler 也是建立在一个 Twitter 开发的开叫做 Finagle 的开源异步 RPC 框架之上。(实际上,这是最早的一个利用 Finagle 的项目)。上图里面的每一个方块,除了 Kestrel Reader,都是一个 Finagle Filter —— 一个允许把一系列处理阶段连接成一个完全异步流水线的抽象概念。完全异步则允许 SpiderDuck 以较少的、固定数量的线程处理很高的流量。

Kestrel Reader 会不断地询问是否有新的推文出现。当推文进来时,它们被发送到 Tweet Processor,它从其中提取 URL。每条 URL 然后就会被送到 Crawl Decider 阶段。该阶段从 Metadata Store 读取 URL 的抓取状态,以确定 SpiderDuck 是否之前已经见过了这个 URL。Crawl Decider 然后根据一个预先制定的抓取策略(就是如果 SpiderDuck 在过去 X 天内已经见过了此 URL 则不再重复抓取)来决定是否该 URL 应该被抓取。如果 Decider 决定不抓取该 URL,它会记录状态以表示处理完成。如果它决定要抓取这个 URL,它就会把 URL 送到 Fetcher Client 阶段。

Fetcher Client 阶段使用客户端库和 Fetcher 交谈。客户端库实现了逻辑用以够决定哪个 Fetcher 会被用来抓取该 URL;它也能够处理重定向跳转。(重定向跳转链非常普遍,因为 Twitter 上的贴的 URL 多数都被缩短了)经过 Scheduler 的每个 URL 都有一个相关的上下文对象。Fetcher Client 会把包括状态、下载的头以及内容的抓取信息添加到上下文对象中,并将其传递给 Post Processor。Post Processor 把下载的数据交给元数据提取器,它会检测页面的编码,并使用一个开源的 HTML5 解析器解析页面的内容。提取库实现了一系列启发式算法,用于提取诸如标题、简介、以及代表图片等元数据。Post Processor 然后把所有的元数据和抓取信息写入 Metadata Store。如果需要的话,Post Processor 还会调度一系列相关抓取。相关抓取的例子之一就是嵌入的媒体内容,比如图片。

后期处理(post processing)结束之后,URL 上下文对象被交给下一个阶段,其会使用一个叫做 Scribe 的开源日志聚集器在 Content Store (HDFS)的日志中记录所有信息,包括完整的内容。该阶段还通知所有的感兴趣的监听者 URL 处理结束了。通知使用了一个简单的发布者-订阅者模型,用 Kestrel 的分散队列实现。

所有的处理阶段都是异步运行的 —— 没有任何线程会等待一个阶段完成。和每个正在处理中的 URL 相关的状态都保存在相关的上下文对象中,所以线程模型也非常简单。异步实现也受益于 Finagle 和 Twitter Util 库提供的方便的抽象和构件。

URL Fetcher-URL 抓取器

让我们来看看 Fetcher 如何处理一条 URL。
SpiderDuck:Twitter的实时URL抓取器
Fetcher 通过 Thrift 界面接收到 URL。经过一些简单的确认之后,Thrift 处理器把 URL 传递给 Request Queue Manager (请求队列管理器),其把 URL 指定给某个合适的请求队列。一个调度了的任务会按照固定的速率从请求队列中读取。一旦 URL 被从队列中取出来了,它就会被送到 HTTP Service 处理。建造在 Finagle 上面的 HTTP Service 首先检查 URL 相关的主机是否已经在缓存中了。如果没有,那么它会为它创建一个 Finagle 客户,并调度好 robots.txt 文件的抓取。在 robots.txt 被下载之后,HTTP Service 会抓取许可的 URL。robots.txt 文件本身是被缓存的,在进程中的 Host Cache 和 Memcached 里面各一份,以防止每次有该主机新的 URL 进来时重复抓取。

一些叫做 Vulture (秃鹫)的任务周期性地检查 Request Queue (请求队列)和 Host Cache (主机缓存)以寻找有一段时间都没有被使用的队列和主机;如果找到了,它们就会被删除。Vulture 还会通过日志和 Twitter Commons 状态输出库报告有用的统计信息。

Fetcher 的 Request Queue 还有一个重要的目标:速率限制。SpiderDuck 限制对每个域名发出的 HTTP 抓取请求,以保证不会使得 web 服务器过载。为了准确地限制速率,SpiderDuck 保证每一个 Request Queue 在任一时刻都被指定到刚好一个 Fetcher,并且能够在 Fetcher 失效的时候自动重新指定到另一个 Fetcher 上。一个叫做 Pacemaker 的机群软件包会把 Request Queue 指定给 Fetcher 并管理失效转移。Fetcher 客户库根据 URL 的域名把它们分配到不同的 Request Queue。对于整个 web 设置的默认速率限制也能够根据需要被对于具体的域名设置的速率限制取代。也就是说,如果 URL 进来的速度比处理它们的速度还要快,它们就会拒绝请求,以告诉客户端应该收敛,或者采取其它合适措施。

为了安全,Fetcher 被部署到了 Twitter 数据中心里面的一个特殊区域 DMZ。这意味着 Fetcher 不能访问 Twitter 的产品机群和服务。所以,确保它们的轻量级设计和自力更生非常重要,这也是一条指导很多方面的设计的原则。

Twitter 如何使用 SpiderDuck

Twitter 服务以很多方式使用 SpiderDuck 的数据。大部分会直接查询 Metadata Store 以获取 URL 的元数据(比如,标题)以及解析信息(所有重定向跳转之后的最终规范化 URL)。Metadata Store 是实时填充的,一般是在 URL 在推文中发布后的几秒钟内。这些服务并不直接和 Cassandra 交谈,而是通过一个代理这些请求的 Spiderduck Thrift 服务器。这个中间层为 SpiderDuck 提供了灵活性,使其能够透明地切换存储系统,如有需有。它同时也支持了比直接访问 Cassandra 更高级的 API 抽象。

其它服务会周期性的处理 SpiderDuck 在 HDFS 上的日志以生成聚合统计信息,用以 Twitter 的内部测量仪表板或者进行其它批量分析。仪表板帮助我们回答诸如“每天 Twitter 上有多少图片被共享?”、“Twitter 用户最经常链接到什么新闻网站?”以及“我们昨天从某个网站抓取了多少网页?”之类的问题。

需要注意的是,这些服务一般不会告诉 SpiderDuck 需要抓取什么东西;SpiderDuck 已经抓取了进入 Twitter 的所有 URL。取而代之,这些服务在 URL 可用之后询问它们的相关信息。SpiderDuck 也允许这些服务直接请求 Fetcher 通过 HTTP 抓取任意内容,(这样它们就能受益于我们的数据中心设置、速率限制、robot.txt 支持等功能),但这种用法并不普遍。

性能数据

SpiderDuck 每秒处理数百条 URL。这中间的大部分都是在 SpiderDuck 的抓取策略所定义的时间窗口里独一无二(unique)的,所以它们会被抓取。对于抓取了的 URL,SpiderDuck 处理延迟中值在 2 秒以下,99% 的处理延迟低于 5 秒。该延迟是基于推问发布时间测量的,也就是说在用户点击“发推”按钮后 5 秒内,推文中的 URL 就被提取出来,做好了抓取准备,获取了所有的重定向跳转,下载并解析了内容,并提取了元数据,并且它们已经通过 Metadata Store 对于客户可用了。这中间大部分的时间要么花在了 Fetcher Request Queue (因为速率限制)中,或者花在了从外部 web 服务器实际获取该 URL 上。SpiderDuck 本身只增加了几百毫秒的额外处理时间,大部分都花在 HTML 解析上。

SpiderDuck 的基于 Cassandra 的 Metadata Store 能够处理接近每秒 10,000 个请求。这些请求一般是针对单独或者小批次(小于 20 个)URL 的,但是它也能够处理大批次(200~300 个 URL)的请求。这个存储系统的读取延迟中值在 4 ~ 5 秒左右,第 99 百分区间在 50 ~ 60 毫秒左右。

致谢

SpiderDuck 的核心团队包括以下成员:Abhi Khune,Michael Busch,Paul Burstein,Raghavendra Prabhu,Tian Wang 以及 Yi Zhuang。此外,我们希望对遍布全公司的以下人员表示感谢,他们要么直接为该项目做出了贡献,帮助设置了 SpiderDuck 直接依赖的部件(比如 Cassandra、Finagle、Pacemaker 以及 Scribe),要么帮助建立了 SpiderDuck 独特的数据中心设置: Alan Liang, Brady Catherman, Chris Goffinet, Dmitriy Ryaboy, Gilad Mishne, John Corwin, John Sirois, Jonathan Boulle, Jonathan Reichhold, Marius Eriksen, Nick Kallen, Ryan King, Samuel Luckenbill, Steve Jiang, Stu Hood and Travis Crawford。我们也要感谢整个 Twitter 搜索团队提供的宝贵的设计反馈和支持。如果你也想参与这样的项目,和我们一起飞吧!

原文地址:http://engineering.twitter.com/2011/11/spiderduck-twitters-real-time-url.htmlhttp://engineering.twitter.com/2011/11/spiderduck-twitters-real-time-url.html

2015.10.27补充: – 爬虫技术浅析

xcode pod 路径下头文件的“file not found”问题

更换了电脑,重新从git上下拉的工程,发现头文件命名存在,但是编译时提示 “file not found”的问题,初步怀疑环境配置问题,因为之前的环境是ok的。但检查比对了pod和主工程的路径,没发现明显的线索。

所以就重新创建了pod的工作区:

把.xcworkspace,pod开头的文件除了Podfile,全删,然后重新pod install/update,再打开新的xcworkspace 文件,编译,ok

vpn时如何自动区分国内国外-chnroutes-autoddvpn

针对这个需求,有专门的开源项目 chnroutes

最起源的代码仓库:https://code.google.com/p/chnroutes/

1. 与这个最接近的github上的代码:

https://github.com/fivesheep/chnroutes

2. 还有一个差异比较大的,从时间上看是比较旧的,但需要比较代码才能知道哪个更合适

https://github.com/jimmyxu/chnroutes

3. 还有一个改进版,提供 go python 以及window界面版本,从其文档连接看是以 fivesheep 的版本为基线版本。

https://github.com/sabersalv/freedom-routes 

本文验证了pptp windows 环境下的功能,工作OK。

其中python 使用 2.7.10 版,请安装完整版,因为可能需要其他关联库。

脚本执行要使用管理员权限。

1,2,3生成的路由数据略有差异,经简单测试,以 baidu.com 和weibo.com 为test case, 似乎3的效果好些,但因每人宽带出口不同,不作为唯一结论,使用者请自行测试。

如果要让路由器实现上述功能,提供用户透明的vpn体验,也有相应的项目  https://code.google.com/p/autoddvpn/

pptp的安全风险

原文已经无法访问了,特意搬运过来,英文吃力的同学,可以用google翻译,当然你要会科  学  上  网

总结起来最终的要的亮点

  • 明文传输
  • 采用简单的用户名和密码验证,方法过于简单

原文:

http://pptpclient.sourceforge.net/protocol-security.phtml

PPTP Client

Protocol Security

References

by James Cameron

Summary

by Peter Mueller

PPTP is known to be a faulty protocol. The designers of the protocol, Microsoft, recommend not to use it due to the inherent risks. Lots of people use PPTP anyway due to ease of use, but that doesn’t mean it is any less hazardous. The maintainers of PPTP Client and Poptop recommend using OpenVPN (SSL based) or IPSec instead.

(Posted on 2005-08-10 to the mailing list)


Why not use PPTP?

by James Cameron

The point to point tunneling protocol (PPTP) is not secure enough for some information security policies.

It’s the nature of the MSCHAP V2 authentication, how it can be broken trivially by capture of the datastream, and how MPPE depends on the MSCHAP tokens for cryptographic keys. MPPE is also only 128-bit, reasonably straightforward to attack, and the keys used at each end are the same, which lowers the effort required to succeed. The obvious lack of two-factor authentication, instead relying on a single username and password, is also a risk. The increasing use of domestic wireless systems makes information capture more likely.

However, that doesn’t mean people don’t accept the risks. There are many corporations and individuals using PPTP with full knowledge of these risks. Some use mitigating controls, and some don’t.

Many people seem to judge the security of a protocol by the availability of the implementation, the ease of installation, or the level of documentation on our web site. Improving the documentation is the purpose of this web site, and we aren’t doing that in order to say anything about the risks of the software! Any judgement of security should be rigorously applied to the design and implementation alone.

PPTP on Linux, and Microsoft’s PPTP, both implement fixes for vulnerabilities that were detected years ago in Microsoft’s PPTP. But there remain the design vulnerabilities that cannot be fixed without changing the design. The changes needed would break interoperability. We can’t change the Linux PPTP design, because it would stop working with Microsoft PPTP. They can’t change their design, because it would stop working with all the other components out there, such as Nortel and Cisco, embedded routers, ADSL modems and their own Windows installed base.

The only option then is to deprecate the product and promote the replacement. Microsoft promote something else. Our choice for Open Source systems is OpenVPN or IPsec.

Level of acceptance isn’t a good indicator of risk either. Some have said that the shipping of MSCHAP V2, MPPE and PPTP in Linux distributions is an indication of design security, but that’s not the reason. It’s for interoperability. As an example, see how Linux distributions still ship telnet, ftp, and rsh, even though these components are insecure because they reveal the password in cleartext in the network packets. The same can be said of many other components and packages.

Our recommendations are;

  1. do not implement PPTP between open source systems, because there’s no justification, better security can be had from OpenVPN or IPsec,
  2. do not implement PPTP servers unless the justification is that the clients must not have to install anything to get going (Microsoft PPTP is included already), and be aware of the risks of information interception,
  3. do not implement PPTP clients unless the justification is that the server only provides PPTP, and there’s nothing better that can be used, and again be aware of the risks of information interception.

(Posted on 2005-08-10 to the mailing list)

nginx设置后端保持长连接

nginx 做反向代理分发时,为了提高效率,最好使用长连接,以下是nginx 支持的几种后端长连接配置方案:

Nginx从 1.1.4 开始,实现了对后端机器的长连接支持,这是一个激动人心的改进,这意味着 Nginx 与后端机器的通信效率更高,后端机器的负担更低。

例如,对一个没有长连接支持的后端机器,会出现大量TIME_WAIT 状态的连接,使用以下命令验证之:

netstat -n | grep TIME_WAIT

经过查阅官方文档,其目前已经实现了http, fastcgi, memcache 协议的长连接支持。而之前的版本中仅支持memcache 协议。

1. 启用到 memcache 服务器的长连接
在upstream 配置段中增加 keepalive N 指令即可:
upstream memcached_backend {

    server 127.0.0.1:11211;

    server 10.0.0.2:11211;

     keepalive 32;

}

server {

    …

    location /memcached/ {

        set $memcached_key $uri;

        memcached_pass memcached_backend;

    }

}

2.  启用fastcgi 长连接支持
除了需要在upstream 中配置 keepalive N 外,还需要在 location 中增加 fastcgi_keep_conn on;

upstream fastcgi_backend {

    server 127.0.0.1:9000;

     keepalive 8;

}

server {

    …

    location /fastcgi/ {

        fastcgi_pass fastcgi_backend;

         fastcgi_keep_conn on;

        …

    }

}

3.  启用对后端机器HTTP 长连接支持

upstream http_backend {

    server 127.0.0.1:8080;

    keepalive 16;

}

server {

    …

    location /http/ {

        proxy_pass http://http_backend;

        proxy_http_version 1.1;

        proxy_set_header Connection “”;

        …

    }

}

注意:需要设置nginx 代理请求的 http 协议版本号为 1.1,  以及清除掉 Connection 请求header,  官方文档描述:

For HTTP, the proxy_http_version directive should be set to “ 1.1 ”  and the “ Connection ”  header field should be cleared .

The connections parameter should be set low enough to allow upstream servers to process additional new incoming connections as well.

即是说:keepalive N 指令中 , N 的值应该尽可能设置小一些,以便后端机器可以同时接受新的连接。

Too many connections

在php的日志里我们看到了如下的告警日志:
mysql_connect(): Too many connections

查看默认参数:
mysql> show variables;

实时修改:
mysql> set global wait_timeout=10;
Query OK, 0 rows affected (0.01 sec)

mysql> set GLOBAL max_connections=1024;
Query OK, 0 rows affected (0.00 sec)

注意 interactive_timeout  和 wait_timeout,根据不同场景,修改不同的参数。

还可以修改 my.cnf , 然后 重启 mysqld 服务。

还需要关注查询慢的本质原因:

1)DB是innodb 还是myisam

2)  高频查询的表的index创建是否合理

3)业务的mysql 语句写的是否合理

如果以上还搞不定,就需要考虑 分库分表 , 加proxy 做集群来分流了。

关于IOS后台socket长连接的问题

1. 进程退到后体后,只有3-10的时间,如果没有进一步处理,处于功耗考虑,socket就会被系统关闭。 2. ios8后,允许后台,ios8之前的版本,只能通过设置后台模式 Required background modes来实现,但如果本身没有voip功能,苹果审查会遭拒。 ①打开info.plist,添加下面的键值对: Required background modes = App provides Voice over IP services ②配置XMPPStream的enableBackgroundingOnSocket属性为YES: _xmppStream.enableBackgroundingOnSocket = YES; 3. 参考 http://my.oschina.net/bankofchina/blog/281233 voip的方法,理论上定位消息也可以实现 4. 网上大段都是voip的例子,但按照苹果的审查规范,用voip实现后台keepalive 而没有实现voip是会被拒的。 综上所述,ios8以后,直接支持后台。ios8以前的,理论上gps位置信息也是可以在后台触发,从而通过策略实现长连接的,目前没有看到验证的例子,可以在这个方向下尝试下,毕竟所有的app都是需要位置服务器的,不属于伪造服务

c++编译工具链

1. gcc

yum -y install gcc automake autoconf libtool make

安装g++:

yum install gcc gcc-c++

2. protobuf

protobuf-2.4.1.tar.gz

./configure –prefix=/usr/local/protobuf
 make
 make check
 make install
sudo vim /etc/profile
 添加
export PATH=$PATH:/usr/local/protobuf/bin/
export PKG_CONFIG_PATH=/usr/local/protobuf/lib/pkgconfig/
保存执行
source /etc/profile

3. google 库文件,将google的库文件路径添加到gcc 编译路径

1).加到gcc的环境变量 C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, OBJC_INCLUDE_PATH

2).放到系统默认目录
/usr/include
/usr/local/include

我们选择直接拷贝protobuf 生成的目录 includegoogle  到 /usr/local/include 下

4. zlib

编译时提示:”/usr/bin/ld: cannot find -lz”

解决:去lib64目录下看是有libz  相关库的,根据好使的环境比对,猜测是缺少特定的连接

# ln -s libz.so.1 libz.so

编译ok…

 

使用Sublime Text3+Ctags+Cscope替代Source Insight

参考:https://www.zybuluo.com/lanxinyuchs/note/33551

说明:以Windows系统下查看C++代码为例。因为Source Insight(以下简称SI)是收费软件,且界面丑陋,所以考虑其替代方案,发现Sublime Text3(以下简称ST3) + Ctags + Cscope 可以取得很好的效果。使用ST3基本可以实现全键盘操作,同时它又没有学习Vim的陡峭曲线。

安装方法

1. 安装Package Control for ST3

 https://packagecontrol.io/installation

2. 安装Ctags插件

(1) 通过 Preference -> Package Control -> Install Package安装Ctags插件
(2) 下载 Ctags.exe, 通过 Preference -> Package Settings -> Ctags -> Settings Default 中的内容拷贝到 Setting User中,将 command": "" 中的 "" 填入Ctags.exe的路径位置
(3) 在工程根目录上点击右键,选择Ctags:Rebuild tags

3. 安装Cscope插件

(1) 通过 Preference -> Package Control -> Install Package安装Cscope插件
(2) 下载 Cscope.exe, 并在工程根目录下生成cscope.out文件
(3) 打开CscopeSublime.sublime-settings文件(可能需要添加到 Package -> User 目录下),将 "executable": "" 中的"" 填入Cscope.exe的路径位置,将 "database_location": "" 中的 ""填入cscope.out的路径位置

功能实现:

(1) 对于symbol函数的定义查询,ST3自带此功能Go to Definition,且搜索结果有多个时可以预览,不用跳转到另一个文件。Ctags也有此功能navigate_to_definition,搜索结果比ST3要准确一些,但多结果时不支持预览。Csope也有此功能 Cscope: look up function defintion,但搜索结果不支持双击点开。因此实际中多用ST3和Ctags来实现此功能
(2) 对于symbol变量的定义查询,ST3不支持,Ctags有此功能,方法同其查询symbol函数的定义一致。Cscope也可以用查询symbol函数定义的方法实现此功能,搜索结果不支持双击点开。因此实际中多用Ctags来实现此功能
(3) 对于函数caller的查询,只有Cscope有此功能Cscope: look up function calling this function
(4) 全局搜索, ST3可通过Ctrl+Shift+F实现,但搜索耗时较长。Cscope可通过Cscope: look up symbol实现,因为已经通过cscope.out建立了索引,所以结果很快,但结果不一定全面

:使用Cscope的功能时,需按enter键确定才会执行

比较:ST3 + Ctags + Cscope的方案基本可以实现Source Insight的常用有效功能(除了查看类继承关系的Relation Windows),且其速度更快,界面也更为清爽。ST3相比于SI的其他优点还包括:
(1)ST3使用Ctrl+P搜索文件时,使用的是模糊匹配,不像SI必须顺次拼写正确才行
(2)ST3支持tab模式,可方便的在多个文件间切换

ST3实用技巧

(1) Alt+O可以实现头文件和源文件之间的快速切换
(2) 通过 View -> Side bar 可在左侧显示当前打开的文件列表
(3) ST3虽然不像notepad++可以在sidebar上显示函数列表,但是可通过Ctrl+R查看
(3) 通过 Preference -> Key binding user 可根据个人操作习惯自定义快捷键(包括ST3自带的和插件的)
(4) 双击可选中光标所在单词,三击可选中光标所在行
(5) Ctrl+Shift+T可以打开之前关闭的tab页,这点同chrome是一样的

RVCT 远程license 问题

错误:

Error: C9932E: Cannot obtain license for Compiler (feature compiler) with licens
e version >= 3.1:
Terminal Server remote client not allowed.
Feature: compiler
License path: D:ARMLicenseslicense.lic
FLEXnet Licensing error:-103,577
For further information, refer to the FLEXnet Licensing End User Guide,
available at “www.macrovision.com”.

解决:rvds.dat里HOSTID=XXXXX之后加上TS_OK就可以了

Hanging Sockets and Power Consumption – Basics, Part 3

很好的文章,就mobile 空socket 的耗电状态做了深入的分析.

更完整的内容参见:trepn-whitepaper-apps-power

from:https://developer.qualcomm.com/blog/hanging-sockets-and-power-consumption-basics-part-3

Continuing our series on mobile apps and their effect on battery drain, I’ll pick up where the three guidelines in Wayne Lee’s last post left off, especially #3: “Know what your app is doing with the hardware and when it’s doing it.”

One common way that mobile apps use too much power is through hanging sockets –network connections that the app is no longer using, but which the server thinks are still alive because the app has not closed them. The subsequent query from the server results in needless battery drain.

Here’s more background on the problem and how you can deal with it.

“Wake up. It’s time to go to sleep.”

Applications often “forget” to close their socket after they are done with it. Then, after some amount of time without data activity, the server times the socket out and closes it.

Socket termination in TCP requires a four-way handshake, so the server has to send a FIN packet to the device, which usually takes the device from the low-power dormant state to the higher-power active state. The device goes idle for a bit, then back to dormant. It’s like waking somebody up to tell them that it’s time to go to sleep.

Look at the example in the diagram. The red (1) shows the device jumping from dormant to active mode to send and receive data normally for a few seconds. Once finished, the cellular radio drops to a power-saving idle mode (2) in case that it’s needed again. After about 15 seconds of inactivity, the radio goes dormant (3).

    The diagram shows inefficiencies in Socket Termination activity on a device, the multiple steps it goes through to send/receive data and why it’s important to close sockets.

But the app has left the socket open (hanging). The server doesn’t like loose ends, so it sends its FIN packet to the device. This rouses the radio from dormant to active again (4), the same as if it were sending/receiving data for the app. Worse yet, the radio follows the normal curve back down to idle for another 15 seconds, wasting more power (5).

Begin to get the idea?

The phone has to bring up the radio for a simple, easily avoidable handshake because the server has asked the device for something that the app should have provided in the first place. If no other traffic moves between the device and the network, the connection is a complete waste of several hundred milliamperes.

Assuming that the app uses the network four times in an hour, the simple fix of having the app close the socket when finished can reduce network power consumption by about 20 percent, which would be the difference between eight and ten hours of standby power.

The lesson is: Program your app to close sockets when it has finished with them. Otherwise, the phone consumes power to bring up the radio for a needless handshake with the server.

Next Steps

So, to paraphrase Wayne, you need to know what your app is doing with the cellular radio, when it’s doing it and how to turn it off when the app no longer needs it.

Questions? Visit the Trepn Profiler Support Forum or let me know in the comments below.

mysql 中文乱码

默认:
mysql> show variables like “character_set%”;
+————————–+—————————-+
| Variable_name            | Value                      |
+————————–+—————————-+
| character_set_client     | latin1                     |
| character_set_connection | latin1                     |
| character_set_database   | latin1                     |
| character_set_filesystem | binary                     |
| character_set_results    | latin1                     |
| character_set_server     | latin1                     |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+————————–+—————————-+
8 rows in set (0.00 sec)
*************************************************************
*************************************************************
1.修改/etc/my.cnf文件,改成这样:
[mysqld]
default-character-set=utf8
init_connect=’SET NAMES utf8′
[client]
default-character-set=utf8
2./etc/init.d/mysqld restart 重新启动mysql;
mysql重启后字符集更改仍然生效。
mysql> show variables like “character_set%”;
+————————–+—————————-+
| Variable_name            | Value                      |
+————————–+—————————-+
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | utf8                       |
| character_set_filesystem | binary                     |
| character_set_results    | utf8                       |
| character_set_server     | utf8                       |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+————————–+—————————-+
8 rows in set (0.00 sec)
*************************************************************
*************************************************************
注意执行命令:
SET NAMES ‘utf8’;
它相当于下面的三句指令:
SET character_set_client = utf8;
SET character_set_results = utf8;
SET character_set_connection = utf8;