Testing the MJT compiler

[Randall]

Create 3 macros in the same folder location as SCRIPT_DIR

main.scp
----------------------------
Let>a=10
If>a=10
Include>%SCRIPT_DIR%\sub.scp
Endif
----------------------------

sub.scp
------------------------
Include>%SCRIPT_DIR%\subsub.scp
------------------------

subsub.scp
------------------------
MessageModal>Hello World!
------------------------

Compile all 3 with the include flags turned on.

Run main.exe, you will get the message "Hello World"

Move the subsub.scp macro from the SCRIPT_DIR location, put it somewhere else.

When I run main.exe again.. it failed and no message "Hello World" appeared.

Is this expected behavior? Main.exe apparently wants to read the raw script.scp data, not execute from its own compiled executable. (this is happening on my machine)

How do we get main.exe fixed so it doesn't need any raw script files at all?

I would like to create a pure executable and NOT have any source files needed for the main.exe to run.

Thanks for your help!!

- Randall

[Marcus Tettmar]

Ah - in this case sub.scp will be compiled into main.exe. subsub.scp will NOT be compiled in because it is referenced by sub.scp. The compiler isn't iteratively evaluating each inlude. It only works against the top level Includes.

I will have the docs updated to that clarify that.

Incidentally you don't need to compile ALL three.

[Randall]

Marcus:

Could you please direct me to your documentation of the compiler not catching the second level or nested Includes> with the compile include flag turned on?

I apologize if I have overlooked it.

Thank you

- Randall

p.s. Thanks for the correction on only needing to compile main.scp, not the other two macros.

[jpuziano]

Marcus:

Could you please direct me to your documentation of the compiler not catching the second level or nested Includes> with the compile include flag turned on?

I apologize if I have overlooked it.

Hi Randall,

I believe Marcus has stated its not in the documentation yet... and he'll be updating to add something along the lines of... "The compiler isn't iteratively evaluating each inlude. It only works against the top level Includes".

Randall, just curious, were you using "nested" Includes when you first posted a problem with Include... or is this a recent variation/finding?

[Randall]

I posted the documentation request from reading the forum about 5 minutes or so previous to Marcus' post, so I didn't see it until I posted. Sorry about that.

I was using nested Macro>%SCRIPT_DIR% at first, then went to nested Include>%SCRIPT_DIR% next.

Placing all the (helping) macros into subroutines is the way out of my conundrum, it seems to be working okay now.

- Randall

[jpuziano]

Placing all the (helping) macros into subroutines is the way out of my conundrum, it seems to be working okay now.

Glad to hear and thanks for your posts... I now have a new understanding and appreciation for the Include> statement... take care.

[Marcus Tettmar]

Hi all,

Glad you have a solution. In the mean time the following is now on our work list:

1. Investigate complexity of modifying the compiler include code to become iterative so that it works on includes in scripts already included, then, dependent on our findings, either make the change or update documentation to state that only "top level" includes are compiled (i.e. ones on the main script).

2. Dick has alerted me to the fact that the compiler is looking for SCRIPT_DIR case sensitively, so the Include is not compiled if you specify script_dir in lower case or mixed. We'll modify the code so that the search is case insensitive.

[jpuziano]

1. Investigate complexity of modifying the compiler include code to become iterative so that it works on includes in scripts already included, then, dependent on our findings, either make the change or update documentation to state that only "top level" includes are compiled (i.e. ones on the main script).

Perfect, thanks Marcus!

2. Dick has alerted me to the fact that the compiler is looking for SCRIPT_DIR case sensitively, so the Include is not compiled if you specify script_dir in lower case or mixed. We'll modify the code so that the search is case insensitive.

Ahh so that was JRL's issue. Marcus, I've run into a similar problem that I did not report. Sorry, I can't remember which system variable it was or the command I used it with but I do recall that things started working properly when I typed the system variable ALL IN UPPER CASE and I have always done that ever since for all system variables. I'm assuming Macro Scheduler system variables are also "supposed" to work in MiXeD cAsE and if so, please check they work that way for all commands... much appreciated.

[Marcus Tettmar]

Variables should not be case sensitive but if you find a scenario which suggests otherwise please let me know.

However, with the compiler we're talking about something different. The compiler doesn't run the script or evaluate script code. It does not happen at run time. The compiler scans the script for any Includes and looks for SCRIPT_DIR. A simple case insensitive flag was missed in this scan. It has no reflection of the script interpreter and variable handling during script execution. The two things are quite separate.

[jpuziano]

Hi Marcus,

Will do and thanks for the clarification... I can see now they are separate things... at compile time, when it looks at Include> statements, it just has to scan the scriptfile parameter and recognize %SCRIPT_DIR% case insensitive... got it.

I do have a request though... can we get a few compile time warnings added? For example:

Code: Select all

Include>%my_variable%\test.scp

When we're compiling statically (under Compile Options, checkmark beside "Compile Includes")... the above macro compiles without a warning.

However, in this scenario, I think it would be helpful to see a compile-time warning something like this:

Static Compile Warning: When compiling statically, variables other than %SCRIPT_DIR% are not allowed in the scriptfile parameter of an Include> statement so the following line will be ignored:

Line: 2
Include>%my_variable%\test.scp

[Abort Compile] [Compile Anyway]

Next example...

Code: Select all

Include>C:\no_such_file.scp

Again, when doing a static compile, the above also compiles without a warning... even when the referenced file does not exist at compile time.

Instead, it would be nice to get a warning something like this:

Static Compile Warning: File not found... the following line will be ignored:

Line: 2
Include>C:\no_such_file.scp

[Abort Compile] [Compile Anyway]

I am only suggesting compile time warnings for when we are compiling statically... because in that case, the referenced file must exist at compile time. If the compiler cannot find the file, then I feel a warning to the user would be appropriate.

Thanks for listening and take care...

[Marcus Tettmar]

Presumably you want such warnings to be disabled. Because it would get very annoying compiling a script in which you WANT dynamic includes. Your point of view seems to be that dynamic includes are undersirable. I've worked on a number of projects where they were a MUST and also some client projects where a .exe needed some static includes AND some dynamic ones. In that case warnings would be annoying. To my mind a warning is unnecessary as a) dynamic includes are useful and may be desired, and b) it should be obvious that variables are ... well, variable ... and only known at runtime.

[jpuziano]

Presumably you want such warnings to be disabled. Because it would get very annoying compiling a script in which you WANT dynamic includes. Your point of view seems to be that dynamic includes are undersirable.

Not my point of view at all... they are a great feature.

I've worked on a number of projects where they were a MUST and also some client projects where a .exe needed some static includes AND some dynamic ones. In that case warnings would be annoying.

Sure but I'm not talking about those cases. To use dynamic includes or *both* static and dynamic includes, under Compile Options, we'd be leaving the box unchecked beside "Compile Includes".

In contrast to that, I am only talking about adding warnings if:

1) user has specified they want a STATIC compile i.e. "Compile Includes" is checked

2) and one of the two error conditions I outlined is found at compile time

To my mind a warning is unnecessary as a) dynamic includes are useful and may be desired, and b) it should be obvious that variables are ... well, variable ... and only known at runtime.

Again, I agree that for a DYNAMIC compile, warnings would indeed be annoying.

However, in the two STATIC compile cases I pointed out... warnings could save the user some grief because without the warnings, lines they thought would be included... will just silently be left out.

Here's another way to look at it:

- now when I click Tools/Create Exe and the Compile dialog appears...
- and under Options I see "Compile Includes"
- I now think of that option as "Static Compilation of Include> lines only"

If I check that box, I know that:

- dynamic includes are not going to happen
- all the code I want to include will be included and compiled statically into my exe
- so my exe is fully stand-alone and self-contained... along the lines of what Randall had been looking for all along

But after compiling, I don't *really* know that do I? What if I had a typo in the filename on the Include> line? I am only going to find out about that typo the hard way... perhaps after releasing the compiled exe to some users who later report a bug.

All I am saying is, IF we specify a STATIC compile, and if when we do the compile, the compiler runs into one of the error scenarios I mentioned, it sure would be nice if it Warned us about the error condition i.e. our typo... instead of having to find out about it the hard way.

Thanks for listening and take care

[Marcus Tettmar]

Sure but I'm not talking about those cases. To use dynamic includes or *both* static and dynamic includes, under Compile Options, we'd be leaving the box unchecked beside "Compile Includes".

What if you want static includes where you reference SCRIPT_DIR AND you want dynamic includes where you use other variables. Right now you would leave the box CHECKED. And you wouldn't want warnings.

See. There's no one right or wrong here.

I think you still misunderstand what that box means.

[jpuziano]

Hi Marcus,

What if you want static includes where you reference SCRIPT_DIR AND you want dynamic includes where you use other variables. Right now you would leave the box CHECKED. And you wouldn't want warnings.

See. There's no one right or wrong here.

I think you still misunderstand what that box means.

You may be right... but I do see this:

Compile Includes

Scripts referenced by Include> statements will be embedded and compiled into the Exe. Will not work where Include> references scripts via variables other than SCRIPT_DIR.

Yet you're suggesting we can compile and have some Include> lines compiled statically and some complied dynamically while leaving the box CHECKED... by using variables other than SCRIPT_DIR... even though it says in the help file entry above that (with the box checked implied)... "Will not work where Include> references scripts via variables other than SCRIPT_DIR".

Yes I am confused. If both static and dynamic compilation of Include> lines can be accomplished... both when the box is checked or unchecked... why have the box at all? I'd really like to understand this but maybe I can't see the forest for the trees.

In each case below, will the code referenced by the Include line be compiled statically, dynamically, not at all... or???

"Compile Includes" Box is Checked:

Include>C:\my_file.scp
1) file exists at compile time
2) file does not exist at compile time
3) file exists at run time
4) file does not exist at run time

Include>%SCRIPT_DIR%\my_file.scp
5) file exists at compile time
6) file does not exist at compile time
7) file exists at run time
8) file does not exist at run time

Include>%NEBULOUS_DIR%\my_file.scp
9) file exists at compile time
10) file does not exist at compile time
11) file exists at run time
12) file does not exist at run time

"Compile Includes" Box is Not Checked:

Include>C:\my_file.scp
13) file exists at compile time
14) file does not exist at compile time
15) file exists at run time
16) file does not exist at run time

Include>%SCRIPT_DIR%\my_file.scp
17) file exists at compile time
18) file does not exist at compile time
19) file exists at run time
20) file does not exist at run time

Include>%NEBULOUS_DIR%\my_file.scp
21) file exists at compile time
22) file does not exist at compile time
23) file exists at run time
24) file does not exist at run time

Again, thanks for your patience in clarifying the above... I am hoping the light bulb will turn on soon...

[Marcus Tettmar]

Yikes

""Will not work where Include> references scripts via variables other than SCRIPT_DIR". "

This is in the section about static includes, so it refers to whether a file will be statically included or not (not being the opposite: dynamic). So if the include references a custom variable the file will still be a dynamic include - just as when not compiled.

So:

With this option checked any includes referencing filenames which can only be resolved at runtime will therefore be dynamic. (It doesn't fail as I think you believe - it just continues to be dynamic - this may be desired and is not an error - so there is no error or warning)

With this option checked any includes referencing SCRIPT_DIR will be static.

With this option checked any includes where the file is literal and exists at compile time will be static.

With the option unchecked all includes will remain dynamic and none will be "sucked" into the .exe.