Re: Ada Library, called, returns and continues ?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sun, 16 Dec 2012 15:13:06 -0800 (PST), Patrick wrote:

> I am intimidated with the QT, GTK and WxWidgets landscape right now.

Well, there is a reason for that. GTK and Qt are trying to provide an
OS-independent layer which brings pretty much everything with it.

> I have been focusing on FLTK, Fox, Tk and don't laugh but Xforms. At under
> 100K lines of code(Tk is a little more)

100K lines of GUI code or 100K lines altogether? Anyway it is unrealistic
to hope that you could keep your code tight when using an alien non-Ada
library. Code reduction can only be achieved when the library has a native
Ada interface and deploy OO techniques at full.

> It may be trivial but once I am able to call entries I can turn a single
> threaded application into a multi-threaded one.

No, that would not if you did all work during the entry call (rendezvous).
Because then both the caller and the callee tasks stayed synchronized.

GUI libraries are event-driven, it is a wholly different model which is
inherently synchronous. Calls to entries initially change nothing. You have
to design the GUI in a completely different manner, which is necessarily
complex because does not fit into the model.

> One communication channel
> back that I am considering is returning a string  that would contain code
> that an interpreted language could eval.

You also need to block the Ada task until its return is accepted or else
implement a queue of requests (blocking upon queueing the request).

You also need support for unsolicited calls from Ada tasks. Consider a
progress bar indicator driven by an Ada task. At some point it should send
a message to the main thread to update the bar state. The main thread has
no idea about when and if that could happen.

An alternative solution (used in RT systems) is polling. This is sometimes
simpler to implement for small atomic objects, but it makes GUI design even
more complicated.

> I know eval is evil but if used
> sparingly I think it could be quite powerful

No, it is not. Think about passing parameters forth and back within the
string. You will have to bind them to some local variables. If that looks
simple to you, look at ODBC and other DB interfaces using SQL. They have
exactly this problem - dressing proper calls into an interpreted SQL
string. The result is utter mess.

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