Bear with me in this long essay. I have to convince Edward to abandon code that he has just written. I do have a replacement in mind, which I describe. I also have a Leo story to tell -- one that shows that my experience using Leo has soured me on working without it!
With a new scheme for generating the .nsi file just launched with the release of Leo 4.6.3, my timing is poor, but I think the generation needs to be revisited;. The version just finished greatly simplifies the maintenance of the lists of files installed and files uninstalled, but it renders maintenance of the rest of the script painfully difficult, much more difficult than was the case with the .nsi install scripts used for Leo 4.4 and earlier. I propose an approach that would preserve Edward's automated generation of lists of files and allow the maintenance of the script source code in Leo. For the sake of the reader whose interest ends with the proposed approach, let us start with that. It is straightforward. The list of "File" commands and the list of "Delete" commands that represent the files to be installed or uninstalled go in separate "LeoInstallManifest.nsi" and "LeoDeleteManifest.nsi" files; the source code for leo.nsi uses "!include" commands to use the NSIS compiler's preprocessor to incorporate these two files. The definitions created by the Python script are written to a "LeoDefinitions.nsi" file; the source code for leo.nsi uses another "!include" command to pull in the contents of that file. This way, we can generate "LeoInstallManifest.nsi" and "LeoDeleteManifest.nsi" and "LeoDefinitions.nsi" using the Python code from the Leo 4.6.3 leoDist.leo. Edward retains the automation for which he worked; because we can abandon the special-purpose Python code that writes the source code for the rest of the .nsi file; because we can abandon the one-off preprocessor written in Python; and because the leoDist.leo outline becomes more stable because the ever- changing manifests and definitions are generated by code that does not change. Developers working on the logic of the installer gain because the .nsi file lives in a Leo outline. I have already hand-tested the use of the "!include" command to include a LeoInstallManifest.msi file, and the NSIS compiler runs to completion on the result, so I'm confident that this is feasable. The required changes to leoDist.leo should be minimal, a few hours' work at most. Any comments? I am willing to get started on the changes, beginning with a switch to my proposed approach incorporating no changes to the installer; with that accomplished, Edward, Rob Sheppard, any other interested folk and I can start enhancing the installer itself. Now, on to my Leo story. In working on the new Leo installer script, Edward went to some trouble to automate the generation of the lists of files that are to be installed or uninstalled -- because hand-editing those lists is at best a distraction from the work he really wants to do. That makes sense to me; I hate such distractions in my own development work. I ran into many such in making changes to the logic of the installer script as that script exists in the released Leo 4.6.3. This release of the script is broken into small pieces, each of which is altered to allow for preprocessing and stored in a Python string. The code in each string is no longer exactly in NSIS installer syntax, and any changes to it must be altered so that the preprocessor produces a legal .nsi file. The script is source code, and treating it as boilerplate text in Python strings prevents the use of Leo to maintain the source code. As the script grows more complicated, that becomes a barrier to development. Here I illustrate. The changes on which I am working introduce additional logic in a number of the sections of code. In the Leo outline that contains my installer for Version 4.4-rc1 of Leo, the added logic exists in nodes that are children of the sections to which they apply. How to add that logic to the Version 4.6.3 installer? I can think of two schemes for this. According to the first, I would simply paste the longer logic in the existing strings. That quickly buries the logic, rendering the code Really Hard to Read. According to the second scheme, I would replace the relevant guts of the generator. For each Python function that required new logic, I tear out the simple string assignment and put statement, and in its place I write more functions, each of which contains a simple string assignment and put statement. I tried this second scheme. For example, in place of the putOnInit function, I produced a new putOnInit, which calls ten functions, three of which also call functions. Why is this a Leo story? It is such because I am used to using Leo to break down long sections of code into comprehensible parts, and I was doing that by hand in this code. In short, I was mimicing the Leo outline in the hand-written source code in the hope of returning the code to Leo later! I was working very hard in order to *solve the wrong problem*. Instead, I needed to develop a scheme that would allow me to move the leo.nsi file back under into a Leo outline. Leo has spoiled me rotten, and I just can't tolerate wimpy tools anymore. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
