freenode/#sicl - IRC Chatlog
Search
4:44:22
beach
Besides mediocre software, the other thing I don't like is mediocre documentation. When I do `git status -s' in one sub-directory of SICL I get a T in the second column, but `man git-status' does not list T as one of the possible outputs.
4:46:23
no-defun-allowed
https://stackoverflow.com/questions/6879501/filter-git-diff-by-type-of-change#6879568 has a snippet from `man git-diff` of all places describing the letters.
4:55:01
beach
OK, I think I see what the problem is, but it required #sicl, no-defun-allowed, stackoverflow, and a second computer with a copy of the SICL repository on it to figure it out.
4:55:27
beach
Somehow, files that are symbolic links in the repository have turned into regular files.
4:56:25
no-defun-allowed
I've never checked, but the GitHub viewer shows broken symbolic links as files, just containing the pathname.
4:57:40
no-defun-allowed
I think that's how the representation could work though. If you look at the contents of those files, are they what you expect?
4:58:22
no-defun-allowed
(Not that this is what you expected at all, but do they have the contents of the linked file?)
5:00:54
beach
Yes, they are identical. Just removing the files and doing git checkout fixes the problem.
5:14:27
beach
Clearly, the software I write has defects, and the documentation is sometimes incorrect or out of date. But I am a single person, and I would think that software like GIT or Firefox would be better, given the resources at their disposal. Having said that, I think that the software that has been `released' and the documentation we produce for it, like Cluffer, Eclector, Flexichain, etc. are not too bad at all, given the resources
5:17:21
beach
I do not consider Cleavir as having been `released', since it is still being worked on. It is used by Clasp because drmeister asked to use it.
5:43:29
beach
The thread is part of the dynamic environment, so a separate register is not strictly required.
5:44:53
beach
Multiple values beyond what registers can hold can be contained there as has been suggested.
5:48:34
beach
Code that uses the floating-point register for floating-point arithmetic can just save that register temporarily.
5:49:21
beach
But since I expect most code to use integer arithmetic, or no arithmetic at all, there is a chance that this register will not have to be saved and restored very often.
5:53:18
beach
The inconvenience, of course, is that it has to be copied to a general-purpose register in order to be dereferenced.
5:56:26
beach
On the other hand, if I dedicate a general-purpose register for it, then it would very likely have to be spilled to make room for other data during the execution of a function.
6:05:08
beach
In the past I was thinking that the thread object would be accessed through the dynamic environment, like a special variable.
6:07:13
beach
And object allocation is needed for lots of stuff, including creating closures and "cells" for shared variables.
6:33:48
Shinmera
beach: Could use SSE registers instead, those would be even less likely to be used.
6:34:42
Shinmera
You might want to talk to the SBCL people though, they might have real-world based opinions on which register to pick.
8:10:51
beach
I have also been looking for a register in which a single bit indicates whether a thread is being debugged. I can use one bit in the same register or I can use another SSE register. That would make the test for being debugged fast enough that it should only have a very small impact on a thread that is not being debugged.
8:14:24
Shinmera
That stuff, if I remember correctly, runs with almost zero overhead, which made me wonder whether it could be repurposed
8:15:23
beach
And I don't even know what tracing and profiling stuff you are referring to, since I am not that familiar with the Linux kernel.
8:17:01
Shinmera
I'm not sure either, I just faintly remember a talk about how they achieved high performance profiling.
8:30:45
beach
I don't know, but it looks like kernel tracepoints are obtained through explicit instrumentation.
9:05:30
beach
My idea for SICL, in case someone missed it, is to have a 3-stage test for each possible breakpoint/tracepoint (when the code is compiled with a high value of DEBUG). In stage 1, a flag is tested to see whether the current thread is being debugged at all. Most threads are not, so this test will then skip the remaining stages, with only a minimal slowdown being the result.
9:05:37
beach
If the thread is being debugged, a small-ish (maybe 64 entries, so that the table fits in a word) Boolean table is being consulted, using the current value of the program counter, modulo the size of the table. If the table contains 0, then, the third stage is being skipped, resulting in a small slowdown only for breakpoints with the same modulo value as one that is "active".
9:05:39
beach
Finally, if the table contains 1, the debugger is consulted to determine whether this value of the program counter requires special treatment. Only a small number of PC values will need to do all 3 stages.
11:15:36
beach
The more I think about it, the more I am impressed by this original idea by scymtym about how the debugger and the debuggee communicate.
11:15:43
beach
Standard wisdom is that the debugger has access to the internal state of the debuggee, and can alter data and control flow relatively arbitrarily. But that model is inherently unsafe. The debugger can then get access to anything that the debuggee has access to, so it can do basically anything.
11:15:58
beach
The model suggested by scymtym (I am paraphrasing; not the literal words used by scymtym) is that the debuggee proposes a bunch of services, depending on the place where it has stopped.
11:16:06
beach
The role of the debugger is merely to show these services to the user and to provide a convenient interface for the user to choose one of the services offered.
11:16:07
beach
With this model, the debuggee only offers services that are safe, and the debugger has no way of proposing any other service.
11:18:16
beach
I guess I should document this basic idea and how it differs from standard wisdom. Probably in the Clordane introduction.