Giter Club home page Giter Club logo

rustbuild's Introduction

RustBuild Twitter URL

Discontinued! ARM compatible libraries are now part of the standard build process for Rust. They can be downloaded here. Directions related to cross compiling can be found at rust-cross.

If you would like to compile your own version of rustc and rustlib on your ARM device, you can refer to petevine's fork.

Scripts and patches to auto build Rust and Cargo on an ARM machine

Unofficial build scripts and binaries for nightly Rust/Cargo on 'arm-unknown-linux-gnueabihf'

This repository contains the required setup/configuration/build scripts and patches for you to setup your own Rust compilation machine. Pre-built 'unofficial' Rust/Cargo binaries are listed below for those who do not want to run their own build machine or are unable to.

Binary Downloads

For those familiar with Jorge Aparicio's ruststrap project; the ARMv6 builds are incredibly similar to his documented process. They're built in a Raspbian container with glibc 2.13 and Clang 3.7. This means that they're compatible with ARMv6-armhf systems and up (Thanks to the requirement by ARM, that all newer ARM architectures are required to recognize and run old ARM architectures). So anyone with a Raspberry Pi running the Wheezy distribution of Raspbian should use those, even if it's the ARMv7 Raspberry Pi 2. However, if the Raspberry Pi 2 is running the newer Jessie distribution of Raspbian, that should be able to run the ARMv7 binaries as it meets the requirement of glibc >= 2.19.

Linking Service

I'm now running a simple linking service to direct to the latest versions available for download without having to go directly to dropbox. The repository links below will still work. However the new links are more convienient as they will update every 12 hours to point to the latest builds. RustBuild-Linker source

Note: 6 Week Rust Release Schedule

Every 6 weeks Rust will roll forward to a new release version. The linking service will automatically direct to the latest files as they become available. However, on the day of the release it will take the build server about 24 hours to catch up to the latest builds.

ARMv7

(Built on Debian Jessie, with Clang 3.8.1 (3.5 before 2016/04/15), GLIBC 2.19-18, OpenSSL 1.2.0d static)

For ARMv7+ devices with linux and atleast GLIBC 2.19

(Including Raspberry Pi 2 running Raspbian Jessie (8))

Nightly

Beta

Stable

ARMv7 Direct Repository Links

ARMv6-armhf

(Built on Raspbian with Clang 3.7 (October 7th+) or GCC 4.8 (September 29th-), GLIBC 2.13-38+rpi2+deb7u8, OpenSSL 1.2.0d static)

For ARMv6+ devices with linux and atleast GLIBC 2.13

For Raspberry Pi (A, A+, B, B+, 2) running Raspbian Wheezy (7)

Nightly

Beta

Stable

ARMv6-armhf Direct Repository Links

Builds tested on:

  • ODROID XU4 (@Today This is the build server) ARMv7 ARMv6-armhf
  • CubieBoard2 (8/30/2015) ARMv7
  • Samsung Note 10.1 (2014) in Arch chroot (4/14/2015) ARMv7
  • Raspberry Pi B (10/7/2015) ARMv6-armhf

Binary Install/Uninstall Instructions

Using the binary builds can be achieved in two ways. Ideally, using multirust to manage your rust binaries, or through manual linking on your system. I'm going to cover using multirust as that is the system I prefer to use. In this guide I will walk you through adding the latest nightly binary build to multirust. This can be adapted for the stable and beta builds simply.

Requirements:

  • Multirust
  • One or more binary builds for your system from above.
  • The users that will have access to rust on the system will have to belong to a group, such as users or rust

Installation

  • Adding user to a group (Setup step for first time users)
# usermod -aG <group> <user>
  • Create the directory where rust will be installed and move into it. I use "/opt/rust/nightly" (Step 1)
# mkdir -p /opt/rust/nightly
# cd /opt/rust/nightly
  • Download the latest cargo and rust nightly. (Step 2)
# wget $LATEST_CARGO_TARBALL
# wget $LATEST_RUST_TARBALL
  • Extract the releases into the directory (Step 3)
# tar xzf $LATEST_CARGO_TARBALL && rm $LATEST_CARGO_TARBALL
# tar xzf $LATEST_RUST_TARBALL && rm $LATEST_RUST_TARBALL
  • Set the group and permissions (Step 4)
# chown -R root:<group> /opt/rust/nightly
# chmod -R 775 /opt/rust/nightly
  • Link multirust to the current extracted rust and cargo. (Step 5)
# multirust update unofficial-nightly --link-local
# multirust default unofficial-nightly

Now you'll have a version of rust installed in a standard place. Other users could also link against it with only the last step.

If you'd prefer to install it only for your user, just use a directory in your home for deployment. Something like "~/opt/rust/nightly" would be fine.

Updating is as simple as entering the deployed directory, removing all the files and folders, and then perform steps 2-4 again. (Because we used --link-local multirust doesn't care that we've changed the files.)

Uninstallation

  • Remove the files and directories in the deployed directory (Step 1)
# rm -rf /opt/rust/nightly
  • Unlink multirust (Step 2)
# multirust remove-toolchain unofficial-nightly

Usage Instructions

Run # /bin/bash scripts/setup/debian_root_build.sh <name of container> to build a new container from scratch (in the default /chroots directory).

Then run # /bin/bash scripts/setup/debian_root_setup.sh <name of container> to download the required sources and do the initial setup of the filesystem for the container. This will start the container with systemd-nspawn and do the final configuration in the container, downloading the system tools required. During the process you will need to configure the dropbox_uploader utility. Follow the prompts when they appear.

Now you have a working container with the ability to build Rust/Cargo arm binaries. To kickstart the process, in the app folder you defined during the dropbox_upload setup, create a "snapshots" folder and copy the oldest snapshot from my snapshots folder to yours. This is essential for your first build process. After that you are entirely reliant on your own binaries. (Alternatively you can cross compile a stage-0 rust compiler on a host machine with your desired target and use that instead.)

In order to build a recent version of Rust, you'll need to first build an up to date snapshot, then compile the Rust binary, and finally create Cargo. (Cargo will require a previous version of cargo to compile) This can be achieved with the 3 following commands currently

##Nightly

systemd-nspawn /chroots/<name of container> /bin/bash ~/build-snap.sh
systemd-nspawn /chroots/<name of container> /bin/bash ~/build-rust.sh
systemd-nspawn /chroots/<name of container> /bin/bash ~/build-cargo.sh

This will build the most recent nightly by first bootstrapping an older snapshot to build a newer snapshot, then compiling a new Rust from the new snapshot, finally building Cargo from the rustc and a previous version of Cargo. These will all be uploaded to the root directory of the app folder for immediate use.

Alternatively you can use the following to also build beta and stable releases

##Beta

systemd-nspawn /chroots/<name of container> /bin/bash ~/build-snap.sh beta
systemd-nspawn /chroots/<name of container> /bin/bash ~/build-rust.sh beta
systemd-nspawn /chroots/<name of container> /bin/bash ~/build-cargo.sh beta

##Stable

systemd-nspawn /chroots/<name of container> /bin/bash ~/build-snap.sh stable
systemd-nspawn /chroots/<name of container> /bin/bash ~/build-rust.sh stable
systemd-nspawn /chroots/<name of container> /bin/bash ~/build-cargo.sh stable

NOTE: The beta/stable tags on the cargo builder do not mean the beta/stable channels of Cargo. Cargo is currently sub 1.0.0 so there is nothing but the nightly branch. However the beta/stable tags mean to build cargo with the latest version of the beta/stable rust compiler and cargo (nightly cargo if no previous cargo exists). This means that the beta/stable version of Cargo should be less prone to issues over the nightly compiled Cargo.

More Information

I run this on a ODROID XU4 running the latest Arch linux and 3.10 HMP kernel with a 32GB eMMC. I have yet to have a memory failure on the eMMC, but it does get heavy usage, so I am considering a ramdrive as the ODROID XU4 has 2gb, and the Arch system + build container running barely reach 800MB during peak compilation.

A typical snapshot + rust + cargo build is about 8 hours with tests.

New snapshots do not need to be built often, so the actual build time for nightlies is closer to 3.5 hours.

The container with Rust/Cargo nightlies, a Rust snapshot, tools, file cache and the in progress compilation runs around 8GB

These scripts are configured to compile the snapshots and full Rust compilers with Clang for the improvement in build time over a slight reduction in runtime performance. (This may change as new versions of Clang are promoted to debian stable.)

Todo

  • migrate to latest LLVM so we don't have to rebuild LLVM with every compilation of Rust
  • fix build issues ARMv7 builds
  • look into why static-ssl no longer seems to be in the configuration for cargo?
  • enhance the scripts to support stable/beta in addition to nightly
  • improve the setup scripts to fail if the required tools are not installed
  • look into finding a way to always use the latest stable openssl
  • automate some of the documentation tasks
  • automate the build process in a container on the ODROID XU4
  • look into cross compiling snapshots for other architectures to provide a baseline to allow others to easily build a rustc and cargo implementation for those platforms
  • start work on raspbian container in addition to the jessie one for raspberry pi support
  • finish and test a build system on the raspbian container and find a way to test the resulting binaries for ARMv6-armhf compatibility.
  • rebuild dropbox directory structure to support multiple difference architectures
  • build a caching script around the dropbox upload script to reduce network usage for recently built snapshots (and maybe nightlies)
  • add a maximum cache size parameter to the caching script, so that a limit can be put in place.
  • build cargo with the latest stable/beta rust versions in addition to the nightly
  • find a way to store version info on the latest stable/beta cargo and rust installed to /opt/rust_{beta,stable} so we can avoid having to re-download and deploy those versions that don't change regularly.
  • work on integrating multirust with the /opt/rust_{stable,beta,nightly} instead of managing our paths directly in the build scripts. Additionally this will allow the build machine to work on more than the latest versions of rust and cargo and act as a build machine for other rust code without needing a complex bootstrapping process.

License

All scripts/patches in this repository are licensed under the MIT license.

More information can be found in the LICENSE file in this directory

Acknowledgements

Inspired and built upon the excellent work of Jorge Aparicio's ruststrap

rustbuild's People

Contributors

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

rustbuild's Issues

Manual vanilla build also working [documentation update]

Hi,

I've just successfully built a nightly version of rustc (using local llvm 3.6 and no jemalloc) using the provided stage0 snapshot on my Odroid C1.

I think the readme could be improved by including this option as well. (speeds up the build and the produced rustc uses less memory also enabling dynamic linking of rust libs by not mixing different allocators)

The command line used:

./configure --disable-jemalloc --disable-valgrind-rpass --disable-valgrind --disable-docs --llvm-root=/usr --enable-local-rust --local-rust-root=/home/odroid/stage0

Needless to say it's working equally well :)

To try out the proposed changes, use the scripts from my fork.

Cross-compiled executable glibc version requirement

The guide at https://github.com/japaric/ruststrap/blob/master/1-how-to-cross-compile.md had me producing cross compiled executables using the armv6hf rust binaries found in this repo. However, the executable doesn't run on my raspberry pi B with raspbian. Raspbian has glibc 2.13-38+rpi2+deb7u8, but the runtime linker complains about not having GLIBC_2.18. Building executables on the pi works as expected. It sounds like the armv6 binaries you produce are built with glibc 2.13. I guess the main problem is that somehow there's a different glibc involved (maybe due to host rustc?).

My host machine is x86_64 linux with rustc 1.3.0 (9a92aaf19 2015-09-15) installed with multirust. glibc version for armhf is 2.19-0ubuntu2cross1.104. The arm libraries are installed at ~/.multirust/toolchains/stable/lib/rustlib/arm-unknown-linux-gnueabihf. I'm linking with ubuntu's arm-linux-gnueabihf-gcc. The target (rpi B with raspbian) has the armv6 binaries installed using multirust at ~/.multirust/toolchains/stable/lib/rustlib/arm-unknown-linux-gnueabihf/.

Kinda lost here and hoping you have some ideas.

Thanks!

Standard links for fetching rust lib

Hi. Thanks for this repo.

I'm planning to write a script which checks current installed rust version and fetches correct rustlib from this repo, and extract it into /usr/local/lib/rustlib. (Now my rust will be ready for cross compilation)

But that seems difficult with current dropbox links. E.g --> https://www.dropbox.com/s/qe2xzttvlywlmd2/rustlib-1.5.0-stable-2015-12-04-3d7cd77-arm-unknown-linux-gnueabihf-1be195a1f195c6515d05a2a287ade45f3ba3efda.tar.gz?dl=0

Is it possible to make the links simpler so that hard coding the link is easy?

Build for OpenPandora (softfloat)

I'd like to be able to cross-compile Rust programs for my Pandora as I discussed on Reddit. glibc says it is version 2.9 so hopefully it may be possible.

Add ARMv7+NEON Cortex-A7-optimized builds

Hi, I think it would be awesome if you could make available ARMv7+NEON builds, tuned for Cortex-A7; i.e. where libstd will be compiled with NEON auto-vectorization enabled. These builds would be very useful for maximizing performance for Raspberry Pi 2 projects, which is NEON-enabled Cortex-A7. I would use these write away for building and testing ring and my other projects for Raspberry Pi 2.

If there's something I can do to help facilitate this, let me know. Thanks!

armv7? Not really

I've just noticed the armhf target's code generation was actually geared towards v6 for compatibility.

Seeing as you already provide separate armv6 builds it makes sense for the armv7 ones to generate code for v7, incl. at the time of bootstrapping themselves (curiously it's the default on android.)

Literally we're talking about just two commands before the start of the armv7 build:

sed -i s/v6/v7/ src/librustc_back/target/arm_unknown_linux_gnueabihf.rs

and

sed -i s/v6/v7/ mk/cfg/arm-unknown-linux-gnueabihf.mk

To try out the proposed changes anyone can use the scripts from my fork.

Build incompatible with Raspbian

I have downloaded the stable rust 1.2 binaries but the glibc version required is higher than the version provided by the Raspbian sources. This is a similar issue to japaric-archived/ruststrap#18. I am using the ARMv7 binaries as I am on a Raspberry Pi 2.

The default glibc version on Raspian is 2.13:

pi@raspberrypi ~ $ sudo dpkg -l | grep libc6
ii  libc6:armhf                           2.13-38+rpi2+deb7u8                     armhf        Embedded GNU C Library: Shared libraries
ii  libc6-dev:armhf                       2.13-38+rpi2+deb7u8                     armhf        Embedded GNU C Library: Development Libraries and Header Files

When running rustc, the following error is produced:

pi@raspberrypi ~/rust $ rustc
rustc: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.18' not found (required by /home/pi/rust/rustc/lib/libstd-62abc69f.so)
rustc: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.18' not found (required by /home/pi/rust/rustc/lib/librustc_llvm-62abc69f.so)
rustc: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.15' not found (required by /home/pi/rust/rustc/lib/librustc_llvm-62abc69f.so)

Please let me know if there is any more information that you need and thanks for taking over from @japaric ๐Ÿ‘!

Recent Builds Failing

Starting around Feb 1st, builds on the Odrioid XU4 started locking up the machine.

Rasbian Nightly Builds Stopped Working

Latest stack trace from the Raspbian container.

Oct 01 10:37:24 aita BuildRust.sh[12488]: /build/rust/build/arm-unknown-linux-gnueabihf/llvm/Release/lib/libLLVMX86CodeGen.a(X86TargetMachine.o): In function `(anonymous namespace)::X86PassConfig::addPostRegAlloc()':
Oct 01 10:37:24 aita BuildRust.sh[12488]: X86TargetMachine.cpp:(.text._ZN12_GLOBAL__N_113X86PassConfig15addPostRegAllocEv+0x8): undefined reference to `llvm::createX86FloatingPointStackifierPass()'
Oct 01 10:37:24 aita BuildRust.sh[12488]: collect2: error: ld returned 1 exit status
Oct 01 10:37:24 aita BuildRust.sh[12488]: /build/rust/src/llvm/Makefile.rules:1434: recipe for target '/build/rust/build/arm-unknown-linux-gnueabihf/llvm/Release/bin/llc' failed
Oct 01 10:37:24 aita BuildRust.sh[12488]: make[3]: *** [/build/rust/build/arm-unknown-linux-gnueabihf/llvm/Release/bin/llc] Error 1
Oct 01 10:37:24 aita BuildRust.sh[12488]: make[3]: Leaving directory '/build/rust/build/arm-unknown-linux-gnueabihf/llvm/tools/llc'
Oct 01 10:37:24 aita BuildRust.sh[12488]: /build/rust/src/llvm/Makefile.rules:939: recipe for target 'llc/.makeall' failed
Oct 01 10:37:24 aita BuildRust.sh[12488]: make[2]: *** [llc/.makeall] Error 2
Oct 01 10:37:24 aita BuildRust.sh[12488]: make[2]: *** Waiting for unfinished jobs....
Oct 01 10:37:24 aita BuildRust.sh[12488]: llvm[3]: Compiling PrintSCC.cpp for Release build
Oct 01 10:37:26 aita BuildRust.sh[12488]: llvm[3]: Compiling opt.cpp for Release build
Oct 01 10:37:27 aita BuildRust.sh[12488]: llvm[3]: Linking Release executable llvm-extract (without symbols)
Oct 01 10:37:29 aita BuildRust.sh[12488]: llvm[3]: ======= Finished Linking Release Executable llvm-extract (without symbols)
Oct 01 10:37:29 aita BuildRust.sh[12488]: make[3]: Leaving directory '/build/rust/build/arm-unknown-linux-gnueabihf/llvm/tools/llvm-extract'
Oct 01 10:37:29 aita BuildRust.sh[12488]: llvm[3]: Compiling ToolRunner.cpp for Release build
Oct 01 10:37:30 aita BuildRust.sh[12488]: llvm[3]: Compiling bugpoint.cpp for Release build
Oct 01 10:37:42 aita BuildRust.sh[12488]: llvm[3]: Linking Release executable bugpoint (without symbols)
Oct 01 10:37:44 aita BuildRust.sh[12488]: llvm[3]: ======= Finished Linking Release Executable bugpoint (without symbols)
Oct 01 10:37:44 aita BuildRust.sh[12488]: make[3]: Leaving directory '/build/rust/build/arm-unknown-linux-gnueabihf/llvm/tools/bugpoint'
Oct 01 10:37:47 aita BuildRust.sh[12488]: llvm[3]: Linking Release executable opt (without symbols)
Oct 01 10:37:50 aita BuildRust.sh[12488]: /build/rust/build/arm-unknown-linux-gnueabihf/llvm/Release/lib/libLLVMX86CodeGen.a(X86TargetMachine.o): In function `(anonymous namespace)::X86PassConfig::addPostRegAlloc()':
Oct 01 10:37:50 aita BuildRust.sh[12488]: X86TargetMachine.cpp:(.text._ZN12_GLOBAL__N_113X86PassConfig15addPostRegAllocEv+0x8): undefined reference to `llvm::createX86FloatingPointStackifierPass()'
Oct 01 10:37:50 aita BuildRust.sh[12488]: collect2: error: ld returned 1 exit status
Oct 01 10:37:50 aita BuildRust.sh[12488]: /build/rust/src/llvm/Makefile.rules:1434: recipe for target '/build/rust/build/arm-unknown-linux-gnueabihf/llvm/Release/bin/opt' failed
Oct 01 10:37:50 aita BuildRust.sh[12488]: make[3]: *** [/build/rust/build/arm-unknown-linux-gnueabihf/llvm/Release/bin/opt] Error 1
Oct 01 10:37:50 aita BuildRust.sh[12488]: make[3]: Leaving directory '/build/rust/build/arm-unknown-linux-gnueabihf/llvm/tools/opt'
Oct 01 10:37:50 aita BuildRust.sh[12488]: /build/rust/src/llvm/Makefile.rules:939: recipe for target 'opt/.makeall' failed
Oct 01 10:37:50 aita BuildRust.sh[12488]: make[2]: *** [opt/.makeall] Error 2
Oct 01 10:37:50 aita BuildRust.sh[12488]: make[2]: Leaving directory '/build/rust/build/arm-unknown-linux-gnueabihf/llvm/tools'
Oct 01 10:37:50 aita BuildRust.sh[12488]: /build/rust/src/llvm/Makefile.rules:880: recipe for target 'all' failed
Oct 01 10:37:50 aita BuildRust.sh[12488]: make[1]: *** [all] Error 1
Oct 01 10:37:50 aita BuildRust.sh[12488]: make[1]: Leaving directory '/build/rust/build/arm-unknown-linux-gnueabihf/llvm'
Oct 01 10:37:50 aita BuildRust.sh[12488]: /build/rust/mk/llvm.mk:89: recipe for target '/build/rust/build/arm-unknown-linux-gnueabihf/llvm/Release/bin/llvm-config' failed
Oct 01 10:37:50 aita BuildRust.sh[12488]: make: *** [/build/rust/build/arm-unknown-linux-gnueabihf/llvm/Release/bin/llvm-config] Error 2
Oct 01 10:37:50 aita BuildRust.sh[12488]: Container RustBuild-raspbian failed with error code 2.

New version building broken due to git changes

Need to add some checking to allow seamlessly moving to new builds (as Rust pushes new point releases every 6 weeks). Currently appears to be broken. Once fixed, it needs to be watched for a few days to be sure it is proceding as normal.

Use latest LLVM without rebuilding every time

It's been possible to use the system LLVM for quite a while but it's probably better to use the bundled, updated source. Here's what I've been doing lately:

Once llvm gets updated, do a full llvm build, preserve the llvm directory. On every subsequent Rust build it's possible to:

  • run configure
  • remove target-triple/llvm
  • link to the previously saved llvm directory in target-triple
  • enter the newly linked llvm dir and invoke:
    find . -exec touch {} \;
  • continue normally with make.

I'm curious how well this method compares to ccache, as similar to using --llvm-root, you get to stage0 immediately.

Segmentation fault while executing crosscompiled binary @ RPi 1 Rev. b

Hello.

If I compile something with: rustc -C linker=arm-linux-gnueabihf-gcc --target=arm-unknown-linux-gnueabihf hello.rs, copy that binary to my RPi1b and trying to execute that binary, after copying finished, I get a segmentation fault at the @RPi1b: [1] 20396 segmentation fault ./hello
Any ideas why this is happening?


CPU on my RPi1b:

processor       : 0
model name      : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 2.28
Features        : half thumb fastmult vfp edsp java tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7

Hardware        : BCM2708
Revision        : 000d
Serial          : 0000000089ffe808
$ file hello
hello: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x02f2a58e4f9061f758700b088ee33909e42d7d43, not stripped

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.