hi IOhannes
many thanks for the the detailed answer.
On Sun, 02 Oct 2005 18:23:49 +0200 IOhannes m zmoelnig zmoelnig@iem.at wrote:
first my rant of the day: i would highly appreciate if people would say which symbols they are entering to make it crash (even better would be a bugreport-patch that says "1st click here, 2nd click here, 3rd click here to crash") people tend to write "type some symbols and sometimes it will crash and sometimes not"; so what am i (as possible bugfixer) expected to do ?? guess which symbols people typed ? end of the rant
i absolutely see your point. in this case i was pretty sure, that it will crash for sure (not somtimes and sometimes not). so i thought, 'after 7 - 10 actions' would be information enough. it turned out, that it crashes after the second action, after the first time a symbol was removed, what would be a more accurate information. for me it was not obvious, that i should tell, what symbols i entered, because it does not depend on what symbols. maybe i should have explicitly wrote, that it does *not* depend.
a note on your patch: i think it is not very clever to send a "delete"-message every time something is omitted on the 1st outlet (you do so by triggering an [f] (hopefully set to something valid by the 2nd outlet of [msgfile]) with the 1st outlet.) (but it could well be, that you only do so, because it proved to delay/circumvent/... the reentrance problem a bit) and "find" changes the current position to the first matching line. [delete( (without argument) deletes the current line (not specifying the line# is more efficient, as you don't have to seek for the line; but i know this only because i just read the code...)
thanks again for the explanation and hints.
lg roman
mfg.asd. IOhannes
Was denken Sie über E-Mail? Wir hören auf Ihre Meinung: http://surveylink.yahoo.com/wix/p0379378.aspx