I guess it's like anything else: one could just look at the load and
save code, make whatever db representation one wants that hooks into
that. I keep wanting to adapt a database representation, when I guess
reading Python wouldn't be hard. But all the things Leo must be
parsing . . . guess I
On Wed, Jan 4, 2012 at 3:50 AM, Offray Vladimir Luna Cárdenas
off...@riseup.net wrote:
Well my approach is that deconstructing textual computer interaction
requires to think in two axes: one of structure in space (Leo outlines are
this) and one of structure in time (DVCS/SCM, specially Fossil
Hi,
On 01/03/12 11:28, Seth Johnson wrote:
On Tue, Jan 3, 2012 at 5:36 AM, Offray Vladimir Luna Cárdenas
off...@riseup.net wrote:
Thanks. About implementation my idea is to start with a different approach.
The idea is to teach fossil to Leo and having in that way a default
support for
On Tue, Jan 3, 2012 at 5:36 AM, Offray Vladimir Luna Cárdenas
off...@riseup.net wrote:
Thanks. About implementation my idea is to start with a different approach.
The idea is to teach fossil to Leo and having in that way a default
support for versioning and collab in Leo, so the convention for
On Tue, 3 Jan 2012 11:28:59 -0500
Seth Johnson seth.p.john...@gmail.com wrote:
My impression is the only thing that keeps people from
going ahead with what you propose, or demo'ing any approach at all, is
uncertainty about having an adequate model that works with Leo's
intricacies.
I think
On Tue, Jan 3, 2012 at 6:41 PM, Terry Brown terry_n_br...@yahoo.com wrote:
I think that's the case. @file handling is complex, I'm not sure how
familiar with it Ville is, I've poked around the edges a bit, but don't
know how it would interact with loading to / from a DB.
My code just dumps
On Tue, Jan 3, 2012 at 3:20 PM, Ville M. Vainio vivai...@gmail.com wrote:
On Tue, Jan 3, 2012 at 6:41 PM, Terry Brown terry_n_br...@yahoo.com wrote:
I think that's the case. @file handling is complex, I'm not sure how
familiar with it Ville is, I've poked around the edges a bit, but don't
On Tue, Jan 3, 2012 at 3:48 PM, Seth Johnson seth.p.john...@gmail.com wrote:
On Tue, Jan 3, 2012 at 3:20 PM, Ville M. Vainio vivai...@gmail.com wrote:
On Tue, Jan 3, 2012 at 6:41 PM, Terry Brown terry_n_br...@yahoo.com wrote:
I think that's the case. @file handling is complex, I'm not sure
I'd sooner use a ,zip file with the .leo file + external files.
On Tue, Jan 3, 2012 at 10:58 PM, Seth Johnson seth.p.john...@gmail.com wrote:
On Tue, Jan 3, 2012 at 3:48 PM, Seth Johnson seth.p.john...@gmail.com wrote:
On Tue, Jan 3, 2012 at 3:20 PM, Ville M. Vainio vivai...@gmail.com wrote:
On Tue, Jan 3, 2012 at 4:33 PM, Ville M. Vainio vivai...@gmail.com wrote:
I'd sooner use a ,zip file with the .leo file + external files.
Right. But that doesn't get us a development context that facilitates
people's participation in developing db solutions.
All that's needed is a db
Hi,
I read all the thread on db-oriented version of Leo. I got lost on
implementation details (what is a shame... :-/), so I'm just want to say
that the things that Alia points here about a single db file containing
all data (external or not) of a project, and collaboration for free is
On Mon, Jan 2, 2012 at 4:04 PM, Offray Vladimir Luna Cárdenas
off...@riseup.net wrote:
Hi,
I read all the thread on db-oriented version of Leo. I got lost on
implementation details (what is a shame... :-/),
I think the single thing that will best get db-oriented Leo going will
be someone just
On Thu, Dec 29, 2011 at 7:53 PM, Seth Johnson seth.p.john...@gmail.com wrote:
I hope to plug in my old hard drive tonight and get the app I built on
the schema I'm describing off of it. I promise not to carp over
abstract theory -- having the schema (and dBASE code!) will help a
lot.
Two
On Thu, Dec 29, 2011 at 6:37 PM, Ville M. Vainio vivai...@gmail.com wrote:
Given the list of edges (a,b) :
If you want all children of node N, list edges where N is the 'a'
node, and store the 'b' node from every edge. To find parent(s) of N,
list edges where N is the 'b' node.
One can use
On Fri, Dec 30, 2011 at 3:25 PM, Seth Johnson seth.p.john...@gmail.com wrote:
On Thu, Dec 29, 2011 at 6:37 PM, Ville M. Vainio vivai...@gmail.com wrote:
Given the list of edges (a,b) :
If you want all children of node N, list edges where N is the 'a'
node, and store the 'b' node from every
On Fri, Dec 30, 2011 at 9:13 AM, Ville M. Vainio vivai...@gmail.com wrote:
On Fri, Dec 30, 2011 at 3:25 PM, Seth Johnson seth.p.john...@gmail.com
wrote:
One can use two indexes instead of having an edges entity:
To find all children of node N, seek N in an index on the parent key
field.
I don't really understand this. What do you mean by 'index'? In rdbms,
index can only contain data that can be trivially derived from tables.
Everything needs to work without index as well.
On Dec 30, 2011 4:42 PM, Seth Johnson seth.p.john...@gmail.com wrote:
On Fri, Dec 30, 2011 at 9:13 AM,
On Fri, Dec 30, 2011 at 10:37 AM, Ville M. Vainio vivai...@gmail.com wrote:
I don't really understand this. What do you mean by 'index'? In rdbms, index
can only contain data that can be trivially derived from tables. Everything
needs to work without index as well.
I do some clever index
I think there are two key conceptual differences: 1) set orientation
vs record orientation; 2) nodes as encapsulated objects vs. nodes as
records
Seth
On Fri, Dec 30, 2011 at 11:03 AM, Seth Johnson seth.p.john...@gmail.com wrote:
On Fri, Dec 30, 2011 at 10:37 AM, Ville M. Vainio
On Fri, Dec 30, 2011 at 11:05 AM, Seth Johnson seth.p.john...@gmail.com wrote:
I think there are two key conceptual differences: 1) set orientation
vs record orientation; 2) nodes as encapsulated objects vs. nodes as
records
or more to the point: nodes as encapsulated objects vs. nodes
On Fri, Dec 30, 2011 at 9:41 AM, Seth Johnson seth.p.john...@gmail.com wrote:
This is a nodes table, two columns/fields:
Node key - Parent key
A - N
B - N
C - N
D - X
E - X
N - D
N - E
This is the tree represented by the above records:
X - D - N - A
So your nodes table is essentially my EDGES table :)
On Dec 30, 2011 6:53 PM, Seth Johnson seth.p.john...@gmail.com wrote:
On Fri, Dec 30, 2011 at 9:41 AM, Seth Johnson seth.p.john...@gmail.com
wrote:
This is a nodes table, two columns/fields:
Node key - Parent key
A - N
B - N
C
On Fri, Dec 30, 2011 at 12:20 PM, Ville M. Vainio vivai...@gmail.com wrote:
So your nodes table is essentially my EDGES table :)
Ah! Will check that, but I think you're probably right. And your
nodes table would be more appropriately identified with my attributes
table(s).
The bottom level
No, not edges gone wild -- pointers: they don't really correlate with
arrows between nodes . . . but sure, edges probably goes right into my
Links level table. :-)
On Fri, Dec 30, 2011 at 12:28 PM, Seth Johnson seth.p.john...@gmail.com wrote:
On Fri, Dec 30, 2011 at 12:20 PM, Ville M. Vainio
On Thu, Dec 29, 2011 at 9:21 AM, Ville M. Vainio vivai...@gmail.com wrote:
On Thu, Dec 29, 2011 at 2:57 PM, Seth Johnson seth.p.john...@gmail.com
wrote:
No reason you can't query a flat file; just no joins involved, is all.
Yeah, and you would have to implement sql engine yourself ;-).
Ville,
I ran the code in
The code to dump outline to sql database (and create the database) is here:
http://bazaar.launchpad.net/~leo-editor-team/leo-editor/contrib/view/...
after changing the db location in
def test(c):
tf = TreeFrag(/home/ville/treefrag.db)
of course
Do you have
On Thu, Dec 29, 2011 at 2:57 PM, Seth Johnson seth.p.john...@gmail.com wrote:
No reason you can't query a flat file; just no joins involved, is all.
Yeah, and you would have to implement sql engine yourself ;-).
Huh? Why? If you're talking about tree traversal, I've addressed
that
I recreate the structure in leoqviewer, but this is c++ code. Dumb
algorithm to create the tree is easy to do for python Leo as well, but if I
write full file format support I'd like to do it the fast way - first
create nodes, then put them to their place in the graph, in just 2 passes.
On Dec 29,
On Thu, Dec 29, 2011 at 5:13 AM, Ville M. Vainio vivai...@gmail.com wrote:
On Thu, Dec 29, 2011 at 11:43 AM, Seth Johnson seth.p.john...@gmail.com
wrote:
No reason you can't query a flat file; just no joins involved, is all.
Yeah, and you would have to implement sql engine yourself ;-).
On Dec 29, 2:50 pm, Ville M. Vainio vivai...@gmail.com wrote:
I recreate the structure in leoqviewer, but this is c++ code. Dumb
algorithm to create the tree is easy to do for python Leo as well, but if I
write full file format support I'd like to do it the fast way - first
create nodes, then
On Fri, Dec 30, 2011 at 1:19 AM, mdb mdbol...@gmail.com wrote:
I am able to recreate nodes from the sqlite db but I do not fully
understand how your edges scheme can be used to recreate a tree
design. It seems easier to simply give the db a field that tells
whether a node is a child of
On Thu, Dec 29, 2011 at 2:50 PM, Ville M. Vainio vivai...@gmail.com wrote:
I recreate the structure in leoqviewer, but this is c++ code. Dumb algorithm
to create the tree is easy to do for python Leo as well, but if I write full
file format support I'd like to do it the fast way - first create
On Tue, Dec 27, 2011 at 10:36 AM, Seth Johnson seth.p.john...@gmail.com wrote:
On Tue, Dec 27, 2011 at 10:15 AM, Terry Brown terry_n_br...@yahoo.com wrote:
On Tue, 27 Dec 2011 00:53:06 -0500
Seth Johnson seth.p.john...@gmail.com wrote:
I read a bit of SQLAlchemy tonight, and it does seem
On Tue, Dec 27, 2011 at 10:46 AM, Seth Johnson seth.p.john...@gmail.com wrote:
My approach would scale globally very easily, but yes, traversal might
get intensive in some contexts. I think optimizing that could be done
locally and/or in the interface rather than the backend -- no reason
why
On Sat, Dec 24, 2011 at 4:30 PM, Kent Tenney kten...@gmail.com wrote:
Wow, I feel like the Rabbi in the following joke:
Yes. Good joke. BTW, I often feel clueless in these discussions
myself. Furthermore, I often forget that we've *had* these
discussions.
I think that's ok. Leo is not going
On Mon, Dec 26, 2011 at 7:44 AM, Edward K. Ream edream...@gmail.com wrote:
On Sat, Dec 24, 2011 at 4:30 PM, Kent Tenney kten...@gmail.com wrote:
Wow, I feel like the Rabbi in the following joke:
Yes. Good joke. BTW, I often feel clueless in these discussions
myself. Furthermore, I often
On Mon, Dec 26, 2011 at 11:19 AM, Seth Johnson seth.p.john...@gmail.com wrote:
On Mon, Dec 26, 2011 at 7:44 AM, Edward K. Ream edream...@gmail.com wrote:
I think that's ok. Leo is not going to change in any big way unless
the way forward is so simple and compelling that it will be impossible
The entry point I envision is this:
The gui shows 3 buttons:
=, ||, =
If the node which currently has focus, only the double bars are active,
clicking that button puts the current node in the repository.
if the node is edited, the double bar and the left arrow become active:
clicking = reverts
In this approach you could continue to do collaboration using the
external files, while just storing in the db while you go about
editing the file with node-level granularity, including going through
versions.
But for those who are concerned with collaborating, the minimalist
first implementation
On Mon, Dec 26, 2011 at 1:24 PM, Seth Johnson seth.p.john...@gmail.com wrote:
In this approach you could continue to do collaboration using the
external files, while just storing in the db while you go about
editing the file with node-level granularity, including going through
versions.
But
On Thu, Dec 22, 2011 at 3:30 PM, Kent Tenney kten...@gmail.com wrote:
On Thu, Dec 22, 2011 at 1:16 PM, Seth Johnson seth.p.john...@gmail.com
wrote:
Okay, I think I have a sense of where you're situated. What do those
5 key components of the address represent?
They are a set of child
Wow, I feel like the Rabbi in the following joke:
You are talking way above my head, I'll study this thread and
try to come up with something to contribute. In the mean time, enjoy.
http://www.awordinyoureye.com/jokes83rdset.html
(#1705) The Pope and the Rabbi [Author unknown] Several centuries
I like that joke! :-)
On Sat, Dec 24, 2011 at 4:30 PM, Kent Tenney kten...@gmail.com wrote:
Wow, I feel like the Rabbi in the following joke:
You are talking way above my head, I'll study this thread and
try to come up with something to contribute. In the mean time, enjoy.
I've been following this discussion with some interest. A couple of
things spring to mind now:
1. This seems to be the first statement of a problem:
outline structure must be first-class data in shared
(cooperative, distributed) environments. Maybe it's been said earlier
and I've missed it
On Fri, Dec 23, 2011 at 5:27 PM, Eoin eoinmccar...@fastmail.fm wrote:
I've been following this discussion with some interest. A couple of
things spring to mind now:
1. This seems to be the first statement of a problem:
outline structure must be first-class data in shared
(cooperative,
That's Rich *Hickey*, not *Hackey* :-)
On Fri, Dec 23, 2011 at 7:16 PM, Seth Johnson seth.p.john...@gmail.com wrote:
On Fri, Dec 23, 2011 at 5:27 PM, Eoin eoinmccar...@fastmail.fm wrote:
I've been following this discussion with some interest. A couple of
things spring to mind now:
1. This
I realize my thinking is on a completely lower-level channel from the
thread's current direction, and much of the below is a rehash of my
previous postings, so do skip it if you're busy or truly at a dead-end with
this line of enquiry.
On Saturday, December 24, 2011 5:27:06 AM UTC+7, Eoin
OK, we're talking apples and oranges here.
My approach is pretty simple-minded, aimed at versioning nodes,
your schema is much richer, over my head.
I just want a snapshot which saves node state to a dict / json object.
It's also intended to be somewhat generic, the Leo specific stuff
is in the
Okay, I think I have a sense of where you're situated. What do those
5 key components of the address represent? Or is it just arbitrarily
a 5-part key value, one large key that happens to be made up of 5
meaningless key parts?
I get that you are grabbing the state, and the json objects that
On Thu, Dec 22, 2011 at 1:16 PM, Seth Johnson seth.p.john...@gmail.com wrote:
Okay, I think I have a sense of where you're situated. What do those
5 key components of the address represent?
They are a set of child indexes
0-5-0-0-1
root
\
0
1
2
3
4
5
\
0 my address is 0-5-0
\
On Thu, Dec 22, 2011 at 3:30 PM, Kent Tenney kten...@gmail.com wrote:
On Thu, Dec 22, 2011 at 1:16 PM, Seth Johnson seth.p.john...@gmail.com
wrote:
Okay, I think I have a sense of where you're situated. What do those
5 key components of the address represent?
They are a set of child
On Tue, Dec 20, 2011 at 2:31 PM, Seth Johnson seth.p.john...@gmail.com wrote:
On Tue, Dec 20, 2011 at 1:39 PM, Kent Tenney kten...@gmail.com wrote:
It sounds like the moral equivalent of a linked list.
The address approach I've been leaning towards feels more
robust / useful, but I haven't
On Wed, Dec 21, 2011 at 6:36 PM, Seth Johnson seth.p.john...@gmail.com wrote:
On Tue, Dec 20, 2011 at 2:31 PM, Seth Johnson seth.p.john...@gmail.com
wrote:
On Tue, Dec 20, 2011 at 1:39 PM, Kent Tenney kten...@gmail.com wrote:
It sounds like the moral equivalent of a linked list.
The
On Wed, Dec 21, 2011 at 10:28 PM, Kent Tenney kten...@gmail.com wrote:
On Wed, Dec 21, 2011 at 6:36 PM, Seth Johnson seth.p.john...@gmail.com
wrote:
Reading more carefully, I should say that if I understand the
distinction I think you're drawing, I think I'm doing both at the same
time:
On Mon, Dec 19, 2011 at 9:58 PM, HansBKK hans...@gmail.com wrote:
Reading this fired off so many synapses, generated so much dopamine etc.,
was as enjoyable to me as sex or quality chocolate. And that without even
understanding most of the implementation side, just imagining that you
consider
On Mon, Dec 19, 2011 at 11:59 AM, Edward K. Ream edream...@gmail.com wrote:
If all (or almost all) data appears in a Leonine sqlite db we can say
the following:
- There is no need for a Leo cache.
- There is no need for private @shadow files.
- We can use the @shadow algorithm for *all*
On Mon, Dec 19, 2011 at 11:59 AM, Edward K. Ream edream...@gmail.com wrote:
All this (and more) is part of the under-appreciated magic of sha1
keys.
I suspect this whole line of thought is a dead end: there is no way,
in a cooperative environment, to separate outline structure from
external
On Tue, Dec 20, 2011 at 9:41 AM, Edward K. Ream edream...@gmail.com wrote:
On Mon, Dec 19, 2011 at 11:59 AM, Edward K. Ream edream...@gmail.com wrote:
All this (and more) is part of the under-appreciated magic of sha1
keys.
I suspect this whole line of thought is a dead end: there is no way,
On Tuesday, December 20, 2011 9:36:36 PM UTC+7, Edward K. Ream wrote:
@shadow will *never* be the model for most files because it demotes
structure info to second-class status, namely, personal preference
grafted on to the real data. But the *essence* of Leo is that
structure is
On Tue, Dec 20, 2011 at 10:00 AM, Seth Johnson seth.p.john...@gmail.com wrote:
Thus, the keys are an attempt to do the wrong thing.
As long as nobody's changing the external files. If they aren't, the
cooperation can be done in the database(s), with external files just
written as the
On Tue, Dec 20, 2011 at 10:19 AM, HansBKK hans...@gmail.com wrote:
given a single user, and never looking at the external files generated
@shadow and @thin are functionally equivalent.
@thin carries structural information in the actual external file.
@shadow carries structure in the private
In my architecture, nodes point up to their parents.
How do you maintain sibling order?
I've been settling on node addresses in metadata,
it's a list of child indexes. It provides each node with a
self contained description of where it lives, which I like.
I haven't come across a more succinct
On Tue, Dec 20, 2011 at 12:58 PM, Kent Tenney kten...@gmail.com wrote:
In my architecture, nodes point up to their parents.
How do you maintain sibling order?
I've been settling on node addresses in metadata,
it's a list of child indexes. It provides each node with a
self contained
On Tue, Dec 20, 2011 at 12:24 PM, Seth Johnson seth.p.john...@gmail.com wrote:
On Tue, Dec 20, 2011 at 12:58 PM, Kent Tenney kten...@gmail.com wrote:
In my architecture, nodes point up to their parents.
How do you maintain sibling order?
I've been settling on node addresses in metadata,
we can imagine a clone server, as has been suggested, being implemented
using a single sqlite file.
I look forward to seeing where this db vision leads. The idea in my
mind is to still use outlines to re-arange and organize data (program
code, documents, task lists) for views -- could be or
On Tue, Dec 20, 2011 at 1:39 PM, Kent Tenney kten...@gmail.com wrote:
On Tue, Dec 20, 2011 at 12:24 PM, Seth Johnson seth.p.john...@gmail.com
wrote:
On Tue, Dec 20, 2011 at 12:58 PM, Kent Tenney kten...@gmail.com wrote:
In my architecture, nodes point up to their parents.
How do you
On Mon, Dec 19, 2011 at 11:59 AM, Edward K. Ream edream...@gmail.com wrote:
SNIP
Summary
===
Let me try to give a big picture overview of my thoughts, before the
myriad complexities arise. The challenge will be to create simplicity
everywhere. The simplicity *must* be real: it must
On Monday, December 19, 2011 11:59:12 PM UTC+7, Edward K. Ream wrote:
This post is pure speculation: the vision may turn out to be a
mirage. It's also long. Feel free to ignore.
Otoh, the ideas here are completely new, and exist in a new design
space.
Reading this fired off so many
68 matches
Mail list logo
