21:06:38drmeister::notify scymtym It's exactly as painful as I thought it would be to try and get hold of these people to ask them how this is implemented. They refer me to the SMARTS links that we have already read and then they tell me to look in the rdkit code. I don't think the answer is in there.
21:06:38Colleendrmeister: Got it. I'll let scymtym know as soon as possible.
21:09:19drmeister::notify scymtym I think the answer is buried in the OpenEye library. I am starting to think that the `@1` is redundant. The numbers are used to indicate rings, the `@` indicates a ring. I think `@1` and `1` are equivalent.
21:09:19Colleendrmeister: Got it. I'll let scymtym know as soon as possible.
21:14:16drmeister::notify scymtym I'm really rusty with esrap - if I want to optionally allow an `@` in `(defrule atom-pattern ...)` how would I do that? Instead of `(and acyclic-atom-pattern (? parser.common-rules:integer-literal/decimal))` to allow an optional `@` before the integer?
21:14:16Colleendrmeister: Got it. I'll let scymtym know as soon as possible.
21:14:26yitziIn other words, they don't know where the parser is?
1:42:29drmeister::notify scymtym This illuminates how ring-closures work - you can prefix them with a bond primitive. This extends to SMARTS so things like `*=1[*][*][*][*]=1` are valid but the `*@1[*][*][*][*]@1` still seems pointless.
1:42:29Colleendrmeister: Got it. I'll let scymtym know as soon as possible.
1:42:42drmeister::notify scymtym This being... http://opensmiles.org/opensmiles.html#ringclosure
1:42:42Colleendrmeister: Got it. I'll let scymtym know as soon as possible.
3:37:17Bikeyitzi: any idea what's up with these test failures? the closest i got to changing koga was a line in repos.sexp, but for some reason it caused the llvm json thing to pop up again https://github.com/clasp-developers/clasp/pull/1397
3:40:33yitziBike: looks like the ubuntu build might need broken-stdlib in the workflow file