freenode/#clasp - IRC Chatlog
Search
0:57:59
Bike
the translator for headerq uses the exact same function as bclasp does, compile-header-check in cmp/compiler.lsp which you saw before.
1:06:25
Bike
of course... i am using bclasp+cleavir. maybe it goes differently in cclasp proper? representationally i mean.
2:28:41
Bike
(if (cmp::typeq #'list function) t nil) does the bclasp typeq, which seems to work but only handles primitive types
2:29:21
Bike
(if (cleavir-primop:typeq #'list function) t nil) for the cclasp one (only works with cleavir compilation, obviously, so like (clasp-cleavir:cleavir-compile nil '(lambda (x) (if (cleavir-primop:typeq x function) t nil)))
2:41:37
drmeister
This isn't very auspicious (compile 'foo '(lambda () (if (cmp::typeq #'list function) nil t)))
2:48:32
drmeister
I'll generate code to handle that case. Is there any subtype of function that you want to use with typeq?
3:38:17
drmeister
There's no code for the general test - there is code for a fixnum test when I use that.
3:45:12
drmeister
headerq-instruction is the one that checks general objects by checking the header - correct?
3:45:31
Bike
i guess maybe it should test generalp first, but if there's no test at all that doesn't seem like the real problem
3:45:39
Bike
https://github.com/drmeister/clasp/blob/dev-typeq/src/lisp/kernel/cleavir/translate.lisp#L741-L746 it should hit this (and i think it does)
3:46:12
Bike
and that goes to https://github.com/drmeister/clasp/blob/dev-typeq/src/lisp/kernel/cmp/compiler.lsp#L562-L580
3:51:47
drmeister
https://usercontent.irccloud-cdn.com/file/JurTqArj/module-00007-hir-pre-mir.dot.pdf
3:52:03
drmeister
(clasp-cleavir:cleavir-compile 'isfunc '(lambda (x) (if (cleavir-primop:typeq x function) t nil)) :debug t)
4:10:04
drmeister
I didn't check - but there is only one generator for this IR and it works in bclasp
4:10:56
drmeister
It checks the tag and then the header value against the min/max header value ranges for function
4:19:23
drmeister
It's clearly being removed. For some reason llvm thinks the test will always be NIL.
4:26:36
drmeister
https://usercontent.irccloud-cdn.com/file/WiTC72Is/cfg.FN_COMMON-LISP-USER%3A%3AISFUNC.dot.pdf
5:13:25
drmeister
::notify Bike I found the problem. You need to %load the first input (header value) - otherwise you are working with an aligned pointer (address of the header) and the ptrtoint will cheerfully convert that to an i64 and fail silently.
6:14:41
drmeister
::notify Bike I'm trying to fix the generic-function test at the same time - that will take another hour probably.
7:29:36
Shinmera
I think yesterday I somehow accidentally made my chat stuff stable? I don't really know, but it seems like Colleen has at least been in there over night, which has never been the case before.
7:54:48
Shinmera
Several ones, which possibly are or are not related: 1. Connections got dropped far more often than reasonable 2. Sometimes multiple connections get dropped all at once 3. Sometimes connections get timed out but stay open 4. Sometimes connections got "half-dropped" at got the system into a state where the user object associated with the connection got lost somehow but the connection didn't.
7:55:56
Shinmera
And whenever it did happen, the logging I had on hand didn't show anything bad happening.
7:56:47
Shinmera
I think a primary issue was that sometimes connections got into a state where they start reading an input, despite there being none. Then that thread gets stuck on read-char/whatever, and doesn't notice that it's timing out.
7:57:30
Shinmera
That shouldn't technically be a problem though, as the other side of the connection should be doing a ping timing too, and should close it, which would then get the other party out of the read.
7:59:22
Shinmera
The cascading closing was related to connections sending stuff to other ones on their own thread, noticing that they're dead, and then closing themselves due to me having thought that if you notice a dead connection you can just end the current thread, rather than the connection's own thread.