freenode/#clim - IRC Chatlog
Search
4:30:10
ck_
Everything ok in equator land? Amusing tidbit: querying duckduckgo with, for example "weather singapore", uses my local time instead of yours
4:33:11
ck_
Hello beach. I wonder why you havn't written a script to greet all channels you're in :) with all the abbrev-expansion and so on
4:39:44
ck_
I'm having some trouble conversing with JMC-design in https://github.com/sharplispers/clx/pull/146 . I don't disagree with his point, but my questions for clarification on how things should work seem to go past them. Can anyone recommend something I can do to mend this?
5:35:50
loke
ck_: In general though, if we can move to Xrender, this issue is moot anyway since with Xrender you don't use GC's.
5:38:04
loke
ck_: also, I think I understand his points. He's saying that the cache you implemented shouldn't be needed since threere is already a cahche that _should_ be doing the same thing. If it isn't, that's a bug that need to looked into.
5:39:26
|3b|
looks you need an enclosing xlib:with-state for that drawable to activate the cache, and there isn't anywhere to put that without breaking the clim backend abstractions
5:39:32
ck_
I'm asking about how exactly it is supposed to work. Should McCLIM code use the xlib:WITH-STATE macro, or is it supposed to work internally? In my tests, the xlib cache alist is empty
5:41:19
ck_
I said "Is xlib:drawable-depth supposed to access this cache you mentioned, or is it the wrong accessor for that purpose? Is WINDOW-ATTRIBUTES the cache you mean, and should user code like mcclim access that?"
5:42:41
|3b|
also arguably more reasonable to handle that field specially since it is the only one in that cache not SETFable
5:43:30
|3b|
ACTION isn't sure exactly why you would want to cache things per thread in the first place though... "last value I set" seems less useful than "the actual current value"
5:46:28
ck_
loke: Yes of course, I considered that. The reason I decided on writing the CLX PR is that the mcclim code works quickly enough on linux. I'm not saying I'm right with that decision
6:36:37
ck_
loke: I can't deny a little envy. Maybe not the temperature, but the constantness of it. At the end of this month, my hemisphere steeply plunges into darkess (dramatization)
6:38:29
loke
ck_: Ok, how about this: Many Europeans who visit here complain about the heat and humidity. Exercising in this climate is much more exhausting than in Europe.
6:41:43
loke
It's OK. Grobal warming has drastically reduced the amount of snow in winter, so that's good I guess?
6:45:36
loke
ck_: I have to say that it takes you about 6 months before you get confortable enough here to sleep without AC on :-)
7:06:20
jackdaniel
I don't mind myself, but as a channel operator I feel obligated to remind you about the channel topic, because others might do ,-)
7:10:55
ck_
sure. jackdaniel: I incorporated scymtyms changes with respect to compilation order, but couldn't find a nice way to rearrange the contents of lisp-syntax.lisp, so I used a declaim there, for |initial-state |. This is PR 808.
7:11:41
jackdaniel
sounds good, I'll take a look and unless there is a problem I can spot I'll merge it right away
7:13:11
ck_
I'll now go back to the float printer for beach, if you have anything you'd like me to work on in mcclim after that, please tell me.
7:14:53
jackdaniel
and scope of this issue should be limited to a single function (messy one though)
7:50:56
jackdaniel
scymtym: I've looked into git history and changes, pressed sheet was introduced around the time clx-fb was added. Unfortunately commit messages were all in a spirit of "for clxv2 backend"d
7:52:21
jackdaniel
these parts of were a subject of many fixes afterwards, so I think we may safely assume that it was not thought through much, so I think we should replicate the behavior (which indeed improved ux) after agreeing what should be done
7:54:15
jackdaniel
I fail to find rationale for some decisions (i.e why presed sheet is limited only to events in the same top-level-sheet hierarchy?)
7:54:55
jackdaniel
so after implementing it cleanly we will target regression as we find them with clear comments why things should be changed
8:05:10
loke
jackdaniel: I'm not sure I understand the underlying problem. Is it related to the fact that when you write to the stream and draw to the screen at the same time, there is conflict?
8:06:56
jackdaniel
consider i.e output-recording stream and (with-output-recording-options (stream :draw drawp :record recordp) …)
8:06:59
loke
And just having all accesses to output-record history being synchronised using a lock is not possible? (too many entry points?)
8:08:34
jackdaniel
second scenario: display function and user code, both only record, but cursor position is messed up
8:09:16
jackdaniel
third scenario: we only draw (not record), but medium's drawing-options are also state of the medium
8:09:18
loke
Would it be possible to have two different streams: One for recording and one for drawing?
8:10:42
jackdaniel
I had a tough ride with that a few years back, I've tried both fine-grained locks and a global lock. fine-grained locks are impossible because of the three cases I've mentioned (you have deadlocks for recording vs drawing)
8:11:47
jackdaniel
and result of that month-long iteration without a line of code change is a proposal to schedule asynchronous operations into event queue
8:12:25
loke
jackdaniel: I recall the work done my Gilberth way back where he separated out drawing and recording (it made for much faster redraws when there was a lot of scrolling output). Wouldn't he have run into the same issue?
8:14:32
jackdaniel
afair his scrolling was slower than what we do. either way; I think that what he did was simply first record, then draw instead of doing both things at once
8:15:01
jackdaniel
as in: (with-output-recording-options (stream :record t :draw nil) ,@body) (with-or-opts (stream :record nil :draw t) (replay-stream stream))
8:15:28
jackdaniel
(doing both things at once would be (with-output-recording-options (stream :record t :draw t) ,@body)
8:15:40
loke
jackdaniel: Ah yes, probably. I was thinking he did it in separate threads, but that wouldn't be necessary because the performance boost would come from not having to draw things that have scrolled away before the redraw call happens.
8:17:31
jackdaniel
i.e imagine calling quickload from a command, you wouldn't see dots after each macroexpansion
8:18:39
jackdaniel
one could thought of having finish-output bound to stream-replay, it might work in this case, but I haven't tried that
8:18:59
jackdaniel
we suffer from this issue ourself, while text is indeed drawn, scrolling is postponed, so we get somewhat corrupted screen
8:19:01
loke
Unless redraws happen in a separate thread, I guess? But I presume there are aspects that prevent this (that I don't know about?)
8:19:14
jackdaniel
try calling quickload of something big in the listener when you are nearing bottom of the screen with the prompt
8:20:17
jackdaniel
if you have redraws in a separate thread then you need to synchronize access to the output records, so you are at square one, but now yo uhave three threads to manage (instead of two)
8:20:25
loke
Any Maxima function that outputs a lot of text (and which isn't specially treated by Climaxima (such as mathematical formulas)) suffer from this.
8:21:19
jackdaniel
(and since you need to synchronize output record access you don't gain any performance by first recording then drawing)
8:21:35
loke
Is the synchronisation really an issue though? Sure, a lot of the CLIM operations will be effectively constrained to a single CPU, but that shouldn't really be a problem, nO?
8:22:24
loke
There are so much code in McCLIM that assumes they can just access shared data without locking that allowing parallell access is problematic anyway.
8:22:53
loke
My favourite case (that we've discussed in the past) is the Shift-drag selection,w hich accesses the output history from the event thread.
8:24:22
jackdaniel
at least I remember thinking and meddling with the code during selection protocol rewrite
8:26:04
loke
Thank you. I'm glad I don't hae to think about it much. The next McCLIM thing I go back to will be the Xrender work. But before that I have StumWM bugs to fix, and I'm putting together some improved UI for StumpWM which is based on CLIM.
8:27:52
jackdaniel
I thought you've made a working prototype with ck_ and you were working on improving performance?
8:33:52
scymtym
jackdaniel: your suggestion for pointer grabbing sounds reasonable but i can't give it much thought right now
8:35:02
jackdaniel
OK, if you ahve something please let me know. there is also sixth point I forgot: 6. Event is delivered to the innermost mirror's child (given it is not stolen)
8:36:04
jackdaniel
alternative approach (which would be the opposite what we did in the past), is to deliver pointer events to the topmost sheet
8:36:21
jackdaniel
and default method on the parent-sheet-mixin would call handle-event on its child
8:37:45
scymtym
that sounds like something i would have to try to implement in order to realize the implications
8:37:57
loke
jackdaniel: I've been away from working on McCLIM for the last few weeks, but I will get back to it.
8:38:43
jackdaniel
First I'll implement behavior we have now and after that I'll maybe propose the top-down approach
11:30:51
jackdaniel
hmm, this whole pressed-sheet emulation business breaks drag-and-drop between different frames
11:32:26
jackdaniel
and that explains why tracking pointer would grab the pointer, to prevent the pressed-sheet situation