Unable to round-trip NSInteger in predicate

[waphumanoid]

Hello! I'm facing some unexpected behavior of the MGLStyleLayer predicate using ios-v3.4.0-alpha.4.

1. I load a style json with some filter inside like this:
   "filter": ["all",["in","id",2467,2269,559,2906,852,189,3027,5597,188,765,190,633,146]]

Then I take a predicate from a current style after loading the app and try to apply it back again:

MGLLineStyleLayer *roadLayer = (MGLLineStyleLayer *)[_mapView.style layerWithIdentifier:@"stagnation"];
NSPredicate *predicateOld = roadLayer.predicate;
roadLayer.predicate = predicateOld;

And here is the exception rising at once:
*** Terminating app due to uncaught exception 'Value not handled', reason: 'Can’t convert q:2467 to mbgl::Value'

All the elements in array are coming with (long) format.

2. Next case is when I load a style json again with a filter:
   "filter": ["all",["in","id",2467,2269,559,2906,852,189,3027,5597,188,765,190,633,146]]

Then I build a predicate just in a few millisecs (asynchronosly) after mapView initializing (while the map is rendering on the screen) and try to apply it:

MGLLineStyleLayer *roadLayer = (MGLLineStyleLayer *)[_mapView.style layerWithIdentifier:@"stagnation"];
NSPredicate *predicateNew = [NSPredicate predicateWithFormat:@"id IN %@", @[@2467, @2269, @559, @2906, @852, @189, @3027, @5597, @188, @765, @190, @633, @146]];
roadLayer.predicate = predicateNew;

And after that the layer disappears from the map.

3. Same as case 2 but now I try to change a predicate in several seconds after map initializing. A layer disappears later. Looks like it exists in cache for a short period of time and then goes off.

In general my goal is to change selected road segment colors on demand based on road traffic data.

[1ec5]

q corresponds to NSInteger. Looks like we’re only handling int at the moment. Our conversion from NSNumber to mbgl::Value needs to handle all the types that NSNumber supports. According to the documentation, that would be:

“c”, “C”, “s”, “S”, “i”, “I”, “l”, “L”, “q”, “Q”, “f”, and “d”

[waphumanoid]

Is a problem with handling int related to the cases 2 and 3 which I pointed above? If it is not, then maybe I should open a separate issue?
In addition I post here another problem with a predicate if you don't mind. The crash appears when I iteratively assign roadLayer.predicate = nil;. Then NSPredicate *predicate = roadLayer.predicate; rises
*** Terminating app due to uncaught exception 'Unsupported filter type', reason: 'Cannot convert mbgl::style::NotHasFilter to NSPredicate'

[1ec5]

I'm unsure about 2 and 3; can you open separate issues so we can diagnose and prioritize them individually?

The NotHasFilter issue is #6244.

[incanus]

For clarity, since Apple seems to like to hide this, the base types spit out by the range of NSNumber initializers are:

2016-09-07 17:40:41.935 Mapbox GL[57864:7766411] signed char: c
2016-09-07 17:40:41.935 Mapbox GL[57864:7766411] unsigned char: s
2016-09-07 17:40:41.935 Mapbox GL[57864:7766411] short: s
2016-09-07 17:40:41.935 Mapbox GL[57864:7766411] unsigned short: i
2016-09-07 17:40:41.936 Mapbox GL[57864:7766411] int: i
2016-09-07 17:40:41.936 Mapbox GL[57864:7766411] unsigned int: q
2016-09-07 17:40:41.936 Mapbox GL[57864:7766411] long: q
2016-09-07 17:40:41.936 Mapbox GL[57864:7766411] unsigned long: q
2016-09-07 17:40:41.936 Mapbox GL[57864:7766411] long long: q
2016-09-07 17:40:41.936 Mapbox GL[57864:7766411] unsigned long long: q
2016-09-07 17:40:41.937 Mapbox GL[57864:7766411] float: f
2016-09-07 17:40:41.937 Mapbox GL[57864:7766411] double: d
2016-09-07 17:40:41.937 Mapbox GL[57864:7766411] bool: c
2016-09-07 17:40:41.937 Mapbox GL[57864:7766411] integer: q
2016-09-07 17:40:41.937 Mapbox GL[57864:7766411] unsigned integer: q

It seems like the capitalized variants (C, S, etc.) are just for completeness and that, at least on certain platforms, long variants come out as q, leaving l (L) unused.

[1ec5]

Note that the encoded representation depends on the size of the type. NSInteger and NSUInteger in particular have different encodings on 32-bit versus 64-bit systems.

[incanus]

Right, hence "at least on certain platforms". Also, we don't have to deal with any 32-bit Darwin systems, right?

[incanus]

Regardless, #6290 handles all 15 NSNumber types properly. Still working to see if this fixes things, though.

[1ec5]

Also, we don't have to deal with any 32-bit Darwin systems, right?

iPad 2 is 32-bit.

[incanus]

Worse is that for some reason we actually aren't setting the righthand side of the comparison predicate:

Currently working on figuring out what about NSNumber to mapbox::geometry::value is falling down.

[incanus]

Lack of console printout is a red herring—expanding the type tree works ok. Something else afoot.