freenode/#clim - IRC Chatlog
Search
8:22:59
jackdaniel
what will be more idiomatic for end-of-line-action when we wrap by word on display: :WORD-WRAP, :WRAP-WORD, :WORD, :WRAP* ?
8:36:21
jackdaniel
speaking of animations: https://terranostra.one/posts/ASCII-Art-Animations-in-Lisp.html :-)
8:39:10
mgiraud
not used to irc but decided to join after reading your everlasting Common lisp TODO list :-)
8:42:00
mgiraud
jackdaniel: yes, i'm not an ecl user but the mcclim part (and last improvements) was interesting
9:10:26
mgiraud
regarding thread safety of seos: i imagine that it is more than a mixin with mutex lock on these classes
9:12:38
jackdaniel
approach I'm going to incorporate is to queue events with stream operations if the thread is not affine to the stream
9:13:23
loke
Could writes to the stream from other threads just result in an event being added to the event queue, and the text being written to the thread during the event handling?
9:14:03
loke
Basically have the stream-write-somethingsomething check if it's on the event thread, and if not, add the event?
9:15:17
jackdaniel
that will need to be incorporated not only to stream operations, but also top-level draw-rectangle etc
9:15:23
jackdaniel
10:14 < jackdaniel> approach I'm going to incorporate is to queue events with stream operations if the
9:15:41
jackdaniel
beach: I believe it is about my todo list: http://turtleware.eu/posts/My-everlasting-Common-Lisp-TODO-list.html
9:15:58
loke
Perosnally, I believe that's a rabbit hole that one does necessarily not want to go into.
9:16:42
jackdaniel
loke: well, it is critical if we want to have application frames not sharing the same thread who use each other streams (i.e log4cl wrapper)
9:16:53
loke
In most UI systems I know of, it is the respknsibility of the caller to ensure he performs the call from the correct thread (i.e. to use some kind of RUN-IN-EVENET-THREAD call if needed)
9:17:06
jackdaniel
also fixing that gives me a good overview of other problems with streams (which I'm fixing right now)
9:17:56
jackdaniel
and there is something about streams which makes them appealing to pass "somewhere else as *standard-output*"
9:18:54
jackdaniel
also since we do not have "good enough for me"™ editor inside McCLIM loop I usually use slime repl. when I want to interact with McCLIM application it is by definition asynchronous access.
9:20:39
jackdaniel
but I acknowledge that lack thread safety on stream operations is not a critical bug in McCLIM, it is more a feature I want to see in there
9:23:01
loke
Hmm... Aren't most of the graphic operations wrapped in some macro? Ah yes... DO-GRAPHICS-WITH-OPTIONS
9:23:50
jackdaniel
I think that there is a 2y old branch somewhere with a prototype for this approach
9:27:21
jackdaniel
loke: this is already sorted out conceptually, there is no need for brainstorming the solution
9:30:43
mgiraud
Interesting. Are there demos or apps that do this (threads that write to another thread stream)?
9:31:39
jackdaniel
I can think of one example: Listener has "show file" command which works like this: creates a window stream and then outputs line-by-line its content to said stream
9:39:24
jackdaniel
the idea was to use locks (either on streams, or graphics operations or whatever) but fine-grained locks always lead to a deadlock (because of how application is written)
9:39:52
loke
jackdaniel: but if you do the writes inside an execute-frame-command, then there will be no corruption, right?
9:39:56
jackdaniel
and a single global lock was a terrible hack which synchronized things which didn't need to be synchronized
9:40:29
jackdaniel
yes, if you execute-frame-command and command does writes there are no thread issues
9:41:12
loke
Yeah, that's how I do it. Although Climaxima only uses frame-to-frame communication in one instance; when you open the documentation from the main frame to the documentation frame.
9:42:44
jackdaniel
I wonder how hard would it be to create a demo where we have application-frameanager, where you have a frame manager which is also an application frame, whose panes embed frames
9:50:58
jackdaniel
from other fun ideas I won't do: broadcast backend, which output goes to more than one medium (possible associated with different ports) - for testing new backends against existing ones
10:08:09
jackdaniel
we need to call finish-output on seos after display, is (redisplay-frame-pane :after) method the right place to issue that?
10:11:30
jackdaniel
I think not, method and qualifier is correct, but not specialization. seos is not a pane-display-mixin
10:24:24
jackdaniel
Wow, :WRAP end-of-page-action seems useless. I can't think of a single practical purpose of it. Maybe it should clean the viewport? Then it would be a "modulo" output sort of thing
10:40:46
jackdaniel
previous find-split function was looking at text-size character by character with an annotation (comment) that it could be done smarter
10:48:45
loke
jackdaniel: Coudl end-of-page action be a throwback to the behaviour of things like ITS?
10:54:01
loke
WHen you log in to an ITS terminal, you can configure the end-of-page behaviour. You can use either scroll (which is how a regular terminal works), or clear whch pauses output until you press a key and then clears the screen.
10:54:50
jackdaniel
loke: I have suggested that as more useful behavior indeed: "maybe it should clean the viewport"
10:55:33
jackdaniel
but yes, that would be more useful behavior and given a historical perspective it makes even more sense
10:56:18
loke
Yes. It was your comment to clearing that reminded me on ITS behaviour (also, MVS (Z/OS these days) works the same way.
10:56:43
jackdaniel
another interpretation (which has a little sense) is vertical text, so you wrap vertically and start in a second "vertical line"
12:37:56
jdz
jackdaniel: Pretty sure you could keep record of calculated widths when midpoint is moving to the right.
12:40:07
jackdaniel
due to kerning "foo bar qux" length is not the same as sum of "fo" "o b" "ar qux"
12:41:56
jdz
My other idea was to approximate split point using some average glyph width (like ems in CSS).
12:44:30
jdz
Also when keeping record of pre-calculated width one could do that at some well-known non-kerned places (like whitespace).
12:48:19
jdz
What I meant was that first you calculate split point (bisection or prediction), and then find the nearest point where it would be safe to split without fear of invalid calculations (due to e.g. kerning).
12:48:39
jackdaniel
(in honesty I think that iterating over string was good enough, I've just succumbed to my microoptimization urges :-)
12:50:32
jackdaniel
so this second approach of yours is basically bisecting with calculated section point (not exactly 1/2)?
12:51:43
jdz
Yes. And in addition to that, adjusting the point to a safe spot, and keeping the calculated result is not good enough.
12:53:16
jackdaniel
OK, now I understand it a bit better (still not clearly though) - i.e what is a safe spot, how do yo udetermine it?
12:53:18
jdz
I mean, if we know that on average a character takes 5 units, and we have 60 units space, and the string is 100 characters long, we'd first try to split at 12 characters.
12:55:02
jdz
And then, if the 12 characters only give us 53 units, and we assume that the width of the 12 character string will not change (hence safe spot), we can now deal with filling 7 units with the rest of the string.
12:55:31
jackdaniel
currently text-style-width returns width of #\m in a medium font (which is nearing the widest characters, not average), but it could be repurposed, because wording in the spec is: "The width of a font is the width of some representative character in the font."
12:55:52
jdz
If the 12 characters give us more than 60 units, we might adjust the predicted character width, and try again.
12:56:22
jackdaniel
OK, so by safe spots you mean bisection boundaries which are already confirmed to meet the criterium
13:00:19
jdz
Could it be worthwhile first splitting string into words? I'd figure this would come in handy when resizing (continuously) a window.
13:08:24
jackdaniel
regarding continously resizing a window: if you want wrapping to change you'd need to redisplay pane (not repaint)
13:10:06
jackdaniel
I think that making adjustable-on-repaint-text-output-records is not impossible, but that would be a non-trivial task being a whole feature (and not a simple fix / improvement)
13:11:29
jackdaniel
I don't want to send too big batches in hope they'll get better peer review that way
14:04:43
loke
I split by word first, and deal with those. Also, I word-wrap at presentation boundaries as well.
14:06:09
loke
The main problem is that CL-UNICODE doesn't implement a way to look up the word-wrap class for characters, so first I need to submit a patch to cl-unicode that allows that.
14:58:18
mgiraud
having a look at drawing-tests, i don't understand why everything is done in a pattern (and then draw-pattern* is called) for the render backend while in the standard backend everything is drawn to the output
16:04:46
Inline
uhuh, my changes seem to have also deleted the window-splitting thing somehow, oh man
16:12:49
Inline
i started and restarted my sbcl several times and in between also deleted the whole fasl cache directory
17:39:52
jackdaniel
now that I have word wrap and other bugs sorted out I'm tempted to split lines by word with minimum raggedness
18:19:33
Inline
maybe a drawing application which draws randomly in space without regards to being in finite space area ?
19:05:10
jackdaniel
Inline: if you found a seemingly correct solution please make a pull request. also please include detailed steps how to reproduce the issue from empty lisp image
19:10:23
Inline
i just changed my Apps/Listener/listener.lisp s class definition to use :end-of-line-action :wrap in the pane definition fields