[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