Re: MPS: treesit

[Yuan Fu <casouri@gmail.com>]

> On Jun 25, 2024, at 9:54 PM, Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
> 
> Yuan Fu <casouri@gmail.com> writes:
> 
>>> On Jun 25, 2024, at 12:44 AM, Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
>>> 
>>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>> 
>>>> Can somone help and explain how this works in treesit.c? Where is the
>>>> Lisp_TS_Parser stored and how/where is the TSParser * that gets passed
>>>> to the treesiter dylib translated to the Lisp_TS_Parser *?
>>> 
>>> Forget that question, I see it, TSInput and so on. But I'd be interested
>>> if there are other such constructs in treesit?
>>> 
>> 
>> If you mean tree-sitter struct that’s exposed to lisp, there are
>> Lisp_TS_Parser, Lisp_TS_Node, and Lisp_TS_Query. Lisp_TS_Node is a
>> node in the parser tree, Lisp_TS_Query is a lazily compiled query.
>> Tree-sitter queries, like regexp, are compiled from string to
>> tree-sitter’s internal struct before being used. HTH.
> 
> Hi Yuan!
> 
> In the TSInput case that I could fix, TSInput::payload, a void *, is set
> to point to a Lisp_TS_Parser, and the read callback in treesit.c gets
> access to that parser because tree-sitter passes it the payload pointer.
> 
> What happened with igc is that the Lisp_TS_Parser object was moved in
> memory, which is normal because MPS is a copying collector, but the
> TSInput::payload pointer wasn't changed accordingly because I didn't
> know that a reference was hiding there.
> 
> My question is if there is a second case like that. A pointer to a
> Lisp_TS_xy or a Lisp_Object for such an object that is hiding in a place
> that isn't apparent. At least for someoneo like me :-).

Ah, I see. I don’t think there’s another one.

Yuan