Re: Is something basic missing from Leo?
LeoPy.leo or LeoPyRef.leo are not the leo files I'm concerned about. I want to collaborate with my colleagues on the forests of system configuration I maintain, and we are frequently committing to our (internal) repository. It is the rare exception that I'm working on something I want only in my own copy. If something is irrelevant cruft, just collapse the node; to concentrate on an area, hoist(*)! The Recovered Nodes give me hope that a humanly useful representation of changes is possible. I need to study that code. The result is so much better than opaque XML operations. - Stephen * (reminder to self: check hoist description in Chapter 3.) -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: Is something basic missing from Leo?
The important information is ONLY in the Leo file. @thin is an impoverished coping mechanism. @auto functions correctly for a tiny fraction of the code I'm concerned with (it fails on perl and ruby, and having Leo-structured those by hand, I'm convinced that automated parsing is either theoretically impossible (perl) or close to useless (riuby)). For instance, when studying code I build partial call-in and call-out graphs, with the call-in node for a function/method A containing a clone of the code node for function A, plus clones of the other call- in nodes which call this function (this would be a general graph; I omit clones that would create a cycle when describing a recursive function by using UNLs instead). For another instance, the Leo file *is* the documentation of the puppet configuration: a host is described by a Leo node that contains a clone of the node containing the code applied to the host; the code is described by a node containing a clone of the specific code plus a clone of the documentation node for each classes, modules or definitions it includes, and so on recursively. The Leo files is **IT**: the ONE source of truth and the one containiner of everything. The Leo file is to derived files as source code is to machine language. only more so. - Stephen On Aug 2, 12:25 pm, Edward K. Ream edream...@gmail.com wrote: On Mon, Aug 2, 2010 at 11:10 AM, thyrsus sschae...@acm.org wrote: LeoPy.leo or LeoPyRef.leo are not the leo files I'm concerned about. I want to collaborate with my colleagues on the forests of system configuration I maintain, and we are frequently committing to our (internal) repository. In that case, using @thin or @auto external files seems like the best way. The Recovered Nodes give me hope that a humanly useful representation of changes is possible. I need to study that code. The result is so much better than opaque XML operations. The code is quite simple, because it is diffing body text, not xml. I would be very interested in a clearer representation of diffs, but I don't have a lot of hope. Even bzr qdiff, good as it is, often fails to convey the true nature of changes. 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-edi...@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: Is something basic missing from Leo?
On Aug 2, 1:26 pm, Edward K. Ream edream...@gmail.com wrote: On Mon, Aug 2, 2010 at 12:09 PM, thyrsus sschae...@acm.org wrote: Leo's compare-leo-files command compares two outlines created by the .leo files. Diffing Leo outlines (rather than the xml that generates them) is a snap because every node has a gnx! Thus, discovering inserted and deleted nodes is trivial, and diffing changed nodes is just a matter of comparing headline and body text. However, the problem of understanding the diffs still remains. It's a human interface problem. Yes! Thanks for emphasizing the compare-leo-files command. That, combined with a human interface for change reconciliation, perhaps hinted at by the Recovered Nodes techniques, is what I need for collaboration. Or there may be some magic in Google wave's eventual consistency/ operational transforms (http://arstechnica.com/open-source/news/ 2009/07/google-releases-wave-protocol-implementation-source-code.ars), topics which I believe were addressed by Rodrigo Benenson in the proposals for LeoN. Perhaps the trick will be to get Google excited about Leo ;-). I've never learned interface design; it's always been a gift from the gods for me - that is, the result of someone else's talent and hard work. - Stephen -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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.
Thinking about graphs
I think a lot of Leo's power comes from its ability to represent DAGs, so my interest is piqued when someone discusses graphs for problem solving. I haven't digested it yet, but this presentation is fascinating: Problem Solving using Graph Traversals http://www.slideshare.net/slidarko/problemsolving-using-graph-traversals-searching-scoring-ranking-and-recommendation -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: OpenSuse Fedora RPM's available
The RPM works under Fedora 13 x86_64. I began with the default desktop spin. It was necessary to do either yum -y install tkinter python-pmw -or- yum -y install PyQt4.x86_64 A yum search pyqt showed both i386 and x86_64 versions available for my machine, so I insisted on the x86_64 version. In either case, a half dozen or so packages get pulled in for dependencies. Leo works as expected with one or both installed. Thanks! - Stephen On Jul 28, 5:41 am, Ville M. Vainio vivai...@gmail.com wrote: On Wed, Jul 28, 2010 at 1:15 AM, thyrsus sschae...@acm.org wrote: On the topic of dependencies, there may be some optional components, such as Tk or Qt, Sphinx and LaTex, aspell (or is it mandatory?). Should the rpm specify all of them? None of them? Multiple rpms to support multiple extras? I didn't pay any attention to dependencies at all. On ubuntu packages I depend on pyqt only. Leo works without the optional dependencies... and actually aspell is a dependency that trends to crash leo if it's available ;-). -- Ville M. Vainio @@ Forum Nokia -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: OpenSuse Fedora RPM's available
I've discovered how aspell gets installed without any language package: a yum install emacs does it. One solution is to install the aspell package language that aspell will use, which is usually aspell- en (the default on my system, when there is no LC_MESSAGES environment variable). Beware, if your LC_MESSAGES=fr (e.g.) then you must have aspell-fr installed or Leo will core dump (not Leo's fault, really, but the fault of the python aspell API implementation). Even worse, if LC_MESSAGES=C or any other unrecognized code, it core dumps then as well! - Stephen On Jul 28, 7:32 am, thyrsus sschae...@acm.org wrote: The RPM works under Fedora 13 x86_64. I began with the default desktop spin. It was necessary to do either yum -y install tkinter python-pmw -or- yum -y install PyQt4.x86_64 A yum search pyqt showed both i386 and x86_64 versions available for my machine, so I insisted on the x86_64 version. In either case, a half dozen or so packages get pulled in for dependencies. Leo works as expected with one or both installed. Thanks! - Stephen On Jul 28, 5:41 am, Ville M. Vainio vivai...@gmail.com wrote: On Wed, Jul 28, 2010 at 1:15 AM, thyrsus sschae...@acm.org wrote: On the topic of dependencies, there may be some optional components, such as Tk or Qt, Sphinx and LaTex, aspell (or is it mandatory?). Should the rpm specify all of them? None of them? Multiple rpms to support multiple extras? I didn't pay any attention to dependencies at all. On ubuntu packages I depend on pyqt only. Leo works without the optional dependencies... and actually aspell is a dependency that trends to crash leo if it's available ;-). -- Ville M. Vainio @@ Forum Nokia -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: OpenSuse Fedora RPM's available
Oh, and if LC_MESSAGES is not set, it appears to use LANG, so if LANG=de, you need aspell-de installed or you will core dump. I'm not familiar with the python aspell API; would someone more familiar be willing to make a bug report? - Stephen On Jul 28, 4:21 pm, thyrsus sschae...@acm.org wrote: I've discovered how aspell gets installed without any language package: a yum install emacs does it. One solution is to install the aspell package language that aspell will use, which is usually aspell- en (the default on my system, when there is no LC_MESSAGES environment variable). Beware, if your LC_MESSAGES=fr (e.g.) then you must have aspell-fr installed or Leo will core dump (not Leo's fault, really, but the fault of the python aspell API implementation). Even worse, if LC_MESSAGES=C or any other unrecognized code, it core dumps then as well! - Stephen On Jul 28, 7:32 am, thyrsus sschae...@acm.org wrote: The RPM works under Fedora 13 x86_64. I began with the default desktop spin. It was necessary to do either yum -y install tkinter python-pmw -or- yum -y install PyQt4.x86_64 A yum search pyqt showed both i386 and x86_64 versions available for my machine, so I insisted on the x86_64 version. In either case, a half dozen or so packages get pulled in for dependencies. Leo works as expected with one or both installed. Thanks! - Stephen On Jul 28, 5:41 am, Ville M. Vainio vivai...@gmail.com wrote: On Wed, Jul 28, 2010 at 1:15 AM, thyrsus sschae...@acm.org wrote: On the topic of dependencies, there may be some optional components, such as Tk or Qt, Sphinx and LaTex, aspell (or is it mandatory?). Should the rpm specify all of them? None of them? Multiple rpms to support multiple extras? I didn't pay any attention to dependencies at all. On ubuntu packages I depend on pyqt only. Leo works without the optional dependencies... and actually aspell is a dependency that trends to crash leo if it's available ;-). -- Ville M. Vainio @@ Forum Nokia -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: OpenSuse Fedora RPM's available
Splendid; this becomes my project for the evening: fire up a virtual machine and get Fedora 13 installed, then install this rpm. In the past, I've just installed dependencies as needed; this time, I'll try to keep careful track. On the topic of dependencies, there may be some optional components, such as Tk or Qt, Sphinx and LaTex, aspell (or is it mandatory?). Should the rpm specify all of them? None of them? Multiple rpms to support multiple extras? - Stephen On Jul 27, 2:32 pm, Ville M. Vainio vivai...@gmail.com wrote: I've been toying with OBS (opensuse build service, the service that is used to create opensuse and MeeGo), and built Leo rpms for opensuse and fedora. I know the opensuse one works, but haven't tried fedora (because I don't have it installed). Fedora: http://download.opensuse.org/repositories/home:/vivainio:/leo/Fedora_... Opensuse: http://download.opensuse.org/repositories/home:/vivainio:/leo/openSUS... I used spectacle to build the rpms. Here's the yaml file I had to create: https://build.opensuse.org/package/view_file?file=leo.yamlpackage=le... It still needs some polishing work (desktop file, icon etc) but gets the job done - you'll have /usr/bin/leo that launches leo properly. BTW, just using distutils (python setup.py bdist_rpm) is not something that the distros would accept, you have to go through the full rpm build routine as I did here. -- Ville M. Vainio @@ Forum Nokia -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: Revisions to User Guide Chapter 4 now on trunk.
Thanks! I've been a way from the internet for a couple days, but I've now incorporated your suggestions. On Jul 21, 7:59 pm, tfer tfethers...@aol.com wrote: Know that I'm on the right revision, here are some proposals: Creating and destroying nodesNow that I'm looking at the right leoDoc.leo: Chapter 3 -- Outline Related --- Navigating through the outline ... When focus is in the outline Pane, you can move from node to node by typing the first letter of a headline. For example, typing 'a' will go to the next visible headline that starts with either 'a' or 'A', wrapping around to the start of the outline if needed. Typing an uppercase 'A' will go to the next headline that starts with 'a' or 'A', making the node visible (expanding its ancestors) if the node was not visible. - this is not implemented in the Qt gui Expanding contracting nodes You can expand or contract a node by clicking in the tree view icon to the left of the headline. The icon in the Qt gui matches the native OS's tree view icon, i.e. for Mac's; a triangle pointing right or down, on Windows; (also when using the Tk gui), a square containing a plus or minus. Expanding a node shows its immediate children; contracting a node hides all its children. The corresponding commands are ``expand-node`` and ``contract-node``. For more convenient navigation, there are ``expand-and-go-right`` and ``contract-or-go- up`` which are bound to Alt-Right and Alt-Left. The ``expand-all`` command expands every node in the outline. ``contract-all`` contracts every node in the outline. Both commands are availble in the Outline-Expand/Contract... submenu. ``contract- all`` is bound to Atl-- (Alt modifying a single hyphen). In all but the smallest outlines, ``expand-all`` is rarely used, and so does not have a key binding. -- note that there is no expand-all-subheads command, as bourne out by trial minibuffer expansion. Creating and destroying nodes The ``insert-node`` command inserts a new node into the outline; it is bound to Control-I and the Insert key. When invoked, (from any pane), it inserts a new node below the presently selected node, and at the same level as that node, or at the child level if it has a child vissible. The ``delete-node`` command deletes a node and all its children; it is initially unbound. If you want to retain the children you must promote all the children before you do the delete. Cloning nodes A cloned node wil become a regular node again whenever deletion makes it the only instance left. A cloned node is a copy of a node that changes when the original changes. One may also think of it as a single node that is hooked into the outline at multiple positions. Because that single node brings along all its desendants, changes are maintained across all the the clones of a node, along with changes to its offspring (children, grandchildren, etc.), i.e. any changes are simultaneously made to the corresponding offspring of all of those clones. A small red arrow in the icon box marks cloned nodes. You can think of the arrow as pointing out that there are other paths to get to this same node. There is no real distinction between the original node and any of its clones. Any headline or body update of a clone headed subtree affects all of its clones simultaneously. A cloned node becomes a regular node whenever deletion of its other clones makes it the only one left. Clones are useful for making alternate views of a program. See `Clones and views`_ for full details. The command ``clone-node``, (Clone Node in the Outline menu, bound to Control-`) creates a clone as the immediate sibling of a selected node. You have to place it where you want it by either using move commands, or cutting and paste the clone. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: Revisions to User Guide Chapter 4 now on trunk.
Thanks so much! I'll be incorporating these tomorrow. I also see I missed an instance of @path appending - @path prepends, or, probably better, prefixes. - Stephen On Jul 20, 9:22 pm, tfer tfethers...@aol.com wrote: Here are some notes for part of chapter 4 Overview: creating and using external files - You create and use external files using @file directives. Most of these directives may only appear in headlines. Here are all the ways of creating external files: Perhaps: You create and use external files by @file directives. Most of these directives may only appear in headlines. They consist of one of the directives below, a space, and a path and file name, or a filename resolvable via a @path directive in an ancestor node. Note that for all these directives, (except @root), only body text occurring in the directive's subtree can end up in the file written, (neglecting sentinel text). Here are all the ways of creating external files: ... The choice between CWEB and noweb is independent of the directive is used to create external files. Perhaps: The choice between CWEB and noweb is independent of which directive is used to create external files. or: The choice between CWEB and noweb is independent of whatever directive is used to create external files. Overview: summary of directives - - *...@auto** Imports the external file every time Leo reads the outline. The read-at-auto-nodes and write-at-auto-nodes commands can be used to read and write and @auto nodes. To: - *...@auto** Imports the external file every time Leo reads the outline. Leo determines what computer language that file is written in from its extension, and uses a set of rules defined for that language to create an outline for that file auto-maticaly. If no rules exist for that language, the file is first put in a single node, the same as @edit. The read-at-auto-nodes command does the same thing as opening up an outline with an @auto node does. The write-at-auto-nodes command will do the same thing as a save, that is, write out the @auto nodes. - *...@ignore** Causes Leo to ignore all or part of an external file. Hmm, that does not seem quite right, isn't it something closer to: - *...@ignore** Causes Leo to ignore this node and its descendants when writing out an external file. - *...@lineending** Sets the line ending to be used in external files. Additionally: - *...@lineending** Sets the line ending to be used in external files. Note that Leo uses newlines in its internal buffers, this directive only controls what line ending will be used in the file(s) it writes out. - *...@pagewidth** Sets the page width used to break doc parts into lines. Additionally: - *...@pagewidth** Sets the page width used to break doc parts into lines. In Leo, doc parts are comments that can be written as paragraphs, letting Leo wrap them to fit in the body pane. This directive tells what column to wrap them at when writing them to an external file. - *...@path** Set the path to be appended to filenames. Additionally: - *...@path** Sets the path to be appended to the filenames following any @file directive. This only affects descendant @file nodes. - *...@verbose**, *...@terse**, *...@quiet** and *...@silent** Set the verbosity of sentinels in external files from @root. Perhaps: - *...@verbose**, *...@terse**, *...@quiet** and *...@silent** Set the verbosity of sentinels in external files generated from an @root. Tom On Jul 17, 2:02 pm, thyrsus sschae...@acm.org wrote: Proofreading much appreciated! -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: Revisions to User Guide Chapter 4 now on trunk.
I'm afraid some of this applies to an older version, for instance, I had noticed that Control-n opened a new Leo window, and I removed that from my version. Could you please download the version on the trunk and work from that? Alternatively, you could work from the PDF file here: http://www.angelfire.com/vi/oremacs/LeoDoc.pdf - Stephen On Jul 20, 8:06 pm, tfer tfethers...@aol.com wrote: On Jul 17, 2:02 pm, thyrsus sschae...@acm.org wrote: Proofreading much appreciated! See you touched chapter 3 also, here are my notes on that: Under: Cloning nodes - A cloned nodes becomes a regular node again when its penultimate clone is deleted. sxtra s: node, also penultimate might be a little high brow Perhaps: A cloned node wil become a regular node again whenever deletion makes it the only instance left. Creating and destroying multiple body editors - Three commands in the Cmds:Body Editors menu allow to create and destroy separate editors in the body pane. misspeaks: Perhaps: Three commands in the Cmds:Body Editors menu allow to create, destroy, or cycle focus on; separate editors in the body pane. Dragging nodes - I think this only applies to Tkinter gui; Perhaps: (Note: not implemented in Qt gui yet.) Editting body text - - Normal printing characters are inserted at the point of the insertion cursor. Not all the story: Perhaps: - Normal printing characters are inserted at the point of the insertion cursor, (overwritting any selection). - Control-Shift-Up and Control-Shift-Down move the insertion cursor by paragraphs and extend the selection. Control-p and Control-n behave the same as Up and Down, respectively. **Note**: by default, Leo binds Control-p and control-n to commands. not true for Qt, plus isn't control-n bound to New in the file menu? - Control-/ selects the entire contents of the widget. - Control-\ clears any selection in the widget. not true for Qt Expanding contracting nodes - You can expand or contract a node by clicking in the standard Windows Tree View icon to the left of the status icon. Expanding a node shows its immediate children; contracting a node hides all its children. The Expand All Subheads command expands all of a nodes offspring (children, grandchildren, etc.) Perhaps; You can expand or contract a node by clicking in the standard Windows Tree View icon to the left of the status icon, (the gray box with a plus or minus sign). Expanding a node shows its immediate children; contracting a node hides all its children. note that the command mentioned below is not exposed by the menus, and does not seem to exist any more. The Expand All Subheads command expands all of a nodes offspring (children, grandchildren, etc.) Navigating through the outline - Note only the first paragraph applies ot both gui's, the others aren't true for Qt. I'll have a look at chapter $ later Tom -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: @shadow node converted to @edit node
Please report your further experiences; I've got a lot of @shadow nodes. I take it this isn't happening for all @shadow; I've got a lot of them, but this hasn't happened for me. Can you speculate on what may have triggered this? Nearly all my @shadow nodes began as an import to @file, which I then converted to @shadow. - Stephen On Jul 14, 10:47 am, zpcspm zpc...@gmail.com wrote: I just opened a leo outline that contains a @shadow node and it added the external file as @edit node instead. I'm running current trunk and the outline was edited last time before new-sentinels was merged into the trunk. What is the correct workflow in this situation? Would renaming the @edit note to @shadow and refreshing from disk suffice? -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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.
Fedora 12 aspell requires aspell-en (or, likely, at least some aspell-${language})
I was trying to start Leo on a Fedora 12 machine, and it was very briefly throwing up its first window, then python crashed with Segmentation fault. Running under gdb, usually the stack corruption obscured the ultimate cause of the problem, but on one occasion, I was able to see that aspell was trying to disable itself, and, looking at the the rpm -qa | grep aspell output, I noted that no languages were installed. Sure enough, the problem stopped when I installed aspell- en. FYI. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: New sentinels: progress report
\nThat kind of round trip testing is what I've been doing to test tangle/untangle in @root. I followed along with an earlier decistion to pollute the code with a dependency on g.unitTesting to put the test result from/to an in-memory dict instead of an actual external fille; the advantange is that one doesn't have to deal with all the externalities created by the OS file system; the disadvantage is that one doesn't test dependencies introduced by the OS filesystem. We each have our threshhold for acceptable corruption ;-). I'm sure we'll need to fix the kind of code duplication mentioned (if a node contains i++\n and turns into i++\ni++\n, I don't think anyone's going to be happy - although the functional programmers might be immune - all 0.001% of them :-}). On the other hand, my code to remove @language and @comment directives from the generated file and then reintroduce them after an untangle changes the section part definition can leave spurious blank lines. At the moment, I'm too concerned with other issues to deal with it. On Jul 1, 8:40 am, Edward K. Ream edream...@gmail.com wrote: The new sentinels code has past its first major milestone. The following round-trip test passes: - Set new_write to True in the working copy of leoPy.leo. - Start a test copy of LeoPy.leo. Write leoAtFile.py, thereby generating new sentinels. - Restart the test copy of LeoPy.leo. Writing leoAtFile.py leaves the file unchanged. This is just the start of rigorous testing. At least two problems remain: 1. In some cases, not yet fully understood, clones can caused body text to be duplicated. Amusingly, this does not cause apparent harm: some nodes become something like: def foo(): body def foo(): body Python is fine with the duplication, though pylint would complain :-) 2. Text following section references, like: if ( condition ): becomes, after round-tripping: if ( condition ): BTW, the parens are required, because the expansion of condition will take several lines. I forget how this case was handled with old sentinels--something similar will be needed with new sentinels. Edward P.S. The works has had quite an ad-hoc flavor to it. It's not entirely clear how to put it on a more sold basis. Unit tests might help, but it's a bit hard to see how to make them easy enough to create to be really useful. More thought is needed on this topic. Perhaps a more useful approach would be to automate round-trip testing. This would involve a script that creates and compares the first and second generations of leoPy.leo and all of Leo's core files. EKR -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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.
Back to LeoDocs.leo
The coverage tool shows several features within the leoTangle.py code that aren't being tested; at this point, however, I'm more inclined to restart work on major revisions to Chapter 4 of the manual - which is what drove me to deal with the @root code in the first place. Perhaps as I attempt to explain features within the documentation, I'll be motivated to revisit them in the code. Last time, when I tried to explain what @root did in the documentation, I was driven to fix the code. Before fixing the code, I removed (@rst-ignore-tree) mention of @root from the documentation. That wasn't met with much enthusiasm. This time, I'm going to do my documentation work on the trunk. Question 1: if I encounter a non-working feature, is it acceptable to hide its documentation until someone is motivated to fix it? Question 2: If I find undocumented (working) features in the code, do I simplify the code by removing the feature, or do I document the feature? I'm looking for broad sentiments, not ironclad rules; i.e., if I find an undocumented feature with a trivial bug, but I decide i *want* that feature, it's going to get tested, fixed and documented :-). -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: New unit tests for @root fail for Python 3k.
Are these problems due to (a) python 3 (b) different OS or (c) differing configuration (e.g., $HOME/.leo/myLeosettings.lo)? If python 3, I'll be more motivated to update to Fedora 13, which has python 3 packages available. If different OS (e.g., Mac using \r for line endings) then I'll have to get supermotivated - the 8 year old minimac I've got access to has been turned off for two years, and I'm not sure what hardware surprises I'll suffer as I try to update its OS to something recent. If it's a matter of settings, then I need to account for that in the initialization before the tests, and I also need to write different tests for the other reasonable initialization. I already know from the coverage tool that there are a number of features (tangleCommands.print_mode == verbose, CWEB escape codes, etc.) that are untested. - Stephen On Jun 30, 2:15 pm, Edward K. Ream edream...@gmail.com wrote: On Wed, Jun 30, 2010 at 1:05 PM, Edward K. Ream edream...@gmail.com wrote: On Wed, Jun 30, 2010 at 11:43 AM, thyrsus sschae...@acm.org wrote: I'm now getting one unit test failure, but I don't think it's my code, so I'm pushing: I thought I had fixed this. I'll look again. The fix is on the trunk at rev 3141. This rev also adds some parens to print statements in leoTest.py so that Leo will once again run with Python 3k. On my machine 7 @root-related unit tests continue to fail, but I'm not too worried about that just now. 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-edi...@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: Plans for @root, redux
On Jun 16, 8:00 am, Edward K. Ream edream...@gmail.com wrote: On Tue, Jun 15, 2010 at 7:30 PM, thyrsus sschae...@acm.org wrote: Leo currently sets the internal flags use_raw_cweb_flag = use_noweb_flag = True use_cweb_flag = False The net effect is that, by not interpeting CWEB, Leo can write CWEB files for use with the external CWEB toolset. Because Leo imposes its own interpretation on noweb syntax, it would be awkward to use Leo in conjunction with the noweb toolset. There is historic code that will never get triggered in the presence of those flags; I'm not interested in exploring it. It would simplify understanding of the code if those portions were eliminated, but there may be value to someone who would like to revisit the code for CWEB-like code definition, so I'll let someone else do that. Please remove the switches and all the code that the switches disable. I think it is important to take every opportunity to simplify the code, especially the tangle/untangle code, and especially now that you are planning to change the code substantively. Aside from this, I think your plan is a good one. Edward I misread the code for self.raw_cweb_flag (not use_raw_cweb_flag): that's still useful in the presence of @language cweb. It insists on the full spelling of @code and @doc so that the CWEB elements '@' and '@c' can be passed to the derived file unmolested. Aside from that, the code is now simplified. I modified the unit tests so that they no longer test for the setting of the now absent tangleCommands.use_cweb_flag and tangleCommands.use_noweb_flag; unit tests all pass except for the failure of mixed @language html and @comment, which is my reminder that work still needs to be done. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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.
bzr workflow
I saw some odd versions go by, and I'm wondering if my workflow might be at fault. What I *intend* to do (and may execute imperfectly) is bzr pull * do work * bzr pull - if complaint about divergence, bzr merge bzr push Am I breaking things? -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: bzr workflow
On Jun 16, 6:45 pm, Terry Brown terry_n_br...@yahoo.com wrote: On Wed, 16 Jun 2010 15:03:21 -0700 (PDT) thyrsus sschae...@acm.org wrote: I saw some odd versions go by, and I'm wondering if my workflow might be at fault. What I *intend* to do (and may execute imperfectly) is bzr pull * do work * bzr pull - if complaint about divergence, bzr merge bzr push Am I breaking things? You're not breaking anything, but you're burying other people's commits in your merges. This causes no real damage, but it's better to avoid it, because it's easier to keep track of everything that's happened on the trunk if commits aren't buried in merges. So you want two copies of the trunk, one which is an unaltered copy, and one which is your working copy. Directory structure might look like this: leo.repo trunk root_update Do your work in root update, pulling, merging, and committing as you please. When you're ready to push, make sure everything's committed in root_updates, and then switch to your trunk directory, pull there (bound to succeed since you're not altering things in there), and then merge root_update into your local trunk, commit in trunk, and push from trunk. It's not really as much of a hassle as it sounds, although it does mean you have to give a commit message for the commit in trunk, which, if you'd only made one commit in root_update, is kind of redundant. The attached image shows the recent activity on the trunk. The three commits by Edward which start recommit after... show the redundant log messages I mentioned. Edward's merge commits only include his own commits as subcommits, whereas your latest included his previous. It's not a big deal, just clearer if avoided. There is a setting that Edward could apply to make it impossible to bite the head of the trunk, as it were, but I don't know if that's really necessary. btw, I'm sure whatever you're doing's very useful, but I've never used @root, that's the only reason I'm not commenting. Cheers -Terry trunk.png 172KViewDownload Thanks. Let me rephrase to be sure I've got it: cd trunk bzr pull cd ../root_update bzr pull * do work * bzr commit cd ../trunk bzr pull bzr merge ../root_update bzr commit bzr push Much appreciated. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: Multiple parts not allowed for secref
On Jun 15, 12:43 pm, Edward K. Ream edream...@gmail.com wrote: On Mon, Jun 14, 2010 at 11:26 PM, thyrsus sschae...@acm.org wrote: Concerning Multiple parts not allowed: Somewhat surprisingly, I still have the original manual, from 1990, so let's see what it says. Mine is the 1994 Version 3.0, so you've got me beat by four years :-) I just checked Chapter 4, and there no mention at all of +=. Thus, I think we can conclude that += is an undocumented feature, and we are free to treat it as we like. Actually, Leo doesn't really recognize +=; it would try to interpret foo += as an interpolation of the definition of section into the location immediately preceding +=; given the node == @root ttt9 secref one secref two secref one = part one secref two = part two secref one += part one point two == it tangles to === # secref one part one # -- end -- secref one # secref two part two # secref one part one # -- end -- secref one (!newline) += part one point two # -- end -- secref two === (I refuse to be distracted by newline handling right now). CWEB did treat += differently from =, but we can ignore that. CWEB used @ foo @= and @ foo @+= synonymoously; its weave would use the former in the first occurrence of the typeset output, and the latter for subsequent occurrences. noweb moved to the foo = syntax, and seems to have dropped the += format -- although, like CWEB, it uses = (actually, like CWEB, ≡) for the first occurrence in its typeset output, and subsequently += (+≡). To repeat, we probably do want to support both spellings, just in case somebody wants to make real CWEB sources from a Leo outline. The possibility is remote, but I see no particular reason not to allow the two spellings. I'll pursue implementing my proposal, but let's be clear what it is: Assuming that the node in question is the node or a subnode of a node containing an @root or @unit directive: * If a node has a headline foo , code sections introduced with @c at the beginning of a line will be appended to the definition of foo . * Code sections introduced with bar = in any node body will be appended to the definition of bar . * As before, @ at the beginning of a line introduces a documentation section. Leo defaults to noweb mode. I haven't explored what happens in CWEB mode. I invite someone who needs CWEB mode to generate unit tests and clarify the documentation. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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.
Changes to manual.
I haven't got any response from my proposed changes to the manual. Among many other changes, they disappear @root from Chapter 4, since there are serious bugs with @comment used with @root, and I intend to significantly rewrite those sections once I'm happier with @root myself. Should I be more aggressive and just work on the trunk? - Stephen -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: @root changes
On Jun 14, 11:08 am, Edward K. Ream edream...@gmail.com wrote: On Jun 12, 1:31 pm, thyrsus sschae...@acm.org wrote: I've just pushed some code concerning @root to the trunk. 6 unit tests fail for me at rev 3116. Also, the checkin message is simple (1), which isn't very helpful. Edward Hmmm. Here's the checkin message in the version I pushed: = revno: 3116 committer: Stephen P. Schaefer s...@thyrsus-laptop2.schaefer-home.org branch nick: leo-editor timestamp: Sat 2010-06-12 13:55:56 -0400 message: (1) The code checks for tangleCommands.head_root not none, but nowhere assigns head_root. To confirm my understanding, I added a number of assert self.head_root == None and found that they never triggered during testing. I speculate that they're there for future implementation of @root in the headline. (2) The testAtRootFile() code was trying to test untangle when @silent or @quiet were in effect, and untangle is impossible by design. I stopped doing that. (3) Sometime in the past, @doc sections were emitted as comments into the derived files, and code was present in untangle to ignore - and thus remove - such comments, at the cost of sometimes losing regular comments. Since Leo no longer emits @doc sections into the derived file, I removed the elimination of those comments from the @code sections during untangle, thus preserving some interlinear comments. (4) Of the unit tests that now fail, they are: (a) a bug in the test code for multiple @root directives in a single node (b) a Leo bug or a failure to understand the conditions in which a section may not have multiple definition parts (sometimes it can) (c) speculation on how mixing @language and @comment would = and it was truncated there, omitting some variation on the word work -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: @root changes
On Jun 14, 11:08 am, Edward K. Ream edream...@gmail.com wrote:
On Jun 12, 1:31 pm, thyrsus sschae...@acm.org wrote:
I've just pushed some code concerning @root to the trunk.
6 unit tests fail for me at rev 3116. Also, the checkin message is
simple (1), which isn't very helpful.
Edward
I'm only getting 3 failed tests; are you using Alt-4 or Alt-5? I'm
doing
python launchLeo.py leo/test/unitTest.leo
then hitting Alt-4
@root /tmp/'root-test'
.('\n', '')
expected files:
['root-test-one'] type 'unicode'
['root-test-two'] type 'unicode'
result files:
['root-test-one'] type 'unicode'
F('\n', '')
result for 'root-test'...
(' 38', u'!-- A less simple test of @root. --\\n')
(' 1', u'\\n')
(' 16', u'// secref \\n')
(' 4', u'abc\\n')
(' 1', u'\\n')
(' 32', 'u\'script type=text/javascript\\n\'')
(' 12', u'@comment //\\n')
(' 28', u'// javascript section \\n')
(' 1', u'\\n')
(' 38', u'// -- end -- javascript section \\n')
(' 10', u'/script\\n')
(' 18', u'@comment !-- --\\n')
(' 26', u'// -- end -- secref \\n')
expected for 'root-test'...
(' 38', u'!-- A less simple test of @root. --\\n')
(' 1', u'\\n')
(' 22', u'!-- secref --\\n')
(' 4', u'abc\\n')
(' 1', u'\\n')
(' 32', 'u\'script type=text/javascript\\n\'')
(' 15', u'// @comment //\\n')
(' 28', u'// javascript section \\n')
(' 7', u'var i;\\n')
(' 38', u'// -- end -- javascript section \\n')
(' 10', u'/script\\n')
(' 32', u'!-- -- end -- secref --\\n')
FMultiple parts not allowed for secref
- No file written because of errors
('\n', '')
expected files:
['root-test'] type 'unicode'
result files:
F...
End of leoUndo tests.
.('tree.redrawCount:', 363)
.saved: unitTest.leo
all unit tests done
.
==
FAIL: @test multiple @root directives
--
Traceback (most recent call last):
File /home/sps/Bzr/leo-editor/leo/core/leoTest.py, line 185, in
runTest
exec(script,d)
File string, line 5, in module
File /home/sps/Bzr/leo-editor/leo/core/leoTest.py, line 985, in
runRootFileTest
assert(expectList == resultList)
AssertionError
==
FAIL: @test @root with @language html and @comment //
--
Traceback (most recent call last):
File /home/sps/Bzr/leo-editor/leo/core/leoTest.py, line 185, in
runTest
exec(script,d)
File string, line 5, in module
File /home/sps/Bzr/leo-editor/leo/core/leoTest.py, line 1006, in
runRootFileTest
assert(expected[t] == result)
AssertionError
==
FAIL: @test @root-doc with subnodes
--
Traceback (most recent call last):
File /home/sps/Bzr/leo-editor/leo/core/leoTest.py, line 185, in
runTest
exec(script,d)
File string, line 5, in module
File /home/sps/Bzr/leo-editor/leo/core/leoTest.py, line 985, in
runRootFileTest
assert(expectList == resultList)
AssertionError
--
Ran 599 tests in 63.444s
FAILED (failures=3)
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email to leo-edi...@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: rename failed: no file created!
On Jun 14, 11:39 am, Ivanov Dmitriy usr...@gmail.com wrote: Leo 4.7.1 final, build 3005, February 26, 2010 Python 2.6.4, Tk 8.5, Pmw 1.3 Windows 5, 1, 2600, 2, Service Pack 3 I found out, that this bug occurs only when leo needs to create a new file. I created the file 'view.html.php' on disk and it was successfully rewritten. As a Unix guy, I find the windows permissions counterintuitive and misleading - and that's before network storage starts mixing in its constraints. Of course, windows folks probably feel the same about Unix permissions ;-). This does seem like a permssions problem: Leo creates the tangle candidate in the same directory as the intended result, then renames within that directory if it needs to update (or create) the file. - Stephen -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: @root changes
On Jun 14, 11:08 am, Edward K. Ream edream...@gmail.com wrote: On Jun 12, 1:31 pm, thyrsus sschae...@acm.org wrote: I've just pushed some code concerning @root to the trunk. 6 unit tests fail for me at rev 3116. Also, the checkin message is simple (1), which isn't very helpful. Edward Most likely due to my error, my unitTest.leo differed from the trunk; I've just pushed the version that generates the three expected failures. - Stephen -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: rename failed: no file created!
On Jun 14, 2:09 pm, Ivanov Dmitriy usr...@gmail.com wrote: This does seem like a permssions problem: Leo creates the tangle candidate in the same directory as the intended result, then renames within that directory if it needs to update (or create) the file. Checking the permissions was my first step. I even moved leo file to another folder, in which I can manually create files - the same error. So, it's not caused by permissions. Maybe, python? Dmitriy Windows file rename may be different than file create. Try creating file foo, then at the command line doing rename foo bar. - Stephen -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: Multiple parts not allowed for secref
On Jun 2, 4:36 am, thyrsus sschae...@acm.org wrote: Huh? There's a fair amount of logic in the @root tangle code to allow or disallow multiple parts to a section definition. It makes sense that when encountering a section reference (i.e., a point at which a section is to be interpolated) that you shouldn't at that point be in the midst of defining the contents of that section, lest interpolation of the section include itself ad infinitum. If that's the point, the error message could be much clearer. But I don't believe that's what's happening. My test @root node, which is failing with this error, is supplied at the end of this message; please help me understand why it is supposed to be invalid. Thanks, - Stephen ?xml version=1.0 encoding=utf-8? ?xml-stylesheet ekr_test? leo_file leo_header file_format=2/ vnodes v t=sps.20100602001344.9941 a=Evh#...@root/vh v t=sps.20100602001344.9942vhsecref gt;gt;= definition/vh/ v v t=sps.20100602001344.9943vhlt;lt; secref gt;gt;/vh/v /v /vnodes tnodes t tx=sps.20100602001344.9941A comment to ignore @root-code 'root-test' # A simple test of @root-code. lt;lt; secref gt;gt; @ ignored documentation /t t tx=sps.20100602001344.9942 lt;lt; secref gt;gt;= abc/t t tx=sps.20100602001344.9943ignored comment @c xyz /t /tnodes /leo_file Concerning Multiple parts not allowed: Having contemplated the code carefully, I now think I can summarize in English what is happening, speculate about what was supposed to happen, and propose what, to me, is a less surprising behavior. What the code does: --- If a headline contains section foo any code part in this node body must be the first encountered code part for section foo multiple @c parts and section foo = parts may occur in the same node body in subsequently encountered node bodies, section foo = parts may extend the definition of section foo the first encountered code part rule means no two nodes may both have headline section foo If a headline does not contain section foo the node body may contain section foo = to add code parts to section foo In any node, section foo = may add code parts for section foo, regardless of how the first part of section foo was defined. What I believe the code intended: - The body of a section using a headline section foo be the one and only place that code parts for the definition of section foo, and that one and only one of the section foo headline + @c body or section foo = body mechanisms be used to define sections. The behavior I would find less surprising: -- section foo headline + @c body add parts to the definition of section foo in the same way that body section foo = adds to the body of section foo. === Am I missing something? I've got unit tests that seem to confirm my interpretation of the present code's behavior. Is there historical justification in CWEB or noweb for the current behavior? For what I am guessing is the intended behavior? Is there an argument that the current behavior or what I speculate is the intended behavior is somehow more elegant or flexible? What downside would there be to changing the code to behave in the manner I find less surprising? -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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.
@root changes
I've just pushed some code concerning @root to the trunk. I just had a well, of course moment: Launchpad can send an e-mail when the trunk gets updated. Click on the Code tag; click on lp:leo-editor; then on the right hand side of the page click on subscribe. - Stephen -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: I'm back
On Jun 8, 5:06 pm, Edward K. Ream edream...@gmail.com wrote: Mother died last Friday from bone cancer at the age of 86. She had been diagnosed only 10 days previously with stage IV cancer, so treatment was out of the question. Our extended family came together to keep vigil. It was a good, if not enjoyable experience. Mother lead a full life, and had many ardent admirers. She was active until the last three weeks of life, and had all her faculties until the last three days. So there is little to regret in her life, and I feel strangely calm about this whole process. Perhaps true grief will strike later unexpectedly, but I think not. I do feel a bit altered. I may do a bit more writing on my personal blog athttp://edreamleo.blogspot.com/ but I want to make sure those personal musings don't get syndicated on Planet Python first. I'll ease back into programming soon. There is plenty to do... Edward My deep gratitude for your gift of Leo naturally extends to a particular wish for your well being and for that of those whom you hold dear. Your loss is in my thoughts. Perhaps these words from Amon Liner's Variations CLXXXIII have some bearing: what is a saint? the palpable man who touches the living death of others beyond the rumble of the stone wagon that hauled his shadow away, who kisses their death and makes it well, whose hand displays the water and the light in its mineral season. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: @root unit testing
I fixed the problem: untangle tests are now comparing to the in- memory generated files. No surprise to anyone doing unit tests: almost all of the untangle tests now fail. The one that works is where an @language c directive causes comments to be dealt with correctly. Both unspecified language and html are failing. - Stephen On Jun 8, 12:03 am, thyrsus sschae...@acm.org wrote: It turns out that c.scanAtPathDirectives ignores path components that do not correspond to existing directories unless the setting createnonexistentdirectories is set True. I could pollute the code with more if unitTesting: clauses, but I've instead created the directory foo as a sibling to unitTest.leo for the purposes of relative path testing, and my unit tests rely on the existence of the directory /tmp for absolute @path testing. That should be easily satisfied for Unix and Mac folks; I invite a windows developer to generalize the tests to the windows environment. I'm pushing these tests to the trunk, but there's an unresolved problem: the test of untangle doesn't know that it's supposed to read from the in-memory dictionary of c.tangleCommands.tangle_output strings instead of real files, so it complains about non-existent files and doesn't change the tree. Since the tree isn't *supposed* to change (with the current tests, at least), the tests pass. In other words: work in progress. - Stephen On Jun 5, 6:30 pm, thyrsus sschae...@acm.org wrote: Thinking out loud; please comment. In unit testing tangle, I ignored @path directives. The live code uses @path directives plus other elements of the environment (such as the directory containing the .leo file) and the argument to @root to to generate an absolute path to the derived file. Thought this code is mostly shared with other @file directives, that testing is rather light and could use some more exploration of corner cases. I can't simply put the absolute path name in a result node header because different developers will locate the unitTest.leo file in different places. There are two general cases to test: (a) paths relative to the unitTest.leo file and (b) absolute path names. In case (a), I can put the file path relative to the unitTest.leo directory in the result node header and test against the derived full file path as derived by the code by removing the unitTest.leo directory prefix from the file name and testing for equality. Tests for (b) can put the fully specified path in the result node header, and work regardless of the developer environment, because the file is not actually written, and the directories in the absolute path do not need to actually exist. Concerning untangle: the no-external-change case can be tested using the current test data, by adding untangle testing the to current runRootFileTest. The next step is to test incorporation of changes generated by untangle. There will be an @root tree node representing the before state, an @root tree node representing the after state, then sibling node pseudo-files (i.e., with header corresponding to the relative file name and body corresponding to the external file contents to be untangled). A test will (deep) copy the @ root before tree, untangle pseudo-files into that copy, then compare the copy to the �...@root after tree using the compareTree() routine. To restate, testing untangle will need: a before @root tree; a copy of the before tree into which we untangle; and an after @root tree, to which we compare the result of the untangle. In the no changes expected, the after tree can be the same as the before tree. In both cases, we can automatically generate the copy of the before tree into which we untangle. - Stephen On Jun 2, 4:50 am, thyrsus sschae...@acm.org wrote: I've just pushed 3108 to the trunk. Some @root unit tests now work due to fixes in leGlobals.py and leoTangle.py; some still fail. Much more to do. I've included a (failing) unit test with a fanciful interpretation of what multiple @comment directives should do in a single node. I'd like to hear opinions on the subject. I'm going to tackle testing untangle tomorrow if I can crib the time. - Stephen On Jun 1, 6:42 pm, thyrsus sschae...@acm.org wrote: I've just pushed changes to the @root testing, removing @root from the responsibility of runAtFileTest and moving it to a new function runRootFileTest. The new routine can handle tests of multiple @root file output. Changes to portions of the tangle code used only during unit testing store the different file results in a dict keyed by (non-path affected) file name. Still to do: modify it to test untangle and fix all the other failing @root tests. - Stephen On May 31, 5:58 pm, thyrsus sschae...@acm.org wrote: I've just pushed unit tests for some of @root functionality. Most of them
Re: leoRst.py mod for Sphinx (sort of)
Thank you. I've included this code in the trunk.
- Stephen
On Jun 7, 8:51 pm, yarko yark...@gmail.com wrote:
I had been using Leo (and enjoying it) for keeping a Sphinx document
up-to-date and congruent with development.
However, I wanted to keep closer to the Sphinx way of naming and
building (and locating files), so that it would be easier to keep up
with new versions of sphinx (or templates), as well as to import
existing projects.
The changes I wanted were really only 2:
- name the rst source file *.rst;
- not have output format (i.e. html) tied to any part of the source
filenames;
For the first, I added a configuration option for file name extension,
consistent with current option naming for intermediate files.
The default is '.txt', as is the current use in Leo documentation
files. To make it '.rst' (or anything else), projects only need to
add an rst3 option:
@string rst3_write_intermediate_extension = .rst
Maybe someone else will also find this handy.
- Yarko
=== modified file 'leo/core/leoRst.py'
--- leo/core/leoRst.py 2010-05-26 14:19:45 +
+++ leo/core/leoRst.py 2010-06-07 21:59:27 +
@@ -288,6 +288,7 @@
'rst3_underline_characters': '''#=+*^~'`-:_''',
'rst3_verbose':True,
'rst3_write_intermediate_file': False, # Used only if
generate_rst is True.
+ 'rst3_write_intermediate_extension': '.txt',
# Mode options...
'rst3_code_mode': False, # True: generate rst markup from
@code and @doc parts.
'rst3_doc_only_mode': False, # True: generate only from
@doc parts.
@@ -850,7 +851,9 @@
return False
if self.getOption('write_intermediate_file'):
- name = self.outputFileName + '.txt'
+ # name = self.outputFileName + '.txt'
+ ext = self.getOption('write_intermediate_extension')
+ name = self.outputFileName.rsplit('.',1)[0] + ext
if g.isPython3: # 2010/04/21
f = open(name,'w',encoding=self.encoding)
else:
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email to leo-edi...@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: @root argument vs. @path argument
I like this a lot. I speculate that odd file names come from folks using GUIs who aren't aware of what the conventions are in a shell - I remember an AppleShare to NFS appliance I dealt with that had to do magic for the Mac folks who liked to name their files - report of 3/2/1990 - . Once it embedded a null within the file name. Shudder. I am reluctant, however, to innovate with @root, and leave @path and @file (i.e., every external file directive other than @root) doing something different. Does anyone use @path file name with surrounding angle brackets and outside spaces stripped (but no other characters)? Google probably wrapped that, and an opening or ' without the corresponding close character before the newline throws an error, but I think you understand what I meant. Newline and carriage return are a valid characters in a Unix file name, but are reserved to sadomasochists ;-). - Stephen On Jun 8, 10:01 am, Terry Brown terry_n_br...@yahoo.com wrote: On Mon, 7 Jun 2010 17:59:26 -0700 (PDT) thyrsus sschae...@acm.org wrote: In @root arguments (which become the last component of the file name), the tangle.setRootFromText() method iremoves surrounding character pairs and , but not '', then removes any leading and trailing whitespace. In @path arguments, the the g.stripPathCruft() method removes character pairs , , and '', then removes any leading and trailing whitespace. I urge that the behavior be made consistent. Which way should it go? Since @root is much less used than @path, there's a strong argument for using the @path convention. Were I designing things from the beginning, I'd give a function to the quoting characters pairs that they suppress the leading and trailing whitespace removal - if you want whitespace removal from around the file name, don't quote it! Am I understanding, that would allow you to create (or load, I guess), files with leading or trailing spaces in their names? Hmm, on the one hand, why would you ever want to do that, on the other, we'd want Leo to be able to edit files with any valid filename, even a really odd one. Seems to me the simplest thing (sort of starting from scratch) would be to allow either a naked filename (leading/trailing whitespace stripped), or a subset of python string representations, i.e. if, after the initial whitespace stripping, first and last character are ' or '', one level of such characters would be stripped, and the result used, regardless of further leading or trailing whitespace, and regardless of further characters from the set [']. Cheers -Terry -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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.
@root argument vs. @path argument
In @root arguments (which become the last component of the file name), the tangle.setRootFromText() method iremoves surrounding character pairs and , but not '', then removes any leading and trailing whitespace. In @path arguments, the the g.stripPathCruft() method removes character pairs , , and '', then removes any leading and trailing whitespace. I urge that the behavior be made consistent. Which way should it go? Since @root is much less used than @path, there's a strong argument for using the @path convention. Were I designing things from the beginning, I'd give a function to the quoting characters pairs that they suppress the leading and trailing whitespace removal - if you want whitespace removal from around the file name, don't quote it! (These quotes currently don't prevent or prescribe any other interpolation, e.g., by os.expanduser.) I'd very much like to hear your opinion, but if I don't hear anything in three or four days, I'll feel free commit to the trunk whatever strikes me as best at that time ;-) -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: @root unit testing
It turns out that c.scanAtPathDirectives ignores path components that do not correspond to existing directories unless the setting createnonexistentdirectories is set True. I could pollute the code with more if unitTesting: clauses, but I've instead created the directory foo as a sibling to unitTest.leo for the purposes of relative path testing, and my unit tests rely on the existence of the directory /tmp for absolute @path testing. That should be easily satisfied for Unix and Mac folks; I invite a windows developer to generalize the tests to the windows environment. I'm pushing these tests to the trunk, but there's an unresolved problem: the test of untangle doesn't know that it's supposed to read from the in-memory dictionary of c.tangleCommands.tangle_output strings instead of real files, so it complains about non-existent files and doesn't change the tree. Since the tree isn't *supposed* to change (with the current tests, at least), the tests pass. In other words: work in progress. - Stephen On Jun 5, 6:30 pm, thyrsus sschae...@acm.org wrote: Thinking out loud; please comment. In unit testing tangle, I ignored @path directives. The live code uses @path directives plus other elements of the environment (such as the directory containing the .leo file) and the argument to @root to to generate an absolute path to the derived file. Thought this code is mostly shared with other @file directives, that testing is rather light and could use some more exploration of corner cases. I can't simply put the absolute path name in a result node header because different developers will locate the unitTest.leo file in different places. There are two general cases to test: (a) paths relative to the unitTest.leo file and (b) absolute path names. In case (a), I can put the file path relative to the unitTest.leo directory in the result node header and test against the derived full file path as derived by the code by removing the unitTest.leo directory prefix from the file name and testing for equality. Tests for (b) can put the fully specified path in the result node header, and work regardless of the developer environment, because the file is not actually written, and the directories in the absolute path do not need to actually exist. Concerning untangle: the no-external-change case can be tested using the current test data, by adding untangle testing the to current runRootFileTest. The next step is to test incorporation of changes generated by untangle. There will be an @root tree node representing the before state, an @root tree node representing the after state, then sibling node pseudo-files (i.e., with header corresponding to the relative file name and body corresponding to the external file contents to be untangled). A test will (deep) copy the @ root before tree, untangle pseudo-files into that copy, then compare the copy to the �...@root after tree using the compareTree() routine. To restate, testing untangle will need: a before @root tree; a copy of the before tree into which we untangle; and an after @root tree, to which we compare the result of the untangle. In the no changes expected, the after tree can be the same as the before tree. In both cases, we can automatically generate the copy of the before tree into which we untangle. - Stephen On Jun 2, 4:50 am, thyrsus sschae...@acm.org wrote: I've just pushed 3108 to the trunk. Some @root unit tests now work due to fixes in leGlobals.py and leoTangle.py; some still fail. Much more to do. I've included a (failing) unit test with a fanciful interpretation of what multiple @comment directives should do in a single node. I'd like to hear opinions on the subject. I'm going to tackle testing untangle tomorrow if I can crib the time. - Stephen On Jun 1, 6:42 pm, thyrsus sschae...@acm.org wrote: I've just pushed changes to the @root testing, removing @root from the responsibility of runAtFileTest and moving it to a new function runRootFileTest. The new routine can handle tests of multiple @root file output. Changes to portions of the tangle code used only during unit testing store the different file results in a dict keyed by (non-path affected) file name. Still to do: modify it to test untangle and fix all the other failing @root tests. - Stephen On May 31, 5:58 pm, thyrsus sschae...@acm.org wrote: I've just pushed unit tests for some of @root functionality. Most of them fail. It's not yet clear whether that has more to do with the test scaffolding or actual @root failures; probably both. Multiple @root directives in a body are currently untestable, in that the test scaffolding uses a hack to tangle into a single string, bypassing file generation. Multiple @root directives will require something like tangling into a dictionary, keyed by the file names - or perhaps we can drop the hack and tangle
Re: @root unit testing
Thinking out loud; please comment. In unit testing tangle, I ignored @path directives. The live code uses @path directives plus other elements of the environment (such as the directory containing the .leo file) and the argument to @root to to generate an absolute path to the derived file. Thought this code is mostly shared with other @file directives, that testing is rather light and could use some more exploration of corner cases. I can't simply put the absolute path name in a result node header because different developers will locate the unitTest.leo file in different places. There are two general cases to test: (a) paths relative to the unitTest.leo file and (b) absolute path names. In case (a), I can put the file path relative to the unitTest.leo directory in the result node header and test against the derived full file path as derived by the code by removing the unitTest.leo directory prefix from the file name and testing for equality. Tests for (b) can put the fully specified path in the result node header, and work regardless of the developer environment, because the file is not actually written, and the directories in the absolute path do not need to actually exist. Concerning untangle: the no-external-change case can be tested using the current test data, by adding untangle testing the to current runRootFileTest. The next step is to test incorporation of changes generated by untangle. There will be an @root tree node representing the before state, an @root tree node representing the after state, then sibling node pseudo-files (i.e., with header corresponding to the relative file name and body corresponding to the external file contents to be untangled). A test will (deep) copy the @ root before tree, untangle pseudo-files into that copy, then compare the copy to the @root after tree using the compareTree() routine. To restate, testing untangle will need: a before @root tree; a copy of the before tree into which we untangle; and an after @root tree, to which we compare the result of the untangle. In the no changes expected, the after tree can be the same as the before tree. In both cases, we can automatically generate the copy of the before tree into which we untangle. - Stephen On Jun 2, 4:50 am, thyrsus sschae...@acm.org wrote: I've just pushed 3108 to the trunk. Some @root unit tests now work due to fixes in leGlobals.py and leoTangle.py; some still fail. Much more to do. I've included a (failing) unit test with a fanciful interpretation of what multiple @comment directives should do in a single node. I'd like to hear opinions on the subject. I'm going to tackle testing untangle tomorrow if I can crib the time. - Stephen On Jun 1, 6:42 pm, thyrsus sschae...@acm.org wrote: I've just pushed changes to the @root testing, removing @root from the responsibility of runAtFileTest and moving it to a new function runRootFileTest. The new routine can handle tests of multiple @root file output. Changes to portions of the tangle code used only during unit testing store the different file results in a dict keyed by (non-path affected) file name. Still to do: modify it to test untangle and fix all the other failing @root tests. - Stephen On May 31, 5:58 pm, thyrsus sschae...@acm.org wrote: I've just pushed unit tests for some of @root functionality. Most of them fail. It's not yet clear whether that has more to do with the test scaffolding or actual @root failures; probably both. Multiple @root directives in a body are currently untestable, in that the test scaffolding uses a hack to tangle into a single string, bypassing file generation. Multiple @root directives will require something like tangling into a dictionary, keyed by the file names - or perhaps we can drop the hack and tangle into actual files, then use file comparisons (against @asis output?). Untangling is completely untested. Since every tangle should have a successful corresponding untangle, I'm leaning toward modifying runAtFileTest to test using the same input tree/output data. The work on allowing @root in headlines appears to be well on its way, if not finished. �...@root in the body remains supported (I'm relieved). runAtFileTest appears not to support testing of @root in the headline; I'll see what I can do about that. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: Leo 4.7.1 final lost Read @shadow Node?
On Jun 3, 7:15 am, Zoom.Quiet zoom.qu...@gmail.com wrote: On Thu, Jun 3, 2010 at 18:37, zpcspm zpc...@gmail.com wrote: I just do Import to @file, then change @file to @shadow and restart leo. restart Leo is tooo hard... many time,just for SVN/CVS/Hg ... auto upgrade some version info. such as: #__author__ = $Author: tangjianwei $ #__date__ = $Date: 2010-04-02 12:50:56 +0800 (五, 2010-04-02) $ #__revision__= $Rev: 15742 $ #__url__ = $URL:http://svn.rdev.kingsoft.net/matter/trunk/sa.defines/hosts$; Not sure this is the best way, but it seems to work. The Read @file Nodes works to incorporate external changes in the select tree, though it does generate an incorrect message: no @file nodes in the selected tree. ...which is either harmless or an indication that there is a Leo bug that needs to be fixed (something not recognizing @shadow as an @file, or the @shadow logic attempting to do more than it needs to). Other than that message, the result is correct. - Stephen -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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.
Multiple parts not allowed for secref
Huh? There's a fair amount of logic in the @root tangle code to allow or disallow multiple parts to a section definition. It makes sense that when encountering a section reference (i.e., a point at which a section is to be interpolated) that you shouldn't at that point be in the midst of defining the contents of that section, lest interpolation of the section include itself ad infinitum. If that's the point, the error message could be much clearer. But I don't believe that's what's happening. My test @root node, which is failing with this error, is supplied at the end of this message; please help me understand why it is supposed to be invalid. Thanks, - Stephen ?xml version=1.0 encoding=utf-8? ?xml-stylesheet ekr_test? leo_file leo_header file_format=2/ vnodes v t=sps.20100602001344.9941 a=Evh#...@root/vh v t=sps.20100602001344.9942vhsecref gt;gt;= definition/vh/ v v t=sps.20100602001344.9943vhlt;lt; secref gt;gt;/vh/v /v /vnodes tnodes t tx=sps.20100602001344.9941A comment to ignore @root-code 'root-test' # A simple test of @root-code. lt;lt; secref gt;gt; @ ignored documentation /t t tx=sps.20100602001344.9942 lt;lt; secref gt;gt;= abc/t t tx=sps.20100602001344.9943ignored comment @c xyz /t /tnodes /leo_file -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: @root unit testing
I've just pushed 3108 to the trunk. Some @root unit tests now work due to fixes in leGlobals.py and leoTangle.py; some still fail. Much more to do. I've included a (failing) unit test with a fanciful interpretation of what multiple @comment directives should do in a single node. I'd like to hear opinions on the subject. I'm going to tackle testing untangle tomorrow if I can crib the time. - Stephen On Jun 1, 6:42 pm, thyrsus sschae...@acm.org wrote: I've just pushed changes to the @root testing, removing @root from the responsibility of runAtFileTest and moving it to a new function runRootFileTest. The new routine can handle tests of multiple @root file output. Changes to portions of the tangle code used only during unit testing store the different file results in a dict keyed by (non-path affected) file name. Still to do: modify it to test untangle and fix all the other failing @root tests. - Stephen On May 31, 5:58 pm, thyrsus sschae...@acm.org wrote: I've just pushed unit tests for some of @root functionality. Most of them fail. It's not yet clear whether that has more to do with the test scaffolding or actual @root failures; probably both. Multiple @root directives in a body are currently untestable, in that the test scaffolding uses a hack to tangle into a single string, bypassing file generation. Multiple @root directives will require something like tangling into a dictionary, keyed by the file names - or perhaps we can drop the hack and tangle into actual files, then use file comparisons (against @asis output?). Untangling is completely untested. Since every tangle should have a successful corresponding untangle, I'm leaning toward modifying runAtFileTest to test using the same input tree/output data. The work on allowing @root in headlines appears to be well on its way, if not finished. �...@root in the body remains supported (I'm relieved). runAtFileTest appears not to support testing of @root in the headline; I'll see what I can do about that. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: @root unit testing
I've just pushed changes to the @root testing, removing @root from the responsibility of runAtFileTest and moving it to a new function runRootFileTest. The new routine can handle tests of multiple @root file output. Changes to portions of the tangle code used only during unit testing store the different file results in a dict keyed by (non-path affected) file name. Still to do: modify it to test untangle and fix all the other failing @root tests. - Stephen On May 31, 5:58 pm, thyrsus sschae...@acm.org wrote: I've just pushed unit tests for some of @root functionality. Most of them fail. It's not yet clear whether that has more to do with the test scaffolding or actual @root failures; probably both. Multiple @root directives in a body are currently untestable, in that the test scaffolding uses a hack to tangle into a single string, bypassing file generation. Multiple @root directives will require something like tangling into a dictionary, keyed by the file names - or perhaps we can drop the hack and tangle into actual files, then use file comparisons (against @asis output?). Untangling is completely untested. Since every tangle should have a successful corresponding untangle, I'm leaning toward modifying runAtFileTest to test using the same input tree/output data. The work on allowing @root in headlines appears to be well on its way, if not finished. �...@root in the body remains supported (I'm relieved). runAtFileTest appears not to support testing of @root in the headline; I'll see what I can do about that. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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.
@root unit testing
I've just pushed unit tests for some of @root functionality. Most of them fail. It's not yet clear whether that has more to do with the test scaffolding or actual @root failures; probably both. Multiple @root directives in a body are currently untestable, in that the test scaffolding uses a hack to tangle into a single string, bypassing file generation. Multiple @root directives will require something like tangling into a dictionary, keyed by the file names - or perhaps we can drop the hack and tangle into actual files, then use file comparisons (against @asis output?). Untangling is completely untested. Since every tangle should have a successful corresponding untangle, I'm leaning toward modifying runAtFileTest to test using the same input tree/output data. The work on allowing @root in headlines appears to be well on its way, if not finished. @root in the body remains supported (I'm relieved). runAtFileTest appears not to support testing of @root in the headline; I'll see what I can do about that. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: @root (at heading) vs. @nosent - real differences?
I'm not sure why you choose to compare @root with @nosent; the default for @root is to *have* sentinels. And for now, @root remains in the body of the node. There are major differences: * @root allows one to specify multiple files in one node (or tree of nodes). Consider the outline: +[root test] | @root /home/sps/ttt6 | ttt6 main | @root /home/sps/ttt7 | ttt7 main +---[ttt6 main] | ttt6 main= | this is the contents of ttt6 main +---[ttt7 main and more] ttt7 main= this is the contents of ttt7 main ttt6 main this is more contents of ttt6 main Using that facility, I could specify the CSS to use with a specific element ID, and in the same node (or tree of nodes) specify the javascript invoked for that element, and have them live in separate files. (This is one of the reasons that I'm interested in getting the @delims/@comments/@language directives working properly with @root). * @root uses an explicit tangle That means you can save your unfinished Leo file without unnerving orphan node complaints, then later deal with them when you want to deal with them. * @root uses an explicit untangle. If, because of collaboration or some other reason, your external files are changing, you can incorporate the changes when you're ready to incorporate the changes, not choosing between automatically when you open the Leo file, or not at all. Things happen when you're ready for them to happen, not when Leo assumes that they need to happen. - Stephen On May 29, 7:10 am, Ville M. Vainio vivai...@gmail.com wrote: I may be a bit out of the loop with this, but anyway - So far, I've considered @root to be a sort of complicated legacy. OTOH, I like @nosent for text generation. Now that @root is being moved to heading, is there a fundamental difference between @root and @nosent? I know other supports some of the things that other doesn't, but is there a reason to keep it so? Could the two be unified, so that @nosent supported everything @root does? -- Ville M. Vainiohttp://tinyurl.com/vainio -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: using clones in external files, safely
One conceptual clarification: all clones are identical; none are distinguished as the original. When a clone is modified by external files, the last read version of the clone wins. With recent versions (e.g. 4.7.1) of Leo, if the same node is contained in multiple @thin external files, then the last file read wins, but Leo will create a node labeled Recovered nodes which contains the multiple versions of each conflicting specification of the clone. Suggestion: the @thin nodes *not* be clones, but that everything of significance within them be a node incorporated into them that is cloned. Further, you could prevent changes from outside your workspace (e.g., deletions) by using @nosent. E.g., [Workspace] [...@path D:\Code] [...@thin script.bat] Content: @language batc...@others\n [clone of script contents] [Local Utils] [...@path C:\utils] [...@nosent script.bat] Content: @language batc...@others\n [clone of script contents] [Shared Utils] [...@path X:\utils] [...@nosent script.bat] Content: @language batc...@others\n [clone of script contents] This may have the benefit of making your shared scripts cleaner: sentinels are usually a fairly clumsy way to provide human readable comments; those should generally be a normal part of the script body text. On the other hand, if you *DO* intend to incorporate changes from the multiple external files, then be sure to use @thin, and resolve the conflicts noted by the Recovered nodes entry. Unless you must collaborate, I would avoid that. - Stephen On May 27, 4:16 pm, Matt Wilkie map...@gmail.com wrote: Hello all, I'm trying to use Leo to manage the same external file in multiple locations: e.g. single Leo source node, duplicate external files. What I want to do is have my editing files on the local machine which is checked into subversion. The scripts which have passed muster and are actually useful are then duplicated to a directory in PATH on my local machine, and to a network location so they can be used by others. This is the structure: [Workspace] �...@path D:\Code] �...@thin script.bat] [Local Utils] �...@path C:\utils] [clone of [...@thin script.bat]] [Shared Utils] �...@path X:\utils] [clone of [...@thin script.bat]] This appears to work well enough, but there is a dangerous gotcha: if [Shared Utils] appears first in the hierarchy and someone deletes X:\utils\script.bat all the clones become empty nodes. Furthermore, if the workbook is saved at this point the clones-with-data are overwritten. Thankfully there is at least an overwrite existing file? prompt so there is a chance to avoid disaster if I'm paying attention and not impatient, at the end of a long day for example. So my question is: is there a safer way to accommodate this workflow? -- -matt -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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.
Fedora 12 can now build .rpm
I've just pushed onto the trunk changes which allow Fedora 12 to build
a .rpm. Those changes were:
* in setup.py, change the version number from 4.6 to 4.7.1
* comment out the contents of leo/plugins/LeoN.py; that code is of
historic interest, but is unmaintained and hasn't worked in a long
time
* change to leo/plugins/ConceptualSort.py which allows it to byte
compile with the Fedora 12 python2.6:
--- leo/plugins/ConceptualSort.py 2010-01-28 15:10:20 +
+++ leo/plugins/ConceptualSort.py 2010-05-13 15:43:46 +
@@ -208,7 +208,7 @@
def lcsort2( a, b, atts =atts ):
z = {}
# exec usort in {}, z
-exec(usort,{},z)
+eval(usort,{},z)
rv = z[ 'user_sort' ]( a, b, atts )
return rv
self.children.sort( lcsort2 )
All Alt-4 unit tests succeed, but I don't believe those two plugins
are covered by unit tests.
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email to leo-edi...@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.
Guildelines for modifying trunk
I'm contemplating an attempt to clean up @root. Edward proposed moving the directive from the body to the headline, but that isn't on the trunk yet, and I don't know if the proposal still stands. I'm going to begin work assuming that the @root behavior will not change. I expect that I'll start by adding unit tests. Why even bother? What's @root good for, anyway? My vision of the use of @root is for those times when you want to structure your code according to function, and those functions are necessarily spread among multiple files. Even a modest project may involve * a database schema * SQL * database stored procedures * web server extension code * web server configuration * HTML * CSS * Javascript * Makefiles and we can expect a conceptual unit to affect multiple components. With @unit, @root and section=, a single node can present all the code relevant to the concept. Back to the original Subject: The guidelines I'm sure about for adding to the trunk are: Code added to the trunk should pass unit tests. An announcement should appear in the leo-editor Google group. I'm guessing at the following: I expect adding working unit tests to the trunk to be uncontroversial. Non-working unit tests go under an @ignore. Documentation should be able to create HTML. I'd like to add: Documentation should be able to create a PDF. There doesn't seem to be a standard for review, so long as unit tests pass; does anyone want to be more cautious? -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: Using and Section Headlines
In the @file family of derived files (@thin, @nosent, etc.) (i.e., not @root), you can prevent any interpretation of the immediately following line with the @verbatim directive, for example @verbatim @others will not be interpreted, neither will not a section name If you have a bunch of such stuff (e.g., C code doing a lot of bit shifts) you can do @raw this will; /* not be interpreted by Leo */ nor will; /* this be interpreted by Leo */ @end_raw this section *will* be interpolated I believe those escape directives *do not* function in @root interpretations, but I'm not sure. - Stephen On May 17, 12:11 pm, mdb mdbol...@gmail.com wrote: Related question: --How does the leo documentation create html pages with ' headline' preserved from a leo outline without producing a write file error of: undefined section: headline -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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.
Renaming @shadow files
I'll be adding this to the manual, but I thought I'd share here first. I'm studying the code of an active project using @shadow. A recent git pull changed the names of some of the files I'd outlined. To recover the outlining work I'd done for, e.g., main.rb renamed to apply.rb, I - went to the .leo_shadow directory and copied xmain.rb to xapply.rb - opened the leo file, observing many complaints about failure to update @shadow nodes - created an empty @shadow apply.rb node - ran read-at-shadow-nodes (success!) - removed the old @shadow main.rb (in case some future file named main.rb appears) - removed the old .leo_shadow/xmain.rb file I hope that if the @shadow mechanism gets revised in the future that this capability won't be somehow eliminated. I may attempt to create a Leo function rename-at-shadow-node that automates the process, but I anticipate lots of complications to making such a function robust (e.g., properly interpreting relevant @path directives. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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.
Plans for @root
I just finished reviewing Chapter 5, and some of its text, if not
downright wrong, is at best confusing, because it was written assuming
use of @root, and then perhaps modified to be less wrong - sometimes.
Before I launch on a significant rewrite, I'd like to know the plans
and timeframe for the revision to @root behavior.
Is it a matter only of @root becoming valid only in headers and not in
the body? E.g., are there any changes to body section definitions,
e.g.,
+ headline
@c
commentary
@
section extension=
more lines
added to section extension
? I.e., what's the full spec for the new behavior?
What's more likely to happen first:
(a) I rewrite the chapter to assume @file behavior (approx. two
weeks).
(b) Edward renews interest in changing @root (? days) and fixes it (2
days?)
(c) I get a spec for the new behavior of @root (? days) and attempt to
implement it myself (20 days?) then rewrite chapter 5 (one week; less
to change because I can leave in @root).
Reasons you'll have to wait longer for me than you might otherwise
expect: 1. Edward is more familiar with the code. 2 I've got
concurrent projects. 3. My strongest languages are perl, /bin/sh, C
and only then {python,ruby,lisp,objective-C,C++,erlang,...} 4.
Edward's probably smarter than I am ;-)
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email to leo-edi...@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: Revised Chapter 4: Writing Programs with Leo
Quite a few errors, mostly cosmetic, repaired. I've omitted the menu File:Read/Write discussion until I can list specifically those external file generating for which it operates as expected (and may be supplemented with discussion of the differences). - Stephen On May 11, 9:56 am, Edward K. Ream edream...@gmail.com wrote: On Mon, May 10, 2010 at 12:01 AM, thyrsus sschae...@acm.org wrote: I've just pushed leo-manualUpdate with extensive revisions to Chapter 4: Writing Programs with Leo. Many thanks for this work. It is greatly appreciated. I'll review it soon. 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-edi...@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/leo-editor?hl=en. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: Proposed change to tangle: require @root in headline
I think I'll devise a way to make the @root sections of Chapter 4 turn invisible until the code settles. When the code and the comments disagree, both are probably wrong. - The Elements of Programming Style. - Stephen On May 8, 8:54 am, Edward K. Ream edream...@gmail.com wrote: On Fri, May 7, 2010 at 6:20 PM, thyrsus sschae...@acm.org wrote: There appear to be a number of uses of @root in leoPluginsRef.leo; from my brief review, they all appear in the body. Will they all be simple to move to headlines? I assume so. The unit tests may have to change also. 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-edi...@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/leo-editor?hl=en. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: The right kind of magic
I've had good luck with @shadow; I tell the version control system to ignore .leo_shadow directories and the .leo file, and the rest of the project participants are none the wiser. I imagine there are cases where this wouldn't work, but it hasn't yet been an insurmountable nuisance. - Stephen On May 8, 4:58 pm, Edward K. Ream edream...@gmail.com wrote: In this thread I'm going to do some blue-sky thinking. Ville's remark about plugins having a shorter life than stand-alone apps like Leo might be said to cast a pall over this entire discussion, but what the heck: I've had some new ideas today that I'd like to share. Besides, if the plugins I am about to discuss were nifty enough perhaps they might become official parts of their respective editors. We can dream, at least. This afternoon I started wondering whether Leo's sentinel problems might possibly have some as-yet-undreamed-of solution. In frustration I fell back on the last resort: magic. I asked myself whether any kind of magic might come to mind that could make sentinels unnecessary. The short answer is no :-) We could imagine some faux-cute hacks that might render sentinels unnecessary for programs, but the idea collapses as soon as one considers that Leo outlines can contain any kind of data. Really and truly, sentinels are essential. The thought then came to mind that the real problem with sentinels is that they are visible. So can we imagine another kind of magic, say a vim plugin that hides Leo sentinels from those that don't want anything to do with Leo. This plugin would have two modes. In Leonine mode it would present thin external files as outlines. (The plugin might even show .leo files). In plain mode it would show thin external files as flat files. Here are the new thoughts: 1. It would be relatively simple to prototype (in Leo itself) code that would hide sentinels from the user but would *maintain* those sentinels (in the hidden background) so that they would be written when the user saves the file. The general principles for this approach are: A. The plugin would never insert or change sentinels and, B. The plugin would delete sentinels only in matching pairs. Given these principles, the task of updating and deleting sentinels as the user inserts and deletes characters is relatively straightforward. I'll omit the details because the question of whether such a plugin ultimately makes sense is still unanswered. 2. If we allow the possibility that an environment will contain (mostly hidden) sentinels, we will likely see a cascade of (benign?) side effects. For example, we would probably want a Leonine diff that would present differences to bzr/git/whatever that ignore (proper) diffs involving sentinels. If the algorithm in part 1 works properly, all diffs will indeed be proper: we will never delete just one of a pair of sentinels. Objections There are several possible objections to such a scheme: 1. Some people will object to Leo sentinels no matter how well hidden they are. Management could lesson dissent by requiring everybody to install the Leo plugin (and diff), giving each programmer the option of running the plugin in Leonine or plain mode. 2. As a practical matter, the changes to the overall tool chain might simply be too difficult for me to do or for others to install. Both objections seem real enough. In the final analysis, though, whether they are fatal depends on whether people really want the plugin. It's hard to know beforehand. Your comments please. 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-edi...@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/leo-editor?hl=en. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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.
Revised Chapter 4: Writing Programs with Leo
I've just pushed leo-manualUpdate with extensive revisions to Chapter 4: Writing Programs with Leo. I've tried to validate each claim in this chapter, and revised it to describe the current trunk. I've liberally changed wording so that I find it more understandable. I've eliminated nearly all mention of @root, with those sections hidden under @rst-ignore-tree or @rst- ignore-node headlines (and their quality is much worse than the unhidden parts). For those without the full Sphinx environment, and as a demo of what the fixup.pl script generates, I've included the file LeoDoc.pdf I'm sure there are errors remaining, nonetheless, I believe this to be an improvement - except now the errors are entirely my fault :-). -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: some docs errors (chap.4)
I need to stop making promises, and restrict myself to announcements. Work proceeds. - Stephen On May 6, 7:08 am, thyrsus sschae...@acm.org wrote: There are partial results in leo-manualUpdate, but there's a lot more to do. Look for more tomorrow morning. - Stephen On May 5, 11:51 am, thyrsus sschae...@acm.org wrote: I missed my promised deadline; I'll try again for tonight. - Stephen On May 4, 3:03 pm, Edward K. Ream edream...@gmail.com wrote: On Tue, May 4, 2010 at 12:15 PM, thyrsus sschae...@acm.org wrote: Thanks for this. I'm working on changes to chapter 4; I'll put them up for review in the leo-manualUpdate branch late tonight. Thanks. Rev 3075 of the trunk contains the last of my work today on the docs. Have at it. EKR -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/leo-editor?hl=en. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/leo-editor?hl=en. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/leo-editor?hl=en. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: Proposed change to tangle: require @root in headline
Ummm... I'm just now popping my head up after having massively rearranged Chapter 4 into Heading External File Directives and @root External File Directives, after observing that few directives operate in the same way in both contexts, with @root behavior being the exception in nearly every case. However, a rewrite of @root may be for the best. I'll come up with different wording if @root moves into the headline. n...@root External File Directives is probably not what I'm after, I'll have to muse over it some more. On May 7, 4:39 pm, Edward K. Ream edream...@gmail.com wrote: On May 7, 10:49 am, Edward K. Ream edream...@gmail.com wrote: I doubt if there is any way to clean up this mess without requiring that @root appear in one and only one place. Imo, this should be the headline. Your comments, please. Hearing no objections, I'll go ahead with the work tomorrow. 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-edi...@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/leo-editor?hl=en. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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.
Using both @comment and @delims?
Yes, perfectly horrible idea, and it's hard to know what madness would drive someone to attempt it, but I'm not sure it should simply be a matter of the manual saying DON'T DO THAT. In attempting to discover the behavior of the mixed directives so I could describe it, I managed to create an @thin file that Leo could write but not read: + @thin foo.html @language html @comment /* */ script @delims !-- -- @ stuff + script int Foo; All hail Eris! -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: Proposed change to tangle: require @root in headline
There appear to be a number of uses of @root in leoPluginsRef.leo; from my brief review, they all appear in the body. Will they all be simple to move to headlines? - Stephen On May 7, 4:39 pm, Edward K. Ream edream...@gmail.com wrote: On May 7, 10:49 am, Edward K. Ream edream...@gmail.com wrote: I doubt if there is any way to clean up this mess without requiring that @root appear in one and only one place. Imo, this should be the headline. Your comments, please. Hearing no objections, I'll go ahead with the work tomorrow. 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-edi...@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/leo-editor?hl=en. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: some docs errors (chap.4)
There are partial results in leo-manualUpdate, but there's a lot more to do. Look for more tomorrow morning. - Stephen On May 5, 11:51 am, thyrsus sschae...@acm.org wrote: I missed my promised deadline; I'll try again for tonight. - Stephen On May 4, 3:03 pm, Edward K. Ream edream...@gmail.com wrote: On Tue, May 4, 2010 at 12:15 PM, thyrsus sschae...@acm.org wrote: Thanks for this. I'm working on changes to chapter 4; I'll put them up for review in the leo-manualUpdate branch late tonight. Thanks. Rev 3075 of the trunk contains the last of my work today on the docs. Have at it. EKR -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/leo-editor?hl=en. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/leo-editor?hl=en. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: some docs errors (chap.4)
I missed my promised deadline; I'll try again for tonight. - Stephen On May 4, 3:03 pm, Edward K. Ream edream...@gmail.com wrote: On Tue, May 4, 2010 at 12:15 PM, thyrsus sschae...@acm.org wrote: Thanks for this. I'm working on changes to chapter 4; I'll put them up for review in the leo-manualUpdate branch late tonight. Thanks. Rev 3075 of the trunk contains the last of my work today on the docs. Have at it. EKR -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/leo-editor?hl=en. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: some docs errors (chap.4)
Thanks for this. I'm working on changes to chapter 4; I'll put them up for review in the leo-manualUpdate branch late tonight. - Stephen On May 4, 3:52 am, Matt Wilkie map...@gmail.com wrote: in pagehttp://webpages.charter.net/edreamleo/directives.html#overview-the-9-... under '@auto' the link to '@auto reference' should behttp://webpages.charter.net/edreamleo/directives.html#auto further down, under 'Overview: summary of directives' the definition for @file contains the nonsensical Thin external files contains simpler sentinels than @thin. Inhttp://webpages.charter.net/edreamleo/directives.html#asis-and-noref a missing space turns 'f...@asis' into a mailto: link. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/leo-editor?hl=en. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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.
@root directive in headline
From the User Guide, it would appear that the @root directive is supposed to operate in the both the body and headline of a node, but (a) it doesn't work for me and (b) it's not part of unit tests - indeed, the unit tests have what appear to be syntactically invalid @root directives in the headlines. Should I just clarify the User Guide to explicitly state that @root directives are honored *only* in the body of a node? -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: reStructuredText chapter heading adjustment?
For the moment, I'm using the button in Leo to generate the .pdf, but
then going back to the Leodocumentation.tex file to replace, e.g.,
\chapter{Front Matter}
with
\chapter*{FrontMatter}
and
\section{Acknowledgements}
with
\section*{Acknowledgements}
\addcontentsline{toc}{section}{Acknowledgements}
This is a modest manual process; I haven't been able to find any
support for this sort of thing in the Sphinx or other reST
documentation.
- Stephen
On Apr 27, 5:01 pm, thyrsus sschae...@acm.org wrote:
I'm obtaining the pdf for the Users's Guide, with this blemish: The
acknowledgements are decorated as Chapter 1, the Preface as Chapter
2, etc., with the severe dissonance arising when Chapter 1:
Installing Leo gets decorated as Chapter 5, and its subsections
decorated as 5.1, 5.2, and so on for the remainder of the
explicitly numbered chapters (i.e., the rest of the book). I tried
changing the title decorations to match the Python Part and Section
conventions, but that didn't help. Advice?
- Stephen
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email to leo-edi...@googlegroups.com.
To unsubscribe from this group, send email to
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/leo-editor?hl=en.
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email to leo-edi...@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: reStructuredText chapter heading adjustment?
I've memorialized the changes to the Leodocumentation.tex file in a
perl script, which I run manually; things look better, though I'm sure
there's more to be done (e.g., from the beginning to the first
chapter, the right hand footer is CONTENTS, even though it's
actually the FAQ or some other front matter section). The .tex file
edit is a wretched hack; I'd love to do it via standard
reStructuredText and Sphinx, but I haven't discovered how.
Do folks want me to post the generated .pdf somewhere? Where?
The perl script, together with some changes in content, are now in the
branch lp:~sschaefer/leo-editor/leo-manualUpdate which I proposed for
merge. Please review and commit.
- Stephen
On Apr 28, 3:58 am, thyrsus sschae...@acm.org wrote:
For the moment, I'm using the button in Leo to generate the .pdf, but
then going back to the Leodocumentation.tex file to replace, e.g.,
\chapter{Front Matter}
with
\chapter*{FrontMatter}
and
\section{Acknowledgements}
with
\section*{Acknowledgements}
\addcontentsline{toc}{section}{Acknowledgements}
This is a modest manual process; I haven't been able to find any
support for this sort of thing in the Sphinx or other reST
documentation.
- Stephen
On Apr 27, 5:01 pm, thyrsus sschae...@acm.org wrote:
I'm obtaining the pdf for the Users's Guide, with this blemish: The
acknowledgements are decorated as Chapter 1, the Preface as Chapter
2, etc., with the severe dissonance arising when Chapter 1:
Installing Leo gets decorated as Chapter 5, and its subsections
decorated as 5.1, 5.2, and so on for the remainder of the
explicitly numbered chapters (i.e., the rest of the book). I tried
changing the title decorations to match the Python Part and Section
conventions, but that didn't help. Advice?
- Stephen
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email to leo-edi...@googlegroups.com.
To unsubscribe from this group, send email to
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/leo-editor?hl=en.
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email to leo-edi...@googlegroups.com.
To unsubscribe from this group, send email to
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/leo-editor?hl=en.
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email to leo-edi...@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: Is it safe to make assumptions about the order of positions in p.subtree()?
Short answer: yes The current code behaves as you describe, and effectively defines a Thread (via the p.moveToThreadNext() method) to be a depth first tree traversal (clones will be visited multiple times, but the acyclic nature of the graph guarantees a termination of the traversal). - Stephen On Apr 28, 11:42 am, zpcspm zpc...@gmail.com wrote: Consider the following tree: - p1 - p2 - p4 - p3 - p5 Is it safe to assume that p4 will appear in p.subtree() after p2, but before p3? -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/leo-editor?hl=en. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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.
reStructuredText chapter heading adjustment?
I'm obtaining the pdf for the Users's Guide, with this blemish: The acknowledgements are decorated as Chapter 1, the Preface as Chapter 2, etc., with the severe dissonance arising when Chapter 1: Installing Leo gets decorated as Chapter 5, and its subsections decorated as 5.1, 5.2, and so on for the remainder of the explicitly numbered chapters (i.e., the rest of the book). I tried changing the title decorations to match the Python Part and Section conventions, but that didn't help. Advice? - Stephen -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: Latest Leo better with Tk or Qt?
In my environment, drag-n-drop of nodes within the outline works for Tk, but does not for Qt. This was an area where I will be suggesting changes in the User Guide, but I haven't finished understanding and reframing the meaning of the current documentation. - Stephen On Apr 22, 1:25 pm, Edward K. Ream edream...@gmail.com wrote: On Thu, Apr 22, 2010 at 11:32 AM, Ville M. Vainio vivai...@gmail.com wrote: On Thu, Apr 22, 2010 at 7:27 PM, Nick_H n...@plextek.co.uk wrote: I have both Tk and Qt installed on my Windows XP system, and Leo 4.7.1 seems to behave differently according to whether I run Leo using Python 2.6 with Tk, or Python 3.1 with Qt. For fair comparison, run with python 2.6 + qt. In my mind, the qt version of Leo is far superior to the tk version, regardless of the Python version. The only reason I can think of to use the tk version would be because some plugins only work with tk. 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-edi...@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/leo-editor?hl=en. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: Documentation pdf
I continue thrashing about, and something has changed. I noticed an error message from the generate-userguide button actions complaining directory _static does not exist. So I created an empty leo/doc/html/_static directory. The next attempt at using the button did not generate an error. I then changed the button to include the pdf manual instead of generating the pdf from the command line. After clicking the button, voilá, no more NSA-style redactions in the pdf. Hurray! There's still no index. Clue as to how to generate an index would be appreciated. Having read up through Chapter 3, there's some content I think needs changing; I'll be discussing that in a separate thread. There's a disabled button that appears to have been used to generate leo/doc/LeoUserGuide.txt, which is an rst file, however, the API for the code invoked in that button appears to have changed too radically to be salvageable, and the file is what was put in bzr on Mon 2009-08-24. If there's a new way to go from LeoDoc.leo to LeoUserGuide.txt, please let me know. Thrash, thrash, thrash... - Stephen On Apr 19, 2:26 am, thyrsus sschae...@acm.org wrote: I'm using python-sphinx-0.6.4-1.fc12.noarch. What version should I use? On Apr 19, 1:49 am, Ville M. Vainio vivai...@gmail.com wrote: On Mon, Apr 19, 2010 at 7:11 AM, thyrsus sschae...@acm.org wrote: ...so I proceeded as suggested: cd _build/latex; make all-pdf which ran pdflatex Leodocumentation.tex I have succesfully generated the pdf manual for Leo using these steps before, so it should be solveable. Perhaps by upgrading sphinx version? -- Ville M. Vainiohttp://tinyurl.com/vainio -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/leo-editor?hl=en. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/leo-editor?hl=en. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: Documentation pdf
I did leo LeoDocs.leo I clicked the button generate-userguide. That created a substantial number of files in the directory html. I then created the latex document as follows: cd html; make latex That ended with the folllowing notice: Build finished; the LaTeX files are in _build/latex. Run `make all-pdf' or `make all-ps' in that directory to run these through (pdf)latex. ...so I proceeded as suggested: cd _build/latex; make all-pdf which ran pdflatex Leodocumentation.tex ...several times (presumably to converge page numbers for the table of contents and index). As I noted, running latex Leodocumentation.tex somehow also created a pdf file and not a dvi; I have to infer that the form of output is somehow being directed by the supporting LaTeX libraries. On Apr 18, 7:20 pm, Largo84 larg...@gmail.com wrote: If I could see what LaTex code you were working with I might have some ideas as I work with LaTex quite a bit. Rob... On Apr 17, 6:36 pm, thyrsus sschae...@acm.org wrote: I was *almost* able to create a PDF document from the LaTeX version of the Leo manual, but all the code examples came out black-on-black, with my PDF readers all complaining about unknown operator 'rgb'. The result looked as if it came from the NSA ;-). The make target that was supposed to produce postscript just recreated the .pdf file, then complained that there was no .dvi file to process; I've noticed that the latex command doesn't produce the .dvi I expected. I'm no expert with any of this. There's also no index, but I can't tell if there is supposed to be. Does anyone have a clue to offer? - Stephen -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/leo-editor?hl=en. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/leo-editor?hl=en. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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.
Publishing hardcopy of the PDF
Assuming the difficulties with the pdf are overcome, it appears that it would be easy enough to get a bound hardcopy from lulu.com, an on- demand self publishing service (I understand the MIT license to cover the manual, so that should be acceptable). I could make the book private - i.e., only I would have access to that copy. If there is sufficient sentiment for more availability, then it would make more sense for Edward to do the publishing, so he could be satisfied with details like the cover design and perhaps a royalty to support the project. Lulu says they take 20% of the book's profit, by which I understand royalties; presumably, they also earn some amount on the production cost, so they can stay solvent when publishing $0.00 royalty books; anyone interested in details should ignore me and see the lulu.com web page. If someone has a better idea for hardcopy, please post. Edward might think royalties aren't worth the trouble, in which case I wouldn't mind doing busy work. If royalties were charged, I'd prefer not to be a middle man, and I don't know if Lulu has a mechanism for assigning royalties to someone besides the account holder. What impact such a project would have on a more traditional book project, I have no idea. I want only what's best for Leo and our Benevolent Dictator for Life :-) (well, and also a bound hardcopy of the manual ;-) -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: Documentation pdf
/ states.py, line 266, in nested_parse node=node, match_titles=match_titles) File /usr/lib/python2.6/site-packages/docutils/parsers/rst/ states.py, line 195, in run results = StateMachineWS.run(self, input_lines, input_offset) File /usr/lib/python2.6/site-packages/docutils/statemachine.py, line 232, in run context, state, transitions) File /usr/lib/python2.6/site-packages/docutils/statemachine.py, line 420, in check_line return method(match, context, next_state) File /usr/lib/python2.6/site-packages/docutils/parsers/rst/ states.py, line 2658, in underline self.section(title, source, style, lineno - 1, messages) File /usr/lib/python2.6/site-packages/docutils/parsers/rst/ states.py, line 307, in section if self.check_subsection(source, style, lineno): File /usr/lib/python2.6/site-packages/docutils/parsers/rst/ states.py, line 336, in check_subsection self.parent += self.title_inconsistent(source, lineno) File /usr/lib/python2.6/site-packages/docutils/parsers/rst/ states.py, line 354, in title_inconsistent line=lineno) File /usr/lib/python2.6/site-packages/docutils/utils.py, line 222, in severe return self.system_message(self.SEVERE_LEVEL, *args, **kwargs) File /usr/lib/python2.6/site-packages/docutils/utils.py, line 180, in system_message raise SystemMessage(msg, level) docutils.utils.SystemMessage: leoUserGuide.txt:14325: (SEVERE/4) Title level inconsistent: IPython code On Apr 17, 6:36 pm, thyrsus sschae...@acm.org wrote: I was *almost* able to create a PDF document from the LaTeX version of the Leo manual, but all the code examples came out black-on-black, with my PDF readers all complaining about unknown operator 'rgb'. The result looked as if it came from the NSA ;-). The make target that was supposed to produce postscript just recreated the .pdf file, then complained that there was no .dvi file to process; I've noticed that the latex command doesn't produce the .dvi I expected. I'm no expert with any of this. There's also no index, but I can't tell if there is supposed to be. Does anyone have a clue to offer? - Stephen -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/leo-editor?hl=en. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: O[blique to] T[opic]: a contemplation of the differences between object and functional programming
I think what the Principle of Demeter described by the article is trying to do is to reduce the number of API's exposed in a particular code module. Adhering to such a principle would make it easier to switch OSs, GUIs, databases, or any of the other intermediate components in a piece of software. The price is that every upper level API must itself provide access to any lower level data legitimately required by a user of the upper level API. Where to draw the line is an engineering decision. Although not explicitly stated in the article, I think what the functional programming folks are claiming is that it's important that one's data structure contain everything essential and nothing inessential, and that the essential be exposed by the functions on that data structure (which may be interpreted as an API). The functional programming approach doesn't give much guidance on what to do with the components that move the data from one representation to another. Such impedance converters necessarily accrete or hide data along the way; e.g., Leo hides portions of the d.a.g. on the screen; the newlines between XML elements are inessential to the underlying data structure and are thus inessential accreted data. - Stephen On Apr 17, 9:11 am, Edward K. Ream edream...@gmail.com wrote: On Fri, Apr 16, 2010 at 2:38 PM, thyrsus sschae...@acm.org wrote: Since Leo is very often about understanding programs, this is not completely off-topic. It's not off topic at all. It's an interesting design issue. I found this train/chain wreck comparison well worth thinking about: http://www.glenstampoultzis.net/blog/2010/04/12/train-wrecks-in-funct... Hmm. I never think about train wrecks. The important design principle is hiding information. A chain a.b.c.d.e.f... makes sense iff each part of the chain is an essential part of the preceding object's api. Naturally, such chains could break if api's change, but that can't be helped. So what matters, to the first approximation at least, is the api and its relation to the data being hidden. Glen Meyers and David Parnas explored these issues years before there was any OO programming. 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-edi...@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/leo-editor?hl=en. -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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.
Documentation pdf
I was *almost* able to create a PDF document from the LaTeX version of the Leo manual, but all the code examples came out black-on-black, with my PDF readers all complaining about unknown operator 'rgb'. The result looked as if it came from the NSA ;-). The make target that was supposed to produce postscript just recreated the .pdf file, then complained that there was no .dvi file to process; I've noticed that the latex command doesn't produce the .dvi I expected. I'm no expert with any of this. There's also no index, but I can't tell if there is supposed to be. Does anyone have a clue to offer? - Stephen -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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.
O[blique to] T[opic]: a contemplation of the differences between object and functional programming
Since Leo is very often about understanding programs, this is not completely off-topic. I found this train/chain wreck comparison well worth thinking about: http://www.glenstampoultzis.net/blog/2010/04/12/train-wrecks-in-functional-languages/ - Stephen -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: @script runs before plugins, not after
I'd like to nominate this for inclusion in the official documentation - which I should spend the day rereading :-). - Stephen On Apr 13, 6:11 pm, Terry Brown terry_n_br...@yahoo.com wrote: (this is a note to self / others, not a suggestion something be done) I notice @scripts in the outline are run before plugin initiation is complete. Doesn't suit my particular application, because I wanted to monkey patch an instance of a plugin class which binds to c. You can work around it like this: def prikey(self, v): try: pa = int(self.getat(v, 'priority')) except ValueError: pa = -1 if pa == 24: pa = -1 if pa == 10: pa = -2 return pa import types from leo.core import leoPlugins def on_create(tag, keywords): c.cleo.prikey = types.MethodType(prikey, c.cleo, c.cleo.__class__) leoPlugins.registerHandler(after-create-leo-frame,on_create) Attempting to modify c.cleo.prikey immediately in the @script gives an AttributeError as c has no .cleo when the @script is executed. Deferring it by using registerHandler() avoids the problem. Cheers -Terry -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: Building rpm - dealing with plugin syntax errors
Thanks for that assurance.
By publish I meant I was contemplating a nomination of the
Leo .rpm/.src.rpm for the Fedora distribution. It would be an
interesting exercise, if nothing else, to go through their quality
control process. What would be a good way to suppress these errors?
Just '@@' in the headline to suppress reading the files?
For the purposes of such a distribution, I'm leaning toward dealing
with LeoN.py by puting an @ignore directive in the leoPluginsRef.leo
and simply prefixing every line in LeoN.py with #. I really don't
know what to do about ConceptualSort.py; the error when byte compiling
is
SyntaxError: (unqualified exec is not allowed in function 'lcsort2'
it is a nested function,)
As best I can tell, there is a syntax change between python 2.6 and
python 3, with the python 2.6 syntax in a comment. For a Fedora
distribution, should I just move the comment marker to the Python 3
line?
I'm generating the MANIFEST file using this bash script (the extra sed
is due to DOS line endings in bzr-manifest.txt):
for f in $(sed -e 's/\r//' bzr-manifest.txt); do [ -f $f ] echo $f;
done MANIFEST
I've created a setup.cfg file to give some clues to bdist_rpm.
The Fedora folks are fastidious about licenses, so I'd like to add a
license = option. Ville, I see that you introduced the current
version; do you think I should leave the tag as UNKNOWN, or could it
be characterized with one of the existing Fedora license tags? To
generate a list of such tags on a Fedora system, I use
rpm -qa --qf '%{LICENSE}\n' | sort -u
- Stephen
On Mar 15, 3:04 pm, Ville M. Vainio vivai...@gmail.com wrote:
On Mon, Mar 15, 2010 at 7:15 PM, thyrsus sschae...@acm.org wrote:
Have those been mistakenly purged by including leo/doc/html in
scrub_datafiles?
It's not a mistake.
The error is harmless.
--
Ville M. Vainiohttp://tinyurl.com/vainio
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email to leo-edi...@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: Building rpm - dealing with plugin syntax errors
More trouble: the setup.py excludes files in directories with an
__init__.py from the data_files list. Instead, there's a line
package_data = {'leo.plugins' : datapats },
where datapats is a list including '*.ui'. Unfortunately, this is
insufficient to convince build_rpm to include those files in the
package. I tried adding
package_dir = {'leo.plugins': 'leo/plugins' },
but that didn't help. I see there's magic code to get windows to
work; is something similarly obscure necessary to convince rpm to
function?
- Stephen
On Mar 15, 12:22 am, thyrsus sschae...@acm.org wrote:
I just attempted to build an rpm for 4.7.1-final with
python setup.py bdist_rpm
...which failed when it encounted syntax errors in plugins/
ConceptualSort.py and plugins/LeoN.py (the rpm attempts to
include .pyc and .pyo files files). The python is 2.6.2 in the Fedora
12 environment. I'm thinking of publishing this, and I'd like
recommendations as to whether to (a) fix the syntax, when I see that
the unitTest.leo declares ConceptualSort.py as tkfail and LeoN.py as
dead, or (b) comment out all the contents of the two file, so as to
document their presence, but make them effective no-ops. I'm not sure
that will really make everything happy; your advice is appreciated.
- Stephen
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email to leo-edi...@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: Building rpm - dealing with plugin syntax errors
So I'm obviously new to this distutils stuff. An earlier run of
python setup.py bdist_rpm created a MANIFEST file with only *.py
files and leo/scripts/leo
I manually added to that the results of find leo \( -name *.ui -o -
name *.leo \) -print; find leo/Icons -print and that seems to have
gotten them included in the .rpm package. Are there more non-python
files I should manually add to MANIFEST?
- Stephen
On Mar 15, 2:08 am, thyrsus sschae...@acm.org wrote:
More trouble: the setup.py excludes files in directories with an
__init__.py from the data_files list. Instead, there's a line
package_data = {'leo.plugins' : datapats },
where datapats is a list including '*.ui'. Unfortunately, this is
insufficient to convince build_rpm to include those files in the
package. I tried adding
package_dir = {'leo.plugins': 'leo/plugins' },
but that didn't help. I see there's magic code to get windows to
work; is something similarly obscure necessary to convince rpm to
function?
- Stephen
On Mar 15, 12:22 am, thyrsus sschae...@acm.org wrote:
I just attempted to build an rpm for 4.7.1-final with
python setup.py bdist_rpm
...which failed when it encounted syntax errors in plugins/
ConceptualSort.py and plugins/LeoN.py (the rpm attempts to
include .pyc and .pyo files files). The python is 2.6.2 in the Fedora
12 environment. I'm thinking of publishing this, and I'd like
recommendations as to whether to (a) fix the syntax, when I see that
the unitTest.leo declares ConceptualSort.py as tkfail and LeoN.py as
dead, or (b) comment out all the contents of the two file, so as to
document their presence, but make them effective no-ops. I'm not sure
that will really make everything happy; your advice is appreciated.
- Stephen
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email to leo-edi...@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: Building rpm - dealing with plugin syntax errors
Sorry to continue the monologue; I hope someone finds it useful: I'm
experimenting with creating MANIFEST from all the regular files listed
in bzr-manifest.txt. That is apparently cleansed by these lines in
setup.py:
scrub_datafiles = ['leo/extensions', '_build', 'leo/test', 'leo/
plugins/test', 'leo/doc/html']
for dirpath, dirnames, filenames in os.walk(leo_dir):
# Ignore dirnames that start with '.'
for i, dirname in enumerate(dirnames):
if dirname.startswith('.'): del dirnames[i]
if '__init__.py' in filenames:
fsplit = fullsplit(dirpath)
packages.append('.'.join(fsplit))
elif filenames:
if not any(pat in dirpath for pat in scrub_datafiles):
data_files.append([dirpath, [os.path.join(dirpath, f) for
f in filenames]])
Later, when I open LeoDocs.leo from the result of the rpm install, I
get these complaints:
reading: /usr/lib/python2.6/site-packages/leo/doc/LeoDocs.leo
can not open: '@file /usr/lib/python2.6/site-packages/leo/doc/html/
front.html'
reading @edit: conf.py
can not open @edit /usr/lib/python2.6/site-packages/leo/doc/html/
conf.py
reading @edit: leo_toc.html.txt
can not open @edit /usr/lib/python2.6/site-packages/leo/doc/html/
leo_toc.html.txt
Have those been mistakenly purged by including leo/doc/html in
scrub_datafiles?
- Stephen
On Mar 15, 12:31 pm, thyrsus sschae...@acm.org wrote:
So I'm obviously new to this distutils stuff. An earlier run of
python setup.py bdist_rpm created a MANIFEST file with only *.py
files and leo/scripts/leo
I manually added to that the results of find leo \( -name *.ui -o -
name *.leo \) -print; find leo/Icons -print and that seems to have
gotten them included in the .rpm package. Are there more non-python
files I should manually add to MANIFEST?
- Stephen
On Mar 15, 2:08 am, thyrsus sschae...@acm.org wrote:
More trouble: the setup.py excludes files in directories with an
__init__.py from the data_files list. Instead, there's a line
package_data = {'leo.plugins' : datapats },
where datapats is a list including '*.ui'. Unfortunately, this is
insufficient to convince build_rpm to include those files in the
package. I tried adding
package_dir = {'leo.plugins': 'leo/plugins' },
but that didn't help. I see there's magic code to get windows to
work; is something similarly obscure necessary to convince rpm to
function?
- Stephen
On Mar 15, 12:22 am, thyrsus sschae...@acm.org wrote:
I just attempted to build an rpm for 4.7.1-final with
python setup.py bdist_rpm
...which failed when it encounted syntax errors in plugins/
ConceptualSort.py and plugins/LeoN.py (the rpm attempts to
include .pyc and .pyo files files). The python is 2.6.2 in the Fedora
12 environment. I'm thinking of publishing this, and I'd like
recommendations as to whether to (a) fix the syntax, when I see that
the unitTest.leo declares ConceptualSort.py as tkfail and LeoN.py as
dead, or (b) comment out all the contents of the two file, so as to
document their presence, but make them effective no-ops. I'm not sure
that will really make everything happy; your advice is appreciated.
- Stephen
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email to leo-edi...@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.
Building rpm - dealing with plugin syntax errors
I just attempted to build an rpm for 4.7.1-final with python setup.py bdist_rpm ...which failed when it encounted syntax errors in plugins/ ConceptualSort.py and plugins/LeoN.py (the rpm attempts to include .pyc and .pyo files files). The python is 2.6.2 in the Fedora 12 environment. I'm thinking of publishing this, and I'd like recommendations as to whether to (a) fix the syntax, when I see that the unitTest.leo declares ConceptualSort.py as tkfail and LeoN.py as dead, or (b) comment out all the contents of the two file, so as to document their presence, but make them effective no-ops. I'm not sure that will really make everything happy; your advice is appreciated. - Stephen -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: The failure of the @file tests (to fail)
One of my favorite sayings: If you don't make mistakes, you're not trying. What's important is to learn, and I think rhere is a general lesson here. The change to @thin semantics for @file changed the semantics of the .leo file; i.e., earlier versions of Leo could no longer read the .leo file. One can therefore not rely on new code to generate - or even preserve - a test case that it could not naturally generate itself (I'm sure there's a way to hide a test .leo file from a containing .leo file and write it out, but a read-only blob sitting in the test tree would be simpler). I.e., transitions are hard, and need to be tested. - Stephen On Feb 24, 10:26 am, Edward K. Ream edream...@gmail.com wrote: The problems with @file that have just resurfaced show how hard it can be to manage complex engineering projects. I got blind-sided by this problem, despite the fact that it had been dealt with before. The problem was compounded by the fact that the unit tests for @file never failed. Looking at them just now, I see that they silently became irrelevant sometime during the course of 4.7 development. Indeed, the unit tests generate file-like sentinels, and then verify that Leo writes those sentinels as expected. But the new @file == @thin code forces thin-like sentinels. Presto, the old unit tests began to test the wrong thing. This shows, quite clearly, that unit tests can create a false sense of security. If there is an automated way to avoid this trap I don't know what it is. Edward P.S. In order to make progress, I relentlessly focus on closing issues. But any mistake in doing so can create a time bomb. One such bomb has just exploded. Here, with Leo, the stakes are relatively small. With the Space Shuttle the stakes are much bigger, and the engineering difficulties much larger. It is all too easy to criticize the management mistakes after they came into sharp focus after the fact. At the time, however, the mistake was only one of thousands of decisions. Could any of us honestly say we surely would have done better? I doubt it. EKR -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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: Ville, what's the status of the install script in the top-level folder?
Sorry for the late reply. The manual, http://webpages.charter.net/edreamleo/install.html specifies use of the install script for Linux. Is there a replacement? It had been working for me, though I hadn't vigourously tested it. - Stephen On Jan 29, 12:54 pm, Edward K. Ream edream...@gmail.com wrote: On Fri, Jan 29, 2010 at 1:00 PM, vivainio vivai...@gmail.com wrote: I don't know, i didn't write it. It's probably broken now. I only care about setup.py. Linux users should use the deb or launchLeo.py Ok. I'll trash it. 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-edi...@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: Leo 4.7 delayed until critical issues fixed
I use cross-file clones. When I do, I consider the Leo file authoritative, and the external files derivative. It becomes unwise to edit such derived files outside of Leo because of the likelihood of introducing inconsistencies. I think this suggest that when a leo file contains cross-file clones, it should *not* incorporate changes made to the involved files outside of Leo; and therefore the cross file clones should be limited to @file generated files, and unavailable in @thin. That restriction is because with @file, the full contents of the file can be derived from the Leo file, whereas in the latter, reconstruction from the derived file is mandatory. Such a restriction could be adopted in multiple ways. Simpler: @file now means that cross file clones are allowed, and changes to files derived from @files outside of leo are ignored; conversely, @thin now means that cross file clones are forbidden and changes from outside leo are incorporated. A cross-file clone encountered in an @thin file throws an exception with a hint about the offending gnx. More complex: @files are inspected for cross-file clones; if and only if there are none, changes from outside of leo are incorporated. That could be further refined so that it is only within content derived from cross-file clones that externally introduced changes get ignored. For @thin files, when encountering a node that is ostensibly cross-file (because of an identical gnx), Leo automatically de-clones the node, assigning a new gnx. Currently, when there are cross-file nodes, the version of the node last encountered during reads of the leo file and its derived file wins - and that order is not well defined. I think we should move away from that. - Stephen On Jan 20, 8:58 am, Edward K. Ream edream...@gmail.com wrote: On Wed, Jan 20, 2010 at 7:36 AM, Ville M. Vainio vivai...@gmail.com wrote: On Wed, Jan 20, 2010 at 2:57 PM, Edward K. Ream edream...@gmail.com wrote: 1. I am considering removing leoProjects.txt from the repository. Indeed, it is irritating to have the diffs muddied by the clones in this file. Just change it to leoProjects.leo, or move the stuff itself to the leo file. Possible. I think the present scheme (local copies) is good enough for now. For sure I won't miss the redundant and confusing diffs. 3. I shall consider banning cross-file clones, that is, clones that appear in multiple *external* files. This would make @view nodes more urgent. This probably will happen after Leo 4.7 final. Before outright banning (there are people who might really need the feature), just produce a loud warning when they are being used. Don't worry, the ban on cross-file clones won't happen soon, and maybe not at all. Indeed, I am already starting to miss them :-) I've used them for years without too much trouble. Banning them is already starting to look like an over-reaction. Otoh, *something* caused last night's woes, and it is troubling that it happened. 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-edi...@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: Leo 4.7 delayed until critical issues fixed
When one uses clones to derive files, Leo is acting as a macro language from which the derived file is generated. Just as you wouldn't edit the output of gcc -E and expect the change to be incorporated in one's source code, you can't expect to edit a file derived from multiple instantiated clones and expect the clones to reflect those changes. When clones aren't involved, there is a mapping between the derived file and the leo file, but not otherwise. The alternatives for collaboration seem to me to be: A: The Leo file is the source; the derived files the uneditable objects. 1 (Either) conflicts don't happen because there are only one-at-a- time edits enforced by locking. 2 (Or) someone invents a directed acyclic graph conflict resolution tool. B: The derived files are the source; the Leo file gets derived. 1. Right now, last (for some value of last) version of a clone wins (mostly: with cross-file clones, Leo doesn't mark earlier read files containing the clone as modified, even though it notes when reading a subsequent clone in an @thin derived file that the node has changed. Move the @thin file around in the outline, and the woods get thick. At Leo trunk revno 2705, the second occurrence of a cloned node within a single @thin file doesn't get written into the derived @thin file. Is that a feature?). 2. I suggest that variant versions of a clone get uncloned; it would be useful to generate a warning. I currently do A1; if I get a sabbatical I'll invent A2 (apparently the commercial tool oXygen can resolve XML conflicts). Edward's practice is currently B1. B2 might improve things. - Stephen On Jan 20, 2:01 pm, Edward K. Ream edream...@gmail.com wrote: On Wed, Jan 20, 2010 at 12:46 PM, thyrsus sschae...@acm.org wrote: I use cross-file clones. When I do, I consider the Leo file authoritative, and the external files derivative. @thin is essential in a cooperative environment. We can pull external files from the bzr repository without having to update the .leo file. We have no choice but to make this work. It becomes unwise to edit such derived files outside of Leo because of the likelihood of introducing inconsistencies. Bzr pulls are such 'edits'. We can't forbid them. We must learn to tame them. 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-edi...@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: qt gui now supports variable tab width and syntax-directed fonts
Ultra-low priority, but relevant to widths: in Qt, the Chapters: dropdown selection button is initially wide enough to contain main; if you choose from among other chapter names (the selection list is already correctly adapts to handle the largest chapter name I've ever used), the button takes on the name of the chapter, but truncates it to fit in the width of main. Don't spend time on this unless it's easy. Thanks, - Stephen On Jan 18, 3:36 pm, Edward K. Ream edream...@gmail.com wrote: Rev 2697 fixes several bugs by adding some important new features. 1. You can now specify the width of hard tabs using the @int qt_tab_width setting. Use 40 or 60 for @tabwidth 4 and @tabwidth 8 respectively. 2. You can now specify the fonts of various syntax-coloring constructs. You can specify defaults for various tags, and override these defaults on a language-by-language basis. For details, see:http://webpages.charter.net/edreamleo/coloring.html#syntax-coloring-s... test.leo contains two example (disabled) @font nodes illustrating how to set these settings. 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-edi...@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: Please do *not* use Google Wave for real work
Yes: wave could be used to edit Leo documents interactively. The promise of wave is that, used correctly, there would be no document conflicts to resolve - and you would be aware that someone is contemporaneously changing the same node/tree that you're working on. There are still cases where preserving versions is appropriate. I and my colleagues use Leo to generate the files that configure computers. The Leo file is the one source of truth for that configuration. We rarely are working on the same component - whether that is host or role or implementing script - at the same time, but we need simultaneous access to the entire Leo file. Currently, version control conflict resolution on XML like entities is so worthless that I've simply declared the Leo file to be binary, and we lock and unlock the file to make changes, with only one person able to make changes while the file is available read-only to others. Wave could fix this. The insights gained from the @shadow implementation are important. Don't hold your breath for an implementation from me: the idea is easier than the programming, but I wanted to get the idea out there in case it inspired a more productive programmer than I. - Stephen On Nov 20, 9:03 am, Edward K. Ream edream...@gmail.com wrote: On Thu, Nov 19, 2009 at 7:27 PM, thyrsus sschae...@acm.org wrote: In the presentation Google gave at LISA, the chat application is simply a toy demo. Wave's importance is that it provides a library and service to provide eventually consistent documents - and why shouldn't that document be a Leo file?! I had to read this a few times before I understood what you might be saying :-) So, are you saying it might be possible to use the wave library to edit Leo documents interactively? OTOH, we already have a way to collaborate on editing, say, leoDocs.leo: it's bzr. I've often said that I don't like instant (im-like) collaboration. I much prefer to work on my own most of the time, uninterrupted. 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-edi...@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=.
Re: Please do *not* use Google Wave for real work
But wave is operation transform enhanced XML, they're already operating on XML documents. From the wave definition at http://www.infoq.com/news/2009/06/wave: Document - A document has an ID that is unique within its containing wavelet and is composed of an XML document and a set of stand-off annotations. Stand-off annotations are pointers into the XML document and are independent of the XML document structure. They are used to represent text formatting, spelling suggestions and hyper-links. Documents form a tree within the wavelet. - Stephen On Nov 20, 3:40 pm, Edward K. Ream edream...@gmail.com wrote: On Fri, Nov 20, 2009 at 12:05 PM, thyrsus sschae...@acm.org wrote: Yes: wave could be used to edit Leo documents interactively. The promise of wave is that, used correctly, there would be no document conflicts to resolve - and you would be aware that someone is contemporaneously changing the same node/tree that you're working on. There are still cases where preserving versions is appropriate. I and my colleagues use Leo to generate the files that configure computers. The Leo file is the one source of truth for that configuration. We rarely are working on the same component - whether that is host or role or implementing script - at the same time, but we need simultaneous access to the entire Leo file. Currently, version control conflict resolution on XML like entities is so worthless that I've simply declared the Leo file to be binary, and we lock and unlock the file to make changes, with only one person able to make changes while the file is available read-only to others. Wave could fix this. The insights gained from the @shadow implementation are important. Don't hold your breath for an implementation from me: the idea is easier than the programming, but I wanted to get the idea out there in case it inspired a more productive programmer than I. Many thanks, Stephen, for these details. Any solution for .leo files would, it seems to me, immediately generalize to all xml files. 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-edi...@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=.
Re: Please do *not* use Google Wave for real work
In the presentation Google gave at LISA, the chat application is simply a toy demo. Wave's importance is that it provides a library and service to provide eventually consistent documents - and why shouldn't that document be a Leo file?! - Stephen On Nov 8, 4:48 pm, Ville M. Vainio vivai...@gmail.com wrote: On Sun, Nov 8, 2009 at 2:35 PM, Edward K. Ream edream...@gmail.com wrote: 1. [Most important] Apparently, it is not possible for us to issue more invitations to Google Wave, which means that most members of this Google Group can not take part. We can not tolerate this. 2. [Very important] There seems to be no way to invite everyone in this Google Group to take part in a wave. Until that happens, I don't think we want to create cliques within this group. Agree about these. 3. [Somewhat important] It's not clear that Google Wave can deliver the required performance as millions of people start using it. The performance I've seen has been marginal. I trust google's judgement on scalability. They will absolutely not issue so many accounts that the wave slows down intolerably. 4. [Unknown importance] As most of you may know, I am not a fan of instant messaging. I find it to be, usually, a huge distraction. Perhaps I can use Google Wave more like email, so that I don't get sucked into immediate conversations, but I'm not convinced that that will happen. Apart from high level of interactivity being somewhat more demanding, I also believe it's more productive, in that less time will be wasted on producing communication that fall to deaf ears (as the subject matters gets too advanced, or off-topic, or whatever). I have often noted that things get grossly misunderstood when a slow, clumsy medium such as email is used. Even if the form of communication may feel a bit alien initially, the whole point is to reach a superior level of communication (where we have less talk and more results). 5. [Unknown importance, but troubling] The *promise* of Google Wave is effective collaboration, but the waves I am seeing would need intensive editing for their contents to be useful as any kind of writing. I *really* do not add yet another task to my life, namely the task of deleting or summarizing dozens or hundreds of IM-like one- line comments. Perhaps each wave will need a designated editor who will clean up the wave, or perhaps some other solutions can be found, but until that solution becomes clear I have a bad feeling about the entire project. I expect this to happen quite organically. Cleaning up waves is a collaborative effort, and you could just do 5 minutes of it every now and then, and let someone else continue. It could start simple, like perhaps just going through a wave and making important points stated stand out in boldface. After that, someone can scan for deeper information related to the bolded points, etc. etc. It should be very productive (esp. when we don't have several consequtive hours at a time to contribute, just 10 minutes here, 2 hours there). Anyway, until the concerns in points 1 and 2 above are completely resolved, I think it only proper that all important communication about Leo takes place here, in leo-editor, rather than in various waves. Agreed about important communication. Less important communication is okay in wave I think, esp. if it's expected to be collaboration between only a few people with wave accounts. The philosophers stone of wave is IMO that it could turn out to be a form of collaboration superior even to sharing an office space. We definitely don't want to miss that. -- Ville M. Vainiohttp://tinyurl.com/vainio -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-edi...@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=.
Re: OT: The Monty Hall Problem
The current glacier melt is not about snowfall, it's about feedback loops. Watch http://www.youtube.com/watch?v=F-QA2rkpBSY about the failure of past experience to deal with exponential changes. Characterizing those who want to mitigate climate change as interested primarily in population reduction is like characterizing the U.S. Republican party as secessionist: there are a few such extremists, but they do not constitute the serious majority. Thermal hot salt plants sound like a prima facie good idea to me, and I'd be happy to entertain any controlled nuclear solution that dealt sustainably with spent fuel disposal. The key is sustainability. As the technology improves, the sustainable population capacity improves. - Stephen On Oct 7, 6:56 am, James A. Donald jam...@echeque.com wrote: ne1uno wrote: so what's your spin on the anti junk science view of glaciers receding? As Climate skeptic sarcastically observed: Somehow, man’s burning of fossil fuels in the late 20th century has caused glaciers to begin melting … starting in the 18th century. glacier change is evidence of climate change, but not, however, anthropogenic climate change. Glaciers have been retreating at a roughly steady rate from 1850 to the present, but substantial increases in CO2 only set in after 1950 or so Glaciers are a lagging indicator of climate change, because the current position of the glacier front reflects snowfall centuries ago - glaciers are retreating today because of seventeenth century global warming. Sea ice is as more responsive indicator, and since 1978, there has been no trend in global sea ice, resulting in ever escalating prophecies of sea ice melting real soon now, and orgasms whenever the arctic melts more than usual in the summer. Glaciers have yet to retreat to the positions they were in shortly after the Medieval Climatic optimum - telling us that climate changes from time to time, but that it is today not as warm as it has been, nor as cold as it has been. or continuing to depend on the internal combustion engine? overreacting to climate change will hardly make the top 100 major follies of the human race in the last 20 years As the communists intended to annihilate the bourgeoisie, and the Nazis intended to exterminate the Jews, the greenies intend to destroy industrial civilization and reduce the earth's population to sustainable levels. If they actually believed it was important to reduce CO2 production, they would support building nukes and building solar thermal hot salt power stations in the desert. That they oppose solar thermal hot salt power stations shows they want the lights out. --~--~-~--~~~---~--~~ 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: ruby
On Aug 28, 1:48 pm, thyrsus sschae...@acm.org wrote: I'd like to create a scanner for the ruby language, and to proceed through test driven development. As I understand it, test driven development means identifying a before, an after, developing a test to determine whether the before was successfully turned into the after, then writing the code to turn the before into the after. In the case of a ruby scanner, the before would be a string containing ruby code, the after would be a Leo tree with the nodes partitioning the ruby code into modules, classes, methods. I'm concerned about two issues. The easiest, perhaps, first. The scanner should take a string and return a portion of a Leo tree, and my test should compare that Leo tree fragment to a pre-built Leo tree fragment which is the expected result. Is there already a routine that can do (deep) comparisons of trees, where equivalence is (a) headers are identical (b) bodies are identical (c) children are identical? The harder problem may be ruby syntax. scanHelper() expects to be able to find whitespace comments strings class definitions function/method definitions ids (names) code blocks noise I'm worried about strings. Like /bin/sh and perl, Ruby supports here documents, that is, strings which are introduced by word, and whose value is all the following lines of source up to the occurrence of word on a line by itself. There are variations on quoting and indentation, but those don't introduce difficult hurdles. The real problem is that Ruby can also use as a method name, as in the familiar left shift: irb(main):002:0 18 = 256 Thus to disambiguate the beginning of a string and the invocation of a method, the parser needs to expect one or the other. I don't see how to do this in cooperation with the current scanner class design. Does anyone have an insight? Hey, at least it's not perl, the parsing of which was recently show to require solution of the halting problem:http://www.perlmonks.org/?node_id=663393 - Stephen I'm cheating on the tree comparisons. This is what I'm using for rubyUnitTest def rubyUnitTest (self,p,fileName=None,s=None,showTree=False,compTree=False): if compTree: showTree=True result = self.scannerUnitTest (p,atAuto=False,fileName=fileName,s=s,showTree=showTree,ext='.rb') if result and compTree: p.moveToFirstChild() t1 = p.convertTreeToString() p.moveToNext() t2 = p.convertTreeToString() result = (t1 == t2) if g.app.unitTesting: if not result: g.es(expected: + t1) g.es(obtained: + t2) assert result return result --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
ruby
I'd like to create a scanner for the ruby language, and to proceed through test driven development. As I understand it, test driven development means identifying a before, an after, developing a test to determine whether the before was successfully turned into the after, then writing the code to turn the before into the after. In the case of a ruby scanner, the before would be a string containing ruby code, the after would be a Leo tree with the nodes partitioning the ruby code into modules, classes, methods. I'm concerned about two issues. The easiest, perhaps, first. The scanner should take a string and return a portion of a Leo tree, and my test should compare that Leo tree fragment to a pre-built Leo tree fragment which is the expected result. Is there already a routine that can do (deep) comparisons of trees, where equivalence is (a) headers are identical (b) bodies are identical (c) children are identical? The harder problem may be ruby syntax. scanHelper() expects to be able to find whitespace comments strings class definitions function/method definitions ids (names) code blocks noise I'm worried about strings. Like /bin/sh and perl, Ruby supports here documents, that is, strings which are introduced by word, and whose value is all the following lines of source up to the occurrence of word on a line by itself. There are variations on quoting and indentation, but those don't introduce difficult hurdles. The real problem is that Ruby can also use as a method name, as in the familiar left shift: irb(main):002:0 18 = 256 Thus to disambiguate the beginning of a string and the invocation of a method, the parser needs to expect one or the other. I don't see how to do this in cooperation with the current scanner class design. Does anyone have an insight? Hey, at least it's not perl, the parsing of which was recently show to require solution of the halting problem: http://www.perlmonks.org/?node_id=663393 - Stephen --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Default chapters to disabled
As long as chapters are significantly degraded, I suggest that they be turned off by default. Specifically, in the system installed leoSettings.leo file under @settings: @bool use_chapters = False @bool use_chapter_tabs = False - Stephen --~--~-~--~~~---~--~~ 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: Coming in Leo 4.7: all clones are the same node
Currently, when one clones an expanded node, the cloned node is shown as unexpanded; thus expanded/unexpanded is an attribute that may be distinct between clones. There are likely others, though I'm not aware that I use them (perhaps an internal optimization that tracks parents?); I think I remember that the cleo plugin also kept data that might differ between otherwise identical clones. It would be fine with me if cloning a node had the side effect of setting it unexpanded; setting it to expanded would almost always be too visually cluttered. I assume it would have no effect on the expanded/unexpanded attribute of child nodes. I could easily be wrong about cleo, which I toyed with but haven't used seriously. If anyone reading this has a plugin that cares about this, I advise you join the conversation now :-). - Stephen On Jul 6, 1:14 pm, Edward K. Ream edream...@gmail.com wrote: On Jul 6, 11:56 am, Edward K. Ream edream...@gmail.com wrote: It is looking like very few changes will be needed to make the one- node scheme work: In particular, the all-important p.moveToX methods should remain unchanged. A subtle point has just now become clear to me: the p.moveToX methods (the foundation of all Leo's iterators) would have to be revised extensively to work in the graph world. But as I have said before, Leo's core is probably never going to support the general graph world, so there is no need to try to reinterpret what, say, threadNext means in the graph world. With this caveat in place, the work to be done should be straightforward. Edward P.S. The reinterpretation of p.moveToThreadNext for the general graph world would be non-trivial. For example, every test of the threadNext code would have to be expanded to test whether a link has already been followed. Equivalently, methods like p.hasNext() would have to test whether p.next() has already been visited (in a particular generation). The new code would be tricky to get exactly right, so it's good there is no need for it. EKR --~--~-~--~~~---~--~~ 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: vim.py works on Linux + qt
I had set vim_exe and vim_cmd in a file a long time ago and then didn't pursue the feature. Today I was confused by having in $HOME/.leo/myLeoSettings.leo @string vim_exe = /usr/bin/gvim @string vim_cmd = /usr/bin/gvim --server LEO @enabled_plugins open_with.py vim.py ...following the example in leoSettings.leo. However, the Help menu Print settings showed: [F] vimcmd = /usr/bin/vim [F] vimexe = /usr/bin/vim Now that I understand it, I see that print settings was trying to help me by noting that those settings had been specified in the immediate file [F] whereas other settings were modified in $HOME/.leo/ myLeoSettings.leo [M] Please change Print settings so that it displays the underscores in the setting names - or, if underscores in setting names are ignored, please mention that prominently in the User Guide chapter Customizing Leo, and also perhaps in leoSettings.leo, where the only mention of name transformation appears to be in About this file--Note about canonicalized names: When looking at @x, Leo converts to lower case and removes minus signs. Therefore, @if-platform and @ifPlatformare equivalent to @ifplatform. (yup, there's a space could be added). - Stephen On Jul 2, 2:23 pm, Ville M. Vainio vivai...@gmail.com wrote: On Thu, Jul 2, 2009 at 8:34 PM, Ville M. Vainiovivai...@gmail.com wrote: It works by enabling vim.py and double-clicking on the icon. The biggest difference to current Edit in gvim from rclick menu is that it reuses the same gvim process/window. As a slight bonus, I added vim-open command for this, to enable binding to a key. Double clicking is annoying in Qt (it activates higlights the headline text as well) -- Ville M. Vainiohttp://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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: vim.py works on Linux + qt
I've just noticed that when I put open_with.py (regardless of the presence of vim.py) that the script button button, and all other buttons defined in an outline, are no long present on the line that contains the (single valued) chapter selection. - Stephen On Jul 2, 8:57 pm, thyrsus sschae...@acm.org wrote: I had set vim_exe and vim_cmd in a file a long time ago and then didn't pursue the feature. Today I was confused by having in $HOME/.leo/myLeoSettings.leo @string vim_exe = /usr/bin/gvim @string vim_cmd = /usr/bin/gvim --server LEO @enabled_plugins open_with.py vim.py ...following the example in leoSettings.leo. However, the Help menu Print settings showed: [F] vimcmd = /usr/bin/vim [F] vimexe = /usr/bin/vim Now that I understand it, I see that print settings was trying to help me by noting that those settings had been specified in the immediate file [F] whereas other settings were modified in $HOME/.leo/ myLeoSettings.leo [M] Please change Print settings so that it displays the underscores in the setting names - or, if underscores in setting names are ignored, please mention that prominently in the User Guide chapter Customizing Leo, and also perhaps in leoSettings.leo, where the only mention of name transformation appears to be in About this file--Note about canonicalized names: When looking at @x, Leo converts to lower case and removes minus signs. Therefore, @if-platform and @ifPlatformare equivalent to @ifplatform. (yup, there's a space could be added). - Stephen On Jul 2, 2:23 pm, Ville M. Vainio vivai...@gmail.com wrote: On Thu, Jul 2, 2009 at 8:34 PM, Ville M. Vainiovivai...@gmail.com wrote: It works by enabling vim.py and double-clicking on the icon. The biggest difference to current Edit in gvim from rclick menu is that it reuses the same gvim process/window. As a slight bonus, I added vim-open command for this, to enable binding to a key. Double clicking is annoying in Qt (it activates higlights the headline text as well) -- Ville M. Vainiohttp://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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: RC1 observations
The Find tab contains selectors for Find options, so if the default isn't what you want, the mouse is sorely tempting - so much so, I don't know how to change the options from the minibuffer. If you're not supposed to change the patterns in the FInd panel, then perhaps the find and replace fields should be read only. Otherwise, if one does type in those fields, it would be nice for the Ctrl-f and Ctrl- shift-r keys to be bound (they work after selecting the Find tab, but not after typing in Find or Change fields). In general, the key binding within the Find tab could use enhancement in both GUIs - some Alt sequences work within the panel, some go to the top menu, others ? For newbies, it would be nice to mention the control sequences for search/replace within the find panel, in addition to it actually working (the bindings do work so long as you don't move focus to the Find/Change fields). As a further wishlist item, if I use the mouse to put focus in the minibuffer and there is not already a full-command: being prompted for (e.g., status is Insert State), I'd like it to be the same as typing Alt-x - by which I mean prompting for a full-command, not toggling the Regexp checkbox ;-). I haven't exhaustively tested the claims above in both GUIs, so they may be more accurate in one or the other. - Stephen On Jul 1, 12:38 pm, Edward K. Ream edream...@gmail.com wrote: On Wed, Jul 1, 2009 at 9:40 AM, tfer tfethers...@aol.com wrote: It's probably just because I haven't wrapped my head around Leo's way of doing search, but Find, or just clicking the Find tab leaves you with no obvious why of executing the search you set up there, I mean there is no OK or Start Search button in the pane to press. This seems like a big disconnect from user expectations. Don't use the mouse! Ctrl-F type pattern return does a find. Ctrl-F search pattern ctrl-shift-r replace pattern does a find/replace. Alt-ctrl keys toggle the find checkboxes. The search tab is for feedback only. 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: @shadow and what should I put under version control
I do a good bit of clones getting expanded into multiple locations, and it works well for me. Important things to remember: * If you're using @thin, it means the .leo file is thin, and the derived file is fat. * If you've got nodes cloned into multiple @thin or @file locations, and their contents gets changed outside of Leo, then the last version encountered during the reading of the derived files wins. * If the sentinels are damaged outside of Leo, Leo can sometimes get confused -- more often with @file than with @thin. * Unless your versioning system is extremely short of disk space, tell your versioning system that the .leo file is a binary. Trying to do reconciliations between XML files is close to impossible except in the very most trivial cases. I've only done it successfully twice; you're almost always better off abandoning your changes, checking out from a known coherent version, and redoing the work from there. Good luck, - Stephen On Jun 22, 8:32 pm, Lucas Thode ljth...@gmail.com wrote: On Mon, Jun 22, 2009 at 1:01 PM, Edward K. Ream edream...@gmail.com wrote: quote snipped The .leo file differs from simple project files of various IDEs in that it can have valuable content that's not trivially derived from anywhere else. You may want to have it in version control outside you normal development tree, but it's still handy to have it somewhere. True, but this is not recommended. I recommend the approach discussed at: http://webpages.charter.net/edreamleo/FAQ.html#how-should-i-use-leo-w... where most information is in @thin trees and the reference .leo file changes only when new @thin nodes are added. Edward What do you do about nodes and structure that is shared among multiple @thin trees in that scenario? Also, what about things that should be kept with the code, but are not part of the code itself? (Leo's clones provide a nice facility for associating code and high-level documentation such as business requirements.) --Lucas --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
UNL plugin tweak
@file, @shadow, etc., in the absence of an @path declaration in the parent nodes, treat relative file names as relative to the directory containing the .leo file. I've just changed the UNL plugin so that for (only) file: type @url nodes, it does the same, instead of treating the path as relative to the directory in which the leo process was executed (current working directory) which can be completely different from one invocation to the next. For example, a leo file bar.leo containing a node @url quux.leo, and leo invoked as: cd $HOME leo foo/bar.leo would previously have referred to the file $HOME/quux.leo, whereas cd $HOME/baz leo ../foo/bar.leo would previously have referred to $HOME/baz/quux.leo. Now that the relative path is relative to the leo file, the name unambiguously refers to $HOME/foo/quux.leo Someone with energy (or the insight to make it trivial) should probably also implement @path directive interpretation for the UNL plugin. Qt folks: there's a comment in the UNL plugin code about something being Tk only; if that's true, I didn't touch it, and it may or may not be a problem. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Linux install fix; debian and windows maintainers please note.
I've just pushed to trunk a dummy (empty) leo/ config/.leoSettings.leo_db so that the empty directory /usr/local/lib/ leo/config/.leoSettings.leo_db will get created by the install script. /usr/local/lib/leo/config/.leoSettings.leo_db appears to be a place where site configurations might be kept. Because it is used by everyone on the system, it is appropriately owned by root and unwritable by everyone else, as is the rest of the application code. Non-root users cannot change anything within /usr/local, so leo died when the directory wasn't there. I haven't looked at the code, but I very much hope that there is an analog using $HOME/.leo/something_db for individuals. I'm completely ignorant of Debian install procedures. Would someone who understands those please do whatever is necessary to allow a fresh install to work. I'm also ignorant of Windows installation. I suspect (though I don't know) that there are different procedures for installing for individual use and installing for multiuser use; a multiuser install will need to create the read only directory. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
ruby scanner
Is there someone not preoccupied with bug fixing who could give me a
conceptual guide to class baseScannerClass in leoImport.py? I've got
a bunch of ruby code to study, and I've got python envy - I'd like all
the ruby classes and methods in their own nodes. All several thousand
of them.
Ruby has blocks delimited with '{' and '}', but it also has a bunch of
control structures that go
begin
lots of other stuff
end
if condition
and who knows what
end
def function_name
stuff
end
while condition
yup, stuff
end
# but we can't just look for an end for every while, since
brief stuff while condition
# ...means that if while occurs while we're building an expression,
the
# implicit block precedes the while, and there is no end
# same for if:
short stuff if condition
class class_name
def method_name
stuff
end
end
The other main challenge is dealing with strings, which come in the
multiform varieties similar to perl:
this is a string expression\n
concat#{foobar}
'concat#{foobar}'
%q!I said, You said, 'She said it.'!
%!I said, You said, 'She said it.'!
%Q('This is it.'\n)
`date`
%x{ date }
print END_OF_STRING
this is an example string
class foo
fun bar
no, this isn't a class, it's still the string
end
end
# yup, still a string
END_OF_STRING
# *that* was the end of the string
regexes are also perlish. Comments should be relatively easy:
# this is a comment line
=begin
everything between a line beginning with `=begin' and
that ends with `=end' at the beginning of the line will be skipped by
the interpreter.
=end
--~--~-~--~~~---~--~~
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: Leo's wiki appears to be down
I just submitted a bug report to zwiki.org concerning leo.zwiki.org. In the meanwhile, I have some fixes to WriteAjax.leo. It now: * renders more than one topmost sibling * copes with unicode characters * result now works with Internet Explorer If leo.zwiki.org doesn't get fixed, where would you like the file? - Stephen --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
c.undoer.{before,after}ChangeGroup
I'm trying to use c.beforeChangeGroup and c.afterChangeGroup in a button script, and, although undoType shows up in the Edit menu as undoable, attempting to undo does nothing except put the string undo 0 instances in the log screen. My code is: undoType=DocumentAHost c.undoer.beforeChangeGroup(c.currentPosition(),undoType) try: search for and clone a some nodes as children under a new node finally: c.undoer.afterChangeGroup(c.currentPosition(),undoType) --~--~-~--~~~---~--~~ 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: Impossible error
Effectively making destroyAllObjects defined as return fixed it. Do you want that on the trunk? Together or separately with the @verbatim directive which I hope to have working today? - Stephen On Nov 12, 3:53 am, Edward K. Ream [EMAIL PROTECTED] wrote: On Wed, Nov 12, 2008 at 1:31 AM, thyrsus [EMAIL PROTECTED] wrote: But then I try to exit leo, and I get [snip] AttributeError: 'vnode' object has no attribute 't' Leo calls frame.destroySelf during shutdown, and this method calls frame.destroyAllObjects, which in turn calls g.clearAllIvars for various objects. So during shutdown attributes can go away. Try making frame.destroyAllObjects (or g.clearAllIvars) a do-nothing and see if the problem disappears. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
