Date: Tue, 10 Dec 2013 00:59:00 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: "army.of.root" <army.of.root@gmail.com> Cc: Devin Teske <dteske@freebsd.org>, "freebsd-stable@freebsd.org Stable" <freebsd-stable@freebsd.org>, "Teske, Devin" <Devin.Teske@fisglobal.com> Subject: Re: BIND segway -> python -> first-class ports Message-ID: <66114E14-6B6A-461B-8F35-D821A8A56C80@fisglobal.com> In-Reply-To: <52A65CBC.4030503@googlemail.com> References: <mailman.313.1386119137.1390.freebsd-stable@freebsd.org> <529E8C53.6020208@freebsd.org> <Pine.GSO.4.64.1312032238220.15897@sea.ntplx.net> <20131204060246.GV2951@home.opsec.eu> <CAN6yY1udd1GbQVK4YR-yxNe7vqX3S1refQwch2cafRnMv=W4mA@mail.gmail.com> <CAFHbX1K1AgZ4FaEjP_vvnfiwDWsj6M3ysEVn4taX_4_p%2B1Z8Nw@mail.gmail.com> <CAN6yY1tjS=uk1Qr-sBN0PT73xpP%2BBxL8wLt9aosYfWf751rC5A@mail.gmail.com> <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> <F7052902-C640-4AAB-92D5-6A15C6C0A5EE@fisglobal.com> <52A65CBC.4030503@googlemail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 9, 2013, at 4:13 PM, army.of.root wrote: > Am 09/12/13 18:27, schrieb Teske, Devin: >>=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. Because this is actually something that I've been >> evaluating since (gosh) 2001. >>=20 >> NB: In 2002 I was a victim of a burglary and lost the original version of >> this solution. Thank God, a buddy in France was using it in his open sou= rce >> software so I had a backup (somewhat). Unfortunately, his version was ol= d, >> but at least it was enough to reconstruct in 2013 (it wasn't until this = year that >> I had excellent reason to bug my buddy kang to go digging for it). >>=20 >> I introduce to you ... libfigpar... >>=20 >> http://druidbsd.cvs.sf.net/viewvc/druidbsd/libfigpar/ >>=20 >> ASIDE: The name figpar stands for "con[fig]uration [par]ser". >>=20 >> You can see it in action here... >>=20 >> http://druidbsd.cvs.sf.net/viewvc/druidbsd/sysconf/ >> -- reads loader.conf(5) and sysctl.conf(5) using libfigpar >> http://druidbsd.cvs.sf.net/viewvc/druidbsd/fdpv/ >> -- reads ~/.dialogrc using libfigpar >>=20 >> And I have plans to write a "jailconf" that reads /etc/jail.conf with li= bfigpar. >>=20 >> I'm aware that sysctl(8) has it's own C code for parsing sysctl.conf. >> I'm also aware that jail(8) has it's own C code for parsing jail.conf. >>=20 >> However, libfigpar allows all these to be parsed with a single library. >> Making things accessible to other languages besides C/C++, you can >> see by sysconf(8) above that the analogous FFI can be built. >>=20 >> NB: I still am wrestling with the idea of rewriting sysrc(8) in C to use= libfigpar >> but... the only thing stopping me is that I know that I would have to ma= ke the C >> code fork-exec to sh(1) several times considering rc.conf(5) is in-fact = shell. >>=20 >> So you asked about the possibility of a Grand Unified Schema, and this i= s my >> take. The library brings the parsing, but you have to bring the function= s that >> handle the values. When you invoke the parser, you give it a few things.= .. >>=20 >> + A bit-field of options that can change the way it parses (strict v loo= se, etc.) >> + A series of function pointers for handling specific data types. >>=20 >> (and I'm sure I'm forgetting much... I wrote a man-page in the CVS repo = so I >> wouldn't have to memorize everything) >>=20 >> But... alas... >>=20 >> One of the things that I lost (which is not that hard to get back) from = the original >> version was the defacto processing functions set{str,strarray,num,bool,e= tc.}. >>=20 >> But that's the easy part. Resurrecting the core processing module (stayi= ng true >> to the fact that original was compiling on over 40 different POSIX envir= onments >> and working perfectly) -- that was the hard part. >>=20 >> As you can see from my works-in-progress... sysconf(8) and fdpv(1) ... I= 'm having >> loads of fun with libfigpar ;D makes parsing easy and stores the data in= a really >> nice memory format for simple access. >>=20 >> But of course... I'd love feedback as ... being how I am developing thos= e things >> for base... I'm curious to know if this could fit your need. >>=20 >=20 > Reading this, I remembered http://augeas.net/ which I stumbled over readi= ng up on ovirt. >=20 > I like proper formats better than some magic middleware though. (givng yo= u schemas incl. validation, xquery style access, standard tooling etc.) >=20 > Could even be done via "proxies" which are completely specified XML schem= as with round trip conversion. Maybe even portable supersets. Hey, that looks really nice. I'm going to have to sit down and play with th= at. Wonder what the licensing is. --=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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?66114E14-6B6A-461B-8F35-D821A8A56C80>