X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Sat, 10 Feb 2018 04:30:35 +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: <20180209204934.CAA35804CEFA@turkos.aspodata.se>
Message-ID: <alpine.DEB.2.00.1802100406500.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> <alpine DOT DEB DOT 2 DOT 00 DOT 1802091735590 DOT 12270 AT igor2priv> <20180209204934 DOT CAA35804CEFA AT turkos DOT aspodata DOT se>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
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:

>> (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)
>
> You mean this:
> http://www.delorie.com/archives/browse.cgi?p=geda-user/2013/09/01/02:49:59

Yup.

> Yes, wouldn't mind that, but Richards problem was to cooperate with
> the pcb programs run by his fellow designers, i.e. make it work with
> older versions of pcb.

Yes, I understand. And that's what shoudl be absolutely possible with 
pcb-rnd. You should be able to work together with your friends who use 
pcb, kicad or protel if you use pcb-rnd.

>
>>> pcb: rtree.c:1054: r_insert_entry: Assertion `which->X1 <= which->X2' failed.
>>> Aborted
> ...
>> However, the assert is a bug in pcb - it should not assert even on invalid
>> input.
>
> Perhaps, but it does in the debug version, and the problem was: can
> Richard save files from pcb-rnd and give them to his co-workers ?

Again: the goal, and normal situation is that you can save pcb files from 
pcb-rnd and load them with older and recent versions of pcb mainline. When 
that doesn't work, that's a bug, that users need to report so it can be 
fixed. As you have seen yesterday, the bugs you reported got fixed 
literally within minutes. We are still in the middle of a big data model 
rewrite so it's sort of expected to have bugs like this, in trunk. We 
expect to have this sort of things fixed by the next release. See also:

http://www.repo.hu/cgi-bin/pcb-rnd-people.cgi?cmd=timeline

What I dislike is when you say things that suggest the normal situation is 
that pcb-rnd can not work together with pcb mainline. That's _not true_. 
It is designed to work together with pcb mainline as much as with kicad. 
There are bugs, like in any other software. You need to report the bugs, 
else they won't get fixed.

The negative coord problem got fixed in pcb-rnd. What I said was that it's 
not handled properly in pcb if it gave a bbox related assert on it. 
Yes, this assert happens only in debug mode - in non-debug mode you don't 
get the an assert but random misbehavour, perhaps in any rtree related 
code.

>> If it doesn't like negative coords in some fields,
>
> Soo, what do a "thickness" of -2mm mean ?

For historical reasons smd pads are lines in pcb. At the end you msot 
often want rectangles at the end, so you toggle the square flag. There's 
some code that converts between the two shapes, "square cap line" and 
"rectangle". It's just a bunch of + and * operations, negative numbers 
technically do a coord flip. If you have both forth and back converter 
calculation written correctly, you get full round trips - I did that with 
pcb-rnd, so I didn't even notice the negative coords.

Anyway, I changed the code to flip the coords manually so we always emit 
positive thicnkess now. What I said about pcb's parsing still holds: if it 
doesn't handle negative coords properly, it should warn about them because 
any random 3rd party code, e.g. footprint generator scripts can 
occassionally make a similar mistake and get a negative coord and the bbox 
assert is not very helpful figuring it.

So this is as much as time I want to spend on it, from now on pcb-rnd 
doesn't export negative thickness, and whether pcb improves their error 
messages or not is not my problem.

(One last thought on this: the line-as-rectangle idea is bad design that 
introduces subtle corner cases. My favorite one is when you want a real 
square: the most trivial way is to have a zero-length line, in which case 
the thickness of the line will happen to be the side length of your 
square. Sounds like a good idea. Until you rotate your element 45 degrees: 
that's when the square stays axis aligned because the 45 degree rotated 
endpoints of a zero length line is the same as for any other angle. A 
trivial workaround would be to cheat and say the line is 1 nm long - 
probably works for n*45 degree, but what if you rotate 30 degrees next? So 
in reality there's a virtual limit even on the minimal length of pad lines 
if you want to get it to work properly. For reasons like this we can use 
real polygons for pads (padstacks) in pcb-rnd.)

> 1, silk lines is missing from the pcb-rnd saved element
>
> 2. pcb-rnd creates attributes which it later complains about:
>
> 3. original clearance is 0.5mm, pcb-rnd converts that to 0.25mm
>
> 4. I don't really know how to treat a mask value of -2mm,
>   the orig. is 1.5mm
>
> 5. theese are supposed to be the same, care to tell me how:
>        Pad[-0.3500mm 1.5500mm 0.3500mm 1.5500mm 1.3000mm 0.5000mm 1.5000mm "1" "1" "onsolder,square"]
>        Pad[-0.3500mm -1.5500mm 0.3500mm -1.5500mm 1.3000mm 0.5000mm 1.5000mm "2" "2" "onsolder,square"]
>
>        Pad[0.0 1200.0um 0.0 1900.0um -2.0mm 250.0um -2.0mm "1" "1" "square"]
>        Pad[0.0 -1900.0um 0.0 -1200.0um -2.0mm 250.0um -2.0mm "2" "2" "square"]
>

Thanks, these look like legit bugs.

As I asked before: please send minimal test cases. Just copying random 
snippets and grep output won't help me reproducing the problem here. It 
looks like you can get these with a footprint. Please send that footprint.

Regards,

Igor2