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

Re: 'make distcheck' has problems with the wxt files

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

On Saturday 17 June 2006 09:47 pm, Timoth=E9e Lecomte wrote:
> You can embed a PNG file in the source code after having converted to a=20
> C array. Thus you profit from the compression of the PNG format=20
> (compared to including XPM files) and you don't have to care about the=20
> paths as the files are included at compile time.

OK by me. =20

But in the abstract, I'd still like to leave open the  possibility
of users adding their own custom menu icons with bound actions.=20
As I envision it, the system would work similarly to the
existing 'bind' command.  E.g. instead of binding to a key, you'd
be binding to a menu button:

    bind icon "paintbox.png" \
	action "load 'linestyles'; set style incr user; replot"

(that doesn't quite work for other reasons, but you get the idea)

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: 'make distcheck' has problems with the wxt files

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

Timoth=E9e Lecomte wrote:
> Timoth=E9e Lecomte wrote:
>> Ethan Merritt wrote:
>> =20
>>> On Friday 16 June 2006 04:33 pm, you wrote:
>>>     =20
>>>> Ethan Merritt wrote:
>>>>         =20
>>>>> Procedure:
>>>>> ./prepare
>>>>> ./configure --readline=3Dgnu
>>>>> make distclean
>>>>>
>>>>> Non-fatal error message during the "make check" part
>>>>> ----------------------------------------------------
>>>>>   Can't load PNG icon(s) of the toolbar.
>>>>>              =20
>>>> I can only solve that by using XPM files included at compile time.
>>>>          =20
>>> I don't see why that should be.  Isn't it just a matter of setting=20
>>> an environmental variable
>>> during the "make check" run so that the icons are picked up
>>> from the build directory rather than their eventual install
>>> directory?
>>> That's what it does with GNUPLOT_DRIVER_DIR (to pick up gnuplot_x11).
>>>      =20
>> Oh yes, I forgot that option. I can do that.
>>
>> Timoth=E9e
>>  =20
> Hmm. It turns out not to be as easy as it seems.
Well, with the help of the wxWidgets guys on IRC, I finally came up with=20
a very nice solution, which combines both simplicity, small executable=20
size, and no path nightmare :

You can embed a PNG file in the source code after having converted to a=20
C array. Thus you profit from the compression of the PNG format=20
(compared to including XPM files) and you don't have to care about the=20
paths as the files are included at compile time.

The size of the executable really does not change much :

- before : 2785700 bytes
- after : 2786862 bytes

... 1162 bytes, I think we can afford that instead of an ugly code to=20
retrieve the paths from different ways ...

I will commit that soon.

Timoth=E9e

Re: 'make distcheck' has problems with the wxt files

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

On Saturday 17 June 2006 07:43 pm, Timoth=E9e Lecomte wrote:
> >>
> >> xresourcedir =3D $(libdir)/X11/app-defaults/Gnuplot
> >> xresource_DATA =3D Gnuplot.app-defaults
> >>    =20
> I put these lines in share/Makefile.am :
>=20
> xresourcedir =3D $(libdir)/X11/app-defaults
> xresource_DATA =3D Gnuplot.app-defaults
>=20
> and I commented out the rules 'install' and 'uninstall'.
>=20
> It seems to work as I described it.

Huh.  Yes it does. I must not have started with a clean enough
slate the first time I tried it.

OK, I'll put that in CVS.

	thanks,

		Ethan
=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

ambiguous help cleanup

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

I put a patch on S.F. for not print "no help" when there is actually ambiguous help.  The patch is short enough that is should be reviewable before 4.2.

Dan

Re: 'make distcheck' has problems with the wxt files

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

Ethan A Merritt wrote:
> On Saturday 17 June 2006 06:51 pm, you wrote:
>  =20
>> I propose the following (assuming that /usr/lib/X11/app-defaults is th=
e=20
>> default directory for this kind of stuff - I don't have such directory=
=20
>> on my machine, everything is in /usr/share/X11/app-defaults instead,=20
>> which makes more sense to me) :
>>
>> xresourcedir =3D $(libdir)/X11/app-defaults/Gnuplot
>> xresource_DATA =3D Gnuplot.app-defaults
>>    =20
>
> Did you actually try this and get it to work?
> I placed these lines in Makefile.am and nothing happened at all.
>  =20
I must admit that I did not try before posting, but I just did. I put=20
these lines in share/Makefile.am :

xresourcedir =3D $(libdir)/X11/app-defaults
xresource_DATA =3D Gnuplot.app-defaults

and I commented out the rules 'install' and 'uninstall'. When doing=20
'make install' after './configure --prefix=3D/home/tipote', I see :

test -z "/home/tipote/lib/X11/app-defaults" || mkdir -p --=20
"/home/tipote/lib/X11/app-defaults"
 /bin/install -c -m 644 'Gnuplot.app-defaults'=20
'/home/tipote/lib/X11/app-defaults/Gnuplot.app-defaults'

It seems to work as I described it.

> Also, the autoconf documentation claims that it should be able
> to find the proper xresourcedir definition by itself if the lines
> AC_SUBST(LIBRARIES_FOR_X)
> AC_PATH_XTRA
> are placed in configure.in.
I can't find these claims.

> <begin rant>
> I think I will give up on this, and leave it for some autoconf
> guru (Lars?)   To truth is, I find the autoconf documentation=20
> impenetrable, and the design of the program itself hideous.
> Somebody should start over and write a better-designed=20
> autoconfiguration system.  I guess gnu autoconf is better than
> nothing, but that's not saying much.  It doesn't quite reach the
> level of horrible design achieved by the 'info' system, but I'd
> rather not touch either one of them if at all possible.
> <end rant>
>  =20
Wow, that's a lot of frustration ;-)
In fact, there is not currently any alternative. cmake is the most=20
likely to replace the autotools in the long run, but it is still very=20
new and little distributed.

Timoth=E9e

Re: 'make distcheck' has problems with the wxt files

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

On Saturday 17 June 2006 06:51 pm, you wrote:
> I propose the following (assuming that /usr/lib/X11/app-defaults is the 
> default directory for this kind of stuff - I don't have such directory 
> on my machine, everything is in /usr/share/X11/app-defaults instead, 
> which makes more sense to me) :
> 
> xresourcedir = $(libdir)/X11/app-defaults/Gnuplot
> xresource_DATA = Gnuplot.app-defaults

Did you actually try this and get it to work?
I placed these lines in Makefile.am and nothing happened at all.
Also, the autoconf documentation claims that it should be able
to find the proper xresourcedir definition by itself if the lines
AC_SUBST(LIBRARIES_FOR_X)
AC_PATH_XTRA
are placed in configure.in.    But it doesn't.
In fact, half the options I try from the autoconf manual don't work :-(

<begin rant>
I think I will give up on this, and leave it for some autoconf
guru (Lars?)   To truth is, I find the autoconf documentation 
impenetrable, and the design of the program itself hideous.
Somebody should start over and write a better-designed 
autoconfiguration system.  I guess gnu autoconf is better than
nothing, but that's not saying much.  It doesn't quite reach the
level of horrible design achieved by the 'info' system, but I'd
rather not touch either one of them if at all possible.
<end rant>

Anyhow, I've hard-coded the Makefile so that it passes
"make distcheck", at least for me.  It would be nice to have
./configure pick up XRESOURCEPATH from the environment, if defined,
but I can't get that to work properly either.

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

Re: 'make distcheck' has problems with the wxt files

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

Ethan A Merritt wrote:
> On Saturday 17 June 2006 03:19 pm, you wrote:
>  =20
>> Ethan A Merritt wrote:
>>    =20
>>> I'm having my own battle with 'make distcheck', with regard to the
>>> recently added X-Resources file.
>>>      =20
>> By the way, as for this file, why not installing it to a standard=20
>> directory relatively to gnuplot (PREFIX/share/gnuplot/apps-defaults ?)=
,=20
>>    =20
>
> The standard directory is dictated by X11 itself.
> We don't get a choice in the matter.
>  =20
I understand that.
>  =20
>> and let 'xrdb' add it to the database ? (or maybe not installing it at=
 all)
>>    install-data-local:
>>        xrdb $(pkgdatadir)Gnuplot.app-defaults
>>    =20
>
> That would do nothing useful.
> xrdb must be run every time a user starts an X session.
>  =20
Ok, I did not know that.

I guess it will be hard to do something that will work everytime with=20
this file.
I propose the following (assuming that /usr/lib/X11/app-defaults is the=20
default directory for this kind of stuff - I don't have such directory=20
on my machine, everything is in /usr/share/X11/app-defaults instead,=20
which makes more sense to me) :

xresourcedir =3D $(libdir)/X11/app-defaults/Gnuplot
xresource_DATA =3D Gnuplot.app-defaults

If 'configure' is called with '--prefix=3D/usr' it will work, otherwise=20
the file will still be installed but probably not used by X. That=20
doesn't seem worse to me than the current situation which only works=20
when root installs. And it would work with 'make distcheck'.

(to install in /usr/share/X11/app-defaults instead, the first line would=20
be :
xresourcedir =3D $(datadir)/X11/app-defaults/Gnuplot
)

Timoth=E9e

Re: 'make distcheck' has problems with the wxt files

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

On Saturday 17 June 2006 03:19 pm, you wrote:
> Ethan A Merritt wrote:
> > I'm having my own battle with 'make distcheck', with regard to the
> > recently added X-Resources file.
> By the way, as for this file, why not installing it to a standard 
> directory relatively to gnuplot (PREFIX/share/gnuplot/apps-defaults ?), 

The standard directory is dictated by X11 itself.
We don't get a choice in the matter.

> and let 'xrdb' add it to the database ? (or maybe not installing it at all)
>    install-data-local:
>        xrdb $(pkgdatadir)Gnuplot.app-defaults

That would do nothing useful.
xrdb must be run every time a user starts an X session.
There is no persistence across users or across sessions.

	Ethan

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

Re: 'make distcheck' has problems with the wxt files

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

Ethan A Merritt wrote:
> I'm having my own battle with 'make distcheck', with regard to the
> recently added X-Resources file.
By the way, as for this file, why not installing it to a standard=20
directory relatively to gnuplot (PREFIX/share/gnuplot/apps-defaults ?),=20
and let 'xrdb' add it to the database ? (or maybe not installing it at al=
l)

Makefile.am would contain :

    dist_pkgdata_DATA =3D Gnuplot.app-defaults

and something like :

   install-data-local:
       xrdb $(pkgdatadir)Gnuplot.app-defaults


Timoth=E9e

Re: the ConTeXt terminal

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

On 6/17/06, Daniel J Sebald wrote:
> Mojca Miklavec wrote:
>
> > I know that I could ignore the PostScript graphic commands, but I need
> > to study the way how (La)TeX &.PostScript are integrated/how separate
> > files are handled inside Gnuplot, etc. I have to patch/integrate both
> > terminals in this case. I'm planning to do that, but it's not really
> > the priority unless someone confident with that code would be willing
> > to help. For the moment is was much easier to write my own code for
> > doing the graphic.
>
> Well, it's up to you of course, and both methods have their benefits.  But if you haven't given combined LaTeX/PostScript a try, it is worth understanding.

As soon as I manage to do the rest, I'll look into it.

> >>Unless ConTeXt is improving on TeX graphics, from what I've seen PostScript is better than TeX graphics.  Much nicer looking and controllable arrows, etc.
> >
> > What exactly do you mean by TeX graphics? \begin{picture} is useless
> > from my point of view, picTeX might be slightly better(?),
>
> Yes, this is what I was referring to, TeX graphics worthless.

I would agree with it. PSTricks might be a bit better, but then again:
they don't work with pdfTeX well. There are some more packages around,
but once I saw metapost, I didn't want to exchange it for anything
else for static 2D drawings.

> > which outputs a PostScript file which is postpocessed (converted to
> > PDF with special trickery) and included into final PDF literally.
>
> Something like ps2pdf, I take it.

No, self-written (assuming the simple output from metapost).

>
> > I
> > don't know how exactly it works if a flavour of TeX other than pdfTeX
> > is used, for example XeTeX, with DVI file as an intermediate step
> > (.tex -> .dvi -> PDF). But when XeTeX came out for the Linux platform
> > last monts, Hans was sitting the whole afternoon behind the laptop
> > trying to fix the existing code, so that transparency started to work
> > with XeTeX as well.
> >
> > But the nice part of it is that I don't really have to care about what
> > is going on behind the scenes: it simply works (with exceptions of
> > bugs).
>
> "It" meaning what simply works?

I just wanted to say that I don't have to care about calling dozens of
conversions inbetween. Very simple syntax integrates TeX and graphics
pretty well. (The conversions happen behind the scenes.)

> Yes, I see that now having paged through Hans H.'s amazing document metafun-s.pdf.  Wow, he put a lot of work into that!  I wonder, though, why he didn't simply format the text more like a book as opposed to slides.

It's more convenient to use on the computer. You also have a paper
version from the same source:
http://www.pragma-ade.com/general/manuals/metafun-p.pdf.

(see http://www.pragma-ade.com/overview.htm)

> I find the gray, seemingly random borders a tad disorienting and annoying.

They are random (each time when a source is compiled they come out
differently, but PDF isn't able to handle randomness, so they are
"fixed"). However: I like the design, but that's my personal opinion
only.

Mojca

Re: the ConTeXt terminal

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

Mojca Miklavec wrote:

> I know that I could ignore the PostScript graphic commands, but I need
> to study the way how (La)TeX &.PostScript are integrated/how separate
> files are handled inside Gnuplot, etc. I have to patch/integrate both
> terminals in this case. I'm planning to do that, but it's not really
> the priority unless someone confident with that code would be willing
> to help. For the moment is was much easier to write my own code for
> doing the graphic.

Well, it's up to you of course, and both methods have their benefits.  But if you haven't given combined LaTeX/PostScript a try, it is worth understanding.


>>Unless ConTeXt is improving on TeX graphics, from what I've seen PostScript is better than TeX graphics.  Much nicer looking and controllable arrows, etc.
> 
> 
> What exactly do you mean by TeX graphics? \begin{picture} is useless
> from my point of view, picTeX might be slightly better(?),

Yes, this is what I was referring to, TeX graphics worthless.


> which outputs a PostScript file which is postpocessed (converted to
> PDF with special trickery) and included into final PDF literally.

Something like ps2pdf, I take it.


> I
> don't know how exactly it works if a flavour of TeX other than pdfTeX
> is used, for example XeTeX, with DVI file as an intermediate step
> (.tex -> .dvi -> PDF). But when XeTeX came out for the Linux platform
> last monts, Hans was sitting the whole afternoon behind the laptop
> trying to fix the existing code, so that transparency started to work
> with XeTeX as well.
> 
> But the nice part of it is that I don't really have to care about what
> is going on behind the scenes: it simply works (with exceptions of
> bugs).

"It" meaning what simply works?


> 
> With MetaPost ("ConTeXt graphics") you can basically do everything
> that you can do in PostScript: the code is converted to PostScript
> indeed. You can't write literal PS code, but MetaPost is still a
> programming language. You can draw exactly the same arrow in MetaPost
> as you can do in PostScript.

Yes, I see that now having paged through Hans H.'s amazing document metafun-s.pdf.  Wow, he put a lot of work into that!  I wonder, though, why he didn't simply format the text more like a book as opposed to slides.  I find the gray, seemingly random borders a tad disorienting and annoying.

OK, so I've learned a bit here about ConTeXt.  Thanks.

Dan

Re: the ConTeXt terminal

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

On 6/17/06, Daniel J Sebald wrote:
> Mojca Miklavec wrote:
>
> > I'm thinking about adding an option to use PostScript instead of
> > "quasi-native" graphics for the background, but many other things have
> > higher priority for now. (I would probably need to rewrite parts of
> > PostScript terminal and to study undocumented PS code as well as
> > supporting that inclusion in ConTeXt, so it could take me some time
> > that I don't feel worth investing yet.)
>
> But if you use something derivative of pslatex, you shouldn't have to study undocumented PS code.  That should be handled correctly already.  You'd need simply to supply the proper syntax for the text that ConTeXt requires as opposed to what LaTeX requires.

I know that I could ignore the PostScript graphic commands, but I need
to study the way how (La)TeX &.PostScript are integrated/how separate
files are handled inside Gnuplot, etc. I have to patch/integrate both
terminals in this case. I'm planning to do that, but it's not really
the priority unless someone confident with that code would be willing
to help. For the moment is was much easier to write my own code for
doing the graphic.

> Unless ConTeXt is improving on TeX graphics, from what I've seen PostScript is better than TeX graphics.  Much nicer looking and controllable arrows, etc.

What exactly do you mean by TeX graphics? \begin{picture} is useless
from my point of view, picTeX might be slightly better(?), but not
that much. What "ConTeXt graphic" means in this case is the following:

    \commandtostartgraphic
    ...
    drawing commands
    ...
    \commandtostopgraphic

drawing commands (ie. everything between the two commands for start
and stop the graphic) are written to a file, processed by MetaPost
which outputs a PostScript file which is postpocessed (converted to
PDF with special trickery) and included into final PDF literally. I
don't know how exactly it works if a flavour of TeX other than pdfTeX
is used, for example XeTeX, with DVI file as an intermediate step
(.tex -> .dvi -> PDF). But when XeTeX came out for the Linux platform
last monts, Hans was sitting the whole afternoon behind the laptop
trying to fix the existing code, so that transparency started to work
with XeTeX as well.

But the nice part of it is that I don't really have to care about what
is going on behind the scenes: it simply works (with exceptions of
bugs).

With MetaPost ("ConTeXt graphics") you can basically do everything
that you can do in PostScript: the code is converted to PostScript
indeed. You can't write literal PS code, but MetaPost is still a
programming language. You can draw exactly the same arrow in MetaPost
as you can do in PostScript.

Less supported (but conditionally possible) are shading and other
patterns introduced in later versions of PostScript. But on the other
hand you can use spot colors, transparency, ...

Mojca

Rotate plot in Gnuplot

[<Olv...@np...>]

Hello,

It is possible to rotate a plot 90 degrees before plotting on screen?

Best regards,
Olvar Lovas
NPD

Re: 'make distcheck' has problems with the wxt files

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

Ethan A Merritt wrote:
> I'm having my own battle with 'make distcheck', with regard to the
> recently added X-Resources file.  I've put lines in .../share/Makefile.=
am
>
>    install-data-local:
> 	$(mkinstalldirs) $(DESTDIR)$(XRESOURCEPATH)
>         if test -d $(DESTDIR)$(XRESOURCEPATH) && test -w $(DESTDIR)$(XR=
ESOURCEPATH); then \
>           $(INSTALL_DATA) Gnuplot.app-defaults $(DESTDIR)$(XRESOURCEPAT=
H)/Gnuplot \
>         ; fi
>
> However, this doesn't work during 'make distcheck' becuase $(DESTDIR) i=
s
> not being expanded.  Why not?  It seems to expand correctly for the sim=
ilar
> lines in .../term/Makefile.am
>
>    install-data-local:
>         $(mkinstalldirs) $(DESTDIR)$(GNUPLOT_PS_DIR)
>         $(INSTALL_DATA) $(srcdir)/PostScript/*.ps $(DESTDIR)$(GNUPLOT_P=
S_DIR)
>
> Why does the latter get expanded to
> =09
>    /bin/sh ../../mkinstalldirs /home/merritt/cvs/gnuplot-cvs/gnuplot-4.=
1.0/_inst/share/gnuplot/4.1/PostScript
>
> While the former gets expanded to
>
>    /bin/sh ../../mkinstalldirs /usr/lib/X11/app-defaults
>  =20
I don't really know why one works while the other does not, but at least=20
here is an interesting part of 'info autoconf', searching for 'DESTDIR' :

     My package needs to install some configuration file.  I tried to use
     the following rule, but `make distcheck' fails.  Why?
          # Do not do this.
          install-data-local:
                  $(INSTALL_DATA) $(srcdir)/afile $(DESTDIR)/etc/afile

    (...)

    `make distcheck' fails because they are installing files to=20
hard-coded paths.  In the later
    case the path is not really hard-coded in the package, but we can
    consider it to be hard-coded in the system (or in whichever tool that
    supplies the path).  As long as the path does not use any of the
    standard directory variables (`$(prefix)', `$(bindir)', `$(datadir)',
    etc.), the effect will be the same: user-installations are impossible.

    (...)

   Now, there are some easy solutions.

   The above `install-data-local' example for installing `/etc/afile'
    would be better replaced by

     sysconf_DATA =3D afile

    by default `sysconfdir' will be `$(prefix)/etc', because this is what
    the GNU Standards require.  When such a package is installed on a FHS
    compliant system, the installer will have to set `--sysconfdir=3D/etc=
'.
    As the maintainer of the package you should not be concerned by such
    site policies: use the appropriate standard directory variable to
    install your files so that installer can easily redefine these
    variables to match their site conventions.
________

So this does not explain why it works for term/Makefile.am, but it tells=20
you that they expect you to use the two following lines instead of the=20
custom install rules using $( DESTDIR) :

	xresourcedir =3D $(*libdir*)/X11/app-defaults/Gnuplot

	xresource_DATA =3D Gnuplot.app-defaults


Timoth=E9e

Re: 'make distcheck' has problems with the wxt files

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

On Friday 16 June 2006 11:12 pm, Timoth=E9e Lecomte wrote:
> When 'make distcheck' enters ./demo to do 'make check', =20
> GNUPLOT_DRIVER_DIR is set to " `pwd`/../src ", so that gnuplot_x11 is=20
> looked in the right place. I thought I would just had to similarly set=20
> WXT_PNG_DIR to " `pwd` /../src/wxterminal/bitmaps/png ", but it does not=
=20
> work. When I say " 'make distcheck' enters ./demo", in fact it enters=20
> <gnuplot root>/gnuplot-4.1.0/_build/demo and there is nothing in=20
> <gnuplot_root>/gnuplot-4.1.0/_build/src/wxterminal/bitmaps/png as 'make=20
> install' has not been called, whereas gnuplot_x11 is is=20
> <gnuplot_root>/gnuplot-4.1.0/_build/src because it has just been compiled.
>=20
> I thought I could set WXT_PNG_DIR to " `pwd`=20
> /../../../src/wxterminal/bitmaps/png ", but that would not work if you=20
> just try 'make check' in <gnuplot_root>.
>=20
> I would need an absolute path to <gnuplot_root>, but I don't know how to=
=20
> get this one.
>=20
> Any suggestion ?

Not really.
I'm having my own battle with 'make distcheck', with regard to the
recently added X-Resources file.  I've put lines in .../share/Makefile.am

   install-data-local:
	$(mkinstalldirs) $(DESTDIR)$(XRESOURCEPATH)
        if test -d $(DESTDIR)$(XRESOURCEPATH) && test -w $(DESTDIR)$(XRESOU=
RCEPATH); then \
          $(INSTALL_DATA) Gnuplot.app-defaults $(DESTDIR)$(XRESOURCEPATH)/G=
nuplot \
        ; fi

However, this doesn't work during 'make distcheck' becuase $(DESTDIR) is
not being expanded.  Why not?  It seems to expand correctly for the similar
lines in .../term/Makefile.am

   install-data-local:
        $(mkinstalldirs) $(DESTDIR)$(GNUPLOT_PS_DIR)
        $(INSTALL_DATA) $(srcdir)/PostScript/*.ps $(DESTDIR)$(GNUPLOT_PS_DI=
R)

Why does the latter get expanded to
=09
   /bin/sh ../../mkinstalldirs /home/merritt/cvs/gnuplot-cvs/gnuplot-4.1.0/=
_inst/share/gnuplot/4.1/PostScript

While the former gets expanded to

   /bin/sh ../../mkinstalldirs /usr/lib/X11/app-defaults



=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: 'make distcheck' has problems with the wxt files

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

Timoth=E9e Lecomte wrote:
> Ethan Merritt wrote:
>  =20
>> On Friday 16 June 2006 04:33 pm, you wrote:
>>  =20
>>    =20
>>> Ethan Merritt wrote:
>>>    =20
>>>      =20
>>>> Procedure:
>>>> ./prepare
>>>> ./configure --readline=3Dgnu
>>>> make distclean
>>>>
>>>> Non-fatal error message during the "make check" part
>>>> ----------------------------------------------------
>>>>   Can't load PNG icon(s) of the toolbar.
>>>>      =20
>>>>        =20
>>> I can only solve that by using XPM files included at compile time.
>>>    =20
>>>      =20
>> I don't see why that should be. =20
>> Isn't it just a matter of setting an environmental variable
>> during the "make check" run so that the icons are picked up
>> from the build directory rather than their eventual install
>> directory?
>> That's what it does with GNUPLOT_DRIVER_DIR (to pick up gnuplot_x11).
>>  =20
>>    =20
> Oh yes, I forgot that option. I can do that.
>
> Timoth=E9e
>  =20
Hmm. It turns out not to be as easy as it seems.

The difference with gnuplot_x11 is that the latter is a compiled file.=20
Let me explain, in case one of you has an idea to solve this mess.

When 'make distcheck' enters ./demo to do 'make check', =20
GNUPLOT_DRIVER_DIR is set to " `pwd`/../src ", so that gnuplot_x11 is=20
looked in the right place. I thought I would just had to similarly set=20
WXT_PNG_DIR to " `pwd` /../src/wxterminal/bitmaps/png ", but it does not=20
work. When I say " 'make distcheck' enters ./demo", in fact it enters=20
<gnuplot root>/gnuplot-4.1.0/_build/demo and there is nothing in=20
<gnuplot_root>/gnuplot-4.1.0/_build/src/wxterminal/bitmaps/png as 'make=20
install' has not been called, whereas gnuplot_x11 is is=20
<gnuplot_root>/gnuplot-4.1.0/_build/src because it has just been compiled.

I thought I could set WXT_PNG_DIR to " `pwd`=20
/../../../src/wxterminal/bitmaps/png ", but that would not work if you=20
just try 'make check' in <gnuplot_root>.

I would need an absolute path to <gnuplot_root>, but I don't know how to=20
get this one.

Any suggestion ?

Timoth=E9e

Re: the ConTeXt terminal

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

Mojca Miklavec wrote:

> I'm thinking about adding an option to use PostScript instead of
> "quasi-native" graphics for the background, but many other things have
> higher priority for now. (I would probably need to rewrite parts of
> PostScript terminal and to study undocumented PS code as well as
> supporting that inclusion in ConTeXt, so it could take me some time
> that I don't feel worth investing yet.)

But if you use something derivative of pslatex, you shouldn't have to study undocumented PS code.  That should be handled correctly already.  You'd need simply to supply the proper syntax for the text that ConTeXt requires as opposed to what LaTeX requires.

Unless ConTeXt is improving on TeX graphics, from what I've seen PostScript is better than TeX graphics.  Much nicer looking and controllable arrows, etc.

Dan

Re: the ConTeXt terminal

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

On 6/14/06, Daniel J Sebald wrote:
> Mojca Miklavec wrote:
> > On 6/14/06, Daniel J Sebald wrote:
> >
> >> Mojca,
> >>
> >> Is there a web page for ConTeXt somewhere?
> >
> >
> > http://wiki.contextgarden.net
>
> Ah, so it is similar to LaTeX in many ways with perhaps a slight variation in syntax and improved features.  Math formatting looks very similar to LaTeX.

Math formatting should not only be similar, but exactly the same
(unless perhaps in some multiline environments ...) since both LaTeX
and ConTeXt use (plain) TeX for doing math.

>
> What is the approach your are taking?  I see there is a means to import external graphics into ConTeXt.  The power of Xfig and gnuplot, in my mind, is the ability to have combined LaTeX and PostScript, i.e., the math format and font characteristics native to LaTeX typesetting intermixed with the far superior graphical elements of PostScript.  Is that what you are aiming for in ConTeXt as well?

I started thinking about PostScript after I realized how slow current
rendering indeed was, but the developer of ConTeXt is currently
reimplementing the whole mechanism for handling labels inside
graphics, so I expect drastic improvements in efficiency.

The current implementation does both graphics and labels in ConTeXt
(in MetaFun): I wouldn't call the PS terminal "far superior graphical
elements of PostScript", but rather "far more efficient". ConTeXt can
theoretically do just as good job as PostScript (it's indeed using
a-kind-of-postscript intermediate step), but it can't "write PS
procedures" just as PS terminal does and the intermediate files are
currently way too big. You could compare PostScript terminal vs.
ConTeXt graphic capabilities with (highly portable) assembler vs. C
for simple tasks on ancient machines. With C you can theoretically do
the same as with Assembler, but not as efficient and you need some
compiler first.

I'm thinking about adding an option to use PostScript instead of
"quasi-native" graphics for the background, but many other things have
higher priority for now. (I would probably need to rewrite parts of
PostScript terminal and to study undocumented PS code as well as
supporting that inclusion in ConTeXt, so it could take me some time
that I don't feel worth investing yet.)

Mojca

Re: Bug #1503114

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

Petr Mikulik wrote:
>>>> 2)  BUG 1503114        FIX: 1107709 plot [-1:1] x is plotted with
>>>> asymmetric y-axis
>>>
>>>
>>> Floating-point rounding is tricky stuff.  It's completely inevitable
>>> that sometimes, results will surprise people.  All this patch does is
>>> move the surprise from a seemingly obvious place to a less obvious one.
>>>  An axis ending at 2.0000001 has no more business being artificially cut
>>> down to 2.0 than one ending at 2.001.
>>
>>
>> I think it does in some cases, and depends on the range.  I'll 
>> illustrate with two ranges determined by the data input.
>>
>> 2) [-2.0 : 2.0000001]
>>
>> In the first case, yes definitely, the limits have no business being 
>> artificially shrunk.
> 
> 
> What about rounding range limits to the nearest "nice value" in a range of
> 100*MachineEpsilon?

Well, yes that is an alternative.  And it accounts, I think, for most of the problems that would likely arise because of some arithmatic error.  I wouldn't mind seeing a formal use of "MachinePrecision".  There is the definition "DBL_EPSILON".  And it would be nice to have some form of epsilon defined, just like pi is defined, so that user can utilize it in function definitions.

However, I still think that rounding to within 1/500 or 1/1000 the axis range--whatever might be beyond the resolution of the display--is a plausible strategy.  Could even have a definable variable, visual_precision (default 0.001), meaning to round outward to within abs(max - min)*visual_precision.  The user could then turn of the effect by setting visual_precision equal to 0.

Anyway, range rounding should be a topic in the documentation and/or part of the "xrange" documentation somewhere.

Dan

Re: 'make distcheck' has problems with the wxt files

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

Ethan Merritt wrote:
> On Friday 16 June 2006 04:33 pm, you wrote:
>  =20
>> Ethan Merritt wrote:
>>    =20
>>> Procedure:
>>> ./prepare
>>> ./configure --readline=3Dgnu
>>> make distclean
>>>
>>> Non-fatal error message during the "make check" part
>>> ----------------------------------------------------
>>>   Can't load PNG icon(s) of the toolbar.
>>>      =20
>> I can only solve that by using XPM files included at compile time.
>>    =20
>
> I don't see why that should be. =20
> Isn't it just a matter of setting an environmental variable
> during the "make check" run so that the icons are picked up
> from the build directory rather than their eventual install
> directory?
> That's what it does with GNUPLOT_DRIVER_DIR (to pick up gnuplot_x11).
>  =20
Oh yes, I forgot that option. I can do that.

Timoth=E9e

Re: 'make distcheck' has problems with the wxt files

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

On Friday 16 June 2006 04:33 pm, you wrote:
> Ethan Merritt wrote:
> > Procedure:
> > ./prepare
> > ./configure --readline=gnu
> > make distclean
> >
> > Non-fatal error message during the "make check" part
> > ----------------------------------------------------
> >   Can't load PNG icon(s) of the toolbar.
>
> I can only solve that by using XPM files included at compile time.

I don't see why that should be.  
Isn't it just a matter of setting an environmental variable
during the "make check" run so that the icons are picked up
from the build directory rather than their eventual install
directory?
That's what it does with GNUPLOT_DRIVER_DIR (to pick up gnuplot_x11).

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

Re: 'make distcheck' has problems with the wxt files

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

Ethan Merritt wrote:
> Procedure:
> ./prepare
> ./configure --readline=3Dgnu
> make distclean
>
> Non-fatal error message during the "make check" part
> ----------------------------------------------------
>   Can't load PNG icon(s) of the toolbar.
>  =20
I can only solve that by using XPM files included at compile time. As I=20
told in a previous message, this adds some extra size to the executable,=20
I don't know exactly how much (~30 KB of source files, but probably much=20
less once compiled (i.e. becomes binary)).
> Fatal error:
> ------------
> make[2]: Entering directory=20
> `/home/merritt/cvs/gnuplot-cvs/gnuplot-4.1.0/_build/src'
> cp: cannot create regular file=20
> `/home/merritt/cvs/gnuplot-cvs/gnuplot-4.1.0/_build/gnuplot-4.1.0/src/w=
xterminal/gp_cairo.c':=20
> Permission denied
> cp: cannot create regular file=20
> `/home/merritt/cvs/gnuplot-cvs/gnuplot-4.1.0/_build/gnuplot-4.1.0/src/w=
xterminal/wxt_gui.cpp':=20
> Permission denied
> make[2]: *** [distdir] Error 1
> make[2]: Leaving directory=20
> `/home/merritt/cvs/gnuplot-cvs/gnuplot-4.1.0/_build/src'
> make[1]: *** [distdir] Error 1
> make[1]: Leaving directory=20
> `/home/merritt/cvs/gnuplot-cvs/gnuplot-4.1.0/_build'
> make: *** [distcheck] Error 2
>
>
> I'm guessing that something in the script is failing to create the
> .../_build/gnuplot-4.1.0/src/wxterminal/   directory, but I don't=20
> know quite how this thing works :-(
>  =20
I solved that problem (and the others related to the distribution of the=20
xpm and png icons which appeared later in the 'make distcheck' process).

Now 'make distcheck' seems to go almost to its completion, but ends up=20
like that :

make[2]: quittant le r=E9pertoire =AB=20
/home/tipote/gnuplot-cvs2/gnuplot-4.1.0/_build =BB
rm -f config.status config.cache config.log configure.lineno=20
configure.status.lineno
rm -f Makefile
ERROR: files left in build directory after distclean:
./demo/temp.dat
make[1]: *** [distcleancheck] Erreur 1
make[1]: quittant le r=E9pertoire =AB=20
/home/tipote/gnuplot-cvs2/gnuplot-4.1.0/_build =BB
make: *** [distcheck] Erreur 2

Thanks for your work, Ethan.

Best regards,

Timoth=E9e

'make distcheck' has problems with the wxt files

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

Procedure:
./prepare
./configure --readline=gnu
make distclean

Non-fatal error message during the "make check" part
----------------------------------------------------
  Can't load PNG icon(s) of the toolbar.

Fatal error:
------------
make[2]: Entering directory 
`/home/merritt/cvs/gnuplot-cvs/gnuplot-4.1.0/_build/src'
cp: cannot create regular file 
`/home/merritt/cvs/gnuplot-cvs/gnuplot-4.1.0/_build/gnuplot-4.1.0/src/wxterminal/gp_cairo.c': 
Permission denied
cp: cannot create regular file 
`/home/merritt/cvs/gnuplot-cvs/gnuplot-4.1.0/_build/gnuplot-4.1.0/src/wxterminal/wxt_gui.cpp': 
Permission denied
make[2]: *** [distdir] Error 1
make[2]: Leaving directory 
`/home/merritt/cvs/gnuplot-cvs/gnuplot-4.1.0/_build/src'
make[1]: *** [distdir] Error 1
make[1]: Leaving directory 
`/home/merritt/cvs/gnuplot-cvs/gnuplot-4.1.0/_build'
make: *** [distcheck] Error 2


I'm guessing that something in the script is failing to create the
.../_build/gnuplot-4.1.0/src/wxterminal/   directory, but I don't 
know quite how this thing works :-(

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

emf : set label colors effects other elements

[Torfinn O. <Tor...@gm...>]

gnuplot - version 4.1 patchlevel 0

Downloaded and compiled just recently from CVS on Cygwin (on Win XP).
Worked just great -out of the box - thanks for great documentation and tool.

For information:

When using the emf-terminal I find that the colors of plot elements: boundary
box, curves and labels are different from what I see on the screen - furthermore
- the colors seems to be dependant on the last label color I specify, like:

set label "label to be colored blue"  ...... tc lt 3

The following plot should give 3 files: plot1.emf, plot2.emf and plot3.emf
describing this issue. The xlabel describes what I see:

Torfinn

------------------
reset

set output 'plot1.emf'
set terminal emf
set grid lt 23


#set label 'red blue' at screen 0.010,0.030 tc lt 3  #diff here
#set label 'red'      at screen 0.010,0.030 tc lt 1  #diff here 
set title  "Investigating red and blue" 
set xlabel "Guess this one is correct, all lines black"
set ylabel "All axis, curves and titles are black"

plot    \
 x   t 'x'   w lp lt -1 lw 2         ,     \
x*x  t 'x*x' w l  lt  1

reset


set output 'plot2.emf'
set terminal emf
set grid lt 23


set label 'red blue' at screen 0.010,0.030 tc lt 3  
set label 'red'      at screen 0.010,0.030 tc lt 1
set title  "Investigating red and blue" 
set xlabel "Here I see that all curves including boundary box, testing label and
text of first key (legend) are red"
set ylabel "red or blue"
set label 'testing color of label'

plot    \
 x   t 'x'   w lp lt -1 lw 2         ,     \
x*x  t 'x*x' w l  lt  1



reset
set output 'plot3.emf'
set terminal emf
set grid lt 23


set label 'red blue' at screen 0.010,0.030 tc lt 3  
#set label 'red'      at screen 0.010,0.030 tc lt 1   # difference here
set title  "Investigating red and blue" 
set xlabel "Here I see that all curves including boundary box, testing label and
text of first key (legend) are blue"
set ylabel "red or blue"
set label 'testing color of label'

plot    \
 x   t 'x'   w lp lt -1 lw 2         ,     \
x*x  t 'x*x' w l  lt  1

Re: What's left for a 4.2 release?

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

> Seriously, I am tempted to include the configuration option
>   ./configure --with-readline=bsd
> because it addresses a recurring issue about readline support.

We can have this "...=bsd" option set during the "beta" phase of gnuplot 
4.2; if it succeeds, then it will stay default for the final 4.2.

> Petr has suggested also including
>    #1027032      Connect gnuplot_x11 to exterior application
> But I don't think this is polished yet (mousing is very problematic)
> and I'd rather leave it out than include a broken version that
> can't be fixed later without breaking backwards compatibility.

If the interactivity is a problem, then there are two possibilities:
- don't include it
- include it without any mouse&hotkey interactivity so that it can be added
   later from scratch

---
PM