libera/#clim - IRC Chatlog
Search
11:18:11
lukego
I'm trying to think of ways to get deeper into CLIM hacking that don't involve distracting maintainers too much. I had an idea now - could it possibly make sense to try doing low-brow differential testing between drawing operations and backends? for example to draw the same scene with e.g. Raster and PDF and SVG (emacs) backends and capture the results into PNGs and ask imagemagick if their similarity is within a certain threshold
11:19:20
lukego
and perhaps to do other low-brow stuff e.g. say that a rotation/translation/scaling should more-or-less preserve the overall distribution of colors in an image regardless of the specific drawing operations that are involved.
11:21:48
lukego
for example I tried applying a rotation transformation in the Emacs backend and the result was surprising - parts of the image seemed to rotate out of the bounding box and disappear - and maybe even quite simple-minded tests could detect that kind of thing and say e.g. whether it is true of other backends too
11:24:36
jackdaniel
lukego: scymtym's master branch has something for comparing images in headless tests
11:31:35
lukego
pardon me popping in and popping out, I am still wrestling with the whole mcclim concept, trying to figure out how to use it in a way that's productive all around, occasionally feeling stuck :)
11:32:22
scymtym
lukego: i wouldn't try to come up with an approximate version of that particular method. on the one hand, i suspect that introducing leeway will make everything too uncertain to be useful (which slight change counts as a regression?). on the other hand, exact comparisons catch things like opacity being 254 vs 255 (yes, that's a real bug). unfortunately, that rules out cross-backend comparison
11:36:40
lukego
I dunno. the bugs I've seen in the Emacs backend lately are e.g. rotation causing clipping - possibly a miscalculated bounding box issue - and e.g. on the dot layout code the bezier curves are completely absent. Seems like both of those could be detected in the low-brained way of seeing that the % of background color is significantly more than it should be wrt a reference e.g. same drawn with raster backend or same drawn w/o rotation
11:39:36
scymtym
i'm not arguing against comparison between backends, but i think if you /automate/ anything, it makes more sense to fully "nail down" the expected output of a given backend
11:40:04
lukego
well maybe I'm misremembering too... I think the bezier curves triggered an NYI kind of error and then I turned them into NOPs and *then* they were absent :) so this testing method idea might be a bit shaky
11:41:31
lukego
scymtym: I dunno, I'm used to doing statistical inferences in automatic testing where exact behaviour is too hard to pin down precisely, e.g. for performance comparisons where benchmarks include a certain amonut of variation, as would e.g. a PDF and SVG rendering of the same scene
11:41:32
jackdaniel
I want to pull it back to core at some point (but retain the extension package for backward compatibility)
11:42:09
scymtym
lukego: does your backend have a separate SVG module like clx-fb uses the render module? that would good for testing and also other use cases
11:44:38
lukego
SVG backend could be used by Emacs, and useful in its own right, and become the basis of a web-based backend too
11:45:42
scymtym
lukego: that would be useful. this seems little known, but McCLIM commands have an optional "output destination" facility which allows redirecting the output to some backend. you use this in listener to say something like ,Show Class Superclasses clim:gadget :output-destination PDF file /tmp/output.pdf
11:47:29
jackdaniel
lukego: like this? https://twitter.com/dk_jackdaniel/status/1245094579994583048/photo/1 ; https://twitter.com/dk_jackdaniel/status/1246099193955041282/photo/1 ?
11:48:59
jackdaniel
this is also nice https://twitter.com/dk_jackdaniel/status/1240346699924680705/photo/1 ; I need to pick up that branch some day
11:50:25
lukego
oh interesting! is that a CLIM backend that outputs javascript code calling the canvas api?
11:53:22
scymtym
jackdaniel: are you generating javascript code or sending instructions to javascript code?
11:53:32
lukego
it would be neat to be able to discover this kind of stuff in some simple way e.g. if such branches had draft PRs open :) but that sounds like creating work for other people again
11:54:32
splittist
FWIW, I'm sketching out something that's communicating with the browser via WebSockets.
11:57:12
jackdaniel
splittist: I also have some hack for such thing ,) as an addendum to this backend: https://twitter.com/dk_jackdaniel/status/1379447011162873864
11:57:48
lukego
So to be honest thing big thing I'm wrestling with is opening source files and seeing Copyright notices from many of the best Lisp hackers in the known universe going back decades and worrying about how everyone's cumulative efforts haven't gotten mcclim to a version 1.0 yet. I worry that those people have somehow gotten stuck in a tarpit e.g. working on a doomed backend that later needs to be removed, and how to avoid such a fate
11:59:48
contrapunctus
jackdaniel: on the subject of documentation, what if the manual was converted to Org? I don't imagine as many people know Texinfo as they do Org, and Org colorizes source code too 🤔 (and of course it can export to HTML, info, LaTeX -> PDF, etc)
12:01:53
jackdaniel
if someone writes a decent documentation tool for common lisp (i.e in mcclim ;) I'll be happy to jump there, but doing org instead of texinfo would be too 2020s
12:07:18
scymtym
in the long run, i want to make the highlighter i used for https://techfak.de/~jmoringe/eclector-manual/eclector.html#Introduction easy to use. it can post-processes any HTML documentation with some hints
12:08:55
jackdaniel
(maybe except for "paren highlighting", but I suppose that not liking it is a personal preference)
12:09:44
scymtym
thanks, the style probably needs tweaking. the point is that appropriate "class=…" attributes in listings and also other text can be added after the fact
12:13:23
jackdaniel
it would be cool if we had a "live" documentation system (exportable to a dead-tree), something similar to a jupyter notebook interactivity-wise
12:18:28
scymtym
ideally, the documentation would consist of objects (like beach pointed out many times) and references to functions, classes, etc. could then just be the actual object presented in a suitable way. but that's a rather big departure from anything we have at the moment
12:21:59
jackdaniel
https://github.com/McCLIM/McCLIM/pull/1196 ; here's a started branch with a new ink sourcing model
13:18:00
contrapunctus
jackdaniel: re: restructuring the manual, here's a partial outline for the content I've read so far (which is up to the section on views) http://ix.io/3pVR ("->" means "move to", "<-" means "move from")
13:18:51
contrapunctus
and "(?)" is stuff I'm not quite sure where to put, or whether to leave it where it is.
13:22:18
contrapunctus
Existing explanations in the tutorials, whenever they can stand alone and are not really necessary for getting through the tutorial, will be moved to the Explanation section.