freenode/#clim - IRC Chatlog
Search
8:50:17
frgo
I am now able to run stuff on AllegroCL using McCLIM from github. That's very good. I will probably come up with a PR for CLX of sharplispers. But:
8:51:42
frgo
Hmpf - How do I "reopen" a display? This happens when I try to run another app right after quitting the first.
8:55:06
ck_
Hmm, is there some caching going on maybe? Where does that error come from, open-default-display?
9:00:05
ck_
I see. I don't understand the problem yet -- the X server, are you using your native one, or is that part of your container thing?
9:01:26
ck_
So then maybe you should look into what Allegro does differently? I have no suggestions, sorry.
9:01:27
frgo
I can run xclock from within the container just fine several times in a row without problems.
9:05:01
Inline
if so someone also should change the on-off-dash references in tests/core-protocol.lisp
10:21:48
kpoeck
frgo did you manage to run clx from https://github.com/sharplispers/clx.git in Allegro?
10:23:12
kpoeck
Error: Unknown hostname: "private/tmp/com.apple.launchd.0rRVZ8rXYU/org.macosforge.xquartz"
10:25:45
scymtym
jackdaniel: do you have anything to add regarding https://github.com/sharplispers/clx/pull/146 ? i would merge it now otherwise
10:26:37
scymtym
Inline: i looked at this as well and i think on-off-dash is the correct name but changing would break clients such as mcclim
10:39:46
jackdaniel
that calls close-display, and you can't reuse closed display, you need to open another one
10:46:20
scymtym
Inline: calling on-off-dash "correct" was based on the xlib documentation. but yeah, just changing the test instead may be better since clients won't break
10:55:46
scymtym
ck_: you benchmarked your fix, right? that should be sufficient justification for closing the issue
10:56:28
scymtym
Inline: i agree, but i'm not sure the costs of changing it are outweighed by the benefits
11:07:06
ck_
scymtym: I did, just wondered whether it was customary to wait -- until the clx chang is in quicklisp / until the original commenter acknowledges it / ...
11:08:49
jackdaniel
frgo: not in franz sources, it is mcclim what closes the display for unknown reason
11:33:15
scymtym
ck_: launchpad has issue states "fix committed" and "fix released" for that, but since github only knows "open" and "closed", closing and re-opening if needed seems appropriate
11:52:27
scymtym
Inline__: just changing clx and not mcclim breaks mcclim, but since jackdaniel usually gets the flak for user-visible issues, best take it up with him
12:36:15
TMA
scymtym: another alternative is to have another open issue #N "release the change #M" for tracking the period between committed and released. this way you can tell whether the original issue is open due to incomplete/wrong fix or just unreleased fix
12:44:33
jackdaniel
more complicated the strategy to manage ticket more time it consumes. I think that open/close (and reopen) works best for small teams in the open source environment
12:45:25
jackdaniel
it works fine when you have dedicated testers, but in foss world it is often weeks or forever before the reporter actually retests things and bothers to close the ticket (their problem is already solved, right?)
12:49:28
TMA
as a freshly minted "expert" on business processes, I can tell that each process model tends to be either incomplete or unusably complex
12:50:44
jackdaniel
don't get me wrong, I despise "agile" development; I'm just saying that with limited resources process must be reasonably lightweight
12:50:51
TMA
It seemed as just a quick hack around the inability to distinguish between "this fix is wrong" and "this fix is ok, but not released"
12:52:17
jackdaniel
well, we have very long release cycles, unless by released you mean commited to master
12:52:43
jackdaniel
but then if commit is in master we close the issue assuming that fix is OK, and repoening the ticket is a lazy way of telling: the fix was wrong
16:34:05
frgo
Hey, it's me again. Sorry for reaching out again with my "Attempt to use closed display" issue. I found the following: See https://gist.github.com/dg1sbg/e264f4e5ce7293f6b76d77e4e6a9bd6f
16:36:02
frgo
I then let stuff just sit there and, after some minutes of not doing anything, this error showed up.
16:48:25
ck_
so, something is closing your display, maybe it's a good idea to trace close-display and find out what
17:29:41
Inline
i have to quit the repl and restart, otherwise it doesn't matter if i even do a setf on my display
17:32:46
frgo
Yep - that's exactly my problem. I somehow need to make sure that I don't run into a timeout of some sort.
17:33:56
Inline
so i run a clx program, the display got closed, i setfed the display anew to a new instance and checked that it is alive (:dead nil), and reran the program, but the program just returned closed-display error
18:08:08
frgo
Question to the CLX gurus here: In 'buffer-input (in file buffer.lisp in sharplisper's CLX), when a timeout occurs, the buffer is closed. I do not understand this - if is not an error, just a timeout ...
18:24:38
jackdaniel
frgo: try replacing allegro-specific buffer-input-wait-default with the one in dependent.lisp
18:25:41
jackdaniel
as of why buffer is closed on timeout, I can only guess that it is by design: if X fails to respond in timely manner it is considered dead
19:06:11
ck_
We'll see where this goes. Through the power of detachment, I can just sit back and watch
19:08:12
jackdaniel
so I wouldn't be bothered much. that said we may indeed work on code on our side to call this function less if it is uncommon in x11 protocol `standards'
19:08:28
ck_
I believe his point is that the caching already happens, and that querying the depth so often is a mistake
19:14:34
ck_
I had a very quick look at the macro (attributes.lisp+309), but couldn't see where the depth is cached in those related functions