octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: merging functions from octave-forge


From: Keith Goodman
Subject: Re: merging functions from octave-forge
Date: Mon, 6 Jun 2005 22:03:19 -0700

I'd also put the save paths at the end of octaverc instead of at the
beginning. If you save a path and then later delete a directory in the
saved path, addpath will produce an error the next time you start
Octave and exit octaverc before executing the other commands in the
startup file. Maybe be double safe (since you're changing someone's
octaverc file) by adding try catch.

On 6/6/05, Keith Goodman <address@hidden> wrote:
> Wow. Dreams do come true.
> 
> I found a couple of problems.
> 
> If "savefile"  doesn't exist  (e.g., I use your hard-coded path to
> your octaverc file, or make one up) savepath crashes. That's because
> there is a "if (exist(savefile) == 2)" but not an else.
> 
> Also I am unable to pass in a name of a file to save the path to.
> That's because in
> 
> (iscellstr(varargin)) && (size(varargin{1}) == prod(size(varargin{1})))
> 
> size varargin{1} is [1 19] for something like "/home/kwg/.octaverc"
> which is not equal to prod(size).
> 
> 
> On 6/6/05, Bill Denney <address@hidden> wrote:
> > On Mon, 6 Jun 2005, Keith Goodman wrote:
> >
> > > addpath and rmpath are very useful. I use them all the time.
> > >
> > > While going back and forth between Octave and bash to port some Matlab
> > > code, I've found that the usefulness of addpath and rmpath is
> > > temporary---once you exit Octave you lose the path changes.
> > >
> > > To keep the path after you exit Octave we need savepath. Maybe the
> > > default storage place could be ~/.octavepathdef, which would be an
> > > ascii file that people can edit by hand if they want.
> > >
> > > Should the path definition be read before or after ~/.octaverc? If it
> > > is THE path, then after.
> >
> > I just hacked together the functionality of matlab's savepath command
> > using the LOADPATH.  It depends on two octave-forge functions: addpath and
> > strtok.  It will save the path to the user's .octaverc (though this is
> > actually the only bug that I don't know how to fix-- I couldn't figure out
> > how to make it go to the user's .octaverc, so it is currently hard-wired
> > for mine).  It will save over itself, and leave the rest of the file
> > untouched.
> >
> > While working on this, I noticed a bug in addpath-- it will add a path
> > that's already in the path (this could be by design, so I won't fix it
> > now, but it seems like a flaw to me).  It seems like the correct behavior
> > should be to add the path to the required part of the path and delete it
> > from the other part of the path as so:
> >
> > LOADPATH = a/:b/:c/
> > addpath('b/')
> > LOADPATH = b/:a/:c/
> >
> > Another possible bug that I found is that the reverse function returns a
> > variable of class list instead of whatever is passed to it (I tried to
> > pass a cell vector into it, and I couldn't contatenate it with other
> > cells).  This can be replicated as follows:
> >
> > [{'a'} reverse({'c' 'b'}) {'d'}]
> > error: concatenation operator not implemented for `cell' by `list'
> > operations
> >
> > where I expected to get an answer equivalent to
> >
> > ans =
> >
> > {
> >    [1,1] = a
> >    [1,2] = b
> >    [1,3] = c
> >    [1,4] = d
> > }
> >
> > The bugs are with OCTAVE_VERSION = 2.1.69 and OCTAVE_FORGE_VERSION =
> > 20041116
> >
> > Bill
> >
> > --
> > "Canada? Why should we leave America to visit America Junior?"
> >    -- Homer Simpson
> >
> >
> >
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]