Language agnostic graphics (Project in CL + LTK)

Discussion of Common Lisp

Re: Language agnostic graphics (Project in CL + LTK)

Postby Pixel_Outlaw » Sat Oct 19, 2013 12:27 pm

Ouch, that kind of undermines the whole project...
*IF* I understand you correctly.
Pixel_Outlaw
 
Posts: 41
Joined: Mon Aug 26, 2013 9:24 pm

Re: Language agnostic graphics (Project in CL + LTK)

Postby edgar-rft » Sat Oct 19, 2013 2:54 pm

Lisp is somehow the opposite of shell programming.

Lisp is not meant to be started every time anew. You start Lisp once, then you re-program the running Lisp program by loading Lisp code, and then you control everything from the REPL.

It's like your first program: Start Lisp (once), load LTK (once), load your Lisp code (once), then load and plot data-files as many times as needed, but do not quit Lisp after every data-file, because the "load Lisp, load LTK, load code" overhead is not small.

I'm also wondering that LTK seems to lack the most important property of Lisp (and Tcl/Tk as well): interactive programming.

I'm currently investigating lisp2wish, one of the predecessors of LTK, to write a specialized interactive Tcl/Tk canvas handler. Then afterwards I will try to integrate the code into LTK. I don't understand the LTK :serve-event input-handler machinery enough to modify LTK right now, I first must try out what's important and what not.

- edgar
edgar-rft
 
Posts: 154
Joined: Fri Aug 06, 2010 6:34 am
Location: Germany

Re: Language agnostic graphics (Project in CL + LTK)

Postby edgar-rft » Mon Oct 21, 2013 8:45 pm

I've discovered another problem that I hadn't thought about: Emacs SLIME can't send new REPL input while CL evaluates a Lisp form. This has to the consequence that I can't write a CL stream dispatcher (a function that reads from multiple input streams) for the SLIME input stream, because SLIME can't send new characters from the REPL while CL evaluates the dispatcher loop and new characters reach CL only after the loop has stopped. In a terminal window the dispatcher works, but with Emacs and SLIME it doesn't. Silly but true.

It looks as if my idea evolves into a too much doctoral thesis for my taste and meanwhile I think it would be easier to use a Tcl/Tk text widget to implement a simple control REPL for the canvas, what I will try next. This way the Tcl/Tk event loop can be used to control the REPL and the canvas, and nobody would be forced to use Emacs to control the whole thing.

- edgar
edgar-rft
 
Posts: 154
Joined: Fri Aug 06, 2010 6:34 am
Location: Germany

Re: Language agnostic graphics (Project in CL + LTK)

Postby pjstirling » Tue Oct 22, 2013 6:29 am

If you don't care about the output going to the repl then you can just write a helper function that spawns threads to do the work (bordeaux-threads is a portable library for doing this), for a bit more effort you can have a thread pool so that you never try to run more requests than processor cores you have free.
pjstirling
 
Posts: 74
Joined: Sun Nov 28, 2010 4:21 pm

Re: Language agnostic graphics (Project in CL + LTK)

Postby edgar-rft » Tue Oct 22, 2013 7:48 am

pjstirling wrote:If you don't care about the output going to the repl...

Hmm ... question: Does interactive programming make sense if I don't see the return values?

pjstirling wrote:... you can have a thread pool so that you never try to run more requests than processor cores you have free.

In my case this is not really complicated, because I don't have a multicore machine.

Please don't get me wrong, thanks for your help, but the problem is that I need to synchronize:

  • LTK wish input (Tcl/Tk commands)
  • LTK wish output (Tcl/Tk widget callbacks and other Tcl/Tk return values)
  • REPL input (arbitrary Lisp forms)
  • REPL output (canvas coordinates and other Lisp return values)
with the standard CL i/o-streams.

Using a Tcl/Tk text widget for the REPL automatically synchronizes the CL REPL with the Tcl/Tk wish event loop because Tcl/Tk cannot send multiple widget callbacks at the same time.

Meanwhile I think that the event loop synchronisation is the main reason why LTK has no built-in capabilities for interactive programming (except the non-portable :serve-event machinery, that works with CMUCL and SBCL only).

Of course everybody is free to write a thread-based framework for this task (and thanks again to pjstirling for the pointers), but I think that this is just simply too much work for a small turtle and plotting canvas.

- edgar
edgar-rft
 
Posts: 154
Joined: Fri Aug 06, 2010 6:34 am
Location: Germany

Previous

Return to Common Lisp

Who is online

Users browsing this forum: Bing [Bot], logxor and 5 guests