让我们来看看我们构建的这五个新应用。您可以在Coni WASM Gallery的浏览器中原生体验它们。

1. 极简Techno视觉化工具 (Minimal Techno Visualizer)

主题: 黑暗、充满驱动力的算法俱乐部能量。 链接: Minimal Techno App

我们想要证明Coni能够编排实时的程序化音乐生成，并将其与繁重的3D几何渲染完美同步。

• 音频引擎: 定制的140 BPM时间线引擎在16分音符的弱拍上触发模拟风格的锯齿波低音线，搭配808风格的合成底鼓，并在高潮段（Drop）引入清脆的基于噪声的军鼓/拍手声。
• WebGL细节: 我们映射了5,000个在16小节“Breakdown”期间反转重力的下落雨粒，以及一个致密脉动的3D几何核心，它在每次底鼓敲击时猛烈绽放，并根据音序器状态从冷青色转变为火橙色。

2. 999Hz 神圣无限 (Divine Infinity 999Hz)

主题: 空灵的数学疗愈。 链接: Divine Infinity 999Hz

这个应用以神圣频率疗愈的概念为核心，是纯粹数学与环境音频的完美结合。

• 音频引擎: 它生成999Hz的“天使频率”正弦波，并辅以微妙的8Hz Theta双耳节拍，以诱导深度放松。
• WebGL细节: 我们在GLSL顶点着色器中使用纯三角函数，将500,000个粒子映射到“伯努利双纽线”（无限大符号）上。它在3D空间中完美渲染，带有微妙的环境光晕和基于深度的不透明度渐隐。

3. 清除脑雾 40Hz (Clear Brain Fog 40Hz)

主题: 几何的清晰与专注。 链接: Clear Brain Fog 40Hz

旨在驱散精神杂念，此应用使用令人着迷的几何图形搭配接地频率。

• 音频引擎: 通过微调两个振荡器（左耳432Hz，右耳472Hz）创建的纯40Hz双耳节拍。
• WebGL细节: 我们在顶点着色器中编程了一个拥有5片旋转花瓣的3D繁花曲线。复杂的重叠曲线产生了一种不断向前运动的错觉，而摄像机实际上根本没有移动，使眼睛陷入一种心流状态。

4. WebGL呼吸引导应用 (WebGL Guided Breathing App)

主题: 控制下的节奏感冥想。 链接: Breathing App

我们很高兴揭晓我们最新的Coni WASM应用程序：WebGL呼吸应用 (WebGL Breathing App)。这是一个从零开始构建的视听体验，旨在引导您完成一段平静的6-2-6呼吸练习（吸气6秒，屏息2秒，呼气6秒）。

打造栩栩如生的UI

与仅仅显示一个不断变大圆圈的传统呼吸计时器不同，我们希望构建一些让人感觉有生命力的东西。我们设计了一个交互式菜单，您可以在其中设置您的心境 (Mood)——从平静 Calm（青色）、温暖 Warm（橙色）或专注 Focus（紫色）中选择。

当您开始练习时，背景环境噪音和程序生成的铃声开始播放。这些声音完全由Web Audio API驱动，并由原生Coni函数无缝调度。通过将逻辑与标准JS运行时的卡顿隔离开来，音频保持完美的连贯性且没有抖动。

GPU的力量

在底层，应用程序生成一个由30,000个几何粒子组成的簇，这些粒子在WebAssembly中原生计算和缓存。我们将这些点连同您选择的心境颜色以及一个连续的 u_breath_factor 传递给WebGL着色器。

当您吸气时，球体膨胀，其半径动态缩放，同时其顶点通过直接在顶点着色器中应用的三角正弦和余弦操作而轻柔起伏。颜色强度也会增加，模拟能量的扩张。

当您呼气时，球体收缩成一个紧凑的核心。

;; 我们完全在WASM中计算阶段
(defn update-phase [t phase-text]
  (let [cycle-time (fmod t 14000.0)
        inhale-time 6000.0
        hold-time 2000.0
        exhale-time 6000.0]
    (if (< cycle-time inhale-time)
      ;; ... 平滑扩展的数学逻辑

通过将视觉变换卸载到GPU，并在WASM中原生保持严格的状态同步，我们实现了如丝般顺滑的60fps体验，感觉非常自然，而不是机械生硬的。

最近，我们通过将核心的Conimo CLI脚本直接嵌入到 conimo 库的 bin 目录中，极大地改善了开发者体验。这意味着您不需要外部的设置脚本——一切都由原生的Coni代码驱动。

在本指南中，我们将带您完成新应用程序的脚手架搭建、运行本地开发服务器，并利用强大的 patom 数据库快速构建一个极简的内容管理系统 (CMS)。

1. 使用 create 搭建脚手架

要开始使用，我们使用内置的 conimo create 命令。Conimo提供了各种内置模板，从最小的SSR设置到完整的实时WebSocket架构，甚至是原生的AI聊天应用程序。

对于CMS，我们需要持久化。csv-store 模板非常适合这个需求，因为它通过 patom 利用了健壮的CSV文件数据库。

运行以下命令来搭建您的项目脚手架：

coni conimo create my-cms --template csv-store

脚手架脚本将瞬间生成一个全栈目录结构：

• backend/: 您的后端HTTP/WebSocket服务器。
• frontend/: 您的WASM编译前端代码。
• coni.edn: 项目配置，会自动注入当前的编译器路径，以确保原生WASM构建无缝工作。

2. 运行开发服务器

创建项目后，启动开发环境就像运行 conimo dev 命令一样简单。

cd my-cms
coni conimo dev

在底层，Conimo开发服务器：

1. 为您的 frontend/ 代码生成一个后台WASM编译进程。
2. 等待直到 main.wasm 和必要的JS桥接完全编译完毕。
3. 自动启动您的 backend/main.coni 服务器。

您现在拥有了一个实时的全栈环境，在这里您的后端服务器和WASM前端无缝连接。

3. 编写CMS

Float32在Coni中到底用在哪里？

原生 float32 数组（make-float32-array、f32-set!、f32-get）是Coni性能层的绝对主干。您会发现它们驱动着：

1. WebGL几何体: 在我们的 deep-focus-webgl 应用中，我们使用 float32 数组在原生层面通过数学方式塑造一个拥有80,000个顶点的大脑矩阵（240,000个浮点数！），然后通过 js/float32-buffer 将其一次性发送给GPU。
2. 游戏引擎粒子系统: 对于像 flappy-bird 或 neon-boids 这样的游戏，并行的 float32 数组无需垃圾回收的停顿，即可跟踪数以千计的X/Y坐标、速度和生命周期。
3. 原始DSP音频: 我们的 sound-nodes 合成器在将复杂的脉冲响应和噪声波形映射到WebAudio通道之前，使用 float32 数组在原生层面计算它们。

错误所在：类型强制转换与 f64.reinterpret_i64

因为这些数组极其关键，它们中的任何错误都将是灾难性的。最近，我们发现了一个问题：将一个精确的整数（如 150）传入 f32-set! 时，会莫名其妙地产生 0.0。

到底发生了什么？在较早版本的WASM编译器中，将整数传递给浮点数setter会导致编译器错误地使用 f64.reinterpret_i64 来解释这些位，从而完全扰乱了底层的值。

解决方案：Float32混沌测试 (Chaos Testing)

我们修补了编译器，以便在插入内存之前将整数正确地强制转换为浮点数，但我们需要一个保证，确保它永远不会再次退化。于是，混沌测试登场了。

在新的 float32_coercion_test.coni 测试套件中，我们构建了一个硬核的混沌测试。我们不是仅仅测试几个顺利通过的数字，而是分配了一个巨大的数组，并用确定性的、伪随机的循环来猛烈敲击它。

(deftest test-f32-chaos
  "针对float32数组边界和类型转换的硬核混沌测试。"
  (let [size 1000
        arr (make-float32-array size)]
    (loop [i 0]
      (if (< i size)
        (let [
          ;; 混合生成极端边缘用例：
          val (if (= (mod i 4) 0) (- 0 i)                   ;; 负整数
                (if (= (mod i 4) 1) (* i 10000)             ;; 大正整数
                  (if (= (mod i 4) 2) (+ i 0.5)             ;; 精确的float32小数
                    0)))                                    ;; 零（整数）
        ]
          (f32-set! arr i val)
          (recur (+ i 1)))
        nil))
    ;; ... 验证循环 ...

通过故意将极端正整数、负边界值、纯零和带有小数的浮点数这种残酷的混合物向 f32-set! 函数抛出1,000次，我们保证了能避免WASM陷阱（traps），并且类型强制转换变得坚不可摧。

如果您写过WebGL代码，您一定深有体会。您最终会将顶点着色器和片段着色器写成庞大、混乱的字符串字面量，散布在整个代码库中。您失去了语法高亮、格式化，而且——对于Lisp黑客来说最悲惨的是——您失去了结构化编辑（Paredit/Slurp/Barf）。

今天，我们非常高兴地宣布，我们通过新的 libs/webgl/src/glsl.coni 库征服了最后的这个前沿阵地。

您现在完全可以使用Coni的原生Lisp语法编写您的GLSL着色器了。

defshader 登场

通过利用Coni强大的AST（抽象语法树）和宏系统，我们构建了 defshader。它接受标准的Lisp形式、类型和数学运算，并在它们到达GPU之前，自动将它们转译为严格的GLSL。

看看为我们的Amplifocus粒子引擎编写的这个片段着色器是多么优雅：

(require "libs/webgl/src/glsl.coni" :all)

(defshader fs-src
  (precision mediump float)
  (varying vec4 v_color)
  
  (defn void main []
    ;; 原生数学运算与坐标映射！
    (set vec2 coord (- gl_PointCoord (vec2 0.5 0.5)))
    (set float dist (length coord))
    
    (if (> dist 0.5)
      (discard))
    
    ;; 使用Lisp S-表达式进行发光（Glow）计算
    (set float glow (- 1.0 (* dist 2.0)))
    (set vec4 final_color (* v_color glow))
    (set gl_FragColor final_color)))

为什么这能颠覆游戏规则？

1. 不再有字符串字面量: 您的着色器是一等代码。它们与应用程序的其余部分格式完美统一。
2. AST级别的验证: Coni编译器可以在它尝试于浏览器中编译WebGL程序之前，就解析并验证您的着色器结构。
3. 结构化编辑: 您可以使用标准的Lisp结构化编辑工具来slurp、barf和操作复杂的GPU数学计算。试着用C风格的GLSL字符串做这些试试！
4. 无缝集成: 将其编译成可用的WebGL着色器极其简单，只需调用我们的 core-gl/gl-shader 函数即可：(core-gl/gl-shader gl (.-FRAGMENT_SHADER gl) fs-src)。

专为浏览器打造的全栈Lisp

有了这次更新，整个流水线终于完整了。从使用 reframe 的DOM操作，到WebAudio合成，到WASM浮点缓冲，再到现在实际的GPU顶点变换——100%都是Coni。

这两个应用程序使用双耳节拍生成40Hz伽马频率——一种与深度专注、记忆唤起和认知提升相关的特定脑波频率。但真正的魔力在底层：它们完全是用Coni WASM编写的。

40Hz伽马波的科学

在深入探讨技术之前，为什么选择40Hz？伽马波是脑波频率中最快的。研究表明，当大脑在40Hz范围内运作时，它与敏锐的感知、问题解决能力和巅峰的注意力相关联。

通过在左耳播放60Hz的正弦波，在右耳播放100Hz的正弦波，大脑会感知到恰好40Hz的频率差“节拍”。这个过程被称为脑波同步（brainwave entrainment），它会温和地将您的认知状态推入伽马频率。

为了展示Coni架构在提供这种体验方面的灵活性，我们构建了该应用的两个截然不同的版本：

1. Canvas版本: deep-focus-40hz

我们的第一个应用程序依赖于传统的2D Canvas和DOM API。我们利用自定义的reframe_wasm库，直接通过WebAssembly以Hiccup风格的DOM生成来处理UI状态和渲染。

音频引擎完全以接近原生的速度细致地管理振荡器。我们甚至构建了一个自动生成铃声系统，它可以实时调制包络——完全避免了JS的开销：

;; 无需JS绑定的富有表现力的WebAudio包络！
(doto (.-gain gain)
  (.linearRampToValueAtTime 0.15 (+ now 2.0))
  (.exponentialRampToValueAtTime 0.001 (+ now 8.0)))

这是在纯Coni中构建一个响应式、高性能音频引擎的完美例子。

2. WebGL性能怪兽: deep-focus-webgl

虽然Canvas版本很棒，但我们想看看我们能将Coni的原生处理能力推到多远。于是deep-focus-webgl（内部代号为Amplifocus）诞生了。

这个版本不再依赖2D Canvas，而是使用纯WebGL渲染一个由80,000个粒子组成的脑矩阵。 是什么让这真正令人兴奋？

• 100%纯Coni: GPU加速的顶点变换和海量粒子数组逻辑都在Coni WASM中原生处理。
• 零JS数学开销: 通过使用Coni的数学库（libs/math），我们计算了数万个顶点的复杂三角函数变换，而无需跨越昂贵的JS-WASM桥梁。

下面看看我们在原生浮点缓冲中塑造3D几何体并将其发送给GPU是多么毫不费力：

;; 在WASM内存中处理8万个顶点，一次性发送给GPU！
(f32-set! *base-points* idx final-x)
(f32-set! *base-points* (+ idx 1) final-sy)
(f32-set! *base-points* (+ idx 2) (* z 1.1))

;; 一次性上传静态几何体
(gl/upload-static-data @*gl-state* (js/float32-buffer *base-points*))

我们只需分配一次浮点数组，原生处理几何数据，然后通过单一缓冲操作将其瞬间送至GPU。

然而，随着生态系统的不断发展（例如添加了我们的Android构建流水线），我们发现工作流中出现了一个小烦恼。要调用Android APK构建器，您必须通过其绝对路径运行脚本：

coni libs/android/bin/build-apk.coni ./my-app

虽然它能用，但感觉不够原生。我们希望提供一种极致的开发者体验，让开发者可以简单地运行：

coni android build-apk ./my-app

今天，我们非常高兴地宣布，我们通过实现由Go的 embed 文件系统驱动的动态子命令路由 (Dynamic Subcommand Routing)，成功填补了这一空白！

它是如何工作的

我们对Go编译器进行了三个关键的架构级修改：

1. 嵌入二进制文件

我们扩展了Go编译器内部的 //go:embed 指令，以自动打包所有模块中的所有 bin/ 目录：

//go:embed libs/*/src libs/*/bin
var embeddedLibs embed.FS

这个简单的改变保证了辅助脚本（如 build-apk.coni）被永久地“烧录”到可执行文件中。

2. 子命令拦截器

我们在CLI参数解析逻辑中引入了一个巧妙的拦截器。现在，如果您运行一个无法识别的命令，比如 coni android build-apk，解析器会拦截它并动态构建一个路径查询：libs/android/bin/build-apk.coni。

它会检查嵌入的文件系统，如果该脚本存在，它会动态地将执行直接重新路由到嵌入的有效载荷！

3. 参数掩码屏蔽

最后一个拼图是保持脚本自身的“错觉”。build-apk.coni 脚本使用 cli/parse-opts 来读取标志（如 -p camera）。如果我们盲目地将参数传递给评估器，脚本会被前面的 android 和 build-apk 令牌搞糊涂。

为了解决这个问题，Go路由器在幕后重写了全局的 os.Args 切片：

os.Args = append([]string{os.Args[0], embeddedPath}, os.Args[3:]...)

从脚本的角度来看，它认为自己是被直接调用的！

结果

其结果就是获得了闪电般快速、无缝的CLI体验。所有的工具和辅助脚本都有机地打包在Coni二进制文件中，通过自然、感觉像原生的子命令即可瞬间访问。

没有额外的下载，没有路径配置。只有纯粹、不受干扰的生产力！

特定平台脚本存在的问题

以前，Coni中的 download-url-to-file 函数依赖于调用特定平台的外部工具：

• 在Linux/macOS上，它会生成一个 curl 进程。
• 在Windows上，它会调用一个使用 System.Net.WebClient 的庞大 powershell 命令。

虽然这种方法可行，但它有几个缺点。首先，调用外部进程既缓慢又消耗资源。其次，依赖外部工具意味着 curl 版本的微妙差异或Windows安全协议可能会导致意想不到的失败。最重要的是，使用这些shell命令顺序下载工件意味着解析大型Maven项目会花费太长时间。

原生解决方案

在提交 9ac76d12 中，我们引入了 sys-http-download，这是一个直接在Go评估器中实现的原生内置函数。这个新的内置函数使用了Go标准的 net/http 客户端。

因为它原生内置在评估器中，所以我们完全避免了进程创建的开销。我们甚至在Go实现中直接加入了一些健壮的重试逻辑，以处理来自Maven Central的速率限制（如果您在没有可识别的User-Agent的情况下请求过快，它经常会抛出429 Too Many Requests错误）。

使用Goroutine进行超级加速

在原生内置函数准备就绪后，真正的魔力发生在我们应用Coni的并发原语时。Coni使用 go、chan、<!（从通道读取）和 >!（写入通道）原生支持Go风格的并发。

我们没有逐个下载工件，而是直接在标准库中设置了一个工作池 (worker pool)：

(let [total-count (count missing)
      result-ch (chan total-count)
      task-ch (chan total-count)]
  ;; 将所有任务推送到任务通道
  (loop [rem missing]
    (if (not (empty? rem))
      (do 
        (>! task-ch (first rem))
        (recur (rest rem)))))
  (close! task-ch)
  
  ;; 生成8个工作goroutine并发处理任务
  (loop [i 0]
    (if (< i 8)
      (do
        (go 
          (loop []
            (let [item (<! task-ch)]
              (if (not (nil? item))
                (do
                  (>! result-ch (download-file-single item repos))
                  (recur))))))
        (recur (+ i 1)))))

  ;; 等待结果并显示进度
  ...)

我们将工作池的上限限制为8个goroutine，以防止网络不堪重负或触发激进的速率限制。