Of course …

I did my modification from numbers to #t #f to quickly and didn’t saw my stupid 
mistake ☹

I’am surprised to see a segfault, since it should probably be catch by bigloo 
isn’t it ?
At least, previous version where checking and reporting something like

“Blablabla … increase BIGLOO_STACK_DEPTH”

I have saw a strange behavior previously: A function  was correctly running 
(processing a big curve) in the “main_thread” but was ending by a segfault when 
launch in a “secondary thread” (ie a thread created by instantiate:pthread) 
looking at the core file it was due to recursive call.

I did not take the time to investigate on it but it’s on my to-do list.

Thanks for your quick reply to highlight my stupid mistake.

Best regards,
Pierre-Francois.

From: Joseph Donaldson [mailto:[email protected]]
Sent: Friday, March 23, 2018 10:54 PM
To: Ollagnon, Pierre-Francois <[email protected]>; 
[email protected]
Subject: Re: [bigloo] (Probably a bug) Segfault using #t / #f instead of numbers


Hello, Pierre-Francois,

In your second example, you are testing equality between numeric values and the 
booleans #t and #f. Neither of these equality checks will every return true 
(the only value equal to #t is #t, likewise for #f; see 
r5rs<https://www-sop.inria.fr/indes/fp/Bigloo/doc/r5rs-9.html#Standard-procedures>
 ), and hence your function loops until it runs out of stack space and throws a 
seg-fault. Try the following:

(define (combination_seg-fault n s lst proc-to-apply)
   (cond ((equal? n 0)   (proc-to-apply  lst))  ;;Final
     ((equal? s 1)   (proc-to-apply  (append (make-list n #f) lst))) ;;Final
        ((equal? n s)       (proc-to-apply  (append (make-list n #t) lst))) 
;;Final
        (else           (begin
                          (combination_seg-fault (- n 1) (- s 1)  (cons #t lst) 
proc-to-apply)
                          (combination_seg-fault (- n 1) s (cons #f lst) 
proc-to-apply)))))

Best Regards,
Joe


The R5RS standard - The CHICKEN Scheme wiki





On Fri, Mar 23, 2018 at 9:07 AM, Ollagnon, Pierre-Francois
<[email protected]<mailto:[email protected]>>
 wrote:

Hello all,



Is there any reason for which I get a different behaviour on this 2 functions:



1:=> (define (combination n s lst proc-to-apply)

  (cond ((equal? n 0)   (proc-to-apply  lst))  ;;Final

        ((equal? s 1)   (proc-to-apply  (append (make-list n 0) lst))) ;;Final

        ((equal? n s)       (proc-to-apply  (append (make-list n 1) lst))) 
;;Final

        (else           (begin

                          (combination (- n 1) (- s 1)  (cons 1 lst) 
proc-to-apply)

                          (combination (- n 1) s (cons 0 lst) proc-to-apply)))))



1:=> (combination  4 2 '() print)

(0 0 0 1)

(0 0 1 0)

(1 1 0 0)

(1 1 0 0)







1:=> (define (combination_seg-fault n s lst proc-to-apply)

  (cond ((equal? n #f)   (proc-to-apply  lst))  ;;Final

        ((equal? s #t)   (proc-to-apply  (append (make-list n #f) lst))) ;;Final

        ((equal? n s)       (proc-to-apply  (append (make-list n #t) lst))) 
;;Final

        (else           (begin

                          (combination_seg-fault (- n 1) (- s 1)  (cons #t lst) 
proc-to-apply)

                          (combination_seg-fault (- n 1) s (cons #f lst) 
proc-to-apply)))))





= >(combination_seg-fault 4 2 '() print)

*** ERROR:bigloo:

`segmentation violation' exception -- raised





Since it is the same code, just dealing with other values I was expecting to get

(#f #f #f #t)

(#f #f #t #f)

(#t #t #f #f)

(#t #t #f #f)



Note that I get the same behavior in compiled and interpreted mode.



Best regards,

Pierre-Francois






Reply via email to