1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
|
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 <jgarzik@bitpay.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CADJgMztRdNWyogPCjv64qpUHcvGDiOZDVAkv5Ra8hn25Z9xa8w@mail.gmail.com>
References: <20141215124730.GA8321@savin.petertodd.org>
<CADJgMztRdNWyogPCjv64qpUHcvGDiOZDVAkv5Ra8hn25Z9xa8w@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Mon, 15 Dec 2014 10:20:47 -0500
Message-ID: <CAJHLa0OvDPazCQVonhokm0KopN-WYj0_PP_LO8gPewc1LG5Qow@mail.gmail.com>
To: Btc Drak <btcdrak@gmail.com>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <btcdrak@gmail.com> 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
<div dir=3D"ltr">On Mon, Dec 15, 2014 at 9:57 AM, Btc Drak <span dir=3D"ltr=
"><<a href=3D"mailto:btcdrak@gmail.com" target=3D"_blank">btcdrak@gmail.=
com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>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.</div></div></blockquote></div><div cl=
ass=3D"gmail_extra"><br></div>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.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"=
>Refactoring of data structures comes after that.</div><div class=3D"gmail_=
extra"><br></div><div class=3D"gmail_extra">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</div><div class=3D"gmail_extra"><br></div><di=
v class=3D"gmail_extra">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.</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">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.</div><div cla=
ss=3D"gmail_extra"><br></div><div class=3D"gmail_extra">-- <br><div class=
=3D"gmail_signature">Jeff Garzik<br>Bitcoin core developer and open source =
evangelist<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=A0<a href=3D"https://bitpay.co=
m/" target=3D"_blank">https://bitpay.com/</a></div>
</div></div>
--089e011602a8a59a65050a42ca99--
|
