freenode/#clim - IRC Chatlog
Search
23:27:59
Inline
that one seems to be climacs side issue, as in gui.lisp has an other-window which gets an argument of current-view in climacs-lisp-syntax-commands.lisp
23:29:33
Inline
whenever some symmetry is broken in mcclim it creeps to very slow actually, that's another thing i notice....
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"