libera/#sicl - IRC Chatlog
Search
15:30:02
scymtym
beach: that is possible although i can't find the offending call right away. i will have to look later as i'm out of time for now
15:34:53
beach
test/concrete-syntax-tree/read.lisp (defmethod eclector.parse-result:make-source-range ...)
16:02:07
Bike
maybe this isn't even fixup related somehow... i mean the problem seems to be a cst ending up as nil, and csts are just standard objects
16:15:45
scymtym
Bike: i'm mostly afk but you could try and check whether the MAKE-EXPRESSION-RESULT :AROUND method returns NIL instead of a CST at any point
16:51:52
Bike
...the one in parse-result, since there's apparently more than one file by that name. i am not smart today
17:04:34
Bike
https://github.com/s-expressionists/Eclector/blob/sharpsign-equals-protocol/code/parse-result/labeled-objects.lisp#L106 it's calling make-expression-result for this line. the object looks ok, but the cst child corresponding to :definition is nil for some reason
17:04:59
Bike
i suspect this is some clasp weirdness rather than eclector's fault, but i don't know eclector's logic well enough to figure out exactly what's happening yet
17:09:09
Bike
this code is referring to labeled-object-state returning a third value, which is not what the manual says
17:14:35
Bike
the method for parse-result-client returns a third value... so maybe that method isn't being invoked here somehow, though i don't understand how that could be possible
17:21:12
Bike
yeah, it'll take me a while to untangle the logic here. but i think what might be happening is that we're reading the actual symbol :DEFINITION, and make-expression-result gets called on that, and it gets to the special cst-client method that uses the third return value of labeled-object-state, except labeled-object-state doesn't return a third value
17:22:02
Bike
possibly because make-expression-result is itself not being called with a CHILDREN that's a %wrapper, because this :DEFINITION is actually in the source instead of arising internally within eclector somehow?
17:23:08
Bike
maybe i should just try reproducing this sin an environment with decent debugging and go from there
17:55:34
Bike
i get the same error just trying to read-from-string "(4 :definition 5)" with clasp's cst client. let me see if i can reproduce this on sbcl
18:00:23
Bike
and, if i change the make-expression-result method on :definition to also require children to be a %wrapper, clasp loads eclector fine
18:02:25
scymtym
big oversight, sorry. i guess i will make something so that the specializers can be (eql *definition*) and (eql *reference*) respectively
18:06:39
Bike
ah, don't worry about it, if this even is the actual problem... in band signaling is hard
21:26:52
scymtym
seems to be the actual problem. i added tests that read the eclector source code with and without parse results/csts. that should somewhat guard against this type of problem in the future
0:26:58
Bike
masinter: subgraph search is reasonably common https://en.wikipedia.org/wiki/SMILES_arbitrary_target_specification