freenode/#clasp - IRC Chatlog
Search
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.
13:52:29
Colleen
Bike: drmeister said 8 hours, 39 minutes ago: 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.
13:52:29
Colleen
Bike: drmeister said 7 hours, 37 minutes ago: I'm trying to fix the generic-function test at the same time - that will take another hour probably.
13:52:29
Colleen
Bike: drmeister said 7 hours, 37 minutes ago: I'll finish it in the morning. Too tired...
14:32:49
drmeister
Bike: I need to detect at compile time if a typeq is for function so that I can generate the additional code to check if the object is an Instance_O and then if obj._isgf != 0
14:37:16
drmeister
I don't quite understand the "nothing to detect". In compile-header-check I need to know if the check should be against 'function', 'compiled-function' or 'generic-function' (are there any more)?
14:38:50
drmeister
So we can have a compile-header-check-function? Maybe with an argument to handle the subtypes?
14:40:58
drmeister
How about (compile-header-check-function function-type object-raw then-br else-br)? where function-type is 'function, 'compiled-function or 'generic-function ?
14:41:40
Bike
also for generic-function i'd just expect it to work like checking any instance's class, is that not viable?
14:42:08
drmeister
'function checks the entire range of header-values and then checks if the header-value matches that of Instance_O and if so checks the obj._isgf!=0
14:42:46
drmeister
'compiled-function checks if its one of the compiled function header-values (there may be only one, maybe two)
14:43:08
drmeister
'generic-function checks if the header-value is that of Instance_O and that obj._isgf != 0
14:43:31
Bike
by the way, i mentioned this before, compiled-function not including generic functions is wrong
14:44:07
drmeister
'compiled-function checks if its one of the compiled function header-values (there may be only one, maybe two) or if the header-value is that of Instance_O and that obj._isgf != 0
14:45:19
Bike
the main thing i want to check is function. leaving off subtypes for later is probably fine.
14:51:49
drmeister
That would put the header value for FuncallableInstance_O right after that of Instance_O
14:52:53
drmeister
You wouldn't be able to CHANGE-CLASS between a regular instance and a funcallable-instance - is that an issue?
14:53:54
drmeister
CLOS initializes a new instance and then copies the rack into whatever you give it.
14:57:09
Bike
if you want to be able to access instances and funcallable instances uniformly the rack would still have to be at the same offset, so maybe you can't save bytes.
14:58:23
drmeister
Neither of them would inherit from Function_O anymore. So there still needs to be separate checks for (typeq x function), (typeq x generic-function)
15:03:15
beach
This one can make things simpler sometimes: http://metamodular.com/CLOS-MOP/graph.png
15:05:31
drmeister
I'll define a FuncallableInstance_O class, which inherits from Instance_O and make Instance_O inherit from General_O.