Re: Namespacing and directories under libinterp/

[Daniel J Sebald]

On 06/01/2013 12:35 PM, Max Brister wrote:
> On Fri, May 31, 2013 at 1:26 PM, Jordi Gutiérrez Hermoso
> <address@hidden <mailto:address@hidden>> wrote:
>
>     On 31 May 2013 14:18, John W. Eaton <address@hidden
>     <mailto:address@hidden>> wrote:
>     >  This reminds me of how we caved in to the pressure from some
>     novice Octave
>     >  developers and rearranged the Octave source tree last year.  The
>     novices
>     >  thought the number of files in the liboctave and src directories was
>     >  intimidating.  And they assumed that it would be easier to see the
>     structure
>     >  of the sources if they were split up into more logical groups of
>     functions.
>     >  Since then, I've had nothing but trouble finding files. I don't
>     think the
>     >  extra directory levels in liboctave and libinterp really helped me
>     at all,
>     >  and they probably just make it more confusing for people -- WTF is the
>     >  difference between libinterp/corefcn and libinterp/interp-core?
>
>     I think those are the only two where the distinction isn't clear. Or
>     interpfcn.
>
>
> I agree here, I think the interpfcn and interp-core directories should
> be gotten rid of and their files moved back under libinterp directly.

We should probably note the distinction before moving forward on 
anything.  I didn't organize things, and I would agree that the naming 
similarities can lead to confusion which was discussed at the time.  In 
working with things, though, the groupings do seem to be of value.  For 
example, I know there are directories that I never venture in and in 
some sense that helps to eliminate a large hunk of code so one can 
concentrate on the code/bug at hand.

If I understand correctly, interp-core is code associated with the 
interpreter.  Fairly stable.  John noted a desire to have done a couple 
things differently or to remove something then resisted, but of all the 
bugs I've looked at I can't recall modifying anything with the code in 
interp-core (may have, just don't remember).  Do a "grep DEFUN 
libinterp/interp-core/*" and you'll note there are no built-in command 
functions there except:

libinterp/interp-core/pt-jit.cc:DEFUN (enable_jit_debugging, args, nargout,
libinterp/interp-core/pt-jit.cc:DEFUN (enable_jit_compiler, args, nargout,

On the other hand, try "grep DEFUN libinterp/interpfcn/*" and the result 
is all built-in command functions.  This is a common directory I'm 
working in when addressing some of the bugs that show up on Savannah.

I'm not quite sure what the distinction is for libinterp/corefcn, but it 
appears to be command functions that are pretty much a reflection of 
some existing library routine, such as math routines.  In other words, 
there isn't so much added code here as for the "interpfcn" category and 
consequently is probably pretty stable.

Having the "octave-value" directory is very nice, as I think of that as 
the main Octave container/data class.  It might make sense to move that 
directory under "liboctave", however, over alongside the "array" 
category.  Don't know.

Liking or not liking subdirectories sort of depends on one's approach to 
working on programs.  If one has limited knowledge about all of the 
code, at least for me, tools like "grep", "find" and tab-completion are 
king.  "grep is the word", so to speak--if one wants to find where some 
variable is or some task is done, grep is the fastest way of locating 
that.  Having subdirectories makes that easier because when every file 
is in one directory the results of grep can create a long list that is 
difficult to visually pick through.  If instead the output is a 
manageable list, it is easier to inspect surrounding code.

With the above in mind, I'd say there is one change I would like and 
that is to remove remnant "ChangeLog" files from the source tree, 
possibly in a hidden file or something that can't be searched. 
Sometimes when I grep for something there is a big list of entries from 
ChangLog files.

Of course, in Windows I'm not sure there is an equivalent to "grep", 
"find" and tab-complete.  In that case there is typically a project IDE 
that will do similar sorts of things.

Dan