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