GPS issues: laundry list

GPS issues: laundry list

[Stephen Leake]

I've only been using GPS a couple of days, but I've got a list of things
that need to be better for me to continue using it:

- The help system is not searchable. I can search within individual pages in
  the web browser, but not within whole documents.

- I can't find a list of current key bindings, neither for a single key,
  nor for all keys. There may be a way to do it, but I couldn't find that
  in the help system (did I mention that's not searchable?)

- I can't change the environment PATH from within GPS. I do this often,
  to change compilers (GNAT 6.3 for frozen projects, 7.0.1 for new,
  Cygwin g++ for monotone, etc).

- I can't change the environment ADA_PROJECT_PATH from within GPS. I
  change that more often than the compiler; typically each project
  requires a different path (mms_version_07, _06; gpm vs mms, lynx 4 vs
  lynx 5, etc). For compiling, I can set it in a Makefile, but GPS
  itself needs it when parsing project files.

  In Emacs Ada mode, setting the 'current project' also sets
  ADA_PROJECT_PATH.

- I can work around the above two by writing shell scripts to set the
  environment, then launch GPS. But then I often end up with two GPS
  running, and I get confused which is which, and they fight each other
  over saving global settings on exit. And exiting my primary interface
  with the computer is annoying; I lose all the ancilliary buffers I had
  open (like the list of things to do today).

- no monotone support in GPS. I had to add that to Emacs as well, so
  that's expected. But it will probably be much harder to get the same
  level of support in GPS, since there was already support for generic
  distributed version control systems in Emacs, and in general writing
  GUI tools is much easier in an interactive environment (although I'm
  not clear on the trade-off between Python and Ada in GPS).

- tab completion and regexp name match on switch buffers. I often have
  dozens of buffers open; tab navigation just does not work in that scenario.

There are some nice things about GPS; the context menus (right click on
an identifier) in particular are much better than in Emacs. And the
indentation engine supports Ada 2012. But that is much less significant
than the above (for me, anyway).

There's no technical reason all of the above could not be implemented in
GPS; that would go a long way toward making it competitive with Emacs.

I think the hardest one to fix is the help system. Help in Emacs is
tightly integrated with Emacs lisp; every lisp function has a doc
string, and the help system can display it, along with a link to the
actual source. Similar for key bindings. You can't do that when you are
displaying help in a separate web browser. But such functionality is
critical when working on writing new features for the system (or fixing
bugs in the existing code). Which I do all the time :).  

But at least it needs a search engine on the GPS documents. I don't
actually know how to that, but such things are clearly possible.

GPS is in Debian, and we could contribute patches to that. But unless
there is a functioning process of merging those patches back into the
main stream, it will be hard to maintain those patches as new versions
of GPS are released.

I understand AdaCore's desire (and commercial need) to maintain control,
in particular to maintain high quality. But perhaps there is some way to
allow more user contribution.

-- 
-- Stephe

Re: GPS issues: laundry list

[Dmitry A. Kazakov]

On Wed, 12 Sep 2012 07:53:21 -0400, Stephen Leake wrote:

> - I can't change the environment ADA_PROJECT_PATH from within GPS. I
>   change that more often than the compiler; typically each project
>   requires a different path (mms_version_07, _06; gpm vs mms, lynx 4 vs
>   lynx 5, etc).

Why don't you use scenario variables for this? I handle multi-targeted
projects (Windows/Linux/VxWorks) using scenarios. It works perfectly well.

> - tab completion and regexp name match on switch buffers. I often have
>   dozens of buffers open; tab navigation just does not work in that scenario.

This is indeed a problem, but I doubt that tab completion could be a
solution, unless you type the names reverse (Ada units tend to have same
prefix and differentiate in the suffix).

For a small project the project view works very well. For large projects,
especially ones with many generic instances, nothing helps. No idea how to
improve that, but tabs and regex are definitely non-starters to me.

> There are some nice things about GPS; the context menus (right click on
> an identifier)

Caution! When the project is large and not completely compiled, right mouse
click may promptly freeze the GPS. There is no hint when this to happen.
However if GPS shows a tooltip upon hovering the item, you may safely right
click on it. Otherwise, you were warned.

> I think the hardest one to fix is the help system.

I never used it and never felt it necessary to have.

> But such functionality is
> critical when working on writing new features for the system (or fixing
> bugs in the existing code).

Why?
 
> GPS is in Debian, and we could contribute patches to that. But unless
> there is a functioning process of merging those patches back into the
> main stream, it will be hard to maintain those patches as new versions
> of GPS are released.

It would be nice to have GPS in Fedora as well. GPS is really a great IDE.

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

Re: GPS issues: laundry list

[Simon Wright]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> - no monotone support in GPS. I had to add that to Emacs as well, so
>   that's expected.

I'm pretty sure there's mtn support in 24.2. But I'm having real trouble
with mtn; ada-france seems to be down, or it might be finger trouble,
but I have to say I never had problems like this with hg, and even git
at least lets me clone a repo.

Re: GPS issues: laundry list

[Marius Amado-Alves]

"For large projects, nothing helps. No idea how to improve that."

Dmitry, you've just created an immortal quote!

"no monotone support"

No Mercurial either:-(

(Mercurial = the successor of Monotone? I recently reviewed a number of VCSs and found Mercurial the best for me, in great part because of the excellent Windows port TortoiseHg.)

I am using GPS only because my project depends on Adacore libraries (AWS, Aunit) that make it necessary to use Adacore to build it. (In a misterious way to me. Gnatmake was such a beautiful tool, everything was clear at last, then suddenly we're back to the black arts age, like with makefiles and autoconf.)

So I am "forced" to use GPS. (I'd rather use Notepad++. I hate visual "studios". Waste of screen space. Visual spagetti. GPS is faulty anyway. Oh, well...)

So I'm learning the "GPS way". Trying to understand the "Project properties" thing. Find it extremely awkward, confusing. A simple thing like putting a source file in a project is ludricously hard.

But I keep going. Some things are very useful viz. the navigation from a reference to its declaration (if the declaration is in the project...)

Re: GPS issues: laundry list

[Simon Wright]

Marius Amado-Alves <amado.alves@gmail.com> writes:

> I am using GPS only because my project depends on Adacore libraries
> (AWS, Aunit) that make it necessary to use Adacore to build it. (In a
> misterious way to me. Gnatmake was such a beautiful tool, everything
> was clear at last, then suddenly we're back to the black arts age,
> like with makefiles and autoconf.)
>
> So I am "forced" to use GPS. (I'd rather use Notepad++. I hate visual
> "studios". Waste of screen space. Visual spagetti. GPS is faulty
> anyway. Oh, well...)
>
> So I'm learning the "GPS way". Trying to understand the "Project
> properties" thing. Find it extremely awkward, confusing. A simple
> thing like putting a source file in a project is ludricously hard.

It sounds to me as though your problems are with GNAT Project rather
than with GPS. GPRbuild[1] is a more-capable cousin of gnatmake, but the
info in [1] mainly applies.

Mostly, you just need to make sure your source _directories_ are in the
project.

> But I keep going. Some things are very useful viz. the navigation from
> a reference to its declaration (if the declaration is in the
> project...)

Emacs ada-mode does this ...

[1] http://docs.adacore.com/gprbuild-docs/html/gprbuild_ug.html

Re: GPS issues: laundry list

[Stephen Leake]

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

> On Wed, 12 Sep 2012 07:53:21 -0400, Stephen Leake wrote:
>
>> - I can't change the environment ADA_PROJECT_PATH from within GPS. I
>>   change that more often than the compiler; typically each project
>>   requires a different path (mms_version_07, _06; gpm vs mms, lynx 4 vs
>>   lynx 5, etc).
>
> Why don't you use scenario variables for this? I handle multi-targeted
> projects (Windows/Linux/VxWorks) using scenarios. It works perfectly
> well.

Scenario variables are defined and used within project files.

ADA_PROJECT_PATH selects which project files to use.

Here's a use case that illustrates the difference:

I have a meta-project (GDS for MMS) that is composed of several GNAT
projects; mms, common, sal

I have several versions of the meta-project at customer sites;
mms_version_07, mms_version_06.

If I want to compile mms_version_06, ADA_PROJECT_PATH must be set to:

mms_version_06/mms/build;mms_version_06/common/build;mms_version_06/sal/build

Similarly, for version 07, it must be set to:

mms_version_07/mms/build;mms_version_07/common/build;mms_version_07/sal/build

How can you do that with scenarios? Note that the source code is
different between the versions, indeed the project files may be
different between the versions.

>> - tab completion and regexp name match on switch buffers. I often have
>>   dozens of buffers open; tab navigation just does not work in that scenario.
>
> This is indeed a problem, but I doubt that tab completion could be a
> solution, unless you type the names reverse (Ada units tend to have same
> prefix and differentiate in the suffix).

In Emacs, I use both; I start by typing a glob that narrows the field,
then tab complete to finish the selection.

> For a small project the project view works very well. For large projects,
> especially ones with many generic instances, nothing helps. No idea how to
> improve that, but tabs and regex are definitely non-starters to me.

Have you actually tried Emacs iswitchb?

>> There are some nice things about GPS; the context menus (right click on
>> an identifier)
>
> Caution! When the project is large and not completely compiled, right mouse
> click may promptly freeze the GPS. There is no hint when this to happen.
> However if GPS shows a tooltip upon hovering the item, you may safely right
> click on it. Otherwise, you were warned.

There are bugs in Emacs, too.

>> I think the hardest one to fix is the help system.
>
> I never used it and never felt it necessary to have.

Amazing. How do you find out how to do anything?

Let me guess; you have a resident guru, who has read the help, and you
just ask them.

Doesn't work for me.

>> But such functionality is
>> critical when working on writing new features for the system (or fixing
>> bugs in the existing code).
>
> Why?

Might as well ask fish why water is necessary.

I take it you have never tried developing code for Emacs in Emacs (or
some similar system).

Have you written GUI code for GPS? For example, added a new feature to
the VCS interface?

Have you tried to debug the crash you describe above?

-- 
-- Stephe

Re: Emacs mtn support

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> - no monotone support in GPS. I had to add that to Emacs as well, so
>>   that's expected.
>
> I'm pretty sure there's mtn support in 24.2. 

I guess you mean Emacs 24.2 (this was a thread about GPS).

Yes, there is very primitive support. But you should try DVC (latest
version in ada-france, or a somewhat earlier version in bzr at
http://www.xsteve.at/prg/emacs_dvc/dvc.html). It provides a _much_
higher level of support.

> But I'm having real trouble with mtn; ada-france seems to be down, or
> it might be finger trouble, but I have to say I never had problems
> like this with hg, and even git at least lets me clone a repo.

monotone exerts stronger control; that does get frustrating sometimes.
But it's very much in the Ada mindset; once you get the program to
compile, it Just Works :).

-- 
-- Stephe

Re: Emacs mtn support

[Simon Wright]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Simon Wright <simon@pushface.org> writes:
>
>> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>>
>>> - no monotone support in GPS. I had to add that to Emacs as well, so
>>>   that's expected.
>>
>> I'm pretty sure there's mtn support in 24.2. 
>
> I guess you mean Emacs 24.2 (this was a thread about GPS).

Not sure what else I might have meant.

> Yes, there is very primitive support. But you should try DVC (latest
> version in ada-france, or a somewhat earlier version in bzr at
> http://www.xsteve.at/prg/emacs_dvc/dvc.html). It provides a _much_
> higher level of support.

The only thing I've missed in Emacs support (which is missing in its SVN
support, too) is the idea that marking a number of files to be committed
should be implemented as one transaction, not one transaction per file.

>> But I'm having real trouble with mtn; ada-france seems to be down, or
>> it might be finger trouble, but I have to say I never had problems
>> like this with hg, and even git at least lets me clone a repo.
>
> monotone exerts stronger control; that does get frustrating sometimes.
> But it's very much in the Ada mindset; once you get the program to
> compile, it Just Works :).

Did you get my e-mail with my signed mtn key?

But the current state is

$ mtn --db ~/monotone-dbs/ada-france.db db init
$ mtn --db ~/monotone-dbs/ada-france.db pull --key '' "mtn://www.ada-france.org?org.emacs.*"
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to mtn://www.ada-france.org?org.emacs.*
mtn: network error: failed to connect: Operation timed out

Re: GPS issues: laundry list

[Dmitry A. Kazakov]

On Thu, 13 Sep 2012 06:55:11 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Wed, 12 Sep 2012 07:53:21 -0400, Stephen Leake wrote:
>>
>>> - I can't change the environment ADA_PROJECT_PATH from within GPS. I
>>>   change that more often than the compiler; typically each project
>>>   requires a different path (mms_version_07, _06; gpm vs mms, lynx 4 vs
>>>   lynx 5, etc).
>>
>> Why don't you use scenario variables for this? I handle multi-targeted
>> projects (Windows/Linux/VxWorks) using scenarios. It works perfectly
>> well.
> 
> Scenario variables are defined and used within project files.
> 
> ADA_PROJECT_PATH selects which project files to use.

I see. Yes, it is a problem with the gpr-project files that one cannot make
a "with" dependent on the scenario.

> How can you do that with scenarios? Note that the source code is
> different between the versions, indeed the project files may be
> different between the versions.

This particular task is rather for a source control system, not for the
IDE. The project file name and its selection must not depend on its
version, IMO.
 
>>> - tab completion and regexp name match on switch buffers. I often have
>>>   dozens of buffers open; tab navigation just does not work in that scenario.
>>
>> This is indeed a problem, but I doubt that tab completion could be a
>> solution, unless you type the names reverse (Ada units tend to have same
>> prefix and differentiate in the suffix).
> 
> In Emacs, I use both; I start by typing a glob that narrows the field,
> then tab complete to finish the selection.

You must have an extraordinary memory to be able to memorize file names. I
bet very few people can do that.

>> For a small project the project view works very well. For large projects,
>> especially ones with many generic instances, nothing helps. No idea how to
>> improve that, but tabs and regex are definitely non-starters to me.
> 
> Have you actually tried Emacs iswitchb?

All people are divided into those who can use Emacs and others. I am in the
second category. Should neurologists ever make brain scans of the Emacs
users, they would certainly find it sufficiently different. Aliens live
among us! (:-))

>>> I think the hardest one to fix is the help system.
>>
>> I never used it and never felt it necessary to have.
> 
> Amazing. How do you find out how to do anything?

There is an old saying that if nothing else works, you may read the manual.
GPS is WYSIWYG. Everything you need, you can guess how to do it by simple
try and error. If you cannot, then, likely, you just don't need it. Why
bother reading anything? (:-))
 
> Let me guess; you have a resident guru, who has read the help, and you
> just ask them.

It would be so nice. Alas, no.

> Doesn't work for me.

Somebody, who can Emacs, who can memorize source file names, does need
on-line help?

>>> But such functionality is
>>> critical when working on writing new features for the system (or fixing
>>> bugs in the existing code).
>>
>> Why?
> 
> Might as well ask fish why water is necessary.
> 
> I take it you have never tried developing code for Emacs in Emacs (or
> some similar system).
> 
> Have you written GUI code for GPS? For example, added a new feature to
> the VCS interface?

Very rudimentary, I modified some menus. Once I saw python and XML, I
backed off. (Who would expect that from AdaCore?)

> Have you tried to debug the crash you describe above?

No, it freezes.

Since GPS is a GTK application, its debugging must be a nightmare, even if
you know the internals of GPS very well. Freezing should have something to
do with a deadlock in an event handler. This is a common case you run into
when designing complex GTK stuff. An extremely nasty thing, I had it
multiple times in my GtkAda projects. On-line help is the last thing that
would assist you here. I would use tracing to catch it.

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

Re: GPS issues: laundry list

[Dmitry A. Kazakov]

On Thu, 13 Sep 2012 02:46:05 -0700 (PDT), Marius Amado-Alves wrote:

> "For large projects, nothing helps. No idea how to improve that."
> 
> Dmitry, you've just created an immortal quote!

(:-))

> Gnatmake was such a beautiful tool, everything was clear at last, then
> suddenly we're back to the black arts age,

Hmm, gprmake is still there:

   gnatmake -Pproject_file

You are not forced to use gprbuild instead, unless you wanted some C/C++
sources in the project. Or, what did you mean?

> So I am "forced" to use GPS. (I'd rather use Notepad++. I hate visual
> "studios".

If you close all GPS windows but the source code window, that will be
exactly the Notepad++'s look-and-feel.

> So I'm learning the "GPS way". Trying to understand the "Project
> properties" thing.

The only thing to understand about it is that you should never ever click
it! Project file is a plain text file in an Ada-like language.

> Find it extremely awkward, confusing. A simple thing
> like putting a source file in a project is ludricously hard.

It is as simple as saving a file. E.g. take an existing project file, then
File -> Save As. That is it!

(you should have

   for Source_Dirs use (directories list);

in the project file. Whatever sources you put in any of the directories,
they go to the project. GPS notices when you save a new Ada file there and
adds it to the project view automatically. The best thing about it is that
doing so, it does not touch the gpr-file.)

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

Re: GPS issues: laundry list

[Markus Schöpflin]

Am 13.09.2012 12:55, schrieb Stephen Leake:

> Have you actually tried Emacs iswitchb?

You just improved my productivity by at least an order of magnitude. :-) I'm a 
long time emacs user and I didn't know about it until now.

Thanks,
Markus

Re: Emacs mtn support

[J-P. Rosen]

Le 13/09/2012 12:58, Stephen Leake a �crit :
> But I'm having real trouble with mtn; ada-france seems to be down, or
> it might be finger trouble, 
I just checked with our sysadmin, no problem on ada-france side.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: GPS issues: laundry list

[mark.lorenzen]

Den torsdag den 13. september 2012 14.37.24 UTC+2 skrev Dmitry A. Kazakov:
> I see. Yes, it is a problem with the gpr-project files that one cannot make
> 
> a "with" dependent on the scenario.

Can't this be solved using an aggregate project? See last example of: http://docs.adacore.com/gprbuild-docs/html/gprbuild_ug.html#Define-a-build-environment

Regards,

Mark L

Re: GPS issues: laundry list

[Marius Amado-Alves]

> The only thing to understand about it is that you should never ever click
> it! Project file is a plain text file in an Ada-like language.

Excellent advice.


> > Find it extremely awkward, confusing. A simple thing
> > like putting a source file in a project is ludricously hard.
> 
> It is as simple as saving a file. E.g. take an existing project file, then
> File -> Save As. That is it!

I know, it should, but then it does not show up in the project view (the tree of things on the left pane). Sometimes (!) it shows up after I restart GPS. (Bug or feature?)

Thanks.

Re: GPS issues: laundry list

[AdaMagica]

On Thursday, September 13, 2012 5:41:56 PM UTC+2, Marius Amado-Alves wrote:
 
> I know, it should, but then it does not show up in the project view (the tree of things on the left pane). Sometimes (!) it shows up after I restart GPS. (Bug or feature?)

Do a Reload Project

Re: GPS issues: laundry list

[Simon Wright]

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

> Hmm, gprmake is still there:

gnatmake. gprmake was, I think, a precursor of gprbuild which lived in
the GCC tree. Shame that gprbuild doesn't.

Re: GPS issues: laundry list

[Simon Wright]

Markus Schöpflin <no.spam@spam.spam> writes:

> Am 13.09.2012 12:55, schrieb Stephen Leake:
>
>> Have you actually tried Emacs iswitchb?
>
> You just improved my productivity by at least an order of
> magnitude. :-) I'm a long time emacs user and I didn't know about it
> until now.

Looks complicated to me. I have mouse-buffer-menu-mode-mult set to 1;
then, when C-down-mouse-1 pops up its menu, you get a first-level menu
of buffer types (eg Ada, Lisp), and second-level menus with all the
buffers of a type under that heading, unless there's only one of a type
in which case it ends up under Others.

Things get less simple when you have more than a screen-heights-worth of
Ada buffers!

Re: GPS issues: laundry list

[Dmitry A. Kazakov]

On Thu, 13 Sep 2012 08:38:13 -0700 (PDT), mark.lorenzen@gmail.com wrote:

> Den torsdag den 13. september 2012 14.37.24 UTC+2 skrev Dmitry A. Kazakov:
>> I see. Yes, it is a problem with the gpr-project files that one cannot make
>> a "with" dependent on the scenario.
> 
> Can't this be solved using an aggregate project? See last example of:
> http://docs.adacore.com/gprbuild-docs/html/gprbuild_ug.html#Define-a-build-environment

Interesting. I missed that somehow, I'll give it a try. Thanks.

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

Re: Emacs mtn support

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> But the current state is
>
> $ mtn --db ~/monotone-dbs/ada-france.db db init
> $ mtn --db ~/monotone-dbs/ada-france.db pull --key ''
> "mtn://www.ada-france.org?org.emacs.*"
> mtn: doing anonymous pull; use -kKEYNAME if you need authentication
> mtn: connecting to mtn://www.ada-france.org?org.emacs.*
> mtn: network error: failed to connect: Operation timed out

OK, I should have said (for the second command)

mtn --db ~/monotone-dbs/ada-france.db pull --key '' mtn://www.ada-france.org "org.emacs.*"

Re: GPS issues: laundry list

[Stephen Leake]

Marius Amado-Alves <amado.alves@gmail.com> writes:

>> The only thing to understand about it is that you should never ever click
>> it! Project file is a plain text file in an Ada-like language.
>
> Excellent advice.
>
>
>> > Find it extremely awkward, confusing. A simple thing
>> > like putting a source file in a project is ludricously hard.
>> 
>> It is as simple as saving a file. E.g. take an existing project file, then
>> File -> Save As. That is it!
>
> I know, it should, but then it does not show up in the project view
> (the tree of things on the left pane). 

It won't show up in the project view in Notepad++ either. Try to be
consistent in what you want :).

> Sometimes (!) it shows up after I restart GPS. (Bug or feature?)

Emacs has an equivalent to the Project View; 'speedbar'. I never use
that, either.

-- 
-- Stephe

Re: GPS issues: laundry list

[Stephen Leake]

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

> On Thu, 13 Sep 2012 06:55:11 -0400, Stephen Leake wrote:
>
> This particular task is rather for a source control system, not for the
> IDE. The project file name and its selection must not depend on its
> version, IMO.

As usual, since you don't have a good answer to the original question,
you are changing the question. You seem to have some good ideas; it is a
shame it is so frustrating attempting to have a conversation with you.

>>>> - tab completion and regexp name match on switch buffers. I often have
>>>>   dozens of buffers open; tab navigation just does not work in that scenario.
>>>
>>> This is indeed a problem, but I doubt that tab completion could be a
>>> solution, unless you type the names reverse (Ada units tend to have same
>>> prefix and differentiate in the suffix).
>> 
>> In Emacs, I use both; I start by typing a glob that narrows the field,
>> then tab complete to finish the selection.
>
> You must have an extraordinary memory to be able to memorize file names. I
> bet very few people can do that.

Say what? That's exactly why I use glob matching; I only remember that I
want a file that deals with "star tracker", I don't remember the
complete name of the file.

On the other hand, I do use a strict naming convention, that helps a
lot.

And I do seem to remember details better than anyone else on my team.

>>> For a small project the project view works very well. For large projects,
>>> especially ones with many generic instances, nothing helps. No idea how to
>>> improve that, but tabs and regex are definitely non-starters to me.
>> 
>> Have you actually tried Emacs iswitchb?
>
> All people are divided into those who can use Emacs and others. I am in the
> second category. Should neurologists ever make brain scans of the Emacs
> users, they would certainly find it sufficiently different. Aliens live
> among us! (:-))

As usual, not actually answering the question.

> Somebody, who can Emacs, who can memorize source file names, does need
> on-line help?

As I indicated in my post, non-searchable help is the biggest problem
with GPS. I use Emacs help all the time, to find out what a particular
function does, or how to go about doing something I haven't done before.

In my real job, I spend quite a bit of time making sure the manuals that
describe our system are correct and up to date. That way, i can just
refer people to the manuals, and don't have to spend time answering the
same questions over and over. The time spent maintaining the manuals is
_very_ well spent! I expect the same from help systems, especially
commercially supported ones.

>> Have you written GUI code for GPS? For example, added a new feature to
>> the VCS interface?
>
> Very rudimentary, I modified some menus. Once I saw python and XML, I
> backed off. (Who would expect that from AdaCore?)

As I understand it, adding simple monotone support is mostly adding
python and XML, so that counts as "writing GUI code".

>> Have you tried to debug the crash you describe above?
>
> No, it freezes.

Ok, there are time when emacs freezes as well, and you are right, online
help is no help then.

But the main point here is this:

> Since GPS is a GTK application, its debugging must be a nightmare, even if
> you know the internals of GPS very well. 

That is _precisely_ why Emacs is better; debugging elisp is _not_ a
nightmare, _because_ it is an interactive system; you can always find
out what function a key invokes, you can find the source code that
implements that function, you can find the source code for all the
functions that calls. And then you can modify one function, and see the
results immediately, without quiting and recreating the current situation.

You get some of that with Ada source code navigation, if you have the
GPS source code compiled, and that project open in GPS. Of course, you
can only have one project open at a time (how limiting!). And you can't
recompile and load just one function.

I suspect the reason you prefer to code in Python and XML is because
they are interactive; you don't have to quit and restart GPS to see the
changes, so you can make small, incremental changes quickly.

-- 
-- Stephe

Re: GPS issues: laundry list

[Stephen Leake]

mark.lorenzen@gmail.com writes:

> Den torsdag den 13. september 2012 14.37.24 UTC+2 skrev Dmitry A. Kazakov:
>> I see. Yes, it is a problem with the gpr-project files that one cannot make
>> 
>> a "with" dependent on the scenario.
>
> Can't this be solved using an aggregate project? See last example of:
> http://docs.adacore.com/gprbuild-docs/html/gprbuild_ug.html#Define-a-build-environment

Ah. So you _can_ set ADA_PROJECT_PATH (and other environment variables)
from within a project file. I missed that; apparently I have not been
keeping up with recent changes in gprbuild. It's time to sit down and
read the whole manual again.

The example has relative paths in Project_Path; that would be perfect for
my needs, actually.

I sent the same list of complaints to AdaCore under my support contract;
it will be interesting to see if they point out this feature.


Thanks for the pointer!

-- 
-- Stephe

Re: GPS issues: laundry list

[Stephen Leake]

Markus Schöpflin <no.spam@spam.spam> writes:

> Am 13.09.2012 12:55, schrieb Stephen Leake:
>
>> Have you actually tried Emacs iswitchb?
>
> You just improved my productivity by at least an order of magnitude.

You're welcome :) That was my reaction when I stumbled on it as well :).

> :-) I'm a long time emacs user and I didn't know about it until now.

That is one problem with Emacs; there is a _lot_ to learn. I learned
about iswitchb on some mailing list.

For a while I ran an "Emacs wizard" contest in my weekly status
meetings; whoever presented the coolest Emacs feature that week
(especially if I had never seen it before) got to keep a little wizard
statue for the week. Found a few good things that way. But it
degenerated into trivia.

One thing to keep in mind; if you find something annoying, you can bet
some other Emacs user found it annoying, and provided a feature to fix
it. Asking on one of the Emacs mailing lists is a good way to find out.

-- 
-- Stephe

Re: GPS issues: laundry list

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> Markus Schöpflin <no.spam@spam.spam> writes:
>
>> Am 13.09.2012 12:55, schrieb Stephen Leake:
>>
>>> Have you actually tried Emacs iswitchb?
>>
>> You just improved my productivity by at least an order of
>> magnitude. :-) I'm a long time emacs user and I didn't know about it
>> until now.
>
> Looks complicated to me. I have mouse-buffer-menu-mode-mult set to 1;
> then, when C-down-mouse-1 pops up its menu, you get a first-level menu
> of buffer types (eg Ada, Lisp), and second-level menus with all the
> buffers of a type under that heading, unless there's only one of a type
> in which case it ends up under Others.
>
> Things get less simple when you have more than a screen-heights-worth of
> Ada buffers!

So you are a rodent-friendly Emacs user; I'm definitely in the
rodent-phobic camp. But Emacs supports both!

-- 
-- Stephe

Re: Emacs mtn support

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> Yes, there is very primitive support. But you should try DVC (latest
>> version in ada-france, or a somewhat earlier version in bzr at
>> http://www.xsteve.at/prg/emacs_dvc/dvc.html). It provides a _much_
>> higher level of support.
>
> The only thing I've missed in Emacs support (which is missing in its SVN
> support, too) is the idea that marking a number of files to be committed
> should be implemented as one transaction, not one transaction per
> file.

Which is the _entire_ point of mtn.

DVC definitely adds that, as well as interactive support for propagating
between branches, with conflict resolution.

>>> But I'm having real trouble with mtn; ada-france seems to be down, or
>>> it might be finger trouble, but I have to say I never had problems
>>> like this with hg, and even git at least lets me clone a repo.
>>
>> monotone exerts stronger control; that does get frustrating sometimes.
>> But it's very much in the Ada mindset; once you get the program to
>> compile, it Just Works :).
>
> Did you get my e-mail with my signed mtn key?

Yes, but I don't actually have access to do anything with it; waiting on
Ludovic.

> But the current state is
>
> $ mtn --db ~/monotone-dbs/ada-france.db db init
> $ mtn --db ~/monotone-dbs/ada-france.db pull --key ''
> "mtn://www.ada-france.org?org.emacs.*"
> mtn: doing anonymous pull; use -kKEYNAME if you need authentication
> mtn: connecting to mtn://www.ada-france.org?org.emacs.*
> mtn: network error: failed to connect: Operation timed out

The error message is saying it can't connect; that's because the name
you gave it is not a valid IP host name.

Your version of mtn (0.48) does not support URLs; you need to use:

$ mtn --db ~/monotone-dbs/ada-france.db pull --key '' www.ada-france.org \
org.emacs.*

Or upgrade to mtn 1.0.

-- 
-- Stephe

Re: Emacs mtn support

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> Simon Wright <simon@pushface.org> writes:
>
>> But the current state is
>>
>> $ mtn --db ~/monotone-dbs/ada-france.db db init
>> $ mtn --db ~/monotone-dbs/ada-france.db pull --key ''
>> "mtn://www.ada-france.org?org.emacs.*"
>> mtn: doing anonymous pull; use -kKEYNAME if you need authentication
>> mtn: connecting to mtn://www.ada-france.org?org.emacs.*
>> mtn: network error: failed to connect: Operation timed out
>
> OK, I should have said (for the second command)
>
> mtn --db ~/monotone-dbs/ada-france.db pull --key '' mtn://www.ada-france.org "org.emacs.*"

Still not right. The first argument must be a valid IP host name;
'www.ada-france.org'. The "mtn:" is implied. Although I may be
remembering wrong: I don't have a 0.48 mtn manual handy.

-- 
-- Stephe

Re: GPS issues: laundry list

[Dmitry A. Kazakov]

On Fri, 14 Sep 2012 03:51:59 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Thu, 13 Sep 2012 06:55:11 -0400, Stephen Leake wrote:
>>
>> This particular task is rather for a source control system, not for the
>> IDE. The project file name and its selection must not depend on its
>> version, IMO.
> 
> As usual, since you don't have a good answer to the original question,
> you are changing the question.

Maybe. But it is still an incredibly bad idea to manage versions by
altering file names.

>>>> For a small project the project view works very well. For large projects,
>>>> especially ones with many generic instances, nothing helps. No idea how to
>>>> improve that, but tabs and regex are definitely non-starters to me.
>>> 
>>> Have you actually tried Emacs iswitchb?
>>
>> All people are divided into those who can use Emacs and others. I am in the
>> second category. Should neurologists ever make brain scans of the Emacs
>> users, they would certainly find it sufficiently different. Aliens live
>> among us! (:-))
> 
> As usual, not actually answering the question.

Didn't I? OK, the answer was no. I don't use Emacs (=> any feature of) and
I don't plan to. I don't enjoy the very idea of "programming" source code
in some kind of programming language. The idea the precursor generation of
tools like Emacs, TeX et al represent. I prefer to concentrate my weak
mental powers solely on typing and gazing Ada.

>> Somebody, who can Emacs, who can memorize source file names, does need
>> on-line help?
> 
> As I indicated in my post, non-searchable help is the biggest problem
> with GPS. I use Emacs help all the time, to find out what a particular
> function does, or how to go about doing something I haven't done before.

That is because you use Emacs as a programming language. GPS is an IDE, it
is not a language. It presumes and encourages an amateurish, casual usage,
which is good.

> In my real job, I spend quite a bit of time making sure the manuals that
> describe our system are correct and up to date. That way, i can just
> refer people to the manuals, and don't have to spend time answering the
> same questions over and over. The time spent maintaining the manuals is
> _very_ well spent! I expect the same from help systems, especially
> commercially supported ones.

Modern-time systems became too complex for a comprehensive up-front dry
training.

> But the main point here is this:
> 
>> Since GPS is a GTK application, its debugging must be a nightmare, even if
>> you know the internals of GPS very well. 
> 
> That is _precisely_ why Emacs is better; debugging elisp is _not_ a
> nightmare, _because_ it is an interactive system; you can always find
> out what function a key invokes, you can find the source code that
> implements that function, you can find the source code for all the
> functions that calls. And then you can modify one function, and see the
> results immediately, without quiting and recreating the current situation.

In my GtkAda programs I hook Glib.Messages, which causes an error window to
pop up with the source code location trace.

The problem is that for GTK the actual error location is never the point
where the error was detected. This is a problem of any event-driven
framework.

> You get some of that with Ada source code navigation, if you have the
> GPS source code compiled, and that project open in GPS. Of course, you
> can only have one project open at a time (how limiting!). And you can't
> recompile and load just one function.

In most cases continuation of a GTK program would be impossible anyway. The
architecture is too tightly coupled. When I am asking for a native Ada
graphical framework that is because I know Win32 and GTK pretty well. And
even Ada has issues.

> I suspect the reason you prefer to code in Python and XML is because
> they are interactive; you don't have to quit and restart GPS to see the
> changes, so you can make small, incremental changes quickly.

"Do not underestimate the power of the Dark Side."

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

Re: GPS issues: laundry list

[Egil Høvik]

On Wednesday, September 12, 2012 1:53:23 PM UTC+2, Stephen Leake wrote:
> - The help system is not searchable. I can search within individual pages in the web browser, but not within whole documents.

My GPS install comes with .html, .pdf and .txt versions of the user guide.
I'm sure it's possible to modify the Help menu to open the .txt file instead of the .html version, if that satisfies your searching needs.


-- 
~egilhh

Re: GPS issues: laundry list

[Simon Wright]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> So you are a rodent-friendly Emacs user; I'm definitely in the
> rodent-phobic camp. But Emacs supports both!

Usually a trackpad-friendly user :-)

Re: Emacs mtn support

[Simon Wright]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Simon Wright <simon@pushface.org> writes:
>
>> Simon Wright <simon@pushface.org> writes:
>>
>>> But the current state is
>>>
>>> $ mtn --db ~/monotone-dbs/ada-france.db db init
>>> $ mtn --db ~/monotone-dbs/ada-france.db pull --key ''
>>> "mtn://www.ada-france.org?org.emacs.*"
>>> mtn: doing anonymous pull; use -kKEYNAME if you need authentication
>>> mtn: connecting to mtn://www.ada-france.org?org.emacs.*
>>> mtn: network error: failed to connect: Operation timed out
>>
>> OK, I should have said (for the second command)
>>
>> mtn --db ~/monotone-dbs/ada-france.db pull --key ''
>> mtn://www.ada-france.org "org.emacs.*"
>
> Still not right. The first argument must be a valid IP host name;
> 'www.ada-france.org'. The "mtn:" is implied. Although I may be
> remembering wrong: I don't have a 0.48 mtn manual handy.

Well, it may not have been right but it did pull the db!

Re: Emacs mtn support

[Simon Wright]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Simon Wright <simon@pushface.org> writes:
>
>> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>>
>>> Yes, there is very primitive support. But you should try DVC (latest
>>> version in ada-france, or a somewhat earlier version in bzr at
>>> http://www.xsteve.at/prg/emacs_dvc/dvc.html). It provides a _much_
>>> higher level of support.
>>
>> The only thing I've missed in Emacs support (which is missing in its SVN
>> support, too) is the idea that marking a number of files to be committed
>> should be implemented as one transaction, not one transaction per
>> file.
>
> Which is the _entire_ point of mtn.

Not sure I'd go that far, but it's also the expected way of using svn,
git, hg ...

> DVC definitely adds that, as well as interactive support for propagating
> between branches, with conflict resolution.

OK, sounds good.

>> Did you get my e-mail with my signed mtn key?
>
> Yes, but I don't actually have access to do anything with it; waiting on
> Ludovic.

OK, thanks.

> Your version of mtn (0.48) does not support URLs; you need to use:
>
> $ mtn --db ~/monotone-dbs/ada-france.db pull --key '' www.ada-france.org \
> org.emacs.*
>
> Or upgrade to mtn 1.0.

Since I'd have to build from sources, which involves building botan,
which involves .. well, 0.48 seems to be OK to use, so I'll stick!

Re: GPS issues: laundry list

[Stephen Leake]

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

> Maybe. But it is still an incredibly bad idea to manage versions by
> altering file names.

You have misunderstood what I'm proposing; I'm not editing file _names_,
just what directory the project is checked out in.

For version 07, the project is in mms_version_07/*. For version 08, the
project is in mms_version_08/*.

How else would you do it?

>>>>> For a small project the project view works very well. For large projects,
>>>>> especially ones with many generic instances, nothing helps. No idea how to
>>>>> improve that, but tabs and regex are definitely non-starters to me.
>>>> 
>>>> Have you actually tried Emacs iswitchb?
>>>
>>> All people are divided into those who can use Emacs and others. I am in the
>>> second category. Should neurologists ever make brain scans of the Emacs
>>> users, they would certainly find it sufficiently different. Aliens live
>>> among us! (:-))
>> 
>> As usual, not actually answering the question.
>
> Didn't I? OK, the answer was no. I don't use Emacs (=> any feature of) and
> I don't plan to. 

"not using on a regular basis" is _not_ the same as "try it to see what
it's like".

I've tried vi, Eclipse, GPS, Visual *, all to be sure I'm not missing
anything in Emacs. I only use Emacs on a regular basis.

> I don't enjoy the very idea of "programming" source code in some kind
> of programming language. The idea the precursor generation of tools
> like Emacs, TeX et al represent. 

I don't understand this point. 

You seem to think that writing Ada code in Emacs is somehow
significantly different than writing Ada code in GPS; I don't find it to
be so. Except that the eye candy in GPS is distracting, but I suspect
I'll get used to it.

Writing documents in LaTeX is significantly different than writing
documents in OpenOffice; markup vs WYSIWYG. But that's not what _this_
thread is about.

> I prefer to concentrate my weak mental powers solely on typing and
> gazing Ada.

What else does Emacs require you to do?

You don't _have_ to write elisp to use Emacs, just as you don't _have_
to write Python and XML to use GPS. 

>>> Somebody, who can Emacs, who can memorize source file names, does need
>>> on-line help?
>> 
>> As I indicated in my post, non-searchable help is the biggest problem
>> with GPS. I use Emacs help all the time, to find out what a particular
>> function does, or how to go about doing something I haven't done before.
>
> That is because you use Emacs as a programming language. 

No, I use elisp as a programming language, to customize Emacs.

> GPS is an IDE, it is not a language. 

Correct. But I can customize it by writing Python and XML, so I want
adequate documentation to help me do that.

> It presumes and encourages an amateurish, casual usage, which is good.

Nothing prevents you from using Emacs in that way.

I'll agree the default settings in Emacs are not as friendly as the
default settings in GPS, so it helps if someone gives you a better set.
That's what I do for my team at work.

>> In my real job, I spend quite a bit of time making sure the manuals that
>> describe our system are correct and up to date. That way, i can just
>> refer people to the manuals, and don't have to spend time answering the
>> same questions over and over. The time spent maintaining the manuals is
>> _very_ well spent! I expect the same from help systems, especially
>> commercially supported ones.
>
> Modern-time systems became too complex for a comprehensive up-front dry
> training.

It did not say anything about "training"; manuals can be read straight
thru, but mostly they are searched for information on a particular
topic, as that topic comes up.

>> But the main point here is this:
>> 
>>> Since GPS is a GTK application, its debugging must be a nightmare, even if
>>> you know the internals of GPS very well. 
>> 
>> That is _precisely_ why Emacs is better; debugging elisp is _not_ a
>> nightmare, _because_ it is an interactive system; you can always find
>> out what function a key invokes, you can find the source code that
>> implements that function, you can find the source code for all the
>> functions that calls. And then you can modify one function, and see the
>> results immediately, without quiting and recreating the current situation.
>
> In my GtkAda programs I hook Glib.Messages, which causes an error window to
> pop up with the source code location trace.
>
> The problem is that for GTK the actual error location is never the point
> where the error was detected. This is a problem of any event-driven
> framework.

Yes. In Emacs, you can also run elisp in debug mode, step by step, and
watch what happens, examine variables.

-- 
-- Stephe

Re: Emacs mtn support

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

>>> The only thing I've missed in Emacs support (which is missing in its SVN
>>> support, too) is the idea that marking a number of files to be committed
>>> should be implemented as one transaction, not one transaction per
>>> file.
>>
>> Which is the _entire_ point of mtn.
>
> Not sure I'd go that far, 

Ok, there are other important features; distributed, monotonic, supports
branch propagation with conflict resolution :).

> but it's also the expected way of using svn, git, hg ...

Yes. Which is why DVC was started; to provide a core of support at the
workspace level, which the base Emacs vc system does not provide at all.

>> DVC definitely adds that, as well as interactive support for propagating
>> between branches, with conflict resolution.
>
> OK, sounds good.
>
>>> Did you get my e-mail with my signed mtn key?
>>
>> Yes, but I don't actually have access to do anything with it; waiting on
>> Ludovic.
>
> OK, thanks.
>
>> Your version of mtn (0.48) does not support URLs; you need to use:
>>
>> $ mtn --db ~/monotone-dbs/ada-france.db pull --key '' www.ada-france.org \
>> org.emacs.*
>>
>> Or upgrade to mtn 1.0.
>
> Since I'd have to build from sources, which involves building botan,
> which involves .. well, 0.48 seems to be OK to use, so I'll stick!

I build mostly from sources in Windows; see INSTALL_windows_native.text
in the mtn sources. It's not that hard, trust me :).

DVC requires 0.99.

-- 
-- Stephe

Re: GPS issues: laundry list

[Dmitry A. Kazakov]

On Sat, 15 Sep 2012 03:45:31 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Maybe. But it is still an incredibly bad idea to manage versions by
>> altering file names.
> 
> You have misunderstood what I'm proposing; I'm not editing file _names_,
> just what directory the project is checked out in.
> 
> For version 07, the project is in mms_version_07/*. For version 08, the
> project is in mms_version_08/*.
> 
> How else would you do it?

I would have the stuff in a source control system. I mean a true system
which maintains consistent project views rather than merely tracking
individual files. The project (under the source control) would depend on
the project MMS, which is in some DB. You change current view from v7 to v8
by changing the project dependency.

This is how we maintain our middleware project. It depends on hundreds of
other projects of third-party libraries, drivers etc. It would be
impossible to handle it using your way.

>> I prefer to concentrate my weak mental powers solely on typing and
>> gazing Ada.
> 
> What else does Emacs require you to do?

Why would you need the on-line help then?

>> GPS is an IDE, it is not a language. 
> 
> Correct. But I can customize it by writing Python and XML, so I want
> adequate documentation to help me do that.

Can /= must. Customizable IDE defeats the purpose of. This is what makes MS
Developing Studio so uncomfortable. Once you start customizing anything,
you open a hell of problems how do I manage customizations. How do I switch
them, how do I store them, how do I version them, how do I train personal
on them, how do I keep them in the incoming version of the tool...

>>> In my real job, I spend quite a bit of time making sure the manuals that
>>> describe our system are correct and up to date. That way, i can just
>>> refer people to the manuals, and don't have to spend time answering the
>>> same questions over and over. The time spent maintaining the manuals is
>>> _very_ well spent! I expect the same from help systems, especially
>>> commercially supported ones.
>>
>> Modern-time systems became too complex for a comprehensive up-front dry
>> training.
> 
> It did not say anything about "training"; manuals can be read straight
> thru, but mostly they are searched for information on a particular
> topic, as that topic comes up.

Training is required in order to know where to search for. On-line help /=
manual /= FAQ.

>>> But the main point here is this:
>>> 
>>>> Since GPS is a GTK application, its debugging must be a nightmare, even if
>>>> you know the internals of GPS very well. 
>>> 
>>> That is _precisely_ why Emacs is better; debugging elisp is _not_ a
>>> nightmare, _because_ it is an interactive system; you can always find
>>> out what function a key invokes, you can find the source code that
>>> implements that function, you can find the source code for all the
>>> functions that calls. And then you can modify one function, and see the
>>> results immediately, without quiting and recreating the current situation.
>>
>> In my GtkAda programs I hook Glib.Messages, which causes an error window to
>> pop up with the source code location trace.
>>
>> The problem is that for GTK the actual error location is never the point
>> where the error was detected. This is a problem of any event-driven
>> framework.
> 
> Yes. In Emacs, you can also run elisp in debug mode, step by step, and
> watch what happens, examine variables.

"Step" is already an imperative point of view, which does not apply to
events. Deadlocks usually happen when the UI tries to emulate or really be
asynchronous. When you, for example, start compilation of a unit, you want
still have IDE's UI responsible. This is what opens the can of worms.

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

Re: GPS issues: laundry list

[Ludovic Brenta]

Dmitry A. Kazakov writes on comp.lang.ada:
> On Sat, 15 Sep 2012 03:45:31 -0400, Stephen Leake wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> Maybe. But it is still an incredibly bad idea to manage versions by
>>> altering file names.
>> 
>> You have misunderstood what I'm proposing; I'm not editing file
>> _names_, just what directory the project is checked out in.
>> 
>> For version 07, the project is in mms_version_07/*. For version 08,
>> the project is in mms_version_08/*.
>> 
>> How else would you do it?
>
> I would have the stuff in a source control system. I mean a true
> system which maintains consistent project views rather than merely
> tracking individual files. The project (under the source control)
> would depend on the project MMS, which is in some DB. You change
> current view from v7 to v8 by changing the project dependency.

Dmitry, you're not paying attention.  This is *exactly* what Stephe
does; his two directories are *checkouts* from the proper version
control system, monotone.  He said so *explicitly*.  Please read more
carefully.

> Can /= must. Customizable IDE defeats the purpose of. This is what
> makes MS Developing Studio so uncomfortable. Once you start
> customizing anything, you open a hell of problems how do I manage
> customizations. How do I switch them, how do I store them, how do I
> version them, how do I train personal on them, how do I keep them in
> the incoming version of the tool...

By merging them upstream into the IDE, of course; this is why
closed-source IDEs are a no-go for me :)

-- 
Ludovic Brenta.

Re: GPS issues: laundry list

[Dmitry A. Kazakov]

On Sat, 15 Sep 2012 11:41:38 +0200, Ludovic Brenta wrote:

> Dmitry A. Kazakov writes on comp.lang.ada:
>> On Sat, 15 Sep 2012 03:45:31 -0400, Stephen Leake wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>> Maybe. But it is still an incredibly bad idea to manage versions by
>>>> altering file names.
>>> 
>>> You have misunderstood what I'm proposing; I'm not editing file
>>> _names_, just what directory the project is checked out in.
>>> 
>>> For version 07, the project is in mms_version_07/*. For version 08,
>>> the project is in mms_version_08/*.
>>> 
>>> How else would you do it?
>>
>> I would have the stuff in a source control system. I mean a true
>> system which maintains consistent project views rather than merely
>> tracking individual files. The project (under the source control)
>> would depend on the project MMS, which is in some DB. You change
>> current view from v7 to v8 by changing the project dependency.
> 
> Dmitry, you're not paying attention.  This is *exactly* what Stephe
> does; his two directories are *checkouts* from the proper version
> control system, monotone.  He said so *explicitly*.  Please read more
> carefully.

Same to you. What you described is just *impossible* in the system I am
talking about. It just does not allow two versions of the same project
being both visible. No way. No problem. He would have exactly same path for
whichever version he selected.

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

Re: GPS issues: laundry list

[Stephen Leake]

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

>> You have misunderstood what I'm proposing; I'm not editing file _names_,
>> just what directory the project is checked out in.
>> 
>> For version 07, the project is in mms_version_07/*. For version 08, the
>> project is in mms_version_08/*.
>> 
>> How else would you do it?
>
> I would have the stuff in a source control system. I mean a true system
> which maintains consistent project views rather than merely tracking
> individual files. 

I do; monotone.

> The project (under the source control) would depend on the project
> MMS, which is in some DB. You change current view from v7 to v8 by
> changing the project dependency.

What does that do to the directories on the disk?

I'm guessing you are saying:

1) only use one directory to check out the files; say <some root>/mms

2) to change the version in the directory, use the appropriate monotone
command

That is certainly possible, but extremely cumbersome. First, every time
you change versions, you have to recompile (unless you use a version
control system that maintains compiled files, which I hate). Second,
there are _many_ times when I want to compare changes between two
versions, and it is much simpler to do that when both are checked out.

But most importantly, I have customers using both versions (some have
not upgraded yet), so I need both versions checked out and compiled.

That's why I need <some root>/mms_version_07, /mms_version_08

> This is how we maintain our middleware project. It depends on hundreds of
> other projects of third-party libraries, drivers etc. It would be
> impossible to handle it using your way.

No, it would not. If I counted all the OS libraries I use, mine probably
depends on hundreds as well. 

In any case, that is othogonal to the issue at hand, which is how to
specify ADA_PROJECT_PATH properly.

>>> GPS is an IDE, it is not a language. 
>> 
>> Correct. But I can customize it by writing Python and XML, so I want
>> adequate documentation to help me do that.
>
> Can /= must. Customizable IDE defeats the purpose of. 

Ok, you don't want to discuss the issue. Never mind.

> This is what makes MS Developing Studio so uncomfortable. Once you
> start customizing anything, you open a hell of problems how do I
> manage customizations. How do I switch them, how do I store them, how
> do I version them, how do I train personal on them, how do I keep them
> in the incoming version of the tool...

All of these problems are solved nicely by a monotone project of Emacs
customizations. Well, except the 'train personel', which I accomplish by
working on the same hallway ...

-- 
-- Stephe

Re: GPS issues: laundry list

[Stephen Leake]

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

> On Sat, 15 Sep 2012 11:41:38 +0200, Ludovic Brenta wrote:
>
>> Dmitry A. Kazakov writes on comp.lang.ada:
>>> On Sat, 15 Sep 2012 03:45:31 -0400, Stephen Leake wrote:
>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>>> Maybe. But it is still an incredibly bad idea to manage versions by
>>>>> altering file names.
>>>> 
>>>> You have misunderstood what I'm proposing; I'm not editing file
>>>> _names_, just what directory the project is checked out in.
>>>> 
>>>> For version 07, the project is in mms_version_07/*. For version 08,
>>>> the project is in mms_version_08/*.
>>>> 
>>>> How else would you do it?
>>>
>>> I would have the stuff in a source control system. I mean a true
>>> system which maintains consistent project views rather than merely
>>> tracking individual files. The project (under the source control)
>>> would depend on the project MMS, which is in some DB. You change
>>> current view from v7 to v8 by changing the project dependency.
>> 
>> Dmitry, you're not paying attention.  This is *exactly* what Stephe
>> does; his two directories are *checkouts* from the proper version
>> control system, monotone.  He said so *explicitly*.  Please read more
>> carefully.
>
> Same to you. What you described is just *impossible* in the system I am
> talking about. It just does not allow two versions of the same project
> being both visible. No way. No problem. He would have exactly same path for
> whichever version he selected.

What CM system is that? I've never heard of such a thing.

It fails the basic requirements of my work flow. I'm glad I'm not forced
to use it!

tools should meet requirements, not dictate them.

-- 
-- Stephe

Re: GPS issues: laundry list

[Dmitry A. Kazakov]

On Mon, 17 Sep 2012 17:35:23 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sat, 15 Sep 2012 11:41:38 +0200, Ludovic Brenta wrote:
>>
>>> Dmitry A. Kazakov writes on comp.lang.ada:
>>>> On Sat, 15 Sep 2012 03:45:31 -0400, Stephen Leake wrote:
>>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>>>> Maybe. But it is still an incredibly bad idea to manage versions by
>>>>>> altering file names.
>>>>> 
>>>>> You have misunderstood what I'm proposing; I'm not editing file
>>>>> _names_, just what directory the project is checked out in.
>>>>> 
>>>>> For version 07, the project is in mms_version_07/*. For version 08,
>>>>> the project is in mms_version_08/*.
>>>>> 
>>>>> How else would you do it?
>>>>
>>>> I would have the stuff in a source control system. I mean a true
>>>> system which maintains consistent project views rather than merely
>>>> tracking individual files. The project (under the source control)
>>>> would depend on the project MMS, which is in some DB. You change
>>>> current view from v7 to v8 by changing the project dependency.
>>> 
>>> Dmitry, you're not paying attention.  This is *exactly* what Stephe
>>> does; his two directories are *checkouts* from the proper version
>>> control system, monotone.  He said so *explicitly*.  Please read more
>>> carefully.
>>
>> Same to you. What you described is just *impossible* in the system I am
>> talking about. It just does not allow two versions of the same project
>> being both visible. No way. No problem. He would have exactly same path for
>> whichever version he selected.
> 
> What CM system is that? I've never heard of such a thing.

It is a custom system on top of Perforce. But IBM's ClearCase does exactly
this.

> It fails the basic requirements of my work flow. I'm glad I'm not forced
> to use it!

In particular it was especially designed to prevent branching and
programmers checking out files from the same project. We do not merge
anything. We split projects into smaller manageable (and testable) projects
instead. When the project is mapped it is fully usable, e.g. includes all
sources, binaries of this build. That is necessary for us because we have
many installations and when a customer reports we have to be able to
reconstruct his installation without rebuilding.

> tools should meet requirements, not dictate them.

Egh, how do you meet a requirement without dictating it? E.g. driving the
right side of the road?

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

Re: GPS issues: laundry list

[Dmitry A. Kazakov]

On Mon, 17 Sep 2012 17:32:38 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> The project (under the source control) would depend on the project
>> MMS, which is in some DB. You change current view from v7 to v8 by
>> changing the project dependency.
> 
> What does that do to the directories on the disk?

It re-maps them to other files.

ClearCase, for example, has a virtual file system for doing this
efficiently.

> I'm guessing you are saying:
> 
> 1) only use one directory to check out the files; say <some root>/mms
> 
> 2) to change the version in the directory, use the appropriate monotone
> command
> 
> That is certainly possible, but extremely cumbersome.

You would have to write a lot of software in order to support that on top
of primitive file versioning.

If funding is no problem for you, why not to buy ClearCase?

> First, every time
> you change versions, you have to recompile (unless you use a version
> control system that maintains compiled files, which I hate).

No. It is a different way of handling dependencies.

The things your project depends on are *already* compiled and their state
is frozen in the code management system. In fact you cannot refer to
anything that is not compiled and checked in, unless that is not your
project. And in our system projects are encouraged to be small, even empty.
That is when we aggregate existing projects in order to deliver them to the
customer. Such an aggregate project may have no sources at all.

> Second,
> there are _many_ times when I want to compare changes between two
> versions, and it is much simpler to do that when both are checked out.

Any decent system supports that without checking out. Our system is very
punitive to checkouts. You cannot check out anything from the project
without scheduling a new version of it. And once you do, nobody can check
out that project again. We do everything to prevent branching. We never
ever merge any files.

You would not need to compare anything, if you worked the way we do. I
don't remember the last time I did. The reason why you are comparing
versions is mainly because, effectively, you do not version projects.

> But most importantly, I have customers using both versions (some have
> not upgraded yet), so I need both versions checked out and compiled.

How could you use both versions in one project? Otherwise, it is absolutely
no problem.

>> This is how we maintain our middleware project. It depends on hundreds of
>> other projects of third-party libraries, drivers etc. It would be
>> impossible to handle it using your way.
> 
> No, it would not. If I counted all the OS libraries I use, mine probably
> depends on hundreds as well. 

And how do you select the proper versions/paths of hundreds of projects? In
our case each library is a project. Each project has a dependency list
where the version is specified. When the project is mapped or checked out,
the right versions of all projects it depends on are automatically mapped.

As I understand, you are running a poor-man's project management by mapping
project versions onto directories. We started it this way 15 years ago and
when it became an expected catastrophe 5-7 years later, we were forced to
build a proper project management system.

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

Re: CM tools vs versions

[Stephen Leake]

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

>>> What you described is just *impossible* in the system I am
>>> talking about. It just does not allow two versions of the same project
>>> being both visible. No way. No problem. He would have exactly same path for
>>> whichever version he selected.
>> 
>> What CM system is that? I've never heard of such a thing.
>
> It is a custom system on top of Perforce. But IBM's ClearCase does exactly
> this.

Nonsense. I used ClearCase briefly a while ago, and I had no problem
maintaining two workspaces with different versions.

I quote from the ClearCase website (http://www-01.ibm.com/software/awdtools/clearcase/features/index.html?S_CMP=rnav):

    Fast, immediate access to virtually any version of a file   

You can of course impose your own policy on your use of the tool. But
ClearCase out of the box does what I want, not what you say it does.

>> It fails the basic requirements of my work flow. I'm glad I'm not forced
>> to use it!
>
> In particular it was especially designed to prevent branching and
> programmers checking out files from the same project. We do not merge
> anything. 

Now you are talking about file version locking to prevent conflicts. I
was talking about project version checkout. Two very different things.

> We split projects into smaller manageable (and testable) projects
> instead. When the project is mapped it is fully usable, e.g. includes
> all sources, binaries of this build. That is necessary for us because
> we have many installations and when a customer reports we have to be
> able to reconstruct his installation without rebuilding.

Which means you need different versions for different customers; exactly
what I am saying.

Hmm, you are going to say "no, not versions, just configurations of many
small projects". I still don't believe it. If one customer is using a
configuration that was frozen 5 years ago, clearly that will involve
different _versions_ than a customer just starting today.

>> tools should meet requirements, not dictate them.
>
> Egh, how do you meet a requirement without dictating it? E.g. driving the
> right side of the road?

The point is that _I_ dictate the requirements, and find tools that meet
them. I don't let tools dictate to me (which is why I like Emacs better
than GPS, to bring this vaguely back on topic :).

-- 
-- Stephe

Re: CM tools vs versions

[Dmitry A. Kazakov]

On Tue, 18 Sep 2012 21:54:48 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>>> What you described is just *impossible* in the system I am
>>>> talking about. It just does not allow two versions of the same project
>>>> being both visible. No way. No problem. He would have exactly same path for
>>>> whichever version he selected.
>>> 
>>> What CM system is that? I've never heard of such a thing.
>>
>> It is a custom system on top of Perforce. But IBM's ClearCase does exactly
>> this.
> 
> Nonsense. I used ClearCase briefly a while ago, and I had no problem
> maintaining two workspaces with different versions.

So what is nonsense? You cannot have two versions of the same component in
the same baseline. (I hope I used the ClearCase UCM terminology correctly
here)

>> We split projects into smaller manageable (and testable) projects
>> instead. When the project is mapped it is fully usable, e.g. includes
>> all sources, binaries of this build. That is necessary for us because
>> we have many installations and when a customer reports we have to be
>> able to reconstruct his installation without rebuilding.
> 
> Which means you need different versions for different customers; exactly
> what I am saying.

So?
 
> Hmm, you are going to say "no, not versions, just configurations of many
> small projects". I still don't believe it. If one customer is using a
> configuration that was frozen 5 years ago, clearly that will involve
> different _versions_ than a customer just starting today.

I don't understand what you are trying to say here.

I will try again. When a project A needs a component represented by a
project B (e.g. a library), I tell the system that the scheduled *new*
version x of A will depend on some *released* version y of B. The system
will map everything needed for using that version into any view of A x.

Later I could schedule yet another release x+n of A dependent on B y+1
(when the latter is released). In fact our system has a "project update"
feature to pull all dependencies of a project to the latest versions while
checking consistency of those automatically rebuilding the new release.
This  saves a huge amount of work (and bugs).

Any actions on the project A do not influence its released versions and
under no circumstances any view of any version of A could see more than one
version of B or any other project.

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