On Apr 14, 7:20 pm, "Edward K. Ream" <[EMAIL PROTECTED]> wrote:
> I just pushed the latest code to the unified-nodes branch. This code
> can now go through all of Leo's startup logic **provided** that the
> code that reads leoSettings.leo and related files is disabled.
I forgot to mention that
On Apr 14, 8:23 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.
I just pushed the latest code to the unified-nodes branch. This code
can now go through all of Leo's start
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
> > displ
On Mon, 14 Apr 2008 10:01:16 -0500
"Edward K. Ream" <[EMAIL PROTECTED]> wrote:
> > 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 previousl
On Mon, Apr 14, 2008 at 9:58 AM, Terry Brown <[EMAIL PROTECTED]>
wrote:
>
> On Mon, 14 Apr 2008 01:17:37 -0700 (PDT)
> derwisch <[EMAIL PROTECTED]> wrote:
>
> > What about unknownAttributes of vnodes and tnodes? What will the
> > distinction in future be?
>
> I think the way to retain the context
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 relationsh
On Mon, 14 Apr 2008 01:17:37 -0700 (PDT)
derwisch <[EMAIL PROTECTED]> wrote:
> What about unknownAttributes of vnodes and tnodes? What will the
> distinction in future be?
I think the way to retain the context distinctions you get from vnodes
will be through position dependent rendering of nodes
On Mon, 14 Apr 2008 08:09:00 -0500
"Edward K. Ream" <[EMAIL PROTECTED]> wrote:
> 6. It looks like the new code will work unchanged in both the DAG and
> graph worlds.
This is great. I was never really a fan of the previous great graph
aha that graphs could be represented in trees, anything can
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 gue
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:
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 vn
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
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
On Sun, Apr 13, 2008 at 4:29 PM, Edward K. Ream <[EMAIL PROTECTED]> wrote:
>
> On Sun, Apr 13, 2008 at 4:10 PM, Kent Tenney <[EMAIL PROTECTED]> wrote:
>
>
> >
> >
> > > I don't think so. In my present thinking it will not be possible to
> > > possible to access a *node's* parents--you can only ac
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 vnode
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 foll
On Sun, 13 Apr 2008 16:44:04 -0500
"Edward K. Ream" <[EMAIL PROTECTED]> wrote:
> > So, how do you iterate through a set of clones? You could search
> > the whole tree of course, any maybe iterating through clones is
> > uncommon enough that this would be ok. Or not?
>
> No, it's *much* easie
On Sun, Apr 13, 2008 at 4:15 PM, Terry Brown <[EMAIL PROTECTED]>
wrote:
>
> So, how do you iterate through a set of clones? You could search the
> whole tree of course, any maybe iterating through clones is uncommon
> enough that this would be ok. Or not?
No, it's *much* easier than this. Giv
On Sun, Apr 13, 2008 at 4:10 PM, Kent Tenney <[EMAIL PROTECTED]> wrote:
>
> > I don't think so. In my present thinking it will not be possible to
> > possible to access a *node's* parents--you can only access the parents
> of a node *at a particular position*. Positions give you parents instantl
On Sun, 13 Apr 2008 13:18:04 -0500
"Edward K. Ream" <[EMAIL PROTECTED]> wrote:
> > > 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 boo
> I don't think so. In my present thinking it will not be possible to
> possible to access a *node's* parents--you can only access the parents of a
> node *at a particular position*. Positions give you parents instantly.
Does this mean that Leo must load and process the xml before parents are k
On Sun, Apr 13, 2008 at 10:07 AM, Terry Brown <[EMAIL PROTECTED]>
wrote:
> > 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 :-)
True.
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 muc
On Sun, 13 Apr 2008 06:31:37 -0700 (PDT)
"Edward K. Ream" <[EMAIL PROTECTED]> wrote:
> DAG's are used in 3-D
> cad formats.
This is interesting stuff. Blender is a very cool 3D rendering system,
here's a page describing its outliner:
http://wiki.blender.org/index.php/Manual/The_Outliner
And
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:
sel
I believe it is possible to unify vnodes and tnodes into what I'll
just call a **unified node**, or node for short. A node will contain
headline, body text, attributes, and a (Python) list of the node's
children.
I have been searching for this Aha for more than 10 years.
The aha is that all we
26 matches
Mail list logo
