freenode/#clim - IRC Chatlog
Search
10:15:15
beach
loke: I am afraid you are going to have to wade through a lot of obsolete code at this point, simply because I haven't taken the time to clean it out and/or document it as such.
10:23:37
loke
beach: So where can I find the actual command definitions? If I want to find th ecommand for, say, next-line?
10:37:26
jackdaniel
I still hold dear the idea of having SLIM library bundled with CLIM which "shrinks" it a little
13:10:11
jackdaniel
at least part of the problem comes from the fact, that when we change mirror geometry Xserver generates configuration event which change this geometry again
13:14:26
fittestbits1
presentation-replace-input builds a file name string using directory-namestring and file-namestring so no host name.
13:14:35
nyef
jackdaniel: Note that in the case of substructure redirection, you can change mirror geometry and then get DIFFERENT geometry back.
13:15:31
fittestbits1
OK - take a look at the log. There's definitely a problem, but I'm not sure how to fix it.
13:16:06
nyef
And there's also the bit where you get "real" and "synthetic" geometry notifications, one of which accounts for the frame ("window decorations") and one which doesn't.
13:17:28
jackdaniel
fittestbits1: isn't it possible to always include host name in completion? modifying presentation-replace-input that is
13:17:31
fittestbits1
Right, but the I think the problem is that the insert text code of mcclim generates a different text string than the completion code uses for matching.
13:18:15
jackdaniel
I don't know these parts of system well so not sure what is the right thing (and my head is still wrapped around mirrors)
13:18:31
jackdaniel
btw, there will be some changes with mirroring code (head-ups regarding mezzano port)
13:18:34
fittestbits1
Yeah, modifiying presentation-replace-input seems right, but someone went to a lot of work to avoid just using namestring and I don't know why.
13:19:03
jackdaniel
fittestbits1: I would just ignore the "I don't know why" part if it is not obviosu after hour-or-so investigation
13:19:48
jackdaniel
at one session I was able to remove ~700 lines of code without changing *any* functionality
13:20:08
jackdaniel
but that was after confirming, that part of the functions is not: a) exported, b) not used anywhere
13:20:56
jackdaniel
or that they can't be called (because some condition always resolves to one of branches) - stuff like that
13:21:10
fittestbits1
Cool. I wish my changes would go as smoothly. I put in some performance changes that I though made no difference for functionality, but running through the examples showed some differences.
13:22:44
jackdaniel
I had weird issue yesterday – after changing name of two slots (just a name!) and all with-slots or slot-value or package imports everything worked fine – except the performance which dropped drastically in case of ellipsis bounding regions
13:24:33
jackdaniel
I've started with post about ports, then I've moved into simplistic-gadgets what led me to layout protocol and now mirrors
13:24:35
fittestbits1
I'm still making forward progress on the mezzano port. Performance seems a lot better, I think because of a logging change.
13:26:46
fittestbits1
It worked OK when creating windows with empty FIFOs just printed a bunch of zeros. But with mcclim using a shared FIFO, it printed out a bunch of event objects which generated a lot of text plus the processing to generate the text.
13:28:42
fittestbits1
I think reading the font files lots of times stops when all of the characters get cached. So, that's more of a startup issue than an on going issue.
14:16:53
jackdaniel
“To keep large problems well structured, you either need superhuman will power or proper language support for interfaces.” - Greg Nelson
14:24:02
nyef
... What constitutes "proper" language support for interfaces here? I sense a "no true Scotsman" fallacy.
14:25:56
jackdaniel
I can't tell what was the quote author idea, but I understand it as a limitation on how objects interact with each other
14:26:40
jackdaniel
example of implementation of such idea is "never use slots directly" principle – using only a protocol for accessing objects
14:27:19
jackdaniel
this contract assures, that you won't hit "gotcha", because some :after method didn't get executed
14:28:54
jackdaniel
if there weren't convenient way to define accessors in CL, then each library would have to come up with its own idea how to access object innards
14:29:39
jackdaniel
what would lead to raised cognitive effort when working with libraries (different ways of doing the same thing) and introduced unnecessary mess
14:32:50
nyef
So, I see five potential lines of argument here, centered around the Linux kernel... 1. Does C have "proper" language support for interfaces? 2. Is the Linux kernel not "well structured"? 3. Do the kernel developers have "superhuman" will power? 4. Is the Linux kernel not dealing with a large problem? Or 5. Is the Linux kernel an existence proof for a counterargument?
14:34:02
jackdaniel
I would argue if it is well structured, but it is also a fact that it has strong leadership
14:34:30
jackdaniel
also bear in mind, that "quotes' carry only limited amount of truth (like general direction), so they are not claims per se
14:34:50
nyef
Yes. I would argue that "superhuman" will power is attainable, provided that you involve more than just one human.
14:36:13
nyef
I would further argue that /this is the most useful line of inquiry/, and that the follow-on question is "how might superhuman will power be replicated on a smaller scale?"
14:37:31
nyef
And that this is not a "technical" problem as such. (Well, it IS, but it's a social-technology thing, not a computer-technology thing.)
14:38:15
jackdaniel
if technology makes things easier, then having this computer technology as your aim influences greatly the overal result
14:39:15
jackdaniel
also attaining superhuman will power sounds like a lot of a hassle, so having language support which deems it unnecessary is something desireable
14:41:42
nyef
Mmm. Will power is a finite resource. Renewable, yes, but you can only have so much of it at a time. The less you need to use it, the more of it you have to use for important things.