Need change for newer slib (>= 3a4)

While updating gauche 0.8.8 in Debian, I've found that following
change is needed for newer slib (I'm using 3a4).

--- Gauche-0.8.8.orig/lib/slib.scm.in	2005-07-12 10:01:07.000000000 +0900
+++ Gauche-0.8.8/lib/slib.scm.in	2006-12-04 14:09:18.000000000 +0900
 <at>  <at>  -115,7 +115,7  <at>  <at> 
 ;;; *FEATURES* should be set to a list of symbols describing features
 ;;; of this implementation.  Suggestions for features are:

-(define *features*
+(define slib:features
       '(
 	source				;can load scheme source files
 					;(slib:load-source "filename")

Besides, I found an installation problem for slibcat.

When 'make install' is invoked, the target 'install-pkg' will be
invoked _before_ invoking 'slibcat' under subdirectory lib.  But the
file lib/slibcat should be available when install-pkg invokes
'install' under subdirectory lib.

Here is a fix.

--- Gauche-0.8.8.orig/Makefile.in	2005-10-28 20:03:14.000000000 +0900
+++ Gauche-0.8.8.orig/Makefile.in	2006-12-05 17:58:37.000000000 +0900
 <at>  <at>  -46,7 +46,9  <at>  <at> 
 pre-package:
 	cd src; $(MAKE) pre-package

gosh-statifier

Hi,

Do you want to run a Gauche script without need to install Gauche?
If so, gosh-statifier is for you.

 http://t-code.org/gosh-statifier.scm

Gosh-statifier converts a Gauche script, Scheme libraries that are
loaded from the script, and DSOs into one binary file.  This file
can run on another machine without need to install Gauche and
its libraries (and even libc).

Creating pseudo-statically linked file is done by `statifier'
command.  Below is the process flow of gosh-statifier:

 (1) Loads the specified script file with `-fload-verbose' option
     to get a list of libraries and DSOs that are needed to run
     the script.

 (2) Creates a C program that contains all Scheme libraries and
     the script file, and compile it.

 (3) Runs statifier to create a pseudo-static binary file from an
     output of (2) and DSOs.

A script that needs to load library at runtime fails to run.
Because loading library is processed at compile time, you usually
do not worry about that.  However, you would test before you move
a file to the another machine.  I test a file by followings:

[Fwd: Bug#404230: gauche-gl: crash in finalizers]

Here is a bug report for gauche-gl 0.4.2.
It can be reproduced on Debian.

-------- Original Message --------
Subject: Bug#404230: gauche-gl: crash in finalizers
Resent-Date: Fri, 22 Dec 2006 17:33:06 +0000,	Fri, 22 Dec 2006 09:33:12
-0800
Resent-From: Jens Thiele (karme) <karme <at> berlios.de>
Resent-To: debian-bugs-dist <at> lists.debian.org
Resent-CC: NIIBE Yutaka <gniibe <at> fsij.org>
Date: Fri, 22 Dec 2006 18:20:47 +0100
From: Jens Thiele (karme) <karme <at> berlios.de>
Reply-To: Jens Thiele (karme) <karme <at> berlios.de>, 404230 <at> bugs.debian.org
To: Debian Bug Tracking System <submit <at> bugs.debian.org>

Package: gauche-gl
Version: 0.4.2-2
Severity: normal

I think the finalizers of the glu objects (nurbs, quadric, tesselator)
are wrong:
test prog:
(use gl)
(make <glu-nurbs>)
(print (gc-stat))
;; todo: will this always enforce gc (or is it more like maybe-gc)
(gc)
(print (gc-stat))

stack dump:

Re: [Fwd: Bug#404230: gauche-gl: crash in finalizers]

Thank you.  This part of code is actually very old (we no longer
call GC_REGISTER_FINALIZER directly).  I'll update this part for
the next gauche-gl release.

--shiro

From: NIIBE Yutaka <gniibe <at> fsij.org>
Subject: [Gauche-devel] [Fwd: Bug#404230: gauche-gl: crash in finalizers]
Date: Sat, 23 Dec 2006 13:40:17 +0900

> Here is a bug report for gauche-gl 0.4.2.
> It can be reproduced on Debian.
> 
> -------- Original Message --------
> Subject: Bug#404230: gauche-gl: crash in finalizers
> Resent-Date: Fri, 22 Dec 2006 17:33:06 +0000,	Fri, 22 Dec 2006 09:33:12
> -0800
> Resent-From: Jens Thiele (karme) <karme <at> berlios.de>
> Resent-To: debian-bugs-dist <at> lists.debian.org
> Resent-CC: NIIBE Yutaka <gniibe <at> fsij.org>
> Date: Fri, 22 Dec 2006 18:20:47 +0100
> From: Jens Thiele (karme) <karme <at> berlios.de>
> Reply-To: Jens Thiele (karme) <karme <at> berlios.de>, 404230 <at> bugs.debian.org
> To: Debian Bug Tracking System <submit <at> bugs.debian.org>
> 
> Package: gauche-gl
> Version: 0.4.2-2
> Severity: normal
> 
> I think the finalizers of the glu objects (nurbs, quadric, tesselator)

On Gauche-gtk development

It has been almost 2.5 years since I made the last release of 
Gauche-gtk.  I haven't had any time to work on it, and I don't
expect I will have anytime soon.

Fortunately, Michal Maruška, an active contributor of Gauche,
has been improving Gauche-gtk meanwhile.  See his email
http://sourceforge.net/mailarchive/forum.php?thread_id=31092525&forum_id=2043
for his latest results.

And now I'm glad to annouce that we have Michal in Gauche
committers.  He is going to merge his changes into Gauche-gtk
CVS, and his new versions will be released as the official
Gauche-gtk releases.

--shiro

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: On Gauche-gtk development

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
Gauche-devel mailing list
Gauche-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gauche-devel

Memory leak in process management

Hello

There is a memory leak in %run-process procedure when :wait #t argument
is provided. The reason is missing deletion of a process from process list.
The following code from process.scm, line 180

(when wait
  (slot-set! proc 'status
             (receive (p code) (sys-waitpid pid) code)))

fills in only process exit status, but leaves process list untouched.
process-wait won't help, because process-alive? check will fail (due to
filled in exit status) and procedure terminates without any effect.
Moreover the process-wait-any could raise an exception if no child 
process exists due to non null process-list.

Swapping the previous code for the following one corrects the bug.

(when wait
  (slot-set! proc 'status
             (receive (p code) (sys-waitpid pid) code))
  (slot-set! proc 'processes
             (delete proc (slot-ref proc 'processes))))

With best regards,
Tomas Stanek

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

c-wrapper 0.5.0

Hi all.

c-wrapper 0.5.0 is released.

c-wrapper is a foreign function interface for Gauche, and you can use  
C libraries easily.

The changes from the previous version are:
   - Added cwcompile command to generate a shared library. This  
reduces loading time.
   - Added c-load macro, which does c-load-library and c-include at  
one time.
   - Added :import keyword option for c-load and c-include to specify  
the symbols you want to define.
   - Added define-objc-class and define-objc-method to define  
Objective-C class and method.
   - Renamed make-c-array to c-array.
   - Fixed a bug that parsing a function pointer doesn't work  
correctly in some cases.

See http://homepage.mac.com/naoki.koguro/prog/c-wrapper/index.html
for more details.

Enjoy.

--
KOGURO, Naoki <naoki <at> koguro.net>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Memory leak in process management

Thanks for pointing this out.  Fixed.

--shiro

From: Tomas Stanek <sad0ur <at> psi.cz>
Subject: [Gauche-devel] Memory leak in process management
Date: Mon, 25 Dec 2006 17:12:54 +0100

> Hello
> 
> There is a memory leak in %run-process procedure when :wait #t argument
> is provided. The reason is missing deletion of a process from process list.
> The following code from process.scm, line 180
> 
> (when wait
>   (slot-set! proc 'status
>              (receive (p code) (sys-waitpid pid) code)))
> 
> fills in only process exit status, but leaves process list untouched.
> process-wait won't help, because process-alive? check will fail (due to
> filled in exit status) and procedure terminates without any effect.
> Moreover the process-wait-any could raise an exception if no child 
> process exists due to non null process-list.
> 
> Swapping the previous code for the following one corrects the bug.
> 
> (when wait
>   (slot-set! proc 'status
>              (receive (p code) (sys-waitpid pid) code))
>   (slot-set! proc 'processes
>              (delete proc (slot-ref proc 'processes))))
> 
> 
> With best regards,
> Tomas Stanek
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gauche-devel mailing list
> Gauche-devel <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gauche-devel
> 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

problem in complex multiply

I think there's a bug in complex multiply:

gosh> (* 0+1.0i 0)
0.0+1.0i
gosh> (* 1.0+1.0i 0.0)
1.0+1.0i
gosh> (gauche-version)
"0.8.8"

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV