freenode/#sicl - IRC Chatlog
Search
11:04:03
beach
Not as advanced as Petalisp, but I keep thinking about ways in which a Common Lisp system like SICL could take advantage of multi-core CPUs. You told me that using threads for sequence functions is not such a good idea. But the garbage collector I am planning takes advantage of threads, and I think that's a very good thing.
11:05:55
beach
I can imagine other things such as scanning the memory for obsolete instances and updating them, or computing discriminating functions after methods have been added or removed.
11:08:55
beach
Oh, here is another question for y'all since drmeister is working on backtraces for Clasp...
11:09:57
beach
A backtrace usually names the function invoked in each stack frame, but what if those functions are not part of user code, but introduced by macros or just called indirectly by the system?
11:11:01
beach
For SICL, I want the backtrace to contain source information and not specific names of functions. The source position can then be accessible by selecting a particular stack frame.
11:18:56
jackdaniel
programmers will expect function names or expressions which are leading to the problem
11:20:43
beach
The beginning would be either 1. The entire form if it is a single line and not too wide. 2. The first line of the form, if it does not have too many characters in it. 3. The first N characters of the first line, if it is too wide.
11:22:22
jackdaniel
I think that except the behavior with truncating lines you've mentioned sldb with sbcl does what you want already (prints expressions)
11:23:25
jackdaniel
and ecl does something else (tries to print function names). I think that printing the expression is much more useful
11:25:00
beach
OK, so here is an example of what I want to avoid. Let say I have (defun ff (x) (destructuring-bind (a b) x (list a b)))
11:25:27
beach
Now the backtrace has (SB-C::CHECK-DS-LIST #<unavailable argument> #<unavailable argument> #<unavailable argument> #<unavailable argument>) on top.
11:27:18
beach
The thing here is that (SB-C::CHECK-DS-LIST #<unavailable argument> #<unavailable argument> #<unavailable argument> #<unavailable argument>) is not something the programmer recognizes. In this case, an educated guess could be made, of course, but imagine complicated macros with strange expansions.
11:28:30
jackdaniel
this can only work for internals you proclaim beforehand as "unrecognizable to a programmer", no?
11:29:14
jackdaniel
also if it is turtles all the way down I'd expect I can see implementation internal functions too (in fact, I often do)
11:30:15
beach
jackdaniel: The highest priority is not to exclude internal stuff, but to include user stuff that is not currently displayed because of macro expansions and such.
11:30:42
beach
But yes, it would be good to have a flag that could control whether that kind of internal stuff is displayed or not.
11:31:31
beach
In my first example, the macro call destructuring-bind is not shown, and in the second example, the call to loop is not shown.
11:31:34
jackdaniel
also: what is a default behavior? you stop at the first macro no matter how many frames downward the error is happening?
11:32:33
jackdaniel
if you print only up to the first unexpanded macro, what about programmer-defined macros? are their expansions skipped too?
11:32:35
beach
I don't understand the question. Instead of some function name being shown on the line of a stack frame, the source code of the expression being evaluated would be shown.
11:34:41
jackdaniel
(defmacro with-foo (opts &body body) `(flet ((cont () …)) (with-opts (,opts) (invoke-with-foo #'cont))
11:36:20
jackdaniel
let's say that error is signalled somewhere (say we have 3 more frames), do we print (with-foo …) line as something being the source code associated with the error on all three lines?
11:39:01
beach
If the existing expression to be evaluated is a function call, it will be the same as now.
11:40:06
jackdaniel
yes, and what are labels of these frames if they come from the expression which was a macro?
11:40:07
beach
If the existing expression is a macro call, then the macro call will be shown instead of the function it expands to. But if, as a result of evaluating the expanded macro, there are calls to other functions, those will have their frames too.
11:44:10
beach
SBCL shows (HH 234) on the top frame, and the error is 234 is not of type LIST which is totally devoid of information because we know that.
11:45:13
jackdaniel
nb: it is a nice touch that when I press "v" to see the source of function defined in the repl I have a *slime-source* with #:***HERE*** marker before the car
11:45:50
heisig
Yes, SBCL with (debug 3) also marks the (car x) form as the location of the error, at least when pressing "v".
11:46:42
jackdaniel
well, seeing (car x) in backtrace won't be terribly useful either (moreover, I don't have a context in which function this car has been invoked)
11:48:02
jackdaniel
right now it is the other way around, when I look at label I see the function, and when I look at stack frame (most notably position) I have the exact expression
11:48:03
beach
And it is still more useful than 234 is not of type LIST, because it shows that the attempt was to take the CAR of 234.
11:49:42
jackdaniel
also, if something like (list (car foo) (cdr foo)) is a result of macroexpansion, the top frame will show "(quux 234)" and "234 is not of type LIST"
11:55:14
beach
A macro like that would not have "(QUUX x) expands to (list (car x) (cadr x))" in its documentation. It would have "The argument of QUUX must be a list, or an error of type ... is signaled".
11:55:19
splittist
which programmer? The one who wrote the library depended on by the library ... used by me?
11:57:39
splittist
I understand that you can't save bad programmers from themselves (or anyone from bad programming practices), but is optimising for the perfect source code the best way to go in a situation where, ex hypothesi, something has gone wrong?
11:59:03
beach
I have had similar discussions with nyef. To him, if it can't be used to debug incorrect code generators, it is useless.
12:00:24
beach
I guess I am working on an ever-expanding list of people who will never touch my stuff. Shinmera, nyef, and now jackdaniel, splittist. Lucky for me, as I have often said, it is perfectly fine with me if I am the only user.
12:00:52
splittist
I'm trying to think how this would have helped/hindered me in working out what I had done wrong the other night, when solving the issue took far too long (PEBKAC, obviously). I should just have grepped for the condition message the library author had supplied...
12:01:43
beach
Shinmera: Oh, yes, you have said that you would never use an editor that executes in the same image at the Common Lisp system. And that's what I am working on.
12:02:31
beach
I guess I am working on an ever-expanding list of people who will never touch MY STUFF.
12:03:01
splittist
So it's an ever-expanding list of people who will not touch each and every piece of your stuff?
12:04:14
jackdaniel
if you decide that discussing something you propose (not due to lack of other things to do) on your specific request makes your list expand? I think you should warn people before starting discussion…
12:04:47
Shinmera
Anyway, your previous statement was very much a strawman. I'd refrain from stating such things as it can put a very foul taste in peoples' mouts.
12:06:24
Shinmera
Just to be clear from my point: the only reason I have yet to touch Sicl and Cleavir is that I'm short on time.
12:06:32
jackdaniel
my above sentence is not a well formed one, what I mean is that I feel a little unpleasent with what you have implied "on my behalf"
13:25:52
jackdaniel
so, when things have cooled a little: idea of printing actual forms as labels sounds useful, but letting user to customize this sounds even better - that way it will be a user choice and I doubt anyone will snark at it anymore. Both printing source and expanded expression is (imo) strictly better than printing function names
13:28:08
jackdaniel
beach: if you are not familiar with a "red team" term, I think that looking at opposing opinions with this optic may prove being more comfortable (https://en.wikipedia.org/wiki/Red_team)
13:31:24
pfdietz
beach: the garbage collector is a good candidate for parallelism. In SBCL., GC quickly becomes the bottleneck when using multiple threads.
13:47:37
shka__
each thread has local memory pool for objects, and there is a also global, shared memory area for stuff that is, well, shared
13:48:29
shka__
so well separated threads in SICL in theory should not be throttled by garbage collector
13:55:40
heisig
Except for collecting the global heap. In that case, a multi-core GC would help a lot.
14:25:20
pfdietz
For the particular use case I was thinking of (largely independent threads that don't communicate much) the SICL style would be fine.
14:26:51
pfdietz
This came up testing the multithreading compatibility of the SBCL compiler, which recently had a global lock removed from it. Even in 8 threads, it was just achieving a ~1.4 speedup. GC was the problem.
14:31:55
jcowan
"Sir, we have an insurmountable problem." "Mr. Jones, in this company, we do not have problems, we have opportunities!" "Yessir. Excuse me, sir. Sir, we have an insurmountable opportunity."
14:32:20
pfdietz
"Boss, we're faced with insurmountable problems." "Don't call them that! We have opportunities, not problems." "Boss, we're faced with insurmountable opportunities."
15:35:05
beach
pfdietz: Is there a version of the SBCL system that does not stop the world for a GC?
15:37:49
beach
It seems Clasp has been able to use MPS successfully. It would be interesting to know how dependent the SBCL GC is on the way other things are done in the system. I imagine hash tables would complicate things for instance.