下面是我之前翻译的Chez Scheme 的Debug文档

第三章 调试

Chez Scheme 有几个用于调试的功能。除了对经过完全类型检查过的运行中的代码提供错误信息之外，Chez Scheme 也支持对过程调用进行跟踪，中断任意计算，重定义异常和中断处理器，检查任意对象，包括异常的continuation 和中断。

Scheme 或 Chez Scheme 的新手程序员，甚至是有经验的 Scheme 程序员都可以参考“How to Debug Chez Scheme Programs” 这个教程。在 http://www.cs.indiana.edu/chezscheme/debug/ 可以找到 HTML 和 PDF 版本的教程。(译者注：此链接在翻译时无法打开 2019/2/1)

3.1 跟踪

跟踪是调试 Scheme 程序最有用的手段之一。 Chez Scheme 可以跟踪任何内建和用户定义的过程。跟踪库会将每一个调用过程的参数和返回值打印出来，通过紧凑的缩进机制来显示嵌套调用的深度。打印非尾递归调用的时候会增加缩进而尾递归调用不会，可以以此区分是尾递归调用还是非尾递归调用。对于嵌套大于等于 10 的调用，会在缩进处有一个括号，其中包括一个数字用于说明嵌套的深度。

这一节会涵盖跟踪过程和控制跟踪输出的机制。

• 语法: (trace-lambda name formals body1 body2 …)
• 返回: 一个被跟踪的过程
• 所属库: (chezscheme)

一个 trace-lambda 表达式等价于一个 lambda 表达式加上一样的语法形式以及程序体，除了无论何时该过程被调用的时候都会向跟踪端口输出跟踪信息。这里使用 name 来命名该过程。跟踪信息会显示过程的参数以及过程的返回值，嵌套的调用会以缩进显示。

下面被跟踪的过程 half 返回整型参数除以 2 的商。

对于 (half 5) 这个返回值是 2 的调用跟踪如下

Go语言的trace包是一个用于追踪程序运行时信息的工具，它可以帮助开发者理解程序的运行时行为，诊断性能问题。trace包主要是通过分析程序生成的追踪文件来工作的。

runtime/trace 包含了一个强大的工具，用于理解和排查 Go 程序。它的功能允许我们生成一个时间段内每个 goroutine 的执行轨迹。通过使用 go tool trace 命令（或者优秀的开源工具 gotraceui），我们可以可视化并探索这些轨迹数据。

trace的魔力在于它能轻易揭示程序中那些以其他方式难以发现的事情。例如，一个并发瓶颈，许多 goroutine 在同一个 channel 上阻塞可能在 CPU 分析中很难看出，因为没有执行样本。但在执行trace中，执行链路的缺失将以惊人的清晰度显示出来，被阻塞的 goroutine 的堆栈追踪将迅速指向问题所在。

Go 开发者甚至可以使用任务、区域和日志来为他们的程序添加插桩，这样他们就能将自己的高层次关注点与底层执行细节相关联。

问题

不幸的是，执行trace中的丰富信息往往难以触及。历史上，与trace相关的四个大问题经常成为障碍：

1. trace的开销很大。
2. trace的扩展性不好，可能变得过于庞大而难以分析。
3. 往往不清楚何时开始trace记录以捕获特定的错误行为。
4. 鉴于缺乏用于解析和解释执行trace的公开包，只有最具冒险精神的 gophers 能够以编程方式分析trace。

如果你在过去几年中使用过trace，你可能因为这些问题中的一个或多个而感到沮丧。但在过去的两个 Go 版本中，Golang团队在这四个领域都取得了重大进展。

降低trace成本

在 Go 1.21 之前，许多应用程序的 trace 运行时开销大约在 10–20% CPU 之间，这限制了 trace 的使用场景，不能像 CPU profiling 那样持续使用。事实证明，trace 的大部分成本都归结于 traceback。由运行时产生的许多事件都附带了堆栈追踪，这对于实际识别 goroutine 在执行关键时刻的行为是无价的。

感谢 Felix Geisendörfer 和 Nick Ripley 在优化 traceback 效率方面的工作，执行 trace 的运行时 CPU 开销已经大幅度降低，对于许多应用程序而言，现在只有 1–2%。

“立志用功，如种树然。方其根芽，犹未有干，及其有干，尚未有枝，枝而后叶，叶而后花、实。初种根时，只管栽培灌溉，勿作枝想，勿作叶想，勿作花想，勿作实想。悬想何益？但不忘栽培之功，怕没有枝叶花实？”

从 jeff dean的演讲中记录的.

https://www.youtube.com/watch?v=oSCRZkSQ1CE

一些观察

• 机器学习让计算机不断打破我们对于计算机能做什么的期待
• 不断变大的计算、数据、模型规模带来了更好的结果
• 我们需要硬件执行的计算类型快速地改变了

计算机能做什么

• 图像分类
• 语音识别
• 翻译
• 图像识别和描述

反过来也行

• 从描述生成图像
• 语音合成

ImageNet 的图像分类准确度从2011年的50.9% 到2021年的90.88% 语音识别的错误率从13.25%下降到2.5%

趋势

大算力可以极大地改进模型，深度学习改变了我们设计计算机的方式： 针对机器学习优化的硬件越来越高效。

机器学习计算特征

• 不需要非常高的精度 –降低精度可以提高运算速度，但是不怎么影响效果
• 特异化的操作—主要是矩阵计算

语言模型的15年历史

2007年， 大规模的N-gram模型，用在翻译算法中。

2013年，词向量技术

2014年，Sequence to Sequence 翻译

2015年， 多回合的神经对话模型

2017年， Attention Is All You Need ,是对15年的工作的并行化优化迭代

2020年，Meena Transformer 架构的对话模型

2022 年，chatGPT

2023 年，Bard Gemini 多态模型

大模型的训练

• 基础架构 映射物理计算设备 资源的热加载和移除 数据自动路由 高度可扩展性
• 大规模训练 最小化失败的可能性 最快的恢复时间
• 训练数据 高质量的数据对于模型训练非常重要

怎么更好地问模型问题

让模型一步一步展示思考过程很有用，思维链模式

模型评估

评估模型的优势和弱势

社区的发展和运营经常会面临的问题是： 随着社区发展，社区的质量越来越差，导致高质量的用户渐渐流失。

为了建设一个小而美，持久的社区，需要为加入社区的用户设置一个门槛：

• 可以是付费加入。
• 可以是通过域名验证加入，类似Google console 会交验用户的域名所有权一样。

付费加入可以为社区提供基础的运营经费。

域名验证可以提高用户的准入门槛，可以为高质量用户自身的网站引流。

社区可以获得用户高质量的博文，解决流量从哪里来的w

Chrome是我工作中最常用的浏览器，但是它的Tab管理确实是一团糟。经常会遇到工作一天之后，CHrome的浏览器Tab开了一堆，要找到之前的Tab简直比登天还难。

浏览器的窗口管理

在chrome大行其道之前，IE是流行的浏览器之一，IE在新建窗口的时候就真的是在你的桌面上新建一个窗口，也许当时的用户工作一天之后桌面上会是一堆的窗口？当时的网页功能肯定没有现在这么强大，不是所有的应用都是运行在网页上的。

chrome已经在IE的基础上进行了改进，通过Tab来管理新建的窗口，至少我们不用看到桌面上的一堆浏览器窗口。Chrome的界面UI设计在刚问世的时候也是以其简洁、快速著称的，它也因此赢得了市场。

问题从桌面上的一堆窗口变成了一条Tab栏上的一个个Tab。这条Tab栏是有上限的，一般来说在10个tab左右就已经填满了整条Tab栏。按照我自己的习惯同时开启的Tab远在这个数字之上，Chrome的Tab页面至少在40个以上，而且习惯开启新的Tab但是不习惯关闭Tab。当我们的Tab栏都看不清标题分不清哪个Tab是你要切换寻找的，这时候我还倾向于新建一个Tab，而不是在一大堆Tab中寻找之前的Tab（除非这上面有我依赖的数据，新建一个需要重新操作一遍）。一天的工作结束之后会发现这些窗口中很大一部分都是一次性的，没有意义的中间窗口，例如导航类型的页面，搜索中间页面等等。

Chrome也在改进Tab页面的设计 引入了Tab分组，支持在已经开启的Tab页面中搜索，但是实际使用中并没有多大程度地解决问题。

Edge、Arc等浏览器开始抛弃最原始的Tab栏的桎梏，开始尝试竖排的Tab页面管理。

为什么？

为什么我们的浏览器页面会变得如此拥挤？ 拆解和分析一下这个问题，会发现我们的问题变成了，为什么我们要新建一个浏览器Tab？这个问题很简单：

• 用户主动通过url打开Tab 比如我想要搜索一个主题，我会打开google进行搜索，或者直接在Tab栏搜索，这都会新建一个Tab
• 网站的新建 这不是用户的行为，更多的是网页的设计，例如Google搜索完成之后会有google 的搜索结果页面，当我点击其中一个搜索结果的时候Google可以选择在新的Tab页面中打开搜索结果网页，也可以选择forward，覆盖现有的搜索结果。(现在baidu的默认是新建Tab，Google采用的是forward的方案)

竖排标签管理

现代用户的屏幕大多是16:9甚至更加宽的比例，在空间上宽会比高更加富裕。竖排的标签不会因为标签过多导致标签名称被挤占,因为竖排之后标签管理的宽度是可调整的，新的tab排列是竖向的，标签名称是横向的，不在一个方向上。

树状标签管理

用户的标签是否可以组织成一颗二叉树一样的形式。

https://chromewebstore.google.com/detail/tree-style-tab/oicakdoenlelpjnkoljnaakdofplkgnd 看上去已经有人在做类似的尝试，先试用一下看。

目前在使用的是

https://chrome.google.com/webstore/detail/nelmjkbalflkmcnnnhjgiodpndcebfgo

插件基本实现了树状Tab管理的基础功能，由于是插件的原因，功能打磨上没有arc做得那么好，也占用了挺多屏幕空间

新建Tab

tree tab可以让tab页面之间的生成逻辑更加清晰，不知道有没有插件可以减少新Tab页面的创建。会不会改造的最后就是zuo c