On Mon, Jun 26, 2017 at 11:21 AM, vitalije <vitali...@gmail.com> wrote:
> What would be the benefits if Leo configuration code use database to store > and retrieve settings > [?] > An interesting question. As I understand you, you are, in effect, suggesting that Leo cache the contents of leoSettings.leo and myLeoSettings.leo. That has the potential to speed the loading of Leo significantly. > I believe that Leo startup code could be greatly simplified if the > settings are available just by opening a database connection. > Let's be absolutely clear about the following: 1. Caching *never* simplifies code. It always adds more complexity. That complexity can be justified, as it is in Leo's atFile read code. I've just spent a week improving that code. It may well be that caching myLeoSettings.leo and LeoSettings.leo could significantly speed up Leo's startup time. 2. I shall not approve of any scheme that changes the *users' *view of Leo's settings. That is, myLeoSettings.leo and leoSettings.leo must remain *exactly *as they are. 3. Using sqlite is a dubious choice because it would add another installation requirement to Leo (or your plugin). Instead, you can probably use the PickleShareDB class in leoCache.py to maintain key/values pairs. I would suggest doing your experiments in a plugin if at all possible. > There is no need to postpone any initialization because settings haven't > been fully read yet. I have tried several times to understand what exactly > is going on during initialization but I gave up every time because it was > nightmare of indirect calls, halfway initialization, > Init code is inherently difficult, because init order matters a lot. Imo, there is no simple solution to this problem. The basic init pattern is relatively simple. I learned it from careful study of Apple's YellowBox code. The finishCreate methods complete inits that could not be completed earlier because not all data, and *especially not all objects*, exist. ... Almost all important members are initialized twice or more times. Once > with the simple or dummy value, and later reinitialized with the correct > one. Because of that there are everywhere checks if some dict is properly > initialized or not. Arguably all that stuff could be written much simpler > if c.config was present at the very beginning of the execution process. > It's the *objects *that don't exist, not just settings. Defining settings early doesn't help all that much. Attached to this message is sqlite3-config-benchmark.leo. Executing the > script in its first node, performs all the steps I wrote about and prints > in Log pane times for retrieving value of every setting 1000 times. On my > computer it take about 6.5 s for c.config and 5.5 s for sqlite3 to give all > those values. > As I said earlier, caching settings may be a reasonable thing to do. > I am not so good in programming PyQt gui, but if all settings are kept in > sqlite database, I could easily make single page web application and > minimal REST server for accessing/adjusting all settings in web browser. > Interesting. This scheme could coexist with myLeoSettings.leo. Or rather, it *must* coexist with myLeoSettings.leo > Leo would need just one simple command to open local url in users default > browser and user would be able to tweak any and all of the settings in > browser. > That would be good, provided that the server would update myLeoSettings.leo. > Server could be implemented in python and may actually run in the same Leo > process or in other separate process. Leo would be aware of any such change > in settings immediately. > Good. > It would not be necessary to restart Leo to see changes. Maybe some of the > changes would require restart, but most of them IMHO would not. > At present, many settings are cached in object ivars, so changing what c.config.getX returns may not make Leo fully "aware" of the new settings. #417: Complete reload-settings <https://github.com/leo-editor/leo-editor/issues/417> is intended to fix this problem. 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.
