Menu
▾
▴
gnuplot-beta
|
From: <tim...@en...> - 2006-07-25 17:24:39
|
Hi, I am working on the bug #1527701, and I need some advice. The bug comes from the current implementation of "persist" in the wxt=20 terminal. This option is used by external programs, like maxima, to control=20 gnuplot. They send their commands through a pipe or a file or whatever,=20 they let gnuplot exit at the end of the commands, but as they want the=20 plot windows to stay open, they use "persist". The X11 terminal lives in a separate process, so for this terminal the=20 "persist" option makes gnuplot main process to exit while the=20 gnuplot_x11 stays alive until the user closes all the windows. However, the wxt terminal is not a separate process. It lives in gnuplot=20 main executable, so when gnuplot exits the plot windows can't but be=20 closed. That's why I implemented "persist" so that gnuplot won't exit=20 until all wxWidgets windows are closed. But obviously that's not what=20 maxima (and probably others, I have not tried octave) wants. I thought=20 about using fork() to duplicate the process, then close the parent=20 process so that maxima and friends will be happy, and let the child=20 process take care of the windows. Although it sounds nice, it is=20 actually dangerous as 1) fork() is not portable, 2) there are a bunch of=20 undetermined behaviours when using fork() in a multithreaded application=20 (the wxWidgets main loop lives in a separate thread, so gnuplot is=20 multithreaded in this context) or an application using X. I'm stuck. Do you have any idea to implement "persist" in this context ? Best regards, Timoth=C3=A9e P.S. : I tend to think that "persist" was a bad idea in the first place=20 : why wouldn't maxima simply leave gnuplot alone and continue its work ?=20 But I don't want to break any established behaviour either... |
|
From: <br...@ph...> - 2006-07-25 20:56:51
|
Timoth=C3=A9e Lecomte wrote: > This option is used by external programs, like maxima, to control= =20 > gnuplot. They send their commands through a pipe or a file or whate= ver,=20 > they let gnuplot exit at the end of the commands, but as they want = the=20 > plot windows to stay open, they use "persist". The problem is that these programs are abusing persist. Persist isn'= t useful for external programs that will keep on running and doing othe= r things while gnuplot sits there. They should either keep gnuplot, an= d=20 their pipe to it, open, or not care about whether gnuplot terminates= =20 itself or not. > P.S. : I tend to think that "persist" was a bad idea in the first p= lace=20 It wasn't. But Maxima shouldn't be using it. |
|
From: <tim...@en...> - 2006-07-25 21:24:46
|
Hans-Bernhard Br=C3=B6ker wrote: > Timoth=C3=A9e Lecomte wrote: > >> This option is used by external programs, like maxima, to control=20 >> gnuplot. They send their commands through a pipe or a file or=20 >> whatever, they let gnuplot exit at the end of the commands, but as=20 >> they want the plot windows to stay open, they use "persist". > > The problem is that these programs are abusing persist. Persist isn't > useful for external programs that will keep on running and doing other > things while gnuplot sits there. They should either keep gnuplot, and=20 > their pipe to it, open, or not care about whether gnuplot terminates=20 > itself or not. So do you think the implementation for the wxWidgets terminal is=20 satisfying (i.e. gnuplot's interactive command line stops, but gnuplot=20 doesn't exist until all windows are closed) ? If yes, I will file a bug against maxima then. > >> P.S. : I tend to think that "persist" was a bad idea in the first plac= e=20 > > It wasn't. But Maxima shouldn't be using it. Ok. Best regards, Timoth=C3=A9e |
|
From: <br...@ph...> - 2006-07-26 00:44:10
|
Timoth=C3=A9e Lecomte wrote: > So do you think the implementation for the wxWidgets terminal is= =20 > satisfying (i.e. gnuplot's interactive command line stops, but gnup= lot=20 > doesn't exist until all windows are closed) ? Yes. It's the only sensible implementation possible for a=20 single-process build of gnuplot. wgnuplot, e.g., behaves the same wa= y. |
|
From: <tim...@en...> - 2006-07-26 00:41:02
|
Hans-Bernhard Br=C3=B6ker wrote: > Timoth=C3=A9e Lecomte wrote: > >> So do you think the implementation for the wxWidgets terminal is=20 >> satisfying (i.e. gnuplot's interactive command line stops, but=20 >> gnuplot doesn't exist until all windows are closed) ? > > Yes. It's the only sensible implementation possible for a=20 > single-process build of gnuplot. wgnuplot, e.g., behaves the same way. > > Ok, bug filed for maxima here : =20 http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1528658&grou= p_id=3D4933&atid=3D104933 Timoth=C3=A9e |
|
From: Daniel J S. <dan...@ie...> - 2006-07-26 17:48:36
|
Timoth=C3=A9e Lecomte wrote: > Hi, >=20 > I am working on the bug #1527701, and I need some advice. >=20 > The bug comes from the current implementation of "persist" in the wxt=20 > terminal. >=20 > This option is used by external programs, like maxima, to control=20 > gnuplot. They send their commands through a pipe or a file or whatever,= =20 > they let gnuplot exit at the end of the commands, but as they want the=20 > plot windows to stay open, they use "persist". They issue the commands for a plot and then close gnuplot? Well it shoul= dn't be done that way. That is not what persist is intended for. The pr= ogram should keep the pipe open. Octave opens gnuplot and holds onto the pipe. (If I recall, it uses a fo= rk... The person that oversees Octave is a very good and organized progr= ammer.) I can make a guess as to what may be going on here. We've had this discu= ssion many times in the past, which is the fact that gnuplot only retains= information about a single plot. If there are several X windows open, s= till it is only the information about the most recent plot that is availa= ble. Hence, you'll see that the mouse functions only work for the most r= ecent X plot. Well, I know that for Octave, John decided to open a new instance of gnup= lot for every plot created. That way, ever plot in Octave does have its = information retained. John figured that gnuplot was a rather small progr= am so not much harm done. Maybe Maxima people have the same philosophy to get multiple windows, onl= y they figure why keep so many versions of gnuplot around? It's wasting = memory. If Maxima had a multiple window version of the terminal (I assum= e we're talking of Windows here, no?) then perhaps they would be willing = to change their program. Dan |
|
From: <tim...@en...> - 2006-07-26 00:29:23
|
Daniel J Sebald wrote: > Timoth=C3=A9e Lecomte wrote: >> >> The bug comes from the current implementation of "persist" in the wxt=20 >> terminal. >> >> This option is used by external programs, like maxima, to control=20 >> gnuplot. They send their commands through a pipe or a file or=20 >> whatever, they let gnuplot exit at the end of the commands, but as=20 >> they want the plot windows to stay open, they use "persist". > > They issue the commands for a plot and then close gnuplot? Well it=20 > shouldn't be done that way. That is not what persist is intended=20 > for. The program should keep the pipe open. > > Octave opens gnuplot and holds onto the pipe. (If I recall, it uses a=20 > fork... The person that oversees Octave is a very good and organized=20 > programmer.) That's why I read once that for his own work he is (was?) actually not=20 using octave's plot() functions, but writes a makefile that would run a=20 gnuplot script when the data changes ;-) > > I can make a guess as to what may be going on here. We've had this=20 > discussion many times in the past, which is the fact that gnuplot only=20 > retains information about a single plot. If there are several X=20 > windows open, still it is only the information about the most recent=20 > plot that is available. Hence, you'll see that the mouse functions=20 > only work for the most recent X plot. And worse, with the "persist" implementation in the X11 terminal, you=20 lose all zooming capabilities once gnuplot has exited. That's an additional argument that I forgor to mention if my maxima bug=20 report... > > Well, I know that for Octave, John decided to open a new instance of=20 > gnuplot for every plot created. That way, ever plot in Octave does=20 > have its information retained. John figured that gnuplot was a rather=20 > small program so not much harm done. > > Maybe Maxima people have the same philosophy to get multiple windows,=20 > only they figure why keep so many versions of gnuplot around? It's=20 > wasting memory. I don't really get what you mean here. > If Maxima had a multiple window version of the terminal (I assume=20 > we're talking of Windows here, no?) then perhaps they would be willing=20 > to change their program. We are talking about UNIX here. Under Windows, maxima does something=20 else (I think it is using the png terminal, and copy the image to their=20 home-made gui). Timoth=C3=A9e |
|
From: Daniel J S. <dan...@ie...> - 2006-07-28 03:32:30
|
Timoth=C3=A9e Lecomte wrote: >> I can make a guess as to what may be going on here. We've had this=20 >> discussion many times in the past, which is the fact that gnuplot only= =20 >> retains information about a single plot. If there are several X=20 >> windows open, still it is only the information about the most recent=20 >> plot that is available. Hence, you'll see that the mouse functions=20 >> only work for the most recent X plot. >=20 > And worse, with the "persist" implementation in the X11 terminal, you=20 > lose all zooming capabilities once gnuplot has exited. > That's an additional argument that I forgor to mention if my maxima bug= =20 > report... OK, before that discussion gets reopened, there are two approaches as to = how this could have been programmed. One would be to zoom what is in the= gnuplot_x11 memory buffer. I.e., make the existing plot bigger so it lo= oks exactly the same only one is looking at a portion of the plot. Or, a= second would be to send a command back to gnuplot with a new range and r= eplot. Consensus is the latter, and of course that means zooming can't b= e done once gnuplot is closed. >> Well, I know that for Octave, John decided to open a new instance of=20 >> gnuplot for every plot created. That way, ever plot in Octave does=20 >> have its information retained. John figured that gnuplot was a rather= =20 >> small program so not much harm done. >> >> Maybe Maxima people have the same philosophy to get multiple windows,=20 >> only they figure why keep so many versions of gnuplot around? It's=20 >> wasting memory. >=20 > I don't really get what you mean here. In Octave, if there are 20 windows open, it means there are twenty versio= n of gnuplot running. If Maxima uses the same strategy, i.e., to open a = new version of gnuplot for every plot, they may have figured "Why do we n= eed gnuplot still running for each of these windows? We've got our plots= , let's keep those and get rid of the gnuplot executables." I'm not sayi= ng that is what they did, but could have been their thinking. > We are talking about UNIX here. Under Windows, maxima does something=20 > else (I think it is using the png terminal, and copy the image to their= =20 > home-made gui). Well, then I don't know what they are thinking. Dan |
|
From: <tim...@en...> - 2006-07-27 22:34:21
|
Daniel J Sebald wrote: > Timoth=C3=A9e Lecomte wrote: >> Hi, >> >> I just tried the wxWidgets terminal with octave (2.1.73, not the last=20 >> development version though). >> >> Bad news : it uses "persist" too. > > Are you sure? I've never seen plots stay alive after Octave is=20 > closed. I've gone to the Octave source directory and grepped for=20 > "persist". I don't see it anywhere used as an option to gnuplot, and=20 > the line of code I see uses "gnuplot" as the default launch command. Hmm, looks like I have missed something. The "persist" option was indeed coming from the wxWidgets terminal=20 configuration dialog, not from octave. But my x11 terminal is also using "persist", and I can't find the=20 app-defaults file that could have caused that. Timoth=C3=A9e |
|
From: <tim...@en...> - 2006-07-27 22:58:36
|
Timoth=C3=A9e Lecomte wrote: > Daniel J Sebald wrote: > =20 >> >> I've never seen plots stay alive after Octave is=20 >> closed. I've gone to the Octave source directory and grepped for=20 >> "persist". I don't see it anywhere used as an option to gnuplot, and=20 >> the line of code I see uses "gnuplot" as the default launch command. >> =20 > Hmm, looks like I have missed something. > The "persist" option was indeed coming from the wxWidgets terminal=20 > configuration dialog, not from octave. > But my x11 terminal is also using "persist", and I can't find the=20 > app-defaults file that could have caused that. > =20 Well, I reinstalled gnuplot, and now it no longer uses "persist".=20 Something must have been messed up in the app-defaults. So no problem with octave. Sorry for the noise. Best regards, Timoth=C3=A9e |
|
From: <tim...@en...> - 2006-07-27 21:35:41
|
Hi, I just tried the wxWidgets terminal with octave (2.1.73, not the last=20 development version though). Bad news : it uses "persist" too. octave uses a pipe to talk with gnuplot, and keeps it open through the=20 whole octave session. The "persist" behaviour appears when you close=20 octave (by issuing "quit" at octave prompt). I guess the process goes=20 the following way : octave closes the pipe, gnuplot engages its exit=20 process, the wxWidgets says "hold on !" until all the windows are=20 closed, and ... octave waits for gnuplot to terminate, so you end up=20 with what looks like a frozen prompt until you realize that you have to=20 close the wxt window (you can also hit ctrl-c twice to force octave to=20 close). Like maxima, octave relies on the X11 "persist" behaviour. Ethan suggested two alternatives : - sending a fake signal SIGCHLD to octave, meaning "child process=20 terminated". I tried, and it does not work. octave does not wait for SIGC= HLD - mimic a 'bg' to gnuplot. Well, I don't know how to do that from=20 gnuplot, and I doubt it will actually work : since gnuplot's process is=20 still running, octave still waits for it. Do any of you have a miraculous idea, or should I report that to the=20 octave developers as I did for maxima ? Best regards, Timoth=C3=A9e |
|
From: <tim...@en...> - 2006-07-28 17:57:56
|
Dave Denholm wrote: > =20 >> - mimic a 'bg' to gnuplot. Well, I don't know how to do that from=20 >> gnuplot, and I doubt it will actually work : since gnuplot's process i= s=20 >> still running, octave still waits for it. >> >> Do any of you have a miraculous idea, or should I report that to the=20 >> octave developers as I did for maxima ? >> >> =20 > > gnuplot can fork(), then allow the parent to exit, leaving the child > continuing to run the same code in exactly the same state, but > detached. > =20 This won't work in my case, because the terminal is multithreaded and=20 fork() has undetermined behaviour with threads, and because exiting the=20 parent would close file and socket descriptors, thus closing the=20 connection to the X server. A workaround would be to close the GUI=20 thread and the windows before the fork() and to open them again in the=20 child, but I'm not sure maxima users would appreciate to see their=20 window disappearing and reappearing... Best regards, Timoth=E9e |
|
From: <tim...@en...> - 2006-08-01 23:29:07
|
Dave Denholm wrote: > Timoth=E9e Lecomte <tim...@en...> writes: > > =20 >> Dave Denholm wrote: >> =20 >>>> - mimic a 'bg' to gnuplot. Well, I don't know how to do that from >>>> gnuplot, and I doubt it will actually work : since gnuplot's >>>> process is still running, octave still waits for it. >>>> >>>> Do any of you have a miraculous idea, or should I report that to >>>> the octave developers as I did for maxima ? >>>> >>>> >>>> =20 >>> gnuplot can fork(), then allow the parent to exit, leaving the child >>> continuing to run the same code in exactly the same state, but >>> detached. >>> >>> =20 >> This won't work in my case, because the terminal is multithreaded and >> fork() has undetermined behaviour with threads, >> =20 > > Not really... you can install fork handlers (assuming pthreads). But > yes, it all becomes horribly complicated. See pthread_atfork() > =20 Well, you're right, especially when you say "horribly complicated" ;) > > =20 >> and because exiting >> the parent would close file and socket descriptors, thus closing the >> connection to the X server. >> =20 > > No, the child inherits the open files. > =20 It does, but when the parent calls exit(), the corresponding files are=20 closed. There is a workaround : _exit(), but again, I think it becomes=20 too complicated and less portable. > =20 >> A workaround would be to close the GUI >> thread and the windows before the fork() and to open them again in the >> child, but I'm not sure maxima users would appreciate to see their >> window disappearing and reappearing... >> >> =20 > > > One other option would always be to immediately fork, but keep the > parent around as a dummy process (just so that the original process > knows it's still active). So all the work would happen in the child. > In effect, code it as if you always detach, and then keep the parent > alive as a workaround to stop the original process thinking the child > has exited until the child chooses to detach. > =20 I wonder what happens regarding the command line then. Anyway, I would *really* prefer not to have to play with fork() just to=20 satisfy a particular use case that is not written word for word=20 anywhere. I am sure the maxima folks will find a nice workaround=20 (there's already one workaround: defining a simple shell wrapper that=20 launches gnuplot in the background) (I would be glad to help them if=20 only it wouldn't be coded in lisp...). Timoth=E9e |
|
From: Daniel J S. <dan...@ie...> - 2006-07-27 22:00:59
|
Timoth=C3=A9e Lecomte wrote: > Hi, >=20 > I just tried the wxWidgets terminal with octave (2.1.73, not the last=20 > development version though). >=20 > Bad news : it uses "persist" too. Are you sure? I've never seen plots stay alive after Octave is closed. = I've gone to the Octave source directory and grepped for "persist". I do= n't see it anywhere used as an option to gnuplot, and the line of code I = see uses "gnuplot" as the default launch command. Please use 2.9.x series as reference. There are major changes in store f= or Octave. If you must compile, I know, it takes a while. >=20 > octave uses a pipe to talk with gnuplot, and keeps it open through the=20 > whole octave session. The "persist" behaviour appears when you close=20 > octave (by issuing "quit" at octave prompt). I guess the process goes=20 > the following way : octave closes the pipe, gnuplot engages its exit=20 > process, the wxWidgets says "hold on !" until all the windows are=20 > closed, and ... octave waits for gnuplot to terminate, so you end up=20 > with what looks like a frozen prompt until you realize that you have to= =20 > close the wxt window (you can also hit ctrl-c twice to force octave to=20 > close). >=20 > Like maxima, octave relies on the X11 "persist" behaviour. I don't think so. >=20 > Ethan suggested two alternatives : > - sending a fake signal SIGCHLD to octave, meaning "child process=20 > terminated". I tried, and it does not work. octave does not wait for SI= GCHLD > - mimic a 'bg' to gnuplot. Well, I don't know how to do that from=20 > gnuplot, and I doubt it will actually work : since gnuplot's process is= =20 > still running, octave still waits for it. >=20 > Do any of you have a miraculous idea, or should I report that to the=20 > octave developers as I did for maxima ? Talk directly with John Eaton. He's the only one who will know. But I'd= say it would be best to compile the latest version and come up with a pa= tch that works with what you are trying to accomplish. (The file __gnupl= ot_raw__.cc contains what you are looking for.) Dan |
|
From: Dave D. <dde...@es...> - 2006-07-28 09:08:18
|
Timoth=E9e Lecomte <tim...@en...> writes: > Ethan suggested two alternatives : > - sending a fake signal SIGCHLD to octave, meaning "child process=20 > terminated". I tried, and it does not work. octave does not wait for > SIGCHLD SIGCHILD informs a parent that a child has died : if they were to do a wait(), they would expect it to complete immediately, but it would block. So that would be a bad idea I think. > - mimic a 'bg' to gnuplot. Well, I don't know how to do that from=20 > gnuplot, and I doubt it will actually work : since gnuplot's process is=20 > still running, octave still waits for it. > > Do any of you have a miraculous idea, or should I report that to the=20 > octave developers as I did for maxima ? > gnuplot can fork(), then allow the parent to exit, leaving the child continuing to run the same code in exactly the same state, but detached. dd --=20 Dave Denholm <dde...@es...> http://www.esmertec= .com |
|
From: Dave D. <dde...@es...> - 2006-07-31 09:14:33
|
Timoth=E9e Lecomte <tim...@en...> writes: > Dave Denholm wrote: >> >>> - mimic a 'bg' to gnuplot. Well, I don't know how to do that from >>> gnuplot, and I doubt it will actually work : since gnuplot's >>> process is still running, octave still waits for it. >>> >>> Do any of you have a miraculous idea, or should I report that to >>> the octave developers as I did for maxima ? >>> >>> >> >> gnuplot can fork(), then allow the parent to exit, leaving the child >> continuing to run the same code in exactly the same state, but >> detached. >> > This won't work in my case, because the terminal is multithreaded and > fork() has undetermined behaviour with threads, Not really... you can install fork handlers (assuming pthreads). But yes, it all becomes horribly complicated. See pthread_atfork() > and because exiting > the parent would close file and socket descriptors, thus closing the > connection to the X server. No, the child inherits the open files. > A workaround would be to close the GUI > thread and the windows before the fork() and to open them again in the > child, but I'm not sure maxima users would appreciate to see their > window disappearing and reappearing... > One other option would always be to immediately fork, but keep the parent around as a dummy process (just so that the original process knows it's still active). So all the work would happen in the child. In effect, code it as if you always detach, and then keep the parent alive as a workaround to stop the original process thinking the child has exited until the child chooses to detach. dd --=20 Dave Denholm <dde...@es...> http://www.esmertec= .com |
|
From: Dave D. <dde...@es...> - 2006-08-02 09:02:06
|
Timoth=E9e Lecomte <tim...@en...> writes: >>>>> >>>> gnuplot can fork(), then allow the parent to exit, leaving the child >>>> continuing to run the same code in exactly the same state, but >>>> detached. >>> and because exiting >>> the parent would close file and socket descriptors, thus closing the >>> connection to the X server. >>> >> >> No, the child inherits the open files. >> > It does, but when the parent calls exit(), the corresponding files are > closed. There is a workaround : _exit(), but again, I think it becomes > too complicated and less portable. >> exit() can cause problems, but it doesn't close the files and sockets. Or at least, it closes the parent's handles, but the child's handles mean the underlying instance remains open. Parent exit() does cause stdio to get cleaned up, which can confuse things. I rather assumed that as soon as we started discussing fork() we were in a unix-only scenario. >>> A workaround would be to close the GUI >>> thread and the windows before the fork() and to open them again in the >>> child, but I'm not sure maxima users would appreciate to see their >>> window disappearing and reappearing... >>> >>> >> >> >> One other option would always be to immediately fork, but keep the >> parent around as a dummy process (just so that the original process >> knows it's still active). So all the work would happen in the child. >> In effect, code it as if you always detach, and then keep the parent >> alive as a workaround to stop the original process thinking the child >> has exited until the child chooses to detach. >> > I wonder what happens regarding the command line then. > Shouldn't really notice anything happening. Both parent and child have stdin open, (or maybe parent closes it), but only child is actually reading from it, and so it doesn't matter. (After all, if you launch gnuplot interactively from a shell, the shell still has the stdin stream open. But it just isn't reading from it.) dd --=20 Dave Denholm <dde...@es...> http://www.esmertec= .com |
|
From: <tim...@en...> - 2006-08-02 16:15:27
|
Dave Denholm wrote: > Timoth=E9e Lecomte <tim...@en...> writes: > > =20 >>>>> gnuplot can fork(), then allow the parent to exit, leaving the chil= d >>>>> continuing to run the same code in exactly the same state, but >>>>> detached. >>>>> =20 > > > =20 >>>> and because exiting >>>> the parent would close file and socket descriptors, thus closing the >>>> connection to the X server. >>>> >>>> =20 >>> No, the child inherits the open files. >>> >>> =20 >> It does, but when the parent calls exit(), the corresponding files are >> closed. There is a workaround : _exit(), but again, I think it becomes >> too complicated and less portable. >> =20 > > exit() can cause problems, but it doesn't close the files and > sockets. Or at least, it closes the parent's handles, but the child's > handles mean the underlying instance remains open. > > Parent exit() does cause stdio to get cleaned up, which can confuse > things. > > I rather assumed that as soon as we started discussing fork() we were > in a unix-only scenario. > =20 The unix-only was my assumption too. As far as the exit()/_exit() stuff=20 is concerned, here is a quote from the gtk+ FAQ : "5.5. Why does this strange 'x io error' occur when I fork() in my GTK+=20 app? [GTK 2.x] This is not really a GTK+ problem, and the problem is not related to=20 fork() either. If the 'x io error' occurs then you probably use the=20 exit() function in order to exit from the child process. When GDK opens an X display, it creates a socket file descriptor. When=20 you use the exit() function, you implicitly close all the open file=20 descriptors, and the underlying X library really doesn't like this. The right function to use here is _exit()." According to 'man 2 exit', the only difference between exit() and=20 _exit() is that the former executes all the functions registered in=20 atexit(), whereas the former doesn't. I guess the Xlib automatically=20 registers one of those, and get confused when exit() is used. Then, my conclusion is that fork() could indeed be used, but I still=20 wonder if it's worth coding it. >>> One other option would always be to immediately fork, but keep the >>> parent around as a dummy process (just so that the original process >>> knows it's still active). So all the work would happen in the child. >>> In effect, code it as if you always detach, and then keep the parent >>> alive as a workaround to stop the original process thinking the child >>> has exited until the child chooses to detach. >>> >>> =20 >> I wonder what happens regarding the command line then. >> >> =20 > > Shouldn't really notice anything happening. Both parent and child have > stdin open, (or maybe parent closes it), but only child is actually > reading from it, and so it doesn't matter. > > (After all, if you launch gnuplot interactively from a shell, the > shell still has the stdin stream open. But it just isn't reading from > it.) > =20 Thank you very much for your explanations ! It's nice to understand=20 fork() a little bit more. Best regards, Timoth=E9e |
