fy
> Hi @fy0 Thanks for your pull request. I would like to better understand in what kind of situations you want to control the parser manually. Can you elaborate and...
I got this: ``` { name: "ox80_oxBF", expr: &charClassMatcher{ val: "[\\200-\\277]", ranges: []rune{'\u0080', '¿'}, ignoreCase: false, inverted: false, }, }, ``` It seems ok: >>> ord('¿') 191 >>> ord('\277') 191
> @fy0 Seems like something spooky is going on... I am on Windows using the latest release. What are you on? Same, on windows 11.
> Hi @fy0 Thanks for you suggestions (also in your other issues). At the moment, I do not have a plan nor the resources to work on a new major...
Still happening, 1.30.0
我认为功能上没有问题，最多就是加个开关，但是建议默认开启
去问问吧，我觉得回复最后一条跑团信息，或者带上上次最后几句话，都可以接受
看起来当前行为是如标题所述的获取最后一条并回复的方案。 这几天QQ群的讨论所说，超过200条的情况下此方案无法正常定位，我对实用性感到有些疑虑。另外非qq平台也需要验证。 要不然还是给出最后几句录的话吧 关于重构部分，private统一了是好的。但是几个变量的修改导致了大范围的diff变化，其实不是很建议。 现在只能看出所有指令都需要重新测试，但是以当前PR的功能性来说影响范围不至于此。 改的话建议过测后进行修改。
如果是自编译豹尝试在初始化数据库后执行一条sql： PRAGMA busy_timeout = 30000; 将等待时间延长至30s试试。几分钟的卡顿表示无法理解，io应该没有这么慢吧，可能后续版本需要对io打点分析。 另外就是数据库那个db的大小是多少？怀疑在固定大小以上的db结合较差的磁盘io性能的组合会导致类似卡顿问题触发
有无可能是进程权限问题，数据库是只读权限