graphics and GUIs

[A.J. Rossini]

This is just a placeholder topic...

Mirko's work is worth looking at:   git://github.com/mirkov/cl-grammar-of-graphics.git

See his recent post regarding insights to that.

I just loaded and played around with commonqt -- if we want to have a OS agnostic approach, that might be it.  Reports from R folks (Michael Lawrence and Deepayan Sarkar) suggested incredible performance of QTpaint on rendering on laptops... in 2009.   If someone wants to play around with that, see the 2 examples, which could be tormented into statistical calculators.

Tamas should be posting a backend soon for tikz, which will be important.

We've got a possibility of the earlier cl-2d and cl-cairo2 to experiment and extend (despite Tamas' claims of failure-to-scale and "it ought to be done better", it's a good package to review and read for learning, and to help "get up to speed" on the general lattice-graphics problem).  There's a copy in my github repository for educational purposes.

What else have I missed? 

One of the XLispStat features that was missing for many years in other systems was cross-platform dynamic and interactive graphics. I'd like to bring this back, but this means ensuring that we consider threads around the REPL.

[Peter Schmiedeskamp]

Separating the question of GUI from plot rendering for a moment, I've been thinking a little about this. I hope it's topical now that commonqt has come up as a potential option for gui development.

This may not be quite what you had in mind, but I quite like the model offered by RStudio. It's not quite as interactive as it could be, though I don't think that is necessarily a limitation of the technology (see "manipulate" as part of the RStudio package). 

In short, they wrote their GUI using mainly web technologies. The downloadable IDE is, I think, mainly based on webkit, but without the surrounding chrome.

As a beneficial side effect of this strategy, they are able to run interactively in a web browser. In the case of R, where sometimes it's easier to throw lots of memory at a problem, this turns out to be a very useful characteristic. If I need lots of memory and don't feel like futzing with bigmemory, I can fire up an Amazon EC2 instance with 64GB of RAM, and do my development interactively on the server, but from the comfort of my web browser.

In fact, I've mused that one easy strategy to getting a new-user-palatable interface for CLS would be to simply extend RStudio to use CLS instead of R. That would certainly create a bridge for a large number of existing R users once CLS is ready to roll.

Another example of the "native-looking, local gui based on web technologies" is Light Table, currently a Clojure IDE in development, that I believe is built on a javascript / html5 foundation. If nothing else, it certainly looks pretty. Oh, and there's another one, TileMill: http://mapbox.com/tilemill/

The last time I went looking for GUI libraries for common lisp, I was a bit disheartened. I basically concluded that if I wanted to do a GUI with common lisp, that I would build it as a web service with the option of running locally and being packaged up with its own app icon and other niceties. That appears to be what RStudio, TileMill, and LightTable are all doing.

Cheers,

Peter 

[David Hodge]

On 08/11/2012, at 7:29 AM, Peter Schmiedeskamp <pe...@thoughtspot.net> wrote:

<snip>

Separating the question of GUI from plot rendering for a moment, I've been thinking a little about this. I hope it's topical now that commonqt has come up as a potential option for gui development.

This may not be quite what you had in mind, but I quite like the model offered by RStudio. It's not quite as interactive as it could be, though I don't think that is necessarily a limitation of the technology (see "manipulate" as part of the RStudio package). 

In short, they wrote their GUI using mainly web technologies. The downloadable IDE is, I think, mainly based on webkit, but without the surrounding chrome.

For the moment, and the foreseeable futureI would hope that we just stick with Slime and Emacs.

From an UI perspective (and I am sure Tony will correct when I am wrong !:) its my belief that we want to leverage the lisp environment as much as possible and develop a "lisp statistical dsl" that aids common tasks but removes the restrictions that various UI's/IDE's seem to impose. THis is not for everyone I guess, but it more targeted at people who want that sort of power and flexibility.

It may well be that once CLS has solidified, someone would want to take this on, but that would be waaay off into the future.

As a beneficial side effect of this strategy, they are able to run interactively in a web browser. In the case of R, where sometimes it's easier to throw lots of memory at a problem, this turns out to be a very useful characteristic. If I need lots of memory and don't feel like futzing with bigmemory, I can fire up an Amazon EC2 instance with 64GB of RAM, and do my development interactively on the server, but from the comfort of my web browser.

In fact, I've mused that one easy strategy to getting a new-user-palatable interface for CLS would be to simply extend RStudio to use CLS instead of R. That would certainly create a bridge for a large number of existing R users once CLS is ready to roll.

Another example of the "native-looking, local gui based on web technologies" is Light Table, currently a Clojure IDE in development, that I believe is built on a javascript / html5 foundation. If nothing else, it certainly looks pretty. Oh, and there's another one, TileMill: http://mapbox.com/tilemill/

The last time I went looking for GUI libraries for common lisp, I was a bit disheartened. I basically concluded that if I wanted to do a GUI with common lisp, that I would build it as a web service with the option of running locally and being packaged up with its own app icon and other niceties. That appears to be what RStudio, TileMill, and LightTable are all doing.

Cheers,

Peter 

--
You received this message because you are subscribed to the Google Groups "Common Lisp Statistics" group.
To post to this group, send email to lisp...@googlegroups.com.
To unsubscribe from this group, send email to lisp-stat+...@googlegroups.com.
Visit this group at http://groups.google.com/group/lisp-stat?hl=en.
 
 

[Peter Schmiedeskamp]

For the moment, and the foreseeable futureI would hope that we just stick with Slime and Emacs.

From an UI perspective (and I am sure Tony will correct when I am wrong !:) its my belief that we want to leverage the lisp environment as much as possible and develop a "lisp statistical dsl" that aids common tasks but removes the restrictions that various UI's/IDE's seem to impose. THis is not for everyone I guess, but it more targeted at people who want that sort of power and flexibility.

It may well be that once CLS has solidified, someone would want to take this on, but that would be waaay off into the future.

I too prefer to work in emacs / slime. I also agree that a GUI probably comes some time after we get the basics. In my defense, I was responding to a thread titled "graphics and GUIs" :-)

Cheers,

Peter

 

[A.J. Rossini]

On Thursday, November 8, 2012 1:31:33 AM UTC+1, David Hodge wrote:

From an UI perspective (and I am sure Tony will correct when I am wrong !:) its my belief that we want to leverage the lisp environment as much as possible and develop a "lisp statistical dsl" that aids common tasks but removes the restrictions that various UI's/IDE's seem to impose. THis is not for everyone I guess, but it more targeted at people who want that sort of power and flexibility.

It may well be that once CLS has solidified, someone would want to take this on, but that would be waaay off into the future.

So, there are two things here.

#1 - the statistical DSL.  Absolutely critical, I'm NOT trading that in.   Long verbose Common Lisp, Ditto.  Specific dialects which provide terse abbreviations and shorthands, the terseness goes into the dialekt, not into the root language/DSL.    Of course, that's the long term goal, plenty of shorthand notation before it is reached, and no need to prematurely optimize the development yet.

#2 - the need for a widget set for GUIs -- absolutely essential at some point.  workflows on how to create data-analytic applications which might have GUIs, from a cross-platform IDE, would be nice.

"at some point".

However, we need a place to render visualizations, and if folks are figuring out a general API for 3d dynamic graphics on QT, and since commonQT works, it might be worth a general evaluation.

No discussion over just how ugly, horrid, or annoying QT is, or it's relationship to KDE, keep it positive, politely suggesting better alternatives :-)

best,
-tony

[David Hodge]

On 09/11/2012, at 7:53 PM, A.J. Rossini <blind...@gmail.com> wrote:

O<snip>

No discussion over just how ugly, horrid, or annoying QT is, or it's relationship to KDE, keep it positive, politely suggesting better alternatives :-)

I'll look at commonQT - however i think that as an interim measure at l;east gnu plot is still my choice. 

The other attractive approach is D3.js - not that i have much of an idea about it other than an hour or so playing with it and being very impressed with what I saw. The upside is similar cross platform capability, the downside is having to have a web server and Javascript. And there is a discussion in itself - QT vs Javascript…..hmmmm…..

And, the world caught up with me as well so not a whole lot got done this week. I have tomorrow afternoon set aside as my birthday present to myself, so I plan to have some lisp style fun while the kids are swimming!

Cheers

best,
-tony

[A.J. Rossini]

On Friday, November 9, 2012 1:40:20 PM UTC+1, David Hodge wrote:

On 09/11/2012, at 7:53 PM, A.J. Rossini <blind...@gmail.com> wrote:

O<snip>

No discussion over just how ugly, horrid, or annoying QT is, or it's relationship to KDE, keep it positive, politely suggesting better alternatives :-)

I'll look at commonQT - however i think that as an interim measure at l;east gnu plot is still my choice. 

The other attractive approach is D3.js - not that i have much of an idea about it other than an hour or so playing with it and being very impressed with what I saw. The upside is similar cross platform capability, the downside is having to have a web server and Javascript. And there is a discussion in itself - QT vs Javascript…..hmmmm…..

Well, I'm up for functionality, with the caveat that it be understandable by those who I think should understand it (i.e. most of the folks reading this).  Lots of things to try out, but still have to get the dataframe stuff working!