Re: Eureka!!! Unified nodes
On Sun, Apr 13, 2008 at 06:31:37AM -0700, Edward K. Ream wrote: It appears that Leo will, relatively soon, move to the unified-node world. Compatibility with existing code and scripts should be no big deal. Indeed, unified nodes will contain .v and .t ivars, inited in the ctor as follows: self.v = self self.t = self [...] This is all really exciting and very cool! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Eureka!!! Unified nodes
On Sun, Apr 13, 2008 at 5:23 PM, Terry Brown [EMAIL PROTECTED] wrote: find-next-clone is what I'm talking about, how's that done? Just like it has always been done. That is, p = c.currentPosition() is a (new) position. We traverse the tree, starting from p, looking for the next position p2 such that p2.v == p.v. I haven't looked at the code, but it shouldn't have to change. Actually, the present code might look for p.v.t == p2.v.t, but since v.t == v for all v we can live with this until a later cleanup. BTW, as hinted above, I have chosen to retain the convention that p.v is a node. I don't want to use n as the name of the typical var containing a node because n has the strong connotation of being an integer. And why bother changing lots of code for nothing? Edward --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Eureka!!! Unified nodes
On Mon, Apr 14, 2008 at 3:17 AM, derwisch [EMAIL PROTECTED] wrote: On Apr 13, 3:31 pm, Edward K. Ream [EMAIL PROTECTED] wrote: That is for any node n, n.v == n, n.t == n, n.v.t == n. In other words, if there is only one kind of node, the problem of distinguishing between vnodes and tnodes becomes pretty easy :-) What about unknownAttributes of vnodes and tnodes? What will the distinction in future be? Nodes will have an .unknownAttributes ivar. But since there is only one kind of node, there can only be one kind of .unknownAttributes ivar. This is a good place to restate the fundamental difference between the old and new (unified nodes) world. In the new world, **exactly the same node can appear in multiple places on the screen.** In particular, **clones are exactly the same node** (as are joined nodes, i.e., nodes in shared subtrees of cloned nodes). One trigger to the eureka was the realization that joined nodes **already are** exactly the same node in the present world. The eureka merely extends this fact to cloned nodes. So there **can be no distinction in the node** in the new world based on where a node appears in the outline. The node **doesn't know** where in the outline it is. Only positions place a node in the outline. If you must make distinctions based on positions, you can do that with secondary data structures. You could even put those data structure in v.unknownAttributes. But Leo can't do that work for you: a node is the same wherever it appears in the outline. Edward --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Eureka!!! Unified nodes
On Mon, Apr 14, 2008 at 8:09 AM, Edward K. Ream [EMAIL PROTECTED] wrote: I think that's about it for now. It truly is thrilling to be able to simplify and generalize this fundamental code. Naturally, the first thing I did was merge the tnode and vnode ctors into the node ctor. It was fun: there is a *lot* of mostly confusion duplication in vnodes and tnodes. Merging the nodes just cuts through all that confusion. Edward --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Eureka!!! Unified nodes
On Mon, Apr 14, 2008 at 8:19 AM, Edward K. Ream [EMAIL PROTECTED] wrote: Nodes will have an .unknownAttributes ivar. But since there is only one kind of node, there can only be one kind of .unknownAttributes ivar. It might be possible to associate permanent data with positions. My guess is that some AI would be needed when the outline changes. I'm not going to do this now, but I'll keep the possibility in the back of my mind... Edward --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Eureka!!! Unified nodes
On Mon, Apr 14, 2008 at 1:01 AM, Kayvan A. Sylvan [EMAIL PROTECTED] wrote: On Sun, Apr 13, 2008 at 06:31:37AM -0700, Edward K. Ream wrote: It appears that Leo will, relatively soon, move to the unified-node world. Compatibility with existing code and scripts should be no big deal. Indeed, unified nodes will contain .v and .t ivars, inited in the ctor as follows: self.v = self self.t = self [...] This is all really exciting and very cool! Oh, it's better than that :-) This would be a good place to update you all on last night's code bashing. It's not in the unified-nodes branch yet. It will be soon, in a files call NEWleoNodes.py, NEWleoFileCommands.py, etc. That way I can run leoPy.leo in the unified-nodes branch without problem. Notes: 1. I started the review/rewrite of the crucial position methods such as p.moveToX methods. They are the acid test: if they can be done, then everything else, including iterators, can be done. In fact, the new code is either unchanged or simpler than the old code. So it looks like the first, crucial test passes. 2. It turns out, as Terry suggested, that having a v.parents list is required so that we can quickly implement p.isCloned and p.v.isCloned. So the symmetry between parents and children will exist explicitly. 3. A few changes to the position class are required. - Each position will have a new ivar, p.childIndex, indicating the index of p.v in p.parent().v.children. This new ivar *replaces* the old v._next and v._back links. I hadn't realized this so clearly before. Do you see how clever this is? Positions allow us to reconstitute the sibling order for v, but *only* in the context of a position. - Similarly, p.stack contains tuples (v,childIndex), where v is the parent node, and childIndex is the position of v in v.parent().v.children. With old positions, p.stack contained just vnodes. - New positions now contain a full p.stack. That is, p.stack contains an entry for *every* parent of p. Old positions optimized this stack by only putting entries in the stack for clones. But a full stack is required now. Furthermore, having a full stack eliminates some very tricky and hard-to-understand code, namely p.vParentWithStack and the code that used it. 4. Last night I wrestled with the issue of how to find the hidden root node, the parent of all top-level nodes. This morning I came up with a clever solutions, one that would have spared us all considerable work previously. The trick is to require a 'context' argument to all vnode ctors. This will be a commander, but the *only* requirement for the context object c is that c.hiddenRootNode exist. In effect, the context is a lightweight adapter class. Had I come up with this solution earlier, I would not have bothered to remove the c argument from vnode constructors (or was it position constructors?) This would have saved everyone the bother of having to change existing code. Perhaps more importantly, re-imagining the c argument as a context means that the new node class is *already* essentially independent of Leo's commander class, which was the whole point of removing the c argument from the ctor. 5. Much of the tricky link code in the position and vnode classes just disappears. 6. It looks like the new code will work unchanged in both the DAG and graph worlds. Of course, the graph world must define different iterators, but we knew that. The hidden root node is optional in the graph world. If it exists, it denotes some designated top-level nodes, and allows those nodes to be siblings. But it need not exist, and perhaps should not exist in some sense: without it, *any* node is potentially the root of all traversals. But clearly, we can deal with these minor issues later. 7. I've removed the .v ivar from nodes. v.v should never exist in Leo today, so there is no need for this ivar. The new position class will still use the .v ivar, so p.v will still exist, and all the code that reverences v.t, p.v and p.v.t will just work. (Or almost all the code :-) I think that's about it for now. It truly is thrilling to be able to simplify and generalize this fundamental code. Edward --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Eureka!!! Unified nodes
On Mon, 14 Apr 2008 10:04:30 -0500 Edward K. Ream [EMAIL PROTECTED] wrote: I think the way to retain the context distinctions you get from vnodes will be through position dependent rendering of nodes. You might need to inspect p.stack to work out the context the node is displayed in. I don't think anything will be lost, vnodes were basically a display context too. Possible, but then you have to remember stuff about positions, which Not necessarily, or at least not for the level of context resolution I had in mind. A particular application (plugin) might just need to know whether or not there's a @todo node in the current node's ancestors (p.stack) to know whether or not to use certain parts of the node's uAs. I guess vnodes would allow you to distinguish between different instances of the same type of context, which determining context from p.stack won't, but I'm not convinced you need to that, or if you do you can use an intermediate ancestor. Cheers -Terry seems like an heroic solution to something that shouldn't be a problem at all. I discussed this in detail in another thread. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Eureka!!! Unified nodes
On Mon, Apr 14, 2008 at 9:48 AM, Terry Brown [EMAIL PROTECTED] wrote: This is great. I was never really a fan of the previous great graph aha that graphs could be represented in trees, anything can be represented in trees, or strings, or base64, after all. But now more complex relationships can actually be integrated in Leo so much more tightly. Well, I'm still a huge fan of the Great Graph Aha. As I said in another reply, the essence of understanding complex data is creating multiple user-controlled views. The graph world would be a step in the wrong direction. So the (non-urgent) issue I see is how could cyclic graphs be included in a Leo outline that was mostly DAG, in some way that Leo knows that from this node and beyond cycles may occur. I said previously that limiting the expansion of nodes is a good first step. We could also have directives that limit expansion to n number of visits. But I remain skeptical that the kind of graph you show really is worth viewing in an outline. It seems seems more than plausible that representing graphs in a Leo tree is all that is needed. No need to argue further until the unified node world is much farther along. Perhaps somebody will produce a plugin that will show the true power of general graphs :-) Edward --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Eureka!!! Unified nodes
On Apr 13, 7:20 am, Edward K. Ream [EMAIL PROTECTED] wrote: It appears that Leo will, relatively soon, move to the unified-node world. Compatibility with existing code and scripts should be no big deal. Indeed, unified nodes will contain .v and .t ivars, inited in the ctor as follows: self.v = self self.t = self That is for any node n, n.v == n, n.t == n, n.v.t == n. In other words, if there is only one kind of node, the problem of distinguishing between vnodes and tnodes becomes pretty easy :-) Similarly for positions. p.v == p.n == p.v.t. I'll probably write scripts to eliminate references to v and t from Leo's core (and plugins) but it is my intention that old scripts works as before. There will be instances where this could produce weird, inefficient or even incorrect code. We shall see... Edward P.S. I just finished talking to my brother Speed. He points out that several interesting projects use DAG's, and that work is happening in devising a DAG-based file format for holograms. DAG's are used in 3-D cad formats. Apparently representing holograms as DAG's improves compression. Anyway, a simplified, more flexible format for .leo files could make Leo relevant for such projects. This will encourage me to make the format of .leo files as straightforward, honest, (optionally) compressible and user-customizable as possible. EKR --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Eureka!!! Unified nodes
On Sun, 13 Apr 2008 05:20:54 -0700 (PDT) Edward K. Ream [EMAIL PROTECTED] wrote: - Unified nodes are *precisely* the nodes contemplated in the graph world. /me grins Recall that a key part in my rejection of the graph world was a realization that iterators in any graph world are much more complex than Leo's iterators. True, but now you're on the slippery slope :-) It seems to me that hard part with the new node system will be not implementing general graph world accidentally. I.e. it's up to the interface to stop the user linking a node in a way that creates a cycle, and the interface has to do that to avoid the more complicated iterators (for now, at least :-) P.S. As a matter of symmetry, a unified node could contain a list of the node's parents. This is not necessary: it is analogous to double- linking a linked list. Unnecessary, but a big speed boost (at the cost of memory) if you wanted to access the list of a nodes parents. Seems to me that the concept of parent only exists as a side effect of the position. What if a node simply had a list L of all nodes to which it connects, and functions that return a list of children or iterate children simply omit any members of L that point to p.parent? So for DAG world, iterating children requires a position? Nah, I guess it's not quite that simple, it doesn't account for loops back to the parent through an intermediate node. But of course that's not a concern if you know the interface doesn't allow creation of such loops. I think this is a great path your heading down - get all the current DAG machinery working on top of the new structure, which sounds doable, then there'll be some solid ground from which to explore the possibilities for cyclic graphs. Bearing in mind that this is all future stuff not to be played with before the DAG stuff is done, a node could have two lists; a list of parents and a list of children, or a single list of tuples (o, d) where o is anOther node to which the current node connects and d is the direction of the connection. These two approaches are equivalent and the two list option might be more convenient, anyway they're equivalent so it doesn't matter much. Then iterators could have three flags, 'unique' as you discussed, 'directed' meaning pay attention to direction (don't follow links to parents), and 'cyclic' meaning don't shield me from cycles in the data (the default being to shield the caller from cycles by maintaining a list of visited nodes). Not sure how unique and cyclic interact, unique makes sense is a DAG+clones context, where cyclic doesn't apply. Again, none of that matters until the DAG stuff is done. Anyway, exciting news. Cheers -Terry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
