From: Ludovic Brenta on 19 Dec 2009 10:19
Dmitry A. Kazakov wrote on comp.lang.ada:
> On Sat, 19 Dec 2009 02:01:13 -0800 (PST), Ludovic Brenta wrote:
>> Shameless_Plug: begin
> Not at all, you are doing a very important job. It takes too much time to
> download components from different sources, to combine them and to make
> them working. When you just want to try a new library out, you are lost.
> BTW, the blame is all on non-Ada stuff. There was never any problem to
> incorporate an Ada library, because Ada has that excellent concept of
> compilation units. The problems begin when Ada is mere bindings to some
> other language mess with its dreadful makefiles and the horrific configure
Yes, I should know. Speaking of configure, in the most complex cases
I bypass autoconf, configure, automake and recursive Makefiles
completely. I replace them with one Makefile (debian/rules, mandated
by the Debian Policy) and one simple GNAT project file with a couple
of External (...) references. Works like a charm.
>> Besides the respective merits of GTK+, Qt and their Ada bindings, you
>> may find that ease of installation and deployment are also of
>> importance. By that metric, I suggest you take a look at Debian GNU/
>> Linux 5.0 "Lenny", the stable distribution. It ships GCC 4.3 and
>> GtkAda 2.8.1 as packages, i.e. precompiled and preconfigured for
>> immediate use, along with a host of other Ada libraries. Beware
>> though: you may get spoiled with the ease of use and never want to go
>> back to Windows :)
> Well, strange it might hear, but Windows API have their merits. One example
> specifically important to Ada, there is no any problem to send and receive
> Windows message from concurrent Ada tasks.
I agree but I was not talking about the respective merits of the
Windows API. I was talking about the ease of installation of the
development environment (including the libraries) and ease of
deployment on the target machines. Pardon me the expression but
Windows sucks big time in that department.
>> The installation is as easy as:
>> aptitude install libgtkada2-dev
>> which will also pull the correct version of GCC and any other packages
>> If you feel adventurous, you may want to try the testing distribution;
>> it has GtkAda 2.12.0. I am planning to upload GtkAda 2.14.2 to
>> unstable in the next couple of weeks; it should reach testing by the
>> end of January.
> Some information maybe interesting for you. I am using gtk 2.14.7 under
> Fedora Core 10, I am planing to jump over to the core 12 (since the core 11
> is broken). So far there is no problems, except for sporadic Storage_Error
> (caused by SIGSEGV). I am investigating the issue. Have you seen something
No but I do very little GtkAda programming on Debian. I use AdaCore's
Pro source-only distribution at work and have not found the issue you
are referring to. FWIW, the version of GTK+ in Debian 5.0 "Lenny" is
2.12.12 and GtkAda is, like I said earlier, 2.8.1.
> Under Windows I go with gtk 2.14.5, which works perfectly well.
> In both cases I didn't change anything in the GtkAda 2.14 itself, just
> recompiled it.
That's my point - Debian users don't have to recompile GtkAda at
Oh, and another benefit of Debian is the public bug database;
AdaCore's bug database is secret even for GNAT GPL users. The public
mailing list does not count as a database :)
From: Dmitry A. Kazakov on 19 Dec 2009 13:09
On Sat, 19 Dec 2009 07:19:34 -0800 (PST), Ludovic Brenta wrote:
> I agree but I was not talking about the respective merits of the
> Windows API. I was talking about the ease of installation of the
> development environment (including the libraries) and ease of
> deployment on the target machines. Pardon me the expression but
> Windows sucks big time in that department.
Yes, recent development with manifest files for DLLs is a sheer disaster.
>> In both cases I didn't change anything in the GtkAda 2.14 itself, just
>> recompiled it.
> That's my point - Debian users don't have to recompile GtkAda at
> all :)
Actually, it would be sufficient to install the sources into the GNAT
directory tree and then let them compile on demand from the user project.
The relocatable version of GtkAda does not work under Windows anyway, and
there is not that many GtkAda-based applications to worry about making it
> Oh, and another benefit of Debian is the public bug database;
> AdaCore's bug database is secret even for GNAT GPL users. The public
> mailing list does not count as a database :)
Well, if AdaCore does not pay much attention to that database, it won't
help. This is another story, but we need a widget library of our own (as a
part of a larger Ada platform abstraction layer).
Dmitry A. Kazakov
From: Michael Erdmann on 29 Dec 2009 03:05
Am 18.12.2009 21:44, schrieb Nasser M. Abbasi:
> I have not kept up with Ada for sometime. I was wondering, if someone wants
> to develop a simple GUI (plots, menus, buttons, graphs, etc..) using Ada,
In most cases i found the GUI not worth the effort, eg. i case it is
intendeted to present the results of a lengthly computation which run
anyway in the background. In such cases i am using simple text based
result files and GNU plot. It is avaiable on both platforms.
In case you plan for an interactive GUI; well i guess GtkAda would be
the right choice or using a completely different language ..
> and have the code compile to a .exe on windows and linux, which is the
> current most popular software pieces needed for the GUI?
> Assuming I will be using GNAT. Which gcc version should I be using these
> days which has the latest Ada support in it? Should I be using gcc directly
> for Ada programming these days, or use GNAT GPL 2009 version from Libre web
> site http://libre.adacore.com/libre/ ?
> I know there are few choices for the GUI, and just wanted to check what is
> the "best" choice do you think for that. One with a GUI builder would be
> nice (i.e. where one can pick the components and lay them out to design the
> interface). This will be an school program, nothing commercial. I wanted to
> try to write some basic finite element code in Ada, but need a GUI part for
> the simulation part.