THIS GIST WAS MOVED TO TERMSTANDARD/COLORS
REPOSITORY.
PLEASE ASK YOUR QUESTIONS OR ADD ANY SUGGESTIONS AS A REPOSITORY ISSUES OR PULL REQUESTS INSTEAD!
Lisp interpreter in 90 lines of C++ | |
I've enjoyed reading Peter Norvig's recent articles on Lisp. He implements a Scheme interpreter in 90 lines of Python in the first, and develops it further in the second. | |
Just for fun I wondered if I could write one in C++. My goals would be | |
1. A Lisp interpreter that would complete Peter's Lis.py test cases correctly... | |
2. ...in no more than 90 lines of C++. | |
Although I've been thinking about this for a few weeks, as I write this I have not written a line of the code. I'm pretty sure I will achieve 1, and 2 will be... a piece of cake! |
Latency Comparison Numbers (~2012) | |
---------------------------------- | |
L1 cache reference 0.5 ns | |
Branch mispredict 5 ns | |
L2 cache reference 7 ns 14x L1 cache | |
Mutex lock/unlock 25 ns | |
Main memory reference 100 ns 20x L2 cache, 200x L1 cache | |
Compress 1K bytes with Zippy 3,000 ns 3 us | |
Send 1K bytes over 1 Gbps network 10,000 ns 10 us | |
Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD |
/** woocommerce remove elements **/ | |
remove_action( 'woocommerce_before_main_content','woocommerce_breadcrumb', 20, 0); | |
remove_action( 'woocommerce_before_shop_loop','woocommerce_result_count', 20, 0); | |
remove_action( 'woocommerce_before_shop_loop','woocommerce_catalog_ordering', 30, 0); | |
remove_action( 'woocommerce_single_product_summary', 'woocommerce_template_single_title', 5 ); | |
remove_action( 'woocommerce_single_product_summary', 'woocommerce_template_single_meta', 40 ); | |
remove_action( 'woocommerce_single_product_summary', 'woocommerce_template_single_price', 10 ); | |
remove_action( 'woocommerce_after_single_product_summary','woocommerce_output_product_data_tabs', 10, 0); |
THIS GIST WAS MOVED TO TERMSTANDARD/COLORS
REPOSITORY.
PLEASE ASK YOUR QUESTIONS OR ADD ANY SUGGESTIONS AS A REPOSITORY ISSUES OR PULL REQUESTS INSTEAD!
Updated: Just use qutebrowser (and disable javascript). The web is done for.
<script type="application/javascript"> | |
<!-- | |
function install (aEvent) | |
{ | |
for (var a = aEvent.target; a.href === undefined;) a = a.parentNode; | |
var params = { | |
"Foo": { URL: aEvent.target.href, | |
IconURL: aEvent.target.getAttribute("iconURL"), | |
Hash: aEvent.target.getAttribute("hash"), | |
toString: function () { return this.URL; } |
# Load | |
Split-Path $MyInvocation.MyCommand.Path -Parent | Push-Location | |
Get-ChildItem poco_*.ps1 | %{. $_} | |
Pop-Location | |
function Select-Poco | |
{ | |
Param | |
( | |
[Object[]]$Property = $null, |
/** | |
* Base contract that all upgradeable contracts should use. | |
* | |
* Contracts implementing this interface are all called using delegatecall from | |
* a dispatcher. As a result, the _sizes and _dest variables are shared with the | |
* dispatcher contract, which allows the called contract to update these at will. | |
* | |
* _sizes is a map of function signatures to return value sizes. Due to EVM | |
* limitations, these need to be populated by the target contract, so the | |
* dispatcher knows how many bytes of data to return from called functions. |
#!/usr/bin/env python2.7 | |
"""Find the Access Codes | |
In order to destroy Commander Lambda's LAMBCHOP doomsday device, you'll need | |
access to it. But the only door leading to the LAMBCHOP chamber is secured with | |
a unique lock system whose number of passcodes changes daily. Commander Lambda | |
gets a report every day that includes the locks' access codes, but only she | |
knows how to figure out which of several lists contains the access codes. You | |
need to find a way to determine which list contains the access codes once |