sbcl - 云端在线

程序：

您的姓名

SBCL -- 钢铁银行Common Lisp

商品描述

SBCL 是 ANSI Common Lisp 的实现，具有高性能的原生
编译器、多个平台上的本机线程、套接字接口、源代码级
调试器、统计分析器等等。

它是免费软件，主要在公共领域，但在 BSD 风格下有一些子系统
只要给予信用，就允许修改和重用的许可证。 它提供“作为
是”，不提供任何形式的保证。

有关许可证问题的更多信息，请参阅分发中的 COPYING 文件。 为了
有关历史的更多信息，请参阅发行版中的 CREDITS 文件。

跑步 SBCL

要运行 SBCL，请键入“sbcl”。 启动消息后会出现提示（“*”）。 输入一个 Lisp
表达式，SBCL 将读取并执行它，打印任何返回的值，给你另一个
提示，然后等待您的下一个输入。

$ sbcl
...[启动消息被忽略]...
* (+ 1 2 3)

6
* （出口）

大多数人喜欢在 Emacs 下将 SBCL 作为子进程运行。 Emacs“史莱姆”模式提供
许多方便的功能，如命令行编辑、选项卡完成和各种
Common Lisp 源文件和交互式 SBCL 子进程之间的耦合。

有关使用 SBCL 创建“独立可执行文件”的信息，请参阅
SB-EXT:SAVE-LISP-AND-DIE 在用户手册中。

指挥 LINE 句法

对于普通的交互式使用，不需要命令行参数。

为了理解 SBCL 命令行语法，了解
系统由两部分组成：运行时环境和Common Lisp系统
支持。 一些命令行参数在初始化过程中被处理
运行时，以及一些在 Lisp 系统初始化期间 - 任何剩余的命令
行参数传递给用户代码。

整体命令行语法是：

SBCL [运行 选项] --end-runtime-选项 [顶层 选项] --end-toplevel-选项
[用户 选项]

--end-runtime-options 和 --end-toplevel-options 都是可选的，可以省略。
它们旨在用于任何命令行选项都在用户之下的情况
控制（例如在批处理文件中）：通过使用它们，您可以阻止用于您的选项的选项
程序被 SBCL 意外处理。

支持的运行时选项是

- 核
使用指定的 Lisp 核心文件而不是默认文件。 （有关文件，请参阅文件部分
标准内核，或 SB-EXT:SAVE-LISP-AND-DIE 的系统文档以获取信息
关于如何创建自定义核心。）请注意，如果 Lisp 核心文件是用户创建的
核心文件，它可能会运行一个不识别标准的非标准顶层
顶级选项。

--动态空间大小
启动时保留的动态空间大小（以 MB 为单位）。 默认值为平台
依赖。

--控制堆栈大小
为每个线程保留的控制堆栈大小（以 MB 为单位）。 默认值为 2。

--noinform
禁止在启动时打印任何横幅或其他信息性消息。 （这个
使编写在 Unix 管道中干净地工作的 Lisp 程序变得更容易。 也可以看看
“--noprint”和“--disable-debugger”选项。）

--禁用-ldb
禁用低级调试器。 仅当 SBCL 与 LDB 一起编译时才有效。

--败于腐败
有一些危险的低级错误（例如，控制堆栈耗尽，
内存故障）（或其处理程序）可能损坏图像。 默认情况下，SBCL 打印一个
警告，然后尝试继续并处理 Lisp 中的错误，但这并不总是
SBCL 可能会出现故障甚至挂起。 有了这个选项，遇到这样的
错误 SBCL 将调用 ldb（如果存在并启用）或退出。

- 脚本
作为等效于 --noinform --disable-ldb --lose-on-corruption 的运行时选项
--end-runtime-options --script . 将 --script 的描述视为
下面的顶级选项。

--merge-核心页面
当存在平台支持时，向操作系统提供相同的提示
页可以在进程之间共享，直到它们被写入。 这对
减少从类似的多个 SBCL 进程启动的系统上的内存使用
但名称不同的核心文件，或来自压缩的核心。 没有平台支持，
没做什么。

--无合并核心页面
确保不向操作系统提供共享提示。

--默认合并核心页面
将共享提示策略恢复为默认值：仅压缩内核触发提示。
未压缩的核心直接从核心文件映射，这通常足以
确保共享。

- 帮帮我
打印一些关于SBCL的基本信息，然后退出。

- 版
打印SBCL的版本信息，然后退出。

将来，可能会添加运行时选项来控制行为，例如延迟分配
记忆。

运行时选项，包括任何 --end-runtime-options 选项，都从
在 Lisp 顶层逻辑有机会看到它之前的命令行。

标准 SBCL 内核支持的顶级选项是

--系统初始化
加载文件名而不是默认的系统范围的初始化文件。 （见文件
部分。）

--无系统初始化
不要加载系统范围的初始化文件。 如果给出此选项，则 --sysinit
选项被忽略。

--用户初始化
加载文件名而不是默认的用户初始化文件。 （请参阅文件部分。）

--无用户初始化
不要加载用户初始化文件。 如果给出此选项，则 --userinit 选项
被忽略。

--评估
在执行任何初始化文件之后，但在开始 read-eval-print 循环之前
在标准输入上，读取并评估给定的命令。 不止一个 --eval 选项可以
被使用，所有的都将被读取和执行，按照它们在命令中出现的顺序
线。

- 加载
这相当于 --eval '(load " ")'。特殊语法旨在
减少从 shell 脚本调用 SBCL 时的引用问题。

--无打印
当通常执行顶层“读取-评估-打印循环”时，执行“读取-
eval 循环”代替， 如 不要打印提示，也不要回显结果。 结合了
--noinform 运行时选项，这使得编写工作的 Lisp“脚本”变得更容易
在 Unix 管道中干净利落。

--禁用调试器
默认情况下，当 SBCL 遇到错误时，它会进入内置调试器，允许
交互式诊断和可能的调解。 此选项禁用调试器，
导致错误打印回溯并以状态 1 退出 - 这是一种模式
操作更适合批处理。 参见用户手册
SB-EXT:DISABLE-DEBUGGER 了解详情。

- 退出
在顶级选项处理结束时，退出 SBCL，成功代码为零。
请注意，此选项的效果会延迟到顶级选项之后
这个。

--非交互式
此选项禁用异常和非异常的 read-eval-print 循环
原因。 它是 --disable-debugger 和 --quit 组合的缩写，很有用
对于不需要 --script 隐含的特殊选项处理的批处理使用。

- 脚本
暗示 --no-sysinit --no-userinit --disable-debugger --end-toplevel-options。

使系统加载指定的文件并在之后立即退出，而不是
进入读取-评估-打印循环。 如果文件以shebang行开头，则为
忽略了。

无论顶级选项出现在命令行中的顺序如何，
行动是：

1. 如果需要，调试器被禁用。

2. 加载任何系统初始化文件，除非被禁止。

3. 加载任何用户初始化文件，除非被禁止。

4. --eval 和 --load 选项按照给定的顺序进行处理。

最后，要么进入 read-eval-print 循环，要么进入 --script 指定的文件
选项已加载。

在 read-eval-print 循环中运行时，系统在文件末尾退出。 同样，
系统在处理用--script 指定的文件后立即退出。

请注意，使用 --core 选项运行 SBCL 时，使用用户创建的核心文件
调用 SB-EXT:SAVE-LISP-AND-DIE，顶层选项可能在控制之下
用户代码作为参数传递给 SB-EXT:SAVE-LISP-AND-DIE。 为此，该
--end-toplevel-options 选项本身可以被认为是一个顶级选项， 如 用户
核心，根据其选择，可能不支持它。

在标准的 SBCL 启动序列中 (如 不涉及用户核心）顶级选项
并且任何 --end-toplevel-options 选项都从命令行参数列表中删除
在用户代码有机会看到它之前。

产品详情

SBCL 源自 CMU CL。 （该名称旨在确认连接：
钢铁和银行业是卡内基和梅隆大学赚大钱的行业。）

SBCL 默认编译：即使是在 read-eval-print 循环中输入的函数也会被编译
到本机代码，除非已明确打开评估器。 （即使在今天，仍有大约 30
在 MacLisp 编译器出现多年后，人们会告诉你 Lisp 是一个解释型的
语。 别理他们。）

SBCL 旨在但尚未完全符合 ANSI 标准的通用
口齿不清。 有关这方面的更多信息，请参阅下面的 BUGS 部分。

SBCL 还包括各种非 ANSI 扩展，在用户手册中有更详细的描述。
其中一些在基本系统中，而另一些是根据请求加载的“contrib”模块
使用要求。 例如加载提供 TCP/IP 的 SB-BSD-SOCKETS 模块
连接性
*（需要'asdf）
* (需要 'sb-bsd-sockets)

有关更多信息，请参阅用户手册。

“ 编译器

SBCL 从 CMU CL 继承了“Python”本机代码编译器。 （虽然我们经常避免
名称以避免与脚本语言（也称为 Python）混淆。）这
编译器非常聪明地理解了 Common Lisp 的类型系统并将其用于
优化代码，以及生成注释让用户知道编译器何时不
有足够的类型信息来生成高效的代码。 它也尝试（几乎总是
成功地）遵循不寻常但非常有用的原则，即“声明是
断言", 如 应该在运行时检查类型声明，除非用户
明确告诉系统速度比安全更重要。

编译后的代码使用垃圾回收来自动管理内存。 垃圾
收集器的实现因 CPU 的不同而有很大差异。 特别是在某些 CPU 上
GC 几乎是精确的，而在其他方面则更为保守，而在某些 CPU 上，GC 是
分代，而在其他情况下使用更简单的停止和复制策略。

有关编译器的更多信息，请参阅用户手册。

系统 参赛要件

SBCL 目前在 X86（Linux、FreeBSD、OpenBSD 和 NetBSD）、X86-64 (Linux)、Alpha 上运行
（Linux、Tru64）、PPC（Linux、Darwin/MacOS X）、SPARC（Linux 和 Solaris 2.x）和 MIPS
(Linux)。 有关其他正在进行和可能的端口的信息，请参阅 sbcl-devel 邮件
列表和/或网站。

SBCL 需要 16Mb RAM 才能在 X86 系统上运行
32Mb 或更多的程序会更快乐。

知 BUGS

本节试图列出最严重和长期存在的错误。 欲知详情
有关错误的最新信息，请参阅发行版中的 BUGS 文件。

耗尽堆内存可能会陷入严重的麻烦。 SBCL系统
在启动时过度使用内存，因此，在典型的类 Unix 系统如 Linux 和 FreeBSD 上，这
意味着如果 SBCL 系统使用的虚拟内存多于系统使用的虚拟内存
可用它，其他进程往往会被随机杀死（！）。

编译器对函数返回值的处理不必要地违反了“声明
是断言”原则，否则它坚持。使用 PROCLAIM 或 DECLAIM 来
指定函数的返回类型会导致编译器不检查就相信你。
因此编译一个包含
（声明（FTYPE（FUNCTION（T）NULL）有时））
(DEFUN 有时 (X) (ODDP X))
(DEFUN FOO (X) (IF (SOMETIMES X) 'THIS-TIME 'NOT-THIS-TIME))
然后运行 ​​(FOO 1) 给出 NOT-THIS-TIME，因为编译器依赖于
不检查就拒绝。

有些事情的执行效率非常低。

-- 多维数组效率低下，尤其是浮动的多维数组
点数。

-- SBCL，像大多数（也许是全部？）Common Lisp 在库存硬件上的实现一样，具有
麻烦有效地传递浮点数，因为浮点数
数字加上一些额外的位来标识其类型，大于机器字。
（因此，它们在堆分配的存储中被“装箱”，导致 GC 开销。）
单个编译单元，或在执行 SQRT 和 AREF 等内置操作时，或某些
特殊操作，如结构槽访问，这是可以避免的：参见用户手册
一些效率提示。 但是对于跨越边界的一般函数调用
编译单元，将浮点计算的结果作为函数传递
参数（或将浮点结果作为函数值返回）从根本上是一个
运行缓慢。

REPORTING BUGS

要报告错误，请将邮件发送到邮件列表 sbcl-help 或 sbcl-devel。 你可以
在网页上找到完整的邮件列表地址：
<http://sbcl.sourceforge.net/>; 请注意，作为减少垃圾邮件的措施，您必须订阅
在您可以发布之前添加到列表中。 （您可能还会发现精美的 SourceForge 错误跟踪
那里有机械，但不要被愚弄。 无论如何，截至 2002-07-25，我们不会主动监控
那个机器，它存在只是因为我们无法弄清楚如何转动
它关了。）

与任何软件错误报告一样，如果您能提供足够的信息，那将是最有帮助的
可靠地重现症状，并且如果您清楚地说明症状是什么。 为了
例如，“非常小的否定论点的 TAN 似乎有问题。
当我在 Linux 上的 sbcl-1.2.3 上以交互方式执行 (TAN LEAST-NEGATIVE-SINGLE-FLOAT) 时
4.5 X86 盒子，我收到一个未绑定变量错误。”

差异性 从 CMU CL

SBCL 可以使用普通的 ANSI Common Lisp 系统和 C 语言从头开始构建
编译器，并且它的所有属性都由源代码的版本指定
它是从. 这种干净的引导性是分叉的直接动机
脱离 CMU CL 开发树。 各种实现差异的动机
通过这个设计目标。

由于前叉与 SBCL 的维护工作有所不同，因此 SBCL 的维护工作
CMU CL。 两者之间共享了许多但不是所有的错误修复和改进
项目，有时这两个项目在改进方面存在分歧。

CMU CL 支持的大多数扩展已经从 SBCL 中分离出来，包括 Motif
支持、Hemlock 编辑器、搜索路径、WIRE 协议、各种用户级宏
和功能（例如 LETF、ITERATE、MEMQ、REQUIRED-ARGUMENT）等等。

（为什么 SBCL 本身不支持更多扩展？为什么要放弃所有这些不错的扩展？
当代码已经存在时，来自 CMU CL？ 这是一个经常被问到的问题
邮件列表。 有两个主要原因。 首先，这是一个设计哲学问题：
可以说 SBCL 通过提供稳定的 FFI 完成了它的工作，正确的设计决策是
将由此衍生的功能（如套接字支持）移动到单独的库中。
其中一些与 SBCL 作为“contrib”模块一起分发，其他的作为
由不同的维护者提供不同的软件包。 其次，这是一个实际的决定——
我们希望，专注于较少的事情会让我们做得更好。）

客户服务

有关 SBCL 的各种信息可在http://www.sbcl.org/>. 邮寄名单
有推荐的地方可以寻求支持。

作者

数十人为 SBCL 及其子系统做出了重大贡献，并为
多年来，它所基于的 CMU CL 系统。 查看 CREDITS 文件
分发以获取更多信息。

环境

SBCL_主页 此变量控制诸如“sbclrc”、“sbcl.core”和附加组件之类的文件的位置
搜索“contrib”系统。 如果未设置，则 sbcl 从
编译时默认位置通常是 /usr/local/lib/sbcl/ 但可能有
被改变 例如 由第三方包装商提供。

使用 onworks.net 服务在线使用 sbcl