freenode/#clasp - IRC Chatlog
Search
14:21:05
drmeister
I discovered that my dispatch functions drop one call history entry under some yet unknown circumstances
14:21:37
Shinmera
That sounds like it might be a bad push somewhere, or forgetting to increase the fill-pointer.
14:39:56
drmeister
There's no concurrency - and yeah - it's a corner case somewhere. It has an optimization step that coalesces ranges of stamps. I'm turning off fastgf and rebuilding so that I can experiment with the dispatcher compilation
14:40:10
scymtym
drmeister: i had a decision tree generator (from working on a pattern matcher/parser) and wrote my own code using that
14:42:33
drmeister
The method requires that objects contain unique integer stamp values and that classes write this stamp into newly allocated objects.
14:43:08
scymtym
instance objects reference layout objects. i use the layout object as whole as a replacement for the stamp
14:43:57
scymtym
the immobile-space variant of sbcl keeps layouts at fixed address, so the respective layout address can be that integer
14:45:18
drmeister
So - instances point to their layout object? You can identify obsolete instances in that the layout object they point to is different from the layout object for their class?
14:46:34
scymtym
i haven't tried that, but i think i would remove obsolete layouts from call histories so that the corresponding instances get trapped
14:51:03
scymtym
btw, an initial version of the code is at https://github.com/scymtym/dispatch-experiment . since then if have added and not yet pushed dispatch on "lowtags" and "widetags"
15:00:44
drmeister
I'd need more context - the only reason I can see that it can't parse bitcode is if somehow you used the system clang when it should have used the externals-clasp one.
15:02:10
drmeister
Bitcode with errors often can't be read by anything - they aren't fault tolerant at all.
15:02:38
drmeister
At that point I set things up to write the .ll files for the module as they are generated - that's a bit involved
15:03:08
drmeister
Ok, then there is bad llvm-ir in there and we need to generate the .ll file instead of the bitcode to figure out what it is.
15:06:06
Bike
so, i could have generated bad code that still passes whatever and is output to a file, but then the loader refuses it?
15:07:10
drmeister
I've run into this several times. The only way I've found out is to write .ll files. We can read those and run them through llc and opt on the command line.
15:34:42
robink
ebuild pull request ('dev-ebuild' branch of https://github.com/Haifen/clasp, single commit) submitted.
15:51:44
robink
drmeister: Once 'dev' builds cleanly I'll submit an ebuild bug (with the last-known-working ebuild attached) to bugs.gentoo.org.
16:48:20
drmeister
::notify Kevslinger Tomorrow (Sep 15) The Cassyny probe is going to crash into Satyrn after thyrtyyn years in spyce.
17:04:03
Bike
slime compilation wrote out a temporary .bc, and said it wrote a temporary .fasl, but it's not actually in the system
17:20:33
Bike
the problem is the bit aset, but it works in the repl. i don't know what's going wrong.
17:37:32
Bike
i mean, i don't know how. the disassemble output looks okay, insofar as i can understand it. i think the array access actually ended up properly as a gep
17:40:27
drmeister
So you would like to write out .ll files instead of .bc during the build process?
17:41:28
Bike
unless you have a better idea. i don't know what's happening beyond fasls not being produced.
17:41:50
Bike
which i'm guessing is due to something seeing that it can't read bitcode and going "oh, well, better just return normally as if i really did write out a fasl then"
17:43:16
Bike
it's a perfectly good clasp, except if you use this one primop in the wrong way this happens
17:44:35
drmeister
Try this - bind cmp:*compile-file-debug-dump-module* to T around the COMPILE-FILE
17:47:34
Bike
well, wait. now i don't know what's happening. if i move the errant definition to a file it compiles and loads! but with C-c C-c in a buffer it gives the error
17:49:05
drmeister
I don't know - I'd like to look at an .ll file that is generated in place of the .bc file that is bad.
17:50:50
drmeister
What that variable (or a slightly different debugging setup) is supposed to do is write out .ll files for intermediate stages of the build. Incomplete modules can be written out just fine.
17:51:33
drmeister
Or run 'opt' or 'llc' on them. They usually point out the problem if there is one.
17:54:02
Bike
"; Function Attrs: nounwind" "declare void @cc_simpleBitVectorAset({}*, i64, i32) local_unnamed_addr #1" seems okay
17:56:36
Bike
as does "%aset = call void @cc_simpleBitVectorAset({}* %farg0, i64 %untagged-offset, i32 %untagged-value)"
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.