fusesoc 2.4__tar.gz → 2.4.3__tar.gz

{fusesoc-2.4 → fusesoc-2.4.3}/.github/workflows/ci.yml

@@ -17,7 +17,7 @@ jobs:
       fail-fast: false
       matrix:
         os:
-        - { icon: 🐧, name: ubuntu-20.04 }
+        - { icon: 🐧, name: ubuntu-22.04 }
         - { icon: 🍎, name: macos-latest }
         # CI is currently broken on Windows
         # https://github.com/olofk/fusesoc/issues/528

{fusesoc-2.4 → fusesoc-2.4.3}/.github/workflows/lint.yml

@@ -1,13 +1,10 @@
 name: lint
 
-on:
-  pull_request:
-  push:
-    branches: [master]
+on: [pull_request, push]
 
 jobs:
   pre-commit:
-    runs-on: ubuntu-20.04
+    runs-on: ubuntu-22.04
     steps:
     - uses: actions/checkout@v4
     - uses: actions/setup-python@v5

{fusesoc-2.4 → fusesoc-2.4.3}/NEWS

@@ -1,3 +1,48 @@
+2.4.3 2024-04-14 Olof Kindgren <olof.kindgren@gmail.com>
+======================================================
+
+* Improve generator caching
+* Check out missing core libraries on updates
+* Added argcompletion
+* Add lockfile support
+* Add mapping support
+* Expose core description files in EDAM
+
+Contributors:
+Erik Bånvik <erik.public@gmail.com>
+Hugo McNally <hugo.mcnally@gmail.com>
+Ivan <ivanmvig@gmail.com>
+Julian Frimmel <julian@fri-me.de>
+Nico Rumpeltin <nico@rumpeltin.de>
+Olof Kindgren <olof.kindgren@gmail.com>
+
+
+2.4.2 2024-01-07 Olof Kindgren <olof.kindgren@gmail.com>
+======================================================
+
+* Support lists in file_input_parameters
+* Add SVN provider
+* Support file-specific defines
+* Always build non-cached generators in work_root
+* Add splitlib filter
+* Warn about non-deterministic virtual cores
+
+Contributors:
+Erik Bånvik <erik.public@gmail.com>
+James Wainwright <james.wainwright@lowrisc.org>
+Mario Werner <nioshd@gmail.com>
+Nazar Kazakov <nazar.kazakov@codethink.co.uk>
+Nico Rumpeltin <nico@rumpeltin.de>
+Olof Kindgren <olof.kindgren@gmail.com>
+
+2.4.1 2024-10-07 Olof Kindgren <olof.kindgren@gmail.com>
+======================================================
+
+* Fix broken documentation builds
+
+Contributors:
+Olof Kindgren <olof.kindgren@gmail.com>
+
 2.4 2024-10-02 Olof Kindgren <olof.kindgren@gmail.com>
 ======================================================
 * Add conflict handling for virtual cores

{fusesoc-2.4 → fusesoc-2.4.3}/PKG-INFO

@@ -1,6 +1,6 @@
-Metadata-Version: 2.1
+Metadata-Version: 2.4
 Name: fusesoc
-Version: 2.4
+Version: 2.4.3
 Summary: Award-winnning package manager and build abstraction tool for HDL code
 Author-email: Olof Kindgren <olof@award-winning.me>
 Maintainer-email: Olof Kindgren <olof@award-winning.me>
@@ -20,9 +20,11 @@ License-File: LICENSE
 Requires-Dist: edalize>=0.4.1
 Requires-Dist: pyparsing>=2.3.1
 Requires-Dist: pyyaml>=6.0
-Requires-Dist: simplesat>=0.8.0
+Requires-Dist: simplesat>=0.9.1
 Requires-Dist: fastjsonschema
 Requires-Dist: jsonschema2md
+Requires-Dist: argcomplete
+Dynamic: license-file
 
 # FuseSoC
 
@@ -61,7 +63,7 @@ full list of system requirements and installation instructions in the
 ### Quick start
 
 To check if FuseSoC is working, and to get an initial feeling for how FuseSoC
-works, you can try to simulate a simple hardware design from our core libray.
+works, you can try to simulate a simple hardware design from our core library.
 
 First, create and enter an empty workspace
 
@@ -87,7 +89,7 @@ add e.g. `--tool=modelsim` or `--tool=xcelium` between `run` and `i2c`.
 Did it work? Great! FuseSoC can be used to create FPGA images, perform
 linting, manage your IP libraries or do formal verification as well.
 Check out the [online documentation](https://fusesoc.readthedocs.io/en/stable/)
-documentation to learn more about creating your own core files and using
+to learn more about creating your own core files and using
 existing ones. If it didn't work, please get in touch (see below).
 
 ## Next steps

{fusesoc-2.4 → fusesoc-2.4.3}/README.md

@@ -35,7 +35,7 @@ full list of system requirements and installation instructions in the
 ### Quick start
 
 To check if FuseSoC is working, and to get an initial feeling for how FuseSoC
-works, you can try to simulate a simple hardware design from our core libray.
+works, you can try to simulate a simple hardware design from our core library.
 
 First, create and enter an empty workspace
 
@@ -61,7 +61,7 @@ add e.g. `--tool=modelsim` or `--tool=xcelium` between `run` and `i2c`.
 Did it work? Great! FuseSoC can be used to create FPGA images, perform
 linting, manage your IP libraries or do formal verification as well.
 Check out the [online documentation](https://fusesoc.readthedocs.io/en/stable/)
-documentation to learn more about creating your own core files and using
+to learn more about creating your own core files and using
 existing ones. If it didn't work, please get in touch (see below).
 
 ## Next steps

{fusesoc-2.4 → fusesoc-2.4.3}/doc/source/conf.py

@@ -12,7 +12,6 @@
 import os
 import sys
 from datetime import datetime
-from distutils.version import LooseVersion
 
 import jsonschema2md
 
@@ -35,16 +34,13 @@ project = "FuseSoC"
 copyright = f"2018-{datetime.now().year}, Olof Kindgren"
 author = "Olof Kindgren"
 
+from importlib.metadata import version as get_version
+
 # The full version, including alpha/beta/rc tags.
-try:
-    from fusesoc.version import version as __version__
-except ImportError:
-    __version__ = "unknown"
+release: str = get_version("fusesoc")
 
-release = __version__
 # The short X.Y version.
-v_major, v_minor = LooseVersion(release).version[:2]
-version = f"{v_major}.{v_minor}"
+version: str = ".".join(release.split(".")[:2])
 
 # -- General configuration ---------------------------------------------------
 
@@ -67,7 +63,7 @@ extensions = [
     "myst_parser",
 ]
 
-intersphinx_mapping = {"https://docs.python.org/3": None}
+intersphinx_mapping = {"python": ("https://docs.python.org/3", None)}
 
 
 # Add any paths that contain templates here, relative to this directory.

{fusesoc-2.4 → fusesoc-2.4.3}/doc/source/index.rst

@@ -8,7 +8,7 @@ This documentation contains material for different audiences.
 
 The :doc:`User Guide <user/index>` explains how to get started with FuseSoC, starting from the installation.
 
-The :doc:`Reference Guide <ref/index>` provides a detailled description of all file formats and APIs.
+The :doc:`Reference Guide <ref/index>` provides a detailed description of all file formats and APIs.
 
 The :doc:`Developer's Guide <dev/index>` is aimed at developers of FuseSoC itself.
 It explains how to set up a development environment, how the source code is structured, and how patches and bug reports can be submitted to the project.

{fusesoc-2.4 → fusesoc-2.4.3}/doc/source/ref/capi1.rst

@@ -361,7 +361,7 @@ main
      - Supported simulators. Valid values are
        icarus, modelsim, verilator, isim and
        xsim. Each simulator have a dedicated
-       section desribed elsewhere in this
+       section described elsewhere in this
        document
 
 

{fusesoc-2.4 → fusesoc-2.4.3}/doc/source/ref/migrations.rst

@@ -278,7 +278,7 @@ Why
 ---
 As an aid for scripts executed during the build process, a number of environment variables were defined. Unfortunately this was done without too much thought and as time moved on, some of these turned out to be a maintenance burden without bringing much benefit, and in some cases without ever being used.
 
-At the same time, the introduction of VLNV and dependency ranges has introduced non-determinism in where the output of a build ends up. For these reasons, it was determined to redefine the rarely used `build_root` variable to point to the the directory containing the work root and exported files. A `--build-root` command-line switch is introduced to explictly set a build_root. Setting `build_root` in `fusesoc.conf` will keep working the same way as before, but the command-line switch takes precedence. CAPI1 cores will no longer export the `BUILD_ROOT` environment variable.
+At the same time, the introduction of VLNV and dependency ranges has introduced non-determinism in where the output of a build ends up. For these reasons, it was determined to redefine the rarely used `build_root` variable to point to the the directory containing the work root and exported files. A `--build-root` command-line switch is introduced to explicitly set a build_root. Setting `build_root` in `fusesoc.conf` will keep working the same way as before, but the command-line switch takes precedence. CAPI1 cores will no longer export the `BUILD_ROOT` environment variable.
 
 These changes affects the following cases:
 

{fusesoc-2.4 → fusesoc-2.4.3}/doc/source/user/build_system/core_files.rst

@@ -165,12 +165,12 @@ For each named file set, several keys are supported:
 Source files
 ~~~~~~~~~~~~
 
-Source files are resolved relative to the location of the core file and must be stored in the same directory as the core file, or in a subdirectory of it.
+For local cores, source files are resolved relative to the location of the core file and must be stored in the same directory as the core file, or in a subdirectory of it. For remote cores, file names are typically relative to the repository or archive root.
 Source file names cannot be absolute paths, or start with ``../``.
 
-Optionally, source files can have attributes; the file ``macros.vh`` is an example of that.
+Optionally, source files can have attributes; the file ``macros.svh`` is an example of that.
 When specifying attributes, end the file name with a colon (``:``), and specify attributes as key-value pairs below it.
-(Alternatively, the equivalent short form syntax can be used, e.g. ``macros.vh: {is_include_file: true}``.)
+(Alternatively, the equivalent short form syntax can be used, e.g. ``macros.svh: {is_include_file: true}``.)
 
 The most common attributes are:
 

{fusesoc-2.4 → fusesoc-2.4.3}/doc/source/user/build_system/dependencies.rst

@@ -12,7 +12,7 @@ This section explains how dependencies are specified, how they are resolved by F
 A dependency example: DualBlinky
 --------------------------------
 
-We introduced the basic FuseSoC features by creating an reusable core called Blinky.
+We introduced the basic FuseSoC features by creating a reusable core called Blinky.
 To illustrate the concept of dependencies in FuseSoC we employ another example: DualBlinky, the "dual-core" version of Blinky.
 Again, all source code is available in the `FuseSoC source tree <https://github.com/olofk/fusesoc>`_ in the ``tests/userguide/dualblinky`` directory.
 
@@ -71,14 +71,14 @@ The following rules apply.
 
 * Files from dependencies are inserted into the file list before the files in the file set where the dependency is declared.
 * The order in which dependencies are listed in the ``depend`` section does not imply any ordering.
-  That is, specifiying ``depend: [A, B]`` does not guarantee that files from core ``A`` are included before the ones from core ``B``.
+  That is, specifying ``depend: [A, B]`` does not guarantee that files from core ``A`` are included before the ones from core ``B``.
   (If such an order is desired, make core ``B`` depend on ``A``.)
 
 What happens if a dependency is specified?
 ------------------------------------------
 
 Declaring a dependency includes the dependent core in the build.
-More specificially, the following sections specified in the ``default`` target of the dependent core are included:
+More specifically, the following sections specified in the ``default`` target of the dependent core are included:
 
 * ``filesets``: File sets to include.
 * ``hooks``: A list of hooks to execute.
@@ -94,7 +94,7 @@ Version constraints
 
 Version constraints specify which version of a dependent core can be used, and which versions are incompatible.
 
-Within a :term:`core file`, version constraints are expressed by prefixing a core name with a version comparision operator.
+Within a :term:`core file`, version constraints are expressed by prefixing a core name with a version comparison operator.
 The following version comparison operators are available.
 
 .. list-table:: Version comparison operators

{fusesoc-2.4 → fusesoc-2.4.3}/doc/source/user/build_system/flow_options.rst

@@ -11,7 +11,7 @@ At the same time, a certain level of tool-specific configurability is required t
 
 There are two categories of options available for the Edalize flows. *Flow options* that affect how the tools are chained together (the flow graph) and *tool options* for the individual tools to be run as part of the flow. This means that since the flow options influence which tools that will be run, some tool options only become available for certain combinations of flow options.
 
-Only one flow can be defined for a target, but the flow it self can be configured in different ways. The example below shows how the `test` target selects and configures a flow. The `flow` key selectes the flow itself. The selected `sim` flow has a *flow option* called `tool` that decides which simulator to use. `iverilog_options` and `vlog_options` are tool options for Icarus Verilog and Siemens QuestaSim/ModelSim and will be passed to the approriate tool if it is present in the flow graph.
+Only one flow can be defined for a target, but the flow itself can be configured in different ways. The example below shows how the `test` target selects and configures a flow. The `flow` key selects the flow itself. The selected `sim` flow has a *flow option* called `tool` that decides which simulator to use. `iverilog_options` and `vlog_options` are tool options for Icarus Verilog and Siemens QuestaSim/ModelSim and will be passed to the appropriate tool if it is present in the flow graph.
 
 This setup selects icarus as the tool, which means the `vlog_options` will not be used. However, all *flow options* and *tool options* are also automatically available on the command-line, which means that passing `--tool=modelsim` as a backend parameter will override the tool setting from the target. The same can be done for the two tool options, with the difference that for flow or tool option that are lists, any additional values passed on the command-line will append rather than replace the values in the core description file.
 

{fusesoc-2.4 → fusesoc-2.4.3}/doc/source/user/build_system/generators.rst

@@ -135,7 +135,7 @@ The final piece of the generators machinery is to run a generator with some spec
               offset: 0xf0000000
               size: 1024
 
-The above core file snippet will register a parametrized generator instance with the name wb_intercon. It will use the generator called `wb_intercon_gen` which FuseSoC has previously found in the depedency tree. Everything listed under the `parameters` key is instance-specific configuration to be sent to the generator.
+The above core file snippet will register a parametrized generator instance with the name wb_intercon. It will use the generator called `wb_intercon_gen` which FuseSoC has previously found in the dependency tree. Everything listed under the `parameters` key is instance-specific configuration to be sent to the generator.
 
 Just registering a generate section will not cause the generator to be invoked. It must also be listed in the target and the generator to be used must be in the dependency tree. The following snippet adds the parameterized generator to the `default` target and adds an explicit dependency on the core that contains the generator. As CAPI2 cores only allow filesets to have dependencies, an empty fileset for this purpose must be created
 
@@ -169,7 +169,7 @@ Generator Cache
 ---------------
 Instead of fusesoc rerunning a generator each time and producing the same result it is possible to configure fusesoc to cache generator output and try to detect if a new run would produce the same output. Since there is no generic way of doing this that will fit all generators a couple of different methods for caching and detecting changes are available.
 
-The `generators` option `cache_type` is used for configuring type of caching. If set to `none` (or if option is omitted) no caching will be used. If set to `input` fusesoc will calculate a SHA256 hash of the generator input yaml file data and use this hash for detecting if something has changed and a rerun would be needed. This would happen if some data in the core file `generate` section, for instance `paramaters`, has changed.
+The `generators` option `cache_type` is used for configuring type of caching. If set to `none` (or if option is omitted) no caching will be used. If set to `input` fusesoc will calculate a SHA256 hash of the generator input yaml file data and use this hash for detecting if something has changed and a rerun would be needed. This would happen if some data in the core file `generate` section, for instance `parameters`, has changed.
 
 If `cache_type` is set to `generator` fusesoc will pass the responsibility for detecting if the previous run to the generator is still up to date. In this mode the generator will always be called and the output directory will be saved.
 

{fusesoc-2.4 → fusesoc-2.4.3}/doc/source/user/build_system/index.rst

@@ -38,5 +38,7 @@ A full reference documentation on the CAPI2 core file format can be found in the
    filters.rst
    flags.rst
    generators.rst
+   virtual_cores.rst
+   mappings.rst
    hooks.rst
    vpi.rst

fusesoc-2.4.3/doc/source/user/build_system/mappings.rst

@@ -0,0 +1,40 @@
+.. _ug_build_system_mappings:
+
+Mappings: Replace cores in the dependency tree
+==============================================
+
+Mappings allow a user of a core to substitute dependencies of the core with other cores without having to edit any of the core or it's dependencies files.
+An example use case is making use of an existing core but substituting one of it's dependencies with a version that some desired changes (e.g. bug fixes).
+
+If you are looking to provide a core with multiple implementations, virtual cores is the recommended and more semantic solution.
+See :ref:`ug_build_system_virtual_cores` for more information on virtual cores.
+Note: virtual cores can also be substituted in mappings.
+
+Declaring mappings
+------------------
+
+Each core file can have one mapping.
+An example mapping core file:
+
+.. code:: yaml
+
+    name: "local:map:override_fpu_and_fifo"
+    mapping:
+      "vendor:lib:fpu":  "local:lib:fpu"
+      "vendor:lib:fifo": "local:lib:fifo"
+
+The example above is a core file with only a mapping property, but any core file may contain a mapping in addition to other properties (e.g. filesets, targets & generators).
+
+Applying mappings
+-----------------
+
+To apply a mapping, provide the VLNV of the core file that contains the desired
+mapping with `fusesoc run`'s `--mapping` argument. Multiple mappings may be
+provided as shown below.
+
+.. code:: sh
+
+    fusesoc run \
+      --mapping local:map:override_fpu_and_fifo \
+      --mapping local:map:another_mapping \
+      vendor:top:main

{fusesoc-2.4 → fusesoc-2.4.3}/doc/source/user/build_system/tool_options.rst

@@ -26,7 +26,7 @@ Typically, these keys are called ``BINARYNAME_options``, and they take a list of
 The example below shows how tool options for Icarus Verilog (``icarus``) and Mentor ModelSim (``modelsim``) are set.
 
 * The ``iverilog`` binary will be called with the ``-g2012`` command-line argument, indicating that SystemVerilog 2012 support should be enabled.
-* Similarily, for ModelSim the argument ``-timescale=1ns/1ns`` will be passed to the ``vlog`` binary, which elaborates the design.
+* Similarly, for ModelSim the argument ``-timescale=1ns/1ns`` will be passed to the ``vlog`` binary, which elaborates the design.
 
 .. code-block:: yaml
 

fusesoc-2.4.3/doc/source/user/build_system/virtual_cores.rst

@@ -0,0 +1,8 @@
+.. _ug_build_system_virtual_cores:
+
+Virtual Cores: Provide a common interface
+=========================================
+
+.. todo::
+
+   Document virtual cores.

fusesoc-2.4.3/doc/source/user/cli.rst

@@ -0,0 +1,56 @@
+.. _ug_cli:
+
+***************
+Running FuseSoC
+***************
+
+FuseSoC is a command-line tool; this section explains how to use it.
+The following content is aimed at users who already have a hardware design which uses FuseSoC.
+
+Build a design
+==============
+
+The ``fusesoc run`` group of commands is used to setup, build, and (if possible) run a design.
+The exact actions taken by the individual steps depend on the toolflow.
+
+::
+
+    usage: fusesoc run [-h] [--no-export] [--build-root BUILD_ROOT] [--setup] [--build] [--run] [--target TARGET] [--tool TOOL] [--flag FLAG] [--system-name SYSTEM_NAME] system ...
+
+    positional arguments:
+      system                Select a system to operate on
+      backendargs           arguments to be sent to backend
+
+    optional arguments:
+      -h, --help            show this help message and exit
+      --no-export           Reference source files from their current location instead of exporting to a build tree
+      --build-root BUILD_ROOT
+                            Output directory for build. Defaults to build/$VLNV
+      --setup               Execute setup stage
+      --build               Execute build stage
+      --run                 Execute run stage
+      --target TARGET       Override default target
+      --tool TOOL           Override default tool for target
+      --flag FLAG           Set custom use flags. Can be specified multiple times
+      --system-name SYSTEM_NAME
+                            Override default VLNV name for system
+
+When FuseSoC is invoked with the run command, it will create an empty working directory called `work_root` internally, where it by default will create all project files, copy all used source files, build and optionally run the project.
+
+Setup, build and run
+--------------------
+
+The process of running EDA tools is divided into three steps called *setup*, *build* and *run*. The *setup* stage creates the working directory and all project files. The *build* stage runs one or more EDA tools to build an artifact, e.g. a GDS, simulation model or FPGA image. The *run* stage is only implemented for some tool flows, such as simulation flows where it runs the simulation. Some FPGA flows uses the *run* stage to program an FPGA device.
+
+Normally FuseSoC runs all three stages, but if the `--setup` flag is added, it will stop after the setup stage and if the `--build` flag is set it will stop after the build stage. Many of the newer backends don't need these flags and will instead only run setup or build when input files or options have changed.
+
+Work root
+---------
+`work_root` is a private working directory and should not be shared between different builds. It is however perfectly fine to reuse the working directory for e.g. running several simulations using different runtime options as long as the build-time options and source files are not modified.
+
+By default, FuseSoC will use `build/<sanitized VLNV>/<target>`, where `<sanitized VLNV>` is the top-level VLNV with underscore instead of colon as the separator. For the Flow API, `<target>` is just the name of the target in the core description file, e.g. `sim`. For the old Tool API, it is a combination of target name and the tool backend, e.g. `sim-verilator`. The work root directory can be changed with the `--work-root` option.
+
+Exporting source files
+----------------------
+
+The standard behavior for FuseSoC is to copy all used source files into a subdirectory of the work root. This has three advantages. The work root is self-contained with all the source files and can be copied elsewhere for archival purposes or to build on another machine. No stray files are picked up by mistake from the original source directories. It is always possible to know from exactly which files a build was created. Despite this, there are situations where it is preferable to reference the source files from their original location. This can be done by adding the `--no-export` flag.

{fusesoc-2.4 → fusesoc-2.4.3}/doc/source/user/introduction.rst

@@ -20,7 +20,7 @@ Its main purpose is to increase reuse of IP (Intellectual Property) cores and be
 
 - set up continuous integration
 
-**FuseSoC is non-intrusive** Most existing designs doesn't need any changes to work with FuseSoC. Any FuseSoC-specific patches can be applied on the fly during implementation or simulation
+**FuseSoC is non-intrusive** Most existing designs don't need any changes to work with FuseSoC. Any FuseSoC-specific patches can be applied on the fly during implementation or simulation
 
 **FuseSoC is modular** It can be used as an end-to-end flow, to create initial project files for an EDA tool or integrate with your custom workflow
 

{fusesoc-2.4 → fusesoc-2.4.3}/doc/source/user/package_manager/index.rst

@@ -54,7 +54,7 @@ FuseSoC is launched. The library locations specified from the
 command-line will be parsed after those in ``fusesoc.conf``
 
 For each library location, FuseSoC will recursively search for files
-with a *.core* suffix. Each of these files will be parsed and addded to
+with a *.core* suffix. Each of these files will be parsed and added to
 the in-memory FuseSoC database if they are valid ``.core`` files.
 
 Several ``.core`` files can reside in the same directory and they will all be parsed.

{fusesoc-2.4 → fusesoc-2.4.3}/fusesoc/capi2/core.py

@@ -10,6 +10,8 @@ import os
 import shutil
 import warnings
 from filecmp import cmp
+from types import MappingProxyType
+from typing import Mapping, Optional
 
 from fusesoc import utils
 from fusesoc.capi2.coredata import CoreData
@@ -93,7 +95,8 @@ class Core:
 
         dirs = list(set(map(os.path.dirname, src_files)))
         for d in dirs:
-            os.makedirs(os.path.join(dst_dir, d), exist_ok=True)
+            if not os.path.isabs(d):
+                os.makedirs(os.path.join(dst_dir, d), exist_ok=True)
 
         for f in src_files:
             if f.startswith(".."):
@@ -274,6 +277,7 @@ class Core:
                     if (type(v) == bool and v == True)
                     or (type(v) == str and len(v)) > 0
                     or (type(v) == list and len(v)) > 0
+                    or (type(v) == dict and len(v)) > 0
                 }
 
                 _src_files.append(attributes)
@@ -628,3 +632,7 @@ Targets:
 
     def get_description(self):
         return self._coredata.get_description()
+
+    @property
+    def mapping(self) -> Optional[Mapping[str, str]]:
+        return MappingProxyType(self._coredata.get("mapping", {}))

{fusesoc-2.4 → fusesoc-2.4.3}/fusesoc/capi2/coredata.py

@@ -43,22 +43,18 @@ class CoreData:
 
         if type(data) == list:
             remove = []
-            append = []
-            for i in data:
+            for idx, i in enumerate(data):
                 if type(i) == str and len(i) > 0 and "?" in i:
                     expanded = Exprs(i).expand(flags)
                     if i != expanded:
-                        remove.append(i)
                         if len(expanded) > 0:
-                            append.append(expanded)
+                            data[idx] = expanded
+                        else:
+                            remove.append(idx)
                 elif type(i) == dict or type(i) == list:
                     self._expand_use(i, flags)
-
-            for i in remove:
-                data.remove(i)
-
-            for i in append:
-                data.append(i)
+            for i in reversed(remove):
+                data.pop(i)
 
     def _append_lists(self, data):
         if type(data) == list: