regner

<?xml version='1.0' ?>

<!--
    Why is this one giant script instead of a bunch of smaller scripts?
    Mostly this comes down to BuildGraph and personal preference. As the language BuildGraph isn't
    really much of a programming language there is no easy way to use an IDE and jump between
    includes, find usages of variables, and just generally quickly search things. It was found to
    be easier to have a single large file that a developer can quickly jump up and down in when
    trying to understand what the BuildGraph script is doing.

Enichan

// coroutines for C adapted from Simon Tatham's coroutines
// https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
// 
// this implementation utilizes __VA_ARGS__ and __COUNTER__
// to avoid a begin/end pair of macros.
#include <stdlib.h>
#include <stdio.h>
#include <stdbool.h>

// modify this if you don't like the `self->name` format

repi

msrv = "1.55.0"

# for `disallowed_method`: https://rust-lang.github.io/rust-clippy/master/index.html#disallowed_method
disallowed-methods = [
    # std functions
    "std::env::temp_dir",        # we use the tempdir crate instead through ark_file_system::TempDir
    "std::env::home_dir",        # deprecated, and we use app_dirs2 crate
    "std::env::set_current_dir", # don't change the current working directory, it usually leads to shared sadness
    "std::env::var_os",          # use std::env::var and UTF-8 strings instead, including for paths
    "std::env::env_os",          # use std::env::env and UTF-8 strings instead, including for paths

thomcc

{
	"unwrap or return": {
		"scope": "rust",
		"prefix": ["unwrap or return", "let if let"],
		"body": [
			"let $1 = if let ${3:Some($1)} = ${2:expr} {",
			"\t$1",
			"} else {",
			"\treturn ${0:Ok(())};",
			"};"

GrabYourPitchforks

Memory<T> API documentation and samples

This document describes the APIs of Memory<T>, IMemoryOwner<T>, and MemoryManager<T> and their relationships to each other.

See also the Memory<T> usage guidelines document for background information.

First, a brief summary of the basic types

• Memory<T> is the basic type that represents a contiguous buffer. This type is a struct, which means that developers cannot subclass it and override the implementation. The basic implementation of the type is aware of contigious memory buffers backed by T[] and System.String (in the case of ReadOnlyMemory<char>).

GrabYourPitchforks

Memory<T> usage guidelines

This document describes the relationship between Memory<T> and its related classes (MemoryPool<T>, IMemoryOwner<T>, etc.). It also describes best practices when accepting Memory<T> instances in public API surface. Following these guidelines will help developers write clear, bug-free code.

First, a tour of the basic exchange types

• Span<T> is the basic exchange type that represents contiguous buffers. These buffers may be backed by managed memory (such as T[] or System.String). They may also be backed by unmanaged memory (such as via stackalloc or a raw void*). The Span<T> type is not heapable, meaning that it cannot appear as a field in classes, and it cannot be used across yield or await boundaries.

• Memory is a wrapper around an object that can generate a Span. For instance, Memory instances can be backed by T[], System.String (readonly), and even SafeHandle instances. Memory cannot be backed by "transient" unmanaged me

mbinna

Effective Modern CMake

Getting Started

For a brief user-level introduction to CMake, watch C++ Weekly, Episode 78, Intro to CMake by Jason Turner. LLVM’s CMake Primer provides a good high-level introduction to the CMake syntax. Go read it now.

After that, watch Mathieu Ropert’s CppCon 2017 talk Using Modern CMake Patterns to Enforce a Good Modular Design (slides). It provides a thorough explanation of what modern CMake is and why it is so much better than “old school” CMake. The modular design ideas in this talk are based on the book [Large-Scale C++ Software Design](https://www.amazon.de/Large-Scale-Soft

dmichael

Redux WebSocket Middleware: Example

This Gist provides some code examples of how to implement WebSocket stream handling using a Redux middleware. Please be aware that this is only provided as an example and that critical things like exception handling have not been implemented.

A more complete version has been packaged, tested, and is available on GitHub as redux-websocket. This library has also been published to npm at @giantmachines/redux-websocket.

Middleware

This module represents the foundation of the middleware and implements the ideas presented above. The exported function is used during the creation of the Redux store (see the following snippet).

Reedbeta

<?xml version="1.0" encoding="UTF-8"?>
<opml version="1.0">
    <head>
        <title>Graphics, Games, Programming, and Physics Blogs</title>
    </head>
    <body>
        <outline text="Tech News" title="Tech News">
            <outline type="rss" text="Ars Technica" title="Ars Technica" xmlUrl="http://feeds.arstechnica.com/arstechnica/index/" htmlUrl="https://arstechnica.com"/>
            <outline type="rss" text="Polygon - Full" title="Polygon - Full" xmlUrl="http://www.polygon.com/rss/index.xml" htmlUrl="https://www.polygon.com/"/>
            <outline type="rss" text="Road to VR" title="Road to VR" xmlUrl="http://www.roadtovr.com/feed" htmlUrl="https://www.roadtovr.com"/>

bkaradzic

Orthodox C++

What is Orthodox C++?

Orthodox C++ (sometimes referred as C+) is minimal subset of C++ that improves C, but avoids all unnecessary things from so called Modern C++. It's exactly opposite of what Modern C++ suppose to be.

Why not Modern C++?