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

config.nt (was: Stuck with compiling 4.1 on windows (again))

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

Marko Brandes wrote:
=2E..(snip)...

>=20
> To activate the datastring and histogram features I had to copy
> EAM_DATASTRINGS and EAM_HISTOGRAM options from config.cyg to config.nt.=

> It may be a good idea to add them to the CVS version of config.nt. Save=
s
> hassle.

Indeed. Config.nt and makefile.nt haven't been updated to reflect recent
features yet. E.g. GP_MACROS, WITH_IMAGE, GP_STRING_VARS, BINARY_DATA_FIL=
E
etc. are missing as well.

I suggest changing the layout of config.nt while at it. Most of the
config.* files in config/ files have the same layout as config.h
generated by the autoconf tools. This makes it very easy to spot
missing defines for new features etc.

>=20
> Again thanks for your help.
>=20
> Marko Brandes.
>=20

--=20
Bastian M=E4rkisch
Physikalisches Institut, Universit=E4t Heidelberg

Re: Stuck with compiling 4.1 on windows (again)

[Marko B. <mar...@sp...>]

Am Mo 05.09.2005 18:07 schrieb Hans-Bernhard Broeker
<br...@ph...>:

> Marko Brandes wrote:
> > - copy ..configconfig.nt ..srcconfig.h
> 
> That still looks strange.  One of those .. should be superfluous.
> 
---
You're right. Just a typo in the mail.

> It's no longer really needed, either --- makefile.nt now makes the
> copy
> itself, if you didn't.
> 
> > But nmake stops (after having assembled the linkopt1.msw) at calling
> > the
> > first link command. 
> 
> That's strange.  It suggests your nmake or VC++ installation could be 
> broken, or your makefile.nt corrupted by earlier editing.
> 
> Are you sure you did this from fresh, unmodified CVS source?
---
Yes, sure. I hadn't touched the makefile.

> 
> Are you sure you had cd'ed to gnuplot/src before running nmake?
---
Yes.

> 
> What ever went wrong there must be a peculiarity of your local system.
> Others have been running builds using makefile.nt successfully for
> years.
> 

Phew... build complete. But don't ask how. I compiled the sources
without using the makefile but loooooooong command-line arguments. Step
by step. Maybe your are right and something is broken with my local
installation.

To activate the datastring and histogram features I had to copy
EAM_DATASTRINGS and EAM_HISTOGRAM options from config.cyg to config.nt.
It may be a good idea to add them to the CVS version of config.nt. Saves
hassle.

Again thanks for your help.

Marko Brandes.

Re: Stuck with compiling 4.1 on windows (again)

[Hans-Bernhard B. <br...@ph...>]

Marko Brandes wrote:
> - copy ..\config\config.nt ..\src\config.h

That still looks strange.  One of those ..\ should be superfluous.

It's no longer really needed, either --- makefile.nt now makes the copy 
itself, if you didn't.

> But nmake stops (after having assembled the linkopt1.msw) at calling the
> first link command. 

That's strange.  It suggests your nmake or VC++ installation could be 
broken, or your makefile.nt corrupted by earlier editing.

Are you sure you did this from fresh, unmodified CVS source?

Are you sure you had cd'ed to gnuplot/src before running nmake?

What ever went wrong there must be a peculiarity of your local system. 
Others have been running builds using makefile.nt successfully for years.

Stuck with compiling 4.1 on windows (again)

[Marko B. <nom...@sp...>]

Hello there,

a few days before I asked a question concernig building gnuplot CVS
version on windows. These problems are solved, but I still did not mange
to build it succesfully.

Until now I did:

- compile libpng and zlib
- compile libpdf
- put the dll's in \windows\system32
- copy ..\config\config.nt ..\src\config.h
- run vcvars32.bat
- run nmake -f ..\config\makefile.nt (from ..\src)

as it was stated in makefile.nt

But nmake stops (after having assembled the linkopt1.msw) at calling the
first link command. It says:

link /subsystem:windows /...[other stuff]... /out:wgnuplot.exe
@linkopt1.msw
LINK: fatal error: Cannot open input file "alloc.obj"

I'm not an computer science expert, so my understanding of this subject
is limited. So do I miss something here? As far as I know "alloc.obj"
has to be created out of "alloc.h" and "alloc.c" which reside in the
same directory. But isn't that the concern of the make subsystem?

Can someone please point me in the right direction? I really need
version 4.1 due to the datastrings facility. This is an awesome feature
making handling of bar-graphs just hassle-free.

Thanks in advance.

Marko Brandes.

Re: Compiling CVS version on Windows fails

[Marko B. <mar...@sp...>]

Am Sa 03.09.2005 17:59 schrieb Hans-Bernhard Broeker
<br...@ph...>:

> Marko Brandes wrote:
> > I grabbed the CVS version of gnuplot and tried to compile it on
> > Windows
> > 2000/XP using MS Visual C++. Using "nmake.exe -f .configmakefile.nt"
> > gives an error saying version.obj could not be created.
> 
> That 'nmake' invocation was done from the wrong place, as evidenced by
> the wrong number of '.' leading the path of makefile.nt. You're
> supposed to
> 
> 	cd whereevergnuplotsrc
> 
> and then either
> 
> 	nmake -f ..configmakefile.nt
> 
> or
> 
> 	copy ..configmakefile.nt .
> 	REM --- possibly edit the copy now, then:
> 	nmake -f makefile.nt
> 
> I'm pretty sure it says so in the README and/or INSTALL files, too.
> 

You are right, it does say so in the INSTALL file.

I don't know why, but I skipped the line 'Change into the "src"
subdirectory'. That's the reason I have chosen the wrong path. My fault.

Thanks for your kind help.

Marko.

Re: Bad wgnuplot.hlp file still on www.gnuplot.info

[Hans-Bernhard B. <br...@ph...>]

Jim McDonald wrote:
> 
> That discussion recommended dowloading gp400win32.zip from
> sourceforge.net, and that solved my problem; wgnuplot.hlp can now
> be read without error on my Win2k SP4 computer.  Can you update
> the file on ftp.gnuplot.info?

It doesn't seem we can.  ftp.gnuplot.info is a mirror, but it's no 
longer updating itself --- and I'm not even sure we still have control 
over the site it's supposed to be mirroring *from*, either.

Re: Compiling CVS version on Windows fails

[Hans-Bernhard B. <br...@ph...>]

Marko Brandes wrote:
> I grabbed the CVS version of gnuplot and tried to compile it on Windows
> 2000/XP using MS Visual C++. Using "nmake.exe -f .\config\makefile.nt"
> gives an error saying version.obj could not be created.

That 'nmake' invocation was done from the wrong place, as evidenced by 
the wrong number of '.' leading the path of makefile.nt.  You're supposed to

	cd \where\ever\gnuplot\src

and then either

	nmake -f ..\config\makefile.nt

or

	copy ..\config\makefile.nt .
	REM --- possibly edit the copy now, then:
	nmake -f makefile.nt

I'm pretty sure it says so in the README and/or INSTALL files, too.

Compiling CVS version on Windows fails

[Marko B. <mar...@sp...>]

Hi list,

I grabbed the CVS version of gnuplot and tried to compile it on Windows
2000/XP using MS Visual C++. Using "nmake.exe -f .\config\makefile.nt"
gives an error saying version.obj could not be created.

Is the makefile for Windows up-to-date or does it need some changes?

Greetings.

Marko Brandes.

Bad wgnuplot.hlp file still on www.gnuplot.info

[Jim M. <Jam...@nr...>]

I downloaded The windows binaries for gnuplot 4.0, gp400win32.zip, from
ftp://ftp.gnuplot.info/pub/gnuplot/, and found that trying to read the
help file, wgnuplot.hlp, produced only the message "language not
supported" as discussed in the thread at

   =20
http://groups.google.com/group/comp.graphics.apps.gnuplot/browse_thread/thr=
ead/37d6fd900dfe5034/8d9fdbf7f2af03b5?lnk=3Dst&q=3D%2B%22gnuplot%22+%2B%22l=
anguage+not+supported%22&rnum=3D1&hl=3Den#8d9fdbf7f2af03b5

That discussion recommended dowloading gp400win32.zip from
sourceforge.net, and that solved my problem; wgnuplot.hlp can now
be read without error on my Win2k SP4 computer.  Can you update
the file on ftp.gnuplot.info?

Thanks,
- Jim McDonald

Re: Crosshair axis

[Hans-Bernhard B. <br...@ph...>]

Justace Clutter wrote:
> I looked at the various settings and did not see anything that would do it 
> right.  I can see that I can remove the axis using the border command and 
> then use the [x,y]zeroaxis commands but that does not actually move the axis 
> with all the tics to the zero cross.

That's what you have commands like

	set xtics axis

for.  In total, the combination you're looking for would be something like

	unset border
	set xzeroaxis lt -1 lw .5 ; set yzeroaxis lt -1 lw .5
	set xtics axis ; set ytics axis
	plot sin(x)

Crosshair axis

[Justace C. <pro...@co...>]

Does anybody know how I might get a crosshair axis setup with the tic marks on 
the axis that go through the origin?  Ya know, like if I walked up to a chalk 
board and drew and axis and then drew my function...

I looked at the various settings and did not see anything that would do it 
right.  I can see that I can remove the axis using the border command and 
then use the [x,y]zeroaxis commands but that does not actually move the axis 
with all the tics to the zero cross.

Justace

Re: [Gnuplot-info] I can't ./prepare

[Hans-Bernhard B. <br...@ph...>]

Peder wrote:
> export CVS_RSH=ssh

Useless for the kind of download you're doing.  ssh access is for 
developers only.

> export CVSROOT=:pserver:ano...@cv...:/cvsroot/gnuplot

I'm reasonably sure that line's is out of date.  The host name was 
changed to cvs.sourceforge.net quite a while ago.

> ./prepare: line 17: aclocal: command not found
> 
> Some part of the preparation process failed.
> Please refer to INSTALL for details.

> Any ideas what the reason could be? 

The reason is written there:

	aclocal: command not found

In other words, your machine is lacking the 'aclocal' command.  You'll 
have to install GNU auto-tools (automake, autoconf) to get it.  I think 
Ethan's instructions do mention that precondition already.  If not, they 
need to be changed.

[Fwd: KNOPPIX/Math project]

[Lars H. <lhe...@us...>]

----- Forwarded message from Tatsuyoshi HAMADA <ha...@ho...> -----

Date: Thu, 01 Sep 2005 17:13:36 +0900 (JST)
To: br...@us...
Cc: cga...@us..., lhe...@us...
Subject: KNOPPIX/Math project
From: Tatsuyoshi HAMADA <ha...@ho...>

Dear sir,

I am one of users of your software product and
wish to express my gratitude deeply. 

>From February 2003, we started the project ``KNOPPIX/Math''.
http://geom.math.metro-u.ac.jp/wiki/index.php?%5B%5BKNOPPIX%2FMath%2FEnglish%5D%5D

KNOPPIX is a bootable CD with a collection of GNU/Linux software. 
Klaus Knopper in Germany started this project.
http://www.knopper.net/knoppix/
It can be used as a Linux demo, educational CD and rescue system. 
It is not necessary to install anything on your hard disk. 

In Japan, 
AIST(National Institute of Advanced Industrial Science and Technology)
started the project, KNOPPIX Japanese edition, from Autumn 2002.
http://unit.aist.go.jp/itri/knoppix/index-en.html

I started our project KNOPPIX/Math with AIST team,
now, it contains many mathematical software and free documents.

We installed your software in KNOPPIX/Math.
Now, we are distributing two types of CD-image, 
Japanese edition and English edition.

You can download the CD-ROM image from our mirror site.
http://geom.math.metro-u.ac.jp/wiki/index.php?%5B%5BKNOPPIX%2FMath%2FEnglish%2FDownload%5D%5D
If you are interested in our project, please send us your shipping address,
I will send you some copies of CD-ROM.

In closing, I thank again and apologize for the delay of my e-mail.

Sincerely yours.
				Tatsuyoshi HAMADA
				KNOPPIX/Math project


----- End forwarded message -----

Re: epslatex in Version 4.1

[Hans-Bernhard B. <br...@ph...>]

Valentina Beato wrote:
> using with term epslatex, the "set size" set the size of the eps graph =
=20
> at different sizes as with gnuplot 4.0
> the correspo=BCndin .tex file is now somethingvery nasty. With gnuplot =
4.0=20
> the .tex file was a nice 20-line file...

If you don't explain to us what you think is "nasty" about the file you=20
got, it's quite impossible for anyone to comment sensibly.  The epslatex =

terminal has changed *a lot* between 4.0 and now.  You may have to check =

back on the terminal documentation and use different options to get even =

roughly the same kind of output, as a consequence.

epslatex in Version 4.1

[Valentina B. <val...@da...>]

using with term epslatex, the "set size" set the size of the eps graph =20
at different sizes as with gnuplot 4.0
the correspo=BCndin .tex file is now somethingvery nasty. With gnuplot 4.=
0=20
the .tex file was a nice 20-line file...

=20

Re: opengl terminal driver (was povray terminal driver)

[V. <gae...@no...>]

On Fri, Aug 19, 2005 at 08:56:32AM -0700, Ethan Merritt wrote:
> I very much fear that an OpenGL driver will remain a compile-it-yoursel=
f
> option under linux.=20

    Quite possibly, but I must point out Blender works very well and
isn't "compile-it yourself".

    That said, I can't add much to the discussion as I don't know
anything about the problem.

--
    Ga=EBl

Re: wxWidgets terminal : locale "C" ?

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

mi...@ph... wrote:

>>"please switch to "C" locale for numbers, at least when
>>communicating with gnuplot; otherwise, zooming wants to
>>execute command "set xr[1,234:5,678]" which is wrong"
>>
>>I've seen this problem on my box too, which has locale fr_FR, with a comma for the LC_numeric locale.
>>    
>>
>
>I reported a similar problem related to parsing .Xdefaults recently, and I
>think init_locale() is called inside plot.c to switch to C locale. Isn't
>initialization of wxterminal before this call?
>
>  
>
No, it isn't : I initialize the wxwidgets library just before the loop
on com_line(), so init_locale has already been called.

Re: wxWidgets terminal : locale "C" ?

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

> "please switch to "C" locale for numbers, at least when
> communicating with gnuplot; otherwise, zooming wants to
> execute command "set xr[1,234:5,678]" which is wrong"
>
> I've seen this problem on my box too, which has locale fr_FR, with a
comma
> for the LC_numeric locale.

I reported a similar problem related to parsing .Xdefaults recently, and I
think init_locale() is called inside plot.c to switch to C locale. Isn't
initialization of wxterminal before this call?

---
PM

Re: patch MAX_NUM_VAR in version 4.0.0

[Lars H. <lhe...@us...>]

 
> Perhaps the constant MAX_NUM_VAR could in fact be an option in the 
> configure/make process?
 
 Even better: make it runtime-configurable, or remove the limitation
 completely.

wxWidgets terminal : locale "C" ?

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

Hi !

Petr Mikulik has just wrote the following comment on the sourceforge page=
 about the wxwidgets terminal :

"please switch to "C" locale for numbers, at least when
communicating with gnuplot; otherwise, zooming wants to
execute command "set xr[1,234:5,678]" which is wrong"

I've seen this problem on my box too, which has locale fr_FR, with a comm=
a for the LC_numeric locale.
However, I see the same problem with the x11 terminal.

And the command "set locale {locale {locale_set}}" doesn't seem to do any=
thing about it...
What behaviour should I expect ?

Thanks,

Timoth=E9e Lecomte

patch MAX_NUM_VAR in version 4.0.0

[Bernard M. <me...@it...>]

Dear Madam/Sir,

I always wondered why the number of variables in a user defined function 
is restricted to five. This prevented me from defining "trivial" 
functions such as the scalar product of two vectors in R^3 ...

Changing the line

# define MAX_NUM_VAR    5

in 'syscfg.h' e.g. to:

# define MAX_NUM_VAR   10

and, for consistency, making an appropriate change in 'gnuplot.doc' e.g. to:

New user-defined variables and functions of one through ten variables may
  be declared and used anywhere, including on the `plot` command itself.

  User-defined function syntax:
        <func-name>( <dummy1> {,<dummy2>} ... {,<dummy10>} ) = <expression>

  where <expression> is defined in terms of <dummy1> through <dummy10>.

seems to work OK.

Perhaps the constant MAX_NUM_VAR could in fact be an option in the 
configure/make process?

Anyhow, thank you very much for GNUPLOT!

with best regards,

Bernard Metsch

wxWidgets terminal : first patch available

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

Hi all happy gnuplot users !

I am pleased to announce my first patch against current CVS which
implements a new interactive terminal with the wxWidgets library. You
will find it on the gnuplot project page :

http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1267434&grou=
p_id=3D2055&atid=3D302055

I have chosen to send it today because I think I have reached a stage
where it would be useful to discuss about implementation details. I'll
try to explain what is working :
* all basic drawing facilities are working.
* mouse/hotkeys support is working.
It involves two side : the terminal one (easy : events designed with the
library) and the main gnuplot thread, which has to listen to the events.
I have chosen to implement something similar to the OS/2 way : the main
thread is sleeping until readline or the event system wakes it up. It
adds a small overhead even if the wxwidgets terminal is not used, as the
wxwidgets library has to be initialized before the main loop begins, and
the sleep/wake process is always used.
* enhanced text mode is almost working.
As you will see (with enhancedtext.dem for example), there are still
problems with text alignment. Text of different sizes are not really
aligned as they should. I also have a problem on my box with non-ascii
characters with the Symbol font (but Kwrite, Kspread, etc. show the same
problem while they are based on qt).
* I have put a small menu which contains only an about page, and a
"close terminal" entry.
I also put a toolbar with one icon, which doesn't do anything now. These
are just here to give you an idea of what can be done with menus and
toolbars.
* Resizing the window will rescale the plot as X11 and win terminals do.
To realize it, I have chosen to store gnuplot commands in a list, which
is processed once when wxt_text() is called, and again when the window
has changed.


Things that are to be improved :
* Text alignment as I said above,
* Speed : you'll see that it's slower than the x11 terminal. Here I need
your ideas. Three things can slow down the process as it is coded now :
       - the list itself : maybe not well designed to store the commands
(too much memory used ?, slow access to items ?)
       - bitmap : commands are processed by drawing into a bitmap, which
pasted to the screen at last. It seemed a simple and efficient way to
cope with screen painting which is done each time the window is hidden
by another, etc. : the bitmap is pasted again and that's all.
       - multithreading : to keep the process synchronous, the commands
are processed in the main gnuplot thread, which draws the bitmap. The
drawing primitives are not really thread-safe, so I have to lock a gui
mutex before. I don't have a lot of experience with mutexes (I also use
them for the events system), and I wonder of the latency it adds is
significant or not.

Things to be done :
* _image() function is lacking (I began to code against 4.0...)
* I'm not sure of what I did with pm3d color settings, especially with
the recent additions linetype/gradient/rgb and so on
* For my toolbar/menus, I planned to use do_event() with its ability to
send raw commands, but it has been removed from CVS... I may revert this
change, or I may use my own implementation with my event stuff...

And finally, I have some doubt regarding licences. I am sure that I can
use the wxwidgets library with gnuplot as it is LGPL, but I don't really
know of gnuplot should contain a copy of the LGPL. I have chosen to
include it in this first patch, so you will find it under docs/licence/.

If you apply this patch, you'll need wxGTK or another port of the
wxWidgets library on your system (please see http://www.wxwidgets.org
for platform details). I have modified configure.in to check for the
library and to initialize c++ stuff. However, there's no option with
./configure once you have installed the patch : either you have
wxWidgets and it *should* work, or it will refuse to configure and
compile. An option and proper tests are  of course on my TODO list !
You should use, on linux(unix?) and against current tree :
patch -p1 < wxterm_cvs20050823.diff
autoconf
aclocal
automake
and then the traditionnal ./configure, make, make install

Well, I have already spoken too much. Here are some screenshots :

http://tipote.free.fr/wxt5.png    [test page]
http://tipote.free.fr/wxt6.png    [plot cos(x),sin(x)]
http://tipote.free.fr/wxt7.png    [about page over a surface plot]
http://tipote.free.fr/wxt8.png    [enhancedtext.dem]

I hope you will appreciate this work, and I wait to hear your points of
view !

Timoth=E9e Lecomte

Re: opengl terminal driver (was povray terminal driver)

[Robert H. <en...@no...>]

On Fri, 2005-08-19 at 08:56 -0700, Ethan Merritt wrote:

> Normally that is true, but when the program (X11 in this case)
> writes directly into hardware and system memory, as the DRI extension
> does, then no.   If you (the glut library) send incompatible commands,
> you may corrupt the system/hardware itself. The poor guy in the middle
> (the X server) is an innocent/unwilling accomplice who does not have
> perfect knowledge of what you sent or what effect it will have on the
> hardware. 

Fair enough. I'm not doubting what you say, I was just wondering if
there was something more going on. As I understood it, GLUT, is just a
set of utility functions built on top of openGL and X11 (or whatever)
and doesn't in itself do any direct messing with anything.

But I don't really have much experience in this matter.

Rob
-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: Explicit rgb colors [was Re: historysize]

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

On Friday 19 August 2005 07:06 am, mi...@ph... wrote:
>
> Or some new call like term->set_palette(be truecolor).

term->set_color() already handles this.

The trick is to have the core routines set the TC_RGB flag rather
than the pm3d/gray flag TC_FRAC.
See patchset uploaded to SourceForge.

Re: opengl terminal driver (was povray terminal driver)

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

On Friday 19 August 2005 02:42 am, Robert Hart wrote:
> On Thu, 2005-08-18 at 13:48 -0700, Ethan Merritt wrote:
> > 
> > I don't think there is a 100% solution to this problem.
> > Sadly, freeglut and other glut implementations are not perfectly
> > compatible.  If you try transferring a binary linked against,
> > say X.org glut, to a machine that has nVidia drivers and glut libs
> > you are likely to crash the application, X11 itself, and possibly
> > the whole machine.  [As I have learned the hard way].
> 
> hmm. I can't say I've had any problems myself. I'm not sure how many of
> the opengl apps I have use glut, but certainly things like upgrading
> from Xfree86 to X.org haven't caused me any issues.
> 
> Anything that crashes X11 is a bug in the server.

Normally that is true, but when the program (X11 in this case)
writes directly into hardware and system memory, as the DRI extension
does, then no.   If you (the glut library) send incompatible commands,
you may corrupt the system/hardware itself. The poor guy in the middle
(the X server) is an innocent/unwilling accomplice who does not have
perfect knowledge of what you sent or what effect it will have on the
hardware. 

Besides which, "your X-server has a bug" is not a very helpful
explanation to people who just want to run the program.

The header files for the various glut implementations are not
compatible. Is it any wonder that binaries built from those
headers are not compatible?

I very much fear that an OpenGL driver will remain a compile-it-yourself
option under linux.  My work involves a lot of computer graphics and
3D interactive visualization tools.  Non-portability of OpenGL code is
a continuing headache, and hits many of the standard libraries and
toolkits we use (or would like to use).

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195