Re: Exceptions in recent revisions
revno 4275:
When executing script that uses c.executeMinibufferCommand
for example: c.executeMinibufferCommand('save-file')
produces the following log
NameError: global name 'stroke' is not defined
line 697: # stroke = None
* line 698: event =
g.app.gui.create_key_event(c,None,stroke,w)
line 699: k.masterCommand(event,func,stroke)
line 700: return k.funcReturn
exception executing script
revno:4284
The same script produces the following log
TypeError: masterCommand() takes at least 4 arguments (3 given)
line 718: event =
g.app.gui.create_key_event(c,None,None,None)
* line 719: k.masterCommand(event,func)
line 720: return k.funcReturn
line 721: else:
and revno: 4288 at the start up produces the following log:
Leo Log Window
Leo 4.9 beta 2, build 4265, June 4, 2011
Python 2.7.1, qt version 4.7.2
linux2
setting leoID from os.getenv('USER'): 'vitalije'
load dir: /home/vitalije/programi/leo-editor/trunk/leo/core
global config dir: /home/vitalije/programi/leo-editor/trunk/leo/config
home dir: /home/vitalije
reading settings in /home/vitalije/programi/leo-editor/trunk/leo/
config/leoSettings.leo
reading settings in /home/vitalije/programi/leo-editor/trunk/leo/
config/myLeoSettings.leo
unexpected exception in g.getScript
Traceback (most recent call last):
File /home/vitalije/programi/leo-editor/trunk/leo/core/
leoGlobals.py, line 4481, in getScript
useSentinels=useSentinels)
File /home/vitalije/programi/leo-editor/trunk/leo/core/
leoAtFile.py, line 3305, in writeFromString
c.endEditing() # Capture the current headline, but don't change
the focus!
File /home/vitalije/programi/leo-editor/trunk/leo/core/
leoCommands.py, line 7415, in endEditing
c.frame.tree.endEditLabel()
File /home/vitalije/programi/leo-editor/trunk/leo/core/
leoFrame.py, line 2289, in endEditLabel
self.onHeadChanged(p)
File /home/vitalije/programi/leo-editor/trunk/leo/core/
leoFrame.py, line 2211, in onHeadChanged
if not c.changed: c.setChanged(True)
File /home/vitalije/programi/leo-editor/trunk/leo/core/
leoCommands.py, line 7234, in setChanged
if g.app.gui.guiName().startswith('qt') and g.app.qt_use_tabs and
hasattr(c.frame,'top'):
AttributeError: 'NoneType' object has no attribute 'guiName'
I am using ubuntu 11.04
HTH
Vitalije
--
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 recent revisions
BTW, at present the menus have silently disappeared from my Linux machine! Using the latest code (4299), I still see menus on _my_ Linux machine with no problems (Python3, qtleo started from command line, ArchLinux). Could I help there somehow? KR, Radim -- 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.
Chapters work
There is a worthy bug in the Chapters-related code. It will not happen often, but when it does it could be dangerous. I can reproduce the bug and see it in action. The problem is doing something sensible. The essence of the situation is that switching chapters is very tricky: it is akin to a hoist, and indeed *part* of the switch involves saving and restoring hoist stacks. The big picture is this: *most* of Leo is blissfully unaware of chapters. For example, saving the file had better save the *entire* file!! But the drawing code, searches, and node moves must be aware of hoists. In particular, we have to be extremely careful that the positions we pass to full_redraw. One way to show the bug to create a new @chapter node. This will invalidate c.p, but it's not so easy to tell the chapter's unselect code (or harder, full_redraw) that c.p is invalid. Like I say, this is a worthy bug. Actually, this bug, as tricky as it is to fix, will be, in most cases, less important than an unrelated problem, namely that the present code relies way too much on archived data. This part of the code is going to be completely rewritten in two ways: 1. Most archived information, such as the location of @chapters and @chapter nodes, is going to be completely removed: the code will recompute these locations every time. This is essential: the user could insert or delete @chapters and @chapter nodes in the main chapter at any time. 2. The archived information that *is* essential (or at least very convenient for the user) is the selected node. We want to save this data when un-selecting a chapter, and restore it when re-selecting the chapter later. Alas, the present code is ridiculous: it saves and restores *positions*, and then does something bogus as a fallback if the position is invalid. Instead, vnodes must be saved and restored. The simplest thing that could possibly work is as follows. When unselecting a chapter, we record both V = c.p.v and N, the number of times that c.p.v is seen in the traversal from the root of the *chapter* to c.p. When restoring, we again traverse the chapter, stopping at the N'th position p with p.v = V, or the last node p with p.v or V if nodes have been deleted, or finally the root position if vnode V is not found anywhere in chapter. The point is that the user may, in the main chapter, have invalidated *all* archived information. The code must plan for that. The easiest way is not to archive anything, but as a courtesy to the user we must attempt to save and restore the user's previous working point. It is tempting to pretend that the worthy bug will magically disappear when archived data disappears, but that would be wrong, wrong, wrong. The first step, partially completed, is to discover exactly why the bug happens, and to attempt a solution in which either the bug is guaranteed never to occur, or in which simple error recovery is reasonable in all cases. I'm on 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-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: Chapters work
On Jun 8, 8:13 am, Edward K. Ream edream...@gmail.com wrote: There is a worthy bug in the Chapters-related code. Rev 4300 fixes this bug by being much more careful about selection. This rev is mostly for backup. Please do not use chapters yet for real work. I should be finished with testing today. All unit tests pass, a non-trivial statement. 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: Chapters work
On Wed, Jun 8, 2011 at 12:07 PM, Edward K. Ream edream...@gmail.com wrote: Rev 4300 fixes the [chapters-related bugs] by being much more careful about selection. The new code is also more relaxed about where @chapter nodes may reside. They are always *created* as the last child of the first @chapters node in the outline (the @chapters, plural, node is created as needed). However, you may move them while in the main chapter, with no ill effects. In fact, you could swap @chapter nodes with the same name: when you select a chapter, Leo will use (show) the first node it finds. The new code is now both more careful and more tolerant of @chapter nodes deleted by hand. The chapter will still appear in the dropdown list: if you select it you will give a polite warning. That's all. In particular, the deleted chapter will *remain* in the dropdown list until you use the proper chapter-remove command. That's about the only sane alternative: it allows you to resurrect the chapter, by hand or with an undo. This is all made possible because the new code is almost completely stateless. The only exception is the saved position used to select a node when selecting a chapter. The old position-based findPositionInChapter method was not so ridiculous after all, but it has been simplified to make it work more reliably. It first looks for a perfect match using positions, and then degrades to looking for a vnode match. In practice, most matches are, in fact, perfect. The imperfect case typically happens when the user alters nodes in @chapter trees by hand in the main chapters. To repeat: treat the code with caution for now. I'll be doing more testing later, but I thought it more important to discuss the user-centric details now before they fade away. 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: Chapters work
On Jun 8, 12:55 pm, Edward K. Ream edream...@gmail.com wrote: The new code is now both more careful and more tolerant of @chapter nodes deleted by hand. True, but it is still possible to thoroughly confuse the selection logic. I've disabled the warning: it doesn't seem to do any harm to select the root node in that case. Not best, but perhaps the best I can do. Rev 4301 contains the latest fit and finish work, as well as the first two unit tests for chapters-related code. A few more unit tests are coming. If you are interested in chapters, please start testing the trunk and report any problems immediately. 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: Chapters work
On Jun 8, 4:35 pm, Edward K. Ream edream...@gmail.com wrote: Rev 4301 contains the latest fit and finish work, as well as the first two unit tests for chapters-related code. A few more unit tests are coming. Here is the checkin log for rev 4302: QQQ Added 4 fairly strong unit tests of chapters code. This exposed some problems, which were fixed or worked around. This completes the chapters work, barring new bug reports. QQQ 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.
