Acknowledged
over 1 year ago

excludeAnnotations stopped working as documented in new SDKs

An excludeAnnotations clause started to return errors for the pattern in the official doc that used to work for years. 

function setLayoutVars(){
	if(dataLoading){
		scheduleDataLoading(activity);
		...
	}
	...
}

(:data)
function scheduleDataLoading(activity){	
	...
}

monkey.jungle excludes that function for some devices:

fenix3.excludeAnnotations = data

Those devices never call that function thanks to the dataLoading var.

It worked perfectly for years.

Yet with the latest SDK version (I skipped multiple versions), the raises an error:

> monkeyc -r -o late.prg -y [path2devkey] -f ../monkey.jungle -d fenix3 --typecheck 0

ERROR: fenix3: ./source/lateView.mlc:x,y: Undefined symbol ':scheduleDataLoading' detected

The documentation guides to such usage with conditinal launching excluded symbols even in an example of the excludeAnnotations with conditional launching of (:newer)newHotnessAlgorithm(){} vs. (:older)oldAndBustedAlgorithm(){} annotations

https://developer.garmin.com/connect-iq/reference-guides/jungle-reference/


What's the problem?

Is there any new compiler setting for that? 

myneur
Parents
  • over 1 year ago

    It's not that excludeAnnotations per se stopped working, it's that:

    1) The compiler tries to determine whether your app calls an undefined symbol at compile-time now, rather than allowing that kind of situation to cause a crash at run-time

    2) In your case, even if dataLoading is always false for the devices which exclude data (which means they'd never actually call scheduleDataLoading), the compiler isn't smart enough to know or care.

    The simplest solution would be to provide a version of scheduleDataLoading() with an empty body for devices which exclude data. This may waste a few bytes, but who knows, maybe the optimizer will optimize out the call and the function itself when appropriate, which means no bytes would be wasted.

    e.g.

    monkey.jungle:

    base.excludeAnnotations = non_data
    fr245m.excludeAnnotations = data

    .mc file:
    (:data) var dataLoading = true;
    (:non_data) const dataLoading = false;

    (:data)
    function scheduleDataLoading() { 
     System.println("scheduleDataLoading");
    }

    (:non_data)
    function scheduleDataLoading() { }

    function testExcludes() {
     System.println("testExcludes");
     if (dataLoading) {
       scheduleDataLoading();
     }
    }




Comment
  • over 1 year ago

    It's not that excludeAnnotations per se stopped working, it's that:

    1) The compiler tries to determine whether your app calls an undefined symbol at compile-time now, rather than allowing that kind of situation to cause a crash at run-time

    2) In your case, even if dataLoading is always false for the devices which exclude data (which means they'd never actually call scheduleDataLoading), the compiler isn't smart enough to know or care.

    The simplest solution would be to provide a version of scheduleDataLoading() with an empty body for devices which exclude data. This may waste a few bytes, but who knows, maybe the optimizer will optimize out the call and the function itself when appropriate, which means no bytes would be wasted.

    e.g.

    monkey.jungle:

    base.excludeAnnotations = non_data
    fr245m.excludeAnnotations = data

    .mc file:
    (:data) var dataLoading = true;
    (:non_data) const dataLoading = false;

    (:data)
    function scheduleDataLoading() { 
     System.println("scheduleDataLoading");
    }

    (:non_data)
    function scheduleDataLoading() { }

    function testExcludes() {
     System.println("testExcludes");
     if (dataLoading) {
       scheduleDataLoading();
     }
    }




Children
  • over 1 year ago in reply to flowstate

    Thanks. I finally did exactly that solution and it works. 

    Then Garmin guys should update the doc where the example suggests something that the compiler does not allow now.

    Or better they should fix this half-baked change, so devs need not todo such unnecessary workarounds with an impact to the memory footprint, that is already quite tight. 

    Thank you took a time to suggest the solution.