[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Namespacing and directories under libinterp/
From: |
Daniel J Sebald |
Subject: |
Re: Namespacing and directories under libinterp/ |
Date: |
Sat, 01 Jun 2013 13:42:06 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
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