clangbuiltlinux / llvm-distributors-conf-2021 Goto Github PK
View Code? Open in Web Editor NEWA day of lightning talks for folks who distribute and release builds of LLVM, with a focus on configuration, testing, and unique constraints.
A day of lightning talks for folks who distribute and release builds of LLVM, with a focus on configuration, testing, and unique constraints.
Building LLVM at rev.ng: a report
Alessandro Di Federico ([email protected]), rev.ng
Filippo Cremonese ([email protected]), rev.ng
We build and distribute LLVM both for development purposes (sort of an SDK) and as a library for our application.
At rev.ng we're building a LLVM-based decompiler with Qt UI.
Our development environment is Linux-only.
We build and distribute LLVM as:
Our own package manager, orchestra, produces binaries that can be used by end-users and developers.
Thanks to RPATH magic, all of our binaries are portable (run them from your $HOME
) and do not require root to be installed.
Also, since we build and link against an ancient glibc, the binaries can run on distributions as old as Debian 7, despite being built on modern systems.
We build LLVM in debug -O0
, debug -O2
, debug + ASan and release.
We'd like to report (and hopefully get feedback) on issues we regularly face when building LLVM:
Struggles and workarounds in building (and cross-building) recent and ancient packages using an clang/libc++ based toolchain.
Swift on Windows
Saleem Abdulrasool [email protected]
A LLVM based toolchain meant to target Windows (X86, X64, ARM, ARM64), Android (X86, X64, ARM, ARM64) for C, C++, [Objective-C, Objective-C++,], Swift.
TODO
The distribution tries to be nearly hermetic (LLVM is not yet sufficient for this for Windows), with coverage for C/C++/Swift in a single toolchain that is meant to target multiple platforms from Windows. The distribution includes all the tools for cross-compiling C/C++/Swift on Windows to Windows and non-Windows targets, as well as components to serve an IDE experience (e.g. language server, indexing, package manager, etc).
The distribution contains significant divergence from upstream including support for an entire language ecosystem. Additionally, the distribution contains support libraries for the ecosystem. The toolchain actually must integrate with MSVC distributed components and bridge content from Microsoft vended toolchains into the custom toolchain.
Reducing build time, complexity, binary size. A current installed toolchain is ~2.5 GiB without debug info. With debug info, a distribution is ~10 GiB. This excludes the language runtime.
Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.
Android's Dream of a Stable Toolchain
Pirama Arumuga Nainar, [email protected], Google
Stephen Hines, [email protected], Google (@stephenhines)
AOSP LLVM toolchain is used to build the Android platform, the Android kernel and host tools (LLDB server, OpenJDK, adb etc). It also ships with Android Studio and NDK to build native applications.
Our distribution of LLVM supports Linux, MacOS and Windows and uses tools from LLVM ecosystem (lld, compiler-rt builtins, libc++) whenever possible.
In this talk, we'll briefly discuss the distribution (components, build options etc) first and then focus on some operational challenges we face:
We don't track an LLVM release but follow LLVM ToT closely. (This also applies to other toolchain maintainers within Google).
Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.
I work with a few teams at Google who ship LLVM-based toolchains to both Google and open-source developers. All of these toolchains have custom pipelines designed to generate PGO profiles, which, when applied to the toolchain, make compiling and linking roughly 10-20% faster.
I'd be more than happy to give a lightning talk going over:
I think this information would be useful and interesting to distributors who are interested in shipping PGO'ed toolchains, but who currently choose not to do so. Bonus points if it starts conversations of the form "we'd do PGO if only we had $X
feature," where $X
isn't terribly difficult to implement and land upstream. ;)
please click subscribe in the bottom right to subscribe for updates.
LLVM-MinGW
Martin Storsjö, [email protected], No affiliation
A packaging of LLVM together with MinGW headers/libraries, usable both as native and cross compiler for targeting Windows on X86 and ARM. Available at https://github.com/mstorsjo/llvm-mingw.
LLVM-MinGW is a freely redistributable toolchain consisting of Clang, LLD and the other binutils replacements, together with MinGW headers and libraries.
MinGW, short for Minimalistic GNU for Windows, consists of a set of freely redistributable (reimplemented from scratch) GCC compatible platform headers, link libraries and a small set of (statically linked) extra compatibility functions. It's traditionally used with GCC and binutils and libstdc++, and it uses the Itanium C++ ABI contrary to MSVC. It produces native Windows executables, not reliant on any extra runtime (contrary to Cygwin).
Clang and the LLVM tools can impersonate both GCC/MinGW and MSVC.
Clang, LLD and the other LLVM provided tools work fine as drop-ins in an existing MinGW environment, but LLVM-MinGW is a toolchain bootstrapped from scratch using only LLVM tools, and using compiler-rt/libc++/libc++abi/libunwind instead of libgcc and libstdc++.
The toolchain originated from a desire to target Windows on ARM; GCC and binutils don't support Windows on ARM (nor ARM64), thus none of those tools could be used. It serves as something of a reference example of a fully LLVM based MinGW configuration, while the MSYS2 project now also provides such environments (with a different setup).
The toolchain tries to provide tools in the same way as a GCC/binutils based MinGW toolchain, to allow building e.g. most autotools based projects with a simple ./configure --host=aarch64-w64-mingw32
.
Windows, as a target environment, is a bit different from most other targets, by there being two fairly different environments (MSVC vs MinGW) with bigger or smaller differences along pretty much every single level of the stack.
Fun fact: The toolchain was developed while actually implementing the support in LLVM/LLD for targeting Windows on ARM64, and the toolchain was used for building a demo app (VLC) that was showcased when Microsoft presented Windows on ARM64 for developers.
The ups and downs of cross compilation and cross testing, how one can get fairly decent testing and QA on commodity hardware without a budget. Staying at top-of-tree without out of tree patches has been a good strategy.
Due to timezones (I'm based in Europe), I'm practically only able to present between 09.00 and 14.00 PDT (with 11.30 to 14.00 PDT being more ideal).
Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.
cc @gburgessiv @serge-sans-paille @aleclearmind @berolinux @pirama-arumuga-nainar @zmodem @aaupov @hyp @petrhosek @skganesan @tstellar @smithp35 @mstorsjo @compnerd @Ericson2314 @carlocab @RoboTux
Hi speakers, thanks for taking the time to submit a CFP; we look forward to all of your talks. Let's use this issue to discuss issues or questions for speakers. You can also email me [email protected], chat on the LLVM discord in #clang-built-linux, or #clangbuiltlinux on IRC on Libera.
I've published a tentative schedule, please take a look and let me know if you'd like to move your talk earlier or later. We probably wont be able to accommodate all requests.
I'm hoping that speakers can join up to 1 hr before the doors open to test your setup; I think the room has a 200 person limit, and I can't save spaces. I don't know if that will be a problem, but the speakers should join before the conference starts to ensure they're able to join. I'll publish the room link soon.
Questions?
Snapdragon LLVM Toolchain
Sivakumar Ganesan, [email protected], Qualcomm Innovation Center
Snapdragon LLVM Compiler Toolchain is distributed for building Android NDK and Bare metal images
Snapdragon LLVM Compiler Toolchain, which is available for Android NDK and Bare metal images, enables use of compilers in a broader range of configurations, providing performance and code size advantage particularly on Qualcomm Snapdragon micro-architectures. Snapdragon LLVM compiler has provided performance gains to a variety of Android applications and libraries.
This talk will discuss on how Snapdragon LLVM compiler manages to stay close to the upstream HEAD and challenges faced during the distribution process
There are a wide range of challenges that we face when trying to distribute the toolchain. Some of those challenges include the following issues that are seen with upstream patches:
Another distribution challenge that we encounter is with the LLVM toolchain version that Android AOSP builds come with. New AOSP drops at times use a different LLVM upstream toolchain version resulting in build issues because of mismatch between upstream LLVM compiler and Snapdragon LLVM
Anything that makes the HEAD revision more stable: for instance, enforcing precheckin verification for each commit, means to determine dependent patches etc.
Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.
Graphcore IPU LLVM toolchain & libraries
Thomas Preud'homme [email protected] (Graphcore)
LLVM toolchain and toolchain libraries for the Graphcore IPU
Developing AI models for the Graphcore IPU is done using the Poplar SDK which relies on LLVM libraries as well as a firmware compiled using a LLVM toolchain. The Toolchain team at Graphcore provides a distribution of those components with an entirely new backend and a custom C library for other internal teams and customers' consumption.
Providing the best platform for the fast evolving AI ecosystem comes with some challenge:
Our target architecture has a fast evolving specification with an entirely downstream support. We also have two separate sets of users: one that use the LLVM toolchain and another one which integrate LLVM libraries into a development framework distributed to customers. Finally, the Graphcore IPU follows the ongoing freestanding proposal which libc++ does not support yet.
Graphcore IPU LLVM backend is downstream-only and has tablegen files generated from the ISA documentation. It also features a SelectionDAG unit testing mechanism and has a very simple C runtime.
Keeping more target-specific code in target-specific files is a relatively easy endeavour that would make merging from upstream easier for downstream targets. A more important effort would be to have a mechanism to inform people of non-breaking changes that both downstream and upstream code owner might take advantage of, such as new SDNode that could do with new lowering code. Finally, support for the ongoing freestanding C++ proposal would help us greatly but would require a significant ongoing effort to maintain.
Clang vendor options: control new Clang and LLVM changes in a release
Alex Lorenz, [email protected] / [email protected], Apple
Apple's Xcode toolchain, used to build Apple's operating systems like iOS and macOS, and also by the App Store developers
Clang and LLVM are constantly improving and are getting 100s of commits per week! Benefiting from all these changes in existing projects comes with unique challenges, for example, the existing code might not be compatible with newly added errors and warnings.
This talk presents clang vendor options and vendor flags. They can be used to selectively control how new Clang and LLVM changes are enabled. For example, a downstream vendor can use them to disable certain new features and/or diagnostics, to ensure that their compiler can continue compiling their existing code, while waiting for the software changes needed to fix the build failures caused by the new compiler changes. They can also be applied selectively to a subset of the user code. The new vendor options allow Apple’s clang team to test the main-tracking branch of Apple Clang on a continuous basis, and also simplifies the process of creating and managing new release branches.
Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.
The LLVM embedded toolchain for Arm
Peter Smith, [email protected] Arm
A LLVM based toolchain for bare-metal embedded systems, initially focused on Cortex-M devices.
For many years the GNU Arm Embedded toolchain has provided an open-source toolchain targeting embedded systems. The LLVM Embedded toolchain for Arm is a new open-source project with the goal of providing an LLVM based equivalent to the GNU Embedded toolchain. We would like the LLVM Embedded toolchain to lower the bar to entry of using LLVM in Embedded systems development. The project itself is a set of build scripts that combines tools and libraries from the llvm-project with the Newlib C-library to build the Toolchain from source. With the sample linker scripts it is simple to build and run a simple example that runs on the QEMU emulator. We have used, with a small enhancement, clang config files to approximate multilib and specs files for some hardware configurations. While sufficient for simple examples this will not scale well to the amount of Arm platforms that the GNU Arm Embedded Toolchain is able to support.
The toolchain targets resource constrained devices in a freestanding environment. Targets need builds of libraries and custom linker scripts to match the memory model of the end device.
Packaging the LLVM tools and libraries with the newlib C library, with some built in configurations for common Cortex-M devices.
Using configuration files in anger.
Using the bare-metal driver.
Integrating newlib
Some areas that the toolchain needs to improve that we'd like to work with the community on.
Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.
LLVM Runtimes Build
Petr Hosek, [email protected], Google
While building Clang and LLVM tools is a simple and straightforward process, building a complete cross-compilation toolchain, that is, a toolchain that supports a number of different targets, can be a complicated endeavor that often involves custom scripts and infrastructure.
In particular, building LLVM runtimes like libc++ or compiler-rt can be especially challenging because runtimes have to be built with the just-built compiler for the target platform and cross-compiling these runtimes often requires custom build scripts to handle subtle bootstrap ordering issues.
In this talk, we are going to cover the LLVM runtimes build which was designed to simplify this process and allows building a complete LLVM-based cross-compiling toolchain with a single CMake invocation.
The LLVM runtimes build is already being used by a number of vendors and we hope that in the future it might become the default way of building LLVM-based toolchain distributions. If you are interested in using runtimes build, in this talk I hope to give you enough information to get you started.
Homebrew LLVM
Carlo Cabrera, [email protected]
Homebrew is a package manager for macOS and Linux. We package LLVM for use by other packages that rely on it, and as an alternative toolchain for our users, who would otherwise be using their system compiler, or Homebrew GCC.
We aim to provide a complete LLVM distribution that is easy to understand for end-users, doesn't interfere with system installations (i.e. Apple LLVM), and is maintainable by our small team (~25 maintainers for a repository of ~6000 packages).
In this talk, I will present how we configure and test our LLVM build: what we do well, what we could do better, and what we struggle with.
The packaging constraints alluded to above.
We seem to have this in common with some of the other submissions, but our distribution is:
How to do a full PGO bootstrap build on macOS.
ABI versioning for libLLVM
on macOS.
Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.
LLVM in OpenMandriva: packages that still need GCC, -fgnuc-version=11.2 and other "fun"
Bernhard Rosenkraenzer, [email protected], OpenMandriva
OpenMandriva is the first Linux distribution that made LLVM/Clang its main compiler. It is used to build almost all of our packages (both main and unsupported) - but we don't consider export CC=gcc; export CXX=g++
a complete taboo.
OpenMandriva is the first Linux distribution that made LLVM/Clang its main compiler. It is used to build almost all of our packages (both main and unsupported) - but we don't consider export CC=gcc; export CXX=g++
a complete taboo. This talk gives a quick overview of where we still have to resort to this, why we still use libstdc++ rather than libc++ and other blockers for a 100% LLVM toolchain.
It also explains why we change the default -fgnuc-version value to 11.2 and what we need to change there.
First Linux distribution that uses LLVM/Clang as its main compiler, use of -fgnuc-version=11.2
Crosscompiling support built in for everything, -fgnuc-version=11.2
What still needs to be done to get to a 100% LLVM distro and more
More help for not so experienced packagers who report "MyFavoriteApp 1.1 works great with gcc but crashes with clang. Obviously clang is to blame and needs to be fixed, let's switch back to gcc!" type "bugs" -- There's currently no really good place for newbie packagers to turn to for help. Also, a patch exchange for the couple of packages where upstream maintainers insist on not supporting clang could result in less duplicated work.
Fedora / Red Hat LLVM Toolchain
Tom Stellard, [email protected], Red Hat
LLVM and various sub-projects packaged for Fedora Linux and Red Hat Enterprise Linux
We provide LLVM packages for both Fedora Linux and Red Hat Enterprise Linux. Our goal it to provide up-to-date LLVM packages that integrate well with the rest of the distribution. We support both the toolchain and library for users within the distribution (i.e. other packages) and for end users as well.
In this presentation we will look at the process of building an LLVM package, from sources to all the way to RPMs in the dnf repos, and discuss some of the unique challenges we face packaging LLVM for a general purpose distribution.
We have a number of distribution-wide rules for packaging, like shared library requirements, hardening flags, standard install paths, etc. that put constraints on how we can package LLVM.
We do 'stand-alone' builds of the LLVM sub-projects, which means that we build each sub-project separately rather than building them all together from the monorepo sources. We also require other packages (including other LLVM sub-projects) that ship in Fedora and Red Hat Enterprise Linux to use the LLVM dynamic libraries instead of the static ones.
How to package LLVM for a Linux distribution.
More stable and/or smaller APIs for the LLVM libraries.
Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.
Fuchsia Clang Toolchain
Petr Hosek, [email protected], Google
Fuchsia's Clang toolchain is used to build the Fuchsia platform, the Zircon kernel and host tools.
The Fuchsia Clang toolchain is a complete C/C++ toolchain distribution that supports Fuchsia, Linux, macOS and Windows and includes a number of LLVM tools and runtime libraries.
It is used by Fuchsia to build the system that powers millions of devices, as well as other related projects such as Pigweed, Dart and Flutter.
In this talk, we will cover our toolchain distribution, how we build it, test it and distribute it to all our developers. We will also talk about our principles and discuss some of the challenges we face.
We ship a complete, general purpose LLVM-based toolchain for C/C++. We use this toolchain to build an entire operating system that was developed from scratch and includes everything from bootloader, kernel, system libraries all the way up to user applications.
We currently support four host platforms:
We currently support nine target platforms:
Our goal is to provide the same experience on every supported platform and we achieve that by using LLVM tools and libraries making our toolchain completely self-contained.
We follow the "live at HEAD" model and stay close to the tip-of-tree. We release new toolchains on a weekly cadence and we adopt new features at a rapid pace.
We rely extensively on automation. We continuously build toolchains and use every newly produced toolchain to build and test the entire system. This automation is what makes it feasible to "live at HEAD" and roll so frequently.
Everything we use, including the CMake cache files, is upstream and we do not have any downstream changes so anyone should be able to reproduce our toolchain build.
How to build an LLVM-based cross-compiling toolchain with a single CMake invocation.
Support for cross-platform testing in lit which will be important for us to run tests on Fuchsia.
Automated way to report downstream test results since it is infeasible for us to cover every build configuration through upstream testing.
Building, Testing, and Distributing Chromium's C++ Toolchain
Hans Wennborg, [email protected], Google
Chromium's C++ toolchain, used to build Chromium and Chromium-derived web browsers.
Chromium uses an LLVM-based C++ toolchain to build the browser for all its supported platforms. This talk covers how we build the toolchain for best performance, test it to be confident it works, and distribute it to all our developers and infrastructure. In particular, it covers how we manage to stay so close to the HEAD revision.
Many host and target platforms: Windows, Mac, Linux, Android, iOS, Fuchsia
Living at HEAD: rigorous CI, shipping a new toolchain semi-weekly, no local patches, your LLVM commit can be used to build tomorrow's shipping canary version of the browser
Not a general-purpose toolchain release: building Chromium is the supported use case
Lots of upstream contributions to support our needs: clang-cl, the new lld; and things which are possible when controlling the whole toolchain such as constructor type homing, global type hashing for PDBs, etc.
Anything that makes the HEAD revision more stable.
Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.
Switching to LLVM based toolchains in Yocto based distributions
Bernhard Rosenkraenzer, [email protected], Huawei Open Source Technology Center
Yet unnamed embedded distribution (current working title: All Scenarios OS)
The Huawei Open Source Technology Center is working on a new distribution for embedded devices, using the Linux kernel for higher end devices and the Zephyr kernel for the low end.
Like many embedded distributions, it is based on Yocto - but unlike most others, it uses LLVM/Clang as its primary toolchain.
The talk shows how it can be done, and goes over some issues currently in the way.
Multi-kernel, multi-architecture embedded distribution using clang as its primary compiler
Crosscompiling with a Yocto based build system
How to use clang in a Yocto/OpenEmbedded environment
More help for not so experienced packagers who report "MyFavoriteApp 1.1 works great with gcc but crashes with clang. Obviously clang is to blame and needs to be fixed, let's switch back to gcc!" type "bugs" -- There's currently no really good place for newbie packages to turn to for help.
Optimizing Clang with BOLT
Amir Ayupov, [email protected], Facebook
https://github.com/facebookincubator/BOLT/blob/main/bolt/docs/OptimizingClang.md
BOLT (Binary Optimization and Layout Tool) is designed to improve the application performance by laying out code in a manner that helps CPU better utilize its caching and branch predicting resources.
The most obvious candidates for BOLT optimizations are programs that suffer from many instruction cache and iTLB misses, such as large applications measuring over hundreds of megabytes in size. However, medium-sized programs can benefit too. Clang, one of the most popular open-source C/C++ compilers, is a good example of the latter. Its code size could easily be in the order of tens of megabytes. Clang executable suffers from many instruction cache misses and can be significantly improved with BOLT, even on top of profile-guided and link-time optimizations.
How to apply BOLT optimizations to make Clang up to 15% faster on top of PGO and LTO.
We're working on preparing BOLT for inclusion into LLVM monorepo as a subproject, and upstreaming BOLT-specific patches is a major part of the effort. Engagement and productive collaboration with reviewers, maintainers and other interested parties on upstreaming reviews is critical for the success.
Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.
LLVM integration test suite
[email protected] sylvestre@{debian.org,ubuntu.org}
Fedora, Debian/Ubuntu
Both Fedora and Debian have the ability to gate their package through a test-suite. In the case of the LLVM compiler infrastructure, it basically means making sure that all components are properly integrated into a working toolchain that also interacts correctly with other toolchain's component. We also see this testsuite as a forcing function to bring consistency to LLVM packaging.
We shared our test cases and ended up with a collaborative repo for these test, unimaginatively named https://github.com/opencollab/llvm-toolchain-integration-test-suite with the secret agenda to integrate it at some point in the LLVM project itself.
The kind of errors we detected early, an interest to use and contribute to the test suite.
LLVM toolchains in Nixpkgs
John Ericson, [email protected], Obsidian Systems
Nixpkgs is best known the package set behind the NixOS Linux distribution, but also runs on macOS, and arbitrary cross compilation. LLVM is used on macOS by default, and may be used for any platform; recently we've added a pkgsLLVM
to encourage LLVM use in more contexts.
About 5 years ago, we in the Nix community set out to be one of the few distros/package sets to support whole-system cross compilation, meaning not just providing cross toolchains, but also building arbitrary packages. Overhauling our infrastructure to do this, we found that the packaging of compilers was the keystone upon which many of our out decisions rested. To cut down complexity, we decided to strive for a few related polices:
LLVM has easily been the compiler most amendable to re-package according to these principles. We want to highlight what has gone well, the current state of the LLVM packaging in Nixpkgs, and what we are trying to get upstreamed into LLVM next.
Very open-world goals --- Nixpkgs aims to be the "universal" package set, running or cross compiling everywhere possible. All the other cross compilation targets being discussed --- we're listening and want to support your platform too, no matter how exotic!
Very fine-grained, with all runtime libraries and tools being built separately, and installed in separate prefixes.
Techniques to manage many configurations / bootstraps without drowning in complexity.
(obligatory plug :)) Of course, you may find like we do that Nixpkgs a great foundation with which to develop toolchains and push them to their limits, and want to just use Nixpkgs rather than borrow our techniques.
DESTDIR
or manual separation.-B
/-resource-dir
division of labor a fresh review.@sternenseemann just let me know about this conference, which I am quite grateful for as I've long hoped for a venue like this to discuss our work, and may have more information to provide about pkgsLLVM
. I imagine our experience chasing after stray build failures in arbitrary packages using LLVM might also be of interest. If I had figured everything out earlier, I would have written the above knowing the answer of whether he had information to add, but as the deadlines looms I figured I better get something up ASAP. Sorry!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.