{"owner":"nlohmann","repo":"json","hasSkills":true,"totalSkillsCount":8,"totalTokensCount":3720,"categories":["anthropic-skill","plugin-manifest","cursor-rule"],"hasMcp":false,"mcpConfig":null,"found":["tools/amalgamate/config_json.json","tools/amalgamate/CHANGES.md","tools/generate_natvis/README.md","tools/amalgamate/config_json_fwd.json","tools/gdb_pretty_printer/README.md","tools/serve_header/README.md","tools/amalgamate/README.md",".cursorrules (python-flask-json-guide-cursorrules-prompt-file.mdc)"],"skills":{"tools/amalgamate/config_json.json":"{\n\t\"project\": \"JSON for Modern C++\",\n\t\"target\": \"single_include/nlohmann/json.hpp\",\n\t\"sources\": [\n\t\t\"include/nlohmann/json.hpp\"\n\t],\n\t\"include_paths\": [\"include\"]\n}\n","tools/amalgamate/CHANGES.md":"The following changes have been made to the code with respect to :\n\n- Resolved inspection results from PyCharm:\n - replaced tabs with spaces\n - added encoding annotation\n - reindented file to remove trailing whitespaces\n - unused import `sys`\n - membership check\n - made function from `_is_within`\n - removed unused variable `actual_path`\n- Added the optional config key `external`: include paths listed there are kept as\n `#include` directives instead of being inlined (the first directive per path; the\n repeated ones are commented out).\n","tools/generate_natvis/README.md":"# generate_natvis.py\n\nGenerate the Natvis debugger visualization file for namespace combinations with up to two ABI tags.\n\nThe checked-in `nlohmann_json.natvis` covers the default namespace (no ABI tags), every single ABI tag, and every pair\nof ABI tags, with both versioned and unversioned namespace variants. Configurations that enable three or more ABI tags\nare not covered by this reduced file; use `--abi-tags` or `--all` (see below) to generate a file for them.\n\nThe ABI tag list and the library version are parsed from\n`include/nlohmann/detail/abi_macros.hpp`, so this script must be re-run (via\n`make natvis`) whenever an `NLOHMANN_JSON_ABI_TAG_*` macro is added to that\nfile or the library version is bumped — otherwise the committed\n`nlohmann_json.natvis` drifts from the header it visualizes, and\n`make check-amalgamation` fails.\n\n## Usage\n\n```shell\nmake natvis\n```\n\n`make natvis` sets up a virtual environment `tools/generate_natvis/venv` with the dependencies from\n`requirements.txt` (Jinja2) and runs the script with it. Alternatively, install the requirements yourself and run:\n\n```shell\n./generate_natvis.py [--version X.Y.Z] [--abi-tags TAGS]... [--all] [--list-tags] [--output FILE] [repository_root/]\n```\n\n`--version` and the repository root both default to values\nderived from this script's own location, so they only need to be given\nexplicitly when generating a Natvis file for a different checkout or a\nversion other than the one in `abi_macros.hpp`.\n\n| Option | Description |\n|-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `--list-tags` | Print every ABI tag (in namespace order) with the macro that enables it and the `NLOHMANN_JSON_ABI_TAG_*` identifier, then exit. |\n| `--abi-tags TAGS` | Add the namespaces of one configuration, given as a comma-separated list of ABI tags (`_diag,_dp,_vns`; the leading underscore is optional, and the order does not matter). Can be repeated for several configurations. Unknown tags are an error. |\n| `--all` | Generate the namespaces for every combination of ABI tags. The file size doubles with each tag (about 60 MB for 12 tags). Cannot be combined with `--abi-tags`. |\n| `--output FILE` | Write the Natvis file to `FILE` instead of `nlohmann_json.natvis` in the repository root. |\n\nEach configuration gets both the versioned (`json_abi_diag_dp_vns_v3_12_0`) and the unversioned (`json_abi_diag_dp_vns`,\nused with `NLOHMANN_JSON_NAMESPACE_NO_VERSION`) namespace. The default namespaces (up to two ABI tags) are always\nincluded, so a generated file can replace the checked-in one.\n\n### Generating a Natvis file for your configuration\n\n1. Check out the release tag of the library version you use (the ABI tags and the version are read from the checkout).\n2. Find the ABI tags of the macros you enable:\n\n ```shell\n make natvis NATVIS_ARGS=\"--list-tags\"\n ```\n\n3. Generate a Natvis file with them, for example for `JSON_DIAGNOSTICS`, `JSON_DIAGNOSTIC_POSITIONS`, and\n `JSON_VIEW_NO_SIMD`:\n\n ```shell\n make natvis NATVIS_ARGS=\"--abi-tags _diag,_dp,_vns --output my_nlohmann_json.natvis\"\n ```\n\n4. Use `my_nlohmann_json.natvis` instead of the shipped `nlohmann_json.natvis`, for example by adding it to your Visual\n Studio project.\n\nPassing `--output` keeps the checked-in `nlohmann_json.natvis` unchanged; without it, `make check-amalgamation` would\nreport the file as out of date.\n","tools/amalgamate/config_json_fwd.json":"{\n\t\"project\": \"JSON for Modern C++\",\n\t\"target\": \"single_include/nlohmann/json_fwd.hpp\",\n\t\"sources\": [\n\t\t\"include/nlohmann/json_fwd.hpp\"\n\t],\n\t\"include_paths\": [\"include\"]\n}\n","tools/gdb_pretty_printer/README.md":"# GDB Pretty Printer\n\nFile [nlohmann-json.py](nlohmann-json.py) contains a pretty printer for GDB for JSON values of this library. It was\noriginally published as [Gist](https://gist.github.com/ssbssa/60da5339c6e6036b2afce17de06050ea#file-nlohmann-json-py) by [Hannes Domani](https://github.com/ssbssa).\n\n## How to use\n\n- Add line\n \n ```\n source /path/to/nlohmann-json.py\n ```\n \n to `~/.gdbinit`. Note you must replace `/path/to` with whatever path you stored file `nlohmann-json.py`.\n- In GDB, debug as usual. When you want to pretty-print a JSON value `var`, type\n \n ```\n p -pretty on -array on -- var\n ```\n \n The result should look like\n \n ```\n $1 = std::map with 5 elements = {\n [\"Baptiste\"] = std::map with 1 element = {\n [\"first\"] = \"second\"\n },\n [\"Emmanuel\"] = std::vector of length 3, capacity 3 = {\n 3,\n \"25\",\n 0.5\n },\n [\"Jean\"] = 0.7,\n [\"Zorg\"] = std::map with 8 elements = {\n [\"array\"] = std::vector of length 3, capacity 3 = {\n 1,\n 0,\n 2\n },\n [\"awesome_str\"] = \"bleh\",\n [\"bool\"] = true,\n [\"flex\"] = 0.2,\n [\"float\"] = 5.22,\n [\"int\"] = 5,\n [\"nested\"] = std::map with 1 element = {\n [\"bar\"] = \"barz\"\n },\n [\"trap \"] = \"you fell\"\n },\n [\"empty\"] = nlohmann::detail::value_t::null\n }\n ```\n\nRequires Python 3.9+. Last tested with GDB 12.1.\nSee [#1952](https://github.com/nlohmann/json/issues/1952) for more information. Please post questions there.\n\n## Copyright\n\nMIT License\n\nCopyright (C) 2020 [Hannes Domani](https://github.com/ssbssa)\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n","tools/serve_header/README.md":"serve_header.py\n===============\n\nServes the `single_include/nlohmann/json.hpp` header file over HTTP(S).\n\nThe header file is automatically amalgamated on demand.\n\n![serve_header.py demo](demo.png)\n\n## Prerequisites\n\n1. Make sure these Python packages are installed.\n ```\n PyYAML\n watchdog\n ```\n (see `tools/serve_header/requirements.txt`)\n\n2. To serve the header over HTTPS (which is required by Compiler Explorer at this time), a certificate is needed.\n The recommended method for creating a locally trusted certificate is to use [`mkcert`](https://github.com/FiloSottile/mkcert).\n - Install the `mkcert` certificate authority into your trust store(s):\n ```\n $ mkcert -install\n ```\n - Create a certificate for `localhost`:\n ```\n $ mkcert localhost\n ```\n The command will create two files, `localhost.pem` and `localhost-key.pem`, in the current working directory. It is recommended to create them in the top level or project root directory.\n\n## Usage\n\n`serve_header.py` has a built-in default configuration that will serve the `single_include/nlohmann/json.hpp` header file relative to the top level or project root directory it is homed in.\nThe built-in configuration expects the certificate `localhost.pem` and the private key `localhost-key.pem`to be located in the top level or project root directory.\n\nTo start serving the `json.hpp` header file at `https://localhost:8443/json.hpp`, run this command from the top level or project root directory:\n```\n$ make serve_header\n```\n\nOpen [Compiler Explorer](https://godbolt.org/) and try it out:\n```cpp\n#include \nusing namespace nlohmann;\n\n#include \n\nint main() {\n // these macros are dynamically injected into the header file\n std::cout << JSON_BUILD_TIME << \" (\" << JSON_BUILD_COUNT << \")\\n\";\n\n return 0;\n}\n```\n\n> `serve_header.py` dynamically injects the macros `JSON_BUILD_COUNT` and `JSON_BUILD_TIME` into the served header file. By comparing build count or time output from the compiled program with the output from `serve_header.py`, one can be reasonably sure the compiled code uses the expected revision of the header file.\n\n## Configuration\n\n`serve_header.py` will try to read a configuration file `serve_header.yml` in the top level or project root directory, and will fall back on built-in defaults if the file cannot be read.\nAn annotated example configuration can be found in `tools/serve_header/serve_header.yml.example`.\n\nBy default, the server listens on `localhost` only, and only web pages from Compiler Explorer (`https://godbolt.org` and `https://compiler-explorer.com`) may read the header.\nSet `bind` to serve other machines as well; anyone who can reach the server can then trigger `make` runs in your working trees.\nSet `cors_origins` to allow other web pages.\n\n## Serving `json.hpp` from multiple project directory instances or working trees\n\n`serve_header.py` was designed with the goal of supporting multiple project roots or working trees at the same time.\nThe recommended directory structure is shown below but `serve_header.py` can work with other structures as well, including a nested hierarchy.\n```\njson/ ⮜ the parent or web server root directory\n├── develop/ ⮜ the main git checkout\n│ └── ...\n├── feature1/\n│ └── ... any number of additional\n├── feature2/ ⮜ working trees (e.g., created\n│ └── ... with git worktree)\n└── feature3/\n └── ...\n```\n\nTo serve the header of each working tree at `https://localhost:8443//json.hpp`, a configuration file is needed.\n1. Create the file `serve_header.yml` in the top level or project root directory of any working tree:\n ```yaml\n root: ..\n ```\n By shifting the web server root directory up one level, the `single_include/nlohmann/json.hpp` header files relative to each sibling directory or working tree will be served.\n\n2. Start `serve_header.py` by running this command from the same top level or project root directory the configuration file is located in:\n ```\n $ make serve_header\n ```\n\n`serve_header.py` will automatically detect the addition or removal of working trees anywhere within the configured web server root directory.\n","tools/amalgamate/README.md":"# amalgamate.py - Amalgamate C source and header files\n\nOrigin: https://github.com/edlund/amalgamate (formerly hosted at\nhttps://bitbucket.org/erikedlund/amalgamate, which no longer exists; see\n`CHANGES.md` for the upstream commit this copy is based on)\n\n`amalgamate.py` aims to make it easy to use SQLite-style C source and header\namalgamation in projects.\n\nFor more information, please refer to: http://sqlite.org/amalgamation.html\n\n## Here be dragons\n\n`amalgamate.py` is quite dumb, it only knows the bare minimum about C code\nrequired in order to be able to handle trivial include directives. It can\nproduce weird results for unexpected code.\n\nThings to be aware of:\n\n`amalgamate.py` will not handle complex include directives correctly:\n\n #define HEADER_PATH \"path/to/header.h\"\n #include HEADER_PATH\n\nIn the above example, `path/to/header.h` will not be included in the\namalgamation (HEADER_PATH is never expanded).\n\n`amalgamate.py` makes the assumption that each source and header file which\nis not empty will end in a new-line character, which is not immediately\npreceded by a backslash character (see 5.1.1.2p1.2 of ISO C99).\n\n`amalgamate.py` should be usable with C++ code, but raw string literals from\nC++11 will definitely cause problems:\n\n R\"delimiter(Terrible raw \\ data \" #include )delimiter\"\n R\"delimiter(Terrible raw \\ data \" escaping)delimiter\"\n\nIn the examples above, `amalgamate.py` will stop parsing the raw string literal\nwhen it encounters the first quotation mark, which will produce unexpected\nresults.\n\n## Installing amalgamate.py\n\nPython 3 is required.\n\nIn this repository, `amalgamate.py` is not installed separately; it is run in\nplace through `make amalgamate`, which calls it once for `json.hpp` and once\nfor `json_fwd.hpp` (see the root `Makefile`).\n\n## Using amalgamate.py\n\n amalgamate.py -c path/to/config.json -s path/to/source/dir \\\n [-p path/to/prologue.(c|h)] [--verbose=yes|no]\n\n * The `-c, --config` option should specify the path to a JSON config file which\n lists the source files, include paths and where to write the resulting\n amalgamation. `config_json.json` and `config_json_fwd.json` in this\n directory are the configs used for `json.hpp` and `json_fwd.hpp`; each\n sets `target`, `sources` and `include_paths`.\n\n The optional `external` list names include paths that are kept as `#include`\n directives instead of being inlined, e.g. `[\"nlohmann/json.hpp\"]` for a header\n that includes another amalgamated header. Only the first directive for each\n of these paths is kept; the repeated ones are commented out.\n\n * The `-s, --source` option should specify the path to the source directory.\n This is useful for supporting separate source and build directories.\n\n * The `-p, --prologue` option should specify the path to a file which will be\n added to the beginning of the amalgamation. It is optional.\n\n * The `-v, --verbose` option takes `yes` or `no` (for example\n `--verbose=yes`, as used by the Makefile). It is optional.\n\n",".cursorrules (python-flask-json-guide-cursorrules-prompt-file.mdc)":"---\ndescription: \"Cursor rules for Python Flask development with JSON guide.\"\nglobs: **/*\nalwaysApply: false\n---\nThis project is heavily reliant on our custom Drawscape Factorio python module.\n\nHere is code examples of how to use the module:\n\n```python\nfrom drawscape_factorio import create as createFactorio\nfrom drawscape_factorio import importFUE5\n\nwith open('/path/to/exported-entities.json', 'r') as file:\n json_data = json.load(file)\n data = importFUE5(json_data)\n result = createFactorio(data, {\n 'theme_name': 'default',\n 'color_scheme': 'main',\n 'show_layers': ['assets', 'belts', 'walls', 'rails', 'electrical', 'spaceship']\n })\n\nwith open(output_file_name, 'w') as f:\n f.write(result['svg_string'])\n"},"files":{"tools/amalgamate/config_json.json":"{\n\t\"project\": \"JSON for Modern C++\",\n\t\"target\": \"single_include/nlohmann/json.hpp\",\n\t\"sources\": [\n\t\t\"include/nlohmann/json.hpp\"\n\t],\n\t\"include_paths\": [\"include\"]\n}\n","tools/amalgamate/CHANGES.md":"The following changes have been made to the code with respect to :\n\n- Resolved inspection results from PyCharm:\n - replaced tabs with spaces\n - added encoding annotation\n - reindented file to remove trailing whitespaces\n - unused import `sys`\n - membership check\n - made function from `_is_within`\n - removed unused variable `actual_path`\n- Added the optional config key `external`: include paths listed there are kept as\n `#include` directives instead of being inlined (the first directive per path; the\n repeated ones are commented out).\n","tools/generate_natvis/README.md":"# generate_natvis.py\n\nGenerate the Natvis debugger visualization file for namespace combinations with up to two ABI tags.\n\nThe checked-in `nlohmann_json.natvis` covers the default namespace (no ABI tags), every single ABI tag, and every pair\nof ABI tags, with both versioned and unversioned namespace variants. Configurations that enable three or more ABI tags\nare not covered by this reduced file; use `--abi-tags` or `--all` (see below) to generate a file for them.\n\nThe ABI tag list and the library version are parsed from\n`include/nlohmann/detail/abi_macros.hpp`, so this script must be re-run (via\n`make natvis`) whenever an `NLOHMANN_JSON_ABI_TAG_*` macro is added to that\nfile or the library version is bumped — otherwise the committed\n`nlohmann_json.natvis` drifts from the header it visualizes, and\n`make check-amalgamation` fails.\n\n## Usage\n\n```shell\nmake natvis\n```\n\n`make natvis` sets up a virtual environment `tools/generate_natvis/venv` with the dependencies from\n`requirements.txt` (Jinja2) and runs the script with it. Alternatively, install the requirements yourself and run:\n\n```shell\n./generate_natvis.py [--version X.Y.Z] [--abi-tags TAGS]... [--all] [--list-tags] [--output FILE] [repository_root/]\n```\n\n`--version` and the repository root both default to values\nderived from this script's own location, so they only need to be given\nexplicitly when generating a Natvis file for a different checkout or a\nversion other than the one in `abi_macros.hpp`.\n\n| Option | Description |\n|-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `--list-tags` | Print every ABI tag (in namespace order) with the macro that enables it and the `NLOHMANN_JSON_ABI_TAG_*` identifier, then exit. |\n| `--abi-tags TAGS` | Add the namespaces of one configuration, given as a comma-separated list of ABI tags (`_diag,_dp,_vns`; the leading underscore is optional, and the order does not matter). Can be repeated for several configurations. Unknown tags are an error. |\n| `--all` | Generate the namespaces for every combination of ABI tags. The file size doubles with each tag (about 60 MB for 12 tags). Cannot be combined with `--abi-tags`. |\n| `--output FILE` | Write the Natvis file to `FILE` instead of `nlohmann_json.natvis` in the repository root. |\n\nEach configuration gets both the versioned (`json_abi_diag_dp_vns_v3_12_0`) and the unversioned (`json_abi_diag_dp_vns`,\nused with `NLOHMANN_JSON_NAMESPACE_NO_VERSION`) namespace. The default namespaces (up to two ABI tags) are always\nincluded, so a generated file can replace the checked-in one.\n\n### Generating a Natvis file for your configuration\n\n1. Check out the release tag of the library version you use (the ABI tags and the version are read from the checkout).\n2. Find the ABI tags of the macros you enable:\n\n ```shell\n make natvis NATVIS_ARGS=\"--list-tags\"\n ```\n\n3. Generate a Natvis file with them, for example for `JSON_DIAGNOSTICS`, `JSON_DIAGNOSTIC_POSITIONS`, and\n `JSON_VIEW_NO_SIMD`:\n\n ```shell\n make natvis NATVIS_ARGS=\"--abi-tags _diag,_dp,_vns --output my_nlohmann_json.natvis\"\n ```\n\n4. Use `my_nlohmann_json.natvis` instead of the shipped `nlohmann_json.natvis`, for example by adding it to your Visual\n Studio project.\n\nPassing `--output` keeps the checked-in `nlohmann_json.natvis` unchanged; without it, `make check-amalgamation` would\nreport the file as out of date.\n","tools/amalgamate/config_json_fwd.json":"{\n\t\"project\": \"JSON for Modern C++\",\n\t\"target\": \"single_include/nlohmann/json_fwd.hpp\",\n\t\"sources\": [\n\t\t\"include/nlohmann/json_fwd.hpp\"\n\t],\n\t\"include_paths\": [\"include\"]\n}\n","tools/gdb_pretty_printer/README.md":"# GDB Pretty Printer\n\nFile [nlohmann-json.py](nlohmann-json.py) contains a pretty printer for GDB for JSON values of this library. It was\noriginally published as [Gist](https://gist.github.com/ssbssa/60da5339c6e6036b2afce17de06050ea#file-nlohmann-json-py) by [Hannes Domani](https://github.com/ssbssa).\n\n## How to use\n\n- Add line\n \n ```\n source /path/to/nlohmann-json.py\n ```\n \n to `~/.gdbinit`. Note you must replace `/path/to` with whatever path you stored file `nlohmann-json.py`.\n- In GDB, debug as usual. When you want to pretty-print a JSON value `var`, type\n \n ```\n p -pretty on -array on -- var\n ```\n \n The result should look like\n \n ```\n $1 = std::map with 5 elements = {\n [\"Baptiste\"] = std::map with 1 element = {\n [\"first\"] = \"second\"\n },\n [\"Emmanuel\"] = std::vector of length 3, capacity 3 = {\n 3,\n \"25\",\n 0.5\n },\n [\"Jean\"] = 0.7,\n [\"Zorg\"] = std::map with 8 elements = {\n [\"array\"] = std::vector of length 3, capacity 3 = {\n 1,\n 0,\n 2\n },\n [\"awesome_str\"] = \"bleh\",\n [\"bool\"] = true,\n [\"flex\"] = 0.2,\n [\"float\"] = 5.22,\n [\"int\"] = 5,\n [\"nested\"] = std::map with 1 element = {\n [\"bar\"] = \"barz\"\n },\n [\"trap \"] = \"you fell\"\n },\n [\"empty\"] = nlohmann::detail::value_t::null\n }\n ```\n\nRequires Python 3.9+. Last tested with GDB 12.1.\nSee [#1952](https://github.com/nlohmann/json/issues/1952) for more information. Please post questions there.\n\n## Copyright\n\nMIT License\n\nCopyright (C) 2020 [Hannes Domani](https://github.com/ssbssa)\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n","tools/serve_header/README.md":"serve_header.py\n===============\n\nServes the `single_include/nlohmann/json.hpp` header file over HTTP(S).\n\nThe header file is automatically amalgamated on demand.\n\n![serve_header.py demo](demo.png)\n\n## Prerequisites\n\n1. Make sure these Python packages are installed.\n ```\n PyYAML\n watchdog\n ```\n (see `tools/serve_header/requirements.txt`)\n\n2. To serve the header over HTTPS (which is required by Compiler Explorer at this time), a certificate is needed.\n The recommended method for creating a locally trusted certificate is to use [`mkcert`](https://github.com/FiloSottile/mkcert).\n - Install the `mkcert` certificate authority into your trust store(s):\n ```\n $ mkcert -install\n ```\n - Create a certificate for `localhost`:\n ```\n $ mkcert localhost\n ```\n The command will create two files, `localhost.pem` and `localhost-key.pem`, in the current working directory. It is recommended to create them in the top level or project root directory.\n\n## Usage\n\n`serve_header.py` has a built-in default configuration that will serve the `single_include/nlohmann/json.hpp` header file relative to the top level or project root directory it is homed in.\nThe built-in configuration expects the certificate `localhost.pem` and the private key `localhost-key.pem`to be located in the top level or project root directory.\n\nTo start serving the `json.hpp` header file at `https://localhost:8443/json.hpp`, run this command from the top level or project root directory:\n```\n$ make serve_header\n```\n\nOpen [Compiler Explorer](https://godbolt.org/) and try it out:\n```cpp\n#include \nusing namespace nlohmann;\n\n#include \n\nint main() {\n // these macros are dynamically injected into the header file\n std::cout << JSON_BUILD_TIME << \" (\" << JSON_BUILD_COUNT << \")\\n\";\n\n return 0;\n}\n```\n\n> `serve_header.py` dynamically injects the macros `JSON_BUILD_COUNT` and `JSON_BUILD_TIME` into the served header file. By comparing build count or time output from the compiled program with the output from `serve_header.py`, one can be reasonably sure the compiled code uses the expected revision of the header file.\n\n## Configuration\n\n`serve_header.py` will try to read a configuration file `serve_header.yml` in the top level or project root directory, and will fall back on built-in defaults if the file cannot be read.\nAn annotated example configuration can be found in `tools/serve_header/serve_header.yml.example`.\n\nBy default, the server listens on `localhost` only, and only web pages from Compiler Explorer (`https://godbolt.org` and `https://compiler-explorer.com`) may read the header.\nSet `bind` to serve other machines as well; anyone who can reach the server can then trigger `make` runs in your working trees.\nSet `cors_origins` to allow other web pages.\n\n## Serving `json.hpp` from multiple project directory instances or working trees\n\n`serve_header.py` was designed with the goal of supporting multiple project roots or working trees at the same time.\nThe recommended directory structure is shown below but `serve_header.py` can work with other structures as well, including a nested hierarchy.\n```\njson/ ⮜ the parent or web server root directory\n├── develop/ ⮜ the main git checkout\n│ └── ...\n├── feature1/\n│ └── ... any number of additional\n├── feature2/ ⮜ working trees (e.g., created\n│ └── ... with git worktree)\n└── feature3/\n └── ...\n```\n\nTo serve the header of each working tree at `https://localhost:8443//json.hpp`, a configuration file is needed.\n1. Create the file `serve_header.yml` in the top level or project root directory of any working tree:\n ```yaml\n root: ..\n ```\n By shifting the web server root directory up one level, the `single_include/nlohmann/json.hpp` header files relative to each sibling directory or working tree will be served.\n\n2. Start `serve_header.py` by running this command from the same top level or project root directory the configuration file is located in:\n ```\n $ make serve_header\n ```\n\n`serve_header.py` will automatically detect the addition or removal of working trees anywhere within the configured web server root directory.\n","tools/amalgamate/README.md":"# amalgamate.py - Amalgamate C source and header files\n\nOrigin: https://github.com/edlund/amalgamate (formerly hosted at\nhttps://bitbucket.org/erikedlund/amalgamate, which no longer exists; see\n`CHANGES.md` for the upstream commit this copy is based on)\n\n`amalgamate.py` aims to make it easy to use SQLite-style C source and header\namalgamation in projects.\n\nFor more information, please refer to: http://sqlite.org/amalgamation.html\n\n## Here be dragons\n\n`amalgamate.py` is quite dumb, it only knows the bare minimum about C code\nrequired in order to be able to handle trivial include directives. It can\nproduce weird results for unexpected code.\n\nThings to be aware of:\n\n`amalgamate.py` will not handle complex include directives correctly:\n\n #define HEADER_PATH \"path/to/header.h\"\n #include HEADER_PATH\n\nIn the above example, `path/to/header.h` will not be included in the\namalgamation (HEADER_PATH is never expanded).\n\n`amalgamate.py` makes the assumption that each source and header file which\nis not empty will end in a new-line character, which is not immediately\npreceded by a backslash character (see 5.1.1.2p1.2 of ISO C99).\n\n`amalgamate.py` should be usable with C++ code, but raw string literals from\nC++11 will definitely cause problems:\n\n R\"delimiter(Terrible raw \\ data \" #include )delimiter\"\n R\"delimiter(Terrible raw \\ data \" escaping)delimiter\"\n\nIn the examples above, `amalgamate.py` will stop parsing the raw string literal\nwhen it encounters the first quotation mark, which will produce unexpected\nresults.\n\n## Installing amalgamate.py\n\nPython 3 is required.\n\nIn this repository, `amalgamate.py` is not installed separately; it is run in\nplace through `make amalgamate`, which calls it once for `json.hpp` and once\nfor `json_fwd.hpp` (see the root `Makefile`).\n\n## Using amalgamate.py\n\n amalgamate.py -c path/to/config.json -s path/to/source/dir \\\n [-p path/to/prologue.(c|h)] [--verbose=yes|no]\n\n * The `-c, --config` option should specify the path to a JSON config file which\n lists the source files, include paths and where to write the resulting\n amalgamation. `config_json.json` and `config_json_fwd.json` in this\n directory are the configs used for `json.hpp` and `json_fwd.hpp`; each\n sets `target`, `sources` and `include_paths`.\n\n The optional `external` list names include paths that are kept as `#include`\n directives instead of being inlined, e.g. `[\"nlohmann/json.hpp\"]` for a header\n that includes another amalgamated header. Only the first directive for each\n of these paths is kept; the repeated ones are commented out.\n\n * The `-s, --source` option should specify the path to the source directory.\n This is useful for supporting separate source and build directories.\n\n * The `-p, --prologue` option should specify the path to a file which will be\n added to the beginning of the amalgamation. It is optional.\n\n * The `-v, --verbose` option takes `yes` or `no` (for example\n `--verbose=yes`, as used by the Makefile). It is optional.\n\n",".cursorrules (python-flask-json-guide-cursorrules-prompt-file.mdc)":"---\ndescription: \"Cursor rules for Python Flask development with JSON guide.\"\nglobs: **/*\nalwaysApply: false\n---\nThis project is heavily reliant on our custom Drawscape Factorio python module.\n\nHere is code examples of how to use the module:\n\n```python\nfrom drawscape_factorio import create as createFactorio\nfrom drawscape_factorio import importFUE5\n\nwith open('/path/to/exported-entities.json', 'r') as file:\n json_data = json.load(file)\n data = importFUE5(json_data)\n result = createFactorio(data, {\n 'theme_name': 'default',\n 'color_scheme': 'main',\n 'show_layers': ['assets', 'belts', 'walls', 'rails', 'electrical', 'spaceship']\n })\n\nwith open(output_file_name, 'w') as f:\n f.write(result['svg_string'])\n"},"items":[{"name":"CHANGES.md","path":"tools/amalgamate/CHANGES.md","rawUrl":"https://raw.githubusercontent.com/nlohmann/json/HEAD/tools/amalgamate/CHANGES.md","title":"Amalgamate Skill","category":"anthropic-skill","format":"markdown","content":"The following changes have been made to the code with respect to :\n\n- Resolved inspection results from PyCharm:\n - replaced tabs with spaces\n - added encoding annotation\n - reindented file to remove trailing whitespaces\n - unused import `sys`\n - membership check\n - made function from `_is_within`\n - removed unused variable `actual_path`\n- Added the optional config key `external`: include paths listed there are kept as\n `#include` directives instead of being inlined (the first directive per path; the\n repeated ones are commented out).\n","isInternal":false,"tokens":157,"sizeBytes":635},{"name":"config_json_fwd.json","path":"tools/amalgamate/config_json_fwd.json","rawUrl":"https://raw.githubusercontent.com/nlohmann/json/HEAD/tools/amalgamate/config_json_fwd.json","title":"Amalgamate Skill","category":"anthropic-skill","format":"json","content":"{\n\t\"project\": \"JSON for Modern C++\",\n\t\"target\": \"single_include/nlohmann/json_fwd.hpp\",\n\t\"sources\": [\n\t\t\"include/nlohmann/json_fwd.hpp\"\n\t],\n\t\"include_paths\": [\"include\"]\n}\n","frontmatter":{"project":"JSON for Modern C++","target":"single_include/nlohmann/json_fwd.hpp","sources":["include/nlohmann/json_fwd.hpp"],"include_paths":["include"]},"isInternal":false,"tokens":53,"sizeBytes":172},{"name":"config_json.json","path":"tools/amalgamate/config_json.json","rawUrl":"https://raw.githubusercontent.com/nlohmann/json/HEAD/tools/amalgamate/config_json.json","title":"Amalgamate Skill","category":"anthropic-skill","format":"json","content":"{\n\t\"project\": \"JSON for Modern C++\",\n\t\"target\": \"single_include/nlohmann/json.hpp\",\n\t\"sources\": [\n\t\t\"include/nlohmann/json.hpp\"\n\t],\n\t\"include_paths\": [\"include\"]\n}\n","frontmatter":{"project":"JSON for Modern C++","target":"single_include/nlohmann/json.hpp","sources":["include/nlohmann/json.hpp"],"include_paths":["include"]},"isInternal":false,"tokens":51,"sizeBytes":164},{"name":"README.md","path":"tools/amalgamate/README.md","rawUrl":"https://raw.githubusercontent.com/nlohmann/json/HEAD/tools/amalgamate/README.md","title":"amalgamate Documentation","category":"plugin-manifest","format":"markdown","content":"# amalgamate.py - Amalgamate C source and header files\n\nOrigin: https://github.com/edlund/amalgamate (formerly hosted at\nhttps://bitbucket.org/erikedlund/amalgamate, which no longer exists; see\n`CHANGES.md` for the upstream commit this copy is based on)\n\n`amalgamate.py` aims to make it easy to use SQLite-style C source and header\namalgamation in projects.\n\nFor more information, please refer to: http://sqlite.org/amalgamation.html\n\n## Here be dragons\n\n`amalgamate.py` is quite dumb, it only knows the bare minimum about C code\nrequired in order to be able to handle trivial include directives. It can\nproduce weird results for unexpected code.\n\nThings to be aware of:\n\n`amalgamate.py` will not handle complex include directives correctly:\n\n #define HEADER_PATH \"path/to/header.h\"\n #include HEADER_PATH\n\nIn the above example, `path/to/header.h` will not be included in the\namalgamation (HEADER_PATH is never expanded).\n\n`amalgamate.py` makes the assumption that each source and header file which\nis not empty will end in a new-line character, which is not immediately\npreceded by a backslash character (see 5.1.1.2p1.2 of ISO C99).\n\n`amalgamate.py` should be usable with C++ code, but raw string literals from\nC++11 will definitely cause problems:\n\n R\"delimiter(Terrible raw \\ data \" #include )delimiter\"\n R\"delimiter(Terrible raw \\ data \" escaping)delimiter\"\n\nIn the examples above, `amalgamate.py` will stop parsing the raw string literal\nwhen it encounters the first quotation mark, which will produce unexpected\nresults.\n\n## Installing amalgamate.py\n\nPython 3 is required.\n\nIn this repository, `amalgamate.py` is not installed separately; it is run in\nplace through `make amalgamate`, which calls it once for `json.hpp` and once\nfor `json_fwd.hpp` (see the root `Makefile`).\n\n## Using amalgamate.py\n\n amalgamate.py -c path/to/config.json -s path/to/source/dir \\\n [-p path/to/prologue.(c|h)] [--verbose=yes|no]\n\n * The `-c, --config` option should specify the path to a JSON config file which\n lists the source files, include paths and where to write the resulting\n amalgamation. `config_json.json` and `config_json_fwd.json` in this\n directory are the configs used for `json.hpp` and `json_fwd.hpp`; each\n sets `target`, `sources` and `include_paths`.\n\n The optional `external` list names include paths that are kept as `#include`\n directives instead of being inlined, e.g. `[\"nlohmann/json.hpp\"]` for a header\n that includes another amalgamated header. Only the first directive for each\n of these paths is kept; the repeated ones are commented out.\n\n * The `-s, --source` option should specify the path to the source directory.\n This is useful for supporting separate source and build directories.\n\n * The `-p, --prologue` option should specify the path to a file which will be\n added to the beginning of the amalgamation. It is optional.\n\n * The `-v, --verbose` option takes `yes` or `no` (for example\n `--verbose=yes`, as used by the Makefile). It is optional.\n\n","isInternal":false,"tokens":745,"sizeBytes":3055},{"name":"README.md","path":"tools/gdb_pretty_printer/README.md","rawUrl":"https://raw.githubusercontent.com/nlohmann/json/HEAD/tools/gdb_pretty_printer/README.md","title":"gdb_pretty_printer Documentation","category":"plugin-manifest","format":"markdown","content":"# GDB Pretty Printer\n\nFile [nlohmann-json.py](nlohmann-json.py) contains a pretty printer for GDB for JSON values of this library. It was\noriginally published as [Gist](https://gist.github.com/ssbssa/60da5339c6e6036b2afce17de06050ea#file-nlohmann-json-py) by [Hannes Domani](https://github.com/ssbssa).\n\n## How to use\n\n- Add line\n \n ```\n source /path/to/nlohmann-json.py\n ```\n \n to `~/.gdbinit`. Note you must replace `/path/to` with whatever path you stored file `nlohmann-json.py`.\n- In GDB, debug as usual. When you want to pretty-print a JSON value `var`, type\n \n ```\n p -pretty on -array on -- var\n ```\n \n The result should look like\n \n ```\n $1 = std::map with 5 elements = {\n [\"Baptiste\"] = std::map with 1 element = {\n [\"first\"] = \"second\"\n },\n [\"Emmanuel\"] = std::vector of length 3, capacity 3 = {\n 3,\n \"25\",\n 0.5\n },\n [\"Jean\"] = 0.7,\n [\"Zorg\"] = std::map with 8 elements = {\n [\"array\"] = std::vector of length 3, capacity 3 = {\n 1,\n 0,\n 2\n },\n [\"awesome_str\"] = \"bleh\",\n [\"bool\"] = true,\n [\"flex\"] = 0.2,\n [\"float\"] = 5.22,\n [\"int\"] = 5,\n [\"nested\"] = std::map with 1 element = {\n [\"bar\"] = \"barz\"\n },\n [\"trap \"] = \"you fell\"\n },\n [\"empty\"] = nlohmann::detail::value_t::null\n }\n ```\n\nRequires Python 3.9+. Last tested with GDB 12.1.\nSee [#1952](https://github.com/nlohmann/json/issues/1952) for more information. Please post questions there.\n\n## Copyright\n\nMIT License\n\nCopyright (C) 2020 [Hannes Domani](https://github.com/ssbssa)\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n","isInternal":false,"tokens":709,"sizeBytes":2759},{"name":"README.md","path":"tools/generate_natvis/README.md","rawUrl":"https://raw.githubusercontent.com/nlohmann/json/HEAD/tools/generate_natvis/README.md","title":"generate_natvis Documentation","category":"plugin-manifest","format":"markdown","content":"# generate_natvis.py\n\nGenerate the Natvis debugger visualization file for namespace combinations with up to two ABI tags.\n\nThe checked-in `nlohmann_json.natvis` covers the default namespace (no ABI tags), every single ABI tag, and every pair\nof ABI tags, with both versioned and unversioned namespace variants. Configurations that enable three or more ABI tags\nare not covered by this reduced file; use `--abi-tags` or `--all` (see below) to generate a file for them.\n\nThe ABI tag list and the library version are parsed from\n`include/nlohmann/detail/abi_macros.hpp`, so this script must be re-run (via\n`make natvis`) whenever an `NLOHMANN_JSON_ABI_TAG_*` macro is added to that\nfile or the library version is bumped — otherwise the committed\n`nlohmann_json.natvis` drifts from the header it visualizes, and\n`make check-amalgamation` fails.\n\n## Usage\n\n```shell\nmake natvis\n```\n\n`make natvis` sets up a virtual environment `tools/generate_natvis/venv` with the dependencies from\n`requirements.txt` (Jinja2) and runs the script with it. Alternatively, install the requirements yourself and run:\n\n```shell\n./generate_natvis.py [--version X.Y.Z] [--abi-tags TAGS]... [--all] [--list-tags] [--output FILE] [repository_root/]\n```\n\n`--version` and the repository root both default to values\nderived from this script's own location, so they only need to be given\nexplicitly when generating a Natvis file for a different checkout or a\nversion other than the one in `abi_macros.hpp`.\n\n| Option | Description |\n|-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `--list-tags` | Print every ABI tag (in namespace order) with the macro that enables it and the `NLOHMANN_JSON_ABI_TAG_*` identifier, then exit. |\n| `--abi-tags TAGS` | Add the namespaces of one configuration, given as a comma-separated list of ABI tags (`_diag,_dp,_vns`; the leading underscore is optional, and the order does not matter). Can be repeated for several configurations. Unknown tags are an error. |\n| `--all` | Generate the namespaces for every combination of ABI tags. The file size doubles with each tag (about 60 MB for 12 tags). Cannot be combined with `--abi-tags`. |\n| `--output FILE` | Write the Natvis file to `FILE` instead of `nlohmann_json.natvis` in the repository root. |\n\nEach configuration gets both the versioned (`json_abi_diag_dp_vns_v3_12_0`) and the unversioned (`json_abi_diag_dp_vns`,\nused with `NLOHMANN_JSON_NAMESPACE_NO_VERSION`) namespace. The default namespaces (up to two ABI tags) are always\nincluded, so a generated file can replace the checked-in one.\n\n### Generating a Natvis file for your configuration\n\n1. Check out the release tag of the library version you use (the ABI tags and the version are read from the checkout).\n2. Find the ABI tags of the macros you enable:\n\n ```shell\n make natvis NATVIS_ARGS=\"--list-tags\"\n ```\n\n3. Generate a Natvis file with them, for example for `JSON_DIAGNOSTICS`, `JSON_DIAGNOSTIC_POSITIONS`, and\n `JSON_VIEW_NO_SIMD`:\n\n ```shell\n make natvis NATVIS_ARGS=\"--abi-tags _diag,_dp,_vns --output my_nlohmann_json.natvis\"\n ```\n\n4. Use `my_nlohmann_json.natvis` instead of the shipped `nlohmann_json.natvis`, for example by adding it to your Visual\n Studio project.\n\nPassing `--output` keeps the checked-in `nlohmann_json.natvis` unchanged; without it, `make check-amalgamation` would\nreport the file as out of date.\n","isInternal":false,"tokens":862,"sizeBytes":4192},{"name":"README.md","path":"tools/serve_header/README.md","rawUrl":"https://raw.githubusercontent.com/nlohmann/json/HEAD/tools/serve_header/README.md","title":"serve_header Documentation","category":"plugin-manifest","format":"markdown","content":"serve_header.py\n===============\n\nServes the `single_include/nlohmann/json.hpp` header file over HTTP(S).\n\nThe header file is automatically amalgamated on demand.\n\n![serve_header.py demo](demo.png)\n\n## Prerequisites\n\n1. Make sure these Python packages are installed.\n ```\n PyYAML\n watchdog\n ```\n (see `tools/serve_header/requirements.txt`)\n\n2. To serve the header over HTTPS (which is required by Compiler Explorer at this time), a certificate is needed.\n The recommended method for creating a locally trusted certificate is to use [`mkcert`](https://github.com/FiloSottile/mkcert).\n - Install the `mkcert` certificate authority into your trust store(s):\n ```\n $ mkcert -install\n ```\n - Create a certificate for `localhost`:\n ```\n $ mkcert localhost\n ```\n The command will create two files, `localhost.pem` and `localhost-key.pem`, in the current working directory. It is recommended to create them in the top level or project root directory.\n\n## Usage\n\n`serve_header.py` has a built-in default configuration that will serve the `single_include/nlohmann/json.hpp` header file relative to the top level or project root directory it is homed in.\nThe built-in configuration expects the certificate `localhost.pem` and the private key `localhost-key.pem`to be located in the top level or project root directory.\n\nTo start serving the `json.hpp` header file at `https://localhost:8443/json.hpp`, run this command from the top level or project root directory:\n```\n$ make serve_header\n```\n\nOpen [Compiler Explorer](https://godbolt.org/) and try it out:\n```cpp\n#include \nusing namespace nlohmann;\n\n#include \n\nint main() {\n // these macros are dynamically injected into the header file\n std::cout << JSON_BUILD_TIME << \" (\" << JSON_BUILD_COUNT << \")\\n\";\n\n return 0;\n}\n```\n\n> `serve_header.py` dynamically injects the macros `JSON_BUILD_COUNT` and `JSON_BUILD_TIME` into the served header file. By comparing build count or time output from the compiled program with the output from `serve_header.py`, one can be reasonably sure the compiled code uses the expected revision of the header file.\n\n## Configuration\n\n`serve_header.py` will try to read a configuration file `serve_header.yml` in the top level or project root directory, and will fall back on built-in defaults if the file cannot be read.\nAn annotated example configuration can be found in `tools/serve_header/serve_header.yml.example`.\n\nBy default, the server listens on `localhost` only, and only web pages from Compiler Explorer (`https://godbolt.org` and `https://compiler-explorer.com`) may read the header.\nSet `bind` to serve other machines as well; anyone who can reach the server can then trigger `make` runs in your working trees.\nSet `cors_origins` to allow other web pages.\n\n## Serving `json.hpp` from multiple project directory instances or working trees\n\n`serve_header.py` was designed with the goal of supporting multiple project roots or working trees at the same time.\nThe recommended directory structure is shown below but `serve_header.py` can work with other structures as well, including a nested hierarchy.\n```\njson/ ⮜ the parent or web server root directory\n├── develop/ ⮜ the main git checkout\n│ └── ...\n├── feature1/\n│ └── ... any number of additional\n├── feature2/ ⮜ working trees (e.g., created\n│ └── ... with git worktree)\n└── feature3/\n └── ...\n```\n\nTo serve the header of each working tree at `https://localhost:8443//json.hpp`, a configuration file is needed.\n1. Create the file `serve_header.yml` in the top level or project root directory of any working tree:\n ```yaml\n root: ..\n ```\n By shifting the web server root directory up one level, the `single_include/nlohmann/json.hpp` header files relative to each sibling directory or working tree will be served.\n\n2. Start `serve_header.py` by running this command from the same top level or project root directory the configuration file is located in:\n ```\n $ make serve_header\n ```\n\n`serve_header.py` will automatically detect the addition or removal of working trees anywhere within the configured web server root directory.\n","isInternal":false,"tokens":958,"sizeBytes":4279},{"name":".cursorrules","path":".cursorrules (python-flask-json-guide-cursorrules-prompt-file.mdc)","rawUrl":"https://raw.githubusercontent.com/PatrickJS/awesome-cursorrules/main/rules/python-flask-json-guide-cursorrules-prompt-file.mdc","title":"Awesome Cursorrules: python flask json guide","category":"cursor-rule","format":"markdown","content":"---\ndescription: \"Cursor rules for Python Flask development with JSON guide.\"\nglobs: **/*\nalwaysApply: false\n---\nThis project is heavily reliant on our custom Drawscape Factorio python module.\n\nHere is code examples of how to use the module:\n\n```python\nfrom drawscape_factorio import create as createFactorio\nfrom drawscape_factorio import importFUE5\n\nwith open('/path/to/exported-entities.json', 'r') as file:\n json_data = json.load(file)\n data = importFUE5(json_data)\n result = createFactorio(data, {\n 'theme_name': 'default',\n 'color_scheme': 'main',\n 'show_layers': ['assets', 'belts', 'walls', 'rails', 'electrical', 'spaceship']\n })\n\nwith open(output_file_name, 'w') as f:\n f.write(result['svg_string'])\n","tokens":185,"sizeBytes":746}],"systemPromptSnippet":"\n\nThe following changes have been made to the code with respect to :\n\n- Resolved inspection results from PyCharm:\n - replaced tabs with spaces\n - added encoding annotation\n - reindented file to remove trailing whitespaces\n - unused import `sys`\n - membership check\n - made function from `_is_within`\n - removed unused variable `actual_path`\n- Added the optional config key `external`: include paths listed there are kept as\n `#include` directives instead of being inlined (the first directive per path; the\n repeated ones are commented out).\n\n\n{\n\t\"project\": \"JSON for Modern C++\",\n\t\"target\": \"single_include/nlohmann/json_fwd.hpp\",\n\t\"sources\": [\n\t\t\"include/nlohmann/json_fwd.hpp\"\n\t],\n\t\"include_paths\": [\"include\"]\n}\n\n\n{\n\t\"project\": \"JSON for Modern C++\",\n\t\"target\": \"single_include/nlohmann/json.hpp\",\n\t\"sources\": [\n\t\t\"include/nlohmann/json.hpp\"\n\t],\n\t\"include_paths\": [\"include\"]\n}\n\n\n# amalgamate.py - Amalgamate C source and header files\n\nOrigin: https://github.com/edlund/amalgamate (formerly hosted at\nhttps://bitbucket.org/erikedlund/amalgamate, which no longer exists; see\n`CHANGES.md` for the upstream commit this copy is based on)\n\n`amalgamate.py` aims to make it easy to use SQLite-style C source and header\namalgamation in projects.\n\nFor more information, please refer to: http://sqlite.org/amalgamation.html\n\n## Here be dragons\n\n`amalgamate.py` is quite dumb, it only knows the bare minimum about C code\nrequired in order to be able to handle trivial include directives. It can\nproduce weird results for unexpected code.\n\nThings to be aware of:\n\n`amalgamate.py` will not handle complex include directives correctly:\n\n #define HEADER_PATH \"path/to/header.h\"\n #include HEADER_PATH\n\nIn the above example, `path/to/header.h` will not be included in the\namalgamation (HEADER_PATH is never expanded).\n\n`amalgamate.py` makes the assumption that each source and header file which\nis not empty will end in a new-line character, which is not immediately\npreceded by a backslash character (see 5.1.1.2p1.2 of ISO C99).\n\n`amalgamate.py` should be usable with C++ code, but raw string literals from\nC++11 will definitely cause problems:\n\n R\"delimiter(Terrible raw \\ data \" #include )delimiter\"\n R\"delimiter(Terrible raw \\ data \" escaping)delimiter\"\n\nIn the examples above, `amalgamate.py` will stop parsing the raw string literal\nwhen it encounters the first quotation mark, which will produce unexpected\nresults.\n\n## Installing amalgamate.py\n\nPython 3 is required.\n\nIn this repository, `amalgamate.py` is not installed separately; it is run in\nplace through `make amalgamate`, which calls it once for `json.hpp` and once\nfor `json_fwd.hpp` (see the root `Makefile`).\n\n## Using amalgamate.py\n\n amalgamate.py -c path/to/config.json -s path/to/source/dir \\\n [-p path/to/prologue.(c|h)] [--verbose=yes|no]\n\n * The `-c, --config` option should specify the path to a JSON config file which\n lists the source files, include paths and where to write the resulting\n amalgamation. `config_json.json` and `config_json_fwd.json` in this\n directory are the configs used for `json.hpp` and `json_fwd.hpp`; each\n sets `target`, `sources` and `include_paths`.\n\n The optional `external` list names include paths that are kept as `#include`\n directives instead of being inlined, e.g. `[\"nlohmann/json.hpp\"]` for a header\n that includes another amalgamated header. Only the first directive for each\n of these paths is kept; the repeated ones are commented out.\n\n * The `-s, --source` option should specify the path to the source directory.\n This is useful for supporting separate source and build directories.\n\n * The `-p, --prologue` option should specify the path to a file which will be\n added to the beginning of the amalgamation. It is optional.\n\n * The `-v, --verbose` option takes `yes` or `no` (for example\n `--verbose=yes`, as used by the Makefile). It is optional.\n\n\n# GDB Pretty Printer\n\nFile [nlohmann-json.py](nlohmann-json.py) contains a pretty printer for GDB for JSON values of this library. It was\noriginally published as [Gist](https://gist.github.com/ssbssa/60da5339c6e6036b2afce17de06050ea#file-nlohmann-json-py) by [Hannes Domani](https://github.com/ssbssa).\n\n## How to use\n\n- Add line\n \n ```\n source /path/to/nlohmann-json.py\n ```\n \n to `~/.gdbinit`. Note you must replace `/path/to` with whatever path you stored file `nlohmann-json.py`.\n- In GDB, debug as usual. When you want to pretty-print a JSON value `var`, type\n \n ```\n p -pretty on -array on -- var\n ```\n \n The result should look like\n \n ```\n $1 = std::map with 5 elements = {\n [\"Baptiste\"] = std::map with 1 element = {\n [\"first\"] = \"second\"\n },\n [\"Emmanuel\"] = std::vector of length 3, capacity 3 = {\n 3,\n \"25\",\n 0.5\n },\n [\"Jean\"] = 0.7,\n [\"Zorg\"] = std::map with 8 elements = {\n [\"array\"] = std::vector of length 3, capacity 3 = {\n 1,\n 0,\n 2\n },\n [\"awesome_str\"] = \"bleh\",\n [\"bool\"] = true,\n [\"flex\"] = 0.2,\n [\"float\"] = 5.22,\n [\"int\"] = 5,\n [\"nested\"] = std::map with 1 element = {\n [\"bar\"] = \"barz\"\n },\n [\"trap \"] = \"you fell\"\n },\n [\"empty\"] = nlohmann::detail::value_t::null\n }\n ```\n\nRequires Python 3.9+. Last tested with GDB 12.1.\nSee [#1952](https://github.com/nlohmann/json/issues/1952) for more information. Please post questions there.\n\n## Copyright\n\nMIT License\n\nCopyright (C) 2020 [Hannes Domani](https://github.com/ssbssa)\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n\n\n# generate_natvis.py\n\nGenerate the Natvis debugger visualization file for namespace combinations with up to two ABI tags.\n\nThe checked-in `nlohmann_json.natvis` covers the default namespace (no ABI tags), every single ABI tag, and every pair\nof ABI tags, with both versioned and unversioned namespace variants. Configurations that enable three or more ABI tags\nare not covered by this reduced file; use `--abi-tags` or `--all` (see below) to generate a file for them.\n\nThe ABI tag list and the library version are parsed from\n`include/nlohmann/detail/abi_macros.hpp`, so this script must be re-run (via\n`make natvis`) whenever an `NLOHMANN_JSON_ABI_TAG_*` macro is added to that\nfile or the library version is bumped — otherwise the committed\n`nlohmann_json.natvis` drifts from the header it visualizes, and\n`make check-amalgamation` fails.\n\n## Usage\n\n```shell\nmake natvis\n```\n\n`make natvis` sets up a virtual environment `tools/generate_natvis/venv` with the dependencies from\n`requirements.txt` (Jinja2) and runs the script with it. Alternatively, install the requirements yourself and run:\n\n```shell\n./generate_natvis.py [--version X.Y.Z] [--abi-tags TAGS]... [--all] [--list-tags] [--output FILE] [repository_root/]\n```\n\n`--version` and the repository root both default to values\nderived from this script's own location, so they only need to be given\nexplicitly when generating a Natvis file for a different checkout or a\nversion other than the one in `abi_macros.hpp`.\n\n| Option | Description |\n|-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `--list-tags` | Print every ABI tag (in namespace order) with the macro that enables it and the `NLOHMANN_JSON_ABI_TAG_*` identifier, then exit. |\n| `--abi-tags TAGS` | Add the namespaces of one configuration, given as a comma-separated list of ABI tags (`_diag,_dp,_vns`; the leading underscore is optional, and the order does not matter). Can be repeated for several configurations. Unknown tags are an error. |\n| `--all` | Generate the namespaces for every combination of ABI tags. The file size doubles with each tag (about 60 MB for 12 tags). Cannot be combined with `--abi-tags`. |\n| `--output FILE` | Write the Natvis file to `FILE` instead of `nlohmann_json.natvis` in the repository root. |\n\nEach configuration gets both the versioned (`json_abi_diag_dp_vns_v3_12_0`) and the unversioned (`json_abi_diag_dp_vns`,\nused with `NLOHMANN_JSON_NAMESPACE_NO_VERSION`) namespace. The default namespaces (up to two ABI tags) are always\nincluded, so a generated file can replace the checked-in one.\n\n### Generating a Natvis file for your configuration\n\n1. Check out the release tag of the library version you use (the ABI tags and the version are read from the checkout).\n2. Find the ABI tags of the macros you enable:\n\n ```shell\n make natvis NATVIS_ARGS=\"--list-tags\"\n ```\n\n3. Generate a Natvis file with them, for example for `JSON_DIAGNOSTICS`, `JSON_DIAGNOSTIC_POSITIONS`, and\n `JSON_VIEW_NO_SIMD`:\n\n ```shell\n make natvis NATVIS_ARGS=\"--abi-tags _diag,_dp,_vns --output my_nlohmann_json.natvis\"\n ```\n\n4. Use `my_nlohmann_json.natvis` instead of the shipped `nlohmann_json.natvis`, for example by adding it to your Visual\n Studio project.\n\nPassing `--output` keeps the checked-in `nlohmann_json.natvis` unchanged; without it, `make check-amalgamation` would\nreport the file as out of date.\n\n\nserve_header.py\n===============\n\nServes the `single_include/nlohmann/json.hpp` header file over HTTP(S).\n\nThe header file is automatically amalgamated on demand.\n\n![serve_header.py demo](demo.png)\n\n## Prerequisites\n\n1. Make sure these Python packages are installed.\n ```\n PyYAML\n watchdog\n ```\n (see `tools/serve_header/requirements.txt`)\n\n2. To serve the header over HTTPS (which is required by Compiler Explorer at this time), a certificate is needed.\n The recommended method for creating a locally trusted certificate is to use [`mkcert`](https://github.com/FiloSottile/mkcert).\n - Install the `mkcert` certificate authority into your trust store(s):\n ```\n $ mkcert -install\n ```\n - Create a certificate for `localhost`:\n ```\n $ mkcert localhost\n ```\n The command will create two files, `localhost.pem` and `localhost-key.pem`, in the current working directory. It is recommended to create them in the top level or project root directory.\n\n## Usage\n\n`serve_header.py` has a built-in default configuration that will serve the `single_include/nlohmann/json.hpp` header file relative to the top level or project root directory it is homed in.\nThe built-in configuration expects the certificate `localhost.pem` and the private key `localhost-key.pem`to be located in the top level or project root directory.\n\nTo start serving the `json.hpp` header file at `https://localhost:8443/json.hpp`, run this command from the top level or project root directory:\n```\n$ make serve_header\n```\n\nOpen [Compiler Explorer](https://godbolt.org/) and try it out:\n```cpp\n#include \nusing namespace nlohmann;\n\n#include \n\nint main() {\n // these macros are dynamically injected into the header file\n std::cout << JSON_BUILD_TIME << \" (\" << JSON_BUILD_COUNT << \")\\n\";\n\n return 0;\n}\n```\n\n> `serve_header.py` dynamically injects the macros `JSON_BUILD_COUNT` and `JSON_BUILD_TIME` into the served header file. By comparing build count or time output from the compiled program with the output from `serve_header.py`, one can be reasonably sure the compiled code uses the expected revision of the header file.\n\n## Configuration\n\n`serve_header.py` will try to read a configuration file `serve_header.yml` in the top level or project root directory, and will fall back on built-in defaults if the file cannot be read.\nAn annotated example configuration can be found in `tools/serve_header/serve_header.yml.example`.\n\nBy default, the server listens on `localhost` only, and only web pages from Compiler Explorer (`https://godbolt.org` and `https://compiler-explorer.com`) may read the header.\nSet `bind` to serve other machines as well; anyone who can reach the server can then trigger `make` runs in your working trees.\nSet `cors_origins` to allow other web pages.\n\n## Serving `json.hpp` from multiple project directory instances or working trees\n\n`serve_header.py` was designed with the goal of supporting multiple project roots or working trees at the same time.\nThe recommended directory structure is shown below but `serve_header.py` can work with other structures as well, including a nested hierarchy.\n```\njson/ ⮜ the parent or web server root directory\n├── develop/ ⮜ the main git checkout\n│ └── ...\n├── feature1/\n│ └── ... any number of additional\n├── feature2/ ⮜ working trees (e.g., created\n│ └── ... with git worktree)\n└── feature3/\n └── ...\n```\n\nTo serve the header of each working tree at `https://localhost:8443//json.hpp`, a configuration file is needed.\n1. Create the file `serve_header.yml` in the top level or project root directory of any working tree:\n ```yaml\n root: ..\n ```\n By shifting the web server root directory up one level, the `single_include/nlohmann/json.hpp` header files relative to each sibling directory or working tree will be served.\n\n2. Start `serve_header.py` by running this command from the same top level or project root directory the configuration file is located in:\n ```\n $ make serve_header\n ```\n\n`serve_header.py` will automatically detect the addition or removal of working trees anywhere within the configured web server root directory.\n\n\n---\ndescription: \"Cursor rules for Python Flask development with JSON guide.\"\nglobs: **/*\nalwaysApply: false\n---\nThis project is heavily reliant on our custom Drawscape Factorio python module.\n\nHere is code examples of how to use the module:\n\n```python\nfrom drawscape_factorio import create as createFactorio\nfrom drawscape_factorio import importFUE5\n\nwith open('/path/to/exported-entities.json', 'r') as file:\n json_data = json.load(file)\n data = importFUE5(json_data)\n result = createFactorio(data, {\n 'theme_name': 'default',\n 'color_scheme': 'main',\n 'show_layers': ['assets', 'belts', 'walls', 'rails', 'electrical', 'spaceship']\n })\n\nwith open(output_file_name, 'w') as f:\n f.write(result['svg_string'])\n"}