lua 5.3官方英文手册 lua 5.3runoob.com中文手册 交互栈注意事项 栈不是一个全局性的结构，每次函数调用都有自己的私有交互栈。尽管出现递归调用，还是有各自的私用栈。 压/弹栈中的元素个数，具体要看capi的实现来理清元素的位置，否侧参数/返回值个数不对，或类型错误引起逻辑错误。常见的规则如下 lua_toXXX系列函数，都不会将栈顶元素弹出 lua_call，lua_settop这类通过参数，影响弹出多个栈顶元素 lua_next务必符合特定的栈结构，才能遍历元素。 不是所用capi都支持伪索引LUA_REGISTRYINDEX，lua_pcall的第四个参数异常处理函数，就不支持伪索引。 ...

最近想写一个轻巧的日志库。在google搜索有关高性能日志的实现原理。 大多认为用mmap技术可以避免由内核到用户态的页交换。而且当进程崩溃时,内核保证mmap的内存最终都能写入磁盘（但具体啥时候程序已经不可控）。 有人认为日志库的一大特性就是顺序写，读/写缺页依然要中断，mmap与fwrite在这方面性能相差无几。 以下是我在v2ex提的帖子，反对使用mmap的理由较多 mmap相比于fwrite写日志，是否有性能优势 原文: https://lizijie.github.io/2021/07/31/mmap-%E7%9B%B8%E6%AF%94%E4%BA%8E-fwrite-%E5%86%99%E6%97%A5%E5%BF%97-%E6%98%AF%E5%90%A...

需求 答题系统,允许角色每天最多答对N道题目。 如果当天题库数量大于N，则要求当天答对的题目不能再出现。 糟糕的代码 以下是生成题目ID的实现大致如下，主要问题是作者没有想到很好的去重办法， 侥幸以为只要尽可能多的循环次数（2倍题库数量），来降低题目再次出现的概率，然而重复的题目还是出现了，这段糟糕的代码才“有幸”见于诸位。 lua代码 -- tQuestSave 记录当天答对题目 -- iQuestListSize 题库的数量 function GenQuestId(tQuestSave, iQuestListSize) local iTargetQuestId = -1 for i = 1, iQuestListSize * 2, 1 do i...

本文并非介绍框架设计。只是想通过这个案例，单地表述解决本文问题思路。 基于上一篇《生成赛事对阵图-排序》，得到小区归总有序的前16名信息 [TOC] 问题 让前4名有机会同时出现在冠军赛和季军赛 其它情况随机分组 已知 保证集合有序,且长度>=16 解决 借鉴Knuth-Durstenfeld Shuffle的算法思路，本算法特别之处在于保打乱局部范围的元素，最终令相邻的元素在一个分组。决定打乱哪些元素由外层指定，如打乱奇数位的元素，则传入{1,3,5,7,9,11,13,15} 1. 满足需求1和2 1.1 第2名交换到索引9的位置，即第5组 1.2 第3名交换到索引5的位置，即第3组 1.3 第4名交换到索引13的位置，即第7...

本文并非介绍框架设计。只是想通过这个案例，单地表述解决本文问题思路。 [TOC] 问题 有一个大区（跨服）玩法，各小区积分归总后的前16名可以参加后续的淘汰赛。 #已知 各个小区榜均已排序 归总后的数据长度>=16 解决 借鉴选择排序的思路，但由于各个集合本身有序，所以无需遍历各个集合求最大值。另外只需要归总后最高的16名，所以不需要对所有集合排序。 每次从N个有序集中，选出一个最大值 由于是有序集，后面的元素不可能比之前的大，所以已被选取的索引，之后不需要再被遍历，tOffsetMap记录各个集合最后的索引位置 Lua代码 math.randomseed(os.time()) local function sortset(s, n) ...

[TOC] 新人容易忘记要先设计GameView分辨率大小再开发界面。 从技术层面，我想一个解决办法是，分辨率默在配置表中定义，当首次打开Unity工程时，GameView默认使用这个分辨率。 翻了UnityEditor源码，发现其并不开放设置GameView窗口的接口。于是写了以下代码，尝试通过修改其配置文件GameView.asset,window下文件大概在C:/Users/YOUR_USER_NAME/AppData/Roaming/Unity/Editor-5.x/Preferences。同时Unity也不开放其内部YAML的序列化接口，于使用了AssetStore的第三库YamlDotNet。但YamlDotNet的输出内容，Unity原生的YAML格式，有一下差...

[TOC] 思考问题要从问题的原点出发，套用某个方案是解决问题的错误思路。我写这个主题，是因为大多数人（包括我也是），在解决问题时，常常不经过具体的分析/验证，就贸然使用那些被“吹得牛B哄哄”的解决方案，如程序滥用插件和第三方库，策划抄需求。 按《金字塔原理 》书中的理论，解决目标问题Root，其实是自上而下解决N个子问题（树的深度）的决策树，其特点是重权越大的子问题越在高位，即被优先考虑/解决。 对比套用方案的思路，无疑是一个逆过程，即自下而上，重要的子问题没被优先考虑。最终可能导致目标Root妥协，迎合不是最优的解决方案，令目标Root偏离最初的原意。 不做分析的原因可能有以下几种： 项目进度紧张，没时间做。 对复杂问题。可能是知识/技能不足以分析/解决子问题（...