西东
之前的社区工作，可以定义为：根用户、根案例的培养。算是完成得很不错。 但是过于依赖官方交流群和作者的形式，很不利于社区发展。 * 交流群的界面，只适合单问题交流；并发问题时一片混乱 * 界面能同时承载的交流人，仅仅少数（绝大数的人会潜水）；否则是疯狂的刷幕 下一阶段规划： ### 1、取消官方的用户交流群（去中心化） 目前有QQ群（1个），和微信群（3个） * 计划2025年2月，群禁言（仅用于同步官方新闻） * 计划2025年4月，群解散 * 官方的用户交流使用流行的开源社区“交流”方式：git issue (可以多问题并发，有记录可搜索) * gitee issue * github issue 用户交流群取消后，将侧重社区的运营： * 预计会新建【Solon 布道者群】、【Solon （代码）贡献者群】、【Solon 生态合作群】、【Solon...
不知道是不是 bug（也可能是使用方式有问题）。这是复现的代码（可以直接 copy 运行）： ```java public class FormatTest { public static void main(String[] args) { // // 当有 Provider::register 类型处理后，@JSONField 注解失效了 // JSONWriter.Context context = new JSONWriter.Context(); context.getProvider().register(Date.class, new ObjectWriter()...
标准规范材料：https://www.rfc-editor.org/rfc/rfc9535.html
参考：可以在 AppContext 里，让其它初始化先完成。然后让异步初始化运行，并等待全部完成。
目前的处理方式，是在执行时： 按自然的线路去运行。当线路经过流入侧（拦栅）时，需要按流出时计数进行拦阻并只让最后一次通过。 优化方向： 1. 添加 ChainBuilder 或 ChainDecl，用于申明 Chain 2. Chain 的构建分为：申明（List 结构） 和 构建（部分 Tree 结构）2部分（或2阶段）。且构建后不允许再调整 3. 构建时对 Chain 做预转换处理，把网关的“后续”节点，转换为“内部”结点。 示意： ``` //旧（所有元素并列，用线连接） 包容网关->a->b-包容网关 //新（部分网关，转为包裹关系。更利于运行） 包容网关(a->b) ``` //有了“包裹”关系后，就不需要栈记录和记数器了。
目前只差 `[start to end]` 语法支持。。。其它都可以扩展支持。比如：`@.a starts with 'a'` （支持操作符有空隔） ```java public class OperatorDemo { public static void main(String[] args) { //::定制操作符（已预置） OperatorLib.register("starts with", (ctx, node, term) -> { ONode leftNode...