freenode/#sicl - IRC Chatlog
Search
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.