### Motivation:
To allow for things like parallel testing, it'd be useful if we can
explicitly provide a MetricsFactory to the existing Counter/... types.
### Modifications:
Added a `factory: MetricsFactory` parameter to all the initializers of
Counter/... types, and kept the existing methods that continue to
default to `MetricsSystem.factory`.
### Result:
Adopters can use a custom MetricsFactory explicitly passed in at metric
creation time. Existing adopters are not affected, unless you opt in,
you continue to use the global factory.
Specifically Swift 5.10 on Intel on Ubuntu Noble (24.04) has a crazy bug
which leads to compilation failures in a #if compiler(>=6.0) block:
swiftlang/swift#79285 .
This workaround fixes the compilation by changing the whitespace.
Fixes https://github.com/apple/swift-metrics/issues/166
# Motivation
This PR supersedes https://github.com/apple/swift-metrics/pull/135. The
goal is to make it easier to measure asynchronous code when using
`Metrics`.
# Modification
This PR does:
- Deprecate the current static method for measuring synchronous code
- Add a new instance method to measure synchronous code
- Add a new instance method to measure asynchronous code
Our README claims we support 4 metric types, and then lists five. But it
fails to list FloatingPointCounter, which we also support, so the real
number is six.
While I was here I also fixed the DocC topic, which omitted
FloatingPointCounter from the list of metrics but _also_ omitted Gauge
for some weird reason.
This PR makes the single `import Android` addition that is needed to get
this package building for Android. `skip android test` passes against
the emulator after I made this one change.
* Update API breakage CI script
* restate sendable conformance to avoid warning/as-error
---------
Co-authored-by: Konrad `ktoso` Malawski <konrad_malawski@apple.com>
# Motivation
Most of the server ecosystem follows the supported Swift versions from `swift-nio`. This means supporting the latest 3 Swift releases.
# Modification
This PR drops support for all Swift versions before 5.8.
# Result
This makes maintaining this repository easier and allows us to clean up some no longer needed stuff.
Motivation:
`Duration` is available starting Swift 5.7, and we
should probably support it in our convinience API.
Modifications:
- Timer.record(_ duration: Duration) implementation
- A unit test case
- Generated Linux tests
motivation: expose increment and decrement public APIs
changes:
* add increment and decrement public API to Meter
* improve the implementation of AccumulatingMeter and TestMeter
* add tests for new APIs
* refactor/modernize other tests
motivation: seperate gauge from recorder in a backwards compatible way
changes:
* add new meter and meter handler pair
* add increment and decrement to meter handler
* add default implementation based on recorder for backwards compatibility
* add and adjust tests
* +docc prepare for docc publishing
* fix test discovery on 5.5 and 5.6
* Delete Package@swift-5.6.swift
* Update Package.swift
* Apply suggestions from code review
Co-authored-by: Yim Lee <yim_lee@apple.com>
Co-authored-by: Yim Lee <yim_lee@apple.com>
motivation: adjust to swift 5.6
changes:
* define sendable shims for protocols and structs that may be used in async context
* refactor Gauge to include rather than inherit Recorder
* adjust tests
* add a test to make sure no warning are emitted
motivation: prepare for sendable checks (they dont work well with static state)
changes:
* abstract the MetricsSystem state into a "boxed" class that handles the locking
* adjust call sites
motivation: It is not currently possible to record floating point values via the swift-metrics API even if the metrics backend supports it.
modifications: Adds a `FloatingPointCounter` type to allow users to accumulate non-integral metrics backed by a `FloatingPointCounterHandler`. Introduces a default implementation for creating and destroying `FloatingPointCounterHandler`s for metric backends that do not natively support floating point counters. On such backends, `FloatingPointCounter` is backed by a `AccumulatingRoundingFloatingPointCounter` which accumulates floating point values internally and record increments to a wrapped `CounterHandler` after crossing integer boundaries.
result: Users can create `FloatingPointCounter`s to record floating point values and get enhanced behavior for backends that support floating point values.
Motivation:
I have a metrics backend where I need to store timer values in
microseconds. The "preferred display unit" models this exactly, but it
seems to have (inadvertently?) omitted the possibility to express
microseconds. Note that among the timer "report" methods there is
already a microseconds option.
Changes:
* change TimeUnit from enum to struct with static members to support non-api breaking future evolution
* add scaleFromNanoseconds to TimeUnit to make it easy to compute the values without switching over
* add tests
Co-authored-by: Chris Burrows <cburrows@gmail.com>
MetricsSystem.bootstrap verifies that the metric system has not been previously
initialized. Otherwise it should fail with a corresponding error message. The
precondition error message includes the name of the currently used factory and
for that accesses self.factory. However, because bootstrap already holds
self.lock as a writer lock, self.factory fails to get it as a reader and
crashes with a less useful precondition error message. This commit ensures that
the correct error message is printed.
motivation: adjust format to xcode format
changes:
* update .swiftformat no-indent setting and run formatter
* update test generation script to match correct format
motivation: some metrics backend prefer to be given a hint about the preferred display unit (seconds, milliseconds, etc) to drive the ux
changes: add a `preferedUnit` to TimerHandler (and `TimeUnits`) to capture the prefer display unit
motivation: define record() more explicitly that it is a "set the value" operation as it seemed to be confusing when implementing or using the API.
changes: update API docs accordingly
motivaiton: unified format
changes:
* use official docker image 🎉
* fix outstanding formatting issues
* add a call to swiftformat as part of sanity script
* fix sanity script language check debugging statements
Motivation:
As discussed in Issue #28, there are a few preferred lightweight APIs for getting timestamps such as `DispatchTime` but those APIs return `UInt64` types, which need to be handled for overflow.
Modifications:
Added a generic `BinaryInteger` overload method for `recordNanoseconds` that guards against accidental overflows from `UInt64` to `Int64`
Result:
Users now have access to a new method to record nanosecond measurements with `Timer` that guards against overflows.
Motivation:
`Timer.record*` methods are generic to cover all cases of `BinaryInteger` values and converts the passed value into `Int64` before doing time unit conversions and overflow checks.
Modifications:
All methods that accept `BinaryInteger` types and converts to `Int64` now guards against values higher than `Int64.max`
Result:
Users can reliably use the `Timer.record*` APIs with `BinaryInteger` types without concern for unknowing fatal errors.
* doc: #26 clarify which init to use, reformat docs for easier noticing this
* Mark all "we do not expect this API to be used in normal..." as warnings
Motivation:
API documentation contains typos and grammatical errors.
Modifications:
Fix typos and grammatical errors. Update to use code syntax where
appropriate.
Result:
Eliminate typos and grammatical errors found.
Honza Dvorsky
Franz Busch
Cory Benfield
Marc Prud'hommeaux
Rick Newton-Rogers
Gustavo Cairo
Konrad `ktoso` Malawski
hamzahrmalik
Si Beaumont
Franz Busch
Natik Gadzhi
tomer doron
hamzahrmalik
Fabian Fett
Gustavo Cairo
Konrad `ktoso` Malawski
Rauhul Varma
Jari (LotU)
Konrad `ktoso` Malawski
Moritz Lang
Christian Priebe
tomer doron
Nathan Harris
Nathan Harris
Yim Lee