Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

[pull] main from matplotlib:main #22

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 246 commits into
base: main
Choose a base branch
Loading
from
Open

Conversation

pull[bot]
Copy link

@pull pull bot commented Apr 29, 2025

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.1)

Can you help keep this open source service alive? 💖 Please sponsor : )

asmeurer and others added 24 commits May 8, 2024 16:20
This allows specifying the output base name of the generated image files. The
name can include '{counter}', which is automatically string formatted to an
incrementing counter. The default if it is not specified is left intact as
the current behavior, which is to use the base name of the provided script or
the RST document.

This is required to use the plot directive with MyST, because the directive is
broken with MyST (an issue I don't want to fix), requiring the use of
eval-rst. But the way eval-rst works, the incrementing counter is not
maintained across different eval-rst directives, meaning if you try to include
multiple of them in the same document, the images will overwrite each other.
This allows you to manually work around this with something like

```{eval-rst}
.. plot::
   :output-base-name: plot-1

   ...
```

```{eval-rst}
.. plot::
   :output-base-name: plot-2

   ...
```

Aside from this, it's generally useful to be able to specify the image name
used for a plot, as a more informative name can be used rather than just
'<document-name>-1.png'.
The idea of allowing the use of the counter for custom base names is flawed
because the counter would always be incremented even for custom names that
don't use it. Also, the global base name is difficult to get working because
we don't have a good global view of the plots to create a counter, especially
in the case of partial rebuilds.

Instead, we just simplify things by just allowing setting a custom-base-name.
If two plot directives use the same custom-base-name, then one will end up
overwriting the other (I'm still looking into whether it's possible to at
least detect this and give an error).
Previously it would just overwrite one plot with the other.

I did not add tests for this because I would have to create a whole separate
docs build just to test the error (but I have tested it manually).
This will hopefully fix Sphinx trying and failing to include it.
Co-authored-by: Jody Klymak <jklymak@gmail.com>
Co-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>
Co-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>
This is shorter and more readable than defining them with
single-use static functions positioned quite far away from the
def_property_readonly calls.
`func` and `init_func` may return None (which is ok if `blit=False`).
Since gating the allowed signature on the state of `blit` is not
feasible, we err on the side on being too permissive in the type
definition: Rather not flag a type error and only raise on runtime than
complain on an actually working signature.

Closes #29960.
Use inline lambdas to define most FT2Font properties.
@pull pull bot added the ⤵️ pull label Apr 29, 2025
anntzer and others added 5 commits April 29, 2025 15:20
In 89a7e19, an API for converting "dvi glyph indices" (as stored
in a dvi file) to FreeType-compatible keys (either "indices into
the native charmap" or "glyph names") was introduced.  It was
intended that end users (i.e., backends) would check the type of
`text.glyph_name_or_index` ((A) int or (B) str) and load the glyph
accordingly ((A) `FT_Set_Charmap(native_cmap); FT_Load_Char(index);` or
(B) `FT_Load_Glyph(FT_Get_Name_Index(name));`); however, with the future
introduction of {xe,lua}tex support, this kind of type checking becomes
inconvenient, because {xe,lua}tex's "dvi glyph indices", which are
directly equal to FreeType glyph indices (i.e. they would be loaded with
`FT_Load_Glyph(index);`), would normally also be converted to ints.

This PR introduces a new API (`Text.index`) that performs this mapping
(via the new `DviFont._index_dvi_to_freetype`), always mapping to
FreeType glyph indices (i.e. one can always just call `FT_Load_Glyph`
on the result).  To do so, in case (A) it loads itself the native
charmap (something the end user needed to do by themselves previously)
and performs the cmap-to-index conversion (`FT_Get_Char_Index`)
previously implicit in `FT_Load_Char`; in case (B) it performs itself
the name-to-index conversion (`FT_Get_Name_Index`).  When {xe,lua}tex
support is introduced in the future, `_index_dvi_to_freetype` will
just return the index as is.

The old APIs are not deprecated yet, as other changes will occur for
{xe,lua}tex support (e.g. font_effects will go away and be replaced by
`.font.effects`, as {xe,lua}tex don't store that info in the pdftexmap
entry), and grouping all API changes together seems nicer (to only
require a single adaptation step by the API consumer).
* DOC: Improve NonUniformImage docs

* Update lib/matplotlib/image.py

Co-authored-by: David Stansby <dstansby@gmail.com>

---------

Co-authored-by: David Stansby <dstansby@gmail.com>
* Adding elinestyle property to errorbar and test case

* whitespaces in testcase

* Update lib/matplotlib/axes/_axes.py

Co-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>

* Update set eb_line_style and fix formatting issues

* Remove extra line from test_axes

* Break line to reduce width in text_axes.py

* Remove trailing whitespaces from axes and test_axes.py

* Move elinestyle to the end of the list

* Shorten line length in axes.py

* accessing the correct property 'linestyle' in eb_line_style

* removing unused code

* Update lib/matplotlib/axes/_axes.pyi

Co-authored-by: Elliott Sales de Andrade <quantum.analyst@gmail.com>

* pyplot.py unwanted changes reverted

* Adding extra blank lines to fix style errors, and removing unnecessary asserts

* Updating test_axes.py tp test for dashed lines instead of default

* Style fix

---------

Co-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>
Co-authored-by: Elliott Sales de Andrade <quantum.analyst@gmail.com>
nakanoh and others added 30 commits June 9, 2025 10:50
Signed-off-by: Emmanuel Ferdman <emmanuelferdman@gmail.com>
Throw exception when alpha is out of bounds
Bumps the actions group with 1 update: [github/codeql-action](https://github.com/github/codeql-action).


Updates `github/codeql-action` from 3.28.18 to 3.28.19
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@ff0a06e...fca7ace)

---
updated-dependencies:
- dependency-name: github/codeql-action
  dependency-version: 3.28.19
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: actions
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: Elliott Sales de Andrade <quantum.analyst@gmail.com>
Co-authored-by: hannah <story645@gmail.com>
Co-authored-by: hannah <story645@gmail.com>
Co-authored-by: hannah <story645@gmail.com>
Co-authored-by: hannah <story645@gmail.com>
TST: Fix runtime error checking NaN input to format_cursor_data
Fixed an off-by-half-pixel bug in image resampling when using a nonaffine transform (e.g., a log axis)
…ctions-694872dfd1

Bump github/codeql-action from 3.28.18 to 3.28.19 in the actions group
Add a filename-prefix option to the Sphinx plot directive
Bumps the actions group with 3 updates: [pypa/cibuildwheel](https://github.com/pypa/cibuildwheel), [actions/attest-build-provenance](https://github.com/actions/attest-build-provenance) and [github/codeql-action](https://github.com/github/codeql-action).


Updates `pypa/cibuildwheel` from 2.23.3 to 3.0.0
- [Release notes](https://github.com/pypa/cibuildwheel/releases)
- [Changelog](https://github.com/pypa/cibuildwheel/blob/main/docs/changelog.md)
- [Commits](pypa/cibuildwheel@faf86a6...5f22145)

Updates `actions/attest-build-provenance` from 2.3.0 to 2.4.0
- [Release notes](https://github.com/actions/attest-build-provenance/releases)
- [Changelog](https://github.com/actions/attest-build-provenance/blob/main/RELEASE.md)
- [Commits](actions/attest-build-provenance@db473fd...e8998f9)

Updates `github/codeql-action` from 3.28.19 to 3.29.0
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@fca7ace...ce28f5b)

---
updated-dependencies:
- dependency-name: pypa/cibuildwheel
  dependency-version: 3.0.0
  dependency-type: direct:production
  update-type: version-update:semver-major
  dependency-group: actions
- dependency-name: actions/attest-build-provenance
  dependency-version: 2.4.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: actions
- dependency-name: github/codeql-action
  dependency-version: 3.29.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: actions
...

Signed-off-by: dependabot[bot] <support@github.com>
…ctions-a7d2d3e850

Bump the actions group with 3 updates
The current implementation is not slow, but uses a lot of memory per
image.

In `compare_images`, we have:

- one actual and one expected image as uint8 (2×image)
- both converted to int16 (though original is thrown away) (4×)

which adds up to 4× the image allocated in this function.

Then it calls `calculate_rms`, which has:

- a difference between them as int16 (2×)
- the difference cast to 64-bit float (8×)
- the square of the difference as 64-bit float (though possibly the
  original difference was thrown away) (8×)

which at its peak has 16× the image allocated in parallel.

If the RMS is over the desired tolerance, then `save_diff_image` is
called, which:

- loads the actual and expected images _again_ as uint8 (2× image)
- converts both to 64-bit float (throwing away the original) (16×)
- calculates the difference (8×)
- calculates the absolute value (8×)
- multiples that by 10 (in-place, so no allocation)
- clips to 0-255 (8×)
- casts to uint8 (1×)

which at peak uses 32× the image.

So at their peak, `compare_images`→`calculate_rms` will have 20× the
image allocated, and then `compare_images`→`save_diff_image` will have
36× the image allocated. This is generally not a problem, but on
resource-constrained places like WASM, it can sometimes run out of
memory just in `calculate_rms`.

This implementation in C++ always allocates the diff image, even when
not needed, but doesn't have all the temporaries, so it's a maximum of
3× the image size (plus a few scalar temporaries).
TST: Calculate RMS and diff image in C++
* DOC: expand polar example

* DOC: expand polar example

* Apply suggestions from code review

Co-authored-by: Ruth Comer <10599679+rcomer@users.noreply.github.com>

---------

Co-authored-by: Ruth Comer <10599679+rcomer@users.noreply.github.com>
Instead of a fixed-size buffer, a dynamic buffer, and all the tracking
for them, just use a standard C++ container, which will clean up for
itself automatically.
Fixed incomplete deletion of all images that have passed tests before upload
Simplify RendererAgg::draw_markers buffers
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Morty Proxy This is a proxified and sanitized view of the page, visit original site.