freenode/#clim - IRC Chatlog
Search
4:31:11
loke
beach: Thanks for your points yesterday. I'm now looking at implementing fast scrolling in a different way, that doesn't change the underlying transformation
4:32:10
loke
beach: In my thinking I boiled down your opinion to one thing, please let me know if I'm on the right track:
4:33:06
loke
beach: The number 1 issue seems to be that if I set transformation on a sheet to X, and then read that same transformation back, then you should get X back. Not, as in my case, kinda-sorta-X-but-rounded-a-bit
4:34:16
loke
The idea being that scrolling operations attempt to would ensure that the subpixel offset remains constant.
4:34:36
loke
That will not eliminate rounding errors, but will ensure that they are always resulting in the same error.
4:36:37
loke
beach: I came to that conclusion after thinking about cases where the forced rounding could cause issues, and came up with only one case: That case being an animation that slowing scrolled the screen by adding a small value to the transformation every frame: Like adding 0.4 pixels per fracme. With forced rounding, that would prevent movement since the 0.4 would be rounded to 0 every time it was updated.
4:37:28
loke
(I don't think this is something that would happen in practice, but it's nice to expore possibilities that would result in a theoretically “correct” behaviour)
4:38:15
loke
Anyway, I spent a day thinking about it, and I just now started to actually experiment with code, so it'll take another day or so before I have anyting to report.
4:38:56
loke
slyrus1: didn't have any time in front of Emacs yesterday so I didn't look at your code yet.
4:41:01
loke
beach: Oh right, I almost forgot: Tell me: Can Second Climacs handle non-text objects in its buffers?
4:42:38
beach
Yes, it can. I but I don't have any ways of inserting them, and I don't know how to display them (yet). :)
4:43:56
loke
beach: What I want to do is to build a “notebook” that can be used to draft scientific papers. When experimenting in Maxima, you'd just click on an equation to copy it into the notebook (which would be a (second climacs?) editor buffer).
4:44:30
loke
Id' want those to be displayed in maths form of course. Then you can export the notebook as LaTeX.
4:46:59
loke
beach: Ideally, I'd like a way to click on the visual form of the equation, which then gets replaced with the maxima-text-form (the kind you type, like “1/x^2”). And then when you're done, it filps back and renders it in mathematical form again.
4:48:42
beach
I haven't thought about it much. My initial thinking would be to include the entire formula as a single item in the buffer as an instance of some appropriate class. Inserting it as text would be trickier, because you would then have to somehow identify text snippets that should be rendered differently.
4:49:51
loke
beach: Correct. The text form would only exist while you edit the text. The moment you move out of the formula it rrverts back. So I presume at all times it would still be stored as a formula (implemented by the class ‘maxima-native-expr’ in CLimaxima at the moment)
4:50:24
loke
The sextual form of the formula is only there since it makes editing it maually easier (or shall I say, ‘possible’)
4:51:34
loke
I think the equation-editing-text should be separately highlighted (or even displayed in a popup of some kind) to make it obvious it's not part of the actual text per se.
4:52:58
loke
I'll probably have to implement it based on Drei for now, but the problem is that I want to add a lot of specialised features, which I'd rather not do unless I can do it based on an editor that is actually maintainable.
4:53:36
beach
I have this "strange" vision of things where one single Common Lisp "image" could include several "applications" that collaborate using Common Lisp objects (as opposed to streams of bytes). That way, Climaxima could transfer formulas to Second Climacs for inclusion in a text buffer, and perhaps a specialized formula editor could be called upon to edit it.
4:54:27
loke
My experience with implementing the text completion popup with Drei was that the generalised-editor-interface in CLIM is very superficial. Anything more advanced than editing a line of text (not even handlign the pressing of return) required you to call DREI::xxx methods.
4:55:36
loke
However, CLIM is limited by some design decision taken by Genera. Specifically the inability to interact between multiple threads, and by extension, windows.
4:55:59
loke
If it's all in a single frame, you're _mostly_ OK, but the imperative nature of command handling is still a problem.
4:56:14
beach
I still haven't quite understood that issue, but if I think hard about it, I might ultimately get it.
4:56:58
loke
beach: I'm going to lunch, but I will try to explain the core issue (as I understand it, I could be wrong of course) in one sentence :-)
5:00:03
loke
Today, you need a separate event loop for each frame. That means that the input context is different for each one. They are, for all intents and purposes, different in all respects. That is why, when the input contexts says I can click on an object of type X, I cannot click on an object in a different frame.
5:01:23
loke
One way of solving this would be to have only a single even loop and letting standard CLIM behaviour control multiple windows. Then the input context would be “global” across all the windows.
5:04:02
loke
It would all have to run in a single thread, so you're limited to a single interactor pane across all windows.
5:05:34
loke
Problem 2 is, in a nutshell, the problem that an interaction pane is driven in an impertive way. You literally have a LOOP sitting there, performing a READ to read chars off the keyboard. Since there are no continuations in CL, you can't have more than one live at the same time.
5:06:42
loke
beach: You literally have a top-level loop that dispatches events, and each event handler is not expected to run more than a fraction of a milliseconf. Longer jobs require threads.
5:08:27
beach
Monday mornings are crazy around here. In an hour or so I have to leave my office and I will be back perhaps an hour later.
5:08:28
loke
One “solution” I have been thinking about is perhaps allowing a different type of command reader, one that can exit (using a signal). If this new command reader is written is such a way that all its runtime state is kept not on the stack but rather in a context object of some kind, then the reader can be restarted.
5:08:59
loke
Applications would have to be written to take this “preemptible” command reader into account.
5:10:23
beach
It would be unfortunate if you couldn't start a computation in one application and switch to a different one while the computation is going on.
5:10:36
loke
A threaded solution is certainly easier to implement in a progressive manner, since it “works” right now, and you'll just have to slowly add more capabilities.
5:11:29
loke
beach: Yeah. Event-driven systems enforce this by making you create compotation threads for literally everything that takes more than a millisecond. Android, for example, will pop up an error message if control is not returned to the command loop within 1 second or so.
5:12:25
loke
I think most GUI frameworks considers that case as an error and will present a popup with the option for a user to kill the application.
5:16:20
loke
beach: Android goes even further. Code in the main thread (where the event loop is running) will throw an exception if you try to call any blocking bethds from it (for example attempts to do IO)
6:03:09
beach
OK, I'll check that. Thanks. I need to go. Cleaning person is due in less than 10 minutes.
6:04:39
loke
Also, perhaps activate another window (text editor) to se eif you'll find the garbage in that window instead
6:07:15
pillton
You should always write event driven systems to allow users to programatically invoke the event processor.
6:07:37
pillton
As you have correctly pointed out, the problem with event loops is that you can only have one.
6:09:16
loke
pillton: that's not really a _problem_ with event loops. It's the definition of one. :-) The real problem is that imperative code calls the event processor as part of its work, instead of leaving that to a single master event loop
6:10:01
pillton
It is a problem because users cannot compose software containing of two or more event loops.
6:10:49
pillton
A good design to follow is non-blocking IO. It has none of the problems associated with synchronous or asynchronous APIs.
6:11:38
loke
pillton: non-blocking IO, or I presume you mean, CPS, is just a way of creating API's around a single event loop
6:12:36
pillton
Yes, but it allows the composer of software to chose how the single event loop is created.
6:13:15
loke
pillton: How could they? All pieces of the software still have to agree on how the flow of events are processed.
6:14:04
pillton
That is what controllers are for. Synchronising the state of disconnected models as events arrive.
6:14:54
loke
TO be fair, McCLIM already has a central place where the events are read from the X11-source. You could add a callback mechanism on there, then you can build whatever infrastrusture you want (be it event-based, CPS, etc) on top of it. And it would still work with the existing CLIM infrastructure. It's just that the event loop isn't sitting on top of the call stack anymore.
6:16:56
jackdaniel
that way you don't hijack distribute-event machinery what would distort the whole design
6:18:27
pillton
I am not really talking about CLIM, I am talking more generally about software that waits and processes events.
6:19:01
jackdaniel
then this question doesn't belong here I think – also you've already answered yourself: in non-blocking io …
6:28:06
loke
jackdaniel: As best as I cal tell, most of the thread-of-control issues in CLIM can be handled by existing machinery, with the exception of the input context stuff. Would that be a fair assessment?
6:47:54
jackdaniel
loke: I think so. I still have a some tasks put on hold regarding McCLIM threading
6:48:29
jackdaniel
most notably: thread-safe streams (I've discussed solution here a few months back)
9:05:52
loke
I wonder why... But then again, I never understood where that problem came from in the first place.
9:06:55
loke
I do have some flickering and stuff though... I'm guessing that my alignment trickery in the scrollbar code isn't always doing the right thing.
9:13:56
loke
The key is in the callback to the scrollbar movement for viewports to pass the new coordinates through this function:
9:14:40
loke
That ensures that when dragging, each update moves the cheet without affecting the decimals
9:15:55
beach
Guys, "advice" is uncountable in English. More advice, less advice. A piece of advice. Many pieces of advice. :)
9:16:06
loke
The scrolling using the arrows didn't need any change, since they arelay scroll by an integer amount.
9:18:44
loke
The new version using the beach-solution seems to have resolved the odd off-by-one errors I had in the scroll-test as well
9:21:17
beach
The real challenge, in my opinion, is to get it right when we do anti-aliasing while at the same time not using mirrored sheets other than for the top-level sheet.
9:22:51
beach
Because, then we must redraw things on other sheets as well when the contents of one sheet changes.
9:23:42
beach
If can get this right, we have a very general system that can produce beautiful and correct output in all cases.
9:24:27
jackdaniel
right now we take by default slow path (and that's what I've been figuring out when I was working on mirroring) with always-repaint-background-mixin in case of single-mirror hierarchy
9:25:24
loke
beach: What I do now is look for the very specific case that works correctly (scrolling by integer amount, partial visibility, etc) and fall back to slow path in other cases
9:25:39
beach
Now, if you listen to moore33 (who is a OpenGL wizard) he says that there is no longer any need to optimize stuff like that. Just redraw the entire thing.
9:26:54
loke
beach: Speaking of that... Is it possible to add custom information to an output record?
9:27:22
loke
I'd like to cache the shaped text in the output record instead of calling out to the font shaper every time the string is redrawn.
9:30:01
loke
jackdaniel: As far as I understand, an output record is generated without knowing what kind of stream it should be drawn to? I mean, can I create a speical output record for DRAW-TEXT, but only for CLX backend?
9:30:52
loke
The output records are created by a specialisation on MEDIUM-DRAW-TEXT on recording streams. This code has no knowledge of CLX
9:33:04
loke
jackdaniel: A specific font-string combination has a shape, which is recorded as an array of font glyphs and offsets.
9:33:22
loke
Right now I'm recomputing these very time a string is drawn, but it's slow so I'd like to be able to cache it in the output record.
9:34:11
jackdaniel
another solution is to do it per-stream, and store that information in stream directly
9:35:07
loke
If I cache it on that level, then I might just hash it based on string/font/size combination and skip the output records
9:38:23
loke
Hmm... I wonder where the slowness comes from. It much too slow on ECL for it to be caused purely by the fact that ECL is slower than SBCL. It isn't _that_ mcuh slower.
9:38:26
jackdaniel
cffi is very fast on ECL. you may also change method (with a special variable, don't remember the name) to inline static calls to C library. but neverless it is reasonably fast
9:40:20
jackdaniel
if you are inclined to do be more specific, then you may use standard C profiling tools
9:41:07
jackdaniel
yes and no. if lisp function is defined in ECL's C core, then you'll see its name
9:42:27
loke
Couldn't defmethod create a one-line function that calls out to a pure function that is compiled?
9:42:48
jackdaniel
as far as I understand things it is possible with some expense, but we didn't get there yet
9:53:25
jackdaniel
library which is on quicklisp . it was created by Mark Kantrovitz and it is partially based on CMU profiler
9:56:48
jackdaniel
I have an impression that Shinmera really prefers to invent his own things instead of contributing to existing software
10:00:02
beach
I am looking for something that I can leave in the production code to gather statistics for a very long time. If a report is never requested, that is fine too. And I don't necessarily want to profile a function. I might want to count the number of times a particular piece of code was executed and how long it took (average, standard deviation, etc).
10:00:59
beach
I hacked together something for SICL, but I would rather get rid of it in favor of something existing (better, maintained, etc).
10:05:19
beach
I think it might require some first-class representation of a "meter" or "monitor" that can be the value of a special variable and that gathers statistics as the program runs.
10:06:11
beach
I am inspired by Multics here. They had plenty of meters in the system and they were quite useful for figuring out general performance statistics.