organizing deep source trees with child packages

organizing deep source trees with child packages

[Greg Moncreaff]

Have a 3 level (so far) tree of packages

foo/bar/narf

foo/foo.ads
foo/bar/foo-bar.ads
foo/bar/narf/foo-bar-narf.ads
foo/bar/narf/foo-bar-narf-able.ads
foo/bar/narf/foo-bar-narf-able.adb
foo/bar/narf/foo-bar-narf-baker.ads
foo/bar/narf/foo-bar-narf-baker.adb
foo/bar/narf/foo-bar-narf-charlie.ads
foo/bar/narf/foo-bar-narf-charlie.adb

as you can see, the full paths of the items are visually silly, and
somewhat painful if the tree needs refactoring

is there some way of renaming the parent package along the way to
tighten up the names?,
without having to have naming blocks in the .gpr files?

e.g. I would like something like

foo/bar/narf/narf-able.ads
foo/bar/narf/narf-able.adb
foo/bar/narf/narf-baker.ads
foo/bar/narf/narf-baker.adb
foo/bar/narf/narf-charlie.ads
foo/bar/narf/narf-charlie.adb

if by some magic

foo/bar/narf/narf.ads could define

package Narf renames Foo.Bar.Narf

and then

foo/bar/narf/narf.ads could be

package Narf.Able is ...


or is this hopeless desire and an exercise with no value?

Re: organizing deep source trees with child packages

[Yannick Duchêne (Hibou57)]

Le Thu, 13 Oct 2011 01:38:27 +0200, Greg Moncreaff <moncreg@gmail.com> a  
écrit:
> e.g. I would like something like
>
> foo/bar/narf/narf-able.ads
> foo/bar/narf/narf-able.adb
> foo/bar/narf/narf-baker.ads
> foo/bar/narf/narf-baker.adb
> foo/bar/narf/narf-charlie.ads
> foo/bar/narf/narf-charlie.adb
Or even

foo/bar/narf/able.ads
foo/bar/narf/able.adb
foo/bar/narf/baker.ads
foo/bar/narf/baker.adb
foo/bar/narf/charlie.ads
foo/bar/narf/charlie.adb

I opened a similar thread some months ago. This is all about GNAT  
convention, not Ada. For OS with symbolic (not shortcuts, which are not  
the same), you may use two directory hierarchies, one using symbolic links  
to the other (ex foo/bar/narf/able.ads would be a link to  
foo-bar-narf-able.ads). Or alternatively, use a smart outliner or explorer  
in your text editor or IDE, which will interpret GNAT file name convention  
and turn these into a view with nested directories.

I still not solved the case myself, I feel the way using symbolic links  
too much heavy, and the way relying on a smart outliner or browser in an  
editor, not so smart for others, as this depends on a specific tool. On  
the other hand, this is the best solution to me, as people feeling a need  
for it would enjoy it, while people not disturbed by overlong file names  
could go without it.

Or else a specific GNAT branch patched for this single purpose ?


-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: organizing deep source trees with child packages

[Greg Moncreaff]

random thought

http://www.adacore.com/wp-content/files/auto_update/gnat-unw-docs/html/gnat_ugn_12.html#SEC130

Dot_Replacement:
    This attribute specifies the string that should replace the "." in
unit names. Its default value is "-" so that a unit Parent.Child is
expected to be found in the file `parent-child.adb'. The replacement
string must satisfy the following requirements to avoid ambiguities in
the naming scheme:

could you set it
for Dot_Replacement use "/";

???????

Re: organizing deep source trees with child packages

[Yannick Duchêne (Hibou57)]

Le Thu, 13 Oct 2011 04:07:48 +0200, Greg Moncreaff <moncreg@gmail.com> a  
écrit:

> random thought
>
> http://www.adacore.com/wp-content/files/auto_update/gnat-unw-docs/html/gnat_ugn_12.html#SEC130
>
> Dot_Replacement:
>     This attribute specifies the string that should replace the "." in
> unit names. Its default value is "-" so that a unit Parent.Child is
> expected to be found in the file `parent-child.adb'. The replacement
> string must satisfy the following requirements to avoid ambiguities in
> the naming scheme:
>
> could you set it
> for Dot_Replacement use "/";
>
> ???????
>
That's clever at least :) A lightweight simple answer.

Will try it a later day (removed the Ada compiler for some reasons, it  
will be back later). Unless you already did ? If that does not work, then  
the GNAT patch could allow this, this would be simpler and nicer than  
tricking elsewhere.

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: organizing deep source trees with child packages

[Yannick Duchêne (Hibou57)]

Le Thu, 13 Oct 2011 05:52:21 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:

> Le Thu, 13 Oct 2011 04:07:48 +0200, Greg Moncreaff <moncreg@gmail.com> a  
> écrit:
>> [...]
>> could you set it
>> for Dot_Replacement use "/";
>>
>> ???????
>>
> That's clever at least :) A lightweight simple answer.

Oops, I just feel to recall I already tried this two years ago on Windows,  
and that was not working. But things change, still worth to give a try.

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: organizing deep source trees with child packages

[Per Sandberg]

Why Java naming conventions ??
/Per

On 10/13/2011 01:38 AM, Greg Moncreaff wrote:
> Have a 3 level (so far) tree of packages
>
> foo/bar/narf
>
> foo/foo.ads
> foo/bar/foo-bar.ads
> foo/bar/narf/foo-bar-narf.ads
> foo/bar/narf/foo-bar-narf-able.ads
> foo/bar/narf/foo-bar-narf-able.adb
> foo/bar/narf/foo-bar-narf-baker.ads
> foo/bar/narf/foo-bar-narf-baker.adb
> foo/bar/narf/foo-bar-narf-charlie.ads
> foo/bar/narf/foo-bar-narf-charlie.adb
>
> as you can see, the full paths of the items are visually silly, and
> somewhat painful if the tree needs refactoring
>
> is there some way of renaming the parent package along the way to
> tighten up the names?,
> without having to have naming blocks in the .gpr files?
>
> e.g. I would like something like
>
> foo/bar/narf/narf-able.ads
> foo/bar/narf/narf-able.adb
> foo/bar/narf/narf-baker.ads
> foo/bar/narf/narf-baker.adb
> foo/bar/narf/narf-charlie.ads
> foo/bar/narf/narf-charlie.adb
>
> if by some magic
>
> foo/bar/narf/narf.ads could define
>
> package Narf renames Foo.Bar.Narf
>
> and then
>
> foo/bar/narf/narf.ads could be
>
> package Narf.Able is ...
>
>
> or is this hopeless desire and an exercise with no value?

Re: organizing deep source trees with child packages

[Stephen Leake]

Greg Moncreaff <moncreg@gmail.com> writes:

> Have a 3 level (so far) tree of packages
>
> foo/bar/narf
>
> foo/foo.ads
> foo/bar/foo-bar.ads
> foo/bar/narf/foo-bar-narf.ads
> foo/bar/narf/foo-bar-narf-able.ads
> foo/bar/narf/foo-bar-narf-able.adb
> foo/bar/narf/foo-bar-narf-baker.ads
> foo/bar/narf/foo-bar-narf-baker.adb
> foo/bar/narf/foo-bar-narf-charlie.ads
> foo/bar/narf/foo-bar-narf-charlie.adb
>
> as you can see, the full paths of the items are visually silly, and
> somewhat painful if the tree needs refactoring

Drop the directory tree; use a flat directory with full file names:

foo/foo.ads
foo/foo-bar.ads
foo/foo-bar-narf.ads
foo/foo-bar-narf-able.ads
foo/foo-bar-narf-able.adb
foo/foo-bar-narf-baker.ads
foo/foo-bar-narf-baker.adb
foo/foo-bar-narf-charlie.ads
foo/foo-bar-narf-charlie.adb


> e.g. I would like something like
>
> foo/bar/narf/narf-able.ads
> foo/bar/narf/narf-able.adb
> foo/bar/narf/narf-baker.ads
> foo/bar/narf/narf-baker.adb
> foo/bar/narf/narf-charlie.ads
> foo/bar/narf/narf-charlie.adb

Is that better than my suggestion? If so, why?

In my view, directories are for very large groupings of files; I often
have hundreds of Ada files in one directory.

> foo/bar/narf/narf.ads could define
>
> package Narf renames Foo.Bar.Narf

I think this is a name conflict, but you could use:

package Narf_Local renames Foo.Bar.Narf

which is probably not worth it.

-- 
-- Stephe

Re: organizing deep source trees with child packages

[Greg Moncreaff]

On Oct 13, 4:20 am, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:
>
> Drop the directory tree; use a flat directory with full file names:
>
>
> In my view, directories are for very large groupings of files; I often
> have hundreds of Ada files in one directory.
>

In this case the files have coherence at the leaf level (same
functional group, standard)
but the middle levels will change (new adds, old removes)

100's of files?  unless it was auto generated from a domain model,
how can you possibly keep it organized as to what depends on what,
what is separable, reusable; what deals with one interface/component/
peer vs another,
etc

Re: organizing deep source trees with child packages

[Ludovic Brenta]

Greg Moncreaff wrote on comp.lang.ada:
> 100's of files?  unless it was auto generated from a domain model,
> how can you possibly keep it organized as to what depends on what,
> what is separable, reusable; what deals with one interface/component/
> peer vs another,
> etc

Remember that Ada was designed for large-scale software engineering
and therefore provides tools to:

- encode dependencies, this is what "with" clauses are for.

- minimize dependencies by means of information hiding.  Private child
packages are your friends.  You normally design large modules as
hierarchies of packages; the top-level package provides the public
interface for the module and the private children provide the
implementation.

- keep track of dependencies: this is what gnatmake is for.

- build and maintain cross-references: that's (also) what the .ali
files produced by the compiler are for, and gnatfind is your friend.

Directories are *not* a solution for these problems.  They do not
represent dependencies or hide any information from the compiler.
They do not help navigate the sources; specialized tools like
gnatfind, GPS or Emacs ada-mode do a better job with or without
directories, and general tools like grep work better without
directories.

The one situation where I find directories useful is when I want to
build some of my sources as a shared library.  In this case I place
these sources into a separate directory, build them separately, and
then install the shared library along with sources, .ali files and a
project file in a read-only directory where the rest of the software
looks for them.  This only works well if the shared library is mature
and stable (i.e. does not change very often anymore).

BTW, I too work on large-scale software (over 2 million lines of
sources) where directories normally contain hundreds of source files.

--
Ludovic Brenta.

Re: organizing deep source trees with child packages

[Yannick Duchêne (Hibou57)]

Le Thu, 13 Oct 2011 16:18:27 +0200, Ludovic Brenta  
<ludovic@ludovic-brenta.org> a écrit:
> Directories are *not* a solution for these problems.  They do not
> represent dependencies or hide any information from the compiler.
This is not a matter of semantic, this is a matter of being handy for  
human beings.

By the way, using overlong file names instead of directory, is not even  
suggested by the ARM, this is just a GNAT convention. Using directory  
would not break Ada semantic, you will just replace “.” by “/” or “\”  
instead of “-”. As to reply to someone previously on this thread, if this  
the difference between Ada and Java was really just about using overlong  
file name or directory to present files to the user, I would start  
wondering a lot. Using directories would not turn Ada into Java.

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: organizing deep source trees with child packages

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.v3a9wdv1ule2fv@index.ici...
>By the way, using overlong file names instead of directory, is not even 
>suggested by the ARM, this is just a GNAT convention. Using directory 
>would not break Ada semantic, you will just replace "." by "/" or "\" 
>instead of "-".

It wouldn't break the Ada semantics, but it would make it a lot harder for 
build tools and the like to function. (Especially simple tools like 
"find"/"grep".) And in any case, the solution for "overlong file names" is 
to use shorter ones! There's no law (either in GNAT or Ada) requiring anyone 
to use 50 character file names.

Indeed, most of my Janus/Ada work still uses 8.3 file names: "J2Code_E.Ads", 
for example. The actual package name is quite a bit longer. Janus/Ada needs 
only to be told once about the correspondence between package names and file 
names -- either by compiling the file manually or telling the build tool the 
name when asked. After that, Janus/Ada remembers the file names in the 
project files and does not need to told again (unless of course you decide 
to make a fresh start with your projects and delete the old file).

                       Randy.

Re: organizing deep source trees with child packages

[Yannick Duchêne (Hibou57)]

Le Fri, 14 Oct 2011 03:44:21 +0200, Randy Brukardt <randy@rrsoftware.com>  
a écrit:
> It wouldn't break the Ada semantics, but it would make it a lot harder  
> for
> build tools and the like to function. (Especially simple tools like
> "find"/"grep".)
I don't see an example rigth away, but I still trust this argument.

> And in any case, the solution for "overlong file names" is
> to use shorter ones! There's no law (either in GNAT or Ada) requiring  
> anyone
> to use 50 character file names.
But this is nicer to give the file the exact same name as the unit it  
contains, and with child packages, you easily reach long name (ans many  
files in a single directory).

> Indeed, most of my Janus/Ada work still uses 8.3 file names:  
> "J2Code_E.Ads",
> for example. The actual package name is quite a bit longer. Janus/Ada  
> needs
> only to be told once about the correspondence between package names and  
> file
> names
Seems good. Instead of patching GNAT to make it use another convention, a  
tool could automatically generate a series of “for Spec ("Unit") use  
"Path";” and “for Body ("Unit") use "Path";” and put these in the GPR file  
or even preferably a GPR file included in a master GRP file.
For reference, see:  
http://www.adacore.com/wp-content/files/auto_update/gnat-unw-docs/html/gnat_ugn_12.html#SEC130
This way, anyone can use any directory and file name layout he/she wish  
(and don't tell anyone if he/she prefer nested directories :-P ).

> -- either by compiling the file manually or telling the build tool the
> name when asked. After that, Janus/Ada remembers the file names in the
> project files and does not need to told again (unless of course you  
> decide
> to make a fresh start with your projects and delete the old file).
I like this idea of an interactive configuration :) Was thinking about a  
similar thing some days ago, for another purpose.

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: organizing deep source trees with child packages

[Stephen Leake]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

>> -- either by compiling the file manually or telling the build tool the
>> name when asked. After that, Janus/Ada remembers the file names in the
>> project files and does not need to told again (unless of course you
>> decide
>> to make a fresh start with your projects and delete the old file).
> I like this idea of an interactive configuration :) Was thinking about
> a similar thing some days ago, for another purpose.

Interactive tools are good while you are learning the system, and for
quick one off prototypes. But for serious work, you need documented,
reproducible results, which means that list of files must be recorded
in file (or a make pattern, or something).

-- 
-- Stephe

Re: organizing deep source trees with child packages

[Dmitry A. Kazakov]

On Fri, 14 Oct 2011 00:25:15 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Thu, 13 Oct 2011 16:18:27 +0200, Ludovic Brenta  
> <ludovic@ludovic-brenta.org> a �crit:
>> Directories are *not* a solution for these problems.  They do not
>> represent dependencies or hide any information from the compiler.
> This is not a matter of semantic, this is a matter of being handy for  
> human beings.

Actually long file names is not the problem. The problem is that GPS in its
tree view control used for browsing the project units ignores the packages
hierarchy in favor of the hierarchy of the file system. Change that in GPS
(or another Ada IDE) and the problem would largely disappear.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: organizing deep source trees with child packages

[Yannick Duchêne (Hibou57)]

Le Fri, 14 Oct 2011 09:27:54 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> Actually long file names is not the problem. The problem is that GPS in  
> its
> tree view control used for browsing the project units ignores the  
> packages
> hierarchy in favor of the hierarchy of the file system. Change that in  
> GPS
> (or another Ada IDE) and the problem would largely disappear.
You perfectly understood the purpose. There was references to IDEs in this  
thread. The case of browsing a directory outside of an IDE still exist,  
but is less important.


-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: organizing deep source trees with child packages

[Stephen Leake]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Fri, 14 Oct 2011 00:25:15 +0200, Yannick Duchêne (Hibou57) wrote:
>
>> Le Thu, 13 Oct 2011 16:18:27 +0200, Ludovic Brenta  
>> <ludovic@ludovic-brenta.org> a écrit:
>>> Directories are *not* a solution for these problems.  They do not
>>> represent dependencies or hide any information from the compiler.
>> This is not a matter of semantic, this is a matter of being handy for  
>> human beings.
>
> Actually long file names is not the problem. The problem is that GPS in its
> tree view control used for browsing the project units ignores the packages
> hierarchy in favor of the hierarchy of the file system. Change that in GPS
> (or another Ada IDE) and the problem would largely disappear.

I still don't understand what "problem" is being solved here.

A file system browser allows viewing files by file name; that's a good
solution for a class of problems. A package browser allows browsing
packages by package name; that's a good solution for another class of
problems.

If the file and package names are the same, then you can use a file
browser as a package browser, avoiding the work of maintaining two
tools.

When do file names and package names _need_ to be different?

I don't see any problem with long file names; they used to be a problem
on 80 character terminals, but we are past that now.

-- 
-- Stephe

Re: organizing deep source trees with child packages

[Dmitry A. Kazakov]

On Sun, 16 Oct 2011 08:51:14 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Fri, 14 Oct 2011 00:25:15 +0200, Yannick Duch�ne (Hibou57) wrote:
>>
>>> Le Thu, 13 Oct 2011 16:18:27 +0200, Ludovic Brenta  
>>> <ludovic@ludovic-brenta.org> a �crit:
>>>> Directories are *not* a solution for these problems.  They do not
>>>> represent dependencies or hide any information from the compiler.
>>> This is not a matter of semantic, this is a matter of being handy for  
>>> human beings.
>>
>> Actually long file names is not the problem. The problem is that GPS in its
>> tree view control used for browsing the project units ignores the packages
>> hierarchy in favor of the hierarchy of the file system. Change that in GPS
>> (or another Ada IDE) and the problem would largely disappear.
> 
> I still don't understand what "problem" is being solved here.

Long file names, which are difficult to read.

GPS project view shows file names, e.g.:

gtk-layered-waveform-ring_data_buffer.adb
gtk-layered-waveform-ring_data_buffer.ads

It should rather show simple names of Ada units, e.g.:

gtk
|-layered
|   |-waveform
|   |   |-ring_data_buffer
|   |   |   |-package specification
|   |   |   |-package body

> A file system browser allows viewing files by file name; that's a good
> solution for a class of problems. A package browser allows browsing
> packages by package name; that's a good solution for another class of
> problems.
> 
> If the file and package names are the same, then you can use a file
> browser as a package browser, avoiding the work of maintaining two
> tools.
> 
> When do file names and package names _need_ to be different?

Always. Actually this is what the OP wished to have: a correspondence
between fully qualified names of Ada units and paths of the files
containing these units. Parent's name <-> directory name. Child name <->
file name.

> I don't see any problem with long file names; they used to be a problem
> on 80 character terminals, but we are past that now.

For projects of many hundred files, it is a huge problem. Especially when
you have hundreds of generic package instances popping everywhere. Pushing
files into different directories makes things only worse. The point is,
when browsing a project you are not interested in files, you are looking
for Ada units, and it is absolutely irrelevant what is the file name of
that unit. In fact, if the source control systems were not so retarded, we
would have no files at all, just versions of units stored in a database.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: organizing deep source trees with child packages

[Shark8]

On Oct 16, 8:43 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> For projects of many hundred files, it is a huge problem. Especially when
> you have hundreds of generic package instances popping everywhere. Pushing
> files into different directories makes things only worse. The point is,
> when browsing a project you are not interested in files, you are looking
> for Ada units, and it is absolutely irrelevant what is the file name of
> that unit. In fact, if the source control systems were not so retarded, we
> would have no files at all, just versions of units stored in a database.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

Spot on. Having the code be a bunch of versions in a DB would be
fantastic as far as development/searching would be; it would be even
better if the code itself were, for lack of a better phrase, a set of
stored-tokens (instead of plain text) as this would allow different
programmers to apply personalized formatting to the source without
causing (what would be in text-files) a change resulting in another
version.

Re: organizing deep source trees with child packages

[Ludovic Brenta]

Shark8 writes on comp.lang.ada:
> Dmitry A. Kazakov wrote:
>> For projects of many hundred files, it is a huge problem. Especially
>> when you have hundreds of generic package instances popping
>> everywhere. Pushing files into different directories makes things
>> only worse. The point is, when browsing a project you are not
>> interested in files, you are looking for Ada units, and it is
>> absolutely irrelevant what is the file name of that unit. In fact, if
>> the source control systems were not so retarded, we would have no
>> files at all, just versions of units stored in a database.
>
> Spot on. Having the code be a bunch of versions in a DB would be
> fantastic as far as development/searching would be; it would be even
> better if the code itself were, for lack of a better phrase, a set of
> stored-tokens (instead of plain text) as this would allow different
> programmers to apply personalized formatting to the source without
> causing (what would be in text-files) a change resulting in another
> version.

Wasn't that how the Rational R1000 machine worked?

-- 
Ludovic Brenta.

Re: organizing deep source trees with child packages

[Simon Wright]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Shark8 writes on comp.lang.ada:

>> Spot on. Having the code be a bunch of versions in a DB would be
>> fantastic as far as development/searching would be; it would be even
>> better if the code itself were, for lack of a better phrase, a set of
>> stored-tokens (instead of plain text) as this would allow different
>> programmers to apply personalized formatting to the source without
>> causing (what would be in text-files) a change resulting in another
>> version.
>
> Wasn't that how the Rational R1000 machine worked?

Exactly so. Except you didn't get to apply personalised formatting; thus
eliminating at a stroke a whole class of religious strife.

(Actually, I don't remember what if any VCS style was supported; I never
got to use it for a real project, just an evaluation, and we hadn't
heard of VCSs then).

Re: organizing deep source trees with child packages

[Ludovic Brenta]

Simon Wright wrote:
> Ludovic Brenta <ludo...@ludovic-brenta.org> writes:
>> Shark8 writes on comp.lang.ada:
>>> Spot on. Having the code be a bunch of versions in a DB would be
>>> fantastic as far as development/searching would be; it would be even
>>> better if the code itself were, for lack of a better phrase, a set of
>>> stored-tokens (instead of plain text) as this would allow different
>>> programmers to apply personalized formatting to the source without
>>> causing (what would be in text-files) a change resulting in another
>>> version.
>
>> Wasn't that how the Rational R1000 machine worked?
>
> Exactly so. Except you didn't get to apply personalised formatting; thus
> eliminating at a stroke a whole class of religious strife.
>
> (Actually, I don't remember what if any VCS style was supported; I never
> got to use it for a real project, just an evaluation, and we hadn't
> heard of VCSs then).

There was a VCS integrated; I used it as part of Rational Apex on
Solaris a few years ago.  I think it was slightly different from the
original, as it used RCS as a storage back-end for source files and
introduced the "subsystem" (consisting of many source files) as the
preferred unit of configuration management.  Branching was OK but
merging was horrible, as with RCS.

The continuous updates of the DIANA database were also gone by then;
the database was only updated on demand as part of compilation.

--
Ludovic Brenta.

Re: organizing deep source trees with child packages

[Simon Wright]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> There was a VCS integrated; I used it as part of Rational Apex on
> Solaris a few years ago.  I think it was slightly different from the
> original, as it used RCS as a storage back-end for source files and
> introduced the "subsystem" (consisting of many source files) as the
> preferred unit of configuration management.  Branching was OK but
> merging was horrible, as with RCS.

The GNAT 'stand-alone library' is, I think, similar to the subsystem in
that only some of the units are externally visible. Of course you _may_
be able to get a similar effect by using private child packages.

Re: organizing deep source trees with child packages

[Ludovic Brenta]

Simon Wright wrote on comp.lang.ada:
> Ludovic Brenta <ludo...@ludovic-brenta.org> writes:
>> There was a VCS integrated; I used it as part of Rational Apex on
>> Solaris a few years ago.  I think it was slightly different from the
>> original, as it used RCS as a storage back-end for source files and
>> introduced the "subsystem" (consisting of many source files) as the
>> preferred unit of configuration management.  Branching was OK but
>> merging was horrible, as with RCS.
>
> The GNAT 'stand-alone library' is, I think, similar to the subsystem in
> that only some of the units are externally visible. Of course you _may_
> be able to get a similar effect by using private child packages.

No, the "subsystem" in Rational has nothing to do with visibility; it
was only a configuration management entity.  You could declare that a
subsystem A with version number N depended on a subsystem B with
version number M.  There was no mechanism (that I remember) to hide
part of a subsystem from the outside.  And TTBOMK the GNAT 'stand-
alone library' is not about version control or configuration
management, since it is not versioned.

--
Ludovic Brenta.

Re: organizing deep source trees with child packages

[Simon Wright]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Simon Wright wrote on comp.lang.ada:
>> Ludovic Brenta <ludo...@ludovic-brenta.org> writes:
>>> There was a VCS integrated; I used it as part of Rational Apex on
>>> Solaris a few years ago.  I think it was slightly different from the
>>> original, as it used RCS as a storage back-end for source files and
>>> introduced the "subsystem" (consisting of many source files) as the
>>> preferred unit of configuration management.  Branching was OK but
>>> merging was horrible, as with RCS.
>>
>> The GNAT 'stand-alone library' is, I think, similar to the subsystem
>> in that only some of the units are externally visible. Of course you
>> _may_ be able to get a similar effect by using private child
>> packages.
>
> No, the "subsystem" in Rational has nothing to do with visibility; it
> was only a configuration management entity.  You could declare that a
> subsystem A with version number N depended on a subsystem B with
> version number M.  There was no mechanism (that I remember) to hide
> part of a subsystem from the outside.  And TTBOMK the GNAT 'stand-
> alone library' is not about version control or configuration
> management, since it is not versioned.

The paper at <http://dodreports.com/pdf/ada323647.pdf> - which is a
PDF'd scan - doesn't seem to agree with this;

on page 20, "The main reason for decomposing a system into subsystems is
to control and manage complexity."

on page 22, "a view [of a subsystem] manages: [...]  c. The visibility
to program units in other subsystems."

And the VCS - on the R1000 - was CMVC. I think that later versions of
APEX use ClearCase?

Re: organizing deep source trees with child packages

[Ludovic Brenta]

Simon Wright wrote on comp.lang.ada:
> Ludovic Brenta <ludo...@ludovic-brenta.org> writes:
>> No, the "subsystem" in Rational has nothing to do with visibility; it
>> was only a configuration management entity.  You could declare that a
>> subsystem A with version number N depended on a subsystem B with
>> version number M.  There was no mechanism (that I remember) to hide
>> part of a subsystem from the outside.  And TTBOMK the GNAT 'stand-
>> alone library' is not about version control or configuration
>> management, since it is not versioned.
>
> The paper at <http://dodreports.com/pdf/ada323647.pdf> - which is a
> PDF'd scan - doesn't seem to agree with this;
>
> on page 20, "The main reason for decomposing a system into subsystems is
> to control and manage complexity."
>
> on page 22, "a view [of a subsystem] manages: [...]  c. The visibility
> to program units in other subsystems."
>
> And the VCS - on the R1000 - was CMVC. I think that later versions of
> APEX use ClearCase?

I was talking about a version of APEX that included yet another
version control system, based on RCS and subsystems, and that tried to
mimick the VCS on the R1000.  This version of APEX could also use
ClearCase but that was an optional and expensive extra.  I don't know
what happened to APEX after these old versions; it is possible that
the "default" VCS was replaced with ClearCase.

About visibility: if you declared that subsystem A depended on
subsystem B, then all the units in A could see all the units in B.
There was no notion of private subsystems, or of private units within
a subsystem.  I think the units of B could also see the units of A;
this allowed a package spec to be in A and several possible bodies to
be in different versions of B or in different subsystems altogether.
But my memory is fuzzy on this point.

Anyway, as I said, this version control system was really bad at
merging.

--
Ludovic Brenta.

Re: organizing deep source trees with child packages

[Yannick Duchêne (Hibou57)]

Le Sun, 16 Oct 2011 15:43:03 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> For projects of many hundred files, it is a huge problem. Especially when
> you have hundreds of generic package instances popping everywhere.  
> Pushing
> files into different directories makes things only worse. The point is,
> when browsing a project you are not interested in files, you are looking
> for Ada units, and it is absolutely irrelevant what is the file name of
> that unit. In fact, if the source control systems were not so retarded,  
> we
> would have no files at all, just versions of units stored in a database.
Any view of a semantic modal. A text view is just a view among other  
possible views. But this is difficult to impose, because this would rely  
on applications far different from raw text editors are, and this would  
require to be common. Don't go to fast, in the area of evolving from raw  
text, we are still hardly switching from US-ASCII to Unicode ;) (which is  
still enough frightening to some people).


-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: organizing deep source trees with child packages

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Long file names, which are difficult to read.
>
> GPS project view shows file names, e.g.:
>
> gtk-layered-waveform-ring_data_buffer.adb
> gtk-layered-waveform-ring_data_buffer.ads
>
> It should rather show simple names of Ada units, e.g.:
>
> gtk
> |-layered
> |   |-waveform
> |   |   |-ring_data_buffer
> |   |   |   |-package specification
> |   |   |   |-package body

You seem to be complaining about the design of GPS rather than anything
particularly to do with long file names.

You could use gnatkr: 

$ gnatkr gtk.layered.waveform.ring_data_buffer.ads
glwrdabu.ads

:-)

Re: organizing deep source trees with child packages

[Dmitry A. Kazakov]

On Mon, 17 Oct 2011 08:09:16 +0100, Simon Wright wrote:

> You seem to be complaining about the design of GPS rather than anything
> particularly to do with long file names.

Yes, as wrote one post before, long file names is not a problem. The
problem is the IDE.

> You could use gnatkr: 
> 
> $ gnatkr gtk.layered.waveform.ring_data_buffer.ads
> glwrdabu.ads
> 
> :-)

There are better one way encryption functions than gnatkr! (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: organizing deep source trees with child packages

[Stephen Leake]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 16 Oct 2011 08:51:14 -0400, Stephen Leake wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On Fri, 14 Oct 2011 00:25:15 +0200, Yannick Duchêne (Hibou57) wrote:
>>>
>>>> Le Thu, 13 Oct 2011 16:18:27 +0200, Ludovic Brenta  
>>>> <ludovic@ludovic-brenta.org> a écrit:
>>>>> Directories are *not* a solution for these problems.  They do not
>>>>> represent dependencies or hide any information from the compiler.
>>>> This is not a matter of semantic, this is a matter of being handy for  
>>>> human beings.
>>>
>>> Actually long file names is not the problem. The problem is that GPS in its
>>> tree view control used for browsing the project units ignores the packages
>>> hierarchy in favor of the hierarchy of the file system. Change that in GPS
>>> (or another Ada IDE) and the problem would largely disappear.
>> 
>> I still don't understand what "problem" is being solved here.
>
> Long file names, which are difficult to read.

I guess we'll just have to disagree about that.

Are long package names easier to read?

> GPS project view shows file names, e.g.:
>
> gtk-layered-waveform-ring_data_buffer.adb
> gtk-layered-waveform-ring_data_buffer.ads
>
> It should rather show simple names of Ada units, e.g.:
>
> gtk
> |-layered
> |   |-waveform
> |   |   |-ring_data_buffer
> |   |   |   |-package specification
> |   |   |   |-package body

I don't use GPS, but I assume it has a package browser that shows this
tree. Personally, I've never felt the need for such a view.

I guess you are saying "yes, long package names are hard to read, and
this tree view is a solution to that".

>> A file system browser allows viewing files by file name; that's a good
>> solution for a class of problems. A package browser allows browsing
>> packages by package name; that's a good solution for another class of
>> problems.
>> 
>> If the file and package names are the same, then you can use a file
>> browser as a package browser, avoiding the work of maintaining two
>> tools.
>> 
>> When do file names and package names _need_ to be different?
>
> Always. 

Why? Simple assertions don't get us anywhere.

> Actually this is what the OP wished to have: a correspondence between
> fully qualified names of Ada units and paths of the files containing
> these units. 

The current gnat convention gives that.

> Parent's name <-> directory name. Child name <-> file name.

That's another alternative, with the drawbacks several of us have
pointed out.

>> I don't see any problem with long file names; they used to be a problem
>> on 80 character terminals, but we are past that now.
>
> For projects of many hundred files, it is a huge problem. 

Not for me or Ludovic (or many others, I assume). Exactly what is the
problem?

> Especially when you have hundreds of generic package instances popping
> everywhere. 

Why are generics a special case? 

It can be difficult to come up with good names for generic packages and
their instances. I solve that with a naming convention; the package name
of a generic package must start with "Gen_".

> Pushing files into different directories makes things only worse. 

How, exactly?

> The point is, when browsing a project you are not interested in files,

Depends on exactly why I'm "browsing".

> you are looking for Ada units, 

Ok, I'll suppose I'm "browsing for Ada units". I'm still not clear what that
means in detail. 

If I'm _searching_ for an Ada unit that deals with lists, I
either:

1) remember the full name exactly, and navigate there by file name
(which matches the package name)

2) open a directory that contains the library that probably contains the
lists packages, and search for the string "list" in the file names.

If the IDE provides some other way to search for "list" in package
names, that would be equally useful. (Does GPS let you search for
strings in its file or package browser?) But since the Emacs file
browser already provides this, I see no need to spend additional
resources adding that specific capability.

Maybe the real solution is to use Emacs instead of GPS or Eclipse (or
anything else)? Every time I compare the three, Emacs wins hands down on
features that contribute to real productivity.

> and it is absolutely irrelevant what is the file name of that unit.

Ok. But I can take advantage of that fact if it happens to be true.

In the above scenario, if the file names do not contain the full package
name, I could use 'grep list *.ads', but that's less reliable, since it
would find instances of "list" in the rest of the package spec, not just
the package name. Building a regexp to match only package names is
possible, but not trivial.


What are some other use cases for "browsing"?

> In fact, if the source control systems were not so retarded, we would
> have no files at all, just versions of units stored in a database.

Many people have said that over the years, and Rational (I think) built
a system that worked that way. It was a failure, and I'm not aware of
any other system that actually works that way. 

The reason is the flexibility, power, and reliability of the current
file based system. You'll have to make _very_ solid arguments to counter
that. So far I see only vague unsubstantiated assertions.

-- 
-- Stephe

Re: organizing deep source trees with child packages

[Dmitry A. Kazakov]

On Tue, 18 Oct 2011 07:12:03 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Long file names, which are difficult to read.
> 
> I guess we'll just have to disagree about that.
> 
> Are long package names easier to read?

They are not long, fully qualified names are long.
 
>>> When do file names and package names _need_ to be different?
>>
>> Always. 
> 
> Why? Simple assertions don't get us anywhere.

"c:\mess\foo.adb" /= "Foo"
 
>> Especially when you have hundreds of generic package instances popping
>> everywhere. 
> 
> Why are generics a special case? 

Because they add a multiplication factor in the number of packages for each
varying generic formal parameter. Generics also adds a layer of indirection
instance <-> generic-body. It is just impossible to remember which is an
instance of what and where are instances with particular parameters.

> It can be difficult to come up with good names for generic packages and
> their instances. I solve that with a naming convention; the package name
> of a generic package must start with "Gen_".

Right, but that does not help much. You can have instances within generic
bodies and other bodies. With generic children you also have cascaded
instantiations along the packages tree path. It seems that we are talking
about different dimensions. My current project has 700+ units.

>> Pushing files into different directories makes things only worse. 
> 
> How, exactly?

You must also remember the directories. If you need to find a unit you
first have to go to its directory and then start searching.

>> The point is, when browsing a project you are not interested in files,
> 
> Depends on exactly why I'm "browsing".

While programming/reviewing/testing/debugging an Ada program.

>> you are looking for Ada units, 
> 
> Ok, I'll suppose I'm "browsing for Ada units". I'm still not clear what that
> means in detail. 
> 
> If I'm _searching_ for an Ada unit that deals with lists, I
> either:
> 
> 1) remember the full name exactly, and navigate there by file name
> (which matches the package name)
> 
> 2) open a directory that contains the library that probably contains the
> lists packages, and search for the string "list" in the file names.
> 
> If the IDE provides some other way to search for "list" in package
> names, that would be equally useful. (Does GPS let you search for
> strings in its file or package browser?)

It does, but it is far slower than browsing, because it involves typing,
browsing the results of the search, and is contaminated by the results
coming from with/use.

> Maybe the real solution is to use Emacs instead of GPS or Eclipse (or
> anything else)? Every time I compare the three, Emacs wins hands down on
> features that contribute to real productivity.

You know, Emacs users and us, the others, represent different species. I'm
certain that a scientific study would show that these don't even
interbreed. Each Emacs user must have been abducted by aliens in flying
saucers... (:-))

>> and it is absolutely irrelevant what is the file name of that unit.
> 
> Ok. But I can take advantage of that fact if it happens to be true.
> 
> In the above scenario, if the file names do not contain the full package
> name, I could use 'grep list *.ads', but that's less reliable, since it
> would find instances of "list" in the rest of the package spec, not just
> the package name. Building a regexp to match only package names is
> possible, but not trivial.
> 
> 
> What are some other use cases for "browsing"?

Browsing is more like looking at the list of packages to see how they are
related etc. It is a generalized view of the project. Often I don't
remember the exact name, but looking at the hierarchy of the packages I can
quickly guess it.

I have no idea how Martians (sorry, Emacs users (:-)) manage their
projects. But I cannot remember more than three phone numbers, have a
mercy! (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: organizing deep source trees with child packages

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> You know, Emacs users and us, the others, represent different
> species. I'm certain that a scientific study would show that these
> don't even interbreed. Each Emacs user must have been abducted by
> aliens in flying saucers... (:-))

I think the alien part may be the answer. We certainly don't seem to
breed true (I only have two data points for this statement :-))

Re: organizing deep source trees with child packages

[Ludovic Brenta]

Simon Wright <simon@pushface.org> writes:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> You know, Emacs users and us, the others, represent different
>> species. I'm certain that a scientific study would show that these
>> don't even interbreed. Each Emacs user must have been abducted by
>> aliens in flying saucers... (:-))
>
> I think the alien part may be the answer. We certainly don't seem to
> breed true (I only have two data points for this statement :-))

I've been an avid emacs user (indeed I am typing this post in emacs
right now) since 2000, and my 5-year-old son learned how to type his
name in the *scratch* buffer of emacs.  How is that for a data point? :)

-- 
Ludovic Brenta.

Re: organizing deep source trees with child packages

[Simon Wright]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Simon Wright <simon@pushface.org> writes:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> You know, Emacs users and us, the others, represent different
>>> species. I'm certain that a scientific study would show that these
>>> don't even interbreed. Each Emacs user must have been abducted by
>>> aliens in flying saucers... (:-))
>>
>> I think the alien part may be the answer. We certainly don't seem to
>> breed true (I only have two data points for this statement :-))
>
> I've been an avid emacs user (indeed I am typing this post in emacs
> right now) since 2000, and my 5-year-old son learned how to type his
> name in the *scratch* buffer of emacs.  How is that for a data point? :)

Hmm, both my daughters were born before the GNU Emacs project started
(1984 according to Wikipedia), so perhaps it's no wonder!

Re: organizing deep source trees with child packages

[Bill Findlay]

On 18/10/2011 19:57, in article m21uuaruu7.fsf@pushface.org, "Simon Wright"
<simon@pushface.org> wrote:

> Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
> 
>> Simon Wright <simon@pushface.org> writes:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>> You know, Emacs users and us, the others, represent different
>>>> species. I'm certain that a scientific study would show that these
>>>> don't even interbreed. Each Emacs user must have been abducted by
>>>> aliens in flying saucers... (:-))
>>> 
>>> I think the alien part may be the answer. We certainly don't seem to
>>> breed true (I only have two data points for this statement :-))
>> 
>> I've been an avid emacs user (indeed I am typing this post in emacs
>> right now) since 2000, and my 5-year-old son learned how to type his
>> name in the *scratch* buffer of emacs.  How is that for a data point? :)
> 
> Hmm, both my daughters were born before the GNU Emacs project started
> (1984 according to Wikipedia), so perhaps it's no wonder!

I'll enrage both of the warring camps, but I see little difference between
emacs and vi: both are feeble attempts to simulate a proper GUI editor.

I first encountered emacs in the late 1970s, on our Unix V7 PDP-11/45.
That machine had 248K of RAM.  Emacs was several times bigger than the
entire store, which supported 16 users well (if emacs was not running) or
one user badly (when emacs was running).  I saw no good reason for that
extravagance and have not changed my mind since.

{Yes, it's a drop in the ocean of this laptop's 4Gb RAM; but it's a matter
of principle. 8-}

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: organizing deep source trees with child packages

[Simon Wright]

Bill Findlay <yaldnif.w@blueyonder.co.uk> writes:

> On 18/10/2011 19:57, in article m21uuaruu7.fsf@pushface.org, "Simon Wright"
> <simon@pushface.org> wrote:
>
>> Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
>> 
>>> Simon Wright <simon@pushface.org> writes:
>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>>> You know, Emacs users and us, the others, represent different
>>>>> species. I'm certain that a scientific study would show that these
>>>>> don't even interbreed. Each Emacs user must have been abducted by
>>>>> aliens in flying saucers... (:-))
>>>> 
>>>> I think the alien part may be the answer. We certainly don't seem
>>>> to breed true (I only have two data points for this statement :-))
>>> 
>>> I've been an avid emacs user (indeed I am typing this post in emacs
>>> right now) since 2000, and my 5-year-old son learned how to type his
>>> name in the *scratch* buffer of emacs.  How is that for a data
>>> point? :)
>> 
>> Hmm, both my daughters were born before the GNU Emacs project started
>> (1984 according to Wikipedia), so perhaps it's no wonder!
>
> I'll enrage both of the warring camps, but I see little difference
> between emacs and vi: both are feeble attempts to simulate a proper
> GUI editor.

Bill, in this case the "camps" are Emacs and (I think) GPS. For once vi
doesn't feature!

> I first encountered emacs in the late 1970s, on our Unix V7 PDP-11/45.
> That machine had 248K of RAM.  Emacs was several times bigger than the
> entire store, which supported 16 users well (if emacs was not running)
> or one user badly (when emacs was running).  I saw no good reason for
> that extravagance and have not changed my mind since.

I've just opened GPS, and it's running at 117 Mb (the X11 server I
wouldn't be running otherwise is at 27 Mb).

Emacs (open for days, including this newsreader) is at 104 Mb.

Safari is top at >600 Mb! (Safari + Safari Web Content).

Re: organizing deep source trees with child packages

[Dmitry A. Kazakov]

On Wed, 19 Oct 2011 07:28:25 +0100, Simon Wright wrote:

> I've just opened GPS, and it's running at 117 Mb (the X11 server I
> wouldn't be running otherwise is at 27 Mb).
> 
> Emacs (open for days, including this newsreader) is at 104 Mb.

Proper IDEs also existed in earlier days. E.g. LSE (under VMS) required far
less than 1Mb, had context sensitive stuff, was fully programmable etc. 

---------------
The division is between command-line interfaces (cryptic commands + key
accelerators for those) and visual interfaces (meant to be "intuitive").

Those who enjoy memorizing commands possibly have no problem to memorize 1K
mappings Ada unit <-> file name.

We must be proud of these courageous people wasting so much efforts, while
still being able to accomplish some useful work too! (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: organizing deep source trees with child packages

[Yannick Duchêne (Hibou57)]

Le Wed, 19 Oct 2011 10:29:48 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> Proper IDEs also existed in earlier days. E.g. LSE (under VMS) required  
> far
> less than 1Mb, had context sensitive stuff, was fully programmable etc.
Some references ? (User Interface is always an hight priority topic, so  
materials and references are welcome)

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: organizing deep source trees with child packages

[Dmitry A. Kazakov]

On Wed, 19 Oct 2011 13:52:35 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Wed, 19 Oct 2011 10:29:48 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
>> Proper IDEs also existed in earlier days. E.g. LSE (under VMS) required far
>> less than 1Mb, had context sensitive stuff, was fully programmable etc.
> Some references ? (User Interface is always an hight priority topic, so  
> materials and references are welcome)

LSE = DEC's language sensitive editor. I think it was the first editor
which supported expansion (parameter lists, language constructs). As for
being programmable, I for example, implemented columned selection,
cut/paste in LSE. DEC debugger was fully integrated. I remember a machine
with 1Mb RAM running 6 LSE sessions (Ada 83 and C).

http://h71000.www7.hp.com/doc/82final/decset/6355_pro.pdf
http://h71000.www7.hp.com/doc/82final/decset/lse_users_guide.pdf

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: organizing deep source trees with child packages

[Stephen Leake]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> The division is between command-line interfaces (cryptic commands + key
> accelerators for those) and visual interfaces (meant to be "intuitive").

What "division" are you talking about?

If you are talking about Emacs vs GPS, you are simply mistaken. Both
Emacs and GPS provide GUI interfaces to command line tools.

> Those who enjoy memorizing commands possibly have no problem to memorize 1K
> mappings Ada unit <-> file name.

The only people who need to memorize this mapping are those that do not
follow a convention that is a trivial rule. 

The GNAT convention for computing a file name from an Ada unit name is
trivial rule; take the unit name, make it lowercase, replace '.' with
'-', add '.ads' or '.adb'. So I don't need to memorize anything beyond
the rule itself.

A convention that says "make up a short name for each unit, and then
tell the compiler about it" requires memory; that is the only way to
know what the file name for a given unit is. This does not scale to
large projects, nor to multiple developers on one project.

You have yet to say what convention you actually prefer. You keep
sidestepping the issue by saying IDEs should not present lists of files.
That is a separate issue.

-- 
-- Stephe

Re: organizing deep source trees with child packages

[Bill Findlay]

On 19/10/2011 07:28, in article m2wrc1qyuu.fsf@pushface.org, "Simon Wright"
<simon@pushface.org> wrote:

> Bill Findlay <yaldnif.w@blueyonder.co.uk> writes:
>  
>> I first encountered emacs in the late 1970s, on our Unix V7 PDP-11/45.
>> That machine had 248K of RAM.  Emacs was several times bigger than the
>> entire store, which supported 16 users well (if emacs was not running)
>> or one user badly (when emacs was running).  I saw no good reason for
>> that extravagance and have not changed my mind since.
> 
> I've just opened GPS, and it's running at 117 Mb (the X11 server I
> wouldn't be running otherwise is at 27 Mb).
> 
> Emacs (open for days, including this newsreader) is at 104 Mb.
> 
> Safari is top at >600 Mb! (Safari + Safari Web Content).

Don't confuse me with facts! 8-)

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: organizing deep source trees with child packages

[Stephen Leake]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Simon Wright <simon@pushface.org> writes:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> You know, Emacs users and us, the others, represent different
>>> species. I'm certain that a scientific study would show that these
>>> don't even interbreed. Each Emacs user must have been abducted by
>>> aliens in flying saucers... (:-))
>>
>> I think the alien part may be the answer. We certainly don't seem to
>> breed true (I only have two data points for this statement :-))
>
> I've been an avid emacs user (indeed I am typing this post in emacs
> right now) since 2000, and my 5-year-old son learned how to type his
> name in the *scratch* buffer of emacs.  How is that for a data point? :)

My daughter does _not_ use Emacs; but she also does not write code. She
uses Google docs for most stuff.

-- 
-- Stephe

Re: organizing deep source trees with child packages

[Niklas Holsti]

On 11-10-18 15:07 , Dmitry A. Kazakov wrote:
> On Tue, 18 Oct 2011 07:12:03 -0400, Stephen Leake wrote:
>

  [ arguments why having many Ada files in the same directory,
    with the Gnat naming, is not a problem ]

I'm on Stephen's side of the debate.

Dmitry again:
> It seems that we are talking
> about different dimensions. My current project has 700+ units.

My current project has 800 units, with Gnat naming conventions, divided 
into not very many directories, according partly to the provenance (e.g. 
OpenToken is in a directory of its own), partly to the choice of 
application platform (e.g. interface implementations for Unix, vs. for 
Windows), partly according to the version of the application.

I often use grep on all files in a directory, and much less often 
find+grep when I need to look at several directories. I think I would 
very much dislike having subdirectories according to the package 
parent-child hierarchy. In this project, the number of children f�r a 
given parent is quite small, usually only one or two, seldom more than five.

The density of generic units and generic instances is also small, so 
perhaps this is more of a "dimensional difference" between this project 
and Dmitry's projects, than the raw number of units.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: organizing deep source trees with child packages

[Ludovic Brenta]

Dmitry A. Kazakov writes on comp.lang.ada:
> You know, Emacs users and us, the others, represent different
> species. I'm certain that a scientific study would show that these
> don't even interbreed. Each Emacs user must have been abducted by
> aliens in flying saucers... (:-))

OK, maybe that's the crux of the problem.  Emacs users can browse, do
not need crutches, and do not want anything to get in the way :)

I may be an extreme example of this.  I use emacs fullscreen, with no
menu bar and no toolbar.  I don't need, use or want a "desktop
environment".  My window manager is ratpoison[1].  I use emacs as a
desktop calculator, telephone directory and organizer; for news and
email, file browsing, and of course programming.

> I have no idea how Martians (sorry, Emacs users (:-)) manage their
> projects. But I cannot remember more than three phone numbers, have a
> mercy! (:-))

I don't remember the key strokes for most Emacs commands, my fingers do.
Really.  Sometimes I have to pause for a moment to explain to new comers
some of the keyboard shortcuts I use constantly.  I use ada-mode to
navigate quickly from spec to body, from generic to all instantiations
thereof, to etc.  While navigating Ada sources, I almost never see a
directory, or a file.  If I need to look for a unit, the name of which I
remember, I use the emacs tags (ETAGS) facility.  As a last resort, I'll
grudgingly browse a directory looking for a file.  Using emacs's power,
of course.

Oh and the system I work on probably consists of a couple thousand
units, at least.

-- 
Ludovic Brenta.
The Chief Human Resources Officer quickly enables our forward plannings
by leveraging the governance.

Re: organizing deep source trees with child packages

[Stephen Leake]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Dmitry A. Kazakov writes on comp.lang.ada:
>> You know, Emacs users and us, the others, represent different
>> species. I'm certain that a scientific study would show that these
>> don't even interbreed. Each Emacs user must have been abducted by
>> aliens in flying saucers... (:-))
>
> OK, maybe that's the crux of the problem.  Emacs users can browse, do
> not need crutches, and do not want anything to get in the way :)
>
> I may be an extreme example of this.  I use emacs fullscreen, with no
> menu bar and no toolbar.  I don't need, use or want a "desktop
> environment".  My window manager is ratpoison[1].  I use emacs as a
> desktop calculator, telephone directory and organizer; for news and
> email, file browsing, and of course programming.

Just for the record, me too, except I keep a real window manager in the
background, for other tools (people insist on sending me non-open-source
docs, and Emacs just doesn't do web very well). 

-- 
-- Stephe

Re: organizing deep source trees with child packages

[Dirk Craeynest]

In article <87ipnmkuvt.fsf@ludovic-brenta.org>,
Ludovic Brenta  <ludovic@ludovic-brenta.org> wrote:
>Oh and the system I work on probably consists of a couple thousand
>units, at least.

At the latest count: 8517 Ada source files to be precise.  Of these,
3681 are specs (suffix .ads) and 4836 are bodies (suffix .adb).

So it's even much more than a couple thousand units...

>-- 
>Ludovic Brenta.
>The Chief Human Resources Officer quickly enables our forward plannings
>by leveraging the governance.

Splendid! ;-)

Dirk
Dirk.Craeynest@cs.kuleuven.be (for Ada-Belgium/-Europe/SIGAda/WG9 mail)

*** 17th Intl.Conf.on Reliable Software Technologies - Ada-Europe'2012
*** June 11-15, 2012 ** Stockholm, Sweden ** http://www.ada-europe.org

Re: organizing deep source trees with child packages

[Stephen Leake]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Tue, 18 Oct 2011 07:12:03 -0400, Stephen Leake wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> Long file names, which are difficult to read.
>> 
>> I guess we'll just have to disagree about that.
>> 
>> Are long package names easier to read?
>
> They are not long, fully qualified names are long.
>  
>>>> When do file names and package names _need_ to be different?
>>>
>>> Always. 
>> 
>> Why? Simple assertions don't get us anywhere.
>
> "c:\mess\foo.adb" /= "Foo"

You seem to be deliberately misrepresenting the question. No one is
talking about the absolute path as "the file name"; we are only talking
about the part of the path that maps to the Ada package name.

So far, the choices seem to be:

package name        Foo.Bar.Baz
gnat convention     foo-bar-baz.ads
"java"              foo/bar/baz.ads
gnatkr              f-barbaz.ads
something else      fobaba.ads
    
Which of these is best, and why? 

I vote for the gnat convention, because the mapping is trivial, and
directories are a pain.

>>> Especially when you have hundreds of generic package instances popping
>>> everywhere. 
>> 
>> Why are generics a special case? 
>
> Because they add a multiplication factor in the number of packages for each
> varying generic formal parameter. 

If the same packages were implemented without generics, there would be
the same number of files (minus the actual generic files). I don't see
that as a significant issue in this discussion.

> Generics also adds a layer of indirection instance <-> generic-body.
> It is just impossible to remember which is an instance of what and
> where are instances with particular parameters.

Why is it necessary to _remember_ that? What does this have to do with
file names? Unless you are attempting to encode all of that information
in the file name and/or the package name, you are just confusing things
by bringing this into the discussion.

>>> Pushing files into different directories makes things only worse. 
>> 
>> How, exactly?
>
> You must also remember the directories. If you need to find a unit you
> first have to go to its directory and then start searching.

Yes, I agree; that's why I have only a few directories, each with
hundreds of files.
>
>>> The point is, when browsing a project you are not interested in files,
>> 
>> Depends on exactly why I'm "browsing".
>
> While programming/reviewing/testing/debugging an Ada program.

Still not specific enough. What demands do the various activities place
on the browser?

I do that all day, and never feel the need for anything more than the
Emacs file browser, together with Emacs Ada mode navigation, gives me.
Which means I'm either "looking for a file" in the file browser, or
"finding the spec/body for this identifier".

>>> you are looking for Ada units, 
>> 
>> Ok, I'll suppose I'm "browsing for Ada units". I'm still not clear what that
>> means in detail. 
>> 
>> If I'm _searching_ for an Ada unit that deals with lists, I
>> either:
>> 
>> 1) remember the full name exactly, and navigate there by file name
>> (which matches the package name)
>> 
>> 2) open a directory that contains the library that probably contains the
>> lists packages, and search for the string "list" in the file names.
>> 
>> If the IDE provides some other way to search for "list" in package
>> names, that would be equally useful. (Does GPS let you search for
>> strings in its file or package browser?)
>
> It does, but it is far slower than browsing, because it involves typing,
> browsing the results of the search, and is contaminated by the results
> coming from with/use.

So the Emacs file browser is more efficient for this task. I find it
more efficient for all tasks :).

>> Maybe the real solution is to use Emacs instead of GPS or Eclipse (or
>> anything else)? Every time I compare the three, Emacs wins hands down on
>> features that contribute to real productivity.
>
> You know, Emacs users and us, the others, represent different species. I'm
> certain that a scientific study would show that these don't even
> interbreed. Each Emacs user must have been abducted by aliens in flying
> saucers... (:-))

Yes, it often seems that way.

That doesn't mean we can't have a technical discussion, to understand
what the issues are, and how to improve both Emacs and GPS to make them
both better.

>>> and it is absolutely irrelevant what is the file name of that unit.
>> 
>> Ok. But I can take advantage of that fact if it happens to be true.
>> 
>> In the above scenario, if the file names do not contain the full package
>> name, I could use 'grep list *.ads', but that's less reliable, since it
>> would find instances of "list" in the rest of the package spec, not just
>> the package name. Building a regexp to match only package names is
>> possible, but not trivial.
>> 
>> 
>> What are some other use cases for "browsing"?
>
> Browsing is more like looking at the list of packages to see how they are
> related etc. 

File names give very little information on that. 

I don't think I learned anything from this message.

-- 
-- Stephe

Re: organizing deep source trees with child packages

[Dmitry A. Kazakov]

On Tue, 18 Oct 2011 21:51:15 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Tue, 18 Oct 2011 07:12:03 -0400, Stephen Leake wrote:
>>
>>>>> When do file names and package names _need_ to be different?
>>>>
>>>> Always. 
>>> 
>>> Why? Simple assertions don't get us anywhere.
>>
>> "c:\mess\foo.adb" /= "Foo"
> 
> You seem to be deliberately misrepresenting the question.

What was the question so was the answer, the package name is always
different from its file name.

> No one is
> talking about the absolute path as "the file name"; we are only talking
> about the part of the path that maps to the Ada package name.
> 
> So far, the choices seem to be:
> 
> package name        Foo.Bar.Baz
> gnat convention     foo-bar-baz.ads
> "java"              foo/bar/baz.ads
> gnatkr              f-barbaz.ads
> something else      fobaba.ads
>     
> Which of these is best, and why? 

My answer to this question was: I would not care about the convention if
the IDE showed me Ada units. Since the IDE, I am using (GPS), shows file
names, I would prefer a convention which eliminates as much as possible of
the mess introduced by the file system. My guess is that the Java
convention would possibly do it better than the GNAT convention.

But again, if the IDE showed units in their relationships (parent-child,
generic-instance, parent-separate body) rather than files, the problem
would disappear.

> I vote for the gnat convention, because the mapping is trivial, and
> directories are a pain.

Yes, they are when the tools are feeble. With proper tools you would not
care.

>> Generics also adds a layer of indirection instance <-> generic-body.
>> It is just impossible to remember which is an instance of what and
>> where are instances with particular parameters.
> 
> Why is it necessary to _remember_ that?

In order to find it. E.g. let you have the type Loudness and for some
reason need a logarithm of its value. You remember that you have already
instantiated Ada.Numerics.Elementary_Functions with Loudness as the
parameter somewhere, but need to remember the package name in order to
"with" it. You probably instantiated Float_IO too, where it was?

Now that was just a trivial example for which some naming schema could
easily be deployed in order to help with that. I am talking about projects
which *do* use generics, of multiple generic parameters, child generic
units etc.

> What does this have to do with
> file names?

Each generic instance is located in some file.

>>>> The point is, when browsing a project you are not interested in files,
>>> 
>>> Depends on exactly why I'm "browsing".
>>
>> While programming/reviewing/testing/debugging an Ada program.
> 
> Still not specific enough. What demands do the various activities place
> on the browser?

Because you cannot see all units of the project at once, not even their
names.
 
> That doesn't mean we can't have a technical discussion, to understand
> what the issues are, and how to improve both Emacs and GPS to make them
> both better.

Not really, because to me the starting point for such discussion is the
precondition that an *Ada IDE* shall show *Ada* projects, *Ada* units,
*Ada* types, not files. It seems that Emacs users disagree with this
precondition telling me how exciting it is to find|grep directories.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: organizing deep source trees with child packages

[Ludovic Brenta]

Dmitry A. Kazakov wrote on comp.lang.ada:
> My answer to this question was: I would not care about the convention if
> the IDE showed me Ada units. Since the IDE, I am using (GPS), shows file
> names, I would prefer a convention which eliminates as much as possible of
> the mess introduced by the file system.

I agree with this.

> My guess is that the Java
> convention would possibly do it better than the GNAT convention.

Here you are contradicting yourself; you think that introducing more
of the "mess introduced by the filesystem" will fix the problem.  It
won't.  Placing all of your source files in one, or a few, directories
will not solve the problem either, but at least it will not make it
worse.

> But again, if the IDE showed units in their relationships (parent-child,
> generic-instance, parent-separate body) rather than files, the problem
> would disappear.

Correct.  In my daily usage, I almost never have to browse a
filesystem because my IDE (Emacs) allows me to navigate the code
efficiently.

>> I vote for the gnat convention, because the mapping is trivial, and
>> directories are a pain.
>
> Yes, they are when the tools are feeble. With proper tools you would not
> care.

But you will always have to use a feeble tool at one point or
another.  Think of version control systems, backup systems, pretty-
printers, find+grep, etc. which do not know, or want to know, about
file naming conventions or the semantics of Ada.  For these tools,
keeping the filesystem layout simple is better.  Granted, the tools I
mentioned are not "feeble" but making them work in the presence of
multiple levels of directories is an additional and unnecessary
hassle.

>>> Generics also adds a layer of indirection instance <-> generic-body.
>>> It is just impossible to remember which is an instance of what and
>>> where are instances with particular parameters.
>
>> Why is it necessary to _remember_ that?
>
> In order to find it. E.g. let you have the type Loudness and for some
> reason need a logarithm of its value. You remember that you have already
> instantiated Ada.Numerics.Elementary_Functions with Loudness as the
> parameter somewhere, but need to remember the package name in order to
> "with" it. You probably instantiated Float_IO too, where it was?

The software I work on has been in existence for much longer than my
presence here.  I cannot possibly remember generic instantiations made
ten years ago by someone else but I can easily find them using
gnatfind, which is integrated in emacs.  I simply do C-c C-r on the
spec of the generic and I can discover all instantiations of it.  In
fact I have already removed some redundant instantiations after
discovering them that way.  Remembering all of the code is not my job;
my job is to *understand* the code.  I have excellent tools that do
the remembering for me.

> Now that was just a trivial example for which some naming schema could
> easily be deployed in order to help with that. I am talking about projects
> which *do* use generics, of multiple generic parameters, child generic
> units etc.

A file naming scheme does not help with generic instantiations because
some generic instantiations are nested in other units and therefore
not in a file of their own.

>> What does this have to do with file names?
>
> Each generic instance is located in some file.

Yes but there is absolutely no correspondence between the name of the
file, the name of the generic instantiation, or the name of the
generic itself.  Especially with generic instantiations inside package
bodies or even inside subprograms (e.g. passive iterators).  Also, one
file can contain multiple generic instantiations.  Therefore, no
naming convention can help discover or find generic instantiations.
Only semantic navigation can.

> Not really, because to me the starting point for such discussion is the
> precondition that an *Ada IDE* shall show *Ada* projects, *Ada* units,
> *Ada* types, not files. It seems that Emacs users disagree with this
> precondition telling me how exciting it is to find|grep directories.

I am an emacs user an I am telling you exactly the opposite.  Emacs is
great at hiding the very existence of files because its semantic
browsing capabilities are outstanding.  Because of this, "organizing"
files in multiple directories gives zero benefit to emacs, but is a
nuisance for some other tools, which we *also* have to use from time
to time.  Since, of course, emacs users launch these other tools from
emacs, it is quite natural that, when they do occasionally need to
browse a file system, they should prefer a very simple directory
layout, and should not be afraid, or surprised, to see hundreds, even
thousands of files in the same directory.

--
Ludovic Brenta.

Re: organizing deep source trees with child packages

[Dmitry A. Kazakov]

On Wed, 19 Oct 2011 02:52:50 -0700 (PDT), Ludovic Brenta wrote:

> Placing all of your source files in one, or a few, directories
> will not solve the problem either, but at least it will not make it
> worse.

There is a case when you need directories, that is OS/Debugging support.
Usually I have files with the same names containing OS-dependent
implementations selected by a GPR scenario variable.

>>> I vote for the gnat convention, because the mapping is trivial, and
>>> directories are a pain.
>>
>> Yes, they are when the tools are feeble. With proper tools you would not
>> care.
> 
> But you will always have to use a feeble tool at one point or
> another.  Think of version control systems, backup systems, pretty-
> printers, find+grep, etc. which do not know, or want to know, about
> file naming conventions or the semantics of Ada.

What the use of them then? Except for backup which stores the whole file
system anyway, the version control system must know Ada in order to build
release versions, build and run automatic tests. The pretty printer must
know it to be pretty, grep (or some more decent thing) must know Ada in
order to search Ada sources by contents.

>> Now that was just a trivial example for which some naming schema could
>> easily be deployed in order to help with that. I am talking about projects
>> which *do* use generics, of multiple generic parameters, child generic
>> units etc.
> 
> A file naming scheme does not help with generic instantiations because
> some generic instantiations are nested in other units and therefore
> not in a file of their own.

Right, that is why IDE must know Ada.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: organizing deep source trees with child packages

[Ludovic Brenta]

Dmitry A. Kazakov wrote on comp.lang.ada:
> Ludovic Brenta wrote:
>> Placing all of your source files in one, or a few, directories
>> will not solve the problem either, but at least it will not make it
>> worse.
>
> There is a case when you need directories, that is OS/Debugging support.
> Usually I have files with the same names containing OS-dependent
> implementations selected by a GPR scenario variable.

This is one of a few cases, with shared libraries, where directories
may be OK.  But, for multiple possible files corresponding to a unit,
it is also possible to use files with different names in a single
directory.  This is what GNAT does for example.

>>>> I vote for the gnat convention, because the mapping is trivial, and
>>>> directories are a pain.
>
>>> Yes, they are when the tools are feeble. With proper tools you would not
>>> care.
>
>> But you will always have to use a feeble tool at one point or
>> another.  Think of version control systems, backup systems, pretty-
>> printers, find+grep, etc. which do not know, or want to know, about
>> file naming conventions or the semantics of Ada.
>
> What the use of them then? Except for backup which stores the whole file
> system anyway, the version control system must know Ada in order to build
> release versions, build and run automatic tests. The pretty printer must
> know it to be pretty, grep (or some more decent thing) must know Ada in
> order to search Ada sources by contents.

Except that existing version control systems do not know Ada and do
not build or run tests; these are the jobs of other tools, which do
not know Ada either.

> Right, that is why IDE must know Ada.

Yes but I also need good support for C, Bourne shell, SQL, flat files,
and occasionally some other languages too.  With a unified way to find
any entity defined in any of them (e.g. a C function imported in Ada,
a shell script calling an executable compiled from Ada, a flat file
containing the name of a database column which is also referenced in
Ada and SQL, etc.).  Sometimes, we simply have to fall back on find
and grep.

--
Ludovic Brenta.

Re: organizing deep source trees with child packages

[Yannick Duchêne (Hibou57)]

Le Wed, 19 Oct 2011 18:43:21 +0200, Ludovic Brenta  
<ludovic@ludovic-brenta.org> a écrit:
> Yes but I also need good support for C, Bourne shell, SQL, flat files,
> and occasionally some other languages too.  With a unified way to find
> any entity defined in any of them (e.g. a C function imported in Ada,
> a shell script calling an executable compiled from Ada, a flat file
> containing the name of a database column which is also referenced in
> Ada and SQL, etc.).  Sometimes, we simply have to fall back on find
> and grep.
Meta-language and tagging could help.


-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: organizing deep source trees with child packages

[Ludovic Brenta]

Yannick Duchêne writes on comp.lang.ada:
> Le Wed, 19 Oct 2011 18:43:21 +0200, Ludovic Brenta
> <ludovic@ludovic-brenta.org> a écrit:
>> Yes but I also need good support for C, Bourne shell, SQL, flat files,
>> and occasionally some other languages too.  With a unified way to find
>> any entity defined in any of them (e.g. a C function imported in Ada,
>> a shell script calling an executable compiled from Ada, a flat file
>> containing the name of a database column which is also referenced in
>> Ada and SQL, etc.).  Sometimes, we simply have to fall back on find
>> and grep.
> Meta-language and tagging could help.

Tagging helps.  Massively.  I think I mentioned my heavy use of Emacs
Tags.

-- 
Ludovic Brenta.
A non-linear timeline technically synergizes the enablers. 

Re: organizing deep source trees with child packages

[Stephen Leake]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

>>> Generics also adds a layer of indirection instance <-> generic-body.
>>> It is just impossible to remember which is an instance of what and
>>> where are instances with particular parameters.
>> 
>> Why is it necessary to _remember_ that?
>
> In order to find it. E.g. let you have the type Loudness and for some
> reason need a logarithm of its value. You remember that you have already
> instantiated Ada.Numerics.Elementary_Functions with Loudness as the
> parameter somewhere, but need to remember the package name in order to
> "with" it. You probably instantiated Float_IO too, where it was?
>
> Now that was just a trivial example for which some naming schema could
> easily be deployed in order to help with that. 

Yes, that is the solution, and it works for the non-trivial real
projects I work on. I have rules for naming generics, and for placing
them in the proper directories, so everyone can find them.

>> That doesn't mean we can't have a technical discussion, to understand
>> what the issues are, and how to improve both Emacs and GPS to make them
>> both better.
>
> Not really, because to me the starting point for such discussion is the
> precondition that an *Ada IDE* shall show *Ada* projects, *Ada* units,
> *Ada* types, not files. 

You are presupposing the solution, which makes it impossible to discuss
the rationale for that solution.

> It seems that Emacs users disagree with this precondition telling me
> how exciting it is to find|grep directories.

I never said it was "exciting". I simply offered that as one possible
solution, to one particular problem. In fact, I presented find|grep as
an undesirable solution, and presented better ones.

In order to have a useful discussion, you need to actively search for
areas of agreement; we agree that find|grep is not a very good solution.

I do disagree that an IDE should work only for one particular language.
I have never worked on any project that was 100% pure Ada, or any other
language. There are always documents written in LaTeX or other formats,
small bits of interface code written in other languages, Makefiles,
compiler configuration files, web pages, and other files that I need to
access. I much prefer using one IDE to do all of that, rather than
switching between IDEs based on the file type. Since the basic tasks are
"find the right file" and "change the text in it", most of the IDE
functionality is shared among the file types. Learning how to use one
IDE well is far more effiicient than learning how to use several IDEs.

-- 
-- Stephe

Re: organizing deep source trees with child packages

[Dmitry A. Kazakov]

On Thu, 20 Oct 2011 06:50:34 -0400, Stephen Leake wrote:

> I do disagree that an IDE should work only for one particular language.

I didn't say that. The IDE must know each language it works with.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: organizing deep source trees with child packages

[Stephen Leake]

Greg Moncreaff <moncreg@gmail.com> writes:

> On Oct 13, 4:20 am, Stephen Leake <stephen_le...@stephe-leake.org>
> wrote:
>>
>> Drop the directory tree; use a flat directory with full file names:
>>
>>
>> In my view, directories are for very large groupings of files; I often
>> have hundreds of Ada files in one directory.
>>
>
> In this case the files have coherence at the leaf level (same
> functional group, standard)
> but the middle levels will change (new adds, old removes)
>
> 100's of files?  unless it was auto generated from a domain model,

No, all hand-written over several years.

> how can you possibly keep it organized as to what depends on what,

That's what "with" is for; the file names don't indicate that (and
therefore your directory names don't either).

> what is separable, 

I'm not clear what you mean my "separable". In one sense, every Ada file
is already "separate".

'with' indicates everything needed for successful compilation, and
therefore for successful operation.

> reusable;

There are some directories, just not nearly as many as you have. My GDS
project looks like this:

sal; reusable
    math and data structures

opentoken; reusable

common ; reusable
    base
        core infrastructure
    models
        standard modules
    hardware
        interfacing to real hardware (analog IO, digital IO)
    1553
        modules that send packets over 1553
    spacewire
        modules that send packets over spacewire

mission; mission specific combinations of sal, common
    
80% of the code is in sal, opentoken, common.

each directory has a 'test' subdirectory.

> what deals with one interface/component/ peer vs another,

The file names don't really do that; how do you tell that
gds-models-reaction_wheel-adcole needs to interface to
gds-hardware-analog_out, but gds-models-reaction_wheel-gsfc needs to
interface to gds-hardware-1553?

In GDS, that information is implicit in the types of the input/output
symbols declared by the modules (these are _not_ just Ada parameter
lists, but items in a runtime symbol table). It is also stated in the
GDS user guide.

Repeating the file name in the directory name doesn't add any
information. So how do you do this?

The high level directory grouping is useful. Although if I was starting
over, I'd move the 1553 and spacewire directories into the hardware
directory; there's really no need to keep them separate. They were
separate in the first place because I was not sure how complicated they
would be when first starting on them, and because the tests were
structured differently than the other hardware tests. But that
difference has become less over time, as I've refactored things.


Give me a specific example; when is repeating the file name in the
directory name useful? 

What operation is possible/much more efficient on a directory with only
a few files than on a directory with lots of files?

Searching is easier in a flat directory; to find all of the files that
mention "serial", I can just do 'grep' in the common/hardware directory.
With your convention, I'd have to do 'find | grep'. Not a huge deal,
but not necessary, either. Sometimes I have to do find | grep as well,
since I do have some directories.

Organizing the tests is simpler in flat directories; it's much easier to
tell that you've got all the tests listed in the test harness.

People can get used to anything; it's often hard to really analyze why
we like a particular system, beyond "that's what I'm used to".

-- 
-- Stephe