Great post, Richard! Best,
Jerry Daniels Join the Rodeo discussion: http://rodeoapps.com/discuss-among-yourselves-0 On Jul 26, 2010, at 10:11 AM, Richard Gaskin <[email protected]> wrote: > Richmond wrote: > >> On 07/26/2010 02:25 PM, Richard Gaskin wrote: >> >> <snip> >>> then mine, >> >>> <snip> >>> -- >>> Richard Gaskin >> >> Boy, I must have been asleep; do tell as would love to try it. > > Your quote was trimmed a bit too short to determine what you were referring > to, so I had to go back to the original message and search for "then mine," > to find this: > > In Rev, any IDE is merely a collection of stacks that runs > on top of the engine. The first IDE for this engine was > MetaCard, then FreeGUI, then Rev, then mine, then Jerry's, > and there may be others. All just stacks - you can write > your own too if you're so inclined; it can be kinda fun. > > What follows is a bit of a rant on complexity, which the reader is encouraged > to ignore if they have anything better to do (I try to keep my off-topic > comments here to a minimum, and save 'em up for one long post <g>): > > > When I first started working with MetaCard in '97, I did what I tend to do > with any new xTalk I pick up: I made tools for it. > > I had started Fourth World on 4/4/94 publishing tools for SuperCard, and did > rather well with SC for many years, sorta the Heizer of the SC world (and for > Heizer too; we had a page in their catalog). But when SC didn't make it to > Windows during the same period Apple posted two years of annual losses, my > clients were scrambling for a cross-platform solution. As much as I liked > Toolbook, maintaining two code bases in SC and TB wasn't going to be > cost-effective, so we started migrating work to MC. > > Making tools for MC was almost a necessity, spartan as that IDE was. These > tools kept growing, and by the time Rev was born in 2000 I was already > spending relatively little time with MC's UI, using mostly my own stuff > within its framework. > > The first commercial add-on for Rev was devolution, a packaging of some of > those tools, released long before Rev even had RevSelect. More of a > collection of utilities than a complete IDE, it was a starting point which > has been in continual development ever since. The publicly-available version > is quite old; between the need to rethink the updater and being busy with an > abundance of interesting client work, the public version has fallen quite > behind the current tool set. > > Today devolution includes a much broader range of stuff, from a > Macromedia-inspired inspector to a standalone builder, and its MetaCard-bound > history is nearly completely severed. Once the last dependencies on MC have > been purged from its framework, I'll use the new RIP Updater tool I've been > working on to release it; extra bonus points that the RIP Updater will work > with all RIP-savvy tools (for more on RIP see the Rev Interoperability > Project at <http://tech.groups.yahoo.com/group/revInterop/>). > > When devo2 is released it'll speak for itself, so there's no need to spend > much time on it here. Some may like it, some won't, and that's okay. I made > it for me and my clients, and will be sharing it as-is in case others find it > useful. > > I will however indulge in describing one small part of devo2: the debugger, > which I'm working on now with some help from Ken Ray. > > > At the heart of devolution is my xTalk mantra: > > Know the engine. > Trust the engine. > Use the engine. > > We all use any variety of scripted tools on top of the engine, but the engine > itself is the one thing we all use, and the only part of the Rev experience > our customers use. So the engine is unusually well tested, having been > through more gauntlets than any IDE can be. It's the engine that binds this > community, the well from which we all drink. > > The engine employs a certain logic to how it deals with things, and I believe > it benefits a toolmaker to understand that logic and use with-the-grain > solutions whenever possible. > > For example, stacks appear in windows and have a "style" property to govern > the window's mode. So if you're making plugins you could just use that > property, and the engine can take care of rendering the window as palette, > modeless, or whatever you've set its style to. > > The Rev IDE, however, added a custom property to mirror this natural > behavior, the cRevLoadInfo["mode"] property. I can't claim to understand why > this was used instead of the built-in property already available, but as you > poke around in Rev you'll find other similar things in which the IDE adds > additional layers on top of things the engine already does quite well. > > Debugging in Rev takes a similar tack. > > Historically, most Rev scripting environments use the same window for both > editing and debugging, but the two are very different tasks. > > Writing scripts and tracing their execution are almost opposite tasks in many > respects, with the only thing they have in common being a need to display a > script in a field. > > Somehow even MC was seduced by this lone commonality into thinking that this > meant the best way to serve both of those very different tasks was in a > single window. > > But because the nature of the tasks are so different, if you read through the > scripts of both the MC and Rev editors you'll find a fair amount of branching > code which the stack uses to alter its appearance and behavior depending on > whether you're scripting or debugging. > > The tools and controls you need for writing scripts are very different from > what you need to simply trace through them. This means a LOT of additional > code is needed if you use one layout for both tasks, for both handling the > switching and for making sure the scripting stuff isn't available when > tracing. > > In a word, complexity. > > In 1976, Thomas J. McCabe, Sr. came up with an algorithm for measuring > complexity in code which is as surprisingly simple as it is > language-independent: count the decision points. He called this algo > Cyclomatic Complexity, and FWIW I have a Rev-specific version which will be > available along with some other code analysis tools in RevCloud later this > summer, but that's another story. > > For the moment just consider what McCabe realized: a straight sequence of > statements only has one possible outcome, and it either works or it doesn't > and you'll know it straight away when you run it. But the moment you > introduce decision points (if-then, switch-case, etc.), your program's > execution path takes on a combinatorial explosion of possibilities. This is > what McCabe measures as "complexity", and in general the more complex a code > base is the more prone it is to errors, and the more expensive it is to test, > maintain, and enhance. > > Debugging with a tool made in the very execution context it's debugging is an > inherently difficult task, rather like making a watch where the only tool you > have is another watch. It's a bit challenging to stick your fingers between > the fan blades while they're turning in order to fiddle with stuff behind > them, but it can be done if you're quick and nimble. > > But that nimbleness requires the opposite of complexity: simplicity. > > In a tool that uses its own language to debug itself, a debugger will be > reliable in inverse proportion to the number of lines of its own code it's > executing. > > If you dig into the debuggers in Rev and MC, you'll find a majority of the > code there isn't about debugging at all, but instead about maintaining the > current state of the dynamic dual-use script editor. Hence, the many issues > people have reported debugging in Rev. > > Looking at that code more deeply, we find that the engine messages involved > are few and well-defined. The only trick in using them is that you won't > have a debugger available to help you if you're using them to write a > debugger, but once you get the hang of it (and have become accustomed to > saving before each test because it's likely you'll hang when you've screwed > up <g>), there's a world of opportunity to make a much simpler way to debug > scripts. > > So in devolution there is now a debugger, implemented as a separate window > which has very few controls, no menus at all, and its scripts are ultra-tiny. > It does only one thing, debugging. And after just a day's work recently it > appears to be rather robust. Yes, it's being tested on Linux too. > > I'm working with Ken this week to hone some of its UI, and then it'll be in > the can and I can get back to finishing its companion script editor, which is > coded with a similar eye toward simplicity, unencumbered as it is without the > needlessly dual-purpose workflow. > > Extra bonus points with the debugger: if testing continues to go well, it > appears it will be possible to use it in a standalone, providing the Rev > community with its first true runtime debugger. With its integrated Variable > Watcher and Message Box, and my Flight Recorder tool for watching message > flows, you'll have the essentials you'll need to diagnose nearly any problem > right inside your compiled standalone. > > And for Rev users that's a bigger deal than it is for MC users, because among > Rev's complexities are a good many differences it introduces between > development and runtime (where are libraries stored and can you control all > of them?). Know the engine, trust the engine, use the engine. > > More on all this as it comes together. The good thing about these tools is > that I'm able to build them because I need them. But the bad thing about > them is that I need them to work on products, and always need to balance my > time between shipping code and crafting new things to ship better code > faster. Delivery timelines on tools are therefore unpredictable, contents > may settle during shipping, objects in mirror may be larger than they > appear.... > > -- > Richard Gaskin > Fourth World > Rev training and consulting: http://www.fourthworld.com > Webzine for Rev developers: http://www.revjournal.com > revJournal blog: http://revjournal.com/blog.irv > _______________________________________________ > use-revolution mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
