去官网下载了一个集成开发环境，直接安装。然后报错“Android Studio was unable to find a valid Jvm” google launchctl setenv STUDIO_JDK /Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk 解决之。 网上还有种方法是，finder --应用程序--android studio--显示包内容--contents--info.plist,搜索1.6.将1.6*改成1.6+就ok了。 Fetching android sdk component information，这个不知道具体干嘛的，好几次不成功。 同样的目录，contents/bin/idea.properties,最后加一行disable.android.first.run=true。 打开后的配置，configure--project Defaults--Project Structure--Android SDK location 添上 /Users/a0x55aa/Library/Android/sdk

tornado.ioloop.IOLoop.instance().start() ioloop继承自Configurable。 configurable_base返回IOLoop，然后调用configured_class，然后再看IOLoop的configurable_default。这里面根据不同系统选择了不同的IOLoop类实现返回。下一步是initialize初始化了。 看一下epoll吧。 先找了一下IOLoop的start()，意料之中。因为configurable_default返回的类实现都是别的类，要看具体别的类中的定义了。 epoll.py里的EPollIOLoop只定义了initialize，EPollIOLoop继承自PollIOLoop，在ioloop.py文件里。 PollIOLoop继承自IOLoop，现在还不知道为什么这么继承，先往下看。super，IOLoop里边是空的。下边用到initialize第二个参数是impl。在PollIOLoop里是select.epoll()。还要去看看platform/select.py，额 我去还是import select。标准库中的select.epoll()返回一个epoll obj。判断是否有fileno属性，这个方法是返回一个文件描述符的。然后不知道是怎么操作这个句柄的不懂。先过。。 设置了一堆值。看platform/common.py里的Waker.继承自interface.Waker.父类只是定义了几个方法名。 先看初始化，self.write是个socket.self.writer.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)注释说禁止buffer，有数据就立即发送。 下边是做了一个测试，好像有些系统不支持检查出来。 下边又没懂，a都关闭了，还要那个文件描述符干嘛.这块后边做个测试研究一下。 初始化完了回到PollIOLoop，add_handler，第一个参数a的文件描述符，第二个参数consume是从a读数据读完为止。第三个参数是IOLoop里定义的，这里体现出继承的意义来了。 看add_handler，spit_fd取文件描述符，第二个handlers空，添加fd为key，文件描述符，handler为值。 没看懂，注释说就为了在io loop空闲时，想让他醒来发送假数据，这里也先过，网络方面的还是懂的太少了 然后初始化完成了。。下边是调用instance()了。这个只有在IOLoop里有定义，这里才是真正的继承意义。开始是没有_instance的，然后加锁，定义个实例IOLoop()返回这个实例。 饶了这么多圈终于实例化了。。。卧槽来 然后start(),PollIOLoop里，这里开始ioloop的循环执行了。详细的先不看了，看了一下等后边仔细分析一下。上边的waker也是结合这里一起再看一遍。

想看一下IOLoop类的实现，发现继承自Configurable。就先看一下这个类。 Configurable类在util.py这个文件里。Configurable类的子类有AsyncHTTPClient，Resolver，IOLoop。 看__new__构造方法，configurable_base返回一个子类的实现，如果返回类本身。类的实现需要调用configured_class，主要初始化了__impl_class在configurable_default里。然后通过子类中configurable_default的定义选择不同的__impl_class（类实现）返回。initialize初始化类。 然后没了 ，没想到这么短。等后边看看IOLoop。

记录，说不定以后还能用到。打jar包指定main程序入口

public class Hello{
    public static void main(String[] args){
        System.out.println("hello");
    }
}

java版helloworld。保存成Hello.java。执行 javac Hello.java会生成Hello.class jar cvf hello.jar Hello.class生成hello.jar 现在直接执行java -jar hello.jar会提示“hello.jar中没有主清单属性”要先指定程序入口 解压hello.jar，会看到/META-INF/MANIFEST.MF文件 Manifest-Version: 1.0 Created-By: 1.8.0_25 (Oracle Corporation) 加上两行 Class-Path: . Main-Class: Hello 执行 jar umfv MANIFEST.MF hello.jar 更新一下jar包里边的文件 执行java -jar hello.jar 成功显示hello。

github地址 https://github.com/0x55aa/pytoto 写不下去了，又开始写别的了 我去。 总是做着做着发现东西越来越多。

在django/conf/__init__.py里，最后一行，settings = LazySettings()。到LazySettings()，继承自LazyObject，django/utils/functional.py里，初始化的时候self._wrapped为object()。LazyObject也设置了__getattr__，不过差不多。回头看LazySettings的__getattr__，开始要执行_setup，然后使用getattr取值。 ---- def _setup(self, name=None): settings_module = os.environ[ENVIRONMENT_VARIABLE]，这个在wsgi脚本，或者在manage.py里有设置，就是项目的setting，例如mysite.settings。然后self._wrapped = Settings(settings_module)。Settings应该是设置值的。 ---- Settings集成自BaseSettings，BaseSettings里只有一个__setattr__方法。看Settings的init方法，第一步导入global_settings，在同一个目录里，定义了全局的setting。导入使用dir获得所有变量名，判断变量名如果全为大写，就setattr。然后看BaseSettings，第一个判读"MEDIA_URL", "STATIC_URL"，必须以’/‘结尾。然后判断ALLOWED_INCLUDE_ROOTS必须是str，然后就设置。 然后使用import_module()导入项目settings，py3带的这个功能。。。 然后后边类似的判断导入项目settings，其中"INSTALLED_APPS", "TEMPLATE_DIRS"必须是tuple，不能是str不然设置成tuple。必须有SECRET_KEY，设置TIME_ZONE。ok了，导入变量完毕了。 ---- self._configure_logging() settings里的日志设置，先不看了，以后再说。

今天领导推荐这个项目，中午看了一下，核心就是一个函数一条命令。最后精简为 gdb -p 9252 -batch -eval-command='call PyGILState_Ensure()' -eval-command='call PyRun_SimpleString("exec(open(\"/home/a0x55aa/code/toto/hello.py\").read())")' -eval-command='call PyGILState_Release($1)' 如果提示“ptrace: 不允许的操作.”执行命令：echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope就好了。 用到gdb和python gil相关知识，不怎么懂，感觉就是与正在运行的进程争抢python虚拟机，执行完文件里的代码，over。 正好在grep ps命令的时候，看到执行python manager.py runserver 的进程有两个（为啥两个读源码里读到）。然后我查了一下ps命令的stat字段都是什么意思。 D 不能中断的进程（通常为IO） R 正在运行中的进程 S 已经中断的进程，通常情况下，系统中大部分进程都是这个状态 T 已经停止或者暂停的进程，如果我们正在运行一个命令，比如说sleep 10，如果我们按一下ctrl -z 让他暂停，那么我们用ps查看就会显示T这个状态 W 这个好像是说，从内核2.6xx 以后，表示为没有足够的内存页分配 X 已经死掉的进程（这个好像从来不会出现） Z 僵尸进程，杀不掉，打不死的垃圾进程，占系统一小点资源，不过没有关系。如果太多，就有问题了。一般不会出现。 下面一些是BSD风格的参数 < 高优先级进程 N 低优先级进程 L 在内存中被锁了内存分页 s 主进程 l 多线程进程 + 代表在前台运行的进程 以前也没用gdb调试过python程序，要学习一下。

urlconf = settings.ROOT_URLCONF urlresolvers.set_urlconf(urlconf) resolver = urlresolvers.RegexURLResolver(r'^/', urlconf) set_urlconf，如果没有设置urlconf的文件路径，保存；有，删掉。下边生成 resolver对象。 resolver_match = resolver.resolve(request.path_info) callback, callback_args, callback_kwargs = resolver_match request.resolver_match = resolver_match 找到RegexURLResolver里的resolve，match = self.regex.search(path)是匹配上边的 r'^/'，也就是path_info必须是’/‘开头，如果不匹配直接404。然后，生成新地址为去掉’/‘剩下的。获得url_patterns，从rulconf得到urlconf_module，从urlconf_module得到urlpatterns，就是url配置文件里的变量。然后返回urlpatterns。 然后遍历urlpatterns，这里要先看一下urls.py里的三个函数了，patterns, include, url。 def include(arg, namespace=None, app_name=None): 判断arg为tuple的写法是：include((urlconf_module, app_name, namespace))并且不能有namespace参数。这种写法没用过 不是tuple，判断arg的类型为string，导入urls.py.然后不是string就是mudule了。然后都获取urls.py里定义的urlpatterns。然后下边验证了一下每一个规则的类型。返回数据。返回的数据和参数一样，当arg为tuple时就是返回arg。 def url(regex, view, kwargs=None, name=None, prefix='') 先判断view为 list或者tuple就是有include的时候，返回RegexURLResolver对象。 否则view是string，返回RegexURLPattern对象。 def patterns(prefix, *args): 还是先判断是否可以为list和tuple，如果是，调用url()。说明在urls.py里url完全可以不写。如果是RegexURLPattern，添加前缀。最后返回所有的regex。也就是说最终的urlpatterns就是一个包含所有RegexURLPattern的list。 上边在dist-packages/django/core/urlresolvers.py里RegexURLPattern里的resolve，for循环urlpatterns，然后用每一个regex对象的resolve方法去匹配新的地址。当是include的时候 对象还是RegexURLResolver，所以还是这个resolve，起到递归循环。当是RegexURLPattern时，如果匹配成功，返回一个ResolverMatch，arg或kwargs是匹配的url参数，再在后边又更新上url()配置里的参数。如果匹配到最后还没匹配到，404。 ResolverMatch有一个ResolverMatch方法，用在这句上，callback, callback_args, callback_kwargs = resolver_match 并且将返回的ResolverMatch存到request里。 url匹配完了

WSGIHandler继承自BaseHandler，BaseHandler初始化的时候_request_middleware和其他moddleware变量都设置为None。 在WSGIHandler中，先通过判断_request_middleware为None，执行load_middleware。 在load_middleware里根据在settings.MIDDLEWARE_CLASSES里的配置导入所有middleware，并判断class里边包含的方法，分别插入相应的middleware列表里。现在_request_middleware是一个列表。load_middleware结束 回到WSGIHandler， set_script_prefix(base.get_script_name(environ))，get_script_name从environ得到SCRIPT_NAME，如果设置settings.FORCE_SCRIPT_NAME，回直接返回settings.FORCE_SCRIPT_NAME，默认为None。django竟然还提供这种碉堡的功能。。。set_script_prefix判断SCRIPT_NAME结尾是否是‘/’不是的话加上，并且在threading local里边保存SCRIPT_NAME。 signals.request_started.send(sender=self.__class__)，用来调用绑定到request_started的方法，大体看了一下没看懂。 request = self.request_class(environ)，得到request，初始化只是设置了一堆的变量。 response = self.get_response(request)，，在get_response里得到urlconf，settings.ROOT_URLCONF就是配置url的入口文件。这里先不看了，以后分析。接着在一个大的try语句里，设置response为None，遍历_request_middleware，只要有response返回就停止。如果执行完response还是none，下边匹配url找到view，然后遍历执行_view_middleware，有response就停止。然后遍历完response还是none执行view。 response = wrapped_callback(request, *callback_args, **callback_kwargs) 如果抛出异常，遍历执行_exception_middleware，返回response不为None就停止，如果最后为None，raise再抛异常。看出exception_middleware只用来在用户写的view里边出现异常的处理。 如果执行完view，还是none，就会抛出The view didn't return an HttpResponse object.的异常。 在这里前边的midddleware，只要有response返回，就不会执行后边的，直接到执行下边了。因为在执行middleware的前边，都先判断response是none才执行。 最后，判断response可调用render，遍历执行_template_response_middleware，最后调用response.render()。这个大的try语句检测执行上边这些操作的404 403等各种异常。 最后遍历执行_response_middleware里的方法，然后调用apply_response_fixes，执行response_fixes里的所有方法修改response。response_fixes在BaseHandler开始定义好了。处理完后返回response。 回到了WSGIHandler，设置http返回的headers，然后直接返回response。 WSGIHandler整个看完了，现在要详细看的好多了。 url的解析部分。 setting middleware里django的默认设置都做了什么。 wrapped_callback调view也看一下。（make_view_atomic这里是数据库事务相关内容） 还有没看懂的signal，以前也没接触过。

django在你执行python manage.py runserver的时候，在修改代码后会自动重启，研究一下是怎么实现的。 django/utils/autoreload.py main(),我只看python_reloader，RUN_MAIN通过搜索源代码，发现只有在这个文件有两处，一个是下边else执行时设置为true。也就是说开始可能没有设置值，先执行restart_with_reloader()。精彩到了。。设置新的environ，RUN_MAIN为True。用os.spawnve启动新的reloader()进程，现在RUN_MAIN为True！然后在restart_with_reloader这个父进程里一直在等待判断子进程是否返回exit code，如果不是3就退出循环结束了。 在的reload进程执行new_thread()，也就是启动一个server。下边执行reloader_thread() ---- reloader_thread()里边 先执行ensure_echo_on()，先判断termios是否导入成功，termios是一个py模块，是unix平台的控制通信端口的，不怎么懂。如果模块没导入成功，将不做任何操作。如果导入成功，从字面意思就是确保echo打开。这不懂，也不是重点。 下边判断RUN_RELOADER，开始为True，进入循环，判断code_changed()，如果只要有一个文件改变code_changed就返回true。然后接着sys.exit(3)。每隔一秒判断一次。 如果py文件改变，执行了sys.exit(3)，然后子进程就会结束。父进程在restart_with_reloader判断exit_code等于三，然后进行下一个while ture的循环。重新创建RUN_MAIN=True的子进程，重新创建一个server，等待（汗）代码修改 然后再退出，，，一直循环下去。 再说说exit_code不等与3的时候，比如子进程在启动server后，reloader_thread等待（再汗）代码改变的时候，你按了ctrl c，然后捕获KeyboardInterrupt异常，代码里什么都不做，然后子线程就会结束，这时exit_code不等于3，直接return exit_code结束了父进程，程序结束了。