freenode/#clasp - IRC Chatlog
Search
14:34:15
drmeister
Up until now we've been relying on undefined behavior of the linker and static constructors in C++ and getting away with it.
14:34:41
drmeister
Now I pass an integer along with the startup function and the integer/startup functions are sorted before the functions are invoked.
14:35:58
drmeister
So the C++ static constructors can run in any order during dlopen or executable startup but then when the lisp code is supposed to start the integer/startup functions are sorted and then invoked one at a time in order.
15:50:11
drmeister
Bike: I think hoisting the AST's needs to be done in serial mode as well. I was doing it in parallel - but that is leading to some form compilation in the threads and that is leading to problems.
15:59:04
drmeister
Now I'm worried that this is going to interact poorly with the literal compilation.
16:07:48
drmeister
I don't have all the details in my head though - I may be wrong. I'll try with hoisted asts.
16:09:43
drmeister
Hoisting ast's though - that involves form compilation for load-time-values - right? I see it in the backtrace so I'm pretty sure it's a general thing.
16:10:34
drmeister
They get compiled in the top level environment - so I if I did do it in threads - the environment isn't a problem.
16:12:54
drmeister
Does that mean something other than that they are compiled in the top level environment?
16:16:41
drmeister
I have a lot of compiler functions that take an environment as a parameter - I always think of the top level environment being what I get when I pass NIL as the environment
16:18:02
drmeister
For Cleavir I define a *clasp-env* that I pass in place of NIL - that's also the top level environment.
16:20:17
drmeister
I may need to switch back to hoisting in threads - my current problem may be a simple issue of the threads that translate ast's needing to communicate back to the main thread about problems like unknown global function references.