| #include "EventDispatcher.h" | |
| void EventDispatcher::addListener( Listener *l ) | |
| { | |
| mListeners.push_back(l); | |
| } | |
| void EventDispatcher::removeListener( Listener *l ) | |
| { | |
| mListeners.erase( std::remove( mListeners.begin(), mListeners.end(), l ), mListeners.end() ); |
| [alias] | |
| man = help | |
| unadd = reset HEAD | |
| #co = checkout | |
| co = "!f(){ git checkout \"$@\" && git sup; }; f" | |
| feature = "!git reset HEAD && git checkout -b feature/\"$1\" && git commit --allow-empty -m \"Created feature branch $1\" && git push --set-upstream origin feature/\"$1\" && echo Branch feature/$1 published to origin" | |
| cp = cherry-pick | |
| sma = submodule add | |
| st = status | |
| br = branch |
As pointed out by @johntyree in the comments, using git reflog is easier and more reliable. Thanks for the suggestion!
$ git reflog
1ed7510 HEAD@{1}: checkout: moving from develop to 1ed7510
3970d09 HEAD@{2}: checkout: moving from b-fix-build to develop
1ed7510 HEAD@{3}: commit: got everything working the way I want
70b3696 HEAD@{4}: commit: upgrade rails, do some refactoring
| $find = 'jquery-1\.4\.4' | |
| $replace = 'jquery-1\.5\.1' | |
| $match = '*.cshtml' , '*.vbhtml' | |
| $preview = $true | |
| foreach ($sc in dir -recurse -include $match | where { test-path $_.fullname -pathtype leaf} ) { | |
| select-string -path $sc -pattern $find | |
| if (!$preview) { | |
| (get-content $sc) | foreach-object { $_ -replace $find, $replace } | set-content $sc | |
| } |
| #!/usr/bin/env bash | |
| dir=$(dirname $0) | |
| gconfdir=/apps/gnome-terminal/profiles | |
| echo # This makes the prompts easier to follow (as do other random echos below) | |
| ######################## | |
| ### Select a profile ### | |
| ######################## |
This is a set up for projects which want to check in only their source files, but have their gh-pages branch automatically updated with some compiled output every time they push.
You want a script that does a local compile to e.g. an out/ directory. Let's call this compile.sh for our purposes, but for your project it might be npm build or gulp make-docs or anything similar.
The out/ directory should contain everything you want deployed to gh-pages. That almost always includes an index.html.
| ; ___ _ __ ___ __ ___ | |
| ; / __|_ _ __ _| |_____ / /| __|/ \_ ) | |
| ; \__ \ ' \/ _` | / / -_) _ \__ \ () / / | |
| ; |___/_||_\__,_|_\_\___\___/___/\__/___| | |
| ; An annotated version of the snake example from Nick Morgan's 6502 assembly tutorial | |
| ; on http://skilldrick.github.io/easy6502/ that I created as an exercise for myself | |
| ; to learn a little bit about assembly. I **think** I understood everything, but I may | |
| ; also be completely wrong :-) |
| solution "SDL2_Test" | |
| configurations { "debug", "release" } | |
| location("make/" .. os.get() .. "/") | |
| targetdir("bin/" .. os.get() .. "/%{cfg.buildcfg}/") | |
| objdir("obj/" .. os.get() .. "/%{cfg.buildcfg}/") | |
| project "sdl2_test" | |
| kind "WindowedApp" | |
| language "C" | |
Porting code from Python 2 to Python 3 can be a daunting task. Tools like Futureize or Modernize can do most of the mechanical work for you, and Pylint can find obvious problems with code that's meant to be 2and3 compatible. You should absolutely be using these tools as they identify the lion's share of compatibility problems. Thanks to this work, it's really never been easier to port a large codebase to Python 3.
Even with these tools, however, porting code in a way that ensures identical behavior in Python 2 and Python 3 is tough. Python is a highly dynamic language and there is a huge breadth of changes between Python 2 and Python 3. Also, while we'd all love to work in code bases with 100% unit test coverage, the reality is unfortunately often very different. Given this, it's hard if not impossible for a static analysis tool t
| # You could also do this in emacs probably, but this is easier. | |
| export RUST_SRC_PATH=/path/to/rust/checkout/src | |
| export PATH="$PATH:/path/to/racer/binary/" |