Tetris-playing computer programs have recently become more popular with the development of Zetris (mat1jaczyyy), a port of MisaMino (misakamm) to the official Tetris game Puyo Puyo Tetris. Since then, new programs have been developed such as Cold Clear (MinusKelvin), Tetras (traias), Wataame (ameyasu), and Hikari (SoRA_X7). Currently, all of these independently solve the problem of interfacing with the host game. This duplicates a lot of work between these projects, especially since this interfacing code is generally not made public due to concerns about such programs being used to cheat in online
//! Port of https://github.com/mogzol/ScpDriverInterface/ | |
use winapi::um::setupapi::{ | |
SetupDiDestroyDeviceInfoList, | |
SetupDiEnumDeviceInterfaces, | |
SetupDiGetClassDevsW, | |
SetupDiGetDeviceInterfaceDetailW, | |
SP_DEVICE_INTERFACE_DATA, | |
SP_DEVINFO_DATA, | |
DIGCF_PRESENT, |
#lang racket | |
; Inspired by https://blog.adamant-lang.org/2019/operator-precedence/ | |
; | |
; This racket file implements grouping infix operators with intransitive operator precedence, | |
; a task that the above blog post does not attempt to describe. This implementation does not handle | |
; ternary operators, nor the breifly-mentioned extension that allows the left and right sides of an | |
; operator to have different precedence relationships. | |
; | |
; This implementation observes that using only the intransitive relation rules, it is impossible to |
A programming language designed for game development.
#!/bin/bash | |
usage() { | |
echo "Usage:" | |
echo " $0 gen <key>" | |
echo " $0 view [key]" | |
echo " $0 add <key> <value>" | |
echo " $0 copy <key>" | |
echo " $0 remove <key>" | |
} |
Interfaces are references that live on the heap. These are obviously compatible with reference types, since the interface object is laid out as a pointer to the object and a pointer to the virtual function table. For value types, we have to allocate space for the type on the heap and point to that in the interface object.
Since value types are semantically immutable, they cannot modify their state in any of these interface methods, making them semantically different from class implementations, which can. This practically invisible difference in semantics is a flaw in the direct approach to this problem
This would be done, probably through another keyword (like trait
) to specify that the implementor of the interface is not allowed to mutate the underlying object. This causes confusion in reference type methods. What is the type of this
? this
is already constant, since it is illegal to assign to this
. Tha