freenode/#clasp - IRC Chatlog
Search
15:00:15
drmeister
I'm stuck at home because we had a bad storm yesterday and my train line is down.
15:00:45
drmeister
I was on a train last night when they shut the line down - we stopped and then reversed back into the train station. I've never experienced that before.
15:04:47
drmeister
ACTION notes that while his keyboard can generate an 'å' with Option-a, it cannot generate an 'o' with two dots over it.
15:06:33
beach
Anyway, great discovery by no-defun-allowed today. I was up to 15 minutes on the 4 current phases of SICL bootstrapping. But I have my OPTIMIZE qualities by default to DEBUG 3 and SPEED 0. With the default SBCL settings, it takes 1/10 of that.
15:06:48
drmeister
I'm thinking more and more about scymtym's idea of (<tab> *something*) for autocompletion. I know it would be hard - but I would really like that feature.
15:08:42
beach
stassats: This is the first time I notice that huge a difference though. It would be fun at some point to understand what the difference is.
15:09:43
drmeister
Shinmera: The idea was to fill in the function name given just the arguments - and it was actually supposed to look like ( *something* <point>
15:10:05
drmeister
Then it would give you a sorted list of things that make sense in the first position of the form.
15:10:41
Shinmera
I don't really understand that myself. How would you know what arguments your function takes but not the name?
15:10:46
stassats
i think the only thing debug 2 really does is preserving variables, generated code wise, the rest is just better debug info computation
15:11:52
drmeister
I'd like to know what methods would apply with a *something* object as the first argument.
15:13:57
Shinmera
I think he wants what's usually done in C++/Java etc where you get "methods of a class"
15:16:08
Bike
yeah, we have the specializer-direct-methods and such set up properly, since we need them in fastgf
15:16:37
drmeister
who-calls, who-binds, who-sets, who-references, who-macroexpands, who-specializes-directly
15:22:49
drmeister
Every time I sit down to write chemistry code in the jupyterlab/slime interface I get frustrated with the disconnect between the environment I want to be working in and the incomplete environment that I have.
15:26:36
drmeister
I have so many classes and these complicated objects - I know there is a way to get a molecule from a 'conformation' object - I just don't recall how.
15:27:59
drmeister
I guess we would need to know what type a function returns - we get that from C++ but in Common Lisp it will all be T
15:29:38
Bike
i forget if we actually store ftypes yet. i did some work for it but don't recall how much i hooked it up
15:31:53
drmeister
Bike: While I have you - this (de)serialization thing - could we resolve what needs to be done there? I see a way to support CLOS objects by adding a 'fields/fieldsp' pair of methods to Instance_O. It's not going to be safe or handle versions unless we can come up with a simple solution to that.
15:32:09
drmeister
I thought I'd serialize the class name, the number of slots and a vector of slots.
15:33:46
Bike
i'm really not sure that we should define a readable print-object for standard-object.
15:34:37
drmeister
Why isn't it a good idea? This isn't a challenge - I want to know what you think the downsides are.
15:36:19
Shinmera
using a custom pprint table for when you do need to do this is less invasive and more customisable in my opinion
15:36:32
Bike
i think what we could do is provide an extension function to print a standard-object with #i syntax, and then we can define print-object methods for cando objects to call that function.
15:36:56
Shinmera
The other thing is that you can't always recreate instances from the data in their slots
15:38:58
Shinmera
Or put another way: classes and instances thereof are a part of a user-defined protocol that you can't generalise
15:40:34
Bike
there is no doubt that we can, in some sense, serialize objects with slots, but that doesn't mean we ought to
15:41:55
drmeister
Sure - but what should I do for those classes that I really want to serialize - that I design to be serialized? Maybe I should have the C++ method 'fields' invoke a generic function that the user specializes and that works like 'fields'?
15:43:47
drmeister
print-object doesn't do everything that 'fields' does. 'fields' handles generating key/value pairs for slots and taking a collection of key/value pairs and filling in slots.
15:44:14
Bike
print-object doesn't do anything. i'm saying we DEFINE METHODS for the cando classes that use fields or whatever.
15:48:30
Bike
We're talking about how we can get the Lisp printer to output some readable representation of a chem:atom or suchlike, right?
15:50:05
Shinmera
drmeister: As I said, you can create your own pprint table that has an entry to serialise your (or all) instances however you want
15:50:38
Bike
i don't know if pprinting would be good for this. i mean, we want readability first off
15:51:54
Shinmera
Maybe, but the pprint tables give you an off-the-shelf easy way of specialising printing behaviour
15:52:31
drmeister
No - we already have a way to have the lisp printer output a readable representation of a chem:atom.
15:55:58
drmeister
I kinda thought they were but now I realize that they weren't and this is the first time it's come up.
15:56:24
Bike
and what i'm saying is that the way to do that is to define appropriate print-object methods, that use core:encode or whatever to put out some #i thing.
15:56:26
drmeister
Everything I've (de)serialized until now have been C++ objects with 'fields' methods.
16:01:21
drmeister
I think that's not quite what I'm looking for - I think the way to do it (in conjunction with what I currently have) is to define a 'core:fields' generic function and a C++ Instance_O::fields virtual method that invokes it. Then you add methods like (defmethod core:fields ((object foo) record) when you want to (de)serialize objects of the 'foo' class.
16:03:12
drmeister
Ours does. That's what you get when the object passes the fieldsp test here: https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/clos/print.lsp#L308
16:04:11
drmeister
I guess we could implement a print-object method for each class that does the same thing - generate a '#i' string and invoke encode.
16:06:27
drmeister
Not yet. I have to define a 'Instance_O::fieldsp' method. It could return true iff there is a method specialized on the class.
16:07:38
drmeister
Is there a quick way to determine if a generic function specializes on a particular class?
16:09:56
Bike
Then whatever you want to put in to check whether there's a core:fields method on a class would return that that default method is specialized
16:10:07
drmeister
Yeah - that would work. Instance_O::fieldsp() const {return true;} Instance_O::fields(Record_sp node) { return core::eval::funcall(core::_sym_fields,this->smartPtr(),node);}
16:10:50
drmeister
If there is no specialization for core:fields - then it will signal an error - no problem.
16:13:01
drmeister
I'd say that you are on your own in that case. It's not a situation that should ever arise.
16:14:39
drmeister
No - you need to pass it a Record_sp object - those aren't things that regular folks should be messing with.
16:16:10
Bike
I don't want to design this so that when we decide to do something else in a month we have to come up with a new design.
16:17:01
drmeister
I need a facility to (de)serialize CLOS objects alongside C++ objects. One that has some reasonable level of safety.
16:17:43
Bike
if there's a possibility of doing that I don't want to tie the function to the printer.
16:19:11
drmeister
I don't know why I tied it into the printer and reader - it seemed like a good idea at the time.
16:19:37
drmeister
https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/clos/print.lsp#L308
16:20:03
Bike
I mean this error thing. That's saying, fields will only ever be called from the printer.
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))"