freenode/#clasp - IRC Chatlog
Search
16:10:20
drmeister
https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/cmp/cmpir.lsp#L919
16:12:56
Bike
https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/cleavir/convert-form.lisp#L14-L15
16:50:30
drmeister
I was very careful to bind that dynamic variable in the threads that take the AST->native code&function-descriptions.
19:15:11
Selwyn
kpoeck: i have experienced some problems with CFFI in clasp https://pastebin.com/KYKNkPnX
19:29:06
Selwyn
the problem is not the garbage. i don't initialise the struct to anything so the values aren't expected to be meaningful
19:29:48
Selwyn
the problem is, if you try to access the data more than once you get different results in clasp, in sbcl you correctly get the same thing
19:30:49
Selwyn
it seems to be related to the fact that data_ptr is incremented. the behaviour comes up only when the struct contains a char array such as (:a-string :char :count 256)
19:31:47
Selwyn
i tried to dig into clasp internals but couldn't find where/why data_ptr is incremented
19:32:53
Selwyn
also i assume that :data-ptr is equivalent in purpose to SB-SYS:INT-SAP but am not sure
19:39:39
Selwyn
i call (convert-from-foreign *struct* '(:struct a-struct)) 3 times and each time it is incremented. somewhere along the way %inc-pointer must surely be called?
19:40:20
Selwyn
this issue was (is) at the heart of the translators in cl-vulkan not working correctly
19:43:12
drmeister
I'm not sure I can reproduce this here quickly - so when you get back to your computer could you give this a try?
19:43:50
drmeister
watch *0x10793ad0 - more info at https://sourceware.org/gdb/download/onlinedocs/gdb/Set-Watchpoints.html#Set-Watchpoints
19:45:10
drmeister
Then the next time anything in the 8-bytes at <address> is modified it will drop back into the debugger.
19:47:58
Selwyn
could you use this to watch C++ objects? or does the garbage collector move things around and prevent this
19:59:43
kpoeck
If you trace FOREIGN-STRUCT-SLOT-VALUE, you see that the data-pointer is incremented with the access for the 2nd slot
20:03:16
kpoeck
drmeister: Does (clasp-ffi:%inc-pointer ptr offset) destructively changes the pointer or return a new one
20:08:17
drmeister
Hmm, could you tell me what to fix and I'll fix it? I'm working with chemistry code and with Martin on the distributor and I'm spread pretty thin today.
20:15:36
Selwyn
kpoeck: https://github.com/clasp-developers/clasp/blob/master/src/core/fli.cc#L670 is the source for %inc-pointer. it looks destructive to me! i didn't notice before
20:18:08
kpoeck
Perhaps a bad idea to change ForeignData_O::PERCENTinc_pointer since other code might use that
20:18:49
kpoeck
and than (defun inc-pointer (ptr offset) "Return a pointer OFFSET bytes past PTR." (clasp-ffi:%inc-pointer-copy ptr offset))
20:20:50
Selwyn
i noticed that the clasp-ffi interface looks very similar to cffi-sys : https://github.com/cffi/cffi/blob/master/src/cffi-clasp.lisp many methods in cffi-sys simply call their counterparts in the clasp-ffi package
20:21:08
drmeister
Suggest any changes that make the most sense - don't worry about backward compatibility - we can fix everything that references functions that you want to change.
20:21:46
Selwyn
i assume this was a deliberate design decision when writing clasp-ffi in order to simplify things - after all cffi interoperation was (presumably) a key goal in giving Clasp FFI abilities
20:22:42
drmeister
frgo wrote the clasp cffi implementation - it's the first big part of clasp that I don't really understand.
20:23:07
Selwyn
i would propose therefore keeping consistency and making %inc-pointer behave the way it does in cffi-sys, and modifying those cases in clasp code which rely on the old destructive behaviour
20:27:19
drmeister
Hi - when you implemented PERCENTinc_pointer you made it work destructively - here is the code...
20:28:02
drmeister
Is it necessary that it works in place like that? Or could it return a copy of the ForeignData_O object?
20:28:47
drmeister
It seems to me that for speed you wouldn't want to be consing a new ForeignData_O object every time you increment a pointer however.
20:29:06
frgo
No need to return a copy. ForeignData_O has two slots - one that always keeps the original address and one that is inc'ed
20:29:50
frgo
If we have to free the originally malloc'd thing then the original address is still there.
20:30:48
drmeister
Selwyn: So the problem is that foreign-struct-slot-value is incrementing the pointer - right?
20:32:51
drmeister
So here's my understanding at this point... foreign-struct-slot-value uses inc-pointer to index into a struct. inc-pointer calls %inc-pointer (https://github.com/cffi/cffi/blob/master/src/cffi-clasp.lisp#L112)
20:33:22
drmeister
%inc-pointer increments m_raw_data in place and that causes problems with foreign-struct-slot-value.
20:37:17
drmeister
Here... https://common-lisp.net/project/cffi/spec/cffi-sys-spec.html#Basic-Pointer-Operations
20:38:55
frgo
Hm - I didn't see the requirement to create a new instance of ForeignData_O for that. Which may well be wrong!
20:51:07
kpoeck_
Inc-pointer is not well defined but i bet a pint of beer that it is not supposed to modify the argument
20:53:02
frgo
So we simply need to have ForeignData_O::PERCENTinc_pointer() create a new ForeignData_O object.
20:53:19
Bike
cffi not-sys says it returns a new-pointer, and there's a separate incf-pointer operation, and generally things seem to be written as pointers being immutable
20:58:26
drmeister
Maybe we should have a separate function like sb-sys:sap+ that adds an offset to a pointer and returns a new pointer.
20:59:33
drmeister
Maybe rename %inc-pointer to %inc-pointer-in-place and leave it as an optimization for the future.
21:26:22
kpoeck
First pick at the test in is https://gist.github.com/kpoeck/21da95451591f301a9c290e0b29db502
22:30:18
frgo
Small correction to the test: https://gist.github.com/dg1sbg/c962ed5d87595b18e39c4fb86c8608be