From: Jay C. <jea...@is...> - 2004-01-15 09:13:56
|
hello again! to answer my previous question: My 50 channel oscilloscope application is feasible with plplot as graph library. It is really fast. I use the polygon fill function to erase previous plotted data. but another problem: If I let the program run a long time my hard disk fills up. It took some time to find out what file would get so huge, because the file doesn't show up in the filesystem, because it is already deleted. (funny phenomenon). #lsof -c scope COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME (...) scope 32031 root 6u REG 8,3 1415630848 19684 /tmp/tmpfXiOQuk (deleted) I suspect that pouring that many data so fast into the X-server or the plplot device perhaps causes it to build up a queue which grows ever bigger. But however my application runs normally and everything I want it to draw gets drawn even after the disk is saturated. So where does the tempfile come from, why is it deleted (it immediately goes away when the program exits) and what exactly is its purpose? How could I correct this? Thanks in advance for any help. |
From: Maurice L. <mj...@ga...> - 2004-01-15 09:27:53
|
Jay Christnach writes: > hello again! > to answer my previous question: > My 50 channel oscilloscope application is feasible with plplot as graph > library. It is really fast. I use the polygon fill function to erase previous > plotted data. > > but another problem: > If I let the program run a long time my hard disk fills up. It took some time > to find out what file would get so huge, because the file doesn't show up in > the filesystem, because it is already deleted. (funny phenomenon). > #lsof -c scope > COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME > (...) > scope 32031 root 6u REG 8,3 1415630848 19684 /tmp/tmpfXiOQuk > (deleted) Heh. That looks like the plot buffer. As you create a plot under X, the plot buffer pseudo-device is written to, so that on window expose or redraw events, the prior contents of the window can be recovered. It's closed at every end-of-page, and my guess is that you aren't issuing any.. LOL. There really should be a size limitation on it though.. >1G is way, way too big. :) Although there is no API control for this, fortunately you do have access through the plplot stream pointer. You can disable writing to the plot buffer entirely by setting pls->plbuf_write to 0. Or keep it writing by default but control its contents through manipulating pls->plbufFile. See src/plbuf.c for more info. -- Maurice LeBrun |
From: <jc...@fe...> - 2004-01-16 00:15:47
|
On Thursday 15 January 2004 09:27, Maurice LeBrun wrote: | Jay Christnach writes: | > hello again! | > to answer my previous question: | > My 50 channel oscilloscope application is feasible with plplot as graph | > library. It is really fast. I use the polygon fill function to erase | > previous plotted data. | > | > but another problem: | > If I let the program run a long time my hard disk fills up. It took | > some time to find out what file would get so huge, because the file | > doesn't show up in the filesystem, because it is already deleted. | > (funny phenomenon). #lsof -c scope | > COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME | > (...) | > scope 32031 root 6u REG 8,3 1415630848 19684 | > /tmp/tmpfXiOQuk (deleted) | | Heh. That looks like the plot buffer. As you create a plot under X, the | plot buffer pseudo-device is written to, so that on window expose or redraw | events, the prior contents of the window can be recovered. It's closed at | every end-of-page, and my guess is that you aren't issuing any.. LOL. | There really should be a size limitation on it though.. >1G is way, way too | big. :) | | Although there is no API control for this, fortunately you do have access | through the plplot stream pointer. You can disable writing to the plot | buffer entirely by setting pls->plbuf_write to 0. Or keep it writing by | default but control its contents through manipulating pls->plbufFile. See | src/plbuf.c for more info. If using the xwin driver, you can use the "-drvopt nobuffered" cmd line driver option. Programatically, use plSetOpt("drvopt","nobuffered") Joao |
From: Arjen M. <arj...@wl...> - 2004-01-15 09:28:22
|
Jay Christnach wrote: > > hello again! > to answer my previous question: > My 50 channel oscilloscope application is feasible with plplot as graph > library. It is really fast. I use the polygon fill function to erase previous > plotted data. > > but another problem: > If I let the program run a long time my hard disk fills up. It took some time > to find out what file would get so huge, because the file doesn't show up in > the filesystem, because it is already deleted. (funny phenomenon). > #lsof -c scope > COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME > (...) > scope 32031 root 6u REG 8,3 1415630848 19684 /tmp/tmpfXiOQuk > (deleted) > > I suspect that pouring that many data so fast into the X-server or the plplot > device perhaps causes it to build up a queue which grows ever bigger. But > however my application runs normally and everything I want it to draw gets > drawn even after the disk is saturated. > > So where does the tempfile come from, why is it deleted (it immediately goes > away when the program exits) and what exactly is its purpose? How could I > correct this? > PLplot uses a temporary file to store the plotting commands in. This is used to recreate the image when necessary, but of course, in your case, the whole history is stored ... That is an unforeseen consequence. I have no solution right now. Perhaps it is possible to turn off the temporary file - you do not really need it. But you would have to check the code. Regards, Arjen |
From: Jay C. <jea...@is...> - 2004-01-15 14:13:17
|
On Thursday 15 January 2004 10:27, Maurice LeBrun wrote: > Heh. That looks like the plot buffer. As you create a plot under X, the > plot buffer pseudo-device is written to, so that on window expose or redraw > events, the prior contents of the window can be recovered. It's closed at > every end-of-page, and my guess is that you aren't issuing any.. LOL. > There really should be a size limitation on it though.. >1G is way, way too > big. :) > > Although there is no API control for this, fortunately you do have access > through the plplot stream pointer. You can disable writing to the plot > buffer entirely by setting pls->plbuf_write to 0. Or keep it writing by > default but control its contents through manipulating pls->plbufFile. See > src/plbuf.c for more info. (I'm really impressed by the speed one gets answers from this mailing list, Thanks!) This got a bit complicated, because I'm no experienced C-programmer. Fortunately one knows somebody who knows more. We found that pls was declared static, so inaccessible and out of pure intuition we decided to try out plsc which is also a PLStream. And it worked! The temporary file is now still open, but it doesn't grow anymore. Here is what I did in my application code: ... #include "plstrm.h" extern PLStream *plsc; .... plinit(); plsc->plbuf_write=0; .... I'm not sure if this was the right (or the best) way to do it, but I think I can be happy with it. Thanks to the developers of those cool libraries which make programming a lot more fun! The next challenge will be user interaction for which I will need an eventhandler for our window. Just don't know yet how to accomplish this stuff. Best regards, Jay |
From: Arjen M. <arj...@wl...> - 2004-01-15 14:40:28
|
Jay Christnach wrote: > > > This got a bit complicated, because I'm no experienced C-programmer. > Fortunately one knows somebody who knows more. We found that pls was declared > static, so inaccessible and out of pure intuition we decided to try out plsc > which is also a PLStream. And it worked! The temporary file is now still > open, but it doesn't grow anymore. > Here is what I did in my application code: > ... > #include "plstrm.h" > extern PLStream *plsc; > .... > plinit(); > plsc->plbuf_write=0; > .... > > I'm not sure if this was the right (or the best) way to do it, but I think I > can be happy with it. Thanks to the developers of those cool libraries which > make programming a lot more fun! > I ran into a similar problem - and used the same solution. This had to do with PLplot being a library inside a larger application. > The next challenge will be user interaction for which I will need an > eventhandler for our window. Just don't know yet how to accomplish this > stuff. > You might want to look at the Tcl/Tk binding: with Tcl/Tk you can easily create user-interfaces and PLplot can serve to produce your graphical display. If you choose another solution, you will probably run into the problems I referred to - I still have to commit them to the PLplot development team - as they arose in this larger program, because it handles the user-interface (and all window events) and uses PLplot as a graphics library. Regards, Arjen |
From: Maurice L. <mj...@ga...> - 2004-01-16 06:31:42
|
Jay Christnach writes: > Here is what I did in my application code: > ... > #include "plstrm.h" > extern PLStream *plsc; > .... > plinit(); > plsc->plbuf_write=0; > .... > > I'm not sure if this was the right (or the best) way to do it, but I think I > can be happy with it. Thanks to the developers of those cool libraries which > make programming a lot more fun! Actually, it would be a bit better to use plgpls() to get the stream pointer. That way it would still work should you ever go with multiple streams, or if we should ever make plsc unavailable to the outside world. While plgpls() is not part of the "common" API, it is still part of the standard "C" API AFAIAC. -- Maurice LeBrun |