freenode/#clasp - IRC Chatlog
Search
18:18:00
drmeister
My macbook pro is going back to Apple for a second time - so I'm going to be crippled for at least another week.
18:19:28
drmeister
So you build cando with BIR and it worked. Did you try running icando-boehm to build all the quicklisp?
18:26:10
drmeister
Well - ok then - that means that BIR works with cando pretty much. I'll try it with the jupyter stuff.
18:53:43
drmeister
I cloned a fresh clasp/cando and switched to 'bir' and I get this while running icando-boehm...
19:15:42
drmeister
Sh*t - a ~ (tilde) in a SIMPLE_ERROR(BF("....~....")) string messes up error printing. It's not fatal - just annoying.
19:24:57
drmeister
What I'm seeing is I have a case where esrap:parse is returning NIL when it shouldn't be.
19:29:12
Bike
https://github.com/cando-developers/esrap/blob/master/src/macros.lisp#L64-L69 this is probably not related, but we could have this use the actual macro
19:30:34
scymtym
the compiler-macro takes care of keyword arguments and compiles constant expression at load-time
19:33:02
scymtym
yeah. i probably wanted to wait for some quicklisp-trickle-through kind of thing before depending on the library. and then i forgot
19:35:39
Bike
also unrelated, but more-conditions looks like it's doing some stuff i'm doing in the error reporting in cleavir
19:37:25
drmeister
I started putting print statements in the esrap:parse compiler macro generated code - it's going through my print statements.
19:38:53
scymtym
drmeister: this may be too coarse for compiler bugs (if you are suspecting that), but (esrap:trace-rule … :recursive t) can be really useful for tracking down problems
19:40:00
drmeister
You've got a pretty rare bit of code there -my guess is that it's the BIR compiler not handling lambda calls properly.
19:41:11
Bike
shouldn't really be doing anything different with them... since it has &key it can't be inlined, even
19:43:05
Bike
is there some (parse ...) form that i can try? or do i need the entire grammar first or something
19:45:38
scymtym
Bike: you could change the compiler macro in the paste by replacing the (load-time-value (compile-expression …)) part with a lambda (lambda (a b c) :result) or similar. that should give hint regarding whether the macro or the compiled expression is the problem
19:48:02
Bike
i haven't used esrap. i don't know how to get code i can run for 'simple things like "[N]"'
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.