[Ecls-list] Unicode: uncomfortable situation

Matthew Mondor mm_lists at pulsar-zone.net
Tue Jan 25 21:09:58 UTC 2011


On Mon, 24 Jan 2011 20:41:26 -0500
Matthew Mondor <mm_lists at pulsar-zone.net> wrote:

> Thanks.  I guess that if comparing implementations, the consensus seems
> to provide a condition/restart interface rather than a more transparent

I started to look how the ECL condition system works so I can
eventually come up with a patch.  Unfortunately it's far from totally
clear to me yet, although I could only check for a few minutes
yesterday night so far.

It appears that CLOS is used for the hierarchy, although small C
functions are used to signal conditions from most of ECL, usually a
SIMPLE-ERROR using FEerror() or CEerror().  What's unclear to me so far
is how that maps to a SIMPLE-ERROR, and what modifications would have to
be made to such a simple function to instead say, signal a STREAM-ERROR
condition instead...  Since STREAM-ERROR is a CL standard condition,
and END-OF-FILE a child of it, I'll probably look closer at the stream
code next time.  I might be able to study ECL further tomorrow.

I think that I also found certain cases where other than a text message
there's no meaningful data provided for code to programatically take
decisions when handling those errors.  It'd be an eventual further step
to correct those.  However, a fair number seem to pass argument data
which should be available via the SIMPLE-CONDITION's (parent of
SIMPLE-ERROR) simple-condition-format-arguments, I think.

Meanwhile, if someone has a good understanding on the ECL condition
system and wishes to explain how those C functions map to the
hierarchical CLOS model, I'd be grateful, it wasn't clear to me when
looking at universal_error_handler().

Thanks,
-- 
Matt




More information about the ecl-devel mailing list