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

Re: Change in syntax OK for binary data?

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

On Friday 17 November 2006 02:30 pm, Daniel J Sebald wrote:
> >>The colon would now be in several place, e.g.,
> >>
> >>splot 'image.foo' binary center=(50,50):(150,50) with rgbimage
> >
> > I don't understand what that one is supposed to do.
>
> There could be multiple images (or whatever) in the file.

Don't we already have a documented syntax for that?

If you need to treat the separate data sets in the file
differently, I think the syntax should be

  splot 'image.foo' index 0 binary center=(50,50), \
                 '' index 1 binary center=(150,50)

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

Re: Change in syntax OK for binary data?

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

Ethan Merritt wrote:
> On Friday 17 November 2006 01:51 pm, Daniel J Sebald wrote:
> 
>>So, as a straightforward workaround, I suggest a change in syntax--on
>>something that few people have probably used as of yet.  So, anyone
>>have any objections of changing the separator from a comma to a
>>colon.  That will have an appearance similar to "using 1:2:3", for
>>example
>>
>>splot 'scatter2.bin' binary endian=little record=30,30,29,26 u 1:2:3
>>
>>would become
>>
>>splot 'scatter2.bin' binary endian=little record=30:30:29:26 u 1:2:3
> 
> 
> I would rather bracket the set of specifiers while keeping the commas
>  
>  splot 'scatter2.bin' binary endian=little record=(30,30,29,26) u 1:2:3

Well, the appearance isn't bad, but it does look a bit like a quadruple, but that isn't necessarily a problem conceptually.

> 
> 
>>The colon would now be in several place, e.g.,
>>
>>splot 'image.foo' binary center=(50,50):(150,50) with rgbimage
> 
> 
> I don't understand what that one is supposed to do.

There could be multiple images (or whatever) in the file.  

To go along with your suggestion above, it might be

splot 'image.foo' binary center=((50,50),(150,50)) with rgbimage

Again, a collection of pairs; that would work.

Dan

Re: Building wxt terminal for OS X

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

Ethan Merritt wrote:
> On Friday 17 November 2006 01:33 pm, Joe Koski wrote:
>  =20
>> on 11/17/06 1:48 PM, Per Persson at per...@ma... wrote:
>>    =20
>>> I still maintain my opinions that=20
>>> 1) building an X11 based wxt  terminal should be straightforward
>>> 2) a "native" wxt terminal is going to take a lot of work.
>>>      =20
>> I think Per's assessment is correct. The problem is not with wxt, but
>> with the necessity for "bundling" wxWidget applications for native
>> use on the Mac.=20
>>    =20
>
> You call it a necessity, where Per implies that it is simply a
> matter of choice between X11 and "native".  Which is it?
>  =20
A native one is for sure better since X11 is not installed by default on=20
MacOS. The *only* problem we seem to get is this "no-input" issue, which=20
is supposed to be related to bundling, as Joe mentioned.


> If it's just a matter of choice, it would be nice to provide
> a concise statement of what is needed to build an X11-based
> wxt terminal under OSX.  And of course since that is the only
> working option, it should be made the default.
>
> In this scenario, can the code in .../term/wxt.trm and=20
>  .../src/wxterminal/*  be used with no change from the=20
> state in 4.2-rc1?
>  =20
Building for X11 (i.e. wxGTK, as you're doing on Linux) should be=20
working right now on MacOS, without modifications, with the usual=20
'configure; make; make install' routine.
Building for wxMAC needs the patch that makes the code in=20
src/wxterminal/wxt_gui.* files recognize the __WXMAC__ preprocessor=20
variable in addition to __WXMSW__ and __WXGTK__. We also need to figure=20
out why the window is not getting input. I'd love to see it working, but=20
I don't have a Mac to test it...

Maybe Mojca can help, since she is now trying to build gnuplot on a Mac=20
too ?

Best regards,

Timoth=E9e

Re: Change in syntax OK for binary data?

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

On Friday 17 November 2006 01:51 pm, Daniel J Sebald wrote:
>
> So, as a straightforward workaround, I suggest a change in syntax--on
> something that few people have probably used as of yet.  So, anyone
> have any objections of changing the separator from a comma to a
> colon.  That will have an appearance similar to "using 1:2:3", for
> example
>
> splot 'scatter2.bin' binary endian=little record=30,30,29,26 u 1:2:3
>
> would become
>
> splot 'scatter2.bin' binary endian=little record=30:30:29:26 u 1:2:3

I would rather bracket the set of specifiers while keeping the commas
 
 splot 'scatter2.bin' binary endian=little record=(30,30,29,26) u 1:2:3

> The colon would now be in several place, e.g.,
>
> splot 'image.foo' binary center=(50,50):(150,50) with rgbimage

I don't understand what that one is supposed to do.

The docs say for 'binary keyword center'
 Similar to `origin`, this keyword will position the array such
 that its center lies at the point given by the tuple.
 For example, `center=(0,0)`.

What is the meaning of the second parenthetical pair in the
above example?


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

Re: Building wxt terminal for OS X

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

On Friday 17 November 2006 01:33 pm, Joe Koski wrote:
> on 11/17/06 1:48 PM, Per Persson at per...@ma... wrote:
> >
> > I still maintain my opinions that 
> > 1) building an X11 based wxt  terminal should be straightforward
> > 2) a "native" wxt terminal is going to take a lot of work.
>
> I think Per's assessment is correct. The problem is not with wxt, but
> with the necessity for "bundling" wxWidget applications for native
> use on the Mac. 

You call it a necessity, where Per implies that it is simply a
matter of choice between X11 and "native".  Which is it?

If it's just a matter of choice, it would be nice to provide
a concise statement of what is needed to build an X11-based
wxt terminal under OSX.  And of course since that is the only
working option, it should be made the default.

In this scenario, can the code in .../term/wxt.trm and 
 .../src/wxterminal/*  be used with no change from the 
state in 4.2-rc1?

> The current gnuplot-4.2.rc1 continues to work well on my Mac, with
> Per's AquaTerm doing the job for .eps and .pdf output.

Much as I appreciate Per's work on aquaterm, it remains
short on features compared to either x11 or wxt. I'm sure that
beefing up aquaterm is possible, but it's clearly not going to
happen for version 4.2.  The wxt terminal, on the other hand,
is all ready to go except for installation instructions.


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

Change in syntax OK for binary data?

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

A while back Ethan brought to my attention that the binary code didn't allow use of defined expressions like most commands in gnuplot, i.e., it didn't use the routine const_express().

Using const_express() created a problem with syntax.  The issue is that the comma separating multiple entries must be resolved against its use as the separator between two plot commands on the same line.  To do that would require attempting to check if there is a valid constant expression, if not, back up and treat as the start of a new plot command.  However, const_express() internally errors and does not return, so that idea is strictly limited.

So, as a straightforward workaround, I suggest a change in syntax--on something that few people have probably used as of yet.  So, anyone have any objections of changing the separator from a comma to a colon.  That will have an appearance similar to "using 1:2:3", for example

-splot 'scatter2.bin' binary endian=little record=30,30,29,26 using 1:2:3

would become

+splot 'scatter2.bin' binary endian=little record=30:30:29:26 using 1:2:3


The colon would now be in several place, e.g.,

splot 'image.foo' binary center=(50,50):(150,50) with rgbimage

Dan

Re: Building wxt terminal for OS X

[Joe K. <jko...@co...>]

on 11/17/06 1:48 PM, Per Persson at per...@ma... wrote:

> 
> On Nov 17, 2006, at 20:27, Ethan Merritt wrote:
> 
>> Was there any resolution to the issue of building wxt terminal
>> support for OSX?
> 
> Not that I know of.
> 
> I still maintain my opinions that 1) building an X11 based wxt
> terminal should be straightforward, and 2) a "native" wxt terminal is
> going to take a lot of work.
> 
> I feel a little uneasy to make a statement like the above without
> actually getting my hands dirty, but for the time being it's the best
> I can do...
> 
>> 
>> I would like to put out a second release candidate for 4.2,
>> and would like to add a note to the INSTALL file about known
>> platform-specific problems.
>> 
>> The most important thing to establish is whether this is going to
>> require further code changes in gnuplot, which might hold up a
>> final release of 4.2, or whether it is a matter of installation
>> instructions only.
>> 
>> -- 
>> Ethan A Merritt
>> Biomolecular Structure Center
>> University of Washington, Seattle WA
> 

Ethan,

I think Per's assessment is correct. The problem is not with wxt, but with
the necessity for "bundling" wxWidget applications for native use on the
Mac. That requires either extensive modifications to the gnuplot make files,
or a special separate make file approach for the Mac. Neither choice is very
pretty. This is compounded by the necessity for "Universal" binaries for PPC
and Intel Macs. In a year or so, that need will decrease. I have the time,
but not the knowledge to do the work. We need someone who has been through
Mac's developer "boot camp" recently. Got any scholarships laying around?
I'll be happy to spend a week or two in San Francisco at someone else's
expense.

Would making the gnuplot build into an Xcode project help? Just a thought.

Over on the octave list, John Eaton is currently tearing his hair out over
some octave/gnuplot interface issues. It sounds to me like he needs some
sort of a gnuplot device independent file for storing and later recalling
plot commands and options that were sent to gnuplot. His problems centers
around an octave routine called legend.m, which has always been somewhat
problematic.

The current gnuplot-4.2.rc1 continues to work well on my Mac, with Per's
AquaTerm doing the job for .eps and .pdf output.

Joe
 

Re: Building wxt terminal for OS X

[Per P. <per...@ma...>]

On Nov 17, 2006, at 20:27, Ethan Merritt wrote:

> Was there any resolution to the issue of building wxt terminal
> support for OSX?

Not that I know of.

I still maintain my opinions that 1) building an X11 based wxt  
terminal should be straightforward, and 2) a "native" wxt terminal is  
going to take a lot of work.

I feel a little uneasy to make a statement like the above without  
actually getting my hands dirty, but for the time being it's the best  
I can do...

>
> I would like to put out a second release candidate for 4.2,
> and would like to add a note to the INSTALL file about known
> platform-specific problems.
>
> The most important thing to establish is whether this is going to
> require further code changes in gnuplot, which might hold up a
> final release of 4.2, or whether it is a matter of installation
> instructions only.
>
> -- 
> Ethan A Merritt
> Biomolecular Structure Center
> University of Washington, Seattle WA

Re: Building wxt terminal for OS X

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

Was there any resolution to the issue of building wxt terminal
support for OSX?

I would like to put out a second release candidate for 4.2,
and would like to add a note to the INSTALL file about known
platform-specific problems.

The most important thing to establish is whether this is going to 
require further code changes in gnuplot, which might hold up a
final release of 4.2, or whether it is a matter of installation
instructions only. 

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

Re: Simplified processing of image and rgbimage plots

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

On Thursday 16 November 2006 07:05 pm, Daniel J Sebald wrote:
> Ethan A Merritt wrote:
> > The specialized code for image handling could be removed from gd.trm,
> > for instance. Also x11. Is this worth doing?
>
> For the bitmapped outputs like PNG and so on, it wouldn't matter if 
> both the image routines and polygon methods produced the same output.

There seems to be a very slight difference in the scaling of the whole
plot.  I guess there must be some subtle difference in the coordinates
fed to the auto-scaling routine?  But they both look equally good to me.

I don't notice any difference at all between the two modes when
output to x11.

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

Re: Simplified processing of image and rgbimage plots

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

Ethan A Merritt wrote:
> Yesterday I committed to CVS a patch that Dan Sebald and I worked out.
> It removes many restrictions on the use of RGBIMAGE in 3D plots, and the 
> use of RGB color in polygons derived from image data. Now all terminal 
> drivers that can handle RGB colors and filled polygons can automatically 
> also handle image and rgbimage plot styles.
> 
> This extends the capabilities of svg, xfig, and maybe other terminals.
> 
> The specialized code for image handling could be removed from gd.trm, for 
> instance. Also x11. Is this worth doing?
> 
> The specialized image handling code in post.trm is still useful because it 
> drastically reduces the output file size, however.

I like this improvement, but I also suggest leaving the the broader image handling in place with the fall back to the polygon-based approach.  For x11, the image code is preferred from the standpoint of memory size and refresh speed.  For an image there is M x N pixel values and the location of its points and borders.  The same image as polygons is M x N pixel values and 4 x M x N pixel corner values.  More memory, more processing for the polygons (even though the code for polygon processing may be more straightforward).  The other thing that having all the image data in the form of one hunk is that if ever someone wants to improve anti-aliasing with the image, it would be possible.  With individual rectangular elements, signal processing on the image would be cumbersome.

For PostScript, there is the capability to place images at viewing angles.  (However, that terminal function doesn't have variables for that right now...  Hindsight is 20/20 I guess.)

For the bitmapped outputs like PNG and so on, it wouldn't matter if both the image routines and polygon methods produced the same output.  We could test that with a simple file diff, I think.

Dan

Re: removing duplicate keys for multiple histograms

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

Laurence Darby wrote:

> Shouldn't the option "notitle" be called "nokey" instead, because it's
> making the keys disappear and the titles are still underneath each
> histogram?

No.  The things underneath the histograms aren't titles, they're tick 
labels.  The thing that becomes a part of the key is the title for that 
dataset.

Re: removing duplicate keys for multiple histograms

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

On Thursday 16 November 2006 11:11 am, Laurence Darby wrote:
> > > Syntax is from the cvs version, but the principle should be
> > > clear:
> > >
> > > plot newhistogram "One", for [i=2:5] 'immigration.dat' using i, \
> > >      newhistogram "Two", for [i=2:5] '' using i notitle, \
> > >      newhistogram "Three", for [i=2:5] '' using i notitle
> >
> > Thanks that does exactly what I want :)
>
> Shouldn't the option "notitle" be called "nokey" instead, because
> it's making the keys disappear and the titles are still underneath
> each histogram?

You are focused on histograms, but the "notitle" option applies
to all plot types and has been part of gnuplot syntax since
approximately forever.  

Yes, histograms have a separate object that is obviously a 'title',
set by the "newhistogram" command. But all other plot types have
only the title that appears in the key.  



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

Re: removing duplicate keys for multiple histograms

[Laurence D. <ld...@mi...>]

Laurence Darby wrote:

> Ethan A Merritt wrote:
> 
> > On Thursday 16 November 2006 05:49 am, Laurence Darby wrote:
> > > 
> > > Hello,
> > > 
> > > Using newhistogram to have several histograms on one plot, I'd like to
> > > be able to turn off keys for certain histgrams, is this possible?
> > 
> > Syntax is from the cvs version, but the principle should be clear:
> > 
> > plot newhistogram "One", for [i=2:5] 'immigration.dat' using i, \
> >      newhistogram "Two", for [i=2:5] '' using i notitle, \
> >      newhistogram "Three", for [i=2:5] '' using i notitle
> > 
> 
> 
> Thanks that does exactly what I want :)
> 


Shouldn't the option "notitle" be called "nokey" instead, because it's
making the keys disappear and the titles are still underneath each
histogram?

Laurence

Simplified processing of image and rgbimage plots

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

Yesterday I committed to CVS a patch that Dan Sebald and I worked out.
It removes many restrictions on the use of RGBIMAGE in 3D plots, and the 
use of RGB color in polygons derived from image data. Now all terminal 
drivers that can handle RGB colors and filled polygons can automatically 
also handle image and rgbimage plot styles.

This extends the capabilities of svg, xfig, and maybe other terminals.

The specialized code for image handling could be removed from gd.trm, for 
instance. Also x11. Is this worth doing?

The specialized image handling code in post.trm is still useful because it 
drastically reduces the output file size, however.

An interesting note:  
The patch removed as much code as it added. 
Net change: +2 lines of code.
And this is aside from the possibility of now removing the special-case
term->image code from gd.trm, x11, and maybe other terminal drivers.



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

Re: removing duplicate keys for multiple histograms

[Laurence D. <ld...@mi...>]

Ethan A Merritt wrote:

> On Thursday 16 November 2006 05:49 am, Laurence Darby wrote:
> > 
> > Hello,
> > 
> > Using newhistogram to have several histograms on one plot, I'd like to
> > be able to turn off keys for certain histgrams, is this possible?
> 
> Syntax is from the cvs version, but the principle should be clear:
> 
> plot newhistogram "One", for [i=2:5] 'immigration.dat' using i, \
>      newhistogram "Two", for [i=2:5] '' using i notitle, \
>      newhistogram "Three", for [i=2:5] '' using i notitle
> 


Thanks that does exactly what I want :)

Laurence

Re: removing duplicate keys for multiple histograms

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

On Thursday 16 November 2006 05:49 am, Laurence Darby wrote:
> 
> Hello,
> 
> Using newhistogram to have several histograms on one plot, I'd like to
> be able to turn off keys for certain histgrams, is this possible?

Syntax is from the cvs version, but the principle should be clear:

plot newhistogram "One", for [i=2:5] 'immigration.dat' using i, \
     newhistogram "Two", for [i=2:5] '' using i notitle, \
     newhistogram "Three", for [i=2:5] '' using i notitle

> The keys for each histogram on my plot are identical, so I'd like to be
> able to turn off all but the first and save some space.


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

removing duplicate keys for multiple histograms

[Laurence D. <ld...@mi...>]

Hello,

Using newhistogram to have several histograms on one plot, I'd like to
be able to turn off keys for certain histgrams, is this possible?

The keys for each histogram on my plot are identical, so I'd like to be
able to turn off all but the first and save some space.  Would manually
turning off keys be the best way or could gnuplot detect they are the
same (same colors too) and omit duplicates?

Thanks,
Laurence

Re: Weard png output problem

[Nibbler <rea...@ho...>]

Oh yes !

Thank you very much Ethan !
godspeed. 


Ethan Merritt wrote:
> 
> On Wednesday 15 November 2006 04:35 am, Nibbler wrote:
>>
>> Can I  increase the autoset yrange value ?
>>
>> What I means is can I somehow do like this:
>> yrange [0:autorange +3 ] ?
> 
> help set offsets
> 
> 
> -- 
> Ethan A Merritt
> Biomolecular Structure Center
> University of Washington, Seattle WA
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 

-- 
View this message in context: http://www.nabble.com/Weard-png-output-problem-tf2624196.html#a7372339
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: Re: compiling gnuplot on Windows & mac/linux

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

On 11/15/06, Hans-Bernhard Br=F6ker <HBB...@t-...> wrote:
> Mojca Miklavec wrote:
>
> > OK, I spent three or four hours and finnaly got MinGW working on this
> > mac
>
> Now you have me confused.  You obviously have a Windows box at your
> disposition (or how else did you run MS Studio.Net?), and you're about
> to build programs for Windows, which you'll have to test-run at some
> point --- so why on earth did you pick a *Mac* to install and run MinGW o=
n?

I admit, weird indeed.

I've changed my computer a few days ago from dual-boot Linux+Win
(running Win 99% of time) to dual-boot Mac+Win (running Mac 95% of
time). I urgently needed gnuplot and when I changed the machine taking
MS Studio.Net was the fastest way to build it (since I had all the
files ready).

Yesterday somebody asked me for windows binary and the one compiled
with MSVC didn't work on his computer (apart from the fact that GD,
PDF, ... don't work either). Since using MinGW was apparently the only
choice, I decided to try to compile on Mac, which will take me less
effort (once set up) next time when I'll want to create a windows
binary.

About testing ... I often use windows on other computers (and I don't
want to set up all the development tools on every single computer
where I might want to use gnuplot) and since I don't intend to develop
the windows user-interface, it should be enough to test the terminal
in one platform only. Once it's OK, the windows binary should remain
OK after applying new pathes.

> > Now a question: is anyone ready to help me to write a clean makefile
> > for MinGW for cross-compiling (which would be suitable to add to CVS)
> > or does that exist already?
>
> It doesn't exist, but I rather doubt it'd be interesting enough to the
> general public to be worth putting in CVS.  The overwhelming majority of
> people who want to build programs for Windows will be using Windows
> machines to do it.
>
> But feel free to post the modified makefile.mgw on the "Patches" Tracker
> page.

I'll see what I can do. I'm currently trying to figure out how to enable gd=
 ...

> > /usr/bin/automake -> /etc/alternatives/automake
> > /etc/alternatives/automake -> /usr/bin/automake-1.9 (was 1.4a)
> >
> > So I only fixed /etc/alternatives/automake and aclocal.
>
> "Fixed" them --- how?  By modifying those symlinks yourself?

Yes. I had no idea what else to do.

> That's not
> how these things are supposed to be managed.  There's a program for
> that.  It should be called 'alternatives' or similar, and it'll probably
> be in /sbin or /usr/sbin, because only root can usefully run it.

Thanks. There's indeed a program update-alternatives in /usr/sbin.

On 11/15/06, Ethan A Merritt wrote:
> On Wednesday 15 November 2006 10:16 am, Mojca Miklavec wrote:
> > > It would be extremely useful if developers wouldn't only put source
> > > files on the web, but also binaries, at least for windows.
> >
> > I'm sorry, I was too unclear. I meant it as: it would help a lot if
> > files like the one on
> >     http://sourceforge.net/project/showfiles.php?group_id=3D2055&packag=
e_id=3D66525
> > (gnuplot 4.2rc1) would also be available in binary form for windows
> > (at least; perhaps also for mac).
>
> Thank you for volunteering.
>
> The current developing team basically doesn't use windows much,
> many of us not at all. So we welcome your assistance in preparing
> binary versions for this awkward platform.

I would be glad to help and submit binaries when needed. At least once
I figure out how to buid help files & gd ...

Mojca

Re: Weard png output problem

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

On Wednesday 15 November 2006 04:35 am, Nibbler wrote:
>
> Can I  increase the autoset yrange value ?
>
> What I means is can I somehow do like this:
> yrange [0:autorange +3 ] ?

help set offsets


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

Re: compiling gnuplot on Windows & mac/linux

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

Mojca Miklavec wrote:

> makefile.mgw
> #DESTDIR = /c/Progra~1/Gnuplot4.1
> 
> any many other places still contain old strings. Can anyone grep for
> them and replace them?

Sure.  Anyone can.  We'd certainly like to receive lists of things we 
missed, so they can be corrected in the next release candidate. 
Spotting things like that is what release candidates are about.

> OK, I spent three or four hours and finnaly got MinGW working on this
> mac 

Now you have me confused.  You obviously have a Windows box at your 
disposition (or how else did you run MS Studio.Net?), and you're about 
to build programs for Windows, which you'll have to test-run at some 
point --- so why on earth did you pick a *Mac* to install and run MinGW on?

> Now a question: is anyone ready to help me to write a clean makefile
> for MinGW for cross-compiling (which would be suitable to add to CVS)
> or does that exist already? 

It doesn't exist, but I rather doubt it'd be interesting enough to the 
general public to be worth putting in CVS.  The overwhelming majority of 
people who want to build programs for Windows will be using Windows 
machines to do it.

But feel free to post the modified makefile.mgw on the "Patches" Tracker 
page.

> It would be extremely useful if developers wouldn't only put source
> files on the web, but also binaries, at least for windows.

We will --- for the actual release.  If and when we actually manage to 
get there.

> But forget about that. It's finally working now - I have no idea where
> the error came from and I don't care any more. Running only autoconf
> doesn't seem the best thing to do anyway.

Obviously not.  You have to at least run automake, too.  And aclocal.

The ./prepare script exists for a reason.

> /usr/bin/automake -> /etc/alternatives/automake
> /etc/alternatives/automake -> /usr/bin/automake-1.9 (was 1.4a)
> 
> So I only fixed /etc/alternatives/automake and aclocal.

"Fixed" them --- how?  By modifying those symlinks yourself?  That's not 
how these things are supposed to be managed.  There's a program for 
that.  It should be called 'alternatives' or similar, and it'll probably 
be in /sbin or /usr/sbin, because only root can usefully run it.

Re: compiling gnuplot on Windows & mac/linux

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

On Wednesday 15 November 2006 10:16 am, Mojca Miklavec wrote:
> > It would be extremely useful if developers wouldn't only put source
> > files on the web, but also binaries, at least for windows.
> 
> I'm sorry, I was too unclear. I meant it as: it would help a lot if
> files like the one on
>     http://sourceforge.net/project/showfiles.php?group_id=2055&package_id=66525
> (gnuplot 4.2rc1) would also be available in binary form for windows
> (at least; perhaps also for mac).

Thank you for volunteering.

The current developing team basically doesn't use windows much, 
many of us not at all. So we welcome your assistance in preparing
binary versions for this awkward platform.


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

Re: Re: Re: compiling gnuplot on Windows & mac/linux

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

> It would be extremely useful if developers wouldn't only put source
> files on the web, but also binaries, at least for windows.

I'm sorry, I was too unclear. I meant it as: it would help a lot if
files like the one on
    http://sourceforge.net/project/showfiles.php?group_id=2055&package_id=66525
(gnuplot 4.2rc1) would also be available in binary form for windows
(at least; perhaps also for mac).

(If it would be easier to compile gnuplot for windows, the one who
puts source files on sourceforge coud also place the windows binary
next to them.)

Mojca

Re: Re: compiling gnuplot on Windows & mac/linux

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

On 11/14/06, Hans-Bernhard Br=F6ker wrote:
> Mojca Miklavec wrote:
> > On 11/12/06, Hans-Bernhard Br=F6ker wrote:
> >> Mojca Miklavec wrote:
>
> >> > # 4996 - term.c(1455) : warning C4996: 'strcpy' was declared depreca=
ted
>
> >> No it wasn't.  MS is spreading misinformation.
>
> > MS wants to have its own version of "safe" string copying
>
> They can want that as much as the day is long, that doesn't change the
> fact that they're telling a lie, and they know it.  strcpy is an ISO/IEC
> Standard C Library function.  That means it's not in Microsoft's power
> to deprecate it.
>
>  > and other
> > routines that are otherwise standard in any other compiler but the
> > Microsoft's one.
>
> There's no such thing.  These functions are standard, and will remain
> so, completely regardless of whether Microsoft's compiler has them or not=
.
>
> > adding /D_CRT_SECURE_NO_DEPRECATE
> > removes those "stupid" warnings.
>
> I'd rather you remove the stupid compiler that emits them.

makefile.mgw
#DESTDIR =3D /c/Progra~1/Gnuplot4.1

any many other places still contain old strings. Can anyone grep for
them and replace them?


OK, I spent three or four hours and finnaly got MinGW working on this
mac and managed to compile a working windows version of gnuplot (still
without gd, freetype & help, but nonetheless I'm happy about it).

Now a question: is anyone ready to help me to write a clean makefile
for MinGW for cross-compiling (which would be suitable to add to CVS)
or does that exist already? (I already fixed in a way that enables me
to compile it on my computer, but it would be nice if it would compile
on other computers as well)

It would be extremely useful if developers wouldn't only put source
files on the web, but also binaries, at least for windows.

> > But it would help a lot if those warnings would be removed with the
> > three switches mentioned above,
>
> Feel free to do that in your own local version.  I don't see a good
> reason why we should support Microsoft's willfully distorted view of
> they world by putting such options into the CVS version of the makefile.
> Microsoft has made it clear that they don't care about providing a
> working compiler, why should we care about supporting their broken produc=
t?

OK, I accept that.

> >> > configure.in:1: error: possibly undefined macro: dnl
>
> >> Complete and utter nonsense.  dnl is an m4 builtin, not a macro.  You
> >> must have managed to mangle the line endings of your sources when you
> >> brought them to that Mac.
> >
> > Do you mean gnuplot sources? I took them from CVS.
>
> Took them --- *how*?

cvs -z3 -d:pserver:ano...@gn...:/cvsroot/gnuplot
co -P gnuplot
But forget about that. It's finally working now - I have no idea where
the error came from and I don't care any more. Running only autoconf
doesn't seem the best thing to do anyway.

> > I installed it already, but the symbolic link was still pointing to
> > the wrong old version.
>
> Which symbolic link?  To switch between several versions of automake,
> you usually have to change a good deal more than one symlink.  It
> generally takes at least 2 or three, depending on how well they were
> prepared to run as alternatives.

"which automake" returns me /usr/bin/automake and:

/usr/bin/automake -> /etc/alternatives/automake
/etc/alternatives/automake -> /usr/bin/automake-1.9 (was 1.4a)

So I only fixed /etc/alternatives/automake and aclocal.

Is there some other way to switch the version? (sorry, I'm really not
expert in those things - I only use linux occasionally and this was
the first time when I played around with autoconf and automake)

> > Someone else has suggested me to use prepare instead of autoconf.
>
> ... You would have gotten that advice a lot sooner if you had told us
> exactly what you did.

I don't have much experience with compiling under linux/unix. There
was no configure script, so I ran "autoconf" (I only mentioned that
the process failed while running autoconf, I really didn't say that
that was the only thing I did since autoconf could have been called
from prepare script as well), but never mind the stupid question from
me.

Thanks,
    Mojca