Skip to content

Instantly share code, notes, and snippets.

View ctreffs's full-sized avatar
💭
🏊 🚴‍♂️ 🏃

Christian Treffs ctreffs

💭
🏊 🚴‍♂️ 🏃
View GitHub Profile
@ctreffs
ctreffs / GLSL-Noise.md
Created November 19, 2020 13:43 — forked from patriciogonzalezvivo/GLSL-Noise.md
GLSL Noise Algorithms

Generic 1,2,3 Noise

float rand(float n){return fract(sin(n) * 43758.5453123);}

float noise(float p){
	float fl = floor(p);
  float fc = fract(p);
	return mix(rand(fl), rand(fl + 1.0), fc);
}
@ctreffs
ctreffs / VulkanClear.cc
Created May 18, 2021 07:42 — forked from Overv/VulkanClear.cc
Vulkan code for clearing the screen
#include <iostream>
#include <vector>
#define GLFW_INCLUDE_VULKAN
#define VK_USE_PLATFORM_WIN32_KHR
#include <GLFW/glfw3.h>
#define GLFW_EXPOSE_NATIVE_WIN32
#include <GLFW/glfw3native.h>
@ctreffs
ctreffs / deployable-artifacts.md
Created June 27, 2021 07:46 — forked from ddunbar/deployable-artifacts.md
Deployable Artifacts thoughts

My hopes for deployable artifacts:

  1. Packages would be able to just describe how the things they build should get laid out in a tarball.
  2. We would implement this as part of the build, it should be super fast (we might want to consider actually generating the tar directly for portability & control purposes).
  3. Packages could have control over the permissions inside the tar file (ideally without having to manipulate the permissions in the filesystem, problematic sometimes if root permission in the tar is desired).
  4. The mechanism would support knowing how to handle RPATH issues.
  5. The mechanism would know how to handle libswift* portability issues.
  6. The mechanism would know how to handle cross-Linux distro issues.
  7. Unlike below, I wouldn't expect the mechanism to handle the GIT REVISION stuff, that belongs in a separate proposal.
  8. The mechanism would support typical Unix-y things, like bin, lib, libexec, share.
  9. The mechanism could support vendored assets like other DSOs or frameworks that can't l
@ctreffs
ctreffs / Tuple.swift
Created June 29, 2021 12:51 — forked from beccadax/Tuple.swift
Exploring user-space tuple designs in the quest for variadic generics.
// First, let's test out the basic design. This is basically just an
// HList.
// This recurses to the right because that makes subscripting simpler,
// at the cost of making appending impossible to generalize.
public protocol TupleProtocol: RandomAccessCollection
where Index == Int, IndexDistance == Int, Element == Any
{
associatedtype First
associatedtype Rest //: TupleProtocol
@ctreffs
ctreffs / README.md
Created October 28, 2021 10:15 — forked from keith/README.md
A test of `@_dynamicReplacement` in Swift

Usage

  1. swiftc main.swift -emit-module-path main.swiftmodule -emit-executable -enable-private-imports -Xfrontend -enable-implicit-dynamic
  2. ./main -> prints From original bar()
  3. swiftc -emit-library inject.swift -o inject.dylib -I . -Xlinker -undefined -Xlinker suppress -Xlinker -flat_namespace -Xfrontend -disable-access-control
  4. DYLD_INSERT_LIBRARIES=inject.dylib ./main -> prints From replacement bar()

Notes

  • Passing -Xfrontend -enable-implicit-dynamic removes you from having to add dynamic to everything you want to be replacable