Closed RimuruChan closed 1 year ago
🤔
还没时间看
我试了下,等了一分钟,还是一样,之前老的错误没被清掉。感觉还是可能被漏掉
我试了下,等了一分钟,还是一样,之前老的错误没被清掉。感觉还是可能被漏掉
![]()
保存了吗,保存了才会触发更新
我晚点看看,干脆加个锁吧,这样肯定不会同时存在多次检查,也不会频繁触发
我试了下,等了一分钟,还是一样,之前老的错误没被清掉。感觉还是可能被漏掉
![]()
保存了吗,保存了才会触发更新
保存了
我晚点看看,干脆加个锁吧,这样肯定不会同时存在多次检查,也不会频繁触发
加锁会不会卡。。file updated 有可能瞬间触发 几千次的,其他的都等锁么?然后挨个排队处理完?那这起的 xmake 进程量有点多,尽管不是并行起的,但是会挨个起几千次。。
我觉得没必要搞这么麻烦,每次去增删。。
每次检测到 file changed 更新,先清空下 问题列表,完整重新添加现有的就行了。。
参考 https://github.com/xmake-io/xmake-vscode/pull/181/files ,不过这个 patch 测下来也有点小问题。。
https://github.com/xmake-io/xmake-vscode/pull/181 这个 patch 可以,问题列表的更新也解决了,检测延迟我也调整到了 3s 内。。
这里我先 close 了。你可以先测试下,如果有其他问题需要改进,可以再来个新 pr
我晚点看看,干脆加个锁吧,这样肯定不会同时存在多次检查,也不会频繁触发
加锁会不会卡。。file updated 有可能瞬间触发 几千次的,其他的都等锁么?然后挨个排队处理完?那这起的 xmake 进程量有点多,尽管不是并行起的,但是会挨个起几千次。。
加锁不是等待,,是丢进队列,, 队列实际上也就是个flag,就是这次执行完要不要再执行一次而已,, 这样不需要有延迟,也不会不能及时更新
我晚点看看,干脆加个锁吧,这样肯定不会同时存在多次检查,也不会频繁触发
加锁会不会卡。。file updated 有可能瞬间触发 几千次的,其他的都等锁么?然后挨个排队处理完?那这起的 xmake 进程量有点多,尽管不是并行起的,但是会挨个起几千次。。
加锁不是等待,,是丢进队列,, 队列实际上也就是个flag,就是这次执行完要不要再执行一次而已,, 这样不需要有延迟,也不会不能及时更新
那这个队列有可能很大,得 上千 size,并且后续的排队中的是否要执行 还得处理判断,但是其实每次只要最新的一次 xmake check 结果就行了。。没必要还去排队。。
如果 1s 内触发了 1 千次,不管用最开始那次 还是最后那次 xmake check 。。结果都是一样的,因此人为操作 1s 内不可能再去编辑一次,就要去重了就行。。
目前测下来 刚那个 patch 基本修复了我这遇到的问题
如果 1s 内触发了 1 千次,不管用最开始那次 还是最后那次 xmake check 。。结果都是一样的,因此人为操作 1s 内不可能再去编辑一次,就要去重了就行。。
队列实际上也就是个flag,就是这次执行完要不要再执行一次而已,, 这样不需要有延迟,也不会不能及时更新
延迟+加上这个策略=及时响应且不会刷多次
一共只会执行两次
我晚点看看,干脆加个锁吧,这样肯定不会同时存在多次检查,也不会频繁触发
加锁会不会卡。。file updated 有可能瞬间触发 几千次的,其他的都等锁么?然后挨个排队处理完?那这起的 xmake 进程量有点多,尽管不是并行起的,但是会挨个起几千次。。
加锁不是等待,,是丢进队列,, 队列实际上也就是个flag,就是这次执行完要不要再执行一次而已,, 这样不需要有延迟,也不会不能及时更新
那这个队列有可能很大,得 上千 size,并且后续的排队中的是否要执行 还得处理判断,但是其实每次只要最新的一次 xmake check 结果就行了。。没必要还去排队。。
你现在这个十秒内保存两次,在第二次保存就不会有更新。必须要我等十秒再保存,, 而不是在最后一次更新的延迟几秒后自动执行1次保存
我晚点看看,干脆加个锁吧,这样肯定不会同时存在多次检查,也不会频繁触发
加锁会不会卡。。file updated 有可能瞬间触发 几千次的,其他的都等锁么?然后挨个排队处理完?那这起的 xmake 进程量有点多,尽管不是并行起的,但是会挨个起几千次。。
加锁不是等待,,是丢进队列,, 队列实际上也就是个flag,就是这次执行完要不要再执行一次而已,, 这样不需要有延迟,也不会不能及时更新
那这个队列有可能很大,得 上千 size,并且后续的排队中的是否要执行 还得处理判断,但是其实每次只要最新的一次 xmake check 结果就行了。。没必要还去排队。。
你现在这个十秒内保存两次,在第二次保存就不会有更新。必须要我等十秒再保存,,
但现在不用锁,好像也没啥问题了。。10s 我已经改成 < 3s 了
但现在不用锁,好像也没啥问题了。。10s 我已经改成 < 3s 了
问题依然存在,。三秒内保存两次就不会更新,非要我等三秒再去保存一次。
而且三秒,如果xmake进程没有退出,一样会堆进程
但现在不用锁,好像也没啥问题了。。10s 我已经改成 < 3s 了
问题依然存在,。三秒内保存两次就不会更新,非要我等三秒再去保存一次。
这种已经是小概率事件了,毕竟改 xmake.lua 编辑 + 保存,也需要时间的,用户日常改完配置+保存的时间 小于3s 内完成的概率,原本就不大,没必要了,,就算还有用户手速飞快能这么搞,再调整到 <2s 也可以。。再小就真没必要了,概率极低,几乎不影响体验,没必要搞得太复杂。
而且三秒,如果xmake进程没有退出,一样会堆进程
xmake check
不可能 3s 还没退出,又不是 build 。。除非有 bug ,那也是修 xmake
而且 3s xmake check 进程没退出,不管怎么搞都是会堵的
但现在不用锁,好像也没啥问题了。。10s 我已经改成 < 3s 了
问题依然存在,。三秒内保存两次就不会更新,非要我等三秒再去保存一次。
这种已经是小概率事件了,毕竟改 xmake.lua 编辑 + 保存,也需要时间的,用户日常改完配置+保存的时间 小于3s 内完成的概率,原本就不大,没必要了,,就算还有用户手速飞快能这么搞,再调整到 <2s 也可以。。再小就真没必要了,概率极低,几乎不影响体验,没必要搞得太复杂。
而且三秒,如果xmake进程没有退出,一样会堆进程
xmake check
不可能 3s 还没退出,又不是 build 。。除非有 bug ,那也是修 xmake而且 3s xmake check 进程没退出,不管怎么搞都是会堵的
并非小概率事件,因为没有lsp,我要经常保存来workaround, 不是说改完才会保存的,,改配置期间就会频繁保存验证写的是不是对的,, 因为没有lsp,不然也不至于这样搞,,
保存又不是只有xmake操作,,更新compile commands之类的也是,,
只是加延迟根本治标不治本,体验也差,, 加延迟好歹也是我这种,不会丢保存事件,,等到时间了至少更新一次,不用用户去等然后再保存再更新,,
加上请求队列(size1)之后直接治根,也提升体验,, 我晚点看看怎么实现你再看看吧
保存又不是只有xmake操作,,更新compile commands之类的也是,,
现在这个问题诊断 还会去解析 compile commands? 我只看到处理 xmake check 么。。这个不就只需要 xmake.lua 么?
并非小概率事件,因为没有lsp,我要经常保存来workaround, 不是说改完才会保存的,,改配置期间就会频繁保存验证写的是不是对的,, 因为没有lsp,不然也不至于这样搞,,
你可以调到 <1s 试试,我感觉也差不多了。。再怎么频繁保存,也不太可能 <1s,我键盘敲几个键 1s 就过去了。
保存又不是只有xmake操作,,更新compile commands之类的也是,,
现在这个问题诊断 还会去解析 compile commands? 我只看到处理 xmake check 么。。这个不就只需要 xmake.lua 么?
并非小概率事件,因为没有lsp,我要经常保存来workaround, 不是说改完才会保存的,,改配置期间就会频繁保存验证写的是不是对的,, 因为没有lsp,不然也不至于这样搞,,
你可以调到 <1s 试试,我感觉也差不多了。。再怎么频繁保存,也不太可能 <1s,我键盘敲几个键 1s 就过去了。
。。明明有更好的方案,为什么不用呢,旧方案好在哪呢。。
this.updateIntellisense();
这么目前也只是根据 xmake.lua 保存触发,没啥区别
。。明明有更好的方案,为什么不用呢,旧方案好在哪呢。。
就看有没有必要,如果新方案改完,跟现在的大部分情况下 感觉不出来什么差异,必要性也不是那么强烈,当然你有兴趣的话 也可以提 pr 过来看下。。