Skip to content

Instantly share code, notes, and snippets.

🐺
aroo

Chris Allen bitemyapp

Block or report user

Report or block bitemyapp

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
View effective_modern_cmake.md

Effective Modern CMake

Getting Started

For a brief user-level introduction to CMake, watch C++ Weekly, Episode 78, Intro to CMake by Jason Turner. LLVM’s CMake Primer provides a good high-level introduction to the CMake syntax. Go read it now.

After that, watch Mathieu Ropert’s CppCon 2017 talk Using Modern CMake Patterns to Enforce a Good Modular Design (slides). It provides a thorough explanation of what modern CMake is and why it is so much better than “old school” CMake. The modular design ideas in this talk are based on the book [Large-Scale C++ Software Design](https://www.amazon.de/Large-Scale-Soft

View keybase.md

Keybase proof

I hereby claim:

  • I am bitemyapp on github.
  • I am bitemyapp (https://keybase.io/bitemyapp) on keybase.
  • I have a public key whose fingerprint is 81D6 75D8 29F1 8485 FDBD B4E2 5809 8478 C9E4 05E5

To claim this, I am signing this object:

@bitemyapp
bitemyapp / QC.hs
Created Mar 8, 2018 — forked from ekmett/QC.hs
Using Quantified Constraints for Optics -- untypechecked (no compiler available)
View QC.hs
{-# language TypeInType, QuantifiedConstraints, ConstraintKinds, RankNTypes, UndecidableInstances, MultiParamTypeClasses, TypeFamilies, KindSignatures #-}
module QC where
import Data.Constraint
import Data.Functor.Contravariant
import Data.Kind
import Data.Profunctor
type C = (Type -> Type) -> (Type -> Type -> Type) -> Constraint
@bitemyapp
bitemyapp / haskell-app-layers.md
Created Jan 2, 2018 — forked from parsonsmatt/haskell-app-layers.md
A basic draft of a future blog post
View haskell-app-layers.md

The question of "How do I design my application in Haskell?" comes up a lot. There's a bunch of perspectives and choices, so it makes sense that it's difficult to choose just one. Do I use plain monad transformers, mtl, just pass the parameters manually and use IO for everything, the ReaderT design pattern, free monads, freer monads, some other kind of algebraic effect system?!

The answer is: why not both/all?

Lately, I've been centering on a n application design architecture with roughly three layers:

Layer 1:

newtype AppT m a = AppT { unAppT :: ReaderT YourStuff m a } deriving ............ The ReaderT Design Pattern, essentially. This is what everything gets boiled down to, and what everything eventually gets interpreted in. This type is the backbone of your app. For some components, you carry around some info/state (consider [MonadMetrics](https://hackage

@bitemyapp
bitemyapp / elm_handlers.js
Created Nov 7, 2017 — forked from wmakley/elm_handlers.js
jQuery-based utilities for things that are hard to do in Elm. Modify as desired. It is used in a project that already depends on jQuery, but it only really needs jQuery for attaching event handlers to the app container, and normalizing key press events.
View elm_handlers.js
/*
JSCmd.elm
==========
port module JSCmd exposing (..)
port focus : String -> Cmd msg
@bitemyapp
bitemyapp / SMBDIS.ASM
Created Oct 16, 2017 — forked from 1wErt3r/SMBDIS.ASM
A Comprehensive Super Mario Bros. Disassembly
View SMBDIS.ASM
;SMBDIS.ASM - A COMPREHENSIVE SUPER MARIO BROS. DISASSEMBLY
;by doppelganger (doppelheathen@gmail.com)
;This file is provided for your own use as-is. It will require the character rom data
;and an iNES file header to get it to work.
;There are so many people I have to thank for this, that taking all the credit for
;myself would be an unforgivable act of arrogance. Without their help this would
;probably not be possible. So I thank all the peeps in the nesdev scene whose insight into
;the 6502 and the NES helped me learn how it works (you guys know who you are, there's no
View main.rs
#![cfg_attr(any(target_os = "ios", target_os = "android"), no_main]
fn main() {
main2();
}
#[cfg(any(target_os = "ios", target_os = "android"))]
#[no_mangle]
#[allow(non_snake_case)]
pub extern "C" fn SDL_main() -> i32 {
View ios_and_android.md

Where you able to produce a binary directly from the Rust build tools that you could submit to the app/play store?


Not quite, but I tried to get as close to that as was reasonably possible. Alas, things ended up a little convoluted.

For iOS, I have a nearly empty Xcode project with a build script that copies my cargo produced executable into the .app that Xcode generates (before Xcode signs it). The build script also uses lipo to merge the executables for each architecture I’m targeting (e.g. armv7 and aarch64 for non-simulator devices) into a single, universal binary.

On top of that, there are various iOS-y things that need to happen before my application’s main method is called. SDL2 provides the Objective-C code that does all of that. In a C or C++ game, SDL2 renames main to SDL_main, and then [inserts its own mai

View transformers.hs
module Transformer where
import Control.Monad.Reader
import Control.Monad.Trans
data Config = Config { filename :: String } deriving (Show)
c = Config { filename = "a.txt" }
loadFile :: ReaderT Config IO String
View transformers.hs
module Transformer where
import Control.Monad.Reader
import Control.Monad.Trans
data Config = Config { filename :: String } deriving (Show)
c = Config { filename = "a.txt" }
loadFile :: ReaderT Config IO String
You can’t perform that action at this time.