On 3/5/07, SPE Stani's Python Editor <[EMAIL PROTECTED]> wrote:
On 3/5/07, Josiah Carlson <[EMAIL PROTECTED]> wrote: > On 3/5/07, SPE Stani's Python Editor <[EMAIL PROTECTED]> wrote: > > Realtime updating is also which belongs to the generic part. Therefore > > we need to be able to diffs between a previous state and a current > > state and to add a property expanded (True/False) to the nodes. Again > > if we implement this in a generic way, we get everything for free for > > all languages. > > I actually implemented a variant of 'diff in place' method for trees after > seeing yours. It doesn't handle renames very well (it ends up recreating > the subtree of a named node), but it seemed to speed up the tree > manipulations that PyPE was doing. I need to release a new version of PyPE > soon, so I'll let everyone know where the code can be found when it is > available. Interesting. Is it not somewhere in cvs or subversion?
I use a local subversion respository via TortoiseSVN, but it's not available generally. I thought my
process could be optimized as you do not need to 'diff in place' for nodes or create subtrees, only when they are expanded. Does your implementation have this 'lazy diff in place'? For doing diffs I was also wondering maybe to provide the tree and nodes with a __str__ method so you can use the diff functionality from the standard diff in the hope that is well written, optimized code.
No, it updates the entire tree. For reference, it is able to update the tree for the currently 5600 line pype.py in .2 seconds on my machine. I honestly don't believe that dynamic rebuild time will be a serious issue.
> Another thing is that fold explorer will be a good tool for what I > I have considered local code blocks, but I don't believe that they are > really all that practical. You end up needing to update line numbers for > all later code blocks anyways, so you may as well just do the entire thing. For syntax errors I still do think it is possible in the following way. Ask scintilla the first and last visible line. Than we need to find the top line equal or above the first line and the bottom line equal or below the last line. If the first line is an except statement we need to go up till the try statement, otherwise we can just use the first visible line. What concerns the last line, we need to go down to the first not folding node, again with the exception that every try statement has to be closed. This is not tested and probably it has to be corrected but maybe it should work.
That's all well and good, and I suppose it could be made to work for those times when you want *immediate* notification; but I've honestly had good luck with a delayed check syntax mechanism. I find that when I'm programming, I usually come to a natural pause where I need to think through something, and the delayed syntax checking offers precisely what I need, more or less when I need it. As for class explorers the task is more difficult indeed. I am just
wondering if there are more hidden treasures in Scintilla for notifications and identifying changes. I need to study this more.
The documentation is my secret stash of information ;). As an aside, one of the problems with using the STC-embedded fold flags, etc., is that it's not quite as easy to extract information and do the "parsing" in the background (in a thread, etc.) - the data is in a GUI widget, whose access methods must be called from the GUI thread. Even if this method were as fast as a line-based parser, there would still be delays in the parsing, in addition to the (required) delays in the tree update. Maybe it is crazy idea, but we could also invent a new way of dealing
with source editing: - first we load the whole document so that scintilla can parse it - than if a user (right) clicks on a tree item, it *only* displays that code. If you want to have more overview, you click a higher node etc... - every time a user (right) clicks a node the editor substitutes the new code with the previous selection between start and end
That sounds a lot like the Code Browser editor: http://code-browser.sourceforge.net/ . There are certainly good ideas embedded in the project. - why?
- sometimes it is nicer to work more zoomed in and you still have the overview if you click on the root node which can be called 'whole document' - if the selection exceeds a certain number of lines (user preference) realtime features are turned off (or switch to threading)
There isn't really any good reason not to use threading all the time. Stick with Queue to send information to the worker thread, and use wx.CallAfter or wx.PostEvent to get data back to the main thread. Alternatively, consider using the DelayedResult module available in recent wxPythons. I would prefer to have a not-threading alternative. For example you
can not run SPE in Blender with threads. For compiling/syntax errors you need only a few lines of output (error label, line number, etc..), so it could also be done with a subprocess as most cpus become multi-core and threading is only single-core.
So that's why you are hesitant to use threads. Though it's only marginally related to the topic, is it documented somewhere why threads + blender + external editor doesn't work?
