X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
        bh=w0qqB6/e3+9IFG5xSBILsd/KPBBrwUb8qZZR+hW4jT0=;
        b=WSgB7hznjy0ZE83paI5MaY7CeMD4pOMutPXJsZ6diBE7XBoBka3yPIusflez42GgJE
         QPrhri4uUYW8UCfpBu1Wps0TUnfbKJAX5Yn5yTPlZo5jX6GJBRllJcP3WiUdesbBcal5
         rRFcjjrQO9KSk/KBxIerqJFbRLFr2yS/Ef5rvJgvbk9ivacgaCPRrnAjj4CLR4PN0S+y
         fsGjWiWnQ6Xmdot/9jORoNY6OOIcTvC+lDVXti+BS0E92Ikg4OLKwrj3HcBu9Lj3hJbB
         RmjgSqi6OAFC8imK2DC7aw1cBySeZC2vI/3OEyC+/EWA5U3M/ViAMvT0PSoiZ38g4xM6
         dBYQ==
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;
        bh=w0qqB6/e3+9IFG5xSBILsd/KPBBrwUb8qZZR+hW4jT0=;
        b=BxahN+1DJJ+iLB00IIvcY/bx+5U1JsCdr+go8KQJnjWwf/sxxssTH+Pc9zy0ZvS2Td
         MEcOJgLl23UpP8O/SJyfcigs0shqVqkqzqKVPyNf4uBBmOTVrfc08lFwvRrHCyKSwZIk
         knr25pgk7aWzVGH0X7bhNz+X2FshCoRi6YWhDsfrdQ/g+RlwTvswLfW1PziHhqDTq/94
         EkvFj3Pd1WBKZnPupTQ1YlFgqjoESbwwVvl7JlkIAcjo5ogHMZRBjdoahd/jueYhw8uI
         19gnTgFAcpBcmqyVA7M+L51+S4J+bNqBO0498DBPwxzGuUq6fWtEwdDOOYr5vzyoeRh4
         cYrg==
X-Gm-Message-State: AE9vXwNED5xiPVIzjewwPXQYM4FvIDOYWSkdhS4uGF+aK850IbRwb1g18ufHQQ0iaouOtYThoZ67NYbrJrt74w==
X-Received: by 10.129.109.6 with SMTP id i6mr13758617ywc.291.1474380187157;
 Tue, 20 Sep 2016 07:03:07 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.11.1609201310470.17116@nimbus>
References: <alpine DOT DEB DOT 2 DOT 11 DOT 1609192251560 DOT 30591 AT nimbus> <CAAKZVJk5eK+Jpo1vZ1-8rZGOKV239TAiTan3ysPVthf=b07cRw AT mail DOT gmail DOT com>
 <alpine DOT DEB DOT 2 DOT 11 DOT 1609201310470 DOT 17116 AT nimbus>
From: "dmn (graahnul DOT grom AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Date: Tue, 20 Sep 2016 17:03:06 +0300
Message-ID: <CAAKZVJ=XtoyEZD7+x_9hxN5Sm0qLZNwKGe9TwdgZLH6XM-9nhA@mail.gmail.com>
Subject: Re: [geda-user] Default gnetlist frontend changed
To: geda-user AT delorie DOT com
Content-Type: text/plain; charset=UTF-8
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On 9/20/16, Roland Lutz <rlutz AT hedmen DOT org> wrote:

> In which paths are Python and Guile installed on your system,
> respectively?  What's the preferred way to determine this on FreeBSD?

On FreeBSD all third party packages are installed under
/usr/local, to that they do not mess up with the base system.

> Is there a reason for you to choose `python-config' and `guile-config'
> over `pkg-config'?

There's no particular reason. If you can do it with pkg-config
and it will work - perfect.

>> - non-portable C++ code in key_iterator.h
> It's in C++98, so how can it not be portable?

Consider, for example, your operator == ():

    bool operator == ( key_iterator x )
    {
        return i.operator == ( x.i );
    }

Here, i and x.i are bidirectional (and hence - forward) iterators.
ISO C++ states ("forward iterator requirements") that if
a and b are forward iterator objects, they must support
expression a == b and the result of such expression must
be convertible to bool. That's all.
Standard does not tell compiler's developer how to
implement it. operator == () can be either class member
function or not. But you assumes that it IS a class member,
thus relying on implementation details.

> The intention is that Xorn shouldn't depend on GNU sed; if it does, that's
> a bug.  What problems did you encounter with non-GNU sed?

xorn depends on GNU sed to be built. Otherwise, compilation stops
in xorn/po/ with 100+ gettext error messages. I can send
you the output, if necessary.

> What's the preferred way on FreeBSD to address a file descriptor as a
> file?  Is there such a way at all?

There is fdescfs (/dev/fd/).

> The other obvious way to implement this would be to redirect the standard
> output, and let the backend output there.  I tried to avoid this as it may
> cause some messages printed to stdout to be included in the output, but
> maybe it's the better option considering portability.

Sorry, but I have no idea what you are trying to implement.
Could you explain, please?

Dmitry.