## 源代码映射：从共享文档到官方标准
多年来，源代码映射——现代 Web 应用程序调试的关键——一直基于一份 Google 文档中的共同理解运作，缺乏正式标准。这阻碍了功能开发并造成了不一致性。源代码映射弥合了优化/压缩代码与原始代码之间的差距，使开发者能够高效调试。
这种需求源于 2009 年 Google 的 Closure Tools 等工具，这些工具优化了 JavaScript，但需要一种映射回原始代码的方式。早期的源代码映射修订版由于逐字符映射而体积庞大。修订版 3（2011 年）使用 Base64 VLQ 编码、基于片段的位置和相对编码，大大减小了体积——这种格式保持了十多年未变。
尽管成功添加了忽略列表（允许从调试中排除框架文件），但正式标准变得至关重要。2023 年，TC39-TG4 成立以标准化源代码映射，最终形成了 ECMA-426。
未来的工作重点是“作用域”（嵌入作用域和绑定信息以获得更好的堆栈跟踪）和“范围映射”（高效映射文本范围，提高组合源代码映射的精度）。这种标准化有望为源代码映射和整个 JavaScript 生态系统带来更强大和不断发展的未来。
每日HackerNews RSS
## 源码映射标准化讨论
最近的 Hacker News 讨论集中在源码映射标准化工作上——这些文件将编译后的代码映射回其原始源代码，用于调试目的。当前的“标准”很大程度上源于 Chrome 对设计文档的实现，并通过实际使用成为事实上的标准。
对话强调了现有调试格式（如 DWARF）的复杂性，DWARF 使用多种字节码格式（甚至有图灵完备的格式！）来执行地址映射和变量定位等任务。一些评论员建议可以从 debuginfo 维护者和较新的格式（如 RDI）中吸取经验。
除了调试之外，源码映射对于语言扩展和工具（如语言服务器协议 (LSP) 服务器）也越来越重要。多位用户对正在进行中的标准化过程表示兴奋，认为这对于改进 Web 平台至关重要，并承认有必要改进该领域的规范。 也有一些对过去脚本语言简单性的承诺与调试现实之间差距的无奈。
迷泽庆祝那些诙谐的讲述者和民俗学家，他们收集故事，以及故事的归属地。它为古老的故事注入了新的生命，通过动画或插图讲述它们，在街头和社区场所，用木偶和人们，在扶手椅上和三轮车上，像博德明沼泽老风暴女人的风一样，将故事散布在整个康沃尔。如果你丢失了什么东西；你的钥匙、你的笔，或者在沼泽上迷失了方向……或者，如果你忘记了你想说什么，或者你上楼做什么……你一定是被小精灵们迷惑了。治愈小精灵迷宫的唯一方法就是把口袋翻过来。有些故事很吓人——使用睡前故事按钮来寻找适合小孩子的故事。迷泽网站上的故事是用来被讲述的——讲述它们，并使它们成为你自己的。……准备好被迷泽惊艳吧！
黑客新闻 新的 | 过去的 | 评论 | 提问 | 展示 | 工作 | 提交 登录
来自康沃尔的传统故事，附带故事地点地图 (mazedtales.org)
14 分，由 ohjeez 发表于 23 小时前 | 隐藏 | 过去的 | 收藏 | 1 条评论 帮助
steve_gh 发表于 19 小时前 [–]
美好的故事。我是一个热衷的攀岩者 - 其中一个故事刚刚向我解释了为什么格韦纳普角的壮丽海崖被称为 Chair Ladder（椅子梯）。回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
## Snail：Emacs 的 Julia 开发环境
Snail 是一个强大的 Julia 开发环境，旨在 Emacs 中复制 SLIME (Common Lisp) 和 CIDER (Clojure) 的体验。它提供了一种动态的、REPL 驱动的工作流程，利用 libvterm 或 Eat 等高级终端模拟器来实现高性能和稳定的 REPL 显示。
**主要特性：**
* **REPL 交互：** 桥接 Emacs 和 Julia 进程，实现代码加载、函数定义和内省。
* **远程 REPL：** 支持通过 SSH 和 Tramp 与远程机器上的 Julia 会话无缝交互。
* **多媒体与绘图：** 直接在 Emacs 中显示 Julia 图形。
* **代码感知：** 使用 Julia 解析器 (CSTParser) 进行准确的代码理解，从而实现诸如交叉引用和模块感知补全等功能。
* **可扩展性：** 支持可选扩展，用于实现 REPL 历史记录、代码格式化、Org-mode 集成和调试等功能。
**设置要求：** Emacs 26.2+（具有模块支持），安装 libvterm 或 Eat，以及 `julia-snail` 包。配置通常涉及将 `julia-snail-executable` 设置为指向您的 Julia 二进制文件，并可能调整显示设置。项目特定设置可以通过 `.dir-locals.el` 文件进行管理。
## Hacker News 上关于 Julia Snail 和 Emacs 的讨论
Hacker News 上的一场讨论围绕着 **Julia Snail** 展开，这是一个为 Julia 编程语言设计的新的 Emacs 开发环境，灵感来自 Clojure 的 Cider。最初的帖子引发了关于 Emacs 使用体验的更广泛的对话，特别是它的易用性和性能。
一些用户表达了对其他语言（如 Haskell）类似强大 REPL 环境的需求。然而，一个反复出现的主题是对 Emacs 本身的沮丧。抱怨从启动时间慢、bug 众多，到总体上过时且难以驾驭的用户体验。
Emacs 的捍卫者强调了它的可定制性和强大的键盘驱动界面，认为它不需要是最先进的才能有效。其他人则指出了像 Elpaca 这样的包管理解决方案，以及 Emacs 与 macOS 规范的良好集成。
最终，这场争论揭示了一个分歧：有些人认为 Emacs 的灵活性是无价的，而另一些人则认为它是一种阻碍现代开发流程的遗物。讨论还涉及 Emacs 社区对批评的抵触情绪。
我构建了一个用于后端配置错误的拼写检查器。
Show HN: Safelaunch – Validates your environment before you push to production
2 天前
启用 JavaScript 和 Cookie 以继续。
## Safelaunch：防止“在我机器上能运行”的部署问题
一位开发者在Hacker News分享了“Safelaunch”，这是一款旨在解决部署失败却在本地测试通过的常见问题的工具。问题源于开发环境和生产环境之间的差异——通常是一些简单的事情，例如缺少环境变量或`.env`和`.env.example`文件不匹配。
Safelaunch直接比较这些文件，在部署*之前*标记出缺失的必需变量，充当后端配置的“拼写检查器”。它可以在本地作为CLI运行，也可以集成到CI流水线中。
创建者正在寻求对其实用性的反馈，并询问其他人是否经常遇到这个问题。一位评论者认为，大多数应用程序已经在启动时实现了环境变量解析，并将`.env`文件进行比较可能是一种脆弱的解决方案。
更多信息请访问[npmjs.com](npmjs.com)。
## 构建更好的编辑器：一次个人旅程
对现有的文本编辑器感到不满——即使尝试了 Helix、VS Code 和 Vim 等许多编辑器——一位程序员开始构建自己的编辑器。现有工具在对其工作流程至关重要的领域表现不足：高效的项目范围搜索、无缝的 SSH 访问以及功能完善的集成终端。
该项目优先考虑个人需求而非广泛的功能集，专注于为开发人员特定语言和习惯量身定制的简化体验。主要成果包括一个受 Howl 启发的快速文件浏览器、一个高度优化的正则表达式引擎，用于语法高亮和搜索，以及一个基于 Alacritty crate 构建的终端模拟器。通过诸如按需高亮和最小化终端重绘等技术来提高性能。
该开发者强调构建自定义工具的好处：完美适应个人工作流程、加深技术理解、提高生产力，最重要的是，重燃编程的乐趣。这个过程虽然具有挑战性，但却非常有价值，将重点从与工具作斗争转移到创造性问题解决，并重新点燃了对这项技艺的热情。最终，这段经历倡导工程师们拥抱构建自己的工具，在奋斗中找到乐趣，并获得由此带来的个性化力量。
## Hacker News 讨论：构建并日常使用自定义文本编辑器
一个 Hacker News 帖子讨论了构建自己文本编辑器的吸引力，起因于一篇关于开发者个人项目（[https://jsbarretto.com/writing-my-own-text-editor/](https://jsbarretto.com/writing-my-own-text-editor/)）的文章。 许多评论者分享了使用自制编辑器多年的经验，认为这提高了生产力，并从完全符合自己需求的工具中获得了乐趣。
讨论强调了理解软件底层机制的价值，即使这意味着最初需要牺牲 VS Code 等大型成熟编辑器中的功能。 作者和评论者的主要收获包括优先考虑简单性而非模块化，积极删除不必要代码，以及保持对代码库清晰的心理模型。
许多人同意，虽然复杂的功能唾手可得，但一个专注的自定义解决方案通常可以胜过臃肿的替代方案。 该帖子还涉及光标操作的挑战、现代终端模拟器的惊人功能以及 Scintilla 等用于 GUI 集成的可用库。 最终，大家的观点倾向于为自己量身定制工具的回报，即使它看起来“简单”。
这个故事源于1994年的一封邮件，讲述了加利福尼亚州帕洛阿尔托市发生的一起怪异事件。一个城市变压器室，容纳着为市中心办公楼供电的一百万瓦设备，被发现装满了大约2000加仑的废弃食用油。
多年来，附近一家餐厅一直在非法将炸油倾倒进变压器室，错误地认为它通往雨水下水道。变压器的热量使油脂保持熔化状态，造成了严重的火灾隐患。如果变压器过热，可能会点燃油脂，导致一场巨大的“超级油火”。
问题浮出水面是因为餐厅顾客抱怨有腐臭味。城市公用事业部门最终发现了问题，切断了电源，移除了油脂，并更换了变压器。幸运的是，没有人受伤，一家餐厅暂时无法提供油炸食品。
## Zig 开发更新 - 2026 (截至 3 月 10 日) 最近的 Zig 开发主要集中在重要的内部改进和扩展功能上。一个包含 30,000 行代码的 PR 彻底修改了编译器的类型解析逻辑，从而实现了更快的增量编译（修复了过度分析问题），并允许编译器在分析未使用的类型字段时“更懒”——这对于用作命名空间的类型是有益的。依赖循环错误信息也得到了显著改进，提供了清晰的解决指导。 在标准库方面，`std.Io.Evented` 接近完成，为 I/O 操作提供用户空间堆栈切换（纤程/协程），但仍被认为是实验性的。努力仍在优先使用原生 Windows API 而不是 Win32 包装器，以提高性能和可靠性，避免不必要的分配和故障。 `zig libc` 子项目正在取得进展，用 Zig 包装器替换了 vendored C 代码，用于 libc 函数，从而减少了代码重复并提高了编译速度。这也为未来与 Zig 功能（如 io_uring 和资源泄漏检测）集成打开了可能性。已经删除了超过 250 个 C 文件。 最后，团队承认并表示与在城市中面临问题的抗议者站在一起。
请启用 JavaScript 并禁用任何广告拦截器。
## SUSE潜在出售 - 黑客新闻总结
据悉，EQT 正在考虑以约 60 亿美元的价格出售 Linux 先驱 SUSE。黑客新闻上的讨论显示出各种不同的观点，主要集中在私募股权的影响以及 SUSE 实际的市场地位。
一些评论员最初认为 SUSE 已经过时，但许多其他人则为其在企业中的广泛使用辩护，尤其是在《财富》500 强企业中（据报道，超过 60% 的企业在其某些工作负载中使用 SUSE）以及在 HPC 和 SAP 基础设施等特定领域，尤其是在欧洲。SUSE 拥有 Rancher 和 Harvester 也被强调为一项有价值的资产。
对话涉及了对私募股权对科技公司影响的更广泛担忧，以及出售最终是会使 SUSE 受益还是受损。如果非欧洲实体收购该公司，人们担心可能会失去欧盟的软件自主权。2022 年的收入报告为 8 亿美元，表明 SUSE 是一家重要的企业，尽管人们的看法并非如此。
最终，该帖子突出了公众认知与 SUSE 在企业 Linux 领域中的实际作用之间的脱节。
## 从递归到迭代：用栈安全换取清晰度
本文探讨了一种将优雅的递归代码转换为迭代形式的技术，用于像JavaScript/TypeScript这样的语言，以避免堆栈溢出错误。虽然递归通常是固有递归问题的最易维护的解决方案，但对于深度嵌套的数据结构来说，它可能会有问题。
核心思想是使用可变数据结构手动模拟调用堆栈——本质上将每个堆栈帧表示为一等值。这允许迭代执行，而无需依赖语言的调用堆栈。这个过程并非完全可自动化，但很大程度上是机械化的，产生可理解的（但不太清晰的）代码。
作者通过链表、二叉树，最后是互递归树和森林来演示这一点。复杂性随着分支数据结构的增加而增加，需要类似堆栈的结构来管理延迟计算。
鉴于复杂性增加，使用基于属性的测试（使用`fast-check`）进行严格测试至关重要，以确保正确性。基准测试显示，与递归版本相比，性能下降了大约2.2倍，对于某些场景来说，这是一个合理的权衡，以换取堆栈安全。该技术存在局限性，尤其是在多态递归函数方面。作者寻求进一步的探索和相关的参考文献。
这个Hacker News讨论的核心是**通过手动模拟调用栈来移除代码中的递归**。原始帖子链接到一篇详细介绍这种技术的文章 (jnkr.tech)。
用户指出这并非一个新想法——**编译器在优化时本质上就是这么做的**。这对于**尾递归**尤其有效，在这种情况下，模拟的栈可以用一个简单的循环来代替，从而提高性能。
虽然像Python这样的语言要求开发者手动实现这一点，但像C++和Rust这样的语言则会因为递归调用而产生开销，而编译器往往*无法*自动优化。用户表达了对主流C++编译器不能自动将递归转换为具有管理栈的迭代解决方案以提高性能的沮丧。
本质上，这次讨论强调了代码可读性（递归）和性能（具有显式栈管理的迭代解决方案）之间的权衡。
## Bippy：React 内部机制探索 Bippy 是一套工具，用于访问 React 的内部“fiber”——代表组件和 DOM 元素的执行核心单元——而无需修改 React 代码本身。通常，这些内部机制是无法访问的，但 Bippy 通过伪装成 React Devtools 来绕过这一限制，从而访问 fiber 树和相关数据。它支持 React 17-19 版本，并且不需要事先了解 React 的源代码。 主要功能包括遍历 fiber 树（`traverseFiber`）、识别渲染的组件（`traverseRenderedFibers`）以及检查 props、state 和 context。Bippy 通过拦截 React 与 `window.__REACT_DEVTOOLS_GLOBAL_HOOK__` 对象的通信来实现这一点，该对象传统上由 React Devtools 使用。 **使用方法：** 在 React 之前导入 Bippy，以接入其内部机制。像 `instrument` 这样的函数可以安全地修补全局 hook，而 `secure` 则添加了错误处理。像 `getFiberFromHostInstance` 这样的工具可以将 DOM 元素链接到其对应的 fiber。 **重要提示：** Bippy 主要是一个开发工具。虽然提供了安全保障，但在生产环境中使用时应谨慎考虑，并参考 React-Scan 等项目以实现更强大的功能。它是一个强大的工具，用于理解 React 的内部运作和调试复杂应用程序。
## Bippy：一个 React 内部机制工具包
一个名为 Bippy (bippy.dev) 的新项目最近在 Hacker News 上分享。它是一个用于与 React 应用程序内部机制交互的工具包。
讨论很快转向了项目名称，提及电影《House 2》中的毛毛虫宠物“Bippy”。用户们正在探索超越典型开发者工具的潜在用途，建议将其应用于浏览器扩展程序，以及作为 devtools 功能的“挖掘者”——特别是对于用户脚本开发而言。
该项目似乎至少从 2023 年就开始开发，并且最近有一个存档快照可用。总体情绪是积极的，评论者们表达了对一个填补了先前未被满足的需求的工具的兴奋之情。