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

Re: Lua/tikz terminal for DJGPP binary (Re: Getting ready to put out a 4.6 release candidate)

[Ethan A M. <sf...@us...>]

> Hello
> 
> Current dggpp binary from cvs source that I have been distributed experimentally includes the lua/tikz terminal.
> 
> For the official 4.6 release, will the lua/tikz be included?

  So far as I know, yes.
  Is there some reason not to include it?

	Ethan

> Regards
> Tatsuro  
> 

Lua/tikz terminal for DJGPP binary (Re: Getting ready to put out a 4.6 release candidate)

[Tatsuro M. <tma...@ya...>]

Hello

Current dggpp binary from cvs source that I have been distributed experimentally includes the lua/tikz terminal.

For the official 4.6 release, will the lua/tikz be included?

Regards

Tatsuro  


--- On Tue, 2012/1/3, sfeam (Ethan Merritt)  wrote:

> Over the holidays I resolved several long-standing bugs related to 
> the helper threads forked by the wxt and qt terminals.
> This should take care of reported problems with zombie processes,
> truncated history files, and program failures if mouse and keyboard
> events arrive out of the expected order.  The qt terminal is now
> acting very reliably for me under linux, which is a big improvement.
> 
> So my list of must-fix-for-4.6 items is now empty.
> 
> Does anyone know of issues that should be addressed before putting 
> out a version 4.6.rc1 release candidate?
> 
> You can have a look at a draft announcement on the News section of
> the gnuplot home page.
> 
>         Happy New Year!
> 
>             Ethan
> 
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create 
> new or port existing apps to sell to consumers worldwide. Explore the 
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: index in fit

[Peter J. <pet...@gm...>]

On Tue, Jan 17, 2012 at 3:02 AM, sfeam (Ethan Merritt)
<eam...@gm...> wrote:
> On Monday, 16 January 2012, pl...@pi... wrote:
>> On 01/16/12 16:41, Peter Juhasz wrote:
>> > On Mon, Jan 16, 2012 at 10:50 AM,<pl...@pi...>  wrote:
>> >> Hi,
>> >>
>> >> I am wanting to run fit on each section of a long, indexed datafile.
>> >> While the symmetry of the syntax between plot and fit means this is
>> >> syntactically possible, it is in fact useless since only the final
>> >> fitted parameters are retained.
>> >> [...]
>> >
>> > With the soon-to-be-released new version it is possible to do the following:
>> >
>> > do for [i=0:10] {
>> >      fit a*x+b 'data.dat' index i via a,b
>> >      # do whatever you want with a,b, for example
>> >      eval(sprintf("a_%d=a;b_%d=b",i,i))
>> > }
>> >
>> > Péter Juhász
>> > }
>> >
>>
>> Hey , I can already do it !
>>
>> I have a recent cvs build , I just thought this was still in long term
>> future planning. Brilliant.
>>
>> I see it is under 'help do' but not 'help for'.
>>
>> gnuplot> help for
>> Ambiguous request 'for'; possible matches:
>>          format
>>          fortran
>>
>> Probably helpful to include it there too.
>>
>> Thanks to the team for including this already , this opens up a word of
>> possibilities.
>> thanks Péter for bringing me upto date.
>>
>> Is there any overall documentation for the new block structures or do I
>> have to guess the keywords to get individual syntax?
>
> There's an introduction under "help new-features".
> The inclusion of a New Features section works better in the printed
> docs than it does in the on-line help.
>

Perhaps the pointer to 'help new-features' could be added to the
splash screen, at least for the first 4.6 series release.

Péter Juhász

Re: index in fit

[sfeam (E. Merritt) <eam...@gm...>]

On Monday, 16 January 2012, pl...@pi... wrote:
> On 01/16/12 16:41, Peter Juhasz wrote:
> > On Mon, Jan 16, 2012 at 10:50 AM,<pl...@pi...>  wrote:
> >> Hi,
> >>
> >> I am wanting to run fit on each section of a long, indexed datafile.
> >> While the symmetry of the syntax between plot and fit means this is
> >> syntactically possible, it is in fact useless since only the final
> >> fitted parameters are retained.
> >> [...]
> >
> > With the soon-to-be-released new version it is possible to do the following:
> >
> > do for [i=0:10] {
> >      fit a*x+b 'data.dat' index i via a,b
> >      # do whatever you want with a,b, for example
> >      eval(sprintf("a_%d=a;b_%d=b",i,i))
> > }
> >
> > Péter Juhász
> > }
> >
> 
> Hey , I can already do it !
> 
> I have a recent cvs build , I just thought this was still in long term 
> future planning. Brilliant.
> 
> I see it is under 'help do' but not 'help for'.
> 
> gnuplot> help for
> Ambiguous request 'for'; possible matches:
>          format
>          fortran
> 
> Probably helpful to include it there too.
> 
> Thanks to the team for including this already , this opens up a word of 
> possibilities.
> thanks Péter for bringing me upto date.
> 
> Is there any overall documentation for the new block structures or do I 
> have to guess the keywords to get individual syntax?

There's an introduction under "help new-features".
The inclusion of a New Features section works better in the printed 
docs than it does in the on-line help.

Re: Getting ready to put out a 4.6 release candidate

[Tatsuro M. <tma...@ya...>]

Hello

I have checked out the recent 4.6 cvs source.
I have confirmed the windows installer can be made using this source tree.

I will check cygwin and djgpp.

Regards

Tatsuro


--- On Sat, 2012/1/7, Tatsuro MATSUOKA 

> Hello
> 
> --- On Fri, 2012/1/6, Bastian Märkisch  wrote:
> 
> > Please note that it is possible to include extra files in the binary 
> > distribution by specifying an EXTRADIST directory in Makefile.
> 
> Oops! I have overlooked. Thank you for your pointing.
> 
> Regards
> 
> Tatsuro 
> 
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual 
> desktops for less than the cost of PCs and save 60% on VDI infrastructure 
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: contents of docs directory in windows binaries

[Tatsuro M. <tma...@ya...>]

Hello

Current uploaded cvs binary uses your change in documentation system.
It worked very fine.

Thanks a lot!!

Regards

Tatsuro

--- On Tue, 2012/1/17, Bastian Märkisch  wrote:

> You can now use config/mingw/Makefile to create most of the 
> documentation. Try `make docs`.
> 
> The installer will now include the following files in docs/
>    FAQ.pdf, gpcard.pdf, gnuplot.pdf, tutorial.pdf,
> and in docs/psdoc/
>    ps_file.doc ps_fontfile_doc.ps|pdf, ps_guide.ps|pdf ps_symbols.ps|pdf
> 
> The source files where left out intentionally. Please let me know if 
> that is ok now.
> 
>    Bastian
> 
> 
> Am 24.12.2011 01:03, schrieb Tatsuro MATSUOKA:
> (snip)
> >> Seeing the contents made by config/mingw/Makefile, contents of docs directory is changed.
> >> The windows binaries so far have the following in docs directory,
> >>
> >> docs
> >>    FAQ.pdf
> >>    gnuplot.pdf
> >>    gpcard.pdf
> >> docs/postscript-terminal
> >>    ps_file.doc
> >>    ps_fontfile_doc.tex
> >>    ps_fontfile_doc.zip
> >>    ps_guide.ps
> >>    ps_symbols.gp
> >>    ps_symbols.gpi
> >>    ps_symbols.ps
> >>    README
> >>
> >> docs/tutorial
> >>    tutorial.pdf
> >>    README
> >>
> >> In new docs directory, I found
> >>   BUGS
> >>   ChangeLog
> >>   gnuplot.pdf
> >>   README
> >>
> >> ******************
> >> My preference is old style contents in docs directory.
> >>
> >> I think that it is better to discuss the contents in docs for windows binaries.
> >>
> >> Regards
> >>
> >> Tatsuro
> 

Re: index in fit

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

On 01/16/12 16:41, Peter Juhasz wrote:
> On Mon, Jan 16, 2012 at 10:50 AM,<pl...@pi...>  wrote:
>> Hi,
>>
>> I am wanting to run fit on each section of a long, indexed datafile.
>> While the symmetry of the syntax between plot and fit means this is
>> syntactically possible, it is in fact useless since only the final
>> fitted parameters are retained.
>> [...]
>
> With the soon-to-be-released new version it is possible to do the following:
>
> do for [i=0:10] {
>      fit a*x+b 'data.dat' index i via a,b
>      # do whatever you want with a,b, for example
>      eval(sprintf("a_%d=a;b_%d=b",i,i))
> }
>
> Péter Juhász
> }
>

Hey , I can already do it !

I have a recent cvs build , I just thought this was still in long term 
future planning. Brilliant.

I see it is under 'help do' but not 'help for'.

gnuplot> help for
Ambiguous request 'for'; possible matches:
         format
         fortran

Probably helpful to include it there too.

Thanks to the team for including this already , this opens up a word of 
possibilities.
thanks Péter for bringing me upto date.

Is there any overall documentation for the new block structures or do I 
have to guess the keywords to get individual syntax?


regards, Peter.

Re: contents of docs directory in windows binaries

[Bastian M. <bma...@we...>]

You can now use config/mingw/Makefile to create most of the 
documentation. Try `make docs`.

The installer will now include the following files in docs/
   FAQ.pdf, gpcard.pdf, gnuplot.pdf, tutorial.pdf,
and in docs/psdoc/
   ps_file.doc ps_fontfile_doc.ps|pdf, ps_guide.ps|pdf ps_symbols.ps|pdf

The source files where left out intentionally. Please let me know if 
that is ok now.

   Bastian


Am 24.12.2011 01:03, schrieb Tatsuro MATSUOKA:
(snip)
>> Seeing the contents made by config/mingw/Makefile, contents of docs directory is changed.
>> The windows binaries so far have the following in docs directory,
>>
>> docs
>>    FAQ.pdf
>>    gnuplot.pdf
>>    gpcard.pdf
>> docs/postscript-terminal
>>    ps_file.doc
>>    ps_fontfile_doc.tex
>>    ps_fontfile_doc.zip
>>    ps_guide.ps
>>    ps_symbols.gp
>>    ps_symbols.gpi
>>    ps_symbols.ps
>>    README
>>
>> docs/tutorial
>>    tutorial.pdf
>>    README
>>
>> In new docs directory, I found
>>   BUGS
>>   ChangeLog
>>   gnuplot.pdf
>>   README
>>
>> ******************
>> My preference is old style contents in docs directory.
>>
>> I think that it is better to discuss the contents in docs for windows binaries.
>>
>> Regards
>>
>> Tatsuro

Re: index in fit

[Peter J. <pet...@gm...>]

On Mon, Jan 16, 2012 at 10:50 AM,  <pl...@pi...> wrote:
> Hi,
>
> I am wanting to run fit on each section of a long, indexed datafile.
> While the symmetry of the syntax between plot and fit means this is
> syntactically possible, it is in fact useless since only the final
> fitted parameters are retained.
> [...]

With the soon-to-be-released new version it is possible to do the following:

do for [i=0:10] {
    fit a*x+b 'data.dat' index i via a,b
    # do whatever you want with a,b, for example
    eval(sprintf("a_%d=a;b_%d=b",i,i))
}

Péter Juhász
}

index in fit

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

Hi,

I am wanting to run fit on each section of a long, indexed datafile. 
While the symmetry of the syntax between plot and fit means this is 
syntactically possible, it is in fact useless since only the final 
fitted parameters are retained.

A similar problem occurs if I split the data file into separate files 
and use the iteration feature.


help fit states:

  <datafile> is treated as in the `plot` command.  All the `plot datafile`
  modifiers (`using`, `every`,...) except `smooth` and the deprecated `thru`
  are applicable to `fit`. See `plot datafile`.



help plot | datafile :

  Syntax:
        plot '<file_name>' {binary <binary list>}
                           {{nonuniform} matrix}
                           {index <index list> | index "<name>"}
                           {every <every list>}
                           {thru <thru expression>}
                           {using <using list>}
                           {smooth <option>}
                           {volatile} {noautoscale}


One work around would be to try to process the fit log but since there 
are other calls to fit this seems error prone and cumbersome.

 >>
Final set of parameters            Asymptotic Standard Error
=======================            ==========================

Td              = -0.294853        +/- 0.003685     (1.25%)

 >>


A more optimal solution that would take full advantage of what is 
possible in the syntax but seems currently in-exploitable would be if 
the final fit results were stored in an internal array in the variable 
name space for each call to fit.

Thus a call to fit with an iteration or an indexed datafile would 
produce an array of all the fit results (presumably with NaN if the fit 
fails).


regards, Peter.

unable to access namespace after breaking into fit

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

Hi,

having had to interrupt the execution of a fit command, I discover I can 
no longer access the variable name space.

gnuplot> print  first_start
gnuplot>

note it does not show it undefined but returns a null result.

if I do 'show all' it does display the expected values.

gnuplot> show all

...
         first_start = 1820
         last_start = 1974
....

regards, Peter.

Re: [ gnuplot-Bugs-3468950 ] Qt, moc and uic not found on Mac OS X

[Ethan A M. <eam...@gm...>]

On Tuesday, 10 January 2012, Tait wrote:
> > $ ./gnuplot             # terminal defaults to qt
> > gnuplot> plot x         # so far, so good
> > 
> > [in another terminal window]
> > $ ps -efT | grep gnuplot           # both ./gnuplot and gnuplot_qt visible
> > $ kill -9 <pid of ./gnuplot>
> > $ ps -efT | grep gnuplot           # gnuplot_qt is visible, ./gnuplot is gone
> > ...
> > I think the problem is that if the parent process dies hard,
> > either from an unintentional segfault or from receiving a KILL signal,
> > then any atexit() processing that would have sent a signal to the 
> > child doesn't happen.
> > ... 
> 
> The definition of a -9 kill is that the killed process CANNOT
> catch/handle/ignore the signal, receives no warning, and has no
> opportunity to clean up. 

Exactly. That was the point of the test.
I wanted to reproduce a condition where the parent process did not
send a signal to the child. 

> Maybe you were thinking of a kill -1 (the
> default), which sends a sighup? A process would normally catch this and
> do the usual clean up before dying.

For what it's worth, I see exactly the same behaviour if I send
kill -HUP.

> The Qt discussion is way beyond my understanding, but the mechanism
> I've seen before for children to die gracefully when a parent dies is
> to keep a pipe open to the parent process, and then react to the
> sigpipe the child would receive if the parent died.

The issue is complicated somewhat by gnuplot's "-persist" option.
If "persist" is set, then the plot window is supposed to remain on
display even though the parent process has exited.  Of course you 
are also supposed to be able to close/kill the display itself when
you are done with it.  I squashed a bug in the earlier CVS version
of the qt driver that left you unable to get rid of the child window
if it had already been closed at the time "persist" mode was enabled.
The equivalent problem may have recurred in the fork/exec variant.

However, I was _not_ using the -persist option in my tests.
But it is possible, I suppose, that the code is incorrectly executing 
that path anyhow.  

Jérôme:
Is it possible that the setting from
   setQuitOnLastWindowClosed(false)
is persistent across Qt sessions?  That is, maybe that setting is
handled by the QSettings mechanism that you already described for
the background color?

	Ethan


-- 
Tradition is not the worship of ashes, but the preservation of fire.
  - Gustav Mahler

Re: [ gnuplot-Bugs-3468950 ] Qt, moc and uic not found on Mac OS X

[Tait <gnu...@t4...>]

> $ ./gnuplot             # terminal defaults to qt
> gnuplot> plot x         # so far, so good
> 
> [in another terminal window]
> $ ps -efT | grep gnuplot           # both ./gnuplot and gnuplot_qt visible
> $ kill -9 <pid of ./gnuplot>
> $ ps -efT | grep gnuplot           # gnuplot_qt is visible, ./gnuplot is gone
> ...
> I think the problem is that if the parent process dies hard,
> either from an unintentional segfault or from receiving a KILL signal,
> then any atexit() processing that would have sent a signal to the 
> child doesn't happen.
> ... 

The definition of a -9 kill is that the killed process CANNOT
catch/handle/ignore the signal, receives no warning, and has no
opportunity to clean up. Maybe you were thinking of a kill -1 (the
default), which sends a sighup? A process would normally catch this and
do the usual clean up before dying.

The Qt discussion is way beyond my understanding, but the mechanism
I've seen before for children to die gracefully when a parent dies is
to keep a pipe open to the parent process, and then react to the
sigpipe the child would receive if the parent died.

Re: contents of docs directory in windows binaries

[Tatsuro M. <tma...@ya...>]

Hello

Now contents in Extra.zip are included in the distribution in installer style.

Regards

Tatsuro

--- On Sat, 2011/12/24, Tatsuro MATSUOKA wrote:

> Hello
> > My preference is old style contents in docs directory.
> gpcard.pdf seems to be out dated so that it might be omitted.
> 
> BTW, tutorial.pdf can be made with out .prepare and .configure,
> 
> gnuplot eg1.plt
> gnuplot eg2.plt
> gnuplot eg3.plt
> gnuplot eg4.plt
> gnuplot eg5.plt
> gnuplot eg6.plt
> gnuplot eg7.plt
> gnuplot linepoin.plt
> gnuplot test.plt
> gnuplot test_tikz.plt
> latex tutorial.tex
> dvips tutorial.dvi
> ps2pdf tutorial.ps tutorial.pdf
> 
> Regards
> 
> Anyway at the moment, I will distribute current omitted old doc files separately from installer.
> 
> Tatsuro
> --- On Sat, 2011/12/24, Tatsuro MATSUOKA  wrote:
> 
> > Hello
> > 
> > Thanks to grate efforts by Bastian Maerkisch, I could make windows cvs binary with installer.
> > 
> > Seeing the contents made by config/mingw/Makefile, contents of docs directory is changed.
> > The windows binaries so far have the following in docs directory,
> > 
> > docs
> >   FAQ.pdf
> >   gnuplot.pdf
> >   gpcard.pdf 
> > docs/postscript-terminal
> >   ps_file.doc
> >   ps_fontfile_doc.tex
> >   ps_fontfile_doc.zip
> >   ps_guide.ps
> >   ps_symbols.gp
> >   ps_symbols.gpi
> >   ps_symbols.ps
> >   README
> > 
> > docs/tutorial
> >   tutorial.pdf
> >   README
> > 
> > In new docs directory, I found
> >  BUGS
> >  ChangeLog
> >  gnuplot.pdf
> >  README
> > 
> > ******************
> > My preference is old style contents in docs directory.
> > 
> > I think that it is better to discuss the contents in docs for windows binaries.
> > 
> > Regards
> > 
> > Tatsuro
> > 
> > ------------------------------------------------------------------------------
> > Write once. Port to many.
> > Get the SDK and tools to simplify cross-platform app development. Create 
> > new or port existing apps to sell to consumers worldwide. Explore the 
> > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> > http://p.sf.net/sfu/intel-appdev
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> 
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create 
> new or port existing apps to sell to consumers worldwide. Explore the 
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: borders.dem fails in the current cvs tip

[Tatsuro M. <tma...@ya...>]

Hello

I have confirmed the fix.

Thanks!

Regards

Tatsuro

--- On Tue, 2012/1/10, Ethan A Merrittwrote:

> > Hello
> > 
> > I have check out the latest cvs tips.
> > On the MinGW, all.dem went well.  Thanks!
> > 
> > However, on the Cygwin, 'make check' did not work due to the following 
> > make[2]: *** No rule to make target `../term/mac.trm', needed by `term.o'.  Stop.
> > 
> > The error might be imported recent change for mac.trm
> 
> I do not understand why Cygwin would ever try to include the macintosh
> terminal in term.o.
> 
> However, I did miss one place where mac.trm was mentioned.  ../src/makefile.all
> I have now removed it.  Perhaps that will fix the problem.
> 
>     Ethan
> 

Re: [ gnuplot-Bugs-3468950 ] Qt, moc and uic not found on Mac OS X

[sfeam (E. Merritt) <eam...@gm...>]

On Monday, 09 January 2012, Jérôme Lodewyck wrote:
> Le Dimanche 8 Janvier 2012 21:55:35 vous avez écrit :
> > I have been running with this one (version 2) under linux.
> > It looks pretty good.  Over the day or so of testing I've accumulated
> > 3 zombie gnuplot_qt processes, however.  So there's a termination
> > condition that's being missed somewhere.
> 
> I tried very hard to crash it but failed to reproduce your observation. Each 
> time I get a gnuplot_qt zombie, there is a gnuplot one, and killing the later 
> kills the former. 

I wasn't really trying to crash anything.  I was just trying to debug
other, unrelated, problems.  Sometimes the program would crash.
Apparently some of those times it would leave behind a zombie.
I didn't notice till later, so I can't tell you exactly what I was 
doing at the time.  

Nevertheless, I think I can now reproduce it consistently.
This is today's CVS with your patch #2 applied.
Here is a recipe:

$ ./gnuplot             # terminal defaults to qt
gnuplot> plot x         # so far, so good

[in another terminal window]
$ ps -efT | grep gnuplot           # both ./gnuplot and gnuplot_qt visible
$ kill -9 <pid of ./gnuplot>
$ ps -efT | grep gnuplot           # gnuplot_qt is visible, ./gnuplot is gone

[close the qt plot window by clicking 'X' in the window title bar]
$ ps -efT | grep gnuplot           # gnuplot_qt is now a zombie

I think the problem is that if the parent process dies hard,
either from an unintentional segfault or from receiving a KILL signal,
then any atexit() processing that would have sent a signal to the 
child doesn't happen.

I thought at first that maybe this only happened if the child
window was closed at the time the parent process was killed, 
but apparently that doesn't matter.

So what I see doesn't seem to match what you see, since you say that if
you kill the parent process then the child process dies also.
That isn't happening here.

> An interesting question would be whether the zombies you 
> observed are still reachable by starting a new gnuplot and entering
> 	set term qt widget "qtgnuplotXXX"
> where XXX is the pid of the zombie gnuplot_qt.

Yes, that works.
So strictly speaking they are not zombies.  But they will sit forever
in that state unless you do something clever.

	cheers,

		Ethan

Re: borders.dem fails in the current cvs tip

[Ethan A M. <sf...@us...>]

> Hello
> 
> I have check out the latest cvs tips.
> On the MinGW, all.dem went well.  Thanks!
> 
> However, on the Cygwin, 'make check' did not work due to the following 
> make[2]: *** No rule to make target `../term/mac.trm', needed by `term.o'.  Stop.
> 
> The error might be imported recent change for mac.trm

I do not understand why Cygwin would ever try to include the macintosh
terminal in term.o.

However, I did miss one place where mac.trm was mentioned.  ../src/makefile.all
I have now removed it.  Perhaps that will fix the problem.

	Ethan

Re: borders.dem fails in the current cvs tip

[Tatsuro M. <tma...@ya...>]

Hello

I have misled the status for MinGW.
The MinGW build failed at

gcc -shared-libgcc -c -I/c/Programs/gplibs/include -fno-keep-inline-dllexport -O3 -I. -I../../src -D_Windows -DHAVE_CONFIG_H -DPIPES -DWGP_CONSOLE -DCONSOLE_SWITCH_CP -DUSE_MOUSE=1 -DWIN_IPC -DWITH_HTML_HELP -I/c/PROGRA~2/HELPWO~1/include -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_LIBGD -DHAVE_GD_H -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG -DHAVE_GD_JPEG -DHAVE_GD_TTF -DHAVE_CAIROPDF -DWXWIDGETS -DHAVE_LUA -DHAVE_ICONV  -o tabulate.co ../../src/tabulate.c
make[1]: *** No rule to make target `../../term/mac.trm', needed by `term.co'.  Stop.
make[1]: Leaving directory `/home/gnuplotcvs/gnuplot/config/mingw'
make: *** [console] Error 2

Regards

Tatsuro

--- On Tue, 2012/1/10, Tatsuro MATSUOKA wrote:

> Hello
> 
> I have check out the latest cvs tips.
> On the MinGW, all.dem went well.  Thanks!
> 
> However, on the Cygwin, 'make check' did not work due to the following 
> make[2]: *** No rule to make target `../term/mac.trm', needed by `term.o'.  Stop.
> 
> The error might be imported recent change for mac.trm
> 
> ******************************************************
> 2012-01-09  Ethan A Merritt  <merritt@u.washington.edu>
> 
>     * docs/Makefile.in src/term.h src/makefile.awc term/mac.trm:
>     Remove vestigial terminal wrapper (contents are long gone).
> *********************************************************
> 
> Regards
> 
> Tatsuro
> --- On Mon, 2012/1/9, sfeam (Ethan Merritt)  wrote:
> 
> > On Sunday, 08 January 2012, Tatsuro MATSUOKA wrote:
> > > Hello
> > > 
> > > borders.dem fails in the current cvs tip
> > > 
> > > ********************** file borders.dem *********************
> > > 
> > >         border is not drawn
> > > 
> > > 
> > > ;
> > >     set border bb;
> > >     show border;
> > >     set label 1 "Border = %.0f",bb  at 5,5 center;
> >                   ^^^^^^^^^^^^^^^^^^      
> > Deprecated syntax.
> > 
> > I added that syntax to the set of deprecated constructions
> > covered by ./configure --with-backwards-compatibility
> > but I didn't realize any of the demos used it.
> > 
> > The demo should now be updated to 
> > 
> >       set label 1 sprintf("Border = %.0f",bb) at 5,5 center
> > 
> > 
> >     Ethan
> > 
> > 
> > >     plot 1/0 notitle;
> > > 
> > >                                                                      ^
> > > line 15: ';' expected
> > > 
> > > This happens in both MinGW and Cygwin.
> > > 
> > > Regards
> > > 
> > > Tatsuro
> > 
> 
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual 
> desktops for less than the cost of PCs and save 60% on VDI infrastructure 
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: borders.dem fails in the current cvs tip

[Tatsuro M. <tma...@ya...>]

Hello

I have check out the latest cvs tips.
On the MinGW, all.dem went well.  Thanks!

However, on the Cygwin, 'make check' did not work due to the following 
make[2]: *** No rule to make target `../term/mac.trm', needed by `term.o'.  Stop.

The error might be imported recent change for mac.trm

******************************************************
2012-01-09  Ethan A Merritt  <merritt@u.washington.edu>

	* docs/Makefile.in src/term.h src/makefile.awc term/mac.trm:
	Remove vestigial terminal wrapper (contents are long gone).
*********************************************************

Regards

Tatsuro
--- On Mon, 2012/1/9, sfeam (Ethan Merritt)  wrote:

> On Sunday, 08 January 2012, Tatsuro MATSUOKA wrote:
> > Hello
> > 
> > borders.dem fails in the current cvs tip
> > 
> > ********************** file borders.dem *********************
> > 
> >         border is not drawn
> > 
> > 
> > ;
> >     set border bb;
> >     show border;
> >     set label 1 "Border = %.0f",bb  at 5,5 center;
>                   ^^^^^^^^^^^^^^^^^^      
> Deprecated syntax.
> 
> I added that syntax to the set of deprecated constructions
> covered by ./configure --with-backwards-compatibility
> but I didn't realize any of the demos used it.
> 
> The demo should now be updated to 
> 
>       set label 1 sprintf("Border = %.0f",bb) at 5,5 center
> 
> 
>     Ethan
> 
> 
> >     plot 1/0 notitle;
> > 
> >                                                                      ^
> > line 15: ';' expected
> > 
> > This happens in both MinGW and Cygwin.
> > 
> > Regards
> > 
> > Tatsuro
> 

Re: Qt terminal

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

2012/1/9 Jérôme Lodewyck wrote:
>> > Maybe we could make it a user-settable preference in the tool widget.
>> > The wxt terminal maintains a preference file ~/.gnuplot-wxt so that the
>> > widget settings are persistent.  I suppose the qt terminal could do the
>> > same.
>> Where does Qt terminal store background color?
>
> This is managed by the QSettings model in Qt. The location and format of the
> settings depends on the system and is chosen by the Qt library. It is hidden
> from the user and programmer. It is a config file under linux
> (~/.config/gnuplot/qtterminal.conf), in the registry on windows, and who knows
> where in OS X...

Thank you. Now I have found it.

~/Library/Preferences/gnuplot_qt.plist

It should have had a different name (for the sake of cleanliness)
though - all others that I have in that folder have something like
net.sourceforge.aquaterm.plist,
hu.mplayerhq.mplayerosx.extended.plist, org.tug.TeXworks.plist - also
a Qt program, ... but that is not too important at the moment. I don't
know how Qt decides about the filename.

But I think that this would be the right place for storing default
window size and font face/size.

Mojca

Re: Qt terminal

[Jérôme L. <lod...@us...>]

> > Maybe we could make it a user-settable preference in the tool widget.
> > The wxt terminal maintains a preference file ~/.gnuplot-wxt so that the
> > widget settings are persistent.  I suppose the qt terminal could do the
> > same.
> Where does Qt terminal store background color?

This is managed by the QSettings model in Qt. The location and format of the 
settings depends on the system and is chosen by the Qt library. It is hidden 
from the user and programmer. It is a config file under linux 
(~/.config/gnuplot/qtterminal.conf), in the registry on windows, and who knows 
where in OS X...

Jérôme

Re: Handling zooming (pinch) with mouse (multi-touch gestures) on OS X

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

Hello,

With help of some additional Ethan's hints ... I'm attaching the patch
for scrolling to the left/right (it might need some minor editing
before applying).

There is only one "problem": scrolling is way too fast. The minimum
amount of scrolling up/down is approximately 45 pixels (but usually it
is much more: that's just a bare minimum) which amounts to 10% of
vertical plotting area. In any other application I can scroll for
single pixels. The value of event->delta() in
    m_eventHandler->postTermEvent(GE_buttonpress, 0, 0, event->delta()
> 0 ? 4 : 5, 0, 0);
is 2, but that delta value probably doesn't propagate anywhere, so
even if trackpad sends 20, the graph probably still moves for the same
amount as if it sends 2.

It is almost the same situation for horizontal scrolling. I'm unable
to generate minimum events, but the x delta is also 2 and the graph
moves for approximately 10%. However it is almost impossible to move
for less than 50-100%. A comfortable horizontal scroll moves the graph
for approximately 120%. Sliding from left to the right of my trackpad
(a single move) takes me 27 screens further away from center (one
screen is 640 pixels, so 17k pixels away).

The original idea of trackpad (the way how it works in other
applications) is that a single move should take you approximately 1
(monitor) screen apart, which means that scrolling movements could
easily be 10-40 times slower (depending on how you define "slower"
since those scrolling values are probably not propagated anyway).

My measurements might also be a tiny bit biased. At the moment I'm
working with Qt 4.7 which is not properly supported on Lion. I need to
install 4.8 first before complaining any further.

But I think that the main problem/difference with other mouses and
operating systems is that:
- they generate pretty stepwise scrolling
- nobody cares about moving webpage 1 pixel further
- it is very uncomfortable to make, say, 20 steps in a row with a
single movement
while on mac the scrolling seems to be extremely precise and generates
tons of events to move just for a fraction of a screen. And that
discrepancy makes a weird experience without taking amount of
scrolling into account.

... and oh, wait! The very funny part is that after this patch,
horizontal scrolling started working in X11 automatically as well.
That came as a pure surprize.

(I'm now working on zooming, but I will need some extra help there anyway.)

Mojca

Re: [ gnuplot-Bugs-3468950 ] Qt, moc and uic not found on Mac OS X

[Jérôme L. <lod...@us...>]

Le Dimanche 8 Janvier 2012 21:55:35 vous avez écrit :
> I have been running with this one (version 2) under linux.
> It looks pretty good.  Over the day or so of testing I've accumulated
> 3 zombie gnuplot_qt processes, however.  So there's a termination
> condition that's being missed somewhere.

I tried very hard to crash it but failed to reproduce your observation. Each 
time I get a gnuplot_qt zombie, there is a gnuplot one, and killing the later 
kills the former. An interesting question would be whether the zombies you 
observed are still reachable by starting a new gnuplot and entering
	set term qt widget "qtgnuplotXXX"
where XXX is the pid of the zombie gnuplot_qt.

Jérôme

Re: patch for fonts on Mac OS X

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

>> 2.) in plot.c:
>>
>> #if defined(_Windows) || defined(_Macintosh)
>> int
>> gnu_main(int argc, char **argv)
>> #else
>> int
>> main(int argc, char **argv)
>> #endif
>>
>> I don't understand what this does, but gnu_main is probably not needed
>> on Apple (modern Mac OS X), so "|| defined(_Macintosh)" may probably
>> go away if there is no code to support the old macintosh anyway.
>
> It's a compiler flag, not an OS flag.
> Given that the next line says "gnu_main", I imagine that it was an identifier
> defined by some version of gcc.   Whether the current version of gcc used on
> OSX has that same flag defined or not, I don't know.

I take my words back. Apparently Timothée really wanted to use this
for Mac OS X, judging from the message below. However, I have no idea
how the problem was fixed later and independent of that: the code
currently cannot be used since _Macintosh is not defined. I'm CC-ing
Adam who wrote some patches for wxt to comment on whether that
function might be needed or not.

(Maybe Adam also has some ideas if making Qt work without forking is
doable in the same way as wxt, but that's a completely separate and
very low priority issue.)

Mojca


PS: here's the thread

2007/4/28 Timothée Lecomte wrote:
> Timothée Lecomte wrote:
>>
>> Dear Mojca, Joe, and all gnuplot enthusiasts,
>>
>> Here are some news about the availability of the wxt terminal for the
>> MacOS platform. I have had the chance to get my hands on my MacBook and I
>> have worked a little bit on the issues you got when trying to use the wxt
>> terminal.
>>
>> (...)
>>
>>
>> So there is one remaining thing to try, but this will involve more work on
>> my part: changing the way wxt works on Unix and Mac and arrange it so that
>> the main thread runs the event loop while the usual gnuplot command-line
>> loop runs in the separate thread. The challenge is to do that only when
>> wxt_init() is called, not before (doing it at startup time is easy, but I
>> don't feel like it would be the right way).
>> (note that on Windows we don't have this problem because the fake terminal
>> already has the event loop and runs gnuplot command loop inside it)
>> (as far as aquaterm is concerned, it has another design again, something
>> like the X11 terminal: the GUI is in a different program with its own loop
>> and talking with gnuplot through some interprocess communication
>> mechanism)
>
>
> Hey people, here are some more news about "wxt on Mac". I've found some time
> yesterday to investigate a little further. I found that wxMac has some
> limitations :
>
> - the GUI thread (i.e. the one running the GUI event loop) has to be the
> main thread. I had some success making the second thread be the GUI one, but
> still a lot of issues come after that, because:
> - GUI calls should all be done in the same thread. With wxGTK, there's a
> mutex locking mechanism, but it seems that it's really not working on wxMac.
>
> So far, I was able to make wxt work by :
> -at startup, first initialize wxWidgets
> -create a second thread that run gnu_main (otherwise called main in plot.c)
> -start the event loop in the main thread
> and use messages to tell the GUI event loop to do something, instead of
> doing it directly in the second thread.
>
> (it may seem very close to a two process-scheme, such as what is done for
> the X11 terminal, but I don't want to have to deal with inter-process
> communication, or fork+exec for now ;)
>
> So, it's working !
>
> The drawback is that there will be problems if, one day, we want to do, for
> example, a GTK terminal with a similar design... there may be some sort of
> clash between the two wanting for their main loop be in the main thread...
> but that day is probably quite far !
>
> I'll be cleaning up the corresponding patch in the next days if I have some
> time again, and I'll send it to the list as soon as it's ready.
>
> Best regards,
>
> Timothée

Re: patch for fonts on Mac OS X

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

On Monday, January 09, 2012 09:40:26 am Mojca Miklavec wrote:
> 1.) in term.h:
> 
> /* Apple Macintosh */
> #ifdef _Macintosh
> # include "mac.trm"
> #endif
> 
> 1.a) Can somebody please explain me where any of the functions like
> MAC_text are defined? It seems to me as if term/mac.trm does nothing.
> I must be blind, but I don't find any function implemented anywhere.
> 
> 1.b) Obviously that doesn't hurt anyone since _Macintosh isn't defined
> anywhere but on ancient machines. But what's the point in keeping it
> if mac.trm is empty anyway? (I suspect that there was some other
> mac-specific source somewhere that got lost in years.)

Good point.  We could do code archeology, but obviously no one is
using the current mac.trm.  Out it goes!

> 2.) in plot.c:
> 
> #if defined(_Windows) || defined(_Macintosh)
> int
> gnu_main(int argc, char **argv)
> #else
> int
> main(int argc, char **argv)
> #endif
> 
> I don't understand what this does, but gnu_main is probably not needed
> on Apple (modern Mac OS X), so "|| defined(_Macintosh)" may probably
> go away if there is no code to support the old macintosh anyway.

It's a compiler flag, not an OS flag.  
Given that the next line says "gnu_main", I imagine that it was an identifier
defined by some version of gcc.   Whether the current version of gcc used on
OSX has that same flag defined or not, I don't know.

	Ethan





-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742