freenode/#clasp - IRC Chatlog
Search
19:52:27
karlosz
calling refresh-local-iblocks in eliminate-catches is just a recipe for trouble when eliminate-catches is called in interpolate function while the IR is in an inconsistent state...
19:53:32
karlosz
we need to think up of something better for reachability and refresh local iblocks since that's becoming more and more of a disaster
19:54:19
karlosz
spent a couple hours just chasing the fact that refresh local iblocks was deleting some reachable stuff due to a basic block being shared between two functions
19:56:09
Bike
and you load the language.smarts.parser and esrap and architecture.builder-protocol systems with quicklisp?
20:00:28
Bike
look, i'm sorry, but i have no understanding of the context here. i don't know how to reproduce any of this explain this like i'm a five year old compiler developer
20:00:55
drmeister
No no no - don't worry. I'm banging away here to try and get a simple reproducer.
20:01:09
Bike
as for what i'm currently focusing on, redoing the constant handling might have screwed with the One Weird Trick we use in defcallback
20:04:39
scymtym
also interesting: what does (architecture.builder-protocol:with-builder (:cando) (funcall (esrap::compile-expression 'language.smarts.parser::smarts) #1="[$([N]-[C])]" 0 (length #1#))) return?
20:55:52
scymtym
drmeister: another easy experiment would be TRACEing architecture.builder-protocol:{make-node,finish-node} and compare the results
21:02:08
scymtym
this call is not returning constant data, i assume? | <2 (ARCHITECTURE.BUILDER-PROTOCOL:MAKE-NODE (NIL))
21:05:26
drmeister
It's the next line after that that they diverge - so I think we are on the same page.
21:08:53
scymtym
a grammar rule that produces a syntax tree node normally does the equivalent of (let ((n (make-node BUILDER KIND INITARGS))) (relate BUILDER RELATION n child) (finish-node BUILDER n))
21:09:55
scymtym
in this case, it seems MAKE-NODE produces some placeholder and FINISH-NODE produces the final result (or some not-traced RELATE call does it)
21:21:57
drmeister
scymtym: You said: "(let ((n (make-node BUILDER KIND INITARGS))) (relate BUILDER RELATION n child) (finish-node BUILDER n))"
21:24:53
scymtym
i think https://github.com/clasp-developers/language.smarts/blob/future/src/smarts/parser/grammar.lisp#L26
21:26:36
scymtym
drmeister: maybe add (esrap:trace-rule 'bond-atom-pattern) and (esrap:trace-rule 'branch) to your instrumentation
21:31:44
drmeister
Is the thing that generates the calls to make-node, relate and finish-node a macro? Is it one of these rules?
21:34:45
scymtym
yes, https://github.com/cando-developers/cando/blob/master/src/lisp/smarts/src/smarts/parser/grammar.lisp#L32
21:35:36
scymtym
there is one more thing you can TRACE: ARCHITECTURE.BUILDER-PROTOCOL:MAKE+FINISH-NODE+RELATIONS. that's what the NODE* macro uses under the hood
21:45:56
drmeister
The macroexpansion of this: https://github.com/cando-developers/cando/blob/master/src/lisp/smarts/src/smarts/parser/grammar.lisp#L32
21:47:47
scymtym
but there is NODE* in there which expands to MAKE+FINISH-NODE+RELATIONS which calls MAKE-NODE, REDUCE with RELATE and finally FINISH-NODE
21:49:22
drmeister
Where does the reduce get introduced? In make+finish-node+relations? Looking for it...
21:50:19
scymtym
https://github.com/scymtym/architecture.builder-protocol/blob/master/src/protocol.lisp#L227
21:54:03
scymtym
ADD-RELATIONS has all the good stuff, local functions, tail calls, local functions as arguments
21:59:15
scymtym
ACTION sees https://github.com/scymtym/architecture.builder-protocol/blob/master/src/protocol.lisp#L149 . starts sweating
22:03:00
scymtym
the hairy code above shouldn't get involved very much since RELATE is called without additional keyword arguments
22:12:27
drmeister
So in the non working version the REDUCE is not being called with the correct argument.
22:13:18
drmeister
The NIL argument in the second line should be the sequence in (* :element (#<ATOM-TEST :id> #<BOND-TO-ATOM-TEST :id>))
22:31:06
drmeister
I haven't worked with REDUCE much - but we might be able to build a reproducer with this.
22:34:51
drmeister
(ARCHITECTURE.BUILDER-PROTOCOL:ADD-RELATIONS :CANDO (cons NIL nil) '((* :ELEMENT (:foo :bar))))
22:41:09
kpoeck
drmeister all your examples work fine in my icando-boehm using bir (code from yesterday)
22:49:30
drmeister
(ARCHITECTURE.BUILDER-PROTOCOL:ADD-RELATIONS :CANDO (cons NIL nil) `((* :ELEMENT (,(core:make-cxx-object 'chem:atom-test :sym :C :test :sapelement) ,(chem:make-bond-to-atom-test :sabany-bond nil)))))
0:45:57
karlosz
probably the set implementation is responsible. if we transparently swap that out for a list we should be able to control for it
1:57:07
drmeister
./icando-boehm -f nosmarts disables all compilation of smarts code during startup.
1:57:31
drmeister
Then you can initialize some smarts using (chem:initialize-smarts-users) and I get ...
3:53:50
drmeister
::notify Bike I can reproduce the problem pretty well now - but it's not convenient. I created the "nosmarts" cando branch (cando - not clasp) and you build the quicklisp code using ./icando-boehm -f nosmarts
3:54:26
drmeister
::notify Bike To reproduce the problem use: ./build/boehm/icando-boehm -e '(trace ARCHITECTURE.BUILDER-PROTOCOL:ADD-RELATIONS)' -e '(trace reduce)' -e '(chem:initialize-smarts-users)' -e "(core:quit)"
3:55:31
drmeister
::notify Bike You can build this with the master branch of clasp and you can compare the output. There are calls to REDUCE that are getting NIL instead of the correct argument.