I’ve recently been having some issues with breakpoint markers not appearing in debug mode. It was intermittent in nature as I was debugging & quite frustrating.
Note the lack of breakpoints offered for the last 2 lines.
set a to 1
set b to 2
(*set x to 7
set y to 8 #FIXME*)
set c to 3
set d to 4
As it turns out, having a line containing a # comment initiator followed by a multi-line comment terminator *) will cause Script Debugger to stop looking for possible breakpoints in the rest of the script, even though this is valid AppleScript code & does not pose any compile/runtime issues.
(Note that the same is not true for the -- comment initiator, which will “comment out” the multi-line comment terminator *)).
Could the debugger’s parsing logic be updated in a future release? This is trivial to work around now that I’m aware of the issue, but I certainly use a mix of # and (* *) quite often while troubleshooting scripts, so it’s liable to pop up accidentally again.
Hi Shane – I was bitten again by this bug again today. I was writing up a Bug Report when I saw that… I had already done that!
I understand how in isolation it looks quite silly & easy to avoid, but in longer scripts with larger nested comment sections it becomes quite an insidious issue.
Because of the breakpoint-setting UI differences between Script Debugger & e.g. Xcode (in Xcode you just click the empty gutter, vs. clicking transparent breakpoint placeholders in Script Debugger), it makes it look as if Script Debugger’s Debug Mode is just plain broken.
Both Script Editor & Script Debugger treat *) as terminating a multi-line string, even if that line has preceding comment characters. Script Debugger’s Debug Mode is not parsing it correctly if the number of preceding comment characters are not balanced with the opening token (e.g. (* to open & # *) to close).
It’s quite easy to comment out the bottom *) token when using the Edit > Lines > Comment functionality on multiple lines.
In today’s case, a multi-line comment’s closing token had been commented out with its surrounding lines at some point in the distant past. The script still executed fine, but when I was making some updates, I wasn’t able to set any breakpoints. The problematic # *) line was hundreds of lines above, so there was no visual clue as to what was causing the issue.
Is this something that can be addressed in a future update?
Not a bad thought, Ed (points for creativity! ). It wouldn’t have helped in this most recent case (the *) was there first), but something like that could be useful if the issue cropped up frequently.
Part of the issue here was that the script has been running fine for months, so it catches you by surprise when the Debug Mode breaks out of the blue.
It does seem that my understanding of how AppleScript handles # end-of-line comments embedded within a block (*...*) comment is incorrect.
I presumed the handling of -- and # end-of-line comments within a block (*...*) comment is the same but it is in fact different. I suspect something changed somewhere along the way because I recall testing this extensively at the time the # end-of-line comment was introduced into AppleScript 2.0.
Consider this example:
(* text
text -- comment*)
log "Hello World"
AppleScript flags this as a syntax error because the -- comment portion of the block comment consumes the *) and thus the block comment is unterminated resulting in a syntax error.
By contrast, the following compiles cleanly:
(* text
text # comment*)
log "Hello World"
The # comment end-of-line comment does not consume the *) block comment terminator.
We’ll sort this out within Script Debugger’s parsers in a future maintenance release.
). It wouldn’t have helped in this most recent case (the