From Offray:
as I understand Sqlite storate will be used only for settings
and from Terry:
I don't think we've considered the impact of switching to a binary format
*That's an important point that was not so clear until now! *At least
not for me considering that Vitalije said the following at the very
first post of this thread:
>> /If we use sqlite as file format for outline data it is trivial to
keep the collected settings in the same file.
/And added this later:/
>> /Yes, we are discussing dropping Leo's XML format.
From Offray:
2) import/export from/to .leo XML files, which solves the DVCS
integration issue,
Well, that's another important point that *was not so clear ***as it is
now *in previous posts. *So there is there a wide field to explore...
Sqlite over XML have proved better response time in loading and
querying when two representation of the same data are available
That's sure true for querying, but I'm not so sure for loading.
early optimization is the root of evil, as Knuth said and this is more
like a lot of bump that a big hole ;-).
I agree in that early optimization is bad, but here *I'm not talking
about optimization at all* so I don't understand the quote. I'm talking
about proper *design *that takes into account the future evolution of
the product.
The idea is to pass from native Objects representation to files and
then use Git to represent changes in the system. The machinery behind
this could be used with other DVCS, but the focus is now on Git:
https://github.com/pharo-vcs/iceberg/
Thanks. Quite interesting, i'll take a look. I've already found
interesting what the project states at its intro (emphasis mine):
>> Right now we support only git, but Iceberg *is designed* to
allow other code versioning systems in the future.
That is: it was *designed *from the begining with that multi-VCS support
in mind. That's what I was trying to transmit when I was talking about
the abstraction layers: one can make a proper design from advance to
account for the future expansion of the system to support any VCS.
Design is not "early optimization", is it?
STON is the storage format you use to "export" notebooks from the
image (a snapshot of all objects in your Pharo system) to the file
disk, so they can be shared and versioned as usual files
Thanks, I got it.
The diff is provided by fossil over any text file, as usual with other
DVCS, so is the combination of STON + Fossil that gives you such
pretty and readable output.
From vitalije:
There is no need to add db file to git. External files are kept in
git. If you want any part of Leo outline to be kept in git, you can
make it external file and add to git.
Aha, I see. So now I realise that *I was wrong in one assumption I was
making about Fossil*: that Fossil could handle _naturally_ the Sqlite
file versioning just because it is Sqlite-based!
That's why I told that "/using Sqlite as the next Leo file format //*is
forcing us to take those files out of git, or to use Fossil*//as VCS./"
Oh my God, I don't know how could I make such a wrong
over-simplification of the problem! Now I see: Fossil is not going to
solve the versioning of Sqlite files more or less than any other VCS does.
*I'm REALLY sorry for the confusion that such statement may have caused!*
From vitalije:
It is not the case that using sqlite as file format or even using
fossil for keeping history of every node in outline is forcing any
change in VCS used for project as whole.
Now I see. Thanks. Then that reinforces my idea that we should make
Leo's capable of integrating with any VCS.
Thanks for the warning.
Je, je, you are welcome! Let me be clear about this point also: my
warning *is not* that we must end the journey just because there is a
hole in the road! It's just that we all have to be aware of the hole and
decide the best way to circumvent it. It seems that you already know how
to do it, but I'm just not sure yet.
To state it clearly again: the hole is that no VCS is capable of
efficiently handling (storing) a database "as is".
Let's see the options we have.
From Terry:
Sqlite is certainly an option - if you're just using it for settings, it may
not be necessary to include those files in VCS.
That's an option. The other option, suggested by Offray and Vitalije is
to just always export the Sqlite info to a textual format (which may be
XML or another more-diff friendly format al suggested by them) and have
that included in your VCS. I have yet to think in how would that
workflow be for the settings in Leo because you still want to store the
(equivalent to the now) *leoSettings.leo* file in GitHub... it's an
advanced topic for me at this moment.
To create more room for confusion :-} there's also now discussion of more
dynamic *code* reloading. I'm unclear as to whether this is for Leo only, in
which case it seems primarily a benefit to Leo developers, or if it would cover
other code being developed in Leo. Without any standard way of doing the
latter, I'm not sure how that would work.
Cheers -Terry
and Offray:
For me there is a deeper question in Vitalije's search and is "How can improve Leo
liveness and responsiveness".
That's *a bigger and really **exciting endeavour *that I like alot!! To
be clear on that point from my part: I'm *all about liveness* when
programming! That's why I gave Light Table <http://lighttable.com/> a
try in the past, before coming to Leo. It has *liveness of your Python
code* (the one that you are developing) included in its design!... or it
may have, because I could never make it work for me. :-( So I switched
to Leo... with the eye put in a wider interactive programming
experience! And I do still have this purpose in mind for Leo.
Light Table design was profoundly inspired by Bret Victor ideas which
resonate alot with my own vision of programming.
There's a lot of work to be done in that direction, but I think /*It's
worth any amount of effort*/, as Edward likes to say!
From Edward:
I prefer exploration to "requirements", but discussions
alternatives forms an important background to exploration.
I really think we should try to make kind of a roadmap for our
explorations. When you know where you are and you know where you wanna
go, you sketch a roadmap. But that *does not mean that later on, when
you are on the road, you must stick to it at any cost*.*Of course
not!***We will have to adapt to the problems and surprises we'll find
along the road and change the roadmap accordingly at every stage. At
least, that's my vision of software development. Roadmaps are just a
tool. They must not get you out of your Goals. Some prefer to call this
difference *Tacticts vs Strategy*, but I've found that those concepts
are quite confusing for many people, so I choose not to use them.
Thanks to all for you refreshing ideas! This journey with you all is
being a pleasure... and this is just the beginning! ;-)
Yours, Xavier
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
