minetest.git - modified minetest for gpcfs purposes

about summary refs log tree commit diff

path: root/src/convert_json.h

	Commit message (Collapse)	Author	Age
*	Sort out cURL timeouts and increase default	sfan5	2021-04-02
\|
*	Serialize tool capabilities JSON without whitespace	sfan5	2021-03-20
\| \| \| \|	fixes #11087
*	Update JsonCPP to 1.8.3 (#6466)	Loïc Blot	2017-09-26
\| \| \| \| \| \| \| \| \| \|	* Update JsonCPP to 1.8.3 * Fix deprecated functions Json::FastWriter, Json::StyledWriter and Json::Reader are marked deprecated since 1.1 and are deprecated in 0.8 but not shown at compilation time. Use new methods to serialize/deserialize
*	C++ modernize: Pragma once (#6264)	Loïc Blot	2017-08-17
\| \| \| \|	* Migrate cpp headers to pragma once
*	Remove remaining modstore code (#6120)	Elijah Duffy	2017-07-14
\|
*	Fixes for compiling with a newer (system) jsoncpp (#4429)	Rogier-5	2016-08-10
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	* Move included json code to jsoncpp subdirectory This is needed to avoid having to specify the minetest src directory as a system include when fixing the json includes. * Fix json includes They used "", so that the compiler searches the project's directory first. The result was that when compiling with a system jsoncpp, the project's own version of json.h was still included, instead of the system version. The includes now use <>, so a system location, or one specified with '-Ilocation' is searched only. * Fix for jsoncpp deprecated function warning When compiling with a newer version of jsoncpp (and ENABLE_SYSTEM_JSONCPP=true), jsoncpp emits a warning about a deprecated function that minetest uses.
*	Remove ugly curl struct pointer from jsonFetchValue signature	sapier	2014-06-19
\|
*	Pass arguments by reference	Selat	2014-03-12
\|
*	Replace C++ mainmenu by formspec powered one	sapier	2013-07-02

ode_style_guidelines). 4. The code's interfaces are well designed, regardless of other aspects that might need more work in the future. 5. It uses protocols and formats which include the required compatibility. ## Issues If you experience an issue, we would like to know the details - especially when a stable release is on the way. 1. Do a quick search on GitHub to check if the issue has already been reported. 2. Is it an issue with the Minetest *engine*? If not, report it [elsewhere](http://www.minetest.net/development/#reporting-issues). 3. [Open an issue](https://github.com/minetest/minetest/issues/new) and describe the issue you are having - you could include: - Error logs (check the bottom of the `debug.txt` file) - Screenshots - Ways you have tried to solve the issue, and whether they worked or not - Your Minetest version and the content (subgames, mods or texture packs) you have installed - Your platform (e.g. Windows 10 or Ubuntu 15.04 x64) After reporting you should aim to answer questions or clarifications as this helps pinpoint the cause of the issue (if you don't do this your issue may be closed after 1 month). ## Feature requests Feature requests are welcome but take a moment to see if your idea follows the [roadmap](https://forum.minetest.net/viewtopic.php?t=9177) in some way and fits the whole picture of the project. You should provide a clear explanation with as much detail as possible. ## Translations Translations of Minetest are performed using Weblate. You can access the project page with a list of current languages [here](https://hosted.weblate.org/projects/minetest/minetest/). ### Donations If you'd like to monetarily support Minetest development, you can find donation methods on [our website](http://www.minetest.net/development/#donate). # Maintaining *This is a concise version of the [Rules & Guidelines](http://dev.minetest.net/Category:Rules_and_Guidelines) on the developer wiki.* These notes are for those who have push access Minetest (core developers / maintainers). - See the [project organisation](http://dev.minetest.net/Organisation) for the people involved. ## Reviewing pull requests Pull requests should be reviewed and, if appropriate, checked if they achieve their intended purpose. You can show that you are in the process of, or will review the pull request by commenting *"Looks good"* or something similar. **If the pull-request is not [merge-able](#a-pull-request-is-considered-merge-able-when):** Submit a comment explaining to the author what they need to change to make the pull-request merge-able. - If the author comments or makes changes to the pull-request, it can be reviewed again. - If no response is made from the author within 1 month (when improvements are suggested or a question is asked), it can be closed. **If the pull-request is [merge-able](#a-pull-request-is-considered-merge-able-when):** Submit a :+1: (+1) or "Looks good" comment to show you believe the pull-request should be merged. "Looks good" comments often signify that the patch might require (more) testing. - Two core developers must agree to the merge before it is carried out and both should +1 the pull request. - Who intends to merge the pull-request should follow the commit rules: - The title should follow the commit guidelines (title starts with a capital letter, present tense, descriptive). - Don't modify history older than 10 minutes. - Use rebase, not merge to get linear history: - `curl https://github.com/minetest/minetest/pull/1.patch | git am` ## Reviewing issues and feature requests - If an issue does not get a response from its author within 1 month (when requiring more details), it can be closed. - When an issue is a duplicate, refer to the first ones and close the later ones. - Tag issues with the appropriate [labels](https://github.com/minetest/minetest/labels) for devices, platforms etc. ## Releasing a new version *Refer to [dev.minetest.net/Releasing_Minetest](http://dev.minetest.net/Releasing_Minetest)*