Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add json support, fix #10, ref XQF/xqf#12 #13

Closed
wants to merge 3 commits into from

Conversation

illwieckz
Copy link
Contributor

Hi @stevenh, this PR imports patches from the @exprojects's qstat-json fork.

This fork was based on a source tarball, so was amnesic to all the revision history, also, this fork included mistakenly some temporary build files.

I've rewritten by hand the two useful patches and I committed them with the original author (Steve Teuber <steve<ad>exprojects.org>) and the original author date for each commit.

After that I've modified the source to add json support to games that were added since the release tarball Steve used (like starmade, dirtybomb, farmsim and ksp) and fixed the ventrilo omission he did.

After that I renamed name_xfroms to xform_names and used xform_printf() instead of fprintf() in json code, like in e777674 (Refactored output splitting out xform processing into its own files improving various portions of it.)

So, some intermediate commits cannot build, but the whole PR builds. I think we can't do better than that without rewriting Steve's commits, which raises legal issues: it must be clear to know who have done what and when.

@skybon, you will probably be interested by this PR.

@vorot93
Copy link
Contributor

vorot93 commented Jun 30, 2015

@illwieckz Nice work! Could you please rewrite the first two commits using @exprojects current GitHub email? Thanks.

@illwieckz
Copy link
Contributor Author

I used the email address @exprojects used himself, see eXprojects/qstat-json/commit/1c56085.patch for example. Legally I think it's the better thing to do.

@vorot93
Copy link
Contributor

vorot93 commented Jun 30, 2015

@illwieckz GitHub does profile linking using email. Since first and foremost license legal requirement is to make proper attribution I believe it is better to use @exprojects' current email.

@illwieckz
Copy link
Contributor Author

I think the only user email Github reveals is the commit one.

@vorot93
Copy link
Contributor

vorot93 commented Jun 30, 2015

@illwieckz And that's the email those two commits should have too :-) Check out latest commits here

@illwieckz
Copy link
Contributor Author

Well, the better is to ask @exprojects himself if he wants I rewrite the commits with his Steve Teuber <steve.teuber<ad>idealo.de> author info.

@illwieckz
Copy link
Contributor Author

I've emailed Steve to ask him which address he wants (he can also just add the former address to his GitHub profile to get profile linking on that commit).

xform_printf(OF, "\t\t</players>\n");
}

/**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we split these out to a separate file please e.g. json.c, as qstat.c is already massive.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

massively done

@illwieckz
Copy link
Contributor Author

so, the code now splits qstat.c to output-standard.c, output-xml.c and output-json.c (all with a .h file).

template.c was renamed to output-template.c and the missing output-template.h was created, and output-template.h now rely on qstat.h (before that, some parts were copypasted in template.c).

@illwieckz
Copy link
Contributor Author

Just one last thing about PR:

As a general rule each PR should be an individual commit
Each project / team has their own rules

There is no PR in git, after a merge, a PR is nothing about a noisy additional commit in the worst case (like GitHub does), PR is just a social mechanism to say « hello, I have changes for you ».

A pull request is just the name GitHub gives to the process to request a pull from a foreign branch, some other online hosting platform call it a merge request for example, and in the traditional form, it's just a request for pull, like there is request for comments.

A pull request is nothing than requesting a pull from a foreign branch, git does not know what is a PR, and there is absolutely no rule in Git that said there must be only one commit per branch, because there is already two obvious rule: there is one commit per commit, and there is branches for multiples commits for changes that does not fit in one commit.

Git was not created to have only one branch per commit, which is insane to maintain, and a request for pull is about branch… If a PR were about commits and not branch, it were not called a pull request but a cherry-pick request

Foreign commits are not pulled, they are cherry-picked, pull is for branches, branches is for multiple commit about the same effort, and jumbo commits that made too much things must be splitted, but branch with multiple commits designed for a unique purpose must not be splitted.

@stevenh
Copy link
Contributor

stevenh commented Jul 8, 2015

Making progress, but the issues highlighted by the review need to be fixed in this PR and not in separate PR's to ensure the code base is in good state no matter which revision is used.

Its great to use new PR's for other issues like general style cleanup and display split which effect other areas of the code but each new PR needs to pass review on its own prior to commit.

Currently your PR's are all dependent on each other instead of being based off separate branches, which make them impossible to review :(

By altering the structure of how they are committed it should be possible to all but eliminate these interdependencies.

From what I can determine we should see the following PR's:

  1. Eliminate unused vars (commits from PR Unset unused variables to avoid warnings, ref #19 #25)
  2. Add json support (combine PR Add json support, fix #10, ref XQF/xqf#12  #13, PR Json improvement, ref #13, ref #10, ref XQF/xqf#12 #26, PR Qstat help improvement, fix #17 #27)
  3. Style cleanup
  4. Split existing display code out to separate files.

Keep up the good work :)

@illwieckz
Copy link
Contributor Author

  1. Eliminate unused vars (commits from PR Unset unused variables to avoid warnings, ref #19 #25)
  2. Add json support (combine PR Add json support, fix #10, ref XQF/xqf#12  #13, PR Json improvement, ref #13, ref #10, ref XQF/xqf#12 #26, PR Qstat help improvement, fix #17 #27)
  3. Style cleanup
  4. Split existing display code out to separate files.

I can't do that, it means redoing all the work from scratch, with risk to introduce new issues.

The work was done in the order I use because it was the safest way to do this job.

I can only do that:

  1. Add json support (+ fix utf8 etc. from PR Json improvement, ref #13, ref #10, ref XQF/xqf#12 #26), it means backports all the change by hand from Json improvement, ref #13, ref #10, ref XQF/xqf#12 #26 then rebase the next branch by hand (git will be able to rebase the others automatically but not this one).
  2. Split the display code.
  3. Begin to clean style - depend of the split
  4. Unset unused variables - depend of the cleaning
  5. Qstat help improvement PR Qstat help improvement, fix #17 #27 + args must exclude themselves from Json improvement, ref #13, ref #10, ref XQF/xqf#12 #26. This is not a JSON issue, it's just the current JSON effort spotted it, there was already a problem with xml and raw, it's better to keep this fix as another PR, it's not related to JSON processing, it's related to Qstat user interface.
      1. and 5. are not JSON-related, it's just some tasks motivated by JSON, they can be done in the order we want, they change nothing for qstat and for you. But it change many thing to me if we do not do that in the order above, because it means to me redoing all from scratch.

xform_printf(OF, "\t\t</players>\n");
}

void xml_display_farcry_player_info(struct qserver *server)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

github is fooled, it's already fixed

@illwieckz
Copy link
Contributor Author

Ok, this was was painful but it's done, it needed to manually backports changes from #26 to #13, #23 and #24. No branch was able to rebase automatically, but I was able to use merge/cherry-pick to recreate each branch without editing files (except for the backports from #26).

Merging the unused var PR #25 before the json pr #13 is undoable, it means backporting by hand all the changes to all other PR since merge will be broken, editing plenty of files by hand each time to just redoing the job in each history. It's the better way to introduce new issues and it is very unsafe and painful. The unused var issue is in the code since years, it's not a problem at all if it's fixed after the json support addition.

Fixing unused var before or after introducing json support is the same to you (json does not depend on it): it was not fixed, it will be fixed, it's ok, it's just another PR unrelated that can be merged right after others PR unrelated.

But fixing unused var before or after introducing json support is not the same to me, it means editing manually each branch for each other PR. It's unsafe for no gain.

This is now the PR list:

#13 Add json support
#23 Split the display code
#24 Begin to clean style, spacing, indentation (cleaning display code + qstat.cfg)
#25 Unset unused variables
#27 Qstat help improvement, also fix the user interface (some options must exclude themselves).

PR #26 is now unneeded since all commits were backported to #13 or merged to #27.

@illwieckz
Copy link
Contributor Author

I've done some extra work with uncrustify to clean the source and I get very good results, so the PR #24 will just be pure noise in the history since I will submit a better one soon.

So, I closed the PR #24 and rebuilded the PR #25 and #27 to be able to merge them without it.

This is now the PR list:

#13 Add json support
#23 Split the display code
#25 Unset unused variables
#27 Qstat help improvement, also fix the user interface (some options must exclude themselves) and some query style.

stevenh added a commit that referenced this pull request Aug 27, 2015
iterator limit now match malloc in protocol listing, fix #21, ref #13
@z
Copy link

z commented Jan 14, 2016

What's the status on this?

@illwieckz
Copy link
Contributor Author

Hello @stevenh, I just reedited all my PR to include the iterator limit to match malloc in protocol listing, I reminds you the merge order:

@illwieckz
Copy link
Contributor Author

Hi @stevenh , is this PR ok for you now? I hope it will be merged soon.

@stevenh
Copy link
Contributor

stevenh commented Jan 30, 2016

Still looks like a number issues already raised, haven't been addressed in this PR.

A secondary PR to fix them is not an option as this means we'll have bad code in the repo at the point this is merged, so I'm afraid I'm going to have to insist all issues are addressed before we can get this merged.

@illwieckz
Copy link
Contributor Author

Hi,

Still looks like a number issues already raised, haven't been addressed in this PR.

Please list them, "looks like" is not an argument.

@illwieckz
Copy link
Contributor Author

Hi, I fixed in this PR the temporary double hyphen --json options wrote by eXprojetcs that are deleted by myself in PR #27 dedicated to option/arg handling fixes which is blocked by the current PR.

@illwieckz
Copy link
Contributor Author

Hi @stevenh , is there still something preventing the merge ?

Steve Teuber and others added 3 commits April 13, 2016 18:19
- add json support to games added since Steve Teuber's patches
- use xform_names instead of name_xforms since Steven Hartland's refactoring
- use xform_printf() instead of fprintf() for json output
- remove commented out code
- use %s for a const switch seems a bit wasteful, fixing it
- do not use inline tests
- explicitely test pointers with NULL
- escape lone backslash character too
- RFC 4627 says: “JSON text SHALL be encoded in Unicode. The default encoding is UTF-8.”
- iterator limit now match malloc in protocol listing
- use singl-hyphen -json-protocols and -json-version options
@stevenh
Copy link
Contributor

stevenh commented Nov 27, 2016

merged via #53

@stevenh stevenh closed this Nov 27, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants