* organizing deep source trees with child packages @ 2011-10-12 23:38 Greg Moncreaff 2011-10-13 1:27 ` Yannick Duchêne (Hibou57) ` (2 more replies) 0 siblings, 3 replies; 55+ messages in thread From: Greg Moncreaff @ 2011-10-12 23:38 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-12 23:38 organizing deep source trees with child packages Greg Moncreaff @ 2011-10-13 1:27 ` Yannick Duchêne (Hibou57) 2011-10-13 2:07 ` Greg Moncreaff 2011-10-13 4:21 ` Per Sandberg 2011-10-13 8:20 ` Stephen Leake 2 siblings, 1 reply; 55+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-10-13 1:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-13 1:27 ` Yannick Duchêne (Hibou57) @ 2011-10-13 2:07 ` Greg Moncreaff 2011-10-13 3:52 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 55+ messages in thread From: Greg Moncreaff @ 2011-10-13 2:07 UTC (permalink / raw) 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 "/"; ??????? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-13 2:07 ` Greg Moncreaff @ 2011-10-13 3:52 ` Yannick Duchêne (Hibou57) 2011-10-13 3:55 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 55+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-10-13 3:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-13 3:52 ` Yannick Duchêne (Hibou57) @ 2011-10-13 3:55 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 55+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-10-13 3:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-12 23:38 organizing deep source trees with child packages Greg Moncreaff 2011-10-13 1:27 ` Yannick Duchêne (Hibou57) @ 2011-10-13 4:21 ` Per Sandberg 2011-10-13 8:20 ` Stephen Leake 2 siblings, 0 replies; 55+ messages in thread From: Per Sandberg @ 2011-10-13 4:21 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-12 23:38 organizing deep source trees with child packages Greg Moncreaff 2011-10-13 1:27 ` Yannick Duchêne (Hibou57) 2011-10-13 4:21 ` Per Sandberg @ 2011-10-13 8:20 ` Stephen Leake 2011-10-13 13:19 ` Greg Moncreaff 2 siblings, 1 reply; 55+ messages in thread From: Stephen Leake @ 2011-10-13 8:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-13 8:20 ` Stephen Leake @ 2011-10-13 13:19 ` Greg Moncreaff 2011-10-13 14:18 ` Ludovic Brenta 2011-10-14 11:55 ` Stephen Leake 0 siblings, 2 replies; 55+ messages in thread From: Greg Moncreaff @ 2011-10-13 13:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-13 13:19 ` Greg Moncreaff @ 2011-10-13 14:18 ` Ludovic Brenta 2011-10-13 22:25 ` Yannick Duchêne (Hibou57) 2011-10-14 11:55 ` Stephen Leake 1 sibling, 1 reply; 55+ messages in thread From: Ludovic Brenta @ 2011-10-13 14:18 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-13 14:18 ` Ludovic Brenta @ 2011-10-13 22:25 ` Yannick Duchêne (Hibou57) 2011-10-14 1:44 ` Randy Brukardt 2011-10-14 7:27 ` Dmitry A. Kazakov 0 siblings, 2 replies; 55+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-10-13 22:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-13 22:25 ` Yannick Duchêne (Hibou57) @ 2011-10-14 1:44 ` Randy Brukardt 2011-10-14 2:40 ` Yannick Duchêne (Hibou57) 2011-10-14 7:27 ` Dmitry A. Kazakov 1 sibling, 1 reply; 55+ messages in thread From: Randy Brukardt @ 2011-10-14 1:44 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-14 1:44 ` Randy Brukardt @ 2011-10-14 2:40 ` Yannick Duchêne (Hibou57) 2011-10-16 12:38 ` Stephen Leake 0 siblings, 1 reply; 55+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-10-14 2:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-14 2:40 ` Yannick Duchêne (Hibou57) @ 2011-10-16 12:38 ` Stephen Leake 0 siblings, 0 replies; 55+ messages in thread From: Stephen Leake @ 2011-10-16 12:38 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-13 22:25 ` Yannick Duchêne (Hibou57) 2011-10-14 1:44 ` Randy Brukardt @ 2011-10-14 7:27 ` Dmitry A. Kazakov 2011-10-14 7:42 ` Yannick Duchêne (Hibou57) 2011-10-16 12:51 ` Stephen Leake 1 sibling, 2 replies; 55+ messages in thread From: Dmitry A. Kazakov @ 2011-10-14 7:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-14 7:27 ` Dmitry A. Kazakov @ 2011-10-14 7:42 ` Yannick Duchêne (Hibou57) 2011-10-16 12:51 ` Stephen Leake 1 sibling, 0 replies; 55+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-10-14 7:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-14 7:27 ` Dmitry A. Kazakov 2011-10-14 7:42 ` Yannick Duchêne (Hibou57) @ 2011-10-16 12:51 ` Stephen Leake 2011-10-16 13:43 ` Dmitry A. Kazakov 1 sibling, 1 reply; 55+ messages in thread From: Stephen Leake @ 2011-10-16 12:51 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-16 12:51 ` Stephen Leake @ 2011-10-16 13:43 ` Dmitry A. Kazakov 2011-10-16 18:51 ` Shark8 ` (3 more replies) 0 siblings, 4 replies; 55+ messages in thread From: Dmitry A. Kazakov @ 2011-10-16 13:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-16 13:43 ` Dmitry A. Kazakov @ 2011-10-16 18:51 ` Shark8 2011-10-16 19:19 ` Ludovic Brenta 2011-10-16 20:20 ` Yannick Duchêne (Hibou57) ` (2 subsequent siblings) 3 siblings, 1 reply; 55+ messages in thread From: Shark8 @ 2011-10-16 18:51 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-16 18:51 ` Shark8 @ 2011-10-16 19:19 ` Ludovic Brenta 2011-10-17 7:04 ` Simon Wright 0 siblings, 1 reply; 55+ messages in thread From: Ludovic Brenta @ 2011-10-16 19:19 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-16 19:19 ` Ludovic Brenta @ 2011-10-17 7:04 ` Simon Wright 2011-10-17 7:19 ` Ludovic Brenta 0 siblings, 1 reply; 55+ messages in thread From: Simon Wright @ 2011-10-17 7:04 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-17 7:04 ` Simon Wright @ 2011-10-17 7:19 ` Ludovic Brenta 2011-10-17 7:48 ` Simon Wright 0 siblings, 1 reply; 55+ messages in thread From: Ludovic Brenta @ 2011-10-17 7:19 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-17 7:19 ` Ludovic Brenta @ 2011-10-17 7:48 ` Simon Wright 2011-10-17 7:56 ` Ludovic Brenta 0 siblings, 1 reply; 55+ messages in thread From: Simon Wright @ 2011-10-17 7:48 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-17 7:48 ` Simon Wright @ 2011-10-17 7:56 ` Ludovic Brenta 2011-10-17 10:27 ` Simon Wright 0 siblings, 1 reply; 55+ messages in thread From: Ludovic Brenta @ 2011-10-17 7:56 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-17 7:56 ` Ludovic Brenta @ 2011-10-17 10:27 ` Simon Wright 2011-10-17 13:37 ` Ludovic Brenta 0 siblings, 1 reply; 55+ messages in thread From: Simon Wright @ 2011-10-17 10:27 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-17 10:27 ` Simon Wright @ 2011-10-17 13:37 ` Ludovic Brenta 0 siblings, 0 replies; 55+ messages in thread From: Ludovic Brenta @ 2011-10-17 13:37 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-16 13:43 ` Dmitry A. Kazakov 2011-10-16 18:51 ` Shark8 @ 2011-10-16 20:20 ` Yannick Duchêne (Hibou57) 2011-10-17 7:09 ` Simon Wright 2011-10-18 11:12 ` Stephen Leake 3 siblings, 0 replies; 55+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-10-16 20:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-16 13:43 ` Dmitry A. Kazakov 2011-10-16 18:51 ` Shark8 2011-10-16 20:20 ` Yannick Duchêne (Hibou57) @ 2011-10-17 7:09 ` Simon Wright 2011-10-17 8:07 ` Dmitry A. Kazakov 2011-10-18 11:12 ` Stephen Leake 3 siblings, 1 reply; 55+ messages in thread From: Simon Wright @ 2011-10-17 7:09 UTC (permalink / raw) "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 :-) ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-17 7:09 ` Simon Wright @ 2011-10-17 8:07 ` Dmitry A. Kazakov 0 siblings, 0 replies; 55+ messages in thread From: Dmitry A. Kazakov @ 2011-10-17 8:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-16 13:43 ` Dmitry A. Kazakov ` (2 preceding siblings ...) 2011-10-17 7:09 ` Simon Wright @ 2011-10-18 11:12 ` Stephen Leake 2011-10-18 13:07 ` Dmitry A. Kazakov 3 siblings, 1 reply; 55+ messages in thread From: Stephen Leake @ 2011-10-18 11:12 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-18 11:12 ` Stephen Leake @ 2011-10-18 13:07 ` Dmitry A. Kazakov 2011-10-18 16:55 ` Simon Wright ` (3 more replies) 0 siblings, 4 replies; 55+ messages in thread From: Dmitry A. Kazakov @ 2011-10-18 13:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-18 13:07 ` Dmitry A. Kazakov @ 2011-10-18 16:55 ` Simon Wright 2011-10-18 18:25 ` Ludovic Brenta 2011-10-18 17:31 ` Niklas Holsti ` (2 subsequent siblings) 3 siblings, 1 reply; 55+ messages in thread From: Simon Wright @ 2011-10-18 16:55 UTC (permalink / raw) "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 :-)) ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-18 16:55 ` Simon Wright @ 2011-10-18 18:25 ` Ludovic Brenta 2011-10-18 18:57 ` Simon Wright 2011-10-19 1:52 ` Stephen Leake 0 siblings, 2 replies; 55+ messages in thread From: Ludovic Brenta @ 2011-10-18 18:25 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-18 18:25 ` Ludovic Brenta @ 2011-10-18 18:57 ` Simon Wright 2011-10-18 22:00 ` Bill Findlay 2011-10-19 1:52 ` Stephen Leake 1 sibling, 1 reply; 55+ messages in thread From: Simon Wright @ 2011-10-18 18:57 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-18 18:57 ` Simon Wright @ 2011-10-18 22:00 ` Bill Findlay 2011-10-19 6:28 ` Simon Wright 0 siblings, 1 reply; 55+ messages in thread From: Bill Findlay @ 2011-10-18 22:00 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-18 22:00 ` Bill Findlay @ 2011-10-19 6:28 ` Simon Wright 2011-10-19 8:29 ` Dmitry A. Kazakov 2011-10-19 13:45 ` Bill Findlay 0 siblings, 2 replies; 55+ messages in thread From: Simon Wright @ 2011-10-19 6:28 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-19 6:28 ` Simon Wright @ 2011-10-19 8:29 ` Dmitry A. Kazakov 2011-10-19 11:52 ` Yannick Duchêne (Hibou57) 2011-10-20 11:00 ` Stephen Leake 2011-10-19 13:45 ` Bill Findlay 1 sibling, 2 replies; 55+ messages in thread From: Dmitry A. Kazakov @ 2011-10-19 8:29 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-19 8:29 ` Dmitry A. Kazakov @ 2011-10-19 11:52 ` Yannick Duchêne (Hibou57) 2011-10-19 12:33 ` Dmitry A. Kazakov 2011-10-20 11:00 ` Stephen Leake 1 sibling, 1 reply; 55+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-10-19 11:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-19 11:52 ` Yannick Duchêne (Hibou57) @ 2011-10-19 12:33 ` Dmitry A. Kazakov 0 siblings, 0 replies; 55+ messages in thread From: Dmitry A. Kazakov @ 2011-10-19 12:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-19 8:29 ` Dmitry A. Kazakov 2011-10-19 11:52 ` Yannick Duchêne (Hibou57) @ 2011-10-20 11:00 ` Stephen Leake 1 sibling, 0 replies; 55+ messages in thread From: Stephen Leake @ 2011-10-20 11:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-19 6:28 ` Simon Wright 2011-10-19 8:29 ` Dmitry A. Kazakov @ 2011-10-19 13:45 ` Bill Findlay 1 sibling, 0 replies; 55+ messages in thread From: Bill Findlay @ 2011-10-19 13:45 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-18 18:25 ` Ludovic Brenta 2011-10-18 18:57 ` Simon Wright @ 2011-10-19 1:52 ` Stephen Leake 1 sibling, 0 replies; 55+ messages in thread From: Stephen Leake @ 2011-10-19 1:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-18 13:07 ` Dmitry A. Kazakov 2011-10-18 16:55 ` Simon Wright @ 2011-10-18 17:31 ` Niklas Holsti 2011-10-18 18:38 ` Ludovic Brenta 2011-10-19 1:51 ` Stephen Leake 3 siblings, 0 replies; 55+ messages in thread From: Niklas Holsti @ 2011-10-18 17:31 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-18 13:07 ` Dmitry A. Kazakov 2011-10-18 16:55 ` Simon Wright 2011-10-18 17:31 ` Niklas Holsti @ 2011-10-18 18:38 ` Ludovic Brenta 2011-10-19 1:55 ` Stephen Leake 2011-10-19 10:41 ` Dirk Craeynest 2011-10-19 1:51 ` Stephen Leake 3 siblings, 2 replies; 55+ messages in thread From: Ludovic Brenta @ 2011-10-18 18:38 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-18 18:38 ` Ludovic Brenta @ 2011-10-19 1:55 ` Stephen Leake 2011-10-19 10:41 ` Dirk Craeynest 1 sibling, 0 replies; 55+ messages in thread From: Stephen Leake @ 2011-10-19 1:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-18 18:38 ` Ludovic Brenta 2011-10-19 1:55 ` Stephen Leake @ 2011-10-19 10:41 ` Dirk Craeynest 1 sibling, 0 replies; 55+ messages in thread From: Dirk Craeynest @ 2011-10-19 10:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-18 13:07 ` Dmitry A. Kazakov ` (2 preceding siblings ...) 2011-10-18 18:38 ` Ludovic Brenta @ 2011-10-19 1:51 ` Stephen Leake 2011-10-19 9:03 ` Dmitry A. Kazakov 3 siblings, 1 reply; 55+ messages in thread From: Stephen Leake @ 2011-10-19 1:51 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-19 1:51 ` Stephen Leake @ 2011-10-19 9:03 ` Dmitry A. Kazakov 2011-10-19 9:52 ` Ludovic Brenta 2011-10-20 10:50 ` Stephen Leake 0 siblings, 2 replies; 55+ messages in thread From: Dmitry A. Kazakov @ 2011-10-19 9:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-19 9:03 ` Dmitry A. Kazakov @ 2011-10-19 9:52 ` Ludovic Brenta 2011-10-19 12:46 ` Dmitry A. Kazakov 2011-10-20 10:50 ` Stephen Leake 1 sibling, 1 reply; 55+ messages in thread From: Ludovic Brenta @ 2011-10-19 9:52 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-19 9:52 ` Ludovic Brenta @ 2011-10-19 12:46 ` Dmitry A. Kazakov 2011-10-19 16:43 ` Ludovic Brenta 0 siblings, 1 reply; 55+ messages in thread From: Dmitry A. Kazakov @ 2011-10-19 12:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-19 12:46 ` Dmitry A. Kazakov @ 2011-10-19 16:43 ` Ludovic Brenta 2011-10-19 20:01 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 55+ messages in thread From: Ludovic Brenta @ 2011-10-19 16:43 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-19 16:43 ` Ludovic Brenta @ 2011-10-19 20:01 ` Yannick Duchêne (Hibou57) 2011-10-19 20:03 ` Ludovic Brenta 0 siblings, 1 reply; 55+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-10-19 20:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-19 20:01 ` Yannick Duchêne (Hibou57) @ 2011-10-19 20:03 ` Ludovic Brenta 0 siblings, 0 replies; 55+ messages in thread From: Ludovic Brenta @ 2011-10-19 20:03 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-19 9:03 ` Dmitry A. Kazakov 2011-10-19 9:52 ` Ludovic Brenta @ 2011-10-20 10:50 ` Stephen Leake 2011-10-20 12:09 ` Dmitry A. Kazakov 1 sibling, 1 reply; 55+ messages in thread From: Stephen Leake @ 2011-10-20 10:50 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-20 10:50 ` Stephen Leake @ 2011-10-20 12:09 ` Dmitry A. Kazakov 0 siblings, 0 replies; 55+ messages in thread From: Dmitry A. Kazakov @ 2011-10-20 12:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: organizing deep source trees with child packages 2011-10-13 13:19 ` Greg Moncreaff 2011-10-13 14:18 ` Ludovic Brenta @ 2011-10-14 11:55 ` Stephen Leake 1 sibling, 0 replies; 55+ messages in thread From: Stephen Leake @ 2011-10-14 11:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
end of thread, other threads:[~2011-10-20 12:08 UTC | newest] Thread overview: 55+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-10-12 23:38 organizing deep source trees with child packages Greg Moncreaff 2011-10-13 1:27 ` Yannick Duchêne (Hibou57) 2011-10-13 2:07 ` Greg Moncreaff 2011-10-13 3:52 ` Yannick Duchêne (Hibou57) 2011-10-13 3:55 ` Yannick Duchêne (Hibou57) 2011-10-13 4:21 ` Per Sandberg 2011-10-13 8:20 ` Stephen Leake 2011-10-13 13:19 ` Greg Moncreaff 2011-10-13 14:18 ` Ludovic Brenta 2011-10-13 22:25 ` Yannick Duchêne (Hibou57) 2011-10-14 1:44 ` Randy Brukardt 2011-10-14 2:40 ` Yannick Duchêne (Hibou57) 2011-10-16 12:38 ` Stephen Leake 2011-10-14 7:27 ` Dmitry A. Kazakov 2011-10-14 7:42 ` Yannick Duchêne (Hibou57) 2011-10-16 12:51 ` Stephen Leake 2011-10-16 13:43 ` Dmitry A. Kazakov 2011-10-16 18:51 ` Shark8 2011-10-16 19:19 ` Ludovic Brenta 2011-10-17 7:04 ` Simon Wright 2011-10-17 7:19 ` Ludovic Brenta 2011-10-17 7:48 ` Simon Wright 2011-10-17 7:56 ` Ludovic Brenta 2011-10-17 10:27 ` Simon Wright 2011-10-17 13:37 ` Ludovic Brenta 2011-10-16 20:20 ` Yannick Duchêne (Hibou57) 2011-10-17 7:09 ` Simon Wright 2011-10-17 8:07 ` Dmitry A. Kazakov 2011-10-18 11:12 ` Stephen Leake 2011-10-18 13:07 ` Dmitry A. Kazakov 2011-10-18 16:55 ` Simon Wright 2011-10-18 18:25 ` Ludovic Brenta 2011-10-18 18:57 ` Simon Wright 2011-10-18 22:00 ` Bill Findlay 2011-10-19 6:28 ` Simon Wright 2011-10-19 8:29 ` Dmitry A. Kazakov 2011-10-19 11:52 ` Yannick Duchêne (Hibou57) 2011-10-19 12:33 ` Dmitry A. Kazakov 2011-10-20 11:00 ` Stephen Leake 2011-10-19 13:45 ` Bill Findlay 2011-10-19 1:52 ` Stephen Leake 2011-10-18 17:31 ` Niklas Holsti 2011-10-18 18:38 ` Ludovic Brenta 2011-10-19 1:55 ` Stephen Leake 2011-10-19 10:41 ` Dirk Craeynest 2011-10-19 1:51 ` Stephen Leake 2011-10-19 9:03 ` Dmitry A. Kazakov 2011-10-19 9:52 ` Ludovic Brenta 2011-10-19 12:46 ` Dmitry A. Kazakov 2011-10-19 16:43 ` Ludovic Brenta 2011-10-19 20:01 ` Yannick Duchêne (Hibou57) 2011-10-19 20:03 ` Ludovic Brenta 2011-10-20 10:50 ` Stephen Leake 2011-10-20 12:09 ` Dmitry A. Kazakov 2011-10-14 11:55 ` Stephen Leake
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox