X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Virus-Scanned: Debian amavisd-new at mail.linetec.nl
Content-Type: multipart/alternative;
 boundary="------------PGwmuT06vvk6vzLhHjCh05BP"
Message-ID: <71f14099-4e8a-22e0-2fb6-088b02aecba8@linetec.nl>
Date: Sat, 6 May 2023 19:36:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Subject: Re: [geda-user] Re: Intractable error message 'could not find refdes
 on component ... '
To: geda-user AT delorie DOT com
References: <xncz5nvzvd DOT fsf AT envy DOT delorie DOT com>
 <0350ae12-d97f-3fc0-f146-c83066c0e695 AT linetec DOT nl>
 <CAJZxidB2RihL-CwFDUuaG9tnkUz-yNeQrRqaFaGZYQKR-c8Tww AT mail DOT gmail DOT com>
 <48f8fe1f-b377-be59-6493-5d61140fdc13 AT linetec DOT nl> <s6nmt4pn5xz DOT fsf AT psjt DOT org>
 <407d4f7a-f529-b0bd-de4f-39fd357cb7c0 AT linetec DOT nl>
 <774de29a-806b-8dc3-84ee-770330b1fd0e AT linetec DOT nl>
 <27387063-1baa-8905-4b41-a99c81fde2d6 AT linetec DOT nl>
 <9b1da9df-b3f3-4fe6-7cc2-1bbdc2bfb281 AT grinsen-ohne-katze DOT de>
Content-Language: nl-NL, en-US
From: "Richard Rasker (rasker AT linetec DOT nl) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
In-Reply-To: <9b1da9df-b3f3-4fe6-7cc2-1bbdc2bfb281@grinsen-ohne-katze.de>
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

This is a multi-part message in MIME format.
--------------PGwmuT06vvk6vzLhHjCh05BP
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello Roland,

Op 06-05-2023 om 13:46 schreef Roland Lutz:
> Hi Richard,
>
> On Fri, 5 May 2023, Richard Rasker (rasker AT linetec DOT nl) [via 
> geda-user AT delorie DOT com] wrote:
>> Maybe a bit of an awkward observation, but it appears that more 
>> recent incarnations of gschem and pcb […] enforce stricter rules that 
>> break older designs in several different ways.
>
> gnetlist used to have undefined behavior in a lot of situations 
> resulting in subtle bugs in the design.  For example, a large SMD 
> board at my university would be missing one in row of identical 
> transistors; this had to be discovered and patched in by hand.  In 
> order to prevent this kind of error, I decided to have gnetlist fail 
> rather than "just output something" if it encountered a situation that 
> was likely to result in a problem.
>
>> I used to have the net:pin definition "net=[name]:1" (not visible), 
>> together with "netname=[name]" (visible) -- but for some reason, it 
>> is no longer allowed to have both a net and a netname attribute defined.
>
> This is prone to errors: someone may change the netname= attribute but 
> not realize that there is a net= attribute to be changed as well, 
> resulting in one net being displayed and another net being connected.  
> Therefore, recent versions of gnetlist honor the netname= attribute 
> directly but require the redundant net= attribute and the pinumber= 
> attribute on the pin to be removed.
>
> So, the "canonical" fix would be to use a new-style power symbol (or 
> just create a copy of the old one minus the two attributes) and remove 
> the net= attribute.

How is such a new-style power symbol defined?

>> Virtually every older project that I created now throws numerous 
>> errors when I try to open and/or modify it, causing a lot of extra work.
>
> I'm sorry about that!  I added these checks to avoid more costly 
> errors later, but I guess I made them a bit too strict...

It's not a big deal when the cause of the problem(s) is clear -- but 
messages like "could not find refdes on component and could not find 
net= attribute on pin" are annoying, because at first I had no idea 
where to look. It took me an hour before I remembered about those 
input/output symbols.

I understand that in cases like this, there is no refdes to point to, 
but it would be helpful already if the error message included the name 
of the symbol(s) causing the problem (input-1.sym and output-1.sym).


Best regards,

Richard Rasker

Linetec
-- 
Linetec Translation and Technology Services
Akkerstafhof 15
7544SP Enschede
The Netherlands

+31-53-4350834

http://www.linetec.nl/
e-mail: rasker AT linetec DOT nl
--------------PGwmuT06vvk6vzLhHjCh05BP
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hello Roland,<br>
    </p>
    <div class="moz-cite-prefix">Op 06-05-2023 om 13:46 schreef Roland
      Lutz:<br>
    </div>
    <blockquote type="cite"
      cite="mid:9b1da9df-b3f3-4fe6-7cc2-1bbdc2bfb281 AT grinsen-ohne-katze DOT de">Hi
      Richard,
      <br>
      <br>
      On Fri, 5 May 2023, Richard Rasker (<a class="moz-txt-link-abbreviated" href="mailto:rasker AT linetec DOT nl">rasker AT linetec DOT nl</a>) [via
      <a class="moz-txt-link-abbreviated" href="mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] wrote:
      <br>
      <blockquote type="cite">Maybe a bit of an awkward observation, but
        it appears that more recent incarnations of gschem and pcb […]
        enforce stricter rules that break older designs in several
        different ways.
        <br>
      </blockquote>
      <br>
      gnetlist used to have undefined behavior in a lot of situations
      resulting in subtle bugs in the design.  For example, a large SMD
      board at my university would be missing one in row of identical
      transistors; this had to be discovered and patched in by hand.  In
      order to prevent this kind of error, I decided to have gnetlist
      fail rather than "just output something" if it encountered a
      situation that was likely to result in a problem.<br>
      <br>
      <blockquote type="cite">I used to have the net:pin definition
        "net=[name]:1" (not visible), together with "netname=[name]"
        (visible) -- but for some reason, it is no longer allowed to
        have both a net and a netname attribute defined.
        <br>
      </blockquote>
      <br>
      This is prone to errors: someone may change the netname= attribute
      but not realize that there is a net= attribute to be changed as
      well, resulting in one net being displayed and another net being
      connected.  Therefore, recent versions of gnetlist honor the
      netname= attribute directly but require the redundant net=
      attribute and the pinumber= attribute on the pin to be removed.
      <br>
      <br>
      So, the "canonical" fix would be to use a new-style power symbol
      (or just create a copy of the old one minus the two attributes)
      and remove the net= attribute.<br>
    </blockquote>
    <p>How is such a new-style power symbol defined?<br>
    </p>
    <blockquote type="cite"
      cite="mid:9b1da9df-b3f3-4fe6-7cc2-1bbdc2bfb281 AT grinsen-ohne-katze DOT de">
      <blockquote type="cite">Virtually every older project that I
        created now throws numerous errors when I try to open and/or
        modify it, causing a lot of extra work.
        <br>
      </blockquote>
      <br>
      I'm sorry about that!  I added these checks to avoid more costly
      errors later, but I guess I made them a bit too strict...
      <br>
    </blockquote>
    <p>It's not a big deal when the cause of the problem(s) is clear --
      but messages like "<span style="font-family:monospace">could not
        find refdes on component and could not find net= attribute on
        pin</span>" are annoying, because at first I had no idea where
      to look. It took me an hour before I remembered about those
      input/output symbols.</p>
    <p>I understand that in cases like this, there is no refdes to point
      to, but it would be helpful already if the error message included
      the name of the symbol(s) causing the problem (input-1.sym and
      output-1.sym).</p>
    <br>
    <div class="moz-signature"
      signature-switch-id="00c1a468-7bb7-4a48-b887-259be8969731">Best
      regards,<br>
      <br>
      Richard Rasker<br>
      <br>
      Linetec<br>
      -- <br>
      Linetec Translation and Technology Services<br>
      Akkerstafhof 15<br>
      7544SP Enschede<br>
      The Netherlands<br>
      <br>
      +31-53-4350834<br>
      <br>
      <a class="moz-txt-link-freetext" href="http://www.linetec.nl/">http://www.linetec.nl/</a><br>
      e-mail: <a class="moz-txt-link-abbreviated" href="mailto:rasker AT linetec DOT nl">rasker AT linetec DOT nl</a></div>
  </body>
</html>

--------------PGwmuT06vvk6vzLhHjCh05BP--