Collect diagnostic logs from the simulator to try to get better diagnostic information for https://github.com/xamarin/maccore/issues/2558.
Interestingly it seems like just collecting diagnostic information makes the problem much less likely to occur...
Tests work because other tests do use the nugets and gets picked up by
the runner. Yet, if we execute this projects witjout others, the tests
will fail when trying to use the nunit2 format.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
The job that hides the previous bot comments tries to find comments with
[OR\CI build] to decide if a comment should be hidden. This is added
when a title is present, so we just add a titles so that we can hide the
comments.
Note that the call to native code still _always_ happen (not cached) since the application could use `class_addProtocol` to add conformance to a protocol at runtime.
So the cache is limited to the .net specific reflection code that is present (only) when the dynamic registrar is included inside applications. This is the default for macOS apps, but not iOS / tvOS or MacCatalyst apps.
The linker/trimmer will remove the caching code when the dynamic registrar is removed. IOW this PR should not have any impact, performance or size, for most iOS apps (where the dynamic registrar is removed by default).
Fix https://github.com/xamarin/xamarin-macios/issues/14065
Running Dope on macOS, a 2 minutes benchmark, shows the following times (in seconds and percentage) spent calling this API:
## Before
<img width="1051" alt="Screen Shot 2022-06-15 at 9 21 22 PM" src="https://user-images.githubusercontent.com/260465/174201703-a91860a5-ec29-4e19-9de0-5158fd7aafa7.png">
* `RemoveFromSuperview` 7.99s (6.4%)
* `NSObject.ConformsToProtocol` 3.26s (2.6%)
## After
<img width="1228" alt="Screen Shot 2022-06-15 at 9 24 42 PM" src="https://user-images.githubusercontent.com/260465/174201708-92193e77-ea8e-41bc-9672-bddaaa18a4f6.png">
* `RemoveFromSuperview` 4.67s (3.8%)
* `NSObject.ConformsToProtocol` 0.32s (.26%)
So a 10x improvements on `ConformsToProtocol` which helps a lot the code path calling `RemoveFromSuperview`.
This makes it not necessary to check for the currently selected Xcode in our
system dependency check. It also means it'll become much easier to work with
multiple branches simultaneously where each branch needs its own Xcode.
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.
* Enable Nullability
* throw better exceptions
* use is null
* Style fixes
* address Rolf suggestions
* use better syntax
* make properties private and use ActualOpenGLContext
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
This was mostly a clean merge, with a few minor differences:
* We no longer compute whether we're running in the simulator or not when building for Mac Catalyst.
* The task now supports building remotely for macOS (due to code sharing).
Will be useful if we ever support building macOS apps remotely.
* We now call AppleSdkSettings.Init () on macOS. No idea why we weren't
before, but it seems logical for macOS to behave like our other platforms.
There shouldn't be any other functional differences.
* 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>
* Add nullability
* throw better exceptions
* use is null
* revert a new throw
* remove unused ConstructionError Exception
* started the nullable gethandle changes
* Update the nullable NSStrings
* revert the bool property nullability and other small fix
* Remove extra indentation
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Apple removed the -z / --minimize option in Xocde 13.3, so now if you use it
you get a warning: "ignoring unknown option: -z".
So just don't pass -z when using Xcode >= 13.3
Ref: https://github.com/dotnet/runtime/issues/66770
Ref: 5d07dc8977
We're putting all packages in the xamarin-macios/packages directory, and that
includes the nunit3-console package, so we need to point these shell scripts
that way.
Also make them behave the same with regards to stsack traces and the --debug
option to mono.
There is no need to provision the simulators on a build. Provisioning
simuatlors is giving problems with the EO pool after an upgrade to macOS
12.4.
We remove the provisioning from the build BUT not from the tests since
those tests are executed in non EO complient machines.
* ensure that outside invocations of IntPtr constructors will work correctly
* Remove E0017 and ignore such constructors instead of hard erroring, they exist in real life
Deciding if we build a PR or not used to be more complicated since we
had to make the diff between a CI build and a PR build. Now, since we
added diff pipelines we do not longer need to check any variable since
we can use a parameter.
This new fact makes the decision making simpler (although forces use to
add a new parameter in a few templates). The overall result is a simple
way to decide what can be used or not in the pipeline.
* Simplify logic.
* Add missing param.
* Fix the checkout for signing in the pr build.
* There is not need to sign in PR builds.
The signature is not needed for the tests and using -s in codesign means
that it is only valid in the machine that signed it.
Only sign the prebuilt hotrestart app in CI, to avoid making it required for
developers to configure code signing.
Also fix DetectSigningIdentity to not require a code signing certificate for
device builds when RequireCodeSigning is false.
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
* Ignore anything Chip-related, the framework was removed from macOS.
* Fix reporting errors some protocol-related errors so that they're actually
reported as errors (by calling 'ReportError' instead of just adding the
errors to a list that doesn't affect anything else).
* Ignore the NSUserActivityRestoring protocol, according to the macOS headers
it's attached to NSResponder using a category, which is invisible at
runtime. Due to the previous point this didn't show up before, but once at
least another error (which happened with the Chip framework), then this was
listed as well.
* Add ignores for a couple of protocols.
Fixes https://github.com/xamarin/xamarin-macios/issues/15229.
Rolf Bjarne Kvinge
Manuel de la Pena
nathannaveen
Sebastien Pouliot
github-actions[bot]
TJ Lambert
Steve Hawley
David Ortinau
