adragomir

VERSION = \"1.0.0\"

PREFIX ?= out
INCDIR	= inc
SRCDIR	= src
LANG	= c
OBJDIR	= .obj

MODULE		= binary_name
CC		= gcc

adragomir

#pragma once

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

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

adragomir

class Protobuf261 < Formula
  desc "Protocol buffers - Google data interchange format"
  homepage "https://github.com/google/protobuf/"

  stable do
    url "https://github.com/google/protobuf/releases/download/v2.6.1/protobuf-2.6.1.tar.bz2"
    sha256 "0a2f8533b2e0587a2b4efce0c4c8aea21bbfae1c41c466634d958dedf580f6aa"

    # Fixes the unexpected identifier error when compiling software against protobuf:
    # https://github.com/google/protobuf/issues/549

adragomir

(define emit printf)

(define (compile exp)
  (cond
    [(fixnum? exp)   (emit "push ~a~%" exp)]
    [(eq? '+ (car exp))    (begin
                              (compile (cadr exp))
                              (compile (caddr exp))
                              (emit "pop eax~%")
                              (emit "pop ebx~%")

adragomir

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

struct lbp_serializer
{
    int32_t DataVersion;
    FILE* FilePtr;

adragomir

#define _CRT_SECURE_NO_WARNINGS
#include <string.h>
#include <stdio.h>
#include <windows.h>
#pragma warning (disable: 4146)
#include <stdint.h>

#ifdef _DEBUG
#define Assert(x) \
    if (!(x)) { MessageBoxA(0, #x, "Assertion Failure", MB_OK); __debugbreak(); }

adragomir

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

adragomir

things I don't know

I took this list from What CS majors should know.

I think it is fun to list things I don't know so I did it =D. I actually found it to be a cool exercise -- maybe I should do a fun graphics project and learn about Open GL!

i wrote this because, while i think the things on this list are potentially worth knowing, and I actually think it's an awesome list of project ideas as well as good food for thought for people developing CS curricula (many of the things I don't know are great exercises!) -- I thought it was really weird to say that every CS student should know all of them. I have a CS degree and I learned very few of the things I do know inside my degree.

I classify "do know" as anything that I have a reasonable grasp of or at least some basic experience with -- the kind of experience I'd expect a CS student to be able to get. If I say I don't know something, it means either I know pretty much nothing about it (for "gr

adragomir

#include <assert.h>
#include <stddef.h>
#include <stdio.h>
#include <stdint.h>

#define tag(x) ((ptrdiff_t)&Tag##x)
#define is(x, T) ((x)->tag == tag(T))
#define as(x, T) ((struct T *)variant_cast((void *)(x), tag(T)))

static inline void*

adragomir

	.globl	_parse
	.align	4, 0x90
_parse:                                 ## @parse
	.cfi_startproc
## BB#0:
	push	rbp
Ltmp8:
	.cfi_def_cfa_offset 16
Ltmp9:
	.cfi_offset rbp, -16