Pyre

Latest version: v1.12.5

Safety actively analyzes 685670 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 1 of 4

1.12.5

This is an update with small bug fixes and enhancements, the most notable of which is support for `enum` types in `h5`.

What's Changed
* cmake: set the include directories for {cuda} and {cudamodule} by biancagi in https://github.com/pyre/pyre/pull/112


**Full Changelog**: https://github.com/pyre/pyre/compare/v1.12.4...v1.12.5

1.12.4

This release is mostly about enhancements and cleanup of `libpyre` and `libjournal`:

- The new `pyre::flow` namespace contains the basic support for building data processing workflows. It is a pure C++ implementation of the ideas in `pyre.flow`, and will eventually become the foundation on which the python package is built. While still in the early stages of development, it is capable of expressing complicated dependency graphs with a relatively frictionless interface. The focus has been on running large datasets through the graph, but there is support for computing efficiently with nodes that carry small data packets.
- The support for visualizing rasters in `pyre::viz` was reimplemented using `pyre::flow` nodes. The new implementation uses arbitrarily shaped data tiles at each stage of the visualization pipeline, enabling a very powerful caching mechanism when needed. The data products and factories are templated on data types and storage mechanisms, making it easy to adopt the engine to a variety of computing contexts. The old implementation got an extensive makeover and is now in `pyre::viz::iterators`.
- The new `pyre::cuda::memory` namespace contains allocators for all CUDA memory models. They are modeled after the ones in `pyre::memory`. This normalizes the allocation interface and allows higher level objects, such as `pyre::grid` instances, to be built on top of CUDA memory wherever permitted. The code was generously donated by SebastiaanVanPaasen and biancagi; many thanks!
- Several holes to the interface of the `null_t` channel in `journal` were plugged to eliminate errors seen when channels like `debug_t` and `firewall_t` are optimized away.

At the python level:
- The support for h5 saw several improvements: new bindings for property lists, including creation and access lists for files and datasets, as well as support for attributes. There was a thorough investigation of ways to optimize access to h5 files in S3 buckets with spectacular results.
- There is now a new `smith` template for bootstrapping `basic` projects.

On the housekeeping front:
- There is now a home for `benchmarks` to host code that tests complex capabilities or measures implementation performance. These are essentially test drivers that are built on demand and not a part of the normal build of the code.
- There were many enhancements in the support for building with 'mm' and 'cmake', in the generation of `docker` images, on the way GitHub actions run the project CI, as well as the generation of binary distributions for `pypi` and `conda-forge`

Finally, this release contains an embedding of the `mm` build system as it is being absorbed by `merlin`. The goal is to eventually automate the build for all projects that are built on `pyre` without the need to clone any other repositories.


What's Changed
* Added support for flow diagrams by aivazis in https://github.com/pyre/pyre/pull/110
* Memory allocators for CUDA pinned and mapped memory by biancagi in https://github.com/pyre/pyre/pull/98


**Full Changelog**: https://github.com/pyre/pyre/compare/v1.12.3...v1.12.4

1.12.3

This is another housekeeping release, this time with focus on publishing source and wheels to PyPI. In addition, the `mm` action was repaired and all is once again well.

**Full Changelog**: https://github.com/pyre/pyre/compare/v1.12.2...v1.12.3

1.12.2

This maintenance release fixes the `cmake` build that was excluding some source files and causing unresolved symbols in the `h5` bindings.

It also includes some housekeeping in the GitHub actions:

- separated the `pypi` source upload from the building of wheels so releases are available if wheel building fails
- narrowed the build matrix for `mm` and `cmake` to the latest two support versions
- abandoned `ubuntu-20.04` as a platform, since it has been left behind by recent versions of the toolchain

**Full Changelog**: https://github.com/pyre/pyre/compare/v1.12.1...v1.12.2

1.12.1

The support for HDF5 now includes all the machinery necessary to control the various cache mechanisms. The motivation behind these changes was to improve performance when accessing h5 files that are stored in S3 buckets. Credentials for AWS access can now be provided by specifying the URI of a dataset using the S3 scheme:

s3:profileregion/bucket/key

biancagi contributed `pyre::tensor`, a library for performing tensor algebra efficiently on small matrices

What's Changed
* Added support for CUDA to CMake build system by biancagi in https://github.com/pyre/pyre/pull/93
* Adjusted paths of python tests in CMake build system by biancagi in https://github.com/pyre/pyre/pull/95
* Cleaned up unused variables in CMake configuration files by biancagi in https://github.com/pyre/pyre/pull/96
* Merlin checkpoint by aivazis in https://github.com/pyre/pyre/pull/101
* Run pipeline on pull request by biancagi in https://github.com/pyre/pyre/pull/100
* algebra by biancagi in https://github.com/pyre/pyre/pull/79
* algebra by biancagi in https://github.com/pyre/pyre/pull/103
* Added support for fine tuning the performance of h5 accesses by aivazis in https://github.com/pyre/pyre/pull/107

New Contributors
* biancagi made their first contribution in https://github.com/pyre/pyre/pull/93

**Full Changelog**: https://github.com/pyre/pyre/compare/v1.12.0...v1.12.1

1.12.0

HDF5 support

The bulk of the work in this release is about access to HDF5 files. The central idea is the specification of the expected layout of a file, its _schema_, in terms of the group structure that defines the content hierarchy, and type, shape and content validators for the datasets at the leaves. The implementation of the schema leans heavily on the same ideas that help describe `pyre` components to the framework. The available types are user extensible and can raise the level of abstraction by leaning of HDF5 for disk content while enabling the user to 'dress up' the content, especially when accessed at the python level. A notable example is the ability to store timestamps as strings in the file but have them auto-converted to `datetime` objects when their values are fetched.

Given a schema, readers are able to compare the actual contents of a file against the specification and adjust its content processors to match the intended use of the information, writers have all the information necessary to build the structure of an output file, and validators can generate compliance reports to help guide the standardization of the data product generation steps.

`journal` improvements

There is now near perfect symmetry between the C++ and native python implementations of `journal`. The C++ bindings now include the necessary trampoline classes so that users can subclass devices and formatters in python. The output devices of individual channels can now be controlled from python as well, and support for indent/outdent was added to assist in formatting the output without having to pass a string with margin content around. The default margin is held by the `chronicler` regardless of which implementation is active. So is the maximum detail level that is forwarded to the output device, while individual channel entries can decorate their output with detail level that is compared to the maximum in order to decide whether to silence an entry or not.

Memory and grids

The bindings for `pyre::memory` and `pyre::grid` were totally restructured and now include access to template expansions for more datatypes and shapes.

User environment

The framework now respects XDG compliant user environments when deciding where the user level configuration files reside

Templates

The `smith` project generator was totally restructured to generate code that reflects the current usage recommendations. It is now able to bootstrap `react` based GUIs with built-in support for all the `pyre` widgets.

Pull requests
* Support for accessing HDF5 data stored in S3 buckets by aivazis in https://github.com/pyre/pyre/pull/86
* Significant improvements to the HDF5 integration layer by aivazis in https://github.com/pyre/pyre/pull/90


**Full Changelog**: https://github.com/pyre/pyre/compare/v1.11.2...v1.12.0

Page 1 of 4

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.