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

[Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

> Preben Randhol wrote:
> Now a point for discussion for GtkAda:
> 
> I need to be careful here, because I don't want to criticize
> volunteer's efforts in this area. I would rather encourage
> them to continue with their efforts, since I think their
> goals are in line with most of ours in the Ada & GUI sense.
> However, I do have a few concerns about the
> implementation as it stands.

Me, too :).

> Forgive me if I don't quite have the facts correct here, because
> it's been a while since I last worked with GtkAda...
> 
> 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. 

I agree the current situation is not up to "Ada standards". For
example, just yesterday I cut and pasted a callback. It compiled
without error, did the Gtk "connect" call without error, but failed
with a stack error (not an Ada exception; just a Windows signal) at
run time. It turned out I had missed a parameter in the callback;
something an Ada compiler is supposed to catch at compile time.

> 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).

I have not looked at it closely enough to see what the real problem
is. I suspect it is a matter of writing complete bindings, and then
writing an Ada polymorphic wrapper. But it's not that simple, because
Gtk has its own object/dispatching model. That model is very powerful,
and we don't want to lose it. We also want to be able to keep up with
Gtk changes/evolution, so we don't want to much investment in the
binding layer that might have to change.

> IIRC, there was a certain amount of reliance on a GStrings
> package/interface too, which annoyed me (and other seemingly C like
> types). 

I have not encountered GStrings in my GtkAda work, so they may be gone.

> 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).
> 
> 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".

I'm using a binary release for Windows. It's quite old; Gtk 1.2. There
is now a Gtk 2.0, and GtkAda 2.0 for Linux. It seems like every
question I post to the GtkAda mailing list is answered with "that
works in Gtk 2.0". So I have the same complaint you do, but for
Windows.

I'm going to try to compile GtkAda for Cygwin, and see what that does.
Cygwin ought to be close enough to Linux by now for this to work.

-- 
-- Stephe