From owner-freebsd-current@FreeBSD.ORG Mon Mar 2 20:01:04 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7528E2BA for ; Mon, 2 Mar 2015 20:01:04 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 5DF84CFC for ; Mon, 2 Mar 2015 20:01:03 +0000 (UTC) Received: from AlfredMacbookAir.local (unknown [12.130.117.99]) by elvis.mu.org (Postfix) with ESMTPSA id D2BE0341F90F for ; Mon, 2 Mar 2015 12:01:02 -0800 (PST) Message-ID: <54F4C250.7090704@mu.org> Date: Mon, 02 Mar 2015 15:04:32 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Massive libxo-zation that breaks everything References: <54F31510.7050607@hot.ee> <54F34B6E.2040809@astrodoggroup.com> <54F35F29.4000603@astrodoggroup.com> <54F36431.30506@freebsd.org> <54F42A82.1020308@freebsd.org> <54F464D1.6060603@mu.org> <54F4BFB4.1060307@freebsd.org> In-Reply-To: <54F4BFB4.1060307@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 20:01:04 -0000 On 3/2/15 2:53 PM, Julian Elischer wrote: > On 3/2/15 5:25 AM, Alfred Perlstein wrote: >> >> >> On 3/2/15 4:25 AM, David Chisnall wrote: >>> On 2 Mar 2015, at 09:16, Julian Elischer wrote: >>>> if we develop a suitable post processor with pluggable grammars, we >>>> save a lot of work. >>>> given enough examples you could almost have automatically generated >>>> grammars. >>> This decoupled approach is problematic. A large part of the point >>> of libxo is to allow changing the human-readable output without >>> breaking tools that consume the output. Now I need to keep the tool >>> that consumes it and the tool that produces it in sync, so that's an >>> extra set of moving parts. When you throw jails with multiple >>> versions of world into the mix, it becomes a recipe for disaster. > why? the jail has it own /usr/share? > >>> >> +1 > > I think the risk is exactly opposite. That the human readable output > will change subtly with bugs in the xo implementation. > and people will not update the two output paths in exactly the same > way, leading bugs. I'm not going to fight on it, but I am > uncomfortable with it. So you mean that we're going to have to act like mature software devs and have regression tests (atf) and such? I welcome such a change. > You are increasing the complexity of every program you touch. And its utility as well. Worth it. -Alfred