I have been looking at the Roslyn code base and noticed that they have two versions of syntax(One internal and one public). Often these appear to be referred to as "Red" nodes and "Green" nodes. I am wondering if anyone can explain what the reasoning is for having two versions of syntax like this.
From Persistence, Facades and Roslyn’s Red-Green Trees:
The “green” tree is immutable, persistent, has no parent references, is built “bottom-up”, and every node tracks its width but not its absolute position. When an edit happens we rebuild only the portions of the green tree that were affected by the edit, which is typically about O(log n) of the total parse nodes in the tree.
The “red” tree is an immutable facade that is built around the green tree; it is built “top-down” on demand and thrown away on every edit. It computes parent references by manufacturing them on demand as you descend through the tree from the top. It manufactures absolute positions by computing them from the widths, again, as you descend.
You, the consumer of the Roslyn API, only ever see the red tree; the green tree is an implementation detail. (And if you use the debugger to peer into the internal state of a parse node you’ll in fact see that there is a reference to another parse node in there of a different type; that’s the green tree node.)
Incidentally, these are called “red/green trees” because those were the whiteboard marker colours we used to draw the data structure in the design meeting. There’s no other meaning to the colours.
Related
I'm planning to use XNA to generate a model made up of multiple components. The model is created at run time from dynamic data. My model would be similar to a tree. The tree has a trunk, branches, leaves, cells, etc. I was planning to create classes for each content type such as branches that would encapsulate the leaves and so forth.
My question is where should I manage the the primitives for drawing the model?
Option 1) Each object manages it's own primitives or drawing objects. Drawing the tree would start with a call to tree->draw which would call truck->draw which would call branches->draw and so on.
Option 2) A 'master' method would traverse the tree collecting primitives into a collection then draw the collection independent of the tree.
There are benefits to both options but which follows a typical architecture for 3d graphics?
Thanks in advance.
That question really depends on the logical approach that you will use to store the data. If your tree has access to all of its children then it would be logically correct to call the tree.Draw() method once, and all subsequent draw methods will be called automatically according to your internal logic.
Moreover this approach can be performance efficient if you will render tree textures from a single spritesheet (eg. many subsequent draw calls using deferred rendering and some spritesheet(s)).
I'm attempting to build a tree, where each node can have an unspecified amount of children nodes. The tree is to have over a million nodes in practice.
I've managed to contruct the tree, however I'm experiencing memory errors due to a full heap when I fill the tree with a few thousand nodes. The reason for this is because I'm attempting to store each node's children in a Dictionary data structure (or any data structure for that matter). Thus, at run-time I've got thousands of such data structures being created since each node can have an unspecified amount of children, and each node's children are to be stored in this data structure.
Is there another way of doing this? I cannot simply use a variable to store a reference of the children, as there can be an unspecified amount of children for each node. THus, it is not like a binary tree where I could have 2 variables keeping track of the left child and right child respectively.
Please no suggestions for another method of doing this. I've got my reasons for needing to create this tree, and unfortunately I cannot do otherwise.
Thanks!
How many of your nodes will be "leaf" nodes? Perhaps only create the data structure to store children when you first have a child, otherwise keeping a null reference.
Unless you need to look up the children as a map, I'd use a List<T> (initialized with an appropriate capacity) instead of a Dictionary<,> for the children. It sounds like you may have more requirements than you've explained though, which makes it hard to say.
I'm surprised you're failing after only a few thousand nodes though - you should be able to create a pretty large number of objects before having problems.
I'd also suggest that if you think you'll end up using a lot of memory, make sure you're on a 64-bit machine and make sure your application itself is set to be 64-bit. (That may just be a thin wrapper over a class library, which is fine so long as the class library is set to be 64-bit or AnyCPU.)
In my small compiler I currently have a hand-made AST.
I was considering the idea of having a visitor that would look after nodes of a certain type X and would replace them by nodes of type X'. The trouble is that it seems that it isn't something easy to implement with the visitor pattern.
The only way I can see to make this work would be to have visit() methods to all kinds of nodes that could possibility have a node of type X as child and put my node replacing logic there, but there may be lots of those nodes. Plus, if I later decide to add a new kind of node, I incur the risk of not remembering to check for that new special case in this visitor.
What's the problem I'm trying to solve:
For the current case I have in my tree nodes of type FunctionCall that convey only the name of a operation as well as its parameters.
I'd like to substitute those with a MethodInvocation, with the appropriate OOish transformation:
m(A, B) -> A.m(B)
m(n(A, B), C) -> (A.n(B)).m(C)
Of course this can be done in a thousand of different ways, being the easiest one to simply try to consider only a Call class in which there may or may not exist a target, but I'd like to be as explicit as possible (that is, using different kinds of nodes), to express different things, if possible.
When a TransformToAncestor is called what Matrices are used to build up the resultant GeneralTransform? When step into the pdb all I see is a TransformField with a signature like:
private static readonly UncommonField<Transform> TransformField = new UncommonField<Transform>();
being used in the resultant GeneralTransform
Nothing beats Reflector. Especially while it's still free ;)
The code is hairy enough but can be followed. Basically it walks up the visual tree and groups the transforms but the entire thing is much more complicated and I never really had an interest to dig that deep into it. Look into Visual.TrySimpleTransformToAncestor for the gory details.
To answer the question, UIElement is never used explicitly of course; the transform is retrieved through an Effect (the UncommonField you mentioned), so I'm guessing that transforms in general are applied as effects, hence you can get them through this shortcut from anywhere, but that's just infrastructure and implementation details and I'm most likely wrong :)
I'm building a gui component that has a tree-based data model (e.g. folder structure in the file system). so the gui component basically has a collection of trees, which are just Node objects that have a key, reference to a piece of the gui component (so you can assign values to the Node object and it in turn updates the gui), and a collection of Node children.
one thing I'd like to do is be able to set "styles" that apply to each level of nodes (e.g. all top-level nodes are bold, all level-2 nodes are italic, etc). so I added this to the gui component object. to add nodes, you call AddChild on a Node object. I would like to apply the style here, since upon adding the node I know what level the node is.
problem is, the style info is only in the containing object (the gui object), so the Node doesn't know about it. I could add a "pointer" within each Node to the gui object, but that seems somehow wrong...or I could hide the Nodes and make the user only be able to add nodes through the gui object, e.g. gui.AddNode(Node new_node, Node parent), which seems inelegant.
is there a nicer design for this that I'm missing, or are the couple of ways I mentioned not really that bad?
Adding a ParentNode property to each node is "not really that bad". In fact, it's rather common. Apparently you didn't add that property because you didn't need it originally. Now you need it, so you have good reason to add it.
Alternates include:
Writing a function to find the parent of a child, which is processor intensive.
Adding a separate class of some sort which will cache parent-child relationships, which is a total waste of effort and memory.
Essentially, adding that one pointer into an existing class is a choice to use memory to cache the parent value instead of using processor time to find it. That appears to be a good choice in this situation.
It seems to me that the only thing you need is a Level property on the nodes, and use that when rendering a Node through the GUI object.
But it matters whether your Tree elements are Presentation agnostic like XmlNode or GUI oriented like Windows.Forms.TreeNode. The latter has a TreeView property and there is nothing wrong with that.
I see no reason why you should not have a reference to the GUI object in the node. A node cannot exist outside the GUI object, and it is useful to be able to easily find the GUI object a node is contained in.
You may not want to tie the formatting to the level the node is at if your leaf nodes may be at different levels.