How to leave .ali files in original library?

How to leave .ali files in original library?

[localhost]

Hi again with another question on building an app using gcc-ada. I'm
building against ncurses thanks to Ludovic and Nasser I *think* I created a
static executable or maybe not ;) Is there a way to tell for sure? I ran ldd
and it doesn't show the curses lib so I think it's included ok but I did get
3 lines of output: 

	linux-vdso.so.1 =>  (0x00007fff3b1fb000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f27f34e3000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f27f3853000)

so maybe it's not static after all. What should I do?

My question after that is how I can stop all the .ali files from being
regenerated in my working directory. They're all in ncurses/lib/ada/adalib
already do they really have to be rebuilt/copied into my working directory?
I seem to remember a way of avoiding this but I can't find it now. The .o
files are also being built. I realize this has to happen but can't it be
done in the adalib directory instead of every directory I build an Ada
ncurses program? In other words why should the object files be created over
and over again.

Re: How to leave .ali files in original library?

[Jeffrey Carter]

On 03/09/2011 11:00 AM, localhost@example.org wrote:
>
> My question after that is how I can stop all the .ali files from being
> regenerated in my working directory. They're all in ncurses/lib/ada/adalib
> already do they really have to be rebuilt/copied into my working directory?
> I seem to remember a way of avoiding this but I can't find it now. The .o
> files are also being built. I realize this has to happen but can't it be
> done in the adalib directory instead of every directory I build an Ada
> ncurses program? In other words why should the object files be created over
> and over again.

If you read the top-secret GNAT documentation, you will find that the trick is 
to make the .ali files read only.

-- 
Jeff Carter
"Sir Robin the not-quite-so-brave-as-Sir-Lancelot,
who had nearly fought the Dragon of Angnor,
who nearly stood up to the vicious Chicken of Bristol,
and who had personally wet himself at the
Battle of Badon Hill."
Monty Python & the Holy Grail
68

Re: How to leave .ali files in original library?

[localhost]

> If you read the top-secret GNAT documentation, you will find that the
> trick is to make the .ali files read only.

Thank you. I'm sure if you work with Ada and GNAT and hang out on the Ada
newsgroup every day you eventually remember where to find everything. I have
awhile to go. ;)

Re: How to leave .ali files in original library?

[localhost]

> If you read the top-secret GNAT documentation, you will find that the
> trick is to make the .ali files read only.

Hmmm it seems this used to work but on the gcc-ada I am using now, 4.3.3 I
still get the ali files in my working directory even though I just double
checked and found them all r/o in the ncurses library. What else should I
look at? Thank you.

Re: How to leave .ali files in original library?

[Ludovic Brenta]

localhost@example.org writes:
> Hi again with another question on building an app using gcc-ada. I'm
> building against ncurses thanks to Ludovic and Nasser I *think* I created a
> static executable or maybe not ;) Is there a way to tell for sure? I ran ldd
> and it doesn't show the curses lib so I think it's included ok but I did get
> 3 lines of output: 
>
> 	linux-vdso.so.1 =>  (0x00007fff3b1fb000)
> 	libc.so.6 => /lib64/libc.so.6 (0x00007f27f34e3000)
> 	/lib64/ld-linux-x86-64.so.2 (0x00007f27f3853000)
>
> so maybe it's not static after all. What should I do?

No, it's pretty much as static as you can get.  This means your
executable depends only on the C library and the dynamic loader; they
are guaranteed to exist on your target computer even if it has no
compiler or other run-time library installed.  So, you can declare
victory on this front :) BTW, ldd was the correct thing to do, too :)

> My question after that is how I can stop all the .ali files from being
> regenerated in my working directory. They're all in
> ncurses/lib/ada/adalib already do they really have to be
> rebuilt/copied into my working directory?  I seem to remember a way of
> avoiding this but I can't find it now. The .o files are also being
> built. I realize this has to happen but can't it be done in the adalib
> directory instead of every directory I build an Ada ncurses program?
> In other words why should the object files be created over and over
> again.

So essentially you want an installation of ncurses that you can reuse in
several programs without recompiling the library.  I don't know how
ncurses is meant to be compiled (makefiles, project files?) but the
canonical way to achieve what you want is by means of a library project
file, as described in the GNAT User's Guide.  Essentially:

library project Ncurses is
   for Library_Name use "ncurses_ada";
   for Library_Dir use "/usr/lib";
   for Library_Kind use "static";
   for Source_Dirs use ("/usr/share/ada/adainclude/ncurses");
   for Library_ALI_Dir use "/usr/lib/ada/adalib/ncurses";
   for Externally_Built use "true";
end Ncurses;

And place libncurses_ada.a in /usr/lib, the source files in the
Source_Dirs and the ALI files, read-only, in the Library_ALI_Dir.  Do
*not* place any object files in any directory referenced by the project
file.  You can, of course, adjust the directories to suit your needs.
The ones shown above are appropriate for proper packages (.deb or .rpm).

For full details on how to package libraries for the masses, here is
another useful link:

http://people.debian.org/~lbrenta/debian-ada-policy.html

-- 
Ludovic Brenta.

Re: How to leave .ali files in original library?

[localhost]

> No, it's pretty much as static as you can get.  This means your
> executable depends only on the C library and the dynamic loader; they
> are guaranteed to exist on your target computer even if it has no
> compiler or other run-time library installed.  So, you can declare
> victory on this front :) BTW, ldd was the correct thing to do, too :)

Super! Thanks for your help, I actually accomplished something sortof.

> So essentially you want an installation of ncurses that you can reuse in
> several programs without recompiling the library.  

I don't mind recompiling the few modules although it is wasteful if you
think about it. I just don't like having the working directory cluttered
with extra files for no good reason. I used to be able to avoid this using
the trick Jeffrey Carter mentioned but now for some reason it doesn't seem
to work.

Thanks for your solution I'll go over it later on.

> http://people.debian.org/~lbrenta/debian-ada-policy.html

Ah great, I'll save the link. Thanks :)

Re: How to leave .ali files in original library?

[Simon Wright]

localhost@example.org writes:

> I just don't like having the working directory cluttered with extra
> files for no good reason.

I always include in my .gprs something like

   for Object_Dir use ".build";

which means all the .alis, .os end up in the subdirectory .build
(relative to the .gpr).

(a) Hoving said that, you also need to say this, otherwise the
    executable ends up there too:

   for Exec_Dir use ".";

(b) The subdirectory needs to be created; modern gnatmakes provide the
    -p flag to do this (cf mkdir).

Re: How to leave .ali files in original library?

[localhost]

Thanks...I would like to avoid using project files but I haven't worked on a
big Ada project yet so I don't know if it's possible. 

Re: How to leave .ali files in original library?

[Ludovic Brenta]

localhost@example.org wrote on comp.lang.ada:
> Thanks...I would like to avoid using project files

Why?

> but I haven't worked on a big Ada project yet so I don't know if it's possible.

You can use project files on small projects, too.  They are very nice.

--
Ludovic Brenta.

Re: How to leave .ali files in original library?

[localhost]

On 2011-03-10, Ludovic Brenta <ludovic@ludovic-brenta.org> wrote:
> localhost@example.org wrote on comp.lang.ada:
>> Thanks...I would like to avoid using project files
>
> Why?

One less thing to learn, if emacs Ada-mode gets the job done (so far!) I try
to avoid learning non-transferable bits as much as I can.

>> but I haven't worked on a big Ada project yet so I don't know if it's
>possible. 
>
> You can use project files on small projects, too.  They are very nice.

I'll see how it goes as I get further along with Ada. Thanks for your help!

Re: How to leave .ali files in original library?

[Robert Matthews]

Jeffrey Carter wrote:

> On 03/09/2011 11:00 AM, localhost@example.org wrote:
>>
>> My question after that is how I can stop all the .ali files from being
>> regenerated in my working directory. They're all in
>> ncurses/lib/ada/adalib already do they really have to be rebuilt/copied
>> into my working directory? I seem to remember a way of avoiding this but
>> I can't find it now. The .o files are also being built. I realize this
>> has to happen but can't it be done in the adalib directory instead of
>> every directory I build an Ada ncurses program? In other words why should
>> the object files be created over and over again.
> 
> If you read the top-secret GNAT documentation, you will find that the
> trick is to make the .ali files read only.
> 

I also use the "-i" switch with gnatmake.

Bob Matthews

Re: How to leave .ali files in original library?

[localhost]

>
> I also use the "-i" switch with gnatmake.
>
> Bob Matthews
>
Thanks Bob I will try it.

Re: How to leave .ali files in original library?

[Per Sandberg]

I dropped emacs and "emacs Ada-mode" several years ago  and the main 
reason was that that environment where only toys compared to the power 
of the .gpr-files in combination with GPS.

However on win32 I count:
  "notepad" as a great editor to write 2 line batch scripts in
and
  ".bat" as a great language as long as the file is less then 5 lines.

I think emacs is great in a much larger scope and it is a very powerful 
tool.
But when the task is to produce larger systems in Ada, I haven't seen 
anything that is even comparable with the combination .gpr-files and 
GPS, and it works fine for "hello_world" as well.


/Per

On 03/10/2011 10:36 AM, localhost@example.org wrote:
> On 2011-03-10, Ludovic Brenta<ludovic@ludovic-brenta.org>  wrote:
>> localhost@example.org wrote on comp.lang.ada:
>>> Thanks...I would like to avoid using project files
>>
>> Why?
>
> One less thing to learn, if emacs Ada-mode gets the job done (so far!) I try
> to avoid learning non-transferable bits as much as I can.
>
>>> but I haven't worked on a big Ada project yet so I don't know if it's
>> possible.
>>
>> You can use project files on small projects, too.  They are very nice.
>
> I'll see how it goes as I get further along with Ada. Thanks for your help!
>

Re: How to leave .ali files in original library?

[Simon Wright]

Per Sandberg <per.sandberg@bredband.net> writes:

> But when the task is to produce larger systems in Ada, I haven't seen
> anything that is even comparable with the combination .gpr-files and
> GPS, and it works fine for "hello_world" as well.

.gpr-files and Emacs. Works for me ...

Re: How to leave .ali files in original library?

[Randy Brukardt]

"Ludovic Brenta" <ludovic@ludovic-brenta.org> wrote in message 
news:eebf3b04-6c56-4192-a0e9-958ac126e428@l2g2000prg.googlegroups.com...
> localhost@example.org wrote on comp.lang.ada:
>> Thanks...I would like to avoid using project files
>
> Why?

I can't speak for the OP, but the obvious reason is that they cause vendor 
lock-in. If any significant amount of your project's functionality is tied 
up in .GPR files, then that functionality is not portable to another Ada 
compiler. (.GPR files are not Ada!).

That said, you practically will have to use some tool to get at least some 
of that functionality for every Ada system -- but clearly the less you 
depend on it the easier porting will be. (Complex project structures in 
Janus/Ada aren't portable anywhere else, either.)

                                 Randy.

Re: How to leave .ali files in original library?

[AdaMagica]

On 10 Mrz., 22:23, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Ludovic Brenta" <ludo...@ludovic-brenta.org> wrote in message
>
> news:eebf3b04-6c56-4192-a0e9-958ac126e428@l2g2000prg.googlegroups.com...
>
> > localh...@example.org wrote on comp.lang.ada:
> >> Thanks...I would like to avoid using project files
>
> > Why?
>
> I can't speak for the OP, but the obvious reason is that they cause vendor
> lock-in. If any significant amount of your project's functionality is tied
> up in .GPR files, then that functionality is not portable to another Ada
> compiler. (.GPR files are not Ada!).
>
> That said, you practically will have to use some tool to get at least some
> of that functionality for every Ada system -- but clearly the less you
> depend on it the easier porting will be. (Complex project structures in
> Janus/Ada aren't portable anywhere else, either.)
>
>                                  Randy.

And on APEX, you have subsystems; this structure is also not portable.
I used a GNAT project file per APEX subsystem when porting. So for big
projects, you're always bound to the vendor with the structure of your
Ada sources. The idea of a standard APSE or KAPSE died long ago.

Re: How to leave .ali files in original library?

[Per Sandberg]

On 03/11/2011 07:05 AM, AdaMagica wrote:
> On 10 Mrz., 22:23, "Randy Brukardt"<ra...@rrsoftware.com>  wrote:
>> "Ludovic Brenta"<ludo...@ludovic-brenta.org>  wrote in message
>>
>> news:eebf3b04-6c56-4192-a0e9-958ac126e428@l2g2000prg.googlegroups.com...
>>
>>> localh...@example.org wrote on comp.lang.ada:
>>>> Thanks...I would like to avoid using project files
>>
>>> Why?
>>
>> I can't speak for the OP, but the obvious reason is that they cause vendor
>> lock-in. If any significant amount of your project's functionality is tied
>> up in .GPR files, then that functionality is not portable to another Ada
>> compiler. (.GPR files are not Ada!).
>>
>> That said, you practically will have to use some tool to get at least some
>> of that functionality for every Ada system -- but clearly the less you
>> depend on it the easier porting will be. (Complex project structures in
>> Janus/Ada aren't portable anywhere else, either.)
>>
>>                                   Randy.
>
> And on APEX, you have subsystems; this structure is also not portable.
> I used a GNAT project file per APEX subsystem when porting. So for big
> projects, you're always bound to the vendor with the structure of your
> Ada sources. The idea of a standard APSE or KAPSE died long ago.

Well during the years I have made transmissions:
Rational-Delta ->
   Rational-APEX ->
     Object-Ada ->
       GNAT-(emacs-adamode) ->
       GNAT-(.gpr-projects)

Large SourceTree with messy project structure and no documented 
dependencies 2MSloc 300 Komponents ->
   GNAT-(.gpr-projects)

In the first case the project files where just some intelligent 
transformation, in the second case the project files revealed the true 
dependency graph between the components.
Since project files has well defined syntax and semantics they could 
always be transformed.

I would not be surprised if its is possible to use the GNAT build system 
as driver for the JanusAda compiler as well.

/Per

Re: How to leave .ali files in original library?

[Stephen Leake]

localhost@example.org writes:

> On 2011-03-10, Ludovic Brenta <ludovic@ludovic-brenta.org> wrote:
>> localhost@example.org wrote on comp.lang.ada:
>>> Thanks...I would like to avoid using project files
>>
>> Why?
>
> One less thing to learn, if emacs Ada-mode gets the job done (so far!) 

Glad to hear someone is using it!

> I try to avoid learning non-transferable bits as much as I can.

You mean there is another Ada compiler? :)

Emacs Ada-mode does not understand another compiler by default, but it
can be customized.

>> You can use project files on small projects, too.  They are very nice.

+2

-- 
-- Stephe

Re: How to leave .ali files in original library?

[localhost]

> Glad to hear someone is using it!

Thanks for writing it, if that was you! One request, could you bind or tell
me how to bind both the adjust-case-in-file and indent-lines-in-file to
keys? Now I have to use the menu which is slow.

>> I try to avoid learning non-transferable bits as much as I can.
>
> You mean there is another Ada compiler? :)

I really have no intention of learning gnu anything any more than I
absolutely must to get what I want done. At this point my needs are very
modest. If I find I'm using Ada alot I'll probably see if there's an Ada
product I can buy and I guess it will have its own editor, system for
makefiles etc.

Re: How to leave .ali files in original library?

[localhost]

> I can't speak for the OP, but the obvious reason is that they cause
> vendor> lock-in. If any significant amount of your project's functionality
> is tied up in .GPR files, then that functionality is not portable to
> another Ada compiler. (.GPR files are not Ada!).

Of course you're right but I'm only writing very small apps trying to learn
Ada at this point. But in principle my objection is what you said and that's
why I said I try not to learn non-transferrable bits because it's a waste of
time in my opinion.

Emacs vs GPS vs Eclipse, Ada vs Lisp vs Lua vs Java

[Stephen Leake]

Per Sandberg <per.sandberg@bredband.net> writes:

> I dropped emacs and "emacs Ada-mode" several years ago  and the main
> reason was that that environment where only toys compared to the power
> of the .gpr-files in combination with GPS.

Perhaps you should try again; Emacs Ada-mode now parses .gpr files to get
the required info.

On the other hand, perhaps I should try GPS again; it's been a few
years. My last impression was that it was a toy compared to Emacs :).

.gpr files are more important to the compiler than to the IDE.

> However on win32 I count:
>  "notepad" as a great editor to write 2 line batch scripts in
> and
>  ".bat" as a great language as long as the file is less then 5 lines.

and doesn't do anything useful.

> I think emacs is great in a much larger scope and it is a very
> powerful tool.

Ok.

> But when the task is to produce larger systems in Ada, I haven't seen
> anything that is even comparable with the combination .gpr-files and
> GPS, and it works fine for "hello_world" as well.

Since Emacs does .gpr, what is left in GPS that is so much better?

Last I checked, GPS doesn't do VHDL, LaTeX, Maxima, Matlab, bash mode,
make mode, monotone, read/send mail; all tools I need in my integrated
development environment. I even need C++ for monotone, but I assume GPS
does that.

I understand the Ada navigation is slightly better in GPS. I haven't
tried it, so I don't miss it.

I haven't tried customizing GPS. I have customized Emacs extensively;
for example, I've significantly improved the monotone front-end.

Hmm. I assume it would not be too hard to teach GPS to colorize VHDL;
adding intelligent indentation is probably harder (is it possible
without writing Ada for GPS? maybe it has been done). To be fair, the
intelligent indentation for Ada in Emacs is the hairiest code I have
every seen.

It might even be possible to build a vhdl.xml for gprbuild to run the
VHDL toolchain. Is there another way to teach GPS to run a toolchain?

If GPS could integrate the gtkwave viewer for VHDL debugging, that would
be great; it's run as a separate process from Emacs.

My understanding is that to add something like the monotone front-end in
GPS requires writing Ada code, which requires compiling, linking, and
restarting GPS for each modification.

In Emacs, the monotone front-end is in elisp, where each subroutine can
be edited and loaded without restarting Emacs, and each variable can be
set on the fly. There is an interactive debugger for stepping thru the
elisp. Once it is debugged, it can be batch compiled for faster
execution.

For most applications, I pick Ada hands down over Lisp. But for user
interface GUIs, a dynamically loaded interpreted/debugged environment is
_much_ better. So I stick with elisp for that.

If GPS can do dynamically loaded Ada with source-code debugging, that
would be a huge selling point. But I suspect the technical requirements
of such an environment require a much simpler language like Lisp.

Lua might work in such an environment; it's better than Lisp, not as
good as Ada. monotone uses Lua as a user customization language.

Apparently Java is used this way in Eclipse; does that have source-code
debugging for dynamically loaded subprograms?

-- 
-- Stephe

Re: How to leave .ali files in original library?

[Ludovic Brenta]

localhost@example.org wrote on comp.lang.ada:
>> I can't speak for the OP, but the obvious reason is that they cause
>> vendor> lock-in. If any significant amount of your project's functionality
>> is tied up in .GPR files, then that functionality is not portable to
>> another Ada compiler. (.GPR files are not Ada!).
>
> Of course you're right but I'm only writing very small apps trying to learn
> Ada at this point. But in principle my objection is what you said and that's
> why I said I try not to learn non-transferrable bits because it's a waste of
> time in my opinion.

But the command-line switches of GCC and your Makefiles tailored for
GCC are also non-transferable.  Other people have mentioned the
proprietary build systems of Rational Apex and Janus/Ada; ObjectAda
also has a different one.  So, your argument is valid in theory but
moot in practice because it applies equally to all Ada toolchains and
is not a differentiator.

I argue that, lock-in for lock-in, GNAT project files are much more
maintainable and readable than Makefiles.  And, to come back to the
subject of this thread, they will leave .ali files in the specified
Library_ALI_Dir by default :)

--
Ludovic Brenta.

Re: How to leave .ali files in original library?

[Stephen Leake]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Ludovic Brenta" <ludovic@ludovic-brenta.org> wrote in message 
> news:eebf3b04-6c56-4192-a0e9-958ac126e428@l2g2000prg.googlegroups.com...
>> localhost@example.org wrote on comp.lang.ada:
>>> Thanks...I would like to avoid using project files
>>
>> Why?
>
> I can't speak for the OP, but the obvious reason is that they cause vendor 
> lock-in. If any significant amount of your project's functionality is tied 
> up in .GPR files, then that functionality is not portable to another Ada 
> compiler. (.GPR files are not Ada!).

Technically, .gpr files are not tied to the GNAT compiler. You can
customize the gpr language to run other tools, in particular other Ada
compilers.

I use gpr files to run auto_text_io, for example. qtada uses it to run
amoc, a GUI preprocessor.

> That said, you practically will have to use some tool to get at least some 
> of that functionality for every Ada system -- but clearly the less you 
> depend on it the easier porting will be. (Complex project structures in 
> Janus/Ada aren't portable anywhere else, either.)

And using the vendor-provided project tool may be easier than adapting
gpr to the vendor compiler. But it is a tradeoff, not an absolute
impossibility. If you have experience adapting gpr, and don't yet know
the vendor tool, the tradeoff could favor using gpr instead of the
vendor tool.

gpr files are the best project tool I've seen. But I have not seen many.

-- 
-- Stephe

Re: How to leave .ali files in original library?

[Cyrille]

On Mar 11, 7:44 am, Per Sandberg <per.sandb...@bredband.net> wrote:
>
> I would not be surprised if its is possible to use the GNAT build system
> as driver for the JanusAda compiler as well.
>

gprbuild has indeed been designed to be as compiler independent as
possible. Although, to be fair, we have put more effort into
addressing the variability of C/C++ compilers than for the Ada
compiler and on the Ada side, GNATitudes m

Re: How to leave .ali files in original library?

[Cyrille]

On Mar 11, 10:26 am, Cyrille <co...@eu.adacore.com> wrote:

> gprbuild has indeed been designed to be as compiler independent as
> possible. Although, to be fair, we have put more effort into
> addressing the variability of C/C++ compilers than for the Ada
> compiler and on the Ada side, GNATitudes m

I hit the "send button" a bit fast. I was about to say that on the Ada
side, there might be a few GNATitudes but that can always be
corrected. If other Ada vendors want to adapt gprbuild to their
technology, it should be possible since gprbuild is open source. We
will be happy to review and incorporate patches to that effect!

Re: Emacs vs GPS vs Eclipse, Ada vs Lisp vs Lua vs Java

[Peter C. Chapin]

On Fri, 11 Mar 2011, Stephen Leake wrote:

> If GPS can do dynamically loaded Ada with source-code debugging, that 
> would be a huge selling point. But I suspect the technical requirements of 
> such an environment require a much simpler language like Lisp.

I believe GPS is extendable using Python.

Peter

Re: Emacs vs GPS vs Eclipse, Ada vs Lisp vs Lua vs Java

[Dmitry A. Kazakov]

On Fri, 11 Mar 2011 04:12:40 -0500, Stephen Leake wrote:

> Last I checked, GPS doesn't do VHDL, LaTeX, Maxima, Matlab, bash mode,
> make mode, monotone, read/send mail; all tools I need in my integrated
> development environment.

What about retouching private album photos and ripping CDs?

> If GPS can do dynamically loaded Ada with source-code debugging, that
> would be a huge selling point.
[...]
> Apparently Java is used this way in Eclipse; does that have source-code
> debugging for dynamically loaded subprograms?

You can start GPS in a command mode listening for connections from the
program being debugged and navigate the project sources from there. (It is
a huge help when debugging GtkAda applications.) You can walk the call
stack from an exception handler or at any point you wanted, without messing
up with gdb (which does not work anyway).

See here:

http://www.dmitry-kazakov.de/ada/gtkada_contributions.htm#1.4

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

Re: How to leave .ali files in original library?

[Dmitry A. Kazakov]

On Fri, 11 Mar 2011 01:16:21 -0800 (PST), Ludovic Brenta wrote:

> localhost@example.org wrote on comp.lang.ada:
>>> I can't speak for the OP, but the obvious reason is that they cause
>>> vendor> lock-in. If any significant amount of your project's functionality
>>> is tied up in .GPR files, then that functionality is not portable to
>>> another Ada compiler. (.GPR files are not Ada!).
>>
>> Of course you're right but I'm only writing very small apps trying to learn
>> Ada at this point. But in principle my objection is what you said and that's
>> why I said I try not to learn non-transferrable bits because it's a waste of
>> time in my opinion.
> 
> But the command-line switches of GCC and your Makefiles tailored for
> GCC are also non-transferable.  Other people have mentioned the
> proprietary build systems of Rational Apex and Janus/Ada; ObjectAda
> also has a different one.  So, your argument is valid in theory but
> moot in practice because it applies equally to all Ada toolchains and
> is not a differentiator.

Actually we could make one step forward and define a
compiler/linker/environment abstraction of an Ada project in ARM. That
would make the gpr file (or, better, an Ada program managing the project)
independent on the target. E.g. instead of "-g", we would write
Project.Debug_Information := True;

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

Re: How to leave .ali files in original library?

[Stephen Leake]

localhost@example.org writes:

>> Glad to hear someone is using it!
>
> Thanks for writing it, if that was you! 

I didn't start it, but I am the current maintainer.

> One request, could you bind or tell me how to bind both the
> adjust-case-in-file and indent-lines-in-file to keys? Now I have to
> use the menu which is slow.

(define-key ada-mode-map "\M-["     'adjust-case-in-file)

etc

"\M" means the "meta" key modifier; the Alt key on most PC keyboards.

See the info manual for more information on specifying keys (C-h i)

>>> I try to avoid learning non-transferable bits as much as I can.
>>
>> You mean there is another Ada compiler? :)
>
> I really have no intention of learning gnu anything any more than I
> absolutely must to get what I want done. At this point my needs are very
> modest. If I find I'm using Ada alot I'll probably see if there's an Ada
> product I can buy and I guess it will have its own editor, system for
> makefiles etc.

It makes much more sense to learn the Gnu tools, and nothing else, if
you are just getting started. They are free, many other people (both
hobbyist and professional) use them (so free help is also available),
and they are perfectly capable of doing everything you need. And they
are available on all current major platforms.

Spending money on tools is only necessary when you need professional
support, or have particular target needs.

--
-- Stephe

Re: How to leave .ali files in original library?

[Stephen Leake]

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

> localhost@example.org wrote on comp.lang.ada:
>>> I can't speak for the OP, but the obvious reason is that they cause
>>> vendor> lock-in. If any significant amount of your project's functionality
>>> is tied up in .GPR files, then that functionality is not portable to
>>> another Ada compiler. (.GPR files are not Ada!).
>>
>> Of course you're right but I'm only writing very small apps trying to learn
>> Ada at this point. But in principle my objection is what you said and that's
>> why I said I try not to learn non-transferrable bits because it's a waste of
>> time in my opinion.
>
> But the command-line switches of GCC and your Makefiles tailored for
> GCC are also non-transferable.  Other people have mentioned the
> proprietary build systems of Rational Apex and Janus/Ada; ObjectAda
> also has a different one.  So, your argument is valid in theory but
> moot in practice because it applies equally to all Ada toolchains and
> is not a differentiator.
>
> I argue that, lock-in for lock-in, GNAT project files are much more
> maintainable and readable than Makefiles.  And, to come back to the
> subject of this thread, they will leave .ali files in the specified
> Library_ALI_Dir by default :)

And of the build systems mentioned, they are the _least_
vendor-specific; they can be used to drive other vendor toolchains.

-- 
-- Stephe

Re: Emacs vs GPS vs Eclipse, Ada vs Lisp vs Lua vs Java

[Stephen Leake]

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

> On Fri, 11 Mar 2011 04:12:40 -0500, Stephen Leake wrote:
>
>> Last I checked, GPS doesn't do VHDL, LaTeX, Maxima, Matlab, bash mode,
>> make mode, monotone, read/send mail; all tools I need in my integrated
>> development environment.
>
> What about retouching private album photos and ripping CDs?

No, I don't expect Emacs to do that. But I wouldn't be surprised if
there is a mode that does!

Are you saying GPS supports that?

>> If GPS can do dynamically loaded Ada with source-code debugging, that
>> would be a huge selling point.
> [...]
>> Apparently Java is used this way in Eclipse; does that have source-code
>> debugging for dynamically loaded subprograms?
>
> You can start GPS in a command mode listening for connections from the
> program being debugged and navigate the project sources from there. (It is
> a huge help when debugging GtkAda applications.) You can walk the call
> stack from an exception handler or at any point you wanted, without messing
> up with gdb (which does not work anyway).

I gather you are saying you can use one GPS instance to debug the Ada
code in another GPS instance. That makes sense; in this mode, GPS is a
front-end for gdb. Emacs can do the same thing.

That would be the equivalent of the Emacs interactive lisp debugger.

But I have debugged GtkAda programs at that level, and it is not nearly
as productive (for the task of implementing simple GUIs for programmer
tools) as the Emacs environment. Mostly because the edit/compile/test
cycle for a single subprogram is much faster in the Emacs environment.

-- 
-- Stephe

Re: Emacs vs GPS vs Eclipse, Ada vs Lisp vs Lua vs Java

[Dmitry A. Kazakov]

On Sat, 12 Mar 2011 07:53:48 -0500, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Fri, 11 Mar 2011 04:12:40 -0500, Stephen Leake wrote:
>>
>>> Last I checked, GPS doesn't do VHDL, LaTeX, Maxima, Matlab, bash mode,
>>> make mode, monotone, read/send mail; all tools I need in my integrated
>>> development environment.
>>
>> What about retouching private album photos and ripping CDs?
> 
> No, I don't expect Emacs to do that. But I wouldn't be surprised if
> there is a mode that does!
> 
> Are you saying GPS supports that?

No, I wondered why it should. I don't want a mail-sending IDE.

>>> If GPS can do dynamically loaded Ada with source-code debugging, that
>>> would be a huge selling point.
>> [...]
>>> Apparently Java is used this way in Eclipse; does that have source-code
>>> debugging for dynamically loaded subprograms?
>>
>> You can start GPS in a command mode listening for connections from the
>> program being debugged and navigate the project sources from there. (It is
>> a huge help when debugging GtkAda applications.) You can walk the call
>> stack from an exception handler or at any point you wanted, without messing
>> up with gdb (which does not work anyway).
> 
> I gather you are saying you can use one GPS instance to debug the Ada
> code in another GPS instance.

No, I mean that you can communicate to GPS from your Ada program, e.g.
while debugging it.

> That makes sense; in this mode, GPS is a
> front-end for gdb. Emacs can do the same thing.

gdb is garbage. But even if there were a decent debugger for GNAT, you may
want to have some tracing tool. GPS gives you an opportunity to browse the
sources while tracing.

> But I have debugged GtkAda programs at that level, and it is not nearly
> as productive (for the task of implementing simple GUIs for programmer
> tools) as the Emacs environment. Mostly because the edit/compile/test
> cycle for a single subprogram is much faster in the Emacs environment.

I am not sure how it can be faster than in GPS: F4, shift+F2. Debugging
GtkAda with gdb cannot work, because GTK does not use exceptions to
indicate errors. Also if you stop GTK in an unfortunate state, you would
corrupt GUI in a way unrelated to the original problem. It is similar to
real-time applications, which break when stepped. Tracing works much better
and an ability to ask GPS to show the source where the message came from is
a great help.

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

Re: Emacs vs GPS vs Eclipse, Ada vs Lisp vs Lua vs Java

[Stephen Leake]

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

> On Sat, 12 Mar 2011 07:53:48 -0500, Stephen Leake wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On Fri, 11 Mar 2011 04:12:40 -0500, Stephen Leake wrote:
>>>
>>>> Last I checked, GPS doesn't do VHDL, LaTeX, Maxima, Matlab, bash mode,
>>>> make mode, monotone, read/send mail; all tools I need in my integrated
>>>> development environment.
>
> I don't want a mail-sending IDE.

I often need to quote parts of code in email; it's convenient if the
code and the email are in the same tool.

In addition, many editing operations are similar between code and email;
cut/paste, fill, spellcheck. So I prefer a consistent interface, which
is much easier to achieve with a single tool.

>>>> If GPS can do dynamically loaded Ada with source-code debugging, that
>>>> would be a huge selling point.
>>> [...]
>>>> Apparently Java is used this way in Eclipse; does that have source-code
>>>> debugging for dynamically loaded subprograms?
>>>
>>> You can start GPS in a command mode listening for connections from the
>>> program being debugged and navigate the project sources from there. (It is
>>> a huge help when debugging GtkAda applications.) You can walk the call
>>> stack from an exception handler or at any point you wanted, without messing
>>> up with gdb (which does not work anyway).
>> 
>> I gather you are saying you can use one GPS instance to debug the Ada
>> code in another GPS instance.
>
> No, I mean that you can communicate to GPS from your Ada program, e.g.
> while debugging it.
>
>> That makes sense; in this mode, GPS is a
>> front-end for gdb. Emacs can do the same thing.
>
> gdb is garbage. 

You seem to not understand how GPS works; it uses gdb as the backend for
all debugging operations. This is true of all frontends for the Gnu toolset.

> But even if there were a decent debugger for GNAT, 

There is; gdb.

gdb is a backend. You can use it directly from the command line (I
actually often prefer that), or via a front end such as Emacs or GPS.
The front end displays the appropriate source, allows setting
breakpoints, and also displays specified variables, the current CPU
registers, etc. I don't think GPS  is significantly different in
functionality from Emacs here; it is  different in the details of how
the windows are manipulated.

> you may want to have some tracing tool. GPS gives you an opportunity
> to browse the sources while tracing.

That capability is based on gdb reporting the source line relevant to
the current code position. Emacs and GPS both provide ways to display
that source code.

>> But I have debugged GtkAda programs at that level, and it is not nearly
>> as productive (for the task of implementing simple GUIs for programmer
>> tools) as the Emacs environment. Mostly because the edit/compile/test
>> cycle for a single subprogram is much faster in the Emacs environment.
>
> I am not sure how it can be faster than in GPS: F4, shift+F2. 

That's just the first keystrokes. How long does it take after that
before the results are known?

In particular, since you have to restart GPS to see the change, you have
to rerun the steps needed to get to the point where the bug occured.
For example, suppose I'm working on DVC, the Emacs front end to
monotone. One operation is to review changed files, collect a commit
statement, and do the commit. If the last step is failing, I have to
repeat the other steps each time I want to try a bug fix.

In Emacs, the context doesn't change when I recompile one elisp
program; I don't have to repeat anything.

You'll have to try it to truly appreciate the difference.

> Debugging GtkAda with gdb cannot work, because GTK does not use
> exceptions to indicate errors. 

You can still set break points in the error handling code.

> Also if you stop GTK in an unfortunate
> state, you would corrupt GUI in a way unrelated to the original
> problem. 

Yes, that is true of GUIs in general.

But it is better in Emacs, because the elisp is at a higher level; the
low level GUI operations are not interrupted by elisp breakpoints.

So you are supporting my position that debugging GUIs is better in Emacs
than in GPS.

> It is similar to real-time applications, which break when stepped.
> Tracing works much better and an ability to ask GPS to show the source
> where the message came from is a great help.

What, exactly, do you mean by "tracing"?

Emacs elisp uses that term to mean roughly "display the source lines as
they are executed". I rarely use that mode in Emacs. In realtime code it
can be useful, but any IO can change the timing.

-- 
-- Stephe

Re: Emacs vs GPS vs Eclipse, Ada vs Lisp vs Lua vs Java

[Dmitry A. Kazakov]

On Sun, 13 Mar 2011 11:17:42 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sat, 12 Mar 2011 07:53:48 -0500, Stephen Leake wrote:
>>
>>> That makes sense; in this mode, GPS is a
>>> front-end for gdb. Emacs can do the same thing.
>>
>> gdb is garbage. 
> 
> You seem to not understand how GPS works; it uses gdb as the backend for
> all debugging operations. This is true of all frontends for the Gnu toolset.

I didn't blame GPS. I did gdb.
 
>> you may want to have some tracing tool. GPS gives you an opportunity
>> to browse the sources while tracing.
> 
> That capability is based on gdb reporting the source line relevant to
> the current code position.

No. It is based on the debugging information. You need not to have gdb in
order to use GNAT.Traceback.Symbolic.

>>> But I have debugged GtkAda programs at that level, and it is not nearly
>>> as productive (for the task of implementing simple GUIs for programmer
>>> tools) as the Emacs environment. Mostly because the edit/compile/test
>>> cycle for a single subprogram is much faster in the Emacs environment.
>>
>> I am not sure how it can be faster than in GPS: F4, shift+F2. 
> 
> That's just the first keystrokes. How long does it take after that
> before the results are known?

As long as GNAT gets it compiled.

> In particular, since you have to restart GPS to see the change, you have
> to rerun the steps needed to get to the point where the bug occured.
> For example, suppose I'm working on DVC, the Emacs front end to
> monotone. One operation is to review changed files, collect a commit
> statement, and do the commit. If the last step is failing, I have to
> repeat the other steps each time I want to try a bug fix.

I didn't understand this. Why should I restart GPS? I start it once I
booted the computer.

>> Debugging GtkAda with gdb cannot work, because GTK does not use
>> exceptions to indicate errors. 
> 
> You can still set break points in the error handling code.

No, I cannot because it is in glib, gobject or any of other C libraries for
many of which I don't even have the source code. Besides it is useless to
look at them, since the problem is definitely on the caller's side. (And
if you did you would never want to do it again! (:-))

>> Also if you stop GTK in an unfortunate
>> state, you would corrupt GUI in a way unrelated to the original
>> problem. 
> 
> Yes, that is true of GUIs in general.
> 
> But it is better in Emacs, because the elisp is at a higher level; the
> low level GUI operations are not interrupted by elisp breakpoints.
>
> So you are supporting my position that debugging GUIs is better in Emacs
> than in GPS.

No. GPS is an independent application, so whatever may happen with my
program it cannot influence GPS.

>> It is similar to real-time applications, which break when stepped.
>> Tracing works much better and an ability to ask GPS to show the source
>> where the message came from is a great help.
> 
> What, exactly, do you mean by "tracing"?

User-made code insertions causing output upon program execution.

I do visual tracing, i.e. the output is made into a GTK window rather than
into a file. The most useful part is done from a log handler (see
Glib.Messages). It also stops the program, before it crashes. Because if
you get an error of Log_Level_Critical, crash is almost imminent. At this
point I can inspect the call stack and go to the source just per mouse
click.

> Emacs elisp uses that term to mean roughly "display the source lines as
> they are executed". I rarely use that mode in Emacs. In realtime code it
> can be useful, but any IO can change the timing.

Yes, that would consume too many system resources.

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

Re: Emacs vs GPS vs Eclipse, Ada vs Lisp vs Lua vs Java

[Stephen Leake]

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

> On Sun, 13 Mar 2011 11:17:42 -0400, Stephen Leake wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On Sat, 12 Mar 2011 07:53:48 -0500, Stephen Leake wrote:
>>>
>>>> That makes sense; in this mode, GPS is a
>>>> front-end for gdb. Emacs can do the same thing.
>>>
>>> gdb is garbage. 
>> 
>> You seem to not understand how GPS works; it uses gdb as the backend for
>> all debugging operations. This is true of all frontends for the Gnu toolset.
>
> I didn't blame GPS. I did gdb.

You said:

>>> You can start GPS in a command mode listening for connections from the
>>> program being debugged and navigate the project sources from there. (It is
>>> a huge help when debugging GtkAda applications.) You can walk the call
>>> stack from an exception handler or at any point you wanted, without messing
>>> up with gdb (which does not work anyway).

This says you think GPS is a good debugger, while gdb is not. That
doesn't make any sense, since GPS uses gdb as a back-end.

Perhaps you mean GPS is a good debugger front-end, while gdb is not a
good front-end. That I can agree with.

>>> you may want to have some tracing tool. GPS gives you an opportunity
>>> to browse the sources while tracing.
>> 
>> That capability is based on gdb reporting the source line relevant to
>> the current code position.
>
> No. It is based on the debugging information. You need not to have gdb in
> order to use GNAT.Traceback.Symbolic.

Well, yes. But is that what GPS actually does while debugging? I doubt it.

>>>> But I have debugged GtkAda programs at that level, and it is not nearly
>>>> as productive (for the task of implementing simple GUIs for programmer
>>>> tools) as the Emacs environment. Mostly because the edit/compile/test
>>>> cycle for a single subprogram is much faster in the Emacs environment.
>>>
>>> I am not sure how it can be faster than in GPS: F4, shift+F2. 
>> 
>> That's just the first keystrokes. How long does it take after that
>> before the results are known?
>
> As long as GNAT gets it compiled.

Yes, which is a relatively long time.

>> In particular, since you have to restart GPS to see the change, you have
>> to rerun the steps needed to get to the point where the bug occured.
>> For example, suppose I'm working on DVC, the Emacs front end to
>> monotone. One operation is to review changed files, collect a commit
>> statement, and do the commit. If the last step is failing, I have to
>> repeat the other steps each time I want to try a bug fix.
>
> I didn't understand this. Why should I restart GPS? I start it once I
> booted the computer.

Because GPS is the program being debugged. The point of this discussion
is developing additional IDE features, in particular a monotone
front-end. I believe that requires writing Ada code that is linked with
GPS. I could be wrong.

>>> Debugging GtkAda with gdb cannot work, because GTK does not use
>>> exceptions to indicate errors. 
>> 
>> You can still set break points in the error handling code.
>
> No, I cannot because it is in glib, gobject or any of other C libraries for
> many of which I don't even have the source code. 

That's not GPS's fault, that's yours. The libraries you mention are
open source; why don't you have the code. 

Please stop raising straw men, and focus on the actual discussion.

In any case, you continue to bolster my point; elisp in Emacs is better for
developing IDEs than Ada in GPS.

> Besides it is useless to look at them, since the problem is definitely
> on the caller's side. (And if you did you would never want to do it
> again! (:-))

Figuring out what the user problem is may require reading the library
code, if the library documentation is not sufficiently clear.

>>> Also if you stop GTK in an unfortunate
>>> state, you would corrupt GUI in a way unrelated to the original
>>> problem. 
>> 
>> Yes, that is true of GUIs in general.
>> 
>> But it is better in Emacs, because the elisp is at a higher level; the
>> low level GUI operations are not interrupted by elisp breakpoints.
>>
>> So you are supporting my position that debugging GUIs is better in Emacs
>> than in GPS.
>
> No. GPS is an independent application, so whatever may happen with my
> program it cannot influence GPS.

Once again, the program under development is GPS.

>>> It is similar to real-time applications, which break when stepped.
>>> Tracing works much better and an ability to ask GPS to show the source
>>> where the message came from is a great help.
>> 
>> What, exactly, do you mean by "tracing"?
>
> User-made code insertions causing output upon program execution.

Ok. That is completely independent of GPS, gdb, and everything else I am
trying to discuss.

> I do visual tracing, i.e. the output is made into a GTK window rather than
> into a file. The most useful part is done from a log handler (see
> Glib.Messages). It also stops the program, before it crashes. 

How can user written output stop the program? Apparently the code does
something more than just output.

Obviously, such techniques are also available in elisp. For example, I
sometimes use them to see what commands are being issued to the monotone
back-end.

> Because if you get an error of Log_Level_Critical, crash is almost
> imminent. At this point I can inspect the call stack and go to the
> source just per mouse click.

In elisp I can call (debug) and get the same effect.

>> Emacs elisp uses that term to mean roughly "display the source lines as
>> they are executed". I rarely use that mode in Emacs. In realtime code it
>> can be useful, but any IO can change the timing.
>
> Yes, that would consume too many system resources.

If it displays every line, while your user intertions display less
information, I agree.


I am trying to discuss this assertion:

Developing user-interactive GUI add-ons for programming IDEs is better
using elisp in Emacs (with Emacs as the target IDE) than using Ada in
GPS (with GPS as the target IDE).

If you have a point relevant to that, I'd like to hear it.

-- 
-- Stephe

Re: Emacs vs GPS vs Eclipse, Ada vs Lisp vs Lua vs Java

[Dmitry A. Kazakov]

On Mon, 14 Mar 2011 08:07:27 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>>> You can start GPS in a command mode listening for connections from the
>>>> program being debugged and navigate the project sources from there. (It is
>>>> a huge help when debugging GtkAda applications.) You can walk the call
>>>> stack from an exception handler or at any point you wanted, without messing
>>>> up with gdb (which does not work anyway).
> 
> This says you think GPS is a good debugger, while gdb is not. That
> doesn't make any sense, since GPS uses gdb as a back-end.

No it only says that GPS can be used to navigate the code programmatically.

>>>> you may want to have some tracing tool. GPS gives you an opportunity
>>>> to browse the sources while tracing.
>>> 
>>> That capability is based on gdb reporting the source line relevant to
>>> the current code position.
>>
>> No. It is based on the debugging information. You need not to have gdb in
>> order to use GNAT.Traceback.Symbolic.
> 
> Well, yes. But is that what GPS actually does while debugging?

It waits for an input or a command.

>>>>> But I have debugged GtkAda programs at that level, and it is not nearly
>>>>> as productive (for the task of implementing simple GUIs for programmer
>>>>> tools) as the Emacs environment. Mostly because the edit/compile/test
>>>>> cycle for a single subprogram is much faster in the Emacs environment.
>>>>
>>>> I am not sure how it can be faster than in GPS: F4, shift+F2. 
>>> 
>>> That's just the first keystrokes. How long does it take after that
>>> before the results are known?
>>
>> As long as GNAT gets it compiled.
> 
> Yes, which is a relatively long time.

Does Emacs compile Ada programs by itself, without GNAT?
 
> Because GPS is the program being debugged. The point of this discussion
> is developing additional IDE features, in particular a monotone
> front-end.

OK, I didn't understand that you wanted to extend GPS. I meant using GPS
for developing Ada programs. I didn't want to steal the AdaCore's bread...

>>>> Debugging GtkAda with gdb cannot work, because GTK does not use
>>>> exceptions to indicate errors. 
>>> 
>>> You can still set break points in the error handling code.
>>
>> No, I cannot because it is in glib, gobject or any of other C libraries for
>> many of which I don't even have the source code. 
> 
> That's not GPS's fault, that's yours. The libraries you mention are
> open source; why don't you have the code. 

Because I know that the error is not there.

>> I do visual tracing, i.e. the output is made into a GTK window rather than
>> into a file. The most useful part is done from a log handler (see
>> Glib.Messages). It also stops the program, before it crashes. 
> 
> How can user written output stop the program? Apparently the code does
> something more than just output.

GTK is single threaded. If you don't return from a signal handler
everything is frozen.

> I am trying to discuss this assertion:
> 
> Developing user-interactive GUI add-ons for programming IDEs is better
> using elisp in Emacs (with Emacs as the target IDE) than using Ada in
> GPS (with GPS as the target IDE).
> 
> If you have a point relevant to that, I'd like to hear it.

Sorry for misunderstanding. No, I don't consider either GPS or Emacs as
good in that respect because neither supports Ada as the language for user
plug-ins. GPS uses Python, Emacs does even bigger mess. 

Although the command mode would allow some kind of dynamic plug-ins running
on the context of an alien program, it would not allow to have persistent
plug-ins.

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