Include function and compiling

[JRL]

I just came across this and thought I'd mention it.

I have started using the include function when dynamically writing external script files. If you write a dynamic external script file then call it with the Macro> function the external script runs independently of your master script, the master script stops until the external script completes and there are extra steps needed to pass information from the external script back into your master script. All issues are resolved if you instead use the Include> function since the dynamic script is absorbed by the master script and is essentially a part of the original script.

The issue I want to mention occurs when a script containing a dynamically created included file is compiled. For some reason if it is compiled with the "Includes" variable set to 1 (the default), the included script will not function. If the script is compiled with the "Includes" variable set to 0, all works as planned.

I do not currently have an issue with this but I could see where this could be detrimental if a script were created with the intention of it being compiled and the script also contained conventional includes.

Here is a sample to demonstrate what I've so in eloquently been trying to explain. If you compile this with "Compile includes" checked, the script will fail. You will not see a message when the executable is run. If you compile this with "Compile includes" unchecked, you will see th message when the executable is run.

Code: Select all

C:\includetest.scp
WriteLn>C:\includetest.scp,wres,MDL>Included
Include>C:\includetest.scp
DeleteFile>C:\includetest.scp

Thanks for listening.

[Marcus Tettmar]

Um. Looks like your script CREATES the include file. If the include file doesn't already exist at compile time, how can it include it and compile it in? SInce you are dynamically creating it it must be dynamically included and cannot be statically compiled. So what you describe makes perfect sense. It's dynamic so you can't compile it in.

[JRL]

I'm not sure that I agree that it makes perfect sense, but that's because I don't know what the code in the compiler is doing to the Include> line.

Yes, the Included file does not exist at compile time so obviously it cannot be sucked into the script during the compile. The part that isn't obvious to me is that compiling with the include option turned on causes the compiled include line to fail.

I'm GUESSING that during the compile the include line is somehow converted to the script that the include line calls effectively making the include> function line disappear. I'm also guessing that if there is no script to include, the line disappears anyway.

Based on this assumption, I have just now while typing this post, figured out a way to get around this. I created a script file in the script directory and named it "includethis.scp". Includethis.scp has one line:

Code: Select all

Include>C:\includetest.scp

I changed the script to be compiled to:

Code: Select all

C:\includetest.scp
WriteLn>C:\includetest.scp,wres,MDL>Included
Include>%SCRIPT_DIR%\includethis.scp
DeleteFile>C:\includetest.scp

Using this technique a dynamically created script can be included if the master script is compiled with "Compile includes" checked.

This technique would only be necessary in the case where a script to be compiled has both a dynamically created script to be included AND a normal included script.

This is important to me right now because of a script I've been working at in my "spare time" that will assist in designing dialogs where multiple objects in the dialog have multiple fonts and multiple sizes. Currently it's quite time consuming to get dialog objects arranged just right when there are many objects of varying sizes. The script relies on the dynamically created include ability. I was disappointed when I couldn't compile it but I now think I can get around the issue.

Hope this makes sense.

[Marcus Tettmar]

It makes perfect sense to me but I am obviously unable to purvey the reason.

Compiling includes "sucks" the include INTO the script that is compiled. The code is included AT COMPILE TIME. So if the include does not exist at compile time compiling that include will suck in nothing and then nothing will exist in it's place and so nothing will happen when you run it.

NOT compiling includes leaves the line as is and therefore leaves it to RUN time to pull in the include file just as if you had not compiled the script. So at run time it pulls in the included file (if it exists) and the code within it is executed.

A static compile includes the code AT COMPILE TIME. Otherwise the code is not included at compile time and only included at RUN TIME.

If you attempt to statically compile code that doesn't exist you will get an EXE containing no code at that point. It won't suddenly change to being a dynamic include again.

Back to your issue - you want dynamic includes. Therefore leave the Compile Includes box UNCHECKED. Then it ignores the include during compile leaving it to include the code at runtime. No workarounds needed.

[JRL]

Back to your issue - you want dynamic includes. Therefore leave the Compile Includes box UNCHECKED. Then it ignores the include during compile leaving it to include the code at runtime. No workarounds needed.

This technique would only be necessary in the case where a script to be compiled has both a dynamically created script to be included AND a normal included script.

Thanks for the confirmation about what goes on during an include compile. AND thanks for adding a new word to my vocabulary. Had to look it up even though I should have recognized it as the root for "purveyor".

[Marcus Tettmar]

Ah - I guess you need a way to mark which Includes should be static and which should be dynamic rather than them all being one or t'other.

[JRL]

"t'other"... There's a word I can relate to.

Yes, some way to differentiate would be nice. Being totally ignorant about how Macro Scheduler base code works, it seems like it would be easy to create a new function (DynamicInclude>?) that has exactly the same functionality as Include> but is not treated by the compiler as an include at compile time Not sure that's the correct way to say it but hopefully you know what I mean.

[gdyvig]

I never realized that compiled macros could include scp script fragments, subroutine libraries and such.

I just tried it and found you can distribute macros with the "compile includes" option checked OFF along with the include files to machines that do not have Macro Scheduler installed. That allow for much smaller executables and like JRL says - more flexibility. You could send out corrections to include files without needing to recompile the executables.


Gale

[jpuziano]

it seems like it would be easy to create a new function (DynamicInclude>?) that has exactly the same functionality as Include> but is not treated by the compiler as an include at compile time. Not sure that's the correct way to say it but hopefully you know what I mean.

That sounds like a capital idea! I suspect and hope this has been added to the secret "wish list" and mjtnet can purvey it to us in a future release. Further thoughts are...

Calling the new command IncludeDynamic> instead has the benefit that if a user is looking through the alphabetic list of commands (in the Help File or elsewhere), then the two commands would be shown next to each other.

Another thought might be to do this similar to how other commands were enhanced, by adding an additional optional parameter... perhaps like this:

Include>scriptfile[,compiler_treatment]

Includes code from an external script file. The code is executed and made available to the calling script. Therefore variables and subroutines in the external script file are made available to the calling script.

The optional parameter compiler_treatment can be used to set how this Include statement will be treated if compiled. All Include statements without this parameter will be treated according to the "Compile Includes" checkbox when you compile the macro:

If checked, all regular Include> statements will be statically compiled (resolved at compile time).

If unchecked, all regular Include> statements will be dynamically compiled (left to be resolved at run time when the compiled exe runs).

Values for this optional parameter are as follows:

0 = Compile Static
This means the code this include statement points to will be pulled into the compiled exe when we compile it (so it must exist at compile time).

1 = Compile Dynamic
The code this include statement points to will be pulled in at run time (when the compiled exe actually runs) so it does not have to exist at compile time.

Note: When you compile a script, the "Compile Includes" checkbox setting only affects Include> statements without this extra parameter. Note also that you can use a variable for this parameter, but any value other than 0 or 1 will produce an error at Compile Time.

Just some thoughts... probably an excess of verbiage... just wanted to contribute to the process.

Take care

[JRL]

Another thought might be to do this similar to how other commands were enhanced, by adding an additional optional parameter

Actually I also prefer the idea of an include parameter if this notion ever makes it into production. But if the solution were to be a second function, I could live with that too.