internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: ManimCommunity/manim

Issue:
Bug in coordinate_systems.NumberPlane._get_lines
## Description of bug / unexpected behavior
In `coordinate_systems.NumberPlane._get_lines`, line 2113 and 2120, the `x_step` for the wrong axis is passed as the `freq` argument to `NumberPlane._get_lines_parallel_to_axis`:

```py
        x_lines1, x_lines2 = self._get_lines_parallel_to_axis(
            x_axis,
            y_axis,
            self.x_axis.x_step,
            self.faded_line_ratio,
        )

        y_lines1, y_lines2 = self._get_lines_parallel_to_axis(
            y_axis,
            x_axis,
            self.y_axis.x_step,
            self.faded_line_ratio,
        )
```

The lines `self.x_axis.x_step` and `self.y_axis.x_step` are the opposite of what they should be. This results in manim using the wrong axis' step to determine lines.


## How to reproduce the issue
<!-- Provide a piece of code illustrating the undesired behavior. -->

<details><summary>Code for reproducing the problem</summary>

```py
class ZetaZeroes(Scene):
    def construct(self):
        zetaplane = ComplexPlane(
            y_range=[-80, 80, 20],
            y_length=config.frame_height,
        )
        zetaplane.add(zetaplane.get_coordinate_labels())
        self.add(zetaplane)
```
</details>
This results in the following:

![image](https://user-images.githubusercontent.com/37909158/134785365-4d919123-7be9-40fe-900c-965257450fb2.png)

When it in fact should look like this:

![image](https://user-images.githubusercontent.com/37909158/134785387-770826dd-d1ef-49ac-bfb8-193c8e0db8c2.png)






Discussion:

Resolving patch:
diff --git a/manim/mobject/coordinate_systems.py b/manim/mobject/coordinate_systems.py
--- a/manim/mobject/coordinate_systems.py
+++ b/manim/mobject/coordinate_systems.py
@@ -2109,14 +2109,14 @@ def _get_lines(self) -> Tuple[VGroup, VGroup]:
         x_lines1, x_lines2 = self._get_lines_parallel_to_axis(
             x_axis,
             y_axis,
-            self.x_axis.x_step,
+            self.y_axis.x_step,
             self.faded_line_ratio,
         )
 
         y_lines1, y_lines2 = self._get_lines_parallel_to_axis(
             y_axis,
             x_axis,
-            self.y_axis.x_step,
+            self.x_axis.x_step,
             self.faded_line_ratio,
         )
 


Test patch:
diff --git a/tests/test_coordinate_system.py b/tests/test_coordinate_system.py
--- a/tests/test_coordinate_system.py
+++ b/tests/test_coordinate_system.py
@@ -86,6 +86,10 @@ def test_NumberPlane():
         assert len(plane.y_lines) == num_y_lines
         assert len(plane.x_lines) == num_x_lines
 
+    plane = NumberPlane((-5, 5, 0.5), (-8, 8, 2))  # <- test for different step values
+    assert len(plane.x_lines) == 8
+    assert len(plane.y_lines) == 20
+
 
 def test_point_to_coords():
     ax = Axes(x_range=[0, 10, 2])
Repository: ManimCommunity/manim

Issue:
line_spacing paramter in Text should be float
**Text("test", line_spacing=1.3)** gets a warning in PyCharm for using the wrong data-type, but floating-point numbers work fine.

I guess the type hint in the **Text** class should be *float* instead of *int*.


Discussion:
So I quickly checked this in the codebase and it's also relevant (I think) for the Paragraph class as well. This leads to the conclusion that it isn't just a change in type hints.

The original intent seems that the numbers really are int (I have no idea why tho?) and there's a lot of if clauses testing for a case where line_spacing == -1 (eg. adjust automatically). At least all those would have to be changed to if line_spacing < 0. But to be honest, it would be nice to know the reasoning for the original intent of using ints in the first place...
Looking into it, there's no reason for it to *not* be a float. [`line_spacing` gets multiplied by `font_size`](https://github.com/ManimCommunity/manim/blob/main/manim/mobject/svg/text_mobject.py#L475-L480), which itself is a float, and multiplying an int and a float will *always* result in a float. Gonna write a PR to fix this!

Resolving patch:
diff --git a/manim/mobject/svg/text_mobject.py b/manim/mobject/svg/text_mobject.py
--- a/manim/mobject/svg/text_mobject.py
+++ b/manim/mobject/svg/text_mobject.py
@@ -120,7 +120,7 @@ class Paragraph(VGroup):
 
     Parameters
     ----------
-    line_spacing : :class:`int`, optional
+    line_spacing : :class:`float`, optional
         Represents the spacing between lines. Default to -1, which means auto.
     alignment : :class:`str`, optional
         Defines the alignment of paragraph. Default to "left". Possible values are "left", "right", "center"
@@ -411,7 +411,7 @@ def __init__(
         stroke_width: float = 0,
         color: Color = WHITE,
         font_size: float = DEFAULT_FONT_SIZE,
-        line_spacing: int = -1,
+        line_spacing: float = -1,
         font: str = "",
         slant: str = NORMAL,
         weight: str = NORMAL,


Test patch:
Repository: ManimCommunity/manim

Issue:
Width & Height for Text can't be float
![grafik](https://user-images.githubusercontent.com/25711926/136423938-10315c73-acc5-4f13-8a57-bd2b5a312fd2.png)

The expected type is Optional[int], but from my understanding, any non-negative float value should be allowed


Discussion:
@Darylgolden would you mind assigning this to me? I'd love to help out!
> 
> 
> @Darylgolden would you mind assigning this to me? I'd love to help out!

Sure, I assigned you! And there's no need to be formally assigned before working on an issue.

Resolving patch:
diff --git a/manim/mobject/svg/text_mobject.py b/manim/mobject/svg/text_mobject.py
--- a/manim/mobject/svg/text_mobject.py
+++ b/manim/mobject/svg/text_mobject.py
@@ -423,8 +423,8 @@ def __init__(
         gradient: tuple = None,
         tab_width: int = 4,
         # Mobject
-        height: int = None,
-        width: int = None,
+        height: float = None,
+        width: float = None,
         should_center: bool = True,
         unpack_groups: bool = True,
         disable_ligatures: bool = False,


Test patch:
Repository: ManimCommunity/manim

Issue:
Fade animation blends with background color, even if background is transparent
## Description of bug / unexpected behavior
When playing a FadeOut animation on an MObject, the color of the object interpolates to the background color even when the background is transparent. I encountered this bug when compositing a PNG image sequence, output from Manim, with a separate background.

## Expected behavior
The MObject should remain the same color, and simply reduce in opacity over time.


## How to reproduce the issue
Setting the background color to purple makes the issue clearer. But it's still an issue, even with a black background.

```py
def construct(self):

    self.camera.background_color = "#662266"

    fadeOutTest = Tex("Fading")
    self.play(FadeOut(fadeOutTest))
```

And I rendered the image sequence with the flags --format png and -t

## Additional media files
I put the resulting rendered image over a white background in a image editor so you can see the effect.

Here is the image at the start of the animation. Interestingly, you can already see the blending happening around the edges due to anti-aliasing.
![StartOfFade](https://user-images.githubusercontent.com/13613122/140630850-ffd82e91-12e3-49d8-8a48-9ea31c93b7ed.png)

And here is the same animation about halfway through.
![MiddleOfFade](https://user-images.githubusercontent.com/13613122/140630872-6e06486a-aa55-4b8a-9a46-0e700b4917f2.png)

## Notes:
I did a little digging in the Manim codebase, and I believe this behavior is caused by the Cairo library. So I couldn't really figure out what to do about it. But maybe one of you guys has an idea?


Discussion:

Resolving patch:
diff --git a/manim/utils/color.py b/manim/utils/color.py
--- a/manim/utils/color.py
+++ b/manim/utils/color.py
@@ -491,8 +491,9 @@ def color_to_int_rgb(color: Color) -> np.ndarray:
 
 
 def color_to_int_rgba(color: Color, opacity: float = 1.0) -> np.ndarray:
-    alpha = int(255 * opacity)
-    return np.append(color_to_int_rgb(color), alpha)
+    alpha_multiplier = np.vectorize(lambda x: int(x * opacity))
+
+    return alpha_multiplier(np.append(color_to_int_rgb(color), 255))
 
 
 def color_gradient(


Test patch:
diff --git a/tests/test_color.py b/tests/test_color.py
--- a/tests/test_color.py
+++ b/tests/test_color.py
@@ -27,7 +27,7 @@ def test_background_color():
     S.camera.background_color = "#bbffbb"
     S.camera.background_opacity = 0.5
     S.renderer.update_frame(S)
-    assert np.all(S.renderer.get_frame()[0, 0] == np.array([187, 255, 187, 127]))
+    assert np.all(S.renderer.get_frame()[0, 0] == np.array([93, 127, 93, 127]))
 
 
 def test_set_color():
Repository: ManimCommunity/manim

Issue:
removing edges from Graph in an animatoin
## Description of bug / unexpected behavior
<!-- Add a clear and concise description of the problem you encountered. -->
If g is a Graph, calling g.animate.remove_edges(...) does not actually play an animation.
Instead, the edges will all be removed instantaneously.

## How to reproduce the issue
<!-- Provide a piece of code illustrating the undesired behavior. -->

<details><summary>Code for reproducing the problem</summary>

```py
class Test(Scene):
  def construct(self):
    g = Graph([1,2,3], [(1,2), (2,3), (3,1)])
    self.add(g)
    self.wait()
    self.play(g.animate.remove_edges((1,2),(2,3)))
    self.wait()
```

</details>


## Additional comments
<!-- Add further context that you think might be relevant for this issue here. -->
I think that the problem has to do with [this line of code](https://github.com/ManimCommunity/manim/blob/63b43ebf82e4a0fcbd79137dae2e27810b21b07e/manim/mobject/graph.py#L999).
It seems like in the animation override method, the original method is called, which removes the edges before creating the animations.


Discussion:

Resolving patch:
diff --git a/manim/mobject/graph.py b/manim/mobject/graph.py
--- a/manim/mobject/graph.py
+++ b/manim/mobject/graph.py
@@ -997,9 +997,7 @@ def _remove_edges_animation(self, *edges, anim_args=None):
         animation = anim_args.pop("animation", Uncreate)
 
         mobjects = self.remove_edges(*edges)
-        return AnimationGroup(
-            *(animation(mobj, **anim_args) for mobj in mobjects), group=self
-        )
+        return AnimationGroup(*(animation(mobj, **anim_args) for mobj in mobjects))
 
     @staticmethod
     def from_networkx(nxgraph: nx.classes.graph.Graph, **kwargs) -> Graph:


Test patch:
Repository: ManimCommunity/manim

Issue:
Rendering TeX strings containing % broken
This unfortunately broke rendering of TeX strings containing `%`. Trying to create `Tex(r"\%")` fails in v0.15.0.

_Originally posted by @behackl in https://github.com/ManimCommunity/manim/issues/2574#issuecomment-1054726581_


Discussion:

Resolving patch:
diff --git a/manim/utils/tex_file_writing.py b/manim/utils/tex_file_writing.py
--- a/manim/utils/tex_file_writing.py
+++ b/manim/utils/tex_file_writing.py
@@ -84,7 +84,10 @@ def generate_tex_file(expression, environment=None, tex_template=None):
 
     result = os.path.join(tex_dir, tex_hash(output)) + ".tex"
     if not os.path.exists(result):
-        logger.info(f"Writing {expression} to %(path)s", {"path": f"{result}"})
+        logger.info(
+            "Writing %(expression)s to %(path)s",
+            {"expression": expression, "path": f"{result}"},
+        )
         with open(result, "w", encoding="utf-8") as outfile:
             outfile.write(output)
     return result


Test patch:
diff --git a/tests/control_data/logs_data/bad_tex_scene_BadTex.txt b/tests/control_data/logs_data/bad_tex_scene_BadTex.txt
--- a/tests/control_data/logs_data/bad_tex_scene_BadTex.txt
+++ b/tests/control_data/logs_data/bad_tex_scene_BadTex.txt
@@ -1,5 +1,5 @@
 {"levelname": "INFO", "module": "logger_utils", "message": "Log file will be saved in <>"}
-{"levelname": "INFO", "module": "tex_file_writing", "message": "Writing \\frac{1}{0} to <>"}
+{"levelname": "INFO", "module": "tex_file_writing", "message": "Writing <> to <>"}
 {"levelname": "ERROR", "module": "tex_file_writing", "message": "LaTeX compilation error: LaTeX Error: File `notapackage.sty' not found.\n"}
 {"levelname": "ERROR", "module": "tex_file_writing", "message": "Context of error: \n\\documentclass[preview]{standalone}\n-> \\usepackage{notapackage}\n\\begin{document}\n\n\\begin{center}\n"}
 {"levelname": "INFO", "module": "tex_file_writing", "message": "You do not have package notapackage.sty installed."}
diff --git a/tests/test_texmobject.py b/tests/test_texmobject.py
--- a/tests/test_texmobject.py
+++ b/tests/test_texmobject.py
@@ -33,6 +33,11 @@ def test_tex():
     assert Path(config.media_dir, "Tex", "983949cac5bdd272.svg").exists()
 
 
+def test_percent_char_rendering():
+    Tex(r"\%")
+    assert Path(config.media_dir, "Tex", "ce6e53f2d9c537bb.tex").exists()
+
+
 def test_tex_whitespace_arg():
     """Check that correct number of submobjects are created per string with whitespace separator"""
     separator = "\t"
Repository: ManimCommunity/manim

Issue:
Preview without embed broken in jupyter notebooks.
## Description

The embed feature seems to have broken preview in jupyter notebooks.

default:
<img width="1115" alt="Screenshot 2022-03-05 at 3 24 09 PM" src="https://user-images.githubusercontent.com/90276965/156878243-224900ac-8da2-46e5-8ee2-cc9f1852bec8.png">

with media embed:
<img width="1115" alt="Screenshot 2022-03-05 at 3 24 30 PM" src="https://user-images.githubusercontent.com/90276965/156878267-b5d77f95-7953-45e9-b155-baac8f19db35.png">

## Expected Behaviour
Should preview images even without `media_embed`


_Originally posted by @Kiran-Raj-Dev in https://github.com/ManimCommunity/manim/issues/2442#issuecomment-1059732017_


Discussion:
Does it work if you specify the `-s` flag for scenes that only render into an image? I know that video output works as expected.
This
```py
%%manim -s -qh --disable_caching -v WARNING Example
class Example(Scene):
    def construct(self):
        self.play(Create(NumberPlane()))
```
and this
```py
%%manim -s -qh --disable_caching -v WARNING Example
class Example(Scene):
    def construct(self):
        self.add(NumberPlane())
```
Both don't work
I have identified and fixed the issue. PR incoming.

Resolving patch:
diff --git a/manim/utils/ipython_magic.py b/manim/utils/ipython_magic.py
--- a/manim/utils/ipython_magic.py
+++ b/manim/utils/ipython_magic.py
@@ -181,7 +181,7 @@ def construct(self):
                     embed = "google.colab" in str(get_ipython())
 
                 if file_type.startswith("image"):
-                    result = Image(filename=config["output_file"], embed=embed)
+                    result = Image(filename=config["output_file"])
                 else:
                     result = Video(
                         tmpfile,


Test patch:
Repository: ManimCommunity/manim

Issue:
Running `self.play` etc. in the IPython terminal spawned by `interactive_embed` does not work
## Description of bug / unexpected behavior
<!-- Add a clear and concise description of the problem you encountered. -->

While the scene is available as `self` in the spawned IPython terminal, running rendering methods like `self.wait` or `self.play` makes Manim crash (hard):
```
In [1]: self.wait()
zsh: segmentation fault
```


## Expected behavior
<!-- Add a clear and concise description of what you expected to happen. -->

The commands should run as expected, no segfault.

## How to reproduce the issue
<!-- Provide a piece of code illustrating the undesired behavior. -->


```py
class EmbedCrash(Scene):
    def construct(self):
        self.wait()
        self.interactive_embed()
```

Take this code, render with `--renderer=opengl`, then run `self.wait()` in the IPython shell.

## Additional comments
<!-- Add further context that you think might be relevant for this issue here. -->

There is some relevant code already which provides the functions `wait`, `play`, etc (without `self.`) in the IPython shell; either `interactive_embed` should monkey-patch `play`, `wait` to do the same -- or `self` should be turned into a special scene wrapper `InteractiveScene` or so which provides the appropriate methods directly.



Discussion:

Resolving patch:
diff --git a/manim/scene/scene.py b/manim/scene/scene.py
--- a/manim/scene/scene.py
+++ b/manim/scene/scene.py
@@ -1008,6 +1008,24 @@ def play(
             All other keywords are passed to the renderer.
 
         """
+        # Make sure this is running on the main thread
+        if threading.current_thread().name != "MainThread":
+            kwargs.update(
+                {
+                    "subcaption": subcaption,
+                    "subcaption_duration": subcaption_duration,
+                    "subcaption_offset": subcaption_offset,
+                }
+            )
+            self.queue.put(
+                (
+                    "play",
+                    args,
+                    kwargs,
+                )
+            )
+            return
+
         start_time = self.renderer.time
         self.renderer.play(self, *args, **kwargs)
         run_time = self.renderer.time - start_time


Test patch:
Repository: ManimCommunity/manim

Issue:
Documentation Bug: Cylinder.get_direction()
The documentation `get_direction` method for `Cylinder` mentions a function called `shoelace_direction` which returns a string, either "CW" or "CCW". However, the implementation of `get_direction` returns a 3d vector. This is the correct behavior in this context, but the documentation is incorrect.


Discussion:

Resolving patch:
diff --git a/manim/mobject/three_d/three_dimensions.py b/manim/mobject/three_d/three_dimensions.py
--- a/manim/mobject/three_d/three_dimensions.py
+++ b/manim/mobject/three_d/three_dimensions.py
@@ -687,6 +687,7 @@ def set_direction(self, direction):
         self._rotate_to_direction()
 
     def get_direction(self):
+        """Returns the direction of the central axis of the cylinder."""
         return self.direction
 
 


Test patch:
Repository: ManimCommunity/manim

Issue:
VMobject  get_end_anchors Wrong Documentation 
## Description of bug / unexpected behavior
<!-- Add a clear and concise description of the problem you encountered. -->
I think the documentation [`vm.get_end_anchors()`](https://docs.manim.community/en/stable/reference/manim.mobject.types.vectorized_mobject.VMobject.html#manim.mobject.types.vectorized_mobject.VMobject.get_end_anchors) is wrong because it is a copy of `vm.get_start_anchor()`

## Expected behavior
<!-- Add a clear and concise description of what you expected to happen. -->
Should probably be changed to "end" instead of start in the documentation comment


Discussion:
The documented return type is also debatable; I guess that it should be `List[np.ndarray]` or `Iterable[np.ndarray]`, but I wouldn't bet that it is just a `np.ndarray`.

Resolving patch:
diff --git a/manim/mobject/types/vectorized_mobject.py b/manim/mobject/types/vectorized_mobject.py
--- a/manim/mobject/types/vectorized_mobject.py
+++ b/manim/mobject/types/vectorized_mobject.py
@@ -1331,7 +1331,7 @@ def get_start_anchors(self) -> np.ndarray:
         return self.points[0 :: self.n_points_per_cubic_curve]
 
     def get_end_anchors(self) -> np.ndarray:
-        """Return the starting anchors of the bezier curves.
+        """Return the end anchors of the bezier curves.
 
         Returns
         -------


Test patch:
Repository: ManimCommunity/manim

Issue:
Unnatural axis alignment when using faded_line_ratio property
## Description of bug / unexpected behaviour
<!-- Add a clear and concise description of the problem you encountered. -->
An uneven interval between the axis and grids causes mapping of coordinates using the NumberPlane.c2p unexpected.

## Expected behaviour
<!-- Add a clear and concise description of what you expected to happen. -->
The interval between the units from ORIGIN should be uniform and Coordinates should be mapped properly.

## How to reproduce the issue
<!-- Provide a piece of code illustrating the undesired behaviour. -->

<details><summary>Code for reproducing the problem</summary>

```py
class Test(Scene):
    def construct(self):
        numberplane = NumberPlane(
            faded_line_ratio=5,
            axis_config={
            "font_size": 40,
            }
        ).add_coordinates()
        coord = numberplane.c2p

        self.add(
            Dot(coord(0, 0)),
            Dot(coord(1, 0)),
            Dot(coord(2, 0)),
        )
        self.add(numberplane)
```


</details>


## Additional media files
<!-- Paste in the files manim produced on rendering the code above. -->

<details><summary>Images/GIFs</summary>

<!-- PASTE MEDIA HERE -->
![image](https://user-images.githubusercontent.com/25475894/180486457-c0c64a92-3cc8-4756-bf75-36ff2b01c270.png)
</details>

## System specifications
Not relevant

## Additional comments
<!-- Add further context that you think might be relevant for this issue here. -->



Discussion:

Resolving patch:
diff --git a/manim/mobject/graphing/coordinate_systems.py b/manim/mobject/graphing/coordinate_systems.py
--- a/manim/mobject/graphing/coordinate_systems.py
+++ b/manim/mobject/graphing/coordinate_systems.py
@@ -2661,7 +2661,7 @@ def _get_lines_parallel_to_axis(
             for k, x in enumerate(inputs):
                 new_line = line.copy()
                 new_line.shift(unit_vector_axis_perp_to * x)
-                if k % ratio_faded_lines == 0:
+                if (k + 1) % ratio_faded_lines == 0:
                     lines1.add(new_line)
                 else:
                     lines2.add(new_line)


Test patch:
diff --git a/tests/test_graphical_units/control_data/coordinate_system/number_plane_log.npz b/tests/test_graphical_units/control_data/coordinate_system/number_plane_log.npz
Binary files a/tests/test_graphical_units/control_data/coordinate_system/number_plane_log.npz and b/tests/test_graphical_units/control_data/coordinate_system/number_plane_log.npz differ
Repository: ManimCommunity/manim

Issue:
Documentation Website Has Broken Links: I Can't Submit Pull Requests!
On each page of Docs.Manim.Community there is a Pencil icon if editing needs be for that page.
But now if I click the Pencil for any page it gives a 404!

For example:
If I go on this link:
https://docs.manim.community/en/stable/reference/manim.mobject.geometry.arc.Circle.html

And click the Pencil on the top-right I get a 404!

Fix it!


Discussion:
Thanks for letting us know, I wasn't aware our documentation theme has added an edit button feature.

The problem is: the way this is [currently implemented]( https://github.com/pradyunsg/furo/blob/main/src/furo/theme/furo/components/edit-this-page.html) does not work correctly with documentation pages generated from docstrings via `autodoc`: In the example you gave above, https://docs.manim.community/en/stable/reference/manim.mobject.geometry.arc.Circle.html tries to link to (after setting up things correctly) https://github.com/ManimCommunity/manim/edit/main/docs/source/reference/manim.mobject.geometry.arc.Circle.rst, so it basically is looking for the corresponding document in our `docs/source` directory.

However, it cannot be found there as this page is autogenerated from the docstring of the `Circle` class in https://github.com/ManimCommunity/manim/blob/44f78f1dfdd7498542869fc06bb39619f2b2d57b/manim/mobject/geometry/arc.py#L467-L490

We'll have to disable the feature for now.


Resolving patch:
diff --git a/docs/source/conf.py b/docs/source/conf.py
--- a/docs/source/conf.py
+++ b/docs/source/conf.py
@@ -99,6 +99,10 @@
 html_static_path = ["_static"]
 
 html_theme_options = {
+    "source_repository": "https://github.com/ManimCommunity/manim/",
+    "source_branch": "main",
+    "source_directory": "docs/source/",
+    "top_of_page_button": None,
     "light_logo": "manim-logo-sidebar.svg",
     "dark_logo": "manim-logo-sidebar-dark.svg",
     "light_css_variables": {


Test patch: