freenode/#sicl - IRC Chatlog
Search
4:53:52
no-defun-allowed
Do you think the object store format in CLOSOS (and the object format in SICL by extension) would be suitable for an object store running on a Unix filesystem?
4:54:05
no-defun-allowed
The main differences I can think of are that we have less control over how objects are stored on the disk (though we should hope the file system is okay at keeping everything sequential) and that the size of the store could change, so overallocating would be impolite to other users of that storage and there would need to be provisions for resizing the store.
5:07:00
beach
I don't know that any other aspect like the exact representation disk is a major obstacle.
5:10:52
beach
The EQ thing is a killer though. It will completely change the way you have to write your code.
5:12:19
beach
If you have a person P in your system, you write that person to the store, but you keep a reference to P in main memory. Later, if you read P back in, you now have two people with the same social-security number, date of birth, name, wife, children, etc.
5:12:59
beach
So your entire programming style can no longer rely on identity. And you are back in C++-style programming where copy semantics rules.
5:13:13
no-defun-allowed
Definitely. For my specific use, that isn't a problem as most of the data is immutable (we only push to one list in an object after it is created), though I think it might be salvageable using a weak hash table to make objects have EQ identity.
5:14:06
beach
Possibly. But you still have to come up with a new test for identity, to use in your hash table.
5:14:40
no-defun-allowed
If the store doesn't move objects on disk, I was thinking that using the offset into the file could work.
5:17:48
no-defun-allowed
Objects would be referenced by their offset into the file. Admittedly I've spent only about two lunchtimes thinking about this, so I'm not sure how to answer that question.
5:20:17
beach
Oh, so you have already completely changed your programming style by using offsets rather than ordinary Common Lisp values.
5:22:40
beach
I mean, you can no longer write (defclass person ((%name ... :reader name))). You need to write (defclass person ((%name-offset :reader name-offset))) and then (defun name (person) (find-object (name-offset person))).
5:22:53
no-defun-allowed
The model I had in mind was to read a whole graph in and write a whole graph out, but that does limit the size of the graphs usable to the size of the implementation's heap.
5:23:36
beach
Oh, that changes everything. If you always start with a fresh Common Lisp invocation and then read in a graph, you are fine.
5:24:00
beach
That's what I do for many things like the accounting software you looked at as a model.
5:24:59
no-defun-allowed
Then a reader would work, but find-object could reel in a lot of information that the client might not be interested in.
5:32:30
no-defun-allowed
A while ago I tried an experiment to see how many objects referred average object had in a Lisp image. I think I will write something similar to that.