Re: "gnuplot development" page on the revised SourceForge layout

[Hans-Bernhard B. <br...@ph...>]

Ethan A Merritt wrote:
> Any chance that one of you can clean up some of the
> dubious listing on the "gnuplot development" page?

Clark did some, now I did some more.

Most importantly, I removed the bogus entries claiming our license were 
GPL or LGPL.

> The existence of a 3.8k snapshot is hardly breaking
> news, and should not be highlighted at the top left.

Clark apparently just deleted that entry...  But keep in in mind that 
it's not SF's fault if we produce so few news that completely outdated 
news still hasn't dropped below their radar?

> This seems misleading to me.  There is no
> 32-bit restriction in the code, 

No intentional one, sure.  But as a matter of fact the 16-bit builds 
haven't worked for quite a while now --- the last time I managed to 
squeeze gnuplot in that small box was for release 3.7.3.  I tried to do 
something about that in the run-up period to the 4.0 release, but 
eventually had to give up when it became clear that the necessary 
changes were too big to contemplate that shortly before a release.  I 
even held a little poll in the newsgroup to find out if anyone cared --- 
looked like nobody did, so we abandoned that.

As it is right now, a 16-bit gnuplot doesn't build even with *all*
terminal drivers disabled.  The break-neck problem is that graphics.c 
alone now contains more than 64K of code.  I managed to produce a build 
only by effectively breaking graphics.c in two and applying the 
'outboard postscript includes' patch.  It still crashes rather lot, 
though, and I don't think it is worthwile tracking those down ;-(

> and the focus is not on MS Windows no matter how you look at it.

Ours isn't, but if you look at what the users have "voted with their 
feet", their message is quite clear:  The win32 binary packages have 
seen about as many downloads as the source and all other binary packages 
combined.

 > I'd opt to list only "OS portable".

I added a more-or-less comprehensive list of all our supported 
platforms.  Since the list is now much longer, the perceived focus on 
Win32 should now be less pronounced.  We can't do anything about Win32 
being listed before "portable", though --- well, not without pestering 
SF staff about it.