freenode/#clasp - IRC Chatlog
Search
16:24:50
[1]ringer1
drmeister, saw the talk to LLVM devs from a few weeks ago, excellent, hearing you speak always leaves me wanting to hear even more.
16:27:11
scymtym
Bike: drmeister: does clasp use ECLECTOR.READER:{FIXUP,WRAP-IN-*}? i would like to make those consistent with the rest of the protocol (which requires lambda list changes) as i document and test them
16:29:37
drmeister
Bike: When compile-file compiles literals - maybe we could take the literal vector and write it out using the fields/(de)serialization protocol.
16:36:03
drmeister
We have this facility built into clasp for serializing complex objects. C++ classes have a 'fields' method that serializes and deserializes objects. It works with the CL printer and handles circularity.
16:43:48
drmeister
The literal table that we generate - can we just write it out and then read it back in?
17:45:03
drmeister
Ok - so when we compile-file code we get this object that describes the constants/literals
17:46:57
drmeister
It's a linear sequence of instructions to invoke functions that create objects at the index indicated right after LITERAL-NODE-CREATOR
17:47:26
drmeister
#(LITERAL::LITERAL-NODE-CREATOR 0 "ltvc_make_nil" "NIL" NIL) --> Puts NIL at position 0 of a vector of constants/literals/roots.
17:49:54
drmeister
It then puts the string "ERROR" at index 2, string "COMMON-LISP" at index 4, looks up the package "COMMON-LISP" using the string at index 4 and puts it at position 3, interns the symbol COMMON-LISP:ERROR at index 1 ...
17:50:41
drmeister
So I guess the idea is we run this little program at compile-time and serialize the vector that it creates?
17:54:25
drmeister
There are funcalls in there as well - top-level forms and load-time-values - but they all run in the top level environment - so I should be able to move them out.
18:03:26
drmeister
Yeah - could that work? We run the literal-node-creator program at compile-time and serialize the resulting literal/constant vector. We would move the funcalls out of the code and they would run after the literal vector is initialized.
18:14:49
drmeister
A simple first test would be to pull the LITERAL-NODE-TOPLEVEL-FUNCALL's to the end - if it still worked - then the LITERAL-NODE-CREATOR's can run independently of the LITERAL-NODE-TOPLEVEL-FUNCALL's and they could be run at compile-file time if we can figure out how to serialize the result in a more compact form.
19:30:19
drmeister
I think I'm coming around to what you are suggesting. When we compile-file build this list of instructions that is then compiled to code that constructs the constants/literals table.
19:30:50
drmeister
I think I can construct the constants/literals table at compile-time and then I just need to figure out how to serialize it and de-serialize it.
19:31:52
drmeister
It might be simple as printing the table and reading it - but I'm not sure about that yet.
19:39:27
drmeister
Nvidia's stock dropped 20% yesterday - I suspect it's because hardly anyone showed up at my talk.
19:45:56
drmeister
That's not causality - it's coincidence. They've got way too many people focused on fads.
2:41:21
drmeister
Ok - I implemented stassats' suggestion. In small tests it drops the amount of code by 20%
3:32:51
drmeister
Now there is a big string that contains a printed vector that is read at load time and used to initialize the literals table.
3:34:13
drmeister
The objects that use the #'ltv/readable are printed into the string and everything else is initialized as it was before.
4:17:29
drmeister
When I load aclasp I get the following error - it's new because of the new way I'm initializing literals.
4:21:33
drmeister
So - I need READ to read the symbol and intern it? Maybe I need to print them all as internal symbols.