代码 > 使用musl代替gcc进行go语言的cgo编译
2022-07-29
最近在发布go代码的时候遇到一些问题
主要是集中在linux版本的gcc上的。
总的来说，gcc的问题有以下几点
1.协议问题，mit协议的代码静态编译gpl的库总觉得有点问题
2.libnss问题，由于gcc本身的特殊性，libnss不能静态编译进去，不然会有各种报错(比如dns解析时panic)
3.glibc版本不匹配问题。
所以换使用musl进行编译。
总体来说，musl提供了一个musl-gcc协议，总体更新跟着不多的文档还是很方便的。
就是各种dev包里一般提供的是glibc编译的版本，之间使用会报错
需要用aptitude source下载代码包
然后通过CC="musl=gcc" ./configure的方式手动编译，得到.a文件，再通过编译脚本以的LDFLAGS中 以-L指定进来。
其他没啥问题，接下去就要进行稳定性测试了。
代码 > Godot到导出wasm过大问题
2022-05-04
研究了下，这个基本无解。
标准是20mb左右
进行功能裁剪后重新打包也有16mb+
通过预压缩可以到4mb左右。
所以，还是只适合大型场景，不适合小场景。
毕竟 Godot功能太强大了吧。
在网络流量和带宽大幅度提速下降之前。
应用godot还是有一定的成本的。
代码 > godot导出为web/html5后与Javascript交互
2022-05-02
继续研究godot
找到了godot与js交互的方式
https://godotengine.org/article/godot-web-progress-report-9
具体API见
https://docs.godotengine.org/en/stable/classes/class_javascript.html
很明显，可以通过:
Javascript.Callbacks 方法，常见可以供js调用的全局方法作为回调接口，可以传入数据
可以通过
Javascript.get_interface 调用封装在js全局域的api
双休调用很容易
很明显，godot可以代替原来Flash领域的大部分工作。
代码 > godot真的不错
2022-04-29
今天测试了下godot,不得不说，真是个好东西。
简单如当年flash的用法，linux原生支持，晚了下自带的骨骼系统做了个简单的骨骼动画，别说在PC浏览器上,连微信浏览器都能使用。
大爱大爱啊。
代码 > golang pprof记录
2021-07-07
mud 客户端有内存泄露，调试了一把，记录一下。
首先，引入 profile库
import "net/http/pprof"
然后合适的地方引入
runtime.SetBlockProfileRate(int(10 * time.Second))
runtime.SetMutexProfileFraction(int(10 * time.Second))
Router.Handle("/debug/pprof/").HandleFunc(pprof.Index)
Router.Handle("/debug/pprof/cmdline").HandleFunc(pprof.Cmdline)
Router.Handle("/debug/pprof/profile").HandleFunc(pprof.Profile)
Router.Handle("/debug/pprof/symbol").HandleFunc(pprof.Symbol)
Router.Handle("/debug/pprof/trace").HandleFunc(pprof.Trace)
SetBlockProfileRate是设置记录block的代码的值，单位是纳秒
SetMutexProfileFraction是设置记录锁起效代码的值。
然后打开debug/pprof页面
allocs 4 block 0 cmdline 17 goroutine 232 heap 0 mutex 0 profile 21 threadcreate 0 trace
其中重点关注的是 goroutine,heap,block几块
goroutine是看实时的goroutine数量和发起位置。如果不停增长，可能是泄露
heap是堆，数值是一直增长的。点入后看到的数据，建议加上gc=1参数强制gc一次
第一行的数字大概是
2: 58368 [2474: 8919408] @ heap/1048576
第二个数字58368是当前堆内存大小，最后一个数字1048576是最大使用的堆内存
然后是按当前使用内存大小的堆信息，大概是
1: 57344 [1: 57344]
第一个57344是当前使用的堆内存
方括号内的57344是最大使用过的堆内存。
代码 > [记录]踩了golang的defer/recover的坑
2021-01-18
今天写代码的时候完了个花活，想复用recover,结果炸了……
体现在recover没起效，直接panic出来了。
查了下，defer里一旦再调用函数，原有上下文就变了，recover就失效了。
想想也有道理。
改了个骚气代码，解决了
q.Recover = func() {
defer n.Recover()
if r := recover(); r != nil {
panic(r)
}
}
代码 > 选择Golang的json schema库蛋疼了
2020-11-02
最近在整理数据验证这一块，看了下json schema下的3款golang 实现，十分蛋疼。
我对于json schema 验证库的要求比较简单，要求就是以下几点
- 能自定义错误信息模板
- 能获取错误类型，进行分类处理
- 能得到错误发生的数据的JSON Pointer
- 能获得错误发生的数据位置的Shcema信息，比如title,描述
这点，php的库
https://docs.opis.io/json-schema/1.x/php-validation-result.html
都能很好的满足。
换成go的库，各有各的问题
https://github.com/xeipuuv/gojsonschema
这个库相对而言最靠谱点，问题是没有JSON Pointer，也没有相关的Schema信息
https://github.com/santhosh-tekuri/jsonschema
这个库有JSON Pointer,但是错误信息只有 数据的pointer,schema的pointer,mesage，非常蛋疼
https://github.com/qri-io/jsonschema
这个库有数据Pointer,但没有schema的数据，只有message。
考虑要拉个库下来改一下了……
代码 > github.com/googollee/go-socket.io的两个坑
2020-05-26
几年前的项目用过socket.io,用了github.com/googollee/go-socket.io这个库起了服务。
最近需要做一点升级，发现了几个蛋疼的坑。
1.BroadcastToRoom反应迟缓
这个好分析，爬了下代码，broadcast的时候是同步的……同步的……同步的……，不是并发的。
万一有连接超时，必须等超时的连接过了timeout才能发下一个……
真有想法。
解决方案：用ForEach方法自己实现一下
func BroadcastToRoom(s *socketio.Server, nsp string, room string, event string, args ...interface{}) {
s.ForEach(nsp, room, func(c socketio.Conn) {
go func() {
c.Emit(event, args)
}()
})
}
2.400错误，提交的信息丢失
这个怕了整个代码，无解。
首先，有错误后不打任何日志，直接返400错误，这个操作略骚
其次，明明每次请求不是异步的，偏要解析payload搞几个chanel搞成异步，然后有pause和resume的状态，判断了pause会报错，这个我也没抓到点。
参考
https://github.com/googollee/go-engine.io/issues/82
解决方案:
检查代码后，websocket没对应的方法……
客户端强制使用websocket....
强制使用websocket我还走一层socket.io干嘛……