Menu
▾
▴
gnuplot-beta
|
From: Petr M. <mi...@ph...> - 2004-12-07 17:35:12
|
> Recalling old version of "embedded" Win32 Gnuplot engine > plotting 500 random points, directly from memory-mapped > file, refreshing an MFC CView 100 times a second, on a > dual 733 MHz PIII... Gnuplot's "oscilloscope" mode ? > > Again, since wx transmogrifies into a native app on each > platform, the same option would still be available for > term=wx on a Win32/64 box. If *nix also has high-speed > memory mapped file options, I wonder if this mode might > be implemented more generally in the Gnuplot core. If you have a demo of your approach, it may be worth to be put into gnuplot's web site. --- PM |
|
From: Nigel N. <nN...@au...> - 2004-12-11 15:02:25
|
Hi all,=0D =0D Thanks to Hans-Bernhard for setting the (wx) scene.=0D --- On Friday, 10 December 2004 HBB wrote: --- > Ethan Merritt wrote: >> On Tuesday 07 December 2004 09:34 am, Petr Mikulik wrote: >>=0D >>> Again, since wx transmogrifies into a native app on each >>> platform, the same option would still be available for >>> term=3Dwx on a Win32/64 box. =0D >>=0D >> What is this "term=3Dwx"; is that an out-of-tree gnuplot=0D >> driver, or something else entirely? > > Nigel Nunn seems otherwise occupied, so I'll bite: it's a=0D > hypothetical new driver, to be built by extending Nigel's=0D > work on integrating gnuplot into other apps, as a GUI control=0D > (original an MFC control, now, apparently, a wx Widget). My (ever-evolving, monolithic) simulation environment needs=0D a number of plotting panels. These are managed by the app, and plots are generated by simulation threads. Since most=0D academics appear to prefer their flavor of *nix rather than=0D HPC-Win64 on a rack of multi-core blades, there was little=0D interest in my VC-specific version... hence I migrated the=0D whole show to wxWidgets.=0D My experimental term wx works well, but the Gnuplot's use=0D of global variables effectively limits us to a single panel.=0D This could be fixed by packaging these globals in a struct,=0D and associating one such struct with each display panel.=0D =0D =0D >> Or do you mean that rather than reading from a real file, >> you want gnuplot to read from a shared-memory area? > > That's what he meant. gnuplot-as-a-library, if it is to make=0D > sense, needs a way to get data passed in by huge blocks, from=0D > the calling application. Going through an ASCII data file=0D > would be pretty foolish for that, but a shared memory-mapped=0D > file of binary data would do it. > > In other words, a named pipe by usage, but implemented in a=0D > more Windows-ish fashion. Memory-mapped files were one of those neat innovations the=0D DEC engineers built into their NT-OS for their Alpha, before=0D Microsoft bought everything and everyone involved.=0D =0D Nigel=0D =0D =0D =0D ___________________________________________________________________________= ________ This message is intended for the addressee named and may contain= confidential and=0D privileged information. If you are not the intended recipient please note= that any=0D form of distribution, copying or use of this communication or the= information in it=0D is strictly prohibited and may be unlawful. If you receive this message in= error,=0D please delete it and notify the sender. Keep up to date with what's happening in Australian sport. Visit= www.ausport.gov.au ___________________________________________________________________________= ________=0D |
|
From: Daniel J S. <dan...@ie...> - 2004-12-11 18:40:10
|
Nigel Nunn wrote: >My experimental term wx works well, but the Gnuplot's use >of global variables effectively limits us to a single panel. >This could be fixed by packaging these globals in a struct, >and associating one such struct with each display panel. > > We've had discussion of global variables before. I don't like 'em... and I tried reducing the extent of them when reworking the use of df_open(), df_readline(), etc. Dan |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-12-12 16:58:36
|
Nigel Nunn wrote: [Nigel, please check your mail client. Something's causing it to emit doubled linebreaks...] > My experimental term wx works well, but the Gnuplot's use > of global variables effectively limits us to a single panel. I consider fixing this a major goal that absolutely has to be achieved before the next official release (4.2). > This could be fixed by packaging these globals in a struct, > and associating one such struct with each display panel. It shouldn't be strictly associated to any visible entity, but rather switchable from inside gnuplot. I.e., we need the effect of 'load' and 'save' commands (but including saving of entire multi-plots), without relying on external files. Each "package of globals" has to be come a selectable global state (--> 'set' command), roughly like this: set state 5 to current # do something else set state to 5 ; replot multi # or even temporily: replot multi 5 |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-12-12 20:53:56
|
On Sunday 12 December 2004 08:59 am, Hans-Bernhard Broeker wrote: > > I consider fixing this a major goal that absolutely has to be achieved > before the next official release (4.2). So you don't think there should be an intervening 4.1 release? > It shouldn't be strictly associated to any visible entity, but rather > switchable from inside gnuplot. I.e., we need the effect of 'load' and > 'save' commands (but including saving of entire multi-plots), without > relying on external files. I wonder if you could elaborate on this ambitious goal a bit more. While I agree that the number of globals should be reduced, if only as a matter of aesthetics, I am not convinced that the goal of invoking multiple parallel copies of the main gnuplot within the same process context makes any sense. Wouldn't it be easier just to fire up multiple separate copies of gnuplot? Consider, for instance, the terminal tables and terminal-specific globals. Is terminal state persistent across wholesale save/restore of the program state? Or does each program state have its own set of terminal tables? I don't quite see how that 2nd option would work. -- Ethan A Merritt Biomolecular Structure Center University of Washington 98195-7742 |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-12-13 12:18:16
|
Ethan Merritt wrote:
> On Sunday 12 December 2004 08:59 am, Hans-Bernhard Broeker wrote:
>
>>I consider fixing this a major goal that absolutely has to be achieved
>>before the next official release (4.2).
>
>
> So you don't think there should be an intervening 4.1 release?
IIRC we agreed to switch to a Linux-like versioning scheme as of 4.0.
I.e. even minor for user releases, odd minor for development versions.
> [...] I am not convinced that the goal of invoking
> multiple parallel copies of the main gnuplot within the same process
> context makes any sense. Wouldn't it be easier just to fire up multiple
> separate copies of gnuplot?
For gnuplot as a process (the only thing currently existing): yes. But
for gnuplot as a (shared) library, that's not an option. AFAIK, a
single parent process can't open a single shared library more than once,
and expect those several instance to have context (i.e. global
variables) independent of each other beyond a very small number of
special variables ("instance variables", stored e.g. in the window
handle of a GUI control).
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-12-13 18:29:37
|
On Monday 13 December 2004 04:19 am, Hans-Bernhard Broeker wrote: > > Wouldn't it be easier just to fire up multiple > > separate copies of gnuplot? > > For gnuplot as a process (the only thing currently existing): yes. But > for gnuplot as a (shared) library, that's not an option. AFAIK, a > single parent process can't open a single shared library more than once, But a library of interface routines can generate multiple threads, each with its own instance of gnuplot. That is the direction in which the Python interface is headed (http://gnuplot-py.sourceforge.net/) and I think also the Java and Perl class libraries. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Petr M. <mi...@ph...> - 2004-12-14 07:26:55
|
> > So you don't think there should be an intervening 4.1 release? > > IIRC we agreed to switch to a Linux-like versioning scheme as of 4.0. > I.e. even minor for user releases, odd minor for development versions. Really? IMHO, I don't see any reason for this. The delay between 2 gnuplot versions is so huge that we cannot afford to make "non-public" releases. -- PM |
|
From: Daniel J S. <dan...@ie...> - 2004-12-14 08:34:26
|
Petr Mikulik wrote: >>>So you don't think there should be an intervening 4.1 release? >>> >>> >>IIRC we agreed to switch to a Linux-like versioning scheme as of 4.0. >>I.e. even minor for user releases, odd minor for development versions. >> >> > >Really? IMHO, I don't see any reason for this. The delay between 2 gnuplot >versions is so huge that we cannot afford to make "non-public" releases. > I'd think that delay could be shortened, especially given all the work the group put into a new release and updating the process thereof. That is, one doesn't want to be making a release so often that it becomes tedious. But at the same time the wait should be too long that it becomes a very big job to accomplish it. There has been enough added to 4.0 to maybe justify a 4.1 in the not to distant future. A good time for a release is when things stabilize and/or right before embarking on some new feature. Spring/early summer... then mid summer people work feverishly to try out their feature ideas. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-12-07 17:47:47
|
On Tuesday 07 December 2004 09:34 am, Petr Mikulik wrote: > > > > Again, since wx transmogrifies into a native app on each > > platform, the same option would still be available for > > term=wx on a Win32/64 box. What is this "term=wx"; is that an out-of-tree gnuplot driver, or something else entirely? > > If *nix also has high-speed > > memory mapped file options, I wonder if this mode might > > be implemented more generally in the Gnuplot core. In most unix/linux systems *all* files are cached in memory to the extent possible. Or do you mean that rather than reading from a real file, you want gnuplot to read from a shared-memory area? That would be possible, but probably unnecessary. You could achieve much the same thing with no change to existing code by using a named pipe rather than a file. I think there's a Python-based demo on the web site that provides an example of this. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-12-09 19:36:10
|
Ethan Merritt wrote: > On Tuesday 07 December 2004 09:34 am, Petr Mikulik wrote: > >>>Again, since wx transmogrifies into a native app on each >>>platform, the same option would still be available for >>>term=wx on a Win32/64 box. > > > What is this "term=wx"; is that an out-of-tree gnuplot driver, > or something else entirely? Nigel Nunn seems otherwise occupied, so I'll bite: it's a hypothetical new driver, to be built by extending Nigel's work on integrating gnuplot into other apps, as a GUI control (original an MFC control, now, apparently, a wx Widget). > Or do you mean that rather than reading from a real file, > you want gnuplot to read from a shared-memory area? That's what he meant. gnuplot-as-a-library, if it is to make sense, needs a way to get data passed in by huge blocks, from the calling application. Going through an ASCII data file would be pretty foolish for that, but a shared memory-mapped file of binary data would do it. In other words, a named pipe by usage, but implemented in a more Windows-ish fashion. |
