Code Monkey home page Code Monkey logo

url's Introduction

C++ Network Library

Modern C++ network programming libraries.

https://travis-ci.org/cpp-netlib/cpp-netlib.svg?branch=master

Join us on Slack: http://slack.cpp-netlib.org/

Subscribe to the mailing list: https://groups.google.com/forum/#!forum/cpp-netlib

Downloading cpp-netlib

You can find official release packages of the library at:

http://github.com/cpp-netlib/cpp-netlib/downloads

If you want the latest code from the master branch of the project, you can follow these instructions for cloning the project repository:

$ git clone https://github.com/cpp-netlib/cpp-netlib
$ cd cpp-netlib
$ git submodule init
$ git submodule update

Introduction

cpp-netlib is a collection of network-related routines/implementations geared towards providing a robust cross-platform networking library. cpp-netlib offers the following implementations:

  • Common Message Type -- A generic message type which can be used to encapsulate and store message-related information, used by all network implementations as the primary means of data exchange.
  • Network protocol message parsers -- A collection of parsers which generate message objects from strings.
  • Adapters and Wrappers -- A collection of Adapters and wrappers aimed towards making the message type STL friendly.
  • Network protocol client and server implementations -- A collection of network protocol implementations that include embeddable client and server types.

This library is released under the Boost Software License (please see http://boost.org/LICENSE_1_0.txt or the accompanying LICENSE_1_0.txt file for the full text.

Building and Installing

To build the libraries you will need to have CMake version 2.8 or higher installed appropriately in your system.

$ cmake --version
cmake version 2.8.1

It is recommended that you build cpp-netlib outside of the source directory, to avoid having issues with CMake generated files polluting the source directory:

$ mkdir ~/cpp-netlib-build
$ cd ~/cpp-netlib-build
$ cmake -DCMAKE_BUILD_TYPE=Debug     \
>       -DCMAKE_C_COMPILER=clang     \
>       -DCMAKE_CXX_COMPILER=clang++ \
>       $HOME/cpp-netlib    # we're assuming this is where cpp-netlib is.

Once CMake is done with generating the Makefiles and configuring the project, you can now build the tests and run them:

$ cd ~/cpp-netlib-build
$ make
$ make test

You can also download and install cpp-netlib using the ` vcpkg`_ dependency manager:

$ git clone https://github.com/Microsoft/vcpkg.git $ cd vcpkg $ ./bootstrap-vcpkg.sh $ ./vcpkg integrate install $ vcpkg install cpp-netlib

The cpp-netlib port in vcpkg is kept up to date by Microsoft team members and community contributors. If the version is out of date, please create an issue or pull request on the ` vcpkg`_ repository.

If for some reason some of the tests fail, you can send the files in Testing/Temporary/ as attachments to the cpp-netlib developers mailing list.

Running Tests

If you want to run the tests that come with cpp-netlib, there are a few things you will need. These are:

  • A compiler (GCC 4.x, Clang 3.6, MSVC 2008)
  • A build tool (CMake is required)
  • OpenSSL headers (optional)

Note

This assumes that you have cpp-netlib at the top-level of your home directory.

Hacking on cpp-netlib

cpp-netlib uses git for tracking work and is hosted on GitHub. cpp-netlib is hosted on GitHub following the GitHub recommended practice of forking the repository and submitting pull requests to the source repository. You can read more about the forking process and submitting pull requests if you're not familiar with either process yet. cpp-netib follows the GitHub pull request model for accepting patches. You can read more about the process at http://cpp-netlib.org/process.html#pull-requests.

Because cpp-netlib is released under the Boost Software License it is recommended that any file you make changes to bear your copyright notice alongside the original authors' copyright notices on the file. Typically the copyright notices are at the top of each file in the project.

You can read about the cpp-netlib style guide at http://cpp-netlib.org/style-guide.html.

The main "upstream" repository is at http://github.com/cpp-netlib/cpp-netlib.

Contact and Support

In case you have any questions or would like to make feature requests, you can contact the development team through the developers mailing list or by filing issues at http://github.com/cpp-netlib/cpp-netlib/issues.

Join us on Slack: http://slack.cpp-netlib.org/

You can reach the maintainers of the project through:

Dean Michael Berris ([email protected])

Glyn Matthews ([email protected])

url's People

Contributors

artemyarulin avatar caitp avatar chrismanning avatar cmbrandenburg avatar deanberris avatar diamond-msc avatar emmenlau avatar georgi-d avatar glynos avatar ingomueller-net avatar internal-compiler-error avatar jdemilledt avatar lacop avatar maztheman avatar mefyl avatar mightrider avatar plaristote avatar pszubiak avatar rogiel avatar ruslo avatar theaquaman avatar toonetown avatar torbjoernk avatar zaufi 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

Watchers

 avatar  avatar  avatar  avatar  avatar

url's Issues

`const` version of `operator->` does not compile

Accessing a const url through operator-> does currently not compile. It uses valptr, which does not have a const version. See the following error:

In file included from test.cpp:22:
In file included from include/skyr/url.hpp:14:
In file included from include/skyr/expected.hpp:9:
include/skyr/external/tl/expected.hpp:1752:50: error: 'this' argument to member
      function 'valptr' has type 'const tl::expected<skyr::url, std::error_code>', but function is not marked const
  constexpr const T *operator->() const { return valptr(); }
                                                 ^~~~~~
test.cpp:266:61: note: in instantiation of member function
      'tl::expected<skyr::url, std::error_code>::operator->' requested here
                is_exception = exceptions.count(endpoint_url->hostname()) > 0;
                                                            ^
include/skyr/external/tl/expected.hpp:1111:6: note: 'valptr' declared here
  T *valptr() { return std::addressof(this->m_val); }
     ^
1 error generated.

Incorrect default argument (be_strict) to domain_to_ascii?

Hi there,

as per WhatWG url spec, we have for "domain to ASCII":

If beStrict is not given, set it to false

But skyr::v1::unicode::domain_to_ascii has true as a default argument:

tl::expected<std::string, std::error_code> domain_to_ascii(
std::string_view domain,
bool be_strict = true);
/// Converts a UTF-32 encoded domain to ASCII using
/// [IDNA processing](https://www.unicode.org/reports/tr46/#Processing)
///
/// \param domain A domain
/// \param be_strict Tells the processor to be strict
/// \returns An ASCII domain, or an error
tl::expected<std::string, std::error_code> domain_to_ascii(
std::u32string_view domain,
bool be_strict = true);

If I'm not missing anything, this should be bool be_strict = false.

I noticed this by trying to urlparse https://+:80/vroot/ - which fails for netlib/url. Doing the analogue (i.e. JavaScript new URL("https://+:80/vroot/")) in Chrome (80.0.3987.132), Firefox (73.0.1), Safari (13.0.5 (15608.5.11)): they all return a new URL object.

Search parameters not serialized

I build a URL the following way:

skyr::url builder{"http://127.0.0.1:7720/path/to/endpoint"};
auto& params = builder.search_parameters();
params.append("caller", "one");
params.append("req", "two");
std::cout << skyr::serialize(builder.record()) << "\n";

It does not add the query parameters to the output. The way this API is used is really weird. I see a skyr::url::set_search(), which seems to be the intended way of doing this. But if I want to construct my query parameters piecemeal as I have above, it doesn't work because the url_search_parameters constructor does not initialize the optional url_record::query member unless it was already non-empty to begin with. I think that the constructor should initialize empty query member if it was obtained using a non-const reference (as is the case with url::search_parameters()). If you intended this to not mutate the parameters, please change the return value to url_search_parameters const&.

Allow boost::filesystem for macOS compatibility?

I've started to use url and like it quite a lot. However I've hit a blocker problem in that Apple introduced full support for std::filesystem only in macOS 10.15, which very much limits the applicability of url. If I can propose optional support for boost::filesystem, would that be an acceptable merge request?

Support -fno-exceptions

I am thinking of using this library in a situation where I have to compile with -fno-exceptions. However, this is currently not possible due to the usage of std::stoull in src/ipv4_address.cpp:parse_ipv4_number (and maybe the usage of expected, but I think it has an exception-free variant). For the former issue, std::from_chars could be an alternative to std::stoull.

File URLs with port in hostname do not work

This URL breaks the parser:

file://example.com:789/over/there?name=ferret#nose

It parses the hostname as example.com:789, but it should be example.com with a port of 789.

In url_parse.cpp, seems to me like file URIs should use url_parse_state::host, and not have a specialized, less flexible parser for hostnames represented by url_parse_state::file_host. At the very least, the file URL hostname parsing should add support for :.

x64-debug has link error, x64-Release build success

In Windows using CMake

F:\vcpkg>vcpkg version
skyr-url install by vcpkg
Vcpkg package management program version 2020.02.04-nohash

See LICENSE.txt for license information.

windows\debug\lib\libcrypto.lib F:\vcpkg\installed\x64-windows\debug\lib\fmtd.lib F:\vcpkg\installed\x64-windows\lib\skyr-url.lib F:\vcpkg\installed\x64-windows\debug\lib\gtestd.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:tests\CMakeFiles\tests.dir/intermediate.manifest tests\CMakeFiles\tests.dir/manifest.res" failed (exit code 1319) with the following output:
G:\GreyDawnModule\GreyDawnNetwork\out\build\x64-Debug\skyr-url.lib(url_search_parameters.cpp.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in GreyDawnNetworkTest.cpp.obj
G:\GreyDawnModule\GreyDawnNetwork\out\build\x64-Debug\skyr-url.lib(url_search_parameters.cpp.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in GreyDawnNetworkTest.cpp.obj
G:\GreyDawnModule\GreyDawnNetwork\out\build\x64-Debug\skyr-url.lib(url.cpp.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in GreyDawnNetworkTest.cpp.obj
G:\GreyDawnModule\GreyDawnNetwork\out\build\x64-Debug\skyr-url.lib(url.cpp.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in GreyDawnNetworkTest.cpp.obj
G:\GreyDawnModule\GreyDawnNetwork\out\build\x64-Debug\skyr-url.lib(ipv4_address.cpp.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in GreyDawnNetworkTest.cpp.obj
G:\GreyDawnModule\GreyDawnNetwork\out\build\x64-Debug\skyr-url.lib(ipv4_address.cpp.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in GreyDawnNetworkTest.cpp.obj
G:\GreyDawnModule\GreyDawnNetwork\out\build\x64-Debug\skyr-url.lib(ipv6_address.cpp.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in GreyDawnNetworkTest.cpp.obj
G:\GreyDawnModule\GreyDawnNetwork\out\build\x64-Debug\skyr-url.lib(ipv6_address.cpp.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in GreyDawnNetworkTest.cpp.obj
G:\GreyDawnModule\GreyDawnNetwork\out\build\x64-Debug\skyr-url.lib(domain.cpp.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in GreyDawnNetworkTest.cpp.obj
G:\GreyDawnModule\GreyDawnNetwork\out\build\x64-Debug\skyr-url.lib(domain.cpp.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in GreyDawnNetworkTest.cpp.obj
G:\GreyDawnModule\GreyDawnNetwork\out\build\x64-Debug\skyr-url.lib(parse.cpp.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in GreyDawnNetworkTest.cpp.obj
G:\GreyDawnModule\GreyDawnNetwork\out\build\x64-Debug\skyr-url.lib(parse.cpp.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in GreyDawnNetworkTest.cpp.obj
G:\GreyDawnModule\GreyDawnNetwork\out\build\x64-Debug\skyr-url.lib(punycode.cpp.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in GreyDawnNetworkTest.cpp.obj
G:\GreyDawnModule\GreyDawnNetwork\out\build\x64-Debug\skyr-url.lib(punycode.cpp.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in GreyDawnNetworkTest.cpp.obj
G:\GreyDawnModule\GreyDawnNetwork\out\build\x64-Debug\skyr-url.lib(idna.cpp.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in GreyDawnNetworkTest.cpp.obj
G:\GreyDawnModule\GreyDawnNetwork\out\build\x64-Debug\skyr-url.lib(idna.cpp.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in GreyDawnNetworkTest.cpp.obj
G:\GreyDawnModule\GreyDawnNetwork\out\build\x64-Debug\skyr-url.lib(url_parser_context.cpp.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in GreyDawnNetworkTest.cpp.obj
G:\GreyDawnModule\GreyDawnNetwork\out\build\x64-Debug\skyr-url.lib(url_parser_context.cpp.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in GreyDawnNetworkTest.cpp.obj
G:\GreyDawnModule\GreyDawnNetwork\out\build\x64-Debug\skyr-url.lib(host.cpp.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in GreyDawnNetworkTest.cpp.obj
G:\GreyDawnModule\GreyDawnNetwork\out\build\x64-Debug\skyr-url.lib(host.cpp.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in GreyDawnNetworkTest.cpp.obj
G:\GreyDawnModule\GreyDawnNetwork\out\build\x64-Debug\LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
G:\GreyDawnModule\GreyDawnNetwork\out\build\x64-Debug\bin\tests.exe : fatal error LNK1319: 20 mismatches detected
ninja: build stopped: subcommand failed.

Build All failed.

Can not build on Ubuntu 18.04 with Clang

When using Clang on an older Linux like Ubuntu 18.04 (gcc-7), the build should link to stdc++fs unless skyr_BUILD_WITH_LLVM_LIBCXX is given.

I've tested that it works when using something like:

set(clang_with_gnu_stdlib $<AND:$<CXX_COMPILER_ID:Clang>,$<NOT:$<BOOL:${WIN32}>>,$<NOT:$<BOOL:${skyr_BUILD_WITH_LLVM_LIBCXX}>>>)

[...]
    target_link_libraries(
            skyr-filesystem
            [...]
            $<${clang_with_gnu_stdlib}:"stdc++fs">

include catch.hpp from catch2/catch.hpp

The default install location for Catch2 is TARGETDIR/include/catch2/catch.hpp. Some tests already use this location, i.e. #include <catch2/catch.hpp> but the majority includes just <catch.hpp>.

Build system should honor DISABLE_LIBCXX for computing CXX_FLAGS

I am trying to use Skyr with clang 7.0 without libc++. Skyr has the build option Skyr_DISABLE_LIBCXX such that libstdc++ is linked instead of libc++. However, libc++ is still used for compilation. This means that the library cannot be linked into something compiled with libstdc++.

The following patch makes the build system honor DISABLE_LIBCXX also for compilation:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 3399962..85fed71 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -32,7 +32,10 @@ if (${CMAKE_CXX_COMPILER_ID} MATCHES GNU)

     message("C++ Flags: ${CMAKE_CXX_FLAGS} link flags: ${CMAKE_CXX_LINK_FLAGS}")
 elseif(${CMAKE_CXX_COMPILER_ID} MATCHES Clang)
-    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++17 -stdlib=libc++")
+    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++17")
+    if (NOT Skyr_DISABLE_LIBCXX)
+        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++")
+    endif()

     if (Skyr_FULL_WARNINGS)
         set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall")

Implement v3 using C++23 features

The most interesting is std::expected, which is similar to the tl::expected I make heavy use of in this library.
If uni-algo turns out to be interesting, this should be part of v3.

This ticket is a placeholder for other things that I will find out about.

Can not compile tests with clang 11.0.1 on Linux due to std::experimental::filesystem linker issue

The build of tests currently fails for me on Ubuntu 18.04 with latest clang 11.0.1 (installed from llvm.org). There seems to be a problem linking the correct std::filesystem libraries required for clang.

FAILED: tests/filesystem/filesystem_path_tests 
: && /data/bdaci01/Tools/lib/ccache/clang++ -glldb -fno-omit-frame-pointer -O0 -m64 -march=skylake   -DDEBUG -g -Wl,--disable-new-dtags -m64 tests/filesystem/CMakeFiles/filesystem_path_tests.dir/filesystem_path_tests.cpp.o -o tests/filesystem/filesystem_path_tests  -Wl,-rpath,/data/bdaci01/Debug/lib:/data/bdaci01/Tools/lib  src/libskyr-urld.a  /data/bdaci01/Debug/lib/libfmt.a  src/libskyr-urld.a && :
tests/filesystem/CMakeFiles/filesystem_path_tests.dir/filesystem_path_tests.cpp.o: In function `path<char [18], std::experimental::filesystem::v1::__cxx11::path>':
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/experimental/bits/fs_path.h:199: undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
tests/filesystem/CMakeFiles/filesystem_path_tests.dir/filesystem_path_tests.cpp.o: In function `path<char [20], std::experimental::filesystem::v1::__cxx11::path>':
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/experimental/bits/fs_path.h:199: undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
tests/filesystem/CMakeFiles/filesystem_path_tests.dir/filesystem_path_tests.cpp.o: In function `path<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::experimental::filesystem::v1::__cxx11::path>':
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/experimental/bits/fs_path.h:199: undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
tests/filesystem/CMakeFiles/filesystem_path_tests.dir/filesystem_path_tests.cpp.o: In function `path':
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/experimental/bits/fs_path.h:186: undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
tests/filesystem/CMakeFiles/filesystem_path_tests.dir/filesystem_path_tests.cpp.o: In function `std::experimental::filesystem::v1::__cxx11::path::clear()':
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/experimental/bits/fs_path.h:298: undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
clang: error: linker command failed with exit code 1 (use -v to see invocation)

default_port() takes a scheme but not a protocol()

auto const myurl = url("https://exampe.com");
url::default_port(myurl.protocol()).has_value(); // false

So, protocol() returns https: but default_port() needs a scheme (no ':'). Plus, there is no url::scheme() provided. Is this some overlooking ? Having to strip the ':' every time is annoying.

is_url_code_point discrepancy from spec

Hi, https://url.spec.whatwg.org/#url-code-points states:

The URL code points are ASCII alphanumeric, U+0021 (!), U+0024 ($), U+0026 (&), U+0027 ('), U+0028 LEFT PARENTHESIS, U+0029 RIGHT PARENTHESIS, U+002A (*), U+002B (+), U+002C (,), U+002D (-), U+002E (.), U+002F (/), U+003A (:), U+003B (;), U+003D (=), U+003F (?), U+0040 (@), U+005F (_), U+007E (~), and code points in the range U+00A0 to U+10FFFD, inclusive, excluding surrogates and noncharacters.

But is_url_code_point has:

"!$&'()*+,-./:/=?@_~"

Shouldn't this be like:

"!$&'()*+,-./:;=?@_~"

I.e. change the second slash (/) to a semicolon (;).

JSON interoperability

Interoperate between JSON (e.g. URL queries) and skyr::url.

nlohmann::json is a good library to use.

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.