Objective-C has an optimization where creating an empty dictionary would
return the same instance every time (probably to a constant empty
dictionary).
This causes a problem with how we've bound generic dictionaries, because
all
empty dictionaries would have the same native handle, even if we'd bound
them
with different managed types.
This surfaces in unfortunate ways when we try to look up a managed
instance
given a native handle, we find that we already have a managed instance,
but
the managed instance is of the wrong type.
Example code:
var a = new NSDictionary ();
var b = new NSDictionary<NSString, NSString> ();
var c = new NSDictionary<NSString, NSObject> ();
Console.WriteLine ($"a: 0x{a.Handle:X}");
Console.WriteLine ($"b: 0x{b.Handle:X}");
Console.WriteLine ($"c: 0x{c.Handle:X}");
would produce something like:
a: 0x0x7fff80821080
b: 0x0x7fff80821080
c: 0x0x7fff80821080
now for this code:
Runtime.GetNSObject<NSDictionary<NSString, NSString>> (b.Handle)
it would throw an exception like this:
Unable to cast object of type
'Foundation.NSDictionary`2[[Foundation.NSString],[Foundation.NSObject]]'
to type
'Foundation.NSDictionary`2[[Foundation.NSString],[Foundation.NSString]]'
because we'll have the 'c' object (with type `NSDictionary<NSString,
Object>`)
in our dictionary of native handles -> managed instances, and that's not
compatible with the desired return type from GetNSObject
(`NSDictionary<NSString, NSString>`)
This likely happens with all the non-mutable collection types we have a
generic version of (NSArray, NSDictionary, NSOrderedSet, NSSet).
Fixes https://github.com/xamarin/xamarin-macios/issues/16378.
Fixes https://github.com/xamarin/xamarin-macios/issues/13704.
This PR is somewhat simpler to review by ignoring whitespace:
https://github.com/xamarin/xamarin-macios/pull/16491/files?w=1
Backport of #16491
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Objective-C has an optimization where creating an empty dictionary would
return the same instance every time (probably to a constant empty dictionary).
This causes a problem with how we've bound generic dictionaries, because all
empty dictionaries would have the same native handle, even if we'd bound them
with different managed types.
This surfaces in unfortunate ways when we try to look up a managed instance
given a native handle, we find that we already have a managed instance, but
the managed instance is of the wrong type.
Example code:
var a = new NSDictionary ();
var b = new NSDictionary<NSString, NSString> ();
var c = new NSDictionary<NSString, NSObject> ();
Console.WriteLine ($"a: 0x{a.Handle:X}");
Console.WriteLine ($"b: 0x{b.Handle:X}");
Console.WriteLine ($"c: 0x{c.Handle:X}");
would produce something like:
a: 0x0x7fff80821080
b: 0x0x7fff80821080
c: 0x0x7fff80821080
now for this code:
Runtime.GetNSObject<NSDictionary<NSString, NSString>> (b.Handle)
it would throw an exception like this:
Unable to cast object of type 'Foundation.NSDictionary`2[[Foundation.NSString],[Foundation.NSObject]]' to type 'Foundation.NSDictionary`2[[Foundation.NSString],[Foundation.NSString]]'
because we'll have the 'c' object (with type `NSDictionary<NSString, Object>`)
in our dictionary of native handles -> managed instances, and that's not
compatible with the desired return type from GetNSObject
(`NSDictionary<NSString, NSString>`)
This likely happens with all the non-mutable collection types we have a
generic version of (NSArray, NSDictionary, NSOrderedSet, NSSet).
Fixes https://github.com/xamarin/xamarin-macios/issues/16378.
Fixes https://github.com/xamarin/xamarin-macios/issues/13704.
Implemented the interfaces for NSOperatingSystemVersion, can now compare
instances and check for equality using operators.
Fixes#15721
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Looks like some of these tests are working in the simulator now.
I also confirmed that ARReferenceObjectTest.MarshallingTest test should be
ignored in the simulator by verifying that Xcode gets the same behavior we do
(i.e. it doesn't work).
Fixes https://github.com/xamarin/xamarin-macios/issues/9531.
For NSArray, implement:
* A ToArray () method that returns an NSArray[].
* A ToArray<T> () method that returns a T[].
* The IEnumerable<NSObject> interface.
For NSArray<T>, implement:
* A ToArray () method that returns a T[].
This should make NSArray much better to work with from managed code.
* Change EnumerateGateways to use the 'static_EnumerateGatewaysHandler'
callback. It looks like this was a c&p error, since the
'static_EnumerateGatewaysHandler' callback was implemented, just never
referenced anywhere.
* Add an overload to EnumerateGateways and EnumerateInterfaces that takes a
callback that returns a bool indicating whether the enumeration should
continue. This mirrors the native API.
* Obsolete the EnumerateGateways and EnumerateInterfaces overloads that take a
void callback (and remove in XAMCORE_5_0).
* Add a test for EnumerateGateways that works (the previous failed, but never
asserted the failure, so it would just silently time out).
Fixes https://github.com/xamarin/xamarin-macios/issues/13772.
Context: dotnet/runtime#68610
Context: https://github.com/xamarin/xamarin-android-tools/commit/0be567a9
In Mono and .NET prior to .NET 8, the
[`System.Environment.SpecialFolder`][0]`.Personal` enum value would refer to
`$HOME` on Unix platforms.
This will be changing in .NET 8, such that
`Environment.SpecialFolder.Personal` will instead refer to
`$XDG_DOCUMENTS_DIR` (if set) or `$HOME/Documents`. This is for "semantic
compatibility" with .NET on Windows.
Replace usage of `Environment.SpecialFolder.Personal` with
`Environment.SpecialFolder.UserProfile`, so that our code continues to work as
expected under .NET 8.
[0]: https://docs.microsoft.com/en-us/dotnet/api/system.environment.specialfolder?view=net-6.0
This PR has the AVKit updates and introduces the AVRouting bindings that
are interconnected with AVKit
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
**Note:** This PR is almost entirely of manual (but simple) bindings, and the documentation of these CG methods is non-existent. I had to add add MarshalAs and change pointers to IntPtr by hand, so please review carefully.
I wrote "did not crash/return null" manual tests, which I could improve upon if desired, but I'd have to re-learn some matrix math and figure out what each method does under the hood (Alex thought this would likely be fine).
A few important notes:
- CGAffineTransformComponents is in CoreFoundation as it was defined (but not used) in those API diffs. There is a define `CF_DEFINES_CGAFFINETRANSFORMCOMPONENTS` which allows CoreGraphics to declare it in the headers, but I'm assuming that is a hack for Apple.
- The headers/docs for kCGColorSpaceITUR_709_HLG lie and claim it's in older OS than it seems to be, so I assumed latest instead.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* [xcode14] Bump to latest Xcode 14 Beta 5
* [CloudKit] Fix cloudkit intro on tvOS
* Revert "[Tests] Fix an monotouch-test test that landed broken. (#15503)"
This reverts commit 161de84bcf.
* Update tools/common/StaticRegistrar.cs
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* Fix typo
* [CHIP] Tell our drivers to not link CHIP at all
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
When we changed SCNMatrix4 to be column-major instead of row-major in .NET, there
were several other related changes we should have done but didn't do. In particular
we should have made transformation operations based on column-vectors instead of
row-vectors.
In legacy Xamarin, a vector would be transformed by a transformation matrix by doing
matrix multiplication like this:
[ x y z w] * [ 11 21 31 41 ]
| 12 22 32 42 |
| 13 23 33 43 |
[ 14 24 34 41 ]
In this case the vector is a row-vector, and it's the left operand in the multiplication.
When using column-major matrices, we want to use column-vectors, where the vector
is the right operand, like this:
[ 11 21 31 41 ] * [ x ]
| 12 22 32 42 | | y |
| 13 23 33 43 | | z |
[ 14 24 34 41 ] [ w ]
This affects numerous APIs in SCNMatrix4, SCNVector3 and SCNVector4:
* The M## fields have been changed to make the first number the column and the
second number the row, to reflect that it's a column-major matrix (this is
also how it's defined in the native SCNMatrix4 type).
* Functions that return a transformation matrix have been modified to return column-vector
transformers. Technically this means that these matrices are transposed compared
to legacy Xamarin. The functions involved are:
* CreateFromAxisAngle
* CreateRotation[X|Y|Z]
* CreateTranslation
* CreatePerspectiveFieldOfView
* CreatePerspectiveOffCenter
* Rotate
* LookAt
* Combining two column-vector transforming transformation matrices is done by multiplying
them in the reverse order, so the Mult function (and the multiplication operator)
have been modified to multiply the given matrices in the opposite order (this matches
how the SCNMatrix4Mult function does it). To make things clearer I've changed the
parameter names for XAMCORE_5_0.
* Functions that transform a vector using a transformation matrix have been modified
to do a column-vector transformation instead of a row-vector transformation. This
involves the following functions:
* SCNVector3.TransformVector
* SCNVector3.TransformNormal
* SCNVector3.TransformNormalInverse
* SCNVector3.TransformPosition
* SCNVector4.Transform
* Numerous new tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/15094.
* Validating Null ignores and adding tests
* add nullability
* use is null
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
dlopen is broken in the latest OS versions: if you pass the path to a symlink, dlopen
will (re)open the target file even if the target file is already loaded (presumably
using the real path and not the symlink).
I've worked around it by redirecting DllImports to libobjc.dylib and libSystem.dylib
to the corresponding real path, and also updating some of our constants to point
to the real path and not a symlink.
The workarounds only work for .NET, legacy Xamarin would need a fix in Mono to
not dlopen "libc.dylib" here (and instead load "libSystem.B.dylib"):
f354099a6b/mono/metadata/w32file-unix.c (L4953)
Ref: https://github.com/xamarin/maccore/issues/2585.
Make our local .NET the default .NET (in the root's global.json), and then if
a directory wants to use the system .NET, then that directory would have to
opt-in (using its own global.json).
This way we don't have to copy global.json/NuGet.config files around to run
tests with the correct .NET setup.
* Confirm nullability in the ignore files
* use is null and is not null
* Remove unnecessary using statements for test
* undo the changes to the csproj
* remove monotouch-test.sln
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
* go through the nullable ignores and add test
* Enable Nullability
* use is null
* save a few lines
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
* Handle 502 and 503 errors in the TrustUsingOldPolicy and TrustUsingNewCallback tests. Fixes:
[FAIL] TrustUsingOldPolicy : System.Net.WebException : The remote server returned an error: (503) Service Unavailable.
[FAIL] TrustUsingNewCallback : System.Net.WebException : The remote server returned an error: (503) Service Unavailable.
* Add more http and https urls to try (and don't use microsoft.com). Hopefully fixes:
[FAIL] WebClient_SSL_Leak : At least one url should work
This is a follow-up to #14943.
* A few tests seem to be failing rather consistently with network errors.
Rewrite these tests to try multiple urls before failing (we'll be assuming
that if one of the urls succeed, the other failures were network related).
* Rename the LinkAnyTest.WebClientTest to LinkAnyTest.WebClientTest_Http to
follow it's original intent, and make it test http instead of https.
* Remove unnecessary assertion from SSL_IP_5706. This is tested in plenty of other places.
Bots seems to break more often after this change, so let's see if this improves matters.
This is what happens with the bots:
We stopped hearing from agent [...]. Verify the agent machine is running and has a healthy network connection. Anything that terminates an agent process, starves it for CPU, or blocks its network access can cause this error. For more information, see: https://go.microsoft.com/fwlink/?linkid=846610
I'm very pleased to present full bindings to the MetalPerformanceShadersGraph framework!
I'm happy with how everything turned out with the exception of a few notes and questions below.
I re-implemented Apple's MNIST sample (from https://developer.apple.com/documentation/metalperformanceshadersgraph/training_a_neural_network_using_mps_graph) here:
https://gist.github.com/praeclarum/b8077771fb341a1f9c28240113e00425
It's also added as a unit test.
Fixes#14286
### Notes
* Although the API says it works on macOS 11, it has bugs and crashes with errors even with Apple’s Swift examples. It’s better on macOS 12. iOS 14 and on is fine.
* `MPSGraphSparseStorageType` has terrible names. They match Apple's but I wish they were better.
* I added convenience methods to `MPSNDArray` and `MPSGrapTensorData` and the `Variable` and `Constant` operations to decrease the amount of unsafe code users have to write. I currently do this for 32-bit floats, the most common data type.
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
We already have a few attributes that can specify the native name for a type, whenever the native name doesn't match the managed name:
* [Register ("DifferentClassName"): specifies the Objective-C class name
* [Native ("DifferentEnumName")]: specifies the Objective-C enum name (and also that it's a native-sized enum)
* [Protocol ("DifferentProtocolName")]: specifies the Objective-C protocol name
* [Category ("DifferentCategoryName")]: specifies the Objective-C category name
Unfortunately this leaves (at least) two cracks:
* Objective-C structs.
* Objective-C enums which aren't native-sized.
So I'm adding a [NativeName] attribute for this purpose, and updating numerous
types to specify the native name (either using an existing [Native] attribute
for enums that already have one, or by adding a new [NativeName] attribute).
The static registrar needs to know the native name for such types, in case
they appear as parameter types in function signatures.
This also allows us to simplify xtro a bit, to not have a separate map of
managed name given a native name, because we can now build that map
dynamically.
* remove null ignores and add nullability
* throw better exception
* use is null
* remove extra ignores
* Add the tests
* use a progma ignore instead
* revert monotouch-test.csproj
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
* adding Nullability
* throw better null exceptions
* use is null
* Added test
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
We can't return unretained INativeObjects to Objective-C, because they might
be freed at any point when the GC collects the managed object. Instead return
retained objects, that way they're not freed even if the GC collects the
managed object.
This fixes a random crash in the TestRegistrar.TestINativeObject when the GC
would run just after we've returned an INativeObject to native code, and later
used that native handle thinking it would still be valid.
Fixes https://github.com/xamarin/maccore/issues/2572.
The headers do not say that a null parameter is allowed, but the
documentation and tests state otherwise:
https://developer.apple.com/documentation/foundation/nsurl/1572047-urlwithstring
The URL string with which to initialize the NSURL object. Must be a URL that conforms to RFC 2396. This method parses URLString according to RFCs 1738 and 1808.
Introduce `FSEventStreamCreateOptions` to avoid a slew of .ctor overrides, and make it easier to specify `DeviceToWatch` and `SinceWhenId`. `SinceWhenId` was previously only exposed on the "low level" .ctor, and it's a rather important parameter for supporting events that may have happened while the application was not running.
Make the existing constructors wrap `FSEventStreamCreateOptions` to avoid API break.
This is a followup to #14318. When using device-relative watches, files can be tracked via a tuple of their device ID and inode instead of paths. #14318 exposes inode data on `FSEvent`.
Implements support for `FSEventStreamCreateFlags.UseExtendedData`, fixing #12007.
When `.UseExtendedData` is specified, the event data type changes from `CFString` to `CFDictionary`; the dictionary contains the path (`path` key) and inode (`fileID` key) information for the file and may be extended in the future with other fields. Previously this was crashing because we assumed `CFString` always.
Further add a convenience constructor for monitoring a single path, add the missing `UnscheduleFromRunLoop` APIs, and add `SetDispatchQueue` to allow using dispatch queues directly instead of run loops.
Finally, this PR adds a fairly exhaustive file system test which covers the existing (non-extended) and fixed (extended) creation modes, along with using a dispatch queue instead of run loop.
Fixes https://github.com/xamarin/xamarin-macios/issues/12007
The new tests do not have a display and that makes certain mac tests
fail. Added a new TestRuntime function to let us know if we are on vsts
and ignore accordingly.
fixes https://github.com/xamarin/maccore/issues/2546
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Fixes two test failures on tvOS with all optimizations enabled:
MonoTests.System.Net.Http.MessageHandlerTest.DnsFailure
[FAIL] DnsFailure(System.Net.Http.SocketsHttpHandler) : Exception
Expected: instance of <System.Net.Http.HttpRequestException>
But was: <System.MissingMethodException: No parameterless constructor defined for type 'System.Net.Http.SocketsHttpHandler'.
at System.RuntimeType.CreateInstanceMono(Boolean , Boolean )
at System.RuntimeType.CreateInstanceDefaultCtor(Boolean , Boolean )
at System.Activator.CreateInstance(Type , Boolean , Boolean )
at System.Activator.CreateInstance(Type , Boolean )
at System.Activator.CreateInstance(Type )
at MonoTests.System.Net.Http.MessageHandlerTest.GetHandler(Type ) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/monotouch-test/System.Net.Http/MessageHandlers.cs:line 50
at MonoTests.System.Net.Http.MessageHandlerTest.<>c__DisplayClass3_0.<<DnsFailure>b__0>d.MoveNext() in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/monotouch-test/System.Net.Http/MessageHandlers.cs:line 76>
MonoTests.System.Net.Http.MessageHandlerTest.RejectSslCertificatesServicePointManager
[FAIL] RejectSslCertificatesServicePointManager(System.Net.Http.SocketsHttpHandler) : System.MissingMethodException : No parameterless constructor defined for type 'System.Net.Http.SocketsHttpHandler'.
at System.RuntimeType.CreateInstanceMono(Boolean , Boolean )
at System.RuntimeType.CreateInstanceDefaultCtor(Boolean , Boolean )
at System.Activator.CreateInstance(Type , Boolean , Boolean )
at System.Activator.CreateInstance(Type , Boolean )
at System.Activator.CreateInstance(Type )
at MonoTests.System.Net.Http.MessageHandlerTest.GetHandler(Type ) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/monotouch-test/System.Net.Http/MessageHandlers.cs:line 50
at MonoTests.System.Net.Http.MessageHandlerTest.RejectSslCertificatesServicePointManager(Type ) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/monotouch-test/System.Net.Http/MessageHandlers.cs:line 405
at System.Reflection.RuntimeMethodInfo.Invoke(Object , BindingFlags , Binder , Object[] , CultureInfo )
The default constructor doesn't work (it's already obsolete).
Fixes:
Xamarin.Mac.Tests.DelegateAndDataSourceTest
[FAIL] DelegateAndDataSourceAllowsNull : 1 failing types
1 failing types:
PassKit.PKPaymentAuthorizationViewController: Could not initialize an instance of the type 'PassKit.PKPaymentAuthorizationViewController': the native 'init' method returned nil.
It is possible to ignore this condition by setting ObjCRuntime.Class.ThrowOnInitFailure to false.
at Xamarin.Mac.Tests.DelegateAndDataSourceTest.DelegateAndDataSourceAllowsNull () [0x0026c] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/monotouch-test/ObjCRuntime/DelegateAndDataSourceTest.cs:90
The [Culture ("en")] attribute means: only run this test if the culture is
"en". This usually meant not running this test (apparently we don't run often
with culture = "en"), leading to outdated tests that happened to fail when
actually run under culture = "en" (such as on older macOS bots).
So change these tests to actually change the culture to "en" (by using the
SetCulture attribute), and also fix them.
VS MobileTools Engineering Service 2
Rolf Bjarne Kvinge
Haritha Mohan
Simon Rozsival
Israel Soto
Manuel de la Pena
TJ Lambert
Chris Hamons
Alex Soto
Frank A. Krueger
Aaron Bockover