freenode/#clasp - IRC Chatlog
Search
4:29:44
drmeister
Yes - I am. I'm trying to understand the concept. It's an instance that stores a function pointer that you can call - that's it - right?
4:30:50
beach
The fact that it is a function means that it has a reference to some code and another reference to the static environment.
4:34:30
beach
The code does not have access to the function object (or the funcallable standard object if you like) unless you explicitly close over it.
4:35:40
beach
Oh, and very important, set-funcallable-instance-function does not store the function argument in the funcallable object.
4:46:06
drmeister
I'm afraid to ask questions because I'm multitasking - I'm writing a proposal and I'm reimplementing our interface to C++ methods using our funcallable-instance class. I think I violate some of the things you say above.
4:48:11
beach
Well, nothing prevents you from having a particular subclass of funcallable-standard-object that contains an indirection to a function. It is just that you would not have your Common Lisp system work like that by default.
4:51:42
drmeister
I'm doing implementation specific stuff here to improve how we call C++ methods - it is working - but I'm going to want to float it past Bike and karlosz to review it.
4:52:47
beach
Speaking of which, every SICL function is an instance of some subclass of FUNCALLABLE-STANDARD-OBJECT. That way, I can use the CLOS machinery on ordinary functions.
4:53:06
drmeister
At some point I want to make these use the fast generic function dispatch compiler.
4:56:30
beach
I take it the proposal is a separate task and has nothing to do with calling C++ methods, yes?
5:00:48
drmeister
In the past four months we have expanded our ability to synthesize our molecules by about 100x using automation and large scale contract synthesis.
5:01:39
drmeister
We've made about 400 large and complex molecules out of a space of billions. More than 90% led to useful amounts of product.
5:03:46
drmeister
We are asking for funds to run them through a panel of assays to evaluate their drug properties. To ask the questions "Do these molecules, in general, have good drug properties".
5:05:27
drmeister
Cell permeability, blood plasma stability and half-life, plasma protein binding, liver microsomal stability, general cell toxicity, general solubility.
5:05:59
drmeister
It costs about $40,000 to contract a company that does this sort of thing to run 20 compounds through a panel of assays.
5:06:39
drmeister
We want to hire these folks to do the assays - they have a good reputation and are used by a lot of drug companies: https://www.cyprotex.com/
5:07:20
drmeister
These tests are used at the very early stages of drug development to assess how likely a molecule is to become a drug.
5:07:57
drmeister
For instance - if a compound doesn't get absorbed in the gut - then there is no point in putting it in a pill. It's a non-starter.
7:56:39
drmeister
::notify Bike I eliminated a lot of the old single dispatch generic function machinery including the cache. No more ECL cache. My dispatch method is a little squirrely because I often only use DEFMETHOD for a base class and derived classes need to be recognized.
14:44:19
beach
I am redoing the bootstrapping procedure for the third (and last) time. It is now using much more production code and much less bootstrapping-specific code.
14:46:49
beach
Step 1. Create host classes in a first-class global environments that have SICL names like standard-class etc.
14:47:23
beach
Step 2. Instantiate those to create bridge objects, pretending that some of them are classes and some are generic functions.
14:47:53
beach
Step 3. Use bridge classes to create ersatz objects with the same shape as final SICL objects.
14:48:34
beach
Step 4. Load the rest of the system to create a graph isomorphic to the one in the SICL executable.
14:58:03
Colleen
Bike: drmeister said 17 hours, 23 minutes ago: - I think I can do anything I want in with the FuncallableInstance_O objects that describe single dispatch generic functions and we can fix them up later. I'll create a rack of whatever size I need and store whatever I need within it. I'll make the entry point a function that knows how to dispatch with whatever is in the rack. I'll keep a list of these single dispatch generic functions so we can fix
14:58:03
Colleen
Bike: drmeister said 7 hours, 1 minute ago: I eliminated a lot of the old single dispatch generic function machinery including the cache. No more ECL cache. My dispatch method is a little squirrely because I often only use DEFMETHOD for a base class and derived classes need to be recognized.
15:11:05
drmeister
Bike: I implemented that single-dispatch rewrite - it was mostly ripping out code.
15:14:46
Bike
i already have a bunch of non-gf funcallable instances used for clos in things. it's kinda neat
15:15:04
drmeister
I did do something that I wasn't really happy about - but the performance looks good. Can I run it past you?
15:15:57
drmeister
It's how I did the dispatch. Each single-dispatch generic function is implemented as a FuncallableInstance_O. I point to the single_dispatch_entry_point C++ function.
15:16:40
drmeister
In the rack I store a ComplexVector_T_O that has alternating class followed by a SingleDispatchMethod_sp pointer.
15:17:07
drmeister
Every DEFMETHOD adds a pair of entries to this table. The receiver class and a method.
15:17:50
drmeister
When you call one of these functions - it gets the class of the argument that it dispatches on (most cases the first argument - but in a few cases the second argument).
15:19:11
drmeister
Now - the problem: in the clasp code - there are lots of places where we declare a DEFMETHOD for a base class but not derived classes - but we expose the derived classes to Common Lisp.
15:20:06
drmeister
The single dispatch generic functions need to handle the derived classes. In C++ the methods are 'virtual' and they overload the base class method.
15:20:58
drmeister
I walk the class-precedence-list of the argument class and look each parent class up in the method table.
15:22:11
drmeister
Ultimately I want to expand the method table to include all valid derived classes (sort of satiate it) and then compile a discriminating function using our fastgf code.
15:25:21
drmeister
I thought I might run a pass over all of the single-dispatch generic functions and sort of satiate their method tables by adding all derived classes of whatever classes is in the method table. These are static C++ methods - they aren't as flexible as generic function methods.
15:26:36
Bike
i suppose dispatch overhead is probably pretty small compared to everything llvm is doing
15:29:13
drmeister
Yeah - when I profile it 1. Calls to single dispatch generic functions are a lot cleaner now. 2. There is no visible overhead.
15:29:47
drmeister
This allowed me to rip out the cache.cc contents and a lot of SingleDispatchXXX classes.
15:32:40
drmeister
I figure with the method table we can compile up a discriminating function and install it.
15:34:03
drmeister
I've stripped down SingleDispatchGenericFunction_O to a stub and I use that to define the _Class of the FuncallableInstance_O
15:35:22
drmeister
It is starting to dawn on me that I will have a bit of a problem with image save/load to link all these function pointers up.
15:36:51
drmeister
It's a linking problem to link C++ functions and methods in the executable to GC managed objects.