Date: Wed, 10 Dec 2014 13:19:10 -0800 From: Garrett Cooper <yaneurabeya@gmail.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: Mark Peek <mp@freebsd.org>, svn-src-projects@freebsd.org, src-committers@freebsd.org, Garrett Cooper <ngie@freebsd.org>, Ian Lepore <ian@freebsd.org> Subject: Re: svn commit: r275601 - projects/building-blocks Message-ID: <FDAF179A-B085-4EE2-AE58-445A2B64071C@gmail.com> In-Reply-To: <20141210210307.GX25139@funkthat.com> References: <201412080743.sB87h3j9044019@svn.freebsd.org> <1418054094.1064.147.camel@revolution.hippie.lan> <5485D8B5.90604@FreeBSD.org> <20141210210307.GX25139@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_5C7FD595-2BE0-4D56-9967-021EF5C907DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 10, 2014, at 13:03, John-Mark Gurney <jmg@funkthat.com> wrote: > Mark Peek wrote this message on Mon, Dec 08, 2014 at 08:58 -0800: >> On 12/8/14 7:54 AM, Ian Lepore wrote: >>> On Mon, 2014-12-08 at 07:43 +0000, Garrett Cooper wrote: >>>> Author: ngie >>>> Date: Mon Dec 8 07:43:02 2014 >>>> New Revision: 275601 >>>> URL: https://svnweb.freebsd.org/changeset/base/275601 >>>>=20 >>>> Log: >>>> - Document why usr.bin/vi needs to be built as part of = bootstrap-tools >>>> ...snip... >>>=20 >>> Is there any chance someone who understands vi could evaluate what = it's >>> being used for and perhaps eliminate it? I know just enough about = vi to >>> get out of it if I accidentally get in. >>>=20 >>> When I looked into this a few days ago it appears to be using it to = sort >>> the data before compiling (an optimization that problably hasn't = been >>> important to do since the 90s). Could another existing build tool = such >>> as awk do the job? >>=20 >> My reading of that code agrees with yours in that it is using 'ex' to=20= >> prioritize some terminal entries in the termcap file. However, it is = then=20 >> hashed into a berkeleydb via cap_mkdb which should render the initial=20= >> prioritization useless. Rather than rewriting it I would suggest = completely=20 >> removing the reordering and the ex dependency. >=20 > There was some dicussion about removing some of the various databases, > and having commonly used entries at the top would help in this case.. I was looking at Fedora 20=92s termcap just the other day, and I was = surprised at the brevity in the file (only a couple entries for = =93xterm=94). They also have it split into multiple files instead of = just one file too (/usr/share/vte/termcap-0.0/xterm). Maybe this would = be a good move going forward (or not=85???)? Why should the .db files be removed? I think reducing the bloat from the = files due to overestimated bucket sizes would be a good first start = instead of just removing them altogether (I noticed that termcap.db has = the same bloat problem services.db has). Thanks! --Apple-Mail=_5C7FD595-2BE0-4D56-9967-021EF5C907DB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUiLjOAAoJEMZr5QU6S73eBdUIAI6M8Pp9cO6j4W9JVgHSLoV3 JrDR+fgsiwVMpx1xLCaF/9rVcd4ITE/e7MJAX0rowubaMMM148ZCrwORY4WU9zPt mOfRhEBq8LZ4CWmOyfj7lRbyWcyB3N997JcS2Q5j6za9XwXbRcRksFCJq429fJZZ 4x9Q2BBT4w3o6FTNheN0/kFr8dDJLqY3FHn2xFN4krzJMCDZnIOQnzPgkmEV04II 6s6kBeFgzc6lXfkEHUGABdTwUwE1llVTeOq4JzH0J9Vkl/g9QaS45IrZFpcOph5q fYwOFxH+35FraFN9jNOc17h9XXTWViNbYbd0v33RctqLxQd2n3seb2rMGlxhaF0= =w2aU -----END PGP SIGNATURE----- --Apple-Mail=_5C7FD595-2BE0-4D56-9967-021EF5C907DB--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FDAF179A-B085-4EE2-AE58-445A2B64071C>