>>>>> "LH" == Lars Hecking <lhecking@...>:

LH>  If successful linking depends on the library order, then I'd say the
LH>  linker is broken.

>>>>> "DD" == Dave Denholm <dave.denholm@...>:

DD> I thought the semantics of the unix linker were to visit each archive
DD> in order, make as many passes as necessary until no more symbols can be
DD> resolved, and then move on and never visit that file again (unless it
DD> is mentioned again).

no - order has has always mattered - at least on every Unix platform I've
ever used (Alliant, Unicos, SunOS, Solaris, HP-UX, OSF1/Tru64Unix, Irix,
AIX, Linux, and probably others I've forgotten)

as Hans says, try this:

#include <math.h>
#include <stdio.h>

main()
{
	 double cos1 = cos(1.0);
	 printf("%f\n", cos1);
}

then:

denmark% gcc cos.c -lm
denmark% a.out
0.540302
denmark% gcc -lm cos.c
ld32: WARNING 84 : /usr/lib32/libm.so is not used for resolving any symbol.
ld32: ERROR   33 : Unresolved text symbol "cos" -- 1st referenced by
/var/tmp/cchR0r1j.o.
	 Use linker option -v to see when and which objects, archives and dsos are
loaded.
ld32: INFO    152: Output file removed because of error.
collect2: ld returned 2 exit status

this isn't the best example, since on, e.g., Irix, the -lm isn't even
needed at all - but you get the idea

--
John A. Turner, Ph.D.           Senior Research Associate
Blue Sky Studios, 44 S. Broadway, White Plains, NY  10601
http://www.blueskystudios.com/             (914) 259-6319

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

I would like to plot 2d and 3d graphics using gnuplot from turbo C.
can you please tell me To load gnuplot on my computer  where i can get the it.

thanking you!
Awaiting for the reply

Satish Mantri
Tool Engineer
Forbes Gokak Ltd.
My email id : bksatish1@...
                     satishbk@...

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

PS: Can someone help me get a current snapshot? Our
firewall refuses to allow anonymous cvs access, and
even appears to be stripping emailed archives that
contains any executable files. Can someone put a
snapshot of the cvs code somewhere accessible via
ftp or http? How about...

   ftp://ftp.ucc.ie/pub/gnuplot/testing/

Thanks!

Wrt adding mouse/pan/zoom features to Win32/VC/MFC version,
Hans-Bernhard Broeker [broeker@...] wrote:

> For extra credit (or easier coding), it'd be cool to
> not invent your own, but rather have a look at how mouse
> support was recently added to the CVS version (present
> for X11 and OS/2 for quite some time, but only recently
> for MS Windows, too), and follow up on that.

Agreed -- I will get acquainted with "diff" and "patch",
then adjust and extend his MFC project to work with a
patched and current version of his Win32 DLL project.
Is the Italian developer still available for collaboration?
His patched v3.7.1 MFC project demonstrates 4 modes of use:

   1: Terminal test
   2: Plot using direct commands
   3: Plot from *.dem file
   4: Plot using data from a memory buffer

What sort of application do you think would be appropriate
to include in the cvs distribution?  How would you like to
present the command line interface?

I would like to see some exploitation of the MFC framework.
For example, one of my projects can plot commands in a MDI
CView-derived window, and also provides another plotting
region in a "dockable" control bar. This allows the user
to have any number of MFC "CView" windows open, as well as
other plots embedded in control bars that can be toggled
on and off.

Such a VC++ project may interest the army of Win32 MFC
developers, and bring more talent on board before the
Great Leap to version 4.0  :-)

thanks,
Nigel

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

Nigel Nunn writes:
> PS: Can someone help me get a current snapshot? Our
> firewall refuses to allow anonymous cvs access, and
> even appears to be stripping emailed archives that
> contains any executable files. Can someone put a
> snapshot of the cvs code somewhere accessible via
> ftp or http? How about...
>
>   ftp://ftp.ucc.ie/pub/gnuplot/testing/

  It's there now.

-rw-r--r--   1 263 100     1817145 Apr  1 16:09 gnuplot-3.8f.0.tar.gz
-rw-r--r--   1 263 100         286 Apr  1 16:17 gnuplot-3.8f.0.tar.gz.asc

  md5sums:

685f8109befe7d813d357be57c04a503  gnuplot-3.8f.0.tar.gz
086c5cfa3df05c7995a1c63cd802febb  gnuplot-3.8f.0.tar.gz.asc

  I will make another snapshot when the new mac driver is integrated.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On 1 Apr 2001, Satish Nathuram Mantri wrote:

> I would like to plot 2d and 3d graphics using gnuplot from turbo C.

Turbo C, heh? Now, that's a challenge. Does that mean you want to write
your own program in Turbo C, which uses gnuplot as an external tool to
do some graphics? Or do you want to integrate gnuplot into your Turbo C
compiled application, as an internally used library?

Of these, only the former can possibly work. gnuplot, even with a strongly
reduced set of terminal drivers compiled in, is simply too large to fit in
DOS' 640K easily. Therefore, the Borland automatic overlay loading/linking
system (VROOM) had to be used to build the DOS 16bit version, but that
one's only available with the big version, Borland C++, not with Turbo C.

I.e. with Turbo C, you cannot even compile gnuplot, let alone have any
memory left to turn it into a library that your program could run,
internally.

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Fri, 30 Mar 2001, Johannes Zellner wrote:

>
> I think the main issue is to discuss the syntax. If there'd be
> an agreement about the syntax I'd volunteer to do the necessary
> changes.

OK. If I remember correctly, there was an issue about the name of the
coloured surface (splot "data.dat" with pm3d in your version). It
could be csurface or colour3d or something like that. Also, pm3d itself is
not very intuitive (furthermore, this feature is not restricted to the PM
terminal anymore), but I understand that it is already widely used in
scripts so it won't be changed.

Also, Petr has posted some time ago a mail in which he pointed out some
problems with the column branch (something like he was unable to get a
coloured projection in the base plane and on the surface at the same time,
IIRC). Is this already fixed (haven't checked the column branch since some
time)? He wrote me that he's using almost exclusively 'pm3d map', so the
new syntax should allow everything what is already possible with 'pm3d
map'. At least, the column feature should allow everything that is already
possible right now.

Levente


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Mon, Apr 02, 2001 at 12:27:28PM +0200, Novak Levente wrote:
> > I think the main issue is to discuss the syntax. If there'd be
> > an agreement about the syntax I'd volunteer to do the necessary
> > changes.
>
> OK. If I remember correctly, there was an issue about the name of the
> coloured surface (splot "data.dat" with pm3d in your version). It
> could be csurface or colour3d or something like that. Also, pm3d itself is
> not very intuitive (furthermore, this feature is not restricted to the PM
> terminal anymore), but I understand that it is already widely used in
> scripts so it won't be changed.

The point is also, that not all (especially Petr) liked the
syntax 'with <whatever>'. But I strongly vote for a syntax
like this, because it's consistent with the other gnuplot
syntax, even if it's more to type, e.g. to get a colored
surface AND also lines, you've to type

     gnuplot> splot 'a.dat' w pm3d, 'a.dat' w lines
                              ^^^^ or whatever this will be named

maybe some abbreviations like 'linespoints' could faciliate this:

     gnuplot> splot 'a.dat' w pm3dlines

All this is easy to implement, it's just a matter of finding an
agreement. Comments are welcome.

--
    Johannes

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Mon, Apr 02, 2001 at 12:27:28PM +0200, Novak Levente wrote:
>
>
> On Fri, 30 Mar 2001, Johannes Zellner wrote:
>
> >
> > I think the main issue is to discuss the syntax. If there'd be
> > an agreement about the syntax I'd volunteer to do the necessary
> > changes.
>
> OK. If I remember correctly, there was an issue about the name of the
> coloured surface (splot "data.dat" with pm3d in your version). It
> could be csurface or colour3d or something like that. Also, pm3d itself is
> not very intuitive (furthermore, this feature is not restricted to the PM
> terminal anymore), but I understand that it is already widely used in
> scripts so it won't be changed.

btw.: I like (and vote) for

     'csurface'

--
    Johannes

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Mon, 2 Apr 2001, Johannes Zellner wrote:

[...]

> The point is also, that not all (especially Petr) liked the
> syntax 'with <whatever>'. But I strongly vote for a syntax
> like this, because it's consistent with the other gnuplot
> syntax,

That's a point which is debatable, at least to some extent. Currently,
we have two families of 'plot styles' in gnuplot.

1) the traditional "with <style>" variety. There's default behaviour,
    and the 'set style data' and "set style functions" to override that
    default, to save some typing.

2) global mode changes. Currently, those are:

	 set hidden3d
	 set contour
	 set pm3d

Traditionally, both 'set hidden3d' and 'set contour' refused to work at
all if there was any data not manageable by them (some of that has changed
with the latest hidden3d rewrite). Neither is there a way of forcing them
to *not* hide/contour grid-structured data once they're activated, short
of modifying the datafile to break grid structure.

I don't know PM3D well enough to be able to say what it does if you
present it, say, a datafile with a single isoline, or what it does with
arrows, contour lines and other non-polygonal data.

I.e. it's not like "with <style>" is the only prior art, in this area, or
the only thing we'ld have to think about if we modify the method to access
pm3d.

> maybe some abbreviations like 'linespoints' could faciliate this:

This smells of lack of orthogonality in the command. We should think twice
before we introduce separate commands for all possible combinations of two
essentially unrelated choices. It blows up the code, and makes it
unnecessarily hard to maintain. The current mess with the axis-related
settings is bad enough, already.

Besides, if we keep adding options to {s}plot at this pace, we'll have to
think about a method to store all the options put into a single dataset
description (from function/filename up to the style arguments) into a
user-definable variable. Something like

	 set plot 5 'datafile' using 5:25 \
	     title "some complicated enhps stuff" \
	     with linespoints lt 3 lw 2.5 pt 2 ps 1

	 plot sin(x), plot(5)

or something along those lines.

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Mon, 2 Apr 2001, Hans-Bernhard Broeker wrote:

| [...]
|
|Besides, if we keep adding options to {s}plot at this pace, we'll have to
|think about a method to store all the options put into a single dataset
|description (from function/filename up to the style arguments) into a
|user-definable variable. Something like
|
| set plot 5 'datafile' using 5:25 \
|     title "some complicated enhps stuff" \
|     with linespoints lt 3 lw 2.5 pt 2 ps 1
|
| plot sin(x), plot(5)
|
|or something along those lines.

Could string support maybe do the job ? E.g.

let Plotcommand=" 'datafile' using 5:25 \
            title \"some complicated enhps stuff\" \
            with linespoints lt 3 lw 2.5 pt 2 ps 1"

plot sin(x), ${Plotcommand}

Arnd


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Sun, 1 Apr 2001, Nigel Nunn wrote:

> Agreed -- I will get acquainted with "diff" and "patch",
> then adjust and extend his MFC project to work with a
> patched and current version of his Win32 DLL project.
> Is the Italian developer still available for collaboration?

Don't know. I haven't heard from him since December, IIRC.
Anyway, I guess it can't hurt to give you his Mail adress, so you
can ask him directly:

"Amedeo Farello" <afarello@...>

He also wrote the first shot of the SVG terminal driver, BTW.

> What sort of application do you think would be appropriate
> to include in the cvs distribution?

In the gnuplot sources, I don't think we pressingly need anything fancy.
Just the interface layer between MFC and gnuplot's code, plus a *short*
demo application that just shows how it's used, in principle. Enough to
get any competent MFC programmer off the ground, but nothing that would
cause headaches maintining, on our end.

> How would you like to present the command line interface?

I have no particular preference, there. AFAICS, there is no
user-presentable command line interface any more, in the library version.
I.e. if the programmer using this library wants a command line interface,
I guess she'd have to creater her own. It might be useful to present a
little example in the demo app (a short input line control, maybe even
using gnuplot's readline.c module...)

The ultimate quest for buzzword compatibility would of course require us
to turn the gnuplot library into a full-fledged OCX/ActiveX control :-)

I know far too little of MFC to know what the proper type of GUI element
gnuplot would become, in this world. In Java, I'd guess something like
a subclass of 'Frame' would be it. In the end, the gnuplot dll would
be just another pluggable thing a Windows programmer can put into his
toolbox and add to a Window whenever he feels like it.

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Mon, 2 Apr 2001, Arnd Baecker wrote:

> Could string support maybe do the job ?

If gnuplot had any: possibly. But it doesn't --- any takers?

Quoting would also tend to become a nightmare.  A separate command would
be easier to handle. After all, it's really the same syntax as the plot
command itself. People could recall an earlier 'plot' command from the
history or from 'show plot', and edit it to turn it into a 'set plot'.

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

> I find that the 'column' feature maintained by Johannes Zellner (which
> adds the capability of speciying the colour of a pm3d point/polygon from
> the datafile itself) is very useful. However it seems that it needs to be
> discussed how it could be merged into the MAIN trunk. Apparently, as
> described by Johannes, the main code requires only little modification,
> the hardest part is to agree on a syntax and some minor issues. Is anybody
> out there apart Johannes and myself using the 'column' feature, and what
> is their opinion about the possible syntax and the things what need to be
> fixed/changed?

See my mail from March 7.

Petr Mikulik


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

There is little if any information in the documentation on how to use
the pipes feature when it is available.

In particular I have built gnuplot v3.8f for Windows using Cygnus
compiler with PIPES defined. Now how do I test it?


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Mon, 2 Apr 2001, William D. Kirby wrote:

> There is little if any information in the documentation on how to use
> the pipes feature when it is available.
>
> In particular I have built gnuplot v3.8f for Windows using Cygnus
> compiler with PIPES defined. Now how do I test it?

Well --- you pipe stuff into it. Either via a program, or simply by
redirection:

	 cat simple.dem | wgnuplot
	 wgnuplot < simple.dem

anything like that. You'll also want to test the internal usages of pipes,
in

	 plot "< sed 's/5/3/g' datafile" with lines, 'datafile' with lines

and

	 set label ` echo "$PATH"`


--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

Hans-Bernhard Broeker wrote:

> On Mon, 2 Apr 2001, William D. Kirby wrote:
>
> > There is little if any information in the documentation on how to use
> > the pipes feature when it is available.
> >
> > In particular I have built gnuplot v3.8f for Windows using Cygnus
> > compiler with PIPES defined. Now how do I test it?
>
> Well --- you pipe stuff into it. Either via a program, or simply by
> redirection:
>
>         cat simple.dem | wgnuplot
>         wgnuplot < simple.dem
>

I tried something like this, but it did not work which made me wonder how the
pipe was suppose to work. . Neither of the above pipe methods works. Note that

wgnuplot simple.dem

works with the filename on the command line.

>
> anything like that. You'll also want to test the internal usages of pipes,
> in
>
>         plot "< sed 's/5/3/g' datafile" with lines, 'datafile' with lines
>

The above internal pipe method works.

>
> and
>
>         set label ` echo "$PATH"`

The above command simply causes the label to be "$PATH", and not the variable
PATH.

>

Thanks for the response. I will also test out the Cygwin X-Window version as
well. So far the X11 version shows additional problems.
So far for the Cygwin X-Windows none of the pipe features work (command line
and internally). Also, for the command line method the $PATH label command
aborts with errors on the Cygwin path variable. It shows the set label command
followed with the path string, but the path string is not enclosed by quotes.
Entering the label command above interactively the label comes out literally
with " echo "$PATH"" on the following plot.

I think the pipe and label problems are separate issues.

>
> --
> Hans-Bernhard Broeker (broeker@...)
> Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Tue, 3 Apr 2001, William D. Kirby wrote:

> >         cat simple.dem | wgnuplot
> >         wgnuplot < simple.dem
> >
>
> I tried something like this, but it did not work which made me wonder
> how the pipe was suppose to work. . Neither of the above pipe methods
> works.

This would be the expected behaviour of wgnuplot, indeed. That's why we
had to write pgnuplot.c, in the first place: Windows GUI programs don't
have stdin/stdout channels, so you can't pipe anything into/out of them
without additional hassles.

> >         set label ` echo "$PATH"`
>
> The above command simply causes the label to be "$PATH", and not the variable
> PATH.

Ooops, error on my end. For a DOS/Windows setting, that should have been:

	 set label ` echo '%PATH%'`

of course, and even then it may not work. But the redirection itself
already works, anyway.

> So far for the Cygwin X-Windows none of the pipe features work (command line
> and internally).

Is -DPIPES active in the generated makefile?

> Also, for the command line method the $PATH label command
> aborts with errors on the Cygwin path variable. It shows the set label command
> followed with the path string, but the path string is not enclosed by quotes.
> Entering the label command above interactively the label comes out literally
> with " echo "$PATH"" on the following plot.

The quoting may have been wrong, too. Try

	 ` echo '$PATH'`

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

Hans-Bernhard Broeker wrote:

> On Tue, 3 Apr 2001, William D. Kirby wrote:
>
> > >         cat simple.dem | wgnuplot
> > >         wgnuplot < simple.dem
> > >
> >
> > I tried something like this, but it did not work which made me wonder
> > how the pipe was suppose to work. . Neither of the above pipe methods
> > works.
>
> This would be the expected behaviour of wgnuplot, indeed. That's why we
> had to write pgnuplot.c, in the first place: Windows GUI programs don't
> have stdin/stdout channels, so you can't pipe anything into/out of them
> without additional hassles.
>
> > >         set label ` echo "$PATH"`
> >
> > The above command simply causes the label to be "$PATH", and not the
variable
> > PATH.
>
> Ooops, error on my end. For a DOS/Windows setting, that should have been:
>
>         set label ` echo '%PATH%'`
>
> of course, and even then it may not work. But the redirection itself
> already works, anyway.
>

The above change to the set label input works.

>
> > So far for the Cygwin X-Windows none of the pipe features work (command line
> > and internally).
>
> Is -DPIPES active in the generated makefile?
>

Yes

>
> > Also, for the command line method the $PATH label command
> > aborts with errors on the Cygwin path variable. It shows the set label
command
> > followed with the path string, but the path string is not enclosed by
quotes.
> > Entering the label command above interactively the label comes out literally
> > with " echo "$PATH"" on the following plot.
>
> The quoting may have been wrong, too. Try
>
>         ` echo '$PATH'`

This did not work. The error message says that a column number should follow the
$
character.

>
>
> --
> Hans-Bernhard Broeker (broeker@...)
> Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Tue, 3 Apr 2001, William D. Kirby wrote:

[...]
> > The quoting may have been wrong, too. Try
> >
> >         ` echo '$PATH'`
>
> This did not work. The error message says that a column number should
> follow the $ character.

Well, the quoting still wasn't right, obviously. This example works on
Unix, at least (this time, I did try it before sending it :-)

gnuplot> set label `echo \"$PATH\" `
  gnuplot> show lab

         label 1
"/cldsk/axp61/he/broeker/Lbin:/cldsk/axp61/he/hemgr/Lbin:/usr/bin:/usr/local/bin\
:/bin:/usr/bin/X11:/usr/TeX/bin:/usr/openwin/bin:/usr/games:.:/usr/user/cern/95a\
/bin:/usr/local/JDK-Linux/jdk1.1.3/bin:/usr/X11/bin:/usr/hosts:/usr/openwin/bin:\
."
at (0, 0, 0) left not rotated

Note the escaped quotes to make them active, and the lack of '' in the
echo to make it actually expand the $PATH.

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

Using Cygwin v1.1.8 with gcc 2.95.3-1 on a Windows NT 4.0 SP3 O/S, and
gnuplot cvs update as of 4/02/01.

configure can't find libpdf.a. I moved the library, and even set
--with-pdf=lib-path.

I was able to modify the makefiles and config.h to get gnuplot to
compile with pdf.




[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Tue, 3 Apr 2001, William D. Kirby wrote:

> Using Cygwin v1.1.8 with gcc 2.95.3-1 on a Windows NT 4.0 SP3 O/S, and
> gnuplot cvs update as of 4/02/01.
>
> configure can't find libpdf.a. I moved the library, and even set
> --with-pdf=lib-path.

No big surprise: there's no pdf support in the CVS version of configure.
Lars: didn't you cvs update before regenerating configure, the last times?
configure.in has pdf since 1st of March, but configure doesn't, not even
in the one you checked in this weekend...

Running autoconf over 'configure' should usually suffice to get one that
has pdf support in.

I'd check in a working 'configure' myself, but my autoconf version is
different from Lars', so I'd rather avoid that.

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Tue, 3 Apr 2001, Hans-Bernhard Broeker wrote:

> On Tue, 3 Apr 2001, William D. Kirby wrote:
>
> > Using Cygwin v1.1.8 with gcc 2.95.3-1 on a Windows NT 4.0 SP3 O/S, and
> > gnuplot cvs update as of 4/02/01.
> >
> > configure can't find libpdf.a. I moved the library, and even set
> > --with-pdf=lib-path.
>
> No big surprise: there's no pdf support in the CVS version of configure.

Sorry, was talking rubbish. Turns out I had somehow acquired a sticky tag
1.102 in my working copy of configure, so it never got updated...

So the question why Cygwin doesn't manage to find the pdflib is open
again.

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

Hans-Bernhard Broeker wrote:

> On Tue, 3 Apr 2001, William D. Kirby wrote:
>
> [...]
> > > The quoting may have been wrong, too. Try
> > >
> > >         ` echo '$PATH'`
> >
> > This did not work. The error message says that a column number should
> > follow the $ character.
>
> Well, the quoting still wasn't right, obviously. This example works on
> Unix, at least (this time, I did try it before sending it :-)
>
> gnuplot> set label `echo \"$PATH\" `
>  gnuplot> show lab
>
>         label 1
>
"/cldsk/axp61/he/broeker/Lbin:/cldsk/axp61/he/hemgr/Lbin:/usr/bin:/usr/local/bin\
:/bin:/usr/bin/X11:/usr/TeX/bin:/usr/openwin/bin:/usr/games:.:/usr/user/cern/95a\
/bin:/usr/local/JDK-Linux/jdk1.1.3/bin:/usr/X11/bin:/usr/hosts:/usr/openwin/bin:\
."
> at (0, 0, 0) left not rotated
>
> Note the escaped quotes to make them active, and the lack of '' in the
> echo to make it actually expand the $PATH.

The escape quotes work with the Cygnus X-Windows version. Thanks

>
>
> --
> Hans-Bernhard Broeker (broeker@...)
> Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

Hi Hans-Bernhard,
Just a quick note to let you know that 3.8fp0 compiled
with VC++ 6 runs very nicely!  Most impressed with the
PM3D stuff, and the mouse operations are great! I used
the existing "makefile.nt" and made three trivial
adjustments to enable mouse support,

1: added compiler options

    /DUSE_MOUSE /DWIN_IPC,

2: added a line to file "/gnuplot38f/src/gnuplot.opt"
    which is used to declare a set of files for linking,

   ...
   interpol.obj
   matrix.obj
   misc.obj
   mouse.obj  <--- added this to "gnuplot.opt"
   parse.obj
   plot.obj


3: added gpexecute.obj to the list in "makefile.nt"

   OBJS = $(COREOBJS) gpexecute.obj version.obj


I will think some more about how we might combine all
this with an MFC project.  My question

> How would you like to present the command line
> interface?

should have been... "What to do about textwin?".
MFC has many very cool ways to manage a list of strings.
Choices, choices  :-)
thanks again for your help,
Nigel

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

> > configure can't find libpdf.a. I moved the library, and even set
> > --with-pdf=lib-path.
>
> No big surprise: there's no pdf support in the CVS version of configure.

  Yes it does, as you finally discovered ;-)

> I'd check in a working 'configure' myself, but my autoconf version is
> different from Lars', so I'd rather avoid that.

  Nope, I'm using bog-standard autoconf 2.13 (release version). The only
  tool I'm using that is different is automake.

  The generated config.log file should say a word or two why the lib
  cannot be found.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Wed, 4 Apr 2001, Nigel Nunn wrote:

> > How would you like to present the command line
> > interface?
>
> should have been... "What to do about textwin?".
> MFC has many very cool ways to manage a list of strings.

Please leave the textwin as it is. In particular, please don't replace it
by a rewrite done in MFC or anything --- remember that there are lots of
guys who can't or don't want to use any C++, let alone MFC, even while
they have to compile for Windows...

I.e. I'm fine with a textwin-like alternative solution running on
top of or inside the MFC'able DLL, but please leave the standalone
C-only version alive...

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

> I.e. I'm fine with a textwin-like alternative solution
> running on top of or inside the MFC'able DLL, but please
> leave the standalone C-only version alive...

Yes, that is what I had in mind.  Just wondering about
how folks would like to interact with Gnuplot command
strings if they could have anything they like... voice
activation comes to mind, and programmatically building
the strings, and dockable control bars with listboxes.
Nigel

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Wed, 4 Apr 2001, Nigel Nunn wrote:

> > I.e. I'm fine with a textwin-like alternative solution
> > running on top of or inside the MFC'able DLL, but please
> > leave the standalone C-only version alive...
>
> Yes, that is what I had in mind.  Just wondering about
> how folks would like to interact with Gnuplot command
> strings if they could have anything they like... voice
> activation comes to mind, and programmatically building
> the strings, and dockable control bars with listboxes.

AFAICS, the very idea of having gnuplot as a DLL is that we shouldn't have
to care about it. That's totally left up to the phantasy of whoever uses
that DLL.

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

In both the Cygnus X-Windows and WIN32 versions of gnuplot the use of
environment variable for PATH in labels works interactively when
directly entered or from a file using the load 'file.plt' command.
However, if the file file.plt is given on the execution command line the
process aborts.

For X-Windows set label command is
set label ` echo \"$PATH\"`

For WIN32 it is
set label ` echo '%PATH%'`


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

Hi Nigel,

This sounds very fancy.  I'd be happy (and find a lot of uses for ) a COM
wrapper for the gnuplot plotting engine. No UI, just write to file (or
return result as string for terms like postscript, SVG etc) Has anyone done
this previously?

-lc


----- Original Message -----
From: "Nigel Nunn" <nNunn@...>
To: <info-gnuplot-beta@...>
Sent: Tuesday, April 03, 2001 8:57 AM
Subject: Re: MFC Gnuplot


> > I.e. I'm fine with a textwin-like alternative solution
> > running on top of or inside the MFC'able DLL, but please
> > leave the standalone C-only version alive...
>
> Yes, that is what I had in mind.  Just wondering about
> how folks would like to interact with Gnuplot command
> strings if they could have anything they like... voice
> activation comes to mind, and programmatically building
> the strings, and dockable control bars with listboxes.
> Nigel
>
> [[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]
>


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]