Skip to content

Instantly share code, notes, and snippets.

View adragomir's full-sized avatar

Andrei Dragomir adragomir

View GitHub Profile
#include <stdio.h>
#include <stdint.h>
#include <assert.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <fcntl.h>
#include <unistd.h>

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

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <assert.h>
#include <string.h>
#define streq(a, b) (!strcmp((a), (b)))
#ifndef __USE_GNU
#define __USE_GNU
#endif
@pervognsen
pervognsen / gob.h
Last active March 31, 2024 22:42
gob.h
// My investigations on the C standard compliance of Gob and related techniques:
// https://gist.github.com/pervognsen/5249a405fe7d76ded1cf08ed50fa9176
#pragma once
#include <stdint.h>
#pragma pack(push, 8)
#if __cplusplus >= 201103L || (__cplusplus && _MSC_VER >= 1900)
#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(); }
@barosl
barosl / add.c
Created July 26, 2015 07:26
Function overloading in C
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int addi(int a, int b) {
return a + b;
}
char *adds(char *a, char *b) {
char *res = malloc(strlen(a) + strlen(b) + 1);
@ocornut
ocornut / (Archived) imgui_memory_editor.h
Last active August 28, 2024 05:01
Mini memory editor for dear imgui (to embed in your game/tools)
// Mini memory editor for Dear ImGui (to embed in your game/tools)
// Animated GIF: https://twitter.com/ocornut/status/894242704317530112
// THE MEMORY EDITOR CODE HAS MOVED TO GIT:
// https://github.com/ocornut/imgui_club/tree/master/imgui_memory_editor
// Click "Revisions" on the Gist to see old version.
@non
non / answer.md
Last active February 28, 2025 11:46
answer @nuttycom

What is the appeal of dynamically-typed languages?

Kris Nuttycombe asks:

I genuinely wish I understood the appeal of unityped languages better. Can someone who really knows both well-typed and unityped explain?

I think the terms well-typed and unityped are a bit of question-begging here (you might as well say good-typed versus bad-typed), so instead I will say statically-typed and dynamically-typed.

I'm going to approach this article using Scala to stand-in for static typing and Python for dynamic typing. I feel like I am credibly proficient both languages: I don't currently write a lot of Python, but I still have affection for the language, and have probably written hundreds of thousands of lines of Python code over the years.

@somebox
somebox / osx-setup.sh
Last active December 11, 2021 13:05 — forked from foz/osx-setup.sh.md
Set up an OSX machine from zero to awesome. Uses Homebrew (and cask, fonts, etc). Focused on Ruby/Rails development, includes rvm, xquartz, editor fonts, sublime text, and many tools.
#!/bin/bash
# A script to set up a new mac. Uses bash, homebrew, etc.
# Focused for ruby/rails development. Includes many utilities and apps:
# - homebrew, rvm, node
# - quicklook plugins, terminal fonts
# - browsers: chrome, firefox
# - dev: iterm2, sublime text, postgres, chrome devtools, etc.
# - team: slack, dropbox, google drive, skype, etc

Git DMZ Flow

I've been asked a few times over the last few months to put together a full write-up of the Git workflow we use at RichRelevance (and at Precog before), since I have referenced it in passing quite a few times in tweets and in person. The workflow is appreciably different from GitFlow and its derivatives, and thus it brings with it a different set of tradeoffs and optimizations. To that end, it would probably be helpful to go over exactly what workflow benefits I find to be beneficial or even necessary.

  • Two developers working on independent features must never be blocked by each other
    • No code freeze! Ever! For any reason!
  • A developer must be able to base derivative work on another developer's work, without waiting for any third party
  • Two developers working on inter-dependent features (or even the same feature) must be able to do so without interference from (or interfering with) any other parties
  • Developers must be able to work on multiple features simultaneously, or at lea