unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Andreas Rottmann <a.rottmann@gmx.at>
To: ludo@gnu.org (Ludovic Courtès)
Cc: guile-devel@gnu.org
Subject: Re: [Guile-commits] GNU Guile branch, stable-2.0, updated. v2.0.1-40-g2252321
Date: Thu, 09 Jun 2011 17:45:19 +0200	[thread overview]
Message-ID: <87hb7znh4g.fsf@gmx.at> (raw)
In-Reply-To: <87d3ioxcyf.fsf@gnu.org> ("Ludovic Courtès"'s message of "Wed, 08 Jun 2011 22:52:56 +0200")

ludo@gnu.org (Ludovic Courtès) writes:

> Hi Andreas,
>
> (Sorry for the laaaate reply, I'm just slowly catching up.)
>
> Andreas Rottmann <a.rottmann@gmx.at> skribis:
>
>> Andreas Rottmann <a.rottmann@gmx.at> writes:
>>
>>> ludo@gnu.org (Ludovic Courtès) writes:
>>>
>>>> Hi Andreas,
>>>>
>>>> Thanks for taking care of this, and thanks for the great doc too!
>>>>
>>>> "Andreas Rottmann" <a.rottmann@gmx.at> writes:
>>>>
>>>>> commit 2252321bb77fe83d98d5bcc9db1c76b914e9dd6a
>>>>> Author: Andreas Rottmann <a.rottmann@gmx.at>
>>>>> Date:   Sat May 7 23:40:14 2011 +0200
>>>>>
>>>>>     Make the R6RS simple I/O library use conditions
>>>>>     
>>>>>     * module/rnrs/io/ports.scm (display): Implement as an
>>>>>       exception-converting wrapper around Guile's core display.
>>>>>     * module/rnrs/io/simple.scm: Don't export Guile's corresponding core
>>>>>       procedures, but use `(rnrs io ports)' instead.  This way, we get the
>>>>>       conditions required by R6RS raised.
>>>>>     
>>>>>     * doc/ref/r6rs.texi (rnrs io simple): Mention that these procedures are
>>>>>       supposed to raise R6RS conditions.
>>>>
>>>> Could you add one or more test cases?
>>>>
>>> I've started to hack on this, aiming for at least providing tests of a
>>> "control sample" of exception-related behaviors in `(rnrs io simple)'
>>> and parts of `(rnrs io ports)'.  However, as this is already
>>> significantly more than one test, it may take a bit.  I could however
>>> push my existing work at any point, if that's needed for any reason.
>>>
>> I've now pushed a first patch (b6a66c2), in the process fixing two bugs.
>> These were not directly related to the simple I/O change you referenced,
>> but located in its base library `(rnrs io ports)'.
>
> +(define (with-i/o-port-error port make-primary-condition thunk)
> +  (with-throw-handler 'system-error
> +      thunk
> +    (lambda args
> +      (let ((errno (system-error-errno args)))
> +        (if (memv errno (list EIO EFBIG ENOSPC EPIPE))
> +            (raise (condition (make-primary-condition)
> +                              (make-i/o-port-error port)))
> +            (apply throw args))))))
> +
> +(define-syntax with-textual-output-conditions
> +  (syntax-rules ()
> +    ((_ port body0 body ...)
> +     (with-i/o-port-error port make-i/o-write-error
> +       (lambda () (with-i/o-encoding-error body0 body ...))))))
>
> [...]
>
>  (define (put-char port char)
> -  (with-i/o-encoding-error (write-char char port)))
> +  (with-textual-output-conditions port (write-char char port)))
>  
>  (define (put-datum port datum)
> -  (with-i/o-encoding-error (write datum port)))
> +  (with-textual-output-conditions port (write datum port)))
>
> I'm a bit concerned about the performance implications of the above
> change: ‘put-char’, ‘put-datum’, etc. now expand to something like
>
>      (with-i/o-port-error p xxx
>        (lambda ()
>          (with-throw-handler 'decoding-error
>            (lambda ()
>              (write-char c p))
>            (lambda (key subr message errno port)
>              (raise (make-i/o-decoding-error port))))))
>
> So there are at least 4 additional function calls (2
> ‘with-throw-handler’ calls, and 2 anonymous closure calls.)
>
Yeah, this is bound to be slow, at least for something as basic as
`put-char' -- but correctness trumps performance, right? ;-).

> Did you do any measurements?  Would be nice to add micro-benchmarks
> under benchmark-suite/.
>
No, but I'm planning to add some benchmarks, and do some (basic)
performance work in this area; as my Guiling time is quite limited ATM,
don't hold your breath, though.

> One optimization would be to instead do something such that ‘put-char’
> would expand to something like:
>
>   (define (put-char p c)
>     (with-throw-handler #t
>            (lambda ()
>              (write-char c p))
>            (lambda args
>              (case (car args)
>                ((decoding-error)
>                 (raise (make-i/o-decoding-error p)))
>                ((system-error)
>                 (if (memv (system-error-errno args)
>                           `(,EIO ,EFBIG ,ENOSPC ,EPIPE))
>                     ...))
>                (else
>                 ;; Not for us.
>                 (apply throw args))))))
>
> What do you think?
>
Yep, good idea.  I'll consider this when I have time to put some work
into it.

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>



      reply	other threads:[~2011-06-09 15:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1QIpZF-0003ay-MM@vcs-noshell.in.savannah.gnu.org>
2011-05-08 14:30 ` [Guile-commits] GNU Guile branch, stable-2.0, updated. v2.0.1-40-g2252321 Ludovic Courtès
2011-05-13 23:20   ` Andreas Rottmann
2011-05-14 17:46     ` Andreas Rottmann
2011-06-08 20:52       ` Ludovic Courtès
2011-06-09 15:45         ` Andreas Rottmann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87hb7znh4g.fsf@gmx.at \
    --to=a.rottmann@gmx.at \
    --cc=guile-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).