Better name for cruft directory

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Better name for cruft directory

Rik-4
All,

In liboctave/ there is the directory cruft/ which contains a library of
Fortran code.  In the spirit of meaningful variable names, can we rename
this to something better?  I'm open to suggestions.  One idea is libfortran
since the code is compiled into a convenience library by autotools just as
libinterp, liboctave, and libgui are.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Better name for cruft directory

Daniel Sebald
On 04/21/2017 09:59 PM, Rik wrote:
> All,
>
> In liboctave/ there is the directory cruft/ which contains a library of
> Fortran code.  In the spirit of meaningful variable names, can we rename
> this to something better?  I'm open to suggestions.  One idea is libfortran
> since the code is compiled into a convenience library by autotools just as
> libinterp, liboctave, and libgui are.
>
> --Rik

The following directories have non-Fortran code:

Faddeeva
--------
Some C++ code (actually may be C code that can be compiled as either)
related to only erf() functions.  It has a fairly recent copyright of
2012, so I assume it must be used in some way, as fallback code or
something.  Could this go in some other directory?  I know there has
been a lot of development around erf so maybe there is a more logical place.

Misc
----
quit.cc,quit.h: Is Octave code, very short.  Seems an odd place for
quit-related code to be since there is probably a lot of start/quit code
elsewhere.

cquit.c: Again, Octave code, very short.  Could probably combine quit.cc
and cquit.c into one file in some way.

lo-error.c,lo-error.h: Here's a comment written in this files: /* Having
this file in this directory is a kluge to avoid unresolved symbol errors
when creating shared versions of libcruft. */

f77-fcn.c,f77-fcn.h,blaswrap.c,f77-extern.cc: C code but it's purpose is
to accommodate Fortran.

Moving Faddeeva directory, misc/quit.cc, misc/quit.h, misc/cquit.c,
misc/lo-error.c, and misc/lo-error.h would make everything in the
liboctave/cruft directory Fortran related, and mostly math related
(directory name "fortmath" perhaps?).

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Better name for cruft directory

Daniel Sebald
On 04/21/2017 10:34 PM, Daniel J Sebald wrote:
> On 04/21/2017 09:59 PM, Rik wrote:
[snip]
> Moving Faddeeva directory, misc/quit.cc, misc/quit.h, misc/cquit.c,
> misc/lo-error.c, and misc/lo-error.h would make everything in the
> liboctave/cruft directory Fortran related, and mostly math related
> (directory name "fortmath" perhaps?).

Or better, "liboctave/f77math".

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Better name for cruft directory

John W. Eaton
Administrator
In reply to this post by Daniel Sebald
On 04/21/2017 11:34 PM, Daniel J Sebald wrote:

> Faddeeva
> --------
> Some C++ code (actually may be C code that can be compiled as either)
> related to only erf() functions.  It has a fairly recent copyright of
> 2012, so I assume it must be used in some way, as fallback code or
> something.  Could this go in some other directory?  I know there has
> been a lot of development around erf so maybe there is a more logical
> place.

Like most of the other code in cruft, this is code that is maintained
(or not) separately from Octave but for which there is no package
available in any Linux distribution that I know of, so we include a copy
in the Octave sources.  So I'd like to keep files like this separate
from the rest of the Octave sources rather than dumping it in with other
Octave source code.

> Misc
> ----
> quit.cc,quit.h: Is Octave code, very short.  Seems an odd place for
> quit-related code to be since there is probably a lot of start/quit code
> elsewhere.

These need to be in liboctave (previously, in libcruft) because they
need to be available for all of Octave, not just libinterp.  When
libcruft was a separate library from liboctave, this location made more
sense.

> cquit.c: Again, Octave code, very short.  Could probably combine quit.cc
> and cquit.c into one file in some way.

Maybe, but the reason it is separate is so that it will be compiled with
a C compiler, not a C++ compiler, in order to avoid warnings.

I moved the files in liboctave/cruft/misc to liboctave/util in this
changeset:

   http://hg.savannah.gnu.org/hgweb/octave/rev/58d56f52d50a

For the rest, how about just renaming liboctave/cruft to be
liboctave/external?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Better name for cruft directory

Rik-4
On 04/22/2017 05:59 AM, John W. Eaton wrote:

> On 04/21/2017 11:34 PM, Daniel J Sebald wrote:
>
>> Faddeeva
>> --------
>> Some C++ code (actually may be C code that can be compiled as either)
>> related to only erf() functions.  It has a fairly recent copyright of
>> 2012, so I assume it must be used in some way, as fallback code or
>> something.  Could this go in some other directory?  I know there has
>> been a lot of development around erf so maybe there is a more logical
>> place.
>
> Like most of the other code in cruft, this is code that is maintained (or
> not) separately from Octave but for which there is no package available
> in any Linux distribution that I know of, so we include a copy in the
> Octave sources.  So I'd like to keep files like this separate from the
> rest of the Octave sources rather than dumping it in with other Octave
> source code.
>
>> Misc
>> ----
>> quit.cc,quit.h: Is Octave code, very short.  Seems an odd place for
>> quit-related code to be since there is probably a lot of start/quit code
>> elsewhere.
>
> These need to be in liboctave (previously, in libcruft) because they need
> to be available for all of Octave, not just libinterp.  When libcruft was
> a separate library from liboctave, this location made more sense.
>
>> cquit.c: Again, Octave code, very short.  Could probably combine quit.cc
>> and cquit.c into one file in some way.
>
> Maybe, but the reason it is separate is so that it will be compiled with
> a C compiler, not a C++ compiler, in order to avoid warnings.
>
> I moved the files in liboctave/cruft/misc to liboctave/util in this
> changeset:
>
>   http://hg.savannah.gnu.org/hgweb/octave/rev/58d56f52d50a
>
> For the rest, how about just renaming liboctave/cruft to be
> liboctave/external?

That would work for me.

My only slight concern is that it will be confused with the External Code
Interface documented in Appendix A.  But, if you are mucking about in
liboctave you probably already understand a lot about the code base.

--Rik


Reply | Threaded
Open this post in threaded view
|

Re: Better name for cruft directory

Carnë Draug
On 22 April 2017 at 15:01, Rik <[hidden email]> wrote:

> On 04/22/2017 05:59 AM, John W. Eaton wrote:
>> On 04/21/2017 11:34 PM, Daniel J Sebald wrote:
>>
>>> Faddeeva
>>> --------
>>> Some C++ code (actually may be C code that can be compiled as either)
>>> related to only erf() functions.  It has a fairly recent copyright of
>>> 2012, so I assume it must be used in some way, as fallback code or
>>> something.  Could this go in some other directory?  I know there has
>>> been a lot of development around erf so maybe there is a more logical
>>> place.
>>
>> Like most of the other code in cruft, this is code that is maintained (or
>> not) separately from Octave but for which there is no package available
>> in any Linux distribution that I know of, so we include a copy in the
>> Octave sources.  So I'd like to keep files like this separate from the
>> rest of the Octave sources rather than dumping it in with other Octave
>> source code.
>>
>>> Misc
>>> ----
>>> quit.cc,quit.h: Is Octave code, very short.  Seems an odd place for
>>> quit-related code to be since there is probably a lot of start/quit code
>>> elsewhere.
>>
>> These need to be in liboctave (previously, in libcruft) because they need
>> to be available for all of Octave, not just libinterp.  When libcruft was
>> a separate library from liboctave, this location made more sense.
>>
>>> cquit.c: Again, Octave code, very short.  Could probably combine quit.cc
>>> and cquit.c into one file in some way.
>>
>> Maybe, but the reason it is separate is so that it will be compiled with
>> a C compiler, not a C++ compiler, in order to avoid warnings.
>>
>> I moved the files in liboctave/cruft/misc to liboctave/util in this
>> changeset:
>>
>>   http://hg.savannah.gnu.org/hgweb/octave/rev/58d56f52d50a
>>
>> For the rest, how about just renaming liboctave/cruft to be
>> liboctave/external?
>
> That would work for me.
>
> My only slight concern is that it will be confused with the External Code
> Interface documented in Appendix A.  But, if you are mucking about in
> liboctave you probably already understand a lot about the code base.
>
> --Rik

3rd-party and vendor are common names for this things too.

Carnë