freenode/#clasp - IRC Chatlog
Search
15:00:48
Bike
you should keep doing what you're doing, i'll tell you if i get something that can be coherently examined
15:08:53
Bike
any chance i can get lisp arguments from lldb? or does all the underlying C++ functions having "<unavailable>" mean they're really gone
15:43:31
drmeister
But if you attach __attribute__((optnone)) to the function - then they will be there for you.
15:43:57
drmeister
You can also try crawling up and down the stack - sometimes I get lucky and I find the value available somewhere.
15:44:55
drmeister
Or if you are truly brave 'register read' will dump the registers - if they end in 'f' or not '0' and they look like a pointer - then you may have a tagged pointer that you can examine.
15:45:23
beach
You can start testing it by replacing Generate-AST by CST-to-AST provided you call cst:cst-from-expression before feeding a form to CST-to-AST.
15:45:47
drmeister
beach: Wonderful! We were talking about modifying our reader to generate CST's today.
15:48:07
beach
How do you plan to modify the reader? I mean, a reader macro can do some arbitrary shuffling of its recursive read result. Or do you plan to "cheat" by having your reader macros do something other than "standard"? If so, what happens if there is a custom reader macro that does not know about CSTs?
15:49:17
drmeister
Clasp's reader has kept track of source information from day 1 - we just don't use it. I haven't thought about reader macro issues.
15:51:18
beach
Suppose your input is (say) [(a) (b) (c)], and the result of invoking the reader is ((c) (c b) (c b a)), how do you identify the origins of all those expressions.
15:51:29
drmeister
Streams keep track of the file offset, line number and column. It used to bundle this info up in a C++ class that is exposed to Common Lisp called a core:source-pos-info object.
15:52:53
drmeister
Right - it didn't do anything with atoms. But in the reader, where the atoms are generated - the source information is available. We can generate CST nodes that associate the atoms with their source info.
15:53:17
beach
What if you have (#1=(a) (b) #1#), what is the origin of the expression marked as #1#?
15:53:28
drmeister
When you say [(a) (b) (c)] you are talking about a reader macro for #\[ - correct?
15:54:54
beach
The problem with symbols is that they are not unique. What source location do you associate with the different "A"s in (a b a c a d a)?
15:55:20
drmeister
I don't have an answer at this point. What I was doing is when I needed source info - I would walk the tree looking for anything that had an association in the source tracking weak key hash table and using that.
15:56:08
beach
Anyway, if you have your hash table, you can do a half-decent job converting an expression to a CST. You just won't get information about symbols.
15:56:29
drmeister
For (a b a c a d a) each symbol is at a different character offset. What would the CST nodes look like?
15:57:16
drmeister
A CST node for a symbol stores what? Just the symbol and an implementation dependent source-location object - right?
15:57:28
beach
It would be a sequence of CONS-CSTs terminated by an ATOM-CST. Each FIRST slot of the CONS-CSTs would be an ATOM-CST containing the symbol.
15:58:05
drmeister
And an ATOM-CST contains the atom and an implementation dependent source position object.
15:59:46
drmeister
(CST-CONS (CST-ATOM 'a (source-position 1)) (CST-CONS (CST-ATOM 'a (source-position 3)) NIL?))
16:00:20
drmeister
I'm not sure about the NIL? - you said a list terminates with an ATOM-CST? What is that for?
16:00:52
drmeister
Uh - I don't understand the question "Great! And how do you distinguish between the two positions for the A? "
16:01:04
beach
If you use a hash table, then the second A will delete the source position of the first, no?
16:01:53
beach
That was my initial question. Do you plan to modify your standard reader macros to generate CSTs?
16:01:55
drmeister
I'm not letting you do all this work and then not implement the best reader that I can to take advantage of it. :-)
16:02:25
Bike
couldn't you have a tracking-reader that calls the normal compiler macros and then wraps the results?
16:04:02
Bike
No, I mean have a special READ function that makes CSTs with the results of reader macros.
16:04:04
drmeister
I think it will have to handle it somehow and probably lose source tracking for custom reader macros.
16:04:39
beach
Bike: Yes, I understand, but how do you identify the result of the reader macro with the source locations?
16:04:54
Bike
So (type-of (read-from-string "(a)")) => CONS like usual, but then (tracking-read-from-string "(a)") is like (make-cst '(a) the-source-location)
16:05:36
beach
Bike: So what if you have the input [a] and the reader macro returns (((((((((((((((((((((a)))))))))))))))))))))?
16:06:45
Bike
you could have a *read-tracking* variable, and have READ return CSTs when it's T... but then a reader macro might want to manipulate the result of read somehow
16:12:04
beach
I myself plan to do something similar to what I do with the "intelligent macro expander", i.e. I start from a "parse result" (that has all the results from recursive reads in the order that they were read, including source information) and a resulting expression. Then I try to identify sub-expressions with the children in the parse result, starting with lists. This will basically do the same as a hash table would. Then, I process
16:12:04
beach
atoms in a similar way. Then, if there are remaining sub-expressions with no corresponding parse-result child, I try to find it deeper in the descendants.
16:12:57
beach
I have already modified the SICL reader so that it can be customized to return parse results in addition to expressions.
16:13:20
drmeister
That sounds a lot like what I was trying to do from the start. Only now the weak key hash table only has to deal with what is going on in one reader macro.
16:13:27
beach
I do not plan to modify the standard reader macros. The advantage is that I can handle some custom reader macros as well.
16:18:12
beach
The simple, most common, case for this parse-result processor will of course be that there are as many sub-expressions as parse-result children, each child has a sub-expression in it, and the order is preserved.
17:31:36
shiho
drmeister, I got the error... "chem::EnergyNonbond_O::constructExcludedAtomListFromAtomTable(gctools::smart_ptr<chem::AtomTable_O>, gctools::smart_ptr<chem::ForceField_O>, bool)", referenced from:
17:31:47
shiho
chem::EnergyFunction_O::generateNonbondEnergyFunctionTables(bool, gctools::smart_ptr<chem::Matter_O>, gctools::smart_ptr<chem::ForceField_O>, gctools::smart_ptr<core::T_O>, bool) in 252.thinlto.o
17:32:02
shiho
ld: symbol(s) not found for architecture x86_64 clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation)
17:33:04
drmeister
That happens if the declaration in the header file doesn't have a matching function definition in the .cc file
17:33:32
drmeister
If there Is there a constructExcludedAtomListFromAtomTable in the energyNonbond.cc file?
18:37:48
Bike
beach: cst-to-ast refers to a cst:parse-macro that i can't find. is that to-do? does it mean the cleavir-code-utilities:parse-macro is going to be obsoleted? i ask because i was about to file an issue about it
18:44:14
Bike
i was just going to note that the conditions are thin, rather than an actual error or anything, so i'll probably leave it