Re: [Yaml-core] How recursive anchoring works in Syck

[Sven V. <ski...@ko...>]

Let me first repeat the order in which
I think the methods are being called.

When the alias in encountered, bad_handler is called.
When the anchor is encountered, handler is called with
the id set to whatever bad_handler returned
and then handler is called again on the same structure
but with id == 0.

On Thu, Aug 07, 2003 at 11:03:03AM -0600, why the lucky stiff wrote:
> In Ruby, an instance of the YAML::Syck::BadAnchor class would be placed as *1. 
> We'll say this instance is represented in Syck by a SYMID of 15.

Were should I get a valid SYMID from ?
Isn't 0 a valid SYMID ?

rb_syck_bad_anchor_handler calls syck_new_map;
I call syck_new_str.  Is there a fundamental difference
wrt ->id ?

> So when the real anchor '1' is created, Syck passes the SYMID of 15 in as that 
> SyckNode's ID.   This is the only case in which a SyckNode will be given an 
> ID before being passed into the handler.
> 
> We can then find the original BadAnchor in our symbol table and overwrite it 
> with the Hash node.  In Ruby, we actually swap the entries of the BadAnchor 
> and the Hash in the symbol table.  That way the BadAnchor can be garbage 
> collected by Ruby rather than doing it manually.

So do you actually create the hash when handler is called
with SYMID != 0 ?
The return value seems to be ignored, so I gather it will
not be passed to the enclosing structures.
That's, I guess, why handler is called a second time on the
same structure; persumably to actually create the thing.
But how do you know at that time (the second time handler
is called for the same structure), that it corresponds
to an anchor ?

At first I though you might be able to use the SyckNode *
that is being passed in and check whether it equals the
value of a previous invocation, but SyckNodes get freed
from time to time, so you might get false positives.

> I think part of what is confusing the matter is that you are passing zero 
> around.  Try to develop a permanent solution for bad anchors right away so it 
> will be obvious to users what is happening.

I don't have any users.  I'm still trying to understand how syck
works.

> 
> See the Ruby extension for more examples of all this.  Good luck!

That's exactly what is getting me confused.
I've never written (or even read) a Ruby extension.

In rb_syck_parse_handler, I can't see where the value of id
is being checked or how it would know what the outcome of
the second invocation will be during the first invocation.

As you can see, I'm still very much confused.
Any further hints will be appreciated.

skimo