freenode/#clasp - IRC Chatlog
Search
18:25:14
Bike
stuff like "CL_DEFMETHOD List_sp function_declares() const { return this->declares(); };"
19:49:57
drmeister
Bike: I think it's just an object I used to represent a closure (in the NIL environment) to a C++ function
19:51:59
drmeister
Bike: If we had a way to compile classes and instances into fasl files then we could store AST's for inlining in fasl files - right?
19:55:38
drmeister
That would just require an ltvc_make_instance and ltvc_set_instance_ref function - sort of like these for arrays: https://github.com/clasp-developers/clasp/blob/dev/src/llvmo/link_intrinsics.cc#L239
19:56:52
drmeister
Or we set up the rack as a simple-vector and then use ltvc_make_instance to create an Instance_O object, set the rack and set the stamp.
19:59:10
attila_lendvai
how do you decide what to do when an instance (or array for that matter) points to another instance that is not being saved into the fasl? IOW, how to you cut the serialized subgraph and then reconnect it at load time?
20:00:14
attila_lendvai
when we worked on hu.dwim.serializer this was the part that required the most attention
20:01:59
attila_lendvai
Bike: but that means that objects may lose identity and get replicated if two separate nodes of the same (potentially large) graph is saved in separate fasl's. in extreme cases that can mean huge graphs are replicated in each fasl.
20:02:41
drmeister
attila_lendvai: We solved that problem with arrays and cons cells. We create objects before they are put into objects that reference them. There is also circularity detection.
20:02:45
attila_lendvai
but it's essentially the same problem with arrays if they contain references to other arrays, potentially forming a large graph
20:04:42
drmeister
I think we can do this - we just need to add support for instance objects to cmpliteral.lsp
20:05:13
attila_lendvai
drmeister: that helps when saving one fasl. but what if another fasl is being saved that wants to store a literal instance that is another node of the same graph in memory. when the two fasl's are loaded they will load the same graph twice into the memory. if the user code relies on singletons or consistent caches or somesuch, then such a fasl save/load can disrupt those
20:05:41
Bike
probably we can have make-load-form-saving-slots return magical forms that cmpliteral knows how to deal with
20:06:55
attila_lendvai
I suggest to introduce safeguards while working on this mechanism, so that users can turn on/off, and/or customize the saving of literal instances and arrays.
20:07:24
drmeister
We could also limit this facility to building clasp at first and then extend it to general fasls later.
20:08:33
attila_lendvai
Bike: I'm only talking about turning off saving literal arrays and instances
20:09:45
drmeister
I'm not sure that there is a problem. The fasl files that we generate now come from compiling lisp source code. I don't see how you could run into this problem.
20:09:57
attila_lendvai
Bike: to send an error/warning for stuff like: (defun foo () #.*some-clos-instance-pointing-into-a-large-and-complex-graph*)
20:11:08
Bike
and i don't really get the point, i mean, if you're throwing a literal object into a fasl you know what you're doing enough to write a make-load-form method and all
20:11:24
attila_lendvai
I did run into sbcl throwing an error when I tried to save a literal instance a few times, and it was always due to some confusion on in some of my macros
20:14:28
attila_lendvai
oh, and now that I recall, it was mostly when trying to save lambda's. clos instances have the m-l-f with a sane error message when unimplemented. so my concern is mostly with arrays forming a graph, but... maybe I'm overblowing it, and people just need to learn what they are doing.
20:31:55
drmeister
If we just focus on the build system for a moment. (1) We keep track of classes that are created during compiling the cclasp source code.
20:32:50
drmeister
(2) We generate a bunch of RUNALL commands that are run before anything else and create all of those classes.
20:35:57
Bike
also have to make sure the make-load-form methods for ast classes are setup right, i guess.
20:48:37
Bike
Not really. make-load-form has specified behavior on classes. We'd have to do something magical.
20:52:20
drmeister
Yes, IIRC rawRef_() returns a reference to the contained pointer and raw_() just returns the contained pointer.
21:08:38
drmeister
I'm having to compile things over and over and over again to bring the new joint-tree code online.