freenode/#clasp - IRC Chatlog
Search
6:37:04
beach
Does GSOC still require some pre-approved organization to provide the advisor for the project?
6:37:39
beach
I remember trying to make my university such an organization in the past, and I failed.
13:11:10
scymtym
beach: some time ago, i mentioned my plan to use CST:RECONSTRUCT in eclector. i have this: https://github.com/robert-strandh/Eclector/compare/wip-cst-reconstruct?expand=1 and i think it works well. as you can see, it calls CST:RECONSTRUCT with multiple CST instances, which is not currently supported in the concrete-syntax-tree library. i have a change which adds support for that, but it conflicts with changes drmeister
13:55:21
beach
I say, check with drmeister that he is OK with that (he usually is), and let him know how to modify his code to account for the change.
14:00:21
scymtym
beach: you probably already did for the "Add client parameter to generic func reconstruct" change. i will try to make further changes compatible to that
14:35:25
beach
Don't try too hard to be backward compatible. There are very few clients at the moment, so this a good time to clean things up.
14:59:29
drmeister
I was messing around with the new jupyter lab yesterday to get some feeling for what it's about.
15:09:44
scymtym
drmeister: the commit message is "Add client parameter to generic func reconstruct". no worries - i will figure something out
15:14:49
scymtym
drmeister: unrelatedly, i think i have pretty good understanding of SMILES and SMARTS now. the most important thing i couldn't completely figure out, neither from your parser nor from the specifications, is how complex descriptions of atoms are supposed to interact with the [] construct
15:15:51
drmeister
Could you give me an example? My understanding is the [...] construct applies a bunch of tests to an atom.
15:15:53
scymtym
i.e. can i just pile up a bunch of modifiers like CH4-2@@ or this only allowed within [] as in [CH4-2@@]?
15:16:31
drmeister
My understanding is only the simplest element tests can be expressed outside of a [...]
15:17:46
scymtym
but within [], multiple complex description can be connected by logical operators without individual []s, like [C++;C@@], right?
15:18:37
scymtym
and the order of the things i called "modifiers" such as "-4" or "H3" or @ doesn't matter?
15:20:30
drmeister
No, I don't think so. The [] match test returns true or false, the order of tests within it shouldn't matter and the tests shouldn't fail.
15:22:55
drmeister
Those tests mean "the atom has a -4 charge"; H3 "The atom has 3 hydrogens attached"; @ "The atom has S stereochemistry".
15:24:00
scymtym
yes, i understand the semantics, i was trying to figure out the exact syntax so the parser can follow the specification
15:24:31
scymtym
precision doesn't seem to be the strong suite of the specification material i have read so far, though
15:26:04
scymtym
ok, i should have said "precision in the formal languages department" since i can't really judge the chemistry part, of course
15:27:25
drmeister
Yeah - you have to read several documents on it to piece it together. There is the reference standard in the OpenEye software - but I don't want to use that.
15:27:42
scymtym
and finally, can i assume that things like APLambda that don't seem to appear in the specifications are cando extensions?
15:28:28
drmeister
Yeah - that's mine - I wanted to inject arbitrary Common Lisp code to do tests - but that is really old. You could drop that out.
15:28:49
drmeister
Back when I implemented it it was an interpreted archaic lisp that I was putting in there.
15:29:57
drmeister
There is another important difference between the OpenEye SMARTS spec and what I did - I mentioned it before - it's how we label atoms to recover them afterwards.
15:31:25
drmeister
It should be a minor modification of my parser - but I want to get rid of my parser.
15:33:35
drmeister
No, that is incorrect. The :N operator is to label the current atom with the ID N.
15:34:42
drmeister
Simply dropping the number into the square brackets indicates a test for atomic mass