Making this work on Smallworld 4.1 and nested alias

[hatchjdecho]

Very grateful for the work that has gone into this library. After some experimentation I have also managed to get it working with a heavily customised implementation on Smallworld 4.1 although to do so I needed to remove the -l argument from the gis_args.

I note that all your documentation only refers to successful use on 4.2 and later so I am not sure if this was a bug in 4.1 that -l and -i together cause the magik image to close immediately after reaching the command prompt?

Currently for our testing I have added an override using an environment variable ROBOT_SKIP_GIS_LOG with minimal changes in robot_start_magik_image.py to suppress the gis argument and the loginfo Logfile location when the variable is set.

It would be cleaner to implement the overide into the classes without depending on an environment variable but that requires much deeper changes.

Would you consider a change to support 4.1 ? (I realise there are probably not many people still using it with active development).

[lczub]

Hello Hatchjdecho,

fine to here, that the library is useful for you. Your observation is correct, I haven't yet use it with 4.1, cause start behavior changed between 4.1 and 4.2 in some details (what you mention) and our focus was to test the behavior after migrating to 4.2 / 4.3.

First idea to support 4.1, introduce an optional parameter gis_version which influence _prepare_gis_args_and_envs(). I will check this during the next week.

If you like, you can commit a pull request with your ROBOT_SKIP_GIS_LOG workaround or attach it to this issue report. Would be a base to identify the required changes. I agree with you, that such a environment variable is not a final solution.

Regards Luiko

[hatchjdecho]

Luiko,
Thanks for the quick response.
Please find attached the only file that I changed in two places (zipped to allow me to upload it). I am setting the extra environment variable to distinguish my requirements from other team members working with later Smallworld versions. Your suggestion for an additional optional parameter gis_version sounds like a better solution compatible with existing usage. Cheers, James. robot_start_magik_image.zip

[lczub]

Hello James,

the commit 1610bf6 adds a sample variable file _variables_sw41cbg.py, I used to start successfully a SW411 TSB120 cambrigde image without setting your ROBOT_SKIP_GIS_LOG environment file.

The image was started using both parameter -l and -i.

Starting process: E:\Smallworld\411_TSB120\CST411\product\bin\x86\gis.exe -a E:\Smallworld\411_TSB120\CST411\product\config\gis_aliases -l C:\Users\czub\AppData\Local\Temp\RIDEh23lh4le.d\cambridge-0929_203109-14001.log -i cambridge C:\Users\czub\AppData\Local\Temp -login "root/ "

Main difference between _variables_sw41cbg.py and _variables_sw43cbg.py, variable MSFSTARTUP is set to True. Effect is, that the startup magik file to init the required remote_cli will be loaded using the environment variable SW_MSF_STARTUP_MAGIK and not the script engine with its start parameter run_script (introduced with 4.2/ 4.3).

Questions a) are you able to start the 411 cambridge image in your environment with -l and -i arguments from dos prompt as shown in above sample (without any robot interaction) ? b) which setting have you used for the robot variable / argument MSFSTARTUP ?

Regards Luiko

[hatchjdecho]

Thanks Luiko, Sorry for the delay - I have been travelling and in meetings ... b) I am indeed using SW_MSF_STARTUP_MAGIK = True

a) Was harder to get tested... it turns out that I can run the Cambridge DB open image from the command prompt with a very similar command to yours (running cst410_camdb_open or cst410_camdb_open_gui_1 on our environment ) . However the heavily customised version of PNI4.1 that I need to start with the Robot currently starts with a set of hierarchical gis_alias files (gis.exe runs gis.exe runs sw_magik_win32 ). This seems to be the root cause of the -l incompatibility. If I bypass the hierarchy and run the final alias directly I can use the -l argument and therefore could presumably use the standard library.

So I guess that between us we have tested your current framework on 4.1 and you can now claim support for that as well. I have the choice between my skiplog solution or streamlining my alias_files.

Thank you for your help on this, Cheers, James.

[lczub]

Hello James,

thanks for your feedback and testing 4.1 compatibility. I was now able to reproduce your problems with a nested gis_alias definition. You work with definition like following, or?

cambridge_nested:
    title       = Open SWAF Image for Cambridge DB
    program     = %SMALLWORLD_GIS%\bin\x86\gis.exe
    args        = cambridge_based -image %SMALLWORLD_GIS%\..\cambridge_db\images\open_swaf.msf

cambridge_based:
    dir     = %SMALLWORLD_GIS%\..\cambridge_db
    directory   = %dir%
    ARGS    = -cli -Mnew 200M -Mold 16M -Mpage 32M -Mext 250M -Mextdir %temp%

We use them in the past, too. But replace them during the 4.2/4.3 migration with shifting environment variables into separate environment files. Do not remember exactly why, but I guess the changed image build mechanism was one reason.

So your issue is not related to a GIS version, it is related to different gis launcher behavior, when nested aliases are used. I will think about it, how I could implement a switch to support such nested alias situations. In principal it could also occur with 4.2/4.3 .

Cheers Luiko

[hatchjdecho]

Luiko, yes that is the form of nested gis alias - in our case we actually have 3 levels of nesting rather than 2 but I am very pleased if you can now reproduce it with that simple combination above which makes a good test case.

I guess one solution would be to add an optional nestedAlias? parameter (instead of the originally proposed swVersion ) and use that to suppress the -l command (in the same way that I did originally with an environment variable) although if you can find a way to make the nested gis.exe calls pass the -l parameter through to subsequent levels that would clearly be better.

Cheers, James.

[lczub]

Hello James,

the commit 7d94361introduce the new argument nested_alias.

sample starting inside robot tests using RobotMagikLauncher see _tests\nested_aliases\Robot_Magik_Launcher_Nested_AliasTests.robot

Start Magik Session    aliasfile=${ALIASFILE_NESTED}    gis_alias=${ALIAS_NESTED}    nested_alias=${True}    msf_startup=${MSFSTARTUP}    login=${LOGIN}

sample starting outside robot tests with python script see _tests\nested_aliases\robot_magik_scripttests.robot

python    resources\scripts\robot_start_magik_image.py --nested_alias --msf_startup --aliasfile ${aliasfile} ${swproduct} ${alias} ... 

Known Limitations:

• with RobotMagikLauncher start and stop works
• with py scripts, only start with robot_start_magik_image.py works, stop with robot_stopt_magik_image.py does not work, cause the process id, catch during the start is the one of the first gis start, but the nested alais starts a different gis process and this pid is currently not catch.

But when you just work with RobotMagikLauncher , it hopefully works. Would be nice to get feedback from your test.

Regards Luiko

[hatchjdecho]

Hi Luiko, I have regression tested that version (commit 7d94361d) with all the tests that we had implemented. And it works well, only needing the additional nested_alias parameter in our Start Magik Session keywords which is only in a couple of library files. I also checked that the log correctly shows the status "session started without a logfile". Thank you for that, I look forward to it being available in the main release. Cheers, James.

[lczub]

Hello James, thanks for the feedback and testing. I hope to find time till end of the month for publishing a new release. Cheers Luiko

[lczub]

Hello James, the new release v0.5.1 supporting nested aliases is published.

Cheers, Luiko

[hatchjdecho]

Super thanks for the support - glad to have been able to contribute a small part.