From: Teemu I. <tpi...@pc...> - 2003-08-08 15:53:27
|
Hi everyone, I've made a set of functions which replace the standard gnuplot based 2d plotting commands by similar functions using Grace (http://plasma-gate.weizmann.ac.il/Grace/). They're available in http://www.physics.helsinki.fi/~tpikonen/octave/grplot-2003.08.08.tgz I'd like to contribute these to octave-forge, but as the functions have same names as their gnuplot counterparts in standard Octave, normal octave-forge installation would cause these functions to override the defaults. Of course, this is probably not what most people installing octave-forge would want. The octave-plplot package (available in Debian, at least) avoids this problem by installing it's m-files to a location which is not in the default LOADPATH (/usr/share/plplot_octave to be exact) and then modifying the LOADPATH to include or not to include this path via a script (toggle_plplot_use). I've implemented (i.e. copied) a similar thing in my Grace package, but I'm not sure where should I upload the files in octave-forge. Maybe a new directory hierachy like main/alternatives is needed? Directories which are found there could then be installed in something like $prefix/share/octave-forge-alternatives Comments? Teemu |
From: Teemu I. <tpi...@pc...> - 2003-08-26 04:01:31
|
On 08/08/03 18:50, Teemu Ikonen wrote: > Maybe a new > directory hierachy like main/alternatives is needed? Directories which are > found there could then be installed in something like > $prefix/share/octave-forge-alternatives I've committed my grace plotting code to extra/graceplot and modified the Makefiles and configure scripts to install the overlapping m-files to /usr/share/octave/2.1.50/site/octave-forge-alternatives/m/graceplot The modifications I made to the installation scripts are general, so that any m-files in directory extra/<package>/alternatives are installed to /usr/share/octave/<version>/site/octave-forge-alternatives/m/<package> and oct-files to /usr/lib/octave/<version>/site/octave-forge-alternatives/oct/<arch>/<package> In a local installation the alternative files go to $path-alternatives/m (and $path-alternatives/oct) where $path is provided by --with-path parameter to configure. It's up to the package to provide scripts to shuffle the loadpath so that the functions are actually visible, the graceplot package contains an example on how to do this. Any comments or suggestions are welcome. Teemu |
From: Rafael L. <ra...@de...> - 2003-08-26 14:19:15
|
* Teemu Ikonen <tpi...@pc...> [2003-08-25 18:41]: > I've committed my grace plotting code to extra/graceplot and modified the > Makefiles and configure scripts to install the overlapping m-files to Great, it works fine for me. What about creating a wrapper like this: function grace_command (str) __grcmd__ (str); __grcmd__ ("redraw"); endfunction At any rate, it is nice to be able to control nearly all aspects of the graph directly from Octave scripts. -- Rafael |
From: Per P. <per...@ma...> - 2003-09-04 20:28:32
|
Hi, I'm having a small (possibly two) problem(s) with target grace_octave_path.m in graceplot/Makefile on OS X. grace_octave_path.m: grace_octave_path.m.in cat grace_octave_path.m.in | sed -e "s:@ALTMPATH@:$(ALTMPATH)/$(GRDESTDIR):" > grace_octave_path.m In the file grace_octave_path.m @ALTMPATH@ comes out as "/" as if $(ALTMPATH) and $(GRDESTDIR) would evaluate to an empty string in the sed command. A little fiddling gives the following: 1) % cat extra/graceplot/grace_octave_path.m.in | sed -e "s:@ALTMPATH@:$(ALTMPATH)/$(GRDESTDIR):" Illegal variable name. 2) % cat extra/graceplot/grace_octave_path.m.in | sed -e "s:@ALTMPATH@:$ALTMPATH/$GRDESTDIR:" Bad : modifier in $ ("). 3) % cat extra/graceplot/grace_octave_path.m.in | sed -e "s.@ALTMPATH@.$ALTMPATH/$GRDESTDIR." (Works as intended) So, it seems that (1) sed dissaproves of $(VARNAME) (2) sed dissaproves : as delimiter (since ':' was the path delimiter in OS 4 through 9, OS X sometimes has funny interpretations of : and / when used together) (3) works fine on OS X, don't know if it is acceptable elsewhere. FWIW, sed -e "s/@ALTMPATH@/$ALTMPATH\/$GRDESTDIR/" also works. My knowledge of sed et al. is limited, so this is about as much info as I can provide on the problem. /Per On Monday, August 25, 2003, at 05:41 PM, Teemu Ikonen wrote: > > It's up to the package to provide scripts to shuffle the loadpath so > that > the functions are actually visible, the graceplot package contains an > example on how to do this. > > Any comments or suggestions are welcome. > > Teemu ------------ Per Persson Blekinge Institute of Technology Dept. of Signal Processing and Telecommunications www: http://www.its.bth.se/staff/pee e-mail: per...@bt... |
From: Per P. <per...@ma...> - 2003-09-04 20:58:21
|
Just disregard my previous mail. Everything works fine, except the pilot... $(ALTMPATH) and $(GRDESTDIR) and were indeed empty strings, and rightly so. for i=1:100 printf("I will henceforth remember to rebuild configure after updating from CVS\n"); endfor /Per On Thursday, September 4, 2003, at 10:27 PM, Per Persson wrote: > Hi, > I'm having a small (possibly two) problem(s) with target > grace_octave_path.m in graceplot/Makefile on OS X. > > grace_octave_path.m: grace_octave_path.m.in > cat grace_octave_path.m.in | sed -e > "s:@ALTMPATH@:$(ALTMPATH)/$(GRDESTDIR):" > grace_octave_path.m > > In the file grace_octave_path.m @ALTMPATH@ comes out as "/" as if > $(ALTMPATH) and $(GRDESTDIR) would evaluate to an empty string in the > sed command. > |
From: <pki...@us...> - 2003-08-27 10:02:00
|
On 25 Aug 2003 at 18:41, Teemu Ikonen wrote: > The modifications I made to the installation scripts are general, so that > any m-files in directory extra/<package>/alternatives are installed to > /usr/share/octave/<version>/site/octave-forge-alternatives/m/<package> > and oct-files to > /usr/lib/octave/<version>/site/octave-forge-alternatives/oct/<arch>/<package> So for example, Alois could put a select few of his NaN toolbox functions into alternatives (those that treat NaN as NA) and the NaN toolbox could then be installed by default? Sounds great! I'm surprised, though, that all the site package tree is not on the default load path. - Paul |