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

Issue:
Add import statements to examples in documentation
See title.

The examples in the documentation should also include the `from manim import *` at the very least, and actually we could provide best-practice examples where we dont do a *-import, but rather import classes/functions separately.

This can of course be an iterative process: start with adding `from manim import *` first, and become more specific later.


Discussion:
In my opinion, the import statement should only be present in the example gallery, I think the reference example do not need it.
Do you agree?
Just a reference to an issue where this was discussed before: https://github.com/ManimCommunity/manim/issues/454
Hmm.

I would like it, if users could take any rendered example in our documentation, and copy/paste the code without modification so that they get the same result. That probably rather speaks for adding them everywhere, but I am not fully decided about it.
Agree with Ben.

I see no argument in favor of not having the importa statements, other than
gaining 1-2 lines per example. I think having complete examples is more
important than saving up a bit of space.

On Thu, Oct 22, 2020, 7:20 AM Benjamin Hackl <notifications@github.com>
wrote:

> Hmm.
>
> I would like it, if users could take any rendered example in our
> documentation, and copy/paste the code without modification so that they
> get the same result. That probably rather speaks for adding them
> everywhere, but I am not fully decided about it.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/ManimCommunity/manim/issues/593#issuecomment-714424635>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAILYAEFGWN3AQEAP7QB5NLSMAIRHANCNFSM4S3AMSIQ>
> .
>

ok, then we can do it with import statements everywhere.

Resolving patch:
diff --git a/docs/source/manim_directive.py b/docs/source/manim_directive.py
--- a/docs/source/manim_directive.py
+++ b/docs/source/manim_directive.py
@@ -202,6 +202,7 @@ def run(self):
         source_block = [
             ".. code-block:: python",
             "",
+            "    from manim import *\n",
             *["    " + line for line in self.content],
         ]
         source_block = "\n".join(source_block)


Test patch:
Repository: ManimCommunity/manim

Issue:
:meth:`~.Mobject.add_to_back` needs to filter out additional incoming objects
## Description of bug / unexpected behavior
<!-- Add a clear and concise description of the problem you encountered. -->
From edge case defined in #1220, and issue encountered in https://github.com/ManimCommunity/manim/pull/1308/commits/ce2cbfb100fe1208e04838aa83caade7f3ca08a

## Expected behavior
<!-- Add a clear and concise description of what you expected to happen. -->
Incoming Mobjects should be filtered out into a set, before being added to submobjects.

## How to reproduce the issue
<!-- Provide a piece of code illustrating the undesired behavior. -->

Code for reproducing the problem

```py
a.add_to_back(b, b, b)
a.add_to_back(b, b)
```

</details>

## Additional comments
<!-- Add further context that you think might be relevant for this issue here. -->
I'll be working on fixing this problem.


Discussion:

Resolving patch:
diff --git a/manim/mobject/mobject.py b/manim/mobject/mobject.py
--- a/manim/mobject/mobject.py
+++ b/manim/mobject/mobject.py
@@ -383,15 +383,16 @@ def add_to_back(self, *mobjects: "Mobject") -> "Mobject":
         :meth:`add`
 
         """
+        if self in mobjects:
+            raise ValueError("A mobject shouldn't contain itself")
+
         for mobject in mobjects:
-            if self in mobjects:
-                raise ValueError("Mobject cannot contain self")
             if not isinstance(mobject, Mobject):
                 raise TypeError("All submobjects must be of type Mobject")
 
-        filtered = list_update(mobjects, self.submobjects)
         self.remove(*mobjects)
-        self.submobjects = list(filtered) + self.submobjects
+        # dict.fromkeys() removes duplicates while maintaining order
+        self.submobjects = list(dict.fromkeys(mobjects)) + self.submobjects
         return self
 
     def remove(self, *mobjects: "Mobject") -> "Mobject":


Test patch:
diff --git a/tests/test_vectorized_mobject.py b/tests/test_vectorized_mobject.py
--- a/tests/test_vectorized_mobject.py
+++ b/tests/test_vectorized_mobject.py
@@ -1,7 +1,7 @@
 import numpy as np
 import pytest
 
-from manim import Line, Mobject, VDict, VGroup, VMobject
+from manim import Circle, Line, Mobject, Square, VDict, VGroup, VMobject
 
 
 def test_vmobject_point_from_propotion():
@@ -127,6 +127,18 @@ def test_vmob_add_to_back():
     a.add_to_back(b)
     a.add_to_back(b, b)
     assert len(a.submobjects) == 1
+    a.submobjects.clear()
+    a.add_to_back(b, b, b)
+    a.add_to_back(b, b)
+    assert len(a.submobjects) == 1
+    a.submobjects.clear()
+
+    # Make sure the ordering has not changed
+    o1, o2, o3 = Square(), Line(), Circle()
+    a.add_to_back(o1, o2, o3)
+    assert a.submobjects.pop() == o3
+    assert a.submobjects.pop() == o2
+    assert a.submobjects.pop() == o1
 
 
 def test_vdict_init():
Repository: ManimCommunity/manim

Issue:
`Dot3D` should have a coordinate parameter
## Enhancement proposal
`Dot3D` should mirror the functionality of `Dot` and have a parameter to specify its coordinates. I think the best way to do this is to add a kwarg to `Sphere` that would also change its position, and then pass in the coordinate from `Dot3D` to the superclass init method.


## Additional comments
<!-- Add further context that you think might be relevant. -->



Discussion:
Was thinking the same thing a while ago, seems like a good idea to me.

Resolving patch:
diff --git a/manim/mobject/three_dimensions.py b/manim/mobject/three_dimensions.py
--- a/manim/mobject/three_dimensions.py
+++ b/manim/mobject/three_dimensions.py
@@ -135,6 +135,7 @@ def set_fill_by_checkerboard(self, *colors, opacity=None):
 class Sphere(ParametricSurface):
     def __init__(
         self,
+        center=ORIGIN,
         radius=1,
         resolution=(12, 24),
         u_min=0.001,
@@ -155,6 +156,7 @@ def __init__(
         )
         self.radius = radius
         self.scale(self.radius)
+        self.shift(center)
 
     def func(
         self, u, v
@@ -167,6 +169,8 @@ class Dot3D(Sphere):
 
     Parameters
     --------
+    point : Union[:class:`list`, :class:`numpy.ndarray`], optional
+        The location of the dot.
     radius : :class:`float`, optional
         The radius of the dot.
     color : :class:`~.Colors`, optional
@@ -183,14 +187,14 @@ def construct(self):
                 self.set_camera_orientation(phi=75*DEGREES, theta=-45*DEGREES)
 
                 axes = ThreeDAxes()
-                dot_1 = Dot3D(color=RED).move_to(axes.coords_to_point(0, 0, 1))
-                dot_2 = Dot3D(radius=0.1, color=BLUE).move_to(axes.coords_to_point(2, 0, 0))
-
-                self.add(axes, dot_1, dot_2)
+                dot_1 = Dot3D(point=axes.coords_to_point(0, 0, 1), color=RED)
+                dot_2 = Dot3D(point=axes.coords_to_point(2, 0, 0), radius=0.1, color=BLUE)
+                dot_3 = Dot3D(point=[0, 0, 0], radius=0.1, color=ORANGE)
+                self.add(axes, dot_1, dot_2,dot_3)
     """
 
-    def __init__(self, radius=DEFAULT_DOT_RADIUS, color=WHITE, **kwargs):
-        Sphere.__init__(self, radius=radius, **kwargs)
+    def __init__(self, point=ORIGIN, radius=DEFAULT_DOT_RADIUS, color=WHITE, **kwargs):
+        Sphere.__init__(self, center=point, radius=radius, **kwargs)
         self.set_color(color)
 
 


Test patch:
Repository: ManimCommunity/manim

Issue:
Remove references to t_min and t_max in ParametricFunction
## Description of bug / unexpected behavior

With PR #1161 the old way of setting the parameter's range (e.g. by setting `t_min` and `t_max`) was replaced by a single parameter `t_range`. However, the docs still show usage of `t_min` and `t_max`.





Discussion:

Resolving patch:
diff --git a/manim/mobject/functions.py b/manim/mobject/functions.py
--- a/manim/mobject/functions.py
+++ b/manim/mobject/functions.py
@@ -25,7 +25,7 @@ def func(self, t):
                 return np.array((np.sin(2 * t), np.sin(3 * t), 0))
 
             def construct(self):
-                func = ParametricFunction(self.func, t_max = TAU, fill_opacity=0).set_color(RED)
+                func = ParametricFunction(self.func, t_range = np.array([0, TAU]), fill_opacity=0).set_color(RED)
                 self.add(func.scale(3))
 
     .. manim:: ThreeDParametricSpring
@@ -38,7 +38,7 @@ def construct(self):
                         1.2 * np.cos(u),
                         1.2 * np.sin(u),
                         u * 0.05
-                    ]), color=RED, t_min=-3 * TAU, t_max=5 * TAU,
+                    ]), color=RED, t_range = np.array([-3*TAU, 5*TAU, 0.01])
                 ).set_shade_in_3d(True)
                 axes = ThreeDAxes()
                 self.add(axes, curve1)


Test patch:
Repository: ManimCommunity/manim

Issue:
Dont import `hilite_me` and `insert_line_numbers_in_html` with `from manim import *`
https://github.com/ManimCommunity/manim/blob/199424d713c77fca6f59de58ba0f8eb3955bfab1/manim/mobject/svg/code_mobject.py#L6

The functions `hilite_me` and `insert_line_numbers_in_html` are currently imported with `from manim import *` , and I think that is not necessary.
Further the question:
Why are they defined outside the Code class?


Discussion:
>  Why are they defined outside the Code class?

Maybe a mistake.

Marking this as a "good first issue" as it is as simple as removing those two lines from `__all__`.

Resolving patch:
diff --git a/manim/mobject/svg/code_mobject.py b/manim/mobject/svg/code_mobject.py
--- a/manim/mobject/svg/code_mobject.py
+++ b/manim/mobject/svg/code_mobject.py
@@ -2,8 +2,6 @@
 
 __all__ = [
     "Code",
-    "hilite_me",
-    "insert_line_numbers_in_html",
 ]
 
 import html


Test patch:
Repository: ManimCommunity/manim

Issue:
numpy not imported in `manim.mobject.probability`
## Description of bug / unexpected behavior
<!-- Add a clear and concise description of the problem you encountered. -->
When you try to use `BarChart` it raises an error saying `np is not defined`

## Expected behavior
<!-- Add a clear and concise description of what you expected to happen. -->
To not get the error and show the bar chart.

## How to reproduce the issue
<!-- Provide a piece of code illustrating the undesired behavior. -->

<details><summary>Code for reproducing the problem</summary>

```py
class Barchart(Scene):
  def construct(self):
    ls = [12,12,13,15,19,20,21]
    bg = BarChart(ls)
    self.add(bg)
```

</details>


## Additional media files
<!-- Paste in the files manim produced on rendering the code above. -->

<details><summary>Images/GIFs</summary>

<!-- PASTE MEDIA HERE -->

</details>


## Logs
<details><summary>Terminal output</summary>
<!-- Add "-v DEBUG" when calling manim to generate more detailed logs -->

```
<string> in <module>

<string> in construct(self)

/usr/local/lib/python3.7/dist-packages/manim/mobject/probability.py in add_axes(self, width, height)
    197         x_axis = Line(self.tick_width * LEFT / 2, width * RIGHT)
    198         y_axis = Line(MED_LARGE_BUFF * DOWN, height * UP)
--> 199         ticks = VGroup()
    200         heights = np.linspace(0, height, self.n_ticks + 1)
    201         values = np.linspace(0, self.max_value, self.n_ticks + 1)

NameError: name 'np' is not defined
```

<!-- Insert screenshots here (only when absolutely necessary, we prefer copy/pasted output!) -->

</details>


## System specifications

<details><summary>System Details</summary>

- OS (with version, e.g Windows 10 v2004 or macOS 10.15 (Catalina)):
- RAM:
- Python version (`python/py/python3 --version`):
- Installed modules (provide output from `pip list`):
```
Google Colab
```
</details>

<details><summary>LaTeX details</summary>

+ LaTeX distribution (e.g. TeX Live 2020):
+ Installed LaTeX packages:
<!-- output of `tlmgr list --only-installed` for TeX Live or a screenshot of the Packages page for MikTeX -->
</details>

<details><summary>FFMPEG</summary>

Output of `ffmpeg -version`:

```
PASTE HERE
```
</details>

## Additional comments
<!-- Add further context that you think might be relevant for this issue here. -->



Discussion:

Resolving patch:
diff --git a/manim/mobject/probability.py b/manim/mobject/probability.py
--- a/manim/mobject/probability.py
+++ b/manim/mobject/probability.py
@@ -2,6 +2,7 @@
 
 __all__ = ["SampleSpace", "BarChart"]
 
+import numpy as np
 
 from ..constants import *
 from ..mobject.geometry import Line, Rectangle


Test patch:
Repository: ManimCommunity/manim

Issue:
Command line help text is cut off
## Enhancement proposal
When running `manim --help`, the following output is returned:

```
Manim Community v0.9.0

Usage: manim [OPTIONS] COMMAND [ARGS]...

  Animation engine for explanatory math videos

Options:
  --version  Show version and exit.
  --help     Show this message and exit.

Commands:
  render*  Render SCENE(S) from the input FILE.
  cfg      Manages Manim configuration files.
  init     Sets up a project in current working directory with default...
  new      Create a new project or insert a new scene.
  plugins  Manages Manim plugins.

  Made with <3 by Manim Community developers.
```

As you can see, the help text for `init` is cut off, and does not provide sufficient information about what that command does.
## Additional comments
<!-- Add further context that you think might be relevant. -->



Discussion:
I can update it to show the full text, but it seems like a lot or do you think it looks okay? The last line seems to say the same as the first so think it can at least be removed?

```
Manim Community v0.8.0

Usage: __main__.py [OPTIONS] COMMAND [ARGS]...

  Animation engine for explanatory math videos

Options:
  --version  Show version and exit.
  --help     Show this message and exit.

Commands:
  render*  Render SCENE(S) from the input FILE.
  cfg      Manages Manim configuration files.
  init     Sets up a project in current working directory with default
           settings.
           
           It copies files from templates directory and pastes them in the
           current working dir.
           
           The new project is set up with default settings.

  new      Create a new project or insert a new scene.
  plugins  Manages Manim plugins.

  Made with <3 by Manim Community developers.
```

Resolving patch:
diff --git a/manim/cli/init/commands.py b/manim/cli/init/commands.py
--- a/manim/cli/init/commands.py
+++ b/manim/cli/init/commands.py
@@ -16,13 +16,14 @@
 @click.command(
     context_settings=CONTEXT_SETTINGS,
     epilog=EPILOG,
+    short_help="""Sets up a new project in current working directory with default settings.\n
+It copies files from templates directory and pastes them in the current working dir.
+""",
 )
 def init():
-    """Sets up a project in current working directory with default settings.
+    """Sets up a new project in current working directory with default settings.
 
     It copies files from templates directory and pastes them in the current working dir.
-
-    The new project is set up with default settings.
     """
     cfg = Path("manim.cfg")
     if cfg.exists():


Test patch:
Repository: ManimCommunity/manim

Issue:
Make submobjects in OpenGLMobject a property
## Enhancement proposal
<!-- Add a clear and concise description of your enhancement proposal. In particular,
     if your enhancement introduces changes to the API, illustrate them with
     (fictional) code examples. -->

This proposal is in relation to #1844. There was an issue raised by @hydrobeam where the code window was oversized.. It turned out to be related to submobjects being set like `self.submobjects = [*self.gen_chars()]`, the problem is that family was not being updated. If we change it to a property then we can ensure `assemble_family` is called and anything else required. I suspect there could be more bugs like this that would be well hidden if we rely on other manual calls after submobjects has been set.

## Additional comments
<!-- Add further context that you think might be relevant. -->



Discussion:

Resolving patch:
diff --git a/manim/mobject/opengl_mobject.py b/manim/mobject/opengl_mobject.py
--- a/manim/mobject/opengl_mobject.py
+++ b/manim/mobject/opengl_mobject.py
@@ -101,7 +101,7 @@ def __init__(
         # Event listener
         self.listen_to_events = listen_to_events
 
-        self.submobjects = []
+        self._submobjects = []
         self.parents = []
         self.parent = None
         self.family = [self]
@@ -471,6 +471,12 @@ def replace_submobject(self, index, new_submob):
         self.assemble_family()
         return self
 
+    @deprecated(
+        since="v0.12.0",
+        until="v0.13.0",
+        replacement="self.submobjects",
+        message="Switching to using properties for submobjects",
+    )
     def set_submobjects(self, submobject_list):
         self.remove(*self.submobjects)
         self.add(*submobject_list)
@@ -1904,6 +1910,15 @@ def get_shader_uniforms(self):
     def get_shader_vert_indices(self):
         return self.shader_indices
 
+    @property
+    def submobjects(self):
+        return self._submobjects
+
+    @submobjects.setter
+    def submobjects(self, submobject_list):
+        self.remove(*self.submobjects)
+        self.add(*submobject_list)
+
     # Event Handlers
     """
         Event handling follows the Event Bubbling model of DOM in javascript.
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
@@ -482,10 +482,7 @@ def __init__(
         )
         self.text = text
         if self.disable_ligatures:
-            if config.renderer == "opengl":
-                self.set_submobjects(self.gen_chars())
-            else:
-                self.submobjects = [*self.gen_chars()]
+            self.submobjects = [*self.gen_chars()]
         self.chars = self.get_group_class()(*self.submobjects)
         self.text = text_without_tabs.replace(" ", "").replace("\n", "")
         if config.renderer == "opengl":


Test patch:
Repository: ManimCommunity/manim

Issue:
Improve TransformMatchingAbstractBase to support different types of objects
## Enhancement proposal
<!-- Add a clear and concise description of your enhancement proposal. In particular,
     if your enhancement introduces changes to the API, illustrate them with
     (fictional) code examples. -->

The first line of `TransformMatchingAbstractBase __init__()` method contains an `assert` keyword to make sure the `mobjects` are of the same type. This implementation makes using the class with submobjects of `Tex` or `MathTex` a bit difficult and it just doesn't look right. Here's what I mean: 

I've made this class:

```py
class TransformTest(Scene):
    def construct(self):
        text1 = Tex("What's that? ", "the ", "morse code")
        text2 = Tex("Look! ", "here come dots").next_to(text1, DOWN)

        self.add(text1, text2[0])
        self.wait(0.5)
        #self.play(TransformMatchingShapes(text1[1:], text2[1])) **This does not works (throws assertion error)**
        self.play(TransformMatchingShapes(text1[1:], text2[1:])) #**This does**
```
The line that is commented throws an `assertion error` because the first object is a `VGroup` and the second one is a `SingleStringMathTex`. But the line after that does work. So basically that `assert` statement is preventing the user from making certain transforms which are (and should be IMO) possible. If some extra logic is added to `TransformMatchingAbstractBase`, this kind of issue would be solved.

Here's another example:

```py
class TransformTest(Scene):
    def construct(self):

        text3 = Tex("Result", "eleven", " plus", " two", color=RED).next_to(text2, DOWN)
        text4 = Tex("twelve plus one", color=RED).next_to(text3, DOWN)

        self.add(text3, text4[0])
        self.wait(0.5)
        #self.play(TransformMatchingShapes(text3[1:], text4)) **This doesn't work**
        self.play(TransformMatchingShapes(text3[1:], text4[:])) #**This does**
        self.wait(0.5)
```

Clearly the Transfroms are possible, but I don't think the user should need to add weird syntax that isn't necessary just so the program doesn't spit out an error.

## Additional comments
<!-- Add further context that you think might be relevant. -->
I'm using `TransformMatchingShapes` here but of course this also affects `TransformMatchingTex` since they share the same parent class.



Discussion:
I agree, the assertion checking that both mobjects are of the same type can probably just be removed. For `TransformMatchingTex` we have a separate check in place anyways.

Resolving patch:
diff --git a/manim/animation/transform_matching_parts.py b/manim/animation/transform_matching_parts.py
--- a/manim/animation/transform_matching_parts.py
+++ b/manim/animation/transform_matching_parts.py
@@ -72,7 +72,6 @@ def __init__(
         key_map: Optional[dict] = None,
         **kwargs
     ):
-        assert type(mobject) is type(target_mobject)
 
         if isinstance(mobject, OpenGLVMobject):
             group_type = OpenGLVGroup


Test patch: