Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Y0XST-0001JO-Uo for bitcoin-development@lists.sourceforge.net; Mon, 15 Dec 2014 15:21:13 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bitpay.com designates 209.85.223.181 as permitted sender) client-ip=209.85.223.181; envelope-from=jgarzik@bitpay.com; helo=mail-ie0-f181.google.com; Received: from mail-ie0-f181.google.com ([209.85.223.181]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Y0XSS-00089C-Ua for bitcoin-development@lists.sourceforge.net; Mon, 15 Dec 2014 15:21:13 +0000 Received: by mail-ie0-f181.google.com with SMTP id tp5so10900238ieb.40 for ; Mon, 15 Dec 2014 07:21:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zLCdHwTjudmdxNsfZ5UoMcvP0H4yposZo/o3keo3+Kg=; b=i5qn8hFNrxWGkhQqwwBYo7a80uzsV/xs/74y50QM/+ERdxhaqFgtP1DvKvHA3Yk5ng ES49uQnlOlVgM7dbu1E7Z7C9aHl56seJ5G4S3HCiy/ugmHF82gHrxbuU0tS5DwWgFR6M miNYmaMNjVuR3N7iO6H20XxxVt1J6FT97lmb+oddJITwd+Z1E2Xbn1NeMY0ogma+atsE fGo2NZDOrG69XNZp4cd7hKnHNtxENFdmCh7U/e1UdELhk/zXNHpNzBnFOFcgZuu0x5RB 7zB6OsjSm7rhf8ilZvl2ddC2dw7RQ5M6DL67flKs+ZDkjKSbScJY5jm1FnyqBBTwdqpy vTew== X-Gm-Message-State: ALoCoQkYSrO6MOzFjtSyqrFzhig+UsfQwbrhRUovmcoaDfDfDDN6rO3ACTTddI3CtJFYoF9y1kdH X-Received: by 10.50.43.136 with SMTP id w8mr17933658igl.33.1418656867516; Mon, 15 Dec 2014 07:21:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.76 with HTTP; Mon, 15 Dec 2014 07:20:47 -0800 (PST) In-Reply-To: References: <20141215124730.GA8321@savin.petertodd.org> From: Jeff Garzik Date: Mon, 15 Dec 2014 10:20:47 -0500 Message-ID: To: Btc Drak Content-Type: multipart/alternative; boundary=089e011602a8a59a65050a42ca99 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Y0XSS-00089C-Ua Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Recent EvalScript() changes mean CHECKLOCKTIMEVERIFY can't be merged X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 15:21:14 -0000 --089e011602a8a59a65050a42ca99 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 15, 2014 at 9:57 AM, Btc Drak wrote: > We all want to see more modular code, but the first steps should just be > to relocate blocks of code so everything is more logically organised in > smaller files (especially for consensus critical code). Refactoring should > come in a second wave preferably after a stable release. > This is my opinion as well. In the Linux kernel, we often were faced with a situation where you have a One Big File driver with > 1MB of source code. The first step was -always- raw code movement, a brain-dead breaking up of code into logical source code files. Refactoring of data structures comes after that. While not always money-critical, these drivers Had To Keep Working. We had several situations where we had active users, but zero hardware access for debugging, and zero access to the vendor knowledge (hardware documentation, engineers). Failure was not an option. ;p Performing the dumb Break Up Files step first means that future, more invasive data structures are easier to review, logically segregated, and not obscured by further code movement changes down the line. In code such as Bitcoin Core, it is important to think about the _patch stream_ and how to optimize for reviewer bandwidth. The current stream of refactoring is really a turn-off in terms of reviewing, sapping reviewer bandwidth by IMO being reviewer-unfriendly. It is a seemingly never-ending series of tiny refactor-and-then-stuff-in-a-class-and-make-it-pretty-and-do-all-the-work. Some change is in order, gentlemen. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ --089e011602a8a59a65050a42ca99 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Dec 15, 2014 at 9:57 AM, Btc Drak <btcdrak@gmail.= com> wrote:
We all want to= see more modular code, but the first steps should just be to relocate bloc= ks of code so everything is more logically organised in smaller files (espe= cially for consensus critical code). Refactoring should come in a second wa= ve preferably after a stable release.

This is my opinion as well.=C2=A0 In the Linu= x kernel, we often were faced with a situation where you have a One Big Fil= e driver with > 1MB of source code.=C2=A0 The first step was -always- ra= w code movement, a brain-dead breaking up of code into logical source code = files.

Refactoring of data structures comes after that.

While not always money-critical= , these drivers Had To Keep Working.=C2=A0 We had several situations where = we had active users, but zero hardware access for debugging, and zero acces= s to the vendor knowledge (hardware documentation, engineers).=C2=A0 Failur= e was not an option. =C2=A0;p

Performing the dumb Break Up Files step first means= that future, more invasive data structures are easier to review, logically= segregated, and not obscured by further code movement changes down the lin= e.=C2=A0 In code such as Bitcoin Core, it is important to think about the _= patch stream_ and how to optimize for reviewer bandwidth.

The current stream of= refactoring is really a turn-off in terms of reviewing, sapping reviewer b= andwidth by IMO being reviewer-unfriendly.=C2=A0 It is a seemingly never-en= ding series of tiny refactor-and-then-stuff-in-a-class-and-make-it-pretty-a= nd-do-all-the-work.=C2=A0 Some change is in order, gentlemen.

--
Jeff Garzik
Bitcoin core developer and open source = evangelist
BitPay, Inc. =C2=A0 =C2=A0 =C2=A0https://bitpay.com/
--089e011602a8a59a65050a42ca99--