https数据包拦截解析这个事之前也做过，不过是借助一个叫 fiddler 的中间代理软件实现的，https协议包其实是在http包之上加了一层ssl加密，所以直接用Wireshark的话只能看到加密后的TCP包内容，没法拿来分析http请求响应的内容。最近发现其实对于浏览器(Chrome，Firefox，其它未测)，可以在Windows系统的环境变量中加入：

最近发现宽带IPv6通了， https://ipv6-test.com 测试可以正确检测出公网IPv6地址（检测到的是Win10 DHCP出来的临时地址），但是又发现ICMP一直不通，于是找了个也有v6地址的朋友帮忙测试一下，发现果然是ping不通，但是连接功能正常，于是想到是系统自带防火墙（Win10 1903，不确定其它版本是否也有此问题…）的问题，结果在防火墙设置里怎么都改不好，后来在microsoft官方上看到了这个： https://answers.microsoft.com/en-us/windows/forum/windows_10-networking/windows-10-firewall-filtering-icmp/527551d0-e477-4dd6-a0a0-eae724940ba3 ，于是照做：

netsh firewall set icmpsetting type=all mode=enable

完事后再测，ICMPv6就能通了，特此记录，以备后需。

Win10的WSL相比Cygwin这类模拟环境来说，确实很好的解决了在Windows下进行Linux相关开发应用的需求，这里简单记录下升级WSL Ubuntu中的git到最新版的方法，以备不时之需：

在使用RapidJson的时候，发现了一个之前很少注意到的问题：

F:\Projects\test\rapidjson-1.1.0\include\rapidjson\document.h(982,70): error : too few arguments provided to function-like macro invocation
if (a < static_cast(-std::numeric_limits::max())

乍一看好像不是很眼熟的错误提示，没看懂什么意思，惯例搜索引擎查，于是很快发现了这个： https://stackoverflow.com/questions/1394132/macro-and-member-function-conflict ，简单一看就反应过来了，原来是成员函数名（这里是max）和之前不知在哪定义过的同名宏max冲突了，编译器把本该作为成员函数调用的max当成宏作了替换，于是就出现了上面的错误。

最近发现Win10推送了1903更新，迫不及待的装上后还没来得及体验各种变化就发现了一个令人恼火的bug，用远程桌面RDP连接1903版Win10时会出现黑屏卡死的问题！具体状态是RDP服务器是一台CPU比较旧的电脑（G1610 B75 GPU为核显），更新1903之前没任何问题，更新1903后用另一台1903的Win10自带的RDP客户端连接，第一次可以正常连接，断开再重连就必出现黑屏卡死的问题！（同时测试了Android、iOS、Mac OSX上的微软官方RDP客户端连，不会出现卡死的问题！）。搜索了下发现微软官方已经确认了这个问题： https://docs.microsoft.com/en-us/windows/release-information/status-windows-10-1903#534msgdesc ，而目前的状态还是 Investigating ，没有解决方法。

首先，发现问题的arcanist版本如下：

arc version
arcanist d92fa96366c0ed50e4257508148aa75192d4fb1f (20 Jun 2019)
libphutil b416093386a225b1d9a2de906899b94cbf4babcb (8 Jul 2019)

错误现象为执行arc feature或arc branch时，提示：

[2019-07-20 13:30:05] ERROR 8: Undefined offset: 1 at [D:\phabricator\arcanist\src\repository\api\ArcanistGitAPI.php:1094]
arcanist(head=master, ref.master=d92fa96366c0), phutil(head=master, ref.master=b416093386a2)
  #0 ArcanistGitAPI::getAllBranches() called at [<arcanist>\src\workflow\ArcanistFeatureWorkflow.php:89]
  #1 ArcanistFeatureWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394]
[2019-07-20 13:30:05] ERROR 8: Undefined offset: 2 at [D:\phabricator\arcanist\src\repository\api\ArcanistGitAPI.php:1094]
arcanist(head=master, ref.master=d92fa96366c0), phutil(head=master, ref.master=b416093386a2)
  #0 ArcanistGitAPI::getAllBranches() called at [<arcanist>\src\workflow\ArcanistFeatureWorkflow.php:89]
  #1 ArcanistFeatureWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394]
[2019-07-20 13:30:05] ERROR 8: Undefined offset: 3 at [D:\phabricator\arcanist\src\repository\api\ArcanistGitAPI.php:1094]
arcanist(head=master, ref.master=d92fa96366c0), phutil(head=master, ref.master=b416093386a2)
  #0 ArcanistGitAPI::getAllBranches() called at [<arcanist>\src\workflow\ArcanistFeatureWorkflow.php:89]
  #1 ArcanistFeatureWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394]
[2019-07-20 13:30:05] ERROR 8: Undefined offset: 4 at [D:\phabricator\arcanist\src\repository\api\ArcanistGitAPI.php:1094]
arcanist(head=master, ref.master=d92fa96366c0), phutil(head=master, ref.master=b416093386a2)
  #0 ArcanistGitAPI::getAllBranches() called at [<arcanist>\src\workflow\ArcanistFeatureWorkflow.php:89]
  #1 ArcanistFeatureWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394]
[2019-07-20 13:30:05] ERROR 8: Undefined offset: 5 at [D:\phabricator\arcanist\src\repository\api\ArcanistGitAPI.php:1094]
arcanist(head=master, ref.master=d92fa96366c0), phutil(head=master, ref.master=b416093386a2)
  #0 ArcanistGitAPI::getAllBranches() called at [<arcanist>\src\workflow\ArcanistFeatureWorkflow.php:89]
  #1 ArcanistFeatureWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394]
Usage Exception: No branches in this working copy.

最近接触了下Vue.js框架，记录个build发布 production 版的部署位置问题：一般情况下，build出的dist直接放到Web服务器的根路径，如 http://www.xxx.com/ 访问就可以了，但如果想要放到子路径下，如 http://www.xxx.com/vue/ ，这时就会发现有资源加载报错了（通过vue-cli一般参数创建的项目， vue版本2.5.2）！

最近把无线路由从y1s换到了k2p，虽然cpu没啥飞跃，反而还没了usb，内存也小了一半，但k2p的无线信号确实是碾压了y1s，据说比newifi3也好些。其实这些年用y1s后总结出的个人对路由器的需求基本就是DDNS动态域名，WOL远程唤醒，端口映射（包括UPNP），再来个某种方式的远程管理路由器（web或者ssh），仔细看看，其实没有什么功能是吃cpu或内存的，真有特别耗资源的应用也不是现在一般水平路由硬件能抗的住的，而且还要平衡功耗，散热等连带问题。

好了，回到正题，这次的问题就是路由换完以后，虽然都是OpenWRT的定制系统（k2p是官改 定制版本： V2.0D 软件版本： 99.8.5.189），但对于我常用的3389远程桌面控制局域网电脑需要的端口映射还是发现了点问题：

最近又在研究远程C/C++项目的linux远程编译调试方法，之前写过一个VS结合VisualGDB搭建OpenWrt交叉编译远程调试开发环境，虽然最终目标平台是OpenWrt，但也算是远程linux编译调试，不过VisualGDB是VS的插件，而且现在新版VS（我看的是2017）已经开始自带支持linux开发了，通过cmake创建编译配置，并且允许在远程linux系统上编译调试：
https://docs.microsoft.com/en-us/cpp/linux/connect-to-your-remote-linux-computer?view=vs-2017，虽然看起来比VisualGDB还差太远…不过，这次的重点并不是VS，因为VS只支持windows（我知道有Mac版了，但是呵呵，那并不是我认识的VS），而对Win和Mac作为远程linux开发host都可以支持的IDE还是有的，那就是JetBrains系的CLion！

然而，不幸的是，在我的CentOS 7 slave虚拟机里，发现CLion需求的remote debug用的GDB版本（ 7.8.x-8.2.x ）并不能满足（7默认yum装的是7.6），那么问题就变成给CentOS 7装个新版本的GDB了…

今天在研究python liblas时，发现使用的IDE PyCharm的一个小功能缺陷：在项目运行配置中的环境变量里无法以追加的方式修改当前环境变量的值，而且又看了下IDEA，相关功能的UI都是一样的，所以应该是JetBrains系的IDE都有同样的问题。
首先，windows下使用python liblas时，除了pip装liblas包以外，还要有相关的原生库，否则import的时候会直接报错。好在win下可以直接通过OSGeo4W安装预编译好的liblas库（ https://trac.osgeo.org/osgeo4w/ ），装好后会有专用的命令行环境快捷方式，看了下和Visual Studio的Developer Command Line Prompt一样，会在这个专用命令行环境里设置一堆环境变量，这时直接运行python项目依然会报错，查了下原来是在加载liblas原生库时寻找Path环境变量里的路径找不到出的错，而专用命令行已经把OSGeo4W的bin加进去了…