Giter Site home page Giter Site logo

sympy-bot's Introduction

SymPy

pypi version Join the chat at https://gitter.im/sympy/sympy Zenodo Badge Downloads GitHub Issues Git Tutorial Powered by NumFocus Commits since last release

SymPy Banner

See the AUTHORS file for the list of authors.

And many more people helped on the SymPy mailing list, reported bugs, helped organize SymPy's participation in the Google Summer of Code, the Google Highly Open Participation Contest, Google Code-In, wrote and blogged about SymPy...

License: New BSD License (see the LICENSE file for details) covers all files in the sympy repository unless stated otherwise.

Our mailing list is at https://groups.google.com/forum/?fromgroups#!forum/sympy.

We have a community chat at Gitter. Feel free to ask us anything there. We have a very welcoming and helpful community.

Download

The recommended installation method is through Anaconda, https://www.anaconda.com/products/distribution

You can also get the latest version of SymPy from https://pypi.python.org/pypi/sympy/

To get the git version do

$ git clone https://github.com/sympy/sympy.git

For other options (tarballs, debs, etc.), see https://docs.sympy.org/dev/install.html.

Documentation and Usage

For in-depth instructions on installation and building the documentation, see the SymPy Documentation Style Guide.

Everything is at:

https://docs.sympy.org/

You can generate everything at the above site in your local copy of SymPy by:

$ cd doc
$ make html

Then the docs will be in _build/html. If you don't want to read that, here is a short usage:

From this directory, start Python and:

>>> from sympy import Symbol, cos
>>> x = Symbol('x')
>>> e = 1/cos(x)
>>> print(e.series(x, 0, 10))
1 + x**2/2 + 5*x**4/24 + 61*x**6/720 + 277*x**8/8064 + O(x**10)

SymPy also comes with a console that is a simple wrapper around the classic python console (or IPython when available) that loads the SymPy namespace and executes some common commands for you.

To start it, issue:

$ bin/isympy

from this directory, if SymPy is not installed or simply:

$ isympy

if SymPy is installed.

Installation

SymPy has a hard dependency on the mpmath library (version >= 0.19). You should install it first, please refer to the mpmath installation guide:

https://github.com/fredrik-johansson/mpmath#1-download--installation

To install SymPy using PyPI, run the following command:

$ pip install sympy

To install SymPy using Anaconda, run the following command:

$ conda install -c anaconda sympy

To install SymPy from GitHub source, first clone SymPy using git:

$ git clone https://github.com/sympy/sympy.git

Then, in the sympy repository that you cloned, simply run:

$ pip install .

See https://docs.sympy.org/dev/install.html for more information.

Contributing

We welcome contributions from anyone, even if you are new to open source. Please read our Introduction to Contributing page and the SymPy Documentation Style Guide. If you are new and looking for some way to contribute, a good place to start is to look at the issues tagged Easy to Fix.

Please note that all participants in this project are expected to follow our Code of Conduct. By participating in this project you agree to abide by its terms. See CODE_OF_CONDUCT.md.

Tests

To execute all tests, run:

$./setup.py test

in the current directory.

For the more fine-grained running of tests or doctests, use bin/test or respectively bin/doctest. The master branch is automatically tested by GitHub Actions.

To test pull requests, use sympy-bot.

Regenerate Experimental LaTeX Parser/Lexer

The parser and lexer were generated with the ANTLR4 toolchain in sympy/parsing/latex/_antlr and checked into the repo. Presently, most users should not need to regenerate these files, but if you plan to work on this feature, you will need the antlr4 command-line tool (and you must ensure that it is in your PATH). One way to get it is:

$ conda install -c conda-forge antlr=4.11.1

Alternatively, follow the instructions on the ANTLR website and download the antlr-4.11.1-complete.jar. Then export the CLASSPATH as instructed and instead of creating antlr4 as an alias, make it an executable file with the following contents:

#!/bin/bash
java -jar /usr/local/lib/antlr-4.11.1-complete.jar "$@"

After making changes to sympy/parsing/latex/LaTeX.g4, run:

$ ./setup.py antlr

Clean

To clean everything (thus getting the same tree as in the repository):

$ git clean -Xdf

which will clear everything ignored by .gitignore, and:

$ git clean -df

to clear all untracked files. You can revert the most recent changes in git with:

$ git reset --hard

WARNING: The above commands will all clear changes you may have made, and you will lose them forever. Be sure to check things with git status, git diff, git clean -Xn, and git clean -n before doing any of those.

Bugs

Our issue tracker is at https://github.com/sympy/sympy/issues. Please report any bugs that you find. Or, even better, fork the repository on GitHub and create a pull request. We welcome all changes, big or small, and we will help you make the pull request if you are new to git (just ask on our mailing list or Gitter Channel). If you further have any queries, you can find answers on Stack Overflow using the sympy tag.

Brief History

SymPy was started by Ondřej Čertík in 2005, he wrote some code during the summer, then he wrote some more code during summer 2006. In February 2007, Fabian Pedregosa joined the project and helped fix many things, contributed documentation, and made it alive again. 5 students (Mateusz Paprocki, Brian Jorgensen, Jason Gedge, Robert Schwarz, and Chris Wu) improved SymPy incredibly during summer 2007 as part of the Google Summer of Code. Pearu Peterson joined the development during the summer 2007 and he has made SymPy much more competitive by rewriting the core from scratch, which has made it from 10x to 100x faster. Jurjen N.E. Bos has contributed pretty-printing and other patches. Fredrik Johansson has written mpmath and contributed a lot of patches.

SymPy has participated in every Google Summer of Code since 2007. You can see https://github.com/sympy/sympy/wiki#google-summer-of-code for full details. Each year has improved SymPy by bounds. Most of SymPy's development has come from Google Summer of Code students.

In 2011, Ondřej Čertík stepped down as lead developer, with Aaron Meurer, who also started as a Google Summer of Code student, taking his place. Ondřej Čertík is still active in the community but is too busy with work and family to play a lead development role.

Since then, a lot more people have joined the development and some people have also left. You can see the full list in doc/src/aboutus.rst, or online at:

https://docs.sympy.org/dev/aboutus.html#sympy-development-team

The git history goes back to 2007 when development moved from svn to hg. To see the history before that point, look at https://github.com/sympy/sympy-old.

You can use git to see the biggest developers. The command:

$ git shortlog -ns

will show each developer, sorted by commits to the project. The command:

$ git shortlog -ns --since="1 year"

will show the top developers from the last year.

Citation

To cite SymPy in publications use

Meurer A, Smith CP, Paprocki M, Čertík O, Kirpichev SB, Rocklin M, Kumar A, Ivanov S, Moore JK, Singh S, Rathnayake T, Vig S, Granger BE, Muller RP, Bonazzi F, Gupta H, Vats S, Johansson F, Pedregosa F, Curry MJ, Terrel AR, Roučka Š, Saboo A, Fernando I, Kulal S, Cimrman R, Scopatz A. (2017) SymPy: symbolic computing in Python. PeerJ Computer Science 3:e103 https://doi.org/10.7717/peerj-cs.103

A BibTeX entry for LaTeX users is

@article{10.7717/peerj-cs.103,
 title = {SymPy: symbolic computing in Python},
 author = {Meurer, Aaron and Smith, Christopher P. and Paprocki, Mateusz and \v{C}ert\'{i}k, Ond\v{r}ej and Kirpichev, Sergey B. and Rocklin, Matthew and Kumar, Amit and Ivanov, Sergiu and Moore, Jason K. and Singh, Sartaj and Rathnayake, Thilina and Vig, Sean and Granger, Brian E. and Muller, Richard P. and Bonazzi, Francesco and Gupta, Harsh and Vats, Shivam and Johansson, Fredrik and Pedregosa, Fabian and Curry, Matthew J. and Terrel, Andy R. and Rou\v{c}ka, \v{S}t\v{e}p\'{a}n and Saboo, Ashutosh and Fernando, Isuru and Kulal, Sumith and Cimrman, Robert and Scopatz, Anthony},
 year = 2017,
 month = Jan,
 keywords = {Python, Computer algebra system, Symbolics},
 abstract = {
            SymPy is an open-source computer algebra system written in pure Python. It is built with a focus on extensibility and ease of use, through both interactive and programmatic applications. These characteristics have led SymPy to become a popular symbolic library for the scientific Python ecosystem. This paper presents the architecture of SymPy, a description of its features, and a discussion of select submodules. The supplementary material provides additional examples and further outlines details of the architecture and features of SymPy.
         },
 volume = 3,
 pages = {e103},
 journal = {PeerJ Computer Science},
 issn = {2376-5992},
 url = {https://doi.org/10.7717/peerj-cs.103},
 doi = {10.7717/peerj-cs.103}
}

SymPy is BSD licensed, so you are free to use it whatever you like, be it academic, commercial, creating forks or derivatives, as long as you copy the BSD statement if you redistribute it (see the LICENSE file for details). That said, although not required by the SymPy license, if it is convenient for you, please cite SymPy when using it in your work and also consider contributing all your changes back, so that we can incorporate it and all of us will benefit in the end.

sympy-bot's People

Contributors

asmeurer avatar iamrajiv avatar namannimmo10 avatar oscarbenjamin avatar sidhantnagpal avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

sympy-bot's Issues

Multiple authors with multiple changes

Sometimes a PR will have multiple authors (like if someone picks up someone else's work), and there will be multiple changes, but only some of them are from certain authors. Right now, the bot will put all authors under every change. See for instance sympy/sympy#15049

When the release notes fail, add a link to how to write release notes

Currently when the release notes fail, it's not clear for me how to fix it, the added hints are nice, but not good enough. In addition what it says, let's add a sentence:

For more information please consult how to write release notes [here](...).

And on that page, let's document exactly what is allowed and not allowed and what is expected about good release notes.

is the initial reply too scary?

A fair number of people are opening PRs and then closing them, only to post later with a new PR. I guess its because a big red x appears. Maybe we can soften the text in the failed case:


Hi, I am the SymPy bot (vxyz). I'm here to make sure this pull request has a release notes entry.

There was an issue with the release notes. The <!-- BEGIN RELEASE NOTES --> block was not found. No need to open a new pull request; you can edit the text above. Please read the ...

[triangle thing] click.

Note: this comment will be updated ....

Suggest the submodule names for the header

The header names are SymPy submodules. When a header is missing, it says that it should be a submodule name. It could read the files that are changed, and if most or all of them are from certain submodules, it could suggest those as headers.

Tests for the webapp

Right now we have tests for the parts that parse the pull request description and edit the changelog, but there are no tests for the webapp logic. We should add some. I don't know what the best way to test it is. If anyone knows, let me know.

What will it do?

Is this meant to help with pull requests? That would be an excellent idea.

Make the webapp tests easier to maintain

The webapp tests are getting a bit unwieldy.

Something that would help to make them easier to write is if common data were factored out from the test functions. I think there are only a handful of pull request "patterns" that are tested, and we could create different objects to represent the data from those.

Improve test coverage

If you run the tests with pytest --cov=sympy_bot --cov-report=html you can see there are several lines that are not covered (you can ignore update_wiki.py, those lines are only covered by the test that runs on Travis).

Better error handling

Right now if there is an error (for example, an invalid use of the API), it just raises an exception and doesn't post anything, except for a few code paths where it checks for errors and posts a comment. So the user experience is that the bot just does nothing (the error is logged, but only admins in Heroku can see those).

It should check for errors almost everywhere and try to post a comment if it can.

show the original user text

I think it should copy the raw text that the user wrote and show it, so that it is clear what version the bot is commenting on. It was unclear to me if the bot already reacted to my changes or not.

That way, I know what change I made in the description, and all I have to do is just to wait until my change propagates to the bot's comment. Once I see my change made it, then I can see what the bot has to say. As opposed to parsing the bot's output and see if it matches my old text or new text.

Add a text

Add a text that the same comment will be updated by the bot. I was looking for a new comment, and it took me a while to realize that the bot updated the same comment.

Warn on new or deleted files

If a commit introduces a new file or deletes a file, we could have the bot warn about it. That way people will notice issues like sympy/sympy#18488. We could also make it fail in such cases, unless someone with push access whitelists the files somehow, e.g., by mentioning the bot and listing the files. CC @oscarbenjamin

Status not updated sometimes

It's because the added/deleted comment fails with

2020-02-25T21:16:11.385238+00:00 app[web.1]: Received pull_request event with delivery_id=0b46c900-5814-11ea-9fd3-9f90b3d5839b
2020-02-25T21:16:11.385406+00:00 app[web.1]: PR #16149 was edited.
2020-02-25T21:16:11.688004+00:00 heroku[router]: at=info method=POST path="/" host=sympy-bot.herokuapp.com request_id=f17fe55f-7626-4676-aac6-9ac190f00f3c fwd="140.82.115.249" dyno=web.1 connect=2ms service=308ms status=500 bytes=330 protocol=https
2020-02-25T21:16:11.686004+00:00 app[web.1]: Error handling request
2020-02-25T21:16:11.686013+00:00 app[web.1]: Traceback (most recent call last):
2020-02-25T21:16:11.686013+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.6/site-packages/aiohttp/web_protocol.py", line 390, in start
2020-02-25T21:16:11.686014+00:00 app[web.1]: resp = await self._request_handler(request)
2020-02-25T21:16:11.686014+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.6/site-packages/aiohttp/web_app.py", line 366, in _handle
2020-02-25T21:16:11.686015+00:00 app[web.1]: resp = await handler(request)
2020-02-25T21:16:11.686015+00:00 app[web.1]: File "/app/sympy_bot/webapp.py", line 40, in main_post
2020-02-25T21:16:11.686016+00:00 app[web.1]: result = await router.dispatch(event, gh)
2020-02-25T21:16:11.686016+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.6/site-packages/gidgethub/routing.py", line 80, in dispatch
2020-02-25T21:16:11.686016+00:00 app[web.1]: await callback(event, *args, **kwargs)
2020-02-25T21:16:11.686017+00:00 app[web.1]: File "/app/sympy_bot/webapp.py", line 68, in pull_request_edited
2020-02-25T21:16:11.686017+00:00 app[web.1]: await pull_request_comment(event, gh)
2020-02-25T21:16:11.686018+00:00 app[web.1]: File "/app/sympy_bot/webapp.py", line 89, in pull_request_comment
2020-02-25T21:16:11.686018+00:00 app[web.1]: com = await gh.getitem(commit['url'])
2020-02-25T21:16:11.686019+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.6/site-packages/gidgethub/abc.py", line 99, in getitem
2020-02-25T21:16:11.686019+00:00 app[web.1]: jwt=jwt, oauth_token=oauth_token)
2020-02-25T21:16:11.686020+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.6/site-packages/gidgethub/abc.py", line 82, in _make_request
2020-02-25T21:16:11.686020+00:00 app[web.1]: data, self.rate_limit, more = sansio.decipher_response(*response)
2020-02-25T21:16:11.686020+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.6/site-packages/gidgethub/sansio.py", line 326, in decipher_response
2020-02-25T21:16:11.686021+00:00 app[web.1]: raise exc_type(*args)
2020-02-25T21:16:11.686095+00:00 app[web.1]: gidgethub.BadRequest: Not Found

some way to indicate major/minor changes?

Maybe I missed it?

I'm sure at some point there are diminishing returns, and of course a human can tweak the wiki later. But it just seems like a pain for a human being to decide later which of the many changes are major and which are minor.

Automatic tagging and assigning of Pull Requests and Issues

I don't know if this is feasible, however, I would still like the sympy-bot to tag the PRs with labels, at least related to the module mentioned in the release notes. This would help the new contributors to help in improving sympy by finding the PRs and Issues of the module that interests them.
In addition it would be great to automatically assign an issue to someone by using commands like, Ping, etc.
This will also reduce a lot of work load on members of the organization.
P.S. - I observed that zulip-bot is capable of doing the above.

Render the submodule headers as Markdown headers?

The release notes may look better if instead of formatting it like

  • core
    • change 1
    • change 2
  • solvers
    • change 1
    • change 2
* core
  * change 1
  * change 2
* solvers
  * change 1
  * change 2

we instead used Markdown headers, like

core

  • change 1
  • change 2

solvers

  • change 1
  • change 2
#### core
* change 1
* change 2
#### solvers
* change 1
* change 2

It may also be easier for people to write release notes in this format, al they won't have to deal with nested bullets.

Finally, this would allow linking to the notes for a specific submodule, since every Markdown header gets an anchor.

Level 4 headers may be better level 3. Level 4 renders the same as just bold text, but with an anchor.

Update the Authors section automatically

We should take the code from the SymPy release code that gets the list of authors for the release notes, and make it run on the bot. The code is here: https://github.com/sympy/sympy/blob/9d53296873723e7a3a287b7508669f830c300400/release/rever.xsh#L381

That way, the list of authors will always be up to date after each pull request merge. Note that it will need to completely clear and re-update the authors list each time in case there is a .mailmap update.

One minor issue with this is that any updates to .mailmap will need to be done as pull requests at release time, so that they bot updates the notes properly.

This would also require the bot to clone the main sympy repo. Hopefully that doesn't take too long. I wonder if we can cache it on Heroku somehow, so that we only need to do a pull each time.

Ready for testing

This is now ready for testing. I have it set up on my test repo at https://github.com/asmeurer/GitHub-Issues-Test. Please make a pull request against that repo and test writing release notes in the PR description. I can give you push access to that repo if you want to test merging.

You can see an example at asmeurer/GitHub-Issues-Test#31, which got added to https://github.com/asmeurer/GitHub-Issues-Test/wiki/Release-Notes-for-1.2.1

I still need to improve the messaging (suggestions welcome), but the bot behavior itself should be working and complete now.

CC @certik (and anyone else who wants to test it)

Do some basic linting of the PR description

In addition to the release notes, we can do some basic linting of the PR description. These wouldn't be things that would fail the build, but would hopefully guide people to writing better descriptions. Some things we can check

  • Warn if there is no "fixes #1234" in the description (but say it's OK if there is no corresponding issue)
  • Warn if the PR title contains an issue number
  • Suggest people to manually post a reference to the PR on the issue
  • Make sure there are no commits in the PR that add large files, or add junk files

Any other ideas?

BadRequest error

The following error happened with PR sympy/sympy#15814.

2019-01-20T17:09:31.684311+00:00 app[web.1]: PR #15814 was opened.
2019-01-20T17:09:31.738566+00:00 app[web.1]: Error handling request
2019-01-20T17:09:31.738574+00:00 app[web.1]: Traceback (most recent call last):
2019-01-20T17:09:31.738595+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.6/site-packages/aiohttp/web_protocol.py", line 390, in start
2019-01-20T17:09:31.738630+00:00 app[web.1]: resp = await self._request_handler(request)
2019-01-20T17:09:31.738632+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.6/site-packages/aiohttp/web_app.py", line 366, in _handle
2019-01-20T17:09:31.738634+00:00 app[web.1]: resp = await handler(request)
2019-01-20T17:09:31.738637+00:00 app[web.1]: File "/app/sympy_bot/webapp.py", line 38, in main_post
2019-01-20T17:09:31.738638+00:00 app[web.1]: result = await router.dispatch(event, gh)
2019-01-20T17:09:31.738640+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.6/site-packages/gidgethub/routing.py", line 80, in dispatch
2019-01-20T17:09:31.738642+00:00 app[web.1]: await callback(event, *args, **kwargs)
2019-01-20T17:09:31.738645+00:00 app[web.1]: File "/app/sympy_bot/webapp.py", line 66, in pull_request_edited
2019-01-20T17:09:31.738646+00:00 app[web.1]: await pull_request_comment(event, gh)
2019-01-20T17:09:31.738648+00:00 app[web.1]: File "/app/sympy_bot/webapp.py", line 77, in pull_request_comment
2019-01-20T17:09:31.738650+00:00 app[web.1]: async for commit in commits:
2019-01-20T17:09:31.738652+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.6/site-packages/gidgethub/abc.py", line 109, in getiter
2019-01-20T17:09:31.738661+00:00 app[web.1]: jwt=jwt, oauth_token=oauth_token)
2019-01-20T17:09:31.738663+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.6/site-packages/gidgethub/abc.py", line 82, in _make_request
2019-01-20T17:09:31.738665+00:00 app[web.1]: data, self.rate_limit, more = sansio.decipher_response(*response)
2019-01-20T17:09:31.738666+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.6/site-packages/gidgethub/sansio.py", line 326, in decipher_response
2019-01-20T17:09:31.738668+00:00 app[web.1]: raise exc_type(*args)
2019-01-20T17:09:31.741523+00:00 app[web.1]: gidgethub.BadRequest: Not Found

Auto-merge on green

Another thing the bot could be used for is to allow someone to tag a PR to be automatically merged as soon as it goes green. That way if they don't have to wait for Travis. For instance, they could add a label "automerge when tests pass" and it would do so.

I'm not exactly sure how to do it. I think there are probably events for the tests passing, but we need to make sure that we only do it if the tests pass on the most recent commit when the label was added. Otherwise the label should become invalid. I don't know if we can check the order. If not, we could make the bot automatically remove that label from any PR as soon as a commit is pushed. We could also check for comments like "do not merge".

Let the bot give people triage access

There is a new "triage" permission in GitHub, which gives people the ability to add labels to issues without giving them push access. See https://help.github.com/en/articles/repository-permission-levels-for-an-organization.

The only issue is that you have to add people to it automatically. We could let the bot give people triage access.

One option would be to have a special bot command like "@sympy-bot give @user triage access". A problem with this is that it isn't discoverable or even easy to remember, so it probably wouldn't get used.

Another option would be to give everyone who opens a pull request access. This could be a bit intrusive, but maybe not. You do have to accept an invitation to actually get the access, and I think you can remove yourself at any time (but I should confirm this).

If this is too much we could have the bot ask people if they want it, or maybe have a link in the bot message to a page where they can enter their username, and the bot will give it. Probably if we do it that way we should authenticate with GitHub so that people can only give themselves access. Otherwise it could be used to spam people.

Update the wiki push test

The wiki push test on CI doesn't work any more because it uses password authentication, which GitHub no longer allows.

Uniform second level list marking

I just edited the release notes a bit and noted that some "second level lists" were using -and some *. I manually edited all to use *, but it would be nice if the bot could either check for the preferred format or change it to a unified format.

The difference seems to be that there is no additional spacing between the items when using -, so maybe that is actually preferred. The Wiki page states *, but some frequent contributors seems to use -.

I do not have any strong opinions on which should be used, but for consistency it should be one of them.

I also noted a bit of inconsistency when it comes to starting entries with capital letters. Maybe not worth checking for, but worth considering if one should update the Wiki page example to use capital letters (and possibly add an example with backticks for a method name). Or we just say that it doesn't matter or that it should not start with a capital letter.

Benchmark report

We've added the benchmark run on travis sympy/sympy#17828 before.
But there should be additional work to make the bot actually post the benchmark report from the CI.

Add automatic Binder deployment for commits

I think it would be good if we can have the sympy-bot comment launch binder links for each commit in a PR. This would make the job of reviewers quite easy as any changes can be tested instantly without cloning the branch. See this for a working example.

Too many NO ENTRY

One issue I've noticed with the bot is that people write NO ENTRY for pull requests that really should have a release note entry.

I'm not really sure what to do about this. This is what it says in the pull request template

#### Release Notes

<!-- Write the release notes for this release below. See
https://github.com/sympy/sympy/wiki/Writing-Release-Notes for more information
on how to write release notes. If there is no release notes entry for this PR,
write "NO ENTRY". The bot will check your release notes automatically to see
if they are formatted correctly. -->

<!-- BEGIN RELEASE NOTES -->

<!-- END RELEASE NOTES -->

Maybe the issue is that it is mentioned there? If anyone has any suggestions on how this can be improved let me know.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.