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

Re: Target to make PS/PDF documentation?

[Reginald B. <pul...@ya...>]

FWIW

I'm not sure I understood the question, but this may be a 90% solution.  A little editing of the output is required, but it finds all the targets.  should be run in the top level directory.

Have Fun!
Reg


#!/bin/sh

find . -name Makefile -exec egrep '^.*:' {} \; \
| egrep -v '#|\$|.*=.*:|^ *\.'                 \
| sed 's/:.*/:/'                               \
| sort -u




      

Re: Target to make PS/PDF documentation?

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

On Thursday 04 September 2008, Petr Mikulik wrote:
> > > Is there a target to make the tex (and from
> > > there, the PS and PDF) versions of the gnuplot
> > > manual?
> > 
> > make pdf          # plain text pdf
> > make pdffigures   # pdf with embedded figures  (cvs version)
> 
> I wish it is possible to list all useful make targets.

"useful" is tricky.
A simple-minded way to list all targets is
  grep : Makefile

or to reduce the noise a little bit
  grep '^[^ 	\.]*:' Makefile


As Phillip pointed out, however, not all of the subdirectory
targets are recognized from the top level directory.  I have
not really looked into that, but if someone has a quick fix
please let me know.

	Ethan




> For example I always  
> use
> 	make install-strip
> for installation, but it is undocumented.
> 
> Should this list go to the beginning of configured Makefile, or " make help" 
> target, or to an INSTALL file?
> 
> ---
> PM
> 



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Target to make PS/PDF documentation?

[Petr M. <mi...@ph...>]

> > Is there a target to make the tex (and from
> > there, the PS and PDF) versions of the gnuplot
> > manual?
> 
> make pdf          # plain text pdf
> make pdffigures   # pdf with embedded figures  (cvs version)

I wish it is possible to list all useful make targets. For example I always 
use
	make install-strip
for installation, but it is undocumented.

Should this list go to the beginning of configured Makefile, or " make help" 
target, or to an INSTALL file?

---
PM

wxt by MingW - Re: Mac OS X and wxt

[Petr M. <mi...@ph...>]

> Yes, wxt does work for Windows. "Official" windows binaries that are 
> distributed on our SourceForge page are not built with it though. With 
> those, you have to use the default "win" terminal. To use wxt on Windows, 
> you can either build gnuplot by yourself with MinGW or MSVC (MinGW should 
> work with the untouched code base).
> Additionally, Michael Goffioul has built a Windows package for Octave, 
> that also contains gnuplot with wxt !

I tried to compile gnuplot with wxt on Windows by MingW, but it failed. How 
can I do it? I did the following:

I have downloaded the files below from 
	http://www.gtk.org/download-windows.html
and unzipped them into the MingW32 directory:

	cairo-dev-1.6.4-2.zip
	cairo-1.6.4-2.zip
	glib-dev_2.18.0-1_win32.zip
	glib_2.18.0-1_win32.zip
	pango-dev-1.20.5.zip
	pango-1.20.5.zip

>From the wx homepage I've got and unzipped into D:/wxMSW-2.8.8
	wxMSW-2.8.8.zip
These are source code. Unfortunately I couldn't compile it, the make always 
failed in some part of its makefile.gcc. I couldn't repair it. Any idea what 
to do?


Anyway, I proceeded further. In gnuplot's makefile.mgw, I had to change:
ifdef WXT
        CFLAGS += -DWXWIDGETS -ID:/wxMSW-2.8.8/include
        CFLAGS += -ID:/Apps/MingW32/MingW344/include/cairo
        CFLAGS += -ID:/Apps/MingW32/MingW344/include/glib-2.0
        WX_OBJS = wxt_gui.o gp_cairo.o
endif

because there is nothing like "wx-config" and "pkg-config" on my PATH as 
shell'ed from makefile.mgw.

In gnuplot/src/wxterminal/wx_gui.cpp, I had to uncomment this code:
#ifdef __WXMSW__
                /* the following is done in wxEntry() with wxMSW only */
                wxSetInstance(GetModuleHandle(NULL));
                wxApp::m_nCmdShow = SW_SHOW;
#endif
because wxSetInstance() was not known.

Then the compilation
    make -f makefile.mgw
worked.

But linking does not work, it complains about many undefined references. It 
seems wgnuplot.exe wants to be linked against the wx library. But it was not 
available as I couldn't compile it. I though the library may not be needed 
and some dll's could be used instead -- Michael's wgnuplot has dependencies 
to many dll's.

Could somebody describe a procedure how to compile wxt under MingW? How to 
have it static or with dll's?

Thanks.

---
PM

Re: Failed build on MacOS

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

On Thursday 04 September 2008, Daniel Farrell wrote:
> Hello,
> 
> I received this error while configure 4.2.3 on MacOS 10.5.4 with 2x
> Dual-Core Xeon processors... think it could be a 64 bit problem (see
> snippet #1). The same error is repeated for all the other headers;

The only thing I can think of that would generate such error messages
is if your compiler installation is incomplete.
Does your machine in fact have a dirent.h installed?
(normally in /usr/include/dirent.h and/or in /usr/include/sys/dirent.h)
Are you able to compile other packages besides gnuplot?

> errno.h, float.h, limits.h ... etc. Unfortunately, this seems to
> yields a make fail (see snippet #2). I've never normally had any
> problems building gnuplot before on my iMac.

Is the iMac also running 10.5.4?

> 
> cc1: error: invalid option argument '-ObjC'
>

This again points to a compiler problem.
Do you in fact have gcc installed?
What do you get as output from
   gcc -v

 
> Regards,
> 
> Daniel
> 
> ---------------
> 
> ___
> 
> snippet #1
> ___
> configure: WARNING: dirent.h: present but cannot be compiled
> configure: WARNING: dirent.h:     check for missing prerequisite headers?
> configure: WARNING: dirent.h: see the Autoconf documentation
> configure: WARNING: dirent.h:     section "Present But Cannot Be Compiled"
> configure: WARNING: dirent.h: proceeding with the preprocessor's result
> configure: WARNING: dirent.h: in the future, the compiler will take precedence
> configure: WARNING:     ## ---------------------------------- ##
> configure: WARNING:     ## Report this to the gnuplot lists.  ##
> configure: WARNING:     ## ---------------------------------- ##
> 
> 
> ___
> 
> snippet #2
> ___
> make  all-recursive
> Making all in config
> make[2]: Nothing to be done for `all'.
> Making all in m4
> make[2]: Nothing to be done for `all'.
> Making all in term
> make[2]: Nothing to be done for `all'.
> Making all in src
> Making all in wxterminal
> make[3]: Nothing to be done for `all'.
> if gcc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term
> -DBINDIR=\"/usr/local/bin\"
> -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.2\"
> -DGNUPLOT_PS_DIR=\"/usr/local/share/gnuplot/4.2/PostScript\"
> -DCONTACT=\"http://sourceforge.net/projects/gnuplot\"
> -DHELPFILE=\"/usr/local/share/gnuplot/4.2/gnuplot.gih\"
> -I/usr/X11/include  -g -O2 -ObjC -MT alloc.o -MD -MP -MF
> ".deps/alloc.Tpo" -c -o alloc.o alloc.c; \
>        then mv -f ".deps/alloc.Tpo" ".deps/alloc.Po"; else rm -f
> ".deps/alloc.Tpo"; exit 1; fi
> cc1: error: invalid option argument '-ObjC'
> make[3]: *** [alloc.o] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Failed build on MacOS

[Daniel F. <boy...@gm...>]

Hello,

I received this error while configure 4.2.3 on MacOS 10.5.4 with 2x
Dual-Core Xeon processors... think it could be a 64 bit problem (see
snippet #1). The same error is repeated for all the other headers;
errno.h, float.h, limits.h ... etc. Unfortunately, this seems to
yields a make fail (see snippet #2). I've never normally had any
problems building gnuplot before on my iMac. I also tried the
development version which gave the same error.

Regards,

Daniel

---------------

___

snippet #1
___
configure: WARNING: dirent.h: present but cannot be compiled
configure: WARNING: dirent.h:     check for missing prerequisite headers?
configure: WARNING: dirent.h: see the Autoconf documentation
configure: WARNING: dirent.h:     section "Present But Cannot Be Compiled"
configure: WARNING: dirent.h: proceeding with the preprocessor's result
configure: WARNING: dirent.h: in the future, the compiler will take precedence
configure: WARNING:     ## ---------------------------------- ##
configure: WARNING:     ## Report this to the gnuplot lists.  ##
configure: WARNING:     ## ---------------------------------- ##


___

snippet #2
___
make  all-recursive
Making all in config
make[2]: Nothing to be done for `all'.
Making all in m4
make[2]: Nothing to be done for `all'.
Making all in term
make[2]: Nothing to be done for `all'.
Making all in src
Making all in wxterminal
make[3]: Nothing to be done for `all'.
if gcc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term
-DBINDIR=\"/usr/local/bin\"
-DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.2\"
-DGNUPLOT_PS_DIR=\"/usr/local/share/gnuplot/4.2/PostScript\"
-DCONTACT=\"http://sourceforge.net/projects/gnuplot\"
-DHELPFILE=\"/usr/local/share/gnuplot/4.2/gnuplot.gih\"
-I/usr/X11/include  -g -O2 -ObjC -MT alloc.o -MD -MP -MF
".deps/alloc.Tpo" -c -o alloc.o alloc.c; \
       then mv -f ".deps/alloc.Tpo" ".deps/alloc.Po"; else rm -f
".deps/alloc.Tpo"; exit 1; fi
cc1: error: invalid option argument '-ObjC'
make[3]: *** [alloc.o] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Re: Gnuplot win terminal regression

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

On Wednesday 03 September 2008, Bastian Maerkisch wrote:
> I found out what's happening:
> 
> In case of "lt palette z" and "lc rgb variable" there's a
> polygon with the same start and endpoint. 

How does that happen?  Is this the real bug?

> Windows optimizes this away  
> and the drawing position is not updated. The next call to W_vect
> therefore uses the wrong starting point.
> 
> Possible fixes:
> a) a MoveTo() at every W_move call
> b) a MoveTo() after all Polyline calls
> c) filter out such polygons and replace by calls to MoveTo()
> 
> 
> I'd prefer option b) because it is straightforward and does not 
> introduce many additional GDI calls:
> 
> 	if ((lastop==W_vect) && (curptr->op!=W_vect)) {
> 	    if (polyi >= 2) {
> 		Polyline(hdc, ppt, polyi);
> 		MoveTo(hdc, ppt[polyi-1].x, ppt[polyi-1].y);  /* make sure we move the 
> drawing position in case of empty polygons */
> 	    } else if (polyi == 1)
> 		LineTo(hdc, ppt[0].x, ppt[0].y);
> 	    polyi = 0;
> 	}

I don't understand why that would fix it, as it still looks to me from
reading the code that every move command has the potential to trigger 
the (polyi == 1) case.   But if you have tested it, then fine.

	Ethan 


> 
> 
>    Bastian
> 
> 
> Ethan A Merritt schrieb:
> > Bastian:
> > 
> > Back in June I applied a patch from you that had the following ChangeLog
> > entry:
> > 
> > 2008-06-24  Bastian Maerkisch  <bma...@we...>
> >         * src/win/wgraph.c (drawgraph): Don't forget to draw a polyline even
> >         if it has only a single segment.
> > 
> > There is now a report on the newsgroup that for data files containing 
> > multiple polyline definitions (e.g. blank lines in the file), each supposedly
> > independent polyline is connected to the previous one.  From inspection of
> > the code, I conclude this is due to your change above.  That is, the initial
> > move command sets polyi=1, but your change causes this to be treated as a
> > length 1 polyline rather than a move.   Strangely, this happens only for
> > plots with either "... lc rgb variable" or "... lt palette z".
> > I don't fully understand why the linetype makes a difference.
> > 
> > Could you have another look at this issue please?  Perhaps the previous
> > patch should be reverted, or perhaps an additional fix is needed somewhere
> > in the W_pm3d_setcolor code block in wgraph.c.
> > 
> > I'd like to release an incremental version 4.2.4 sometime soon, and this
> > is the only regression I know of that would hold it up.
> > 
> > 	Ethan
> > 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

running mean attached files in pastbin

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

http://pastebin.ca/1192516
http://filebin.ca/vcpzmb/mlo-cut.data.gz

regards.

Re: Gnuplot win terminal regression

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

I found out what's happening:

In case of "lt palette z" and "lc rgb variable" there's a
polygon with the same start and endpoint. Windows optimizes this away 
and the drawing position is not updated. The next call to W_vect
therefore uses the wrong starting point.

Possible fixes:
a) a MoveTo() at every W_move call
b) a MoveTo() after all Polyline calls
c) filter out such polygons and replace by calls to MoveTo()


I'd prefer option b) because it is straightforward and does not 
introduce many additional GDI calls:

	if ((lastop==W_vect) && (curptr->op!=W_vect)) {
	    if (polyi >= 2) {
		Polyline(hdc, ppt, polyi);
		MoveTo(hdc, ppt[polyi-1].x, ppt[polyi-1].y);  /* make sure we move the 
drawing position in case of empty polygons */
	    } else if (polyi == 1)
		LineTo(hdc, ppt[0].x, ppt[0].y);
	    polyi = 0;
	}



   Bastian


Ethan A Merritt schrieb:
> Bastian:
> 
> Back in June I applied a patch from you that had the following ChangeLog
> entry:
> 
> 2008-06-24  Bastian Maerkisch  <bma...@we...>
>         * src/win/wgraph.c (drawgraph): Don't forget to draw a polyline even
>         if it has only a single segment.
> 
> There is now a report on the newsgroup that for data files containing 
> multiple polyline definitions (e.g. blank lines in the file), each supposedly
> independent polyline is connected to the previous one.  From inspection of
> the code, I conclude this is due to your change above.  That is, the initial
> move command sets polyi=1, but your change causes this to be treated as a
> length 1 polyline rather than a move.   Strangely, this happens only for
> plots with either "... lc rgb variable" or "... lt palette z".
> I don't fully understand why the linetype makes a difference.
> 
> Could you have another look at this issue please?  Perhaps the previous
> patch should be reverted, or perhaps an additional fix is needed somewhere
> in the W_pm3d_setcolor code block in wgraph.c.
> 
> I'd like to release an incremental version 4.2.4 sometime soon, and this
> is the only regression I know of that would hold it up.
> 
> 	Ethan
> 

Re: about incremental version 4.2.4

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

Hello

I understand what you would like to say.
了解しました。

I will continue to use gcc-4.3(cvs) on cygwin for mouse zooming on octave for windows.

Regards

Tatsuro 

--- Ethan A Merritt <merritt@u.washington.edu> wrote:

> On Monday 01 September 2008, you wrote:
> > Hello
> > 
> > In my previous mail, English is too poor to reead. 
> > I will revise as possible as I can.
> 
> Eメールをよく分かりました。
>   
> > Are you planning to add mouse zooming feature for volatile data which is experimentally
> > embeded in cvs version (gnuplot 4.3) ?
> 
> そんあ事が複雑すぎると思います。4.2のために、bug-fix以外何でも余り変えないつもりです。
>  
> >  As an octave user, it is better that the mouse zooming feature for volatile data is to be
> embeded in
> > the gnuplot 4.2.4.
> > 
> > Regards
> >  
> > Tatsuro  
> >  
> 
> -- 
> Ethan A Merritt
> Biomolecular Structure Center
> University of Washington, Seattle 98195-7742
> 


--------------------------------------
Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more!
http://pr.mail.yahoo.co.jp/mlb/

        

--------------------------------------
Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more!
http://pr.mail.yahoo.co.jp/mlb/

Re: Mac OS X and wxt

[Timothée L. <tim...@lp...>]

Philipp K. Janert wrote:
> Thanks for your reply. That's too bad... ;-(
>
> Does the wxt terminal currently work for
> Windows? Or is the wxt really only available
> for Unix right now (despite its potential to 
> be a cross-platform eventually)?
>
> Best,
>
> 		Ph.
>
>   
Yes, wxt does work for Windows.
"Official" windows binaries that are distributed on our SourceForge page 
are not built with it though. With those, you have to use the default 
"win" terminal.
To use wxt on Windows, you can either build gnuplot by yourself with 
MinGW or MSVC (MSVC may need additional gnuplot patches, I have not 
tested it myself; MinGW should work with the untouched code base). 
Additionally, Michael Goffioul has built a Windows package for Octave, 
that also contains gnuplot with wxt ! It is available there : 
http://sourceforge.net/project/showfiles.php?group_id=2888&package_id=40078 
. It is probably the easiest way to use wxt on Windows.

Best regards,

Timothée

Re: about incremental version 4.2.4

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

Hello

In my previous mail, English is too poor to reead. 
I will revise as possible as I can.

--- Tatsuro MATSUOKA <tma...@ya...> wrote:

Hello Ethan A Merritt 
 
 In your mail to Bastian, I found.
 
 --- Ethan A Merritt <merritt@u.washington.edu> wrote: 
> I'd like to release an incremental version 4.2.4 sometime soon, and this
> is the only regression I know of that would hold it up.
 
Are you planning to add mouse zooming feature for volatile data which is experimentally
embeded in cvs version (gnuplot 4.3) ?

 As an octave user, it is better that the mouse zooming feature for volatile data is to be embeded in
the gnuplot 4.2.4.

Regards
 
Tatsuro  
 
 
> --------------------------------------
> Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more!
> http://pr.mail.yahoo.co.jp/mlb/
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


--------------------------------------
Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more!
http://pr.mail.yahoo.co.jp/mlb/

Re: Target to make PS/PDF documentation?

[Philipp K. J. <ja...@ie...>]

On Monday 01 September 2008 22:28, Ethan A Merritt wrote:
> On Monday 01 September 2008, Philipp K. Janert wrote:
> > Is there a target to make the tex (and from
> > there, the PS and PDF) versions of the gnuplot
> > manual?
>
> make pdf          # plain text pdf
> make pdffigures   # pdf with embedded figures  (cvs version)

In the doc/ directory! (Just found out. Does not seem 
to work from the gnuplot/ directory.)

Thanks. 


>
> I wouldn't bother with a postscript version.
>
> 	Ethan
>
> > I looked through the makefile, but found nothing
> > appropriate.
> >
> > Best,
> >
> > 		Ph.
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> > challenge Build the coolest Linux based applications with Moblin SDK &
> > win great prizes Grand prize is a trip for two to an Open Source event
> > anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Target to make PS/PDF documentation?

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

On Monday 01 September 2008, Philipp K. Janert wrote:
> 
> Is there a target to make the tex (and from
> there, the PS and PDF) versions of the gnuplot
> manual?

make pdf          # plain text pdf
make pdffigures   # pdf with embedded figures  (cvs version)

I wouldn't bother with a postscript version.

	Ethan


> I looked through the makefile, but found nothing
> appropriate.
> 
> Best,
> 
> 		Ph.
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Mac OS X and wxt

[Philipp K. J. <ja...@ie...>]

Thanks for your reply. That's too bad... ;-(

Does the wxt terminal currently work for
Windows? Or is the wxt really only available
for Unix right now (despite its potential to 
be a cross-platform eventually)?

Best,

		Ph.



On Sunday 31 August 2008 10:53, you wrote:
> Philipp K. Janert wrote:
> > I have been asked about the status of
> > using the wxt terminal on Mac OS X.
> >
> > Not being a Mac OS X user, I don't really
> > have this information.
> >
> > I looked through the mailing list archives,
> > but am not really clear what the current
> > situation and the future plans are at this time.
> > Could someone briefly summarize the current
> > state of the wxt terminal on OS X for me?
> >
> > Best,
> >
> > 		Ph.
>
> Hi,
>
> Both in gnuplot 4.2 and in the current CVS, wxt does not work on Mac OS X.
>
> There is a patch on SourceForge that is supposed to make it work on Mac
> OS X :
> https://sourceforge.net/tracker/?func=detail&atid=302055&aid=1950392&group_
>id=2055 However, this is a heavy work, and still in progress. It is supposed
> to build and work on Mac OS X, but it is most likely to be slowish, and I
> have not tried it yet.
>
> I'd like to finish it to move further, but I do not spend as much time
> developing for gnuplot as I used to...
>
> Best regards,
>
> Timothée Lecomte

Target to make PS/PDF documentation?

[Philipp K. J. <ja...@ie...>]

Is there a target to make the tex (and from
there, the PS and PDF) versions of the gnuplot
manual?

I looked through the makefile, but found nothing
appropriate.

Best,

		Ph.

about incremental version 4.2.4

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

Hello Ethan A Merritt 

In your mail to Bastian, I found.

--- Ethan A Merritt <merritt@u.washington.edu> wrote:

> I'd like to release an incremental version 4.2.4 sometime soon, and this
> is the only regression I know of that would hold it up.

Are you planning to add mouse zooming faclities for volatile data which is experimentally managed  in
cvs version (gnuplot 4.3) ?

As a octave user, I would like to manage this facilities in the gnuplot 4.2.4.

Regards

Tatsuro  


--------------------------------------
Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more!
http://pr.mail.yahoo.co.jp/mlb/

Gnuplot win terminal regression

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

Bastian:

Back in June I applied a patch from you that had the following ChangeLog
entry:

2008-06-24  Bastian Maerkisch  <bma...@we...>
        * src/win/wgraph.c (drawgraph): Don't forget to draw a polyline even
        if it has only a single segment.

There is now a report on the newsgroup that for data files containing 
multiple polyline definitions (e.g. blank lines in the file), each supposedly
independent polyline is connected to the previous one.  From inspection of
the code, I conclude this is due to your change above.  That is, the initial
move command sets polyi=1, but your change causes this to be treated as a
length 1 polyline rather than a move.   Strangely, this happens only for
plots with either "... lc rgb variable" or "... lt palette z".
I don't fully understand why the linetype makes a difference.

Could you have another look at this issue please?  Perhaps the previous
patch should be reverted, or perhaps an additional fix is needed somewhere
in the W_pm3d_setcolor code block in wgraph.c.

I'd like to release an incremental version 4.2.4 sometime soon, and this
is the only regression I know of that would hold it up.

	Ethan

-- 
Ethan A Merritt

Re: Mac OS X and wxt

[Timothée L. <tim...@lp...>]

Philipp K. Janert wrote:
> I have been asked about the status of 
> using the wxt terminal on Mac OS X.
>
> Not being a Mac OS X user, I don't really
> have this information. 
>
> I looked through the mailing list archives,
> but am not really clear what the current
> situation and the future plans are at this time.
> Could someone briefly summarize the current
> state of the wxt terminal on OS X for me?
>
> Best,
>
> 		Ph.

Hi,

Both in gnuplot 4.2 and in the current CVS, wxt does not work on Mac OS X.

There is a patch on SourceForge that is supposed to make it work on Mac 
OS X : 
https://sourceforge.net/tracker/?func=detail&atid=302055&aid=1950392&group_id=2055
However, this is a heavy work, and still in progress. It is supposed to 
build and work on Mac OS X, but it is most likely to be slowish, and I 
have not tried it yet.

I'd like to finish it to move further, but I do not spend as much time 
developing for gnuplot as I used to...

Best regards,

Timothée Lecomte

Mac OS X and wxt

[Philipp K. J. <ja...@ie...>]

I have been asked about the status of 
using the wxt terminal on Mac OS X.

Not being a Mac OS X user, I don't really
have this information. 

I looked through the mailing list archives,
but am not really clear what the current
situation and the future plans are at this time.
Could someone briefly summarize the current
state of the wxt terminal on OS X for me?

Best,

		Ph.

Re: grid minor

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

On Thu, 21 Aug 2008 15:45:39 +0200, Theo Hopman  
<th...@ph...> wrote:

>  Everything you ask for already exists in gnuplot 4.2. For example, `set  
> grid mxtics` sets a grid at minor x tics. See `help grid` for details on  
> how to set the linetype.
>


Indeed, many thanks. I had looked at that help entry but must have been  
confused by the number of brackets and terse syntax.

In fact, looking at it, I am not sure whether it is accurate anyway. Take  
the first term of the first line:

        set grid {{no}{m}xtics}

{m} should indicate xtics AND/OR mxtics  but {no} means xtics OR noxtics  
since both would be a contradiction. So either the syntax definition is  
ambiguous or it is wrong. {no} and {m} cannot have the same meaning.

It seems that being too concise in representing the multitude of possible  
options has led to inaccuracy. It seems this should read:

        set grid {{no}xtics} {{no}mxtics}


I also get an error when I try to define minor grid line style without  
major line style.

set style line 11 lw 0.25 lc rgb "#C0C0C0"
set grid mxtics mytics , ls 11


This gets in invalid expression on the comma. Now unless I have had a  
mental stack overflow condition trying to parse all those braces, that  
should be correct usage.

Am I misreading this or is that also an error in the sytax definition?

TIA. , Peter.


BTW, I'm using recent CVS gnuplot.

Re: grid minor

[Theo H. <th...@ph...>]

pl...@pi... wrote:
> Hi,
> 
> I often find my self guessing when reading data off a gnuplot graph with
> grid on. In reality I need the minor ticks as a grid as well , like on old
> fashioned graph paper. The minor intervals are marked with a much lighter
> grid so as not to clutter the graph.
> 
> Is there a way to achieve this that I have over looked?
[...]

Everything you ask for already exists in gnuplot 4.2. For example, `set 
grid mxtics` sets a grid at minor x tics. See `help grid` for details on 
how to set the linetype.

Note that if you're at an interactive terminal with mouse capability 
(any modern one) pressing `r` gives you a ruler. I find this far easier 
to use than trying to interpolate on a grid, especially since I can zoom 
in for higher precision.

THeo

grid minor

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

Hi,

I often find my self guessing when reading data off a gnuplot graph with
grid on. In reality I need the minor ticks as a grid as well , like on old
fashioned graph paper. The minor intervals are marked with a much lighter
grid so as not to clutter the graph.

Is there a way to achieve this that I have over looked?

If not can this be considered as an enhancement request?

Coding would be very simple and would just invovle adding a new variable
such as :

grid_minor on


Many thanks , Peter.

Re: Saving mouse coordinates to a file

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

On Saturday 16 August 2008, Reginald Beardsley wrote:
> 
>  Hi,
>   
>   I have occasion to want to digitize polygonal boundaries
>   on  plots.  I've modified 4.2.3 to implement the following
>   options to the set mouse command:
>   
>   set mouse outputfile "filename" - opens the
>   output file and turns off the text part of the temporary
>   labels
>   
>   set mouse outputfile off - closes the output file and
>   restores normal operation
> 
>   set mouse outputfile format "str" - set the format string
> 
>   and added the appropriate output to "show mouse"
>   
>   While I can manage maintaining my own copy of gnuplot,
>   I'd greatly prefer not to do that.  How should I
>   submit the changes?

Upload a "unified diff" patchset to the SourceForge patches
page:
  http://sourceforge.net/tracker/?group_id=2055&atid=302055

For example, if you have modified two files, mouse.c and set.c,
do something like

   diff -urp original/src/mouse.c my/src/mouse.c >> mousing.patch
   diff -urp original/src/set.c my/src/set.c >> mousing.patch
   ...


However, if I understand correctly what you are trying to do,
it is possible to do this already with no changes to the current
cvs. In fact it should work fine in the released version 4.2.  
Here is a simple version:

main script:
  plot 'whatever'
  set print "vertices.dat"
  load 'get_clicks.gnu'
  unset print

get_clicks.gnu:
  # This loops forever. Control-C to exit
  pause mouse
  print MOUSE_X, MOUSE_Y
  reread

If you want to get fancier, you can format the mouse coordinates
into a string and then print the string. E.g.
  i = i + 1
  vertex = sprintf("%i %g %g",i,MOUSE_X,MOUSE_Y)
  print vertex


-- 
Ethan A Merritt

Saving mouse coordinates to a file

[Reginald B. <pul...@ya...>]

 Hi,
  
  I have occasion to want to digitize polygonal boundaries
  on  plots.  I've modified 4.2.3 to implement the following
  options to the set mouse command:
  
  set mouse outputfile "filename" - opens the
  output file and turns off the text part of the temporary
  labels
  
  set mouse outputfile off - closes the output file and
  restores normal operation

  set mouse outputfile format "str" - set the format string

  and added the appropriate output to "show mouse"
  
  While I can manage maintaining my own copy of gnuplot,
  I'd greatly prefer not to do that.  How should I
  submit the changes?
  
  
  Thanks,
  Reg