The failure of an AppleScript.app that was written months ago and ran every morning until today really focuses my attention on how poor the Script Editor is for debugging. I’ve tried Smile too, but found its debugging process a bit mysterious even after two days of working with it (though the price is right). On the other hand, Script Debugger, Scripter, and FaceSpan are $189, $189, and $199 which translate to $238, $238, and $250 Canadian, sales taxes not included.
So the burning questions are these:
1) Are these high-priced AppleScript Editors worth it?
2) Do many of the contributers to this list use any of them?
3) Can they explain why they chose the one they use?
or: Should I just stick with the Script Editor and get cleverer about how I debug scripts by doing things like opening an external file and writing intermediate results to it?
Smile is very flexible and powerful. The new private releases (versions 3.0bx) include new surprising debug commands. My advice is: subscrite to “Smile Users List” and request the link to the new betas. http://www.satimage.fr/software/en/sul.html
(though Script Editor’s “log” capabilities should be good enough for a pro, I think)
I have used nothing but apple’s Script Editor, and have yet to find a reason why not to.
This is the real trick. As jj says, script editor’s log capabilities should be good enough for anyone’s needs… novice or pro… but finding the way to use them effectively can be the real challenge.
I have found that using a process-flow approach to applescripting is best. I start at the beginning, and then add code following the intended progression of the application. I compile and run VERY frequently (as the situation allows), to ensure that every new update to the code is solid and does not throw errors. By using the ‘log’ command, or using a ‘display dialog’, to show a variable’s value or some object’s status, I can see as the program runs where errors arise or where certain conditions are or are not being met.
I’m not sure that writing to external files is going to prove to be a worthwhile approach to error logging. The overhead of writing a file is unnecessary, and the result is at best equivalent to simply logging to the standard log. Aside from the “event log” at the bottom of the editor window, you can also use the log history Window > Event Log History (opt+cmd+L) which not only displays the log results, but also allows you to navigate through all of the past run logs.
I find using script editor to be sufficient, and certainly am not interested in paying for anything more.
Smile’s log command is nicer than SE’s - you can direct output to a dedicated console window, where it’ll remain till you delete it. On the downside, Smile 2.x doesn’t do Apple event logging (Smile 1.x had it but it was dropped in 2.x for some reason.)
I’d agree that a decent ‘log’ command is all you really need for debugging in a dynamic language. Though note that while AppleScript’s ‘log’ command should work ok with AppleScript values it doesn’t like application references, which is a bit of a pain. (That’s a limitation of AS rather than the editor, mind you.)
Anyway, the real trick to debugging is not to write code so convoluted and complex that it’s impossible to test in the first place. A well-designed script that uses good structured programming techniques is worth ten debuggers any day when it comes to tracking down and eliminating bugs; not to mention avoiding them completely. If you’re not already up on this stuff, I’d recommend a high school-level Computing Studies textbook and a copy of Code Complete as excellent grounding, and significantly cheaper than a copy of Script Debugger.
BTW, if you do consider buying a copy of SD, it’s probably worth waiting till after Tiger comes out as that’s likely to bring various changes with it.
I had didn’t know there was a method of controlling what appeared in the log, but in one script I have that suddenly stopped working, the log doesn’t tell me much. How do I get the values of variables to appear in the log along the way? A very reduced subset is all I see. Do I have to write a handler to display dialogs of each variable I want to see and then insert doDialog(myVar) everywhere I care?
The script I am debugging (now rewriting with a different approach; this was an early script while I was learning AppleScript) stopped after running successfully for months, so the bug is not obvious.
You must explicitly tell the log to log whatever information your looking for. The ‘log’ command simply places a log entry into the log with the data you tell it to. Here’s a silly example that shows a few log’s. Wow, with all the logs in this post I’m starting to feel like a lumberjack… 8)
(* Log a variable *)
set theFile to "/Users/joe_shmoe/Desktop/file.txt" --> An intentionally bad file path
log (("Variable 'theFile': " & theFile) as string)
(* Log an Error *)
try
tell application "Finder"
reveal theFile
end tell
on error theError
log theError
end try
(* Log a result *)
set tmpResult to (display dialog "Enter a different path..." default answer "" giving up after 30)
log tmpResult
(* Log a list *)
set tmpList to {(text returned of tmpResult), (button returned of tmpResult), (gave up of tmpResult)}
log tmpList
What do you mean by this exactly? What changed that made the script stop working? What errors are you getting? There are still a lot of unanswered questions that your knowledge of how to use the log still may not answer. You’ll have to know what you’re looking for to ask the log to find it. Usually when a script stops working, an environment variable has changed (like the os, existence of certain files or folders, software updates or changes, etc), or a “user error” has occurred, which makes the script break. Typically a script will throw some kind of error or will act erratically in an obvious fashion if it is broken. It might be nice for us to see the script… or the broken portion of it… to help you determine exactly what approach would best weed out the problems.
