optimizing lazy sequences: srfi-41 vs delayed continuation with values + promise vs delayed continuation with cons + lambda

Hello all, I know it's not good to optimize first, but I got into it and now I need to know. A few months ago, I created a lazy sequence library that retains history based on delayed continuation, it can be summarized as follow: (define-public (list->traversi lst) (let loop ((lst lst)) (l

Re: optimizing lazy sequences: srfi-41 vs delayed continuation with values + promise vs delayed continuation with cons + lambda

On 2018-02-25 15:16, Amirouche Boubekki wrote: Hello all, I know it's not good to optimize first, but I got into it and now I need to know. A few months ago, I created a lazy sequence library that retains history based on delayed continuation, it can be summarized as follow: (define-public (li

Is there any security risk related to the use of the reader?

I have procedures like that in my program: (define-public (scm->string scm) (call-with-output-string (lambda (port) (write scm port (define-public (string->scm string) (call-with-input-string string read)) Is it safe to pass to this procedures input from third parties? TIA!

Re: Is there any security risk related to the use of the reader?

On 02/25/2018 07:35 AM, Amirouche Boubekki wrote: I have procedures like that in my program: (define-public (scm->string scm)   (call-with-output-string     (lambda (port)   (write scm port (define-public (string->scm string)   (call-with-input-string string read)) Is it safe to pass

Re: Is there any security risk related to the use of the reader?

On 2018-02-25 16:35, Amirouche Boubekki wrote: I have procedures like that in my program: (define-public (scm->string scm) (call-with-output-string (lambda (port) (write scm port (define-public (string->scm string) (call-with-input-string string read)) Is it safe to pass to t

Re: Is there any security risk related to the use of the reader?

Luckily I kept notes on this... the answer is not very if you're snarfing stuff over the wire! : paroneayea: relatedly, : http://git.savannah.gnu.org/cgit/guile.git/commit/?id=e68dd5c601ef7975507d4118bcc2ad334b0450b2 : i suppose that doc update doesn't touch security at all tho... [16:5

Re: Is there any security risk related to the use of the reader?

On 2018-02-25 18:29, Matt Wette wrote: On 02/25/2018 07:35 AM, Amirouche Boubekki wrote: I have procedures like that in my program: (define-public (scm->string scm)   (call-with-output-string     (lambda (port)   (write scm port (define-public (string->scm string)   (call-with-input-st

Re: Is there any security risk related to the use of the reader?

On 2018-02-25 18:35, Christopher Lemmer Webber wrote: Luckily I kept notes on this... the answer is not very if you're snarfing stuff over the wire! : paroneayea: relatedly, : http://git.savannah.gnu.org/cgit/guile.git/commit/?id=e68dd5c601ef7975507d4118bcc2ad334b0450b2 : i suppose th

Re: optimizing lazy sequences: srfi-41 vs delayed continuation with values + promise vs delayed continuation with cons + lambda

I figured how to benchmark this. Here are the timings: promise: 43s lambda: 7s And at the current 'max' value the srfi-41 streams can't complete the benchmark with this error: Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS Here is the benchmark program: (use-modules (srfi srfi

Re: optimizing lazy sequences: srfi-41 vs delayed continuation with values + promise vs delayed continuation with cons + lambda

(define (lazyseq-with-stream) (list->stream (iota max))) This is wrong. It must be implemented as: (define-stream (lazyseq-with-stream) (stream-let loop ((v 1)) (stream-cons v (loop (+ 1 v) I get the same segfault with the following error: Too many heap sections: Increa