From: Ethan M. <merritt@u.washington.edu> - 2003-10-20 19:49:41
|
[apologies if you receive this message twice. Since I'm not entirely sure that the new gnu...@li... is working, I have CCed various interested parties directly] Petr Mikulik and John Bollinger alerted me to the recurrence of an old problem. When (1) gnuplot is run from a script and (2) mouse input is enabled, then characters are dropped from the input=20 stream. I initially thought this was something I had broken with my X11 initialization patches (revisions 1.71 - 1.74 of term/x11.trm). But after backing these out altogether, I still see the problem, although possibly with a lower frequency. After much poking about in the source code, I came across this bit in term/x11.trm /* apparently multi-character inputs like escape sequences * but also mouse-pasted text got buffered and therefore * didn't trigger the select() function in X11_waitforinput()= =2E * Switching to unbuffered input solved this (although I don'= t * really like this solution 23 Jan 2002 (joze) */ setvbuf(stdin, (char *) 0, _IONBF, 0); Commenting out this one setvbuf() line solves 99% of the=20 problem in my tests using the awk script below. =20 With the setvbuf() in place, running the awk script causes the first 120+ plot commands to be lost in transit!!!!!! Without the setvbuf() command, only a single character is dropped - the first one following the first plot command. Before proceeding any further, I'd like to hear more detail from=20 Johannes about what problem this line was originally fixing. I have not noticed any dropped paste events or mouse clicks, but I may not be testing the right combination of events. It would also be good to hear from Petr or some other Octave user as to whether removing the setvbuf() line also fixes things in Octave.=20 My test awk script: BEGIN { gp=3D"./gnuplot" print "set term post" |gp print "set mouse" |gp print "set term x11" |gp for (k=3D1; k<500; k++) { print "reset"|gp print "plot x*x*" k |gp } } On Friday 10 October 2003 00:57, Petr Mikulik wrote: > > This Octave script may show the error earlier than the awk script: > > gset mouse > #do_print=3D1; > do_print=3D0; > > x=3D1:600; > y=3Dsin(x/3); > if do_print > gset term post lw 2 'Helvetica' 16 > gset out 'gpbug.ps' > end > > for k=3D1:30 > gset grid > title(sprintf('loop %i',k)) > plot(x*1e-3,y,';curve;') > replot > end > > if do_print > gset out > gset term pop > end > > --- > Petr Mikulik --=20 Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Box 357742 University of Washington, Seattle, WA 98195 |
From: Hans-Bernhard B. <br...@ph...> - 2003-10-22 12:02:54
|
On Wed, 22 Oct 2003, Petr Mikulik wrote: > On my machine, the 2 patches pass the two problems. However, there is a new > one: the Octave script below works differently whether the first Octave > command was "gset mouse" That's not at all new. That's exactly the problem that patch by Johannes was made to fix, in the first place: quick cut-n-paste with mousing on will loose large quantities of input and find them again as soon as you press a key. We're running in circles, here. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
From: Ethan M. <merritt@u.washington.edu> - 2003-10-22 16:58:27
|
On Wednesday 22 October 2003 04:04, Hans-Bernhard Broeker wrote: > On Wed, 22 Oct 2003, Petr Mikulik wrote: > > On my machine, the 2 patches pass the two problems. However, there is > > a new one: the Octave script below works differently whether the firs= t > > Octave command was "gset mouse" > > That's not at all new. That's exactly the problem that patch by > Johannes was made to fix, in the first place: quick cut-n-paste with > mousing on will loose large quantities of input and find them again as > soon as you press a key. So now we have a problem: octave scripts only work with the call to setvbuf(), while awk scripts only work without it. Octave is likely t= he more important application, and anyway people have been using the setvbuf() version for almost 2 years now. So we should leave the default the way it is. However, in case someone does want to use an awk script, perhaps there could be an option =09set mouse [no]buffered The default would be nobuffered, implemented by the existing call to setvbuf(). Specifying 'set mouse buffered' instead would bypass the call to setvbuf() and allow awk to work.=20 Would that be an acceptable work-around? --=20 Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Box 357742 University of Washington, Seattle, WA 98195 |
From: Daniel J S. <dan...@ie...> - 2003-10-23 21:59:55
|
Here is an observation in x11.trm that technically isn't a bug, but there is a small issue with consistency. I'm working on a short patch right now that highlights this issue. I'm debating a work around but it might be nice for the list to think whether a small alteration should be made for consistency, in which case I wouldn't have to do a work around. If one starts up gnuplot and issues a set term x11 3 the X11_ipc to gplt_x11 is not valid yet. That means that anything in the X11_options() routine that checks if X11_ipc is valid will not send information to gplt_x11 at that point in time. There currently is some code there, but it has no real effect because what would have been sent over is something saved internal to x11.trm code and gets resent. (You can probably guess I'd like to put something there that won't be saved necessarily. But don't let that sway you, I'm arguing consistency here.) Once something is plotted, say plot sin(x) X11_ipc is up and running and all things are hunky dory. So, the consistency issue... The ramification of the above is that set term x11 3 will cause the x11 window to appear on the desktop, _unless no plots have been created yet_. In other words, from a fresh invocation set term x11 3 creates no window. But plot sin(x) set term x11 3 creates _two_ windows. Any comments on this? Thanks, Dan |
From: Petr M. <mi...@ph...> - 2003-10-29 10:08:17
|
> So now we have a problem: octave scripts only work with the call > to setvbuf(), while awk scripts only work without it. Octave is likely the > more important application, and anyway people have been using the > setvbuf() version for almost 2 years now. So we should leave the > default the way it is. I.e., there are some applications which call setvbuf(gp,NULL,_IOLBF,0); or do fflush(gp) after each command, and those which don't. Fortunately, interactive programs should not be affected unless they "set mouse" explicitly. However, this applies only to X11 terminal. I think it would be worth to add some text about the necessity of using setvbuf(f,NULL,_IOLBF,0); /* set unbuffered output */ into "help x11_mouse". > However, in case someone does want to use an awk script, > perhaps there could be an option > set mouse [no]buffered > The default would be nobuffered, implemented by the existing call > to setvbuf(). Specifying 'set mouse buffered' instead would bypass > the call to setvbuf() and allow awk to work. > > Would that be an acceptable work-around? Isn't this just X11 specific? Does it set both stdin/stdout to application and to terminal to non-buffer, or only for one end? Maybe, in the next fool-proof reincarnation of X11 terminal, it would be worth to do it like in gnuplot for OS/2 -- named pipe terminal->gnuplot, with gnuplot having a thread waiting for pipe events (or semaphores + shared memory). --- Petr Mikulik |
From: Daniel J S. <dan...@ie...> - 2003-10-23 17:38:41
|
Daniel J Sebald wrote: > In other words, from a fresh invocation > > set term x11 3 > > creates no window. But > > plot sin(x) > set term x11 3 > > creates _two_ windows. You are probably wondering what I mean because the current version doesn't do this, as I just realized. What I am speaking of the system's behavior after an alteration to the 'N' option for changing the X11 window via "set term x11 5" [If you type the following, you'll notice you are unable to resize the first plot... that should be fixed at some point. plot sin(x) set term x11 4 {try resizing first plot}] I guess the question boils down to should the command set term x11 7 cause an empty X11 window to appear on the desktop if it didn't already exist? Or should it be until after something is actually plotted to the window that it appears on the desktop? Dan -- Dan Sebald email: daniel . sebald @ ie ee . o rg URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/ |
From: Daniel J S. <dan...@ie...> - 2003-10-23 21:49:19
|
My original message must have been lost by SF, but I don't think it needs resending to clarify the issue. The points up to this point are 1) I think the problem of x11 windows getting stuck when only a "set term x11 #" should be fixed at some point. Nobody needs to change this, I can do so with Petr's help. But, feel free to comment. 2) If you think the above problem should be modified, do you feel that a) graphics windows should not appear until something is actually plotted to them b) graphics windows should _always_ appear when "set term x11 ..." is entered c) the first x11 window should not appear until something is actually plotted, but after that "set term x11 ..." will cause a new blank window to appear. With regard to 2, note that if one types "set output 'name'" followed by no plot commands, but then "set output", the file 'name' will be created. Is there an analogy here between a file and a window? The next point is 3) Looking at the X11_options() in x11.trm it is very similar to other parsing/interpretting schemes, however it doesn't have the many checks for repeated entry, valid entry, etc. Some commands are sent to gplt_x11 even before the end of parsing. So even if there is something bogus in the "set term x11" command, a portion of the command could have been processed. Should it do that? Or should it wait until it is known that the whole command is valid? For example, "set term x11 3 "TimesFont"" will show an error message because "font" is missing before the font name, but it will in fact change the x11 window to 3. If you feel point 2b above should be the case, then "set term x11 1 2 noraise" where someone mistypes the 12 will cause window 1 and window 2 to show on the desktop. In fact, as it currently is "set term x11 1 2 noraise reset 3 4 raise" is fine by Gnuplot. Should there be some checks to prevent this kind of thing? Dan Daniel J Sebald wrote: > > > Daniel J Sebald wrote: > >> In other words, from a fresh invocation >> >> set term x11 3 >> >> creates no window. But >> >> plot sin(x) >> set term x11 3 >> >> creates _two_ windows. > > > > You are probably wondering what I mean because the > current version doesn't do this, as I just realized. What > I am speaking of the system's behavior after an alteration > to the 'N' option for changing the X11 window via > > "set term x11 5" > > [If you type the following, you'll notice you are unable > to resize the first plot... that should be fixed at some > point. > > plot sin(x) > set term x11 4 > {try resizing first plot}] > > I guess the question boils down to should the command > > set term x11 7 > > cause an empty X11 window to appear on the desktop > if it didn't already exist? Or should it be until after something > is actually plotted to the window that it appears on the > desktop? > > Dan > -- Dan Sebald email: daniel . sebald @ ie ee . o rg URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/ |
From: Daniel J S. <dan...@ie...> - 2003-10-24 10:25:28
|
Ethan A Merritt wrote: >garbage in -> garbage out. >But a warning message would be OK. At least in the above >case it echoes back the actual state that was set. In your >earlier example "set term X11 3 'Times-Roman'" it failed to >echo back the state. It is that failure that I consider a bug, >not the fact that it accepted the 3 but rejected the font. > And what of "reset"? I think as it is "set term x11 reset noraise 19" is different than "set term x11 noraise 19 reset" because the order of appearance matters. I think it would be better that options have a precedence say "reset" (first) number (second) order of remaining options doesn't really matter That is, the user would be able to enter them in any order but they will be processed in order above. That would be changing Gnuplot's behavior a bit, but I don't think users have come to realize that order matters in the x11 options string. Dan -- Dan Sebald email: daniel . sebald @ ie ee . o rg URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/ |
From: Petr M. <mi...@ph...> - 2003-10-24 17:20:44
|
> >But a warning message would be OK. At least in the above > >case it echoes back the actual state that was set. In your > >earlier example "set term X11 3 'Times-Roman'" it failed to > >echo back the state. It is that failure that I consider a bug, > >not the fact that it accepted the 3 but rejected the font. I think X11 should be consistent with other terminals. So: any order of options allowed; nothing drawn (and no window open) until (s)plot; it should not do strange things with (mistakenly) duplicating options. --- Petr Mikulik |
From: Petr M. <mi...@ph...> - 2003-10-21 10:09:25
|
> Petr Mikulik and John Bollinger alerted me to the recurrence of an > old problem. When (1) gnuplot is run from a script and (2) mouse > input is enabled, then characters are dropped from the input > stream. > > I initially thought this was something I had broken with my X11 > initialization patches (revisions 1.71 - 1.74 of term/x11.trm). > But after backing these out altogether, I still see the problem, > although possibly with a lower frequency. > > After much poking about in the source code, I came > across this bit in term/x11.trm > > /* apparently multi-character inputs like escape sequences > * but also mouse-pasted text got buffered and therefore > * didn't trigger the select() function in X11_waitforinput(). > * Switching to unbuffered input solved this (although I don't > * really like this solution 23 Jan 2002 (joze) */ > setvbuf(stdin, (char *) 0, _IONBF, 0); > > Commenting out this one setvbuf() line solves 99% of the > problem in my tests using the awk script below. > > With the setvbuf() in place, running the awk script causes the > first 120+ plot commands to be lost in transit!!!!!! > > Without the setvbuf() command, only a single character is > dropped - the first one following the first plot command. > > It would also be good to hear from Petr or some other Octave > user as to whether removing the setvbuf() line also fixes > things in Octave. I've tried it with Octave, but there is no change with or without setvbuf. Gnuplot mostly looses the first character. Probably, there was a thread on this topic around 23 Jan 2002, where Johanness submitted his patch ...? What I can confirm, is that I have this problem with gnuplot cvs'ed on June 21 2003 and newer. And, in the version of 21.6.2003, commenting out the setvbuf command, only the first char written is lost; otherwise many of them. --- Petr Mikulik |
From: Ethan M. <merritt@u.washington.edu> - 2003-10-21 18:55:17
Attachments:
ipc_lock.patch
setvbuf.patch
|
On Tuesday 21 October 2003 02:36, Petr Mikulik wrote: > Ethan Merritt wrote> > > Commenting out this one setvbuf() line solves 99% of the > > problem in my tests using the awk script below. > > > > With the setvbuf() in place, running the awk script causes the > > first 120+ plot commands to be lost in transit!!!!!! > > > > Without the setvbuf() command, only a single character is > > dropped - the first one following the first plot command. > > I've tried it with Octave, but there is no change with or without > setvbuf. Gnuplot mostly looses the first character. Last night I built Octave 2.1.50 so that I could test this myself. What I found is that the Octave problem and the awk problem are not the same. The Octave problem can, I believe, be solved with the first patch attached below (ipc_lock.patch). This one causes X11_waitforinput() to refuse to read any more characters using getc(stdin) while it is waiting for a response from the mousing pipe.=20 This still leaves awk losing many lines of input, which is fixed only if I also remove the call to setvbuf() as in the second patch below (setvbuf.patch). Applying these two patches makes both the awk and octave test scripts run on my usual desktop machine under linux. =20 I've tested both with gnu libreadline and with the builtin readline. But I have not yet tested on other machines, and I would not like to commit either patch to CVS without more extensive testing. =20 In particular I am concerned that if the response from the mouse pipe is lost altogether, then the first patch will cause gnuplot will hang. I need to add some sort of timeout or upper limit of attempts to read from the mouse pipe. --=20 Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Box 357742 University of Washington, Seattle, WA 98195 |
From: Daniel J S. <dan...@ie...> - 2003-10-21 19:48:48
|
I haven't been following too closely, but here's an observation that may or may not be related. I've notice for a while that if one uses the mouse to copy text to Gnuplot's command line (i.e., the "clipboard" method, or whatever) that whenever there is a "pause -1", the first character after the pause is always deleted. That is, it will interpret all lines up to "pause -1" correctly, then wait for the keyboard to hit, then the first character after the keyboard hit is lost. If it is a non-whitespace character, Gnuplot will have a syntax error. Dan Ethan Merritt wrote: >On Tuesday 21 October 2003 02:36, Petr Mikulik wrote: > > >>Ethan Merritt wrote> >> >> >>>Commenting out this one setvbuf() line solves 99% of the >>>problem in my tests using the awk script below. >>> >>>With the setvbuf() in place, running the awk script causes the >>>first 120+ plot commands to be lost in transit!!!!!! >>> >>>Without the setvbuf() command, only a single character is >>>dropped - the first one following the first plot command. >>> >>> >>I've tried it with Octave, but there is no change with or without >>setvbuf. Gnuplot mostly looses the first character. >> >> > >Last night I built Octave 2.1.50 so that I could test this >myself. What I found is that the Octave problem and the awk >problem are not the same. > >The Octave problem can, I believe, be solved with the first >patch attached below (ipc_lock.patch). This one causes >X11_waitforinput() to refuse to read any more characters >using getc(stdin) while it is waiting for a response from the >mousing pipe. > >This still leaves awk losing many lines of input, which is >fixed only if I also remove the call to setvbuf() as in the >second patch below (setvbuf.patch). > >Applying these two patches makes both the awk and octave >test scripts run on my usual desktop machine under linux. > >I've tested both with gnu libreadline and with the builtin >readline. But I have not yet tested on other machines, and >I would not like to commit either patch to CVS without more >extensive testing. > >In particular I am concerned that if the response from the >mouse pipe is lost altogether, then the first patch will cause >gnuplot will hang. I need to add some sort of timeout or >upper limit of attempts to read from the mouse pipe. > > > |
From: Ethan M. <merritt@u.washington.edu> - 2003-10-21 20:01:36
|
On Tuesday 21 October 2003 13:00, Daniel J Sebald wrote: > I haven't been following too closely, but here's an observation > that may or may not be related. I've notice for a while that if > one uses the mouse to copy text to Gnuplot's command line > (i.e., the "clipboard" method, or whatever) that whenever there > is a "pause -1", the first character after the pause is always > deleted. OK. I'll chase after that one also. Neither of my current patches fixes it. --=20 Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Box 357742 University of Washington, Seattle, WA 98195 |
From: Petr M. <mi...@ph...> - 2003-10-22 08:15:58
|
> The Octave problem can, I believe, be solved with the first > patch attached below (ipc_lock.patch). This one causes > X11_waitforinput() to refuse to read any more characters > using getc(stdin) while it is waiting for a response from the > mousing pipe. > > This still leaves awk losing many lines of input, which is > fixed only if I also remove the call to setvbuf() as in the > second patch below (setvbuf.patch). On my machine, the 2 patches pass the two problems. However, there is a new one: the Octave script below works differently whether the first Octave command was "gset mouse" #gset mouse n=30; x=linspace(100,5000,30); y=x+100; title('first plot') plot(x,y); title('second plot') plot(1-x,log10(y),x,log10(y),'b*'); title('third plot') plot(1000-x,1000-y,x,y,'g*'); If there is no "gset mouse", then it displays all 3 plots. If there is "gset mouse", it displays only the 1st plot, and waits until you do whatever "gset ..." command -- then it displays all the rest. Seems like something is waiting in the buffer. --- Petr Mikulik |
From: Petr M. <mi...@ph...> - 2003-10-27 15:10:40
|
> > > With the setvbuf() in place, running the awk script causes the > > > first 120+ plot commands to be lost in transit!!!!!! > > > > > > Without the setvbuf() command, only a single character is > > > dropped - the first one following the first plot command. > > > > I've tried it with Octave, but there is no change with or without > > setvbuf. Gnuplot mostly looses the first character. > > Last night I built Octave 2.1.50 so that I could test this > myself. What I found is that the Octave problem and the awk > problem are not the same. > > The Octave problem can, I believe, be solved with the first > patch attached below (ipc_lock.patch). This one causes > X11_waitforinput() to refuse to read any more characters > using getc(stdin) while it is waiting for a response from the > mousing pipe. > > This still leaves awk losing many lines of input, which is > fixed only if I also remove the call to setvbuf() as in the > second patch below (setvbuf.patch). > > Applying these two patches makes both the awk and octave > test scripts run on my usual desktop machine under linux. > > I've tested both with gnu libreadline and with the builtin > readline. But I have not yet tested on other machines, and > I would not like to commit either patch to CVS without more > extensive testing. > > In particular I am concerned that if the response from the > mouse pipe is lost altogether, then the first patch will cause > gnuplot will hang. I need to add some sort of timeout or > upper limit of attempts to read from the mouse pipe. I'd a look to the patch of June 21 which made the break; even though I don't understand it, I've found that commenting out the "X11_waitforinput();" call does not produce the forgetting-pipe error: /* Force default font at start of plot */ #ifdef USE_MOUSE /* EAM June 2003 - Flush the set font command through the pipe */ /* to gnuplot_x11, then wait for it to return the resulting */ /* font size information (v_char and h_char). */ if (!default_font_size_known) { X11_set_default_font(); FFLUSH(); X11_waitforinput(); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ default_font_size_known = TRUE; } #else X11_set_default_font(); #endif X11_set_font(""); } Does that command have to be there? Petr |
From: Daniel J S. <dan...@ie...> - 2003-10-27 19:48:57
|
Petr Mikulik wrote: >I'd a look to the patch of June 21 which made the break; even though I don't >understand it, I've found that commenting out the "X11_waitforinput();" call >does not produce the forgetting-pipe error: > > > /* Force default font at start of plot */ >#ifdef USE_MOUSE > /* EAM June 2003 - Flush the set font command through the pipe */ > /* to gnuplot_x11, then wait for it to return the resulting */ > /* font size information (v_char and h_char). */ > if (!default_font_size_known) { > X11_set_default_font(); > FFLUSH(); > X11_waitforinput(); >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > default_font_size_known = TRUE; > } >#else > X11_set_default_font(); >#endif > X11_set_font(""); >} > > >Does that command have to be there? > My guess would be "yes" if the size of the font is to be correct when used in Gnuplot formatting. That is some strange code, however. Does anyone know what the basic concept is here? Is this using a single pipe to have traffic in both directions? If so, I might speculate that x11.trm is sending information through the pipe then looking to get something back perhaps grabbing characters that it just sent into the pipe because gplt_x11 hasn't yet pulled them out.(????) Maybe a handshaking scheme is needed. Perhaps x11.trm should send a command through the pipe. The gplt_x11 font command doesn't send stuff immediately but waits for another special character to be sent. On the other end, x11.trm first sits waiting for the pipe to be completely empty. Then it knows that gplt_x11 has received the font command and is waiting to send something back. x11.trm then sends the special character. But still that doesn't seem fool proof, unless there is some way for x11.trm to know the pipe has grown bigger than the one character it sent, say. That might be a way of knowing that what is in the pipe came from gplt_x11 and not its own self. Dan -- Dan Sebald email: daniel . sebald @ ie ee . o rg URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/ |
From: Ethan M. <merritt@u.washington.edu> - 2003-10-27 20:29:14
|
On Monday 27 October 2003 07:04, Petr Mikulik wrote: > I'd a look to the patch of June 21 which made the break; even though I > don't understand it, I've found that commenting out the > "X11_waitforinput();" call does not produce the forgetting-pipe error: > > /* Force default font at start of plot */ > #ifdef USE_MOUSE > /* EAM June 2003 - Flush the set font command through the pipe */ > /* to gnuplot_x11, then wait for it to return the resulting */ > /* font size information (v_char and h_char). */ > if (!default_font_size_known) { > X11_set_default_font(); > FFLUSH(); > X11_waitforinput(); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > default_font_size_known =3D TRUE; > } > #else > X11_set_default_font(); > #endif > X11_set_font(""); > } > > > Does that command have to be there? Well yes. That is the whole point of the excercise. The idea is to give X11 a chance to initialize the window data structure and send back sizing and font information before proceeding. That way the plot can be laid out correctly. Daniel J Sebald <dan...@ie...> wrote> >That is some strange code, however. =20 I will choose to take that as a compliment :-) >Does anyone know what the basic concept is here? See above.=20 > Maybe a handshaking scheme is needed. Perhaps x11.trm Handshaking didn't help. What was needed was an interlock. I added that to CVS on 23 Oct. You should not (I hope!!) be seeing problems with Octave any more. If you are then=20 please send me another sample script that generates the error. As I previously noted, there is a separate problem with buffered/unbuffered input streams. Awk is not happy=20 with the unbuffered stream. I don't know why, and I don't know what other scripting environments might suffer from the same problem. --=20 Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Box 357742 University of Washington, Seattle, WA 98195 |
From: Daniel J S. <dan...@ie...> - 2003-10-27 21:55:44
|
Ethan Merritt wrote: >Daniel J Sebald <dan...@ie...> wrote> > > >>That is some strange code, however. >> >> > >I will choose to take that as a compliment :-) > Why, of course I meant it that way. :-) >>Maybe a handshaking scheme is needed. Perhaps x11.trm >> >> > >Handshaking didn't help. > Yes, sometimes it just pushes the problem to some other obscure location. Dan -- Dan Sebald email: daniel . sebald @ ie ee . o rg URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/ |