freenode/lisp - IRC Chatlog
Search
8:06:03
flip214
hmmm, the lotto example from http://www.xach.com/naggum/articles/3063147946409477@naggum.no.html is with gcc -O3 more than twice as fast as with SBCL 1.3.14...
11:44:42
drmeister
jackdaniel: My problem is this common scenario: A process is running and taking too long. I hit Control-C and a SIGINT gets sent to the process with an interrupt handler that calls #'break. sldb comes up and lets me inspect things. I decide I want to unwind the stack to above the loop that was taking too long.
11:47:17
jackdaniel
drmeister: in handler you may save, which thread is to be interrupted, and interrupt it from signal handler thread
11:49:01
flip214
so perhaps you'll need to "inject" calling some cleanup-code, that cleans up the caller chain
11:58:40
ogamita
or any other non-local exit destination: a block with a closure to return to it, a catch with an object to throw at, a handler with a condition to signal to.
11:59:56
ogamita
drmeister: sigint can be distributed to any thread by default. If another thread is interrupted, you will have to "go over" the thread you want to debug. Take this into account.
12:05:52
drmeister
I can't unwind to a restart established around the loop from an interrupt handler. It has no way to properly unwind the stack and call destructors when interrupting execution at an arbitrary point.
12:06:14
drmeister
It's a fundamental incompatibility between C++ exception handling and unix signal handler.s
12:07:33
flip214
drmeister: to interrupt a thread, set its instruction pointer to a cleanup function that knows how to unwind the stack frames.
12:08:15
flip214
as you generate the code, you can control whether there's a frame pointer to help you, for example.
12:09:47
drmeister
The only way I see to deal with this is from within the interrupt handler, maintain a thread-local queue that is polled from within the loop from a safe-point, and then from the safe-point unwind the stack. It means I need to insert safe points into loops somehow.
12:12:37
drmeister
flip214: This is what I'm saying, there is no cleanup function that knows how to unwind the stack frames. Unwinding the stack in C++ is a very delicate process. It only happens from 'invoke' instructions that are like 'call' but have a second return path that goes through 'landing-pads' that know how to call destructors and unwind the stack. This is how
12:14:57
drmeister
Interrupting a thread means that after any arbitrary instruction, an interrupt can come in and the stack can be taken over by the interrupt handler. Things can be set up so that the interrupt handler returns to the next instruction, but there is no way to unwind to a frame above that because there is no way to identify an appropriate landing pad to start
12:16:25
flip214
well, how about just _killing_ the thread and running the cleanup fns in another (newly created) thread?
12:20:16
ogamita
drmeister: I don't understand why there would be an incompatibility between unix signal handlers and C++ exception handling.
12:21:05
ogamita
drmeister: Also, if you handle the signal in a specific thread, you reduce the problem to some thread-thread communication.
12:26:20
ogamita
Given the restrictions on what you can do in a signal handler, this thread would be a trampoline to dispatch and process signals.
12:27:03
jackdaniel
shka: check out src/c/unixint.d comment at the top if you are interested in details
12:46:13
drmeister
Thanks everyone for the feedback. I've been mulling this over and reading up on it for a week. I just wanted to get some input from lispers on it.
13:26:32
dwrngr
The way that letter is written I wouldn't expect anything in it to be accurate, even in 1997 :P
13:53:44
nyef
drmeister: I fail to see that C++ exception handlers and unix signal handlers are fundamentally incompatible, though I could easily see the toolset being lazy about adding .eh_frame sections for the entry frame for the signal handler.
13:55:58
nyef
drmeister: Which suggests that it might be patchable at runtime, though that way probably lies madness.
14:58:42
ogamita
gargaml: IIRC, PCL was written with such a DSL. it should be available in some git repo somewhere.
17:03:34
whoman
hi! =) i do not wish to distribute my code until my project matures. is creating executables with ECL a good way to hide the code from reversing or introspection ?
17:06:56
beach
whoman: What is your reason for not wanting your code exposed early? There are some great advantages to that, in that you will get suggestions for improvements.
17:07:03
whoman
hmm. my intuition tells me that making the lisp into C and then compiling, could really help. but it will still link with ecl.dll and run as VM, i think. i've been googling for a little bit with no clear path
17:07:55
whoman
beach, some superstition, and some nervousness. as i am completely alone in the project (not even a single person in my real life who knows anything about computers) it will aid in creativity immensely
17:08:43
whoman
i am quite sensitive and having the code even backed up on a server that is not mine (google drive, dropbox) is also something i am not sure i would like to happen to my code while i am working on it (superstitions.)
17:09:25
daemoz
whoman: I disagree that keeping your project source private will help with creativity, but that's my angle.
17:11:20
beach
I find that any efficient learning experience requires making a fool of oneself by exposing one's naive early attempts.
17:11:23
JuanDaugherty
not distributing sources is contrary to the lisp culture. Getting paid for them isn't necessarily and may be a way forward in that it causes you to retain them till they're worth something
17:12:25
whoman
daemoz, okay, fair enough. but the thing about creativity is that it is personal. consider my immediate environment as my workspace. guaranteed most if not all of it is disagreeable to what inspires your own personal creativity.
17:13:38
daemoz
whoman: well you dont' know anything about me personally so you can't really say, can you?
17:13:56
whoman
JuanDaugherty, the massively grandiose concepts of cultural impact or business economics completely aside, this is a hobby project; it is like when i start to develop feelings for a lady. i wont tell any of my friends until it actually develops into something. maybe i am easy or gullible to "jynx"ing myself.
17:14:14
JuanDaugherty
also, you realize the age demographic in this computing culture is skewed beyond the normal burnout, people here have seen stuff
17:14:32
whoman
i do not wish to hide any secret formulas. but i am not making a generic utility library. i am making something for myself only.
17:15:59
jasom
whoman: I don't know how well obfuscated code compiled with ECL is; most lisps with code compiled with e.g. (speed 3) (debug 0) aren't a whol lot more reversable than C, though the presence of the runtime means there's a debugger already there rather than having to attach one.
17:16:15
whoman
it is simply "dont read my poem until i am finished" or "dont look at my drawing until it is complete".
17:17:05
JuanDaugherty
anyway a solution would be to distribute your thing as an all-in-one with fasls
17:17:15
whoman
jasom, mhmm, true. i will leave my peace of mind right there at that then, i won't worry about uninterning debugger/eval/inspect/do- symbols
17:38:49
JuanDaugherty
most of them actually. Reconstructing from an AST works for statement oriented langs.
17:48:24
jasom
some implementations save some parts ot the code in the debug information, but declaring (optimize (debug 0)) usually stops most of that
18:08:55
otjura
I started wondering why projects such as SBCL are still being developed actively. haven't they matched the ANSI spec years ago could thus be considered complete?
18:10:27
dlowe
You can always be more correct, faster, take fewer resources, behave better with threads
18:13:43
whoman
i had just been looking at sbcl changelog to see if i want to update (im on 1.3.9 and latest is 1.3.15) and they are mostly bugfixes, performance, memory footprint, etc.
18:14:29
whoman
if simply filling in the spec was all that we needed.. there might not be multiple implementations to begin with.