#898 using more than one runtime class in a single GLM result in mass confusion,

[nikhilgupta10]

It looks like the GLM loader does not clear the source code buffers when it begins a new runtime class. When a second runtime class is defined the first class's code ends in the second class's source files and mingw input chaos ensues. Although this has never been a autotest case, it probably should be.,

[nikhilgupta10]

nikhilgupta10 imported these comments from Sourceforge: The user dchassin does not exist anymore. Therefore assigning this to afisher1. "dchassin":Fixing this problem will fix #897.,

"dchassin":Suggest adding the following to the end of load.c/compile_code() right before the return.

    /* clear buffers */
    code_block[0] = global_block[0] = init_block[0] = '\0';
    code_used = 0;
~~~~~,

 "dchassin":I made the above patch but there is more to it than just the buffers. The problem persists depending on the order in which #includes are listed in the GLM file.

This works

set tmp=.

include

include \enduse_monitor.glm\r

include \house.glm\r

include \market.glm\r

include \schedules.glm\r

and this fails

set tmp=.

include \market.glm\r

include

include \enduse_monitor.glm\r

include \house.glm\r

include \schedules.glm\r

For now I can work with this, but the situation suggest a more profound problem with the core module/compile code.,

 "dchassin":- **status**: new --> assigned
- **assigned_to**: David P. Chassin
- **Milestone**: Unscheduled --> Knothole Interim
- **Priority**: blocker --> critical
,

 "dchassin":Verified that the specific problem is fixed, noting only that the failure of gldcore/autotest/test_duplication_function_err.glm indicates another problem best addressed by diagnosis of the validation failure.,

 "dchassin":- **status**: assigned --> closed
- **Resolution**: none --> fixed
,