freenode/#clasp - IRC Chatlog
Search
12:47:56
drmeister
I added a SIGINFO handler so that on macOS if you hit Control-T you get a backtrace.
12:59:17
drmeister
So you are running in the terminal and you see a pause and ask "What the heck is that thing doing now?"
13:16:10
drmeister
Here's the frame structure: https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/lsp/backtrace.lsp#L12
13:16:21
Shinmera
Here's the survey for things I'll need to know then: http://plaster.tymoon.eu/view/856
13:19:16
drmeister
I understand - note: (core:call-with-backtrace ...) has only existed for less than two weeks.
13:21:18
Shinmera
Anyway, I'm not too bothered if I need to make adaptations to the dissect backend if Clasp should change
13:21:40
Shinmera
But I just want to get it done so that other people can depend on a stable interface
13:28:52
drmeister
Also - the backtrace only has meaning within the call-with-backtrace - can you deal with that?
13:29:23
Shinmera
Yes, Dissect captures the trace and translates it into its own objects that are then exposed to the user
13:30:24
Shinmera
It's ok if you can't answer every point on the survey, that's only for full feature compliance
13:30:38
drmeister
But if you capture the trace and it escapes from call-with-backtrace parts of it will be meaningless
13:31:32
Shinmera
Stack caps cut off anything above a particular point to throw away useless frames that are implementation details
13:37:59
Shinmera
No, it has a singular entry function called STACK that returns al ist of FRAME instances.
13:40:42
drmeister
I've always had a core C++ namespace. When I started using ECL's CL code it uses "SYS" and "SI". I realized quickly that what I have in the 'core' C++ namespace corresponds to what ECL has in the "SYS" package.
13:41:24
Shinmera
In any case, it would be great if the documented interface was through EXT, as that is not internal.
13:41:29
drmeister
To go back and change it would require me to write a source-to-source translator - which I can but there have been more pressing things to do.
13:44:20
drmeister
Question: How much can I do in a signal handler? (This will require more explanation).
13:44:50
drmeister
I currently have a backtrace generator with arguments that does a bit of malloc'ing but no GC allocations.
13:45:34
drmeister
I'm not sure if a signal handler stack frame is connected properly to the rest of the stack.
13:46:02
Shinmera
Wasn't the typical advice that you should do practically nothing and get out as quick as you can?
13:46:57
drmeister
Yeah - that's what I do now. But that means that this Control-T/SIGINFO/SIGUSR2(linux) thing only works once it encounters a safe-point in Clasp.
13:47:29
drmeister
I can't get a Control-T backtrace within llvm or any C++ library that is taking time.
13:49:26
drmeister
I'm curious if I can get away with it. I don't even need to malloc - I just need to follow the linked list of base-pointers.
13:55:03
Shinmera
By the way, I came across this, which might interest you https://github.com/weirdNox/emacs-gdb
14:07:10
Bike
so if i bclasp-compile something with a tagbody but no closures, the disassembly seems to indicate there's still a bunch of __cxa shit and so on
14:30:44
Bike
drmeister: here, you can use these definitions for the documentation thing https://pastebin.com/r5xTdi75
14:32:19
stassats
but you still may want to first expose something from not ext for testing purposes, or even not exporting at all
14:38:26
drmeister
So replace this: https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/clos/inspect.lsp#L352
14:46:09
Bike
the simple example i tried only didn't have the landing pad because there were no calls. if there's a calla the landing pad sticks around
14:49:14
drmeister
Ideas: (1) What if we define special operators local-tagbody that only works with local-go
14:50:33
drmeister
(2) If we determine that there is no dynamic-go or dynamic-return-from and redirect the second return value of the invoke to the next landing pad that comes after the one that handles dynamic-go/return-from.
14:51:20
drmeister
I thought maybe it would - but maybe not. We could rewrite it as a call followed by a branch.
14:52:28
drmeister
I thought maybe it would be difficult - because invoke's are branches and they come at the end of basic blocks and calls can appear anywhere.
14:54:59
drmeister
Actually I think it's easier than that. There is a stack of landing pads at every invoke site.
14:56:28
drmeister
Conceptually - there is a stack of valid landing pads at every invoke. Hopefully the dynamic-go/return-from one is the top of the stack. If it is then we simply change the unwind path of the invoke to the next one down the stack.
14:58:25
Bike
(block nil (tagbody foo ... (lambda ... (go foo)) ... (return (bar)))). then the tagbody has dynamic exits but the block doesn't, but the return is within the scope of the tagbody
15:00:06
drmeister
For optimizing discriminating functions I think the local-tagbody/local-go is looking better.
15:01:27
Bike
also if we do add new special operators, we'll need them in cclasp too. though they'll just alias to tagbody and block and stuff.
15:04:58
drmeister
Well, I had put a typo in one of the documentation defmethods and when it was compiling alexandria it halted.
15:07:06
Bike
they do at runtime, but for the compile-file version they might get run through cclasp.
15:34:05
drmeister
Ugh - I think this may be a similarity thing during literal compilation. The docstring and declares are starting out as NIL and so they are getting the same slot in the literal table as NIL.
15:35:49
Bike
how are we setting the value of nil? shouldn't we just be changing the value in the function description?
15:36:36
drmeister
The function descriptions can't store GC managed objects - they live outside of the GC managed memory.
15:37:08
drmeister
So for docstring - they contain an integer index into a literal table (which does store GC managed objects).
15:38:06
Bike
So what if I set the function-docstring to be something dynamically computed, so it doesn't have an index in hte literal table?
15:38:33
drmeister
We need to ensure that the function-docstring gets its own slot in the literal table - that's all.
15:39:03
drmeister
Right now we are violating the (unintended) constant nature of the literal table.
15:39:18
Bike
Like is something going to explode if I do (setf (documentation #'foo t) (format nil ...))
15:40:33
Bike
is it really a good idea to allow alterations of the literal table at runtime? that sounds extremely sketchy.
15:43:01
drmeister
It's just a root. There is a slight issue in boehm - when we write into the slot we have to write two places unless I can get their root declaration function to work.
15:43:48
drmeister
No - this is totally fine - we are just updating a root. I just need a few min with the literal compiler.
15:47:29
drmeister
How about this? We add a level of indirection - we compile a CONS cell as a literal and we store the docstring in the CAR of that CONS cell?
15:48:51
drmeister
That solves the uniqueness problem, and the boehm issue at the expense of 4*16bytes for every function-description. We should do it for all of these function-description components.
15:49:45
drmeister
Someone went and put these little cinnamon christmas trees on all of the door knobs on our floor.
19:45:27
drmeister
If I want to export the core:backtrace-frame to the ext package - as part of the API - what is the idiom to do that?
19:46:08
drmeister
I mean export backtrace-frame from the ext package and for now just import the symbol from core to ext and export it from ext
19:52:22
jackdaniel
drmeister: more (defpackage ext (:export #:backtrace-frame)) (defpackage core (:use :cl :ext) …)