A road to branch pollution: git stash goes back in time

[Edward K. Ream]

Here's a common scenario.

1. I think a task is going to be easy, so I begin work on it in master.

2. Oops. The task isn't so easy. I better switch to a new branch.

3. No problem, right? Just do git stash, create the branch, and do a git 
stash pop.

*Danger*: *stashing goes back in time in master*. All of Leo's caches must 
be completely cleared!

I recommend deleting everything in .leo/db. Not doing this was very likely 
the cause of the bleeds of other branches into master.  Do you see?

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: How does instant update work in Pharo?

[Edward K. Ream]

On Sat, Jul 8, 2017 at 6:17 PM, 'Karsten Wolf' via leo-editor <
leo-editor@googlegroups.com> wrote:

> Disclaimer: This may sound like a rant but it isn't. I got out of that
> rabbit hole a decade ago. For me programming in Smalltalk is dreaming of
> the ideal software and programming in Python is Getting things done.
>

​Thanks for this perspective! It's easy to get carried away by grand
ideas.  Perhaps they will bear fruit with Leo on Python.

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: How does instant update work in Pharo?

['Karsten Wolf' via leo-editor]

Disclaimer: This may sound like a rant but it isn't. I got out of that rabbit 
hole a decade ago. For me programming in Smalltalk is dreaming of the ideal 
software and programming in Python is Getting things done.

>From what I have seen, Pharo is the current popular Squeak derivative. I might 
>be wrong. My knowledge has a rot of 10+ years.

That being said.

A short recap:

- Smalltalk (ST) has 5 reserved words: true, false, super, self and nil. 
Everything else is in Classes, methods and objects.

- Arithmetic is not part of the language. "3 + 4" means the binary message '+' 
with argument '4' is sent to 3. Which means "3 + 4 * 5" evaluates to 35 (left 
to right) not 23 (multiplication before addition).

- Everything except variables is an object. Which is also true for Python.

- The image holds the complete state. On startup the image is loaded and every 
object recreated in RAM the way it was when the image was last saved. If the VM 
crashed either your last savepoint was good or you ended in the debugger or you 
really shot yourself in the foot.

- With Squeak and a 32-bit VM the limit was 512 MB for the image. I wonder 
where the limits are with 64 bit. A save writes the complete image...

- The last time I looked smalltalk didn't have what a Pythoneer would call a 
namespace.

- Deploying an application is... you don't have applications.




> Am 08.07.2017 um 20:45 schrieb Edward K. Ream :
> 
> 
> 
> On Friday, July 7, 2017 at 5:23:21 AM UTC-5, Edward K. Ream wrote:
> I'm beginning to wonder what the difference is between the Pharo way and 
> #511: reload-leo command.

Not much. You load stuff into RAM and do your best to keep it current.



> How does Pharo handle changes in object format or methods? How does Pharo 
> recover from crashes due to changed method signatures, invalid calls, etc?


It's a very integrated system. Class definitions are in image/RAM not a class 
file. Any Class/method can be changed at runtime because that's where they 
exist: in RAM at runtime. You have means to iterate over all objects and filter 
and manipulate them.



> This simple, deep video shows how at around 3:30.  It  illustrates a great 
> quote at 5:40:
> 
> "Objects are not there just to run whatever we put in classes.
> Objects are there to carry on a dialog with us as programmers."
> 
> Hmm. Roughly two minutes to change your world.

Please invest another hour to get back to earth. I would hate it if you get 
lost on another planet: https://www.youtube.com/watch?v=YX3iRjKj7C0

If you're impatient, start at 19:30 and watch 5 min.

I watch it at least once a year.


> So...Could we define a PharoObject class (in Python) that could do the same?  
> Has anyone already done so?  A quick google has not turned up anything.

Yes you can... if you also take the VM and the class system. The VM for 
performance. The class system for the magic.

If you want to know more about the magic: learn about MetaClasses and the class 
Behaviour.






If you really want to bring some of the good smalltalk stuff to Python: Write a 
class browser that works like the ST browser.


And get as much fun and inspiration you could get from Squeak/Pharo.


And please don't get lost.



-karsten


-- 
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: How does instant update work in Pharo?

[Edward K. Ream]

On Sat, Jul 8, 2017 at 5:20 PM, Jacob MacDonald  wrote:

> Afraid not, it's firmly vaporware right now and thus I'm loath to talk
> about it before I've done any actual work.
>

​Hehe.  I'll wait with as much patience as I can muster ;-)

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: How does instant update work in Pharo?

[Jacob MacDonald]

Afraid not, it's firmly vaporware right now and thus I'm loath to talk
about it before I've done any actual work.

On Sat, Jul 8, 2017 at 5:17 PM Edward K. Ream  wrote:

> On Sat, Jul 8, 2017 at 3:51 PM, Jacob MacDonald 
> wrote:
>
>> This mailing list keeps getting filled with things I'm otherwise
>> interested in, from Fossil to Smalltalk! Since the beginning of this year
>> I've had the idea of creating a Smalltalk environment inside Leo; Perhaps
>> this is the inspiration needed for me to actually put some time into it.
>>
>
> ​That would be amazing. Can you give us a glimpse of your ideas?
>
> I've spent the afternoon happily going down the Pharo rabbit hole.  I'm
> tempted to lose myself in Pharo Wonderland...
>
> 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.

Re: How does instant update work in Pharo?

[Edward K. Ream]

On Sat, Jul 8, 2017 at 3:51 PM, Jacob MacDonald  wrote:

> This mailing list keeps getting filled with things I'm otherwise
> interested in, from Fossil to Smalltalk! Since the beginning of this year
> I've had the idea of creating a Smalltalk environment inside Leo; Perhaps
> this is the inspiration needed for me to actually put some time into it.
>

​That would be amazing. Can you give us a glimpse of your ideas?

I've spent the afternoon happily going down the Pharo rabbit hole.  I'm
tempted to lose myself in Pharo Wonderland...

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: How does instant update work in Pharo?

[Jacob MacDonald]

This mailing list keeps getting filled with things I'm otherwise interested
in, from Fossil to Smalltalk! Since the beginning of this year I've had the
idea of creating a Smalltalk environment inside Leo; Perhaps this is the
inspiration needed for me to actually put some time into it.

On Sat, Jul 8, 2017 at 1:48 PM Edward K. Ream  wrote:

> On Saturday, July 8, 2017 at 1:45:26 PM UTC-5, Edward K. Ream wrote:
>
> So...Could we define a PharoObject class (in Python) that could do the
>> same?
>>
>
> I meant to say that if we want our app to emulate Pharo in Python all our
> app's objects should derive from PharoObject instead of object.  Hmm.  That
> might be a tad difficult for builtins...
>
>
> 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.

Re: How does instant update work in Pharo?

[Edward K. Ream]

On Saturday, July 8, 2017 at 1:45:26 PM UTC-5, Edward K. Ream wrote:

So...Could we define a PharoObject class (in Python) that could do the same?
>

I meant to say that if we want our app to emulate Pharo in Python all our 
app's objects should derive from PharoObject instead of object.  Hmm.  That 
might be a tad difficult for builtins...

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: How does instant update work in Pharo?

[Edward K. Ream]

On Friday, July 7, 2017 at 5:23:21 AM UTC-5, Edward K. Ream wrote:
>
> I'm beginning to wonder what the difference is between the Pharo way and 
> #511: 
> reload-leo command. 
>
> How does Pharo handle changes in object format or methods? How does Pharo 
> recover from crashes due to changed method signatures, invalid calls, etc?
>

This simple, deep video  shows 
how at around 3:30.  It  illustrates a great quote at 5:40:

"Objects are not there just to run whatever we put in classes.
Objects are there to carry on a dialog with us as programmers."

Hmm. Roughly two minutes to change your world.

So...Could we define a PharoObject class (in Python) that could do the 
same?  Has anyone already done so?  A quick google has not turned up 
anything.

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: Experiment: use README.MD to document branches

[Edward K. Ream]

On Sat, Jul 8, 2017 at 10:10 AM, Terry Brown  wrote:

> There is a simple workaround. Don't *replace* the standard readme,
> > *add *the branch description *in front of* the standard readme file.
>
> One option:
>
> https://stackoverflow.com/a/3970442/1072212
>
> another approach:
>
> https://stackoverflow.com/a/16455853/1072212
>
​
Thanks for these!

git merge --​no-commit *might *be simple enough to remember ;-)

I might even bake it into my gm shortcuts (alias and .bat file).

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: sqlite-format and settings - ideas

[Edward K. Ream]

On Sat, Jul 8, 2017 at 10:43 AM, Chris George  wrote:

> Here is one approach to using sqlite with git.
>
> https://ongardie.net/blog/sqlite-in-git/
>

​Thanks for this.  And here is a stack overflow response
.

​All this research is a ton of fun.

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: sqlite-format and settings - ideas

[Chris George]

Here is one approach to using sqlite with git.

https://ongardie.net/blog/sqlite-in-git/

Chris

On Sat, Jul 8, 2017 at 2:16 AM, Xavier G. Domingo 
wrote:

> 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

Re: help with modes and key handling

[vitalije]

Command 'edit-shortcut' is in 7142abe.

Usage is like this. When editing line in `@shortcut` node or when `@command 
... @key=` is selected, executing this command will wait for the next key 
combination to be pressed. Whatever key combination user press, that is 
entered in current body line (in case of `@shortcut` node) or in 
appropriate position in headline. It remains to actually bind this key 
combination, which should be easy: one call to `c.k.bindKey`. I'll try to 
add this later this evening. 

Vitalije

-- 
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: sqlite-leo and collecting settings

[Terry Brown]

On Sat, 8 Jul 2017 08:46:07 -0500
"Edward K. Ream"  wrote:

> On Sat, Jul 8, 2017 at 4:53 AM, vitalije  wrote:
> 
> 
> > It seems that at-font settings kind is replaced with other methods
> > of configuration.
> >
> 
> ​This is complicated.  Iirc, the complications stem, in part, from the
> theme machinery.  @data qt-gui-plugin-style-sheet forms a "base"
> style, which the user can "override" with @data
> qt-gui-user-style-sheet.

I don't think there's much complication there, qt-gui-user-style-sheet
is just appended to qt-gui-plugin-style-sheet.

> There is a substitution mechanism, somewhere, that replaces @
> constants in these stylesheets with the proper values. I can provide
> more details if you like, but I would have to do the same searches
> that you would ;-)

I think the dereferencing system is not to messy, but there is some
complication where the Ctrl-mousewheel font zooming hooks in.  It's
actually a generic system for dynamically updating stylesheet elements,
I'd have to look at the code to remember more details, but please test
that Ctrl-mousewheel font zooming doesn't get broken as that's an
important accessibility feature I feel.

Cheers -Terry

> This is yet another case where trying to simplify the user's
> experience creates lots of complications behind the scenes.
> 
> There used to be an issues called something like @color settings don't
> dereference, but I don't seem to be able to find it.
> 
> 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: sqlite-leo and collecting settings

[Terry Brown]

On Sat, 8 Jul 2017 00:57:14 -0700 (PDT)
vitalije  wrote:

> I am confident that I can write command to open relevant 
> settings file, make change there and save it again

Note that the Settings -> Edit Settings menu item machinery does some
of this.  Well, really it's just copying settings from one file to
another, but if you're heading down the track of making an API for
setting settings, those functions might be informative or might benefit
from whatever you come up with as an alternative implementation.

That code will also create myLeoSettings.leo if needed, which might be
relevant to your work.

Cheers -Terry

-- 
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: Experiment: use README.MD to document branches

[Terry Brown]

On Sat, 8 Jul 2017 06:34:26 -0700 (PDT)
"Edward K. Ream"  wrote:

> 
> 
> On Saturday, July 8, 2017 at 12:50:22 AM UTC-5, Edward K. Ream wrote:
> >
> > On Sunday, July 2, 2017 at 6:32:34 AM UTC-5, Edward K. Ream wrote:
> >
> > > Changing README.MD seems to be the simplest way to keep track of
> > > the 
> > purpose and status of a branch. 
> >
> > Alas, merging a branch into master over-writes the readme file in
> > master. Naturally, this can be undone, but if it *isn't* undone it
> > is a bother to restore the readme file.
> >
> 
> There is a simple workaround. Don't *replace* the standard readme,
> *add *the branch description *in front of* the standard readme file.
> That way, if someone mistakenly merges a branch's readme, it will be
> easy to "recover" the standard readme by deleting the branch
> description.

One option:

https://stackoverflow.com/a/3970442/1072212

another approach:

https://stackoverflow.com/a/16455853/1072212

-- 
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: sqlite-leo and collecting settings

[Edward K. Ream]

On Sat, Jul 8, 2017 at 4:02 AM, vitalije  wrote:

> When user edits at-font settings node, clicking OK should adjust body of
>> node to selected font.
>>
>
> Done at  30c6dae.
> Warning: previously command show-fonts expected that font family is in
> clipboard and it copied selected font family in clipboard after dialog
> confirmation. Now this command doesn't use clipboard but it adjusts body
> changing accordingly not only family but also weight, slant and size  of a
> font.
>

​Excellent.  I've made a note to myself to document this.v

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: sqlite-leo and collecting settings

[Edward K. Ream]

On Sat, Jul 8, 2017 at 4:53 AM, vitalije  wrote:


> It seems that at-font settings kind is replaced with other methods of
> configuration.
>

​This is complicated.  Iirc, the complications stem, in part, from the
theme machinery.  @data qt-gui-plugin-style-sheet forms a "base" style,
which the user can "override" with @data qt-gui-user-style-sheet.

There is a substitution mechanism, somewhere, that replaces @ constants in
these stylesheets with the proper values. I can provide more details if you
like, but I would have to do the same searches that you would ;-)

This is yet another case where trying to simplify the user's experience
creates lots of complications behind the scenes.

There used to be an issues called something like @color settings don't
dereference, but I don't seem to be able to find it.

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: Experiment: use README.MD to document branches

[Edward K. Ream]

On Saturday, July 8, 2017 at 12:50:22 AM UTC-5, Edward K. Ream wrote:
>
> On Sunday, July 2, 2017 at 6:32:34 AM UTC-5, Edward K. Ream wrote:
>
> > Changing README.MD seems to be the simplest way to keep track of the 
> purpose and status of a branch. 
>
> Alas, merging a branch into master over-writes the readme file in master.  
> Naturally, this can be undone, but if it *isn't* undone it is a bother to 
> restore the readme file.
>

There is a simple workaround. Don't *replace* the standard readme, *add *the 
branch description *in front of* the standard readme file.  That way, if 
someone mistakenly merges a branch's readme, it will be easy to "recover" 
the standard readme by deleting the branch description.

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.

help with modes and key handling

[vitalije]

I have an idea how to allow user to enter shortcut in more natural way: 
just by hitting desired key combination. I don't know how exactly to 
implement it but maybe Edward or Terry would know.

The idea is to create new mode: `input-shortcut`. While in this mode, every 
key combination should lead to one single command `change-shortcut`. This 
command would analyze body line in which cursor is or headline of selected 
node. Assuming in current headline, or current body line there is shortcut 
definition, this shortcut definition gets changed to newly pressed key 
combination, and automatically exits mode `input-shortcut`. I believe this 
command would be easy to write, I just don't know enough how to set this 
new mode and attach handler for it. Maybe for this mode we could use a 
dictionary with default value that lead to `change-shortcut` command. 

If implemented, user could edit at-shortcuts, at-mode, at-button and 
at-command settings (wherever a shortcut is expected) and executing command 
`enter-input-shortcut-mode` and then pressing new key combination. Command 
`change-shortcut` can additionally call c.k.bindKey to make this shortcut 
instantaneously effective and previously defined ineffective. 

Vitalije

-- 
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.

Script: use git bundle to backup entire Leo repo

[Edward K. Ream]

*Devs should never use git push --force*. Unless you you pushed sensitive 
data.  git push --force  could 
destroy Leo's repo.

But brain spikes do happen. The following script will use git bundle 
 to create a complete backup 
of Leo's repo in a single file.  This has other uses besides backup.  I 
encourage Leo's core devs to run this script (suitably modified for your 
machine), from time to time:

import os
import subprocess
import sys
import time
win = sys.platform.startswith('win')
old_dir = g.os_path_abspath('.')
### Change the following for your machine
if win:
new_dir = r'C:\leo.repo\leo-editor'
path = r'C:\Users\edreamleo\Backup'
else:
new_dir = '/home/edward/leo.repo/leo-editor'
path = '/home/edward/Backup'
assert g.os_path_exists(new_dir), repr(new_dir)
assert g.os_path_exists(path), repr(path)
stamp = time.strftime("%Y%m%d-%H%M%S")
fn = g.os_path_finalize_join(path, 'leo-bundle-all-%s' % (stamp))
bundle_command = 'git bundle create %s --all' % fn
print(bundle_command)
os.chdir(new_dir)
# os.system(bundle_command)
proc = subprocess.Popen(bundle_command, shell=True)
proc.wait()
os.chdir(old_dir)
print('done! wrote %s' % fn)

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: sqlite-leo and collecting settings

[vitalije]

While trying to test new show-fonts capabilities, I have noticed that in 
leoSettings.leo there are just a few at-font settings. However, when 
searching for at-font in Nav panel, it finds tons of settings of the 
following form:

@string  @font-...

It seems that at-font settings kind is replaced with other methods of 
configuration. In the chapter about customizing Leo, there is just one 
paragraph about at-font type of setting and in given example several values 
are set to None. One can't figure by reading that paragraph what can be set 
in _weight, _slant values. Size is maybe obvious but can it be set to 
float? Is it point size or pixel size? 

Is this feature deprecated in favor of something else?

-- 
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: sqlite-format and settings - ideas

[Xavier G. Domingo]

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 develop

Re: sqlite-leo and collecting settings

[vitalije]

>
> When user edits at-font settings node, clicking OK should adjust body of 
> node to selected font. 
>

Done at  30c6dae.
Warning: previously command show-fonts expected that font family is in 
clipboard and it copied selected font family in clipboard after dialog 
confirmation. Now this command doesn't use clipboard but it adjusts body 
changing accordingly not only family but also weight, slant and size  of a 
font.

When invoked outside of at-font node it doesn't do anything special with 
selected font.
Vitalije

-- 
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.

sqlite-leo and collecting settings

[vitalije]

Recently, I was working mostly on a leo.external.sax2db script (*part of 
sqlite-leo branch). Idea was to make stand-alone script that can parse xml 
leo document and produce sqlite db version of it. The first part of it was 
to transfer outline with all vnodes and their ivars including v.u. This 
part went smoothly and it is capable of turning any Leo document from XML 
file to its db version.

The second part was supposed to collect all the settings from the outline 
and store them in separate table. I wished to implement it in such way that 
it uses from Leo code base only those objects that are easy to instantiate, 
that don't require special init code. And I almost made it. It searches 
tree and collects all settings creating table of tuples:

(gnx, kind, name, value, conditions)

conditions is a list of conditions that affect this particular setting. A 
condition may have any of the following forms:

   - ifhost: hostnames,...
   - ifenv: env values,...
   - ifplatform: platform,...

In tuple this list of conditions is joined with some special separator 
'|#|' which is unlikely to be part of hostname, environment vars or 
platform names.

The idea was to store all those tuples in database table and on opening Leo 
document to calculate conditions and select only those settings whose 
condition list is True. Empty list of conditions is considered to be True.

I have been implementing one by one all needed functions for dealing with 
different kinds of settings and everything went smoothly until I came to 
at-commands, at-buttons and at-outlinedata kinds. Those kinds require 
g.getScript, and it requires operational commander. Now I had two choices:

   1. to re-implement g.getScript without commander and that means 
   re-implement write file logic with all possible at-directives, or 
   2. to raise white flag and admit that it was a bad idea in the first 
   place

This get me to think again about the reasons that lead me to this. I wanted 
an easy way to change shortcut, or color or font and see the effect without 
delay. I wasn't feeling very comfortable with the idea of using PyQt to 
implement those features and I wished to implement gui for those parts in a 
web page where I feel more like being at home. For creating such web page I 
needed access to settings and some way to persist the changes in settings. 
Now, after swallowing large amounts of Leo's code, I feel confident enough 
to access all settings data directly in Leo. As far as persistence is 
concerned, I am confident that I can write command to open relevant 
settings file, make change there and save it again. So that part of the 
problem is solvable. The only thing that remains to be done (apart from web 
page) is reloading settings and Edward has created branch for it and 
presumably it will be done in foreseeable future.

Now as I am becoming more and more familiar with Leo's code, implementing 
something in PyQt doesn't seem so frightful anymore. I need to experiment a 
bit.

I wish to implement as a start three very simple dialogs. One for entering 
shortcut, one for entering color and one for entering font. As I write this 
I have just remember that commands `show-fonts` and `show-color-wheel` 
already exists. So it will be just shortcut dialog. It will have just one 
input control which will register any KeyEvent in format that Leo would 
accept for at-shortcuts setting line. When user edits at-color settings 
node, opening color dialog should start with the present color value 
selected and after clicking OK it should change the value in headline. When 
user edits at-font settings node, clicking OK should adjust body of node to 
selected font. When editing line in at-shortcuts node opening shortcut 
dialog should change the relevant line with pressed key combination. In 
more advanced version of shortcut dialog it may present user a list of all 
commands, filter field for filtering commands list and user would be able 
to select command from list and press key combination to be bound to 
selected command.

Vitalije

-- 
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.