2作者: skuldnorniern大约 1 个月前原帖
最近,我一直在开发Lamina,这是一种编译器基础设施,能够为多种架构生成本地汇编代码,而无需依赖LLVM或Cranelift。它旨在为新语言、教育项目以及任何可以利用自定义语法进行代码生成的项目构建编译器。 Lamina提供了一个完整的管道,从单一的基于SSA的中间表示(IR)直接生成支持目标的汇编代码,而不依赖外部后端。该IR可读性强,并提供了一个易于使用的IRBuilder API,便于通过编程构建。 为了更好地管理代码生成过程,未来将采用新的管道:IR -> MIR -> 本地汇编,并包含优化过程。 主要特点: - 直接代码生成:IR -> 汇编/机器代码,无需LLVM/Cranelift - 基于SSA的IR:单一赋值形式,优化用于分析和优化过程 - 基于MIR的代码生成(实验性):新的中间表示,具有寄存器分配和高级优化 - IRBuilder API:用于构建模块、函数、代码块和控制流的流畅接口 - 可读的IR:易于调试,低于高级语言 - 零外部后端依赖:简化构建和透明管道,同时构建速度更快 优化过程(仅限实验性MIR流): - 控制流:CFG简化、跳转线程、分支优化 - 循环优化:循环融合、循环不变代码移动、循环展开 - 代码移动:复制传播、公共子表达式消除、常量折叠 - 函数优化:内联、尾调用优化 - 算术:强度降低、窥视优化 性能:在256×256矩阵乘法基准测试(300次运行)中,Lamina的实验性基于MIR的代码生成(包括所有优化过程)生成的代码与C/C++/Rust相当(在1.8倍以内),并且比Java、Go、JavaScript和Python更快。实验性的MIR流的结果远快于基于IR -> 汇编的代码生成。 该项目使用Rust(2024版)编写,目前版本为0.0.7。可选的夜间功能支持SIMD、原子占位符和实验性目标。
4作者: cjlooi大约 1 个月前原帖
我对PDF文件感到沮丧,并发现arXiv的HTML版本不够理想,因此我构建了一个完全互动的论文阅读器。<p>功能: • 悬停查看参考文献、引用和公式 • 明亮/黑暗模式 • 自动生成定义/引理/定理的依赖图 • 与滚动同步的目录 • 高亮和注释 • 在任何地方“复制原始LaTeX”<p>推荐论文:视频模型是零样本学习者和推理者(Veo 3) <a href="https://www.sciencestack.ai/arxiv/2509.20328v2" rel="nofollow">https://www.sciencestack.ai/arxiv/2509.20328v2</a>
1作者: acc_10000大约 1 个月前原帖
嗨,HN!我是 lazygotest 的创作者。我之所以开发这个工具,是因为我喜欢 lazygit 的用户体验,并希望为 Go 测试提供同样流畅的体验。现在,你可以不必在终端和编辑器之间切换,也无需滚动查看冗长的测试输出,直接做到以下几点: - 使用类似 Vim 的导航方式浏览包和测试(j/k,gg/G) - 按 Enter 运行测试,并在分屏中实时查看结果 - 跟踪测试历史,并通过按 'r' 快速重新运行失败的测试 - 使用 '/' 过滤测试,专注于重要内容 技术亮点: - 使用 tview([https://github.com/rivo/tview](https://github.com/rivo/tview))构建的 TUI 框架 - Catppuccin Mocha 配色方案,符合 WCAG 2.1 AA 无障碍标准 - 通过向上遍历父目录自动检测 go.mod - 支持 Docker 以实现隔离的测试环境 界面分为四个窗格:左侧为包,右上为测试,中右为历史记录,底部为日志。状态栏显示上下文相关的快捷键。 我正在寻找贡献者!以下是我希望得到帮助的一些领域: - CI/CD 集成:为 lazygotest 运行测试的 GitHub Actions 工作流 - 基准模式:支持 go test -bench 并提供可视化图表 - 覆盖率可视化:显示每个包/测试的代码覆盖率百分比 - 测试生成:根据函数签名自动生成表驱动测试 - 插件系统:允许自定义命令和键绑定 如果你有兴趣参与贡献,代码库遵循清晰架构,域、应用和基础设施层之间有明确的分离。欢迎提交 PR——我希望进行小而专注的更改(尽量不超过 20 行),并包含测试。 我很想听听你的反馈,特别是来自那些花大量时间运行测试的 Go 开发者的意见! 安装方法:`go install -tags tview github.com/YuminosukeSato/lazygotest/cmd/lazygotest@latest`
2作者: andupotorac大约 1 个月前原帖
文本输入在进行复杂提示时速度太慢,尤其是在进行氛围编码或生成媒体时。我为React/Next.js构建了一个完整的语音模式组件(用户界面 + 逻辑 + 转录),它处理了浏览器音频的各种尴尬问题,让你无需担心。此外,我还使用了Gemini 3在一次提示中生成了整个页面。:-)
1作者: andrewdany大约 1 个月前原帖
大多数企业工作并不是因为数据差而变得缓慢,而是因为访问这些数据的界面分散。<p>像“哪些交易停滞不前?”这样一个简单的问题,涉及到仪表板、电子表格、客户关系管理(CRM)、商业智能(BI)工具、内部脚本以及几个Slack讨论。对答案采取行动需要在系统之间切换,这中间的摩擦就是问题所在。<p>Worqlo是一个通过将对话作为接口层、将确定性工作流作为执行层来消除这种摩擦的实验。<p>这个想法很简单:自然语言输入 → 验证后的工作流输出。<p>大型语言模型(LLM)处理意图,结构化工作流引擎负责执行:CRM查询、字段更新、通知、权限和审计日志。该模型从不直接执行操作。<p>以下是其工作原理。<p>为什么选择对话?<p>人们以问题为思维方式,而系统则以模式为思维方式。仪表板在它们之间起到桥梁作用。<p>接口层面不断增加,因为每个系统都暴露出自己的用户界面。工程师最终会构建内部工具、过滤器、查询、分析页面和一次性自动化。这就是用户界面的“税收”。<p>对话减少了表面复杂度,工作流则增加了安全性和确定性。<p>架构(简化版) 用户 → LLM(意图) → 路由器 → 工作流引擎 → 连接器 → 系统<p>LLM<p>提取意图和参数。 没有执行权限。<p>意图路由器<p>将意图映射到已知的工作流模板。<p>工作流引擎<p>按顺序执行步骤: - 模式验证 - 权限检查 - CRM查询 - API更新 - 通知 - 审计日志<p>连接器<p>针对CRM、ERP、内部API和消息系统的严格适配器。<p>如果以下情况发生,工作流引擎将拒绝运行: - 字段不存在 - 数据类型不匹配 - 权限失败 - 工作流模板与用户意图不匹配<p>这可以防止常见的LLM失败案例:虚构字段、不正确的API调用、不安全的操作等。<p>示例查询<p>用户: “给我看看本周DACH的销售管道”<p>内部流程: 意图 = llm.parse(“管道查询”) 验证(意图) 获取(数据) 汇总(统计) 返回(摘要)<p>后续: “将汉莎航空的交易重新分配给朱莉,并提醒亚历克斯跟进”<p>工作流: 按名称查找交易 验证所有权变更 写入CRM更新 发送Slack通知 写入审计日志<p>所有操作都通过确定性的步骤进行。<p>为什么从销售开始?<p>销售CRM结构化且可预测。 工作流重复(重新分配、提醒、跟进)。 延迟很重要。 输出是可测量的。 这使得该领域成为对话工作流的良好测试环境。<p>长期的想法并不局限于销售。 相同的模式适用于运营、财务、市场营销和人力资源。<p>为什么不直接使用“ChatGPT + API”?<p>因为那样会导致速度变慢。<p>LLM并不是可靠的执行引擎。 它们会虚构字段名称、ID、端点和逻辑。 企业系统需要安全、可审计的操作。<p>Worqlo将LLM视为解析器,而不是工作者。<p>执行在一个受控环境中进行,包含: - 工作流模板 - 模式合同 - 基于角色的访问控制(RBAC) - 日志 - 可重复的结果<p>这保持了自然语言的便利性和经典自动化引擎的可靠性。<p>我们正在测试什么<p>我们想看看: - 对话是否可以替代用户界面,处理狭窄、结构化的任务 - 确定性执行是否可以与自然语言意图共存 - 多轮工作流是否真的可以减少操作负担 - 连接器模型是否可以扩展而不产生另一个集成混乱 - 工程师是否更喜欢通过工作流而不是用户界面层来暴露功能<p>现在还为时已早。 但该模型在高容量、低级别的操作工作中似乎很有前景。