freenode/#clasp - IRC Chatlog
Search
16:22:52
drmeister
The error will mean that there is no fields method specialized on that class - that doesn't tie it to the printer does it?
16:23:21
drmeister
(core:encode <something>) will fail if <something> contains a CLOS object that isn't specialized.
16:24:21
drmeister
Hmmm. What if we signal different errors if its coming from the printer vs any other context?
16:24:55
Bike
the more we tie everything up the harder it is to untie them when we want to change something.
16:25:19
Bike
that means if we change how printer errors or something work later i have to care about fixing something in the fields machinery.
16:26:31
Bike
what i think we can do is not mess with fields, do (defmethod print-object ((o chem:atom) stream) (if *print-readably* (fields print here) (call-next-method))).
16:27:17
drmeister
Ok - what if we have the fields machinery signal one kind of error and have the printer catch that and signal a cant-print-readably error?
16:28:08
drmeister
It would be: (if *print-readably* (progn (write-string "#i" stream) (write (cons (class-name (class-of object)) (core:encode object)) :stream stream))
16:30:02
drmeister
Here - I'll put it together and we can look at it and change it again - what I'm suggesting is really quick to do.
16:47:31
drmeister
I'm pretty certain this is what needs to be done on the C++ side - we can continue the discussion on what to do on the Common Lisp side later.
16:48:57
drmeister
What this really is is the core:encode/core:decode facility that is built into clasp - this just extends it to CLOS objects. How we use it from the printer is up to us.
17:07:49
beach
What a terrible insult to accuse you of sounding like me. Are you sure you don't want to look around for a different job?
17:09:38
drmeister
Let me put it this way - I appreciate the wise advice to stay on the straight and narrow - I'm completely aware that I'm a bit of a chaotic force.
18:52:01
drmeister
bool fieldsp() const {return true;} just reports that the class supports the mechanism
18:54:14
drmeister
The latter is for hash tables. Ignore the 'patching' case - it's handled elsewhere.
18:55:06
drmeister
What it basically does is if the Record_sp argument is in the 'loading' mode - then the field functions create an alist of symbol/value pairs.
18:55:16
frgo
Yeah Ok. I see. What for? Transferring objects from one running lisp image to another? Something else? Persistence?
18:55:31
drmeister
If it's in a 'saving' or 'initializing' mode - it takes an alist and fills slots with it.
18:56:25
drmeister
I didn't want to write a lot of serialization/deserialization code for all the things I need to save/load
18:57:26
drmeister
frgo: Yes - I'm looking for something that is good enough and that handles circularity.
18:58:59
drmeister
The current fieldsp/fields approach has been working fine and now that I'm extending it to CLOS objects I think it will be adequate.
19:00:17
Bike
i don't know what to do about this crash. it only happens when i compile something with a nonlocal exit, but the crash looks like a nonlocal exit is actually happening, and there's no compiler in the backtrace
19:15:36
drmeister
The first two macros are core macros to support the fields interface - at the bottom is an example
21:48:41
shiho
drmeister: I got the error "chemInfo.cc:544:24: error: no member named 'matches' in 'chem::ChemInfoNode_O' if (this->_Left->matches(root, atom))"