freenode/#clasp - IRC Chatlog
Search
12:50:53
drmeister
The travis build failed because it failed trying to include #include <rti_dds/rti_dds.h> ?????
12:57:33
drmeister
I think I know what is going on. I added attila's travis code and so travis started working but it's still working in drmeister.
12:58:31
drmeister
I connected travis to the 'clasp-developers' account - we need to migrate the clasp repo to 'clasp-developers'
14:31:58
drmeister
I forked clasp and cando into clasp-developers - don't do anything with them for now. I just want to test travis.
14:43:48
frgo
drmeister: Q: In file include/clasp/gctools/gc_interface.h there is an #include <project_headers.h> when building extensions. Do you use/need that project_headers.h in Cando? Where does it live there?
14:45:13
drmeister
I think it's this: ~/Development/cando/extensions/cando/include/cando/main/project_headers.h
14:46:12
drmeister
Now - this is more (exclusively?) for classes that you define that subclass from core::General_O
14:47:06
drmeister
This is all referenced from here: https://github.com/drmeister/cando/blob/dev/wscript#L16
14:47:35
drmeister
It's that Python code that hooks the extension header file into the clasp build system.
14:49:03
drmeister
These extensions are more for when you add classes that you want managed by the garbage collector - are you doing that?
14:50:05
drmeister
Ok - there is no fundamental reason why we can't support multiple extensions simultaneously but there is a challenge to overcome.
14:51:55
drmeister
The static analyzer will need to be run on any permutation of clasp+extensions that are compiled into the single cclasp-mps executable that clasp builds.
14:52:53
frgo
One is the Data Distribution Standard messaging system for realtime message exchange between systems.
14:53:58
frgo
So I set up the wscript machinery to include them if the respective subdirs in extensions/ are found.
14:54:05
drmeister
Will they both contain GC managed classes? Nanogui seems kind of lightweight and may not require any GC management.
14:54:53
drmeister
Nanogui can just be a library that is dynamically loaded and exposed to clasp without ever needing GC managed classes.
14:55:45
drmeister
The idea is that you drop any number of extensions into that directory and then you build a clasp that incorporates them all.
14:56:46
drmeister
It's using the waf 'recurse' facility to find extensions in clasp/extensions and accumulate all the information necessary to create a single executable.
14:58:52
drmeister
Rest assured though that I designed all of this so that any number of extensions can be merged together into one super clasp system.
14:59:11
drmeister
If it doesn't support that now - it's a bug and we should fix it. I only had one extension (cando) when I started this.
15:00:05
drmeister
The reason everything needs to be together is because the GC needs to have unique header stamp (integer index values to identify each C++ class that is GC managed) for every class in the system.
15:00:59
drmeister
It was mind bogglingly difficult to figure out how to do this in a modular way so that extensions could be added piecemeal at load time.
15:01:57
drmeister
You will notice in the clasp/src/main/ directory there is a clasp_gc.cc and a clasp_gc_cando.cc file.
15:02:30
drmeister
That is a massive wart in my current scheme - that the clasp source code needs to know about clasp_gc_cando.cc
15:02:55
drmeister
When you use the static analyzer and you generate one of those files yours will be named...
15:04:30
drmeister
Ok - with the present scheme (before we figure out how to fix this wart) when you use the static analyzer on clasp plus your rti_dds and nanogui extensions - the static analyzer will generate a clasp_gc_nanogui_rti_dds.cc file.
15:05:35
drmeister
Currently (the wart) means you will need to generate that file and we put it into clasp/src/main/clasp_gc_nanogui_rti_dds.cc
15:06:22
drmeister
In the future we might have a repository of combinations of extensions that can be added to clasp for which there exist GC descriptions.
15:07:04
drmeister
None of this is needed by the Boehm GC mind you - the Boehm GC gets all of its information from the scraper - the scraper runs every time you build clasp.
15:08:17
drmeister
Well, it will once I run the static analyzer. I haven't done that in a while because I really want MPS for Cando - and the SMARTS parser in Cando is still implemented using yacc and it will crash MPS.
15:08:48
drmeister
We haven't made any changes to Clasp that would break MPS - other than possibly breaking allocation of derivable_cxx classes.
15:09:14
drmeister
I'm keeping track of all of this in my head and I don't talk about it much because there is so much to do.
15:09:31
drmeister
But I'm not too worried about maintaining MPS support at the moment - we aren't messing with anything that would break it.
15:10:30
drmeister
My critical path to getting everything working is (1) write a SMARTS/SMIRKS parser using esrap (2) run the static analyzer.
15:15:01
drmeister
Would you be interested in assisting or writing a kind of complicated parser for the SMARTS language?
15:15:38
drmeister
I have an existing yacc parser and there is plenty of literature online describing it.
15:15:55
drmeister
No need to tell me right away - but yes - we need a SMARTS parser written in esrap.
15:17:06
drmeister
No not quickly. We can keep moving forward with the yacc parser running in boehm.
15:18:21
scymtym
more seriously though, i would be doing this in my free time and i don't know yet how much work it would be
15:19:04
drmeister
In no particular order...https://docs.eyesopen.com/toolkits/cpp/oechemtk/SMARTS.html
15:21:58
scymtym
do you already have a domain model and a corresponding implementation instances of which the parser would build?
15:22:24
drmeister
Basically SMARTS is for recognizing patterns and SMIRKS adds the ability to save and label atoms that are part of the pattern so that you can query the match and get the atoms back out.
15:23:37
scymtym
i mean a set of CLOS (or C++) classes for representing SMILES, SMARTS, SMIRKS concepts
15:24:19
drmeister
Oh yeah - they aren't super tidy - but they do the job. I wanted to clean them up and bring them into the modern era with this rewrite of the SMARTS parser.
15:25:55
drmeister
The messy bits are that I have one class (AtomTest_O) that does a lot more than it should and it should be subclassed for different tests.
15:26:32
drmeister
These classes implement code that test atoms to see if they are particular elements, have certain hybridization, charge whatever.
15:28:00
drmeister
Or there is the Logical_O class that does all logical tests - there should be subclasses that do them for HighPrecedenceAnd, Or, LowPrecedenceAnd, Not etc.
15:28:05
Bike
smarts is also a specified thing, like it's got a wikipedia article with syntax and such.
15:29:00
Bike
well, the article on SMILES is better. smarts is like smiles plus replacements, as far as i understand
15:29:28
drmeister
I'll get you a few more links - there is one that is super clear - I'm looking for it.
15:31:58
drmeister
The thing that my bison/yacc parser doesn't do properly is label atoms - I came up with a different syntax.
15:32:32
drmeister
Proper SMARTS uses [C:1][C:2] to indicate two carbons connected to each other and the first will be labeled '1' and the second '2'
15:33:28
drmeister
My parser implements almost all of the [] atom tests however. Just not the #\: labeling operator.
15:35:21
scymtym
drmeister: sure. and i will add your last remarks to my notes. the links seem like a better starting point
15:35:40
drmeister
We don't need to support Reaction Queries at this point so section 4.6 and section 5 aren't important at this point.
15:37:41
drmeister
Also, since SMARTS is a superset of SMILES - if we could also parse SMILES and generate a different domain model - that would make the code much more powerful.
15:38:12
drmeister
SMARTS would generate those chemInfo.h classes and SMILES would generate a different set of classes that would build molecules.
15:39:56
drmeister
Since esrap separates the parser from the builder - it should be straightforward to do that.
15:40:17
scymtym
would generate /instances/ of those classes, right? sorry if this comes across pedantic but i need to understand things in those terms
15:40:52
drmeister
We already expose almost everything you would need to generate instances of those classes.
15:42:10
drmeister
They simply call other Cando exposed code to query atom properties and bond properties.
15:43:19
drmeister
Back when I wrote this stuff I was exposing it to Python - I would never think of doing this pattern matching in Python - it would have serious performance issues.
15:43:26
scymtym
i don't know how to phrase this politely, but maybe, before you spend more effort explaining more aspects, let me have a look
15:53:27
drmeister
Namely, when I enter the command line debugger and select a restart - the REPL goes a bit nuts.
15:56:32
drmeister
The REPL works fine with forms - but it goes nuts with simple expressions like '1' or ':r1' (I type what is in the single quotes and press enter)
15:59:16
drmeister
I'm using fprintf(stderr,"stuff") to print those ../../src/core/lispReader.cc:... messages
16:00:37
drmeister
What exactly is going on with a stream that is waiting for input? How do people think about that? Is it at the EOF?
16:31:23
frgo
Seems as if not getting an "end of form" character, i.e. ), causes the reader to not complete its processing and keeping characters in the buffer.
16:32:30
drmeister
Right - I'm using peek-char and if the char returned is whitespace then I call read-char
17:37:38
drmeister
It looks like my simplistic solution of peek-char for a white space after READ was incorrect.
17:51:52
drmeister
The reader eats whitespace after any token is read unless whitespace is preserved.
17:56:01
drmeister
I think I'll try unreading the character in every case along with the peek-char/read-char in READ
17:56:24
drmeister
That should put back the whitespace after reading a token and then READ can eat it again.
18:22:33
Bike
https://github.com/drmeister/clasp/blob/cst/src/lisp/kernel/cleavir/translate.lisp#L1216-L1217 uncomment this and compile something with lets
18:39:37
drmeister
It looks like I need to transfer clasp to clasp-developers if I want travis to start working on it.
18:43:38
drmeister
It looks like transferring clasp from drmeister to clasp-developers should be pretty straight forward. https://help.github.com/articles/about-repository-transfers/
19:14:07
drmeister
I moved clasp to clasp-developers, I told travis to build it, I pushed to dev - I merged dev into master and pushed that (yeah - I went there).
19:45:30
drmeister
You can update your remote - but I don't think anything on github needs to be updated - it should migrate everything.