freenode/#clasp - IRC Chatlog
Search
23:28:37
Bike
"returns_twice: This attribute indicates that this function can return twice. The C setjmp is an example of such a function. The compiler disables some optimizations (like tail calls) in the caller of these functions." that's a point i hadn't considered
23:28:57
Bike
i guess you can't reuse the stack space for a tail call since the code after the second return will still want access to the frame
23:32:26
Bike
yeah ok, since returns_twice is the only annotation for this and it's only for functions... yeah, that's difficult, since you'd want the same mark for the equivalent to catch-instruction
23:35:55
Bike
i mean that returns_twice on a function is the only way llvm has to indicate that it can't do tail calls and stuff, as far as i can tell
23:36:15
Bike
so you'd need anything that checks for a returns_twice call to check for this instruction too, i guess?
23:38:16
karlosz
oh, you mean because it's just a bare instruction and not a function that you can annotate return_twice on
1:09:35
yitzi
I removed the line that executed cando in the root user and forced all quicklisp activities to be in the user account
1:12:04
yitzi
I'll have to write a custom installer or tweak cl-jupyters installer since it thinks that cando is clasp.
1:17:16
yitzi
I'm probably done tonight. I'll detangle the dockerfile and fix the kernel installer tomorrow. Just thought you'd like to know that progress is being made.
1:21:09
drmeister
It means I have to go through the whole rigamarole to set up /opt/clasp and set permissions and so on.
1:36:59
karlosz
okay, i coded up a slightly more conservative analysis for when to do setjmp that should be correct
1:38:34
karlosz
Look at every catch-instruction. Look at every unwind that uses that catch-instruction. If every intermediate function of the catch and the unwind are in call-position, there is no problem
1:39:32
karlosz
it's simple and can be improved later, but now the next step is how to actually emit setjmp and longjmp
1:41:59
karlosz
so, anything that is of the class "escaping instruction" should fall back to using c++ unwinding
1:59:20
Bike
i mean, it's the same with unwind-protect, the protection functions need to be executed on the way out
1:59:55
karlosz
i thought we were just handling the cases where we could substitute in setjmp for unwind
2:00:46
Bike
we could just stick to cases with no intervening binds or protects, that should be statically detectable
2:01:08
Bike
doing them in a different dynamic context may be difficult, the way they work now is C++-like and not amenable to it
2:52:56
Bike
also, i fixed up the ast interpreter so that it only maps the ast once, and only converts csts to asts once even when it gives up and uses the compiler
2:53:34
Bike
i'm thinking the "children" relation on ASTs may form an actual tree so we don't need to do the hash table thing for the mapping, though
3:06:30
Bike
but i don't think it's in the "children". maybe it used to be, i remember it being an issue
3:06:54
karlosz
oh, i see.i would have just expected it to be a block tag, rather than the actual full ast itself
3:10:45
Bike
i think i'll look at ensuring the AST is actually a tree, and then this hash table thing can be gone. could speed up a couple different things, really, and i don't see any need to make it not a tree
3:11:23
karlosz
yeah. though its still kinda weird that that is the problem because of how much the compiler uses map instructions with hash tables
3:12:03
Bike
doing some flamegraphs with the new system might be good. it only maps once so the time usage there should be obvious
3:12:06
karlosz
and its not like its the gf dispatch either, because ast->hir basically walks the same thing
3:18:54
Bike
could also save consing by, instead of having the CHILDREN generic function, have a MAP-CHILDREN function that doesn't cons, and derive CHILDREN from it
5:11:56
drmeister
This unwinding problem is biting me bad today - I've lost at least three hours waiting for this docker image with 18 cores! of an iMacPro to compile generated-encodings.lisp.
5:12:30
drmeister
kpoeck: It's not that your code was wrong - it was fine - we have a really bad problem with unwinding that bites us at the worst times.
5:13:12
drmeister
It's been compiling generated-encodings.lsp in this docker image for about an hour now - I'm giving up and going to bed.
5:14:05
drmeister
I don't think yitzi sees these looooooooooooooooong compilations on his docker image.
5:14:24
drmeister
And this same file on the same iMacPro in macOS only takes a few seconds to compile.
7:12:26
beach
If you are new to Lisp, I suggest you learn it first, independently of C++ integration.
7:13:30
beach
I am answering you because most Clasp developers are in the US, and asleep at this time.
7:58:35
beach
You need to wait for the developers to wake up for that. I know very little about C++ integration. I hang out here because Clasp uses the compiler of a project that I started.
7:59:39
beach
But, again, if you plan to use Common Lisp, I strongly suggest you learn it first, independently of C++. Otherwise, you might be very confused.
8:00:00
beach
The semantics of C++ and Common Lisp are very different, so the integration is nontrivial.
8:08:40
minion
kapil_: please see PCL: pcl-book: "Practical Common Lisp", an introduction to Common Lisp by Peter Seibel, available at http://www.gigamonkeys.com/book/ and in dead-tree form from Apress (as of 11 April 2005).