libera/#sicl - IRC Chatlog
Search
13:56:36
scymtym
Bike: sorry for bringing this up once again but did you get a chance to test the updated eclector changes?
13:57:28
Bike
ah, no, sorry, yesterday ended up being a bit hectic. i can do it today. i'll just get to a stopping point with what i'm doing first
14:11:52
beach
scymtym: Am I right that eclector.parse-result:make-source-range is deprecated, yet called by Eclector code, so that a style warning is issued, when Eclector is compiled?
14:19:08
Bike
without further changes to clasp from when i updated it for the earlier sharpsign-equals-protocol, i get an error where something wants a cst but gets nil. curious...
15:00:01
scymtym
beach: i renamed the source position and range functions so that their names are now in the ECLECTOR.BASE package (in order to be able to make source ranges for error conditions without circularly depending on the parse-result module). for backward compatibility, i added functions which use the old names
15:00:12
scymtym
the "delegation" logic includes a call from the "new" functions to the "old" functions. compiling this call generates the deprecation warning. i plan to remove the backward compatibility code some time in the future which should resolve the warning
15:02:13
scymtym
Bike: it is possible that, compared to the previous integration attempt, you have to adapt the logic for deciding whether an object is a finalized labeled object, a non-finalized labeled object or an ordinary object
15:05:39
Bike
wow, i think fixup-place has the most complicated lambda list i've ever seen in real code.
15:07:28
Bike
i don't understand what the circular-labeled-object-forms are for, so hopefully i can just leave that empty. the problem might just be that the fixup method didn't know about final/circular
15:07:56
scymtym
sorry. it was supposed to be like CASE but maybe the differences so substantial that it just ends up confusing
15:08:55
scymtym
you can likely ignore that case. at the moment, that case is used only for fixing up hash tables
15:23:45
Bike
just wondering if the clasp-specific structures i'm fixing up are similarly complicated
15:24:18
scymtym
something like (let ((eclector.reader:*readtable* *hashtable-readtable*)) (eclector.reader:read-from-string "#1=(#2=#{#1# (b #2#)})")) when FIXUP is called for #2= before the FIXUP call for #1=. this is hard to write with lisp syntax but there is a test case that constructs an object graph which triggers the case
15:25:54
beach
scymtym: Sure, but it seems the test directory refers directly to the deprecated function.
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