freenode/#clasp - IRC Chatlog
Search
13:07:06
drmeister
Bike: I managed to transform molecules and smarts trees into boost::graphs that I think are compatible with VF2
13:08:09
drmeister
A native implementation would be better because there needed to be a fair amount of indirection to bridge the C++ and Clasp memory management approaches.
13:09:50
drmeister
Now that I say it I realize I should put the smarts objects into collectible_immobile memory.
13:52:59
Colleen
shiho: drmeister said 8 hours, 14 minutes ago: Ask me about BAD_SMARTS - we need to fix up some smarts strings
14:05:01
drmeister
::notify kpoeck I found the reason the source file numbers were starting higher - it was something I introduced accidentally in the last couple of days. I'm fixing it. But we have another problem - 'dev' is broken at the moment and we are working on fixing it.
14:53:37
Bike
okay, so the ast-interpreter problem is that the inliner doesn't work with bind-va-list-instruction well. i could try to fix that, but i think what i'd rather do is just not use bind-va-list-instruction in the cst build, and do a regular lambda call, since the inliner should be able to eliminate it
14:54:06
drmeister
Holy crap - I reflexively typed 'git pull origin dev' while in the 'work' branch and now I've pulled in the broken part of dev. (sigh)
14:56:03
drmeister
I could trash my work branch and pull it from github - I pushed it so that shiho could use it.
18:24:08
kpoeck_
The metaclass error can be worked around by first loading the file and than conpiling it
19:58:08
kpoeck_
But i have a partial succes, clpython compiles, test suite compiles, and some test work
20:04:08
kpoeck
The reader error message is: Condition of type: SIMPLE-READER-ERROR Undefined reader macro for char '#' subchar '=' in file compiler-test.lisp line: (521) column (51).
20:04:08
Colleen
kpoeck: drmeister said 5 hours, 59 minutes ago: I found the reason the source file numbers were starting higher - it was something I introduced accidentally in the last couple of days. I'm fixing it. But we have another problem - 'dev' is broken at the moment and we are working on fixing it.
20:06:53
drmeister
kpoeck: Yeah - clpython is interesting as a talking point for a meeting we have next week.
20:07:53
drmeister
I want to blunt the annual "We don't want to learn any language that looks insufficiently like Python" that I get at this meeting. If I can at least compile clpython I can say - "Well - we have Python"
20:08:04
Bike
i don't think the default eclector readtable supports it, because of having to walk structure? something like that
20:08:37
drmeister
re: vf2 graph isomorphism - I looked for source code where people use vf2_subgraph_iso from the boost::graph library - I found this... https://github.com/rdkit/rdkit/issues/1284
20:13:28
drmeister
Does cl-python automatically expose all of the Common Lisp functions and classes to python?
20:24:59
drmeister
I'm wondering if clasp implementation specific functions implemented in C++ or Common Lisp just "appear" in cl-python and can be invoked.
20:25:54
drmeister
If so - then it would be a viable scripting language with almost zero work - and I don't want to put a lot of work into this.
20:30:32
kpoeck
CLPython is able to turn a regular Lisp listener (REPL) into a "mixed-mode" listener that supports both Lisp and Python source as input:
20:37:31
kpoeck
Bike: there is (IN-SYNTAX *AST-USER-READTABLE*) in clpython, so probably you are right
20:51:01
Bike
drmeister: i've been seeing transient errors about seemingly random dynamic variables being unbound in the asdf/serve-event build step. shiho just hit it (in work branch) so it may not relate to my issues
21:02:07
kpoeck
drmeister: https://github.com/clasp-developers/clasp/wiki/How-to-load-cl-python-in-clasp
21:13:47
drmeister
Methods have va-list on the stack - so that may not be an indicator of a problem.
21:14:48
drmeister
I've switched to the 'work' branch - this provides a working version of clasp that I'm adding changes to.
21:30:51
drmeister
Here's the poop - there is a flaw in the compiler code that we merged into dev that currently shows up when we compile babel. Just prior to merging the new compiler code into dev we pushed the working dev code to testing->preview->master. We are working on finding and fixing the compiler code - but that takes time.
21:31:30
drmeister
In the meantime - to keep working I I cherry-picked everything after the merge into a branch that built on the good 'testing' branch and I call it 'work'.
21:47:53
drmeister
kpoeck: We had a discussion on this end - it is difficult to unwind that one merge commit - we tried and got something that didn't build - although it should have because later commits didn't refer to the merge commit.
21:59:40
drmeister
(sigh) I had turned on cmp::*compile-file-parallel* in the wscript file - so even when I turn it off in compile-file-parallel the build system turned it back on.
22:21:42
drmeister
I put (compile-file-parallel <asdf>) in a loop - to try and reproduce a crash we are seeing.
23:51:25
drmeister
Bike. The changes to the compiler that were merged into dev. - did they cnange the llvm ir that was generated?
23:54:13
drmeister
Ok - I thought maybe dynamic environment changes might not effect the code generation