freenode/#clim - IRC Chatlog
Search
10:43:54
scymtym
jackdaniel: in the refactored code, the traversal (that is calling the inferior producer) does not stop at already seen objects
10:45:07
jackdaniel
I was trying to make the refactored alorithm semantically identical;it seems that I've failed at that
10:45:30
scymtym
re #1074: wouldn't it be better to handle the dx=0 ∧ dy=0 situation in the arrow drawing code instead?
10:46:01
scymtym
i discovered the graph formatting regression while putting the commented-out graph tests in graph-formatting.lisp into a demo file
10:46:35
jackdaniel
that's why I've suggested in the comment - namely that maybe the caller should be responsible for detecting invalid data
10:46:54
jackdaniel
and atan* to signal an error (to make the issue explicit when invalid data sneaks in)
10:47:28
scymtym
yeah, i'm pretty sure if dx=0 ∧ dy=0 comes up, you can't draw a "normal" arrow anyway
10:57:04
scymtym
jackdaniel: https://github.com/McCLIM/McCLIM/pull/1075 is a draft pull-request that shows how i found the problem. should i remove everything but the regression fix from the pull-request?
11:00:44
jackdaniel
I would also add tests if they are complete, but I'd keep the formatting changes from it
11:02:07
scymtym
the tests are only tests in McCLIM's demo/test sense, but separating them out makes sense to me and, as i said, in this case, the tests demonstrated the regression
11:02:42
jackdaniel
re pointer drawings in the pointer documentation -- I think that it is a good idea, however I would draw more "symbolic" versions of the mouse (i.e three rectangles with one in an "active" colors for the button press, two triangles with one active for scrolling etc -- so a) more symbolic, b) different for different gestures, not from the same template
11:03:30
jackdaniel
sure, I agree that having them in the third column in demodemo is a good idea, and they should go with the same PR as the regression fix
13:09:32
jackdaniel
scymtym: I thought about something in this spirit: http://turtleware.eu/static/paste/8c014dbd-mouse.png
13:10:27
jackdaniel
here is a code I've sketched http://turtleware.eu/static/paste/5bf40a92-mouse.lisp
13:44:38
jackdaniel
n.b that could be simplified even further with standard unicode full block element with a different ink (I'm mentioning that because of a potential console backend)
13:46:08
pjb
jackdaniel: also, with some display system, you can easily define your own fonts, and unicode has whole planes free for such custom usage.
13:48:36
jackdaniel
probably, but if we take a terminal backend, I think that ecma-48 is the target, if we have more sophisticated target, then we don't need to play with "custom" fonts, because we may simply draw
14:22:38
pjb
Well, implementations of ecma-48 that would allow you to represent graphically (or semi-graphically) whether thru the support of alternate font, or others, would be sufficiently advanced to run only on GUI. It's probably better to remain with ASCII on terminals…
16:07:01
jackdaniel
froggey: you may be interested in a discussion in here: https://gitlab.com/embeddable-common-lisp/ecl/-/merge_requests/194