aphyr

:- use_module(library(pairs)).
:- use_module(library(reif)).

not_in_list(K, L) :-
  if_((L = []),
    true,
    ([X | More] = L,
     dif(K, X),
     not_in_list(K, More))).

aphyr

:- use_module(library(reif)).

axiom([quote, X], X).

axiom([atom, X], R) :-
  axiom(X, XR),
  ((atomic(XR),   R = t, !) ;
   (compound(XR), R = [])).

axiom([eq, X, Y], R) :-

nicebyte

#pragma once

#define DYN_ARR_OF(type) struct  { \
  type *data; \
  type *endptr; \
  uint32_t capacity; \
}

#if !defined(__cplusplus)
#define decltype(x) void*

OswaldHurlem

#include <stdlib.h>
#include <stdint.h>
#include <stdio.h>
#include <time.h>
#include <string.h>

struct lbp_serializer
{
    int32_t DataVersion;
    FILE* FilePtr;

pervognsen

// frontend with abstract backend

void parse_expr(expr_t *expr);

void parse_base_expr(expr_t *expr) {
    if (token == NUMBER) {
        do_number_expr(expr, token_value);
        next_token();
    } else if (match_token('(')) {
        parse_expr(expr);

vurtun

API Design: Modular Data-oriented processes (June-2017)

This is the second entry in my series about API design. While I wrote about granularity and request based APIs in my last post I want to write about API design and code architecture for modular data-oriented process this time. This is basically the write up of my findings while writing and finishing the core of my current GUI research quarks.

Actually sparking my interest for writing up my findings however was rasmusbarr@github (rasmusbarr@twitter) releasing his small data-oriented and SIMD-optimized 3D rigid body physics library. I noticed a lot of overlap in design between his physics and my GUI library and wanted to write up some general thoughts about what seems

pervognsen

#include <stdlib.h>
#include <string.h>
#include <stdarg.h>
#include <stdio.h>
#include <stdint.h>

#define WIN32_LEAN_AND_MEAN
#include <windows.h>

void error(const char *str) {

vurtun

Graphical User Interfaces

For the last few weeks I spend some time coding, writing and cleaning up my notes from almost a year since I published nuklear.

Basically this is a possible implementation for a graphical user interface builder backend with support for an immediate mode style API. So it provides a way to define non-mutating UI state, an immediate mode style API for dynamic UI components (lists,trees,...) and a combination of both.

The core implementation is ~800 LOC without any kind of default widgets or extensions. At first this seems quite counter intuitive. However since the inherent design allows for lots of different ways to define any widget like buttons it does not make sense to provide a specific default implementation. The way this code was architectured furthermore removes the need for style/skinning configurations used in Nuklear since widget painting is just calling a small

pervognsen

// The stack is 8-byte aligned.
#define ALIGN(p) ((uint64_t *)(((uintptr_t)(p) + 7) & ~7))
#define STACK(stack, size) uint64_t *_stack = ALIGN(stack), *_stack_end = (uint64_t *)((char *)(stack) + size)
#define PUSH(x) do { memcpy(_stack, &x, sizeof(x)); _stack += (sizeof(x) + 7) / 8; } while (0)
#define POP(x) do { _stack -= (sizeof(x) + 7) / 8; memcpy(&x, _stack, sizeof(x)); } while (0)

#if __GNUC__
// Use computed gotos on GCC-compatible compilers (including Clang). 
#define JOIN(x, y) x##y
#define LABEL(name) JOIN(label, name)

garybernhardt

This document has moved!

It's now here, in The Programmer's Compendium. The content is the same as before, but being part of the compendium means that it's actively maintained.