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:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        bh=UKF8cMLEUZD8tRirCb3v8jfuSV+XeBkFbomuH6z3OVM=;
        b=LhEEMKDlsONEnNFgfxARR9SPpoamNEEkszUCWAhqaRqIJtSgSFh3o+0zQEb2UuABkF
         IZS47aL+Ukb4B3ZSN9EgNs8jC6N+x0qRawDUahHARhv65mVunY83e5EO+ifzlWdaZIWI
         70K275daLkFuT8aQqD+2wiNK9rSyJX/qDs3Asm+AOw3bZ0jE1Qg0zrmKniDpz8yIfrkz
         IIp5Ju1qDGEW651piwFAkpMIr8DVEG/nOXOkKzaUvxUrhVZChKTAne1YqiSOEf137fz8
         d5Au7jtE1oPrOy3UN0gx6mgI+LuqEPew5MZDoK6+fnNJBdudLDtAhNHHa/7jbRLXDI1P
         zpsQ==
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:date
         :message-id:subject:from:to:content-type:content-transfer-encoding;
        bh=UKF8cMLEUZD8tRirCb3v8jfuSV+XeBkFbomuH6z3OVM=;
        b=URsCkqkbd5XBMEKQtsURZx4mq6Z8ezQilsV8ib4JKju8ez7a+aeVv177dfNtkt/6YS
         k2w+e/VkRzL5KZ1TM3RqUjv55jbPkt1W4fJFVMZcjZoBUOkaIDG03jvV6Ip6rFTKuzhq
         063eYU6hKt+yzI+6+xTokKg5Lvn2TZMbj2h3NkLiwBk0qwy8RWX+qbjtZ/YEMX48nfs+
         tFgpvzMayRh2nWTQupITLtes2nZmXflB6ob1Oz4TBvJuSgYc5OKVLT1WEczDzG2EFSjd
         NTVdi0U5t8iE+2WaAtrVMIQEqF/hRsjTNQMCiPSgi8wGikJopHQuGrp4qJ29bjrvD4AV
         GaiQ==
X-Gm-Message-State: AG10YOTQHxeAYFZrqCnU8oAcebIbPJh8ba1p/PpL8+svPkf1bIEWPimX+Z6zqxR/iEelV24RaYN5Rw90atvVGw==
MIME-Version: 1.0
X-Received: by 10.194.133.201 with SMTP id pe9mr9479442wjb.101.1455831116509;
 Thu, 18 Feb 2016 13:31:56 -0800 (PST)
In-Reply-To: <E75ECBB6-14E7-437A-B374-E0CF86BDFF1A@noqsi.com>
References: <20160215215221 DOT fd472794e7b9446a243bfc40 AT gmail DOT com>
	<201602152055 DOT u1FKtM4K011038 AT envy DOT delorie DOT com>
	<20160215220938 DOT bbc7eaa59d827cd0b261ea97 AT gmail DOT com>
	<D3167F4D-4750-49F8-9125-BDC4937F5C69 AT noqsi DOT com>
	<201602152135 DOT u1FLZrw9012774 AT envy DOT delorie DOT com>
	<7F210DE7-0A0B-42F9-ABBE-2C2768621186 AT noqsi DOT com>
	<20160216081722 DOT 1065cbed6653d3da4ffc7498 AT gmail DOT com>
	<201602160724 DOT u1G7Ox26001785 AT envy DOT delorie DOT com>
	<20160216085628 DOT b70143c330cd4da98a4603d3 AT gmail DOT com>
	<201602160805 DOT u1G85d8c003148 AT envy DOT delorie DOT com>
	<20160216092912 DOT 7f7439f703b49175a21dbb1b AT gmail DOT com>
	<CAJXU7q_w5NunkojiCr36RHRTq0hJ+PZP1e0GumTRMoGXcvgRXQ AT mail DOT gmail DOT com>
	<201602161715 DOT u1GHFMBB028078 AT envy DOT delorie DOT com>
	<CAC4O8c9jr_b376SpuUk5HrJApP1c75oxsEBemn-i_xtC-rt-Zw AT mail DOT gmail DOT com>
	<201602162032 DOT u1GKWL7Y005291 AT envy DOT delorie DOT com>
	<CAC4O8c-ig=0UVAqagNXH_DBmC9uVQDu3Y1Gx7LBGmRCo0-_kVQ AT mail DOT gmail DOT com>
	<E75ECBB6-14E7-437A-B374-E0CF86BDFF1A AT noqsi DOT com>
Date: Thu, 18 Feb 2016 12:31:56 -0900
Message-ID: <CAC4O8c8z4JiJr=mgA+co4pX-yxu_pVsXpeKRYqneuxZNnYqh8g@mail.gmail.com>
Subject: Re: [geda-user] pcb import schematic crash, parantheses in netname
From: "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id u1ILW0AW020102
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 Thu, Feb 18, 2016 at 12:06 PM, John Doty <jpd AT noqsi DOT com> wrote:
>
> On Feb 18, 2016, at 12:59 PM, Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>
>> On Tue, Feb 16, 2016 at 11:32 AM, DJ Delorie <dj AT delorie DOT com> wrote:
>>>
>>>> The excuse is that doing that will lead to bugs.
>>>
>>> The context was "what should gnetlist allow?"  The answer is:
>>> everything it can.  If the downstream tools have limits, let them
>>
>> I disagree.  It doesn't add much to accept weird characters.  UTF-8 is
>> full of chars that *look* identical but compare non-equal, its nuts to
>> send them to anything except a human reader if you can avoid it.
>
> It’s a UTF-8 world, we should be part of it. But you can’t even avoid the problem in ASCII. 0 and O. Or 1, I, l, and |.

Yeah, we should use it for output to humans, where it makes sense.

>>> manage those limits themselves.  Why should gnetlist, or even a
>>> netlist backend, limit what *it* can handle, if it doesn't have to?
>>
>> Because you *know* it's gonna break downstream stuff,
>
> But you don’t know which characters break which downstream stuff. Should gnetlist restrict netnames to upper case for SPICE?

Yes you do.  The ones that break pcb are the most important and should
be caught as early as possible by default.  Restricting to upper case
would actually be fine with me as well, but it's obviously less
important because fewer people use that work flow.

>> and fixing bugs
>> is generally cheaper the closer you detect them to where they occur.
>
> You don’t even know where the netlist is coming from. It’s the downstream processing’s job to avoid breakage. If the downstream has problems that can’t be fixed, and the netlister is gnetlist, it may be useful to dodge them in the back end. Gnetlist has the machinery to support this.

What to you mean by dodge them in the back end?

>> And that's the case here: the user doesn't know wtf is going on and
>> that the problem is really upstream of gnetlist.  It would be better
>> to set up gnetlist st by default it pukes on weird stuff that's going
>> to confuse downstream stuff.  If user's want kanji let them set an
>> option to get it.
>
> I completely disagree. The toolkit’s job is to enable the user to do what they need, not to get in their way.

The toolkit gets in the way most when it's inconsistent and
unpredictable, which is overall what it's being here.  I remember when
I first encountered this issue myself and it was confusing and
annoying that gschem couldn't tell me up front which chars were going
to be a problem.

>>> If I change the pcbfwd netlister to fail on '$' for some then-valid
>>> reason in pcb, and pcb itself changes to allow '$', I have to go back
>>> and "fix" the netlister (and possibly older but previously installed
>>
>> So what?  In the meantime you haven't confused the heck out of users
>> for no real gain.
>
> You don’t know what other users need, so you can’t say “no real gain”. No real gain for you, maybe.

What ~90% of users need is for pcb to work as well as possible.  I
know you don't like that, but you've implicitly acknowledged it
yourself with your complaints that development is pcb-centric.  So the
real gain is for ~90% of the users, not just me  The default behavior
of the toolkit should favor that 90%.  It's trivial for you to set an
option that relaxes a restriction on the available character set.  You
can even advise the user of the possibility when funny characters are
seen.  It's much less trivial for a relatively new user to sort out
what's going on in cases like this.

Britton