This change moves the RADIX_TYPE enum into its own header. This resolves a compilation error and reduces the dependency graph by allowing RadixToStringConverter to include just the enum header rather than the entire CalcEngine header.
Change verified by ensuring Calculator build locally.
* Converts NumObj* functions to use Rationals. Places new functions under CalcEngine::RationalMath namespace
* Moves functions that correspond to an operator to the Rational class with intent to convert to operators in the future
* Consolidates use of RatPack's NUMBER and RAT data types to Number/Rational classes and RationalMath namespace.
* Move build jobs to the Hosted VS2017 pool instead of our internal pool
* Move the prepare-release-internalonly job from a team-specific pool to a shared pool with more capacity
* Remove symbol publishing from PR/CI builds since it's not necessary; do it only in release builds
Before this change, the pchs for CalcViewModel and Calculator project referenced project headers. If those project headers (or any of their dependencies) were to change, then the pch would be recompiled, slowing local build times.
By removing references to project headers, the pch will be compiled once and is resilient to changes in the project. Now that project headers are explicit about their dependencies, when there is a change to a project header only the translation units referencing the modified header will need to be rebuilt.
- Manually tested by ensuring Calculator project builds locally.
@Microsoft/calculator-team
Update the Microsoft.UI.Xaml NuGet package to a new version. The ARM64 framework package in 2.0.181018003.1 had entries missing from its manifest, so the classes in the package couldn't be activated.
The app currently logs diagnostic events to ETW in various places. If we add certain flags to those events, the data is eligible to be sent as telemetry. (Whether it actually gets sent is controlled outside of Calculator--for example, there are lots of checks at the system level to ensure privacy settings are honored.)
Currently we set the "eligible for telemetry" flags only in official builds, so no telemetry gets uploaded while the app is in development. We already have this set up for the main TraceLogging provider, but we also need to do this for the AppLifecycle performance logging.
Calculator (the main app project) depends on CalcManager, but only transitively: Calculator -> CalcViewModel -> CalcManager.
However, Calculator's project file currently has a direct dependency on CalcManager. Let's remove this to make it harder to accidentally introduce new dependencies between the layers.
Also cleaning up some commented-out directives in the CalcManager MSBuild file.
A few small changes to improve the view of the code in Solution Explorer:
* Delete folders from solution explorer which don't appear on disk (Resource Files, PerfTrack)
* Delete files on disk which aren't compiled into the project (Type.xaml)
* Rename CalculatorHistory.Cpp to CalculatorHistory.cpp, for consistency with other files
Remove LayoutAwarePage, SuspensionManager, and other suspend-resume handling code. SuspensionManager::SaveAsync and related methods weren't actually called anywhere. I didn't attempt to remove the serialize/deserialize code at the ViewModel layer, although much of that is likely not needed either.
We may decide we want to persist more state through a suspend-terminate-resume cycle (as the app might have done a long time ago). But if we decide we want that, we should not use a persistence mechanism that's closely coupled to frame navigation.
Stephanie Anderl
Josh Koon
Matt Cooley
Daniel Belcher
Howard Wolosky
Pepe Rivera
Pepe Rivera
David Grochocki
Matt Cooley
Microsoft Open Source
Microsoft GitHub User