From f58061d8363f188cd505ff731ca955f0bc5ac890 Mon Sep 17 00:00:00 2001 From: sciencewhiz Date: Sat, 23 Nov 2024 20:29:22 -0800 Subject: [PATCH 1/3] Update formatting to avoid blockquote on furo --- source/docs/beta/tasks/task-3-port-code.rst | 12 +++++------ .../sensors/accelerometers-hardware.rst | 6 +++--- .../docs/hardware/sensors/gyros-hardware.rst | 6 +++--- .../hardware/sensors/proximity-switches.rst | 10 ++++----- .../sensors/sensor-overview-hardware.rst | 21 ++++++++----------- .../roborio-network-troubleshooting.rst | 6 +++--- .../advanced-controls/controls-glossary.rst | 3 --- .../advanced-controls/filters/debouncer.rst | 6 +++--- 8 files changed, 32 insertions(+), 38 deletions(-) diff --git a/source/docs/beta/tasks/task-3-port-code.rst b/source/docs/beta/tasks/task-3-port-code.rst index ce5840e160..0c9c1f4a1c 100644 --- a/source/docs/beta/tasks/task-3-port-code.rst +++ b/source/docs/beta/tasks/task-3-port-code.rst @@ -13,9 +13,9 @@ Desired Feedback Please keep the following questions in mind as you complete the task and include this information, as appropriate, in your Task 3 report. - 1. Note any required changes to your robot program not detailed in the :doc:`documentation for porting robot code `. - 2. What problems or difficulties did you encounter? - 3. What questions did you have during the process? - 4. Any specific suggestions on improving the documentation? (Were any instructions unclear?) - 5. Compare the Free RAM on the DS diagnostics tab to similar code running on the 2024 image. - 6. Is there anything else you want to tell us related to this task? +1. Note any required changes to your robot program not detailed in the :doc:`documentation for porting robot code `. +2. What problems or difficulties did you encounter? +3. What questions did you have during the process? +4. Any specific suggestions on improving the documentation? (Were any instructions unclear?) +5. Compare the Free RAM on the DS diagnostics tab to similar code running on the 2024 image. +6. Is there anything else you want to tell us related to this task? diff --git a/source/docs/hardware/sensors/accelerometers-hardware.rst b/source/docs/hardware/sensors/accelerometers-hardware.rst index 19edef55da..eb63c300a5 100644 --- a/source/docs/hardware/sensors/accelerometers-hardware.rst +++ b/source/docs/hardware/sensors/accelerometers-hardware.rst @@ -43,6 +43,6 @@ The roboRIO has a built-in accelerometer, which does not need any external conne Several popular FRC devices (known as "inertial measurement units," or "IMUs") combine both an accelerometer and a gyroscope. Popular FRC example include: - - [Analog Devices ADIS16448 and ADIS 16470 IMUs](https://www.analog.com/en/landing-pages/001/first.html) - - [CTRE Pigeon IMU](https://store.ctr-electronics.com/gadgeteer-pigeon-imu/) - - [Kauai Labs NavX](https://pdocs.kauailabs.com/navx-mxp/) +- [Analog Devices ADIS16448 and ADIS 16470 IMUs](https://www.analog.com/en/landing-pages/001/first.html) +- [CTRE Pigeon IMU](https://store.ctr-electronics.com/gadgeteer-pigeon-imu/) +- [Kauai Labs NavX](https://pdocs.kauailabs.com/navx-mxp/) diff --git a/source/docs/hardware/sensors/gyros-hardware.rst b/source/docs/hardware/sensors/gyros-hardware.rst index 0edeac0d67..054e9bec99 100644 --- a/source/docs/hardware/sensors/gyros-hardware.rst +++ b/source/docs/hardware/sensors/gyros-hardware.rst @@ -8,9 +8,9 @@ Gyroscopes (or "gyros", for short) are devices that measure rate-of-rotation. T Several popular FRC\ |reg| devices known as :ref:`IMUs ` (Inertial Measurement Units) combine 3-axis gyros, accelerometers and other position sensors into one device. Some popular examples are: - - [Analog Devices ADIS16448 and ADIS 16470 IMUs](https://www.analog.com/en/landing-pages/001/first.html) - - [CTRE Pigeon IMU](https://store.ctr-electronics.com/gadgeteer-pigeon-imu/) - - [Kauai Labs NavX](https://pdocs.kauailabs.com/navx-mxp/) +- [Analog Devices ADIS16448 and ADIS 16470 IMUs](https://www.analog.com/en/landing-pages/001/first.html) +- [CTRE Pigeon IMU](https://store.ctr-electronics.com/gadgeteer-pigeon-imu/) +- [Kauai Labs NavX](https://pdocs.kauailabs.com/navx-mxp/) ## Types of Gyros diff --git a/source/docs/hardware/sensors/proximity-switches.rst b/source/docs/hardware/sensors/proximity-switches.rst index 9b724ef730..632bab7cb9 100644 --- a/source/docs/hardware/sensors/proximity-switches.rst +++ b/source/docs/hardware/sensors/proximity-switches.rst @@ -18,11 +18,11 @@ The digital inputs on the roboRIO have pull-up resistors that will make the inpu There are several types of proximity switches that are commonly used in FRC\ |reg|: - - `Mechanical Proximity Switches ("limit switches")`_ - - `Magnetic Proximity Switches`_ - - `Inductive Proximity Switches`_ - - `Photoelectric Proximity Switches`_ - - `Time-of-flight Proximity Switches`_ +- `Mechanical Proximity Switches ("limit switches")`_ +- `Magnetic Proximity Switches`_ +- `Inductive Proximity Switches`_ +- `Photoelectric Proximity Switches`_ +- `Time-of-flight Proximity Switches`_ ### Mechanical Proximity Switches ("limit switches") diff --git a/source/docs/hardware/sensors/sensor-overview-hardware.rst b/source/docs/hardware/sensors/sensor-overview-hardware.rst index 1484568f6b..16a2ba2d89 100644 --- a/source/docs/hardware/sensors/sensor-overview-hardware.rst +++ b/source/docs/hardware/sensors/sensor-overview-hardware.rst @@ -17,22 +17,19 @@ Sensors used in FRC can be generally categorized in two different ways: by funct Sensors can provide feedback on a variety of different aspects of the robot's state. Sensor functions common to FRC include: - :doc:`Proximity switches ` - - * Mechanical proximity switches ("limit switches") - * Magnetic proximity switches - * Inductive proximity switches - * Photoelectric proximity switches + * Mechanical proximity switches ("limit switches") + * Magnetic proximity switches + * Inductive proximity switches + * Photoelectric proximity switches - Distance sensors - - * :doc:`Ultrasonic sensors ` - * :doc:`Triangulating rangefinders ` - * :doc:`LIDAR ` + * :doc:`Ultrasonic sensors ` + * :doc:`Triangulating rangefinders ` + * :doc:`LIDAR ` - Shaft rotation sensors - - * :doc:`Encoders ` - * :doc:`Potentiometers ` + * :doc:`Encoders ` + * :doc:`Potentiometers ` - :doc:`Accelerometers ` diff --git a/source/docs/networking/networking-introduction/roborio-network-troubleshooting.rst b/source/docs/networking/networking-introduction/roborio-network-troubleshooting.rst index e006d08813..f0bc5d3e63 100644 --- a/source/docs/networking/networking-introduction/roborio-network-troubleshooting.rst +++ b/source/docs/networking/networking-introduction/roborio-network-troubleshooting.rst @@ -17,10 +17,10 @@ If there is no response, try pinging ``10.TE.AM.2`` (:ref:`TE.AM IP Notation :guilabel:`Settings` -> :guilabel:`Network & Internet`. Depending on your network, select :guilabel:`Wifi` or :guilabel:`Ethernet`. Then click on your connected network. Scroll down to **IP settings** and click :guilabel:`Edit` and ensure the :guilabel:`Automatic (DHCP)` option is selected. +If pinging the IP address directly fails, you may have an issue with the network configuration of the PC. The PC should be configured to **Automatic**. To check this, click :guilabel:`Start` -> :guilabel:`Settings` -> :guilabel:`Network & Internet`. Depending on your network, select :guilabel:`Wifi` or :guilabel:`Ethernet`. Then click on your connected network. Scroll down to **IP settings** and click :guilabel:`Edit` and ensure the :guilabel:`Automatic (DHCP)` option is selected. ## USB Connection Troubleshooting diff --git a/source/docs/software/advanced-controls/controls-glossary.rst b/source/docs/software/advanced-controls/controls-glossary.rst index 4f32953a36..10b754cd20 100644 --- a/source/docs/software/advanced-controls/controls-glossary.rst +++ b/source/docs/software/advanced-controls/controls-glossary.rst @@ -61,7 +61,6 @@ input An input to the :term:`plant` (hence the name) that can be used to change the :term:`plant's ` :term:`state`. - - Ex. A flywheel will have 1 input: the voltage of the motor driving it. - Ex. A drivetrain might have 2 inputs: the voltages of the left and right motors. @@ -87,7 +86,6 @@ output Measurements from sensors. There can be more measurements than states. These outputs are used in the "correct" step of Kalman Filters. - - Ex. A flywheel might have 1 :term:`output` from a encoder that measures it's velocity. - Ex. A drivetrain might use solvePNP and V-SLAM to find it's x/y/heading position on the field. It's fine that there are 6 measurements (solvePNP x/y/heading and V-SLAM x/y/heading) and 3 states (robot x/y/heading). @@ -129,7 +127,6 @@ state A characteristic of a :term:`system` (e.g., velocity) that can be used to determine the :term:`system `\'s future behavior. In state-space notation, the state of a system is written as a column vector describing its position in state-space. - - Ex. A drivetrain system might have the states :math:`\begin{bmatrix}x \\ y \\ \theta \end{bmatrix}` to describe its position on the field. - Ex. An elevator system might have the states :math:`\begin{bmatrix} \text{position} \\ \text{velocity} \end{bmatrix}` to describe its current height and velocity. diff --git a/source/docs/software/advanced-controls/filters/debouncer.rst b/source/docs/software/advanced-controls/filters/debouncer.rst index 2640ab3a8e..03b5735ff0 100644 --- a/source/docs/software/advanced-controls/filters/debouncer.rst +++ b/source/docs/software/advanced-controls/filters/debouncer.rst @@ -8,9 +8,9 @@ Debouncing is implemented in WPILib by the ``Debouncer`` class ([Java](https://g The WPILib ``Debouncer`` can be configured in three different modes: - * Rising (default): Debounces rising edges (transitions from `false` to `true`) only. - * Falling: Debounces falling edges (transitions from `true` to `false`) only. - * Both: Debounces all transitions. +* Rising (default): Debounces rising edges (transitions from `false` to `true`) only. +* Falling: Debounces falling edges (transitions from `true` to `false`) only. +* Both: Debounces all transitions. ## Usage From 623b3d29cae5bfe9184eee358238e69808c6c7ff Mon Sep 17 00:00:00 2001 From: sciencewhiz Date: Sat, 23 Nov 2024 22:29:36 -0800 Subject: [PATCH 2/3] Update advanced-controls --- .../introduction/introduction-to-pid.rst | 1 - .../introduction/tuning-flywheel.rst | 4 ++-- .../introduction/tuning-turret.rst | 4 ++-- .../introduction/tuning-vertical-arm.rst | 4 ++-- .../trajectories/constraints.rst | 16 ++++++++-------- 5 files changed, 14 insertions(+), 15 deletions(-) diff --git a/source/docs/software/advanced-controls/introduction/introduction-to-pid.rst b/source/docs/software/advanced-controls/introduction/introduction-to-pid.rst index d3d590f0e5..f247b1e8c5 100644 --- a/source/docs/software/advanced-controls/introduction/introduction-to-pid.rst +++ b/source/docs/software/advanced-controls/introduction/introduction-to-pid.rst @@ -27,7 +27,6 @@ Roughly speaking: the proportional term drives the position error to zero, the d Throughout the WPILib documentation, you'll see two ways of writing the tunable constants of the PID controller. For example, for the proportional gain: - * :math:`K_p` is the standard math-equation-focused way to notate the constant. * ``kP`` is a common way to see it written as a variable in software. diff --git a/source/docs/software/advanced-controls/introduction/tuning-flywheel.rst b/source/docs/software/advanced-controls/introduction/tuning-flywheel.rst index bcf8f980b0..54768bbb74 100644 --- a/source/docs/software/advanced-controls/introduction/tuning-flywheel.rst +++ b/source/docs/software/advanced-controls/introduction/tuning-flywheel.rst @@ -6,8 +6,8 @@ In this section, we will tune a simple velocity controller for a flywheel. The Our "Flywheel" consists of: - * A rotating inertial mass which launches the game piece (the flywheel) - * A motor (and possibly a gearbox) driving the mass. +* A rotating inertial mass which launches the game piece (the flywheel) +* A motor (and possibly a gearbox) driving the mass. For the purposes of this tutorial, this plant is modeled with the same equation used by WPILib's :ref:`docs/software/advanced-controls/controllers/feedforward:SimpleMotorFeedforward`, with additional adjustment for sensor delay and gearbox inefficiency. The simulation assumes the plant is controlled by feedforward and feedback controllers, composed in this fashion: diff --git a/source/docs/software/advanced-controls/introduction/tuning-turret.rst b/source/docs/software/advanced-controls/introduction/tuning-turret.rst index f836d83e18..7cc186c184 100644 --- a/source/docs/software/advanced-controls/introduction/tuning-turret.rst +++ b/source/docs/software/advanced-controls/introduction/tuning-turret.rst @@ -8,8 +8,8 @@ A turret rotates some mechanism side-to-side to position it for scoring gamepiec Our "turret" consists of: - * A rotating inertial mass (the turret) - * A motor and gearbox driving the mass +* A rotating inertial mass (the turret) +* A motor and gearbox driving the mass For the purposes of this tutorial, this plant is modeled with the same equation used by WPILib's :ref:`docs/software/advanced-controls/controllers/feedforward:SimpleMotorFeedforward`, with additional adjustment for sensor delay and gearbox inefficiency. The simulation assumes the plant is controlled by feedforward and feedback controllers, composed in this fashion: diff --git a/source/docs/software/advanced-controls/introduction/tuning-vertical-arm.rst b/source/docs/software/advanced-controls/introduction/tuning-vertical-arm.rst index 82f5b52ae0..c81f9dab24 100644 --- a/source/docs/software/advanced-controls/introduction/tuning-vertical-arm.rst +++ b/source/docs/software/advanced-controls/introduction/tuning-vertical-arm.rst @@ -8,8 +8,8 @@ Vertical arms are commonly used to lift gamepieces from the ground up to a scori Our "vertical arm" consists of: - * A mass on a stick, under the force of gravity, pivoting around an axle. - * A motor and gearbox driving the axle to which the mass-on-a-stick is attached +* A mass on a stick, under the force of gravity, pivoting around an axle. +* A motor and gearbox driving the axle to which the mass-on-a-stick is attached For the purposes of this tutorial, this plant is modeled with the same equation used by WPILib's :ref:`docs/software/advanced-controls/controllers/feedforward:ArmFeedforward`, with additional adjustment for sensor delay and gearbox inefficiency. The simulation assumes the plant is controlled by feedforward and feedback controllers, composed in this fashion: diff --git a/source/docs/software/advanced-controls/trajectories/constraints.rst b/source/docs/software/advanced-controls/trajectories/constraints.rst index abb365f4bb..cd223a53af 100644 --- a/source/docs/software/advanced-controls/trajectories/constraints.rst +++ b/source/docs/software/advanced-controls/trajectories/constraints.rst @@ -6,14 +6,14 @@ For example, a custom constraint can keep the velocity of the trajectory under a ## WPILib-Provided Constraints WPILib includes a set of predefined constraints that users can utilize when generating trajectories. The list of WPILib-provided constraints is as follows: - - ``CentripetalAccelerationConstraint``: Limits the centripetal acceleration of the robot as it traverses along the trajectory. This can help slow down the robot around tight turns. - - ``DifferentialDriveKinematicsConstraint``: Limits the velocity of the robot around turns such that no wheel of a differential-drive robot goes over a specified maximum velocity. - - ``DifferentialDriveVoltageConstraint``: Limits the acceleration of a differential drive robot such that no commanded voltage goes over a specified maximum. - - ``EllipticalRegionConstraint``: Imposes a constraint only in an elliptical region on the field. - - ``MaxVelocityConstraint``: Imposes a max velocity constraint. This can be composed with the ``EllipticalRegionConstraint`` or ``RectangularRegionConstraint`` to limit the velocity of the robot only in a specific region. - - ``MecanumDriveKinematicsConstraint``: Limits the velocity of the robot around turns such that no wheel of a mecanum-drive robot goes over a specified maximum velocity. - - ``RectangularRegionConstraint``: Imposes a constraint only in a rectangular region on the field. - - ``SwerveDriveKinematicsConstraint``: Limits the velocity of the robot around turns such that no wheel of a swerve-drive robot goes over a specified maximum velocity. +- ``CentripetalAccelerationConstraint``: Limits the centripetal acceleration of the robot as it traverses along the trajectory. This can help slow down the robot around tight turns. +- ``DifferentialDriveKinematicsConstraint``: Limits the velocity of the robot around turns such that no wheel of a differential-drive robot goes over a specified maximum velocity. +- ``DifferentialDriveVoltageConstraint``: Limits the acceleration of a differential drive robot such that no commanded voltage goes over a specified maximum. +- ``EllipticalRegionConstraint``: Imposes a constraint only in an elliptical region on the field. +- ``MaxVelocityConstraint``: Imposes a max velocity constraint. This can be composed with the ``EllipticalRegionConstraint`` or ``RectangularRegionConstraint`` to limit the velocity of the robot only in a specific region. +- ``MecanumDriveKinematicsConstraint``: Limits the velocity of the robot around turns such that no wheel of a mecanum-drive robot goes over a specified maximum velocity. +- ``RectangularRegionConstraint``: Imposes a constraint only in a rectangular region on the field. +- ``SwerveDriveKinematicsConstraint``: Limits the velocity of the robot around turns such that no wheel of a swerve-drive robot goes over a specified maximum velocity. .. note:: The ``DifferentialDriveVoltageConstraint`` only ensures that theoretical voltage commands do not go over the specified maximum using a :ref:`feedforward model `. If the robot were to deviate from the reference while tracking, the commanded voltage may be higher than the specified maximum. From 038d81ce369b135602bb8226af7caaecdd29043c Mon Sep 17 00:00:00 2001 From: sciencewhiz Date: Sun, 24 Nov 2024 19:01:49 -0800 Subject: [PATCH 3/3] Update basic programming --- .../basic-programming/coordinate-system.rst | 35 ++++++++----------- .../basic-programming/reading-stacktraces.rst | 10 +++--- 2 files changed, 19 insertions(+), 26 deletions(-) diff --git a/source/docs/software/basic-programming/coordinate-system.rst b/source/docs/software/basic-programming/coordinate-system.rst index e10316af13..fb0428a5ea 100644 --- a/source/docs/software/basic-programming/coordinate-system.rst +++ b/source/docs/software/basic-programming/coordinate-system.rst @@ -93,16 +93,14 @@ The code snippet below uses the ``DifferentialDrive`` and ``Joystick`` classes t The code calls the ``DifferentialDrive.arcadeDrive(xSpeed, zRotation)`` method, with values it gets from the ``Joystick`` class: - The first argument is ``xSpeed`` - - - Robot: ``xSpeed`` is the speed along the robot's X axis, which is forward/backward. - - Joystick: The driver sets forward/backward speed by rotating the joystick along its Y axis, which is pushing the joystick forward/backward. - - Code: Moving the joystick forward is negative Y rotation, whereas moving the robot forward is along the positive X axis. This means the joystick value needs to be inverted by placing a - (minus sign) in front of the value. + - Robot: ``xSpeed`` is the speed along the robot's X axis, which is forward/backward. + - Joystick: The driver sets forward/backward speed by rotating the joystick along its Y axis, which is pushing the joystick forward/backward. + - Code: Moving the joystick forward is negative Y rotation, whereas moving the robot forward is along the positive X axis. This means the joystick value needs to be inverted by placing a - (minus sign) in front of the value. - The second argument is ``zRotation`` - - - Robot: ``zRotation`` is the speed of rotation along the robot's Z axis, which is rotating left/right. - - Joystick: The driver sets rotation speed by rotating the joystick along its X axis, which is pushing the joystick left/right. - - Code: Moving the joystick to the right is positive X rotation, whereas robot rotation is CCW positive. This means the joystick value needs to be inverted by placing a - (minus sign) in front of the value. + - Robot: ``zRotation`` is the speed of rotation along the robot's Z axis, which is rotating left/right. + - Joystick: The driver sets rotation speed by rotating the joystick along its X axis, which is pushing the joystick left/right. + - Code: Moving the joystick to the right is positive X rotation, whereas robot rotation is CCW positive. This means the joystick value needs to be inverted by placing a - (minus sign) in front of the value. ### Mecanum drivetrain example @@ -133,23 +131,20 @@ Mecanum drivetrains are holonomic, meaning they have the ability to move side-to The code calls the ``MecanumDrive.driveCartesian(xSpeed, ySpeed, zRotation)`` method, with values it gets from the ``Joystick`` class: - The first argument is ``xSpeed`` - - - Robot: ``xSpeed`` is the speed along the robot's X axis, which is forward/backward. - - Joystick: The driver sets forward/backward speed by rotating the joystick along its Y axis, which is pushing the joystick forward/backward. - - Code: Moving the joystick forward is negative Y rotation, whereas robot forward is along the positive X axis. This means the joystick value needs to be inverted by placing a - (minus sign) in front of the value. + - Robot: ``xSpeed`` is the speed along the robot's X axis, which is forward/backward. + - Joystick: The driver sets forward/backward speed by rotating the joystick along its Y axis, which is pushing the joystick forward/backward. + - Code: Moving the joystick forward is negative Y rotation, whereas robot forward is along the positive X axis. This means the joystick value needs to be inverted by placing a - (minus sign) in front of the value. - The second argument is ``ySpeed`` - - - Robot: ``ySpeed`` is the speed along the robot's Y axis, which is left/right. - - Joystick: The driver sets left/right speed by rotating the joystick along its X axis, which is pushing the joystick left/right. - - Code: Moving the joystick to the right is positive X rotation, whereas robot right is along the negative Y axis. This means the joystick value needs to be inverted by placing a - (minus sign) in front of the value. + - Robot: ``ySpeed`` is the speed along the robot's Y axis, which is left/right. + - Joystick: The driver sets left/right speed by rotating the joystick along its X axis, which is pushing the joystick left/right. + - Code: Moving the joystick to the right is positive X rotation, whereas robot right is along the negative Y axis. This means the joystick value needs to be inverted by placing a - (minus sign) in front of the value. - The third argument is ``zRotation`` - - - Robot: ``zRotation`` is the speed of rotation along the robot's Z axis, which is rotating left/right. - - Joystick: The driver sets rotation speed by twisting the joystick along its Z axis, which is twisting the joystick left/right. - - Code: Twisting the joystick to the right is positive Z rotation, whereas robot rotation is CCW positive. This means the joystick value needs to be inverted by placing a - (minus sign) in front of the value. + - Robot: ``zRotation`` is the speed of rotation along the robot's Z axis, which is rotating left/right. + - Joystick: The driver sets rotation speed by twisting the joystick along its Z axis, which is twisting the joystick left/right. + - Code: Twisting the joystick to the right is positive Z rotation, whereas robot rotation is CCW positive. This means the joystick value needs to be inverted by placing a - (minus sign) in front of the value. ### Swerve drivetrain example diff --git a/source/docs/software/basic-programming/reading-stacktraces.rst b/source/docs/software/basic-programming/reading-stacktraces.rst index 61109685b0..ce14df42c9 100644 --- a/source/docs/software/basic-programming/reading-stacktraces.rst +++ b/source/docs/software/basic-programming/reading-stacktraces.rst @@ -53,7 +53,6 @@ To start, search above the ``unexpected error has occurred`` for the stack trace * The exception was a ``java.lang.NullPointerException`` * The error happened while running line ``24`` inside of ``Robot.java`` - * ``robotInit`` was the name of the method executing when the error happened. * ``robotInit`` is a function in the ``frc.robot.Robot`` package (AKA, your team's code) @@ -100,7 +99,6 @@ To start, search above the ``unexpected error has occurred`` for the stack trace * The reason it paused was one thread having an ``exception`` * The error happened while running line ``20`` inside of ``Robot.cpp`` - * ``RobotInit`` was the name of the method executing when the error happened. * ``RobotInit`` is a function in the ``Robot::`` namespace (AKA, your team's code) @@ -123,8 +121,8 @@ Often, just looking in (or near) the problematic location in code will be fruitf A key strategy for analyzing code is to ask the following questions: - * When was the last time the code "worked" (I.e., didn't have this particular error)? - * What has changed in the code between the last working version, and now? +* When was the last time the code "worked" (I.e., didn't have this particular error)? +* What has changed in the code between the last working version, and now? Frequent testing and careful code changes help make this particular strategy more effective. @@ -140,8 +138,8 @@ Sometimes, just looking at code isn't enough to spot the issue. The :ref:`single If all else fails, you can seek out advice and help from others (both in-person and online). When working with folks who aren't familiar with your codebase, it's very important to provide the following information: - * Access to your source code, (EX: :ref:`on github.com `) - * The **full text** of the error, including the full stack trace. +* Access to your source code, (EX: :ref:`on github.com `) +* The **full text** of the error, including the full stack trace. ## Common Examples & Patterns