Re: [Chicken-users] catching exceptions
Am Dienstag, den 29.07.2008, 18:19 +0200 schrieb felix winkelmann: > On Tue, Jul 29, 2008 at 3:05 PM, Jörg F. Wittenberger > <[EMAIL PROTECTED]> wrote: > > BTW: I just compared with SRFI-18: > > > > (raise obj) ;procedure > > > >Calls the current exception handler with obj as the single > >argument. obj may be any Scheme object. > > > > Looks to me as if chicken was not compatible with srfi-18 either. > > > > Of course it is. What makes you think it isn't? See my last posting: it is srfi-18 compliant. However half way of my experiments, I tried to (raise 1) and got to catch some condition object. So I read the source and found ##sys#current-exception-handler initially set something, which would convert non-condition objects to condition-objects. That's ok by itself. The problem is, that, other than via "with-exception-handler" I've been/still am unable to modify the systems exception handler. The latter was what I was trying to do (similar to the SRFI-34 egg). ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] catching exceptions
On Tue, Jul 29, 2008 at 3:05 PM, Jörg F. Wittenberger <[EMAIL PROTECTED]> wrote: > BTW: I just compared with SRFI-18: > > (raise obj) ;procedure > >Calls the current exception handler with obj as the single >argument. obj may be any Scheme object. > > Looks to me as if chicken was not compatible with srfi-18 either. > Of course it is. What makes you think it isn't? cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] catching exceptions
Am Dienstag, den 29.07.2008, 14:55 +0200 schrieb Jörg F. Wittenberger: > Am Dienstag, den 29.07.2008, 05:26 -0700 schrieb Elf: > > furthermore, srfi-34 can be written entirely in terms of srfi-12, while the > > reverse is not true. > > Great! > > So far I have neither an idea how that could be done Being unable to solve a little programming task is something, which eats deeply into my self-respect. ... I'm NOT yet sure that the following is the correct solution to the problem. Please chicken friends: verify. At least it behaves as specified in those cases, where the srfi-34.egg failed this morning. However I'm still somewhat puzzled over the result! It happens not to redefine 'raise' now. How it comes that my raised objects are no longer replaced with some condition-object? I can't tell. As much as I couldn't tell why they where before. (define-syntax guard (syntax-rules () ((guard (var clause ...) e1 e2 ...) ((call-with-current-continuation (lambda (guard-k) (let ((oldh (current-exception-handler))) (with-exception-handler (lambda (condition) (with-exception-handler oldh (call-with-current-continuation (lambda (handler-k) (guard-k (lambda () (let ((var condition)) ; clauses may SET! var (guard-aux (handler-k (lambda () (raise condition))) clause ... (lambda () (call-with-values (lambda () e1 e2 ...) (lambda args (guard-k (lambda () (apply values args)) (define-syntax guard-aux (syntax-rules (else =>) ((guard-aux reraise (else result1 result2 ...)) (begin result1 result2 ...)) ((guard-aux reraise (test => result)) (let ((temp test)) (if temp (result temp) reraise))) ((guard-aux reraise (test => result) clause1 clause2 ...) (let ((temp test)) (if temp (result temp) (guard-aux reraise clause1 clause2 ... ((guard-aux reraise (test)) test) ((guard-aux reraise (test) clause1 clause2 ...) (let ((temp test)) (if temp temp (guard-aux reraise clause1 clause2 ... ((guard-aux reraise (test result1 result2 ...)) (if test (begin result1 result2 ...) reraise)) ((guard-aux reraise (test result1 result2 ...) clause1 clause2 ...) (if test (begin result1 result2 ...) (guard-aux reraise clause1 clause2 ...) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] catching exceptions
BTW: I just compared with SRFI-18: (raise obj) ;procedure Calls the current exception handler with obj as the single argument. obj may be any Scheme object. Looks to me as if chicken was not compatible with srfi-18 either. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] catching exceptions
Am Dienstag, den 29.07.2008, 05:26 -0700 schrieb Elf:
> furthermore, srfi-34 can be written entirely in terms of srfi-12, while the
> reverse is not true.
Great!
So far I have neither an idea how that could be done nor have I shown
the mental or social capability to aquire the relevant knowledge. I'm
running up against walls, trying to do so. (I even can't find out
whether this is my fault or some problem with the chicken environment,
where I'm trying it.)
So if you, or anybody else, could supply me with a working
implementation, I'll raise my hat (via neither srfi-18 nor srfi-34).
/Jörg
>
> -elf
>
> On Tue, 29 Jul 2008, Elf wrote:
>
> >
> > srfi-34 is meaningless without srfi-35 and srfi-36. nothing in srfi-34
> > details the actual format of exceptions/conditions. all of this is
> > self-contained in srfi-12. the reason for srfi-12's withdrawl was not
> > because of any flaws inherent in srfi-12, but because william clinger, the
> > author, disappeared apparently for a bit and therefore there was no
> > discussion. srfi-34 and related srfis are brittle and encode things in a
> > nonschemelike way, with a lot of extra parsing and ridiculousness involved.
> >
> > -elf
> >
> > On Tue, 29 Jul 2008, Jörg F. Wittenberger wrote:
> >
> >> Am Dienstag, den 29.07.2008, 04:48 -0700 schrieb Elf:
> >>>
> >>> the reason for the incompatibilities is that chicken uses the srfi-12
> >>> exception model, not the srfi-34, as the srfi-12 model is cleaner,
> >>> more flexible, and doesnt require six other srfis in order to work.
> >>
> >> I'm not (yet) interested in arguing about the pro's and con's of various
> >> exception systems.
> >>
> >> At least not until I get the one working, which is an accepted SRFI.
> >>
> >> I just can't believe that chicken is too weak to implement that one.
> >>
> >>
> >>
> >> Furthermore I fail to see, which six other srfi's are needed by srfi-34.
> >> The srfi document claims dependencies on srfi-9 and srfi-23. But I can
> >> see only srfi-23 ("error") being used.
> >>
> >>
> >>
> >> The problem I do have has actually nothing to do with exception handling
> >> and advantages of either srfi. It has to do with some magic, which
> >> prevents setting variables as Scheme is supposed to allow. That might
> >> be ok, if and only if, I can break through this fence.
> >>
> >>
> >>
> >> BTW: once I got SRFI-34 working, I'd really be interested to learn about
> >> your opinion and what is a) cleaner and b) more flexible in srfi-12.
> >> I'm not religious about the exception system. There are exactly two
> >> reason, why I insist and going to insist on srfi-34: I) "standard is
> >> better than better" and II) I depend on it for portability.
> >>
> >> best regards
> >>
> >> /Jörg
> >>
> >>> -elf
> >>>
> >>> On Tue, 29 Jul 2008, Jörg F. Wittenberger wrote:
> >>>
> Am Dienstag, den 29.07.2008, 03:21 -0700 schrieb Elf:
> > #;1> (use srfi-34)
> > ; loading /usr/lib/chicken/3/srfi-34.scm ...
> > ; loading /usr/lib/chicken/3/syntax-case.so ...
> > ; loading /usr/lib/chicken/3/syntax-case-chicken-macros.scm ...
> > ; loading library srfi-18 ...
> > #;2> (print (guard (ex (else 'success)) (with-input-from-string ")"
> > read)))
> > success
> > #;3> (condition-case (with-input-from-string ")" read) (val () "no
> > prob"))
> > "no prob"
> > #;4> (condition-case (call-with-input-string ")" read) (val () "no
> > prob"))
> > "no prob"
> > #;5>
> >
> > wasnt srfi-34.
>
> True. Was the old version of srfi-34, which I could not get replaced
> because of some network errors and probably some confusion on my part.
>
> Those - and my workaround - revealed some confusion wrt. chicken related
> resources: I fetched manually
> http://www.call-with-current-continuation.org/eggs/srfi-34.egg
> This is still version 0.1 at this time.
>
> chicken-setup - which refused to download last time (yesterday I think)
> - now finds version 0.2 as changed by Elf recently.
>
> However version 0.2 seems non-functional too. Though it catches
> exceptions, which the 0.1 version prevented to catch, it failes on
> several tests from the SRFi-34 examples.
>
> (print (guard (ex (else 'success)) (call-with-input-string ")" read)))
> => success
>
> OK
>
> 1st example from srfi-34:
>
> (call-with-current-continuation
> (lambda (k)
> (with-exception-handler (lambda (x)
> (display "condition: ")
> (write x)
> (newline)
> (k 'exception))
> (lambda ()
> (+ 1 (raise 'an-error))
> PRINTS: condition: an-error
> => exception
>
> chicken prints: condition: #
>
> 5th example:
>
> (call-with-current-continuati
Re: [Chicken-users] catching exceptions
Am Dienstag, den 29.07.2008, 05:17 -0700 schrieb Elf: > srfi-34 is meaningless without srfi-35 and srfi-36. nothing in srfi-34 > details the actual format of exceptions/conditions. Maybe I'm the only one, but I consider this separation of concern an advantage of srfi-34 over srfi-12. While it's true that I'm using parts of srfi-35 to encode some of the exception I'm using, this is a mere accident and might change at any time. However I do sometimes simply raise numbers or symbols or other objects (e.g. srfi-9 records), when that appears appropriate to me. Simpler than property conditions. > all of this is self-contained in srfi-12. the reason for srfi-12's withdrawl > was not > because of any flaws inherent in srfi-12, but because william clinger, the > author, disappeared apparently for a bit and therefore there was no > discussion. srfi-34 and related srfis are brittle and encode things in a > nonschemelike way, with a lot of extra parsing and ridiculousness involved. That's true: I view srfi-35 more like an interesting way to encode some types akin to multiple inheritance - though not exactly. Not too interesting. srfi-36 feels somewhat uninteresting to me. But as I said: I have still little interest in that discussion until my code runs. It can't be hard to allow me to raise arbitrary objects and re-establish the old handler during the exception handling. I just can't do it for some mythical reason. /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] catching exceptions
furthermore, srfi-34 can be written entirely in terms of srfi-12, while the
reverse is not true.
-elf
On Tue, 29 Jul 2008, Elf wrote:
srfi-34 is meaningless without srfi-35 and srfi-36. nothing in srfi-34
details the actual format of exceptions/conditions. all of this is
self-contained in srfi-12. the reason for srfi-12's withdrawl was not
because of any flaws inherent in srfi-12, but because william clinger, the
author, disappeared apparently for a bit and therefore there was no
discussion. srfi-34 and related srfis are brittle and encode things in a
nonschemelike way, with a lot of extra parsing and ridiculousness involved.
-elf
On Tue, 29 Jul 2008, Jörg F. Wittenberger wrote:
Am Dienstag, den 29.07.2008, 04:48 -0700 schrieb Elf:
the reason for the incompatibilities is that chicken uses the srfi-12
exception model, not the srfi-34, as the srfi-12 model is cleaner,
more flexible, and doesnt require six other srfis in order to work.
I'm not (yet) interested in arguing about the pro's and con's of various
exception systems.
At least not until I get the one working, which is an accepted SRFI.
I just can't believe that chicken is too weak to implement that one.
Furthermore I fail to see, which six other srfi's are needed by srfi-34.
The srfi document claims dependencies on srfi-9 and srfi-23. But I can
see only srfi-23 ("error") being used.
The problem I do have has actually nothing to do with exception handling
and advantages of either srfi. It has to do with some magic, which
prevents setting variables as Scheme is supposed to allow. That might
be ok, if and only if, I can break through this fence.
BTW: once I got SRFI-34 working, I'd really be interested to learn about
your opinion and what is a) cleaner and b) more flexible in srfi-12.
I'm not religious about the exception system. There are exactly two
reason, why I insist and going to insist on srfi-34: I) "standard is
better than better" and II) I depend on it for portability.
best regards
/Jörg
-elf
On Tue, 29 Jul 2008, Jörg F. Wittenberger wrote:
Am Dienstag, den 29.07.2008, 03:21 -0700 schrieb Elf:
#;1> (use srfi-34)
; loading /usr/lib/chicken/3/srfi-34.scm ...
; loading /usr/lib/chicken/3/syntax-case.so ...
; loading /usr/lib/chicken/3/syntax-case-chicken-macros.scm ...
; loading library srfi-18 ...
#;2> (print (guard (ex (else 'success)) (with-input-from-string ")"
read)))
success
#;3> (condition-case (with-input-from-string ")" read) (val () "no
prob"))
"no prob"
#;4> (condition-case (call-with-input-string ")" read) (val () "no
prob"))
"no prob"
#;5>
wasnt srfi-34.
True. Was the old version of srfi-34, which I could not get replaced
because of some network errors and probably some confusion on my part.
Those - and my workaround - revealed some confusion wrt. chicken related
resources: I fetched manually
http://www.call-with-current-continuation.org/eggs/srfi-34.egg
This is still version 0.1 at this time.
chicken-setup - which refused to download last time (yesterday I think)
- now finds version 0.2 as changed by Elf recently.
However version 0.2 seems non-functional too. Though it catches
exceptions, which the 0.1 version prevented to catch, it failes on
several tests from the SRFi-34 examples.
(print (guard (ex (else 'success)) (call-with-input-string ")" read)))
=> success
OK
1st example from srfi-34:
(call-with-current-continuation
(lambda (k)
(with-exception-handler (lambda (x)
(display "condition: ")
(write x)
(newline)
(k 'exception))
(lambda ()
(+ 1 (raise 'an-error))
PRINTS: condition: an-error
=> exception
chicken prints: condition: #
5th example:
(call-with-current-continuation
(lambda (k)
(with-exception-handler (lambda (x)
(display "reraised ") (write x) (newline)
(k 'zero))
(lambda ()
(guard (condition
((positive? condition) 'positive)
((negative? condition) 'negative))
(raise -1))
=> positive
chicken: reraised #
Ergo: raise from SRFI-18 - i.e., ##sys#signal from library.scm is not
compatible with SRFI-34 (btw: this is obvious from the source) and needs
to be replaced.
But I'm not entirely clear what the problem actually is. To me it seems
to be related to my disability to change some of chickens variables as I
want to and apparently the chicken library.scm happens to have the same
problem.
Let's see:
(condition-case
(with-exception-handler
(lambda (ex) (print "Toplevelhandler: " ex))
(lambda ()
((current-exception-handler) 1)))
(var () (print "Backstop: " var)))
prints: Toplevelhandler: 1
(condition-case
(with-exception-handler
(lambda (ex) (print "Toplevelhandler: " ex))
(lambda ()
(raise 1)))
(var () (print "Backstop: " var)))
Loops printing: Toplevelhandler: #
Assembling the relevant definitions from chicken's
Re: [Chicken-users] catching exceptions
srfi-34 is meaningless without srfi-35 and srfi-36. nothing in srfi-34
details the actual format of exceptions/conditions. all of this is
self-contained in srfi-12. the reason for srfi-12's withdrawl was not
because of any flaws inherent in srfi-12, but because william clinger, the
author, disappeared apparently for a bit and therefore there was no
discussion. srfi-34 and related srfis are brittle and encode things in a
nonschemelike way, with a lot of extra parsing and ridiculousness involved.
-elf
On Tue, 29 Jul 2008, Jörg F. Wittenberger wrote:
Am Dienstag, den 29.07.2008, 04:48 -0700 schrieb Elf:
the reason for the incompatibilities is that chicken uses the srfi-12
exception model, not the srfi-34, as the srfi-12 model is cleaner,
more flexible, and doesnt require six other srfis in order to work.
I'm not (yet) interested in arguing about the pro's and con's of various
exception systems.
At least not until I get the one working, which is an accepted SRFI.
I just can't believe that chicken is too weak to implement that one.
Furthermore I fail to see, which six other srfi's are needed by srfi-34.
The srfi document claims dependencies on srfi-9 and srfi-23. But I can
see only srfi-23 ("error") being used.
The problem I do have has actually nothing to do with exception handling
and advantages of either srfi. It has to do with some magic, which
prevents setting variables as Scheme is supposed to allow. That might
be ok, if and only if, I can break through this fence.
BTW: once I got SRFI-34 working, I'd really be interested to learn about
your opinion and what is a) cleaner and b) more flexible in srfi-12.
I'm not religious about the exception system. There are exactly two
reason, why I insist and going to insist on srfi-34: I) "standard is
better than better" and II) I depend on it for portability.
best regards
/Jörg
-elf
On Tue, 29 Jul 2008, Jörg F. Wittenberger wrote:
Am Dienstag, den 29.07.2008, 03:21 -0700 schrieb Elf:
#;1> (use srfi-34)
; loading /usr/lib/chicken/3/srfi-34.scm ...
; loading /usr/lib/chicken/3/syntax-case.so ...
; loading /usr/lib/chicken/3/syntax-case-chicken-macros.scm ...
; loading library srfi-18 ...
#;2> (print (guard (ex (else 'success)) (with-input-from-string ")" read)))
success
#;3> (condition-case (with-input-from-string ")" read) (val () "no prob"))
"no prob"
#;4> (condition-case (call-with-input-string ")" read) (val () "no prob"))
"no prob"
#;5>
wasnt srfi-34.
True. Was the old version of srfi-34, which I could not get replaced
because of some network errors and probably some confusion on my part.
Those - and my workaround - revealed some confusion wrt. chicken related
resources: I fetched manually
http://www.call-with-current-continuation.org/eggs/srfi-34.egg
This is still version 0.1 at this time.
chicken-setup - which refused to download last time (yesterday I think)
- now finds version 0.2 as changed by Elf recently.
However version 0.2 seems non-functional too. Though it catches
exceptions, which the 0.1 version prevented to catch, it failes on
several tests from the SRFi-34 examples.
(print (guard (ex (else 'success)) (call-with-input-string ")" read)))
=> success
OK
1st example from srfi-34:
(call-with-current-continuation
(lambda (k)
(with-exception-handler (lambda (x)
(display "condition: ")
(write x)
(newline)
(k 'exception))
(lambda ()
(+ 1 (raise 'an-error))
PRINTS: condition: an-error
=> exception
chicken prints: condition: #
5th example:
(call-with-current-continuation
(lambda (k)
(with-exception-handler (lambda (x)
(display "reraised ") (write x) (newline)
(k 'zero))
(lambda ()
(guard (condition
((positive? condition) 'positive)
((negative? condition) 'negative))
(raise -1))
=> positive
chicken: reraised #
Ergo: raise from SRFI-18 - i.e., ##sys#signal from library.scm is not
compatible with SRFI-34 (btw: this is obvious from the source) and needs
to be replaced.
But I'm not entirely clear what the problem actually is. To me it seems
to be related to my disability to change some of chickens variables as I
want to and apparently the chicken library.scm happens to have the same
problem.
Let's see:
(condition-case
(with-exception-handler
(lambda (ex) (print "Toplevelhandler: " ex))
(lambda ()
((current-exception-handler) 1)))
(var () (print "Backstop: " var)))
prints: Toplevelhandler: 1
(condition-case
(with-exception-handler
(lambda (ex) (print "Toplevelhandler: " ex))
(lambda ()
(raise 1)))
(var () (print "Backstop: " var)))
Loops printing: Toplevelhandler: #
Assembling the relevant definitions from chicken's source we find:
srfi-18.scm:
(define raise ##sys#signal)
library.scm:
(define (##sys#signal x)
(##sys#current-exception-handler x) )
(defi
Re: [Chicken-users] catching exceptions
Am Dienstag, den 29.07.2008, 04:48 -0700 schrieb Elf:
>
> the reason for the incompatibilities is that chicken uses the srfi-12
> exception model, not the srfi-34, as the srfi-12 model is cleaner,
> more flexible, and doesnt require six other srfis in order to work.
I'm not (yet) interested in arguing about the pro's and con's of various
exception systems.
At least not until I get the one working, which is an accepted SRFI.
I just can't believe that chicken is too weak to implement that one.
Furthermore I fail to see, which six other srfi's are needed by srfi-34.
The srfi document claims dependencies on srfi-9 and srfi-23. But I can
see only srfi-23 ("error") being used.
The problem I do have has actually nothing to do with exception handling
and advantages of either srfi. It has to do with some magic, which
prevents setting variables as Scheme is supposed to allow. That might
be ok, if and only if, I can break through this fence.
BTW: once I got SRFI-34 working, I'd really be interested to learn about
your opinion and what is a) cleaner and b) more flexible in srfi-12.
I'm not religious about the exception system. There are exactly two
reason, why I insist and going to insist on srfi-34: I) "standard is
better than better" and II) I depend on it for portability.
best regards
/Jörg
> -elf
>
> On Tue, 29 Jul 2008, Jörg F. Wittenberger wrote:
>
> > Am Dienstag, den 29.07.2008, 03:21 -0700 schrieb Elf:
> >> #;1> (use srfi-34)
> >> ; loading /usr/lib/chicken/3/srfi-34.scm ...
> >> ; loading /usr/lib/chicken/3/syntax-case.so ...
> >> ; loading /usr/lib/chicken/3/syntax-case-chicken-macros.scm ...
> >> ; loading library srfi-18 ...
> >> #;2> (print (guard (ex (else 'success)) (with-input-from-string ")" read)))
> >> success
> >> #;3> (condition-case (with-input-from-string ")" read) (val () "no prob"))
> >> "no prob"
> >> #;4> (condition-case (call-with-input-string ")" read) (val () "no prob"))
> >> "no prob"
> >> #;5>
> >>
> >> wasnt srfi-34.
> >
> > True. Was the old version of srfi-34, which I could not get replaced
> > because of some network errors and probably some confusion on my part.
> >
> > Those - and my workaround - revealed some confusion wrt. chicken related
> > resources: I fetched manually
> > http://www.call-with-current-continuation.org/eggs/srfi-34.egg
> > This is still version 0.1 at this time.
> >
> > chicken-setup - which refused to download last time (yesterday I think)
> > - now finds version 0.2 as changed by Elf recently.
> >
> > However version 0.2 seems non-functional too. Though it catches
> > exceptions, which the 0.1 version prevented to catch, it failes on
> > several tests from the SRFi-34 examples.
> >
> > (print (guard (ex (else 'success)) (call-with-input-string ")" read)))
> > => success
> >
> > OK
> >
> > 1st example from srfi-34:
> >
> > (call-with-current-continuation
> > (lambda (k)
> > (with-exception-handler (lambda (x)
> > (display "condition: ")
> > (write x)
> > (newline)
> > (k 'exception))
> > (lambda ()
> > (+ 1 (raise 'an-error))
> > PRINTS: condition: an-error
> > => exception
> >
> > chicken prints: condition: #
> >
> > 5th example:
> >
> > (call-with-current-continuation
> > (lambda (k)
> > (with-exception-handler (lambda (x)
> > (display "reraised ") (write x) (newline)
> > (k 'zero))
> > (lambda ()
> > (guard (condition
> >((positive? condition) 'positive)
> >((negative? condition) 'negative))
> >(raise -1))
> > => positive
> >
> > chicken: reraised #
> >
> > Ergo: raise from SRFI-18 - i.e., ##sys#signal from library.scm is not
> > compatible with SRFI-34 (btw: this is obvious from the source) and needs
> > to be replaced.
> >
> > But I'm not entirely clear what the problem actually is. To me it seems
> > to be related to my disability to change some of chickens variables as I
> > want to and apparently the chicken library.scm happens to have the same
> > problem.
> >
> > Let's see:
> >
> > (condition-case
> > (with-exception-handler
> > (lambda (ex) (print "Toplevelhandler: " ex))
> > (lambda ()
> >((current-exception-handler) 1)))
> > (var () (print "Backstop: " var)))
> > prints: Toplevelhandler: 1
> >
> > (condition-case
> > (with-exception-handler
> > (lambda (ex) (print "Toplevelhandler: " ex))
> > (lambda ()
> >(raise 1)))
> > (var () (print "Backstop: " var)))
> >
> > Loops printing: Toplevelhandler: #
> >
> > Assembling the relevant definitions from chicken's source we find:
> >
> > srfi-18.scm:
> >
> > (define raise ##sys#signal)
> >
> > library.scm:
> >
> > (define (##sys#signal x)
> > (##sys#current-exception-handler x) )
> >
> > (define (with-exception-handler handler thunk)
> > (let ([oldh ##sys#current-exception-handler])
> >(##sys#dynamic-wind
> > (lambda ()
Re: [Chicken-users] catching exceptions
the reason for the incompatibilities is that chicken uses the srfi-12 exception model, not the srfi-34, as the srfi-12 model is cleaner, more flexible, and doesnt require six other srfis in order to work. -elf On Tue, 29 Jul 2008, Jörg F. Wittenberger wrote: Am Dienstag, den 29.07.2008, 03:21 -0700 schrieb Elf: #;1> (use srfi-34) ; loading /usr/lib/chicken/3/srfi-34.scm ... ; loading /usr/lib/chicken/3/syntax-case.so ... ; loading /usr/lib/chicken/3/syntax-case-chicken-macros.scm ... ; loading library srfi-18 ... #;2> (print (guard (ex (else 'success)) (with-input-from-string ")" read))) success #;3> (condition-case (with-input-from-string ")" read) (val () "no prob")) "no prob" #;4> (condition-case (call-with-input-string ")" read) (val () "no prob")) "no prob" #;5> wasnt srfi-34. True. Was the old version of srfi-34, which I could not get replaced because of some network errors and probably some confusion on my part. Those - and my workaround - revealed some confusion wrt. chicken related resources: I fetched manually http://www.call-with-current-continuation.org/eggs/srfi-34.egg This is still version 0.1 at this time. chicken-setup - which refused to download last time (yesterday I think) - now finds version 0.2 as changed by Elf recently. However version 0.2 seems non-functional too. Though it catches exceptions, which the 0.1 version prevented to catch, it failes on several tests from the SRFi-34 examples. (print (guard (ex (else 'success)) (call-with-input-string ")" read))) => success OK 1st example from srfi-34: (call-with-current-continuation (lambda (k) (with-exception-handler (lambda (x) (display "condition: ") (write x) (newline) (k 'exception)) (lambda () (+ 1 (raise 'an-error)) PRINTS: condition: an-error => exception chicken prints: condition: # 5th example: (call-with-current-continuation (lambda (k) (with-exception-handler (lambda (x) (display "reraised ") (write x) (newline) (k 'zero)) (lambda () (guard (condition ((positive? condition) 'positive) ((negative? condition) 'negative)) (raise -1)) => positive chicken: reraised # Ergo: raise from SRFI-18 - i.e., ##sys#signal from library.scm is not compatible with SRFI-34 (btw: this is obvious from the source) and needs to be replaced. But I'm not entirely clear what the problem actually is. To me it seems to be related to my disability to change some of chickens variables as I want to and apparently the chicken library.scm happens to have the same problem. Let's see: (condition-case (with-exception-handler (lambda (ex) (print "Toplevelhandler: " ex)) (lambda () ((current-exception-handler) 1))) (var () (print "Backstop: " var))) prints: Toplevelhandler: 1 (condition-case (with-exception-handler (lambda (ex) (print "Toplevelhandler: " ex)) (lambda () (raise 1))) (var () (print "Backstop: " var))) Loops printing: Toplevelhandler: # Assembling the relevant definitions from chicken's source we find: srfi-18.scm: (define raise ##sys#signal) library.scm: (define (##sys#signal x) (##sys#current-exception-handler x) ) (define (with-exception-handler handler thunk) (let ([oldh ##sys#current-exception-handler]) (##sys#dynamic-wind (lambda () (set! ##sys#current-exception-handler handler)) thunk (lambda () (set! ##sys#current-exception-handler oldh)) ) ) ) (define (current-exception-handler) ##sys#current-exception-handler) This is where I can't follow. To my understanding (raise 1) and ((current-exception-handler) 1) are supposed to be equivalent. Apparently I'm wrong on that one, since they are not. Judging from the source, I tried: (with-exception-handler (lambda (ex) (print "Toplevelhandler: " ex)) (lambda () (raise (make-property-condition 'testcondition since I'd expect that to go unchanged though the ##sys#current-exception-handler but it doesn't help and I don#t know where my testcondition get's converted into # - which is what happens. I wan't be able to fix that one, since I do not understand what's going on. Let's use (define (raise obj) ((current-exception-handler) obj)) for the time being and continue to test for srfi-34 compliance. Example #7: (with-exception-handler (lambda (ex) (print "Toplevelhandler:" ex)) (lambda () (call-with-current-continuation (lambda (k) (with-exception-handler (lambda (x) (display "reraised ") (write x) (newline) (k 'zero)) (lambda () (guard (condition ((positive? condition) 'positive) ((negative? condition) 'negative)) (raise 0 PRINTS: reraised 0 => zero chicken: does not print anything, hangs in a tight loop (since the exceptionhandler in effect while evaluating the guard ha
Re: [Chicken-users] catching exceptions
Am Dienstag, den 29.07.2008, 03:21 -0700 schrieb Elf: > #;1> (use srfi-34) > ; loading /usr/lib/chicken/3/srfi-34.scm ... > ; loading /usr/lib/chicken/3/syntax-case.so ... > ; loading /usr/lib/chicken/3/syntax-case-chicken-macros.scm ... > ; loading library srfi-18 ... > #;2> (print (guard (ex (else 'success)) (with-input-from-string ")" read))) > success > #;3> (condition-case (with-input-from-string ")" read) (val () "no prob")) > "no prob" > #;4> (condition-case (call-with-input-string ")" read) (val () "no prob")) > "no prob" > #;5> > > wasnt srfi-34. True. Was the old version of srfi-34, which I could not get replaced because of some network errors and probably some confusion on my part. Those - and my workaround - revealed some confusion wrt. chicken related resources: I fetched manually http://www.call-with-current-continuation.org/eggs/srfi-34.egg This is still version 0.1 at this time. chicken-setup - which refused to download last time (yesterday I think) - now finds version 0.2 as changed by Elf recently. However version 0.2 seems non-functional too. Though it catches exceptions, which the 0.1 version prevented to catch, it failes on several tests from the SRFi-34 examples. (print (guard (ex (else 'success)) (call-with-input-string ")" read))) => success OK 1st example from srfi-34: (call-with-current-continuation (lambda (k) (with-exception-handler (lambda (x) (display "condition: ") (write x) (newline) (k 'exception)) (lambda () (+ 1 (raise 'an-error)) PRINTS: condition: an-error => exception chicken prints: condition: # 5th example: (call-with-current-continuation (lambda (k) (with-exception-handler (lambda (x) (display "reraised ") (write x) (newline) (k 'zero)) (lambda () (guard (condition ((positive? condition) 'positive) ((negative? condition) 'negative)) (raise -1)) => positive chicken: reraised # Ergo: raise from SRFI-18 - i.e., ##sys#signal from library.scm is not compatible with SRFI-34 (btw: this is obvious from the source) and needs to be replaced. But I'm not entirely clear what the problem actually is. To me it seems to be related to my disability to change some of chickens variables as I want to and apparently the chicken library.scm happens to have the same problem. Let's see: (condition-case (with-exception-handler (lambda (ex) (print "Toplevelhandler: " ex)) (lambda () ((current-exception-handler) 1))) (var () (print "Backstop: " var))) prints: Toplevelhandler: 1 (condition-case (with-exception-handler (lambda (ex) (print "Toplevelhandler: " ex)) (lambda () (raise 1))) (var () (print "Backstop: " var))) Loops printing: Toplevelhandler: # Assembling the relevant definitions from chicken's source we find: srfi-18.scm: (define raise ##sys#signal) library.scm: (define (##sys#signal x) (##sys#current-exception-handler x) ) (define (with-exception-handler handler thunk) (let ([oldh ##sys#current-exception-handler]) (##sys#dynamic-wind (lambda () (set! ##sys#current-exception-handler handler)) thunk (lambda () (set! ##sys#current-exception-handler oldh)) ) ) ) (define (current-exception-handler) ##sys#current-exception-handler) This is where I can't follow. To my understanding (raise 1) and ((current-exception-handler) 1) are supposed to be equivalent. Apparently I'm wrong on that one, since they are not. Judging from the source, I tried: (with-exception-handler (lambda (ex) (print "Toplevelhandler: " ex)) (lambda () (raise (make-property-condition 'testcondition since I'd expect that to go unchanged though the ##sys#current-exception-handler but it doesn't help and I don#t know where my testcondition get's converted into # - which is what happens. I wan't be able to fix that one, since I do not understand what's going on. Let's use (define (raise obj) ((current-exception-handler) obj)) for the time being and continue to test for srfi-34 compliance. Example #7: (with-exception-handler (lambda (ex) (print "Toplevelhandler:" ex)) (lambda () (call-with-current-continuation (lambda (k) (with-exception-handler (lambda (x) (display "reraised ") (write x) (newline) (k 'zero)) (lambda () (guard (condition ((positive? condition) 'positive) ((negative? condition) 'negative)) (raise 0 PRINTS: reraised 0 => zero chicken: does not print anything, hangs in a tight loop (since the exceptionhandler in effect while evaluating the guard handler is the same as during guard's body, which is wrong. Summary: I'm afraid srfi-34.egg is not yet ready for the prime time. I appreciate either a fixed version or *any* help and pointers to get m
Re: [Chicken-users] catching exceptions
#;1> (use srfi-34) ; loading /usr/lib/chicken/3/srfi-34.scm ... ; loading /usr/lib/chicken/3/syntax-case.so ... ; loading /usr/lib/chicken/3/syntax-case-chicken-macros.scm ... ; loading library srfi-18 ... #;2> (print (guard (ex (else 'success)) (with-input-from-string ")" read))) success #;3> (condition-case (with-input-from-string ")" read) (val () "no prob")) "no prob" #;4> (condition-case (call-with-input-string ")" read) (val () "no prob")) "no prob" #;5> wasnt srfi-34. -elf On Tue, 29 Jul 2008, Jörg F. Wittenberger wrote: ERR Double checked: it's SRFI-34, which is in the way! I accidentally left (require-extension srfi-34) in the code I compiled to test condition-case. Once removed, the error get caught. So we have the bug in srfi-34.egg - definately. Am Dienstag, den 29.07.2008, 11:35 +0200 schrieb Jörg F. Wittenberger: Am Dienstag, den 29.07.2008, 18:06 +0900 schrieb Ivan Raikov: What version of Chicken is this on? Your code works fine on my system (Chicken 3.3.0): $ ./tg condition-case-does-a-better-job-than-guard thanks anyway. still wondering about the way .deb's are build. /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] catching exceptions
Am Dienstag, den 29.07.2008, 02:56 -0700 schrieb Elf: > i explained this already. > you want with-input-from-string. > not call-with-input-string and I answered already, that *I* pretty sure call-with-input-string should be ok too, since it's just direct passing of the port instead of passing via (current-input-port). I consider the former preferably for readability and amount of runtime operations. /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] catching exceptions
ERR Double checked: it's SRFI-34, which is in the way! I accidentally left (require-extension srfi-34) in the code I compiled to test condition-case. Once removed, the error get caught. So we have the bug in srfi-34.egg - definately. Am Dienstag, den 29.07.2008, 11:35 +0200 schrieb Jörg F. Wittenberger: > Am Dienstag, den 29.07.2008, 18:06 +0900 schrieb Ivan Raikov: > > What version of Chicken is this on? Your code works fine on my > > system (Chicken 3.3.0): > > > > $ ./tg > > condition-case-does-a-better-job-than-guard thanks anyway. still wondering about the way .deb's are build. /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] catching exceptions
#;1> (condition-case (with-input-from-string ")" read) (var () "no prob")) "no prob" #;2> (condition-case (call-with-input-string ")" read) (var () "no prob")) "no prob" #;3> On Tue, 29 Jul 2008, Jörg F. Wittenberger wrote: Am Dienstag, den 29.07.2008, 18:06 +0900 schrieb Ivan Raikov: What version of Chicken is this on? Your code works fine on my system (Chicken 3.3.0): $ ./tg condition-case-does-a-better-job-than-guard chicken -version CHICKEN (c)2008 The Chicken Team (c)2000-2007 Felix L. Winkelmann Version 3.3.4 - linux-unix-gnu-x86 [ manyargs dload ptables applyhook hostpcre ] SVN rev. 11356 compiled 2008-07-19 on debian (Linux) Ivan, could you try this one too (precondition: chicken-setup srfi-34 ): --- %< --- tg.scm --- (require-extension srfi-34 ports) (print (guard (ex (else 'success)) (call-with-input-string ")" read))) --- %< --- If this works too, I'll tear my chicken apart not my application. thanks a lot /Jörg BTW: Does anybody know how the Debian packages are being built? I installed binary from ubuntu 8.04 and got some newer version than what dpkg-buildpackage in my local copy produces (which claims Version: 3.2.0-0.2 for the very same thing as above). ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] catching exceptions
i explained this already. you want with-input-from-string. not call-with-input-string -elf On Tue, 29 Jul 2008, Jörg F. Wittenberger wrote: Hi all, continuing my experiments to catch exceptions in chicken, I've been working out a more core-chicken-only example. Let's see. Is this correct as a minimal example? --- %< tg.scm (require-extension srfi-34) (print (guard (ex (else 'success)) (call-with-input-string ")" read))) --- %< no, for two reasons: first, you need to (require-extension ports) for call-with-input-string. Now I tried: --- %< tg.scm (require-extension ports) (print (condition-case (call-with-input-string ")" read) (var () 'condition-case-does-a-better-job-than-guard))) --- %< And here the result: $ csc -o tg tg.scm $ ./tg Error: unexpected list terminator: #\) Call history: ##sys#require call-with-current-continuation with-exception-handler ##sys#call-with-values call-with-input-string <-- Looks as if condition-case is - too - unable to catch the exception. Did I still do anything wrong? best regards /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] catching exceptions
I get: csi> (print (guard (ex (else 'success)) (call-with-input-string ")" read))) success The official Debian package is based on development release 3.2.7, which is identical to stable release 3.3.0. -Ivan Jörg "F. Wittenberger" <[EMAIL PROTECTED]> writes: > Ivan, could you try this one too (precondition: chicken-setup srfi-34 ): > > --- %< --- tg.scm --- > (require-extension srfi-34 ports) > (print (guard (ex (else 'success)) (call-with-input-string ")" read))) > --- %< --- > > If this works too, I'll tear my chicken apart not my application. > > thanks a lot > > /Jörg > > BTW: Does anybody know how the Debian packages are being built? I > installed binary from ubuntu 8.04 and got some newer version than what > dpkg-buildpackage in my local copy produces (which claims Version: > 3.2.0-0.2 for the very same thing as above). ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] catching exceptions
Am Dienstag, den 29.07.2008, 18:06 +0900 schrieb Ivan Raikov: > What version of Chicken is this on? Your code works fine on my > system (Chicken 3.3.0): > > $ ./tg > condition-case-does-a-better-job-than-guard chicken -version CHICKEN (c)2008 The Chicken Team (c)2000-2007 Felix L. Winkelmann Version 3.3.4 - linux-unix-gnu-x86 [ manyargs dload ptables applyhook hostpcre ] SVN rev. 11356 compiled 2008-07-19 on debian (Linux) Ivan, could you try this one too (precondition: chicken-setup srfi-34 ): --- %< --- tg.scm --- (require-extension srfi-34 ports) (print (guard (ex (else 'success)) (call-with-input-string ")" read))) --- %< --- If this works too, I'll tear my chicken apart not my application. thanks a lot /Jörg BTW: Does anybody know how the Debian packages are being built? I installed binary from ubuntu 8.04 and got some newer version than what dpkg-buildpackage in my local copy produces (which claims Version: 3.2.0-0.2 for the very same thing as above). ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] catching exceptions
What version of Chicken is this on? Your code works fine on my system (Chicken 3.3.0): $ ./tg condition-case-does-a-better-job-than-guard Jörg "F. Wittenberger" <[EMAIL PROTECTED]> writes: > > Now I tried: > > --- %< tg.scm > (require-extension ports) > (print (condition-case > (call-with-input-string ")" read) > (var () 'condition-case-does-a-better-job-than-guard))) > --- %< > > And here the result: > > $ csc -o tg tg.scm > $ ./tg > Error: unexpected list terminator: #\) > > Call history: > > ##sys#require > call-with-current-continuation > with-exception-handler > ##sys#call-with-values > call-with-input-string <-- > ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] catching exceptions
Hi all, continuing my experiments to catch exceptions in chicken, I've been working out a more core-chicken-only example. > > > Let's see. Is this correct as a minimal example? > > > --- %< tg.scm > > > (require-extension srfi-34) > > > (print (guard (ex (else 'success)) (call-with-input-string ")" read))) > > > --- %< > > > > no, for two reasons: > > first, you need to (require-extension ports) for call-with-input-string. Now I tried: --- %< tg.scm (require-extension ports) (print (condition-case (call-with-input-string ")" read) (var () 'condition-case-does-a-better-job-than-guard))) --- %< And here the result: $ csc -o tg tg.scm $ ./tg Error: unexpected list terminator: #\) Call history: ##sys#require call-with-current-continuation with-exception-handler ##sys#call-with-values call-with-input-string <-- Looks as if condition-case is - too - unable to catch the exception. Did I still do anything wrong? best regards /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] catching exceptions
On Sun, Jul 27, 2008 at 8:49 PM, Jörg F. Wittenberger <[EMAIL PROTECTED]> wrote: > BTW: how do you know about the memory leak on my machine? Did *you* > install that big brother module? Actually it seems not to be a leak, > more like a swap. After a while things segfault, which happend to work. > All I did: change the compiler. > That means a lot: different FFI, and different ways to interpret R5RS... cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] catching exceptions
Thanks for your reply.
Am Samstag, den 26.07.2008, 13:45 -0700 schrieb Elf:
> On Sat, 26 Jul 2008, Jörg F. Wittenberger wrote:
>
> > Am Donnerstag, den 24.07.2008, 14:41 -0700 schrieb Elf:
> >> guard is not normally part of chicken.
> >
> > Still I don't know how to get a basic example working.
> >
> >> if you run 'chicken-setup srfi-34'
> >
> > done.
> >
> >> and add a require-extension srfi-34 line to your code, youll have guard.
> >
> > Let's see. Is this correct as a minimal example?
> > --- %< tg.scm
> > (require-extension srfi-34)
> > (print (guard (ex (else 'success)) (call-with-input-string ")" read)))
> > --- %<
>
> no, for two reasons:
> first, you need to (require-extension ports)
> for call-with-input-string.
OK. But this appears to be optional, at least it did work
> second, youre using call-with-input-string incorrectly.
> you probably want with-input-from-string in this case, because otherwise
> read will be expecting an arg that its not getting.
I'm afraid it's you this time, who got the use of call-with-input-string
wrong. From "manual/Unit ports"
call-with-input-string
[procedure] (call-with-input-string STRING PROC)
Calls the procedure {{PROC}} with a single argument that is a
string-input-port with the contents of {{STRING}}.
That's exactly what I wanted: "read" should get one argument, the port.
However your are right: with-input-from-string should call "read" too,
this time with no arguments, but the current-input-port set to the
string port. Thus an explicit parameter passing would be replaced by
passing the value via parameter variables. Not much difference (except
that I do not really like the latter for obfuscating the souce and
[little] additional runtime work to be done).
> thirdly, after some experimentation, i see your point. whoever 'ported'
> it originally DID do the same thing you did, namely try to hack in a
> reference implementation without any regard for the existing procedures,
> macros, vars, etc of the same name. This is why srfi-34 didn't work.
>
> around 21:30 UTC, the new egg will be in place in the repo. possibly before.
> all this egg does is provide a guard macro. all other functionality is
> provided by the core chicken lib and srfi-18 (for raise).
Hm, I'm not sure what's going on here. chicken.wiki.br appears
unavailable right now.
I made a wild guess and fetched:
http://www.call-with-current-continuation.org/eggs/srfi-34.egg
This one appears to be pretty identical to the none-working one.
Tested: same problem.
Could you do me the favor to pass me a copy of the fixed version in
personal email.
I'd be curious: raise as in srfi-18.scm; that is ##sys#signal from
library.scm seems not exactly what SRFI-34 raise is. How is the macro
supposed to solve that?
> I would strongly
> recommend converting to condition-case forms over the guard form, though.
Did I say "no, I'm not changing&breaking 50kLOC; I want portability"?
I'm going to stand at that point until *really* good reasons come up.
One of them will be: available at most Scheme systems.
> guard will work for you.
I hope so. But currently it does unfortunately not catch those
exceptions.
> as stated above, i was wrong. it turns out he did exactly what you
> did,
> namely overwrite things without reading the manual or finding out what was
> there or even asking what the capabilities may be, nor apparently reading
> any of the main web pages, nor...
Well, if I had been able to deduce those answer from anywhere, I would
have done so.
> how to avoid repeating mistakes: read the bloody manual. its not kept up
> to date just cause we're bored.
Just do me the favor, please, and tell me where I could find the
relevant information. Reading manual and source did not help. For some
reasons, I can't replace the exception handler. I'm to stupid to find
the spot, which prevents me from doing so. Neither in the docs nor by
reading the source. And asking here did not help any further so far.
BTW: how do you know about the memory leak on my machine? Did *you*
install that big brother module? Actually it seems not to be a leak,
more like a swap. After a while things segfault, which happend to work.
All I did: change the compiler.
best regards
/Jörg
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] catching exceptions
chicken already supports most of srfi-34 natively and the rest is supported via an egg. have you looked at all at the manual or at the egg libs yet? -elf On Thu, 24 Jul 2008, Jörg F. Wittenberger wrote: Hi all, I have some lines of Scheme, which rely on SRF-34 and I don't really want to change that code. I can hardly imagine, that I can't replace chickens exception handler. But I can't. What I tried was to overwrite ##sys#error and friends (see appended source - which does not really get the job done). [The next step is going to be funny formating and routing of those exceptions. So I *really* need to get them under control. So how would I plug my exception handler in place of the standard exception handler? Thanks a lot ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
