Skip to content

Instantly share code, notes, and snippets.

SamwiseFilmore MggMuggins

Block or report user

Report or block MggMuggins

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
@MggMuggins
MggMuggins / tradingPrices.d
Last active Jan 16, 2017
A little program written in D to calculate the price range of items in LOTR mod trading from the average price.
View tradingPrices.d
import std.stdio;
float readValue (string text) {
float output;
write(text);
readf(" %s", &output);
return output;
}
void printOut (float large, float small) {
@MggMuggins
MggMuggins / fileAppend.d
Created Apr 8, 2017
Small D program to do some stuff with a file.
View fileAppend.d
/*
* Pseudocode
* Read Infomation on what needs to happen from the user
* Open file
* Read each line of the file to an array of strings
* Apply operations to array of strings
* Write each element of the array to the file
*
* Syntax:
* Arguments go in this order: Input File, Output file, Prefix, Suffix
View chrysalis.swift
import Glibc
import Qlift
class ChrysalisFM {
let app = QApplication()
let window = QMainWindow()
let mainWidg = QWidget()
var layout: QHBoxLayout
let v_layout = QVBoxLayout()
@MggMuggins
MggMuggins / styleguide.md
Last active Aug 2, 2017
My Personal D style Guide
View styleguide.md

D Style Guide

My personal style guide for the D programming language. This document outlines best practices that I have found to help with D source code readability and cleanliness.

General Statements

Take a moment to think about what you spend the most time doing when you are writing a program. Is it typing? Certainly not. Is it looking through documentation? Arguably. Is it reading the mess you've written and trying to understand it? Most of the time.

Code readability is very important. If no one (including you!) can read your code, you've done somthing wrong. The vast majority of our time as programmers is spent reading and understanding either our code or someone else's. The majority of this document focuses on code quality as code readability. The rules defined here are designed to make your code easier to read and easier to follow.

One thing this document does not claim to do is to make code easier to write. In fact, it does quite the opposite. Making code easy to read is inherently making it har

View drinkOverlay.sh
#!/bin/bash
# USAGE:
# ./drinkOverlay /path/to/lotr/assets /path/to/output/dir
# $0 $1 $2
cd $1
cd lotr/textures/items
# Make sure we have the overlays
@MggMuggins
MggMuggins / yam.fish
Last active Aug 10, 2017
My tool for installing packages from the AUR. Rename to "yam" and install in /usr/local/bin if you so desire for easy execution.
View yam.fish
#!/usr/bin/fish
# Sources are placed in $HOME/.local/share/yam
# by default. I'll add better argument parsing
# and an option to change it later
set install false
set srcdir $HOME/.local/share/yam/
for arg in $argv
@MggMuggins
MggMuggins / ArtemisDesignGuidelines.md
Last active Sep 7, 2017
A file that describes design goals for the Artemis desktop.
View ArtemisDesignGuidelines.md

Preface

This document describes goals and rules for creating the Artemis desktop. It is written in plain english with an attempt to be clear and consice and is currently small enough to contain both internal design goals and user interface guidelines. It is a heavy work in progress.

We aim to create a desktop shell and applications for the desktop Linux experience. As such, no accomodations will be made specifically to support mobile platforms.

Design Goals

  1. Clean source with good source code documentation.
  2. Efficiency is important. However, when there is a choice between user experience/polish and efficiency, efficiency comes second.
  3. Modularity is key. Making components that can work apart from the whole as well as they can with it. This will allow multiple peices of our codebase to be reused easily.
  4. Consistency in both programming style and archetecture. Programming should be done in a similar way across our codebase. Also, archetecture should be consistent across all parts of the desktop.
@MggMuggins
MggMuggins / build.log
Last active Nov 3, 2017
Ecere Build Log
View build.log
Bootstrapping eC compiling tools...
Building ecere...
Building ec...
Building ecp...
Building ecc...
Building ecs...
All done!
Building 2nd stage ecere...
/usr/include/bits/mathcalls-helper-functions.h:21:1: warning: Undeclared class _Float128
/usr/include/bits/mathcalls-helper-functions.h:25:1: warning: Undeclared class _Float128
@MggMuggins
MggMuggins / Challenges.md
Last active Dec 15, 2017
Python Cheat Sheet for K-8 Coding night
View Challenges.md

Here are some example problems to solve! They are listed roughly by how hard they will be to solve, top to bottom (easiest at the top).

Random Numbers

This isn't a challenge, just something that is used in a number of the other challenges. How to create a random number:

# Allows us to use a function someone else wrote (called "randint")
from random import randint

# Selects a number anywhere between 6 and 12 (including 6 and 12)
my_var = randint(6, 12)
@MggMuggins
MggMuggins / Panic
Last active Dec 23, 2017
authd stuff
View Panic
PANIC: no entry found for key
FILE: ~/Workspace/Rust/Redox/redox/rust/src/libcore/option.rs
LINE: 874
TRACE: FFFFFF40001B2700
FFFFFF40001B2700: FFFFFF000015AC4A
FFFFFF000015AAA0+01AA
rust_begin_unwind
FFFFFF40001B2790: FFFFFF0000198DB4
FFFFFF0000198D30+0084
core::panicking::panic_fmt::h1a71b4e9c4db074d
You can’t perform that action at this time.