libera/#clasp - IRC Chatlog
Search
15:50:29
Bike
i mean, what i'd like is some kind of conceptual background, but i know you don't have that written down and it would take time to explain
15:50:41
Bike
you have to understand - i'm at a level where i don't know what things like "templated kind" are even suppoesd to mean
15:51:22
Bike
i can probably figure out the code generation just by copying stuff, but stamps will be more involved
15:54:41
drmeister
Understood. We have a place to put documentation now. Ask me specific questions and I'll make a section on the static analyzer. Things like "templated kind" I'd have to go into the source code and figure out what I was doing.
15:58:20
drmeister
That is to indicate that these classes: Iterator_O, Creator_O, WrappedPointer_O, ConstructorCreator_O, Closure_O, BuiltinClosure_O can be further subclassed by template classes that can be parameterized.
15:58:50
drmeister
The are the immediate base class of additional classes that are templated on other types.
16:00:53
drmeister
This recognized the templated_kind enum and stores info about them. If the code is identical to what we do with class_kind then we could switch them to class_kind.
16:02:20
drmeister
I propagate the 'templated_kind' info to the gdb/lldb debugging interface in places like here...
16:02:28
drmeister
https://github.com/clasp-developers/clasp/blob/isl/src/gctools/gc_interface.cc#L784
16:02:57
drmeister
So it may be a useful flag to keep using - basically it's a 'class_kind' flag to expose a class.
16:07:38
Bike
i'm keeping all the information i get, i think, if only because I don't understand what's important
16:38:54
Bike
ok, here's one specific question. if "atomic-smart-ptr-p" is true, the analyzer outputs a variable-field tag with some slots unbound
16:39:06
Bike
should i just... check for that? is that a different kind of thing from the other variable fields?
17:47:40
Bike
have some code generated, but there are some little problems... the tags:variable-capacity records (layout-offset-field-names array) but not (layout-offset-field-names end) and and (l-o-f-n length), which appear in the generated code... unless i can infer them somehow?
17:59:42
drmeister
The atomic-smart-ptr-p thing - I think on macOS and Linux the way atomics are defined is different.
18:00:33
drmeister
I run the static analyzer on linux usually - and you are probably running it on macOS. Could you show me the sif file entries you are getting?
18:03:18
drmeister
{ TAGS:VARIABLE-FIELD ( TAGS:OFFSET-TYPE-CXX-IDENTIFIER . "ATOMIC_SMART_PTR_OFFSET") ( TAGS:CTYPE-KEY . "std::atomic<gctools::smart_ptr<core::T_O>>") }
18:04:12
drmeister
And I had a problem with atomic values because they have internal C++ structure on MacOS or Linux (or both) and the differences drove me a bit nutty.
18:04:38
drmeister
But since they all reduce to a single word I ignore all of that and just use the offset of the std::atomic<whatever>
18:05:20
drmeister
I'm guessing you are getting confused by the internal structure that I'm ignoring?
18:07:19
drmeister
The internal structure is simply C++ template types within C++ template types that all reduce to a single word in memory. On one of the OS's the internal structure is declared 'private' and so my C++ code can't get access to it.
18:17:29
Bike
but the atomic-smart-ptr-p thing means there are two kinds of code generated corresponding to the same tag class
18:18:08
Bike
atomic-smart-ptr-p makes it generate code as if there's multiple fields, except the variable-field tag lacks the information it has when there are actually multiple fields
18:21:35
Bike
https://github.com/clasp-developers/clasp/blob/main/src/lisp/modules/clasp-analyzer/clasp-analyzer.lisp#L810-L820 the other problem is here - the code uses these layout offset field names that aren't actually put in the tag
18:31:15
drmeister
I don't think I explained how the tags work together. Either information is missing and you need to add it - or it's in one of the related tags and you need to group the info together...
18:33:56
drmeister
The FIXED-FIELD's define fields in the Rack_O and the VARIABLE-ARRAY0 and VARIABLE-CAPACITY together define the stretchy vector on the tail end of the Rack_O and then there can be multiple VARIABLE-FIELD entries that define what is stored in each element of the stretchy vector.
18:34:30
drmeister
If you know that and that doesn't solve the problem - then you understand things and yes - we need to add some more entries to one of the tags.
18:34:55
drmeister
If you paste the sif file entries for the class you are talking about we can take a look.
19:19:28
Bike
i mean, conceptually. i don't get how the corresponding c++ code really defines anything
19:20:01
Bike
{ TAGS:VARIABLE-CAPACITY (( TAGS:CTYPE . "unsigned short")( TAGS:OFFSET-BASE-CTYPE . "gctools::GCArray_moveable<unsigned short>")( TAGS:FIELD-NAMES . ("_Data"))) \
19:20:43
Bike
this is incorrect, as far as i can tell, because the field name for the capacity is _MaybeSignedLength, and that's what's in clasp_gc.cc too
19:23:28
Bike
i have made some minor changes to the analyzer's sif file generation already btw (in my branch)
19:24:32
drmeister
{ variable_capacity, sizeof(short), __builtin_offsetof(SAFE_TYPE_MACRO(gctools::GCArray_moveable<short>),_MaybeSignedLength), __builtin_offsetof(SAFE_TYPE_MACRO(gctools::GCArray_moveable<short>),_MaybeSignedLength), 0, NULL },
19:24:40
Bike
in the code generator it actually uses two things which apparently both end up as _MaybeSignedLength
19:26:39
drmeister
This is an array - that means the "end" and "capacity" are equivalent and I put the same info in them.
19:28:14
drmeister
So I provide two offsets for GCVector, one for the "end" and one for the "capacity".
21:01:32
drmeister
The GC_DECLARE_FORWARDS part of the clasp_gc_cando.cc was a especially annoying thing to have to build.
21:36:16
Bike
drmeister: this isn't important, but out of curiosity, what are priority tags for? i think there's only one use in the codebase
3:16:09
drmeister
I got the seqan extension to work in Cando with snapshot save/load and jupyterlab.