headers
Shiro Kawai | 2 Feb 2006 10:55
Favicon

Re: Problem redefining primitives

From: Arto Bendiken <arto.bendiken <at> gmail.com>
Subject: Re: [Gauche-devel] Problem redefining primitives
Date: Mon, 30 Jan 2006 12:11:06 +0100

> Shiro, sorry for my late reply. I noticed from the CVS change log that
> you've implemented the ((with-module x y) arg ...) support, great! Is
> the short-hand reader macro also included?

No, short-hand reader for with-module syntax is not in.  It's
easy to add, but I noticed one drawback.  Suppose we have a
syntax foo#bar that reads as (with-module foo bar).  The syntax
works just like Common Lisp's package-qualified symbols in most
places, except when you say (define foo#bar ...), which redefines
'with-module'.

--shiro

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
Permalink | Reply | 0 comments |
headers
Michal Maruška | 6 Feb 2006 04:31
Picon

kahua.partcont -- bug & fix


Hello to Kahua developers,

I'm trying to understand the Kahua system and
found the kahua/partcont.scm file.

I think, that there is a bug:

(use kahua.partcont)

(+ 1
  (reset/pc
   (+ 5
      (begin
        (format #t "before\n")
        1)
      (let/pc k
              (begin
                                        ;(format #t "2-> ~d\n" (k 2))
                                        ;(format #t "5-> ~d\n" (k 5))
                0
                ))
      (begin
        (format #t "after\n")
        1)
      )))

(k is not invoked, and) "after\n" is not printed.
value returned is 1.
(Continue reading)

Permalink | Reply | 1 comment |
headers
cut-sea | 6 Feb 2006 06:31
Picon

Re: kahua.partcont -- bug & fix

Hi.

Michal Maruška wrote:

>(use kahua.partcont)
>
>(+ 1
>  (reset/pc
>   (+ 5
>      (begin
>        (format #t "before\n")
>        1)
>      (let/pc k
>              (begin
>                                        ;(format #t "2-> ~d\n" (k 2))
>                                        ;(format #t "5-> ~d\n" (k 5))
>                0
>                ))
>      (begin
>        (format #t "after\n")
>        1)
>      )))
>
>(k is not invoked, and) "after\n" is not printed.
>value returned is 1.
>  
>

I think this result is my expected.
This reset/pc expression's continuation is like as (lambda (a) (+ 1 a)).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Shiro Kawai | 15 Feb 2006 08:48
Favicon

Re: Gauche-fastcgi 0.1.3

I updated Gauche-fastcgi, an extension module to use fastcgi
with Gauche.

http://sourceforge.jp/projects/gauche/files/

The only change is to support the API change of 
Scm_CStringArrayToList in upcoming Gauche 0.8.7.
This version should compile on both 0.8.6 and 0.8.7.

Gauche-0.8.7 is going to be a maintainance release, including
several important bug fixes.   I'd like to release Gauche 0.8.7
soon, though I'm occupied by my day job currently and can't
tell how soon it's gonna be.
You can update to Gauche-fastcgi-0.1.3 at your convenience.

--shiro

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
Permalink | Reply | 0 comments |
headers
Tomas Stanek | 15 Feb 2006 18:06
Picon
Favicon

Re: thread termination

On Sat 07.01 (11:23), Shiro Kawai wrote:
> Anyway, it needs to be addressed eventually, if not soon.
> Asynchronous cancelling seems too dangerous.   I think I can
> make VM loop occasionally call pthread_testcancel(), so that
> the busy VM loop can be interrupted by deferred cancellation.
> GC would be hard.  Maybe disabling cancellation while GC is
> holding the global lock?

Hello,

I've played with thread termination again a bit...
At the beginning, I've mainly focused on asynchronous termination via
pthread_cancel, but it realy seems to be painfull. When in asynchronous
mode, pthread_cancel sends signal to the thread being canceled, but it
works in quite undeterministic fassion :) Sometimes, the signal is
raised immediately, sometimes it's delayed and more signals are send in one
go (possibly bug in my version of pthreads?)

Then I remembered, how signals are handled in gauche...
The solution could be quite easy. I'm testing a variant, where each
thread has a signal mask for a dedicated signal and thread-terminate
sends the signal to given thread by pthread_kill, instead of
pthread_cancel-ing the thread. Then signal is handled by usual signal
handling mechanism, but instead of queueing the signal,
vm->queueNotEmpty is bitmasked with termination flag, and there is test
for termination in process_queue part of the vm loop and the loop simply
returns.
thread-terminate can even wait for actual termination (on vm's condition
variable) and it seems to by working fine.
I'm not using any of gauche's signal facilities and when this mechanism
(Continue reading)

Permalink | Reply | 1 comment |
headers
Shiro Kawai | 17 Feb 2006 22:34
Favicon

Re: thread termination

Using a signal, that's an interesting idea.  I'll think of it.

Probably a couple of issues here... first one is whether we
can afford one more reserved signal---Boehm GC already took
two on some platforms.

The second one is that a thread doesn't always return to
VM loop after receiving a signal; usually a signal interrupts
system calls and resturns with EINTR, which Gauche checks and
invokes appropriate (Gauche's handler).  However,
pthread_cond_wait may not return EINTR when it gets a signal---
the C singal handler is called, but after the handler returns
the thread may still keep waiting for a condition variable.
Thus, for this purpose only, we need to jump out of C signal
handler dirctly.  I need to think this more if there's a
safe way.

--shiro

From: Tomas Stanek <sad0ur <at> psi.cz>
Subject: Re: [Gauche-devel] thread termination
Date: Wed, 15 Feb 2006 18:06:26 +0100

> On Sat 07.01 (11:23), Shiro Kawai wrote:
> > Anyway, it needs to be addressed eventually, if not soon.
> > Asynchronous cancelling seems too dangerous.   I think I can
> > make VM loop occasionally call pthread_testcancel(), so that
> > the busy VM loop can be interrupted by deferred cancellation.
> > GC would be hard.  Maybe disabling cancellation while GC is
> > holding the global lock?
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Kilburg | 24 Feb 2006 15:18

test.csv and incomplete strings

The following code

#!/local/gauche/bin/gosh

(use text.csv)

(define (main args)
  (let ((proc (make-csv-writer #\,)))
    (proc (standard-output-port)
      '( #*"\"xxx" #*"2" "3" "4" "5" "6" )
    )
  )
)

gives me this error:

*** ERROR: incomplete string is not allowed: #*"\"xxx"
Stack Trace:
_______________________________________
  0  (rxmatch rx string)
        At line 164 of "/local/gauche-0.8.6/share/gauche/0.8.6/lib/gauche/regexp.scm"
  1  (regexp-replace-all quote-rx field quote-escape)
        At line 127 of "/local/gauche-0.8.6/share/gauche/0.8.6/lib/text/csv.scm"
  2  (display (regexp-replace-all quote-rx field quote-escape) port)
        At line 127 of "/local/gauche-0.8.6/share/gauche/0.8.6/lib/text/csv.scm"
  3  write-a-field

while this code

#!/local/gauche/bin/gosh
(Continue reading)

Permalink | Reply | 1 comment |

Gmane