Re: [Chicken-users] catching exceptions

[F. Wittenberger]

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