Re: Creating tempfile takes too long: GNAT or Windows bug? (& GtkAda)

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Preben Randhol wrote:
> Warren W. Gay VE3WWG wrote:
...
>>My main concern was with the implementation of certain aspects of
>>GtkAda, concerning the use of typing. It seemed to me that there are
>>too many places that require "data conversions" to occur in the
>>application source code (I am thinking of parameters in certain
>>callbacks where there was some sort of function to mangle things into
>>the right type). It seems to me that there should be a better way to
>>handle this correctly. Either through generics, or through the
>>object'Class mechanism using inheritance. Converting from a base type
>>to a derived type would be acceptable IMHO, although it does have the
>>disadvantage that it is not properly checked until run time (generics
>>OTOH would catch problems at compile time).
> 
> Please let us know which version of GtkAda you have tried. It sounds
> like it is a long time ago as I don't recognise these things in any of
> the later versions (from at least 1 year ago).

It was 1.x of some sort. Here is a snippit that bugs me:

    procedure On_Clist2_Select_Row
      (Object : access Gtk_Clist_Record'Class;
       Params : Gtk.Arguments.Gtk_Args)
    is
       Row_X : Gint := To_Gint (Params, 1);
--    Rows  : Gint := To_Gint (Params, 2);
--    Evt   : Gdk_Event := To_Event (Params, 3);
    begin
       ...

The Params argument is of type Gtk.Arguments.Gtk_Args. To get the
real args, I have to use a bunch of To_G*() conversion calls. If
the API changes at some later date, this now incorrect code will not
be caught at compile time. This bugs me because, as a GUI, this
error may not be noticed for a long time -- in fact, it is likely
the user will find it instead of me. ;-)

Alternatively, the API may never change, but I may not code this
correctly. Once again, I may not be the one that discovers the
problem in a large GUI project.

Where possible, I would prefer to get one consistent strongly
typed interface. If "select row" only returns certain info, then
IMHO the callback should be tailored for this, or at the minimum,
the event data could be a discriminated type.

>>IIRC, there was a certain amount of reliance on a GStrings
>>package/interface too, which annoyed me (and other seemingly C like
>>types).  I would have preferred a native String interface rather than
>>yet another strings package. The numeric types should not at least
>>look like C types (maybe I'm just being picky about this one).

I don't think much of using Gint as a data type, but maybe I am
being fussy. I'd prefer to user more strongly typed data types that
match the parameter or argument's purpose, than any general purpose
argument. If you must, Gint as a base type might be ok.

> Gstrings?

I guess my memory had a parity error on this one.

>>Finally, it seems that every time I try to compile a recent version of
>>GtkAda on FreeBSD, it has numerous compile and install issues. This
>>puts me off, as it will any user that must go through this same
>>process. As a result, I give up and say "try again in a few months".
> 
> What issues?

I'd have to go back and retry this, because there were several compile
time issues. Too many for me to remember right now, and too many to
plow through at the time. If I try it again RSN, I'll email you directly.

Warren.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg