freenode/#clim - IRC Chatlog
Search
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
18:08:12
jackdaniel
I agree that both are valid; there are three reasons why I have decided (contrary to my initial intuition) to be more permissive
18:09:01
jackdaniel
for once, there is no practical reason why not to be permissive (i.e I can't think of any improvements for the implementation which would use this fact)
18:09:53
jackdaniel
second reason is that since more popular implementations allow that, there is most likely some software which does excercise this permissive interpretation
18:11:10
jackdaniel
and the third reason is quite similar to the second one - a new code is (usually) written with more popular implementations (I mean sbcl and ccl by that), so being more permissive is good for forward compatibility
18:12:07
jackdaniel
well, if there are reasons for not being compatible with sbcl I do just that (i.e ,@,@form is not conforming, however sbcl supports that -- but that complicates and basically decides for a very specific reader implementation)
18:14:45
scymtym
i wouldn't mind conforming to the strict interpretation in McCLIM code, since i already had to make the required changes twice. once when playing with Mezzano and once when playing with ABCL
18:15:25
jackdaniel
mind that I'm not trying to convince you, just being talkative about why I have changed ECL's behavior (and Marius had a good argument afair that the more permissive interpretation seems to be more in line with the generic function dispatch as specified)
18:17:15
jackdaniel
re PR, we still need to guard against nil in initialize-instance (for sake of ESA, throw-ptype and similar), so that won't go away regardless of whether we put (ax:required :arg)
18:18:50
jackdaniel
regarding calls to floor, I think that I've just assumed that native coordinates are integers (and they are in /our/ case), so it is only natural to have sheet coordinates the same way. other than that I think that there is no reason
18:19:22
jackdaniel
except maybe for defensive programming in case, that some code in McCLIM assumes exactly that (i.e forgets to round coordinates), but I don't think there is such code in the codebase