Zed 编辑器的 gpui v0.2.0 发布
gpui 是一个兼有即时模式和保留模式的 Rust GUI 框架,支持 GPU 加速,也是 Zed 编辑器的 GUI 组件。之前都是通过 git 仓库的方式引入到其他的项目中,现在正式发布到 crates.io。但是它依然处于积极开发中,可能在未来的版本中会有一些不兼容变更。
state-machines v0.1.1 发布
state-machines 是 Ruby 库 state_machines 的 Rust 移植版本。
功能特性
- 层级状态(Hierarchical States)—— 支持自动事件冒泡与状态本地存储的超状态
- 守卫与反向条件(Guards & Unless)—— 事件级与转换级的条件性状态转换
- 回调机制(Callbacks)—— 支持灵活过滤的前置 / 后置 / 环绕钩子
- 异步支持(Async Support)—— 为守卫、动作与回调提供原生
async/await
支持 - 事件载荷(Event Payloads)—— 通过类型安全的载荷在状态转换中传递数据
- 兼容
no_std
(No-std Compatible)—— 可运行于嵌入式设备(如 ESP32、裸机系统) - 内省功能(Introspection)—— 运行时提供元数据,便于调试和可视化
- 类型安全(Type-safe)—— 在编译期验证状态、事件和转换的合法性
Github: https://github.com/state-machines/state-machines-rs
hop-hash - 在最差情况下也能保证性能的哈希表
hop-hash 采用的是改进版的 Hopscotch 哈希算法,即使在最差情况下,也能保证查找和删除操作恒定时间复杂度,并未牺牲过多性能。该实现最多只进行 8 次探测(即最多 128 次键比较,实际通常远少于此),如果启用 sixteen-way 特性,则最多进行 16 次探测。此外,它支持更高的填充密度(可配置至最高 92% 或 97% 的负载因子),而传统哈希表通常以 87.5% 为目标。这种高填充密度对大哈希表的性能的影响微乎其微;但对于小表来说,确实会带来明显的开销。
适用场景
- 期望在最差情况下也能保证性能
- 中等或大型的哈希表,且混合查找/插入/移除操作
- 频繁的迭代操作
不太适用场景
- 哈希表很小
- 绝大部分情况下,都是查找操作
- 期望安全的、广泛应用的且简单的方案
Github: https://github.com/Jesterhearts/hop-hash
--
From 日报小组 Yuan YQ
社区学习交流平台订阅:
评论区
写评论排到了zed的windows beta等待队列, 看起来zed的这个gui对输入法的支持还是有些问题;