Re: Well Kent, your vision for Leo is becoming clearer

[Edward K. Ream]

On Mon, Mar 20, 2017 at 7:45 PM, Offray Vladimir Luna Cárdenas <
off...@riseup.net> wrote:

​> ​
Maybe you will enjoy this video that shows software architecture as data
and then makes live coding on data to make it spacial (this was the video
that convinced me that Grafoscopio was possible):
​ ​
https://vimeo.com/94724841

​Spectacular. This video convinced me that Pharo is worth a closer look.​


​> ...notebooks history, collaboration and publishing should have a default
smooth integrated experience for the user/author. I'm still pretty far, but
this year Grafoscopio will be one of the Google Summer of Code projects[1],
so flow will increase.

Congratulations!  Please keep us informed.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Well Kent, your vision for Leo is becoming clearer

[Offray Vladimir Luna Cárdenas]

Hi,


On 07/03/17 11:56, john lunzer wrote:

[...]


I'd love to hear more about this or read some docs about what you're 
working on. Any time I hear the word 'spatial' in relation to data my 
ears perk up a little.


Maybe you will enjoy this video that shows software architecture as data 
and then makes live coding on data to make it spacial (this was the 
video that convinced me that Grafoscopio was possible):


https://vimeo.com/94724841



This may not be very helpful but you might want to take a look at 
Fossil , which is a versioning system that 
uses a database to store version artifacts. Dr Richard Hipp and co has 
put about a decade of work into merging the ideas versioning and 
databases. There are a lot of design documents and I've been told the 
C code is pretty clean and well commented.


Thanks,
Kent


Anyway, I'm excited to hear about what comes out your work. As an 
aside, I think Offray is exploring some ideas related to versioning 
and databases as well.


But my exploration is pretty limited to using fossil as integrated 
default versioning system for Grafoscopio notebooks. What I think is 
that notebooks history, collaboration and publishing should have a 
default smooth integrated experience for the user/author. I'm still 
pretty far, but this year Grafoscopio will be one of the Google Summer 
of Code projects[1], so flow will increase.


[1] 
http://gsoc.pharo.org/#topic-grafoscopio-literate-computing-and-reproducible-research-for-pharo


Cheers,

Offray

--
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Well Kent, your vision for Leo is becoming clearer

[john lunzer]

On Monday, March 6, 2017 at 11:41:26 AM UTC-5, Kent Tenney wrote:
>
> I'm not sure if my periodic outbursts qualify as 'vision' but in terms
> of where my characterization of Leo might differ from the norm, it
> would be my seeing Leo as a hierarchal data store rather than an
> editor, the D3 reference would imply generating data
> relationships viewed in the browser, I'd love to see that.
>

Leo is what it is, and what it happens to be is an editor. I don't think 
anything is going to change that and I don't think it should change. But, 
perhaps, Leo could be the editor of choice for your for your hierarchical 
data store

Abstraction is important. I see the big three primary layers as: data, 
"actions on data", visualization. I think Leo's focus is primarily on 
"actions on data" with enough visualization (tree pane) to make acting on 
data fluid. 
 

> I am slowly coding away at another implementation of my obsession
> with the notion of 'spatial versioning', meaning multiple versions which
> exist next to, above or below, etc. rather than temporal versioning:
> only before or after.
>

I'd love to hear more about this or read some docs about what you're 
working on. Any time I hear the word 'spatial' in relation to data my ears 
perk up a little. 
 

> It always seems to come down to storing data, so I've been studying
> Postgresql more, if the issue is data, a database makes sense. The
> next thing to fret is how much Python vs. how much Postgres, and
> what about json?
>
> Enter the code master, Jim Fulton, announcing newt.db 
> http://www.newtdb.org
> which joins ZODB (persisting Python), Postgresql, and json.
>
> I once had node level spatial versioning working for Leo, I hope to return 
> to it,
> in a form I can stick with.
>

This may not be very helpful but you might want to take a look at Fossil 
, which is a versioning system that uses a database 
to store version artifacts. Dr Richard Hipp and co has put about a decade 
of work into merging the ideas versioning and databases. There are a lot of 
design documents and I've been told the C code is pretty clean and well 
commented. 
 

> Thanks,
> Kent
>

Anyway, I'm excited to hear about what comes out your work. As an aside, I 
think Offray is exploring some ideas related to versioning and databases as 
well.
 

> On Mon, Mar 6, 2017 at 9:34 AM, Edward K. Ream  > wrote:
>
>> I never really understood it until I saw the Atom editor 
>>  and d3 demo 
>> .
>>
>> Cool stuff enabled by standard web technologies.
>>
>> Edward
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "leo-editor" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to leo-editor+...@googlegroups.com .
>> To post to this group, send email to leo-e...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/leo-editor.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Well Kent, your vision for Leo is becoming clearer

[Kent Tenney]

And yes, proper abstraction, but newt.db has me convinced
to go all in with it.

On Mon, Mar 6, 2017 at 1:26 PM, 'Terry Brown' via leo-editor <
leo-editor@googlegroups.com> wrote:

> Hi - I wouldn't discount SQLite either, DB wise, unless you need connect
> to a *remote* server capability, but for local work it's quite capable.
> And a proper abstraction layer should make it possible to switch out the
> backend.
>
> Cheers -Terry
>
>
> --
> *From:* Kent Tenney <kten...@gmail.com>
> *To:* leo-editor <leo-editor@googlegroups.com>
> *Sent:* Monday, March 6, 2017 10:41 AM
> *Subject:* Re: Well Kent, your vision for Leo is becoming clearer
>
> I'm not sure if my periodic outbursts qualify as 'vision' but in terms
> of where my characterization of Leo might differ from the norm, it
> would be my seeing Leo as a hierarchal data store rather than an
> editor, the D3 reference would imply generating data
> relationships viewed in the browser, I'd love to see that.
>
> I am slowly coding away at another implementation of my obsession
> with the notion of 'spatial versioning', meaning multiple versions which
> exist next to, above or below, etc. rather than temporal versioning:
> only before or after.
>
> It always seems to come down to storing data, so I've been studying
> Postgresql more, if the issue is data, a database makes sense. The
> next thing to fret is how much Python vs. how much Postgres, and
> what about json?
>
> Enter the code master, Jim Fulton, announcing newt.db
> http://www.newtdb.org
> which joins ZODB (persisting Python), Postgresql, and json.
>
> I once had node level spatial versioning working for Leo, I hope to return
> to it,
> in a form I can stick with.
>
> Thanks,
> Kent
>
> On Mon, Mar 6, 2017 at 9:34 AM, Edward K. Ream <edream...@gmail.com>
> wrote:
>
> I never really understood it until I saw the Atom editor
> <https://atom.io/> and d3 demo
> <https://bl.ocks.org/kaleguy/57266b6fff9f864403e007e9efd06401>.
>
> Cool stuff enabled by standard web technologies.
>
> Edward
> --
> You received this message because you are subscribed to the Google Groups
> "leo-editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to leo-editor+unsubscribe@ googlegroups.com
> <leo-editor+unsubscr...@googlegroups.com>.
> To post to this group, send email to leo-editor@googlegroups.com.
> Visit this group at https://groups.google.com/ group/leo-editor
> <https://groups.google.com/group/leo-editor>.
> For more options, visit https://groups.google.com/d/ optout
> <https://groups.google.com/d/optout>.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "leo-editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to leo-editor+unsubscr...@googlegroups.com.
> To post to this group, send email to leo-editor@googlegroups.com.
> Visit this group at https://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "leo-editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to leo-editor+unsubscr...@googlegroups.com.
> To post to this group, send email to leo-editor@googlegroups.com.
> Visit this group at https://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Well Kent, your vision for Leo is becoming clearer

[Kent Tenney]

And the previous version which was up and running briefly was SQLite,
confirmed proof of concept, but I am interested in a db server available
from anywhere, I work from several different machines during the day.

The principle I've described for Leo nodes will apply to versioning files,
commands ... etc. The combination of features in newt.db addresses
my interests wonderfully, so that part of the decision has been made for me.

Thanks,
Kent

On Mon, Mar 6, 2017 at 1:26 PM, 'Terry Brown' via leo-editor <
leo-editor@googlegroups.com> wrote:

> Hi - I wouldn't discount SQLite either, DB wise, unless you need connect
> to a *remote* server capability, but for local work it's quite capable.
> And a proper abstraction layer should make it possible to switch out the
> backend.
>
> Cheers -Terry
>
>
> --
> *From:* Kent Tenney <kten...@gmail.com>
> *To:* leo-editor <leo-editor@googlegroups.com>
> *Sent:* Monday, March 6, 2017 10:41 AM
> *Subject:* Re: Well Kent, your vision for Leo is becoming clearer
>
> I'm not sure if my periodic outbursts qualify as 'vision' but in terms
> of where my characterization of Leo might differ from the norm, it
> would be my seeing Leo as a hierarchal data store rather than an
> editor, the D3 reference would imply generating data
> relationships viewed in the browser, I'd love to see that.
>
> I am slowly coding away at another implementation of my obsession
> with the notion of 'spatial versioning', meaning multiple versions which
> exist next to, above or below, etc. rather than temporal versioning:
> only before or after.
>
> It always seems to come down to storing data, so I've been studying
> Postgresql more, if the issue is data, a database makes sense. The
> next thing to fret is how much Python vs. how much Postgres, and
> what about json?
>
> Enter the code master, Jim Fulton, announcing newt.db
> http://www.newtdb.org
> which joins ZODB (persisting Python), Postgresql, and json.
>
> I once had node level spatial versioning working for Leo, I hope to return
> to it,
> in a form I can stick with.
>
> Thanks,
> Kent
>
> On Mon, Mar 6, 2017 at 9:34 AM, Edward K. Ream <edream...@gmail.com>
> wrote:
>
> I never really understood it until I saw the Atom editor
> <https://atom.io/> and d3 demo
> <https://bl.ocks.org/kaleguy/57266b6fff9f864403e007e9efd06401>.
>
> Cool stuff enabled by standard web technologies.
>
> Edward
> --
> You received this message because you are subscribed to the Google Groups
> "leo-editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to leo-editor+unsubscribe@ googlegroups.com
> <leo-editor+unsubscr...@googlegroups.com>.
> To post to this group, send email to leo-editor@googlegroups.com.
> Visit this group at https://groups.google.com/ group/leo-editor
> <https://groups.google.com/group/leo-editor>.
> For more options, visit https://groups.google.com/d/ optout
> <https://groups.google.com/d/optout>.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "leo-editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to leo-editor+unsubscr...@googlegroups.com.
> To post to this group, send email to leo-editor@googlegroups.com.
> Visit this group at https://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "leo-editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to leo-editor+unsubscr...@googlegroups.com.
> To post to this group, send email to leo-editor@googlegroups.com.
> Visit this group at https://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Well Kent, your vision for Leo is becoming clearer

['Terry Brown' via leo-editor]

Sure, SQLite isn't as heavier hitter as pg et al.  But I've seen it handle 
millions of records (although perhaps not "more than a few Gb of data" without 
too much trouble.
I guess I was thinking it would be nice to have interchangeable backends for 
any new Leo db backend, and if you were going that route you could use SQLite 
for simplicity until such time as you needed to switch to something better.  I 
wouldn't expect Kent to hit gigabytes of data very quickly, at least not in 
dev. stages.
Cheers -Terry
  From: Mike Hodson <myst...@gmail.com>
 To: leo-editor@googlegroups.com 
 Sent: Monday, March 6, 2017 1:56 PM
 Subject: Re: Well Kent, your vision for Leo is becoming clearer
   
On Mon, Mar 6, 2017 at 12:26 PM, 'Terry Brown' via leo-editor 
<leo-editor@googlegroups.com> wrote:

Hi - I wouldn't discount SQLite either, DB wise, unless you need connect to a 
*remote* server capability, but for local work it's quite capable.  And a 
proper abstraction layer should make it possible to switch out the backend.
Cheers -Terry

Hi Terry, I've got another quick "Mike's $0.02" relating to SQLite..
I've found that a local SQL Server, (My/Maria/MS/pg) is nearly "required" when 
dealing with data larger than a few gigabytes, and further, the optimizations 
in Maria/pg allow for very quick querying and joining of the data as well, 
evidenced by my hundreds-of-thousands-of-emails in KMail working properly with 
Maria and working very sporadically with sqlite. (when working for a webhosting 
company where _everything_ (tickets/alerts/daily notifications/vendor 
mails/*.*) was emailed out to _everyone_.)
However I've yet to compare with a more capable and perhaps better programmed 
project that has utilized mysql/pgsql and also has proper sqlite integration; 
from my understanding, the coding model is very different and this may be a 
reason the KDE people haven't optimized for sqlite and/or bugs exist in the 
code as nobody uses sqlite fully knowing the mysql akonadi integration "just 
works"
R1Soft CDP, the backup solution, has since version 3.0 used a SQLite database 
file as its "block storage" and every successful merge of old recovery points 
causes a full-sqlite-file-rewrite-to-disk. I am strong in my belief that if 
they used Maria or Postgres instead of SQLite, they'd have a far more 
performant product and less filesystem fragmentation with 'file per table' 
XtraDB layout in Maria, or whatever Postgres does internally to be so bloody 
efficient.
Mike
-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.


   

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Well Kent, your vision for Leo is becoming clearer

[Mike Hodson]

On Mon, Mar 6, 2017 at 12:26 PM, 'Terry Brown' via leo-editor <
leo-editor@googlegroups.com> wrote:

> Hi - I wouldn't discount SQLite either, DB wise, unless you need connect
> to a *remote* server capability, but for local work it's quite capable.
> And a proper abstraction layer should make it possible to switch out the
> backend.
>
> Cheers -Terry
>

Hi Terry, I've got another quick "Mike's $0.02" relating to SQLite..

I've found that a local SQL Server, (My/Maria/MS/pg) is nearly "required"
when dealing with data larger than a few gigabytes, and further, the
optimizations in Maria/pg allow for very quick querying and joining of the
data as well, evidenced by my hundreds-of-thousands-of-emails in KMail
working properly with Maria and working very sporadically with sqlite.
(when working for a webhosting company where _everything_
(tickets/alerts/daily notifications/vendor mails/*.*) was emailed out to
_everyone_.)

However I've yet to compare with a more capable and perhaps better
programmed project that has utilized mysql/pgsql and also has proper sqlite
integration; from my understanding, the coding model is very different and
this may be a reason the KDE people haven't optimized for sqlite and/or
bugs exist in the code as nobody uses sqlite fully knowing the mysql
akonadi integration "just works"

R1Soft CDP, the backup solution, has since version 3.0 used a SQLite
database file as its "block storage" and every successful merge of old
recovery points causes a full-sqlite-file-rewrite-to-disk. I am strong in
my belief that if they used Maria or Postgres instead of SQLite, they'd
have a far more performant product and less filesystem fragmentation with
'file per table' XtraDB layout in Maria, or whatever Postgres does
internally to be so bloody efficient.

Mike

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Well Kent, your vision for Leo is becoming clearer

['Terry Brown' via leo-editor]

Hi - I wouldn't discount SQLite either, DB wise, unless you need connect to a 
*remote* server capability, but for local work it's quite capable.  And a 
proper abstraction layer should make it possible to switch out the backend.
Cheers -Terry

  From: Kent Tenney <kten...@gmail.com>
 To: leo-editor <leo-editor@googlegroups.com> 
 Sent: Monday, March 6, 2017 10:41 AM
 Subject: Re: Well Kent, your vision for Leo is becoming clearer
   
I'm not sure if my periodic outbursts qualify as 'vision' but in terms
of where my characterization of Leo might differ from the norm, it
would be my seeing Leo as a hierarchal data store rather than an
editor, the D3 reference would imply generating data
relationships viewed in the browser, I'd love to see that.

I am slowly coding away at another implementation of my obsession
with the notion of 'spatial versioning', meaning multiple versions which
exist next to, above or below, etc. rather than temporal versioning:
only before or after.

It always seems to come down to storing data, so I've been studying
Postgresql more, if the issue is data, a database makes sense. The
next thing to fret is how much Python vs. how much Postgres, and
what about json?

Enter the code master, Jim Fulton, announcing newt.db http://www.newtdb.org
which joins ZODB (persisting Python), Postgresql, and json.

I once had node level spatial versioning working for Leo, I hope to return to 
it,
in a form I can stick with.

Thanks,
Kent

On Mon, Mar 6, 2017 at 9:34 AM, Edward K. Ream <edream...@gmail.com> wrote:

I never really understood it until I saw the Atom editor and d3 demo.

Cool stuff enabled by standard web technologies.

Edward
-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscribe@ googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/ group/leo-editor.
For more options, visit https://groups.google.com/d/ optout.


-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.


   

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Well Kent, your vision for Leo is becoming clearer

[Kent Tenney]

I'm not sure if my periodic outbursts qualify as 'vision' but in terms
of where my characterization of Leo might differ from the norm, it
would be my seeing Leo as a hierarchal data store rather than an
editor, the D3 reference would imply generating data
relationships viewed in the browser, I'd love to see that.

I am slowly coding away at another implementation of my obsession
with the notion of 'spatial versioning', meaning multiple versions which
exist next to, above or below, etc. rather than temporal versioning:
only before or after.

It always seems to come down to storing data, so I've been studying
Postgresql more, if the issue is data, a database makes sense. The
next thing to fret is how much Python vs. how much Postgres, and
what about json?

Enter the code master, Jim Fulton, announcing newt.db http://www.newtdb.org
which joins ZODB (persisting Python), Postgresql, and json.

I once had node level spatial versioning working for Leo, I hope to return
to it,
in a form I can stick with.

Thanks,
Kent

On Mon, Mar 6, 2017 at 9:34 AM, Edward K. Ream  wrote:

> I never really understood it until I saw the Atom editor
>  and d3 demo
> .
>
> Cool stuff enabled by standard web technologies.
>
> Edward
>
> --
> You received this message because you are subscribed to the Google Groups
> "leo-editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to leo-editor+unsubscr...@googlegroups.com.
> To post to this group, send email to leo-editor@googlegroups.com.
> Visit this group at https://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Well Kent, your vision for Leo is becoming clearer

[Edward K. Ream]

I never really understood it until I saw the Atom editor  
and d3 demo .

Cool stuff enabled by standard web technologies.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.