Subject: Re: macros
jskov@zoftcorp.adsl.dk
Date: Fri Apr 13 2001 - 03:02:01 CDT
>>>>> "Dom" == Dom Lachowicz <cinamod@hotmail.com> writes:
Dom> I've had a minute or two to think about how to implement macros,
Dom> and here is a *very* rough draft of what I came up with. It was
Dom> literally scribbled onto a napkin during dinner.
Dom> I have also given some thought as to implement macros giving 0
Dom> overhead in the default case (i.e. not editing a macro) -
Dom, I had some concerns I discussed with Martin and Joaquín.
This is what I wrote to them:
-------------
Yes. I read your message a while back, obviously, and have been
pondering if there's any way we can get a log on segv, even if the
user did not enable logging. But that would require the logging
overhead to be minimal, and the log report would have to be really
small.
I'm thinking of using a simple ring buffer, with a simple binary
encoding of the events. On segv, save this out to a file.
AbiWord, for the macro recording could use the same binary encoding to
save the amount of memory used - I see your code does continual writes
to the file - I can't help wonder if that'll become a nasty overhead.
So maybe always do binary encoding. When user selects save, translate
that to the ASCII representation. Import reads ASCII, translates to
binary minimal form.
AbiWord should have a switch that allows a crash report to be
translated to ASCII for inclusion in the bug report:
abiword --binary-macro-to-ascii dump.bin dump.txt
Or something like that.
-------------------
As you see, being biased, I'm more interested in the macro mechanism
to be used for tracking bugs than as a tool for the user. I very much
consider myself a power emacs user, but I don't actually use macros
that often. There's only so many things they're useful for.
IMO, the mechanism should be lean and fast, so it shouldn't really any
overhead to AbiWord - whether used or not.
And I'd like us to take advantage of that and do, as described above,
a background logger that'll use something like 10kB of memory on a
ring buffer, and will save this out in event of a (trapped) crash.
As a developer, I'm really excited thinking about such a feature: it's
like a core dump with a full record of events up to the crash. It'll
save the user from describing what she did to crash abiword, it'll
save us from trying to figure out how it was done, it'll allow us to
test fixes automatically, and keep the log around for regression
testing. And more importantly, it'll give us a handle on those
happens-once-a-month-impossible-to-reproduce bugs - those are the
really annoying ones IMO.
Jesper
This archive was generated by hypermail 2b25 : Fri Apr 13 2001 - 03:03:07 CDT