- Download the latest zsh package: https://packages.msys2.org/package/zsh?repo=msys&variant=x86_64
Example:
zsh-5.7.1-1-x86_64.pkg.tar.xz
// The DockBuilder API is still marked as experimental, include Dear ImGui's internal header to pull the functions in: | |
#include "imgui_internal.h" | |
// [...] | |
// Beginning of main loop | |
// 1. DockBuilder functions only need to run once to take effect. | |
// This state variable will let us check for the first frame of the app. | |
static bool firstLoop = true; |
Example:
zsh-5.7.1-1-x86_64.pkg.tar.xz
For the every-day programmer who needs to get shit done instead of fighting type errors.
If your application deals with times in any meaningful way, you should probably want to actually store time_points and durations and what-not; chrono has a pretty rich vocabulary for talking about time-related concepts using the type system. However, sometimes you just need to do something simple, like timing how long something takes, which is where chrono becomes overly complex, hence this cheat sheet.
All examples will assume #include <chrono>
.
# optional.gd | |
# | |
# Caveat | |
# ------ | |
# This only works with types inheriting from Object. Built-in types don't work | |
# with the call api. Built-ins can still be fetched but they cannot be operated | |
# on. | |
# | |
# This can be fixed by subclassing optional and adding type specific methods | |
# that wrap the builtin type. |
# Lets say we want to add a library and an executable, both with the same name. | |
# In this example, it is resman | |
add_library(resman ${src_cpps} ${src_hpps} ) | |
target_link_libraries(resman ${Boost_LIBRARIES} ${LIBYAML} ${LIBFMT}) | |
# | |
# Add resman executable | |
# | |
# We call the executable resman-bin | |
add_executable(resman-bin main.cpp ) |
State machines are everywhere in interactive systems, but they're rarely defined clearly and explicitly. Given some big blob of code including implicit state machines, which transitions are possible and under what conditions? What effects take place on what transitions?
There are existing design patterns for state machines, but all the patterns I've seen complect side effects with the structure of the state machine itself. Instances of these patterns are difficult to test without mocking, and they end up with more dependencies. Worse, the classic patterns compose poorly: hierarchical state machines are typically not straightforward extensions. The functional programming world has solutions, but they don't transpose neatly enough to be broadly usable in mainstream languages.
Here I present a composable pattern for pure state machiness with effects,
function prompt | |
{ | |
# Determine if Powershell is running as Administrator | |
$currentPrincipal = New-Object Security.Principal.WindowsPrincipal( [Security.Principal.WindowsIdentity]::GetCurrent() ) | |
$isAdmin = $currentPrincipal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) | |
$leftCharCount = 0 | |
$middleCharCount = 0 | |
$rightCharCount = 0 |
/* | |
* A function for toggling windowed mode in a C++ SDL app. Fullscreen windows will appear on whichever screen the window was on. | |
* | |
* Could be used in conjunction with SDL_GetDisplayName(int displayIndex) | |
* and SDL_GetNumVideoDisplays(void) to programmatically force fullscreen onto a particular display | |
*/ | |
void toggleWindowed() | |
{ | |
//Grab the mouse so that we don't end up with unexpected movement when the dimensions/position of the window changes. |