From owner-freebsd-stable@FreeBSD.ORG Mon Dec 9 18:52:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D8C8A0B; Mon, 9 Dec 2013 18:52:39 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BF81C155F; Mon, 9 Dec 2013 18:52:38 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa04.fnfis.com (8.14.5/8.14.5) with ESMTP id rB9IqbQK026181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 9 Dec 2013 12:52:37 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.7]) by LTCFISWMSGHT05.FNFIS.com ([10.132.206.16]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 12:52:36 -0600 From: "Teske, Devin" To: George Mitchell Subject: Re: BIND segway -> python -> first-class ports -> parsing Thread-Topic: BIND segway -> python -> first-class ports -> parsing Thread-Index: AQHO9Qraf9UgZprqqka7QwRtv3aUDJpMmiWA Date: Mon, 9 Dec 2013 18:52:36 +0000 Message-ID: References: <529E8C53.6020208@freebsd.org> <20131204060246.GV2951@home.opsec.eu> <52A12843.3010204@freebsd.org> <0BFC927B-D72E-4926-BB3D-2C000F310BDD@fisglobal.com> <7271C4C4-7BAB-4DA7-9E10-49D5B2DB8964@mu.org> <52A51438.4090200@bluerosetech.com> <8D54491D-5A1C-4D30-AD48-12336D0726DC@gsoft.com.au> <5C28ECE3-CE0C-44A9-A7CD-08A01C714594@fisglobal.com> <52A5A7D4.4080404@m5p.com> <4EE82B0A-44A1-4B0E-94F0-C101625108AC@fisglobal.com> In-Reply-To: <4EE82B0A-44A1-4B0E-94F0-C101625108AC@fisglobal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.72, 1.0.14, 0.0.0000 definitions=2013-12-09_02:2013-12-09,2013-12-09,1970-01-01 signatures=0 Cc: Devin Teske , "freebsd-stable@freebsd.org Stable" , "Teske, Devin" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Devin Teske List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 18:52:39 -0000 On Dec 9, 2013, at 10:17 AM, Teske, Devin wrote: >=20 > On Dec 9, 2013, at 9:27 AM, Teske, Devin wrote: >=20 >>=20 >> On Dec 9, 2013, at 3:21 AM, George Mitchell wrote: >>=20 >>> On 12/09/13 00:39, Teske, Devin wrote: >>>> [...] >>>> But keep in mind... >>>>=20 >>>> The real power is not in shell, the real power is in POSIX. I have the= supreme >>>> pleasure of having developed C programs that can compile on: >>>>=20 >>>> + Windows using MinGW >>>> + Mac OS X using ... gcc >>>> + Mac OS Classic using SIOUX >>>> NB: Simple Input/Output User eXchange >>>> + Linux, Unix, BSD, AIX, OSF1, Amiga, etc. >>>>=20 >>>> All with a single source package. It's the power of POSIX. >>>>=20 >>>> So whenever I've made a choice to target "/bin/sh" as a platform, it's >>>> always *only* ever been based on the decision of "reach". >>>>=20 >>>> Shell quite often doesn't cut it. Prior to shell, I spent my time tryi= ng >>>> building libraries used to abstract higher functionality for cross-pla= tform >>>> compatibility. And, until now, that's primarily been in C -- shell is = only a >>>> recent excursion because I feel I've *finally* nailed the right recipe= s for >>>> that. >>>>=20 >>>> I'm actually a bit worried that Python and Lua don't have the reach th= at C does, >>>> let alone shell. >>>>=20 >>>=20 >>> +1 to a well-reasoned and insightful post. >>>=20 >>> What are your thoughts on the other part of Mr. Perlstein's concern: the >>> lack of what I would like to call a Grand Unified Schema? Perhaps such >>> a thing belongs in POSIX as well, as it would be intriguing to be able >>> to write tools (in whatever language) that could rely on uniformly >>> parseable data (i.e. sizes always known to be in eight-bit bytes, text >>> in UTF-8 [let's say], time in seconds, numbers in decimal without >>> commas, key-value pairs in a specified format, consistent meaning for >>> key names). -- George >>=20 >> Hi George, >>=20 >> I'm glad you asked. >=20 > My experience tells me that 90% of the Grand Unified Schema is adapting > a single interface so that the following two issues are dealt with: >=20 > [snip] >=20 > 1. Centralized parsing library >=20 > 2. Centralized mangling library >=20 #1 I've conceptualized into code as "libfigpar". For #2, I'm thinking something similar, but libfigman (for "Con[fig]uration= [Man]gler") ;D --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.