Swiftpack.co - Swift Packages by heckj

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. ## Initial API Release - Multiple well-known CRDT types included: - `GCounter`, `PNCounter`, `GSet`, `ORSet`, `ORMap`, and `List` - [Documentation hosted at Swift Package Index](https://swiftpackageindex.com/heckj/CRDT/main/documentation/crdt) - All included CRDT implementations support whole-instance merging and delta-state replication and merging. - APIs for merging include `merged(:_)` which implicitly makes a copy, and `merging(:_)` which modifies an in-place struct. - Corrupted history is identifier and thrown as an error, relevant for `ORSet`, `ORMap`, and `List` types. - Project includes basic benchmarks, [with results available through the GitHub repo](https://github.com/heckj/CRDT/blob/main/Benchmarks/Results.md). - extended conformances for CRDT types, when underlying (and ActorID) types support it: `Codable`, `Hashable`, `Equatable`, and `Sendable` ## What's Changed since the pre-release (0.5.0-alpha1) * Additional checking for error states in merging related, and unrelated, CRDT instances by @heckj in https://github.com/heckj/CRDT/pull/16 * String convertible by @heckj in https://github.com/heckj/CRDT/pull/17 * ORmap by @heckj in https://github.com/heckj/CRDT/pull/18 * Example code baseline by @heckj in https://github.com/heckj/CRDT/pull/19 * additional use cases of replication tests by @heckj in https://github.com/heckj/CRDT/pull/20 * Sendable by @heckj in https://github.com/heckj/CRDT/pull/21 * adding stub article for details about replicating content by @heckj in https://github.com/heckj/CRDT/pull/22 * basic benchmarks by @heckj in https://github.com/heckj/CRDT/pull/23 * Causal Tree List by @heckj in https://github.com/heckj/CRDT/pull/24 * Update .spi.yml by @finestructure in https://github.com/heckj/CRDT/pull/26 ## New Contributors * @finestructure made their first contribution in https://github.com/heckj/CRDT/pull/26 **Full Changelog**: https://github.com/heckj/CRDT/compare/0.5.0-alpha1...0.5.0 Initial alpha release. The pre-release includes an initial implementation, API, and documentation for the raw CRDT data types: - GCounter - PNCounter - LWWRegister - GSet - ORSet The pre-release is intended for feedback on API usage, and should not be considered stable. The delta-state merge methods are set to asynchronous, and both an ORMap and an actor-based replicator wrapper is still pending as of this release. To use this release, add the following dependency to your `Package.swift`: ``` .package(url: "https://github.com/heckj/CRDT.git", from:"0.5.0-alpha1") ```

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. ## What's Changed * Remove duplicate docc-plugin by @finestructure in https://github.com/heckj/CameraControlARView/pull/1 * Updates to make views usable on both macOS and iOS by @sakrist in https://github.com/heckj/CameraControlARView/pull/2 ## New Contributors * @finestructure made their first contribution in https://github.com/heckj/CameraControlARView/pull/1 * @sakrist made their first contribution in https://github.com/heckj/CameraControlARView/pull/2 **Full Changelog**: https://github.com/heckj/CameraControlARView/compare/0.5.0...0.6.0 Initial release version for the CameraControlARView swift package, which provides an ARView subclass for macOS that enables a perspective camera and controls the camera from keyboard, mouse, and trackpad. This lets you get up and running with an "active" view that leverages RealityKit to provide 3D rendering. The view offers control in one of two modes: arc-ball and first person. The `arcball` mode rotates and orbits the camera around a fixed position, where `firstperson` mode allows greater freedom of movement within the 3D rendered environment. The package also includes a SwiftUI container view for hosting this view within SwiftUI.

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. Swift6 compatibility/strict concurrency update When I originally created this package, async/await wasn't yet available. In supporting strict concurrency and the upcoming Swift 6 release, I've updated the Swift language support to require at least Swift 5.8, and changed the API to utilize async/await on the modules that produce results, with either a custom definition file for the Lindenmayer system, or leveraging the stochastic (random choices) features available in some of the Lindenmayer systems. ## Known Issues - there's one remaining Swift6 compatibility issue, complaining that I SwiftUI's [ScrollViewProxy](https://developer.apple.com/documentation/swiftui/scrollviewproxy) isn't `Sendable`, even with a `@preconcurrency` import into the view that uses it (this is in the [LindenmayerViews](https://swiftpackageindex.com/heckj/Lindenmayer/documentation/lindenmayerviews) module). I suspect it will be marked as `Sendable` in the future, but am hesitant to apply my own assertions on that front, so I'm leaving it alone as the final remaining Swift6 compatibility issue. ## What's Changed * use @_exported to expand SwiftUI Angle to be easier to find by @heckj in https://github.com/heckj/Lindenmayer/pull/39 * Experimental skip synthesized symbols by @finestructure in https://github.com/heckj/Lindenmayer/pull/40 * updating swift tooling to prep for Swift 6 concurrency updates by @heckj in https://github.com/heckj/Lindenmayer/pull/41 * Concurrency lockdown by @heckj in https://github.com/heckj/Lindenmayer/pull/42 ## New Contributors * @finestructure made their first contribution in https://github.com/heckj/Lindenmayer/pull/40 **Full Changelog**: https://github.com/heckj/Lindenmayer/compare/0.7.3...0.8.0 ## What's Changed * removing Squirrel3 dependency by @heckj in https://github.com/heckj/Lindenmayer/pull/36, which allows for Lindenmayer to be used within Swift Playgrounds as it's now all pure-swift code (no C-based dependencies) **Full Changelog**: https://github.com/heckj/Lindenmayer/compare/0.7.2...0.7.3 ## What's Changed * updating 3D rendering by @heckj in https://github.com/heckj/Lindenmayer/pull/30 * Roll to vertical by @heckj in https://github.com/heckj/Lindenmayer/pull/32 * Updating documentation for Lindenmayer by @heckj in https://github.com/heckj/Lindenmayer/pull/31 * final tweaks to resource locations by @heckj in https://github.com/heckj/Lindenmayer/pull/34 * fixes for updates in dependency modules that are pre-release **Full Changelog**: https://github.com/heckj/Lindenmayer/compare/0.7.1...0.7.2 ## What's Changed * module cleanup, normalizing rendering commands by @heckj in https://github.com/heckj/Lindenmayer/pull/23 * Faster iteration by @heckj in https://github.com/heckj/Lindenmayer/pull/24 * Debug view by @heckj in https://github.com/heckj/Lindenmayer/pull/28 **Full Changelog**: https://github.com/heckj/Lindenmayer/compare/0.7.0...0.7.1 **BREAKING CHANGES** Writing rules ergonomic updates: The process of writing LSystems has been improved by including factory/wrapper methods on the various types of LSystems (basic, RNG, Parameters, RNG+Parameters), and now all the rules are explicitly typed. This in turn allows for the closures that produce the rewriting for the relevant modules to be explicitly typed, so there's no longer a need to down-cast from the existential Module type into the specific kind of module in order to use the types parameters when computing what replaces it. The rules all now also have additional evaluation criteria enabled through an optional (typed) closure so that you can choose if rules are activated not only by the types they match, but in addition with a closure that you provide that can interrogate the modules that were matched. (2021-12-23) The initial release of Lindenmayer. The library supports creating context-free and contextual parametric L-systems. Built-in modules support 2D and basic 3D visualizations, and some reference implementations of previously described L-systems. The API is by no means finished, complete, or in a final form. There are several places where I'm considering how to make creating L-systems written in the Swift language more ergonomic, and additional features that I want to add for broader support (such as stochastic production rules). This edition is suitable for experimentation, and I certainly welcome feedback in the [discussion section](https://github.com/heckj/Lindenmayer/discussions) of the [Github repository](https://github.com/heckj/Lindenmayer/). **Full Changelog**: https://github.com/heckj/Lindenmayer/commits/0.5.0

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. ## What's Changed * Adding RealityKit support by @heckj in https://github.com/heckj/MeshGenerator/pull/1 * Export by @heckj in https://github.com/heckj/MeshGenerator/pull/2 **Full Changelog**: https://github.com/heckj/MeshGenerator/compare/0.5.1...0.6.0 **Full Changelog**: https://github.com/heckj/MeshGenerator/compare/0.5.0...0.5.1 Very minor changes - some improved documentation, and more explicit platform support identified (watchOS, tvOS) for when this library is consumed as a dependency. ### Initial Release MeshGenerator is partially derived from [Euclid](https://swiftpackageindex.com/nicklockwood/Euclid), with sections of the code used under license (MIT) from that project, with modifications: - The underlying computations for vectors, normals, etc from this library use [`simd`](https://developer.apple.com/documentation/accelerate/simd) from the [`Accelerate`](https://developer.apple.com/documentation/accelerate) framework, if available. - The API provides support for building meshes from triangles, not other general types of polygons (quads, or higher order polygons). MeshGenerator provides the basic types and concepts needed to generate geometries for use in Apple 3D rendering. The library is intended to be a component that can be used to build geometries, and not a source of geometries itself. If you want to work with quads or higher order polygons, or use constructive solid geometry, please look into [Euclid](https://swiftpackageindex.com/nicklockwood/Euclid), which supports generating geometries from paths and text, constructive solid geometry, as well as geometric primitives. The initial release provides API support for SceneKit.

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days.

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. - Updates Squirrel3 with a new `SeededRandomNumberGenerator` protocol, which formalizes the ability to see a random number generator (specifically with a UInt64 seed), and references a constant `seed` property and a variable `position` property for the generator. - updated Squirrel3 implementation to mutate on the position and keep the initial seed constant. With the two values together, the `next` generated random value is deterministic. - adds tests to verify the determinism as well as seed and position values. - fixed public access to the swift PRNG struct under Squirrel3 - added basic DocC comments - added test suite to validate fairness and randomness of Squirrel3 Squirrel3 PRNG based on Squirrel Eiserloh's hash noise function.