gnuplot-beta

16-bit versions of gnuplot doomed?

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

Hello, all,

I've got round to trying to build 16-bit binaries of gnuplot for DOS and
Windows and the news, so far, is bad.

Win16 (i.e. good old Windows 3.1 and Windows for Workgroups 3.11) kills
itself directly on startup.  I may be blowing the stack or something ---
investigating that is a nightmare without at least a Win9x machine.

DOS-16bit works, sort of.  But that's after I disabled most of the bit
optional features (filled boxes, PM3D) *and* removed pretty much all
terminal drivers besides dospc (the interactive graphics driver), table
and cgm.  Yes, that does mean I had to throw out post.trm ;-( The reason
post.trm had to go is the PS_header[] string array.  This is simply too
large, and the way it's constructed (array of many short strings) means
that Borland's compiler, which is otherwise quite clever at squeezing a
lot of code into those 640KB, fails to move the bulk of it into a separate
segment.  As is, term.obj with post.trm in it costs 26000 of the total of
64 precious kilobytes of "dgroup".  I won't give up on this quite yet,
though.

The other major challenge is graphics.c, and it affects both 16-bit
platforms: that module is plain and simply too large.  BCC chokes already
on compiling that source file because it contains more than 64KB of code.  
Maybe I'm overlooking some optimization (the 32-bit graphics.o on Linux
has only 52KB...), but for the time being, I decided to tentatively split
graphics.c into two files: I copied all the "steps" plotting style handler
(plot_{f,hi,}steps) and their helper functions to a separate source file
and #ifdef'ed out their implementations in graphics.c.  The new files
steps2d.[ch] currently contain copies of the relevant parts of
graphics.[ch], but those may be replaced by #include'ing graphics.c if I
put even more #ifdef's into the latter.

I will leave the CVS version free of these complications for now, until
the following question is settled: Is support for 16-bit machines (think:
old lab PCs, "poor pupils", under-developed countries...) important enough
to warrant changes as deep as these before the release?

I'll hands-up poll of any users of the 16-bit versions to the newsgroup to
get some additional feedback.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: 16-bit versions of gnuplot doomed?

[Lars H. <lhe...@us...>]

 
> I will leave the CVS version free of these complications for now, until
> the following question is settled: Is support for 16-bit machines (think:
> old lab PCs, "poor pupils", under-developed countries...) important enough
> to warrant changes as deep as these before the release?
> 
> I'll hands-up poll of any users of the 16-bit versions to the newsgroup to
> get some additional feedback.

 That would need to be done.

 I remember receiving email from a user (Nobel laureate in physics ...)
 a few years back, mentioning that he is using both DOS and Linux versions.

Re: 16-bit versions of gnuplot doomed?

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

On Wednesday 25 February 2004 01:03 am, Hans-Bernhard Broeker wrote:
> The new files steps2d.[ch] currently contain copies of the
> relevant parts of  graphics.[ch], but those may be replaced by
> #include'ing graphics.c if I  put even more #ifdef's into the latter.

That sounds ugly.  If it must be split, I hope we can make it a 
clean split.

> I will leave the CVS version free of these complications for now, until
> the following question is settled: Is support for 16-bit machines
> (think: old lab PCs, "poor pupils", under-developed countries...)
> important enough to warrant changes as deep as these before the release?

The goal of supporting old (cheap) machines is a laudable one.
But is it not sufficient to support these machines under linux?
It sounds like the problems you found are more an issue of the
inadequacies of Win3.1 than of the hardware per se.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center    (206)543-1421
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: 16-bit versions of gnuplot doomed?

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

Hans-Bernhard Broeker wrote:

>Hello, all,
>
>I've got round to trying to build 16-bit binaries of gnuplot for DOS and
>Windows and the news, so far, is bad.
>
>Win16 (i.e. good old Windows 3.1 and Windows for Workgroups 3.11) kills
>itself directly on startup.  I may be blowing the stack or something ---
>investigating that is a nightmare without at least a Win9x machine.
>
>DOS-16bit works, sort of.  But that's after I disabled most of the bit
>optional features (filled boxes, PM3D) *and* removed pretty much all
>terminal drivers besides dospc (the interactive graphics driver), table
>and cgm.  Yes, that does mean I had to throw out post.trm ;-( The reason
>post.trm had to go is the PS_header[] string array.  This is simply too
>large, and the way it's constructed (array of many short strings) means
>that Borland's compiler, which is otherwise quite clever at squeezing a
>lot of code into those 640KB, fails to move the bulk of it into a separate
>segment.  As is, term.obj with post.trm in it costs 26000 of the total of
>64 precious kilobytes of "dgroup".  I won't give up on this quite yet,
>though.
>
>The other major challenge is graphics.c, and it affects both 16-bit
>platforms: that module is plain and simply too large.  BCC chokes already
>on compiling that source file because it contains more than 64KB of code.  
>Maybe I'm overlooking some optimization (the 32-bit graphics.o on Linux
>has only 52KB...), but for the time being, I decided to tentatively split
>graphics.c into two files: I copied all the "steps" plotting style handler
>(plot_{f,hi,}steps) and their helper functions to a separate source file
>and #ifdef'ed out their implementations in graphics.c.  The new files
>steps2d.[ch] currently contain copies of the relevant parts of
>graphics.[ch], but those may be replaced by #include'ing graphics.c if I
>put even more #ifdef's into the latter.
>
>I will leave the CVS version free of these complications for now, until
>the following question is settled: Is support for 16-bit machines (think:
>old lab PCs, "poor pupils", under-developed countries...) important enough
>to warrant changes as deep as these before the release?
>
>I'll hands-up poll of any users of the 16-bit versions to the newsgroup to
>get some additional feedback.
>

I think "graphics.c" is the file I argued should be restructured because 
2D and 3D graphics seemed to be bifurcating.  (Ultimately, everything 
ends up being plotted in 2D.)  It should be just the core routines for 
graphics and then maybe a "graph2D.c" and "graph3D.c".  If a major 
change is made to graphics.c right now it will undoubtedly mess up some 
of the patches currently on SF.  Supporting 16-bit would probably be 
nice, but a conscious decision needs to be done on how to make that 
happen, i.e., how should software be organized, what features will be 
included.  That will be difficult to make work in the time span of 
making a release.  Maybe it would be best to not rock the 16-bit boat 
until 4.1.  That is, don't make an untested upgrade for 16-bit. 
 Otherwise the 16-bit world will upgrade and probably end up wrecking 
their current, workable set up.  I don't look back fondly on software 
upgrades in the 16-bit days.

Dan

Re: 16-bit versions of gnuplot doomed?

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

I propose to let gnuplot 3.7.3 to be the last one supporting 16bit machines.
This may change only if there is a strong feedback, as you say in your
posting. You could add this announcement to the new web page too, section
"Development".

On DOS 386 machine, people can use compiles by emx (or djgpp) -- anyway, I
haven't heard long time about any such compile, but as emx is used to
compile the OS/2 version, it should work too "in principle" (another
terminals).

Machines with 286 and Win3.1 -- obviously not the production machines of
today, but still can be used in labs for running experiments -- I guess
people are happy with gnuplot plotting nice curves as 3.7.3 does, with the
memory requirements gnuplot <3.7.3 has, and don't need those features for
which gnuplot 4.0 has been extended.

---
Petr Mikulik

PostScript prologue [was: 16-bit versions of gnuplot doomed?]

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

On Wednesday 25 February 2004 01:03 am, Hans-Bernhard Broeker wrote:
>
> DOS-16bit works, sort of.  But that's after I disabled most of the bit
> optional features (filled boxes, PM3D) *and* removed pretty much all
> terminal drivers besides dospc (the interactive graphics driver), table
> and cgm.  Yes, that does mean I had to throw out post.trm ;-( The reason
> post.trm had to go is the PS_header[] string array.  This is simply too
> large, ...

It occurs to me that we might use the approach of Adobe products
like FrameMaker.  The long PostScript prolog that is constant for
every output document is stored as a separate file in some appropriate
directory, and then copied into the output stream when a new 
document is being generated.

This has a number of advantages:

1) It doesn't take up any space in the source code module, which is
   what your DOS compiler doesn't handle well

2) It allows local customization of the prologue without having to
   recompile the main program. 
   This would allow customization of A4/letter page size, selection of colors,
   dash-dot styles, and alternate character encodings.

3) It is possible to have multiple, printer- or language- specific, prologues.

The only possible down-side I can think of at the moment is that this
separate prologue file might get lost if the installation process is botched.
But this shouldn't be any worse than having to correctly find the outboard
gnuplot_x11 driver, or the help file.





-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center    (206)543-1421
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: PostScript prologue [was: 16-bit versions of gnuplot doomed?]

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

Instead of forcing to compile gnuplot 4.0 under 16bit with crippled
functionality, what about to extend gnuplot 3.7.3 to 3.7.4 so that it
supports "unset blabla" and "set style xxx" instead of the previous?


> every output document is stored as a separate file in some appropriate
> directory, and then copied into the output stream when a new

I'm like this way -- people are used to have a single (or two)  executables
and will be happening that under crazy installations, they won't be able to
create postscript files, and thus cry a lot.

> 3) It is possible to have multiple, printer- or language- specific, prologues.

There could be a new option for the postscript driver to load such personal
prologues. But that's a new feature never needed until now.

> separate prologue file might get lost if the installation process is botched.
> But this shouldn't be any worse than having to correctly find the outboard
> gnuplot_x11 driver, or the help file.

Unixish people do mostly "make install", but all others (using "*.exe"
binaries) will definitely loose this file frequently.

---
Petr Mikulik