Applying scripts that don't compile

[Mark Waddingham]

On 2016-07-02 17:52, Richard Gaskin wrote:
> If someone out there wants to set scripts that won't run it's not my
> place to tell them not to, but if it helps your development work to
> let that oddity go it won't affect anything I do since I prefer
> writing scripts that are at least possible to run. :)

As far as I'm aware - the functionality of the LiveCode Script Editor 
has always been to set the script of the object *regardless* of whether 
it compiled or not. The reason here is that if you do not do that, then 
you could lose work that you have done as the version which doesn't 
compile is held in a state of 'limbo' (i.e. in the script editor window 
and nowhere else).

Given that LiveCode is a dynamic environment, where you can easily do 
things 'behind the IDE's back' (perfectly legitimately) this errs on the 
side of caution - it means regardless of what might happen in the 
environment, if you have clicked 'Apply' in the script editor, then you 
will not lose the changes you have made.

The reason I think this is 'okay' from the point of view of editing 
projects within the IDE is that a script edit operation should really be 
considered to be this:

    1) Pause the running project (i.e. switch to Edit Mode)

    2) Apply the edited script

    3) Resume the running project (i.e. switch back to Run Mode)

If (2) fails due to compilation errors then you can't really 'resume' 
the running project as it is not in a state it can be run (it is 
incomplete!). Obviously, the IDE doesn't enforce this at the moment but 
one can imagine that it could be enforced without too much 
'interruption' to the current workflow. (Indeed, 'widgets' do actually 
have this distinction - they only 'run' in Browser mode, when in 
'pointer' mode notionally they are considered to be being edited and 
thus processes that occur whilst 'running' do not occur).

When considering the IDE case, however, the IDE is something which 
cannot be paused to edit itself, because it is editing itself - if it 
were paused you wouldn't be able to edit anything (it's turtles all the 
way down!). Hence, Monte's modification in the case of the IDE *right 
now* is probably reasonable, as long as it is specific to IDE stacks 
*and* the S/E shows a visual reminder that the script being edited is 
not applied to the script property).

A more helpful approach in the future, however, might be that 
non-compiling scripts are stored in the object in a custom property and 
the script property of the object itself is not touched in this case. 
When you edit such an object:

    1) the script editor would show the non-compiling script (and 
indicate that it is different from the actual set script)

    2) you cannot set breakpoints, or 'run' handlers in that script - you 
need to switch to the actual set script view

    3) if the debugger triggers on the object, it displays the actual set 
script view which would be visually distinct from the non-compiling 
script view.

(The Visual Studio IDE has long had an 'Edit-and-Continue' option for 
C++ which works quite well as long as you don't violate various 
unwritten rules about modifications to the C++ code; if your edit and 
continue fails and the debugger triggers in this case you are clearly 
shown that it is not the actual code which you were editing and thus it 
is stale).

Anyway, food for thought here I think!

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps