headers
Manuel.Serrano | 1 Feb 08:11
Picon
Picon
Favicon

Re: segfault with filter

Hi, 

> Tue, 31 Jan 2012 14:51:29 +0100, cyprien.nicolas wrote:
> > According to gdb, it's a stack overflow. filter consumes stack as it
> > must check if a element must be kept or not in the newly allocated
> > resulting list.
> > 
> > You can find the definition of filter in runtime/Ieee/control.scm.
> 
> Would it make sense to replace the implementation of such a popular function
> with one that is tail-recursive?
> Or even by a dumb version like the following:
> 
> (define (filter pred l)
>   (let loop ((l l)
>              (new '()))
>      (cond ((null? l)
>             (reverse! new))
>            ((pred (car l))
>             (loop (cdr l) (cons (car l) new)))
>            (else
>             (loop (cdr l) new)))))
Filter, tries, as much as possible to return the same list as its argument.
That is:

  1:=> (define l '(1 2 3))
  1:=> (equal? l (filter (lambda (x) #t) l) 
         --> #t

This implies that it is not tail-recursive, contrary to filter! which is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johannes Bruegmann | 1 Feb 16:31
Picon

SRFI-18 compliance: mutex-lock!, mutex-unlock!

Hello,

the documentation [1] for mutexes with  3.8a (and 3.6a, too) describes the two
SRFI-18 procedures with the following signatures:

    (mutex-lock! mutex [timeout [thread]])
    (mutex-unlock! mutex)

The implementation in runtime/Llib/thread.scm has these signatures:

    (inline mutex-lock!::obj ::mutex #!optional (timeout::long 0))
    (inline mutex-unlock!::obj ::mutex)

The SRFI-18 document [2] instead describes the procedures having the following
signatures:

    (mutex-lock! mutex [timeout [thread]])
    (mutex-unlock! mutex [condition-variable [timeout]])

Additionally,  the signature for THREAD-JOIN! differs too:

    (thread-join! THREAD [TIMEOUT]) ; bigloo implementation and documentation
    (thread-join! thread [timeout [timeout-val]]) ; SRFI-18 documentation

Just wanted to let you know. Sorry for the noise.

Regards,
Johannes

[1]: http://www-sop.inria.fr/mimosa/fp/Bigloo/doc/bigloo-18.html#Mutexes
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lasse Kliemann | 1 Feb 23:25

silent exit when writing to lost connection

Assume that in the following situation, the server closes the SSL 
connection during the sleep of 30 seconds. 

(define (main main)
  (let* ((s (make-ssl-client-socket "example.com" 9000 protocol: 'sslv3))
         (from-srv (socket-input s))
         (to-srv (socket-output s)))
    (print "sleeping")
    (sleep 30000000)
    (print "printing")
    (fprint to-srv (list->string (map! (lambda (x) #\a) (make-list 100000))))
    (print "done")))

If the string written to 'to-srv' is long enough (100000 
characters is enough), then the program will simply exit with 
return code 141 without any error message (without printing 
"done").

I think, instead an exception should be raised. Otherwise, it's 
very hard to track down.

This happens with 3.7a and the latest alpha of 3.8a (27 Jan).
Permalink | Reply | 3 comments |
headers
Johannes Bruegmann | 3 Feb 12:32
Picon

thread-sleep! on bigloo3.6a FreeBSD 8.2-RELEASE

Hello,

The documentation says the following about thread-sleep! for posix threads:

     thread-sleep! timeout ; SRFI-18 function

    The  current thread  sleeps for  a  certain period.  It is  suspended and  the
    scheduler is free to  select a new thread to be resumed.  If there is only one
    thread started in the scheduler, the  same thread will be resumed. The time of
    timeout is used to determine the time the thread must sleep.

    Here are the possible types for timeout.

        * date: the thread sleeps at least until the date timeout.
        * real: the thread sleeps at least timeout seconds.
        * fixum, elong, llong: the thread sleeps at least timeout milli-seconds.

I have attached a small test file sleep-test.scm [1] that compiles fine with 

    bigloo3.6a -q -afile .afile -O5 -unsafe sleep-test.scm -o sleep-test

When run with "./sleep-test 1000" the program produces the following output:

    date1: Fri Feb  3 10:33:21 2012
    date2: Fri Feb  3 10:33:22 2012
    seconds slept: 1

The reason why the program runs fine is the function

    (define (sleep! ms)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Manuel.Serrano | 4 Feb 06:48
Picon
Picon
Favicon

Re: silent exit when writing to lost connection

Hi Lasse,

> Assume that in the following situation, the server closes the SSL 
> connection during the sleep of 30 seconds. 
> 
> (define (main main)
>   (let* ((s (make-ssl-client-socket "example.com" 9000 protocol: 'sslv3))
>          (from-srv (socket-input s))
>          (to-srv (socket-output s)))
>     (print "sleeping")
>     (sleep 30000000)
>     (print "printing")
>     (fprint to-srv (list->string (map! (lambda (x) #\a) (make-list 100000))))
>     (print "done")))
> 
> If the string written to 'to-srv' is long enough (100000 
> characters is enough), then the program will simply exit with 
> return code 141 without any error message (without printing 
> "done").
> 
> I think, instead an exception should be raised. Otherwise, it's 
> very hard to track down.
> 
> This happens with 3.7a and the latest alpha of 3.8a (27 Jan).
That's definitively a problem, unfortunately not that easy to solve.

Scheme (R5RS) is not very precise about errors that might occur when
writing characters. Display is described as returning an unspecified
value. The default (and more or less useless) choice of Bigloo is to
return the output port. Then, even if the printing fails, the returned
(Continue reading)

Permalink | Reply | 0 comments |
headers
Manuel.Serrano | 4 Feb 07:01
Picon
Picon
Favicon

Re: silent exit when writing to lost connection

My apologize, I said something wrong. Contrary to what I said, display
returns its output port but the runtime system *does* raise an exception
if an error occurs. In your case you don't see that exception because
you also receive a SIGPIPE signal from the OS that kills the
execution. To fix that problem, simply add the following at the
beginning of your execution:

   (signal sigpipe (lambda (x) #unspecified))

Please, let us know if that fixes your problem.

Sincerely,

--

-- 
Manuel
Permalink | Reply | 1 comment |
headers
Manuel.Serrano | 4 Feb 07:40
Picon
Picon
Favicon

Re: Problem compiling bigloo3.7a-2: Cannot open heap file"alsa.heap"

Hi Vladimir,

> just tried to build bigloo3.7a-2, the latest release of 3.7 I've found 
> at ftp://ftp-sop.inria.fr/indes/fp/Bigloo/:
> 
> ./configure
> make
> 
> Got the following problem:
> 
> /home/wowa/build/bigloo3.7a-2/bin/bigloo -O3 -fcfa-arithmetic -q 
> -lib-dir /home/wowa/build/bigloo3.7a-2/lib/3.7a -I Llib -lib-dir 
> /home/wowa/build/bigloo3.7a-2/lib/3.7a -unsafe -safee -srfi flac -copt 
> "" -copt -fPIC -copt "-IClib" Llib/flac_alsadec.scm -o 
> objs/flac_alsadec.o -c
> *** ERROR:restore-additional-heap:
> Cannot open heap file "alsa.heap" -- 
> (/home/wowa/build/bigloo3.7a-2/lib/3.7a . /usr/local/lib/bigloo/3.7a)
> make[5]: *** [objs/flac_alsadec.o] H81:0 1
Ah, yes. I have forgotten that alsa libs might not be available while mpg123
and flac are. I will fix that. Thanks for your report.

--

-- 
Manuel
Permalink | Reply | 1 comment |
headers
Manuel.Serrano | 4 Feb 07:42
Picon
Picon
Favicon

Re: Problem compiling bigloo3.7a-2: Cannot open heap file"alsa.heap"

> Why not? I skipped 3.7a almost completely ...
> and 3.8a will soon be final if I remember correctly.
Yes. It's almost stable. I'm just swamped with various other things. 
As soon as I have a couple of days in front of me I will try my best to
finalize the version.

--

-- 
Manuel
Permalink | Reply | 0 comments |
headers
Lasse Kliemann | 4 Feb 09:29

Re: silent exit when writing to lost connection

* Message by -Manuel.Serrano <at> inria.fr- from Sat 2012-02-04:
> My apologize, I said something wrong. Contrary to what I said, display
> returns its output port but the runtime system *does* raise an exception
> if an error occurs. In your case you don't see that exception because
> you also receive a SIGPIPE signal from the OS that kills the
> execution. To fix that problem, simply add the following at the
> beginning of your execution:
> 
>    (signal sigpipe (lambda (x) #unspecified))
> 
> Please, let us know if that fixes your problem.

Yes, now I get:

*** ERROR:write/display:
Broken pipe -- #<output_port:127.0.0.1>

Precisely, it is an &io-sigpipe-error. This should enable me to 
catch the error if it occurs.

Thank you!
Permalink | Reply | 0 comments |
headers
Vladimir Tsichevski | 4 Feb 13:43
Picon

Re: Problem compiling bigloo3.7a-2: Cannot open heap file"alsa.heap"

Thanks Manuel,

will wait for the patch.

On 04.02.2012 10:40, Manuel.Serrano <at> inria.fr wrote:
> Hi Vladimir,
>
>> just tried to build bigloo3.7a-2, the latest release of 3.7 I've found
>> at ftp://ftp-sop.inria.fr/indes/fp/Bigloo/:
>>
>> ./configure
>> make
>>
>> Got the following problem:
>>
>> /home/wowa/build/bigloo3.7a-2/bin/bigloo -O3 -fcfa-arithmetic -q
>> -lib-dir /home/wowa/build/bigloo3.7a-2/lib/3.7a -I Llib -lib-dir
>> /home/wowa/build/bigloo3.7a-2/lib/3.7a -unsafe -safee -srfi flac -copt
>> "" -copt -fPIC -copt "-IClib" Llib/flac_alsadec.scm -o
>> objs/flac_alsadec.o -c
>> *** ERROR:restore-additional-heap:
>> Cannot open heap file "alsa.heap" --
>> (/home/wowa/build/bigloo3.7a-2/lib/3.7a . /usr/local/lib/bigloo/3.7a)
>> make[5]: *** [objs/flac_alsadec.o] H81:0 1
> Ah, yes. I have forgotten that alsa libs might not be available while mpg123
> and flac are. I will fix that. Thanks for your report.
>
Permalink | Reply | 0 comments |

Gmane