Re: "Ask us anything" and the executionContexts
On 12/19/05 4:00 PM, "Dick Kriesel" <[EMAIL PROTECTED]> wrote: > Thanks for asking, Ken. My answer is neither: I'm concerned because of the > following message from Scott Raney, which leads me to think there may be > some disqualifying problem in the design or implementation of the > executionContexts. No, not at all... it's just that it was designed for debugging (that is, the debugger uses it), and not for public use. As such, it's "internal", and may be changed at any time as RunRev sees fit. So if you want to use it for now, knowing that it might be changed later on, fine. In fact, I've done so myself. And since the executionContexts have been in there for years, and AFAICR have not been changed since their original creation, they are "safe" to use, but may very likely remain undocumented because of their internal bent. HTH, Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: "Ask us anything" and the executionContexts
On 12/17/05 9:50 AM, "Ken Ray" <[EMAIL PROTECTED]> wrote: > On 12/17/05 3:14 AM, "Dick Kriesel" <[EMAIL PROTECTED]> wrote: > >> Your answer left me a hope that maybe we were just a BZ away from being able >> to use the executionContexts in a standalone, so I decided to search BZ >> before asking about that possibility. > > Dick, are you saying that you can't use executionContexts in a standalone? > Or that you need to know how to use it? Thanks for asking, Ken. My answer is neither: I'm concerned because of the following message from Scott Raney, which leads me to think there may be some disqualifying problem in the design or implementation of the executionContexts. On 05/31/03 10:54 PM, "Scott Raney" <[EMAIL PROTECTED]> wrote: > On Sat, 31 May 2003 curry wrote: > >> How about a function that returns the name of the handler that called >> the current handler? For example, this would be useful when a handler >> needs to reset each time a different handler calls it, or to keep >> track of different sets of data for each handler that calls it. > > You can get this information with the executionContexts function. I > hesitate to even mention it, however, because it was designed for > debugging purposes *only*: using it for conditional execution would > be, IMHO, heinous. Use an optional parameter instead unless you want > your status as an xTalk wizard permanently revoked. > Regards, > Scott Even though I don't have the status of xTalk wizard, that sounds pretty foreboding. -- Dick ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: "Ask us anything" and the executionContexts
Dick Kriesel wrote: Your answer left me a hope that maybe we were just a BZ away from being able to use the executionContexts in a standalone, so I decided to search BZ before asking about that possibility. The result was a surprise, so here's another question: Would you please comment on the resolutions of BZ 724 and BZ 1243? I know you're not speaking officially for RR, but you know the BZ business process pretty well. I'm afraid I don't know the answer to this. I don't do much with Bugzilla myself, except to enter an occasional bug of my own, and I don't have any more input than anyone else. When someone on the team mentioned in IM that they were planning some more bug fixes for the next release, I asked "Can I pick which ones?" and got back "LOL!" So, I guess my status isn't exactly superior. ;) Well, I wasn't being entirely serious when I asked it either. I know a little bit about the generic process though. Bugs are fixed according to a flexible process of prioritization. Crashing bugs get top priority. The number of people who are likely using a buggy feature also influences priority. The number of votes a bug has influences it some too. The ease of the fix is also a factor. None of these things weights a fix according to a rigid decision tree, but rather a combination of all those factors tends to influence the order in which bugs and enhancements get addressed. Since you want to add votes to this feature, you could ask one of the original bug owners to re-open the bug. That would free it up again for votes and comments. Or you could open a new bug yourself to address it. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: "Ask us anything" and the executionContexts
On 12/17/05 3:14 AM, "Dick Kriesel" <[EMAIL PROTECTED]> wrote: > Your answer left me a hope that maybe we were just a BZ away from being able > to use the executionContexts in a standalone, so I decided to search BZ > before asking about that possibility. Dick, are you saying that you can't use executionContexts in a standalone? Or that you need to know how to use it? Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: "Ask us anything" and the executionContexts
Your answer left me a hope that maybe we were just a BZ away from being able to use the executionContexts in a standalone, so I decided to search BZ before asking about that possibility. The result was a surprise, so here's another question: Would you please comment on the resolutions of BZ 724 and BZ 1243? I know you're not speaking officially for RR, but you know the BZ business process pretty well. On 2003-9-29 Jeanne Devoto (then still at RR) commented on BZ 724: the executionContexts "... will be documented sooon (probably the next nonbugfix release)..." She later commented "Removed for 2.1.2." BZ 724 shows severity "minor" and status "RESOLVED/FIXED." But there's still no entry for the executionContexts in the dictionary. BZ 1243 in an enhancement request for implementing and documenting anything like the functionality of the executionContexts (my words, not Dar's). BZ 1243 shows status "RESOLVED/NOT_A_BUG." Of course it was "not_a_bug;" it was an enhancement request. If these weren't marked "resolved" I'd vote for them. Instead of voting, what's the next step to take? Thanks again in advance, Jacque. -- Dick On 12/16/05 8:41 AM, "J. Landman Gay" <[EMAIL PROTECTED]> wrote: > Dick Kriesel wrote: >> On 12/15/05 10:27 PM, "J. Landman Gay" <[EMAIL PROTECTED]> wrote: >> >> >>> Ask us anything, anything at all. Really. >> >> >> An offer far too good to refuse. >> >> The executionContexts could be a useful tool if it were sanctioned for use >> in standalones. What is there about the executionContexts that causes it to >> remain undocumented and unsupported for standalones? >> >> Thanks in advance, Jacque! > > Hey, I didn't say I could *answer*. :) > > But as I understand it, the executionContexts was implemented internally > when the script editor was rewritten, back when MetaCard first changed > over to allowing clickable breakpoints (yes, there was a time when that > wasn't in there.) It was never intended for consumer use, but its > availability leaked out and some folks started taking advantage of it. > Officially it isn't really supported, and there are no guarantees that > it won't change in the future. Thus, it's not documented. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution