freenode/#clasp - IRC Chatlog
Search
14:40:39
drmeister
libelf is a new dependency on linux - I think I forgot to add it to the documentation - adding it now.
15:34:55
drmeister
shiho: The TagSet_O object will accept a logical - the problem may be in the builder protocol - I don't think it's constructing a proper TagSet_O object when given a smarts string like: "[something;something]1"
15:43:03
drmeister
That's where you set the atom-test to nil - what other values are available in the args?
15:45:48
drmeister
What about here: https://github.com/drmeister/cando/blob/dev/src/lisp/smarts/smarts.lisp#L215
15:46:10
drmeister
That's where we relate tag-set nodes to other things. Does this only get invoked when the other thing is an atom-test?
15:48:45
drmeister
I'm trying to figure out if the parser is not working properly here or we are just not handling what the parser is giving us.
15:49:40
drmeister
Well, here you go - this method is probably what is being called - and it doesn't create anything.
15:51:34
drmeister
These tests that you are running - can you set them all up in a source file so that we can run them all?
15:51:56
drmeister
You are doing good testing work here - we should accumulate the tests for the future.
15:52:54
drmeister
Meanwhile - usha wants to start testing the AM1-BCC charge calculations on compound libraries - comparing to Antechamber
15:53:51
shiho
The test comes from am1-bcc.lisp. If the test doesn't work, it means am1-bcc doesn't work...
15:55:03
drmeister
But still - it would be good to duplicate these tests into one file that tests SMARTS
15:59:37
drmeister
And then scymtym joins. Hi scymtym - we are just talking about the SMARTS parser and the builder protocol. It's more cando integration than anything else so we were going to take it into a private channel. We can keep it here if you are interested.
16:01:49
drmeister
Ok - we are just sorting out how to deal with things like "[C]1" vs "C1" - they should be handled the same way but aren't at the moment.
16:03:19
drmeister
I also overloaded them to put tags on atoms rather than using them to test for ring closures.
16:05:12
scymtym
i suggest writing down what the different syntactic forms /should/ mean, then writing corresponding unit tests and finally changing the parser
16:05:54
scymtym
i did the unit-test-before-code-change approach for the recent changes and fixes you requested
16:06:07
drmeister
We are discovering shortcomings in the old parser - it's really good that we are switching to this new one.
16:07:48
scymtym
ok, i hope it's up to the task. these highly ambiguous grammars with operator precedence are easy to get wrong
16:17:27
scymtym
regarding the issue at hand: (esrap:trace-rule 'language.smarts.parser::smarts :recursive t) (language.smarts.parser:parse "C1" 'list) is often enough to see what's going on
19:09:08
Bike
serial build is messed up for me. i know that't not a big priority or anything, but still. i'm guessing it's something to do with inline.lisp being in front.
19:10:38
drmeister
Does that make sense? inline.lisp is already loaded and we are compile-filing it. Does compile-file'ing inlined functions change something in the system?
19:13:12
Bike
the clasp executable builds, but if you run it it complains about there being no class called NAMED-FUNCTION-AST
19:13:25
Bike
which would make sense if it tries to load the inline.fasl before the class is defined.
19:14:49
drmeister
Oh - so at startup the inline toplevel forms are running before everything else. They are running in order of how they are being compile-file'd.
19:55:36
shiho
drmeister: Now, the test stopped in the line "this->_TagLookup->setf_gethash(tag, a);" in ChemInfoMatch_O::defineAtomTag.
19:56:16
shiho
I remember we changed core::HashTableEqual_sp _TagLookup to core::HashTableEql_sp _TagLookup
22:48:57
scymtym
drmeister: shiho: if i understood correctly, https://github.com/scymtym/language.smarts/commit/b525d52c9925da551c2c8fb264b943d389ffc76f does what you want
22:51:11
drmeister
I need to spend some time with this code tonight and sort out in my head what is going on.
23:05:38
scymtym
drmeister: i thought [C]1 and [C:1] should just be different spellings of the same thing - that is the point of the change
23:07:24
drmeister
scymtym: It's ok -it's kind of a subtle point and requires several readings of the spec to understand what these are.
23:19:48
drmeister
So I think I shouldn't apply the change. I think the parser is fine. I think the problem is all in how we interpret what the parser gives us.
23:20:31
drmeister
I'm still puzzled by [C:1] - I think it means [C&:1] where :1 is always true - it's the side effect that we want, assign a label '1' to that carbon.
23:23:07
scymtym
i expected these labels to turn into AST pointers during or after parsing, so they wouldn't really be "executed" while matching
23:25:02
drmeister
So should I apply these changes? Or keep working with what we have? I confess that I don't really understand the SMARTS parser.
23:38:33
scymtym
i don't think you should apply the changes as they are. the test cases and maybe other parts can be used once it is clear what the parser should do
23:41:06
scymtym
to me, the main problem seems to be that there is no clear path to figuring out what a given syntactic element should mean
23:43:01
drmeister
Well, most of it is fairly clear - it's just these dusty corners. The SMIRKS colon operation is underspecified.