X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Fri, 9 Feb 2018 18:13:27 +0100 (CET)
X-X-Sender: igor2 AT igor2priv
To: geda-user AT delorie DOT com
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] Another PCB grid step question
In-Reply-To: <20180209161532.6AF57804CEFA@turkos.aspodata.se>
Message-ID: <alpine.DEB.2.00.1802091735590.12270@igor2priv>
References: <c3aa1897-3806-3f72-feef-85551a63c2db AT linetec DOT nl> <alpine DOT DEB DOT 2 DOT 00 DOT 1802091235090 DOT 12270 AT igor2priv> <6221de93-bb98-d397-79b4-eecf3975c2e6 AT linetec DOT nl> <alpine DOT DEB DOT 2 DOT 00 DOT 1802091324350 DOT 12270 AT igor2priv> <f2259553-7015-8fc8-33b2-8ca8be6c5a45 AT linetec DOT nl>
 <alpine DOT DEB DOT 2 DOT 00 DOT 1802091427450 DOT 12270 AT igor2priv> <20180209161532 DOT 6AF57804CEFA AT turkos DOT aspodata DOT se>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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 Fri, 9 Feb 2018, karl AT aspodata DOT se wrote:

> Igor2:
> ...
>> 2. if you just 'save', it should save in the same original format you
>> loaded from (or last saved in)
> ...
>
> Not really true, you seems to have invented a "floater" flag
> which pcb doesn't understand, and what happened to the "lock" flag ?

It is true, minus the temporary bugs. Bugs can be fixed only when 
reported.

We do a best effort save to any alien format, including .pcb. If you find 
a bug, just repot it and it will get fixed. At the moment not too many 
pcb-rnd users use the mainline file format, as it can't express most of 
the "new" features they use daily. So testing the .pcb path is welcome.

Yes, we introduced a lot of new features, but that has nothing to do 
with the goal of being able to save in alien file formats. A "load .pcb 
file, save as lihata, load lihata, save as .pcb" should always work and 
shouldget back the original .pcb file without much data loss. If that 
doesn't happen with your file, please do report (preferrably with 
minimal test case attached).

>
> $ pcb-rnd -V
> pcb-rnd version 1.2.7 rev svn r14602
> $ cp original.pcb tt.pcb
> $ pcb-rnd -gui lesstif tt.pcb
> adding a line
> File->save layout
>
> $ diff tt.pcb original.pcb
>
> 880c871
> < Element["" "apem_3mek_sc.fp" "M2" "unknown" 92.75mm 71.25mm -18.75mm -15.5mm 0 100 "floater"]
> ---
>> Element["lock" "apem_3mek_sc.fp" "M2" "unknown" 92.7500mm 71.2500mm -18.7500mm -15.5000mm 0 100 ""]
> 882,893c873,881
> <       Attribute("footprint" "apem_3mek_sc.fp")
> <       Attribute("refdes" "M2")
> <       Attribute("value" "unknown")
>
> $ pcb tt.pcb
> ERROR parsing file 'tt.pcb'
>    line:        844
>    description: 'Unknown flag: "floater" ignored'
> ERROR parsing file 'tt.pcb'
>    line:        880
>    description: 'Unknown flag: "floater" ignored'
> ERROR parsing file 'tt.pcb'
>    line:        897
>    description: 'Unknown flag: "floater" ignored'

Thanks for reporting, worked around in r14603.

(The real fix would be to upgrade pcb with the flag compat patch, back 
from 2013 - but I gave up on trying to get it applied back in 2015)


> pcb: rtree.c:1054: r_insert_entry: Assertion `which->X1 <= which->X2' failed.
> Aborted

Fixed a negative coord in the padstack -> old-pad converter in r14604. 
It seems mainline doesn't like negative pad widths (pcb-rnd had no 
problem with them and rendered things as numerically expected).

However, the assert is a bug in pcb - it should not assert even on invalid 
input. If it doesn't like negative coords in some fields, it should 
probably check for those and give a meaningful error message.

If you find further bugs in pcb-rnd's io_pcb, please make bugreports, 
preferrably with a minimal test case attached. Please remember that we are 
still in the middle of the data model switchover, so this is exactly when 
these bugs should be introduced, should be found & reported and get fixed, 
so that the next release in late March would be stable.

Regards,

Igor2