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

Re: minimum installation query

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

On Mon, 21 Jan 2008 21:52:07 +0100, Ethan A Merritt  =

<merritt@u.washington.edu> wrote:

> In the Makefile there is a line
> SUBDIRS =3D config m4 term src docs $(LISPDIR) man demo tutorial share=

> Remove the "docs" entry and any others that you do not care about.

That the simplest solution. It did the trick.

After a closer look I realised I was confusing two similar fs clones I'd=
  =

been working on. The true problem was the trimmed down fs was lacking  =

doc2gih and indeed make was failing as well, so that is all consistant.

What this does bring out is that there is no check for doc2gih in the  =

preamble. Since this fails to compile and hence fails to install even th=
e  =

executable this is a fatal error and probably should be checked for in t=
he  =

preamble.

Sorry I did not spot this earlier.

regards.

Re: minimum installation query

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

On Mon, 21 Jan 2008 21:52:07 +0100, Ethan A Merritt  =

<merritt@u.washington.edu> wrote:

> On Monday 21 January 2008 07:25, pl...@pi... wrote:
>> Hi,
>>
>> I am trying to build a minimum sized installation for use on an arm S=
BC
>> using crosstools on debian 3.1
>>
>> Mostly it seems to be going perfectly but I have a couple of hitches.=

>>
>> Firstly gnuplot.gih is about half a meg that I could do without. It's=

>> addind about 25% to the foot print and will be totally useless on the=

>> headless target. Is there (or should there be) a means to take this o=
ut  =

>> of
>> the build options?
>>
>> I could of course just delete it but that's a hack and I dont know if=
 it
>> will cause a failure at runtime.
>
> You can test the effect for yourself easily. Just delete the file.
> It causes a non-fatal error message at runtime if you type "help":
> /usr/local/share/gnuplot/4.3/gnuplot.gih: No such file or directory
>
> gnuplot.gih compresses by about a factor of about 4X using gzip.
> Perhaps it would be worth tweaking the code to uncompress dynamically?=

>
>> Also it appears not to get built by `make`
>
> It is normally. I don't know what you may have tweaked in the Makefile=
.

No, I have not touched the makefile . I'll update to cvs and check again=
.

>
>> but during `make install` it
>> seems to be detected as missing and an attempt is made to build it. T=
his
>> suggests an error in the make files.
>
> No. That is correct behavior.  "make install" is a superset of "make  =

> all".
> If it detects that a component hasn't been made, it will do that first=
.
>

I realise that , I was meaning it seemed there was an error in that it w=
as  =

not getting caught my make itself. This have been missed if it got picke=
d  =

up by make install. I'll report back if it still does on clean cvs.


>> /bin/sh: line 1: arm-linux-gcc: command not found
>> make[2]: *** [alloc.o] Error 127
>> make[2]: Leaving directory `/home/prof/tmp/gnuplot/src'
>> make[1]: *** [install-recursive] Error 1
>> make[1]: Leaving directory `/home/prof/tmp/gnuplot/src'
>> make: *** [install-recursive] Error 1
>>
>>
>> This error is coming to light since root does not have the cross  =

>> compiler
>> in its path.
>
> [shrug] If you don't want to have it in the path permanently, you coul=
d
> still put the full path in the environmental variable CC before doing =
 =

> "make".

Again this is not an issue, I was just explaining my rather odd set up  =

which caused it to show up in this way.

>
>> If I try install as user (which it does not have write perms
>> for) it creates the gih and then root can install it. Again it seems =
 =

>> wrong
>> that it only gets build by make install rather than make. Root should=
  =

>> not
>> need to build anything to run install and finally, as I said I do not=
  =

>> want
>> the gih file anyway.
>
> FWIW, I have the same problem with the emacs support files.  No matter=
  =

> what
> I tell gnuplot's ./configure script,  "make install" always tries to  =

> write
> into /usr/local/share/emacs/site-lisp/  and fails if it doesn't have r=
oot
> permission.  This drives me bats, but I've never figured out how to fi=
x  =

> it.
>
LOL

>> ./configure tells me that help is always build . This seems to be hal=
f
>> correct. I would be best for this installation if I could be opted ou=
t.
>>
>> What is the best way to clean this up?
>
> In the Makefile there is a line
> SUBDIRS =3D config m4 term src docs $(LISPDIR) man demo tutorial share=

>
> Remove the "docs" entry and any others that you do not care about.
>
> If you are willing to sacrifice the help subsystem in order to make th=
e
> footprint smaller, then logically you would also want to omit help.c f=
rom
> the list of source files and comment out the calls to its routines.

I'm not that tight I need to byte pinch at this stage but saving 500k + =
is  =

relevant.

> You used to be able to accomplish this by adding -DNO_GIH to the CFLAG=
S,
> but that option seems to have suffered from bit rot in a couple of  =

> places.
> I'll see about whiping up a patch to restore that as a viable option
> unless you beat me to it.
>

Thanks, I would have thought that the most consistant way would be  =

--without-help , like --without-doc . That would keep everything tidy in=
  =

one ./configure command .

I wanted to make sure I was not over looking some option.

Many thanks for such a detailed reply.

regards. Peter.

Re: minimum installation query

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

On Monday 21 January 2008 07:25, pl...@pi... wrote:
> Hi,
> 
> I am trying to build a minimum sized installation for use on an arm SBC  
> using crosstools on debian 3.1
> 
> Mostly it seems to be going perfectly but I have a couple of hitches.
> 
> Firstly gnuplot.gih is about half a meg that I could do without. It's  
> addind about 25% to the foot print and will be totally useless on the  
> headless target. Is there (or should there be) a means to take this out of  
> the build options?
> 
> I could of course just delete it but that's a hack and I dont know if it  
> will cause a failure at runtime.

You can test the effect for yourself easily. Just delete the file.
It causes a non-fatal error message at runtime if you type "help":
/usr/local/share/gnuplot/4.3/gnuplot.gih: No such file or directory

gnuplot.gih compresses by about a factor of about 4X using gzip.
Perhaps it would be worth tweaking the code to uncompress dynamically?

> Also it appears not to get built by `make` 

It is normally. I don't know what you may have tweaked in the Makefile.

> but during `make install` it   
> seems to be detected as missing and an attempt is made to build it. This  
> suggests an error in the make files.

No. That is correct behavior.  "make install" is a superset of "make all".
If it detects that a component hasn't been made, it will do that first.

> /bin/sh: line 1: arm-linux-gcc: command not found
> make[2]: *** [alloc.o] Error 127
> make[2]: Leaving directory `/home/prof/tmp/gnuplot/src'
> make[1]: *** [install-recursive] Error 1
> make[1]: Leaving directory `/home/prof/tmp/gnuplot/src'
> make: *** [install-recursive] Error 1
> 
> 
> This error is coming to light since root does not have the cross compiler  
> in its path.

[shrug] If you don't want to have it in the path permanently, you could
still put the full path in the environmental variable CC before doing "make".

> If I try install as user (which it does not have write perms   
> for) it creates the gih and then root can install it. Again it seems wrong  
> that it only gets build by make install rather than make. Root should not  
> need to build anything to run install and finally, as I said I do not want  
> the gih file anyway.

FWIW, I have the same problem with the emacs support files.  No matter what
I tell gnuplot's ./configure script,  "make install" always tries to write 
into /usr/local/share/emacs/site-lisp/  and fails if it doesn't have root
permission.  This drives me bats, but I've never figured out how to fix it.

> ./configure tells me that help is always build . This seems to be half  
> correct. I would be best for this installation if I could be opted out.
> 
> What is the best way to clean this up?

In the Makefile there is a line
SUBDIRS = config m4 term src docs $(LISPDIR) man demo tutorial share

Remove the "docs" entry and any others that you do not care about.

If you are willing to sacrifice the help subsystem in order to make the
footprint smaller, then logically you would also want to omit help.c from
the list of source files and comment out the calls to its routines.
You used to be able to accomplish this by adding -DNO_GIH to the CFLAGS,
but that option seems to have suffered from bit rot in a couple of places.
I'll see about whiping up a patch to restore that as a viable option
unless you beat me to it.

-- 
Ethan A Merritt

minimum installation query

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

Hi,

I am trying to build a minimum sized installation for use on an arm SBC =
 =

using crosstools on debian 3.1

Mostly it seems to be going perfectly but I have a couple of hitches.

Firstly gnuplot.gih is about half a meg that I could do without. It's  =

addind about 25% to the foot print and will be totally useless on the  =

headless target. Is there (or should there be) a means to take this out =
of  =

the build options?

I could of course just delete it but that's a hack and I dont know if it=
  =

will cause a failure at runtime.


Also it appears not to get built by `make` but during `make install` it =
 =

seems to be detected as missing and an attempt is made to build it. This=
  =

suggests an error in the make files.


prof@debbox:~/tmp/gnuplot$ ./configure --without-x --without-tutorial  =

--without-pdf --without-cairo
--disable-wxwidgets --without-gd --with-readline=3Dbuiltin
--prefix=3D/debsTS/usr --host=3Darm-linux


su
make install
....

make[3]: Leaving directory `/home/prof/tmp/gnuplot/src/wxterminal'
make[2]: Leaving directory `/home/prof/tmp/gnuplot/src/wxterminal'
make[2]: Entering directory `/home/prof/tmp/gnuplot/src'
arm-linux-gcc -DHAVE_CONFIG_H -I. -I..  -I../term -I../term
-DBINDIR=3D\"/debsTS/usr/bin\"
-DX11_DRIVER_DIR=3D\"/debsTS/usr/libexec/gnuplot/4.3\"
-DGNUPLOT_PS_DIR=3D\"/debsTS/usr/share/gnuplot/4.3/PostScript\"
-DCONTACT=3D\"gnu...@li...\"
-DHELPFILE=3D\"/debsTS/usr/share/gnuplot/4.3/gnuplot.gih\"
-DGNUPLOT_X11=3D\"`echo gnuplot_x11 | sed 's,x,x,'`\"   -g -O2 -MT alloc=
.o
-MD -MP -MF .deps/alloc.Tpo -c -o alloc.o alloc.c
/bin/sh: line 1: arm-linux-gcc: command not found
make[2]: *** [alloc.o] Error 127
make[2]: Leaving directory `/home/prof/tmp/gnuplot/src'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/prof/tmp/gnuplot/src'
make: *** [install-recursive] Error 1


This error is coming to light since root does not have the cross compile=
r  =

in its path. If I try install as user (which it does not have write perm=
s  =

for) it creates the gih and then root can install it. Again it seems wro=
ng  =

that it only gets build by make install rather than make. Root should no=
t  =

need to build anything to run install and finally, as I said I do not wa=
nt  =

the gih file anyway.

./configure tells me that help is always build . This seems to be half  =

correct. I would be best for this installation if I could be opted out.

What is the best way to clean this up?

Thanks in advance, Peter.

Re: context terminal

[Allin C. <cot...@wf...>]

On Sat, 19 Jan 2008, GDutilleux wrote:

> On Mac OS X 10.3.9 i tried to compile gnuplot 4.2.0 from source with the
> ConTeXt terminal. To do so 
> 1 I added   in term/ the context.trm file provided by Mojka Miklavec. 
> 2 I added #include "context.trm" in src/term.h. 
> 
> On his recipe for building this custom gnuplot Mojka Miklavec 
> mentions a ./prepare gnuplot utility to run first. I don't find 
> it in the 4.2.0 source release.

The "prepare" script is part of gnuplot CVS.  You'll probably have 
to set that up.  See:

http://gnuplot.sourceforge.net/development/index.html

Allin Cottrell

Re: MS C++

[<HBB...@t-...>]

Leopoldo Peralta wrote:

> I would like to build a GNUPLOT application based on MFC (C++ 7.1) MS 
> Visual Studio 2003 running on Windows XP sp2

You're trying too hard.  There's already a pre-made makefile for use 
with MSVC.  It doesn't use MFC, but that's not a problem --- MFC would 
not help with anything anyway.

It's all described in the README and INSTALL files.  Go figure.

MS C++

[Leopoldo P. <lpe...@ca...>]

I would like to build a GNUPLOT application based on MFC (C++ 7.1) MS Visual
Studio 2003 running on Windows XP sp2

 

I would like to know:

 

1.                   What .\src\.. files should I include in the project?

2.                   Is there any additional GNUPLOT Library\dll I should
build and include? What files should be included in this dll project?

3.                   Is there any special setting for MSVS to properly
compile the project?

4.                   What other external references I should made?

 

Leopoldo Peralta

Developer, Procesador Matematico

 

 

 

 

Re: how to use iso-latin-2 with PS terminal

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

On Saturday 19 January 2008 17:43, Mojca Miklavec wrote:

> I'm using Mac OS X and ...

> No, wait ... it's more weird than that. I'm trying to use these
> characters before issuing any other command (setting encoding etc.).
> These letters work "per-se". But they fail in one particular case:
> when I type normally, it works OK, but once I press left arrow (to go
> back in the line), it completely confuses gnuplot whenever I play with
> accented letters (multibyte) forth and back.

That sounds like a problem with the input stream.
Are you using gnu libreadline?  gnuplot's built-in readline?
No readline at all?  Given that this is OSX, we may have to
worry also that the library claims to be gnu libreadline but
is really BSD's editline in disguise.

All I can really say is "it works for me".


> I cannot read the line 
> any more, there is no connection betwen what's on the screen and what
> gnuplot sees. So I need to press [enter], then gnuplot complains about
> invalid characters (which I do not see), and then I may start writing
> from fresh again.
> 
> So: once I press left arrow and try to use unicode letters, it leads
> to really messy/buggy behaviour.

I understand.  But I don't think that is gnuplot's fault, except insofar
as it may be linked against a buggy libreadline.

-- 
Ethan A Merritt

Re: how to use iso-latin-2 with PS terminal

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

T24gSmFuIDE5LCAyMDA4IDk6NTcgUE0sIEV0aGFuIEEgTWVycml0dCB3cm90ZToKPiBPbiBTYXR1
cmRheSAxOSBKYW51YXJ5IDIwMDggMDI6MTUsIE1vamNhIE1pa2xhdmVjIHdyb3RlOgo+ID4gSGVs
bG8sCj4gPgo+ID4gY2FuIHNvbWVvbmUgcGxlYXNlIGhlbHAgbWUgd2l0aCBhIG1pbmltYWwgZXhh
bXBsZSBob3cgdG8gdXNlCj4gPiBpc29fODg1OV8yIGluIHRoZSBwb3N0c2NyaXB0IHRlcm1pbmFs
Pwo+Cj4gQXJlIHlvdSBzdXJlIHRoYXQgdGhlIGNoYXJhY3RlcnMgeW91IGFyZSBlbnRlcmluZyBh
cmUgZW5jb2RlZAo+IGluIGlzbzg4NTktMj8gICBJIGFzayBiZWNhdXNlIHlvdXIgRW1haWwgKHRo
YXQgdGhpcyBpcyBhIHJlcGx5IHRvKQo+IGFycml2ZWQgaGVyZSBlbmNvZGVkIGluIHV0Zi04LCBu
b3QgaXNvODg1OS0yLgoKSG1tbSAuLi4gaW50ZXJlc3RpbmcuCkknbSBzb3JyeSwgaXQgd2FzIHRo
ZSBmYXVsdCBvZiBteSB2aWV3ZXIuIEkgZG9uJ3QgcmVtZW1iZXIgZXZlciBoYXZpbmcKYW55IHBy
b2JsZW1zIHdpdGggYWNjZW50ZWQgbGV0dGVycyBpbiB0aGUgc2FtZSBzZW5zZSBhcyBoZXJlOgph
Y2NlbnRlZCBsZXR0ZXJzIGRpZG4ndCB3b3JrIGluIFBTLCBidXQgYWZ0ZXIgZXhlY3V0aW5nICJw
czJwZGYKZmlsZS5wcyIsIHRoZXkgc2hvd2VkIHVwIE9LIGluIHRoZSByZXN1bHRpbmcgUERGLiAo
SSB3b25kZXIgd2hhdCBhbgphdmVyYWdlIFBvc3RTY3JpcHQgcHJpbnRlciB3b3VsZCBkbyB3aXRo
IGl0LikKCkknbSB1c2luZyBNYWMgT1MgWCBhbmQgdHJpZWQgdG8gdmlldyB0aGUgUFMgZmlsZSB3
aXRoIFByZXZpZXcuYXBwCih3aGljaCBkb2VzIHNvbWUgaW50ZXJuYWwgY29udmVyc2lvbiB0byBQ
REYpLgoKSSdtIHNvcnJ5IGZvciB0aGUgbm9pc2UsIGJ1dCBJIHJlYWxseSBkaWQgbm90IHRoaW5r
IGFib3V0ICJidWdzIiBpbgp0aGUgYXBwbGljYXRpb3MgdXNlZCB0byBvcGVuIHRoZSBQb3N0U2Ny
aXB0IGZpbGUgd2hlbiBJIGRpZCBmaXJzdApleHBlcmltZW50cy4KCj4gPiBGb3IgZXhhbXBsZSwg
d2l0aCBzb21lIGxhYmVsICLFoMSNZcW+ZWdlxI1rYW0iLgo+ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgXl5eXl5eXl5eXl4KPiBUaGVzZSBhcmUgVVRGLTggY2hhcmFjdGVycyBhcyBk
aXNwbGF5ZWQgaGVyZS4KCkkga25vdy4gSSBoYXZlIG5vIGluZmx1ZW5jZSBvbiBjaGFyYWN0ZXIg
ZW5jb2RpbmcgaW5zaWRlIHRoZSB3ZWIKaW50ZXJmYWNlIGZvciBteSBtYWlsIChvZnRlbiB0aGV5
IGFyZSBzZW50IHVzaW5nIGNvbXBsZXRlbHkgd2VpcmQKZW5jb2RpbmdzKS4KCj4gPiBXaGF0J3Mg
d29yc2U6IEkgZmlndXJlZCBvdXQgdGhhdCBpZiBJIHRyeSB0byB0eXBlc2V0Cj4gPiAgICBzZXQg
bGFiZWwgImPEjXPFoXrFviIKPiA+IGluIHRlcm1pbmFsIChJIHVzdWFsbHkgbG9hZCBmaWxlcyB3
aGVuIEkgbmVlZCBnbnVwbG90KSwgZXZlbiB0aGF0Cj4gPiBkb2Vzbid0IHdvcmsuCj4KPiBUaGlz
IHNvdW5kcyBsaWtlIGEgcHJvYmxlbSB3aXRoIHlvdXIgdGVybWluYWwgZW52aXJvbm1lbnQsCj4g
aW5kZXBlbmRlbnQgb2YgYW55dGhpbmcgdGhhdCBtaWdodCBiZSB3cm9uZyBpbiBnbnVwbG90Lgo+
Cj4gSSBhbSBndWVzc2luZyB0aGF0IHlvdSBhcmUgdHlwaW5nIGluIFVURjgsIGFuZCB0aGVuIHdo
ZW4geW91IHRlbGwgZ251cGxvdAo+IG9yIGFueSBvdGhlciBhcHBsaWNhdGlvbiB0aGF0IGl0IGlz
IHRvIGJlIGludGVycHJldGVkIGFzIGlzbzg4NTktKgo+IGl0IGJlY29tZXMgbWlzaW50ZXJwcmV0
ZWQgYXMgc29tZSBtdWx0aS1jaGFyYWN0ZXIgZ2liYmVyaXNoLgoKTm8sIHdhaXQgLi4uIGl0J3Mg
bW9yZSB3ZWlyZCB0aGFuIHRoYXQuIEknbSB0cnlpbmcgdG8gdXNlIHRoZXNlCmNoYXJhY3RlcnMg
YmVmb3JlIGlzc3VpbmcgYW55IG90aGVyIGNvbW1hbmQgKHNldHRpbmcgZW5jb2RpbmcgZXRjLiku
ClRoZXNlIGxldHRlcnMgd29yayAicGVyLXNlIi4gQnV0IHRoZXkgZmFpbCBpbiBvbmUgcGFydGlj
dWxhciBjYXNlOgp3aGVuIEkgdHlwZSBub3JtYWxseSwgaXQgd29ya3MgT0ssIGJ1dCBvbmNlIEkg
cHJlc3MgbGVmdCBhcnJvdyAodG8gZ28KYmFjayBpbiB0aGUgbGluZSksIGl0IGNvbXBsZXRlbHkg
Y29uZnVzZXMgZ251cGxvdCB3aGVuZXZlciBJIHBsYXkgd2l0aAphY2NlbnRlZCBsZXR0ZXJzICht
dWx0aWJ5dGUpIGZvcnRoIGFuZCBiYWNrLiBJIGNhbm5vdCByZWFkIHRoZSBsaW5lCmFueSBtb3Jl
LCB0aGVyZSBpcyBubyBjb25uZWN0aW9uIGJldHdlbiB3aGF0J3Mgb24gdGhlIHNjcmVlbiBhbmQg
d2hhdApnbnVwbG90IHNlZXMuIFNvIEkgbmVlZCB0byBwcmVzcyBbZW50ZXJdLCB0aGVuIGdudXBs
b3QgY29tcGxhaW5zIGFib3V0CmludmFsaWQgY2hhcmFjdGVycyAod2hpY2ggSSBkbyBub3Qgc2Vl
KSwgYW5kIHRoZW4gSSBtYXkgc3RhcnQgd3JpdGluZwpmcm9tIGZyZXNoIGFnYWluLgoKU286IG9u
Y2UgSSBwcmVzcyBsZWZ0IGFycm93IGFuZCB0cnkgdG8gdXNlIHVuaWNvZGUgbGV0dGVycywgaXQg
bGVhZHMKdG8gcmVhbGx5IG1lc3N5L2J1Z2d5IGJlaGF2aW91ci4KCj4gPiBJdCBtaWdodCBtYWtl
IHNlbnNlIHRvIGZpeCBzdWNoIHRyaXZpYWwgaXNzdWVzIGZpcnN0LCBiZWZvcmUgZG9pbmcKPiA+
IHBhdGNoZXMgdG8gZXh0ZW5kIGdudXBsb3QgdG8gc3VwcG9ydCBvdGhlciBlbmNvZGluZ3MuCj4K
PiBJIGFncmVlLiBCdXQgSSB0aGluayB0aG9zZSBmaXhlcyBsaWUgb3V0c2lkZSBvZiBnbnVwbG90
LgoKRm9yIHByZXZpZXc6IHllcy4KRm9yIGNvbnNvbGU6IEkgZG8gbm90IGRhcmUgdG8gY2xhaW0g
YW55dGhpbmcsIGJ1dCB2aW0gYW5kIGNvbnNvbGUKaXRzZWxmIHNlZW0gdG8gd29yayBmaW5lICh2
aW0gaXMgb25seSBjb25mdXNlZCBieSAiY29tYmluaW5nIGdseXBocyIKaW4gVW5pY29kZSwgYnV0
IHNpbXBsZSBzdHJpbmdzIHdpdGggdGhlIHNhbWUgbGV0dGVycyB3b3JrIGZpbmUpLgoKSG93IGRv
ZXMgZ251cGxvdCAidGVybWluYWwiIGhhbmRsZSBsZWZ0IGFycm93IGluc2lkZSB1bmljb2RlIHRl
eHQgKG9uZQpieXRlIGJhY2ssIG9uZSBjaGFyYWN0ZXIgYmFjaywgLi4uKT8KCj4gPiAoUGVvcGxl
IGhlcmUga2VlcCBhc2tpbmcgbWUgaG93IHRvIHVzZSBhY2NlbnRlZCBsZXR0ZXJzLiBJIGFsd2F5
cwo+ID4gYW5zd2VyIHRoZW0gdGhhdCB0aGVyZSBpcyBhbG1vc3Qgbm8gc3VpdGFibGUgZ251cGxv
dCB0ZXJtaW5hbCAtIFBTCj4gPiBkb2Vzbid0IHN1cHBvcnQgYWNjZW50ZWQgbGV0dGVycwo+Cj4g
VGhlIHBvc3RzY3JpcHQgdGVybWluYWwgaGFzIHN1cHBvcnRlZCBsYXRpbjIgYW5kIG90aGVyIElT
TyBlbmNvZGluZ3MKPiBmb3IgYSB2ZXJ5IGxvbmcgdGltZSBub3cuICBVVEY4IGlzIHZlcnkgcmVj
ZW50LCBob3dldmVyLgoKSSd2ZSBiZWVuIGF3YXJlIG9mIHRoYXQsIGJ1dCBpdCdzIHZlcnkgZGlm
ZmljdWx0IHRvIHVzZS4gKG5vdCBtZWFudAp2ZXJ5IHNlcmlvdXMsIGJ1dDopICJub2JvZHkiIG9u
IHRoZSBwbGFuZXQgdXNlcyBsYXRpbjIgYW5kICJubyBlZGl0b3IiCnN1cHBvcnRzIGl0ICh0aGF0
J3Mgbm90IHRydWUgb2YgY291c2UsIGJ1dCB3aW5kb3dzIHVzZXMgY3AxMjUwIGFuZApsaW51eCB1
c2VycyBzd2l0Y2ggdG8gdXRmLTgsIGFuZCByZWFsbHk6IG5vbmUgb2YgdGhlIGVkaXRvcnMgSSB1
c2UKc3VwcG9ydCBsYXRpbjIsIG9ubHkgdmltLCBhbmQgZXZlbiB0aGVyZSBpdCdzICJkaWZmaWN1
bHQiIHRvIHVzZSBpdCkuCgo+IFRoZSBzdmcgYW5kIHBkZiB0ZXJtaW5hbHMgaGF2ZSBhbHdheXMg
c3VwcG9ydGVkIGFjY2VudGVkIGNoYXJhY3RlcnMuCj4KPiBUaGUgbmV3IGNhaXJvLWJhc2VkIHRl
cm1pbmFscywgYm90aCBwbmcgYW5kIHBkZiwgYXJlIG5hdGl2ZWx5Cj4gVVRGOCB3aXRoIGludGVy
bmFsIGNvZGUgdG8gY29udmVydCBmcm9tIG90aGVyIGVuY29kaW5ncy4KCkkgaGF2ZSBmb3Jnb3R0
ZW4gYWJvdXQgcGRmY2Fpcm8uCgo+IFNWRyBpcyBhbHNvIG5hdGl2ZWx5IFVURjguCgpCdXQgSSBk
byBub3Qga25vdyBob3cgdG8gdXNlIGl0IC4uLiBJIG1lYW4gLi4uIEkgZG8gbm90IGtub3cgaG93
IHRvCmluY2x1ZGUgYSBzdmcgZ3JhcGhpYyBpbnRvIGEgVGVYIGRvY3VtZW50IChhcGFydCBmcm9t
IGNvbnZlcnRpbmcgaXQgdG8KUERGIGZpcnN0IHdpdGggSW1hZ2VNYWdpY2spLgoKPiA+IGJpdG1h
cCB0ZXJtaW5hbHMgYXJlIG91dCBvZiBxdWVzdGlvbiwKPgo+IFdoeSBkbyB5b3Ugc2F5IHRoYXQ/
CgpJIG9ubHkgbWVhbiB0aGF0IHRoZXkgZG8gbm90IG9mZmVyIHJlYXNvbmFibGUgcXVhbGl0eSBh
dCBkZWZhdWx0CnJlc29sdXRpb24gKEkgcHJlZmVyIHZlY3RvciBncmFwaGljcyB3aGVuZXZlciBw
b3NzaWJsZSwgdW5sZXNzIHRoZXJlJ3MKYSBnb29kIHJlYXNvbiBmb3IgYml0bWFwIGdyYXBoaWNz
OiBpbiBnbnVwbG90IHRoZXJlIGlzIHByb2JhYmx5IG5vCnJlYXNvbiB0byB1c2UgYml0bWFwIGZv
ciBwcmludGVkIG1hdGVyaWFsKS4gTm90IGJlY2F1c2UgdGhlIHRlcm1pbmFscwp3b3VsZCBiZSBi
YWQsIGJ1dCBiZWNhdXNlIG9mIHRoZSBuYXR1cmUgb2YgYml0bWFwIGdyYXBoaWNzLiBUaGV5J3Jl
CmZpbmUgZm9yIHdlYiwgYnV0IG5vdCBzbyBtdWNoIGZvciBwcmludGVkIG1hdGVyaWFscy4KCj4g
Y2F2ZWF0OiAgSSBoYXZlIG9ubHkgdW5zZWQgZ251cGxvdCB1bmRlciBsaW51eC91bml4LCBhbmQg
aGF2ZQo+IGxpdHRsZSBpZGVhIHdoYXQgd29ya3Mgb3IgZG9lc24ndCB3b3JrIHVuZGVyIFdpbmRv
d3MuCgpJbiB3aW5kb3dzIHRob3NlIGFjY2VudGVkIGNoYXJhY3RlcnMgZG9uJ3Qgd29yayAoZGlz
cGxheWVkIGRpZmZlcmVudGx5Cm9uIHRlcm1pbmFsIGFuZCBvbiB0aGUgcGxvdCB3aW5kb3cgLSB3
cm9uZyBpbiBib3RoIGNhc2VzIGFuZCB3aXRoCmFsbW9zdCBhbnkgZW5jb2RpbmcpLCBidXQgSSBo
YXZlIG5ldmVyIGJvdGhlcmVkIGFib3V0IHRoYXQgcHJvYmxlbSBhcwpsb25nIGFzIHRoZXkgd2Vy
ZSBPSyBpbiB0aGUgZmluYWwgZG9jdW1lbnQgKChMYSlUZVggb3IgQ29uVGVYdCBpbiBtb3N0CmNh
c2VzLCBldmVuIGVtZiB3b3JrZWQgT0sgLSBiZWZvcmUgdGhlIGxhdGVzdCBwYXRjaCkuCgpUaGFu
a3MgYWdhaW4sCiAgICBNb2pjYQo=

Re: how to use iso-latin-2 with PS terminal

[Allin C. <cot...@wf...>]

On Sat, 19 Jan 2008, Ethan A Merritt wrote:

> caveat:  I have only unsed gnuplot under linux/unix, and have
> little idea what works or doesn't work under Windows.

I can confirm that what you say also applies on Windows. The 
complication on Windows is that "native" text is probably in one 
of the Microsoft CP12XX encodings.  This shouldn't be a problem 
for the cairo/pango based terminals, which recode to UTF-8 
automatically, but might be an issue when producing PostScript.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: how to use iso-latin-2 with PS terminal

[Allin C. <cot...@wf...>]

On Sat, 19 Jan 2008, Ethan A Merritt wrote:

> On Saturday 19 January 2008 11:53, Allin Cottrell wrote:
> > On Sat, 19 Jan 2008, Mojca Miklavec wrote:
> > 
> > > can someone please help me with a minimal example how to use
> > > iso_8859_2 in the postscript terminal?
> > 
> > * Depending on the font you're using, you might possibly have to 
> > mess with the {no}adobeglyphnames option to the postscript terminal.
> 
> So far as I know, that setting affects only UTF-8.
> The glyph names for the ISO8859-* encodings are set in the prolog
> files, and cannot be changed from inside gnuplot.

OK, I stand corrected.

Allin Cottrell

context terminal

[GDutilleux <gui...@fr...>]

Hello, 

On Mac OS X 10.3.9 i tried to compile gnuplot 4.2.0 from source with the
ConTeXt terminal. To do so 
1 I added   in term/ the context.trm file provided by Mojka Miklavec. 
2 I added #include "context.trm" in src/term.h. 

On his recipe for building this custom gnuplot Mojka Miklavec mentions a
./prepare gnuplot utility to run first. I don't find it in the 4.2.0 source
release. 
After running ./configure script the context terminal is not mentioned in
the list of terminals taken into account. Any idea ?
Best regards,

G. Dutilleux
-- 
View this message in context: http://www.nabble.com/context-terminal-tp14975999p14975999.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: how to use iso-latin-2 with PS terminal

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

On Saturday 19 January 2008 11:53, Allin Cottrell wrote:
> On Sat, 19 Jan 2008, Mojca Miklavec wrote:
> 
> > can someone please help me with a minimal example how to use
> > iso_8859_2 in the postscript terminal?
> 
> * Depending on the font you're using, you might possibly have to 
> mess with the {no}adobeglyphnames option to the postscript terminal.

So far as I know, that setting affects only UTF-8.
The glyph names for the ISO8859-* encodings are set in the prolog
files, and cannot be changed from inside gnuplot.

-- 
Ethan A Merritt

Re: how to use iso-latin-2 with PS terminal

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

On Saturday 19 January 2008 02:15, Mojca Miklavec wrote:
> Hello,
>=20
> can someone please help me with a minimal example how to use
> iso_8859_2 in the postscript terminal?

Are you sure that the characters you are entering are encoded
in iso8859-2?   I ask because your Email (that this is a reply to)
arrived here encoded in utf-8, not iso8859-2.
=20
> For example, with some label "=C5=A0=C4=8De=C5=BEege=C4=8Dkam".
                                ^^^^^^^^^^^
These are UTF-8 characters as displayed here.

> What's worse: I figured out that if I try to typeset
>    set label "c=C4=8Ds=C5=A1z=C5=BE"
> in terminal (I usually load files when I need gnuplot), even that
> doesn't work.

This sounds like a problem with your terminal environment,
independent of anything that might be wrong in gnuplot.

I am guessing that you are typing in UTF8, and then when you tell gnuplot
or any other application that it is to be interpreted as iso8859-*
it becomes misinterpreted as some multi-character gibberish.

> It might make sense to fix such trivial issues first, before doing
> patches to extend gnuplot to support other encodings.

I agree. But I think those fixes lie outside of gnuplot.

=20
> (People here keep asking me how to use accented letters. I always
> answer them that there is almost no suitable gnuplot terminal - PS
> doesn't support accented letters

The postscript terminal has supported latin2 and other ISO encodings
for a very long time now.  UTF8 is very recent, however.

The svg and pdf terminals have always supported accented characters.

The new cairo-based terminals, both png and pdf, are natively
UTF8 with internal code to convert from other encodings.

SVG is also natively UTF8.

> bitmap terminals are out of question,=20

Why do you say that?  Do you mean that you don't want to use
bitmap terminals for other reasons?  The internationalization support
in the libgd terminals (png/gif/jpeg) comes directly from the
freetype2 library, which is probably the same library used by=20
the other programs on your system, and uses the same fonts as well.
So the support for accented characters through gnuplot's png/gif/jpeg
terminals should match what you see on the rest of the system.=20

caveat:  I have only unsed gnuplot under linux/unix, and have
little idea what works or doesn't work under Windows.

=2D-=20
Ethan A Merritt

Re: how to use iso-latin-2 with PS terminal

[Allin C. <cot...@wf...>]

On Sat, 19 Jan 2008, Mojca Miklavec wrote:

> can someone please help me with a minimal example how to use
> iso_8859_2 in the postscript terminal?

* Ensure the strings in your plot file really are encoded in
iso_8859_2.

* Put "set encoding iso_8859_2" into the file, before selecting
the postscript terminal.

* Make sure that gnuplot is able to find the PS prologue files it 
needs (and of course, that the font you're using supports the 
required characters).

* Depending on the font you're using, you might possibly have to 
mess with the {no}adobeglyphnames option to the postscript 
terminal.

This works for me.

> (People here keep asking me how to use accented letters. I always
> answer them that there is almost no suitable gnuplot terminal - PS
> doesn't support accented letters, bitmap terminals are out of
> question...

Not so.  The png term (either using libgd or the new cairo-based 
version) handles accented characters just fine.  So does the 
cairo-based PDF terminal.  All of these use UTF-8 internally, 
which is the only sane way to do it these days.

For the libgd version of the PNG driver you'll have to ensure your 
input is encoded in UTF-8; for the cairo-based terminals (PNG and 
PDF) you should be able to use your locale encoding (if it's not 
UTF-8) and the conversion will be done for you.  In the latter 
case it may be necessary to specify the locale encoding via "set 
encoding", but if your system is properly configured this 
shouldn't be required.

Allin Cottrell

how to use iso-latin-2 with PS terminal

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

SGVsbG8sCgpjYW4gc29tZW9uZSBwbGVhc2UgaGVscCBtZSB3aXRoIGEgbWluaW1hbCBleGFtcGxl
IGhvdyB0byB1c2UKaXNvXzg4NTlfMiBpbiB0aGUgcG9zdHNjcmlwdCB0ZXJtaW5hbD8KCkZvciBl
eGFtcGxlLCB3aXRoIHNvbWUgbGFiZWwgIsWgxI1lxb5lZ2XEjWthbSIuCk5laXRoZXIgbGF0aW4y
IG5vciB1dGYtOCBpbnB1dCB0ZXh0cyB3b3JrZWQgKGluIG9uZSBjYXNlIEkgZ290IGMKaW5zdGVh
ZCBvZiDEjSBhbmQgd2l0aCB1dGYtOCBpbnB1dCBJIGdvdCB0d28gY2hhcmFjdGVycyBlYWNoIHRp
bWUpLgoKV2hhdCdzIHdvcnNlOiBJIGZpZ3VyZWQgb3V0IHRoYXQgaWYgSSB0cnkgdG8gdHlwZXNl
dAogICBzZXQgbGFiZWwgImPEjXPFoXrFviIKaW4gdGVybWluYWwgKEkgdXN1YWxseSBsb2FkIGZp
bGVzIHdoZW4gSSBuZWVkIGdudXBsb3QpLCBldmVuIHRoYXQKZG9lc24ndCB3b3JrLiBJIG9ubHkg
c2VlICJjPz9zPz96Pz8iLCBidXQgdGhlc2UgbGV0dGVycyB3b3JrIGluIHNoZWxsLgpJdCBtaWdo
dCBtYWtlIHNlbnNlIHRvIGZpeCBzdWNoIHRyaXZpYWwgaXNzdWVzIGZpcnN0LCBiZWZvcmUgZG9p
bmcKcGF0Y2hlcyB0byBleHRlbmQgZ251cGxvdCB0byBzdXBwb3J0IG90aGVyIGVuY29kaW5ncy4K
CihQZW9wbGUgaGVyZSBrZWVwIGFza2luZyBtZSBob3cgdG8gdXNlIGFjY2VudGVkIGxldHRlcnMu
IEkgYWx3YXlzCmFuc3dlciB0aGVtIHRoYXQgdGhlcmUgaXMgYWxtb3N0IG5vIHN1aXRhYmxlIGdu
dXBsb3QgdGVybWluYWwgLSBQUwpkb2Vzbid0IHN1cHBvcnQgYWNjZW50ZWQgbGV0dGVycywgYml0
bWFwIHRlcm1pbmFscyBhcmUgb3V0IG9mCnF1ZXN0aW9uLCBsYXRleCBpcyB1c2VsZXNzLCBhbmQg
ZXBzbGF0ZXggY2Fubm90IGJlIHVzZWQgd2l0aCBwZGZsYXRleC4KRGlkIGFueW9uZSB0YWtlIGEg
bG9vayBhdCBodHRwOi8vcGV0ZXIuYWZmZW5iYW5kZS5vcmcvZ251cGxvdC8gPykKClRoYW5rcyBh
IGxvdCwKICAgTW9qY2EK

Re: fix for "pause -1" on Windows

[Allin C. <cot...@wf...>]

Sorry, but here's a slightly better version of the fix.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

fix for "pause -1" on Windows

[Allin C. <cot...@wf...>]

Tha attached patch fixes "pause -1" on MS Windows for current CVS.  
That is, loading a file containing this command no longer crashes 
wgnuplot.exe.  

It may not be the most elegant fix, but I'm reluctant to go deeper 
since the "pause" apparatus is rather complex, particularly on 
Windows.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Crop option for pngcairo [patch]

[Peter D. <pc...@wi...>]

See attached, and:

    http://sourceforge.net/tracker/index.php?func=detail&aid=1873297&group_id=2055&atid=302055

I needed a crop option for pngcairo à la gd.trm.

Re: Pseudodata for Vector Fields [Patch]

[Peter D. <pc...@wi...>]

Quoth Ethan Merritt on Sweetmorn, Chaos 16, 3174:
> It no longer handles the simpler case of a single stream of vectors.

Do you mean something like this, Ethan?

   plot [-8:8][-1:1] '+' using ($1):(sin($1)):(cos($1)):(sin($1)) \
   with vectors

It works so long as you specify a y-range.

Re: "pause -1" problem on win32?

[Allin C. <cot...@wf...>]

On Wed, 16 Jan 2008, Allin Cottrell wrote:

> With current CVS for win32, cross-built using mingw, I'm getting a 
> segfault when passing "pause -1" in a gnuplot input file...

Analysis after some searching:

When fed "pause -1" on win32, pause_command() in command.c will 
end up calling Pause(), in winmain.c, with a NULL argument. (This 
fact is new as of revision 1.161 of command.c, October 2007). The 
Pause() function reads as follows:

int
Pause(LPSTR str)
{
        pausewin.Message = str;
        return (PauseBox(&pausewin) == IDOK);
}

And then PauseBox() has the line:

width  = max(24,4+_fstrlen(lppw->Message)) * tm.tmAveCharWidth;

so _fstrlen will be called on a NULL argument.  I guess that's the 
crash right there.

This could be fixed at various different levels; I'm not sure 
where's the "right place".

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: wmenu.c

[<HBB...@t-...>]

Allin Cottrell wrote:
> win/wmenu.c: In function `SendMacro':
> win/wmenu.c:402: warning: passing arg 1 of `_getcwd' from 
> incompatible pointer type
> 
> The call in wmenu.c is
> 
>     char cwd[MAX_PATH];
>     <snip>
>     _getcwd(&cwd, sizeof(cwd));

> So it looks as if the call is indeed wrong -- the first arg should 
> be cwd, not &cwd? -- but I might be missing something.

The call is neither quite wrong, nor quite right.  &cwd and cwd 
eventually express the same address, so no harm done.  The pointer type 
will be converted automatically.  _getcwd(cwd, sizeof(cwd)) would be 
better, but not so much that it'd actually make a difference :-)

"pause -1" problem on win32?

[Allin C. <cot...@wf...>]

With current CVS for win32, cross-built using mingw, I'm getting a 
segfault when passing "pause -1" in a gnuplot input file.  E.g.

plot sin(x)
pause -1

When I load the above, wgnuplot.exe crashes.  Pause values >= 0 
are OK.  

It's possible there's something wrong with my build, but I've 
cross-built previous versions and haven't seen this.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

wmenu.c

[Allin C. <cot...@wf...>]

When cross-building wgnuplot.exe on Linux using mingw,
I get this warning:

win/wmenu.c: In function `SendMacro':
win/wmenu.c:402: warning: passing arg 1 of `_getcwd' from 
incompatible pointer type

The call in wmenu.c is

    char cwd[MAX_PATH];
    <snip>
    _getcwd(&cwd, sizeof(cwd));

And msdn
http://msdn2.microsoft.com/en-us/library/sf98bd4y(VS.80).aspx
gives as prototype for _getcwd:

char *_getcwd( 
   char *buffer,
   int maxlen 
);

So it looks as if the call is indeed wrong -- the first arg should 
be cwd, not &cwd? -- but I might be missing something.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: Pseudodata for Vector Fields [Patch]

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

On Tuesday 15 January 2008 22:34, Peter Danenberg wrote:
> Direction fields come in handy for first order ODEs; some people have
> expressed frustration that they're not directly supported.*
> 
> The attached patch produces two dimensions of data from the pseudofile
> operator when df_current_plot->plot_style == VECTOR

Please see also the comment attached to the patch tracker.

The functionality added by this patch is nice, but unless I am
missing something it comes at a cost.  Because it traps all cases
of "plot with vector", you can now *only* plot vector fields.
It no longer handles the simpler case of a single stream of vectors.

Can we somehow arrange to keep both capabilities?



> allowing you to do things like:**
> 
>     set isosamples 20
>     set samples 20
>     l = 0.05
>     f(t,y) = 2*y + 4 - t
>     g(c,x) = -7/4. + 1/2.*x + c*exp(2*x)
>     plot [0:2][-4:0] '+' using 1:2:(l):(l*f($1,$2)) \
>          with vectors title "dy/dt - 2y = 4 - t", \
>          g(0,x) title "g(c, t) = -7/4 + 1/2t + ce^2t, c = 0", \
>          g(.1,x), g(.2,x), g(.3,x), g(-.1,x), g(-.2,x), g(-.3,x)
> 
> Here's the sourceforge tracker:
> 
>     http://sourceforge.net/tracker/index.php?func=detail&aid=1872528&group_id=2055&atid=302055
> 
> -----------
> * http://thread.gmane.org/gmane.comp.graphics.gnuplot.devel/5805/focus=5814
> ** http://wikisophia.org/wiki/User:Danenberg#Direction_field
> 

-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742