freenode/#clasp - IRC Chatlog
Search
8:30:08
kpoeck
@Bike, when you have time - if there is time before the demo - could you have a look at issue 454?
8:31:11
kpoeck
Definining shared-initialize on a struct throws an error about allocate-instance not being defined for structure-class
11:34:20
scymtym
drmeister: the SMILES/SMARTS material you provided doesn't seem too complicated. so far, the main difficulties seem to be handling the separation into SMILES and SMARTS intelligently and managing the apparently numerous variants and extensions
11:46:13
drmeister
scymtym: Agreed - but that would be gravy - I don't implement SMILES at the moment. SMARTS is the really important capability.
11:48:10
drmeister
Bike: Now that other people are working on the ld crashing issue I rebuilt cst with your partial inlining turned on and reproduced the STORE issue.
11:50:30
drmeister
Shiho and Bike: I found some PDF's on the Shrodinger web site that describe their user interface for setting up these FEP calculations.
11:51:39
drmeister
It's the typical pointy-clicky-menu-dialog GUI that drives me nuts. I think we can do a much better job with the Jupyter Notebook interface.
11:52:09
drmeister
I figure if they publish it on their web site then it is fair game for us to look at it.
12:02:11
scymtym
drmeister: i see. a basic parser for SMARTS shouldn't be too much work, then. i mean, i seem to have most(?) of it, from playing around while learning how the languages work
12:07:43
drmeister
Yeah - the tricky part is turning it into the model. I have a yacc/bison parser that does it. I posted a link and I can repost it if you like.
12:09:33
scymtym
my thinking at the moment is having the parser and maybe generic language support in a separate system and having a suitable builder in cando. does that make sense?
12:13:18
drmeister
I have to prepare for teaching. I’ll be more available to talk after a couple of hours.
12:14:58
drmeister
But since ideally we want one parser and two model generators - yeah I think it makes a lot of sense to have the parser in its own system.
12:44:08
Bike
i think you're right that the smarts parser should be its own system, by the way. surely whatever it parses into can be useful even without extra info from cando
12:46:59
scymtym
yes. in my experience, when dealing with languages, it is best to put some effort into cleanly separating the components. this helps things like editor support and whatnot easier and it makes development and debugging easier
12:48:23
scymtym
Bike: do you happen to know whether the "two model generators" mentioned above also implies restricting the parser to only accept SMILES for one of them?
12:50:16
scymtym
to me as well. but keeping the two separate is not always easy since everything is a bit tangled. i'm trying to decide whether it is worth the effort
13:02:18
Kevslinger
https://drugdesigndata.org/upload/community-components/d3r/webinar2017/presentations/Cournia_lab_D3R_webinar.pdf
14:31:31
attila_lendvai
I'm looking at the repos, like cffi, in clasp-developers, comparing it with cffi proper to see what's the difference... and it has a master branch that is ahead of cffi proper, and it's not rebased, but merged with cffi master. it's very confusing... it should have a branch called 'clasp' or somesuch, and the extra commits rebased on master.
14:32:36
attila_lendvai
this applies to all the other repos... what's the reason for this? is it the lack of git-foo? if so, I'm willing to put together a short wiki page about the workflow...
14:34:19
attila_lendvai
would it be welcome if I cleaned it up, e.g. collect the useful patches into a 'clasp' branch of cffi? the fetch git script in my build refactor branch supports getting non-master branches and even tags.
14:38:27
attila_lendvai
I generally prefer to avoid merge commits most of the cases, unless it's really something significant, or I want to attach a GPG signature to the merge commit