Re: Revisiting the generation of the .nsi install script
On Mon, Sep 7, 2009 at 12:02 AM, David Szent-Györgyi das...@gmail.comwrote: Bear with me in this long essay. I have to convince Edward to abandon code that he has just written. The problem with long essays, is that hardly anyone reads them. I sympathize with the goal of making it easier to change the installer script. I don't usually like to do that by creating three external files that must be kept in synch :-) It's already bad enough that we must remember to bzr ls -R bzr-manifest.txt before running the install script. Could you live with the following scheme? Place all boilerplate in nsi-installer-boilerplate.txt. The nsi generation script (in @button make leo.nsi) will copy that file verbatim near the start of leo.nsi. This seems a bit simpler than what you propose. Edward --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Revisiting the generation of the .nsi install script
On Sep 7, 7:05 am, Edward K. Ream edream...@gmail.com wrote: I sympathize with the goal of making it easier to change the installer script. I don't usually like to do that by creating three external files that must be kept in synch :-) It's already bad enough that we must remember to bzr ls -R bzr-manifest.txt before running the install script. Could you live with the following scheme? Place all boilerplate in nsi-installer-boilerplate.txt. The nsi generation script (in @button make leo.nsi) will copy that file verbatim near the start of leo.nsi. This seems a bit simpler than what you propose. I sympathize with your desire to not abandon a scheme that works now in favor of one that you have not seen work. I expect that you would not relish the prospect of further labor: of changing the outline nodes that generate the script and one-time edits to restore the .nsi file. I won't volunteer anyone's time but my own for this. I could create a branch from a suitable revision of Leo's source code, working in private until my code is finished. I could even publish it on Launchpad for anyone else to follow along. The rest of Leo would change during my work, but I doubt that the contents of leoDist.leo and the files it contains would see changes from anyone other than me. My development would start with work to implement my scheme alongside yours, generating a separate .nsi file and using software -- a diff tool or Leo itself -- to prove that my scheme's .nsi file includes the exact statements included in yours. There -- no essay, just blunt English! With the human aspects of this addressed, on to the technical arguments! Your proposal -- putting all the boilerplate in a .txt file -- would allow me to maintain all the code in one place. It would still mean editing the boilerplate in the .txt file and the calls to the boilerplate in a Python script elsewhere in the Leo outline. I see this as similar to keeping the Leo trunk and a release branch in sync, which you write elsewhere is causing you headaches this week. I think the outline would be easier for developers to understand if the .nsi file were fully represented as a first-class citizen. The current scheme uses a button to generate the .nsi file. The scheme that I am suggesting would still use a button.This revised button would generate the file manifest, delete manifest and definitions .nsi files for the real .nsi file to include. Why not have the button call bzr to generate the manifest file and then call the NSIS compiler to generate the .exe, and (if the compilation turns up no errors), delete the manifest files and the .nsi file? That way there would be no synchronization problem -- the Leo outline's button would be the *only* way to generate the Leo installer. I read in multiple sources that Python is a great tool for gluing together other software. This sounds like a gluing job. -- David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Revisiting the generation of the .nsi install script
On Mon, Sep 7, 2009 at 7:47 AM, David Szent-Györgyi das...@gmail.comwrote: Your proposal -- putting all the boilerplate in a .txt file -- would allow me to maintain all the code in one place. It would still mean editing the boilerplate in the .txt file and the calls to the boilerplate in a Python script elsewhere in the Leo outline. This seems to me to be a reasonable plan: - Rather than reading the boilerplate, the script generator script could simply generate an !include line. - leoDist.leo could contain @thin nsi.boilerplate.txt tree. This scheme would allow all aspects of the final .nsi script to be written in leoDist.leo. Edward --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Revisiting the generation of the .nsi install script
On Sep 7, 9:01 am, Edward K. Ream edream...@gmail.com wrote: On Mon, Sep 7, 2009 at 7:47 AM, David Szent-Györgyi das...@gmail.comwrote: Your proposal -- putting all the boilerplate in a .txt file -- would allow me to maintain all the code in one place. It would still mean editing the boilerplate in the .txt file and the calls to the boilerplate in a Python script elsewhere in the Leo outline. This seems to me to be a reasonable plan: - Rather than reading the boilerplate, the script generator script could simply generate an !include line. - leoDist.leo could contain @thin nsi.boilerplate.txt tree. This scheme would allow all aspects of the final .nsi script to be written in leoDist.leo. I can try later to convince you otherwise, but it'll be best for the users if if we go with your nsi.boilerplate.txt tree plan for now. I will branch from the initial nsi.boilerplate.txt revision and start enhancing the installer. Would you like me to publish my branch before you return from vacation? It would be available for the use of anyone who needs an installer fix. -- David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Revisiting the generation of the .nsi install script
On Mon, Sep 7, 2009 at 9:39 AM, David Szent-Györgyi das...@gmail.comwrote: Would you like me to publish my branch before you return from vacation? It would be available for the use of anyone who needs an installer fix. Sure, go ahead. Edward --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Revisiting the generation of the .nsi install script
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
