CLLocationCoordinate2D is CGPoint in arm64

[rromanchuk]

Getting a crash on arm64 builds where

] <Error>: *** Terminating app due to uncaught exception 'NoMethodError', reason: 'undefined method `latitude' for #<CGPoint x=37.7801385901698 y=-122.393648843357> (NoMethodError)

the get_once callback result is returning a CLLocation as expected but when accessing the coordinate property a CGPoint is returned instead of the expected CLLocationCoordinate2D

[myob]

My team is encountering this error as well. Any advice or suggestions on how we can work around it?

[markrickert]

Hmmm. looks like the CLLocation2D is being reported as a CGPoint. Not sure if this is a BubbleWrap bug, but more likely it's a RM bug. use motion support to report it. Do you know if it does the same thing just using pure CLLocation?

I'd suggest something like this as a workaround:

class CGPoint
  def latitude
    x
  end

  def longitude
    y
  end
end

...that should do it till the bug gets fixed.

[myob]

I agree, the errors in our usage of location coordinates does not lie within BubbleWrap code. In particular it impacted our use of google maps. The peculiar thing about the issue is that it did not appear in the simulator, nor on either of 2 iPad Minis, both running iOS 8.1.1. It showed up immediately on an iPhone 5S also running 8.1.1. We can craft our app so as not to rely on latitude and longitude, but find your solution of adding code to CGPoint to be more elegant and less risky given our app status. Thanks much for the input!

[markrickert]

Glad you like my workaround solution... make sure HipByte knows about this please. $ motion support is your friend :)

[myob]

I'm working now to put together a mini-project to demonstrate the issue. I expect to file the motion support issue by the end of the day today.

[rromanchuk]

This was filed a long time ago http://hipbyte.myjetbrains.com/youtrack/issue/RM-638

[rromanchuk]

just use an array accessor until it's fixed lat = location[0] lon = location[1]

[myob]

markricker's solution seems cleaner to us as it involve less change to our code and less ongoing maintenance issues. Thank you for your suggestion and the pointer to the ruby motion issue.

[markrickert]

It appears that the bug is fixed and will be in the next release of rubymotion.

[rromanchuk]

Monkey patching CGPoint is not cleaner, but then again, this is RM.

[myob]

I beg to differ. This specific patch to CGPoint is as close to benign as it is possible to get. It’s cleaner in that it allows our code to consistently use latitude and longitude messages rather than digging into implementation details of the receivers of the message. As such, any fix should be transparent to our code and the patch can be removed by deleting a single file. Relying on all receivers of latitude and longitude to understand array-style positional accessing seems far riskier and would have wide fan-out in our code. But then again, I’m old Smalltalker.

Bill Felton bill.felton@driverontap.com Chief Technical Officer / Director of Software Development DriverOnTap 934 Clark Street Lansing, MI, 48906

This electronic message and all contents contain information from the sender which may be privileged, confidential or otherwise protected from disclosure. The information is intended to be for the addressee only. If you are not the addressee, any disclosure, copy, distribution or use of the contents of this message is prohibited. If you have received this electronic message in error, please notify us immediately and destroy the original message and all copies.

On Dec 5, 2014, at 12:35 PM, Ryan Romanchuk notifications@github.com wrote:

Monkey patching CGPoint is not cleaner, but then again, this is RM.

— Reply to this email directly or view it on GitHub.

[sajoku]

http://hipbyte.myjetbrains.com/youtrack/issue/RM-638 states that this is fixed in 3.0. I'm running 3.1 but encounter the same issue as described above. Anybody else also seeing the same behaviour?