freenode/#clim - IRC Chatlog
Search
4:26:25
loke
I need to get back into it. I've been spending some time fixing bugs in StumpWM, since I'm moving to it on my laptop.
4:29:49
loke
ck_: my next step is figuring out why the currently implement doesn't work in some cases. :-)
8:33:24
jackdaniel
I may have more time for McCLIM and ECL for a few months now; my consultancy contract on a propietary lisp software comes to an end
8:40:15
ck_
Sounds nice for mcclim and ecl. Have you put some thought into the most pressing questions already?
8:42:03
jackdaniel
I did: if it is to be during upcoming 2-3 months it will be a forefathers-eve, if it will be more like 8 months it will be kupala night ,)
8:45:09
jackdaniel
beach: no, I think that Rigetti is interested in improving ECL compiler, also I have at least a few month buffer before I should start worrying
9:27:45
jackdaniel
scymtym: regarding command-table per pane: that's one of purposes for which ESA was written
9:28:12
jackdaniel
according to documentation it is enough to inherit from esa:esa-pane-mixin and supply :command-table initarg
10:03:04
beach
scymtym: ESA was written a long time ago, and my style and experience have both improved since. So it is entirely possible that it needs to be updated.
10:05:38
beach
scymtym: It may need to be more modular as well. As I recall from Second Climacs, it was hard to use only some of the features.
10:13:18
beach
scymtym: What I am trying to say is that you should not look at the ESA code as being set in stone. As far as I know only two applications use it, namely (first) Climacs and Gsharp, both of which are kind of obsolete.
10:16:41
jackdaniel
ck_: please do (next time just ask, in the worst case scenario I'll tell you that you weren't allowed to ask ,-)
10:17:37
ck_
I meant, "is now a good time". OK here goes: you repeatedly say in your comments to "use defvar" -- I don't think we have the same perspective or reasoning
10:18:12
ck_
I wanted to preserve semantics locally while changing or moving as little code around as possible
10:19:01
scymtym
ck_: did you have time to look at my commit? i think moving code around may be the right thing in one of the two cases
10:19:06
ck_
also you comment "yes, people usually look for where the variable is defined, if it is only declared then it may be confusing.."
10:19:54
ck_
scymtym: I did and I thought I commented on it here -- also thought that you had that in the pipeline so I'd remove the part you already covered when I continued with my pr (which is right now)
10:20:43
jackdaniel
ck_:it is like with always use EQL camp on my side: it makes code simpler to read
10:21:03
ck_
jackdaniel: re/people look for the definition: I agree of course, but I didn't remove the defvar/defparameter definitions. the special declaimations I put in because those forms occur at a later time in the asdf order; anybody M-.'ing will arrive at that form
10:21:36
jackdaniel
I'd rather move defvars earlier than declare them beforehand but this is fine too I suppose
10:23:43
scymtym
ck_: sorry for the miscommunication. i thought since you were taking charge, you could incorporate my change into your pull request
12:03:09
scymtym
jackdaniel: thanks. i haven't thought about it. i guess, as long as credit is given and the content is not framed inappropriately, i have no objections
12:05:21
scymtym
jackdaniel: now i'm curious, though. would you provide a link to the social media post?
12:08:58
scymtym
the protocol and client side are already a little different from the original GTK version, but your description is still accurate
12:14:33
no-defun-allowed
Whoa, that was quick...weren't you just drawing boxes not long ago, scymtym?
12:17:08
scymtym
no-defun-allowed: yes. check https://techfak.de/~jmoringe/mcclim-broadway-{1,2,3,4,5,6}.ogv for progress over time. however, those don't show the whole story, since you can't see the protocol spoken between client and server
12:22:27
no-defun-allowed
It still seems magical that someone could write a backend for a graphics toolkit in less than a month.
12:24:14
scymtym
the protocol or protocols rather are one of the harder parts. especially since GTK changed their approach (and protocol) entirely at one point and still called it "broadway 2.0"
12:24:59
jackdaniel
no-defun-allowed: CLIM's protocol complexity is overestimated while an effort to bring a prototype to a usable shape is usually underestimated
12:26:21
scymtym
regarding implementation speed: keep in mind that i didn't have to write the javascript client from scratch - i just adapted it a bit. also, the backend uses off-screen rendering, then transfers pixels in a smart way, so i didn't have to implement rendering, "just" what amounts to a streaming video codec
12:27:53
scymtym
jackdaniel is totally right. if what i have now is one unit of work, getting to a usable backend is probably five or more units of work
12:41:59
jackdaniel
we could create a medium-crutches-mixin which draws everything using medium-draw-point* method unless specialized further :-)
12:42:55
scymtym
i think i made a significant improvement to the render backend's speed, but i haven't benchmarked it
12:43:19
ck_
wow, I think that working on that issue has left some scars. I just caught medium-draw-something* and my pulse went up
12:46:54
scymtym
not recompute the foreground "ink" unnecessarily: https://github.com/scymtym/McCLIM/commit/7ec10701c86c8c7a75b10f0806106b71eca526ab
12:48:10
jackdaniel
my main focus last time I've worked on this code was to reduce insane macrology used there without caring much about performance at the moment
12:49:02
scymtym
i'm prepared to throw that work away. i just needed the thing to be faster so i could work properly on the backend
12:51:12
jackdaniel
just saying that I might have degraded performance significantly while removing #1=(writing-code . #1#) macros
12:57:56
jackdaniel
scymtym: 1ae81284184dd6d5eabd53b2d6ede6493fcce2c5 (branch origin/medium-transformation-fixes -> origin/master)
12:59:12
jackdaniel
ck_: n.b this very merge impacted the osx performance, namely implementing transformed-patterns