freenode/#clasp - IRC Chatlog
Search
19:28:36
drmeister
My problem appears to be when a class is redefined the generic functions that have specializers in entries in their call history are not getting those entries cleaned out - they should be. They are cleaned out in small test cases.
20:06:34
Bike
inling float arithmetic seems to speed it up three times or so, even before box elimination
20:08:12
Bike
i guess i'll implement some more instructions/etc for coercing fixnums to floats and such
20:09:46
drmeister
ACTION has been itching to break that stuff up into little functions that can be inlined.
20:45:27
Bike
hm i need to ask beach about some instructions in cleavir he probably hasn't had occasion to think about for years
20:51:46
Bike
drmeister: if i want to export symbols from CORE, how should i go about that? i've already added, like, five special operators in the course of this array shit
20:53:12
drmeister
Lower down I initialize their values where you see all the _sym_foo->defparameter(...);
20:57:12
Bike
it's not high priority or anything. just means i have (core::%displacement ...) and stuff around
20:57:20
drmeister
If they are special operators then there is stuff like special-operator-p that needs to know about them.
20:57:46
drmeister
Since I'd like to smarten up the aclasp and bclasp compiler - I think it behooves us to put them in the corePackage.cc file.
0:41:39
drmeister
This way that I use to identify all generic functions that may need their call-history edited when a class changes...
0:41:40
drmeister
https://github.com/drmeister/clasp/blob/dev/src/lisp/kernel/clos/closfastgf.lsp#L453
0:42:04
drmeister
https://github.com/drmeister/clasp/blob/dev/src/lisp/kernel/clos/closfastgf.lsp#L450
0:44:43
drmeister
The call-history entry of INITIALIZE-INSTANCE that specializes on PRETTY-STREAM and every subclass of PRETTY-STREAM needs to be removed from INITIALIZE-INSTANCE's call history.
0:45:17
drmeister
I thought that code would provide a list of generic functions that needed to be edited like this - but it doesn't.
0:46:20
drmeister
It will miss INITIALIZE-INSTANCE because INITIALIZE-INSTANCE only has a method on T and not PRETTY-STREAM or any subclass.
0:51:38
Bike
wait, but if it only has a method on T then redefining pretty-stream doesn't matter to it.
0:58:41
drmeister
I need to remove the INITIALIZE-INSTANCE call-history entry for any previous calls where a PRETTY-STREAM was passed to INITIALIZE-INSTANCE because ...
1:00:13
drmeister
It's not a bad idea because it will generate a dispatch-miss the next time and be added back.
1:01:21
drmeister
Right - because redefining the class means that probably the effective-method-function for INITIALIZE-INSTANCE when passed a PRETTY-STREAM should be re-evaluated.
1:02:04
drmeister
Right, it contains a history of all actual specializers (and satiated ones) passed to the generic function.
1:03:19
drmeister
I could check all generic-functions and edit their history. But I'm trying to do this more efficiently and get the subset of generic-functions that may need to be updated and avoid the ones that absolutely won't need to be updated.
1:18:17
Bike
well, actually, wait. when you redefine a class, the new class will have a new stamp, and all instances with the old stamp will be obsolete, right?
1:19:53
drmeister
INITIALIZE-INSTANCE has a call history entry with the selector for PRETTY-STREAM with stamp 851
1:21:29
drmeister
The dispatch function for INITIALIZE-INSTANCE isn't updated because it isn't included in the list of generic functions that were updated when the change class happened
1:21:52
drmeister
Then INITIALIZE-INSTANCE with a fresh instance of PRETTY-STREAM, with the stamp 2021
1:22:23
drmeister
The dispatch function triggers a dispatch-miss because it's expecting 851 - it doesn't know anything about stamp 2021
1:23:31
drmeister
The dispatch-miss generates a new effective-method-function and calls the function that updates the call history but that immediately returns because the call history still contains an entry with the selector for PRETTY-STREAM -
1:24:40
drmeister
The last part? "The dispatch-miss generates a new effective-method-function and calls the function that updates the call history but that immediately returns because the call history still contains an entry with the selector for PRETTY-STREAM - "
1:25:43
drmeister
No - the call history is classes (specializers, specializers - I started saying selectors again) and eql-specializers
1:25:59
drmeister
I have this function for updating a call history: clos__generic_function_call_history_push_new
1:26:23
Bike
it seems like that's conceptually the problem then - the dispatcher and the call history are tracking different things.
1:26:31
drmeister
It returns false if a new entry isn't created in the call history. I won't create an entry if there is already an entry with the same selectors.
1:27:35
drmeister
Well, yes, that's why I invalidate these generic-function dispatch functions when I redefine a class.
1:27:57
drmeister
The call history is definitely selectors keys and effective-method-function values.
1:29:04
drmeister
You invalidate the generic-function with dispatch functions any time the call history and the dispatcher might get out of date - like when you redefine a class.
1:30:10
drmeister
I haven't thought it through - but beach was very clear on that point. It's specializers. So I never gamed it out.
1:31:14
drmeister
I imagine update of the call-history would be tricker. If you redefine a class you have to remove call history entries that contain the old stamp and add ones that have the new stamp...
1:32:30
drmeister
I don't think it would change my current problem - which is to identify the subset of generic functions that may have their call-histories edited because of a redefined class and that will have to be invalidated because of a redefined class.
1:32:57
Bike
i mean, you could just leave the old stamp around, and the invalidated dispatcher would probably compute the new call history entry, i figured.
1:34:00
drmeister
No - that's not how I understand things to work. An invalidated dispatcher does nothing but compile the call history into the new dispatcher - while completely avoiding generic function calls.
1:36:08
drmeister
The call history is the history of all previous memoized calls - the specializer for a particular argument for a memoized call is the class - the stamp of the class might be used - but I haven't thought it through.
1:38:01
Bike
i meant that i don't know what computes call history entries, and what does so wasn't really my point
1:38:32
drmeister
Mind you, I'm not arguing - I'm just trying to hold on to what I think I understand to sort out what I think is my problem.
1:39:30
drmeister
You compute call history entries on a dispatch-miss. It constructs a key and evaluates the effective-method-function and adds those to the call-history.
1:43:09
drmeister
I'm pretty sure my problem is I'm not invalidating the dispatch function of the INITIALIZE-INSTANCE generic function when PRETTY-STREAM (which it has a call-history entry for) is redefined and the INITIALIZE-INSTANCE dispatcher tests for the old stamp.
3:00:22
Bike
minion: memo for beach: 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?
5:05:11
beach
minion: memo for Bike: 1. Sure, go ahead and add those primops/ASTs. 2. Yes, an unboxed fixnum is a raw machine integer in the range of a fixnum.