1

Closed

Verify use of _templateBuffer in TemplateProjectionBuffer.UpdateTemplateSpans

description

I couldn't find a way to make a comment directly on a line. The reference was added in commit d7a32bd6a4b47b185cc282b600ae7a83e5a37aa4, and as of right now is on line 361 of TemplateProjectionBuffer. Here is the line in context:
newProjectionSpans.Add(
    new CustomTrackingSpan(
        _templateBuffer.CurrentSnapshot,
        sourceSpan,
        PointTrackingMode.Positive,
        PointTrackingMode.Negative
    )
);
Can you verify that this use of _templateBuffer is correct, and should not be a reference to _diskBuffer?
Closed Mar 20, 2013 at 10:32 PM by Ptools

comments

dinov wrote Mar 4, 2013 at 8:54 PM

This looks correct. We’re actually building up 2 different lists here:
        List<object> newProjectionSpans = new List<object>();   // spans in the projection buffer
        List<SpanInfo> newSpanInfos = new List<SpanInfo>();     // our SpanInfo's, with spans in the on-disk buffer
With the newProjectionSpans being the spans we want to project into the projection buffer, and newSpanInfos which are tracking how all of the spans are correlated with the on-disk buffer.

When we create the buffer initially we create a HTML buffer and a template buffer which map the on disk buffer to a buffer with the desired content type. We then want to project those buffers into the projection buffer so that the final buffer gets the intermixed content types. If we were to map just from the on disk buffer here to the projection buffer then we’d lose the classification of the templates.

And then we maintain the list of disk spans separately so that we can do any updates when the template tags are getting added/removed and it’s invalidating our current set of regions.

Is there something specifically you’re trying to accomplish or fix that we can help with?

sharwell wrote Mar 4, 2013 at 10:56 PM

I was experimenting with using projection buffers in another application. I observed a problem when I modified the code to create the initial _templateBuffer as empty instead of containing the entire file, using the following tracking span in CreateTemplateBuffer.
_diskBuffer.CurrentSnapshot.CreateTrackingSpan(
    0,
    0,
    SpanTrackingMode.EdgeNegative,
    TrackingFidelityMode.Forward
)
This ended up failing due to the use of _templateBuffer mentioned above (ArgumentException due to source span out of range). I noticed that on lines 340 and 396 a tracking span based on _diskBuffer was added to newProjectionSpans, so I modified my code to use _diskBuffer for the other one as well and the problem was resolved. Since you don't calculate the source spans in exactly the same way as I do, I could not be sure that the difference was a bug in your code, which is why I filed this report as a "verify" instead of as a bug.

sharwell wrote Mar 4, 2013 at 11:37 PM

Now that I look again, it appears that the sourceSpan derived from the TemplateToken is always using indexes based on _diskBuffer, suggesting that _diskBuffer.CurrentSnapshot is what you want for the tracking span here.

dinov wrote Mar 5, 2013 at 5:17 AM

While the span may have come from _diskBuffer, it's applicable to both _htmlBuffer and _templateBuffer. That's because both of those buffers are elision or projection buffers mapping all of _diskBuffer. Their only purpose really is to change the content type and get a different classifier to run over their contents.