Game driven development

[ArneOrtlinghaus]

Again for the 4th time our colleague Volkmar has encouraged us to participate at the Adventofcode event for resolving 25 programming puzzles in the advent time:adventofcode

I have used the VO/X#-Macrocode to resolve these puzzles. Our macro processing is based on the X#-Macrocode compiler enhanced with control structures/functions/variables. We use it much for programming customer specific solutions/modifications for our standard programs. Although the execution is much slower, the solution often is cheaper, faster realized, can be developed with the customer data and often also modified by projects/support colleagues or admins from customer.

In the four years I participated I made different enhancements to this macro code to better resolve the puzzles: Performance enhancements, additional functions for string parsing, array usage, diagnose and control possibilities of the macro execution. I added also a class to be able to use the dictionary class in macros to have the right performance to resolve puzzles with millions of executions with millions of number. So this can be also a type of enhancing programs: Use them in competitions!

Of course I didn't want to seriously invite everyone from you to do the same, I thought as a funny side in our daily work.

If someone is interested in some code, I can share it, of course only the code that is not depending on third party licencing. I believe that the macro/script execution is an important part for a program and with X# we have already many of the necessary parts.

Have a nice start of the new year!

Arne

[fxm]

Hey Arne,

Very interesting. I'd certainly be interested in looking at any code you'd be willing to share!

Thanks!

[robert]

Arne,
Interesting indeed.
Actually we are in the process of adding an ExecScript() function to the runtime that allows you to call the X# script engine from your code.
This is like the macro compiler, but then it also allows entities (functions, classes etc). The code gets compiled into an in memory assembly with full support for everything in the language.
Unlike the standalone script engine this will also support dialects (including things like privates and publics for dialects that support these), late binding and UDCs.

Robert

[ArneOrtlinghaus]

Hi Fergus,
please send me your email address and I will send you some code.

Arne

[ArneOrtlinghaus]

Robert,
having this "Execscript" will be a big step ahead. Surely execution will get much faster. And having all language features will also give many possibilities.

Arne

[fxm]

That's great Robert. Do you have a rough timeline for this addition? I was just about to start a scripting project but these changes should make the project a whole lot easier.

Thanks,
Fergus

Actually we are in the process of adding an ExecScript() function to the runtime that allows you to call the X# script engine from your code.
This is like the macro compiler, but then it also allows entities (functions, classes etc). The code gets compiled into an in memory assembly with full support for everything in the language.
Unlike the standalone script engine this will also support dialects (including things like privates and publics for dialects that support these), late binding and UDCs.
 

[robert]

Fergus,
We will most likely include this in the next build.
We're still polishing things, but it is working. Some things that we support:
- you can have a body that consist of "top level statements" (a function without function header)
- top level statements can start with PARAMETERS or LPARAMETERS to receive parameters from the calling code
- you can also declare functions and classes
- UDCs are supported (like USE, GO TOP etc). We have included the header files as resource in the script compiler
- The Script compiler picks up the current dialect and enables/disables dialect specific options in the language based on the current dialect

Robert

[fxm]

Fantastic - thanks!

Fergus,
We will most likely include this in the next build.
We're still polishing things, but it is working. Some things that we support:
- you can have a body that consist of "top level statements" (a function without function header)
- top level statements can start with PARAMETERS or LPARAMETERS to receive parameters from the calling code
- you can also declare functions and classes
- UDCs are supported (like USE, GO TOP etc). We have included the header files as resource in the script compiler
- The Script compiler picks up the current dialect and enables/disables dialect specific options in the language based on the current dialect

Robert