gavinandresen

Half-baked thoughts exploring a different way of implementing a fully-validating BCH node.

The idea is to shift the storage of full transaction data to wallets, and explore how little data a fully validating node could store. This isn't a problem today (the UTXO set easily fits in the RAM of an inexpensive server-class machine), but might eventually be at very large transaction volumes.

Initial block download is a problem today (it is annoying to have to wait several hours or days to sync up a new node), and this scheme could make it orders of magnitude faster by shifting the time when full transaction data is broadcast from initial block download to new transaction announcement.

paulirish

console.log wrap resolving for your wrapped console logs

I've heard this before:

What I really get frustrated by is that I cannot wrap console.* and preserve line numbers

We enabled this in Chrome DevTools via blackboxing a bit ago.

If you blackbox the script file the contains the console log wrapper, the script location shown in the console will be corrected to the original source file and line number. Click, and the full source is looking longingly into your eyes.

KatieHoban

#While this particular version takes files of the text on my followers and following pages, 
#it can be easily modified to check a past list of followers against a more recent list - 
#just replace following.txt with the "past followers" file and followers.txt with "present followers". 

#encoding may be 'utf-8' depending on the type of files you are using


with open('following.txt', 'r', encoding = 'latin-1') as following_file:
    with open('followers.txt', 'r', encoding = 'latin-1') as followers_file:
        discrepancy = set(following_file).difference(followers_file)

philfreo

#!/usr/bin/perl



use Mysql;
use strict;
use vars qw($school_name);
use vars qw($pass);

require "./cgi-lib.pl";