Defined subroutines out of stay in scope

[lowenthalm]

The sequence below calls another sequence "Autofocus (Refocus)" which in turn calls another sequence that defined a couple of functions and performs a plate solve. The second time through the loop in the below sequence, calling the "Autofocus (Refocus)", failed when calling the plate solve sequence because SUB LongerExposureSolve was already defined. It appears that functions definitions leak out of the scope of a called sequences. As it is now, this makes it impossible to call any external sequence multiple times if that exteral sequence defines functions. It seems to me that the scope of functions should be confined to the sequence that is called and all identifiers in that sequence should be deleted upon exit from that sequence.

The only way these functions should be hoisted into the name space of the current sequence should be via the import function definition step (which is currently broken, as I reported in another e-mail). Not sure how you want to cope with calling an external sequence for which you have already imported functions. It seems to be that the most seamless way to do it would be to have the import function definiton step copy the function definitions into the current sequence's name space. This would prevent redfined function errors from occurring if you both imported function definitions from an external sequence, and also called the external sequence. Since the only identifiers in any name space are function definitions (as you are avoiding implementing variables), I think this would probably be a safe way to do it.

SEQUENCE
PROMPT FOR TARGET
PROMPT "Is target star reticle positioned properly and right FILTER?" ENABLECONTROLS True
SET CONTROL "Background Subtraction" TO Off
SAVE MOUNT COORDINATES
STOP AT -6 FROM MERIDIAN
UNLOCK CONTROLS
LOOP 3 TIMES
RUN SEQUENCE FROM "\\Mac\Home\Desktop\SharpCap Captures\__Sharpcap Sequences\Autofocus (Refocus).scs"
LOOP 4 TIMES
GUIDING CONNECT ABORT False
GUIDING DITHER NOW
DELAY 3
LIVE STACK FOR 72 FRAMES SAVING AS AllFormats COUNTING Stacked FRAMES
PLAY SOUND Alert
GOTO SAVED COORDINATES
DELAY 4
PRESERVE CAMERA SETTINGS
SET RESOLUTION TO 4144x2822
IGNORE ERRORS FROM ONERROR RUN ""
RETRY ERRORS UP TO 4 TIMES
MOUNT SOLVEANDSYNC
END RETRY ERRORS
END IGNORE ERRORS
END PRESERVE
DELAY 4
END LOOP
END LOOP
END UNLOCK
END STOP AT
PLAY SOUND Alert
PLAY SOUND Alert
END SEQUENCE


Autofocus (Refocus).scs:
SEQUENCE
.... blah blah ... focus hocus pocus ... blah blah ....
RUN SEQUENCE FROM "\\Mac\Home\Desktop\SharpCap Captures\__Sharpcap Sequences\Plate solve.scs"
END SEQUENCE


Plate solve.scs:
SEQUENCE
DEF SUB LongerExposureSolve
SHOW NOTIFICATION "Short exposure failed, trying longer exposure" COLOUR Amber DURATION 15
SET EXPOSURE TO 10
IGNORE ERRORS FROM ONERROR RUN ""
RETRY ERRORS UP TO 2 TIMES
MOUNT SOLVEANDSYNC
END RETRY ERRORS
DELAY 4
SHOW NOTIFICATION "Long exposure plate solve succeeded!" COLOUR Green DURATION 15
END IGNORE ERRORS
END SUB
DEF SUB ShorterExposureSolve
IGNORE ERRORS FROM ONERROR RUN LongerExposureSolve
ADJUST CONTROL Exposure BY -1
DELAY 4
MOUNT SOLVEANDSYNC
SHOW NOTIFICATION "Reduced exposure plate solve succeeded!" COLOUR Green DURATION 15
END IGNORE ERRORS
END SUB
PRESERVE CAMERA SETTINGS
SET RESOLUTION TO 4144x2822
IGNORE ERRORS FROM ONERROR RUN LongerExposureSolve
RETRY ERRORS UP TO 2 TIMES
MOUNT SOLVEANDSYNC
SHOW NOTIFICATION "Short exposure plate solve succeeded!" COLOUR Green DURATION 15
END RETRY ERRORS
END IGNORE ERRORS
END PRESERVE
END SEQUENCE

[admin]

Hi,

this will need some thought, since it goes beyond the original design I had in mind for this. As the 'programming language' features of the sequencer of grown, some of the interactions between them are now significant and were not envisaged initially

If you put the subroutines in the main sequence then you can take advantage of the current 'global' nature of them, since they will be available to any sub sequences that you run.

cheers,

Robin

[lowenthalm]

Understood. I known addition a hidden scope identifier as a prefix to every identifier would be an tricky retrofit. Your suggestion is certainly one workaround. However, it defeats any modularity that should come with the ability to call external sequence files.

[admin]

Hi,

agreed on the modularity. For now I'm leaning towards making the redefinition of a subroutine no longer an error - just overwrite the original. Although that opens a new minefield...

cheers,

Robin

[lowenthalm]

That would be a decent work around that would cover the problem I reported. Might I suggest that before overwriting, maybe you could compare the two function definitions to see if they are the same. If they aren't, then you throw a "function redefined error". A little bit of a hack, but it would avoid that minefield you mention, while still keeping the SC code changes required fairly localized.

[admin]

Hi,

yes, that would probably work as an interim solution - I can write both subroutines to code and check that the text output is the same (easier than trying to compare the internal representations of them).

cheers,

Robin