The important information is ONLY in the Leo file. @thin is an
impoverished coping mechanism. @auto functions correctly for a tiny
fraction of the code I'm concerned with (it fails on perl and ruby,
and having Leo-structured those by hand, I'm convinced that automated
parsing is either theoretically impossible (perl) or close to useless
(riuby)).
For instance, when studying code I build partial call-in and call-out
graphs, with the call-in node for a function/method A containing a
clone of the code node for function A, plus clones of the other call-
in nodes which call this function (this would be a general graph; I
omit clones that would create a cycle when describing a recursive
function by using UNLs instead).
For another instance, the Leo file *is* the documentation of the
puppet configuration: a host is described by a Leo node that contains
a clone of the node containing the code applied to the host; the code
is described by a node containing a clone of the specific code plus a
clone of the documentation node for each classes, modules or
definitions it includes, and so on recursively.
The Leo files is **>>IT<<**: the ONE source of truth and the one
containiner of everything. The Leo file is to derived files as source
code is to machine language. only more so.
- Stephen
On Aug 2, 12:25 pm, "Edward K. Ream" <[email protected]> wrote:
> On Mon, Aug 2, 2010 at 11:10 AM, thyrsus <[email protected]> wrote:
> > LeoPy.leo or LeoPyRef.leo are not the leo files I'm concerned about.
> > I want to collaborate with my colleagues on the forests of system
> > configuration I maintain, and we are frequently committing to our
> > (internal) repository.
>
> In that case, using @thin or @auto external files seems like the best way.
>
> > The "Recovered Nodes" give me hope that a humanly useful
> > representation of changes is possible. I need to study that code.
> > The result is so much better than opaque XML operations.
>
> The code is quite simple, because it is diffing body text, not xml. I
> would be very interested in a clearer representation of diffs, but I
> don't have a lot of hope. Even bzr qdiff, good as it is, often fails
> to convey the true nature of changes.
>
> Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected].
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.
