lysee 官方网站开张营业

为保障 Lysee 的健康发展，我于近期创建了 Lysee 的官方网站 http://www.lysee.net，从此 Lysee 算是有个正正经经的家了，欢迎感兴趣的朋友们访问。

引用

Lysee 是一种小巧、快速、可靠、跨平台的脚本编程语言。它既可以直接嵌入到 Pascal 和 C/C++ 程序中为宿主程序提供强大的脚本处理能力，也可以通过键盘和显示器与程序员进行互动，或者批量执行为其指定的任何 Lysee 程序文件。Lysee 同样适用于网站开发，其代码可以直接嵌入到 HTML 页面中，就象 ASP 和 PHP 所做的那样。如果您是刚刚接触到 Lysee 并想了解它是怎样工作的，请阅读本站为您准备的在线文档、示例代码以及本站提供的其它资源。

理论上 Lysee 可以在数十种操作系统和 CPU 架构中编译运行，而目前我需要大量不同 CPU 架构、不同操作系统类型的编译主机进行验证，希望有条件的朋友能为 Lysee 提供编译主机和帐户，本人绝对保证不侵犯您的任何权益和隐私，谢谢！

评论

20 楼 libudi 2008-05-25  

RednaxelaFX  2008-05-20

引用

啊，来迟了。刚刚有空在JavaEye逛的时候才发觉Lysee有新进展了，加油！

谢谢老兄的鼓励，Lysee 很快要做一次升级，准备发布 64 位 Linux 版本，事儿真不少。

=================================================================================

很快还要发布一套用 Lysee 开发的论坛系统（跨平台，基于PQ，开放源代码），所以有必要为 Lysee 寻找一个跨平台、简单配置、无须安装的HTTP服务器，并把它打包到 Lysee 安装包中，看了几个，都不太满意。几年前我曾经用IDHTTP开发过一个，代码一直没有维护，再拾起来恐要非不少时间，如果有现成的就不操这个心了，看谁能给推荐一个。

19 楼 RednaxelaFX 2008-05-20  

啊，来迟了。刚刚有空在JavaEye逛的时候才发觉Lysee有新进展了，加油！

梁利锋 写道

（即使一种编译语言都不应该了，C++0x都加入垃圾回收了）

C++0x不是已经否决了在语言中加入GC的提案了么，解决方案是用TR1里就包含了的shared_ptr<T>。

18 楼 梁利锋 2008-05-09  

我认为，托管资源目前来说，主要是内存。不是handle。所谓托管资源，也就是由gc分配的内存；所谓非托管资源，也就是其他语言的代码分配的内存或handle。

记得看过一篇文章，说过，即使非托管资源，其实gc也是可以回收的，之所以选择不回收，是为了让非托管代码（比如c++）自己来回收，这样比较符合“谁分配，谁回收”的原则，可以最大限度的保证和非托管代码的兼容性。

17 楼 libudi 2008-05-08  

猜的不错的话 GC 回收的托管资源，比如，链表、字典、内存流之类的，通常都是非托管资源中对应对象的存根或代理，也就是托管代码与非托管对象之间的连接，主要是堆和操作系统分配的handle。有 GC 的语言在这方面应该是一样的，区别只是策略和编码，殊途但同归。对 GC 的改进主要是提升回收效率而不是内容。

16 楼 梁利锋 2008-05-07  

google 了一下 Notification 和 FreeNotification，觉得和我说的 dispose 方式是类似的，都是为了尽量简单的处理大量资源。

不过，对于c#来说，只有非托管资源才需要这样做。对于托管资源，比如，链表、字典、内存流之类的，都是由gc自动回收的。这也是我觉得脚本语言应该做的。

15 楼 梁利锋 2008-05-07  

虽然写过几个小的delphi程序，不过没什么研究，也不清楚 Notification 和 FreeNotification 机制。

如果使用c来编写解释器，则能提供最大的跨平台性。比如iphone sdk只支持c/c++，如果lysee是pure c编写的，那么就可以很容易的提供iphone版。

14 楼 libudi 2008-05-07  

Anders 开发 C# 前在 Borland 开发 Delphi 并部分参与 JBuilder，跳槽到 M$ 时我本人有些失落感，可惜 Borland 无心为 Anders 提供更多自主发挥的资源，M$ 确实狠，在 Anders 之前已经从 Borland 挖走了一批水平相当的高手（网上可以查到）做铺垫。

C# 带有 Borland  的编程风格，无论怎么看都像 Java 与 Delphi 的混合体（可能是我的偏见），Delphi VCL（Visual Component Library） 为对象协作提供了 Notification 和  FreeNotification 机制（对象释放通知），理论上使 Delphi 程序可以做到所有从 TComponent 类继承的对象只需创建而无须释放（自动释放），Free Pascal 社区用 FCL 实现了 VCL。我对 C# 并不熟悉，特别是没有读过 C# 的类库，不知道 C# 是否有类似的机制，比如 winform 部分？

用 Pascal 开发 Lysee 除了我熟悉 Pascal 语言外，另一个原因是用 C 开发的已经太多了，而 Pascal 社区还没有水平相当的作品，我想做一个试试，希望能得到朋友们的支持，特别是国内的。

13 楼 梁利锋 2008-05-07  

要是用js写个汇编编译器，还不算麻烦，如果用来写高级语言的编译器，不是不能，而是没必要。 不过，记得以前见过一个用js实现的ruby的解释器，用来在web客户端用ruby编程的，忘了叫什么了。

我个人认为像lua那样使用pure c来写，能提供更好的跨平台性，不过也许比pascal烦一点儿吧。

我做js开发不多，所以不太能解释你提的js的托管非托管的问题，我用c#来解释，理论上来说，应该是一样的。

使用其他语言的模块这一点，确实可能是问题。c#解决这个问题的方式是对于unmanaged code，要求程序员显式释放，而且有一个专用接口 IDisposable。很多人认为只要实现了这个接口，系统就会自动调用它，其实不是的，这个接口必须被代码明确调用，一般使用 try-finally来确保，因为这种情况很多，所以c#提供了一个语法糖using:

using(File f = new File("1.txt")
{
    f.ReadToEnd();
}

另外，对于winform来说，所有的控件其实都要调用win32 api，这个也是非托管资源，所以也要明确调用Dispose，不过，主窗体的Dispose被主线程自动调用，而窗体以及窗体内的容器，在被Dispose时，也会调用它的所有子控件的Dispose函数，所以整个窗体的所有非托管资源就得以在程序员未明确参与的情况下被完全Dispose掉。

我觉得这个做法很酷，值得模仿。

12 楼 libudi 2008-05-06  

不好意思，JavaEye 邀请朋友的功能关闭了。

顺便讨论一下托管的问题。换个思路，说说 JavaScript，顺便提些问题：

1、是否可以认为 JavaScript 代码就是托管代码，而为 JavaScript 提供具体服务的对象（比如浏览器中的Document、Window和External）就是非托管代码，如果是，是否可以确认托管代码与非托管代码是绑定运行的，而垃圾回收无法处理非托管代码，那它回收什么呢？

2、如果不是，合理的理由是什么？

3、资源泄露是托管代码还是非托管代码造成的？在垃圾回收无法处理非托管代码的情况下，语言开发人员该如何处理呢？

回到 Lysee： Lysee 不是基于传统的虚拟机运行的，代码不分托管不托管，享受同等待遇，都能通过 GC 回收。

11 楼 libudi 2008-05-06  

哦！使用多语言开发 Lysee 是迫不得已的，原因有三：

1、跨平台。为简化开发必须保证不同平台同时使用同一套代码，为此必须模拟提供所有操作系统具备的特性，比如在 Linux 中用 sem 模拟 Windows 的 Mutex，而操作系统多是用 C 开发的，Pascal 的运行需要 C 库，libc 在 Free Pascal 的 code base 中并不总是存在，比如 Lysee 在 Arch Linux Amd64 中可以访问到 libc，而在 Ubuntu 8.04 x86 中就没有那么好的运气，这时只好用 C 编写这部分代码然后链接到 Lysee 程序中。

2、高性能。Free Pascal 在编译优化和运行效率上还达不到 C/C++ 和 Object Pascal 的水平，曾有人做过这方面的测试（http://blog.csdn.net/yaolab/archive/2006/04/11/659463.aspx），Free Pascal 的成绩不是很理想，在特殊场合，不排除要在 Lysee 的开发中适当链接一些其它语言的代码，提高性能。

3、使用其它语言的元素。比如用 Lysee 装载使用 PHP 和 Perl 的模块，充实 Lysee 的模块库，这时必须使用其它语言（特别是 C）为 Lysee 做一些特别编码。

因此可以说 Lysee 解释器是用多语言开发的，但 Lysee 语言本身是纯正可移植的。

==========================================================================

如果记得不错的话，D 语言的作者开发过 C++ 版的 Delphi，比 Borland 版的 Delphi 和 C++Builder 都要厉害，所以我很佩服他（一个独行大虾）。D 是要用其它语言激活的（先有鸡还是先有蛋的问题），他会选择哪种语言，选择什么样的内存管理方式，猜对不会很难。D 语言能达到与它父辈相当的水平就已经成功了，值得尊敬。

==========================================================================

开个玩笑，见过用 C/C++/Pascal/Scheme 开发编译器的，确实没见过用 Js 开发编译器的，希望梁老兄做一个出来，我保证第一个用到自己的项目中。说实在的，用 Js 开发编译器真是勉为其难，但我真见过用 Js 实现 Lisp 的，用 Js 把浏览器改造成 HTTP 服务器的，都有代码，这种高手太少了而且很难碰到。

==========================================================================

梁老兄，不见外的话相互加个朋友如何？

10 楼 梁利锋 2008-05-06  

我想，“程序是多语言开发的”，和“语言是多语言开发的”还是不一样的。我不觉得，lysee在短期内会需要使用多语言开发程序。

另外，像 C# 对于 managed code 提供垃圾回收，而对 unmanaged code 不提供垃圾回收一样，就可以达到很好的平衡。毕竟，大多数时候，我们都是在使用 managed code 的。

我不是说引用计数完全没用，不过，它确实有它的适用范围，而对于语言级的垃圾回收，它并不适合。

引用

D is being written in which language?

本质上说，编译器只是读取文本文件，输出二进制文件，所以，用JavaScript写编译器也是可能的。

另外，D 语言的作者不止写 D 的编译器，事实上，他的主要工作是写 C/C++ 的编译器。有兴趣不妨去看看他介绍 D 垃圾回收机制以及和 C/C++ 模式比较的文档。

至于他说的可不可信，也许每个人有自己的判断吧。

9 楼 libudi 2008-05-06  

JavaEye 把我的恢复给吃了，还得再写一遍！

是否自动执行 GC 是配置和策略的问题，我个人更倾向于根据具体应用来决定。

Lysee 的开发方向是多进程，执行 GC 将中断现有程序，但比使用后台线程可能要简单一点。

Js 闭包和 ActiveX 资源泄露只是很小的一个方面，普遍看来，只要你的程序是多语言开发的，或者需要转载或运行其它人或其它语言编写的库或程序，就会碰到资源调度和回收的问题，问题就是：谁是协调人？Lysee 内核的非 Windows 版本同时使用 Free Pascal 和 GNC C 进行编写和联编，在接口定义、调用约定和资源调度方面碰到一系列棘手的问题，更何况 Java  与 C# 这样的超级大块头。我更倾向于 Java, 它比 C# 纯的多，而 C# 就是一条贪吃蛇，什么都往肚子里咽，消化肯定不是太好。

引用计数是非常好的计算机技术，Windows 的 COM 就是基于它开发的，从实际情况看，Windows 越来越庞大，但可靠性却在不断提升，证明 COM 没有伤害 Windows，而引用计数更没有伤害 COM。目前有越来越多的程序语言在使用引用计数，说明开发人员普遍认同这项技术，它已经成为程序语言的基础设施之一，GC 相对尴尬一点，它更多还只是一个可选项。

至于 D 比 C++ 快，在没看到可信服的测试数据前，我还不能认同！
D is being written in which language?

纯讨论技术，我可能过于强调自己的观点，请不要放在心上。

8 楼 梁利锋 2008-05-05  

以一种脚本语言，却需要程序员自己管理gc，在我看来是不能接受的。（即使一种编译语言都不应该了，C++0x都加入垃圾回收了）

如果像你的第一种做法所示，直接调用sys::gc()即可清理交叉引用的垃圾的话，为什么不在一个背景线程里执行？或者中断现有程序执行垃圾回收？是担心效率？但是据D语言的文档介绍，其实，使用垃圾回收机制的语言（如D语言），速度上常常反而快于C++。

另外，如果我没记错，js本身并不会造成内存泄漏，而是和ActiveX有交叉引用的时候才会造成内存泄漏，而ActiveX是使用引用计数的。所以，所谓的js的内存泄漏事实上还是因为引用计数算法造成的。

至于你说的“现有语言”“检查对象是否不再可访问的算法仍然是有很多漏洞”，你能举出Java/C#的例子来说明它确实产生了内存泄漏么？

7 楼 libudi 2008-05-05  

在开发 Lysee 的 GC 时我也参考了 Scheme, Haskell, Js 还有一些其它语言的方式，个人感觉 GC 在现阶段还只能达到基本能用的水平，为保 GC 正确进行，程序员仍然有责任编写适应 GC 机制的规范化的代码，就像 10 几年前写 Windows 程序时不断 ProcessMessages 和 Sleep 一样，否则资源的霸占和泄露就不可避免，现在的 Js 就是典型的例子。

用引用计数确实无法解决嵌套的问题，比如代码：

varlist A = [C];
varlist B = [A];
varlist C = [B];

A = nil;
B = nil;
C = nil;

列表 A, B, C 循环嵌套对方，即使将变量 A, B, C 的值清零， 列表 A, B, C 的引用计数仍保持 1 而无法释放，这是引用计数算法必然面对的困境。而从 GC 的角度看变量 A, B, C 退出堆栈后，列表 A, B, C 作为整体（作为一个大的容器看）从程序的角度看都是不再可访问的，可以安全的予以回收。现有语言的问题在于：检查对象是否不再可访问的算法仍然是有很多漏洞的，必须进行更深入的研究。

针对前面的代码，Lysee 可以用四种方法解决泄露的问题：

// 1. GC

sys::gc();

// 2. delete

delete A, B, C;

// 3. clear

A.clear();
B.clear();
C.clear();

// 4. exit
sys::exit(); // @_@, yeah! easy.

6 楼 梁利锋 2008-05-04  

我看到的一篇讲垃圾回收的文章各种垃圾回收算法的通俗解里说，早在1960年的时候，人们就因为引用计数法不能解决交叉引用而放弃使用它了。

换言之，目前主流的有垃圾回收机制的语言，都是解决了交叉引用问题的。

5 楼 libudi 2008-05-04  

梁利锋： 非常感谢你指出问题，同时感谢 playfish 的支持！

从 GC 发展的历史看，特别是现在，就是如何解决交叉引用、自我引用、嵌套引用等复杂情况的问题，Lysee 也不例外。Lysee 的垃圾回收是基于容器进行的，细节比较复杂，代价也很高，但总体效率和准确性应与其它语言在伯仲之间。

Lysee 是一种面向对象的函数式语言，象gc(), curry(), yield(), super(), eval(), apply() 等具有特定功能的函数有不少，闭包、RTTI 信息的获取和修改也都可以通过函数进行。现在的主要问题是由于人手太少，帮助文档没能及时跟上。文档的编写正在加紧进行，一两个月后应该有很大的改善。

4 楼 梁利锋 2008-05-04  

既然需要程序员自己调用gc，就更有必要介绍一下了。

另外，引用计数的方式，无法处理交叉引用的情况，如果 sys::gc 只是根据引用计数的来释放内存的话，则很有可能造成内存泄露。

3 楼 libudi 2008-05-04  

Lysee 同时采用引用计数和GC进行对象和内存管理，在短时计算（比如LSP网页生成）中进行垃圾回收通常没有太大的意义，因此 Lysee 中的垃圾回收缺省设置是不自动执行的，需要执行时只需执行“sys::gc();”即可，垃圾回收的具体时机更多交给程序员自己决定。

2 楼 梁利锋 2008-05-04  

看了一下文档，很不错的。不过没有提到内存分配方式，想来应该是自动垃圾回收的，不过还是明确说一下比较好。

1 楼 playfish 2008-05-04  

自己写的语言？很强大。。。虽然没用过，支持下。。写语言不容易啊。。