Ada-Python demo

Ada-Python demo

[Maciej Sobczak]

Hi,

Some time ago I have posted an article presenting the principles of writing Ada loadable modules that can be used as extensions for Python scripts.
This time I have gathered some basics for the opposite case, which is writing the Ada program that embeds the Python interpreter and loads external Python scripts:

http://www.inspirel.com/articles/Ada_Python_Demo.html

Having covered both directions of the inter-language integration, the article also contains the complete two-part working demo that shows all this magic working.

All comments are welcome.

-- 
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Ada-Python demo

[Gour]

On Thu, 11 Jul 2013 14:12:24 -0700 (PDT)
Maciej Sobczak <see.my.homepage@gmail.com> wrote:

> Hi,

> Some time ago I have posted an article presenting the principles of
> writing Ada loadable modules that can be used as extensions for
> Python scripts. 

Thank you. Read your article about calling Ada modules from within
Python and wonder, if you explored that idea further, what do you think
if it would be feasible to write the whole back-end/libraries of
application using Ada and then glue everything together in GUI app
written with PyQt?


Sincerely,
Gour

-- 
The intricacies of action are very hard to understand. 
Therefore one should know properly what action is, 
what forbidden action is, and what inaction is.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

Re: Ada-Python demo

[Maciej Sobczak]

> Thank you. Read your article about calling Ada modules from within
> Python and wonder, if you explored that idea further, what do you think
> if it would be feasible to write the whole back-end/libraries of
> application using Ada and then glue everything together in GUI app
> written with PyQt?

It makes perfect sense, especially if you take into account that GUI in Ada is kind of shaky subject. This might be a valid idea also for teams where some programmer(s) might be more Ada-oriented while other(s) might happen to be Python fans - problem solved, all programmers will be happy. :-)

On the other hand, in the context of writing GUI I would consider even more options. Extending Python interpreter with Ada modules means that there exists a single process that does everything. Why not divide the whole application into separate processes: one (or many) handling the business logic and another for the UI. This can open some interesting options like having desktop GUI (Python? Java? etc.) *and* web-based interface (AWS? Java? etc.) *and* perhaps even something else (mobile app?) for the same functionality.
In this case, instead of investing into inter-language integration at the level of Python interpreter (note that it basically binds you to a single scripting language) I would consider going full distributed.

No, I'm not trying to discourage you from the Ada-Python integration (what would be the point of creating the demo? :-) ), but keeping alternatives in the back of our minds is probably a good idea.

-- 
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Ada-Python demo

[Thomas Løcke]

On 07/12/2013 09:53 AM, Maciej Sobczak wrote:
> Why not divide the whole application into separate processes: one (or many) handling the business logic and another for the UI. This can open some interesting options like having desktop GUI (Python? Java? etc.) *and* web-based interface (AWS? Java? etc.) *and* perhaps even something else (mobile app?) for the same functionality.
> In this case, instead of investing into inter-language integration at the level of Python interpreter (note that it basically binds you to a single scripting language) I would consider going full distributed.


I like the way you think Maciej.  :)

And thanks for the demo.

-- 
Thomas Løcke | thomas@12boo.net | http://12boo.net

Re: Ada-Python demo

[Gour]

On Fri, 12 Jul 2013 00:53:19 -0700 (PDT)
Maciej Sobczak <see.my.homepage@gmail.com> wrote:

> It makes perfect sense, especially if you take into account that GUI
> in Ada is kind of shaky subject. 

Yeah, I'm aware of it...too bad there is no one *common* QtAda project.
:-/

> This might be a valid idea also for teams where some programmer(s)
> might be more Ada-oriented while other(s) might happen to be Python
> fans - problem solved, all programmers will be happy. :-)

Well, it sounds better than we tried to use only Haskell and few of
(potential) contributors just run away in fear. :-)

otoh, I'm a little concerned about what will happen with type-safety
when entering data into Python-powered GUI loop and rendering it back
after being processed by Ada part?

if the cost is too hight, then it's maybe better to wrestle with GUI in
Ada.

> On the other hand, in the context of writing GUI I would consider
> even more options. Extending Python interpreter with Ada modules
> means that there exists a single process that does everything. Why
> not divide the whole application into separate processes: one (or
> many) handling the business logic and another for the UI. 

That's one possibility.

> This can open some interesting options like having desktop GUI
> (Python? Java?  etc.) *and* web-based interface (AWS? Java? etc.)
> *and* perhaps even something else (mobile app?) for the same
> functionality. 

At the moment, I simply do not believe that web interface can replace
desktop GUI, at least, in our case.

Otoh, using Qt(5) seems to cover many/most of those interfaces by
staying within the realm of Qt only.

> No, I'm not trying to discourage you from the Ada-Python integration
> (what would be the point of creating the demo? :-) ), but keeping
> alternatives in the back of our minds is probably a good idea.

Certainly it is. However, at the moment I still believe that desktop is
the interface which would be most appropriate and/or mostly used.


Sincerely,
Gour

-- 
The spirit soul bewildered by the influence of false ego thinks 
himself the doer of activities that are in actuality carried out 
by the three modes of material nature.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

Re: Ada-Python demo

[Marc C]

On Friday, July 12, 2013 2:53:19 AM UTC-5, Maciej Sobczak wrote:

> It makes perfect sense, especially if you take into account that GUI in Ada is kind of shaky subject. This might be a valid idea also for teams where some programmer(s) might be more Ada-oriented while other(s) might happen to be Python fans - problem solved, all programmers will be happy. :-)

What I found optimal was writing the "engine" in Ada, with a PyGtk-based Python GUI (built with GLADE). Then I used JSON over ZeroMQ to communicate between the two processes

Minimum pain, and maximum productivity.

The JSON/ZeroMQ also made it easy to build other specialized-GUI, or non-GUI, drivers for the engine process.

Marc A. Criley

Re: Ada-Python demo

[Gour]

On Fri, 12 Jul 2013 05:56:22 -0700 (PDT)
Marc C <mc.provisional@gmail.com> wrote:

> What I found optimal was writing the "engine" in Ada, with a
> PyGtk-based Python GUI (built with GLADE). Then I used JSON over
> ZeroMQ to communicate between the two processes

Thanks a lot for sharing. Very interesting. ;)

> The JSON/ZeroMQ also made it easy to build other specialized-GUI, or
> non-GUI, drivers for the engine process.

May I know what kind of app it is?


Sincerely,
Gour

-- 
Bewildered by the modes of material nature, the ignorant fully 
engage themselves in material activities and become attached. But 
the wise should not unsettle them, although these duties are inferior 
due to the performers' lack of knowledge.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

Re: Ada-Python demo

[Marc C]

On Friday, July 12, 2013 10:51:52 AM UTC-5, Gour wrote:
> On Fri, 12 Jul 2013 05:56:22 -0700 (PDT)
> 
> Marc C <mc.provisional@gmail.com> wrote:
> > What I found optimal was writing the "engine" in Ada, with a
> > PyGtk-based Python GUI (built with GLADE). Then I used JSON over
> > ZeroMQ to communicate between the two processes
> 
> Thanks a lot for sharing. Very interesting. ;)
> 
> > The JSON/ZeroMQ also made it easy to build other specialized-GUI, or
> > non-GUI, drivers for the engine process.
> 
> May I know what kind of app it is?

The specifics are proprietary, but the GUIs are basically configuration setup, start/stop, and monitoring the activities.  The engines are just data manglers.

Marc

Re: Ada-Python demo

[Gour]

On Fri, 12 Jul 2013 10:11:57 -0700 (PDT)
Marc C <mc.provisional@gmail.com> wrote:

> The specifics are proprietary, but the GUIs are basically
> configuration setup, start/stop, and monitoring the activities.  The
> engines are just data manglers.

OK. Thanks.


Sincerely,
Gour

-- 
Therefore, without being attached to the fruits of activities, 
one should act as a matter of duty, for by working without 
attachment one attains the Supreme.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

Re: Ada-Python demo

[Maciej Sobczak]

> What I found optimal was writing the "engine" in Ada, with a PyGtk-based Python GUI (built with GLADE). Then I used JSON over ZeroMQ to communicate between the two processes
> 
> Minimum pain, and maximum productivity.

Heck, I cannot agree with this. Both JSON and ZeroMQ is just low-level mess.
You might want to read this:

http://www.inspirel.com/articles/YAMI4_vs_ZeroMQ.html

I also find it disturbing that you consider JSON to be appropriate on the Ada side. What about this:

http://www.inspirel.com/yami4/book/10.html
http://www.inspirel.com/yami4/book/10-2.html
http://www.inspirel.com/yami4/book/10-4-1.html

YAMI4 allows you to write your next (!) distributed system without sacrificing the advantages of Ada. Integration with the Ada tasking model and type safety are features that you should be asking for.

-- 
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Ada-Python demo

[Peter Brooks]

On Saturday, 13 July 2013 23:06:31 UTC+2, Maciej Sobczak  wrote:
> > What I found optimal was writing the "engine" in Ada, with a PyGtk-based Python GUI (built with GLADE). Then I used JSON over ZeroMQ to communicate between the two processes
> 
> > 
> 
> > Minimum pain, and maximum productivity.
> 
> 
> 
> Heck, I cannot agree with this. Both JSON and ZeroMQ is just low-level mess.
> 
> You might want to read this:
> 
> http://www.inspirel.com/articles/YAMI4_vs_ZeroMQ.html
> 
This is interesting - I should have read this before posting my other question..

However, reading the article, it looks as if YAM14 uses its own data model language that isn't translatable into any ontology language - which seems a major problem.

Surely a communication language like this ought first to be defined in an ontology?
> 
> 
> I also find it disturbing that you consider JSON to be appropriate on the Ada side. What about this:
> 
> 
> 
> http://www.inspirel.com/yami4/book/10.html
> 
> http://www.inspirel.com/yami4/book/10-2.html
> 
> http://www.inspirel.com/yami4/book/10-4-1.html
> 
> 
> 
> YAMI4 allows you to write your next (!) distributed system without sacrificing the advantages of Ada. Integration with the Ada tasking model and type safety are features that you should be asking for.
> 
There's a lot of wheel re-inventing here. The advantage of using an ontology is that all the mappings are defined independent of language, so should be easy to port into any language that can interpret ontologies without the need for specific, error-prone interfaces for each language.

Re: Ada-Python demo

[Georg Bauhaus]

On 15.07.13 08:43, Peter Brooks wrote:
> On Saturday, 13 July 2013 23:06:31 UTC+2, Maciej Sobczak  wrote:

>> YAMI4 allows you to write your next (!) distributed system without sacrificing the advantages of Ada. Integration with the Ada tasking model and type safety are features that you should be asking for.
>>
> There's a lot of wheel re-inventing here. The advantage of using an ontology is that all the mappings are defined independent of language, so should be easy to port into any language that can interpret ontologies without the need for specific, error-prone interfaces for each language.

A translation from OWL to YDL should be straight forward, using an XSL
translation. OTOH, XML seems hugely unpopular with Adaists who, while
they like using a language sensitive editor for data types written in Ada,
would never accept language sensitive editing of data types written in OWL,
since the latter uses XML which is always to be dismissed in favor of
more direct expression in Ada. Even when the portable description would
eventually be mapped to Ada.

AFAIK, DGs are usually handled with the help of maps (Ada.Containers,
Booch components) or graphs' nodes (Booch components).
There are some Prolog engines written in Ada, see e.g. adapower.com.

Re: Ada-Python demo

[Maciej Sobczak]

> > http://www.inspirel.com/articles/YAMI4_vs_ZeroMQ.html

> However, reading the article, it looks as if YAM14 uses its own data model language

Not exactly. YAMI4 *poposes* the data model out of the box, as this is what is normally needed.
If you have a communication solution that does not offer any data model at all (ZeroMQ comes to mind, similarly to other low-level libraries), then users are forced to solve the problem of data model and serialization *in addition* to the communication, which leads to using *two* different libraries (like ZeroMQ with JSON, or sockets with protobuf, etc.) for handling what is essentially a single problem: make two programs talk. Why the hell would you want to use two separate libraries to solve this single problem?

YAMI4 recognizes that and proposes a data model that is more or less equivalent in terms of expressiveness to JSON (that is, there is a small set of basic data types, arrays and nesting). And it happens to directly map to Python's directory, which makes it trivial to use in that language and programmers in other languages have the option to describe their object in YDL. Thanks to this users can just take a single library and solve their *single* problem of making two programs talk - no need to mess with two separate products (think: licensing, integration, support, etc.).

However, YAMI4 does not force users to commit to that particular data model and if in a given system it makes sense to use other data models or serialization schemes, it is perfectly possible - YAMI4 supports also raw binary data buffers. That is, you can use anything you like (JSON, ASN.1, XML, ontologies, whatever) with YAMI4.

Interestingly, as far as I know, *nobody* does it. In other words, nobody chooses to benefit from the freedom to use anything they like. Which kind of suggests that having a data model that works out of the box is perhaps a better idea than not having it and pretending that communication and data model are independent. Technically they are, but from the usability point of view they are closely related.

> that isn't translatable into any ontology language - which seems a major problem.

Not at all. :-)

-- 
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Ada-Python demo

[Peter Brooks]

On Monday, 15 July 2013 10:10:27 UTC+2, Maciej Sobczak  wrote:
> 
> Interestingly, as far as I know, *nobody* does it. In other words, nobody chooses to benefit from the freedom to use anything they like. Which kind of suggests that having a data model that works out of the box is perhaps a better idea than not having it and pretending that communication and data model are independent. Technically they are, but from the usability point of view they are closely related.
> 
A lot of people design ontologies, they're very important, so far mainly in static but large repositories.

I'm keen on one for a much less static situation.

A also agree that XML is not a good basis, so I'd prefer work with dot and JSON.

Re: Ada-Python demo

[Marc C]

On Saturday, July 13, 2013 4:06:31 PM UTC-5, Maciej Sobczak wrote:

> Heck, I cannot agree with this. Both JSON and ZeroMQ is just low-level mess.
>
> You might want to read this:
>  
> http://www.inspirel.com/articles/YAMI4_vs_ZeroMQ.html
> 
> I also find it disturbing that you consider JSON to be appropriate on the Ada side. What about this:
> 
> http://www.inspirel.com/yami4/book/10.html
> http://www.inspirel.com/yami4/book/10-2.html
> http://www.inspirel.com/yami4/book/10-4-1.html
>
> YAMI4 allows you to write your next (!) distributed system without sacrificing the advantages of Ada. Integration with the Ada tasking model and type safety are features that you should be asking for.

YAMI4 is a perfectly fine distributed messaging system, I've got no argument with its strengths and capabilities, and it has clearly been put to excellent use.

The messaging interfaces I'm referring to here are *very* simple. Nearly all of the handful of commands consist of a Target_ID (String), Command (String), and Associated_Data_Item (String). The response/broadcast messages consist of Source_ID (String), Error_Status_Message (String), and Data (String). This is *all* that's needed for these applications. Should more complex interaction be required, the messaging infrastructure decision would be reevaluated.

ZeroMQ has an Ada binding (http://www.zeromq.org/bindings:ada), around which I wrapped a thicker binding, TOMI_4_Ada (http://sourceforge.net/projects/tomi4ada). So it's perfectly comfortable being integrated into a multi-tasking Ada application.

Maintaining an IDL (or a YDL), performing code generation, and integrating the generated code skeletons into the app is way more than what's needed here given the minimal requirements and the tools that are already at hand.

At some point the app may be distributed, and the desire is to leave open the possibility of customers writing their own site-specific viewers and controllers.  It's much easier to tell them then can leverage their own in-house JSON expertise over the well-known ZeroMQ protocol, than tell them they have to acquire YAMI4 and either go GPL or purchase a license.

While we're fully comfortable with full GPL for applications, we don't like it for utilities/libraries/infrastructure type things. LGPL, GMGPL or some variant thereof is much preferred. While YAMI4 provides a Boost license for some fee, the accompanying dedicated technical support, while surely valuable to those who need it--is not needed for these apps.

With a simple interface, capable bindings readily available, and no license management to worry about, JSON over ZMQ was an easy decision for these particular applications.

YMMV.

Marc A. Criley