freenode/#clasp - IRC Chatlog
Search
23:32:04
drmeister
https://github.com/drmeister/cando/blob/dev/src/lisp/leap/antechamber-type-definition-parser.lisp#L519
23:43:46
drmeister
(trace esrap:parse) isn't resulting in trace messages - so I'm assuming it's expansion is used.
23:55:08
Bike
i don't know if it's a cause, but having an entire special operator broken is not good
0:05:50
Bike
oh, and about esrap working a few days ago - does that mean dev from a few days ago, or shiho's much older dev that she only recently updated?
0:14:30
Bike
i cut down allocate-instance to allocating the memory and setting a few C++ fields, so that's nice
0:34:11
drmeister
You think so? Not the (LET ((EXPR-FUN10693 (LOAD-TIME-VALUE (ESRAP::COMPILE-EXPRESSION 'WILD-ATOM-LINE)))) ...)
0:34:53
Bike
besides, if the compile-expression was hanging, it would hang when you load the fasl, right? not when you actually do the parse.
0:35:05
drmeister
I was thinking the load-time-value was wrong and that was screwing up the funcall - but ok.
0:36:37
Bike
so you can do something like (let ((fun (esrap::compile-expression 'wild-atom-line))) (print "done with compile") (funcall fun text 0 (length text))) and see how that goes
0:36:55
drmeister
This (1) stick a print statement in the code (2) compile everything (3) run it - is driving me nuts
2:46:59
drmeister
I've held off debugging issues because I wanted source tracking - and it's in the cst branch.
2:47:31
drmeister
Here I am in the 'dev' branch debugging a nasty problem in compiling esrap expressions trying to read freaking tea leaves to figure out what is wrong.
2:48:12
drmeister
If I can't crack this in the next couple of edit/rebuild cycles I'm merging it into 'cst' and I'll try debugging it there.
2:55:03
Bike
oh byt the way you mentioned having a make-unspecial function- i added a (setf core:specialp) in dev that kind of subsumes that
2:55:42
drmeister
Ok - can you remind me of that tomorrow and I'll remove make-unspecial and change my port of maxima
10:00:21
scymtym
drmeister: i can't pinpoint the problem based on what i have seen in the logs. infinite loops in esrap parsers are usually caused by repetition expressions with child expressions that can succeed without consuming input such as (* (? "a")). also, esrap has a tracing facility that could help (esrap:trace-rule 'RULE :recursive t)
11:27:30
drmeister
I'm going to pull another copy of clasp and cando, merge dev into cst and debug this issue in esrap with the help of source tracing and esrap trace.
11:28:13
drmeister
Something broke in the last couple of days and I need to fix it fast - so that we can get this very important demo running for next Thursday.
11:28:33
drmeister
Or by the end of today I have to start regressing to older versions to find one that works.
11:30:03
drmeister
We can't render molecules because that requires parsing sybyl type rules and that requires esrap .