Re: leoInspect: a hobby with a future?
On Nov 17, 10:26 am, Edward K. Ream edream...@gmail.com wrote: I expect to spend at least the rest of today on format and the AstFormatter class. It was an interesting day, not least because the Fool (capitalized, the skeptical part of me) kept screaming at me. leoInspect is so elegant, I started doubting it! As an antidote, and as a way to honor the skeptical part of me, here is a dialog between the Fool and the excited part of me: Fool: Why all the excitement? All you've done is made a trivial front end for ASTs! Me: The front end is important, for several reasons. First, it provides a way to examine *dead* code more easily than Python's inspect module allows you to examine *live* code. It is also a spectacular collapse in code complexity. Fool: Of *course* it's a collapse in complexity, you've *given up* trying to do a proper lint! What did you expect? Me: Actually, almost all the code is unchanged! Only my *understanding* has changed. Giving up just means that a few algorithms are no longer part of leoInspect itself. Fool: Let's get back to the interface. The getters just deliver ASTs. That's no big deal. Me: Getters deliver Context objects, not ASTs. User query code quite naturally starts with a call to the module getter:: m = leoInspect.module(fn=path to a file) # For users. m = leoInspect.module(s=s) # For testing leoInspect itself. The module getter preprocesses all the code, creating semantic information (Context objects) that speed up and enrich all future getters. **leoInspect adds rich data structures to ASTs**. Fool: How useful can these data structures be? They cost almost nothing to make: there is no such thing as a free lunch. Me: That's my second point. As far as the users of leoInspect are concerned, Context classes *are* query objects. The leoInspect API shows that this change in point of view is a huge advance for users. Fool: Well, what about you? You wasted all day yesterday writing the AstFormatter class, yet another AST-to-Python converter. You haven't done your homework: 2to3lib already has such a thing. Me: Yes, 2to3lib already has something similar. But it doesn't fit in with leoInspect's Context or AstTraverser classes. AstFormatter is essential. Fool: AstFormatter is always going to be buggy. Me: Writing unit tests for AstFormatter will be easy. AstFormatter doesn't need to preserve whitespace exactly. The only requirement is that the *tokenized* version of the input must be equivalent to the *tokenized* version of leoInspect.module(s=s).format(). The new g.python_tokenizer function will suffice as a tokenizer. Fool: Well, writing AstFormatter was a big distraction. Me: Not really. It has given me a chance to look again at the old LintTraverser class, now called InspectTraverser. I used InspectTraverser as a reference while writing AstFormatter. In the process I found some horrible code, namely InspectTraverser.attribute_to_string. This is a wretched hack, supposedly for the benefit of the symbol table classes. It can't possibly be correct. The new code will simply use the AST to represent itself. Fool: Using ASTs to represent themselves? That's a step backwards! It makes the code harder to use. Me: No, it doesn't, because the getters don't get more complex. Yes, the assign_to and assign_using getters must do some work, but that work hides all the AST-related blah-blah-blah from the user. If other getters are needed to hide AST details, I'll put them in. Fool: Maybe the getters will be useful for the naive user, but they will never be good enough to implement a real lint. Me: Wrong, on two counts. First, *I* will be a naive user when it comes to writing unit tests based on leoInspect. I want a dead-simple interface in which to build up significant assertions about Leo's own code base. Second, the o.tree() getter provides a fast trap door to any part of the AST. The leoInspect API *can* be used as the basis for a new lint. Actually, the old sudoku-like (data-driven) lint algorithm could use the underlying Context classes as before. The new leoInspect API doesn't hide the old API. Fool: But you are going to gut attribute_to_string. Isn't that going to ruin some old code? Me: Now you're nit-picking. InspectTraverser.attribute_to_string will be sound, which is kinda important for a lint! Fool: But you are going to waste even more time revising InspectTraverser. Me: It's never a waste of time to put code on sound foundation. And the big collapse in complexity creates further opportunities for simplifications. Don't even *think* about complaining about that. Furthermore, the run-marked-unit-tests-externally command has amplified the Stupendous Aha. As a result, I seem to have gotten smarter--I find even more ways to collapse complexity. This happened several times yesterday, and I expect to simplify InspectTraverser even more today. All the great mathematicians revisit their old proofs, seeking
Re: leoInspect: a hobby with a future?
On Nov 18, 2:35 am, Edward K. Ream edream...@gmail.com wrote: Me: Time to get back to work on leoInspect! Actually, it's time for sleep. I'm a bit short due to the excitement of the leoInspect project. 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.
bug: shell interprets characters in at-mime headings
on linux, parenthesis or angled brackets in @mime headings prevent the file from being opened, probably because they are interpreted specially by the shell, e.g. they need to be escaped. Such characters should be escaped before passing the filename to the shell. -- 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.
at-mime and at-url
There is some overlap in functionality between @mime and @url, when it comes to local files. Although it seems @url can under some circumstances also open local files with the associated program, @mime certainly does a more consistent job, particularly with relative path names. One big difference is that @url is active also in the body, while @mime only works in the header. This may even make sense, because it may be difficult to determine the end of a filename in body text, particulary when the filename contains blanks. I would be in favor of making @mime a default package. It may even be possible to merge them into a unified @url, but because of the reasons just stated, that may not be desirable after all. - Josef -- 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.
global buttons don't work in recent version of 4.9.1
buttons defined under @buttons in myLeoSettings.leo do not seem to work any more, while local buttons still work. Is this change intentional? - Josef -- 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: leoInspect: a hobby with a future?
On Fri, Nov 18, 2011 at 2:35 AM, Edward K. Ream edream...@gmail.com wrote: leoInspect is so elegant, I started doubting it! The quick summary of leoInspect: 1. leoInspect inspects text; Python's inspect module inspects live objects. 2. leoInspect is much easier to use than inspect, and more scriptable. 3. Most importantly, leoInspect is a view of **symbol tables**, not ASTs. These symbol tables are designed to answer important, practical questions about source code, including Leo's sources. 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: File 'Open' or 'Import File' command to follow @path directive
not only would I vote for this, but in addition, the generated path should be *relative* to the path in the @path directive, not absolute. E.g. use os.path.relpath(path[, start]) where start is the path specified by the (cascaded) @path directive. That allows Leo files to be moved together with the files it is pointing to, without having to rewrite all the filename paths, and is the only way to for collaboration with others. Only in rare occations one would actually prefer an absolute path, so we would need open-relative and open-absolute versions. When dragging files this might be achieved by left-click-dragging versus middleclick- dragging or ctrl-dragging. - Josef On Nov 16, 4:30 pm, Terry Brown terry_n_br...@yahoo.com wrote: On Tue, 15 Nov 2011 19:31:20 -0800 (PST) Largo84 larg...@gmail.com wrote: Is there a setting that would cause the 'FileOpen' or 'FileImport File' commands to begin the search dialog in the directory, E: \Documents\Some Folder\ instead of the last directory used? Would others find this a useful feature? I vote for that being default behavior, not sure a setting is necessary. 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-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: Big improvements to external unit tests
On Nov 15, 9:31 am, Edward K. Ream edream...@gmail.com wrote: I plan no further improvements to Leo's unit test infrastructure. All the tiny grains have grit have been removed from the gears. Rev 4822 removes two more pieces of grit: 1. *Any* of the run-x-unit-test commands will execute the *selected* @test or @suite node, regardless of whether an ancestor node is an @ignore node, and regardless of whether the node is marked or not. Doh! 2. Alt-4 is now bound to run-selected-unit-tests-externally in leoSettings.leo. This is the new standard I use everywhere. Change your myLeoSettings.leo files as appropriate if you dislike this binding. 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.
Terry, please check todo.py
The cycle-all-focus command crashed in todo.py, and I thought the best way to fix it would be to add dummy support for the HighLevelInterface to cleoQtUI. Terry, please check to make sure that todo.py is working as you expect. Thanks. 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: Terry, please check todo.py
On Fri, Nov 18, 2011 at 11:28 AM, Edward K. Ream edream...@gmail.com wrote: The cycle-all-focus command crashed in todo.py, and I thought the best way to fix it would be to add dummy support for the HighLevelInterface to cleoQtUI. Oops. The problem was somewhere else completely. I've removed the new code, but changes remain. Sorry for the interference. 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: Exceptions in doCommand
On Thu, Nov 17, 2011 at 11:01 AM, Morgul jmfo1...@gmail.com wrote: Hello. I'm using the latest bzr snapshot, and I get the following error when I open a new editor (using add-editor in the minibuffer), select some text in the newly open editor, and press the backspace key: [snip] File D:\Jose\Archivos de programa\Leo\leo\core\leoFrame.py, line 100, in getSelectionRange def getSelectionRange (self): return self.widget.getSelectionRange() AttributeError: 'NoneType' object has no attribute 'getSelectionRange' Thanks for this report. This bug has been fixed at rev 4830, with a new unit test. It was due to a recent botch, not caught by unit tests. 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: How to re-assign a key binding
Kent, The post I wrote yesterday was probably not relevant to your question. Apparently, setting a key binding in a plugin is significantly different from setting a key binding in leoSettings.leo. I wrote yesterday focused on re-assigning a key binding made in a plugin. As I wrote yesterday, so far as I know it is impossible to re-assign a key binding that is set by a plugin. Attempts to do so in myLeoSettings fail with error messages. Judging from your question, a key binding made in leoSettings.leo can NOT be re-assigned by an @key statement in a plugin. But I have not verified this. But it is possible to re-assign key bindings that are done in leoSettings.leo. Just put the re-assignment in myLeoettings.leo and it works without any warnings or error messages. But to the best of my knowledge this does not help you, Kent. The problem with Alt+W is that it is the shortcut for the Windows menu. You can replace the assignment of Alt+W that is in leoSettings.leo, but that does you no good---unless there is some way I don't know to turn off the menu shortcuts. That is, when I assign Alt+W in my myLeoSettings.leo, Alt+W still just opens the Windows menu. This makes me wonder if the assignment in leoSettings.leo of Alt+W to propogate-key-event was ever effective or useful? -- 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.
Checking Leo's properties: present and (near!) future
The recent problems with crashes in the log pane were due to a complete botch when I created the logCtrl (and bodyCtrl) properties: the properties both got the name b rather than the intended names. A proper unit test would have caught that mistake. Indeed, a proper unit test would have been the development scaffold for creating these properties, but I created the code a few days ago when I wasn't using unit tests for *everything*. Anyway, once I discovered the cause of the bug I wanted to come up with a proper unit test that would demonstrate that the bug is gone. It took awhile. Afaik, there is no obvious test to tell whether a symbol 'x' is a property. I discovered a clean enough test after my workout this afternoon. Here is the unit test for logCtrl, on the trunk at rev 4831:: # Test that changing c.frame.log.logCtrl changes c.frame.log.widget. log = c.frame.log old_w = log.widget assert old_w is not None try: log.logCtrl = None assert log.widget is None finally: log.widget = old_w This is an indirect test that logCtrl isn't a normal ivar: changing it also changes log.widget. That should be good enough to prove that logCtrl is a property with the expected effect. However, there is another test that I would like to create, and it may become the first real use of the leoInspect module. The real intention of the logCtrl property is that there be *no* assignment to logCtrl anywhere in Leo. That is, log.logCtrl is basically a macro that expands to log.widget. All assignment happen to log.widget, not log.logCtrl. This is a perfect prototype for leoInspect inferences. It is a simple *textual* property that reflects how I created and understand the code. Verifying this property should be easy using leoInspect, and difficult or impossible using any other tool. In short, while I am far from happy about the logCtrl blunder, it has had the happy side effect of suggesting the first unit test based on leoInspect. I hope to have the test ready in a day or so. 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: Checking Leo's properties: present and (near!) future
On Nov 18, 7:09 pm, Edward K. Ream edream...@gmail.com wrote: The real intention of the logCtrl property is that there be *no* assignment to logCtrl anywhere in Leo...This is a perfect prototype for leoInspect inferences. As stated earlier today, the real power of leoInspect will come from the behind-the-scenes symbol tables built at startup by the module getter. I'll be tweaking these symbol tables to support assertions such as, there are no assignments to logCtrl exist anywhere in Leo. 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.
