re LT: It'd be a natural thing to dig into if/when you look to move to cljs.
For the context at hand I think of an LT plugin as something that: - is easy to edit code/text in - has access to ways of executing "remote" code via nrepl and get back results - have access to files and resources etc via node modules - have access to HTML UI since LT is effectively Chromium in that regard - the plugin itself would most naturally be clojurescript All in all sounds like it could be a nice platform. Your plugin could have some custom ways to execute code which means you get to intercept results as e.g. EDN and then do the same kind of thing you do in the current version - take the descriptive data and generate an HTML UI representation. The UI rep you could have live update inside LT a side-by-side tab to your input source/document for example. (I've got some similar dreams but not sure I'll be able to dig into it anytime soon) On Sunday, February 23, 2014 5:22:32 PM UTC, Jony Hudson wrote: > > Hi, > > thanks again for the kind words and enthusiasm! Let me try and give my > thoughts on some of the points raised: > > ** Light table plugin (@Patrik) ** > > I would like to see this, as I think LT has a lot of potential. Things > like file-handling UI, nice code editing ... are all difficult problems > that I've not really tackled in Gorilla. Light table has those already, so > I could see it working well. I haven't the foggiest how to do it though! > > > ** Extensible (@Jeff) ** > > Yes, it's good to say this explicitly as I think this is key. At the > moment it's very poor in that regard. Before it happens I think the central > thing to pin down and get right is ... > > > ** Value rendering and interaction (@Jeff) ** > > This, to my mind, is the place where real design decisions have to be > made. There are some free-floating ideas in my head, but nothing really > joined-up yet. > > If we leave aside interactivity for a minute: the one thing that is clear > to me is that having the back-end return plain old Clojure values is a > *good idea*. Things you run just produce values, and the front-end knows > how to present values in a way that's helpful to the user. There should be > no state in the front-end that can be accessed by the back-end, no > messaging etc. This I see as the central idea. It's what makes it possible > to compose plots, (and hypothetically) append tables, make a tree-diagram > with plots as nodes, display formulae in tables etc. Because everything > displayed by the front-end is just a Clojure value, and you can manipulate > those as you wish. > > Ultimately, everything has to end up as something the browser can display. > At the moment, all of this conversion is happening in the browser. I had > resisted having this conversion happening in the back-end because I was > nervous about having the front-end evaluate things on the back-end that the > user hasn't explicitly asked for. But maybe that isn't a problem as long as > the rendering functions are tastefully written (i.e. side-effect free). So > maybe what Jeff suggests is the right idea: allow rendering on the > front-end or the back-end, and make these renderers easy to plug in. > Back-end rendering works well for extensibility too, as renderers could be > plugged in as needed per project. Extending the set of renderers on the > front end, looks less clean - either they'd be baked in, or there'd need to > be some way to inject them at runtime. Perhaps the preference should be for > back end rendering, with a small set of standardised renderers on the front > end? It's still unclear to me how the wiring will work - I think I probably > have to prototype something (maybe table rendering) and see how it looks. > > As for interactivity, I think this is a really tricky one. Wolfram, with > Mathematica, have done a _really_ nice job with this. In case you're not > familiar, the heart of it is a dependency-tracking, reactive variable > system (Dynamic[]). And on top of this they've come up with a nice language > for describing UI. It's extremely impressive, but it's also a pretty large > engineering effort I think. I wonder whether a more modest goal might not > be the right thing to try for (given I don't see us bringing the same > resources as Wolfram to bear on the problem!). I found with monkeycruncher > that you can get almost all of what you might want to do regarding > interactivity with a much more restricted mode of interaction. It had a > "Bret Victor" style "live mode" where you could edit the code and see the > results change live. It also had some neat UI (sliders, colour pickers) to > edit parts of the code fluidly. I found that this worked really well, and > it fits very well with the idea above (edit code, automatically > re-evaluate, generates new value, new value is rendered). > > I'd love to hear your thoughts on all of this :-) > > > ** Implementing client in Clojurescript (@Jeff) ** > > Yes, cljs etc would probably have been a very good fit. But I already had > some code and plenty of experience with javascript and knockout.js (which > is a very lovely piece of software IMHO). I'd be disinclined to port it to > cljs unless there was a compelling reason to do so! > > > ** Core.matrix (@Mikera) ** > > Yes. Definitely should happen! > > > ** Load/save problems (@Fabian) ** > > I can't reproduce this on my machine (Mac OS) with Chrome. It doesn't save > into non-existent directories, but it does give an error message for me on > this. I can load/save worksheets to the root directory. Can you confirm you > can reproduce the problem, and if so perhaps file a Github issue with > details of your setup? > > > ** MathML support (@mmower) ** > > I think this already works, as in I can paste in some MathML and it > renders as a formula. It's so horrible compared to laTeX though I don't see > why you'd want to do it! Get revising that laTeX :-) > > > A long post! Love to hear your thoughts, and thanks for the support :-) > > > Jony > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
