Giter Club home page Giter Club logo

leanblueprint's Introduction

Lean blueprints

This is a plasTeX plugin allowing to write blueprints for Lean 4 projects. You can learn what those blueprints are about by reading Terence Tao’s excellent blog post about it.

This infrastructure was originally created in 2020 for the Sphere Eversion Project. Since then, it has been used by many projects. The list below will give you many examples but is not intended to be exhaustive. It is in approximate chronological order.

Installation

This package depends on plastexdepgraph which requires graphviz and its development libraries. If you have a user-friendly OS, it is as simple as sudo apt install graphviz libgraphviz-dev. See https://pygraphviz.github.io/documentation/stable/install.html otherwise.

Then, assuming you have a sane python environment, you only need to run:

pip install leanblueprint

Note this will automatically install plasTeX and the other needed python packages.

Upgrading

pip install -U leanblueprint

will upgrade to the latest version.

Starting a blueprint

This package provides a command line tool leanblueprint that automates in particular the creation of a blueprint for your Lean project. This tool is not mandatory in any way. Its goal is to make it easy to create a blueprint without worrying about choosing a file layout or a continuous integration and deployment setup. As every one–size-fits-all tool, it is fairly opinionated. It assumes in particular that your project repository is hosted on Github and you want to host its blueprint on github.io.

If you don’t want to use the leanblueprint command line tool, you can use this plugin as any other plasTeX plugin, using plastex --plugins leanblueprint my_file.tex (not recommended).

In order to use the leanblueprint tool, you need to already have a Lean project created using lake. In addition, your blueprint will be easier to configure if you have at least one commit in the git repository of your project and you have already configured its GitHub git remote (GitHub displays instructions allowing to do the remote setup when you create a new repository there). You should also tell GitHub that you want to use GitHub pages using GitHub actions. You can do that from the GitHub page of your repository by clicking on the Settings tab in the top menu, then the Pages link in the side menu and selecting GitHub Actions as the source, as in the following screenshot.

GitHub pages settings

Assuming your project is ready and GitHub is configured, from your project folder run

leanblueprint new

You will then have to answer some questions to configure your blueprint. If unsure, accept all default answers by simply hitting Enter for each question. Only two questions will insist on having an explicit y/n answer: the question confirming you want to create the blueprint and the one proposing to commit to your git repository.

After running this creation script, you can push to GitHub and wait for GitHub Actions to build your blueprint. You can monitor this task in the Actions tab of the GitHub page of your repository. When building is done, the html version of your blueprint will be deployed to https://user_name.github.io/repo_name/blueprint/ (with the appropriate user or organization name and repository name). The pdf version will be at https://user_name.github.io/repo_name/blueprint.pdf. The API documentation will be at https://user_name.github.io/repo_name/docs/.

Local compilation

Assuming you used the leanblueprint command line tool to create your blueprint (or at least that you use the same file layout), you can use leanblueprint to build your blueprint locally. The available commands are:

  • leanblueprint pdf to build the pdf version (this requires a TeX installation of course).
  • leanblueprint web to build the web version
  • leanblueprint checkdecls to check that every Lean declaration name that appear in the blueprint exist in the project (or in a dependency of the project such as Mathlib). This requires a compiled Lean project, so make sure to run lake build beforehand.
  • leanblueprint all to run the previous three commands.
  • leanblueprint serve to start a local webserver showing your local blueprint (this sounds silly but web browsers paranoia makes it impossible to simply open the generated html pages without serving them). The url you should use in your browser will be displayed and will probably be http://0.0.0.0:8000/, unless the port 8000 is already in use.

Note: plasTeX does not call BibTeX. If you have a bibliography, you should use leanblueprint pdf before leanblueprint web to get it to work in the web version (and redo it when you add a reference).

Editing the blueprint

Assuming you used the leanblueprint command line tool to create your blueprint (or at least that you use the same file layout), the source of your blueprint will be in the blueprint/src subfolder of your Lean project folder.

Here you will find two main TeX files: web.tex and print.tex. The first one is intended for plasTeX while the second one is intended for a traditional TeX compiler such as xelatex or lualatex. Each of them includes macros/common.tex for all TeX macros that make sense for both kinds of outputs (this should be most of your macros). Macros that should behave differently depending on the target format should go to either macros/web.tex or macros/print.tex. All those files already exist and contains comments reminding you about the above explanations.

The main content of your blueprint should live in content.tex (or in files imported in content.tex if you want to split your content).

The main TeX macros that relate your TeX code to your Lean code are:

  • \lean that lists the Lean declaration names corresponding to the surrounding definition or statement (including namespaces).
  • \leanok which claims the surrounding environment is fully formalized. Here an environment could be either a definition/statement or a proof.
  • \uses that lists LaTeX labels that are used in the surrounding environment. This information is used to create the dependency graph. Here an environment could be either a definition/statement or a proof, depending on whether the referenced labels are necessary to state the definition/theorem or only in the proof.

The example below show those essential macros in action, assuming the existence of LaTeX labels def:immersion, thm:open_ample and lem:open_ample_immersion and assuming the existence of a Lean declaration sphere_eversion.

\begin{theorem}[Smale 1958]
  \label{thm:sphere_eversion}
  \lean{sphere_eversion}
  \leanok
  \uses{def:immersion}
  There is a homotopy of immersions of $𝕊^2$ into $ℝ^3$ from the inclusion map to
  the antipodal map $a : q ↦ -q$.
\end{theorem}
  
\begin{proof}
  \leanok
  \uses{thm:open_ample, lem:open_ample_immersion}
  This obviously follows from what we did so far.
\end

Note that the proof above is abbreviated in this documentation. Be nice to you and your collaborators and include more details in your blueprint proofs!

By default, the dependency graph will collect the environments definition, lemma, proposition, theorem and corollary. You can change this list using the thms option which expects a list of environment names separated by + signs. For instance you can write

\usepackage[thms=dfn+lem+prop+thm+cor]{blueprint}

if you like short environment names. See the plastexdepgraph documentation for other dependency graph options having nothing to do with Lean.

The above macros are by far the most important, but there are a couple more.

  • \notready which claims the surrounding environment is not ready to be formalized, typically because it requires more blueprint work.
  • \discussion gives a GitHub issue number where the surrounding definition or statement is discussed.
  • \proves inside a proof environment gives the LaTeX label of the LaTeX statement being proved. This is necessary only when the proof does not immediately follow the statement.

Blueprint configuration

Most of the configuration is handled during the blueprint creation if you used the leanblueprint client. But some of it can be changed by LaTeX macros in the web version of LaTeX preamble (in the file web.tex if you use the default layout).

  • \home{url} defines the url of the home page of the project.

  • \github{url} defines the url of the git repository of the project.

  • \dochome{url} defines the url of the doc-gen API documentation of the project.

  • \graphcolor{node_type}{color}{description} sets a color in the dependency graph and its description in the legend. The default values are

    • stated, green, Green
    • can_state, blue, Blue
    • not_ready, #FFAA33, Orange
    • proved, #9CEC8B, Green
    • can_prove, #A3D6FF, Blue
    • defined, #B0ECA3, Light green
    • fully_proved, #1CAC78, Dark green

    In particular you can use the above color descriptions to interpret the node type by comparison with the default legend.

Acknowledgments

The continuous integration configuration template used by leanblueprint new is based on the work of many people who had to write such a configuration by hand in the past, including Yakov Pechersky, Ben Toner, Sky Wilshaw, Yaël Dillies and Utensil Song. It also got contributions from Pietro Monticone.

leanblueprint's People

Contributors

bergschaf avatar ianjauslin-rutgers avatar kbuzzard avatar mdgeorge4153 avatar mo271 avatar patrickmassot avatar pitmonticone avatar utensil avatar zeramorphic avatar

Stargazers

 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  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  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  avatar  avatar  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

leanblueprint's Issues

lakeblueprint pdf not working on fresh blueprint

It seems like the leanblueprint macros are not defined for some reason in my environment.

I created a brand new repo and lean blueprint:

lake new blueprint-mwe
cd blueprint-mwe
git ci -am "initial commit"
leanblueprint new

I then edited blueprint/src/content.tex as follows:

\newtheorem{theorem}{Theorem}

\begin{theorem}
    \label{thm:example}
    \notready
    Exampl
\end{theorem}

When I run leanblueprint pdf I get the following (some output elided):

Rc files read:
  /etc/LatexMk
  latexmkrc
Latexmk: This is Latexmk, John Collins, 20 November 2021, version: 4.76.
Latexmk: applying rule 'pdflatex'...
Rule 'pdflatex': File changes, etc:
   Changed files, or newly in use since previous run(s):
      '/home/mdgeorge/lean/blueprint-mwe/blueprint/print/print.aux'
------------
Run number 1 of rule 'pdflatex'
------------
------------
Running 'xelatex -synctex=1  -recorder -output-directory="/home/mdgeorge/lean/blueprint-mwe/blueprint/print"  "print.tex"'
------------
This is XeTeX, Version 3.141592653-2.6-0.999993 (TeX Live 2022/dev/Debian) (preloaded format=xelatex)
 restricted \write18 enabled.
entering extended mode
(./print.tex
LaTeX2e <2021-11-15> patch level 1
L3 programming layer <2022-01-21>
(/usr/share/texlive/texmf-dist/tex/latex/base/report.cls

...

(/usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty)
(/usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty))
(/home/mdgeorge/lean/blueprint-mwe/blueprint/print/print.out)
(/home/mdgeorge/lean/blueprint-mwe/blueprint/print/print.out)
(/usr/share/texlive/texmf-dist/tex/latex/amsfonts/umsa.fd)
(/usr/share/texlive/texmf-dist/tex/latex/amsfonts/umsb.fd) [1] (./content.tex
! Undefined control sequence.
l.13     \notready

Dependency graph is not properly generated if there is no empty line above '\begin{theorem}'

I ran into an issue where the dependency graph is not generated properly if the line preceding '\begin{theorem}' or '\begin{definition}' is not empty.

Setup:

  • leanblueprint: latest commit (a377de0)
  • plastex: 3.0

Steps to reproduce: use the following tex file:


\usepackage{amsmath, amsthm}
\usepackage[showmore, dep_graph, coverage, project=../../]{blueprint}

\newtheorem{theorem}{Theorem}

\begin{document}

tt
\begin{theorem}
  \label{tt:test}
  Test
\end{theorem}

\begin{proof}
test
\end{proof}

tt
\begin{theorem}
  \label{tt:test2}
  Test
\end{theorem}

\begin{proof}
\uses{tt:test}
test uses \ref{tt:test}
\end{proof}

\end{document}

The dependency graph does not show the dependency between test and test2. It works fine if the lines before the theorems are blank.

cut and paste access to LaTeX and lean labels?

If I click on a declaration in the blueprint graph, can we discretely have at the bottom of the pop-up window LaTeX: ZHat.torsionFree ; Lean: ZHat.torsionFree or something like that, so I can cut and paste labels?

Triangle before proof not correctly shown if `showmore` is enabled

TL;DR

In project PFR and alike, the triangle before a proof shows ▼/▶ for proof collapsing/expansion, which is the opposite of how one expects them, where ▼ should indicate proof expansion. Also, it's the opposite of project LTE.

Reported by @kbuzzard .

Details

What's expected

In LTE ( code, rendered ), showmore is NOT enabled, the triangle before proof is shown as ▼, and the proof is expanded by default, so ▼ indicates proof expansion correctly.

Afterward, clicking on the triangle works as expected, the triangle toggles between ▼ and ▶ , indicating the proof is expanded and collapsed, respectively.

image

What went wrong

In PFR ( code, rendered ), showmore is enabled, besides the eye +/- icons appear below and can control the level of details to show, by default, it collapses proofs, but the triangle before proof is still shown as ▼, so ▼ is not correctly corresponding to the proof collapsing status but the opposite.

image

Afterward, clicking on the triangle will never works as expected, it's always the opposite, unless one click on the eye +/- icon odd times, then this would be reversed and fixed.

Cause

The clicking of the triangle and the show more handles the triangle states separately, causing the confliction, plus they have different defaults.

Workaround

Don't enable showmore until this issue is fixed: In web.tex

Change the line like

\usepackage[showmore, dep_graph, project=../../]{blueprint}

to

\usepackage[dep_graph, project=../../]{blueprint}

Feature Request: Full Mathlibok Support

The command mathilbok exists, but there is no color customization for it.
It would be nice if the color (border and interior) could be configured via a latex command and if there would appear a link to the item in the mathlib when clicking on the node.

Error when `graphviz` is not installed (macOS)

I got the following error because graphviz or pygraphviz was not installed previously. It would be great if it could be added as a requirement and installed automatically when pip install leanblueprint. I'm using M2 MacBook Air with Sonoma 14.5, and this answer helped me to install it.

Building wheels for collected packages: pygraphviz
  Building wheel for pygraphviz (pyproject.toml) ... error
  error: subprocess-exited-with-error
  
  × Building wheel for pygraphviz (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [63 lines of output]
      running bdist_wheel
      running build
      running build_py
      creating build
      creating build/lib.macosx-14-arm64-cpython-310
      creating build/lib.macosx-14-arm64-cpython-310/pygraphviz
      copying pygraphviz/scraper.py -> build/lib.macosx-14-arm64-cpython-310/pygraphviz
      copying pygraphviz/graphviz.py -> build/lib.macosx-14-arm64-cpython-310/pygraphviz
      copying pygraphviz/__init__.py -> build/lib.macosx-14-arm64-cpython-310/pygraphviz
      copying pygraphviz/agraph.py -> build/lib.macosx-14-arm64-cpython-310/pygraphviz
      copying pygraphviz/testing.py -> build/lib.macosx-14-arm64-cpython-310/pygraphviz
      creating build/lib.macosx-14-arm64-cpython-310/pygraphviz/tests
      copying pygraphviz/tests/test_unicode.py -> build/lib.macosx-14-arm64-cpython-310/pygraphviz/tests
      copying pygraphviz/tests/test_scraper.py -> build/lib.macosx-14-arm64-cpython-310/pygraphviz/tests
      copying pygraphviz/tests/test_readwrite.py -> build/lib.macosx-14-arm64-cpython-310/pygraphviz/tests
      copying pygraphviz/tests/test_string.py -> build/lib.macosx-14-arm64-cpython-310/pygraphviz/tests
      copying pygraphviz/tests/__init__.py -> build/lib.macosx-14-arm64-cpython-310/pygraphviz/tests
      copying pygraphviz/tests/test_html.py -> build/lib.macosx-14-arm64-cpython-310/pygraphviz/tests
      copying pygraphviz/tests/test_node_attributes.py -> build/lib.macosx-14-arm64-cpython-310/pygraphviz/tests
      copying pygraphviz/tests/test_drawing.py -> build/lib.macosx-14-arm64-cpython-310/pygraphviz/tests
      copying pygraphviz/tests/test_repr_mimebundle.py -> build/lib.macosx-14-arm64-cpython-310/pygraphviz/tests
      copying pygraphviz/tests/test_subgraph.py -> build/lib.macosx-14-arm64-cpython-310/pygraphviz/tests
      copying pygraphviz/tests/test_close.py -> build/lib.macosx-14-arm64-cpython-310/pygraphviz/tests
      copying pygraphviz/tests/test_edge_attributes.py -> build/lib.macosx-14-arm64-cpython-310/pygraphviz/tests
      copying pygraphviz/tests/test_clear.py -> build/lib.macosx-14-arm64-cpython-310/pygraphviz/tests
      copying pygraphviz/tests/test_layout.py -> build/lib.macosx-14-arm64-cpython-310/pygraphviz/tests
      copying pygraphviz/tests/test_attribute_defaults.py -> build/lib.macosx-14-arm64-cpython-310/pygraphviz/tests
      copying pygraphviz/tests/test_graph.py -> build/lib.macosx-14-arm64-cpython-310/pygraphviz/tests
      running egg_info
      writing pygraphviz.egg-info/PKG-INFO
      writing dependency_links to pygraphviz.egg-info/dependency_links.txt
      writing top-level names to pygraphviz.egg-info/top_level.txt
      reading manifest file 'pygraphviz.egg-info/SOURCES.txt'
      reading manifest template 'MANIFEST.in'
      warning: no files found matching '*.swg'
      warning: no files found matching '*.png' under directory 'doc'
      warning: no files found matching '*.html' under directory 'doc'
      warning: no files found matching '*.txt' under directory 'doc'
      warning: no files found matching '*.css' under directory 'doc'
      warning: no previously-included files matching '*~' found anywhere in distribution
      warning: no previously-included files matching '*.pyc' found anywhere in distribution
      warning: no previously-included files matching '.svn' found anywhere in distribution
      no previously-included directories found matching 'doc/build'
      adding license file 'LICENSE'
      writing manifest file 'pygraphviz.egg-info/SOURCES.txt'
      copying pygraphviz/graphviz.i -> build/lib.macosx-14-arm64-cpython-310/pygraphviz
      copying pygraphviz/graphviz_wrap.c -> build/lib.macosx-14-arm64-cpython-310/pygraphviz
      running build_ext
      building 'pygraphviz._graphviz' extension
      creating build/temp.macosx-14-arm64-cpython-310
      creating build/temp.macosx-14-arm64-cpython-310/pygraphviz
      clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -I/opt/homebrew/opt/llvm/include -DSWIG_PYTHON_STRICT_BYTE_CHAR -I/opt/homebrew/opt/[email protected]/Frameworks/Python.framework/Versions/3.10/include/python3.10 -c pygraphviz/graphviz_wrap.c -o build/temp.macosx-14-arm64-cpython-310/pygraphviz/graphviz_wrap.o
      pygraphviz/graphviz_wrap.c:9:9: warning: 'SWIG_PYTHON_STRICT_BYTE_CHAR' macro redefined [-Wmacro-redefined]
      #define SWIG_PYTHON_STRICT_BYTE_CHAR
              ^
      <command line>:2:9: note: previous definition is here
      #define SWIG_PYTHON_STRICT_BYTE_CHAR 1
              ^
      pygraphviz/graphviz_wrap.c:3023:10: fatal error: 'graphviz/cgraph.h' file not found
      #include "graphviz/cgraph.h"
               ^~~~~~~~~~~~~~~~~~~
      1 warning and 1 error generated.
      error: command '/usr/bin/clang' failed with exit code 1
      [end of output]
  
  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for pygraphviz
Failed to build pygraphviz
ERROR: ERROR: Failed to build installable wheels for some pyproject.toml based projects (pygraphviz)

RFC: Absorb scattered functionalities back into leanblueprint

There is a common issue of the blueprint ecosystem, namely every project is using a slightly different setup with a few loosely coupled building blocks, in Python, in Github Actions workflows, in LaTeX etc. This issue is a RFC to absorb some if not all of them into leanblueprint.

Here is a potential list:

Existing inv tasks

Blueprint can provide a default implementation for the common tasks which are almost identical with trivial differences, and users can selectively import or improve them:

  • inv bp: builds the LaTeX to a PDF file, it also generates the .bbl file for the web version to have proper bibliography
  • inv web: builds the LaTeX to a website
  • inv decls: deprecated, it was for Lean 3, replaced by doc-gen4 declarations extraction which is non-trivial task to distill and maintain particularly because the implementation highly depends on the involving lake and the process is quite time-consuming to run
  • inv all: it depends on inv bp and inv web, some projects include copying of some of the products of previous tasks
  • inv dev: I use this and provided it to some projects, for auto-rebuilding the PDF and the website after each edit, the downside is if some LaTeX goes wrong, the user has to use X to exit LaTeX then restart inv dev which could be improved

Some potential tasks

  • inv create: it could set up an optimal Github Actions workflow with caches (there are some variants with longer CI time, due to the complexity of getting all of LaTeX, Python, Lean work in CI efficiently ), default blueprint directory layout with the correct project name, and dummy LaTeX macros, python dependencies, unlike now people copy setup from another project then change the project name, a potential issue of this is colliding with existing LaTeX code or Lean code, which could be mitigated by discovering the existing equivalent files and gives a warning/hint for the user to check manually -- not implemented as a inv task yet
  • inv check or inv lint: it checks the correspondence between the blueprint and the Lean code, in a loosely coupled way, it can check \leanok nodes against doc-gen4 declaration files (naively implemented in teorth/pfr#97 ), and check sorries in Lean code but marked \leanok in blueprint.

These are what I can think of for now. If there is a consensus on this, I can break them into smaller issues or PRs but unfortunately no promises on a timeline except hopefully not slower than the emergence of new formalization projects.

P.S. I'm motivated to do the work as keeping multiple projects running OK and fixing usability issues across them (with subtle differences) has become quite some overhead, also people are asking for project setup or instructions, and they develop their own variants of instructions for doing the same thing which has variants of caveats or inconveniences . If these functionalities are indeed absorbed into leanblueprint, it would be much easier to write documents for instructions.

P.P.S. I understand that there are possibly plans to rewrite or incorporate leanblueprint into the new Lean documentation system, but they are not an imminent future for the coming formalization projects, so a little investment into these tiny details of quality of life seems to be still worth the while.

Feature requests for more types of nodes and their behavior

Red node 🟥

Requested by @kbuzzard .

I would like to be able to make red nodes, which in the old days would show up as blue but were actually huge projects all disguised as one node. A red node means that LaTeX needs to be written and the node needs to be broken up into smaller nodes, and I want blue to mean "this node is ready to be tackled as a reasonable project, there is a either a clear citation or a good explanation in the LaTeX".

For the legend: I think I want red border to mean "the statement of this result needs to be broken down into smaller formalizable pieces; prerequisites may or may not be ready.

I want (theorems stated in Lean) to be green border and red "not ready to be worked on; waiting for Kevin" interior (as their proofs are not sorted out in blueprint).

This is now partially implemented by a maker named \tangled (for now) in my prototype.

More green node 🟢

Requested by @teorth on Zulip.

I wonder if there is a way to add an additional coloring to the dependency graph (maybe some sort of "really green") that indicates not only that a node has been locally formalized, but that all of the nodes it depends on transitively are also formalized? Right now for instance we are adding a few extensions to the PFR project, which has temporarily uglified our dependency graph, but it would be nice to tell at a glance that the original result PFR is still completely proven (or at least, that blueprint thinks that it is).

Not implemented yet, just filed this issue for follow up.

Feature requests that can be fulfilled using current implementation

Requested by @kbuzzard .

These are subtle details, documenting them in the hope that they will still be there:

A definition and a theorem together in one node, with different prerequisites of the statement and the proof.

An example is that the definition and the theorem are stated in Lean, so

I want it to be green border 🟢 and blue interior 🟦 . All prerequisites are done, data in definition is done, we just need some proofs filled in.

The solution is:

a. put the definition and the theorem in \begin{theorem} block, mark it with \leanok
b. put the proof sketch or an empty one in \begin{proof} block, mark it with some \uses, note that:

  • no \uses means not ready (white interior) ⚪
  • empty \uses{} means all ready (green interior) 🟢
  • \uses{A,B,C} depends on the readiness of A, B, and C (could be blue interior). 🟦
  • arrows of (prerequisites) of a node is the union of \uses in theorem and in proof, but the colors are determined separately, when all proof \uses are ready (at least stated), its interior turns blue, when all statement \uses are ready, its border turns blue.

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.