Trivial one-way use (send only) of EQL from any CL

[Polos Ruetz]

So, playing around I had this stupid idea:

- run the "EQL local-server" (example 9)
- load "send.lisp" into any CL

Now you can do this:

#q (qmsg (package-name *package*))

#q (qmsg #.(package-name *package*)) ; pass any data

#q (load "../2-clock.lisp")
#q (qfun clock::*clock* "showMaximized")

--

Paul

[Mark Cox]

Hi Paul,

I have been working on a similar idea for some time. My first attempt can be seen with projects [1] and [2]. The remote-qt-controller library provided a method of serialising and deserialising lisp objects to the remote GUI. The remote GUI in this case is written entirely in C++ using Qt. The interface for exposing remote functions is rather simple [3], but ultimately the entire approach is limited by the requirement of one TCP connection per GUI program. For my purposes, there will be a lot of small GUI programs. Having to manage the connection plus the external process associated with each program seemed wasteful and too much like hard work. Another problem is the inability to extend the serialisation routines to objects outside of what is provided by the library.

These drawbacks led me to consider using a single lisp machine as a GUI server. I started to evaluate ECL, EQL and TinyScheme as a method of interfacing to Qt. The patches I wrote for MAKE-QIMAGE were part of this evaluation process. EQL is very suitable for my purposes and is awesome when coupled with Cells [4].

My current design involves:
1. An extensible serialisation library.
This part is important to me as I require transmission of arrays (matrices) and images. Also important to me is that the client and server may not be on the same host.

2. A completely asynchronous model of communication between the client and server.
Communication from the client to server is for GUI state changes and the communication from server to client is for user events.

3. Cells [4] would be used for synchronising the state of the client and the server.

If any of this interests you then I happy to collaborate. If you have a different idea then I am interested in hearing it. If this sounds like too much hard work then that is ok too. :)

Thanks
Mark

[1] https://github.com/markcox80/remote-qt-controller
[2] https://github.com/markcox80/image-viewer
[3] See image_viewer_application_functions in https://github.com/markcox80/image-viewer/blob/master/cpp/iv-remote-controller.cpp
[4] https://github.com/kennytilton/cells (requires some patches that I have sent upstream)

[Polos Ruetz]

2012/11/7, Mark Cox <mark...@gmail.com>:

> If any of this interests you then I happy to collaborate. If you have a
> different idea then I am interested in hearing it. If this sounds like too
> much hard work then that is ok too. :)

Hi Mark,

thanks for the really interesting links to your work, but I'm in a
completely different situation now:

My new job is not related to programming, and I will probably have
less spare time in future for "playing around" with programming
tools...

I made the trivial "send.lisp" just for fun, and have no personal use for it.

All I will be able to do in future is maintaining EQL, nothing more, sorry.

Paul