Re: [gfsd]Re: CLISP on GNU directory and GNU web pages

[Bradley M. Kuhn]

Sam Steingold <address@hidden> wrote:

> there is another issue here: this category lists _only_ CLISP!  while
> the directory structure is up to you, CLISP should be in the same
> directory as GCL: both are compilers for the same language.  either both
> should be in the compiler section, or both should be in the lisp
> section, or, best of all -- have them in both places!

I'm having deja vu.  As I said in my last email, Janet can fix this by
adding the appropriate categories, and, as I said, due to the holiday,
this might not get fixed until Wednesday.

> if your categorization limits a program to a singe category, then the
> categorization is hard to use, as nicely exemplified by the CLISP & GCL
> being placed in different categories.  it's OK to have one "primary"
> category and several "secondary" ones.  then GCC will have "compiler" as
> its primary category and "C/C++", "Java" &c as secondary ones.
> CLISP/GCL/CMUCL will have "Lisp" as primary and "compiler",
> "interpreter" and "debugger" as secondary.  Maxima will have "symbolic
> math" as primary and "lisp" as secondary.  then each category will have
> a "primary" list and a "secondary" list.

[...]

> GCL and CLISP belong together -- whenever one goes there goes the other.

> I think that all three should be mentioned in _both_ <dev/lang/lisp> and
> <dev/comp> (for compilers).
>
> Maxima should be mentioned in _both_ <math/sym> and <dev/lang/lisp>.
>

[...]

> also, you put `autoclass' under
> <http://www.gnu.org/directory/Software_development/Programs_for_small_specific_development_tasks/autoclass.html>
> while it should go under <math/stat>.


We have the ability to put a program in as many categories as it belongs
now.  In fact, this was a major feature that we absolutely knew we needed.
Because of the old limitation of the broken interface program we used
before, Janet never tried to put something in more than one category.
She now knows that it's safe to do so, and has begun doing it.

However, there are many places, due to legacy, where a package is in one
category where it really should be in multiple ones.  If you find such
problems, I suggest you simple send a short, stand-alone message to
<address@hidden> that says:

   Subject: New Category for package FOO

   Package FOO

   is in category Bar/Baz

   but it really should also be in Goo/Garb

   because of the following reason: ....


And, if your reason is convincing (as all the ones you give above seem to
be at a glance), then Janet will categorize the program that way.


> CMUCL is in that category too, being in the public domain, it should be
> mentioned in the GNU directory. see <http://cmucl.cons.org/cmucl/>.


Great!  Sounds like it's a new program that should go in the directory.

BTW, it is much easier for the folks on <bug-directory> and Janet in
particular if you send new program submissions in separate messages.
Something like this would be helpful, I think:

     Subject: New program for directory: CMUCL

     CMUCL is at http://cmucl.cons.org/cmucl/, and I believe it is in the
     public domain.


> > http://www.gnu.org/directory/Software_development/Programming_languages/LISP_programming_language/
>
> ouch -- is it too late to change this to something easier to type, like
> <http://www.gnu.org/directory/dev/lang/lisp/> ?!

Each category has a "long name" and a "short name".  The short names are
close to what you describe.  It would be an excellent feature to make
both long and short names work.  We can certainly add it to the TODO
list.

There is a down side that the unique names must be unique database wide,
so actually the URL would look something like:

  http://www.gnu.org/directory/dev/lisplang/lisp/

However, we can solve that problem by adding another field that is the
"non-unique short name".  That, too, would be a great feature to add.  Our
goal is to make as many guessable URLs DTRT as possible.


However, please realize that while we have a full time researcher (Janet)
to maintain the data of the directory itself, we don't have a full-time
programmer to work on the interface code.  Recently, we have given 100+%
full-time tech staff for a few weeks to rewrite the new interface and get
it working such that the major, show-stopping problems are gone. (And,
also, to give the directory a presentable interface that we can be
somewhat proud of).


That work is now done.  Moving forward, we must rely primarily on
volunteers to begin hacking on it.  We will give limited staff time each
week to fix urgent problems and to slowly move forward on the most
essential features, but staff time for directory interface hacking will be
precious in the future.  We're trying to get grants to hire staff to do
the work, but that is not assured.  We need volunteers to actually make
this project a success.


It seems like you have some great ideas about how to make the directory
interface better, and you are clearly a talented hacker.  Why don't you
help us on the hacking side as a volunteer?  If you have a savannah ID, we
can add you to the project right away and you can dig in.


> I always wait for a full week before complaining.

That's not completely true.  I just sent my message this morning, and
your response came the same day.  ;)

--
Bradley M. Kuhn, Executive Director
Free Software Foundation     |  Phone: +1-617-542-5942
59 Temple Place, Suite 330   |  Fax:   +1-617-542-2652
Boston, MA 02111-1307  USA   |  Web:   http://www.gnu.org

pgpEqH160jiBu.pgp
Description: PGP signature