Menu
▾
▴
gnuplot-beta
|
From: Hans-Bernhard B. <br...@ph...> - 2004-05-09 20:27:05
|
On Sun, 9 May 2004, Petr Mikulik wrote: > Hmm on "unix" .. "make install" does not install demos, so there is not > "properly" installed unix. As far as I'm aware, none of our makefiles installs the demos anywhere. Nor did any of them, ever. > Using a rpm package for gnuplot ... turns you to demos for an old > gnuplot. Huh? That only applies if you look at an old, now outdated RPM, obviously. There'll be only *one* binary RPM of gnuplot installed in any given box. So far, that'll be the one of 3.7.3 made by the distributor, so yes, it will have the old version of the demos. > => ordinary people (who do just "make install" have no demos avaible). > INSTALL writes ./configure does not want to decide where to put demos -- > why not? INSTALL says so, and it's written in there for said "ordinary people" to see. So they'll know there are demos they may want to install, at a place of their choosing. We can't do anything to help people who won't read README and INSTALL files, and there's really no point trying. > /usr/local/share/gnuplot/... gnuplot is already writing there, why not use > it for demo? That would be the right place for them to go for a non-RPM local installation from sources. I.e. if we make a "install-demos" target, or have the default 'install' put them up anywhere, $(pkgdatadir)/demo is where that'll be. But it's not the place the existing binary packages made by third parties put them. SuSE Linux, e.g., puts such files below /usr/share/docs/packages/<name>, not /usr/share/<package>, and they may prefer to keep it that way. But since there's no /usr/local/share/docs/packages in a Linux system, we can't easily duplicate that, and probably we shouldn't. And remember that as soon as we put a pointer to the locally installed copy of the demos into the online help, odds are distributors will manage to break it. But it'll likely be us who get the complaints about it. > BTW, "make install" installs big unstriped binaries, even for the final > gnuplot 4.0.0. It's not polite for harddisks of our users. I hope no other > app do that! > Who knows about "make install-strip", and who actually use it? Those people who care, know. Those who build RPMs at distributors included. OTOH, HD space is less than 0.01 USD or EUR per MB these days... It might make sense to mention install-strip in the INSTALL document. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-05-10 12:02:37
|
On Sun, 9 May 2004, Daniel J Sebald wrote: > I think the additional method requiring installing demos isn't so bad. > That is, a separate "make install-demos" which would require some > interaction (i.e., specifying the exact directory, the "make > install-demos" would automagically define GNUPLOT_LIB and add the demo > directory to it) But 'make install' can't do that. Modifying the user's environment variables is way out of scope of a simple program installation. The best you could do would be to display a comment as part of running 'make install' that reminds the user this should be done. Or make that note part of 'help demo' (to be written). > would be something only run by the distributors. Distributors already install the demos, generally. They're not really the parties we're worried about here. That'd rather be the persons building and installing gnuplot from sources. > >It might make sense to mention install-strip in the INSTALL document. > > > > I assume that non-stripped is the default because developers want to do > debugging? Not quite --- we would have the sources and a non-installed, un-stripped binary for that. The original reasoning goes back to Mr. Stallman himself, who insists on having at least minimal debugging capabilities in installed programs. I.e. if a user reports a strange problem, on hardware we have no access to ourselves, the default un-stripped installation allows us to walk him through a debugger session and show us a backtrace. It's all written down somewhere in the GNU Coding Standards, I think. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-05-10 12:29:40
|
On Mon, 10 May 2004, Petr Mikulik wrote: > Are you sure? I have two. > > $ rpm -q gnuplot > gnuplot-3.7.3-106 > gnuplot-4.0.0-1 > The former by SUSE, the other by > checkinstall make install-strip Well, suffice it to say that if you make a less complete RPM than SuSE, the blame for that is entirely yours. > No, they don't know, and no, they won't read it -- or stop reading before > "how to install demos". I strictly refuse to worry about people who don't read READMEs and follow instructions contained in them. If they don't bother, neither will I. > Look at other software packages -- their "make install" installs more docs, > faqs, demos. Why should gnuplot not do this? > ./configure --prefix=$HOME/usr > > Now I want all goes into a useful directory there. Why not > > $HOME/usr/share/doc/gnuplot-4.0.0/ Because it would break things for distributors, who want to build and install using '--prefix=/usr' and have the demos and other docs under /usr/share/doc/packages/gnuplot, not under /usr/share/doc/gnuplot-4.0.0 I.e. we should leave the $(prefix)/share/doc directory alone. If at all, it'ld have to be either $(prefix)/share/gnuplot/4.0 or $(prefix)/share/gnuplot-4.0 I would prefer the former, because it's more in parallel with our installation directory for gnuplot_x11, $(exec_prefix)/libexec/gnuplot/4.0/ > > copy of the demos into the online help, odds are distributors will manage > > to break it. But it'll likely be us who get the complaints about it. > > Don't put the exact pointer, but say "see gnuplot doc installed on your > system". Somehow I'm not convinced that this phrase would help to reduce the number of questions about where they might be... > If every application of those 1466 wastes 700 KB as gnuplot, it is 1 GB of > wasted HD. That's not negligable. *If*. But they don't, and they shouldn't. There is a difference between a distributor-built, supported RPM (or DEB) package, and locally built and installed programs, see. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Petr M. <mi...@ph...> - 2004-05-10 14:34:17
|
> > $ rpm -q gnuplot > > gnuplot-3.7.3-106 > > gnuplot-4.0.0-1 > > > > The former by SUSE, the other by > > checkinstall make install-strip > > Well, suffice it to say that if you make a less complete RPM than SuSE, > the blame for that is entirely yours. I don't do RPM for distribution; I do it for myself to be able to uninstall the package easily, from my own system. That's "checkinstall" good for. Forget RPM and consider it as "make install" with a later possibility of "make uninstall". > > Now I want all goes into a useful directory there. Why not > > > > $HOME/usr/share/doc/gnuplot-4.0.0/ > > Because it would break things for distributors, who want to build and > install using '--prefix=/usr' and have the demos and other docs under > /usr/share/doc/packages/gnuplot, not under /usr/share/doc/gnuplot-4.0.0 Distributors can put stuff where they want. Here, we speak about making/instaling current gnuplot for yourself, not how distributors should make their RPM. Moreover, on a experimental workstation with HPUX, there is no RPM distributor. > I.e. we should leave the $(prefix)/share/doc directory alone. If at all, > it'ld have to be either > > $(prefix)/share/gnuplot/4.0 > or $(prefix)/share/gnuplot-4.0 > > I would prefer the former, because it's more in parallel with our > installation directory for gnuplot_x11, > $(exec_prefix)/libexec/gnuplot/4.0/ If someone makes such a Makefile target to be close to gnuplot 4.0.0 binaries zips for OS/2 or Windows, that'll be great. --- PM |
|
From: Daniel J S. <dan...@ie...> - 2004-05-09 22:57:43
|
Hans-Bernhard Broeker wrote: >On Sun, 9 May 2004, Petr Mikulik wrote: > > >>=> ordinary people (who do just "make install" have no demos avaible). >> >> > > > >>INSTALL writes ./configure does not want to decide where to put demos -- >>why not? >> >> > >INSTALL says so, and it's written in there for said "ordinary people" to >see. So they'll know there are demos they may want to install, at a place >of their choosing. > >We can't do anything to help people who won't read README and INSTALL >files, and there's really no point trying. > >>/usr/local/share/gnuplot/... gnuplot is already writing there, why not use >>it for demo? >> >> > >That would be the right place for them to go for a non-RPM local >installation from sources. I.e. if we make a "install-demos" target, or >have the default 'install' put them up anywhere, $(pkgdatadir)/demo is >where that'll be. > >But it's not the place the existing binary packages made by third parties >put them. SuSE Linux, e.g., puts such files below >/usr/share/docs/packages/<name>, not /usr/share/<package>, and they may >prefer to keep it that way. But since there's no >/usr/local/share/docs/packages in a Linux system, we can't easily >duplicate that, and probably we shouldn't. > >And remember that as soon as we put a pointer to the locally installed >copy of the demos into the online help, odds are distributors will manage >to break it. But it'll likely be us who get the complaints about it. > I was going to say that the distributor/packager or whatever can move them to where ever they want. But point taken. I think the additional method requiring installing demos isn't so bad. That is, a separate "make install-demos" which would require some interaction (i.e., specifying the exact directory, the "make install-demos" would automagically define GNUPLOT_LIB and add the demo directory to it) would be something only run by the distributors. The, eh-hem, "non informed people" could then still type "make, make install" and hope for the best, i.e., watch the pretty glowing characters wiz by. Then at the very end of the "make install" after the message indicating everything is hunky-dory, there could be a message noting the existence of demo scripts that can be installed. Well, in any case, if a message in the INSTALL file were to do, perhaps add a GNUPLOT_LIB comment. The gnuplot demo files are not installed by default, mainly because there is no universally agreed place where such files should go. If desired, they should be copied manually to a location of choice. (add this) Including the chosen demo directory in the global variable path GNUPLOT_LIB (see below) will allow easy access for all users to the demo script files. >>BTW, "make install" installs big unstriped binaries, even for the final >>gnuplot 4.0.0. It's not polite for harddisks of our users. I hope no other >>app do that! >> Who knows about "make install-strip", and who actually use it? >> >> > >Those people who care, know. Those who build RPMs at distributors >included. OTOH, HD space is less than 0.01 USD or EUR per MB these >days... > Well, that kind of thinking only promotes sloppy computer usage... like putting an extraneously high resolution image on a web site. I will use "install-strip" from now on if I remember. >It might make sense to mention install-strip in the INSTALL document. > I assume that non-stripped is the default because developers want to do debugging? And they don't want to have to be constantly typing the "make install-debug" or something similar. How about a global variable for controlling this? That is, install-stripped: same as current "install-stripped" behavior install-debug: same as current "install" behavior install: Include debugging information according to a global variable GNUPLOT_DEBUG; i.e., defined then include debug info, if not (default) then don't include debug info. For developers, define GNUPLOT_DEBUG once and that is it. Dan |
|
From: Ethan A M. <merritt@u.washington.edu> - 2004-05-09 23:05:04
|
On Sunday 09 May 2004 04:19 pm, Daniel J Sebald wrote: > >> Who knows about "make install-strip", and who actually use it? > > > >OTOH, HD space is less than 0.01 USD or EUR per MB these days... > > Well, that kind of thinking only promotes sloppy computer usage... like > putting an extraneously high resolution image on a web site. My $.02 worth: I dislike having stripped executables, because if something goes wrong you get essentially zero information to help you report or fix the problem. The small increase in disk space is a minor price to pay for having debuggable programs. Anyone who want to run 'make install-strip' is free to do so, of course, but I would not like to see it made the default. -- Ethan A Merritt Department of Biochemistry & Biomolecular Structure Center University of Washington, Seattle |
|
From: Allin C. <cot...@wf...> - 2004-05-10 02:18:14
|
I wonder if anyone has experimented with an audio driver of any sort for gnuplot? I ask because I face the interesting challenge, this coming Fall, of teaching a data analysis class that will include a blind student. Allin Cottrell |
|
From: Daniel J S. <dan...@ie...> - 2004-05-10 05:58:42
|
Allin Cottrell wrote: >I wonder if anyone has experimented with an audio driver of any sort >for gnuplot? > >I ask because I face the interesting challenge, this coming Fall, of >teaching a data analysis class that will include a blind student. > >Allin Cottrell > Something I've never thought of, but interesting idea. Are you thinking of combining plotted waveforms with a capability to listen to them, as in a speech processing scenario? Of course, the problem is the long running history of PC's and various systems not having a standard audio interface. Perhaps that has changed in the recent past, but judging from the last time I went though buying a computer it didn't seem like it. Dan |
|
From: Daniel J S. <dan...@ie...> - 2004-05-10 06:43:55
|
Allin Cottrell wrote:
>I wonder if anyone has experimented with an audio driver of any sort
>for gnuplot?
>
>I ask because I face the interesting challenge, this coming Fall, of
>teaching a data analysis class that will include a blind student.
>
>Allin Cottrell
>
There are the Octave audio functions. However, the documentation on a
few of them is what I suspected (end of first paragraph below). A
fairly standard audio card might (might!) work with the existing Octave
version. Recording properly is probably more unlikely.
=====
The following functions for audio I/O require special A/D hardware
and operating system support. It is assumed that audio data in linear
encoding can be played and recorded by reading from and writing to
`/dev/dsp', and that similarly `/dev/audio' is used for mu-law
encoding. These file names are system-dependent. Improvements so that
these functions will work without modification on a wide variety of
hardware are welcome.
- Function File: playaudio (NAME, EXT)
- Function File: playaudio (X)
Plays the audio file `NAME.EXT' or the audio data stored in the
vector X.
- Function File: record (SEC, SAMPLING_RATE)
Records SEC seconds of audio input into the vector X. The default
value for SAMPLING_RATE is 8000 samples per second, or 8kHz. The
program waits until the user types <RET> and then immediately
starts to record.
- Function File: setaudio ([W_TYPE [, VALUE]])
executes the shell command `mixer [W_TYPE [, VALUE]]'
|
|
From: Petr M. <mi...@ph...> - 2004-05-10 10:00:51
|
> I dislike having stripped executables, because if something goes > wrong you get essentially zero information to help you report or > fix the problem. The small increase in disk space is a minor price > to pay for having debuggable programs. I don't remember very much of such information being posted regularly on the gnuplot mailing/news lists. It is OK for developers, but for regular users, not (especially for final release). -- PM |
|
From: Petr M. <mi...@ph...> - 2004-05-10 09:58:51
|
> > Hmm on "unix" .. "make install" does not install demos, so there is not
> > "properly" installed unix.
>
> As far as I'm aware, none of our makefiles installs the demos anywhere.
> Nor did any of them, ever.
Yes, and that's what I always complain about: there is no "make install all"
that would do automatically such an install as I packaged for OS/2 and
Windows packages -- ie including all docs, demos, INSTALL and README files.
> > Using a rpm package for gnuplot ... turns you to demos for an old
> > gnuplot.
>
> Huh? That only applies if you look at an old, now outdated RPM, obviously.
> There'll be only *one* binary RPM of gnuplot installed in any given box.
Are you sure? I have two.
$ rpm -q gnuplot
gnuplot-3.7.3-106
gnuplot-4.0.0-1
The former by SUSE, the other by
checkinstall make install-strip
Of course, gnuplot's own "make install-strip" sucks for the above reasons
(no docs, no demos, no FAQ, ...).
> > INSTALL writes ./configure does not want to decide where to put demos --
> > why not?
>
> INSTALL says so, and it's written in there for said "ordinary people" to
> see. So they'll know there are demos they may want to install, at a place
> of their choosing.
No, they don't know, and no, they won't read it -- or stop reading before
"how to install demos".
I don't understand why you don't want to support ordinary people who wish to
do
make install
and have installed really everything what gnuplot offers.
Look at other software packages -- their "make install" installs more docs,
faqs, demos. Why should gnuplot not do this?
Actually -- if we don't let install all, we have more troubles answering
FAQs...
> > /usr/local/share/gnuplot/... gnuplot is already writing there, why not use
> > it for demo?
>
> That would be the right place for them to go for a non-RPM local
> installation from sources. I.e. if we make a "install-demos" target, or
> have the default 'install' put them up anywhere, $(pkgdatadir)/demo is
> where that'll be.
>
> But it's not the place the existing binary packages made by third parties
> put them. SuSE Linux, e.g., puts such files below
> /usr/share/docs/packages/<name>, not /usr/share/<package>, and they may
> prefer to keep it that way. But since there's no
> /usr/local/share/docs/packages in a Linux system, we can't easily
> duplicate that, and probably we shouldn't.
Look this way: I want to install new gnuplot for me and just me, on a unix
box. Thus I do:
./configure --prefix=$HOME/usr
Now I want all goes into a useful directory there. Why not
$HOME/usr/share/doc/gnuplot-4.0.0/
and thus:
$HOME/usr/share/doc/gnuplot-4.0.0/ with gnuplot.pdf, ...
$HOME/usr/share/doc/gnuplot-4.0.0/psdocs
$HOME/usr/share/doc/gnuplot-4.0.0/demo
Similarly,
./configure --prefix=/usr/local
would do
$HOME/usr/share/doc/gnuplot-4.0.0/ with gnuplot.pdf, tutorial.pdf,
gpcard.pdf, FAQ
$HOME/usr/share/doc/gnuplot-4.0.0/psdocs
$HOME/usr/share/doc/gnuplot-4.0.0/demo
What about accepting this scheme?
> And remember that as soon as we put a pointer to the locally installed
> copy of the demos into the online help, odds are distributors will manage
> to break it. But it'll likely be us who get the complaints about it.
Don't put the exact pointer, but say "see gnuplot doc installed on your
system".
> Those people who care, know. Those who build RPMs at distributors
> included.
$ rpm -qa | wc -l
1464
If every application of those 1466 wastes 700 KB as gnuplot, it is 1 GB of
wasted HD. That's not negligable.
> OTOH, HD space is less than 0.01 USD or EUR per MB these days...
But:
1. You cannot easily change hard disk in your notebook.
2. You cannot change/add hard disk in computer of your company.
3. You cannot add new hard disk for whichever other hardware reason.
---
PM
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X