freenode/#clim - IRC Chatlog
Search
21:54:44
jackdaniel
my last pr is not merged yet and I already have fixed for 3 another bugs waiting in a pipe
22:30:57
jackdaniel
another one is that last stream text output record is not closed if there is no new line at the end
22:31:15
Inline
this issue is related to how count is defined in tabify-buffer-region in Libraries/Drei/base.lisp
23:13:52
Inline
it was just the line (>= offset offset2) that was wrong, in untabify that's right but tabify is untabifies inverse so it should be (<= offset offset2) and two more lines had to be changed (delete-buffer-range buffer offset count) to (delete-buffer-range buffer offset (1- count)) and the line (decf offset2 (1- count)) to (decf offset2 count), what i notice now is an accelerated tabifying (very fast)
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.