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 21:30:49 -0700

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]