freenode/#clasp - IRC Chatlog
Search
23:23:43
drmeister
I'd like to run the ansi tests - where are we with them? kpoek has been doing some great work with those.
23:28:40
drmeister
I'm using (trace esrap:parse) and I've put a print statement in front of the call to (esrap:parse ...)
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)