freenode/#clim - IRC Chatlog
Search
7:54:02
scymtym
loke: iiuc, in your requirements document you specify that configuration data should be loadable without the system using it being loaded. you also specify that configuration items have associated types which would presumably be under the control of the system using the options. how does that work?
7:54:03
scymtym
(also, the configuration.options systems meets many of the requirements and could be extended to meet more, but the one related to "bootstrapping" are tough)
8:42:37
loke
scymtym: Things like the editor and the validator would indeed be part of the application that uses the data.
8:43:13
loke
scymtym: This works, because you'd only use those function (like the encoder/decoder/validator) when the system is available.
8:56:57
loke
The storage engine would simply return the lisp structure. The DECODE method would only be called when the application requests the data, at which point all dependencies are obviously available.
8:58:34
scymtym
where the "lisp structure" is created and stored when the configuration file is processed?
9:04:00
loke
scymtym: Well. There is a single function, SET-VALUE that writes a setting to the storage engine. Theis function would pass the argument through the encoder function, which implies that you need to have dependencies available to use it.
9:04:39
loke
However, there is no reason why you couldn't have a funciton that allows you to store a variable directory without the encoder. That would allow the storage of incorrectly formatted data though
9:05:22
loke
One alternative would be to have the validator function act on the backend structure, and let the storage engine store the validator function itself as code
9:24:56
scymtym
loke: there certainly are tradeoffs. what is the downside of processing a separate file, say ~/.config/climrc, lazily. i.e. when the system using the configuration data is loaded or maybe even right before it wants to access the data?
9:26:11
loke
The main purpose of this, hoever, is to be able to ptovide a uniform configuration GUI.
9:26:36
loke
Specifically for CLIM where you'd want to have a single font selector and a single place to configure fonts.
9:29:10
scymtym
a configuration editor would have to use some kind of schema (configuration variable names and types) defined by the clients of the configuration system, right?
9:31:16
scymtym
i'm going to say one final time that the configuration.options system seems like a potential match for the requirements, then shut up about it for good :)
9:41:26
scymtym
loke: more than a few days, i think, but yes, probably. this: https://github.com/scymtym/configuration.options
9:45:28
loke
scymtym: If I want to use a custom backend, can I configure that prior to loading configuration.options?
9:47:24
scymtym
the application has to setup the source(s) (= backend) in any case. so yes, that is possible. there is some builtin support for typical sources such as a cascade of configuration files/directories, environment variables and commandline options
9:52:28
scymtym
loke: maybe this can help you get started: https://techfak.de/~jmoringe/clim-option-editor.lisp
10:21:06
scymtym
loke: i extended it a bit more so that it creates semi-working editor cells for integer and string options
10:31:09
loke
scymtym: Hmm... How do I enable sb-sprof? Isn't it enabl;ed by default when compiling with --fancy?
10:31:57
scymtym
it should be built and installed in any configuration. (require 'sb-sprof) to load it
10:51:11
loke
That told me that I should not be creating a new ink object for each string being pritned
10:54:35
scymtym
and then the flamegraph gives very different insights compared to the flat/tree reports
10:55:43
loke
ACTION discovered that caching the ink objects doesn't work, that causes protocol errors on the Xlib level :-)
15:37:57
loke
If I don't have to reallocate the xrender objects every time I draw a string, performacnce is doubled.
15:44:35
loke
destroy-window is a not a generic function, so I can't attach an :AROUND method or anything like that
15:45:36
loke
The problem is that the xrender pictures are logically attached to the window in my code, but they are not part of it from the Xlib point of view
15:48:13
loke
but... I'm thinking that instead of attaching the cached pictures to the window, I can attach them to the Display... After all, I _think_ they are compatible.
15:48:46
loke
There would be a problem if you have an application opening windows on multiple screens, some of which have different bit depts. Then the xrender pictures wouldn't be compatible anymore.
15:49:57
loke
oleo: You never "map" a picture to a window. A picture is used as a storage medium for something that should be drawn to any window. It's a server-side image buffer.
15:50:59
oleo
from the server point of view they are offscreen memory, which are realized from time to time so to say
15:51:16
loke
Up until now, both pictures I need to render subpixel sampled text has been allocated in the beginning of every render-glyphs call, and freed at the end. I noticed drawing was slow so I did a benchmark: 50% time spent allocating just _one_ of those two pictures.
15:52:31
loke
oleo: Well, they're not realised. You draw the source image to one picture, then you draw the background to another, then you use these two images in an Xrender call to composite them with the actual window content.
15:57:40
loke
Now... the "pen" object (the one that holds the foreground colour) is created with a pixmap as its backing object. After creating that picture, the pixmap is freed.
15:58:15
loke
If it's freed when the X connection is closed, then I can just tie the cached pen to the XDisplay object and be done with it.
16:00:57
oleo
if you want to free the image, as in alter it or destroy it (like setting all bits to zero etc) then you have to have another pixmap of the same bounds, drawn onto the same window
16:03:46
loke
Yeah, that's not the issue. The problem is when/if the Xrender picture gets freed if I don't do it manually.
16:08:46
loke
So I'm going to assume that they understood it, and that the picture gets freed when the GC is dropped.