libera/#clasp - IRC Chatlog
Search
13:20:34
drmeister
I didn't look at the scraper stuff yet - I'm making progress on the refactoring thing .
13:22:51
drmeister
The idea that we could have code that improves our code fascinates me. It lets us escape from bad decisions made in the past when we didn't know how things would work together.
18:34:32
drmeister
Bike: If I use llvm-dwarfdump and it dumps debug info - that means there's debug info - right? I'm going a bit crazy here. Spending hours building a debug version of llvm, building and linking with it and no debug info is available.
18:37:03
drmeister
I go llvm-dwarfdump /opt/llvm13/lib/libclangLex.a and there are DWARF entries for the function I'm trying to debug.
18:37:24
drmeister
I do the same thing on my executable that linked that library (statically I think) and I don't find DWARF entries for that function.
18:41:20
drmeister
Because it has: -L/opt/clasp/lib -L/opt/llvm13/lib in the link command line #*%$@*#%@ Why?
18:42:54
Bike
there's something putt ing -L/opt/clasp-support/lib into LINKFLAGS, and then another thing that puts in the result of llvm-config --libdir
18:48:35
Bike
example: MDArrayT_O's parent class is listed as core::template_Array<bla bla bla>, which isn't described in the sif
18:49:38
drmeister
Ah - there is a bunch of that. How does the static analyzer deal with it? The static analyzer has more insight about what inherits what.
18:50:18
drmeister
Is this a general problem when template classes are in the hierarchy? That's what I meant when I said "there's a bunch of that".
18:51:12
Bike
there are a whole lot of cases of stamps being messed up, so it might be common. all the array classes look messed up, probably for this reaosn
18:51:16
drmeister
Oh - right - the static analyzer didn't assign stamps for this part of the hierarchy - it got them from the scraper.
18:53:19
drmeister
Regarding MDArrayT_O - the scraper only knows this: LISP_CLASS(core, CorePkg, MDArrayT_O, "MDArrayT",MDArray_O);
18:54:04
drmeister
class MDArrayT_O : public template_Array< MDArrayT_O, SimpleMDArrayT_O, SimpleVector_O, MDArray_O >
18:54:40
drmeister
I think this is a hack that we use here: LISP_CLASS(core, CorePkg, MDArrayT_O, "MDArrayT",MDArray_O);
18:56:16
drmeister
So I think you want to merge in the info from the LISP_CLASS entries to figure out what inherits from what.
18:57:59
drmeister
Or - another way to think about it is mimic the generation of stamps for the class hierarchy where we generated them in the scraper and passed them to the static-analyzer.
18:58:28
drmeister
Now we pass info from the static-analyzer to the scraper and ask it to generate all the stamps. For the exposed classes the scraper should generate stamps just like it used to.
19:00:39
Bike
i haven't thought about merging multiple sources. i have the clasp_gc.sif generating entirely different representations
19:02:46
drmeister
{ TAGS:CLASS-KIND (TAGS:STAMP-NAME . "STAMPWTAG_core__MDArrayT_O") (TAGS:STAMP-KEY . "core::MDArrayT_O") (TAGS:PARENT-CLASS . "core::template_Array<core::MDArrayT_O,core::SimpleMDArrayT_O,core::SimpleVector_O,core::MDArray_O>") (TAGS:ROOT-CLASS . "core::T_O") (TAGS:STAMP-WTAG . 3) (TAGS:DEFINITION-DATA . "IS_POLYMORPHIC") }
19:03:12
drmeister
It knows that MDArrayT_O inherits from "core::template_Array<core::MDArrayT_O,core::SimpleMDArrayT_O,core::SimpleVector_O,core::MDArray_O>"
19:03:54
drmeister
We just want to know that MDArrayT_O inherits from MDArray_O from the point of view of generating stamps
19:04:06
Bike
i'm surprised there's no information about template_Array, or is it stored in some other way
19:04:48
drmeister
Maybe it's only pulling out classes with names that end in "_O"? I don't remember the matching rules.
19:08:53
Bike
if we did know about template_Array completely, we could fill out the class hierarchy entirely and thus get good stamps
19:09:05
Bike
although i guess that would also include stamps for abstract classes like template_Array
19:11:04
kpoeck
https://github.com/clasp-developers/clasp-boehm installs boehm in /opt/clasp-support/lib . Is that not a good idea?
19:12:15
drmeister
Hi kpoeck - I'm starting to think using hard coded paths starting with '/opt/' are a bad pattern - yes.
19:12:35
Bike
in installers i've usd there's usually been an option to provide an install prefix, if nothing else
19:14:14
Bike
AstVisitor_O is given one that's lower than T_O's, because it's i a different hierarchy, but you said i could delete that class
19:17:02
drmeister
kpoeck: I remember something happening with boehm a while ago - what does --enable-large-config do?
19:19:02
drmeister
Ah - that was a long time ago - I don't think it's a problem anymore to use stock boehm