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

Re: extending pstricks terminal driver

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

On Wed, Dec 10, 2008 at 9:27 AM, Juergen Wieferink wrote:
>> What parser probs did you encounter? I don't see any problems in parsing
>> strings or numbers, as it is already done. But maybe we are just talking
>> about different things. Anyway, it shouldn't be a problem to extend the
>> parser if necessary.
>
> Well, not exactly problems.  AFAIR the lua script has no access to
> the higher level parsing functions like try_to_get_string() and
> real_expression().  Thus you cannot use string variables or general
> expression evaluating to strings or numbers.

This could be implemented, but I doubt that it is really worth the
effort. You only need it to set monochrome/color, plot size, font
size, ... And one doesn't really need complex gnuplot expressions to
set the plot size. The defaults should already be OK.

> Additionally no spaces
> are allowed between the number and the dimension, i.e. "5in" is
> allowed, "5 in" is not.

That's not the problem. It could be changed, but the idea is that if
one provides no number, it is treated as centimeters, and then "in"
would be treated as the next option.

> As far as I am concerned "fulldoc" should be renamed into
> "standalone" to fit the corresponding option of the epslatex
> terminal.

I agree. The same is true for preamble that is called header in epslatex.

> These are of course minor issues.  Having an autoconfiscated version
> would really help in testing.

Right. Once the terminal is integrated, it would be easier for others to test.

Mojca

Re: extending pstricks terminal driver

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

On Wed, Dec 10, 2008 at 6:50 AM, Petr Mikulik wrote:
>> I wish there was a way to plot with bitmap terminal and use TeX labels
>> over it.
>
> That you can do. Use "set term png", unset border and tics, save the plot
> and then "plot with image" with additional labels.

One question: is "with image" already able to read png images? I had
an impression that it was only able to read some
unusual binary formats (3 bytes per pixel).

My idea was to unset labels and then draw the labels in metapost or
TikZ, but this means that I still need to put all the labels there
manually (for every plot the number must be adapted), but the really
useful thing would be to do what epslatex does: draw everything with
png terminal except for labels and then include the resulting png
image into TeX document.

(But I would need to learn a bit more about hacking terminals in order
to do that mix.)

Mojca

Re: extending pstricks terminal driver

[Juergen W. <wie...@fr...>]

> What parser probs did you encounter? I don't see any problems in parsing
> strings or numbers, as it is already done. But maybe we are just talking
> about different things. Anyway, it shouldn't be a problem to extend the
> parser if necessary.

Well, not exactly problems.  AFAIR the lua script has no access to
the higher level parsing functions like try_to_get_string() and
real_expression().  Thus you cannot use string variables or general
expression evaluating to strings or numbers.  Additionally no spaces
are allowed between the number and the dimension, i.e. "5in" is
allowed, "5 in" is not.

As far as I am concerned "fulldoc" should be renamed into
"standalone" to fit the corresponding option of the epslatex
terminal.

I agree with Mojca about the alias "tikz" for "lua".  Additionally
I'm not sure if "gnuplot.lua" is the right name for the TikZ
terminal...

These are of course minor issues.  Having an autoconfiscated version
would really help in testing.

Juergen

Re: extending pstricks terminal driver

[Juergen W. <wie...@fr...>]

> Gnuplot currently provides the following "TeX" terminals:
[...]
> where there is no single one that would satisfy my expectations.
> PS/PDF provides no TeX labels, pslatex doesn't work with pdftex,
> pstricks have serious problems working with pdftex apart from the fact
> that a lot of functionality is missing, latex looks ugly and doesn't
> even have color output, mp is lacking functionality, all others are
> old and not maintained. How should some newbie user know which
> terminal to use?
>
> Apart from that, colors and point shapes differ between terminals.

Have you tried epslatex recently?  Harald Harders has completely
reworked it.  It has the look and feel of the postscript terminal
with latex output for the textual parts.  By converting the eps file
into pdf you can even use pdflatex with it.

Juergen

Re: extending pstricks terminal driver

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

> I wish there was a way to plot with bitmap terminal and use TeX labels 
> over it.

That you can do. Use "set term png", unset border and tics, save the plot 
and then "plot with image" with additional labels.

---
PM

Re: extending pstricks terminal driver

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

On Mon, Dec 8, 2008 at 9:38 AM, Christoph Bersch wrote:
>
> Just to mention a possible drawbacks of pure TeX terminals:
> While working on the PSTricks terminal, I noticed that the pm3d support is
> very limited as the large number of polygons needed for the plot require a
> lot of TeX main memory. As TikZ is also TeX based, it could be that you run
> into similar problems also with this terminal.

That's right. Sooner or later it does. I was unable to draw 100x100
matrix with some other (context) terminal as well.

But it's also a problem to display too many polygons in any vector
terminal/format.

I currently need some scatter plots with possibly 1 million points and
using pdf terminal wouldn't really help since my acrobat and/or
printer would crash, so I need to use png terminal. I wish there was a
way to plot with bitmap terminal and use TeX labels over it. One could
then use 1000x1000 grid for 3D plots without a problem.

>> My (context) terminal enables changing line style or colors on the fly
>> (after running gnuplot) - the feature  that Christoph mentioned as one
>> thing that could be done with PSTricks. But it is not usable in LaTeX,
>> just as PSTricks is not usable with pdfTeX, so this makes it usable
>> for a much smaller audience.
>
> PSTricks can be used with pdflatex in dvi output mode

I know, but I use pdftex in pdf output mode exclusively.

> And again: it shouldn't be a developer decision which terminal the users
> 'want' to use.

Definitely not. But it helps to get a hint. I probably needed a year
to discover other terminals besides "latex", and I was fighting with
getting some outdated TeX-like terminals to work properly when they
were actually using tricks that don't work in TeX packages any more or
were using packages that are no longer part of TeX distributions.)

> PS: I forwarded the mail to the gnuplot mailing list

Thanks.

Juergen Wieferink wrote:

> TikZ is not really a pure TeX based solution.

But it works with basically any existing engine and format. TikZ is fantastic.

> As I understand
> things it works mostly like PSTricks but with more than one back
> end, i.e. PS as well as PDF.

And also important: LaTeX as well as plain TeX and ConTeXt.

>  Nevertheless I ran into exceeding
> memory when there were three images in TeX memory at the same time.

I need to do some tests. When I was implementing the first draft of
context terminal, it was only able to handle 10 graphs at most and it
needed 10 minutes to process them. After some optimisation in ConTeXt
core it was possible to do much more with 20 or 50-fold speedup.

There are definitely limitations, but a pure TeX terminal has been
serving me for two years without any major issues apart from the
obvious memory limitation.

Mojca

Re: extending pstricks terminal driver

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

On Mon, Dec 8, 2008 at 6:47 PM, Ethan Merritt wrote:
> On Monday 08 December 2008 01:25:58 Juergen Wieferink wrote:
>> > > Fixing PSTricks terminal still makes sense if there are minor patches.
>> > > For the rest, I would claim that TikZ should become *the* (La)TeX
>> > > terminal of the future.
>> >
>> > As far as im in it, one of the ideas behind gnuplot is to be as portable
>> > as possible and to support a great variety of different output formats.
>> > So there will hardly ever be a discussion of favoring one format over
>> > another from the developer side. This choice is up to the user!

I only meant that since resources are limited it's better to have one
really good terminal than having ten "broken"/nonfunctional ones.
So it makes senso to put some considerable amount of time into
creating one good terminal.

Having a 'preferred' terminal should by no means prevent developers
from applying patches to other terminals and it should not prevent
users from using them.


Gnuplot currently provides the following "TeX" terminals:
            eepic  EEPIC -- extended LaTeX picture environment
            emtex  LaTeX picture environment with emTeX specials
         epslatex  LaTeX picture environment using graphicx package
            latex  LaTeX picture environment
               mf  Metafont plotting standard
               mp  MetaPost plotting standard
          pslatex  LaTeX picture environment with PostScript \specials
            pstex  plain TeX with PostScript \specials
         pstricks  LaTeX picture environment with PSTricks macros
          texdraw  LaTeX texdraw environment
             tpic  TPIC -- LaTeX picture environment with tpic \specials
plus (also TeX-friendly)
              pdf  PDF (Portable Document File) file driver
       postscript  PostScript graphics, including EPSF embedded files (*.eps)

where there is no single one that would satisfy my expectations.
PS/PDF provides no TeX labels, pslatex doesn't work with pdftex,
pstricks have serious problems working with pdftex apart from the fact
that a lot of functionality is missing, latex looks ugly and doesn't
even have color output, mp is lacking functionality, all others are
old and not maintained. How should some newbie user know which
terminal to use?

Apart from that, colors and point shapes differ between terminals.

>> I think so, too.  But nevertheless the TikZ terminal seems quite
>> promising.
>>
>> > I think you should ask Peter why he did not contact the gnuplot
>> > developer for including his terminal. Maybe its an issue with the
>> > license?! (lua terminal is under GPL license)
>>
>> Peter has kindly uploaded his terminal to the patches tracker recently:
>>
>> http://sourceforge.net/tracker/index.php?func=detail&aid=2183264&group_id=2055&atid=302055
>>
>> He writes that he has no objections in changing the license.
>
> I am afraid that I have no time to check out lua + TikZ myself,
> but I am  certainly open to adding this new driver to CVS if multiple
> people agree that it is a useful addition, and if Peter confirms that
> we can include it under the gnuplot license.
>
> Do you think it is ready for inclusion in CVS?

As far as I know it's fully functional. There's only one thing that
I'm not sure about:
    set term lua
It uses lua, but outputs tikz code. I would prefer to call the
terminal tikz or maybe set a synonym
    set term lua tikz options = set term tikz options

If terminal is called lua, nobody will figure out that it's used for
generating TeX code. On the other hand, one can plug in any code to
generate any other kind of ouput from the lua interface, so the name
"lua" for terminal does make sense.

But that's up to gnuplot developers.

I wanted to suggest some modifications to enable compatibility with
ConTeXt (terminal only works with LaTeX at the moment), but this
should not prevent the code from being added to CVS. Functionality is
not frozen right after being added to CVS, and as long as you accept
patches from the author himself, it should be fine.

> Does the ./configure script need to be modified for it (that is,
> should it try to autodetect lya and/or TikZ)?

TikZ: definitely not. Firstly: it's literally impossible to figure out
whether it is installed or not. Secondly: gnuplot should not care.
Providing the right package in TeX is the responsibility of user.

Lua: yes. One could also *include* it into gnuplot itself. The whole
source is only 0.5MB. See also:

     http://peter.affenbande.org/gnuplot/gnuplot_lua_terminal/INSTALL

Mojca

Re: [RFC] Proposal to re-think binary file handling

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

On Wednesday 03 December 2008 09:28:18 Ralf Juengling wrote:
> > Having looked at the code, I think currently it would be easier to
> > store a single string for later interpretation than it would be to
> > store a variable number of separate dimensions.  But I'm proposing
> > to throw out the current code anyhow, so that argument doesn't have
> > much weight.
> 
> I have a slight preference for not making it a string. On a second
> thought a comma might not be such a good choice for separator, though. 
> The comma is also used to separate different lines in a single plot
> command, so there is potential for ambiguity.
> 
> I vote for ':' instead, like
> 
> array=4:23:100
> 
> but not
> 
> array=[4:23:100]
> 
> as you initially suggested.
> 
> Ralf
> 

Please have a look at the patch now attached to Bug #2378535
 https://sourceforge.net/tracker/index.php?func=detail&aid=2378535&group_id=2055&atid=102055

The best I have come up with is to replace 
   array=5x10
with
   array=(5,10)

That cleans up the parsing, and also allows you to use variables and expressions: 
   array=(A, 2+NVAR)

A bare comma with no parentheses would not work, because it makes the following
plot command ambiguous:

   plot foo binary array=5,baz    # Is baz a second dimension or a second graph?

Colon is already in use to separate fields within a record, and may exist in the
same specification as an array:

   record=(5,10):2:4


	thanks for your feedback,

		Ethan


-- 
Ethan A Merritt

Re: [RFC] Proposal to re-think binary file handling

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

>    set binary datafile array=Infx5 format="%double%double"
> 
> Someone please remind me why we need oddball format specs like
> 	format="%double%double"
> rather than 
> 	format="%lf%lf"
> I'm sure I must have asked this before, when the code went into CVS,
> but I have forgotten the answer.  Can we get rid of additional hundreds
> of lines of obscure code simply by requiring that users provide
> a valid C format statement for reading their own binary data files?

Implementation of general binary files comes from 2003. We exchanged a lot 
of e-mails with Daniel Sebald. Nobody came with such a proposal as you have 
now.

The main reason for format="%double%double" and not "%lf%lf" is that textual 
headers of image or volume files have keywords like char, byte, double, int, 
float, etc. That's why we had used the same keywords for "format" as well.

On the other hand, your proposal "%lf%lf" reflects the formating from 
programmer's point of view. However, in C, there is no special formatting 
for signed and unsigned char, so we are out of luck for this notation.

---
PM

Re: extending pstricks terminal driver

[Juergen W. <wie...@fr...>]

Ethan Merritt wrote:
> I am afraid that I have no time to check out lua + TikZ myself,
> but I am  certainly open to adding this new driver to CVS if
> multiple people agree that it is a useful addition, and if Peter
> confirms that we can include it under the gnuplot license.

The terminal certainly is a very useful addition.  

> Do you think it is ready for inclusion in CVS?

I think in almost all respects it is.  The ./configure script has to
be updated (see below) and there are some minor edges in the user
interface; it does not "feel" very gnuplot'ish.  For example, AFAICR
the "set term" command line cannot make use of string expressions or
even real valued expressions.  To some degree this probably cannot
be avoided because the parsing is done within the lua script.  But
some edges actually could be smoothed.

That said, as long as it is marked EXPERIMENTAL and you are free to
drop backwards compatibility, I think it is quite mature.

> Does the ./configure script need to be modified for it (that is,
> should it try to autodetect lya and/or TikZ)?

Yes.  But it should check for the lua library and build the terminal
conditionally.  I don't think it has to check for TikZ, as it is
only needed for using the gnuplot output.  Additionally the
gnuplot.lua script has to be installed.  As things are it is
expected to reside along in the same directory as gnuplot_x11.

I'd like to do more review on this but it seems I won't find much
time within the next few months.

Juergen

Re: extending pstricks terminal driver

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

On Monday 08 December 2008 01:25:58 Juergen Wieferink wrote:
> > > Fixing PSTricks terminal still makes sense if there are minor patches.
> > > For the rest, I would claim that TikZ should become *the* (La)TeX
> > > terminal of the future.
> >
> > As far as im in it, one of the ideas behind gnuplot is to be as portable
> > as possible and to support a great variety of different output formats.
> > So there will hardly ever be a discussion of favoring one format over
> > another from the developer side. This choice is up to the user!
> 
> I think so, too.  But nevertheless the TikZ terminal seems quite
> promising.
> 
> > I think you should ask Peter why he did not contact the gnuplot
> > developer for including his terminal. Maybe its an issue with the
> > license?! (lua terminal is under GPL license)
> 
> Peter has kindly uploaded his terminal to the patches tracker recently:
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=2183264&group_id=2055&atid=302055
> 
> He writes that he has no objections in changing the license.

I am afraid that I have no time to check out lua + TikZ myself,
but I am  certainly open to adding this new driver to CVS if multiple
people agree that it is a useful addition, and if Peter confirms that
we can include it under the gnuplot license.

Do you think it is ready for inclusion in CVS?

Does the ./configure script need to be modified for it (that is, 
should it try to autodetect lya and/or TikZ)?


 
> > Just to mention a possible drawbacks of pure TeX terminals:
> > While working on the PSTricks terminal, I noticed that the pm3d support
> > is very limited as the large number of polygons needed for the plot
> > require a lot of TeX main memory. As TikZ is also TeX based, it could be
> > that you run into similar problems also with this terminal.
> 
> TikZ is not really a pure TeX based solution.  As I understand
> things it works mostly like PSTricks but with more than one back
> end, i.e. PS as well as PDF.  Nevertheless I ran into exceeding
> memory when there were three images in TeX memory at the same time.
> 
> 
> Juergen
> 
> 
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 



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

Re: extending pstricks terminal driver

[Juergen W. <wie...@fr...>]

> > Fixing PSTricks terminal still makes sense if there are minor patches.
> > For the rest, I would claim that TikZ should become *the* (La)TeX
> > terminal of the future.
>
> As far as im in it, one of the ideas behind gnuplot is to be as portable
> as possible and to support a great variety of different output formats.
> So there will hardly ever be a discussion of favoring one format over
> another from the developer side. This choice is up to the user!

I think so, too.  But nevertheless the TikZ terminal seems quite
promising.

> I think you should ask Peter why he did not contact the gnuplot
> developer for including his terminal. Maybe its an issue with the
> license?! (lua terminal is under GPL license)

Peter has kindly uploaded his terminal to the patches tracker recently:

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

He writes that he has no objections in changing the license.


> Just to mention a possible drawbacks of pure TeX terminals:
> While working on the PSTricks terminal, I noticed that the pm3d support
> is very limited as the large number of polygons needed for the plot
> require a lot of TeX main memory. As TikZ is also TeX based, it could be
> that you run into similar problems also with this terminal.

TikZ is not really a pure TeX based solution.  As I understand
things it works mostly like PSTricks but with more than one back
end, i.e. PS as well as PDF.  Nevertheless I ran into exceeding
memory when there were three images in TeX memory at the same time.


Juergen

Re: extending pstricks terminal driver

[Christoph B. <us...@be...>]

Hi,

I haven't worked much with TikZ and I can speak only for myself as a 
gnuplot user:

Mojca Miklavec wrote:
> 
> Concerning the question about pstricks terminal: in my opinion it
> would make much more sense to work on TikZ terminal than on PSTricks.

I work on the PSTricks terminal because I do a lot with PSTricks. For 
myself I usually use the eps or epslatex terminal for most of my gnuplot 
diagrams. I just want the PSTricks terminal to be more complete and 
usable for the people who want to use it :-)

> Fixing PSTricks terminal still makes sense if there are minor patches.
> For the rest, I would claim that TikZ should become *the* (La)TeX
> terminal of the future.

As far as im in it, one of the ideas behind gnuplot is to be as portable 
as possible and to support a great variety of different output formats. 
So there will hardly ever be a discussion of favoring one format over 
another from the developer side. This choice is up to the user!

For use with LaTeX you have a lot of different formats to choose from.

Just to mention a possible drawbacks of pure TeX terminals:
While working on the PSTricks terminal, I noticed that the pm3d support 
is very limited as the large number of polygons needed for the plot 
require a lot of TeX main memory. As TikZ is also TeX based, it could be 
that you run into similar problems also with this terminal.

> Somebody already started the effort:
>      http://peter.affenbande.org/gnuplot/
> 
> My (context) terminal enables changing line style or colors on the fly
> (after running gnuplot) - the feature  that Christoph mentioned as one
> thing that could be done with PSTricks. But it is not usable in LaTeX,
> just as PSTricks is not usable with pdfTeX, so this makes it usable
> for a much smaller audience.

PSTricks can be used with pdflatex in dvi output mode (this is the 
default for 'latex' on most newer systems). Or, with the package 
'pst-pdf', directly with pdflatex ;-)
And again: it shouldn't be a developer decision which terminal the users 
'want' to use.

> However, one should *really* take a look at what Peter did on the link
> above. I did not test the terminal too much. I want to send him some
> patches, but really ... one should take a look and consider including
> it.

I think you should ask Peter why he did not contact the gnuplot 
developer for including his terminal. Maybe its an issue with the 
license?! (lua terminal is under GPL license)

Christoph

PS: I forwarded the mail to the gnuplot mailing list

New programmatic interface: plt-scheme

[Dimitris V. <vy...@me...>]

Hi,

I have posted a programmatic interface for plt-scheme in the planet 
package repository.

The package is available here:
http://planet.plt-scheme.org/display.ss?package=gnuplot.plt&owner=vyzo

-- vyzo

Re: [RFC] Proposal to re-think binary file handling

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

On Tuesday 02 December 2008 15:17:14 Ralf Juengling wrote:
> 
> On Tue, 2 Dec 2008, Ethan Merritt wrote:
> 
> >   set binary datafile array=Infx5 format="%double%double"
> >
> > As best as I can understand it, this is supposed to describe a rectangular
> > array of data whose extent in x is however many records there are in the
> > data file  (keyword "Inf") and whose extent in y is 5.
> >
> > Needless to say, there is no way that gnuplot's normal tokenising and
> > parsing routines (in scanner.c) can figure out that the string of
> > characters "Infx5" is supposed to represent three entities:
> >  "Inf"	- not the number "infinity" but a magic keyword
> >  "x"	- a magic-character field separator
> 
> Yes, but so is ":".

Sorry, I was not clear enough.
When gnuplot reads an input line, it separates the character stream into
a list of "tokens",  each of which is one or more characters that function
as a  single unit in the syntax.  Tokens must be separated by whitespace or
by a limited set of special characters.  "x" is not one of those special 
characters, because it is needed as a normal alphabetic character.
Placing quotes around any character sequence turns it into a single
token, a string constant.

The character sequence   10,12 is 3 tokens:    "10" "," and "12"
The character sequence   a1=22 is 3 tokens:    "a1"  "=" and "22"
The character sequence   5x5   is two tokens   "5"  and "x5"  
The character sequence   5xInf is two tokens   "5" and "xInf"
The character sequence   Infx5 is a single token  "Infx5"

Infx5 would be a legal variable name, or a possible keyword, but there
are only 2 ways to break it down into more than one unit of information.
One way is to bypass the existing gnuplot scanning/parsing mechanism and
write special-purpose code.  Worse yet, after treating this one sequence
of characters as a special case, you have to dummy up a modified list of
tokens that hides the characters you just processed separately.
That is what the current code does.

A second way is to put the whole thing in quotes, so that it is treated
as a single token.  In that case you still have to parse it specially,
but it does not require breaking and then repairing the existing token
scanning process.



> 
> >  "5"	- an actual integer
> >
> > If this specification instead used some rational syntax, perhaps
> >   array="[-1:5]"
> 
> I think this syntax is not a good idea as "[a:b]" means something
> completely different in other places. And with more dimensions you
> could not reuse existing parsing code anyway, could you?

That may or may not be the case, but it becomes irrelevant if we make
the required parameter be a string.  If it's a string, then it will be
handled as a single token.  


> > or the even more minimal
> >   array="-1 5"
>
> That's better (but I don't see how this is easier to parse than
> "x" as a separator). Why not a separator token other than space,
> a comma, for instance? With a comma one could write ",5" instead
> of "-1,5" to indicate that the number of records is unknown.

I don't really care much what is in the string, so long as it is
easy to interpret, ideally via a single sscanf().  

And it doesn't really have to be a string either, so long as the choice
of separators and syntax results in something that can be parsed unambiguously.
We already do that for "offset". Consider:
    set label "foo" offset 1
    set label "foo" offset 1,2
    set label "foo" offset 1,2,3

Having looked at the code, I think currently it would be easier to
store a single string for later interpretation than it would be to
store a variable number of separate dimensions.  But I'm proposing
to throw out the current code anyhow, so that argument doesn't have
much weight.



> As for breaking compatibility, I am in favor if it means it fixes
> problems. Binary data is a pretty recent feature, better make the
> change now than never.
> 
> Ralf
> 
> 
> 
> 
> 
> >
> > then we would gain at least the following:
> >
> > 1) It could be parsed by a single sscanf call
> > 	sscanf(string, "[%d:%d]", &xdim, &ydim]")
> > 2) The normal input line tokenise+parse routines could handle it
> > 3) The use of a string would allow substitution of alternative formats:
> > 	A = "[5:4]"; B = "[4:5]"
> > 	set binary datafile array=( typeA ? A : B )
> > 4) We could throw away hundreds of lines of unreadable code in
> >   plot_option_array() and associated routines
> > 5) Future maintenance would be vastly easier
> >
> >
> > What is the downside?
> > ---------------------
> >
> > It will break all current scripts, including the image-handling demos,
> > that use the keywords "array" or "record".
> > Then again, as Shige has been pointing out, many things are broken in
> > the current version already.
> >
> >
> > Should we go even further?
> > --------------------------
> >
> > Someone please remind me why we need oddball format specs like
> > 	format="%double%double"
> > rather than
> > 	format="%lf%lf"
> > I'm sure I must have asked this before, when the code went into CVS,
> > but I have forgotten the answer.  Can we get rid of additional hundreds
> > of lines of obscure code simply by requiring that users provide
> > a valid C format statement for reading their own binary data files?
> >
> > 	Ethan (sf...@us...)
> >
> > --
> > Ethan A Merritt
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK & win great prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> >
> 



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

Re: [RFC] Proposal to re-think binary file handling

[Ralf J. <jue...@cs...>]

On Tue, 2 Dec 2008, Ethan Merritt wrote:

>   set binary datafile array=Infx5 format="%double%double"
>
> As best as I can understand it, this is supposed to describe a rectangular
> array of data whose extent in x is however many records there are in the
> data file  (keyword "Inf") and whose extent in y is 5.
>
> Needless to say, there is no way that gnuplot's normal tokenising and
> parsing routines (in scanner.c) can figure out that the string of
> characters "Infx5" is supposed to represent three entities:
>  "Inf"	- not the number "infinity" but a magic keyword
>  "x"	- a magic-character field separator

Yes, but so is ":".

>  "5"	- an actual integer
>
> If this specification instead used some rational syntax, perhaps
>   array="[-1:5]"

I think this syntax is not a good idea as "[a:b]" means something
completely different in other places. And with more dimensions you
could not reuse existing parsing code anyway, could you?


> or the even more minimal
>   array="-1 5"

That's better (but I don't see how this is easier to parse than
"x" as a separator). Why not a separator token other than space,
a comma, for instance? With a comma one could write ",5" instead
of "-1,5" to indicate that the number of records is unknown.

As for breaking compatibility, I am in favor if it means it fixes
problems. Binary data is a pretty recent feature, better make the
change now than never.

Ralf





>
> then we would gain at least the following:
>
> 1) It could be parsed by a single sscanf call
> 	sscanf(string, "[%d:%d]", &xdim, &ydim]")
> 2) The normal input line tokenise+parse routines could handle it
> 3) The use of a string would allow substitution of alternative formats:
> 	A = "[5:4]"; B = "[4:5]"
> 	set binary datafile array=( typeA ? A : B )
> 4) We could throw away hundreds of lines of unreadable code in
>   plot_option_array() and associated routines
> 5) Future maintenance would be vastly easier
>
>
> What is the downside?
> ---------------------
>
> It will break all current scripts, including the image-handling demos,
> that use the keywords "array" or "record".
> Then again, as Shige has been pointing out, many things are broken in
> the current version already.
>
>
> Should we go even further?
> --------------------------
>
> Someone please remind me why we need oddball format specs like
> 	format="%double%double"
> rather than
> 	format="%lf%lf"
> I'm sure I must have asked this before, when the code went into CVS,
> but I have forgotten the answer.  Can we get rid of additional hundreds
> of lines of obscure code simply by requiring that users provide
> a valid C format statement for reading their own binary data files?
>
> 	Ethan (sf...@us...)
>
> --
> Ethan A Merritt
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

[RFC] Proposal to re-think binary file handling

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

This is a serious proposal to throw out and re-implement the
current binary file handling code.

Yes, this will break backwards compatibility.  I suppose this means
that current CVS will eventually become version 5.0 rather than 4.4.

Why do it?
----------

The code in datafile.c that handles binary files is horrible.
So horrible that I think it is unmaintainable as currently written.
Some of the documented behavior was never implemented, and some of
the implemented code does not work. I have managed to fix a couple of
simple errors, but the  amount of time I had to spend slogging
through obscure code was ridiculous.  The gnuplot project does not
have enough developer time available to maintain this code in its
current state.

For specific examples of problems, please see Shige Takeno's recent
series of error reports.  

For an example of the poor design and consequent ugly code that
tries to support it, consider the following command:

   set binary datafile array=Infx5 format="%double%double"

As best as I can understand it, this is supposed to describe a rectangular 
array of data whose extent in x is however many records there are in the
data file  (keyword "Inf") and whose extent in y is 5.

Needless to say, there is no way that gnuplot's normal tokenising and
parsing routines (in scanner.c) can figure out that the string of
characters "Infx5" is supposed to represent three entities:
  "Inf"	- not the number "infinity" but a magic keyword
  "x"	- a magic-character field separator
  "5"	- an actual integer       

If this specification instead used some rational syntax, perhaps
   array="[-1:5]"
or the even more minimal
   array="-1 5"

then we would gain at least the following:

1) It could be parsed by a single sscanf call
	sscanf(string, "[%d:%d]", &xdim, &ydim]")
2) The normal input line tokenise+parse routines could handle it
3) The use of a string would allow substitution of alternative formats:
	A = "[5:4]"; B = "[4:5]"
	set binary datafile array=( typeA ? A : B )
4) We could throw away hundreds of lines of unreadable code in 
   plot_option_array() and associated routines
5) Future maintenance would be vastly easier


What is the downside?
---------------------

It will break all current scripts, including the image-handling demos,
that use the keywords "array" or "record".
Then again, as Shige has been pointing out, many things are broken in
the current version already.


Should we go even further?
--------------------------

Someone please remind me why we need oddball format specs like
	format="%double%double"
rather than 
	format="%lf%lf"
I'm sure I must have asked this before, when the code went into CVS,
but I have forgotten the answer.  Can we get rid of additional hundreds
of lines of obscure code simply by requiring that users provide
a valid C format statement for reading their own binary data files?

	Ethan (sf...@us...)

-- 
Ethan A Merritt

Re: gd.trm issue for mingw-gcc-4.3.0 building

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

Hello 

--- Pierre Joye <pie...@gm...> wrote:
> 
> Without having tested it recently under mingw, I would suggest to
> first use a more recent version (.35 or .36-cvs).
> 
> Cheers,
> -- 
> Pierre

I will try and report you and gnuplot-beta/ML.
However, I have caught a cold so that the trial will be delayed.

Thank for Ethan and Pierre for kind treatments of the matter.

BTW

//#if !defined(GD_NEED_LOCAL_FONT_POINTERS) 
BGD_EXPORT_DATA_PROT gdFontPtr gdFontSmall;	/* 6x12 */
BGD_EXPORT_DATA_PROT gdFontPtr gdFontLarge;	/* 8x16 */
BGD_EXPORT_DATA_PROT gdFontPtr gdFontMediumBold;	/* 7x13 */
BGD_EXPORT_DATA_PROT gdFontPtr gdFontGiant;  /* 9x15 */
BGD_EXPORT_DATA_PROT gdFontPtr gdFontTiny;  /* 5x8 */
//#else
//static gdFontPtr gdFontSmall;	/* 6x12 */
//static gdFontPtr gdFontLarge;	/* 8x16 */
//static gdFontPtr gdFontMediumBold;	/* 7x13 */
//static gdFontPtr gdFontGiant;  /* 9x15 */
//static gdFontPtr gdFontTiny;  /* 5x8 */
//#endif

Quick and dirty modification the above seemed to work well yesterday for gcc-4.3.0 (mingw) building.

**********************************************
gnuplot> set term png small
Terminal type set to 'png'
Options are 'nocrop font arial 10 size 640,480 '
gnuplot> set term png medium
Terminal type set to 'png'
Options are 'nocrop font arial 12 size 640,480 '
gnuplot> set term png large
Terminal type set to 'png'
Options are 'nocrop font arial 14 size 640,480 '
***********************************************
The above are the same as those by wgnuplot.exe build by Petr (gp43-Nov21_2008-winbin.zip)

However, the above modification of course is permitted only for personal purpose.

Anyway first I have to do is to get rid of the cold. :-)

Regards

Tatsuro 

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: problems for binary general

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

On Saturday 29 November 2008 22:05:35 Shigeharu TAKENO wrote:
> shige 11/30 2008
> ----------------
> 
> Ethan A Merritt wrote:
> | > 3) The following setting make core dump on our environment:
> | > 
> | >   set datafile binary format='%*2double%double' 
> | 
> | The feature "set datafile binary format=..." was never implemented,
> | despite what it says in the documentation.  For now I have
> | added an error message in the CVS version that prevents you from
> | issuing such a command, and therefore prevents the segfault.
> 
> Thanks. I understand.
> 
> | However, please try the attached patch and tell me if it works for you.
> | This patch is against current CVS (27 November 2008).
> 
> It seems to work as expected. But, I think there have been some 
> problems yet.
> 
> 1) We can some options on 'set datafile binary', but we must 
> remain to the splot command line:
> 
>   set datafile binary format='%double'
>   splot 'data1' binary record=5x5 using 1:2:3 w lp
> 
> is OK, but 
> 
>   set datafile binary format='%double' record=5x5
>   splot 'data1' binary using 1:2:3 w lp
> 
> is not.

That problem is easy to fix.
Revised patch is attached.

> 2) Since I have not understand 'array' yet, I think it needs to 
> modify the document for 'binary array' and 'binary record' to 
> explain data format required by 'array' and 'record' precisely, 
> like as 'binary matrix'.

I cannot write documentation for it, because I do not understand it.
You probably understand it better than I do.

I think the binary file code is a horrible mess, and should
be ripped out, re-designed, and re-written from the beginning.
But I don't have time to do that myself, and I don't see anyone else
volunteering.  Small fixes may be the best we can do. 


> 3) The document for 'binary array' says:
> 
>   A special "number", `Inf`, can be used to indicate that data 
>   should be read until the end of file.
> 
> But, I obtain unexpected results:
> 
>   gnuplot> set datafile binary record=5xInf
>   gnuplot> show datafile binary
>      ....
>           Record 0:
>             Dimension: 5
>             Generate coordinates: no
>      ....
>   gnuplot> set datafile binary record=Infx5
>   gnuplot> show datafile binary
>      ....
>            Record 0:
>             Dimension: 0x5
>             Generate coordinates: no
>      ....

Is that a bug in the code?
        in the documentation?
        only a problem in the output of "show"?
Does the program correctly read through to the end of the file?

Perhaps the documentation is simply wrong and the feature was
never implemented, the same as it was for  "set datafile binary format=..."  

I think that syntax is anyway not supportable.
Some machines will parse Inf as a number, but other machines will not.
If it must be read as a number, better to make it "-1".
If it is supposed to be a keyword, better make it something other than
a legal number such as "Inf".
In any case it would be better if the format were a string:

     set datafile binary record="5x5"

That change by itself might get rid of 100 lines of unreadable code in
plot_option_array(), and has the added benefit that you could store it
in a variable:

   format_A = "5x5"
   format_B = "5x10"
   set datafile binary record= (some_test ? format_A : format_B)

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

Re: gd.trm issue for mingw-gcc-4.3.0 building

[Pierre J. <pie...@gm...>]

On Mon, Dec 1, 2008 at 11:47 AM, Tatsuro MATSUOKA
<tma...@ya...> wrote:
> Hello
>
> #if defined(WIN32) && !defined(NONDLL)
>  /* static font pointers are recommended when using bgd.dll */
> # ifndef GD_NEED_LOCAL_FONT_POINTERS
> #  define GD_NEED_LOCAL_FONT_POINTERS
> # endif
> #endif
>
>
>  /* static font pointers are recommended when using bgd.dll */
>
> In the Gd 2.0.33 in the GnuWin32, libgd2.dll is used not but bgd.dll.
> Why static font pointers are recommended for bgd.dll ?

Without having tested it recently under mingw, I would suggest to
first use a more recent version (.35 or .36-cvs).

Cheers,
-- 
Pierre

http://blog.thepimp.net | http://www.libgd.org

Re: gd.trm issue for mingw-gcc-4.3.0 building

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

Tatsuro:

I am forwarding your question to the libgd development list.
Perhaps someone there will advise us whether there are known
problems with difference mingw versions.

	Ethan

On Monday 01 December 2008 02:47:05 Tatsuro MATSUOKA wrote:
> Hello
> 
> #if defined(WIN32) && !defined(NONDLL)
>   /* static font pointers are recommended when using bgd.dll */
> # ifndef GD_NEED_LOCAL_FONT_POINTERS
> #  define GD_NEED_LOCAL_FONT_POINTERS
> # endif
> #endif
> 
> 
>   /* static font pointers are recommended when using bgd.dll */
> 
> In the Gd 2.0.33 in the GnuWin32, libgd2.dll is used not but bgd.dll.
> Why static font pointers are recommended for bgd.dll ?
> 
> Regards
> 
> Tatsuro
> 
> 
> --- Tatsuro MATSUOKA <tma...@ya...> wrote:
> 
> > Hello
> > 
> > Sorry for my carelessness for what Ethan wrote:
> > 
> > ===Ethan===
> > Please look to see if it can be fixed by modifying these lines instead:
> > 
> > #if defined(WIN32) && !defined(NONDLL)
> >   /* static font pointers are recommended when using bgd.dll */
> > # ifndef GD_NEED_LOCAL_FONT_POINTERS
> > #  define GD_NEED_LOCAL_FONT_POINTERS
> > # endif
> > #endif 
> > ================
> > 
> > > However Ethan suggest that DO NOT TREAT HERE.
> > 
> > was not what Ethan would like to say.
> > 
> > So my conclusion is that I cannot overcome this issue to modify the above.
> > 
> > It is likely to modify the below 
> > 
> > #ifndef GD_NEED_LOCAL_FONT_POINTERS
> > BGD_EXPORT_DATA_PROT gdFontPtr gdFontSmall;	/* 6x12 */
> > BGD_EXPORT_DATA_PROT gdFontPtr gdFontLarge;	/* 8x16 */
> > BGD_EXPORT_DATA_PROT gdFontPtr gdFontMediumBold;	/* 7x13 */
> > BGD_EXPORT_DATA_PROT gdFontPtr gdFontGiant;  /* 9x15 */
> > BGD_EXPORT_DATA_PROT gdFontPtr gdFontTiny;  /* 5x8 */
> > #else
> > static gdFontPtr gdFontSmall;	/* 6x12 */
> > static gdFontPtr gdFontLarge;	/* 8x16 */
> > static gdFontPtr gdFontMediumBold;	/* 7x13 */
> > static gdFontPtr gdFontGiant;  /* 9x15 */
> > static gdFontPtr gdFontTiny;  /* 5x8 */
> > #endif
> > 
> > 
> > Regards
> > 
> > Tatsuro
> >  
> > 
> > --- Tatsuro MATSUOKA <tma...@ya...> wrote:
> > 
> > > Hello
> > > 
> > > I'm now confusing.
> > > 
> > > To include
> > > # include "gdfonts.h"
> > > # include "gdfontl.h"
> > > # include "gdfontmb.h"
> > > # include "gdfontt.h"
> > > # include "gdfontg.h"
> > > 
> > > GD_NEED_LOCAL_FONT_POINTERS should be defined,
> > > 
> > > However
> > > GD_NEED_LOCAL_FONT_POINTERS is defined
> > > 
> > > static gdFontPtr gdFontSmall;	/* 6x12 */
> > > static gdFontPtr gdFontLarge;	/* 8x16 */
> > > static gdFontPtr gdFontMediumBold;	/* 7x13 */
> > > static gdFontPtr gdFontGiant;  /* 9x15 */
> > > static gdFontPtr gdFontTiny;  /* 5x8 */
> > > 
> > > is effective.
> > 
> > > 
> > > *********
> > > In file included from term.h:356,
> > >                  from term.c:1368:
> > > ../term/gd.trm:198: error: static declaration of 'gdFontSmall' follows non-static declaration
> > > c:/Programs/GnuWin32/include/gdfonts.h:26: error: previous declaration of 'gdFontSmall' was
> > here
> > > ../term/gd.trm:199: error: static declaration of 'gdFontLarge' follows non-static declaration
> > > c:/Programs/GnuWin32/include/gdfontl.h:28: error: previous declaration of 'gdFontLarge' was
> > here
> > > ../term/gd.trm:200: error: static declaration of 'gdFontMediumBold' follows non-static
> > > declaration
> > > c:/Programs/GnuWin32/include/gdfontmb.h:26: error: previous declaration of 'gdFontMediumBold'
> > > was here
> > > ../term/gd.trm:201: error: static declaration of 'gdFontGiant' follows non-static declaration
> > > c:/Programs/GnuWin32/include/gdfontg.h:27: error: previous declaration of 'gdFontGiant' was
> > here
> > > ../term/gd.trm:202: error: static declaration of 'gdFontTiny' follows non-static declaration
> > > c:/Programs/GnuWin32/include/gdfontt.h:27: error: previous declaration of 'gdFontTiny' was
> > here
> > > make: *** [term.o] Error 1
> > > 
> > > How can I overcome the above?
> > > 
> > > It seems that I have to treat 
> > > #else
> > > static gdFontPtr gdFontSmall;	/* 6x12 */
> > > static gdFontPtr gdFontLarge;	/* 8x16 */
> > > static gdFontPtr gdFontMediumBold;	/* 7x13 */
> > > static gdFontPtr gdFontGiant;  /* 9x15 */
> > > static gdFontPtr gdFontTiny;  /* 5x8 */
> > > #endif
> > > 
> > > 
> > > 
> > > Are the gd devtools in the GnuWin32 curious?
> > > 
> > > Regards
> > > 
> > > Tatsuro
> > > 
> > > 
> > > --- Tatsuro MATSUOKA <tma...@ya...> wrote:
> > > 
> > > > Hello Petr Mikulik
> > > > 
> > > > Thank for your reply
> > > > 
> > > > --- Petr Mikulik <mi...@ph...> wrote:
> > > > 
> > > > > > The below works well for gcc-3.4.5 (mingw) and gcc-4.3.0-tdm (mingw).  
> > > > > 
> > > > > It works for me with gcc 3.4.4.
> > > > > 
> > > > > Your patch is wrong because selection of gd fonts no longer works:
> > > > > 	set term png medium
> > > > > 	show term
> > > > > => shows arial instead.
> > > > 
> > > > OK. I have to include the below. Right?
> > > > # include "gdfonts.h"
> > > > # include "gdfontl.h"
> > > > # include "gdfontmb.h"
> > > > # include "gdfontt.h"
> > > > # include "gdfontg.h"
> > > >  
> > > > 
> > > > > > I do not understand why gcc-3.4.5 works with GD_NEED_LOCAL_FONT_POINTERS.
> > > > > 
> > > > > Probably something is broken in your installation. Wrong library? Library 
> > > > > compiled by another compiler?
> > > > 
> > > > I used the pre-build Gd-2.0.33 binaries, development tools on the GnuWin32.  I do not know
> > > what
> > > > complier is used for build them.  (Perhaps gcc 3.?.? for mingw libralies.)
> > > > 
> > > > Regards
> > > > 
> > > > Tatsuro
> > > > 
> > > > 
> > > > --------------------------------------
> > > > Power up the Internet with Yahoo! Toolbar.
> > > > http://pr.mail.yahoo.co.jp/toolbar/
> > > > 
> > > > -------------------------------------------------------------------------
> > > > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> > > > Build the coolest Linux based applications with Moblin SDK & win great prizes
> > > > Grand prize is a trip for two to an Open Source event anywhere in the world
> > > > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > > > _______________________________________________
> > > > gnuplot-beta mailing list
> > > > gnu...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > > > 
> > > 
> > > 
> > > 
> > > --------------------------------------
> > > Power up the Internet with Yahoo! Toolbar.
> > > http://pr.mail.yahoo.co.jp/toolbar/
> > > 
> > 
> > 
> > --------------------------------------
> > Power up the Internet with Yahoo! Toolbar.
> > http://pr.mail.yahoo.co.jp/toolbar/
> > 
> 
> 
> --------------------------------------
> Power up the Internet with Yahoo! Toolbar.
> http://pr.mail.yahoo.co.jp/toolbar/
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 



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

Re: gd.trm issue for mingw-gcc-4.3.0 building

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

Hello

#if defined(WIN32) && !defined(NONDLL)
  /* static font pointers are recommended when using bgd.dll */
# ifndef GD_NEED_LOCAL_FONT_POINTERS
#  define GD_NEED_LOCAL_FONT_POINTERS
# endif
#endif


  /* static font pointers are recommended when using bgd.dll */

In the Gd 2.0.33 in the GnuWin32, libgd2.dll is used not but bgd.dll.
Why static font pointers are recommended for bgd.dll ?

Regards

Tatsuro


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

> Hello
> 
> Sorry for my carelessness for what Ethan wrote:
> 
> ===Ethan===
> Please look to see if it can be fixed by modifying these lines instead:
> 
> #if defined(WIN32) && !defined(NONDLL)
>   /* static font pointers are recommended when using bgd.dll */
> # ifndef GD_NEED_LOCAL_FONT_POINTERS
> #  define GD_NEED_LOCAL_FONT_POINTERS
> # endif
> #endif 
> ================
> 
> > However Ethan suggest that DO NOT TREAT HERE.
> 
> was not what Ethan would like to say.
> 
> So my conclusion is that I cannot overcome this issue to modify the above.
> 
> It is likely to modify the below 
> 
> #ifndef GD_NEED_LOCAL_FONT_POINTERS
> BGD_EXPORT_DATA_PROT gdFontPtr gdFontSmall;	/* 6x12 */
> BGD_EXPORT_DATA_PROT gdFontPtr gdFontLarge;	/* 8x16 */
> BGD_EXPORT_DATA_PROT gdFontPtr gdFontMediumBold;	/* 7x13 */
> BGD_EXPORT_DATA_PROT gdFontPtr gdFontGiant;  /* 9x15 */
> BGD_EXPORT_DATA_PROT gdFontPtr gdFontTiny;  /* 5x8 */
> #else
> static gdFontPtr gdFontSmall;	/* 6x12 */
> static gdFontPtr gdFontLarge;	/* 8x16 */
> static gdFontPtr gdFontMediumBold;	/* 7x13 */
> static gdFontPtr gdFontGiant;  /* 9x15 */
> static gdFontPtr gdFontTiny;  /* 5x8 */
> #endif
> 
> 
> Regards
> 
> Tatsuro
>  
> 
> --- Tatsuro MATSUOKA <tma...@ya...> wrote:
> 
> > Hello
> > 
> > I'm now confusing.
> > 
> > To include
> > # include "gdfonts.h"
> > # include "gdfontl.h"
> > # include "gdfontmb.h"
> > # include "gdfontt.h"
> > # include "gdfontg.h"
> > 
> > GD_NEED_LOCAL_FONT_POINTERS should be defined,
> > 
> > However
> > GD_NEED_LOCAL_FONT_POINTERS is defined
> > 
> > static gdFontPtr gdFontSmall;	/* 6x12 */
> > static gdFontPtr gdFontLarge;	/* 8x16 */
> > static gdFontPtr gdFontMediumBold;	/* 7x13 */
> > static gdFontPtr gdFontGiant;  /* 9x15 */
> > static gdFontPtr gdFontTiny;  /* 5x8 */
> > 
> > is effective.
> 
> > 
> > *********
> > In file included from term.h:356,
> >                  from term.c:1368:
> > ../term/gd.trm:198: error: static declaration of 'gdFontSmall' follows non-static declaration
> > c:/Programs/GnuWin32/include/gdfonts.h:26: error: previous declaration of 'gdFontSmall' was
> here
> > ../term/gd.trm:199: error: static declaration of 'gdFontLarge' follows non-static declaration
> > c:/Programs/GnuWin32/include/gdfontl.h:28: error: previous declaration of 'gdFontLarge' was
> here
> > ../term/gd.trm:200: error: static declaration of 'gdFontMediumBold' follows non-static
> > declaration
> > c:/Programs/GnuWin32/include/gdfontmb.h:26: error: previous declaration of 'gdFontMediumBold'
> > was here
> > ../term/gd.trm:201: error: static declaration of 'gdFontGiant' follows non-static declaration
> > c:/Programs/GnuWin32/include/gdfontg.h:27: error: previous declaration of 'gdFontGiant' was
> here
> > ../term/gd.trm:202: error: static declaration of 'gdFontTiny' follows non-static declaration
> > c:/Programs/GnuWin32/include/gdfontt.h:27: error: previous declaration of 'gdFontTiny' was
> here
> > make: *** [term.o] Error 1
> > 
> > How can I overcome the above?
> > 
> > It seems that I have to treat 
> > #else
> > static gdFontPtr gdFontSmall;	/* 6x12 */
> > static gdFontPtr gdFontLarge;	/* 8x16 */
> > static gdFontPtr gdFontMediumBold;	/* 7x13 */
> > static gdFontPtr gdFontGiant;  /* 9x15 */
> > static gdFontPtr gdFontTiny;  /* 5x8 */
> > #endif
> > 
> > 
> > 
> > Are the gd devtools in the GnuWin32 curious?
> > 
> > Regards
> > 
> > Tatsuro
> > 
> > 
> > --- Tatsuro MATSUOKA <tma...@ya...> wrote:
> > 
> > > Hello Petr Mikulik
> > > 
> > > Thank for your reply
> > > 
> > > --- Petr Mikulik <mi...@ph...> wrote:
> > > 
> > > > > The below works well for gcc-3.4.5 (mingw) and gcc-4.3.0-tdm (mingw).  
> > > > 
> > > > It works for me with gcc 3.4.4.
> > > > 
> > > > Your patch is wrong because selection of gd fonts no longer works:
> > > > 	set term png medium
> > > > 	show term
> > > > => shows arial instead.
> > > 
> > > OK. I have to include the below. Right?
> > > # include "gdfonts.h"
> > > # include "gdfontl.h"
> > > # include "gdfontmb.h"
> > > # include "gdfontt.h"
> > > # include "gdfontg.h"
> > >  
> > > 
> > > > > I do not understand why gcc-3.4.5 works with GD_NEED_LOCAL_FONT_POINTERS.
> > > > 
> > > > Probably something is broken in your installation. Wrong library? Library 
> > > > compiled by another compiler?
> > > 
> > > I used the pre-build Gd-2.0.33 binaries, development tools on the GnuWin32.  I do not know
> > what
> > > complier is used for build them.  (Perhaps gcc 3.?.? for mingw libralies.)
> > > 
> > > Regards
> > > 
> > > Tatsuro
> > > 
> > > 
> > > --------------------------------------
> > > Power up the Internet with Yahoo! Toolbar.
> > > http://pr.mail.yahoo.co.jp/toolbar/
> > > 
> > > -------------------------------------------------------------------------
> > > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> > > Build the coolest Linux based applications with Moblin SDK & win great prizes
> > > Grand prize is a trip for two to an Open Source event anywhere in the world
> > > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > > _______________________________________________
> > > gnuplot-beta mailing list
> > > gnu...@li...
> > > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > > 
> > 
> > 
> > 
> > --------------------------------------
> > Power up the Internet with Yahoo! Toolbar.
> > http://pr.mail.yahoo.co.jp/toolbar/
> > 
> 
> 
> --------------------------------------
> Power up the Internet with Yahoo! Toolbar.
> http://pr.mail.yahoo.co.jp/toolbar/
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: gd.trm issue for mingw-gcc-4.3.0 building

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

> However these confilt with the defenition in gdfont??.h.
>
> Are the gd devtools in the GnuWin32 curious?

I don't know. I have compiled the static gd library myself. I did it with 
NONDLL defined -- I see I've put

#define NONDLL 1
    /* //PM @@@@@@@@@@@@@ */

to the very beginning of gd.h.

---
PM

Re: gd.trm issue for mingw-gcc-4.3.0 building

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

Hello

Sorry for my carelessness for what Ethan wrote:

===Ethan===
Please look to see if it can be fixed by modifying these lines instead:

#if defined(WIN32) && !defined(NONDLL)
  /* static font pointers are recommended when using bgd.dll */
# ifndef GD_NEED_LOCAL_FONT_POINTERS
#  define GD_NEED_LOCAL_FONT_POINTERS
# endif
#endif 
================

> However Ethan suggest that DO NOT TREAT HERE.

was not what Ethan would like to say.

So my conclusion is that I cannot overcome this issue to modify the above.

It is likely to modify the below 

#ifndef GD_NEED_LOCAL_FONT_POINTERS
BGD_EXPORT_DATA_PROT gdFontPtr gdFontSmall;	/* 6x12 */
BGD_EXPORT_DATA_PROT gdFontPtr gdFontLarge;	/* 8x16 */
BGD_EXPORT_DATA_PROT gdFontPtr gdFontMediumBold;	/* 7x13 */
BGD_EXPORT_DATA_PROT gdFontPtr gdFontGiant;  /* 9x15 */
BGD_EXPORT_DATA_PROT gdFontPtr gdFontTiny;  /* 5x8 */
#else
static gdFontPtr gdFontSmall;	/* 6x12 */
static gdFontPtr gdFontLarge;	/* 8x16 */
static gdFontPtr gdFontMediumBold;	/* 7x13 */
static gdFontPtr gdFontGiant;  /* 9x15 */
static gdFontPtr gdFontTiny;  /* 5x8 */
#endif


Regards

Tatsuro
 

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

> Hello
> 
> I'm now confusing.
> 
> To include
> # include "gdfonts.h"
> # include "gdfontl.h"
> # include "gdfontmb.h"
> # include "gdfontt.h"
> # include "gdfontg.h"
> 
> GD_NEED_LOCAL_FONT_POINTERS should be defined,
> 
> However
> GD_NEED_LOCAL_FONT_POINTERS is defined
> 
> static gdFontPtr gdFontSmall;	/* 6x12 */
> static gdFontPtr gdFontLarge;	/* 8x16 */
> static gdFontPtr gdFontMediumBold;	/* 7x13 */
> static gdFontPtr gdFontGiant;  /* 9x15 */
> static gdFontPtr gdFontTiny;  /* 5x8 */
> 
> is effective.

> 
> *********
> In file included from term.h:356,
>                  from term.c:1368:
> ../term/gd.trm:198: error: static declaration of 'gdFontSmall' follows non-static declaration
> c:/Programs/GnuWin32/include/gdfonts.h:26: error: previous declaration of 'gdFontSmall' was here
> ../term/gd.trm:199: error: static declaration of 'gdFontLarge' follows non-static declaration
> c:/Programs/GnuWin32/include/gdfontl.h:28: error: previous declaration of 'gdFontLarge' was here
> ../term/gd.trm:200: error: static declaration of 'gdFontMediumBold' follows non-static
> declaration
> c:/Programs/GnuWin32/include/gdfontmb.h:26: error: previous declaration of 'gdFontMediumBold'
> was here
> ../term/gd.trm:201: error: static declaration of 'gdFontGiant' follows non-static declaration
> c:/Programs/GnuWin32/include/gdfontg.h:27: error: previous declaration of 'gdFontGiant' was here
> ../term/gd.trm:202: error: static declaration of 'gdFontTiny' follows non-static declaration
> c:/Programs/GnuWin32/include/gdfontt.h:27: error: previous declaration of 'gdFontTiny' was here
> make: *** [term.o] Error 1
> 
> How can I overcome the above?
> 
> It seems that I have to treat 
> #else
> static gdFontPtr gdFontSmall;	/* 6x12 */
> static gdFontPtr gdFontLarge;	/* 8x16 */
> static gdFontPtr gdFontMediumBold;	/* 7x13 */
> static gdFontPtr gdFontGiant;  /* 9x15 */
> static gdFontPtr gdFontTiny;  /* 5x8 */
> #endif
> 
> 
> 
> Are the gd devtools in the GnuWin32 curious?
> 
> Regards
> 
> Tatsuro
> 
> 
> --- Tatsuro MATSUOKA <tma...@ya...> wrote:
> 
> > Hello Petr Mikulik
> > 
> > Thank for your reply
> > 
> > --- Petr Mikulik <mi...@ph...> wrote:
> > 
> > > > The below works well for gcc-3.4.5 (mingw) and gcc-4.3.0-tdm (mingw).  
> > > 
> > > It works for me with gcc 3.4.4.
> > > 
> > > Your patch is wrong because selection of gd fonts no longer works:
> > > 	set term png medium
> > > 	show term
> > > => shows arial instead.
> > 
> > OK. I have to include the below. Right?
> > # include "gdfonts.h"
> > # include "gdfontl.h"
> > # include "gdfontmb.h"
> > # include "gdfontt.h"
> > # include "gdfontg.h"
> >  
> > 
> > > > I do not understand why gcc-3.4.5 works with GD_NEED_LOCAL_FONT_POINTERS.
> > > 
> > > Probably something is broken in your installation. Wrong library? Library 
> > > compiled by another compiler?
> > 
> > I used the pre-build Gd-2.0.33 binaries, development tools on the GnuWin32.  I do not know
> what
> > complier is used for build them.  (Perhaps gcc 3.?.? for mingw libralies.)
> > 
> > Regards
> > 
> > Tatsuro
> > 
> > 
> > --------------------------------------
> > Power up the Internet with Yahoo! Toolbar.
> > http://pr.mail.yahoo.co.jp/toolbar/
> > 
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK & win great prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> 
> 
> 
> --------------------------------------
> Power up the Internet with Yahoo! Toolbar.
> http://pr.mail.yahoo.co.jp/toolbar/
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: gd.trm issue for mingw-gcc-4.3.0 building

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

Hello

I'm now confusing.

To include
# include "gdfonts.h"
# include "gdfontl.h"
# include "gdfontmb.h"
# include "gdfontt.h"
# include "gdfontg.h"

GD_NEED_LOCAL_FONT_POINTERS should be defined,

However
GD_NEED_LOCAL_FONT_POINTERS is defined

static gdFontPtr gdFontSmall;	/* 6x12 */
static gdFontPtr gdFontLarge;	/* 8x16 */
static gdFontPtr gdFontMediumBold;	/* 7x13 */
static gdFontPtr gdFontGiant;  /* 9x15 */
static gdFontPtr gdFontTiny;  /* 5x8 */

is effective.

However these confilt with the defenition in gdfont??.h.
like 

*********
In file included from term.h:356,
                 from term.c:1368:
../term/gd.trm:198: error: static declaration of 'gdFontSmall' follows non-static declaration
c:/Programs/GnuWin32/include/gdfonts.h:26: error: previous declaration of 'gdFontSmall' was here
../term/gd.trm:199: error: static declaration of 'gdFontLarge' follows non-static declaration
c:/Programs/GnuWin32/include/gdfontl.h:28: error: previous declaration of 'gdFontLarge' was here
../term/gd.trm:200: error: static declaration of 'gdFontMediumBold' follows non-static declaration
c:/Programs/GnuWin32/include/gdfontmb.h:26: error: previous declaration of 'gdFontMediumBold' was here
../term/gd.trm:201: error: static declaration of 'gdFontGiant' follows non-static declaration
c:/Programs/GnuWin32/include/gdfontg.h:27: error: previous declaration of 'gdFontGiant' was here
../term/gd.trm:202: error: static declaration of 'gdFontTiny' follows non-static declaration
c:/Programs/GnuWin32/include/gdfontt.h:27: error: previous declaration of 'gdFontTiny' was here
make: *** [term.o] Error 1

How can I overcome the above?

It seems that I have to treat 
#else
static gdFontPtr gdFontSmall;	/* 6x12 */
static gdFontPtr gdFontLarge;	/* 8x16 */
static gdFontPtr gdFontMediumBold;	/* 7x13 */
static gdFontPtr gdFontGiant;  /* 9x15 */
static gdFontPtr gdFontTiny;  /* 5x8 */
#endif

However Ethan suggest that DO NOT TREAT HERE.


Are the gd devtools in the GnuWin32 curious?

Regards

Tatsuro


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

> Hello Petr Mikulik
> 
> Thank for your reply
> 
> --- Petr Mikulik <mi...@ph...> wrote:
> 
> > > The below works well for gcc-3.4.5 (mingw) and gcc-4.3.0-tdm (mingw).  
> > 
> > It works for me with gcc 3.4.4.
> > 
> > Your patch is wrong because selection of gd fonts no longer works:
> > 	set term png medium
> > 	show term
> > => shows arial instead.
> 
> OK. I have to include the below. Right?
> # include "gdfonts.h"
> # include "gdfontl.h"
> # include "gdfontmb.h"
> # include "gdfontt.h"
> # include "gdfontg.h"
>  
> 
> > > I do not understand why gcc-3.4.5 works with GD_NEED_LOCAL_FONT_POINTERS.
> > 
> > Probably something is broken in your installation. Wrong library? Library 
> > compiled by another compiler?
> 
> I used the pre-build Gd-2.0.33 binaries, development tools on the GnuWin32.  I do not know what
> complier is used for build them.  (Perhaps gcc 3.?.? for mingw libralies.)
> 
> Regards
> 
> Tatsuro
> 
> 
> --------------------------------------
> Power up the Internet with Yahoo! Toolbar.
> http://pr.mail.yahoo.co.jp/toolbar/
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 



--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/