freenode/#lisp - IRC Chatlog
Search
4:22:32
minion
beach, memo from Bike: there are instructions for converstions between float types but no primops/asts; i was going to add them with two types so you'd write like (cleavir-primop:coerce single-float double-float x). also, there's one for "unboxed integers", does this mean fixnums with tag shifted out to take advantage of machine instructions?
4:32:10
drmeister
I should (1) identify the minimal set of generic functions that may need their call histories edited to remove entries that have selectors that match the redefined class and and remove those entries and (2) I should invalidate the dispatchers for those generic functions.
4:33:28
drmeister
I need to invalidate the dispatchers because their code contains the old stamp for the class.
4:34:07
beach
And you can either recompute the dispatcher on the fly, or you can set it so something that will.
4:34:32
drmeister
Honestly, I've been wracking my brains for hours why I might need to remove the entries from the call history - I can't recall. I also can't recall how to obtain the minimal set of generic functions that need invalidation. I was wondering if you could point me in the right direction.
4:37:38
drmeister
ensure-class-using-class calls the function that invalidates dispatchers that are effected by the class change.
4:38:11
drmeister
How does that function use specializer-direct-generic-functions given the class PRETTY-STREAM to get the generic function INITIALIZE-INSTANCE.
4:38:45
drmeister
Do I accumulate all of the generic functions that are specializer-direct-generic-functions of the class-precedence-list of PRETTY-STREAM?
4:39:11
drmeister
Because the only specializer that INITIALIZE-INSTANCE is a specializer-direct-generic-functions of is (find-class 'T)
4:39:51
drmeister
I can't recall why I was removing the call history entries - if I don't have to that is a relief and I will stop trying.
4:41:21
drmeister
As I said - I don't recall - it's just there in my code that I do it - but I wrote no comment why I was doing it. I wrote a fair amount of code to achieve it - so I assumed there was a reason. If there is no reason - then I will remove the code.
4:42:22
drmeister
That being said - it seemed harmless to remove the entries - because they would be added back in the next dispatch miss.
4:42:25
beach
Certainly, when a class is redefined so that its class precedence list changes, then whether some methods are applicable or not to a particular signature may change.
4:43:11
beach
And not only the entries for a particular class that is being modified, but also for all of its subclasses.
4:44:22
drmeister
But see what I wrote above about not finding all of the generic functions that needed to be updated when I simply append together the results of calling specializer-direct-generic-functions on the subclasses of the specializer.
4:45:12
beach
I think you need something similar to SPECIALIZER-DIRECT-GENERIC-FUNCTIONS but that keeps track of what is in the call history instead.
4:46:46
beach
I think you need a function called (say) SPECIALIZER-CALL-HISTORY-GENERIC-FUNCTIONS that takes a class and returns a list of all generic functions that specializer in its call history.
4:50:16
drmeister
Yes - that is what I need to write - I'm trying to figure out how to do it efficiently.
4:50:38
drmeister
I could search every generic function - that's a no-brainer - I was looking for something a bit more ... focused.
4:52:48
drmeister
Would that be better than calculating it on the fly? In the worst case it's a loop over all call-histories for every generic function.
4:53:24
drmeister
I can get every generic function by calling specializer-direct-generic-functions on every class - bleh.
4:54:20
drmeister
But maybe better than keeping specializer-call-history-generic-functions up to date?
4:58:28
drmeister
Nope - no reasons - just anxiety over updating state like specializer-call-history-generic-functions would require. Especially in a multi-threaded environment - every specializer will need a lock won't it?
5:03:03
drmeister
I'm just exploring options. I'm starting to warm to the idea of maintaining a specializer-call-history-generic-functions and a mutex to protect it in each class.
5:04:26
drmeister
There are only two functions that modify call histories in Clasp, one that adds to them and another that removes from them.
5:05:55
drmeister
I talked with scymtym about his implementation - he doesn't handle class changes yet. Interestingly - he doesn't use integer stamps. He uses the address of sbcl's 'layout' object in some sbcl mode where layouts don't move in memory.
5:27:04
drmeister
Well, I'm off to bed. I'll think about specializer-call-history-generic-functions and probably implement it tomorrow.
12:54:05
drmeister
What is the relationship between specializers and classes? There is a specializer class and class classes.
13:03:01
drmeister
Huh is right. Adding slots to specializer slides all of the class slots indices up.
13:41:05
drmeister
I do have it in two places - it's in C++ and it's in Common Lisp. There is a sanity check that causes the build to fail if the information gets out of sync.
14:06:18
beach
If you can make a sanity check, why can't you automatically generate one of the instances?
14:09:47
beach
A significant fraction of my time is spent coming up with techniques to avoid having a particular piece of information in more than one place.
14:11:44
beach
No, I think the opposite would be a maintenance nightmare, especially for people coming after me.
14:19:23
beach
I meant: No, I think having a particular piece of information in more than once place would be a maintenance nightmare, especially for people coming after me.
14:20:38
scymtym
ACTION thinks beach is talking about duplication in source code while ralt is talking about duplication at runtime (hence "caching")
14:21:21
beach
scymtym: You are definitely right that I am talking about duplication in source code.
14:24:43
Shinmera
In a way code duplication is like caching-- you also have the problem of knowing when to expire.
14:45:56
drmeister
It's better to specify the slots in the Common Lisp CLOS code - of course - but the C++ code needs to run loooong before the Common Lisp bootstraps up to CLOS and it needs to know where the slots are.
14:46:18
drmeister
To avoid circularity/bootstrapping problems it's easier to just bake it into the C++ code.
14:50:08
beach
But you are planning to use SBCL to bootstrap Clasp. Then you can extract that information from the Common Lisp code and generate the C++ code.
14:50:56
drmeister
The indices of standard-class slots and the number of standard-class, and structure-class slots and the layout of a couple of types are the only places where I had to do this. They all have sanity checks.
14:53:11
drmeister
We may have to do this... (1) Run the Clasp interpreter to generate a configuration file (2) Run SBCL to compile the Clasp Common Lisp code to an intermediate representation (long lists of generic function calls) (3) Run the Clasp interpreter to load and interpret the intermediate representation to llvm bitcode.
14:57:59
drmeister
We still haven't decided if we are going to use sbcl to bootstrap Clasp. There are nasty issues with environments that I'm not sure we have solutions to yet.
14:58:39
drmeister
We can save a discussion about that at a later time - Bike is more up on the details. I've had my head in fastgf for weeks.
15:16:25
beach
Though I don't think I have much to contribute. I am just asking questions that come to mind.
15:42:44
green_
ok, I have a newbie lisp package question... see here: https://paste.fedoraproject.org/paste/2nnzraEoqHCH2EdElS1~-w
15:43:54
beach
green_: When the reader sees your DEFPACKAGE form, it creates a symbol named MYFUNC in the COMMON-LISP-USER package.
15:44:43
mfiano
green_: the WHY package is using all of the symbols from CL-USER, then you are adding all of those symbols to CL-USER.
15:45:51
beach
green_: To avoid this problem, the typical solution is to use a "symbol designator" that is not a symbol in your DEFPACKAGE form.
15:47:08
beach
green_: You can also use (:export "MYFUNC"), but that looks ugly because the string needs to be upper case, whereas your function name is written in lower case.
15:50:29
beach
green_: Just use explicit package prefixes when you are in the COMMON-LISP-USER package, like why:myfunc.
15:51:56
rpg
the former is mildly preferable, in case there's any chance your code will be run in a case-sensitive lisp session
15:52:36
green_
but when I call why:myfunc I get "The symbol "MYFUNC" is not external to the WHY package".
15:52:39
beach
green_: The package system can be confusing to newbies because it is not a module system. A package does not contain function definitions. Only symbols. So as soon as a symbol is read, it is created in some package.