UPDATE:
-
dynamic updater : there was a super huge hole in my previous updater. I hadn’t thought about it earlier. It’s the old instances replacement. The way I recreated the new instances was simply by generally call realClass(). Of course, that doesn’t work for a class which receives init arguments, which is mostly the way you need it.
So, how if I want to rebind such a class (say class B) ? I must find its host class instances (say class A), and crush them and recreate them, so all class B instances will be created correctly and treated naturally afterward by class A instances. But how if those class A instances are part of a larger environment, which is part of another larger one ? I have to do exactly the same thing for them.
At the end, I might need to crush the whole World class instance and recreate it anyway. So, yes that’s what I do now, directly crush World instance and recreate it everytime after any rebind process. The major inconvenience of that is the whole thing get restarted from the very beginning. -
dynamic updater : if there is an error in a class during instantiation after rebind, and before that erroneous point, you have attached some nodes to scenegraph, registered some events, etc, they used to get left over, alive and don’t get rolled back. It means, the next time you update the scene, you’d get another set of duplicates, models, events, lights, and everything instantiated before the broken line. So the scene would look and behave just like hell, or trash bin, sooooo ugly.
It’s because the broken class instance doesn’t get crushed. Previously, I hadn’t figured out how to crush it, since the broken class instance isn’t saved in the caller’s locals, but only in the broken class’ locals.
But I have found a way to crush it, by tracking the real error until the end of tracebacks chain, saving it in the caller class instance, so it can be removed altogether. So there should not be any artifact left anymore during rebind-restart process.
To demonstrate this, uncomment this line in dyn1.py :
[color=darkred]# self.brokenInstance=BrokenClass()
and update it (press F9).
You should never see the teapot created before messItUp() call in BrokenClass. What would happen is, the instance of World class, which is responsible for creating BrokenClass instance, will be crushed altogether after saving BrokenClass instance temporarily as its attribute, to ensure safety, in case the expected BrokenClass instance is used in other part of it.
-
code completion is available, works for live objects (everything exists in builtins), all imported modules, Python keywords, and class instance attributes (the last part is still experimental and not usable yet).
Works as you type, with stop-typing-threshold .3 second.
It’s enabled by default, press F4 to toggle.
Press Ctrl-Space to force it to show up if you’re not typing but want to know more about the code your cursor is on.
Use ArrowUp/Down, PageUp/Down, and Home/End to navigate through the list.
Press F1 to toggle the description when highlighting the available code.
Use Ctrl-arrow up/down to navigate through the description.
Press Enter to use the highlighted code.
Press Esc to cancel.
The performance to render the available codes list is poor, since I use my own text builder, which is not optimized for fast render, it’s geared towards quick show, so the faster it’s generated, the better. For 422 list items, DirectButton takes 3 seconds, plus additional 1 mysterious second. DirectLabel takes 2.3 seconds. Then I decided to use my own text builder, as for the script’s text, since I don’t need any cosmetics part. The result is it takes only 0.15 second for the same 422 items. In the future, I might use RTT too for it, just like what I do for the code description, which uses 3 pages cameras.
-
before I released this in the 1st place, I dropped pixel-perfect text rendering for a funny reason. Somehow, some letter’s vertical edge or corner vanished. I thought that was due to “nearest” texture filter. But recently I found out that it was due to something completely different, it’s the side effect of flattenStrong(). Somehow, some overlapping vertices of adjacent letters get welded, or its texcoord loses precission or so, I don’t know exactly. The good news is it’s easy to solve, only by enlarging each letter’s quad to avoid overlapping vertices. See if it’s better.
