Re: private functions in the core Octave distribution

[Jaroslav Hajek]

On Wed, Dec 2, 2009 at 11:16 AM, John W. Eaton <address@hidden> wrote:
> On  2-Dec-2009, Jaroslav Hajek wrote:
>
> | OK, I see the problem. Still, I think there should be just a warning,
> | not an error.
> | This problem only happens because you have ./q.m and the "." directory
> | always stays at top of path. If the other q.m will be somewhere else
> | in the path and you prepend d1/private (which is the default), the
> | functions will still be able to correctly call each other. It only
> | works for one directory, but that is usually enough for debugging.
>
> For debugging, can't you just cd to the private directory?

That's also possible, but it can be problematic if my working
directory contains some other working scripts or datafiles.

For illustration: Let's say I'm testing fsolve on a function myfunc.m
in the working directory, and I want to check whether the
finite-difference jacobian is being computed correctly.
So I do
addpath ("scripts/optimization/private")
__fdjac__ (@myfunc, x)
rmpath ("scripts/optimization/private")

but if I just cd into the directory, @myfunc won't work.

> Or just
> call the function that uses the private function you are debugging?

Yes, of course I *can* work the restriction around. I'm just pointing
out that the restricted action may be potentially useful.

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz