Coder Social home page Coder Social logo

boostorg / website-v2-docs Goto Github PK

View Code? Open in Web Editor NEW
6.0 13.0 22.0 2.59 MB

Boost Site Documentation

Home Page: https://docs.cppalliance.org

License: Boost Software License 1.0

Shell 4.78% JavaScript 34.44% CSS 49.09% Handlebars 7.45% HTML 4.24%
boost cplusplus libraries

website-v2-docs's Introduction

Antora Guide

Antora

This tool renders the documentation for Boost modules whose documentation use asciidoc.

Installing Antora

Caution
The workflow may change in the future.

Dependencies

Antora requires Node.js:

$ node -v

This command should return an active Node.js LTS version number:

v16.18.0

If you have Node.js installed, but it isn’t an active LTS version, you need to upgrade Node.js.

$ nvm install --lts

Install Antora

After cloning the project, you need to install Antora command line interface (CLI) and the Antora site generator describe in the package.json file:

$ npm ci

Verify the antora command is now available by running:

$ npx antora -v
@antora/cli: 3.1.2
@antora/site-generator: 3.1.2

You also have the option of installing Antora globally so that the antora command is available on your PATH.

$ npm i -g @antora/[email protected] @antora/[email protected]
$ antora -v
@antora/cli: 3.1.2
@antora/site-generator: 3.1.2

Read more about antora on their Quickstart guide

Generating the website

The website is composed of components defined in the content.sources field of its playbook file site.playbook.yml. To generate the develop version of the website, run the Antora command with the following options:

npx antora --fetch --attribute boost_version=develop --attribute boost_site_prefix=develop/ site.playbook.yml

This should build the website in build/develop/doc/.

Important

Notice the --attribute options. Instead of using the Antora versioning control system, we render the documentation for a single version. To achieve this, we use an Antora extension that let us render the playbook for a single documentation version via these attributes. By setting --attribute boost_version=develop, the Antora playbook will fetch the develop branch of each documentation component.

To simplify the process of setting these attributes, you should use the sitedoc.sh script. Let us generate the develop and master versions of the documentation:

./sitedoc.sh develop

or

./sitedoc.sh master
Site generation complete!
Open file:///home/user/path/to/antora/build/develop/doc in a browser to view your site.
Site generation complete!
Open file:///home/user/path/to/antora/build/doc in a browser to view your site.

Generating the library documentation

The process for generating the documentation for all libraries is similar. Each library documentation is defined as a component in the playbook file libs.playbook.yml:

content:
  sources:
  - url: https://github.com/cppalliance/user-guide
    start_path: antora
  - url: https://github.com/vinniefalco/mp11
    start_path: antora
  # ...

To simplify the process of setting attributes, you should use the libdoc.sh script:

./libdoc.sh develop
./libdoc.sh master
Site generation complete!
Open file:///home/user/path/to/antora/build/develop/libs/index.html in a browser to view your site.
Site generation complete!
Open file:///home/user/path/to/antora/build/master/libs/index.html in a browser to view your site.

The complete libdoc.sh command syntax is:

Usage: ./libdoc.sh { branch | version | 'release' | 'all' }...

    branch : 'develop' | 'master' | 'release'
    version: [0-9]+ '.' [0-9]+ '.' [0-9]+
    'release': builds master to build/doc/html
    'all': rebuilds develop, master, and every version

Examples:

    ./libdoc.sh develop master      # build develop and master
    ./libdoc.sh 1.83.0              # build tagged version boost-1.83.0

The first positional argument is the only parameter, which identifies which version should be built.

  • branch: valid arguments are master or develop. Builds the master or develop versions of the documentation in build/master/libs or build/develop/libs. It checks out all libraries in their master or develop branches.

  • version: a semver version, such as 1.82.0 describing a Boost version. This allows us to generate the documentation content of an old Boost version with the current version of the Antora UI.

  • 'release': generate the master version to build/doc/html with the release UI layout. This layout omits the header, Google analytics, and Edit this Page. This version of the documentation is meant to be distributed with sources files in the Boost release.

  • 'all': retroactively iterate and generate the documentation for all versions of Boost with the most recent Antora UI. This command iterates each playbook in the history directory.

The master/develop branches of the library documentation are designed to co-exist alongside the per-release documentation and thus the branch name (or release version) does appear in its URLs.

Working on a single component

Each Antora-enabled library includes the component version descriptor file antora/antora.yml. Each library should contain an antora.yml describing the component. For instance,

name: mp11
title: Boost.Mp11
version: ~
nav:
  - modules/ROOT/nav.adoc

By checking antora/antora.yml and the modules directory into git, the repository is identified as an Antora content source, which can be listed in libs.playbook.yml of this repository. When working locally on an individual component, it’s the developers responsibility to adjust and maintain a local playbook.

Adjusting the local playbook

To render the documentation locally using the local filesystem. Modify and include a local version of lib.playbook.yml as local.playbook.yml for your repository.

Boost library candidates

When writing a Boost library proposal, include your library in the local playbook. For instance, supposed you are proposing a boost library installed in the boost/libs directory:

- url: /boost/libs/proposed-lib
  start_path: antora

Boost libraries

When working on an existing Boost library, the url field cannot be set to /path/to/boost/libs/my_library because the subdirectories of boost/libs are submodules. Instead, change the URL for one or more content sources to point to the boost superproject and adjust the start path accordingly:

- url: /path/to/boost
  start_path: libs/existing-lib/antora

This local version will include your repository only. Run npx antora --fetch playbook.yml and similar antora commands described above to build the docs.

To Configure Antora Documentation to Remove Left-Side Navigation

This section explains how to to configure an Antora documentation site to remove left-side navigation.

The options are set in a playbook.yml file. For sitedocs documentation the file is website-v2-docs/site.playbook.yml. For library playbooks the file is website-v2-docs/libs.playbook.yml.

To remove the left-side navigation bar and instead include the table of contents (TOC) in the index.adoc page, include this yml code:

# Remove the sidenav and include a TOC in the index.adoc page
 remove-sidenav: ''

By default, the setting is disabled. Setting remove-sidenav to any string (including the empty string) enables it.

The setting applies to all components of the playbook. There is no option to enable/disable it for any specific component of the playbook.

website-v2-docs's People

Contributors

peterturcan avatar alandefreitas avatar vinniefalco avatar novoio avatar julioest avatar ashtum avatar sdarwin avatar cmazakas avatar rbbeeston avatar anarthal avatar d-spencer-strickland avatar louistatta avatar mborland avatar lastique avatar joaquintides avatar grafikrobot avatar

Stargazers

Ray Manaloto avatar  avatar  avatar Kenneth Reitz avatar Jack avatar  avatar

Watchers

Marshall Clow avatar  avatar  avatar Dmitry avatar  avatar  avatar  avatar Richard Hodges avatar  avatar  avatar  avatar  avatar  avatar

website-v2-docs's Issues

User's Guide: The History of Boost

There needs to be a chapter on the history of Boost which precisely chronicles its founding and goes into as much detail as possible describing Boost's evolution. Topics include:

  • Names and backgrounds of the founders
  • Noteworthy library additions (smart pointer) and authors (Peter Dimov, et. al.)
  • The migration from SVN / Trac to GitHub and GitHub Issues (and all the debates surrounding it) - we can link to select mailing list archive threads
  • Key decisions and controversies, such as cmake and deprecation of C++03
  • Boost's foray into conferences: BoostCon, which became C++Now
  • The build system (b2 / bjam)
  • Recent C++ Alliance involvement

We should screenshot select parts of the current website for posterity for example the original Get Boost button along with a credit and link to its creator (@grafikrobot )

image

User guide: usage example of header-only and compiled library

I think it may be worth to show how to consume libraries in the "getting started" guide. The old docs did something like this: https://www.boost.org/doc/libs/1_82_0/more/getting_started/unix-variants.html#id23.

I'd say the most popular way of consuming the libraries (at least on Linux) is via CMake, so I'd base the example on that (something really simple, a main.cpp and a CMakeLists.txt). That can be more useful (and looks more modern) than setting LD_LIBRARY_PATH and CPLUS_INCLUDE_PATH. I suggest using URL or JSON as the example library, since they don't need much setup (unlike Beast or MySQL), are fast to compile and implement interesting stuff.

Please note that using vcpkg or conan changes the way libraries are consumed IIRC (requires some additions to the CMakeLists.txt if I'm not mistaken) and thus may require separate usage examples.

Introduction: what do we have in Boost?

Which documentation does this apply to?
User's Guide

I think that the current introduction doesn't transmit the user why she should use Boost. For example:

Particular strengths of the Boost libraries include smart pointers, unit tests, lambda functions, function binding, regex, a file system, to name a few.

We already have all of this in the standard, so this is somehow contradicting the other arguments.

I'd say the table on library categories belongs to a reference section, rather to an introduction section, since it's ordered alphabetically and doesn't provide a way for the user to explore the libraries inside each category.

README workflow is missing gulp installation

Which documentation does this apply to?
Repo README

I followed the README and was getting this error

gulp is not installed
[21:55:56.110] FATAL (antora): Specified UI bundle does not exist: /home/ruben/workspace/site-docs/antora-ui/build/ui-bundle.zip (resolved from url: ./antora-ui/build

Solved by npm -g install gulp. Could gulp be added as dependency in package.json?

Contributor-Guide: Tips for Using CI

We need a section on how to use GHA, Drone, et. al. for Continuous Integration and especially on how to minimize the amount of resources used so that more targets can be tested. Boost authors and CPPA staff need to help with this... Peter Turcan cannot be expected to write this all on his own.

Missing libraries requiring compilation

Which documentation does this apply to?
User's Guide

The page user-guide/header-organization-compilation.html#_required_compiled_binaries lists all libraries allowing compilation, but it looks like some of them are missing.

There is an option to b2, ./b2 --show-libraries, that is worth mentioning in this page. It will show you which libraries can be built (useful to find out which --with-<lib> you can do. Here is the list I got from 1.82 in my Linux:

    - atomic
    - chrono
    - container
    - context
    - contract
    - coroutine
    - date_time
    - exception
    - fiber
    - filesystem
    - graph
    - graph_parallel
    - headers
    - iostreams
    - json
    - locale
    - log
    - math
    - mpi
    - nowide
    - program_options
    - python
    - random
    - regex
    - serialization
    - stacktrace
    - system
    - test
    - thread
    - timer
    - type_erasure
    - url
    - wave

Towards making candidate libraries testable in Compiler Explorer

This is more like an idea, as I do not have a concrete recipe for the moment.
The ultimate goal would be to have libraries that are candidates for inclusion into Boost, especially during the review period, to be testable in an online environment, such as Compiler Explorer.
This would enable the feedback from people who do not have time or capabilities to install a candidate library in their environments.
Potential reviewers are volunteers, have their private lives and they $dayjobs, and the review period is relatively short. They are often put off by the time it is required to perform a review. Writing the report is time consuming itself. Environment setup is an additional unnecessary effort.
Of course, library authors are also volunteers with similar constraints, so burdening them with the additional requirement is also not a good option.
But maybe Boost website could offer an instruction or scripts for making the online access to the testing environment easier. Maybe a hot line channel with Matt Godbolt? Something that would make it easy for library authors to install their library in the testing environment. Or something for the reviewers to do so. Or a server similar in spirit to Compiler Explorer where the candidate libraries can be tested. This would be useful not only during reviews. Official Boost libraries would also benefit from such online demos. This would help developers decide if they want to use Boost.

Adding a way to map boost symbols to their reference page

cppreference.com has some nice ways to map, lets say, std::vector to their doc pages. You have a symbol table and their old search engine. Both make it quite convenient to learn about a symbol youre seeing somewhere (not just as a human, but also for programs/web scrapers). Making it possible for bots to find a symbol and link against their documentation is a huge benefit for beginners that never really got into boost.

GHA for syntax checking

We could use a GitHub action that checks the syntax of the adoc files for errors or warnings

The 'Getting Started Doc' should review the presentation of package managers

Which documentation does this apply to?

User's Guide

The problem

These new Getting Started guides are often including sentences like:

using package managers (...) simplifies the installation of software packages

If you do not wish to use a package manager, (...)

I keep reading these kinds of statements there. The guides usually go on to present the package manager first rather than the official installation method. I think some content in those guides is biased toward the assumption that using a package manager is always better as a default. There's no consensus about that at all.

A small comparison

I'm not even sure it's always simpler. That's how you install brew+boost:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew install boost

And that's how you install the official boost package in a way where you can get whatever version you want, including the latest version:

curl -L "https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/boost_1_82_0.tar.gz" | tar -xz -C /tmp/
cd /tmp/boost_1_82_0/ && ./bootstrap.sh && ./b2 -j "$(nproc)" --prefix=/usr/local install

Copying and pasting any of these has basically the same cost. This difference is even more questionable on Windows, where there's no dominant system package manager.

The cons need to be listed

These package managers are the best option for many people in many cases, especially if they are already in their eco-system. They are also a good way to get started if they are not looking at any specific boost library that requires some boost version. And we should totally cover the existence of package managers in these guides.

However, the documentation should be neutral about which one is best and include appropriate admonitions to indicate the trade-offs. Package managers have their cons, and these are not listed in these guides. This can lead the user to end up making uninformed decisions based on these documents. Some things have to be clear about package managers when writing these guides:

  1. People need a standalone guide to create the packages in the first place.
  2. External packages are not officially maintained or supported
  3. The most important point in the context of these guides: Package managers are always a few or many versions behind and promoting these versions in this very guide is contradictory with our goals.

Docs as a reference for packages

First of all, if the docs don't present boost as something easily packageable more than something that has been packaged many times, this is a problem, because this is the documentation people creating packages are going to read.

If you use Linux or macOS, you already know you can apt-get anything slightly famous. You're probably reading this guide because you tried that and had some kind of problem. And if you use Windows, you are probably here because you know you're always out of luck regarding system package managers. choco is not quite there yet.

Docs as a reference for the supported methods

Regarding support, although packages are convenient, we don't officially provide support for these packages in any way, and by that I mean we don't test or even control what is in these packages. This should be a big warning admonition on all pages that mention package managers. It's a safety issue. It should even be in a ROOT/partial/package-manager-warning.adoc so it can be included in all sections about package managers.

Imagine you are a user trying to install Boost for the first time. You go to stack overflow or ask ChatGPT. They tell you to use a package manager and let's say the command it gave you fails. Maybe it gives you something that works now but we don't know if it's going to work in six months. How would you know all package managers will keep working without testing them? But that's OK because ChatGPT is allowed to fail. And SO answers often don't solve your problem.

But if the user follows the instructions in this very guide and it fails, that's a much bigger problem. Not only the quick uncaring method failed but the official method also failed. We have a responsibility here. If the very instructions coming from Boost fail, the user has only one possible conclusion: boost sucks. There's no hope even another package will work because that's where the instructions for packages come from.

Another situation we have to imagine is a user who tried using the package manager before getting to this page, which is also a common scenario. Or assume you want to use a boost feature and the version is too old because you used a package manager. OS and ChatGPT give you proper instructions to fix the problem. But you try the solution and it doesn't work for you because you used a package manager. You go to the website and read the instructions to get Boost from a package manager again. And it fails again. You're out of luck.

Docs as a reference for the latest version

But the most important problem is this: we're about to release boost 1.83, while brew provides boost 1.81 (release 6 months ago). But not that many users are on Macos anyway. Consider systems whose default repositories don't change because they're not external, which are the package managers most people will use: apt-get libboost-all-dev will get you Boost 1.65 (from 5 years ago!) in Ubuntu bionic, boost 1.71 (3 years ago) in Ubuntu focal, and Boost 1.74 (2.25 years ago) in Ubuntu jammy (the latest LTS). Let alone users who want to use boost master or develop.

These old versions of Boost are ok for their goals, which is to provide a system dependency that works with their other system dependencies, based on the assumption that only those versions of Boost are supported. From their POV, the best way to upgrade Boost is to upgrade the whose operating system. That's in conflict with our goals, which is to promote the most recent version of Boost for new applications.

Incentivizing users to use such old versions of Boost is detrimental to Boost itself and contradictory with the purpose of a getting started guide that comes from Boost. Imagine we promote a new version of boost on twitter and the big selling point is that it now includes the boost.mysql library. Users on all kinds of platforms follow the instructions in this guide and no boost.mysql. This is going against the goals of anything we are promoting.

Package managers and modularization

Two notable exceptions regarding the last point about versions are vcpkg and conan. Because they are C++ package managers rather than system package managers, the versions of boost they provide are not stuck in the past to maintain compatibility with some systems. They want the opposite of that. They are also in competition, which gives them the incentive to keep updating it.

Although this might change, vcpkg always has a recent version of boost. Their latest commit to the boost port is from two weeks ago. conan also has reasonably recent versions, although usually a little bit behind. Their latest version is 1.81. But most importantly, in the case of vcpkg, it actually achieves something the official method doesn't, which is modularization. This is one of the biggest complaints about boost and a good reason to list it.

There are some other official modularization methods, like boostorg/boostdep and some ways of integrating with cmake. This should be documented at some point but the official methods are currently less convenient than vcpkg.

Tentative initial guidelines

So, in conclusion, there must be some warnings and some constraints on how package managers are presented and which package managers are presented. These are some initial guidelines I would consider:

  • Guides coming from boost cannot have the assumption that using a package manager is always a better default method to install boost, because there's no consensus at all on that.
  • The default and supported methods are b2 and cmake. Although the limitations from boostorg/cmake should be disclaimed or handled (the specifics are being discussed in parallel in #17)
  • A package manager can never be presented as the default way of installing boost
  • Whenever a package manager is presented, an admonition with the disclaimer about support should be included from partials
  • Some package managers are more important than others in the context of these guides (this list is not exclusive):
    • package managers that only provide very old versions of boost are less important or should be discarded
    • system package managers of which more than 90% of users are already aware are less important
    • package managers providing modularized libraries are more important as this is a recurrent complaint

Provide instructions for dynamic libraries

The contributor guide should provide instructions for dynamic libraries.

The information about what libraries should support are here

https://www.boost.org/doc/libs/master/libs/config/doc/html/boost_config/boost_macro_reference.html#boost_config.boost_macro_reference.macros_for_libraries_with_separate_source_code.macros_controlling_shared_library_symbol_visibility

and here

https://www.boost.org/doc/libs/master/libs/config/doc/html/boost_config/boost_macro_reference.html#boost_config.boost_macro_reference.macros_for_libraries_with_separate_source_code.automatic_library_selection

One important thing to note is this needs to be properly tested (gcc, msvc, mingw, clang-cl, ...) or the probability that a blind untested implementation is not going to work is close to 100%.

Introduction: phrasing of advantages of Boost

Which documentation does this apply to?
User's Guide

Some Boost libraries can be referenced from Python.

What does this mean? Is it referring to Boost.Python? Are there Python bindings for other Boost libraries that I'm not aware of?

Boost libraries are peer reviewed, well designed, and extensively tested.

I think this should be the first bullet point.

Of lower priority is readability and compile times.

I'd be scared as a user to read this.

Getting started guide should mention dependency cycles

This page has very useful information on dependency cycles: https://grafikrobot.github.io/boost_lib_stats/

Many people seem to think you can't download and install individual libraries because boost has dependency cycles but this is no longer the case since boost 1.77.

This information should be included as an admonition in the "individual modules" section of the "getting started" page.

That page also has a somewhat useful popularity metric we can use to guide us when writing about use cases. We have to take that with a grain of salt though because it's only based on GitHub "watchers", "forks", and "stars". A better measure would probably be just shallow cloning the top X (say 10000) C++ projects with the most stars (some other metric (?)) and checking what boost libraries they are using:

API_URL="https://api.github.com/search/repositories?q=language:C++&sort=stars&order=desc&per_page=10000"
REPO_URLS=$(curl -s "$API_URL" | jq -r '.items[].clone_url')
for URL in $REPO_URLS; do
    git clone --depth 1 "$URL"
done

Getting started with Linux, installing from source, typos/corrections

Which documentation does this apply to?
User's Guide

  • Steps as are written right now don't allow for copying code, and don't stand out - I'd move them to be code blocks.
  • The wget command has two extra surrounding backticks that makes the command invalid
  • The URL is wrong (https://boostorg.jfrog.io/artifactory/main/release/1.77.0/source/boost_1_82_0.tar.bz2) - should be 1.82 in both parts of the URL
  • Do people really use CPLUS_INCLUDE_PATH as of today? Seems like a way to get non-reproducible builds. I've learnt this variable is a thing today.

Header-only vs. compiled libraries, library compilation selection

I'm think we're missing a mention of "header only vs. compiled libraries" in the discussion part (maybe in the introduction or the getting started, without having to scan through all of user-guide/header-organization-compilation.html.

We're also missing how to use --with-<lib>, which can alleviate compile times if you're not using all libraries.

The size of heading tags are not proportional

I'm no designer but the size of heading tags is not always smaller or not even differentiated sometimes when we go from h2 to h3, etc... Sometimes I look at the navbar just to find out at what level a section heading is.

For instance, it looks like an h2 section heading is smaller than an h3 section heading:

image

Examples in getting-started

Which documentation does this apply to?
User's Guide

We're using lambda (which will ring a bell of "we already have this in the language", something we're trying to flee from) and iostreams (which we all love). We need a different example.

I propose jumping directly to URL or JSON (even if they're compiled), and provide a note on how to link against header-only libs later.

The current JSON example may be problematic, since it relies on another helper header, and this is not explained.

Advanced Scenarios > High-Performance Database Engine lists client libs

Which documentation does this apply to?
User's Guide

Advanced Scenarios > High-Performance Database Engine lists Boost.Redis and Boost.MySQL, but these are client libraries - they are used from within the client program to interact with a server that is already built. These make sense for a HTTP server, but not for a database engine.

Missing points in Organization Requirements

Which documentation does this apply to?
(Contributor's Guide)

I've recently integrated Boost.Redis into Boost. I've been following https://docs.cppalliance.org/contributor-guide/requirements/organization-requirements.html along to help the process (it's almost worked perfectly, so nice job :)). I've noticed a couple missing points though:

  • It should mention that a root-level CMakeLists.txt, with a certain structure, is required. This is documented here, so there's probably no need to replicate it, but just link to it.
  • Almost all new libraries now use a test/cmake_test folder with a certain structure. I've noticed this is not documented in the source above (it should be this point, but it's in TBC.
  • Building documentation talks about the boostdoc target, but not about the boostrelease target, which is the one most new libs use. This target is intended for libraries building HTML documentation, and should generate HTML docs and place them under doc/html. I don't know the exact details about the interaction of the two - maybe asking Peter or someone more experienced can be useful.
  • The library metadata section says that the meta/libraries.json is optional, but the organization requirements section says it's mandatory. It's mandatory.

User guide New Issue

Which documentation does this apply to?
User's Guide

Feedback on the libraries, or any aspect of the documentation, is encouraged, and is available by creating a [New Issue](https://github.com/cppalliance/site-docs/issues).

It looks like I should open an issue against this repository regardless of what library I'm using. I think we should clarify that this repo is for the documentation only, and that if you found a bug in a library, open the issue against the library's repository.

Library naming is presented as generic but is Windows-specific

Which documentation does this apply to?
User's Guide

This is what you get in Linux when running b2 --with-json install:

<BOOST_ROOT>/lib $ ls | grep json
libboost_json.a
libboost_json.so
libboost_json.so.1.82.0

Which doesn't match the scheme presented in user-guide/library-naming.html

FAQ

There is a list of questions people have about Boost. Often these questions take the form of criticisms, because people don't understand the reasons for why Boost maintainers do things one way and not the other. There should be a FAQ page where these questions are answered and criticisms are addressed.

Correct a misspell

image

In the User Guide Introduction section, the word "Dependant" should be changed to "Dependent".

Common Scenarios > Networking improvement suggestions

Applies to User Guide.

  • Having Boost.Thread, Boost.SmartPtr and Boost.Test there feels strange. These are general-purpose facilities, not specific to networking.
  • I'd add Boost.URL and Boost.JSON (since URLs and JSON are pretty common in networking).

Getting started - Linux distributions

Which documentation does this apply to?
User's Guide

All Linux documentation on how to get started is Ubuntu/Debian specific. We should cover some other major distros like Fedora or CentOS, that do not use apt.

UI: Navigation / ToC should scroll on its own

The left side table of contents should not scroll with the page. It needs its own scroll bar and it should stay put when you scroll the page. Only if you use the interior scrollbar attached to the left nav should it scroll.

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.