libera/#clim - IRC Chatlog
Search
10:56:51
lukego
jackdaniel selwynning: basically I want to produce some animated SVGs and for present purposes clime/mcclim-emacs seems preferable to other options like raw SVG, reveal.js, blender, etc. So I'm trying to quickly get it up and running again but with the complication that I switched from SLIME to SLY and so it needs porting :)
10:57:51
jackdaniel
I think that the svg backend as it is now is incapable of producing animations so that may be a problem
11:00:44
jackdaniel
I hope that you've meant build not burn because it is hard to cross a burning bridge! ;)
11:04:25
lukego
yeah I blew the dust of that, it's from the standard set of idioms that my grandfather's generation were into
11:04:59
jackdaniel
speaking of animations, I've already removed a few obstacles towards that goal, but there are still some
11:05:35
lukego
I haven't actually read the SVG animation spec yet but I'm anticipating being able to e.g. define keyframes saying where things should be at a point in time and then interpolate between them
11:05:48
jackdaniel
mcclim already can do ad-hoc animations with double buffering and clever event scheduling, but having them as a first class concept requires some extra work on the repaint queue (which is planned)
11:06:35
lukego
I'm meaning to present them in the browser e.g. revealjs slideware. I mostly want the emacs/mcclim integration for a comfy development workflow.
11:07:01
lukego
I gather that browsers have mutiple ways to animate things e.g. both at the SVG and CSS levels.
11:07:34
lukego
right. it was the thought of writing javascript code that made me come crawling back to mcclim :)
11:07:50
jackdaniel
imo it is a shame that they've botched svg format to include javascript programming language and css as parts of it
11:11:11
jackdaniel
that's another question whether emacs renderer supports animated svg's (I don't know, just asking)
11:11:35
lukego
I think it does. or at least animated bitmaps, and it internally renders SVGs to bitmaps during the input/import process.
11:12:26
lukego
"multi-frame images" https://www.gnu.org/software/emacs/manual/html_node/elisp/Multi_002dFrame-Images.html
11:13:36
lukego
I'd actually like to do this in Blender but I'm not sure how suitable its animated-SVG-export feature is and also I'd like to write Lisp code to specify the positions of things at various things.
11:21:16
lukego
since the last time I was here I spent quite a bit of time hacking Julia before concluding that it's not really a substitute for Lisp nor, really, even for R.
11:21:51
jackdaniel
thanks, it is temporarily stalled by other mcclim and ecl tasks but I think that I've cracked the most pressing conceptual issues for now
11:23:13
jackdaniel
https://c10.patreonusercontent.com/4/patreon-media/p/post/75916637/336466f3c00041e6aa6e06ab317f2088/eyJxIjoxMDAsIndlYnAiOjB9/1.png?token-time=1677110400&token-hash=cIf-IqdaTvRRM6jsvfZB49f_fTRdbQhdH0yTL-rHaEU%3D this is the picture of grouped bar charts (dodging and all)
11:25:08
jackdaniel
currently it is licensed under agpl-3.0+, that may potentially change later when it is finished
11:29:22
lukego
that screenshot is impressive :) easy to imagine wanting to switch to this for visualizing data generated in lisp. my workflow in Julia was usually to dump a CSV to an R/ggplot2 process that's running in tandem.
11:30:14
lukego
and if e.g. points in scatterplots could be proper presentations of objects that could be really killer.
11:31:00
jackdaniel
on the other hand creating a presentation is not that much expensive, depends how much data we are talking about
11:33:03
jackdaniel
another angle that is not really covered by ggplot is making the plot interactive
11:33:12
lukego
the scatterplots I did in julia tended to have thousands of points. that could give the Emacs side of CLIME a workout trying to track the presentations, I don't remember what data structure it uses off hand :)
11:34:03
jackdaniel
mcclim has a well optimized spatial tree, so it should handle thousands of points easily
11:34:06
lukego
yeah ggplot2 is a bit of a pain in the ass. random walk through options looking for a publication-quality result. better for scientists than engineers
11:34:46
jackdaniel
grammar of graphics was "invented" by the creator of ggplot2, and there are many good things there conceptually
11:35:05
jackdaniel
earlier I've written (unreleased) library for generating charts without thinking things through
11:35:17
lukego
yeah. it's the best tool for me for now, but it feels like something more geared towards creating "just so" graphs to present to other people, than wrangling my own data.
11:35:29
jackdaniel
it was a hot pulsating mess; having a guide in a form of a "grammar" is a godsend
11:57:23
jackdaniel
if I remember correctly from key features only faceting is missing; other than that it is a matter of polishing and adding new chart types / statistics. but there is readme.org that ought to know better than I remember now
12:57:53
lukego
I wonder what's the best (default) behaviour for clime to show presentations from lisp/mcclim. should the repl automagically #'present results, as I guess the clim-listener does? or should the lisp side always explicitly say "present this in emacs"? and/or should the presentations be written inline in the repl or pop up in a buffer?
12:58:59
lukego
Emacs is equally happy for presentations to appear anywhere, you can even kill and yank them and they keep on working. original behaviour is that lisp code needs to explicitly ask for the presentation to appear in Emacs and it gets inlined into the repl.
13:01:05
lukego
maybe there should be separate integrations for repl/inspector/debugger/etc. maybe basic default should be to just pop to a buffer...?
13:01:53
jackdaniel
the name 'clime' is quite confusing to me, because each time I see it I think "clim-extensions package".. that aside slime already returns a presentation (not clim presentation mind that) in repl, so returning it below the prompt seems only natural
13:02:16
jackdaniel
as of presenting things at different parts of the screen - I'd have that available via direct calls to present
13:03:07
jackdaniel
I'm not sure whether you've seen that, but I wrote a short blog post that implements a visual repl with presentations in clim: http://turtleware.eu/posts/Implementing-a-simpleminded-REPL-from-scratch.html (it is not clim-listener, much simpler)
13:05:23
jackdaniel
being able to draw and present on a separate buffer from repl also sounds like a good idea (i.e depending on the stream argument)
13:06:11
lukego
I saw selwynning's comment re: "clime" and I'm keeping that local to the emacs lisp code. I think it's mostly confusing in the context of common lisp code and mcclim developers but the target user for this is just lisp randos.
13:07:22
jackdaniel
I anticipate that it would make lisp randos confused when they approach it at some point because there would be two entirely different things with the same name
13:08:34
lukego
yeah sorry I like the name and I don't think it's pulling its weight as a nickname for clim-extensions package :)
13:09:36
lukego
that ^ is a mcclim clim extension. there is no CL package called "clime" in the stuff I'm working on. the name is only used in emacs lisp code
13:10:45
lukego
also there are already two separate "competing" implementations of the Emacs code, the original one based on SLIME and the new port based on SLY, so maybe someone can write a third one that's not called CLIME and the problem will be resolved :)
13:11:18
lukego
(I'd considered dropping the name CLIME with the port to SLY, since the SLIME connection is not there anymore, but decided that "CLIM for Emacs" works too)
13:13:11
lukego
jackdaniel: supposing we start with the repl displaying the presentations in Emacs, the question is when should it display such a presentation: for every lisp result that CLIM is able to present; for lisp results that happen to be CLIM presentations; or only for values explicitly passed to e.g. mcclim-emacs:present-to-emacs
13:13:15
jackdaniel
I'm personally surprised that it is a problem in the first place; there are so many interesting problems but this one is not. either way the backend naming convention in mcclim codebase is mcclim-foo (with an exception for clim-postscript as it is specified)
13:14:06
lukego
of course if anyone has a better name for the emacs side, which will be the user visible face, then now would be a great time to propose it. but I think "clime" is hard to beat :)
13:14:08
jackdaniel
I think that the PRINT function in REPL should call (present results 'repl-results :stream 'repl-stream :view 'repl-view)
13:15:23
lukego
so in practice does that mean that (format t "~s" obj) would insert a presentation into the repl whereas simply (identity obj) would not because there is only a return value and no output?
13:16:28
lukego
oh, right, PRINT as in REPL. So the default behaviour for displaying result values. Yeah that sounds like a good thing to start with and then see if people hate it.
13:16:49
jackdaniel
of course that requires handling multiple values too, that's why I've mentioned my blog post
13:17:30
lukego
likely need convenient commands to toggle this mode on/off and to easily see the "normal" lisp representation of the object e.g. via right click or something.
13:18:30
jackdaniel
lukego: assuming that the buffer is represented as sa stream, then customizing stream-view would be a good place to do that
13:21:36
jackdaniel
the presentation method present may be specialized on the type, the object, the stream and the view
13:23:29
lukego
interesting. could alternatively drive the whole thing from the Emacs side, with Emacs directly invoking PRESENT in Lisp when it wants a graphical representation of something
13:24:44
lukego
I heard a rumour that SLY dropped presentations but clicking on REPL results seems to open them in the inspector so I guess in some form Emacs can reference lisp objects.
13:25:25
lukego
maybe shift-click could toggle between the clim / text representation of an object and default state could be a user setting
13:26:02
lukego
(maybe a good default would be to show only the most recent repl result in all its CLIM glory and to toggle off the potentially large graphical representations of older results)
13:26:37
jackdaniel
it is just that the link between the text on the screen and the object is preserved
13:27:31
lukego
that's the bit that I think of as "supporting presentations" i.e. remembering which object the text refers to. but I'm probably forgetting how it really works in slime's presentations.
13:27:32
jackdaniel
so you can i.e reference stuff like #<abra kadabra> without actually reading it (and erroring misreably)
13:30:51
lukego
(btw I see that I lied above about naming and there is a package called slynk-clime on the Lisp side but that's internal plumbing in SLY and not part of the clim code.)
13:37:20
lukego
aside - I also find that I just have a really hard time understanding clim abstractions and thinking in those terms. I think that if I try to do things Right form the CLIM perspective there's a high risk I get stuck. so that's probably a point in favor of doing something "emacs'ey" and working that can be iterated upon.
13:38:00
lukego
I think I could easily lose the rest of the day trying to appreciate what STREAM-DEFAULT-VIEW is all about for example.
13:38:39
jackdaniel
when you present something on the stream and you do not explicitly provide a view, then the view is supplemented by the value of stream-default-view
13:39:34
lukego
I don't really have "swapped in" even basic ideas like what a view is, and I'm not sure if I've ever really understood how FORMAT interacts with CLIM. could be that I am a bit too "MTV generation" for these details and have to work within my limitations :)
13:40:33
lukego
okay less blah blah from me. let's try to get SVGs rendering in a convenient way so that I don't end up giving up and doing something I will regret with revealjs/javascript or blender/python :)
13:41:07
jackdaniel
a view is a an object that may have twofold use - to specialize the appearance, i.e (present *student* :view +list-of-students-view+)
13:42:19
jackdaniel
and the other is to retain some state of the presentation, i.e in +list-of-students-view+ instance you could have a slot TYPE with possible values :SHORT-VIEW or :DETAILED-VIEW
13:43:11
jackdaniel
the latter use (that is retaining some view-specific state) is rarely used as far as I can tell
13:44:01
jackdaniel
format just prints characters to the stream. clim-stream-pane implements gray stream protocol and remembers printed characters so they can be repainted etc, as well as honors the current dynamic context (i.e the current drawing ink)
13:44:55
lukego
thanks for your exertions but I have been failing to construct a solid mental model of these concepts for over 20 years now and I think it's time to admit defeat and try to cooperate with others who can compensate for my limitations :)
13:54:29
lukego
(I find everybody frustrating to communicate with on IRC, but much easier on other media, so I usually try to stay away but didn't know where else to connect with mcclim-emacs interested parties in a timely fashion)
14:24:22
selwynning
regarding the naming dispute: i don't think it is unfair for clim-extensions to take the nickname, as it was there first and eliminating the nickname would lead to a very great deal of work in renaming things
14:25:19
selwynning
on the other hand, calling the backend mcclim-emacs is consistent with the package names of other backends
14:26:13
selwynning
however, it doesn't seem unreasonable that the backend with package 'mcclim-emacs' can be referred to as clime in casual conversation, or even elisp
16:01:18
selwynning
while transform-glyphs is t, and using with-scaling to try and fix it doesn't seem to have an effect
16:05:03
jackdaniel
if you can make a small test case and put an issue on the tracker then I'll take a look at it tomorrow
16:06:05
lukego
thanks again for the help today jackdaniel. I am conscious of my debt to you in patient tutoring.
16:06:57
jackdaniel
you're welcome, if you happen to be at els this year then you may buy me a beer ,)
16:07:52
lukego
(I guess it's time to make travel arrangements at this point... last time I was rudely surprised by how long it takes to get to and from Porto and the city where I live these days.)
16:19:34
jackdaniel
indeed, if beers are as expensive as housing in amsterdam then I'll save two housings this year ;)