Tracing option fails to appear in targetConfig

[edwardalee]

In the tracing-federates branch, I attempted to add the following lines to FedLauncher.java:

        if (targetConfig.tracing != null) {
            commands.add("                        -t \\");
        }

However, even when tracing is set to true, targetConfig.tracing is null. I don't understand the code in TargetProperty.java. Can you fix this?

[ChadliaJerad]

I think this issue relates to the one I created 2 days ago: Target tracing property is not "inherited" is all the generated individual federates #1597.

[lhstrh]

In the tracing-federates branch, I attempted to add the following lines to FedLauncher.java:

        if (targetConfig.tracing != null) {
            commands.add("                        -t \\");
        }

However, even when tracing is set to true, targetConfig.tracing is null. I don't understand the code in TargetProperty.java. Can you fix this?

What is the problem with the TargetProperty class? If there was a bug there, tracing wouldn't work at all, also not in an unfederated program.

Maybe we should start addressing the FIXMEs in FedGenerator first? I'm looking at FedGenerator.createLauncher, for instance, and it first obtains a launcher based on the the target configuration of the first federate (why?), and then it invokes createLauncher on the obtained launcher object while passing in all federates. This code makes no sense to me... What are we expecting it to do even?

Update: if we want each federate to inherit target properties from the main file, which I'm not sure is generally true but probably is true for the tracing target property, simply using the setter as the default update function will work (bae32df). Previously, the default was to ignore updates if no custom update function was given. Note that for properties like cmake-include, where we want to merge lists, a custom update function must be provided, anyway.

[lhstrh]

See #1597 (comment)

[edwardalee]

These questions should have been addressed, I think, as part of the development of the fed-gen approach. Anyway, help would be welcome. I was not involved in either the fed-gen idea nor the implementation. I personally feel that federated execution (and scheduling enclaves) have higher priority than, say, bodiless reactions.

[lhstrh]

Do my changes address the problem satisfactorily? If so, let's close this issue.

[edwardalee]

It seems that now the tracing: true property is properly set to true in all the generated .lf files for the federation. However, it is still not seen by the above code in FedLauncher.java, which still sees null. I see the following in FedGenerator.java:

            launcher = FedLauncherFactory.getLauncher(
                federates.get(0), // FIXME: This would not work for mixed-target programs.
                fileConfig,
                errorReporter
            );

This seems to be getting the target properties from the first federate, which has tracing: true.

Unfortunately, I still don't have a working debugger now that Eclipse no longer works, so I unable to trace this. Can @lhstrh help?

[lhstrh]

OK, will look into this. This needs to be fixed to get multi-target federations working, anyway.

[lhstrh]

Work in progress can be found here: #1663. I will also add unit tests to make sure that options propagate to federates...