gnuplot-beta — Developers and beta testers of new gnuplot code

Time formats [was Re: Feature request - assignment in expressions]

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 08 May 2007 09:43, Juergen Wieferink wrote:
> 
> > I have never understood the time-handling code.  I suspect that the
> > whole special case time format mechanism is no longer needed, as the same
> > goal can be achieved using general string-handling functions.
> > In your case, you probably need to use some combination of stringcolumn()
> > strptime() strftime() rather than setting a time format.
> 
> I don't think so.  I see two problems (probably there are more):
> * Automatic tic generation is date/time aware.  This could be
>   adjusted manually, but the automatic tics wouldn't be too sensible.

Could be.  As I said, I am not familiar with the time format options.

> * Tic label generation.  The command "set format" just takes a
>   format string, which is used either for date/time or ordinary
>   numbers.  The functions strptime() and strftime() only work with a
>   more flexible "set format" which takes a string valued expression, which
>   is evaluated at plot time.

Sure.  But that could be a useful addition in its own right.
I didn't mean to say that the time format options could be deprecated
with no additional work; I just meant that the basic pieces are in place
to replace them with a more general mechanism.

Don't forget that we have several long-standing requests to extend
the time format system so that it can handle intervals smaller than
a second, and also to allow it to handle spherical coordinate systems
deg/min/sec/fractional-sec

One could write a lot of special-purpose code to handle these
extensions, but I would rather see the effort spent on implementing
a generic mechanism of which the existing time formats and the 
proposed geographic variants are just user-configurable examples.


-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

Re: gnuplot with wxt on MacOS, time for decisions

[Per P. <per...@ma...>]

On May 7, 2007, at 21:17, Ethan Merritt wrote:

> On Monday 07 May 2007 11:02, Timoth=E9e Lecomte wrote:
>> Dear gnuplot (especially on MacOS) enthusiasts,
>> Dear Joe, Mojca, who tested wxt on MacOS since its early ages ;),
>> Dear Nigel, whose remarks inspired me for this mail,
>>
>> I have worked a little more on wxt for MacOS this last days.
>>

First of all: nice work Timoth=E9e, the screenshots looks very nice.

>> Fixing it for MacOS is not really straightforward, because I seem to
>> have abused Linux/GTK/X flexibility so that some things have to be
>> restricted now.
>
> [rest of original message now at the end]
>
>> So, I'd like to know what you think of this. Do you think it's worth
>> doing all these changes ?
>
> Not really.  I think the prefered options are
>
> (4) Fix the upstream package in OSX
>
> It seems pointless to spend all that time re-arranging gnuplot only
> to the benefit of gnuplot users.  The equivalent amount of work on
> the OSX equivalent of the GTK layer would presumably benefit ports
> of many other applications to OSX as well.

Huh, you lost me here. Fix what? You mean wxMac/wxCocoa right?

>
> or
>
> (5) Use X11 + wxWidgets on OSX rather than the apparently broken
> native OSX layer (that's possible, right?)

Yes, I can't see why it shouldn't.

>
> I'd like to hear from Per Persson as well (CC'ed)
>
> If you really want to pick from options 1, 2, and 3 I'd go with
> (1) two single-threaded processes, as in the X11 implementation.
> If nothing else, this makes it easier to debug.

I don't really have a strong opinion here, and since I don't know wx =20
stuff at all I'm mostly guessing.

Do you really need all that asynchronicity in option (2)? AFAIK most =20
GUI-systems will lock focus on a drawing view
at an appropriate time and then call a specific method, lets call it =20
draw(). What if you used Cairo's metasurface to record the drawing =20
commands in the driver, and then played them back in the draw() =20
method? But then again, I haven't had time to follow what's going on =20
here or on the related projects.

As for (3), maybe that approach (should you choose it) should be =20
generalized[1] to simplify development of Windows/GTK/Mac/Qt/etc GUI =20
interfaces to gnuplot, on equal footing with the current CLI.

/Per

(1) I guess such a generalization could lead to a situation with x =20
number half-baked GUI's popping up, each with different feature sets, =20=

level of maintenance, quality etc since developer resources would be =20
"like butter spread over too much bread". In that case I'd rather see =20=

a single well kept CLI.


>
>
> 	Ethan
>
>
>
>
>
>
>> The main restriction, as discussed in previous mails, is that the =20
>> main
>> thread should do each and every GUI action. Currently, wxt uses a =20
>> second
>> thread for the GUI event loop, and happily does things in the first
>> thread with some mutexes locked. This approach does not work on =20
>> MacOS.
>>
>> 1st solution, as suggested previously =3D use two processes:
>>  - this is the design of the x11 terminal. I don't like it, because I
>> find complicated to have to handle two processes and their
>> inter-communication where we really have one program (one task).
>>
>> 2nd solution =3D invert the threads' roles (i.e. the shortest path =
from
>> where we are now):
>> - the main thread runs the GUI event loop, and gnuplot gnu_main()
>> (plot.c:278) runs in the second thread.
>> - terminal callbacks (such as term->graphics, term->text) do every =20=

>> GUI
>> action asynchronously, by posting messages to the GUI event loop
>> - corner cases:
>>     *signals masks have to be carefully set, so that ^C ends up in =20=

>> the
>> second thread (easy)
>>     *doing everything asynchronously can be painful, sometimes it's
>> actually synchronous, so you have to wait for the other thread to =20
>> finish
>> before continuing (I am thinking of term->init() where new windows =20=

>> are
>> created) (easy, but not really beautiful programming)
>>     * this adds a startup overhead, because wxWidgets has to be
>> initialized at launch-time for the threads facility (I don't see =20
>> how to
>> switch the two thread contexts when they are already running) =20
>> (currently
>> it's initialized when first used).
>>
>> 3rd solution =3D use one thread only (the most ambitious)
>>  - the one and only thread is an event loop.
>>  - "a char arrived on stdin" is handled as an event (this is natural,
>> isn't it?), and passed to readline
>>  - the event loop is actually the GUI loop, just extended to watch =20=

>> stdin
>> in addition to window events
>>  - no more locking, no more worries about not-so-asynchronous =20
>> actions,
>> no more multithreading restrictions to take care of
>>  - it looks like it's the way Nigel Nunn has mentioned for so long
>>  - drawbacks:
>>     * it's the longer way to go from what we have now, involving some
>> work in some mechanisms and assumptions gnuplot has had since the =20
>> early
>> ages probably.
>>     * as for the previous solution, there's a startup overhead =20
>> because
>> we would have to initialize the event loop (i.e. wxWidgets)
>>
>> Currently, we have:
>>     while( readline(); do_line(); ) {};
>>
>> Instead we would have an event loop, with the following callbacks:
>>     data_is_available_in_stdin() {rl_callback_read_char ();}
>>     line_is_completed() {do_line();}
>> The event loop naturally processes these events exactly the same =20
>> way it
>> does with others, namely GUI events.
>>
>> In practise, a lot of reorganization is needed:
>> - in plot.c, to separate the initialization code, from the actual =20
>> loop
>> quoted above,
>> - in command.c and readline.c, to implement the event-based approach,
>> and to rework the pieces of code that call read_line or getc directly
>> (builtin-pager, help system, inline data)
>>
>>
>> So, I'd like to know what you think of this. Do you think it's worth
>> doing all these changes ? Note that if I work on this, I won't change
>> the way it works when wxt is not compiled in.
>>
>>
>> Best regards,
>>
>> Timoth=E9e Lecomte
>>
>>
>>
>> ---------------------------------------------------------------------=20=

>> ----
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> gnuplot-beta mailing list
>> gnu...@li...
>> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>
>
> --=20
> Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
> Dept of Biochemistry
> Health Sciences Building
> University of Washington - Seattle WA 98195-7742

Re: Feature request - assignment in expressions

[Juergen W. <wie...@fr...>]

Am Dienstag, 8. Mai 2007 schrieb Ethan A Merritt:
>    plot <foo>  using 1:2 after track_max($2) with lines

[...]

> - (Con) This is incompatible with the revised zooming/refresh code
>   that I am working on.  There the idea is to avoid re-reading the input
>   data if all you want to do is replot it.  But the assign/after mechanism
>   is applied during data input, so it would be bypassed by any such
> shortcut.

I think this is a feature.  For compatibility, the refreshing should
not be done with "replot" but with "redraw" (or similar).  I would
not expect "redraw" to go through this filter.

> I have never understood the time-handling code.  I suspect that the
> whole special case time format mechanism is no longer needed, as the same
> goal can be achieved using general string-handling functions.
> In your case, you probably need to use some combination of stringcolumn()
> strptime() strftime() rather than setting a time format.

I don't think so.  I see two problems (probably there are more):
* Automatic tic generation is date/time aware.  This could be
  adjusted manually, but the automatic tics wouldn't be too sensible.
* Tic label generation.  The command "set format" just takes a
  format string, which is used either for date/time or ordinary
  numbers.  The functions strptime() and strftime() only work with a
  more flexible "set format" which takes a string valued expression, which
  is evaluated at plot time.

Juergen

Re: Feature request - assignment in expressions

[Ethan A M. <merritt@u.washington.edu>]

On Monday 07 May 2007 23:56, pl...@pi... wrote:
> 
> thanks very much for picking this up. That seems quite close to what I was  
> requesting. I extended your example to pick up the x value of the ymax as  
> well. The plot gives the sample-and-hold plot as expected. Proof of  
> principle. Nice one.
> 
> The nice thing is this can be limitted by setting the range before plot.  
> This is a nice quick solution that avoids quite a bit of effort messing  
> about with external scripts for simple stuff like this. A nice addition.

Please continue to play with it.  We need to discover what limitations and
drawbacks this simple implementation may have before seriously considering
to add some variant to the program.

I hope we can come up with a nicer syntax, as it seems ugly to me to hide
this inside the 'using' clause.  Thinking out loud....  what about a 
parallel clause with a name like 'after'.  The operations in the 'after'
clause would be carried out before passing the data through for actual
plotting:

   plot <foo>  using 1:2 after track_max($2) with lines

perhaps it should allow multiple operations:

   plot <foo> using 1:2 after {track_max($2), track_min($2), sum($2)} with lines


More thoughts:

- (Pro) As compared to filtering through an external script, this mechanism
  has the advantage that it can affect internal gnuplot user variables.

- (Con) This is incompatible with the revised zooming/refresh code
  that I am working on.  There the idea is to avoid re-reading the input
  data if all you want to do is replot it.  But the assign/after mechanism
  is applied during data input, so it would be bypassed by any such shortcut.

- Having to use the name of the variable rather than the variable itself
  may make sense to a low-level programmer, but is likely to be confusing
  to many users.  Suggestions for a syntax that hides this level of 
  complexity would be welcome.  Or perhaps some additional cleverness in
  the parset is possible.  We have one such function already,
  exists("VARNAME"), but that one is also confusing.

> This presents me with some small issues remaining to be solved:
> 
> 1. My xdata is time format , I imagine your patch does not try to fit all  
> cases but in assigning the x value it gets truncated to the nearest hour,  
> 12:45 becomes 12.0

I have never understood the time-handling code.  I suspect that the
whole special case time format mechanism is no longer needed, as the same
goal can be achieved using general string-handling functions.
In your case, you probably need to use some combination of stringcolumn()
strptime() strftime() rather than setting a time format.

> 2. my inexperience with gnuplot, it seems that if I try to set a label  
> after the plot command (which I need to do for xmax,ymax) it does not  
> show. The same command before plot command does work but it's at (0,0).

Of course.  When you draw a new graph by issuing the command "plot" or
"splot", it uses the currently defined labels.
If you define a label afterwards, how could it possibly appear in the
already-drawn plot?  If you don't mind reading the data a second time,
you could "replot" to pick up the new labels.


-- 
Ethan A Merritt

Re: Feature request - assignment in expressions

[<pl...@pi...>]

On Tue, 08 May 2007 09:23:01 +0200, <pl...@pi...> wrote:

> Example:
> 	MAX =3D -999
> 	update_max(x) =3D assign("MAX",  x > MAX ? x : MAX)
> 	plot <foo> using 1:($2 + 0. * update_max($2))
> 	print "Maximum data value plotted was", MAX
> Comments:
> 	I'm not sure this will actually accomplish what you want, but
> 	please try it out and let us know.  If you use this inside a
> 	"using" clause, it will slow down data input. For large data files
> 	the slowdown is likely to be noticeable.  For the use above, it
> 	would probably be more convenient to have the update_max(x) function
> 	return the current value of x rather than the updated maximum.
> 	It's not clear to me how best to achieve that.

shift the 'times zero' trick inside the funtion?

  	catch_max(y) =3D y+ 0. * assign("MAX",  y > MAX ? y : MAX);
	plot <foo> using 1:(catch_max($2))

pretty much the same thing but like you say a bit more convenient for pl=
ot.

;)

Re: Feature request - assignment in expressions

[<pl...@pi...>]

On Tue, 08 May 2007 01:51:34 +0200, Ethan Merritt  =

<merritt@u.washington.edu> wrote:

> The SourceForge end of the gnuplot-bugs mailing list is currently brok=
en.
> I found this posting via gmane.org (under "bugs") but it doesn't reall=
y
> belong there, so I'm copying it to the developers list with a reply.

Hi Ethan,

thanks very much for picking this up. That seems quite close to what I w=
as  =

requesting. I extended your example to pick up the x value of the ymax a=
s  =

well. The plot gives the sample-and-hold plot as expected. Proof of  =

principle. Nice one.

It would be quite a simple extention to do a trapezoidal area under grap=
h  =

or the mean.
The nice thing is this can be limitted by setting the range before plot.=
  =

This is a nice quick solution that avoids quite a bit of effort messing =
 =

about with external scripts for simple stuff like this. A nice addition.=




set xdata time
set timefmt "%H:%M"

set xr ["10:15":"18:30"]

xmax=3D0;ymax=3D0;
max(x,y)=3Dassign("ymax",(ymax<y)?y+0. * assign("xmax",x):ymax );

set label "max was here" at "11:00",ymax/10;

plot  datafile   using 1:(P( Th4($3-2.0) - Th5($2) )) axes x1y2  with  =

lines s f t "useful power" \
,  datafile   using 1:(max(column(1),P( Th4($3-2.0) - Th5($2) ))) axes  =

x1y2  with lines s f t "s/hold" \


My initial task with this was to put a label on the graph at the max poi=
nt.

This presents me with some small issues remaining to be solved:

1. My xdata is time format , I imagine your patch does not try to fit al=
l  =

cases but in assigning the x value it gets truncated to the nearest hour=
,  =

12:45 becomes 12.0

2. my inexperience with gnuplot, it seems that if I try to set a label  =

after the plot command (which I need to do for xmax,ymax) it does not  =

show. The same command before plot command does work but it's at (0,0).


I'm sure gnuplot users (ingenious as they are) will find 101 neat tricks=
  =

to do with the new command , it opens up all sorts of possibilities.

Many thanks.


>>>>>>>>>>
Synopsis:
	The suggestion is to allow assignment to a variable inside an
	expression.  This may be useful in order to collect statistics
	about data points as they are read in

Response:
	I have attached a small patch that implements a new user-visible
	function:
		assign("VAR", <expression>)
	It assigns the current value of the expression to a variable
	named VAR.
	NB: this is the _name_ of the variable, not the variable itself.

Example:
	MAX =3D -999
	update_max(x) =3D assign("MAX",  x > MAX ? x : MAX)
	plot <foo> using 1:($2 + 0. * update_max($2))
	print "Maximum data value plotted was", MAX

Comments:
	I'm not sure this will actually accomplish what you want, but
	please try it out and let us know.  If you use this inside a
	"using" clause, it will slow down data input. For large data files
	the slowdown is likely to be noticeable.  For the use above, it
	would probably be more convenient to have the update_max(x) function
	return the current value of x rather than the updated maximum.
	It's not clear to me how best to achieve that.

%%%%%%%% begin forwarded message %%%%%%%%%
From: <plotter <at> piments.com>
  Subject: feature request
  Newsgroups: gmane.comp.graphics.gnuplot.bugs

I have been trying to trick gnuplot into doing some simple tasks it does=

not seem possible to do but which could be immensely useful.

to judge by comp.graphics.apps.gnuplot it seems that there are certain
basic tasks that are frequently requested and get a reply along the line=
s
of "gnuplot is not for number crunching".

Fine. Gnuplot is a plotting program, not a data processing package but
there are an number of trivial tasks like calculating a mean or finding
the max of values *calculated* by gnuplot that cant currently be done.

Tasks like this are far less complex than function fitting do data or
plotting with spline interpolation and would be very valuable in the
context of outputting data to a graph.

eg how to put a label at the max point of the data. Definately a plottin=
g
task and hardly "number crunching" but currently it seems I have do this=

simple task in an external script.

Worse, if I do some fitting and expression evaluation in the plot comman=
d
, I have to duplicate it all to a table, call an external script and the=
n
read in a new file to get the value of the max or mean value of y.

all I really need is a means to assign one tiny little variable during
plot (directly or from a within a fn )

consider the following that will plot a "sample and hold":

xmax=3D0;
max(x)=3D( (xmax<x)?(xmax=3Dx):xmax  );

plot  "150tank-txC.data"   using 1:(Th6($4)) with lines t "panel out" \
, "150tank-txC.data"   using 1:(max(Th6($4))) with lines t "s/h" ;

Currently not possible since function parser will not allow C style
'assignment returns a value'.
A similar technique could find the min , max, mean or area under graph; =
in
fact it opens a whole range of possibilities that are frequently request=
ed
on the list.

So how much effort is it?

Well without going to the extent of supporting procedure calls from with=

plot command , adding the above parsing of C style assignments would be
simple to add and open the door to some very useful techniques.

I hope you will find it worth considering.

Kind regards.
%%%%%%%% begin forwarded message %%%%%%%%%

Feature request - assignment in expressions

[Ethan M. <merritt@u.washington.edu>]

The SourceForge end of the gnuplot-bugs mailing list is currently broken.
I found this posting via gmane.org (under "bugs") but it doesn't really
belong there, so I'm copying it to the developers list with a reply.

Synopsis:
	The suggestion is to allow assignment to a variable inside an
	expression.  This may be useful in order to collect statistics
	about data points as they are read in

Response:
	I have attached a small patch that implements a new user-visible
	function:
		assign("VAR", <expression>)
	It assigns the current value of the expression to a variable
	named VAR.
	NB: this is the _name_ of the variable, not the variable itself.  

Example:
	MAX = -999
	update_max(x) = assign("MAX",  x > MAX ? x : MAX)
	plot <foo> using 1:($2 + 0. * update_max($2))
	print "Maximum data value plotted was", MAX

Comments:
	I'm not sure this will actually accomplish what you want, but
	please try it out and let us know.  If you use this inside a
	"using" clause, it will slow down data input. For large data files
	the slowdown is likely to be noticeable.  For the use above, it
	would probably be more convenient to have the update_max(x) function
	return the current value of x rather than the updated maximum.
	It's not clear to me how best to achieve that.

%%%%%%%% begin forwarded message %%%%%%%%%
From: <plotter <at> piments.com>
 Subject: feature request
 Newsgroups: gmane.comp.graphics.gnuplot.bugs

I have been trying to trick gnuplot into doing some simple tasks it does  
not seem possible to do but which could be immensely useful.

to judge by comp.graphics.apps.gnuplot it seems that there are certain  
basic tasks that are frequently requested and get a reply along the lines  
of "gnuplot is not for number crunching".

Fine. Gnuplot is a plotting program, not a data processing package but  
there are an number of trivial tasks like calculating a mean or finding  
the max of values *calculated* by gnuplot that cant currently be done.

Tasks like this are far less complex than function fitting do data or  
plotting with spline interpolation and would be very valuable in the  
context of outputting data to a graph.

eg how to put a label at the max point of the data. Definately a plotting  
task and hardly "number crunching" but currently it seems I have do this  
simple task in an external script.

Worse, if I do some fitting and expression evaluation in the plot command  
, I have to duplicate it all to a table, call an external script and then  
read in a new file to get the value of the max or mean value of y.

all I really need is a means to assign one tiny little variable during  
plot (directly or from a within a fn )

consider the following that will plot a "sample and hold":

xmax=0;
max(x)=( (xmax<x)?(xmax=x):xmax  );

plot  "150tank-txC.data"   using 1:(Th6($4)) with lines t "panel out" \
, "150tank-txC.data"   using 1:(max(Th6($4))) with lines t "s/h" ;

Currently not possible since function parser will not allow C style  
'assignment returns a value'.
A similar technique could find the min , max, mean or area under graph; in  
fact it opens a whole range of possibilities that are frequently requested  
on the list.

So how much effort is it?

Well without going to the extent of supporting procedure calls from with  
plot command , adding the above parsing of C style assignments would be  
simple to add and open the door to some very useful techniques.

I hope you will find it worth considering.

Kind regards.
%%%%%%%% begin forwarded message %%%%%%%%%

-- 
Ethan A Merritt

Re: gnuplot with wxt on MacOS, time for decisions

[<tim...@en...>]

Ethan Merritt wrote:
> On Monday 07 May 2007 13:43, Mojca Miklavec wrote:
>   
>>> Here's one example where it looks like they are working on an aqua
>>> port in addition to the X11-OSX "hybrid" version we are currently using
>>>     http://pymol.sourceforge.net/obtaining.html
>>>       
>> I don't know the dirty details, but I use pymol without X11 from the
>> beginning (MacPyMOL probably). It seems to be a pure aqua port without
>> traces of X11.
>>     
>
> OK, so then PyMOL is an example application that uses both command line
> and GUI-driver input.  Perhaps it would be useful to look and see how
> it does so?   Or does the "pure aqua" version not let you type commands
> into a scripting window?
>   

I have given a quick look... I don't know much about python, apart from 
the fact that it's an interpreted language, with its command line & parser.

The python files have mutex locks all over the place:

   93     # these locks are to be shared by all PyMOL instances within a
   94     # single Python interpeter
   95 
   96     _pymol.lock_api = threading.RLock() # mutex for API
   97     _pymol.lock_api_c = threading.RLock() # mutex for C management of python threads
   98     _pymol.lock_api_status = threading.RLock() # mutex for PyMOL status info
   99     _pymol.lock_api_glut = threading.RLock() # mutex for avoiding GLUT



In __init__.py, there's also:

  76     # standard input reading thread
   77 
   78     _pymol._stdin_reader_thread = None

So it looks like it's multithreaded, with a thread dedicated to waiting for the input.


Timothée

Re: gnuplot with wxt on MacOS, time for decisions

[Mojca M. <moj...@gm...>]

On 5/7/07, Ethan Merritt <merritt@u.washington.edu> wrote:
> On Monday 07 May 2007 13:43, Mojca Miklavec wrote:
> > > Here's one example where it looks like they are working on an aqua
> > > port in addition to the X11-OSX "hybrid" version we are currently using
> > >     http://pymol.sourceforge.net/obtaining.html
> >
> > I don't know the dirty details, but I use pymol without X11 from the
> > beginning (MacPyMOL probably). It seems to be a pure aqua port without
> > traces of X11.
>
> OK, so then PyMOL is an example application that uses both command line
> and GUI-driver input.

Yes.

> Perhaps it would be useful to look and see how
> it does so?   Or does the "pure aqua" version not let you type commands
> into a scripting window?

Yes, of course it's possible to type commands in it - no problem.
Also, an interesting example probably worth looking into is the R
project. But I don't have the slightest idea what they did. I guess
that they used a purely Aqua-specific solution.

Mojca

Re: gnuplot with wxt on MacOS, time for decisions

[Ethan M. <merritt@u.washington.edu>]

On Monday 07 May 2007 13:43, Mojca Miklavec wrote:
> > Here's one example where it looks like they are working on an aqua
> > port in addition to the X11-OSX "hybrid" version we are currently using
> >     http://pymol.sourceforge.net/obtaining.html
> 
> I don't know the dirty details, but I use pymol without X11 from the
> beginning (MacPyMOL probably). It seems to be a pure aqua port without
> traces of X11.

OK, so then PyMOL is an example application that uses both command line
and GUI-driver input.  Perhaps it would be useful to look and see how
it does so?   Or does the "pure aqua" version not let you type commands
into a scripting window?


-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

Re: gnuplot with wxt on MacOS, time for decisions

[Mojca M. <moj...@gm...>]

On 5/7/07, Timoth=E9e Lecomte wrote:
> Mojca Miklavec wrote:
> > On 5/7/07, Ethan Merritt wrote:
> >
> >> It seems pointless to spend all that time re-arranging gnuplot only
> >> to the benefit of gnuplot users.  The equivalent amount of work on
> >> the OSX equivalent of the GTK layer would presumably benefit ports
> >> of many other applications to OSX as well.
> >
> > I wouldn't object the improvement of native GTK handling on Mac (I
> > would really like to see Mono working on Mac), but that's probably
> > off-topic here and outside the scope ...
>
> Note that there's no GTK involved here. wxMac uses Cocoa and Carbon, the
> native interfaces, directly.

I know. It was just a slightly off-topic discussion (but I would
really be glad if wxt was ported natively to Mac - in a stable state -
even though it has nothing to do with gnuplot).

> > It really is important to have some native driver unless there is no
> > other choice.
>
> That's what I've understood. Besides, there's already a plotting program
> in MacOS X, called Grapher if I remember correctly.

Yes, and it's really simple to use for a newbie. I don't use it (yet?)
for some reason, probably because I have old code lying around,
because I keep changing platforms I work on, and because it's
difficult to change old habits ... but the program is really worth
looking into.

Thanks again,
   Mojca

Re: gnuplot with wxt on MacOS, time for decisions

[Ethan M. <merritt@u.washington.edu>]

On Monday 07 May 2007 12:35, Timoth=C3=A9e Lecomte wrote:
> > (4) Fix the upstream package in OSX
> >
> > It seems pointless to spend all that time re-arranging gnuplot only
> > to the benefit of gnuplot users.  The equivalent amount of work on
> > the OSX equivalent of the GTK layer would presumably benefit ports
> > of many other applications to OSX as well.
> >  =20
>=20
> Well, I wouldn't say so ;)
> First, I don't know of *any* application that use this design. First, I=20
> can't think of any other application that have to mix command lines from=
=20
> stdin with GUI.

They are quite common in my field, and many of them work under OSX.
However, they do so by requiring the user to install X11 and use
that interface.  Hence my option (5).

Most of the recent ones are written in Python; I don't know if that makes
any difference to the toolkits available.
Here's one example where it looks like they are working on an aqua
port in addition to the X11-OSX "hybrid" version we are currently using
    http://pymol.sourceforge.net/obtaining.html
Here's another page that collects info and instructions on interactive
X11-based programs running on OSX. These generally do require mixed
input from GUI and stdin.
    http://xanana.ucsc.edu/~wgscott/xtal/wiki/index.php/Main_Page

I have not myself done any OSX development, but for better or worse
I have committed to [supervise the] port of several other apps to OSX,
so in the future I have more insight into the difficulties.
=09
"Mojca Miklavec" <moj...@gm...> wrote:
> If I had to use X11, I would prefer to stick with AquaTerm, even
> though it's functionality (esp. mouse) is limited. X11 is really the
> last resort to consider. (I never use this word, but X11 really
> "s*cks" on Mac.)

There may be a misunderstanding. I wasn't proposing that they use the
x11 terminal.  I was proposing the we require x11-based wxWidgets+cairo+pan=
go
support libraries for OSX so that the wxWidgets-based wxt terminal can
be built.  As to whether X11 sucks on Mac, I don't know.  People in the
lab here seem to be happy with the OSX ports of X11-based interactive
graphics programs we use.  Maybe a native port would be better yet,
but I don't hear a loud clamor for someone to put in the work.=20

=2D-=20
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

Re: gnuplot with wxt on MacOS, time for decisions

[<tim...@en...>]

Mojca Miklavec wrote:
> On 5/7/07, Ethan Merritt wrote:
>> On Monday 07 May 2007 11:02, Timothée Lecomte wrote:
>> > Dear gnuplot (especially on MacOS) enthusiasts,
>> > Dear Joe, Mojca, who tested wxt on MacOS since its early ages ;),
>> > Dear Nigel, whose remarks inspired me for this mail,
>> >
>> > I have worked a little more on wxt for MacOS this last days.
> Dear Timothée,
>
> Thanks a lot for all your effort.
>
> I really don't have any idea about the "dirty details" of
> implementation, so I might be the wrong person to ask about the
> opinion. But I'm still willing to test (and looking forward to the day
> when I will be able to use the working version of it :). 


Oops, I forgot to put a link to a screenshot I made earlier today, after 
I got solution n°2 working:
http://tipote.free.fr/wxt_mac_20070507.png
(wow, I *love* those transparent surfaces !)

No code yet, but a nice screenshot, isn't it ? Insightful eyes would 
have notices that oversampling is disabled (not much noticeable on these 
plots with few straight lines, and the toolbar icons are bigger than 
they should be)

Timothée

>
> ---
>
> Thanks again for the marvellous work you do,
>    Mojca

Re: gnuplot with wxt on MacOS, time for decisions

[<tim...@en...>]

Mojca Miklavec wrote:
> On 5/7/07, Ethan Merritt wrote:
>> On Monday 07 May 2007 11:02, Timothée Lecomte wrote:
>> > Dear gnuplot (especially on MacOS) enthusiasts,
>> > Dear Joe, Mojca, who tested wxt on MacOS since its early ages ;),
>> > Dear Nigel, whose remarks inspired me for this mail,
>> >
>> > I have worked a little more on wxt for MacOS this last days.
> Dear Timothée,
>
> Thanks a lot for all your effort.
>
> I really don't have any idea about the "dirty details" of
> implementation, so I might be the wrong person to ask about the
> opinion. But I'm still willing to test (and looking forward to the day
> when I will be able to use the working version of it :).

Your user's point of view makes a lot of sense !
>
>> Not really.  I think the prefered options are
>>
>> (4) Fix the upstream package in OSX
>>
>> It seems pointless to spend all that time re-arranging gnuplot only
>> to the benefit of gnuplot users.  The equivalent amount of work on
>> the OSX equivalent of the GTK layer would presumably benefit ports
>> of many other applications to OSX as well.
>
> I wouldn't object the improvement of native GTK handling on Mac (I
> would really like to see Mono working on Mac), but that's probably
> off-topic here and outside the scope ...

Note that there's no GTK involved here. wxMac uses Cocoa and Carbon, the 
native interfaces, directly.

>
>> (5) Use X11 + wxWidgets on OSX rather than the apparently broken
>> native OSX layer (that's possible, right?)
>
> If I had to use X11, I would prefer to stick with AquaTerm, even
> though it's functionality (esp. mouse) is limited. X11 is really the
> last resort to consider. (I never use this word, but X11 really
> "s*cks" on Mac.)
>
> It's as if one would suggest using wine for running gnuplot with
> windows interface on linux instead of using X11 or wxt.
>
> It really is important to have some native driver unless there is no
> other choice.

That's what I've understood. Besides, there's already a plotting program 
in MacOS X, called Grapher if I remember correctly. There would be 
little point in working on wxt if it was a complicated (for the user) 
solution using X11, compared to Aquaterm and Grapher.

> ---
>
> Thanks again for the marvellous work you do,
>    Mojca


Well, thank you for your answer !

Timothée

Re: gnuplot with wxt on MacOS, time for decisions

[Mojca M. <moj...@gm...>]

On 5/7/07, Ethan Merritt wrote:
> On Monday 07 May 2007 11:02, Timoth=E9e Lecomte wrote:
> > Dear gnuplot (especially on MacOS) enthusiasts,
> > Dear Joe, Mojca, who tested wxt on MacOS since its early ages ;),
> > Dear Nigel, whose remarks inspired me for this mail,
> >
> > I have worked a little more on wxt for MacOS this last days.
Dear Timoth=E9e,

Thanks a lot for all your effort.

I really don't have any idea about the "dirty details" of
implementation, so I might be the wrong person to ask about the
opinion. But I'm still willing to test (and looking forward to the day
when I will be able to use the working version of it :).

> Not really.  I think the prefered options are
>
> (4) Fix the upstream package in OSX
>
> It seems pointless to spend all that time re-arranging gnuplot only
> to the benefit of gnuplot users.  The equivalent amount of work on
> the OSX equivalent of the GTK layer would presumably benefit ports
> of many other applications to OSX as well.

I wouldn't object the improvement of native GTK handling on Mac (I
would really like to see Mono working on Mac), but that's probably
off-topic here and outside the scope ...

> (5) Use X11 + wxWidgets on OSX rather than the apparently broken
> native OSX layer (that's possible, right?)

If I had to use X11, I would prefer to stick with AquaTerm, even
though it's functionality (esp. mouse) is limited. X11 is really the
last resort to consider. (I never use this word, but X11 really
"s*cks" on Mac.)

It's as if one would suggest using wine for running gnuplot with
windows interface on linux instead of using X11 or wxt.

It really is important to have some native driver unless there is no
other choice.
---

Thanks again for the marvellous work you do,
    Mojca

Re: gnuplot with wxt on MacOS, time for decisions

[<tim...@en...>]

Ethan Merritt wrote:
> On Monday 07 May 2007 11:02, Timothée Lecomte wrote:
>   
>> Dear gnuplot (especially on MacOS) enthusiasts,
>> Dear Joe, Mojca, who tested wxt on MacOS since its early ages ;),
>> Dear Nigel, whose remarks inspired me for this mail, 
>>
>> I have worked a little more on wxt for MacOS this last days.
>>
>> Fixing it for MacOS is not really straightforward, because I seem to 
>> have abused Linux/GTK/X flexibility so that some things have to be 
>> restricted now.
>>     
>
> [rest of original message now at the end]
>  
>   
>> So, I'd like to know what you think of this. Do you think it's worth 
>> doing all these changes ? 
>>     
>
> Not really.  I think the prefered options are
>
> (4) Fix the upstream package in OSX
>
> It seems pointless to spend all that time re-arranging gnuplot only
> to the benefit of gnuplot users.  The equivalent amount of work on
> the OSX equivalent of the GTK layer would presumably benefit ports
> of many other applications to OSX as well.
>   

Well, I wouldn't say so ;)
First, I don't know of *any* application that use this design. First, I 
can't think of any other application that have to mix command lines from 
stdin with GUI. Then, when I first wrote wxt, I tried my best to make it 
work without changing anything in gnuplot core (and I'm quite proud of 
the result, the current code is *purely* self-contained in the 
"term->..." table!). But it's obviously not the best design. Finally, 
"fixing the upstream" means work on wxWidgets (there may be locking 
issues that could be fixed), which I won't do, or fixing Carbon, which I 
won't do either, cause I'm not paid by Apple ;) Really, the piece that 
needs fixing is wxt/gnuplot.
> or
>
> (5) Use X11 + wxWidgets on OSX rather than the apparently broken
> native OSX layer (that's possible, right?)
>   
It's should be working right now... but it seems that Mac users are 
reluctant to install X11 when they can have a native counterpart.

> I'd like to hear from Per Persson as well (CC'ed)
>
> If you really want to pick from options 1, 2, and 3 I'd go with 
> (1) two single-threaded processes, as in the X11 implementation.
> If nothing else, this makes it easier to debug.
>
>
> 	Ethan
>   
Thanks for your comments, Ethan.
Best regards,

Timothée



>
>
>
>
>
>   
>> The main restriction, as discussed in previous mails, is that the main 
>> thread should do each and every GUI action. Currently, wxt uses a second 
>> thread for the GUI event loop, and happily does things in the first 
>> thread with some mutexes locked. This approach does not work on MacOS.
>>
>> 1st solution, as suggested previously = use two processes:
>>  - this is the design of the x11 terminal. I don't like it, because I 
>> find complicated to have to handle two processes and their 
>> inter-communication where we really have one program (one task).
>>
>> 2nd solution = invert the threads' roles (i.e. the shortest path from 
>> where we are now):
>> - the main thread runs the GUI event loop, and gnuplot gnu_main() 
>> (plot.c:278) runs in the second thread.
>> - terminal callbacks (such as term->graphics, term->text) do every GUI 
>> action asynchronously, by posting messages to the GUI event loop
>> - corner cases:
>>     *signals masks have to be carefully set, so that ^C ends up in the 
>> second thread (easy)
>>     *doing everything asynchronously can be painful, sometimes it's 
>> actually synchronous, so you have to wait for the other thread to finish 
>> before continuing (I am thinking of term->init() where new windows are 
>> created) (easy, but not really beautiful programming)
>>     * this adds a startup overhead, because wxWidgets has to be 
>> initialized at launch-time for the threads facility (I don't see how to 
>> switch the two thread contexts when they are already running) (currently 
>> it's initialized when first used).
>>
>> 3rd solution = use one thread only (the most ambitious)
>>  - the one and only thread is an event loop.
>>  - "a char arrived on stdin" is handled as an event (this is natural, 
>> isn't it?), and passed to readline
>>  - the event loop is actually the GUI loop, just extended to watch stdin 
>> in addition to window events
>>  - no more locking, no more worries about not-so-asynchronous actions, 
>> no more multithreading restrictions to take care of
>>  - it looks like it's the way Nigel Nunn has mentioned for so long
>>  - drawbacks:
>>     * it's the longer way to go from what we have now, involving some 
>> work in some mechanisms and assumptions gnuplot has had since the early 
>> ages probably.
>>     * as for the previous solution, there's a startup overhead because 
>> we would have to initialize the event loop (i.e. wxWidgets)
>>
>> Currently, we have:
>>     while( readline(); do_line(); ) {};
>>
>> Instead we would have an event loop, with the following callbacks:
>>     data_is_available_in_stdin() {rl_callback_read_char ();}
>>     line_is_completed() {do_line();}
>> The event loop naturally processes these events exactly the same way it 
>> does with others, namely GUI events.
>>
>> In practise, a lot of reorganization is needed:
>> - in plot.c, to separate the initialization code, from the actual loop 
>> quoted above,
>> - in command.c and readline.c, to implement the event-based approach, 
>> and to rework the pieces of code that call read_line or getc directly 
>> (builtin-pager, help system, inline data)
>>
>>
>> So, I'd like to know what you think of this. Do you think it's worth 
>> doing all these changes ? Note that if I work on this, I won't change 
>> the way it works when wxt is not compiled in.
>>
>>
>> Best regards,
>>
>> Timothée Lecomte
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> gnuplot-beta mailing list
>> gnu...@li...
>> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>
>>     
>
>   

Re: gnuplot with wxt on MacOS, time for decisions

[<tim...@en...>]

Hans-Bernhard Bröker wrote:
> Timothée Lecomte wrote:
>
>> 1st solution, as suggested previously = use two processes:
>>  - this is the design of the x11 terminal. I don't like it, because I 
>> find complicated to have to handle two processes and their 
>> inter-communication where we really have one program (one task).
>
> I don't really believe inter-communication between threads to be any 
> easier than inter-communication between processes, in the long run. 
> More efficient it may be, but it's not easier.  You basically pay for 
> the extra speed by extra requirements on careful coding.

I agree that both are difficult, in different places. 
Inter-communication in general seems to be worth avoiding.

>
>> 3rd solution = use one thread only (the most ambitious)
>>  - the one and only thread is an event loop.
>>  - "a char arrived on stdin" is handled as an event (this is natural, 
>> isn't it?), and passed to readline
>>  - the event loop is actually the GUI loop, just extended to watch 
>> stdin in addition to window events
>
> That's pretty much the way the Windows native terminal has been doing 
> things since day 1 (and in a pretty nasty way, too, overriding the 
> <stdio.h> functions with macros of our own making).  Which means a bit 
> of synergy might be achievable if you go this way.

That's true, and wxt works on Windows thanks to this ! That's also why 
I've been thinking about that.

>
>> Currently, we have:
>>     while( readline(); do_line(); ) {};
>>
>> Instead we would have an event loop, with the following callbacks:
>>     data_is_available_in_stdin() {rl_callback_read_char ();}
>>     line_is_completed() {do_line();}
>
> Not necessarily.  It's possible to lace the GUI event handling into 
> the readline character input function instead.
>

Right, that's somehow the way it works on Windows (since the "message 
loop" - from Windows terms - is in TermGetCH), and I guess it was part 
of the intent when term->waitforinput was first introduced, since it is 
used as a wrapper for getch().

But in that situation the GUI loop stays at a lower level, run by a 
master loop waiting for commands input. I'd like to have a global and 
single loop, with everything at the same level. I agree that it's not 
that different, but it seems clearer to me.
Note that it's definitely the way the GNU Readline "alternate interface" 
is designed to work 
(http://www.delorie.com/gnu/docs/readline/rlman_41.html) (It is already 
used in gnuplot, but I don't understand why... )

Thanks for your comments,
Best regards,

Timothée

Re: gnuplot with wxt on MacOS, time for decisions

[Ethan M. <merritt@u.washington.edu>]

On Monday 07 May 2007 11:02, Timoth=C3=A9e Lecomte wrote:
> Dear gnuplot (especially on MacOS) enthusiasts,
> Dear Joe, Mojca, who tested wxt on MacOS since its early ages ;),
> Dear Nigel, whose remarks inspired me for this mail,=20
>=20
> I have worked a little more on wxt for MacOS this last days.
>=20
> Fixing it for MacOS is not really straightforward, because I seem to=20
> have abused Linux/GTK/X flexibility so that some things have to be=20
> restricted now.

[rest of original message now at the end]
=20
> So, I'd like to know what you think of this. Do you think it's worth=20
> doing all these changes ?=20

Not really.  I think the prefered options are

(4) Fix the upstream package in OSX

It seems pointless to spend all that time re-arranging gnuplot only
to the benefit of gnuplot users.  The equivalent amount of work on
the OSX equivalent of the GTK layer would presumably benefit ports
of many other applications to OSX as well.

or

(5) Use X11 + wxWidgets on OSX rather than the apparently broken
native OSX layer (that's possible, right?)

I'd like to hear from Per Persson as well (CC'ed)

If you really want to pick from options 1, 2, and 3 I'd go with=20
(1) two single-threaded processes, as in the X11 implementation.
If nothing else, this makes it easier to debug.


	Ethan






> The main restriction, as discussed in previous mails, is that the main=20
> thread should do each and every GUI action. Currently, wxt uses a second=
=20
> thread for the GUI event loop, and happily does things in the first=20
> thread with some mutexes locked. This approach does not work on MacOS.
>=20
> 1st solution, as suggested previously =3D use two processes:
>  - this is the design of the x11 terminal. I don't like it, because I=20
> find complicated to have to handle two processes and their=20
> inter-communication where we really have one program (one task).
>=20
> 2nd solution =3D invert the threads' roles (i.e. the shortest path from=20
> where we are now):
> - the main thread runs the GUI event loop, and gnuplot gnu_main()=20
> (plot.c:278) runs in the second thread.
> - terminal callbacks (such as term->graphics, term->text) do every GUI=20
> action asynchronously, by posting messages to the GUI event loop
> - corner cases:
>     *signals masks have to be carefully set, so that ^C ends up in the=20
> second thread (easy)
>     *doing everything asynchronously can be painful, sometimes it's=20
> actually synchronous, so you have to wait for the other thread to finish=
=20
> before continuing (I am thinking of term->init() where new windows are=20
> created) (easy, but not really beautiful programming)
>     * this adds a startup overhead, because wxWidgets has to be=20
> initialized at launch-time for the threads facility (I don't see how to=20
> switch the two thread contexts when they are already running) (currently=
=20
> it's initialized when first used).
>=20
> 3rd solution =3D use one thread only (the most ambitious)
>  - the one and only thread is an event loop.
>  - "a char arrived on stdin" is handled as an event (this is natural,=20
> isn't it?), and passed to readline
>  - the event loop is actually the GUI loop, just extended to watch stdin=
=20
> in addition to window events
>  - no more locking, no more worries about not-so-asynchronous actions,=20
> no more multithreading restrictions to take care of
>  - it looks like it's the way Nigel Nunn has mentioned for so long
>  - drawbacks:
>     * it's the longer way to go from what we have now, involving some=20
> work in some mechanisms and assumptions gnuplot has had since the early=20
> ages probably.
>     * as for the previous solution, there's a startup overhead because=20
> we would have to initialize the event loop (i.e. wxWidgets)
>=20
> Currently, we have:
>     while( readline(); do_line(); ) {};
>=20
> Instead we would have an event loop, with the following callbacks:
>     data_is_available_in_stdin() {rl_callback_read_char ();}
>     line_is_completed() {do_line();}
> The event loop naturally processes these events exactly the same way it=20
> does with others, namely GUI events.
>=20
> In practise, a lot of reorganization is needed:
> - in plot.c, to separate the initialization code, from the actual loop=20
> quoted above,
> - in command.c and readline.c, to implement the event-based approach,=20
> and to rework the pieces of code that call read_line or getc directly=20
> (builtin-pager, help system, inline data)
>=20
>=20
> So, I'd like to know what you think of this. Do you think it's worth=20
> doing all these changes ? Note that if I work on this, I won't change=20
> the way it works when wxt is not compiled in.
>=20
>=20
> Best regards,
>=20
> Timoth=C3=A9e Lecomte
>=20
>=20
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>=20

=2D-=20
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

Re: gnuplot with wxt on MacOS, time for decisions

[<HBB...@t-...>]

Timothée Lecomte wrote:

> 1st solution, as suggested previously = use two processes:
>  - this is the design of the x11 terminal. I don't like it, because I 
> find complicated to have to handle two processes and their 
> inter-communication where we really have one program (one task).

I don't really believe inter-communication between threads to be any 
easier than inter-communication between processes, in the long run. 
More efficient it may be, but it's not easier.  You basically pay for 
the extra speed by extra requirements on careful coding.

> 3rd solution = use one thread only (the most ambitious)
>  - the one and only thread is an event loop.
>  - "a char arrived on stdin" is handled as an event (this is natural, 
> isn't it?), and passed to readline
>  - the event loop is actually the GUI loop, just extended to watch stdin 
> in addition to window events

That's pretty much the way the Windows native terminal has been doing 
things since day 1 (and in a pretty nasty way, too, overriding the 
<stdio.h> functions with macros of our own making).  Which means a bit 
of synergy might be achievable if you go this way.

> Currently, we have:
>     while( readline(); do_line(); ) {};
> 
> Instead we would have an event loop, with the following callbacks:
>     data_is_available_in_stdin() {rl_callback_read_char ();}
>     line_is_completed() {do_line();}

Not necessarily.  It's possible to lace the GUI event handling into the 
readline character input function instead.

gnuplot with wxt on MacOS, time for decisions

[<tim...@en...>]

Dear gnuplot (especially on MacOS) enthusiasts,
Dear Joe, Mojca, who tested wxt on MacOS since its early ages ;),
Dear Nigel, whose remarks inspired me for this mail,


I have worked a little more on wxt for MacOS this last days.

Fixing it for MacOS is not really straightforward, because I seem to 
have abused Linux/GTK/X flexibility so that some things have to be 
restricted now.

The main restriction, as discussed in previous mails, is that the main 
thread should do each and every GUI action. Currently, wxt uses a second 
thread for the GUI event loop, and happily does things in the first 
thread with some mutexes locked. This approach does not work on MacOS.

1st solution, as suggested previously = use two processes:
 - this is the design of the x11 terminal. I don't like it, because I 
find complicated to have to handle two processes and their 
inter-communication where we really have one program (one task).

2nd solution = invert the threads' roles (i.e. the shortest path from 
where we are now):
- the main thread runs the GUI event loop, and gnuplot gnu_main() 
(plot.c:278) runs in the second thread.
- terminal callbacks (such as term->graphics, term->text) do every GUI 
action asynchronously, by posting messages to the GUI event loop
- corner cases:
    *signals masks have to be carefully set, so that ^C ends up in the 
second thread (easy)
    *doing everything asynchronously can be painful, sometimes it's 
actually synchronous, so you have to wait for the other thread to finish 
before continuing (I am thinking of term->init() where new windows are 
created) (easy, but not really beautiful programming)
    * this adds a startup overhead, because wxWidgets has to be 
initialized at launch-time for the threads facility (I don't see how to 
switch the two thread contexts when they are already running) (currently 
it's initialized when first used).

3rd solution = use one thread only (the most ambitious)
 - the one and only thread is an event loop.
 - "a char arrived on stdin" is handled as an event (this is natural, 
isn't it?), and passed to readline
 - the event loop is actually the GUI loop, just extended to watch stdin 
in addition to window events
 - no more locking, no more worries about not-so-asynchronous actions, 
no more multithreading restrictions to take care of
 - it looks like it's the way Nigel Nunn has mentioned for so long
 - drawbacks:
    * it's the longer way to go from what we have now, involving some 
work in some mechanisms and assumptions gnuplot has had since the early 
ages probably.
    * as for the previous solution, there's a startup overhead because 
we would have to initialize the event loop (i.e. wxWidgets)

Currently, we have:
    while( readline(); do_line(); ) {};

Instead we would have an event loop, with the following callbacks:
    data_is_available_in_stdin() {rl_callback_read_char ();}
    line_is_completed() {do_line();}
The event loop naturally processes these events exactly the same way it 
does with others, namely GUI events.

In practise, a lot of reorganization is needed:
- in plot.c, to separate the initialization code, from the actual loop 
quoted above,
- in command.c and readline.c, to implement the event-based approach, 
and to rework the pieces of code that call read_line or getc directly 
(builtin-pager, help system, inline data)


So, I'd like to know what you think of this. Do you think it's worth 
doing all these changes ? Note that if I work on this, I won't change 
the way it works when wxt is not compiled in.


Best regards,

Timothée Lecomte

z_floor and z_ceiling patch update

[Daniel J S. <dan...@ie...>]

I updated bug patch:

[ 1488168 ] z_floor and z_ceiling based on xyplane.absolute

Should be ready to go if someone wants to check it into CVS.

Dan

Re: RGBA image mode (patchset #1589067)

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:

> - The only real use I can think of:  painting a heat map onto a surface in 3D,
>   for instance a pm3d representation of electrostatic potential at the surface
>   of a cube, and then making it semi-transparent so that you can see other plot
>   elements (3D vector fields?) through it.  The thing is, you can *already* do
>   this in gnuplot, using the new "set style fill transparent solid <alpha>" and
>   pm3d quadrilaterals.  It would only require an RGBA mode if you had a need to
>   map a pre-existing image onto the surface, and even then only if each pixel
>   had a separate alpha value.  Are there any such real-world cases?

This seems the best example I can think of.  But I, like Timothée, imagine the 
general alpha channel could be of benefit to someone, especially in the areas of 
image processing.

And if only for the ability to draw non-rectangular images it might be worth it. 
  With that, someone could put a logo on the plot or something.  (Then again, 
that might be possible similar to that cow milk production example.)

Dan

Re: RGBA image mode (patchset #1589067)

[<tim...@en...>]

Ethan A Merritt wrote:
> On Saturday 05 May 2007 15:03, Ethan A Merritt wrote:
>   
>> Even after fixing a bug in unpacking the alpha channel in gp_cairo.c,
>> I can't get the wxt/cairopdf implementation of this patch to work properly.
>> I'm thinking that maybe the sub-pixel antialiasing in the cairo library is
>> messing things up. 
>>     
>
>   
See the fix on the patch page on sf.net.

> Recent versions of cairo provide a routine cairo_paint_with_alpha( image, alpha )
> This seems to work, but it applies the same alpha value to the whole image,
> not a pixel-by-pixel value.
>
> That causes me to wonder, do we really need a full RGBA format?
> For real-world usage it might be sufficient to apply the alpha value 
> from "set style fill transparent ..." to the whole image.
>
> It gets right back to the question of what an alpha channel capability
> would really be used for.
>
> Let's throw it back to the mailing list:
>
> Hey everyone,
>
> If it were possible to handle a separate alpha channel (partial transparency)
> in gnuplot's  "with image" or "with rgbimage" mode, what would you use it for?
>   
I've tried to think about that for a little while, and unfortunately I 
cannot think of anything related in my plotting experiences. However, 
the concept of layers (with an alpha channel, obviously) is pretty 
powerful as far as drawing programs are concerned. I would be surprised 
if this, applied to gnuplot, would be of no value.

Thanks for your work on this. Best regards,

Timothée

RGBA image mode (patchset #1589067)

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 05 May 2007 15:03, Ethan A Merritt wrote:
> Even after fixing a bug in unpacking the alpha channel in gp_cairo.c,
> I can't get the wxt/cairopdf implementation of this patch to work properly.
> I'm thinking that maybe the sub-pixel antialiasing in the cairo library is
> messing things up. 

Recent versions of cairo provide a routine cairo_paint_with_alpha( image, alpha )
This seems to work, but it applies the same alpha value to the whole image,
not a pixel-by-pixel value.

That causes me to wonder, do we really need a full RGBA format?
For real-world usage it might be sufficient to apply the alpha value 
from "set style fill transparent ..." to the whole image.

It gets right back to the question of what an alpha channel capability
would really be used for.

Let's throw it back to the mailing list:

Hey everyone,

If it were possible to handle a separate alpha channel (partial transparency)
in gnuplot's  "with image" or "with rgbimage" mode, what would you use it for?
My thoughts:

- You could overlay an image (e.g. a map) onto a plot.  But you don't really
  need an alpha channel for this, because you could draw the map first and then
  plot on top of it.

- You could use an arbitrary non-rectangular bitmap image as a point style.
  Each point could be a litte icon.  Cute, but is it really useful?

- The only real use I can think of:  painting a heat map onto a surface in 3D,
  for instance a pm3d representation of electrostatic potential at the surface
  of a cube, and then making it semi-transparent so that you can see other plot
  elements (3D vector fields?) through it.  The thing is, you can *already* do
  this in gnuplot, using the new "set style fill transparent solid <alpha>" and
  pm3d quadrilaterals.  It would only require an RGBA mode if you had a need to
  map a pre-existing image onto the surface, and even then only if each pixel
  had a separate alpha value.  Are there any such real-world cases?


-- 
Ethan A Merritt

alpha image

[Daniel J S. <dan...@ie...>]

Mojca,

Just wondering if you have a real word example of an alpha image and its 
application for a plot.  Can you think of any data or combination of data where 
you'd like to do alpha compositing?

Dan