Re: [Kicad-developers] IBIS / SPICE simulation

[Andrew Zonenberg]

Also of note...

I've got a bunch of tools in glscopeclient and
libscopehal/libscopeprotocols for NRZ/PAM4 signal generation, channel
emulation, de-embedding, equalization, clock recovery, eye patterns,
etc. Might be worth pursuing some kind of integration to develop a full
channel design/simulation tool kit in KiCAD down the road? I have an
IBIS parser already but haven't built a full IBIS simulator yet. It's on
the to-do list though. All of these tools are 3-clause BSD so license
compatible with KiCAD.

Ideally I'd like to integrate with an EM solver to extract a S-parameter
model of a PCB channel as well, so I can just click on pads of a board
to set up ports, configure a frequency sweep, then shove that into a
time domain model.

Here's a quick demo of some of the channel design tools:
https://www.youtube.com/watch?v=tgxtSVG4y_E

On 8/30/21 3:24 PM, Reece R. Pollack wrote:
> I started down the path of creating an IBIS-to-Spice converter a couple
> of years ago. I researched it enough to decide it was feasible, then
> discovered a commercial product demo that would do enough of what I
> needed at the time and stopped working on it.
> 
> I'd just about forgotten about it until you mentioned it.
> 
> -Reece
> 
> On 8/30/21 12:34 PM, Fabien Corona wrote:
>> Hello everyone,
>>
>> I am working on an IBIS parser for kicad integration.
>> IBIS is a standard format to I/O buffers, that allows for "fast" and
>> accurate signal integrity simulations.
>> While parsing the IBIS format is not so hard, well... I have data to
>> simulate, but no simulator...
>>
>> I was wondering if anybody in this mailing list had knowledge about
>> IBIS and / or SPICE simulation ?
>> From the info I gathered, it is quite "easy" to convert to convert to
>> a SPICE model, but maybe there are better ways to do.
>> ( If we could avoid a whole simulator from scratch, that would be nice )
>>
>>
>> Basically, an IBIS file is :
>> - R L C parameters,
>> - voltage vs current tables
>> - voltage vs time tables
>>
>> Regards,
>>
>> Fabien Corona
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp



OpenPGP_signature
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] DXF export generates non-closed polygons, and other problems interchanging data w/ Sonnet

[Andrew Zonenberg]

Hi,

Kicad's DXF export seems to be broken, causing many tools (such as the
Sonnet field solver, example attached) to not import layouts correctly.
I contacted Sonnet support and they did some digging; it seems like
KiCAD is producing malformed DXFs that have non-closed polygons in them.

I've also encountered two other problems getting KiCAD designs into Sonnet:

1) Sonnet's DXF import expects a *single* DXF, with one drawing layer
per PCB/via layer. KiCAD generates one DXF per layer and I don't think
there is currently a way to do a multilayer export. This isn't a fatal
problem as I can just do multiple imports, but it's annoying.

2) More seriously, There does not seem to be any way to get via drill
*outlines* in DXF format. The "drill map" file just has an X at each via
location which is useless when trying to import layout into an external
tool.

Anybody have suggestions on how to proceed, or interested in helping to
fix this? I'm not super familiar with the DXF file format although back
in the v4.x days I did do some work on the microvia/blind via Excellon
drill export code so I've done at least a little bit of work there.
(kicad_pcb (version 20171130) (host pcbnew "(5.1.4)")

  (general
(thickness 1.6)
(drawings 13)
(tracks 349)
(zones 0)
(modules 11)
(nets 6)
  )

  (page A4)
  (layers
(0 F.Cu signal)
(1 In1.Cu signal)
(2 In2.Cu signal)
(31 B.Cu signal)
(32 B.Adhes user)
(33 F.Adhes user)
(34 B.Paste user)
(35 F.Paste user)
(36 B.SilkS user)
(37 F.SilkS user)
(38 B.Mask user)
(39 F.Mask user)
(40 Dwgs.User user)
(41 Cmts.User user)
(42 Eco1.User user)
(43 Eco2.User user)
(44 Edge.Cuts user)
(45 Margin user)
(46 B.CrtYd user)
(47 F.CrtYd user)
(48 B.Fab user)
(49 F.Fab user)
  )

  (setup
(last_trace_width 0.31)
(user_trace_width 0.125)
(user_trace_width 0.31)
(user_trace_width 0.5)
(user_trace_width 1)
(trace_clearance 0.1)
(zone_clearance 0.15)
(zone_45_only no)
(trace_min 0.125)
(via_size 0.5)
(via_drill 0.3)
(via_min_size 0.4)
(via_min_drill 0.3)
(user_via 0.5 0.3)
(uvia_size 0.3)
(uvia_drill 0.1)
(uvias_allowed no)
(uvia_min_size 0.2)
(uvia_min_drill 0.1)
(edge_width 0.05)
(segment_width 0.2)
(pcb_text_width 0.3)
(pcb_text_size 1.5 1.5)
(mod_edge_width 0.12)
(mod_text_size 1 1)
(mod_text_width 0.15)
(pad_size 4.8 1.4)
(pad_drill 0)
(pad_to_mask_clearance 0.05)
(solder_mask_min_width 0.05)
(aux_axis_origin 0 0)
(visible_elements FF7F)
(pcbplotparams
  (layerselection 0x210f8_)
  (usegerberextensions false)
  (usegerberattributes false)
  (usegerberadvancedattributes false)
  (creategerberjobfile false)
  (excludeedgelayer true)
  (linewidth 0.10)
  (plotframeref false)
  (viasonmask false)
  (mode 1)
  (useauxorigin false)
  (hpglpennumber 1)
  (hpglpenspeed 20)
  (hpglpendiameter 15.00)
  (psnegative false)
  (psa4output false)
  (plotreference true)
  (plotvalue true)
  (plotinvisibletext false)
  (padsonsilk false)
  (subtractmaskfromsilk false)
  (outputformat 1)
  (mirror false)
  (drillshape 0)
  (scaleselection 1)
  (outputdirectory "output/"))
  )

  (net 0 "")
  (net 1 /GND)
  (net 2 "Net-(R1-Pad1)")
  (net 3 "Net-(R2-Pad1)")
  (net 4 "Net-(J1-Pad1)")
  (net 5 "Net-(J2-Pad1)")

  (net_class Default "This is the default net class."
(clearance 0.1)
(trace_width 1)
(via_dia 0.5)
(via_drill 0.3)
(uvia_dia 0.3)
(uvia_drill 0.1)
(add_net /GND)
(add_net "Net-(J1-Pad1)")
(add_net "Net-(J2-Pad1)")
(add_net "Net-(R1-Pad1)")
(add_net "Net-(R2-Pad1)")
  )

  (module azonenberg_pcb:EIA_0402_RES_NOSILK_FLIPCHIP (layer F.Cu) (tedit 
5F4B5CE7) (tstamp 5E096C1E)
(at 87.4 24 180)
(path /5D098F11)
(solder_paste_margin -0.06)
(fp_text reference R3 (at 0 1.5) (layer F.SilkS) hide
  (effects (font (size 1 1) (thickness 0.15)))
)
(fp_text value FC0402E2000BTT0 (at 0 3.5) (layer F.SilkS) hide
  (effects (font (size 1 1) (thickness 0.15)))
)
(pad 2 smd rect (at 0.5 0 180) (size 0.5 0.5) (layers F.Cu F.Paste F.Mask)
  (net 3 "Net-(R2-Pad1)"))
(pad 1 smd rect (at -0.5 0 180) (size 0.5 0.5) (layers F.Cu F.Paste F.Mask)
  (net 5 "Net-(J2-Pad1)"))
(model 
/nfs4/home/azonenberg/kicad-libs/3rdparty/walter/smd_resistors/r_0402.wrl
  (at (xyz 0 0 0))
  (scale (xyz 1 1 1))
  (rotate (xyz 0 0 0))
)
  )

  (module azonenberg_pcb:EIA_0402_RES_NOSILK_FLIPCHIP (layer F.Cu) (tedit 
5F4B5CE7) (tstamp 5E096C18)
(at 86.3 24 180)
(path /5D097CEB)
(solder_paste_margin -0.06)
(fp_text reference R2 (at 0 1.5) (layer F.SilkS) hide
  (effects (font (size 1 1) (thickness 0.15)))
)
(fp_text value FC0402E2000BTT0 (at 0 3.5) (layer 

[Kicad-developers] DXF export generates non-closed polygons, and other problems interchanging data w/ Sonnet

[Andrew Zonenberg]

Hi,

Kicad's DXF export seems to be broken, causing many tools (such as the
Sonnet field solver) to not import layouts correctly.
I contacted Sonnet support and they did some digging; it seems like
KiCAD is producing malformed DXFs that have non-closed polygons in them.

I've also encountered two other problems getting KiCAD designs into Sonnet:

1) Sonnet's DXF import expects a *single* DXF, with one drawing layer
per PCB/via layer. KiCAD generates one DXF per layer and I don't think
there is currently a way to do a multilayer export. This isn't a fatal
problem as I can just do multiple imports, but it's annoying.

2) More seriously, There does not seem to be any way to get via drill
*outlines* in DXF format. The "drill map" file just has an X at each via
location which is useless when trying to import layout into an external
tool.

Anybody have suggestions on how to proceed, or interested in helping to
fix this? I'm not super familiar with the DXF file format although back
in the v4.x days I did do some work on the microvia/blind via Excellon
drill export code so I've done at least a little bit of work there.

Andrew

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC - detecting acute angles

[Andrew Zonenberg]

Hi,

I guess the other question is, do we even *want* to be doing this check?
It's not the 1980s anymore.

At the very least it should be able to be disabled for those of us who
aren't working with a PCB shop stuck in last century.

https://resources.ema-eda.com/blog/are-acid-traps-still-a-problem-for-pcbs-in-2019

https://electronics.stackexchange.com/questions/115653/are-acid-traps-real-2014

https://resources.altium.com/p/7-common-misconceptions-about-pcb-design

https://www.nwengineeringllc.com/article/right-angle-pcb-traces-its-time-to-kill-the-myths.php

Andrew

On 7/20/20 8:29 AM, Tomasz Wlostowski wrote:
> On 18/07/2020 23:47, Joshua Redstone wrote:
>> Thanks, that link's a helpful starting point.
>> Josh
> 
> Hi Joshua,
> 
> If you could figure out the algorithm for robust acute angle detection
> (your input is a set of BOARD_ITEMs), I can integrate it with the new
> KiCad DRC engine.
> 
> Tom
> 
> 
>>
>> On Fri, Jul 17, 2020 at 7:40 PM Seth Hillbrand > > wrote:
>>
>> Please have a look over the open issues on GitLab.  Until the new
>> DRC code has been merged into master, it's not a good candidate for
>> a new developer.
>>
>> Here's a link with open issues for the feature-freeze that have not
>> yet been assigned.  Please do note that any feature-development work
>> should have a documented implementation plan that the lead
>> developers sign off on before you begin coding.  This can help to
>> avoid problems where you do a lot of work that doesn't get accepted
>> because it doesn't fit in the larger plan.
>>
>> 
>> https://gitlab.com/kicad/code/kicad/-/issues?scope=all=%E2%9C%93=opened_title=6.0%20Feature%20Freeze_id=None
>>
>> I would also strongly encourage you (as we do for all developers
>> starting to work on KiCad) to look at fixing small issues first. 
>> They are not nearly as appealing as a feature implementation but
>> they are more manageable and will help you learn the general layout
>> and workings of the system.
>>
>> Best-
>> Seth
>>
>> KiCad Services Corporation KiCad Services Corporation Logo
>> Seth Hillbrand
>> *Lead Developer*
>> +1-530-302-5483‬ 
>> Davis, CA
>> www.kipro-pcb.com     i...@kipro-pcb.com
>> 
>> https://twitter.com/KiProEDA 
>> https://www.linkedin.com/company/kicad
>> 
>>
>>
>> On 2020-07-17 16:13, Joshua Redstone wrote:
>>
>>> Hi all,
>>> I was wondering what's the state of the pcbnew DRC work and what
>>> are the todos left to be done?
>>> I have a bit of time while waiting for a board to be assembled. I
>>> was thinking of exploring DRC changes to either detect acute
>>> angles in copper or detect silkscreen text that intersects vias /
>>> pads, but I'm also curious to know what else needs doing.
>>> Cheers,
>>> Josh
>>>  
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> 
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@lists.launchpad.net
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Auto-generated backup files: are they useful?

[Andrew Zonenberg]

I find them annoying and have to add them to my gitignore's etc constantly.

They're of no value to me because I tend to save every 30 seconds or so
while working.

The *one* thing they might be useful for is guarding against kicad
segfaulting or other failures (disk full, NFS connection lost, etc)
during the save process itself. To do this, I'd suggest:

* Move old file to file.bak
* Write new file
* Delete old file if everything worked. If something goes wrong before
reaching this point, you can restore from the bak.

On 6/29/20 12:23 PM, Jon Evans wrote:
> Currently, KiCad automatically creates backups of schematic and PCB
> files when you save a file.
> 
> The logic for these backups is basically: if a file already exists
> with the same name as what we are saving, copy that file to a new file
> and give it the "-bak" suffix on the file extension.
> 
> These backups are stored next to the original file in the current
> KiCad codebase.  This understandably creates clutter that some people
> don't like (myself included) so in the project-settings branch that is
> about ready to be merged, I changed this behavior to place all these
> backups in a special backups folder for the project.
> 
> This proved to have some complications around the handling of files
> outside the project path (which it's possible to have with
> hierarchical schematic sheets) so I need to do something else.
> 
> After some thought, I am pretty convinced that the right thing to do
> is just *remove this backup feature entirely*.  Here's why:
> 
> 1) It's not a very good backup:  It just stores the state from the
> last time you hit "save".  If you hit save again, your backup is blown
> up.  So, it's really like a "undo" function, but on disk, and with
> only one level of undo.
> 
> 2) Recently I changed how we save schematic and board files to fix
> some unrelated issues people were seeing with cloud backup services.
> Before this change, if KiCad crashed or had some other serious error
> while saving a file, the file would be lost (because we used to delete
> the old file and then write a new one in its place).  After this
> change, we write the new file to a temporary location, and only if
> that write succeeds do we copy it on top of the old file.  I think
> this vulnerability to generating corrupt files if we crash was one of
> the reasons for this backup file system, and that reason is now gone.
> 
> 3) Because it's not a very good backup, I worry that the fact that
> "bak" files exist might cause some users to have a false sense of
> security and not use a true backup system (like a version control
> system, or some other mechanism that actually backs up files
> periodically).  I want to remove this false sense of security so that
> it is more clear that users should back up their files in some way if
> they care about the work.
> 
> In other words, I don't think this feature actually gives enough value
> to make it worth the clutter in the project folder and/or the
> development effort to make it work well with less clutter.
> 
> So, I'd like to hear from others on this: anyone disagree?
> 
> Thanks,
> Jon
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] How much do we care about small memory leaks?

[Andrew Zonenberg]

If the memory is allocated at startup and doesn't grow in size, I
wouldn't be too worried about not freeing it at shutdown.

True leaks (growing in size over time) are a major problem. I routinely
leave kicad instances open for weeks or months while working on large
projects.

On 5/29/20 7:22 AM, Johannes Pfister wrote:
> As an example, if opening and closing the plot window would leak 3 kB
> each time, would we care about that? And is it justified to increase
> code complexity to avoid this leak?
> If yes, what about "leaks" that alloc memory only once, use the same
> memory till the application is closed and don't free it. Should we
> increase code complexity to avoid this "leaks" too?
> 
> The reason for this question: There are some of this kind of leaks in the 
> code.
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Pushback on bug 1838448

[Andrew Zonenberg]

Hiding memory access errors is a terrible idea from both a security and
software reliability perspective. IMO we should be moving in the
opposite direction and adding -fsanitize=address to debug builds.

On 8/2/19 8:25 AM, Steven A. Falco wrote:
> I asked on the Fedora development list about removing the 
> "-Wp,-D_GLIBCXX_ASSERTIONS" flag as requested in 
> https://bugs.launchpad.net/kicad/+bug/1838448, and I got some pushback 
> (attached) stating that it is not a good idea to hide crashes caused by 
> out-of-bounds memory accesses.
> 
> I agree with that, and I made a similar argument in comment #22 of the bug.
> 
> Therefore I'd like to have more discussion about this.  Are we really sure we 
> want to hide memory access errors?  In some cases they could cause 
> hard-to-find corruption bugs, as well as hard crashes.  Personally, I'd 
> rather know there is a problem.
> 
>   Steve
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad's way of drawing filled zones

[Andrew Zonenberg]

I don't see the need to tie OS support to hardware support. It's totally
plausible to say, for example, "we'll support users on Debian 6 but only
if they have a <10 year old graphics card"

According to Wikipedia, OpenGL 3.x support is available for cards as old as:
* NVIDIA GeForce 8 series (12 years old)
* ATI Radeon HD 2000 series (11 years old)
* Intel Sandy Bridge integrated graphics (8 years old)

Does the project have any official hardware age/spec cutoff at this
point? I don't think the 11/12 year age cutoff for discrete graphics is
unreasonable.

The only users we'd impact by switching the OpenGL cutoff to 3.x are
users of 11+ year old discrete GPUs or 8+ year old integrated GPUs, who
either are on ancient laptops (so no GPU upgrade possible) or have a
desktop but can't spare the cash for a cheap GL 3.x capable card.
Considering that Newegg lists an ancient Radeon HD 3450 (which supports
OpenGL 3.3) for 11 USD, this doesn't seem like a major burden.

On 11/05/2019 23:58, Andrew Lutsenko wrote:
> Is it possible to determine openGL hardware support at runtime and use
> advanced API on newer machines while switching to fallback for older ones?
> I believe that solution would be best of both worlds.
> Otherwise the only reasonable cut-off date would be when officially
> supported OS versions will not support hardware with given OpenGL
> version. (For hypothetical example if kernel 7.0 will drop driver
> support for HD2000 and the likes there is no sense in clinging to old
> api but graphics drivers live very long time).
> 
> Regards,
> Andrew
> 
> On Sat, May 11, 2019 at 7:33 AM jp charras  > wrote:
> 
> Le 11/05/2019 à 16:18, Jon Evans a écrit :
> > Hi JP,
> >
> > Thanks for the input, it's a good point. It sounds like in this case
> > there may be a technical solution that works fine in GL2.1 so I
> agree it
> > makes sense to avoid raising requirements if at all possible. 
> >
> > Do you have any thoughts about how we should handle this in the
> future,
> > if for some reason there is a technical challenge that cannot be
> solved
> > as easily without moving to a higher OpenGL version? (or some other
> > similar hardware support issue) Should we always design for 2.1, or is
> > there some time in the future when it becomes appropriate to expect
> > users to have something newer? 
> >
> > Best, 
> > Jon
> 
> Of course, if OpenGL 2.1 cannot solve a technical challenge, we can move
> to 3.0.
> 
> Moreover, in the future, more PCs will support 3.0.
> 
> However, generally speaking, I prefer better algorithms to more powerful
> PCs.
> 
> >
> >
> > On Sat, May 11, 2019, 07:27 jp charras  
> > >> wrote:
> >
> >     Le 10/05/2019 à 18:43, Jon Evans a écrit :
> >     > Does anyone have a good sense of which hardware / software
> platforms
> >     > would be impacted by a switch to OpenGL 3.0 as baseline
> requirement?
> >     >
> >     > As far as I am aware, all commercial tools in the space have
> more
> >     > advanced / modern system requirements than KiCad, with the
> possible
> >     > exception of Eagle.  We have to consider whether supporting old 
> >     > graphics cards goes counter to the desire to have KiCad
> handle more
> >     > professional use cases (including large designs).
> >     >
> >     > The integrated Intel GPUs that are old enough to not have OpenGL
> >     3.0 are
> >     > no longer supported by Intel (everything since HD2000 series has
> >     it, as
> >     > far as I know)
> >     >
> >     > -Jon
> >
> >     Hi Jon,
> >
> >     To be honest, I do not share your opinion, and I am not especially
> >     thrilled by switching to OpenGL 3.0 as baseline requirement as
> long as
> >     we can avoid it.
> >
> >     OpenGL 2.1 is a reasonable requirement.
> >
> >     What is a professional use case?
> >     I know at least 2 opposite cases:
> >     - A advanced user who designs very complex boards: he needs a
> recent and
> >     fast computer with 2 (or enev 3) monitors.
> >     - Classroom "users"
> >     They are also professional users who do not design very
> complex boards.
> >     But force updating the computers just to use Kicad is a
> serious issue:
> >     As a old teacher I am knowing what I am saying:
> >     In the department I worked before being retired, we have
> roughly 200 PCs
> >     (most of them are dual boot: Linux and Windows).
> >     Not of all are used to run Kicad, but many of them.
> >     Saying: our new Kicad version needs a recent computer+OS so
> you have to
> >     change 50 or 100 of your computers in a bit hard 

Re: [Kicad-developers] [PATCH] Allow OpenCASCADE standard edition

[Andrew Zonenberg]

My understanding is that LGPL can be DYNAMICALLY linked with arbitrarily
licensed code (GPL of any version, proprietary, permissive, etc) as long as:

1) any modifications to the LGPL'd module are redistributed under the
copyleft terms of the LGPL, and
2) patched/updated versions of the LGPL module can be freely swapped for
the original (no signature checks etc)

Static linking is a whole other can of worms because now you have a new
derived work which is a combination of the two. It may indeed be the
case that LGPL 2.1-only and GPL 3+ cannot be STATICALLY linked. But my
reading of the license does not in any way prohibit dynamic linking.

On 29/01/18 12:04, Wayne Stambaugh wrote:
> Hey Seth,
> 
> One of us missed something.  Here is my interpretation:
> 
> The opencascade website license states:
> 
> "Open CASCADE Technology version 6.7.0 and later are governed by GNU
> Lesser General Public License (LGPL) version 2.1 with additional exception."
> 
> It makes no mention of later versions of the LGPL (including the
> exception) so I am interpreting this as v2.1 only.  I do not have a copy
> (and I'm not going to sign up to get a copy so please check the
> copyright in the source to see if it matches the website) of the
> opencascade source archive to see if the license in the source
> specifically states "v2.1 or (at your option) any later version" which
> is typically how the GPL and LGPL are used.  If it does, than I can
> safely add this patch because I can make the claim that I am using
> opencascade under at later version of the LGPL which is compatible with
> the GPL 3 used by kicad.
> 
> According to the folks at the FSF:
> 
> "Please note that GPLv2 is, by itself, not compatible with GPLv3.
> However, most software released under GPLv2 allows you to use the terms
> of later versions of the GPL as well. When this is the case, you can use
> the code under GPLv3 to make the desired combination. To learn more
> about compatibility between GNU licenses, please see our FAQ."
> 
> I hope this clarifies why I am hesitant to merge this patch and what
> needs to clarified.  Isn't licensing fun! ;)
> 
> Thanks,
> 
> Wayne
> 
> On 1/29/2018 2:47 PM, Seth Hillbrand wrote:
>> Hi Wayne-
>>
>> My reading of your links is different.  Here's the relevant quote:
>>
>> "GNU Lesser General Public License (LGPL) version 2.1 (#LGPLv2.1) This
>> is the previous version of the LGPL: a free software license, but not a
>> strong copyleft license, because it permits linking with nonfree
>> modules. It is compatible with GPLv2 and GPLv3."
>>
>> Did I miss something?
>>
>> -Seth
>>
>> 2018-01-29 11:18 GMT-08:00 Wayne Stambaugh > >:
>>
>> Seth,
>>
>> There maybe licensing issues involved with this.  OpenCascade is
>> licensed using LGPL v2.1 not v2.1[1] or later.  LGPL v2.1 is not
>> compatible with GPL 3[2].  If OpenCascade is willing to change their
>> license LPGL 2.1 or later or if this is just an oversight on their part,
>> than I can include this patch.  Please verify the OpenCascade license
>> with something that I can verify to ensure we are not violating and
>> licensing terms.
>>
>> Cheers,
>>
>> Wayne
>>
>> [1]: https://www.opencascade.com/content/licensing
>> 
>> [2]:
>> https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses
>> 
>>
>> On 1/29/2018 1:54 PM, Seth Hillbrand wrote:
>> > ​Hi All-
>> >
>> > Currently, the build requires the opencascade community edition.  For
>> > various reasons, I need to have the current non-community edition of
>> > OpenCASCADE installed on my work machine.
>> >
>> > The attached patch allows compiling KiCad with either the OpenCASCADE
>> > community edition or standard edition.  
>> >
>> > I've tested on a homebrew-based Mac install as well as Linux but
>> haven't
>> > verified MSW, if someone would be willing to test it there, that would
>> > be great!  The basic search routines are lightly modified from
>> FreeCAD's
>> > logic and keep their LGPL copyright on the CMake file.
>> >
>> > -Seth​
>> >
>> >
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~kicad-developers
>> 
>> > Post to     : kicad-developers@lists.launchpad.net
>> 
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> 
>> > More help   : https://help.launchpad.net/ListHelp
>> 
>> >
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> 

Re: [Kicad-developers] Acid-Traps - how to avoid them?

[Andrew Zonenberg]

This seems related to teardropping trace-pad junctions, which is
apparently pretty important to reduce bending stresses in flex circuits.
Maybe the two could come together?

On 24/04/17 14:58, Cirilo Bernardo wrote:
> In principle, a minimum curvature can be applied to geometric
> outlines. Maybe we can do that one day; aside from creating a fillet,
> such a feature would also round the edges of all rectangular pads.
> 
> - Cirilo
> 
> On Mon, Apr 24, 2017 at 10:42 AM, Clemens Koller  wrote:
>> Hi, there, Hello, Heikki!
>>
>> I just had a look at the video at https://youtu.be/G1YCu2daNww posted from 
>> Heikki
>> and was wondering if it is possible to avoid Acid-Traps [1] as shown in your 
>> example.
>> I've marked these in the attached picture.
>>
>> Usually, the PCB tools take special care how to exit a pad with a trace 
>> avoiding these acute corners and
>> have some design- and first corner rules.
>>
>> Regards,
>>
>> Clemens
>>
>> [1] For further information, see: 
>> https://community.cadence.com/cadence_technology_forums/f/27/t/11497
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Differential pair skew matching fails with certain dimensions

[Andrew Zonenberg]

Hi,

Try to skew-match the pair in the attached file.

On 14/03/17 16:06, Tomasz Wlostowski wrote:
> On 14.03.2017 19:20, Andrew Zonenberg wrote:
>> This one is probably for Orson or Tom...
>>
>>
>> Tested with latest code from git (on Debian Jessie), but I also had the
>> issue with my old version (a few weeks old, forgot to write down the
>> exact hash).
>>
>> Steps to reproduce:
>> * Create schematic that has a differential pair in it
>> * Set differential pair design rules to 0.21mm trace, 0.15mm space
>> * Route differential pair in such a way that there's skew between the halves
>> * Try to skew-match
>>
>> Expected result: overlay appears, says "too short", mouse motion adds
>> meanders
>>
>> Actual result: Overlay appears, says "too short", no meanders are created
>>
>> I've had the issue with other dimensions as well, it appears that having
>> trace width greater than space is necessary but not sufficient to cause
>> the problem.
> 
> Hi Andrew,
> 
> Could you send a sample PCB file with a diff pair that causes the issue
> (and tell us what target length we should use?)
> 
> Cheers,
> Tom
> 
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
(kicad_pcb (version 20170123) (host pcbnew "(2017-03-12 revision 
28a6ca1)-master")

  (general
(links 2)
(no_connects 2)
(area 66.67 75.48 82.920001 94.1975)
(thickness 1.6)
(drawings 0)
(tracks 14)
(zones 0)
(modules 1)
(nets 11)
  )

  (page A4)
  (layers
(0 F.Cu signal)
(31 B.Cu signal)
(32 B.Adhes user)
(33 F.Adhes user)
(34 B.Paste user)
(35 F.Paste user)
(36 B.SilkS user)
(37 F.SilkS user)
(38 B.Mask user)
(39 F.Mask user)
(40 Dwgs.User user)
(41 Cmts.User user)
(42 Eco1.User user)
(43 Eco2.User user)
(44 Edge.Cuts user)
(45 Margin user)
(46 B.CrtYd user)
(47 F.CrtYd user)
(48 B.Fab user)
(49 F.Fab user)
  )

  (setup
(last_trace_width 0.25)
(trace_clearance 0.125)
(zone_clearance 0.508)
(zone_45_only no)
(trace_min 0.2)
(segment_width 0.2)
(edge_width 0.15)
(via_size 0.8)
(via_drill 0.4)
(via_min_size 0.4)
(via_min_drill 0.3)
(uvia_size 0.3)
(uvia_drill 0.1)
(uvias_allowed no)
(uvia_min_size 0.2)
(uvia_min_drill 0.1)
(pcb_text_width 0.3)
(pcb_text_size 1.5 1.5)
(mod_edge_width 0.15)
(mod_text_size 1 1)
(mod_text_width 0.15)
(pad_size 1.524 1.524)
(pad_drill 0.762)
(pad_to_mask_clearance 0.2)
(aux_axis_origin 0 0)
(visible_elements FF7F)
(pcbplotparams
  (layerselection 0x00030_)
  (usegerberextensions false)
  (excludeedgelayer true)
  (linewidth 0.10)
  (plotframeref false)
  (viasonmask false)
  (mode 1)
  (useauxorigin false)
  (hpglpennumber 1)
  (hpglpenspeed 20)
  (hpglpendiameter 15)
  (psnegative false)
  (psa4output false)
  (plotreference true)
  (plotvalue true)
  (plotinvisibletext false)
  (padsonsilk false)
  (subtractmaskfromsilk false)
  (outputformat 1)
  (mirror false)
  (drillshape 1)
  (scaleselection 1)
  (outputdirectory ""))
  )

  (net 0 "")
  (net 1 /FOO_N)
  (net 2 "Net-(P1-Pad9)")
  (net 3 /FOO_P)
  (net 4 "Net-(P1-Pad5)")
  (net 5 "Net-(P1-Pad6)")
  (net 6 "Net-(P1-Pad12)")
  (net 7 "Net-(P1-Pad11)")
  (net 8 "Net-(P1-Pad10)")
  (net 9 "Net-(P1-Pad7)")
  (net 10 "Net-(P1-Pad8)")

  (net_class Default "This is the default net class."
(clearance 0.125)
(trace_width 0.25)
(via_dia 0.8)
(via_drill 0.4)
(uvia_dia 0.3)
(uvia_drill 0.1)
(add_net /FOO_N)
(add_net /FOO_P)
(add_net "Net-(P1-Pad10)")
(add_net "Net-(P1-Pad11)")
(add_net "Net-(P1-Pad12)")
(add_net "Net-(P1-Pad5)")
(add_net "Net-(P1-Pad6)")
(add_net "Net-(P1-Pad7)")
(add_net "Net-(P1-Pad8)")
(add_net "Net-(P1-Pad9)")
  )

  (module azonenberg_pcb:CONN_HEADER_2.54MM_2x6_RA_PMOD_MODULE (layer F.Cu) 
(tedit 58C5FEED) (tstamp 58C878C1)
(at 74.8 85.52)
(path /58C8788E)
(fp_text reference P1 (at -5.08 7.27) (layer F.SilkS)
  (effects (font (size 1.5 1.5) (thickness 0.15)))
)
(fp_text value CONN_6X2 (at -1.27 -3.81) (layer F.Fab)
  (effects (font (size 1.5 1.5) (thickness 0.15)))
)
(f

[Kicad-developers] Differential pair skew matching fails with certain dimensions

[Andrew Zonenberg]

This one is probably for Orson or Tom...


Tested with latest code from git (on Debian Jessie), but I also had the
issue with my old version (a few weeks old, forgot to write down the
exact hash).

Steps to reproduce:
* Create schematic that has a differential pair in it
* Set differential pair design rules to 0.21mm trace, 0.15mm space
* Route differential pair in such a way that there's skew between the halves
* Try to skew-match

Expected result: overlay appears, says "too short", mouse motion adds
meanders

Actual result: Overlay appears, says "too short", no meanders are created

I've had the issue with other dimensions as well, it appears that having
trace width greater than space is necessary but not sufficient to cause
the problem.



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Going to update default via size

[Andrew Zonenberg]

I dont know the DRC code but it should be easy: enumerate all pads and
vias, measure outside diameter and drill size and subtract. If less than
minimum, complain.

On 05/06/16 14:54, Chris Pavlina wrote:
> I would like that very much, but not sure how feasible it is. Thoughts from
> someone who knows the DRC code?
> 
> On Sun, Jun 05, 2016 at 02:49:15PM -0700, Andrew Zonenberg wrote:
>> On that note... Thoughts on adding a new DRC rule for minimum annular ring?
>>
>>
>> On 05/06/16 14:29, Chris Pavlina wrote:
>>> Yeah, the vias still have their size stored in the pcb file.
>>>
>>> On Sun, Jun 05, 2016 at 09:27:08PM +, Jon Neal wrote:
>>>> Sounds like a fantastic idea. I've definitely been bitten by this one as
>>>> well.
>>>>
>>>> I am assuming this will still keep backwards compatibility for those who
>>>> have already created boards with default sized vias?
>>>>
>>>> On Sun, Jun 5, 2016 at 5:23 PM José Ignacio <jose.cyb...@gmail.com> wrote:
>>>>
>>>>> I like both suggestions, I got bitten by the annular ring issue before
>>>>> because the DRC doesn't even check for that.
>>>>>
>>>>> On Sun, Jun 5, 2016 at 4:06 PM, Chris Pavlina <pavlina.ch...@gmail.com>
>>>>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Just a quick warning - I'm going to update the default via size to 0.8mm
>>>>>> diam/0.4mm drill, as the current default of 0.6/0.4 isn't manufacturable
>>>>> at
>>>>>> most general purpose fabs. Annular ring too narrow. That should be
>>>>>> uncontroversial, but I'm still giving a bit of warning to make sure
>>>>> nobody's
>>>>>> too attached to that.
>>>>>>
>>>>>> Simon Wells suggested allowing that value to be read from the .pro
>>>>> instead, so
>>>>>> it can be set in the default template instead of hardcoded. I might do
>>>>> that
>>>>>> later, as it seems like a win in general. Objections?
>>>>>>
>>>>>> --
>>>>>> Chris
>>>>>>
>>>>>> ___
>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>> Post to : kicad-developers@lists.launchpad.net
>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>> ___
>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>> Post to : kicad-developers@lists.launchpad.net
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
> 
> 



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Going to update default via size

[Andrew Zonenberg]

On that note... Thoughts on adding a new DRC rule for minimum annular ring?


On 05/06/16 14:29, Chris Pavlina wrote:
> Yeah, the vias still have their size stored in the pcb file.
> 
> On Sun, Jun 05, 2016 at 09:27:08PM +, Jon Neal wrote:
>> Sounds like a fantastic idea. I've definitely been bitten by this one as
>> well.
>>
>> I am assuming this will still keep backwards compatibility for those who
>> have already created boards with default sized vias?
>>
>> On Sun, Jun 5, 2016 at 5:23 PM José Ignacio  wrote:
>>
>>> I like both suggestions, I got bitten by the annular ring issue before
>>> because the DRC doesn't even check for that.
>>>
>>> On Sun, Jun 5, 2016 at 4:06 PM, Chris Pavlina 
>>> wrote:
 Hi,

 Just a quick warning - I'm going to update the default via size to 0.8mm
 diam/0.4mm drill, as the current default of 0.6/0.4 isn't manufacturable
>>> at
 most general purpose fabs. Annular ring too narrow. That should be
 uncontroversial, but I'm still giving a bit of warning to make sure
>>> nobody's
 too attached to that.

 Simon Wells suggested allowing that value to be read from the .pro
>>> instead, so
 it can be set in the default template instead of hardcoded. I might do
>>> that
 later, as it seems like a win in general. Objections?

 --
 Chris

 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Margin (and others) layers question

[Andrew Zonenberg]

Mask is used on pretty much any design. Paste is used on any design that
will be reflowed (probably 95% of designs these days, if not more) so
they're hardly advanced.

On 22/04/16 07:50, Duane Johnson wrote:
> I recently taught a class on KiCad to beginning users and one of the
> points of difficulty was understanding what so many layers are for. I
> was thinking, it would be nice if there were a divider in the layers
> panel, above which could be displayed the "commonly used layers" and
> below could be the "advanced layers":
> 
> F.Cu
> B.Cu
> F.SilkS
> B.SilkS
> Edge.Cuts
> -
> F.Adhes
> B.Adhes
> F.Paste
> B.Paste
> F.Mask
> B.Mask
> Dwgs.User
> Cmts.User
> Eco1.User
> Eco2.User
> Margin
> F.CrtYd
> B.CrtYd
> F.Fab
> B.Fab
> 
> This would make things much easier for a beginner to engage with.
> 
> On Fri, Apr 22, 2016 at 8:45 AM, jp charras  > wrote:
> 
> Le 22/04/2016 16:08, i...@elektroquark.com
>  a écrit :
> > So no layers defined for assembly as IPC-7351C suggest.
> 
> F.Fab and B.Fab can be used for assembly drawings. This is your choice.
> 
> >
> >
> >
> > 2016-04-22 16:01 egunean, Chris Pavlina-(e)k idatzi du:
> >> Yup. I often use it to specify regions where I don't want
> components placed,
> >> like to set a 5mm border around the edge to keep things from
> being too close.
> >> That's about what I understood its purpose to be.
> >>
> >> On Fri, Apr 22, 2016 at 03:56:52PM +0200, jp charras wrote:
> >>> Le 22/04/2016 15:06, i...@elektroquark.com
>  a écrit :
> >>> > Hello,
> >>> >
> >>> > I don't know really what the Margin layer (Board's edge
> setback outline) is for.
> >>> > What is the real use and the difference from Edge Cuts?
> >>> >
> >>> > I need it for a useful translation of "Board's edge setback
> outline" to Spanish.
> >>> >
> >>> > And, are F.Fab and B.Fab for assembly drawings (part body
> drawings)?
> >>> >
> >>> > Thank you.
> >>> >
> >>> > Iñigo.
> >>>
> >>> Currently, there is no specific code for the margin layer, so it
> has *currently* no specific
> >>> properties.
> >>>
> >>> However, it is intended to define electrical margins (clearance)
> on a board (first target: define a
> >>> clearance for board edges or define any clearance area inside a
> board, just by placing lines of
> >>> defined width (clearance) on the board or on its outline)
> >>>
> >>> This is currently a reserved layer, until some code relative to
> this layer is written.
> >>>
> >>> --
> >>> Jean-Pierre CHARRAS
> >>>
> >>> ___
> >>> Mailing list: https://launchpad.net/~kicad-developers
> >>> Post to : kicad-developers@lists.launchpad.net
> 
> >>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>> More help   : https://help.launchpad.net/ListHelp
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> 
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> 
> 
> --
> Jean-Pierre CHARRAS
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] PATCH: Dirty flag to prevent double-commit of routing in PNS

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The current PNS_LINE_PLACER::GetModifiedNets() always returns the net
being routed, even if it hasn't changed since the last FixRouting()
call. This leads to unnecessary rebuilds of the ratsnest, which can
take several hundred milliseconds on large boards.

My patch (on launchpad at
https://code.launchpad.net/~azonenberg/kicad/performance-patches) adds
a dirty flag to PNS_PLACEMENT_ALGO, currently only used by
PNS_LINE_PLACER, that indicates whether the placer has had any changes
made to it since the last time routing was committed.

On my current design, this reduces the UI hang after drawing a ground
track from ~700 ms to ~350 ms.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJWvX6PAAoJEDRhermzHH18kucP/AjKoZzS+yMtyIByA3hvhgqq
mCzE9bPkwnahfxsyawQIIE4wf8dvRYSeSA/c9fRol5nFrWWHiF7AjJB/n7AeJkTy
/TdqF5fL2T/AtxnDeT1YdJ88aVtudy2DQjtNIQOU61LWs702NZucGwnMp4C8DNR2
oF3eR1/oDeL7o1DYj3A8HW97d7ZFmsIStSN3vnbkGLWeD2JPXReYw9kmFgevyXwK
V7OUCpuOclWzDhLcGGYzjttBSIydnD3rHvCWpRTcGnNfbV/5/UKDCrcBkxVKEN1j
Kx6R20neu8/6fMDFFR+Q8cJTYmg74aZNNc1GVvQPJLOGbL6cXgHRUIchnwFJuNUc
9dmd4trNRghPODBpK9ZEr02/l354UB0hTctE18YAc6Fl8qLMT2fUbQHCxndFYs1P
8VSz2o6w/6KI/I9xkaYJwwseXrYcT2XmRCbnj/cHaw+UhxIymUQtyZHep8awvzSd
s6OPEErSsZNw6/TyMG07MW8qoUmBNvlp8LPAHl84ZAtmkGMbCAzoDIcyaLn/0zPN
YR+k+YE6wI2Kl3x5r2KsOt+PbdGrQ5MugeAC6jEtAMvzWbnpw6IplbFDvor4bGB+
qFoa+BoEBJRB9DRdu4ACCpsW5NyvS17VO5qL6b0QFi9yJONZCve7poYA1asYZMUz
suto/8qc5ob8qnrkMVU2
=FFf5
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Discussion: Hidden Pins, Net labels

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This sounds like the best option to me - keep the feature around but
throw a DRC error if you try to use it. This keeps old designs working
(albeit with warnings) and discourages use of hidden connections in
new designs.

Eventually, if the project reaches a consensus in the future, the
creation of new hidden-pin components can be disabled in the UI (or
maybe require an explicit preference change / warning dialog to
enable); existing ones will continue to work for compatibility.

On 06/02/16 09:12, Thor-Arne wrote:
> I think the multiple netnames on the same net should be included in
> the roadmap v5 DRC check. This should as a minimum throw a warning
> as this might break the finished pcb.
> 
> It might also affect the hidden pins issue as one might have
> several supply voltages connected to VCC pins. However, it's better
> to get warned by this in eeschema than risking having parts
> supplied with 5V when it should have been 3.3V.
> 
> I see no issues with this for backwards compability.
> 
> -Original Message- From: Wayne Stambaugh Sent: Saturday,
> February 06, 2016 4:52 PM To: kicad-developers@lists.launchpad.net 
> Subject: Re: [Kicad-developers] Discussion: Hidden Pins, Net
> labels
> 
> I would not have allowed that to be implemented.  One thing I try
> to avoid is forcing users down the "one true way" path of pcb
> design whenever possible.  I prefer to give users the flexibility
> to design as they see fit even if it means that kicad has a steeper
> learning curve. I don't pretend to be wise enough to know what the
> "one true way" is and I really don't like someone else forcing it
> upon me so it would be hypocritical of me to force it upon someone
> else.  If you are comfortable with hidden pins, use them.  If not,
> don't.
> 
> On 2/6/2016 9:59 AM, Thor-Arne wrote:
>> I agree with Chris on the hidden pins issue, old design should
>> not be broken.
> 
> That is also a no-no for the project.  One of the goals of kicad is
> to make every effort to maintain backwards compatibility.
> 
>> 
>> When it comes to net names I think they should be forced to be
>> unique.
>> 
>> Anyway, are we going to collect features requests now? Would it
>> be better to have a wanted-feauture list on github instead of the
>> mail list so nothing gets lost?
> 
> Take a look at the release 5 (current development cycle) road map. 
> Maybe we can add it to one of the existing tasks where it makes
> sense. Please keep in mind, we cannot endlessly add tasks to the
> release 5 road map.  We need to be realistic about what we can
> achieve given our current manpower.  I can always add new tasks to
> the global road map for future dev cycles.
> 
>> 
>> 
>> -Original Message- From: Chris Pavlina Sent: Saturday,
>> February 06, 2016 3:30 PM To: André S. Cc: KiCad Developers 
>> Subject: Re: [Kicad-developers] Discussion: Hidden Pins, Net
>> labels
>> 
>> Eh. I agree 100% about hidden pins being Bad, anyone using them
>> surely should be tarred and feathered. But I'm not sure it's our
>> place to enforce good schematic drawing practices. If people want
>> to use KiCad to draw terrible, horrible schematics, they'll find
>> a way. Personally, I'm *strongly* against breaking old projects,
>> the feature should be kept around at least as a legacy support
>> feature for old projects that are imported.
>> 
>> I just don't use hidden pins, they're strictly forbidden in my
>> libs and I would never use them for anything other than
>> implementing power symbols.
>> 
>> On the fence about net names.
>> 
>> On Sat, Feb 06, 2016 at 03:22:04PM +0100, André S. wrote:
>>> Hi everyone,
>>> 
>>> this issues are still on my wishlist for KiCad: - Ban hidden
>>> Pins. - Disallow multiple labels on the same net. Especially
>>> the combination of those two is a source for non-obvious 
>>> design bugs.
>>> 
>>> Wayne recently stated that now the planning for release 5 has
>>> started, so I just thought I bring it up again.
>>> 
>>> I wrote a blog entry why I think those two topics should be
>>> addressed, you can find it here (warning: wall of text ahead
>>> ;)): 
>>> http://transistorgrab.de/2016/02/05/why-hidden-pins-are-evil-and-net
s-should-only-have-one-name/
>>>
>>>
>>>
>>>
>>> 
I'm really interested that at least there is a definite conclusion for
>>> KiCad and that this conclusion is then put somewhere obvious in
>>> the documentation with all the pitfalls that come with that
>>> features and how to avoid them.
>>> 
>>> Thanks in advance for anyone taking part in the discussion. :)
>>> 
>>> Best Regards, André
>>> 
>>> ___ Mailing list:
>>> https://launchpad.net/~kicad-developers Post to :
>>> kicad-developers@lists.launchpad.net Unsubscribe :
>>> https://launchpad.net/~kicad-developers More help   :
>>> https://help.launchpad.net/ListHelp
>> 
>> ___ Mailing list:
>> 

Re: [Kicad-developers] Discussion: Hidden Pins, Net labels

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I do the same thing - power flags and hidden pins are banned in my
designs. To supply power to a net I set the "power output" flag on the
pins of the connector going to the battery/power plug.

On 06/02/16 09:23, André S. wrote:
> Ok, I see your point regarding not breaking old designs.
> 
> However: the current KiCad broke mine, since it does regard hidden
> pins different than "the old KiCad" (around 2013). The old KiCad
> connected a visible "hidden pin" only to the connected net. The
> current KiCad still connects it to "VDD" regardless of the
> connected net and therefore connects two different named nets.
> Which then forbids the use of "VDD" for a power net, when you use a
> KiCad library part with hidden pins in your design and connect its
> power pin to a no-"VDD" net.
> 
> BUT if I did "the right thing" right from start, KiCad would have
> warned me, that I connected two "power nets". Which it does when I
> place a "power flag" on each net. (Which is one way where KiCad
> forces its "true way" where other tools have the "power flag" built
> into the power net symbols.)
> 
> I learned my lesson on this one: do not use KiCad library parts,
> create your own.
> 
> Regarding multiple names on (not power) nets. There was a
> discussion some time ago. If I remember correctly, most people that
> use that feature would be OK with net-aliases (which is what they
> use that feature for) and having a fixed name on that net. 
> Currently when a net has a name and you add a new label it may
> occur that KiCad uses the new label name for the net. In the PCB
> the trace then gets a new name, which may not be what the user
> intended. Also with the current implementation you may accidentally
> connect two nets and have _no_ way to check this with ERC.
> 
> My proposal on this is: Newer KiCad versions can check for multiple
> names on a net and raise an error/warning when it sees one. 
> Therefore the user has a way to see accidentally connected nets. 
> Regarding not breaking old designs: One way: KiCad will need a
> dialog window where the user can add aliases to the net to keep
> current functionality. This dialog  may be accessible from the ERC
> report window to give the user a way to do it the "right way". Net
> aliases are then handled like net labels but do not (re)define the 
> name of the net in the netlist. OR second way: The user ignores the
> error/warning and works as before.
> 
> André
> 
> On 06.02.2016 16:52, Wayne Stambaugh wrote:
>> I would not have allowed that to be implemented.  One thing I try
>> to avoid is forcing users down the "one true way" path of pcb
>> design whenever possible.  I prefer to give users the flexibility
>> to design as they see fit even if it means that kicad has a
>> steeper learning curve. I don't pretend to be wise enough to know
>> what the "one true way" is and I really don't like someone else
>> forcing it upon me so it would be hypocritical of me to force it
>> upon someone else.  If you are comfortable with hidden pins, use
>> them.  If not, don't.
>> 
>> On 2/6/2016 9:59 AM, Thor-Arne wrote:
>>> I agree with Chris on the hidden pins issue, old design should
>>> not be broken.
>> That is also a no-no for the project.  One of the goals of kicad
>> is to make every effort to maintain backwards compatibility.
>> 
>>> When it comes to net names I think they should be forced to be
>>> unique.
>>> 
>>> Anyway, are we going to collect features requests now? Would it
>>> be better to have a wanted-feauture list on github instead of 
>>> the mail list so nothing gets lost?
>> Take a look at the release 5 (current development cycle) road
>> map. Maybe we can add it to one of the existing tasks where it
>> makes sense. Please keep in mind, we cannot endlessly add tasks
>> to the release 5 road map.  We need to be realistic about what we
>> can achieve given our current manpower.  I can always add new
>> tasks to the global road map for future dev cycles.
>> 
>>> 
>>> -Original Message- From: Chris Pavlina Sent: Saturday,
>>> February 06, 2016 3:30 PM To: André S. Cc: KiCad Developers 
>>> Subject: Re: [Kicad-developers] Discussion: Hidden Pins, Net
>>> labels
>>> 
>>> Eh. I agree 100% about hidden pins being Bad, anyone using them
>>> surely should be tarred and feathered. But I'm not sure it's
>>> our place to enforce good schematic drawing practices. If
>>> people want to use KiCad to draw terrible, horrible schematics,
>>> they'll find a way. Personally, I'm *strongly* against breaking
>>> old projects, the feature should be kept around at least as a 
>>> legacy support feature for old projects that are imported.
>>> 
>>> I just don't use hidden pins, they're strictly forbidden in my
>>> libs and I would never use them for anything other than
>>> implementing power symbols.
>>> 
>>> On the fence about net names.
>>> 
>>> On Sat, Feb 06, 2016 at 03:22:04PM +0100, André S. wrote:
 Hi everyone,
 
 this 

Re: [Kicad-developers] Slow performance in pcbnew (PNS/GAL only) on high-fanout nets

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Apparently most of the run time in processPads() was caused by copying
the RN_NODE_SET "candidates".

I have a one-line patch in my branch
(https://code.launchpad.net/~azonenberg/kicad/drc-patches/+merge/284682)
that changes this copy to a const reference. There's probably room for
bigger speedups but this was a trivial (and significant) optimization.

On 01/02/16 10:33, Andrew Zonenberg wrote:
> Pads on the same net overlapping should not necessarily be a DRC 
> error, consider the case of someone trying to make a D-shaped pad
> by putting a round one on top of a rectangle. Maybe if they're not
> part of the same component?
> 
> Here's some quick performance numbers for the ground net on my
> board.
> 
> processPads took 0.266 sec Update took 0.377 sec processPads took
> 0.275 sec Update took 0.383 sec processPads took 0.293 sec Update
> took 0.403 sec processPads took 0.305 sec Update took 0.413 sec
> 
> So looks like processPads is about 3/4 of the total run time of 
> Update(). Will look into that a little bit and see if there's any 
> obvious speedups.
> 
> On 01/02/16 06:24, Maciej Sumi?ski wrote:
>> Apparently the most expensive part is RN_DATA::processPads()
>> that does collision checks for pads. It handles cases when tracks
>> do not end in the middle of a pad, or when pads overlap (IMHO
>> this should be caught by DRC as an error instead, as pointed out
>> at FOSDEM).
> 
>> If you do not care about mini ratsnest lines when a track ending 
>> and a pad center have different coordinates, then you should be 
>> safe commenting it out (ratsnest_data.cpp:417). There is an idea
>> to improve speed here, but it requires more changes and has to be
>> well planned first.
> 
>> Regards, Orson
> 
>> On 01/31/2016 09:27 PM, Andrew Zonenberg wrote:
>>> When working on a board with a lot of pads, terminating a
>>> trace on a high-fanout net results in a significant (a second
>>> or more) hang of the entire UI. I haven't yet attempted to
>>> figure out what part of the code this hang is in.
>>> 
>>> Steps to reproduce:
>>> 
>>> 1) Open a large board file in pcbnew (I'm testing with 
>>> http://thanatos.virtual.drawersteak.com/unlisted/marblewalrus-switch
.
>
>>> 
kic
>>> 
>>> 
> ad_pcb)
>>> in GAL mode. The hang does not appear to be reproducible in 
>>> legacy.
>>> 
>>> 2) Start drawing a track on a high-fanout net (GND is a good 
>>> example)
>>> 
>>> 3) Performance should be normal when the track is started and 
>>> during drawing, but when you click on a pad to terminate the 
>>> track pcbnew hangs .
>>> 
>>> Anybody with PNS experience (Orson, Tomasz, etc) care to 
>>> investigate thi s?
>>> 
>>> ___ Mailing list: 
>>> https://launchpad.net/~kicad-developers Post to : 
>>> kicad-developers@lists.launchpad.net Unsubscribe : 
>>> https://launchpad.net/~kicad-developers More help   : 
>>> https://help.launchpad.net/ListHelp
>>> 
> 
> 
> 
> ___ Mailing list:
> https://launchpad.net/~kicad-developers Post to :
> kicad-developers@lists.launchpad.net Unsubscribe :
> https://launchpad.net/~kicad-developers More help   :
> https://help.launchpad.net/ListHelp
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJWr+OnAAoJEDRhermzHH18xjcP/R3PEm3qdUcFsWzLB7/FtX0m
A9AgVU/r9wlojpFluyZDdH2+yWEkofqtRODbNnhn3tcSlLjrLz9hWusimEIzMAq9
rlVVF0ODbih/HS3dpcGj3HVrvnijeSNwbc0y8E54H3p7+zfabIRRqdoYZvbnlZ0d
SYhMzZuNKNtYK8IrQgme8oqLp1aNuPeLSr8Vje36D5vSFLcZ73mIK52+oKKW8xwY
21/I40U9FP6XLzOHnMoYtbQBbvIPgKmEft8veCF1iX1lojELqtC5kdoIDzLkCHya
m2QHmQKlafJMLRYT5+ziDtFq9G/fiVjkz2BRZLCF+lggp1h2hQ8xMkeuQqzmG2Lk
XxYrrFLA5OHQIQ1xU6ZV2cTOhILxL9lwxgow6xAopQOoddiBWAyHYxhp2Vdh1dXa
+/Mn5beXsVIlKdNAngnBSGDyQbu+tyXKh5x4yN5lqX/FypsgAMHs7dwqswroCp0b
FOGMHvFnSPh2YgsS7PQBEuiZHLUhxcTk825T09nDewtNcSp3MvZRJlWAVinLyPQ4
ljBsHAzvJf6z6rbsViFhFsypUD2C543fLPTBsQgfE5dowLv25TR8EFVld1OWmrD0
KbSshlcDnEHH+xyJFIUP/OJ2PC4C50lUVUobmANHPFSqdj4uh3ECBNe2hi+9ZhEx
1CQOMHAeDZ5mpY7iyTmu
=984p
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Slow performance in pcbnew (PNS/GAL only) on high-fanout nets

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Pads on the same net overlapping should not necessarily be a DRC
error, consider the case of someone trying to make a D-shaped pad by
putting a round one on top of a rectangle. Maybe if they're not part
of the same component?

Here's some quick performance numbers for the ground net on my board.

processPads took 0.266 sec
Update took 0.377 sec
processPads took 0.275 sec
Update took 0.383 sec
processPads took 0.293 sec
Update took 0.403 sec
processPads took 0.305 sec
Update took 0.413 sec

So looks like processPads is about 3/4 of the total run time of
Update(). Will look into that a little bit and see if there's any
obvious speedups.

On 01/02/16 06:24, Maciej Sumi?ski wrote:
> Apparently the most expensive part is RN_DATA::processPads() that
> does collision checks for pads. It handles cases when tracks do not
> end in the middle of a pad, or when pads overlap (IMHO this should
> be caught by DRC as an error instead, as pointed out at FOSDEM).
> 
> If you do not care about mini ratsnest lines when a track ending
> and a pad center have different coordinates, then you should be
> safe commenting it out (ratsnest_data.cpp:417). There is an idea to
> improve speed here, but it requires more changes and has to be well
> planned first.
> 
> Regards, Orson
> 
> On 01/31/2016 09:27 PM, Andrew Zonenberg wrote:
>> When working on a board with a lot of pads, terminating a trace
>> on a high-fanout net results in a significant (a second or more)
>> hang of the entire UI. I haven't yet attempted to figure out what
>> part of the code this hang is in.
>> 
>> Steps to reproduce:
>> 
>> 1) Open a large board file in pcbnew (I'm testing with 
>> http://thanatos.virtual.drawersteak.com/unlisted/marblewalrus-switch.
kic
>>
>> 
ad_pcb)
>> in GAL mode. The hang does not appear to be reproducible in
>> legacy.
>> 
>> 2) Start drawing a track on a high-fanout net (GND is a good
>> example)
>> 
>> 3) Performance should be normal when the track is started and
>> during drawing, but when you click on a pad to terminate the
>> track pcbnew hangs .
>> 
>> Anybody with PNS experience (Orson, Tomasz, etc) care to
>> investigate thi s?
>> 
>> ___ Mailing list:
>> https://launchpad.net/~kicad-developers Post to :
>> kicad-developers@lists.launchpad.net Unsubscribe :
>> https://launchpad.net/~kicad-developers More help   :
>> https://help.launchpad.net/ListHelp
>> 
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJWr6TrAAoJEDRhermzHH18+vYP/1ppPavkFyBE/rLs0TsPQF0+
mv5EPTQsLuiNe+ZY8NWY3PyRn/MdUcUNo1ja4ZwAiEWekqC0Qh/50Rnu+agyZXbI
SuZY0Xn77MmdfCrBZCzco68hVYfSFRuu3LL7V3/j+LAQT0icbE/4Xto5CGpkTzvy
Vsv5sZ13uYB3zRo8OkdMJkYhLCT4tNGcnnPNGFEjT7pqyqCYyKQhHZMT5K6oLHvO
BQpAni8N8EaPIvKNe7pyBkb1UxFqz+ks9iFAIJvFf9oT/+MWu2hhYP5HbjWZJmz0
KU0bs0Xb9M2fcHiMN7u2aNaojFuNiE2sXZo8XlrYfls7wtIFnZ5SLvu4l9G5v/6n
CHkWbfsKgMcG8KsN636pLZCwK/BG0VVMo/wgRCdWyjcLFWw+wmlka+DK3UKIjn3s
0/czStdT0jWC6KvLlGTzaCi5Y24xJX0arJELyxg6MvzvNGXhZ1yKYro6RH04AEaB
r+osJ1nO8n9TFnRuJf28Hiph3fJ60HOEujYpkbYRVDl4mYfvh3/8BC/LAUnTqYCG
+6vXmBUHJTZ9+d6zAiw4rj7K/yHJrix3QJFI8my5sEfxIdj62tgHZtXnpkhXFRRH
m78RcWpbLxIUzOWHhDIC5KPWnwEAiK+830M2yAId1kwCHoz4w0KzBPGcSjioyToR
7Wwpb3Xy0HVrpJt6xAaZ
=OIA0
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Slow performance in pcbnew (PNS/GAL only) on high-fanout nets

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

When working on a board with a lot of pads, terminating a trace on a
high-fanout net results in a significant (a second or more) hang of
the entire UI. I haven't yet attempted to figure out what part of the
code this hang is in.

Steps to reproduce:

1) Open a large board file in pcbnew (I'm testing with
http://thanatos.virtual.drawersteak.com/unlisted/marblewalrus-switch.kic
ad_pcb)
in GAL mode. The hang does not appear to be reproducible in legacy.

2) Start drawing a track on a high-fanout net (GND is a good example)

3) Performance should be normal when the track is started and during
drawing, but when you click on a pad to terminate the track pcbnew hangs
.

Anybody with PNS experience (Orson, Tomasz, etc) care to investigate thi
s?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJWrm5IAAoJEDRhermzHH18YI4P/1wRR1OXvOp9X0YBMMt1QpHw
8hEpVeinwteDJ8mIM7e5oFy1Ebcl9LudQPdgr6W00bw2pGW+lexL1mCSIGksZ+8w
fFa9t7VkLAUN1jtEdXluAQnEtlkdlSWukqE3wXu7iYz+dIB/erE0xyjELQWx4ri6
TRyM1PSv4tZUHmeFnSyCcNWbvqUcVi5V890giF+P6E3KO4QanbHID/ZJ5Btrm7OY
eC/Q+gx0DJbLHU7mZglfCE2C62Wnjy8+Sx7mSU/CgRS/sQdt9a9KclFLEFJlCBEh
jS4mqS8pdXHJXv6vBX8E82VdEqTxrQdRzScSAH65YjUDIzUULnQ2exTuAc+N7/fc
4JtvKf94NQhoTyZv8waMZHzRyqbJuvQno6SrkzH/aRhAAxC59T6SLpirC9ur0AjJ
4aHvyP3zZu/QdHdvVtQlZF9IDMT1CRLdOTszs87StHeNQ5K/WZtIxCw1dXiputy1
ergQv1En59OQJRBKbAvuhktZdRHfb5FWLiLshaGNJOKE18Za6LSMzrAYrcQOMPGL
K7YVF4QYcnAWyDHJbcQ/Nu+1Y28CjmqdLvv1O5fwGmpGxa4BHAZ/F8LGAqsnofdd
spudVScB7/FVz30dHv6nwFLOy4x8UABJ0V3/fumCsgnl4UlgvSzss/7APIXq2O2O
Cp0dzalot30IxX/YSjgt
=+1BI
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Slow performance in pcbnew (PNS/GAL only) on high-fanout nets

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sounds good. What file/function is that code in? Maybe I can help take
a look at it.

The board is the Ethernet switch module for the MARBLEWALRUS FPGA
cluster (http://redmine.drawersteak.com/projects/marblewalrus/wiki).
Nine 1000base-KX interfaces on the backplane, then three 1000base-X
SFPs and one 10gbase-R SFP+ on the front panel. The fast path of the
switch runs entirely in the XC7A200T FPGA; there's an 18mbit QDR-II+
SRAM for packet buffering if necessary. If I later add layer-3 routing
capabilities (on the longer term TODO) the slow path and routing
protocols will run on the XC7Z010 SoC at the top of the board.

On 31/01/16 15:11, Tomasz Wlostowski wrote:
> On 31.01.2016 21:27, Andrew Zonenberg wrote:
>> When working on a board with a lot of pads, terminating a trace
>> on a high-fanout net results in a significant (a second or more)
>> hang of the entire UI. I haven't yet attempted to figure out what
>> part of the code this hang is in.
>> 
>> Steps to reproduce:
>> 
>> 1) Open a large board file in pcbnew (I'm testing with 
>> http://thanatos.virtual.drawersteak.com/unlisted/marblewalrus-switch.
kic
>>
>>
>
>> 
ad_pcb)
>> in GAL mode. The hang does not appear to be reproducible in 
>> legacy.
>> 
>> 2) Start drawing a track on a high-fanout net (GND is a good 
>> example)
>> 
>> 3) Performance should be normal when the track is started and 
>> during drawing, but when you click on a pad to terminate the
>> track pcbnew hangs .
>> 
>> Anybody with PNS experience (Orson, Tomasz, etc) care to 
>> investigate thi s?
> 
> Hi Andrew,
> 
> Thanks for the report.
> 
> It's the ratsnest update, it can take a significant time for
> highly fanouted nets - we're going to optimize it.
> 
> Tom
> 
> BTW. Nice project, are you designing some specialized Ethernet
> switch?
> 
> 
>> 
>> ___ Mailing list: 
>> https://launchpad.net/~kicad-developers Post to : 
>> kicad-developers@lists.launchpad.net Unsubscribe : 
>> https://launchpad.net/~kicad-developers More help   : 
>> https://help.launchpad.net/ListHelp
>> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJWrqAdAAoJEDRhermzHH18F/cP/jjwu+PUyxhGBaagq5OI4k5+
iVQlhi0mpAQu6czKXc76DxqOzof/WMMN7gn+XSCUENh+zH4Ym0UDMqwl3XkGNIXm
ReWJYVc6lr5vgkc7k27xDgzxfk+ivq3C/bTacDTGrY520FtYP/gxpcvpaW/39ym/
F/WvMMbhvVqzyi+XyVMLRGT4Kg9f+RAsbYIlxzleknTo7T7sr75RHiBf8TyPbEWR
O95rNOVFAqjoF5DerRjng0nlHCxeBncB6n7rUIhOzbUsH2JXJUjnw0sd2hJ7c0Gd
H9Q9k7N9D7Vxs1CclG1eUG/HANqvcT65SKH8r302tbKiR6kWB6/Ho+Yjq7attOTN
Cb0mkO+JleFP9AXFvk3uygfMxPZfvFiVlQBXvooPiCi9Ba1AyzfG5bCFH+FJUA74
0NZXhAsixesWfbJwXME01uHXpL9vTxQn53mi1iMxYEQ14FiNkwCvwIKjjOFOLJen
qy3sGbR+ei62iIBFst6wCS31g0dO1hFGrjx6UgpTl3FJHbZzBjD4h5513tmOzc69
eP4CM1o1R0GuUR3N9dbDsuAR0z48YmFGUTkqTHELuysfo0P14nnRZ2tWypzibmJQ
nyITanORHtkWfGF4fZeM8gkvdgnMEmWhsKQhG6iVdM4YOHF8G72fu8s/qN1d3kPt
MXj4caZlQbnx9iuzQEkr
=eQcu
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] PATCH: Make DRC not report clearance violations between technical pads and copper pads

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This patch makes the DRC not report clearance violations between
copper pads and non-copper pads (for example, a pad entirely on the
soldermask layer vs a pad on top copper). There were some mentions of
this scenario in the existing code but it wasn't fully handled.

Branch at:

https://code.launchpad.net/~azonenberg/kicad/drc-patches
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJWpmn9AAoJEDRhermzHH18DEwP/j0Az7qYK8WH5hfjI8q0cjOI
goyuCATFW4B+U3Y9IjwUklvHYWZ2Jb2Pa0bw325/BlITDujOSEoDpQ/esyP0zlW3
j+DCAG4drHAl/rllmkjQnrj/NN2UnId0TtsxaKAINi1ZMMessPNyR9+A69PmgaEK
rHLxvTvaFFjxbVg65j8iGRDe9YAI2PylgM/oIONs7F77q4VZJOZMC5eeMGtvloSL
WXc9X/ubEq/S3tkNSUnEkx9++3xDlxPqcbaVQx6XuOUi16PU9f6RYWTcTRYq5Ji+
0ZhM25m4voIl/MFGzbqSxabxGAaQYd92brBs5RIkL9qnHtLSlyIvy+4qf54UpnH0
QMBDW9g5HXcWEwE3qy5dYukt78c9SheFklLSXGTz77Prg1GgyVEdvI9ZveK0io1R
hcalL9xMxGIQJeAdNpnyx8f8yGB8QicJDulq89OkC6wJC3EaWcyn0l1WlKdQeE3h
OydxdD21q6+tk3uS69MO2jVNGSHEqkjAzNKzuW1wG7zTSx408jiLpBvzoQM4S6vI
/Qvl3EsMUZo2lthNXDwyEXNXff+5XTWea6UDYLc8/lUmBwZeW5wV42xtyuC7U62c
5dRI4oy64Qsmmyke82XMVmXix+O7maH+goANr8XTaeQdhu05ITz22sIrV909/UkF
GiM076vRJCtgRxbzi9QL
=fiea
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] BZR 6510 breaks build for latest stable wxWidgets

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Investigated a bit more, looks like the issue was with the 3.1.x
version I had installed. Since 3.1 isn't released yet, some versions
labeled as 3.1 do not support the magnifier event functionality, so
the test thinks it's present even when it's not.

When using either latest wx from git or stable, it's fine.

On 24/01/16 23:44, jp charras wrote:
> Le 25/01/2016 08:21, Andrew Zonenberg a écrit :
>> The most recent commit (6510) requires wxWidgets 3.1.0 even
>> though the latest stable release is 3.0.x. As a result, it will
>> not build on any platform that is not using a pre-release
>> development build of wxWidgets.
>> 
>> If the intention was to #ifdef this feature and only enable it on
>>  3.1.x or higher, the check was done incorrectly or missed some 
>> stuff.
>> 
>> Steps to reproduce: Install latest stable wxWidgets and try to 
>> build BZR 6510.
>> 
> 
> I do not have any issue with wxWidgets 3.0.2
> 
> What is the error message?
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJWpdhzAAoJEDRhermzHH18DHMP/0spJ7h3XnoMrpgR7xp75/MN
KirHHovupklw9dAAjxi/VtVvIQ7zQoYBdLPb/MMKCFDG231LgjYQw2O1IBUU6evj
FUNNsDdPe37Tzyewrlhsoqtse/zfXVB3ltnyYPOvWxTJnwpsjttIsJr69j+W54AJ
PJPTl65TuI063EPAgtJltr+9JQ1ppi2SWDyAFFxw6tEWgoXLGQ+9imDTS//Q1v43
6fvrWR8bBjhGBCm1dq+Z3M6jUFcgbyWEtHMQCNILJ2wCrYUszCBTBNw8LqsBjCcF
XcrDZD4vyXxnECdlql8tr9HnFwIEiyAUNXvQZqHe1Dn8PahFhg3DitaH5eMMKmUy
YoxJIf66O3OpYGj38n8ouroMF0NSqHYB0luab1AXW+Dz3Xv1OPDDAe7sL+fDVqhv
PGM/T5H5RZspPn4HnujVU4fM0HUlR4tczLnMPKTZ0UukSJ8+5LykAi2zqlGeVlzV
dJm2I+9dcbdCvA4W/Ohdw0IHRGCURvTkSqrBuouC2ZE7BdB8z0lIozkSHFWZS+A+
GXswBr5/25OuqU06Ym19h5AafiGB5L6wCSHrybQ7Q053601mZ2Tjxks5mjjFxcIl
2Cnn1TNyx58XADxsHdP+T+CVq1PvAsrV4C/X6u/yzzk/UORtIUzCPs1GfNVris2k
JrLv/ln77Kv6+fIbWnNb
=Dhfh
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] BZR 6510 breaks build for latest stable wxWidgets

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The most recent commit (6510) requires wxWidgets 3.1.0 even though the
latest stable release is 3.0.x. As a result, it will not build on any
platform that is not using a pre-release development build of wxWidgets.

If the intention was to #ifdef this feature and only enable it on
3.1.x or higher, the check was done incorrectly or missed some stuff.

Steps to reproduce: Install latest stable wxWidgets and try to build
BZR 6510.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJWpcziAAoJEDRhermzHH18WhAP/3wcIvvWpSzYh18NPtVyIr21
E37MhedWUjE+XTATFquLMNlU18SHOctBgLypoF3wLAt7m1X7+XsbCmhea7rmc/pK
ShHpgEVyjmbanQlIk+yTFM7jF+SfH6KMHzYrE08Y6oIyX2gEoNFsS82/w8VPk82z
J6X2Zxtui9Z4ap0yy1LUQQfggw2RsurAp/+pShyoJjVSgVgse4o4M9g4pGvPwXFt
kmxZO/QWiNqy6ImS8fKkUaX3MjoAiAvfro+Y9DSEA6VzplNPWrXxlLwgIcOOH3Ka
Lv5cPuTVwqfneYShv//jDZLWSEdW7zY+aJXBsP62yw+rgwjuK27EXBjhoQ3OS1W9
n8UHFP+Qrdsb6uUMlQEnP4zwE6FgiFSoHWIgpJLAalxXx6hprl/No4oHfRQDi+Xr
GjTPOUJirabf5osH3IHW1IbVtlQk558B7AGDVMRnzCbVaSQ2k1KmRJy1fwlsEl8r
+W7hHP2cGuKJ/xGYwDsIoNgs2C7W2ZTVrwHxQOzVURKB21i432aeZ8VMozYIdfLl
U9KO2kWPYQbnt62juDb2zcYrKAWCEfoKpwWUDnSsBdP06v5c5LCyA2ZJI+Ijbzej
A5WqmwHCX3FLZzSZKETYmuLjNwe9GyUQdbJog7xDEz53iPl6mLrpUKgziH+l0/3Q
6tFdC9RdM4X9hHON4Oju
=Aelj
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Segfault in PNS on BZR 6317

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I can confirm this appears to fix it as well.

On 18/11/15 13:34, Nick Østergaard wrote:
> I just tested 6324 and I can not reproduc the segfault anymore \o/
> 
> 2015-11-18 15:41 GMT+01:00 Wayne Stambaugh <stambau...@gmail.com>:
>> On 11/18/2015 5:07 AM, Tomasz Wlostowski wrote:
>>> On 17.11.2015 20:07, Andrew Zonenberg wrote:
>>>> Hi,
>>>> 
>>>> I'm getting crashes in the PNS on latest BZR in both debug
>>>> and release builds.
>>>> 
>>> Hi Wayne,
>>> 
>>> Patch for the segfault in the attachment. There are also two
>>> more bugfixes: #1514081: recalculation of the ratsnest after
>>> drawing a zone in the GAL #1514126: performance improvement in
>>> zone processing code (it was using too much strict
>>> simplification)
>>> 
>>> Cheers, Tom
>>> 
>> 
>> Hey Tom,
>> 
>> I committed your patches in r6322.
>> 
>> Thanks,
>> 
>> Wayne
>> 
>> ___ Mailing list:
>> https://launchpad.net/~kicad-developers Post to :
>> kicad-developers@lists.launchpad.net Unsubscribe :
>> https://launchpad.net/~kicad-developers More help   :
>> https://help.launchpad.net/ListHelp
> 
> ___ Mailing list:
> https://launchpad.net/~kicad-developers Post to :
> kicad-developers@lists.launchpad.net Unsubscribe :
> https://launchpad.net/~kicad-developers More help   :
> https://help.launchpad.net/ListHelp
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJWTPAYAAoJEDRhermzHH18hdMP/2hhLGhZu20GT+w6ybCR8p3x
3164gLafKJsEtFUSY7HA7X8TFuDy1+tnS4jW039D1nm3P+YQCXdfbMg0tmmeQmIF
KfFz63Q5duL4vPmmthKc4HGFiNrSEDD3qlAT6tsChQVLvqlFed8SWiOI3fq8AAGf
/AsASu/8f7+839nyYNlr7bip6nzyDsgaktgELGLd/IcFOFon5Zwe4zCEFFyloEE0
egnhDJXnfFs+w2JQHxfqL8q5+nJwIiQuguXneOBnDYMxrNY3fWnTOjCmc5kw9cMz
kU/VPGfYXnST4mpfDO0I1z3w2cLaJiDeZWaKX+HAjO2LRjumKMiTvMztfFO8Lqz2
Dqg2X7QFbShGqc3/fBQa3Ol2iYRRZNx0OpNWQiNMBiK5hTEc50Pi8N4dbiv2VQwl
V+qP0SmQdUl68224ysBdEgC8Km07FxqL/6NUW05hG+eEh8H4RYT6TN4rj9Q4Cziq
y+NBAqhvnbCdn6fC1tgQqxWxkby646Z60wTyBW4RuTMlGCwmz31iAjIl6DLYvDPe
hUHweeS1Imoy9ucmN8KvxNO5WYxnHWPOBIq1vZKH/m1qCKbGoxTOQLa+byF5M39o
P7mMHBuqpw16lpVV3gmLN5RXNbsyBiUBD2XD7d+XzHpL9OFlFc0HMZv7rwxeAz5T
ENfzXIiY0KZS1rhDxCzq
=1a9h
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Segfault in PNS on BZR 6317

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Valgrind thinks it's a use-after-free: http://pastebin.com/8aCpbQAJ

On 17/11/15 11:07, Andrew Zonenberg wrote:
> Hi,
> 
> I'm getting crashes in the PNS on latest BZR in both debug and
> release builds.
> 
> GDB log: http://pastebin.com/i4kQvXwn
> 
> PCB file: 
> http://thanatos.virtual.drawersteak.com/unlisted/marblewalrus-backplan
e.
>
> 
kicad_pcb
> 
> System: Debian 7 amd64 with nvidia binary drivers
> 
> Steps to reproduce: * Open PCB file * Go to GAL mode if not already
> selected * Select grid 0.05 mm * Select via 0.5 / 0.25 mm * Select
> track 0.123 mm * Move the cursor over the track at (78.6, 64), this
> is CB2_I2C_SCL * Press X to begin drawing tracks, click on the
> track * Move the cursor to (78.6, 65.5) * Press V to create a new
> via. Immediate crash.
> 
> ___ Mailing list:
> https://launchpad.net/~kicad-developers Post to :
> kicad-developers@lists.launchpad.net Unsubscribe :
> https://launchpad.net/~kicad-developers More help   :
> https://help.launchpad.net/ListHelp
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJWS4DqAAoJEDRhermzHH18pm0QAJOF6X52OwBLVOPUgmeJisLJ
U9OZs0hIbu8uvSW+IY/uFkUDKQxw3njEX4ugg80d7xCUDYESysbMU326v317oq2O
neTh4CfSbOjmSDOqEMQ9FJg6bL1kRHGuRYei/VR/dLPrxZA/mrCzrhqdVfbcl8nc
839ff6dARQxP/YVfWbQNWryjhV/iI95uZCxiJPkc+Av+QMWDNOISqRK5CtsEWxBS
jhrdPNgZZ3g++E5PjWBFbZDzoXRRxRtbSF/DA0S4tU6hQLWgklZcW/KN4IodXbbK
JlyPszEO1v5fwF5ZaLlM2b9kxMsp2jMSMDfzxi8+rmyMire7YWuW+s9Ud/gT3ram
Y8lTXchqaifoF+c84Ux87+HrqlZNQJPJJChbvN4BaDBIPYyz86u3PEI5o9y33Fh/
n0T243IUh3i3YCZSdWrq2suak98iWd4XWY3ayWK3uomiSQ2XIWpw76FS2QbXTkQc
Cpdc9L++0pe2parHmNJRODqwHhhfOC3AIJf9VNIIqKldca5U/I/Cl/UY/1nH0KQT
uu4eJzUApiXcX9rcAxl+CtdRtEcybKvy6NJCYClC13brBdUOjOUjbU2jLb8B00ki
Sztjsty/SvLQrPdwOqLVhUOwsRjuExz7PJ5S0+E4G/AtMj9s2H51ztwvsiTmwb59
IkyBfBDxyeNnxrkNO72W
=oBVv
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Segfault in PNS on BZR 6317

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I'm getting crashes in the PNS on latest BZR in both debug and release
builds.

GDB log:
http://pastebin.com/i4kQvXwn

PCB file:
http://thanatos.virtual.drawersteak.com/unlisted/marblewalrus-backplane.
kicad_pcb

System: Debian 7 amd64 with nvidia binary drivers

Steps to reproduce:
* Open PCB file
* Go to GAL mode if not already selected
* Select grid 0.05 mm
* Select via 0.5 / 0.25 mm
* Select track 0.123 mm
* Move the cursor over the track at (78.6, 64), this is CB2_I2C_SCL
* Press X to begin drawing tracks, click on the track
* Move the cursor to (78.6, 65.5)
* Press V to create a new via. Immediate crash.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJWS3rzAAoJEDRhermzHH18ROQP/1LWlFkL1pjjVm9kvsV0mMHr
0iRI4ODvM1ISU3zFhsAdnbBigQgQK282KjNi0hbllzAEOftjibVv0QrbBzcnPyhL
oC8kurr2AHPIob8fOv2M1NQY5OtQcEbcux61XWj/gGm+CLSQ7Wyj21IV6rnF+5yn
dZ8FDVEr3sqRxr+Mr15aCYeesuxv3+bIJ6GNKxMhWe+OK3/s1fWjuHdC7dOXJjWq
up5+DdGW9zBGDUHwEnA81Gm9YrqggkiiNP87KOc1IlgWYKoxLLybuAUDj9PagkUV
fsALaAdEvxoyx1sB6JcZmTtuy2g8OUF2hGEF5sbTfKT7zhNNWJQdkFtkYYHtRnJr
3XcRqAVpxhIFvq7Wfe3vM0vNiX3UCD0U54bp+qEglo7BjzorEN9N6dgKMVRk7Bo+
qrVHB8XM2WqtHTt4OgiWBLsGBMeccv+u4QWEXEIikqFvQ2rPfLCswBUoGTGyIAuU
DIwdUehmuhGF8cINLQ5zCjJic4CJ84tj+gThxOcRegC4u1M/5/Hm8aHFN6LrUW63
39qBzjJWkPu/2Edhocm2NVBY2ppuO9F5b2c7fyCLplg41asjtwOWJvVIccj22y5q
xemyg5yiAzseLMpAmKohrA5OzxUpQzAi9JehLThdMk0QrU1RC+sVDXtDIcc+qMoe
xaVHU81Iqb2ZZAKeiZ3z
=IJ6t
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] RC2

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Confirmed to warn, but not crash, in r6302. Guess somebody fixed it
already.

On 07/11/15 13:04, Wayne Stambaugh wrote:
> On 11/06/2015 12:25 PM, Andrew Zonenberg wrote:
>> There's another bug I spent a while hunting for earlier this
>> week, but couldn't get too far with. Maybe someone else can pick
>> it up?
>> 
>> Steps to reproduce: * Open pad editor * Select pad type: SMT *
>> Select copper layers: none * Uncheck all technical layers
>> 
>> In the debug build this will display a warning but keep running;
>> in release it aborts or crashes.
>> 
>> Although *exiting* the pad editor should not be allowed if the
>> pad has no layers at all (or possibly pop up a dialog asking if
>> the user wants to delete it?), having no layers selected should
>> be a legal intermediate state during editing of a pad stack.
> 
> I cannot even exit the pad properties dialog using the OK button.
> I keep getting an error message dialog "Error: no layer selected."
> every time I hit the OK button.  I'm using r6302 on Debian testing
> amd64 build.
> 
>> 
>> On 06/11/15 09:04, Mark Roszko wrote:
>>> One thing I didn't think was fixed yet was a null dereference 
>>> introduced with the clipper library upgrade. jp fixed the 
>>> uninitialized warnings but theres still a explicit null deref
>>> in a loop condition. CID 132144. What does it impact? No clue.
>> 
>>> And speaking of pns, there is still CID 106401 where 
>>> PNS_MEANDERED_LINE::MeanderSegment can memory leak.
>> 
>>> ___ Mailing list: 
>>> https://launchpad.net/~kicad-developers Post to : 
>>> kicad-developers@lists.launchpad.net Unsubscribe : 
>>> https://launchpad.net/~kicad-developers More help   : 
>>> https://help.launchpad.net/ListHelp
>> 
>> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJWPpN4AAoJEDRhermzHH18QWUP/37S/Pz38wbXfMzBpGsWztIJ
QlV9f7K/5t3oHOwFXmc7qomJH7iuJxp2Dq/1z8aYM64iXa5X3ce7K1ra1H7skqKV
sedJlHDk2ginjGxGDfQtJZ/YTbOgCz+1LeZT7v3TPhBMZjDh4QiNVxNIIqbL4quU
r/nF0dKy9TOQzLNavGtFaHdX3qstsIs8YvBN7nPV7lSMfk0emJo/H4iZ9eH5gg/Z
SzWd761PnHGyudSeaDp19g6K58PnV0ePn9jrsTZP0DOsLpnRZNV4F3j1NV0NnCUE
ugnI2UV/TOk6aBlOUXhZg0bb6Kv2aKYlxQ/bEc+uaberRnLqybdgPU7qESb3sORd
P/SX298vwqC8q1EeLzebnksoI9iHHvNSIXqWz0R3ETkPVITQYwDwqtrwuu089eXG
sDW78pjsQeMVsTPsoqOeDCeW7SmaiolSPafYUoNuTlpqGSY/cLW5Vq0T2TpYkQBt
pPpPQeE6N5SIgRrSv+gUm80gHMcisvwZkDipgb/mIRusjS6fMq7nm0Glnt6sa6Gb
PB/3VMQzzu2VipXAUHKATcjHJiRASFNyhUCqkCyJL9AJZ8GBjp69TPM+QPyYbedk
Drp58Tk8qui7PZ3zJMUzoqt7iSyZtclAeZUcss9nRah83x3Lq85s/Bs6+Fpwo2I0
hjAmLXnbG+mjGv2AYvHn
=hsnT
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] RC2

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

There's another bug I spent a while hunting for earlier this week, but
couldn't get too far with. Maybe someone else can pick it up?

Steps to reproduce:
* Open pad editor
* Select pad type: SMT
* Select copper layers: none
* Uncheck all technical layers

In the debug build this will display a warning but keep running; in
release it aborts or crashes.

Although *exiting* the pad editor should not be allowed if the pad has
no layers at all (or possibly pop up a dialog asking if the user wants
to delete it?), having no layers selected should be a legal
intermediate state during editing of a pad stack.

On 06/11/15 09:04, Mark Roszko wrote:
> One thing I didn't think was fixed yet was a null dereference 
> introduced with the clipper library upgrade. jp fixed the 
> uninitialized warnings but theres still a explicit null deref in a 
> loop condition. CID 132144. What does it impact? No clue.
> 
> And speaking of pns, there is still CID 106401 where 
> PNS_MEANDERED_LINE::MeanderSegment can memory leak.
> 
> ___ Mailing list:
> https://launchpad.net/~kicad-developers Post to :
> kicad-developers@lists.launchpad.net Unsubscribe :
> https://launchpad.net/~kicad-developers More help   :
> https://help.launchpad.net/ListHelp
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJWPOKkAAoJEDRhermzHH18NfgQAJKIoYj+Yb5P+j4JGBQuZjQK
QF2gXcsn3lCpjaCPTKhZvVtyjXpG+kqy1jYL+TIg5lU4fk1k3LAh/f5VdUE/nPZE
GIgrfT+4pv0GEKdEZ9c8IXjHHInHfxna9qowArVyD2DZWrhCdP749BRrYAGcgprF
4MmCHNAz1P/lfzKY3bbCnYCOpD+uWR+thMr/17FAixH5D9l16GKtYXoXE9CkGZUr
6Rjb3X6cWhNba/ACjF92XZytEI/XcXetX7iHUC9wIdOXgwyELzvZy7i2ptAbD7Ck
RUf4XkNfpM6TW86qmLywFMyt4qfb6BpNud1x9LwFXsMZUl8GIoIUith9FLQwGM3P
HWKJ66WgjE4FmpRTXhnG3ulunIjHY3q7z5U3Ch/IYJNof995KFQP4yLqu/BaYUdw
LnvrL1HJdZDcrvW9p4bbH+/Fijcma8NwXDI/bwCGy75DSiA1QiTVnGHmDXvvWKBk
12ry1Cgf0hZhWO3oS/Tti2lPka8K4vYStjiO7Tp9Odx2Pol0uGQj6B6JrefPeTYr
29R4Qw02hhtldKVqCvFGlyhf7O8ASdmzweGubmYV86z+VMRO302gZ9f0yWAUOCE+
h4XQ5mM2wzzwY4i87PdEV6wPteX717fgX7wUMznpGmmr+u8DZsp2rRJ6Y4OmmM5M
3AiiCjN1eEAUPBzgC3gh
=1C44
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] RC2

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm on Debian 7 amd64. A couple of other people in #kicad managed to
reproduce the issue as well and I think most were linux based too.

On 06/11/15 09:34, jp charras wrote:
> Le 06/11/2015 18:25, Andrew Zonenberg a écrit :
>> There's another bug I spent a while hunting for earlier this
>> week, but couldn't get too far with. Maybe someone else can pick
>> it up?
>> 
>> Steps to reproduce: * Open pad editor * Select pad type: SMT * 
>> Select copper layers: none * Uncheck all technical layers
>> 
>> In the debug build this will display a warning but keep running; 
>> in release it aborts or crashes.
> 
> On Windows, I just have a warning message in a message box in
> OpenGL canvas and no issue in legacy mode, but no crash.
> 
> What is your OS ?
> 
>> 
>> Although *exiting* the pad editor should not be allowed if the
>> pad has no layers at all (or possibly pop up a dialog asking if
>> the user wants to delete it?), having no layers selected should
>> be a legal intermediate state during editing of a pad stack.
>> 
>> On 06/11/15 09:04, Mark Roszko wrote:
>>> One thing I didn't think was fixed yet was a null dereference 
>>> introduced with the clipper library upgrade. jp fixed the 
>>> uninitialized warnings but theres still a explicit null deref
>>> in a loop condition. CID 132144. What does it impact? No clue.
>> 
>>> And speaking of pns, there is still CID 106401 where 
>>> PNS_MEANDERED_LINE::MeanderSegment can memory leak.
> 
> They are only warnings.
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJWPO8OAAoJEDRhermzHH188egQAIZXOHxqWcwUQNcmTHCxC+nM
cFwiV8bU/zArqKjyNCm65KBTaCHMyayTVO9i4mLLQpH26wiwmv/OOAzlugmPNpz3
F9p43Uj3g0aXwY4BHPsbEmL89DJ3u0Z9HbLAEUjawE0AOneOfUnn3f2hOlrBqx3j
XxVhkEgHJWKQKmrgfWUHEuI7w78Pj3J6S5C0UrkXJAktMtEw+mIE87Ox2an7Sysp
rjhov2xT1uzKPOiVMOl5M+aRQGgdU3WY44GtOvONXHsaZ+qnv2GRBhKHqoiTM4le
MraUpPetfNvL89cldmccMHcgok6B+IIU5pCVHud/6s1sUmJAX1WiQ6cR3vg7cWZc
hpg0KvEUA9a4VC/NBBW7X1CdexQcZQOYPzqU5NIqgM7xcpBWfxYc8t74cuMjxxKY
+tG0R070NNxAjMpmZ+T+H1eG40+20ZaZoUjK31SkNm95DJjVn1NJNk97HeJx4Mn7
jShFyECCiI55XGW6fc8F0eYT4Ah+NfY2qd3OQdMynYMKDouU4lZI/BgZ87v63Ftm
PaAu0Q+qy4WCC/k00pM9eLSXbB9q9jgjgIMtK/0xrZ7C2tH+/+SPz1I1xtL2WsY9
19wZSUtLOsfcEaEAfcji0KVXjZrhPZRcd9bYfjbnxdD7HCy3oOKrhoRKcTkCc1u/
6HPpnZ6STfIafLy4RveM
=Y9Xs
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Looking for complex board designs

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This is only 4 layers but pretty decently sized and has a big BGA on
it (personal project)

http://redmine.drawersteak.com/projects/achd-soc/repository/show/trunk/b
oards/cat5-tdr

This one is tiny but full of WLCSPs (open sourced research project
from work)
http://thanatos.virtual.drawersteak.com/unlisted/tacoshield.kicad_pcb

On 31/10/15 13:59, Mário Luzeiro wrote:
> Hello all,
> 
> Does anyone have some complex board designed in kicad to share?
> (complex == big, lots of tracks, holes, layers, etc?) I was
> thinking in CERN designs, but there is a huge list here I wasn't
> able to find nothing: www.ohwr.org/projects/
> 
> Any help? thank!
> 
> Mario ___ Mailing list:
> https://launchpad.net/~kicad-developers Post to :
> kicad-developers@lists.launchpad.net Unsubscribe :
> https://launchpad.net/~kicad-developers More help   :
> https://help.launchpad.net/ListHelp
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJWNT0pAAoJEDRhermzHH181bAP/A3kCkqUhvJ+xhSOyIrumt65
5IFToIqt9dHdyNTLEsmkCBnLnLxIptqwWJYXAJTta7Sjj3eDBA7unGQOsjnQYjeO
FzXZCGyUh4MauePldtuNKF1bYT3hxUd25USSceRGlC65hp1qDbb3n1vaCYD8T/X9
16WLoeVdym0QeBtIyoPrEHgmhNK4mYcVAWnFLq8SBzjSni0XULJdC8+EmTLwUoQf
ETovXRuIa4HxWm+3oOWRoxmvKS7X2wb1gPtDJkAWobtzRHhEUksytc1he8KfYZAl
QDuUzWY3YL2+GARjw/5rwzMnAs1efGOkfaYjE9ZCw2H5FuC/ipfndX2lKINyYzxX
nRsf7+BZ3R5I5903GUSRkLbyEOnidkKepJSVzOT75E+DrfES9gX+VKhs18Jtzci8
IKxvyiahOYn5xK8Zv9fhxuI+G1hqPWX9fv2bLqrri3kq8Sq19ZU+RNsoIpDMn0Ed
KgsFnufhUkI3O5exytSvuttpB1pLkPzdD72YEhBjYRoTV4OXs9G+FuwBGl3eerul
zCIyh8EnIOSnbcfCXD494MKcxqKLm+mqjauT0KQRxmNcTOyhCqBx08NN5PgIWciq
Viq2ITd+uoPTflVLDaPWANp1JodlxXlFBAGs4MqkcpuyFfpvAbBC7Bpwi+qkj4v6
hZwgUt+MbDRiHvPHeMMW
=gAOD
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] PATCH: GAL text tool captures cursor when it shouldn't

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I don't think you got them all. My event handling fix in the same
branch wasn't merged.

Submitted a new merge request covering that.

On 13/07/15 01:46, Maciej Sumi?ski wrote:
 Hi Andrew,
 
 Thank you very much for the patchset, it's really appreciated. I 
 have just merged all the changes (5928).
 
 Regards, Orson
 
 On 07/12/2015 01:12 AM, Andrew Zonenberg wrote:
 Hi guys,
 
 Here's a fix for two separate issues where the GAL text tool 
 captures the cursor under undesirable circumstances.
 
 BUG 1: Placing text in the GAL module editor will capture the 
 cursor and never release it.
 
 BUG 2: Activating the GAL text tool, in either the PCB or module 
 editor, will capture the cursor at all times that the tool is 
 active rather than only when text is being actively 
 moved/placed.
 
 Merge request is at: 
 https://code.launchpad.net/~azonenberg/kicad/advanced-feature-bugfixe
s/+


merge/264485


 
___ Mailing list:
 https://launchpad.net/~kicad-developers Post to : 
 kicad-developers@lists.launchpad.net Unsubscribe : 
 https://launchpad.net/~kicad-developers More help   : 
 https://help.launchpad.net/ListHelp
 
 
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJVo9JXAAoJEHHYD0Ve7x+sc+oP/ixg3S8csGiZYTDBCDGgNW4a
VL+KJIjPcaBOrCJ2menCwmO9aHRFhxp1slYcFARIgrPOcoRFAWR866PKqXVV82Us
PJe25FVZMKqYEighdMYuGBMNjrQOhS8hcB3b77EMDqJa4rPac4Ipw+NshNo5Y2iR
YyuaV8/CPoAY0Uekr2TP1Bm/HVV2BP5UZ2yH5VXerkvOhIwHySQEt3n/dL/w3ROj
kwHEvuYN/QemolMfZqn/WG6+pcPX788cy2EU7WoRsTclBV7OBBY8064tempOXydd
Fef6eNfq8Zj/57SzeC33/gzYLLtUFS58LnAwJMapIjdYQ+Gy8YNeZrinZr7k7vsB
QdNOPBWSp1xwpZaO2SJ2gIm+Um4TlqsB7+mlqdsCKt6Mv5f2PlVVXrD+xWLNnPeV
fuNOD97OgBs6bMV9GPDmGhYpKesIV5QGlTbJaa5IwX1AdIGeOt1M7j0lcNMag9/n
5G15UT9tHSiR0GAbvU5z51H1vrhRZwoc4wj1fBJkCC38RdCDQB2BsmMfeFlUslGo
jW23quzcH7RJn2kc7lvQzopDj4GnmILaqpPS5eA0hfXfYzoJAPWXNAsc4fILpsJC
MRDoFQyJnu6HnOBbANpG6lW7Xxk9PJezPiq2atB97wbJMHop+mZwp6U3vZ+++TC9
2nlGFK/DUsdAdDos95KC
=tvvI
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Changing layers while routing in GAL does not create vias

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In previous versions, hitting a layer hotkey (f5, f6, pgup, pgdn, etc)
while routing in GAL would create a via. As of the latest version,
this is no longer the case.

Was this intentional? If so, what was the rationale? If not, this is a
major regression since it makes routing 2 layer boards extremely
annoying.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJVoszVAAoJEHHYD0Ve7x+sHQ8QAI3+o2isa40DECZd4ejtewr6
ghLut1WoYQkC/lTqf8xD4RtHc2gpOg5y4iQAqDoLRTel0msD3x2m83gxccrtRTN/
6BupaZDQM7qDN0QNWzQOZhhsQbzFfRgWFx4U6QaiW/af9N4BwifIAUwJggvGkGbd
Dn8nhOc0Xh6KTXb4+moQjihb9Su4H0cccIKCiupttzzspg3Myry8Ay6OMGnjJYsU
ED519gxzYfL28q0hb7xk3+p98ugE83peEPd2TMTxnbQXsQLljGw14XRaL/SGbL7J
AvvPexo/VC5mOb+4sdbMk04Xa6OP3BpKv/nnDge70rHbhmjGny4s5Yzis7BPVNUc
xE1S8DosKFTh7VtarSCwMBQqEPzgs04XIbaYqK+hP8cOJJbLcKxwX4egoPm3JRA0
F8yP9nrXVG2GrL2DVZQkMg0vj760nsJS+Ci1LxMxRUhbCGQjds3LMSch92sLpUyQ
xg4ZCI+pA3UMKKia79fL8rZm4R+8M/k+nbyzQviyBt81bmlw5jYM4FcLg0DnHVa+
6Or+Z3FYCD9AiJHKZxqE3htd/uLHx62MGPjvxjeysyBNqfG14tinANPKZc/hajth
OjL5U3eYHbkC90iprNhBebzn55CClgfENFNhw/3EQl2pCLfsV/uOAAO+VtvZHddN
ZgT+/olS/Rr1HFaIZrjD
=xh0a
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] A question about the crosshair behaivour

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I pushed a patch to advanced-feature-bugfixes that hides the cursor
when the mouse is outside the window. This only applies to GAL and
does not change legacy.

JP, can you be more specific about what would break in legacy if I
were to do the same?

On 12/07/15 11:36, jp charras wrote:
 Le 12/07/2015 20:23, Wayne Stambaugh a écrit :
 
 On 7/12/2015 2:08 PM, Andrew Zonenberg wrote:
 I'll write up a patch to clean up the cursors (GAL only, not
 going to worry about legacy since that's so full of artifacts
 anyway) and push it to my advanced-feature-bugfixes branch in a
 few.
 
 It would be nice if you could fix both canvases.  There are not
 many artifacts when just drawing the crosshairs.  Artifacts in
 the legacy cursor are primarily caused by editing, placing, and
 moving items.
 
 
 In legacy mode, the graphic cursor is used by the cross probing
 between Eeschema and Pcbnew.
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJVorwoAAoJEHHYD0Ve7x+sXMUP/iciZeQLPXvMHFf4HLEoUkjv
EXzFAPqoxiJoS5HC5VaXmmrwd1h+WItYPixnQIqAuwcMP09+xKbxzwUuDnl+663I
FaX8AEtZWXyeQMSvfdbc08KKlRcDl/9v4/RZUmrSMJC7hhzRFanJodE8EXf46p2U
tqOIxe4Bgtw7gsQJzMVJBcmbXiU+AUsYc3EfclkqU4gmGBgeDL1nbR+y2Ueliz2n
FXJxktVwiBWHca+IVnlQ1PsyFUcHy23GBOtWopuaE+AwxEU11FAcJ7XhCXD2JvGh
J+a/UpQioObgYTeHoTKWg6brST94kNcjtGNAgpbxuE3+QLAIZxt/CsIU6Jqn/4G8
vC4SuUTMdARGIIZRcKbGPtIRnmZUxL8uf68wFEvLoo4ofcfz0mriZV6Laf1xN2cd
oHLV4Ls4UtnfmZfzw8t0wvmS1ZXIEKbJHJjTvQC1Mx9uWcckY6Z/3oYBRafnOidq
Wd1XGUDFmC2hSj+K0lmVeaNWp69HRS/XN+IyN/hjYLejiAahHRb2PjaqcFFOxg5V
tX5NfGabfA06rpcXisbWU4I7SvXsMRqbXgdG8fdSTtIuJ5ShVymcahG+12yZoxVc
5ouhv9RqFsXVU1Myf0RNnGWZBk6wbdlibL3EFhsq9LEieq93GEwxiBlAcocUIo8g
e7XxPsx9DySnZeWkn5eW
=1Itj
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] A question about the crosshair behaivour

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I found a regression in GAL caused by my last change so I reverted it
(advanced-feature-bugfixes r5932). This needs more thought.

In the meantime, though, the other bug fixes in the branch (related to
mouse grabs on the text tool) have been pretty well tested and should
be good to merge any time you want.

On 12/07/15 12:51, jp charras wrote:
 Le 12/07/2015 21:12, Andrew Zonenberg a écrit :
 I pushed a patch to advanced-feature-bugfixes that hides the 
 cursor when the mouse is outside the window. This only applies
 to GAL and does not change legacy.
 
 JP, can you be more specific about what would break in legacy if
 I were to do the same?
 
 
 
 When you are clicking on a component or a pin in schematic editor,
 the graphic cursor of the board editor ( in legacy mode) is moved
 to the footprint or the pad.
 
 When you are clicking on a footprint or a pad, the graphic cursor
 of the schematic editor ( in legacy mode) is moved to the component
 or the pin in schematic editor.
 
 if the graphic cursor is hidden, the cross probing shows nothing.
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJVosZcAAoJEHHYD0Ve7x+sNfUP+QFwea5poNjBINgKLhDb4nBE
9hRSd+aEK+7wRFE+jO7Mqf1CQW6JDugSAs4yciZKIkmNCA5eidr8B2si4eXisarv
NduuyS4xkWN7fNmzfyIUVZJAUjbYUgmV/QMtCrJeARkGgGSDgm89gXiq4ZS8gbjd
prRDdK7HD+OGdgclqtug430CREJurYk60BD6h6z4i7BJNh6wqgCFiYD4XgOybMEW
2jzRap1S5IznHPhhwwem6ZPnR50DmJoQZ5W11mI5zLMj4bmKqDYdnLWmJIGPr3lt
ZZ9r7L+XZPPIe++yABK2dEuokK/aZ3VTK+zNFutpwzCTHjEt54DwhYELSFEZWSZs
a+Nr+z/GnCJQ0UCt5/iNh7H2IDT9n08N9XZiYMLdxukvISpaKU6/6+28pmkYDCas
OJ3dz8Ed9bAUmaeFLsG2wrNWdwFCwGz3PZNgum6a5R9IbNKM8+azsJMHZJ6I/0KS
NX86nSnV33cNy9YyanChUB72vAu0RtDobupyrM98Ni2MB2R3gvn6KLqgBeCypjWf
K0T6FgJX+oQyPRG/xgGnTnWAg01wfVxRDp+Q8vwrwAKJ4GJm+yffIlYXcTXxWq/6
0/ixoxpjytXHHIlMytmIWf6IKwZuIbnh862+cs1uFaLW2jnurpqMcmdIdQ0jn3ok
SJcVaUHdfRSv9xEfuXPJ
=RiMt
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Changing layers while routing in GAL does not create vias

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Confirmed to be a bug in event handling.

Fixed in my bugfix branch at
https://code.launchpad.net/~azonenberg/kicad/advanced-feature-bugfixes/+
merge/264485

On 12/07/15 13:23, Andrew Zonenberg wrote:
 In previous versions, hitting a layer hotkey (f5, f6, pgup, pgdn,
 etc) while routing in GAL would create a via. As of the latest
 version, this is no longer the case.
 
 Was this intentional? If so, what was the rationale? If not, this
 is a major regression since it makes routing 2 layer boards
 extremely annoying.
 
 ___ Mailing list:
 https://launchpad.net/~kicad-developers Post to :
 kicad-developers@lists.launchpad.net Unsubscribe :
 https://launchpad.net/~kicad-developers More help   :
 https://help.launchpad.net/ListHelp
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJVo0dcAAoJEHHYD0Ve7x+ssMQQALuZTl5OP7yqiO71qu7t5GQ3
DQnvVfcgw7tHD/1NR9kz7McxluVGAtKCcSnrIajeTLnNBcfD+vYALi/pDDFjJkfW
X4gafzZadH7eZWqg/f0s1NnkkAwReRklWA2SOvUTK/LmLr4rlFDxDVOH/eWhgS3X
akMSPw+Eq4es9l4qyrOSj5TmCZ6TIiRl7W0HqgEANSuBHp7f28+GX/yzqpUM+cmE
lO4cc6LomkoPDhFAbSUOrPhQGxXXxOCYgGXjm3A1ASAuoHe0q5feOkyMwMmUpQWY
ebheDNR4dia1ZV2zLC4U05e30h/oWOSEhwhmlTMiO9tdQYTzYpXocSMSA9bGTPMG
8Oi6KZimPq63z3hGppPWheOGkjbPBdgSLE15pFDdBP90oega9BEBmjGq8LXQlGbj
5eL9BuEZt1LH/YievMNFX3CrgYcrx2rhq3DYbR3yVxVbx4pcHUqBU/RLIKMPVqSC
LsnFITqdcXoXzlh6OV73zAcA44GKgY23oyfPakFsLhR0hbIXdv3JYDX2pmDa87lp
I55VL7AsVx5h6/0wsCbqdIl/qwi/ctw9d2v7F2q3UChU48szVmW7aXFDnQUQlQeH
U/btd17WGkAAEHIcq4jTqcgSY+Sbti7+Jboyc2PQqMTs5TLTPipXzHilC/NLN+TJ
O0YaokkreTSrrIjGSqNU
=eE+R
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] A question about the crosshair behaivour

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'll write up a patch to clean up the cursors (GAL only, not going to
worry about legacy since that's so full of artifacts anyway) and push
it to my advanced-feature-bugfixes branch in a few.

On 12/07/15 10:42, Bernhard Stegmaier wrote:
 For my taste it should be cleared. If you leave some active area
 IMHO it doesn’t make sense to keep any old/inactive traces of a
 tool/cursor… In fact, I find it hard to identify the real active
 mouse position when multiple (old, but inactive) cursors are
 visible on the screen.
 
 When writing this mail I have a text cursor when moving around in
 the text window. The text cursor also doesn’t stay visible at the
 edge of the text window when leaving the text window...
 
 
 Regards, Bernhard
 
 On 12 Jul 2015, at 18:46, Nick Østergaard oe.n...@gmail.com
 wrote:
 
 Hello All
 
 When testing Andrew's patch from yesterday and the fact we
 finally got the crosshair ported to GAL, I have noticed that when
 the mouse pointer cursor exits the canvas the crosshair will
 freeze at the edge of the canvas.  I have not thought more deeply
 about this before, because it is usual to the legacy canvas to
 have drawing artifacts.
 
 But what I really is asking now is; should it be like that or
 should it clear from the canvas?
 
 Please note this is when any tool except the pointer tool is
 active. The same behaivour is seen in the legacy canvas except it
 does not hide the cross hair in the select tool.
 
 Andrew told me to mention that he offered to fix it if people
 think that a fix is required. He estimate it'd take him 5 mins to
 make a patch to hide the cursor in the leave handler. It will be
 like a 4-line patch to common/view/wx_view_controls.cpp in
 onEnter and onLeave.
 
 He is willing to patch it if the consensus is that a fix is
 required.
 
 About the inconsistency about the select tool having the cross
 hair or not, he said he likes to have it becauese he uses to
 check alignment of stuff. This should of course lead the mind to
 think of https://xkcd.com/1172/.
 
 Regards Nick Østergaard
 
 ___ Mailing list:
 https://launchpad.net/~kicad-developers Post to :
 kicad-developers@lists.launchpad.net Unsubscribe :
 https://launchpad.net/~kicad-developers More help   :
 https://help.launchpad.net/ListHelp
 
 
 ___ Mailing list:
 https://launchpad.net/~kicad-developers Post to :
 kicad-developers@lists.launchpad.net Unsubscribe :
 https://launchpad.net/~kicad-developers More help   :
 https://help.launchpad.net/ListHelp
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJVoq0pAAoJEHHYD0Ve7x+svcMQAIoXMQHXONc9yZblMz2hl1UY
WepkMEBvm2l7i1xfEqSEQIwTWZ0bvvmj+yh98NBCLl1p9rF/sMeZaifPAhOhOzVc
7Mb+9JMhlIeqYolvqekDB4P2rG4YDf5fNGjz+xxs9YGJ5GG/353HqJY+2IrDjnfX
C8rYwaREQY0cpFjqeau/5fOZHh+lS/Ov8+NyGloYCu5V6ou8nqrrMEa0m2fxN1pD
zIRD7BTaAcrib7Ci/yrNIa0wuWhB2LqSOymAFpMQXA48bWyR7cUn7Voj3zvumn3r
eGHQF8NOybCGVManpOw+zij8qGxB79sJ4klCt/AcVAeA2bqZO13AqjhKDvo0i71B
y9DcJNybDoYpxe0u72DJi5iysYNVBuZiVaLAYFmENmLDkCU+ZboeN1GFghfYmm6k
Rq+WGvDGev8rLYfZDeq4O87stXHguqdsrEqqSMguiNcBqaDofresHr3K2rmwErt8
a5wQrZB52PMGtMT01KziZ7K6qUF/MdkjSrdX0nksyn00ST05GaoOZzojEPWLw3m4
SHZM3wYVQ7SxsoK7nA8P/T1CUoZJM9C6AJI2PYzSTAxTb7U7KJvJ7tMk1WgWGbO+
bNkEigP11WI39DkbBJcuZfk7XPXPvL+M4zAhEou0ctx6yWXeCPwcz72wRgwnNvJp
xRLIPx6yUvs5uEn706Nh
=MRfn
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] PATCH: GAL text tool captures cursor when it shouldn't

[Andrew Zonenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi guys,

Here's a fix for two separate issues where the GAL text tool captures
the cursor under undesirable circumstances.

BUG 1: Placing text in the GAL module editor will capture the cursor
and never release it.

BUG 2: Activating the GAL text tool, in either the PCB or module
editor, will capture the cursor at all times that the tool is active
rather than only when text is being actively moved/placed.

Merge request is at:
https://code.launchpad.net/~azonenberg/kicad/advanced-feature-bugfixes/+
merge/264485
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJVoaLuAAoJEHHYD0Ve7x+s318P/RxSQwFOSEqfrjrRGO2zztVX
z+dGp0oXORmeLrWhRYsTDjWyO6B7ivnKzX+t9Zcepsf7aXTHmHvn/x7mboePEl7h
xwmI2tWYrTfcSKaz2kvk8suPne5OUXIgnpA7mt6rtXfevkKwJk8LNNOxtJ6LQ2EY
ebuOX/rEjiiWat06BsiPRAJeSSy/Cq//iuibcnpmtdEsip3qzusSFyQdXw4cIQxb
BNBEjPSA8gd9ZSMVGIMroZ8X3OVP9bJAtPjHj/lXaURenHDKKrFf66D3n6IBRUGH
13e4QS96XrFQTfso98F9yxHvbCfrUtU8LPcR9kTaZeYJ55Btftt1JVydcU9+ZiCN
kJdBAIpfq3+AybCCokpKeH10Op3wSs9Mzp5NpSAWCjuI+/yRzel2r+jOXU00ua8C
XQjgfbOoDLCTUF06CI41h5cFOdcHActq/3cqavmRf1/6VgD7edaIEy/oAwmiuCwA
h7qN6FmaFf89hNB+qvwJuMBxGvk/cJtRYgK/8i5kV2N0YUH5q91yj3uOJY8Kb7cQ
WGg8Gl/r9ntt/x5cEfSO7oUIo2UwYM1UF/fcbW6fM34OzFGHhvsd2YUSvKLG5Jma
3k68wUsM5ivhI2VFbT2wuwo1GUD71rOfVdCIluGgNLK4BJGrmVI/PoUknnpHiwsb
Pa7mq85CPu3pTRYxzmtN
=1mlZ
-END PGP SIGNATURE-

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] render a layer to a image

[Andrew Zonenberg]

Not that I know of. In the past I've used gerbv from geda, which has all 
kinds of nice features like antialiasing and alpha blending (but only 
works on exported gerbers).


On 05/06/2015 11:53 AM, Mário Luzeiro wrote:

Hello all,

do we have any function in kicad that we can use to render some layer (i.e: 
edge cuts, coppers, silks, etc..) to a image (ex: wxImage) ?

Regards,
Mario Luzeiro
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Diff Pairs Length tuning in the product branch

[Andrew Zonenberg]

So if I understand this correctly, net names must currently be FOO+ and 
FOO- for differential pair routing.


Can you add support for FOO_P and FOO_N naming? These names are legal 
identifiers in most hardware description languages and will allow PCB 
and HDL net names to be the same.


On 03/03/2015 08:44 AM, Tomasz Wlostowski wrote:

Dear all,

We've just merged the new features of the Interactive Router to the
product branch:
- Routing differential pairs (in pushshove mode too).
- Tuning trace length.
- Tuning differential pair length and skew.

There's a video tutorial and a demo available on YouTube [1].

The merge also includes some improvements to the selection/edit tools
that we've developed alongside the new router features:
- Snapping to the origin axes when moving (allowing to move an item
exactly vertically/horizontally wrt its former position)
- Editing footprint pad properties directly on PCB.
- Moving pads of a footprint directly on PCB.
- Opening the footprint editor for selected footprint on a PCB in GAL mode.
- Dragging footprints by origin, pad 1 or pad nearest the cursor.
- Guessing the best selection candidate instead of displaying the
disambiguation menu every time.

We did our best to make sure the branch compiles and runs correctly, and
we'll greatly appreciate your feedback - be that bugs, feature requests
or suggestions for improvements. Please keep in mind this is the first
public release of the Diff Pairs, so some fine tuning may be needed in
the future.

Many thanks to all developers, funders  users for your help and support!

Cheers,
Tom  Orson

[1] https://www.youtube.com/watch?v=chejn7dqpfQ

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Crash with zero size pads in module editor

[Andrew Zonenberg]

Good catch. I fixed the same bug but for zero-sized drills a while ago,
apparently the same check was missing for pad sizes.

On Wed, 2014-11-19 at 16:52 +1300, Blair Bonnett wrote:
 Currently, the module editor crashes if the pad size is set to zero
 (e.g., while backspacing the current value to replace it). Note that
 this also happens if the entry is cleared as that is also treated as
 zero. Basically, the previewer tries to set the drawing context scale
 to zero and the drawing library doesn't like this.
 
 
 Also, the editor accepts zero as a pad size for surface mount pads.
 
 
 The attached patch adds checks for the zero entry case and sets the
 scale to (what I think is) a sensible default -- it uses the drill
 size rather than the pad size, or if the drill size is also zero, it
 arbitrarily uses a size of 1mm. It also adds an error message for
 zero-size pads when checking if the dialog is valid before accepting
 it.
 
 
 This closes lp:1378917.
 
 
 Regards,
 Blair
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Detecting Colliding Zones Across Layers

[Andrew Zonenberg]

That bit me once too. Perhaps the best option is to force an automatic
zone re-fill before exporting gerbers?

On Mon, 2014-11-17 at 18:22 +, Ian Woloschin wrote:
 Hi folks,
 
 
 I had a question regarding a sort-of-but-not-really bug that's
 bitten me a couple of times now.  Most of my boards now are 4 layers,
 with the two inner layers being Power/Ground zones.  This generally
 works really well, but on at least two fairly complex boards, I've had
 the misfortune of not remembering to quadruple check that no zones are
 colliding with vias.  I believe this is usually caused by forgetting
 to redraw zones after moving a via, which is entirely my own fault,
 but I just did a quick check and I don't see any indication of
 potentially colliding zones, and my DRC passes without any issue :(.
 Can the DRC detect colliding Nets?  Is this something that could be
 exposed via Python?
 
 
 Unfortunately I cannot share any of these boards, but it's pretty easy
 to replicate this (4 layer board, punch a via through, fill Inner
 layers with zones, move via, run DRC).
 
 
 In any case, I wanted to ask about this before filing a bug report or
 feature request, because while it's not technically incorrect
 behavior, it's behavior that is not intuitive based off of all the
 other awesome things KiCad does for the board designer.
 
 
 -Ian
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Detecting Colliding Zones Across Layers

[Andrew Zonenberg]

I fixed the bug on my board the same way.

As of last time I checked, there is an automatic zone-fill before DRC
anyway. I've gotten in the habit of running DRC before taping out a
design since that both reruns zone fills and confirms that the fills are
good.

On Mon, 2014-11-17 at 18:47 +, Ian Woloschin wrote:
 That was my original thought, but I wasn't sure if that was too heavy
 handed since it could break existing designs?  Though of course,
 they'd be bad designs if they relied on this as a feature.  If the
 choice is to force a zone re-fill I'd request that it does a zone
 re-fill before DRC as well.
 
 
 Should this be filed as a bug?  I'm happy to do so, but I thought this
 could benefit from some discussion first.
 
 
 The good news, I just found my 3/64 bits from the last time I did
 this, and drilling out the via through the inner layers does indeed
 disconnect my power and ground nets, so this was definitely my
 problem.  Easy enough to fix, especially since this was only 5
 prototype boards, but I'd have been real mad at myself if this was a
 large run!
 
 
 -Ian
 
 On Mon Nov 17 2014 at 1:40:44 PM Andrew Zonenberg
 azonenb...@drawersteak.com wrote:
 That bit me once too. Perhaps the best option is to force an
 automatic
 zone re-fill before exporting gerbers?
 
 On Mon, 2014-11-17 at 18:22 +, Ian Woloschin wrote:
  Hi folks,
 
 
  I had a question regarding a sort-of-but-not-really bug
 that's
  bitten me a couple of times now.  Most of my boards now are
 4 layers,
  with the two inner layers being Power/Ground zones.  This
 generally
  works really well, but on at least two fairly complex
 boards, I've had
  the misfortune of not remembering to quadruple check that no
 zones are
  colliding with vias.  I believe this is usually caused by
 forgetting
  to redraw zones after moving a via, which is entirely my own
 fault,
  but I just did a quick check and I don't see any indication
 of
  potentially colliding zones, and my DRC passes without any
 issue :(.
  Can the DRC detect colliding Nets?  Is this something that
 could be
  exposed via Python?
 
 
  Unfortunately I cannot share any of these boards, but it's
 pretty easy
  to replicate this (4 layer board, punch a via through, fill
 Inner
  layers with zones, move via, run DRC).
 
 
  In any case, I wanted to ask about this before filing a bug
 report or
  feature request, because while it's not technically
 incorrect
  behavior, it's behavior that is not intuitive based off of
 all the
  other awesome things KiCad does for the board designer.
 
 
  -Ian
  ___
  Mailing list: https://launchpad.net/~kicad-developers
  Post to : kicad-developers@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~kicad-developers
  More help   : https://help.launchpad.net/ListHelp
 
 --
 Andrew Zonenberg
 PhD student, security group
 Computer Science Department
 Rensselaer Polytechnic Institute
 http://colossus.cs.rpi.edu/~azonenberg/
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Detecting Colliding Zones Across Layers

[Andrew Zonenberg]

I would argue that zone filling is implicit - if it was less
resource-intensive we'd do it live (perhaps we should revisit that
decision? Can we optimize the code to be interactively fast on modern
hardware?). The user assumes that zones will back off around objects to
make room.

Therefore, NOT re-filling zones before plotting should be considered a
UX bug.

On Mon, 2014-11-17 at 18:54 +, Ian Woloschin wrote:
 Andrew,
 
 You are correct about DRC, I just double checked and it does re-fill
 zones.  I must have not been paying attention when I tried that
 earlier.
 
 
 I think I must have moved a via slightly, probably to align it in a
 grid with other nearby vias, and neglected to re-run DRC since I
 knew that change was minor and didn't require a DRC.  Maybe KiCad
 should just force a DRC before plotting?  That'd definitely be heavy
 handed, but it would help prevent stupid designers from doing stupid
 things.
 
 
 ...like myself.
 
 
 *sigh*
 
 On Mon Nov 17 2014 at 1:50:06 PM Andrew Zonenberg
 azonenb...@drawersteak.com wrote:
 I fixed the bug on my board the same way.
 
 As of last time I checked, there is an automatic zone-fill
 before DRC
 anyway. I've gotten in the habit of running DRC before taping
 out a
 design since that both reruns zone fills and confirms that the
 fills are
 good.
 
 On Mon, 2014-11-17 at 18:47 +, Ian Woloschin wrote:
  That was my original thought, but I wasn't sure if that was
 too heavy
  handed since it could break existing designs?  Though of
 course,
  they'd be bad designs if they relied on this as a feature.
 If the
  choice is to force a zone re-fill I'd request that it does a
 zone
  re-fill before DRC as well.
 
 
  Should this be filed as a bug?  I'm happy to do so, but I
 thought this
  could benefit from some discussion first.
 
 
  The good news, I just found my 3/64 bits from the last time
 I did
  this, and drilling out the via through the inner layers does
 indeed
  disconnect my power and ground nets, so this was definitely
 my
  problem.  Easy enough to fix, especially since this was only
 5
  prototype boards, but I'd have been real mad at myself if
 this was a
  large run!
 
 
  -Ian
 
  On Mon Nov 17 2014 at 1:40:44 PM Andrew Zonenberg
  azonenb...@drawersteak.com wrote:
  That bit me once too. Perhaps the best option is to
 force an
  automatic
  zone re-fill before exporting gerbers?
 
  On Mon, 2014-11-17 at 18:22 +, Ian Woloschin
 wrote:
   Hi folks,
  
  
   I had a question regarding a
 sort-of-but-not-really bug
  that's
   bitten me a couple of times now.  Most of my
 boards now are
  4 layers,
   with the two inner layers being Power/Ground
 zones.  This
  generally
   works really well, but on at least two fairly
 complex
  boards, I've had
   the misfortune of not remembering to quadruple
 check that no
  zones are
   colliding with vias.  I believe this is usually
 caused by
  forgetting
   to redraw zones after moving a via, which is
 entirely my own
  fault,
   but I just did a quick check and I don't see any
 indication
  of
   potentially colliding zones, and my DRC passes
 without any
  issue :(.
   Can the DRC detect colliding Nets?  Is this
 something that
  could be
   exposed via Python?
  
  
   Unfortunately I cannot share any of these boards,
 but it's
  pretty easy
   to replicate this (4 layer board, punch a via
 through, fill
  Inner
   layers with zones, move via, run DRC).
  
  
   In any case, I wanted to ask about this before
 filing a bug
  report or
   feature request, because while it's not
 technically
  incorrect
   behavior, it's behavior that is not intuitive
 based off of
  all the
   other awesome things KiCad does for the board
 designer.
  
  
   -Ian

Re: [Kicad-developers] problems running kicad-install.sh

[Andrew Zonenberg]

Unfortunately I don't have time to devote to migration either. I do vote
in favor of a switch to git though.

On Wed, 2014-10-29 at 13:05 +1100, Cirilo Bernardo wrote:
 
 
 On Wed, Oct 29, 2014 at 7:51 AM, Marco Ciampa ciam...@libero.it
 wrote:
 On Sun, Oct 26, 2014 at 10:59:20PM -0700, Jake wrote:
 [...]
  So i deleted the folder entirely with rm -rf
 ~/kicad_sources/kicad-lib.bzr/
 
  and when i ran the script again, now it seems to be working.
 
  i don't know anything about how bzr works, i am just
 competent with
  git, so hopefully some bash scripting and bzr experts can
 think of a
  way to restructure the install script to more consistently
 deal with
  incomplete installations.  I think that a less intrepid user
 than me
  (imagine!) would either have to delete all of
 ~/kicad_sources and
  start over, or give up entirely.
 
  please let me know if i should post this problem in the
 bugtracker
  or something else to make it easier to deal with, or if i
 have done
  it right.
 
 Bazaar is virtually dead. Its userbase decrease day by day.
 There are some bugs in it that presumably will never be fixed.
 
 For example, and this seems to be this case, if you stop a
 bzr up
 command abruptly, chances are that it will not be able to
 recover by
 himself, and you have to delete all and restart downloading
 afresh.
 
 I keep on thinking that a git migration of all kicad project
 repos should
 be considered for sometime in the (near?) future...
 
 bye
 
 --
 
 
 Marco Ciampa
 
 I know a joke about UDP, but you might not get it.
 
 
 
 I have no problem with using git, but we would need some volunteers
 with experience to perform the migration, test, and synchronize with
 bzr until the devs agree that the migration is a success and are ready
 to switch. This is no small job since the version history must be
 preserved and the bugtracker must also be migrated (preferably with no
 loss of information).
 
 
 - Cirilo
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Updates to authors.txt

[Andrew Zonenberg]

Hi all,

While browsing recent commits I saw some updates to authors.txt which
prompted me to take a look at the file and noticed two minor issues.

1) maintener (line 15) should be spelled maintainer
2) Neither Cirillo Bernardo nor myself are listed as contributors.

Thanks :)

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Rename instances of module to footprint for consistency

[Andrew Zonenberg]

Second the vote for consistency, no matter which way it goes.

Personally, I have a slight preference for footprint over module as
well.

On Wed, 2014-10-08 at 18:56 +1100, Mitch Davis wrote:
 On Wed, Oct 8, 2014 at 5:47 PM, Mark Roszko mark.ros...@gmail.com wrote:
  Hehe, well, I guess everything can be renamed in the opposite
  direction. But consistency is needed.
 
 YES PLEASE!  A number of people I've spoken to were really confused by
 this inconsistency.
 
 I use footprint myself.  Though footprint seems to imply what a PCB
 must have in order to accommodate a part, eg, pads, silk.  Are the 3d
 models part of this?  If they are, then footprint might not be the
 best term.
 
 Mitch.
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Build changes.

[Andrew Zonenberg]

Debian stable ships CMake 2.8.9. Will test next time I update my
checkout and report on my results.

On Fri, 2014-09-26 at 21:12 -0400, Wayne Stambaugh wrote:
 On 9/26/2014 8:43 PM, Blair Bonnett wrote:
  On 27 September 2014 12:36, Wayne Stambaugh stambau...@verizon.net
  mailto:stambau...@verizon.net wrote:
  
  I may have pulled trigger on this change too fast.  If I remove
  
  ${CMAKE_CURRENT_LIST_DIR} using CMake 2.8.12.2 on windows, I get the
  
  same error you get with it.  What version of CMake are you using?  If
  
  it's 3 or greater, I may have to copy FindPackageMessage.cmake and
  CMakeParseArguments.cmake into the CMakeModules folder as well.
  
  CMake 3.0.2.
  
  Incidentally, revision 5150 still doesn't build on my machine -- you
  need to remove the .cmake extension on the includes. But it might be
  best to copy the new versions of those files into CMakeModules and
  restore the ${CMAKE_CURRENT_LIST_DIR}/. I can confirm doing this works
  for me so if it works with older versions of CMake thats probably the
  way to go.
  
  Blair
 
 I copied the other two cmake files from 3.0.2 and it now works on
 windows with cmake 2.8.12 and linux with cmake 3.0.2.  I had to leave
 ${CMAKE_CURRENT_LIST_DIR}/ off the include statements to make it work
 correctly on cmake 2.8.12.  Sorry about the build issues.  I appears
 that there were some significant changes between CMake 2 and 3 that I
 was unaware of.
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Stackups and via design rules

[Andrew Zonenberg]

After a discussion with Nick Oestergard on IRC, I've come to the
conclusion that we really need to sit back and think about how design
rules for vias and stackups are handled.

As of right now, we have three kinds of vias:
1) Through-board via. These penetrate the entire board and can connect
any layers in between.
2) Microvia. These can only go from an outer layer to the adjacent
internal layer.
3) Blind/buried via. These go from any layer to any other layer, and can
connect anything in between.

We currently have two sets of design rules:
1) Drilled vias. There is a global minimum, netclass default size, and a
list of custom sizes. This applies to both through and blind/buried
vias.
2) Microvias. There is a global minimum, netclass default size, but no
support for custom sizes.

Unfortunately, this doesn't accurately reflect the realities of PCB
manufacture. Mechanical drills can be done through the entire stack at
any point during manufacture (including before all layers have been
laminated), and laser drills can be done from any layer to the next one
down (including before all layers have been laminated). Furthermore,
minimum diameters of drills are typically limited by aspect ratio
concerns. In other words, the less depth a drill has to penetrate, the
smaller the hole can be.

To illustrate my point, I've attached a cross section of a typical
6-layer HDI stackup (similar, but not identical, to one that I used on a
project for work recently). There are quite a few different kinds of
vias:

1) Buried mechanical drills from layer 3 to 4, through the board core
before any prepregs are applied. These can be slightly smaller than
through-board mechanical drills since the stack is thinner.
2) Buried laser drills from layer 2 to 3, the first level of prepreg,
before the outer layer is laminated. These can be very tiny since
they're only penetrating one layer.
3) Blind laser drills from layer 1 to 2, the second level of prepreg,
after the stack is fully laminated. These can be just as small as the
buried laser drills.
4) Mechanical drills through the entire board after the stack is fully
laminated. These are the largest since they have to penetrate the entire
stack.
5) Laser drills on the back side (4-5 or 5-6) are not allowed at all
since this requires an extra process step, increases cost, and I only
had fine-pitch BGAs on the front side of the board.

Kicad's current model cannot handle this case well. I could use
microvias from 1-2, but the 2-3 vias need to be blind/buried, which
uses the global through-board drill design rule. This means that I need
to set the global drill minimum to something tiny like 6 mils, which
would implicitly allow a 6 mil through-board mechanical drill (something
few fabs can manufacture at all, and certainly not for a reasonable
price). I also would need to enable blind/buried vias globally, which
would allow me to do a 4-5 or 5-6 laser via accidentally and not catch
it until I exported CAM files for manufacture.

I think what we really need to do is define a more complete stackup
editor that specifies layer thicknesses (for future impedance
control/current capacity calculations etc), dielectric constants, and
allows a list of layer pairs and via sizes to be defined. Does anyone
have input into how this should work? I'm pretty busy but would like to
at least get a non-functional mockup of the UI prototyped soon.

For extra fun in the longer term, integrate with the PCB calculator so
you can design design rules for target impedances. For example:

Layer  | Width | Spacing | Type   | Z0 target | Z0 actual |
F_Cu   | 0.15  | | Single | 50.00 | 48.95 |
F_Cu   | 0.25  | 0.125   | Diff   | 100.00| 101.32|
In1_Cu | 0.125 | | Single | 50.00 | 51.24 |

Then just select 50 ohm single from the track width dropdown and the
correct size for the current layer will be used automatically.

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Fix signed/unsigned warning in pcbnew/tools/drawing_tool.cpp:1022 [PATCH]

[Andrew Zonenberg]

Just updated to latest bzr and saw a warning when compiling:

/nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad/pcbnew/tools/drawing_tool.cpp:
 In member function ‘bool DRAWING_TOOL::drawSegment(int, DRAWSEGMENT*, 
boost::optionalVECTOR2double )’:
/nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad/pcbnew/tools/drawing_tool.cpp:1022:29:
 warning: comparison between signed and unsigned integer expressions 
[-Wsign-compare]

This is caused by DRAWING_TOOL::WIDTH_STEP being a const int, rather
than an unsigned int.

The attached patch explicitly casts it to unsigned before comparing
against lineWidth, which is unsigned. Another possible fix is to change
WIDTH_STEP to an unsigned int but I'm not sure where else it's used;
this patch is less intrusive and easier to confirm safety of.

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/
=== modified file 'pcbnew/tools/drawing_tool.cpp'
--- pcbnew/tools/drawing_tool.cpp	2014-09-01 11:48:51 +
+++ pcbnew/tools/drawing_tool.cpp	2014-09-21 16:03:08 +
@@ -1019,7 +1019,7 @@
 
 else if( evt-IsAction( COMMON_ACTIONS::decWidth ) )
 {
-if( lineWidth  WIDTH_STEP )
+if( lineWidth  (unsigned int)WIDTH_STEP )
 {
 lineWidth -= WIDTH_STEP;
 aGraphic-SetWidth( lineWidth );



signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Blind/buried via creation in PS router

[Andrew Zonenberg]

So I'm starting to work on adding full blind/buried/micro via support to
the PS router. My previous patches allow the router to correctly
shove/avoid special vias but not create them.

As of now I have hotkeys created in the tool framework for instantiating
blind/buried vias, along with adding a via-type field to PNS_LINE_PLACER
so it knows what type of via it should be creating.

There's still a few more things I need to fix before I'll have a patch.

1) Right now PNS_LINE_PLACER only stores the current layer, not the
layer pair. The existing code hard-codes (0, MAX_CU_LAYERS - 1) all over
the place, which needs to get fixed.

2) My current code doesn't check if blind/buried/microvias are allowed
by global settings. 

I should have a patch ready to submit in a day or so, depending on how
much time I spend cleaning up the lab and doing homework/thesis stuff
instead of kicad ;)

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Blind/buried via creation in PS router

[Andrew Zonenberg]

Question for Orson or anybody else who knows PNS internals well. 

PNS_ROUTING_SETTINGS::SetLayerPair() currently sets m_layerTop to always
be  m_layerBottom, which is the opposite of how it's done elsewhere in
pcbnew. Is this a bug or intended behavior?

On Sun, 2014-09-21 at 16:00 -0400, Andrew Zonenberg wrote:
 So I'm starting to work on adding full blind/buried/micro via support to
 the PS router. My previous patches allow the router to correctly
 shove/avoid special vias but not create them.
 
 As of now I have hotkeys created in the tool framework for instantiating
 blind/buried vias, along with adding a via-type field to PNS_LINE_PLACER
 so it knows what type of via it should be creating.
 
 There's still a few more things I need to fix before I'll have a patch.
 
 1) Right now PNS_LINE_PLACER only stores the current layer, not the
 layer pair. The existing code hard-codes (0, MAX_CU_LAYERS - 1) all over
 the place, which needs to get fixed.
 
 2) My current code doesn't check if blind/buried/microvias are allowed
 by global settings. 
 
 I should have a patch ready to submit in a day or so, depending on how
 much time I spend cleaning up the lab and doing homework/thesis stuff
 instead of kicad ;)
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Blind/buried via creation in PS router [PATCH]

[Andrew Zonenberg]

Looks like the issue I mentioned previously is indeed a bug. The
attached patch fixes it and provides full support for
blind/buried/microvias in GAL.

On Sun, 2014-09-21 at 19:27 -0400, Andrew Zonenberg wrote:
 Question for Orson or anybody else who knows PNS internals well. 
 
 PNS_ROUTING_SETTINGS::SetLayerPair() currently sets m_layerTop to always
 be  m_layerBottom, which is the opposite of how it's done elsewhere in
 pcbnew. Is this a bug or intended behavior?
 
 On Sun, 2014-09-21 at 16:00 -0400, Andrew Zonenberg wrote:
  So I'm starting to work on adding full blind/buried/micro via support to
  the PS router. My previous patches allow the router to correctly
  shove/avoid special vias but not create them.
  
  As of now I have hotkeys created in the tool framework for instantiating
  blind/buried vias, along with adding a via-type field to PNS_LINE_PLACER
  so it knows what type of via it should be creating.
  
  There's still a few more things I need to fix before I'll have a patch.
  
  1) Right now PNS_LINE_PLACER only stores the current layer, not the
  layer pair. The existing code hard-codes (0, MAX_CU_LAYERS - 1) all over
  the place, which needs to get fixed.
  
  2) My current code doesn't check if blind/buried/microvias are allowed
  by global settings. 
  
  I should have a patch ready to submit in a day or so, depending on how
  much time I spend cleaning up the lab and doing homework/thesis stuff
  instead of kicad ;)
  
  ___
  Mailing list: https://launchpad.net/~kicad-developers
  Post to : kicad-developers@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~kicad-developers
  More help   : https://help.launchpad.net/ListHelp
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/
=== modified file 'pcbnew/router/pns_line_placer.cpp'
--- pcbnew/router/pns_line_placer.cpp	2014-07-09 14:50:31 +
+++ pcbnew/router/pns_line_placer.cpp	2014-09-22 00:09:13 +
@@ -60,11 +60,12 @@
 }
 
 
-void PNS_LINE_PLACER::AddVia( bool aEnabled, int aDiameter, int aDrill )
+void PNS_LINE_PLACER::AddVia( bool aEnabled, int aDiameter, int aDrill, VIATYPE_T aType )
 {
 m_viaDiameter = aDiameter;
 m_viaDrill = aDrill;
 m_placingVia = aEnabled;
+m_viaType = aType;
 }
 
 
@@ -73,7 +74,7 @@
 assert( m_world != NULL );
 
 m_direction = m_initial_direction;
-TRACE( 1, world %p, intitial-direction %s layer %d\n,
+TRACE( 1, world %p, initial-direction %s layer %d\n,
 m_world % m_direction.Format().c_str() % aLayer );
 m_head.SetNet( aNet );
 m_tail.SetNet( aNet );
@@ -379,8 +380,8 @@
 if( !m_placingVia )
 return true;
 
-PNS_LAYERSET allLayers( 0, MAX_CU_LAYERS - 1 );
-PNS_VIA v( aHead.CPoint( -1 ), allLayers, m_viaDiameter, m_viaDrill, aHead.Net() );
+PNS_LAYERSET layers( Settings().GetLayerTop(), Settings().GetLayerBottom() );
+PNS_VIA v( aHead.CPoint( -1 ), layers, m_viaDiameter, m_viaDrill, aHead.Net(), m_viaType );
 
 VECTOR2I force;
 VECTOR2I lead = aHead.CPoint( -1 ) - aHead.CPoint( 0 );
@@ -439,8 +440,8 @@
 }
 else if( m_placingVia  viaOk )
 {
-PNS_LAYERSET allLayers( 0, MAX_CU_LAYERS - 1 );
-PNS_VIA v1( walkFull.CPoint( -1 ), allLayers, m_viaDiameter, m_viaDrill );
+PNS_LAYERSET layers( Settings().GetLayerTop(), Settings().GetLayerBottom() );
+PNS_VIA v1( walkFull.CPoint( -1 ), layers, m_viaDiameter, m_viaDrill, -1, m_viaType );
 walkFull.AppendVia( v1 );
 }
 
@@ -464,8 +465,8 @@
 
 if( m_placingVia )
 {
-PNS_LAYERSET allLayers( 0, MAX_CU_LAYERS - 1 );
-PNS_VIA v1( m_head.CPoint( -1 ), allLayers, m_viaDiameter, m_viaDrill );
+PNS_LAYERSET layers( Settings().GetLayerTop(), Settings().GetLayerBottom() );
+PNS_VIA v1( m_head.CPoint( -1 ), layers, m_viaDiameter, m_viaDrill, -1, m_viaType );
 m_head.AppendVia( v1 );
 }
 
@@ -507,9 +508,9 @@
 
 if( m_placingVia )
 {
-PNS_LAYERSET allLayers( 0, MAX_CU_LAYERS - 1 );
-PNS_VIA v1( l.CPoint( -1 ), allLayers, m_viaDiameter, m_viaDrill );
-PNS_VIA v2( l2.CPoint( -1 ), allLayers, m_viaDiameter, m_viaDrill );
+PNS_LAYERSET layers( Settings().GetLayerTop(), Settings().GetLayerBottom() );
+PNS_VIA v1( l.CPoint( -1 ), layers, m_viaDiameter, m_viaDrill, -1, m_viaType );
+PNS_VIA v2( l2.CPoint( -1 ), layers, m_viaDiameter, m_viaDrill, -1, m_viaType );
 
 l.AppendVia( v1 );
 l2.AppendVia( v2 );

=== modified file 'pcbnew/router/pns_line_placer.h'
--- pcbnew/router/pns_line_placer.h	2014-07-09

Re: [Kicad-developers] wxWidgets version.

[Andrew Zonenberg]

In addition, I strongly recommend putting a warning when someone tries
to build against wx 3.0.1 on Linux based on the regression I found a
while ago.

On Fri, 2014-09-05 at 17:01 -0400, Wayne Stambaugh wrote:
 I know we have informally discussed dropping wxWidgets 2.8 support due
 to it's known issues.  Not that wxWidgets 3 is not without issues but I
 believe it is time to kick 2.8 support to the curb.  This way we only
 have to support the issues in the 3 branch.  I also doubt that the
 wxWidgets folks will support any more 2.8 bug fix releases.  If no one
 has any strong objections, I will modify our FindwxWidgets.cmake file to
 support version testing and fail if the version of wxWidgets is less
 than 3.0.0.
 
 Wayne
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Strange segfaults/assertions

[Andrew Zonenberg]

What wxwidgets version are you using? There's a known regression in
3.0.1 that can cause crashes in exactly that situation (although the
assertion you're seeing doesn't make sense for this bug).

On Wed, 2014-09-03 at 10:38 +0200, Lorenzo Marcantonio wrote:
 It's two days that I'm tracking a segfault in the 'change module'
 feature and an assertion during netlist import when the 'replace module'
 and/or 'delete bad track' option is set. 
 
 Seems that something in core is not correctly updated... if I reload and
 do the exact same thing it works!
 
 This could give a clue:
 
 /home/lomarcan/cvswork/kicad-bzr/pcbnew/ratsnest_data.cpp:931: void
 RN_DATA::Remove(const BOARD_ITEM*): Assertion `net  (int)
 m_nets.size()' failed.
 
 Very frustrating, be careful when using pcbnew and save often :D
 

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Compilation error

[Andrew Zonenberg]

The specific issue at hand, for your reference, is
http://trac.wxwidgets.org/ticket/16423. I found this while debugging a
segfault while running the DRC but it could happen anywhere that the
busy cursor is used.

On Wed, 2014-09-03 at 17:01 +0200, Maciej Sumiński wrote:
 Hi Carl
 
 Recently there was a discussion about bugs in 3.0.1 (topic: Segfault
 when running DRC). It might be a better choice to switch to the
 bleeding edge.
 
 Regards,
 Orson
 
 On 09/03/2014 04:59 PM, Carl Poirier wrote:
  I will try that. Thanks.
  
  
  On Wed, Sep 3, 2014 at 9:51 AM, Wayne Stambaugh
  stambau...@verizon.net wrote:
  
  On 9/3/2014 9:49 AM, Carl Poirier wrote:
  Hi people,
  
  I am trying to compile KiCad from source on a fresh Xubuntu 
  installation. I started off by compiling and installing
  wxWidgets 3.0.1.Then, for KiCad, I get this error:
  
  [ 45%] Building CXX object
  common/CMakeFiles/gal.dir/draw_panel_gal.cpp.o In file included
  from 
  /home/thesmith/kicad/kicad/common/draw_panel_gal.cpp:38:0: 
  /home/thesmith/kicad/kicad/include/gal/opengl/opengl_gal.h:62:1:
  error: expected class-name before ‘{’ token { ^ 
  /home/thesmith/kicad/kicad/include/gal/opengl/opengl_gal.h:256:12:
 
  
 error: ‘wxGLContext’ does not name a type
  static wxGLContext* glContext;  /// OpenGL
  context of wxWidgets ^ make[2]: ***
  [common/CMakeFiles/gal.dir/draw_panel_gal.cpp.o] Error 1 
  make[1]: *** [common/CMakeFiles/gal.dir/all] Error 2 make: ***
  [all] Error 2
  
  Is anyone aware of a reason and/or solution?
  
  Carl
  
  
  Did you build wxWidgets with the --with-opengl flag?  If memory
  servers, this is not enabled by default.
  
  
  
  ___ Mailing list:
  https://launchpad.net/~kicad-developers Post to :
  kicad-developers@lists.launchpad.net Unsubscribe :
  https://launchpad.net/~kicad-developers More help   :
  https://help.launchpad.net/ListHelp
  
  
  
  
  ___ Mailing list:
  https://launchpad.net/~kicad-developers Post to :
  kicad-developers@lists.launchpad.net Unsubscribe :
  https://launchpad.net/~kicad-developers More help   :
  https://help.launchpad.net/ListHelp
  
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] version info does not get updated

[Andrew Zonenberg]

I've observed the same issue with my builds. The only workaround I've
found to date is to delete the build directory and do a full rebuild.

On Sun, 2014-08-31 at 20:56 +0200, Nick Østergaard wrote:
 Hi Yann
 
 Does 'bzr revno --tree' result in the same?
 
 2014-08-31 20:21 GMT+02:00 yann jautard brico...@free.fr:
  REVISION is set to TESTING, I use the script daily, it's the first time I
  notice something like that.
 
  the result of bzr log in my kicad source tree starts by :
 
  
  revno: 5106
  fixes bug: https://launchpad.net/bugs/1035151
  committer: Wayne Stambaugh stambau...@verizon.net
  branch nick: kicad
  timestamp: Fri 2014-08-29 16:23:40 -0400
 
 
  so it updated the source correctly.
 
  And considering the number of files that has be recompiled, it updated
  something in the bin files.
 
 
 
 
 
 
 
  Le 31/08/2014 19:38, Nick Østergaard a écrit :
 
  That just looks like it did not update.
 
  What is the REVISION variable set to in the sript? It should be
  $TESTING, where that is last:1.
 
  2014-08-31 18:12 GMT+02:00 yann jautard brico...@free.fr:
 
  Hi all,
 
  I don't know if this is important, but I just updated my kicad install
  this
  afternoon, and I noticed the kicad version information is not up to date
  :
 
 
  yann@yann-netbook:~/kicad_sources$ ./kicad-install.sh --install-or-update
  (...)
  step 3) checking out the source code from launchpad repo...
  Tree is up to date at revision *5106* of branch
  http://bazaar.launchpad.net/~kicad-product-committers/kicad/product
local source working tree updated.
  (...)
  All KiCad --install-or-update steps completed, you are up to date.
 
 
 
  and then, the kicad windows says this :
 
 
  Application: kicad
  Version: (*2014-08-26 BZR 5099*)-product Release build
  wxWidgets: Version 3.0.0 (debug,wchar_t,compiler with C++ ABI 1002,GCC
  4.8.2,wx containers,compatible with 2.8)
  Platform: Linux 3.13.0-35-generic i686, 32 bit, Little endian, wxGTK
  Boost version: 1.54.0
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=OFF
KICAD_SCRIPTING_MODULES=OFF
KICAD_SCRIPTING_WXPYTHON=OFF
USE_FP_LIB_TABLE=HARD_CODED_ON
BUILD_GITHUB_PLUGIN=ON
 
  you can see the compilation date is wrong (we are the 14 08 31) and the
  version number is wrong.
 
 
 
 
  ___
  Mailing list: https://launchpad.net/~kicad-developers
  Post to : kicad-developers@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~kicad-developers
  More help   : https://help.launchpad.net/ListHelp
 
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] version info does not get updated

[Andrew Zonenberg]

Why does CMake not recompute this particular value during the
pre-compile configuration step? It runs checks for changed stuff every
time you make anyway and only caches certain things. Is it really that
hard to not cache this particular value?

On Sun, 2014-08-31 at 22:24 +0100, Brian Sidebotham wrote:
 The version is essentially created during the CMake configure step -
 when CMake generates its cache of variables. You need to re-create
 this cache to update the value:
 
 make rebuild_cache
 
 That should update to the same as bzr revno.
 
 Best Regards, Brian.
 
 
 On 31 August 2014 21:47, Andrew Zonenberg azonenb...@drawersteak.com wrote:
  I've observed the same issue with my builds. The only workaround I've
  found to date is to delete the build directory and do a full rebuild.
 
  On Sun, 2014-08-31 at 20:56 +0200, Nick Østergaard wrote:
  Hi Yann
 
  Does 'bzr revno --tree' result in the same?
 
  2014-08-31 20:21 GMT+02:00 yann jautard brico...@free.fr:
   REVISION is set to TESTING, I use the script daily, it's the first time I
   notice something like that.
  
   the result of bzr log in my kicad source tree starts by :
  
   
   revno: 5106
   fixes bug: https://launchpad.net/bugs/1035151
   committer: Wayne Stambaugh stambau...@verizon.net
   branch nick: kicad
   timestamp: Fri 2014-08-29 16:23:40 -0400
  
  
   so it updated the source correctly.
  
   And considering the number of files that has be recompiled, it updated
   something in the bin files.
  
  
  
  
  
  
  
   Le 31/08/2014 19:38, Nick Østergaard a écrit :
  
   That just looks like it did not update.
  
   What is the REVISION variable set to in the sript? It should be
   $TESTING, where that is last:1.
  
   2014-08-31 18:12 GMT+02:00 yann jautard brico...@free.fr:
  
   Hi all,
  
   I don't know if this is important, but I just updated my kicad install
   this
   afternoon, and I noticed the kicad version information is not up to 
   date
   :
  
  
   yann@yann-netbook:~/kicad_sources$ ./kicad-install.sh 
   --install-or-update
   (...)
   step 3) checking out the source code from launchpad repo...
   Tree is up to date at revision *5106* of branch
   http://bazaar.launchpad.net/~kicad-product-committers/kicad/product
 local source working tree updated.
   (...)
   All KiCad --install-or-update steps completed, you are up to date.
  
  
  
   and then, the kicad windows says this :
  
  
   Application: kicad
   Version: (*2014-08-26 BZR 5099*)-product Release build
   wxWidgets: Version 3.0.0 (debug,wchar_t,compiler with C++ ABI 1002,GCC
   4.8.2,wx containers,compatible with 2.8)
   Platform: Linux 3.13.0-35-generic i686, 32 bit, Little endian, wxGTK
   Boost version: 1.54.0
 USE_WX_GRAPHICS_CONTEXT=OFF
 USE_WX_OVERLAY=OFF
 KICAD_SCRIPTING=OFF
 KICAD_SCRIPTING_MODULES=OFF
 KICAD_SCRIPTING_WXPYTHON=OFF
 USE_FP_LIB_TABLE=HARD_CODED_ON
 BUILD_GITHUB_PLUGIN=ON
  
   you can see the compilation date is wrong (we are the 14 08 31) and the
   version number is wrong.
  
  
  
  
   ___
   Mailing list: https://launchpad.net/~kicad-developers
   Post to : kicad-developers@lists.launchpad.net
   Unsubscribe : https://launchpad.net/~kicad-developers
   More help   : https://help.launchpad.net/ListHelp
  
  
 
  ___
  Mailing list: https://launchpad.net/~kicad-developers
  Post to : kicad-developers@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~kicad-developers
  More help   : https://help.launchpad.net/ListHelp
 
  --
  Andrew Zonenberg
  PhD student, security group
  Computer Science Department
  Rensselaer Polytechnic Institute
  http://colossus.cs.rpi.edu/~azonenberg/
 
  ___
  Mailing list: https://launchpad.net/~kicad-developers
  Post to : kicad-developers@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~kicad-developers
  More help   : https://help.launchpad.net/ListHelp
 

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] version info does not get updated

[Andrew Zonenberg]

What I did in my previous build systems is to regenerate the file in a
temporary directory then check if the files had the same hash. If they
didn't I'd update the file.

This way, if you don't change the file's contents it doesn't get touched
and nothign else gets rebuilt.

On Sun, 2014-08-31 at 22:50 +0100, Brian Sidebotham wrote:
 On 31 August 2014 22:27, Andrew Zonenberg azonenb...@drawersteak.com wrote:
  Why does CMake not recompute this particular value during the
  pre-compile configuration step? It runs checks for changed stuff every
  time you make anyway and only caches certain things. Is it really that
  hard to not cache this particular value?
 
 Currently KiCad uses a configure file mechanism for the version.h file
 and it's not normal to regenerate these each time you make otherwise
 you end up re-compiling everything that uses the file and then
 re-linking everything that links to that target if the target's a
 library (which in this case it is).
 
 Therefore, when you bzr up - make rebuild_cache too in order to update
 the version number. Caching this value makes subsequent repetitive
 builds quicker. If you can suffer the time, just do a simple cheat:
 
 bk.sh
 #!/bin/bash
 make rebuild_cache
 make
 
 just use bk.sh instead of make...
 
 The following is from CMakeModules/version.h.cmake :
 
 /*
  * Define the current source code Subversion commit number.  The version
  * string defined below does not update automatically when building the
  * source with make.  Run make rebuild_cache to update version strings.
  */
 
 Best Regards,
 
 Brian.

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Default menu behavior fix.

[Andrew Zonenberg]

I'm on Debian 7 and was using 2.8 until a week or two ago, but switched
from the wx 2.8 binary package to a binary package recently to add
antialiasing support. After encountering the Linux 3.0.1 DRC crash, I
switched to a from-source build of 3.0.1+ SVN HEAD which has the issue
patched.

On Sun, 2014-08-24 at 15:52 -0400, Wayne Stambaugh wrote:
 On 8/24/2014 3:09 PM, Lorenzo Marcantonio wrote:
  On Sun, Aug 24, 2014 at 02:20:05PM -0400, Wayne Stambaugh wrote:
  code get screwed up.  If someone is still using wxWidgets 2.8, that
  testing would be very useful.  I tested on both Windows and Linux with
  wx 3.0.1 so I need a few more data points.
  
  AFAIK 2.8 isn't supported anymore since it has broken behaviour with
  some of the modular code; last week Dick wrote in some bug report about
  that IIRC (also the issue with quasimodals on linux)
  
 
 Your right, I remember the discussion now.  Too bad FindwxWidgets.cmake
 doesn't support limiting the version yet.  This way we could set it to
 3.0.1 or greater and be done with it.
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] New 3D Viewer options patch

[Andrew Zonenberg]

I am interested in working on the model cache system (I was the one who
originally proposed it) but won't have the time to work on it for
another week or so.

If anyone else is interested in getting started in the meantime please
coordinate with me so we don't duplicate efforts, if not I'll let you
guys know after I find a day or so to spend coming up with a solid
design.

On Mon, 2014-08-18 at 08:55 +, Mário Luzeiro wrote:
 Hi Jean-Pierre,
 
  Option Show 3D Footprint cannot be re-enabled, after it is disabled.
 As I already pointed here, I know that bug a very long time ago, but I dint 
 check for fix it now. I know that as user, my workaround is open the dialog 
 options and then set there the options correct.
 
 I didn't experience the show zone filling issue. Maybe this can be related 
 the way 3dViewer is setting the flags for update. (so it is not updating 
 the right flags?.. )
 I do believe that flags in future need to be reviewed by someone that is 
 working in the model cache system (is anyone working on this?)
 
 I agree with your tool tip suggestions.
 
 MarioLuzeiro
 
 From: jp charras [jp.char...@wanadoo.fr]
 Sent: 18 August 2014 10:42
 To: Mário Luzeiro; kicad-developers@lists.launchpad.net
 Subject: Re: [Kicad-developers] New 3D Viewer options patch
 
 Thanks, Mario.
 
 I tested it, and I have some remarks:
 Option Show 3D Footprint cannot be re-enabled, after it is disabled.
 Option Show Zone Filling cannot be disabled, after it is enabled.
 Option Remove Holes: the text is unclear.
 Should be something like Show Holes in Copper Zones
 Perhaps adding tool tips for some render options is helpful.
 
 
 The textures are now better.
 
 --
 Jean-Pierre CHARRAS
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] New 3D Viewer options patch

[Andrew Zonenberg]

Testing your patch against latest BZR kicad with latest wx from SVN on
Debian 7 amd64, GTX 460m with binary nvidia drivers. Board is 4 layers.

The board looks fine as seen from the top
(http://i.imgur.com/jv4Rfvg.png). Purple color is intentional, I was
trying to make it look like the OSHpark standard process.

On the bottom (http://i.imgur.com/HrKT2Em.png long shot,
http://i.imgur.com/9CMyI4X.png closeup) there are a few issues:

1) The vias under the QFN should go all the way through the board but
they appear plugged by copper in the underside view.

2) Bottom-side traces have very low contrast and are nearly invisible.
Top-side traces look fine.

I also have intermittent issues with what seems to be bad normals
calculated for some 3D models. Not sure if this is a bug in my
parallelization of normal calculation or in your original code but it's
worth investigating; I haven't had time to poke around with it too much.

On Sat, 2014-08-16 at 22:45 +, Mário Luzeiro wrote:
 Hi all,
 I implemented some new (old wishes) improvements to 3D-Viewer.
 Also, the overall render was improved.
 
 All changes related with 3D-Viewer:
 - Remove HightQualityMode (now is remove holes option)
 + Render smooth option
 + Render shadow option
 + Render textures option
 + Render remove holes option (old highQualityMode)
 + Render materials option
 + Color option background top
 + Color option background bottom
 + Color option copper
 + Color option solder mask
 + Auto silk screen color (white or black)
 Rearrange menu options
 New pcb and silk textures
 Fix an issue related with wx3 selection grid
 Fix an issue related with wx3/x3d parser VRML conversion
 
 Dear humans merger masters, would you mind to add this patch to main branch?!
 Sorry for any miss coding style (I had problems before with tabs vs spaces, 
 hope that is a bit more fixed now..)
 The patch is against the very last repository version so should be just 
 automerge it.
 
 Thank you!
 
 Mario Luzeiro
 ___ Mailing list: 
 https://launchpad.net/~kicad-developers Post to : 
 kicad-developers@lists.launchpad.net Unsubscribe : 
 https://launchpad.net/~kicad-developers More help : 
 https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] New 3D Viewer options patch

[Andrew Zonenberg]

Just to be clear, the bad normals started happening a while ago and this
most recent patch isn't at fault. I haven't had a chance to check older
versions and see if it was introduced by your new normal calculation
code, my parallelism patch, or something else.

On Sat, 2014-08-16 at 22:50 -0400, Andrew Zonenberg wrote:
 Testing your patch against latest BZR kicad with latest wx from SVN on
 Debian 7 amd64, GTX 460m with binary nvidia drivers. Board is 4 layers.
 
 The board looks fine as seen from the top
 (http://i.imgur.com/jv4Rfvg.png). Purple color is intentional, I was
 trying to make it look like the OSHpark standard process.
 
 On the bottom (http://i.imgur.com/HrKT2Em.png long shot,
 http://i.imgur.com/9CMyI4X.png closeup) there are a few issues:
 
 1) The vias under the QFN should go all the way through the board but
 they appear plugged by copper in the underside view.
 
 2) Bottom-side traces have very low contrast and are nearly invisible.
 Top-side traces look fine.
 
 I also have intermittent issues with what seems to be bad normals
 calculated for some 3D models. Not sure if this is a bug in my
 parallelization of normal calculation or in your original code but it's
 worth investigating; I haven't had time to poke around with it too much.
 
 On Sat, 2014-08-16 at 22:45 +, Mário Luzeiro wrote:
  Hi all,
  I implemented some new (old wishes) improvements to 3D-Viewer.
  Also, the overall render was improved.
  
  All changes related with 3D-Viewer:
  - Remove HightQualityMode (now is remove holes option)
  + Render smooth option
  + Render shadow option
  + Render textures option
  + Render remove holes option (old highQualityMode)
  + Render materials option
  + Color option background top
  + Color option background bottom
  + Color option copper
  + Color option solder mask
  + Auto silk screen color (white or black)
  Rearrange menu options
  New pcb and silk textures
  Fix an issue related with wx3 selection grid
  Fix an issue related with wx3/x3d parser VRML conversion
  
  Dear humans merger masters, would you mind to add this patch to main 
  branch?!
  Sorry for any miss coding style (I had problems before with tabs vs spaces, 
  hope that is a bit more fixed now..)
  The patch is against the very last repository version so should be just 
  automerge it.
  
  Thank you!
  
  Mario Luzeiro
  ___ Mailing list: 
  https://launchpad.net/~kicad-developers Post to : 
  kicad-developers@lists.launchpad.net Unsubscribe : 
  https://launchpad.net/~kicad-developers More help : 
  https://help.launchpad.net/ListHelp
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] New 3D Viewer options patch

[Andrew Zonenberg]

Possibly a bug in the order layers are drawn in? Alpha blending requires
specific draw orders to get good results. Top-down requires one order,
bottom-up another

On Sat, 2014-08-16 at 22:13 -0500, Jason Whiteman wrote:
 In my unreleased (due to incomplete status of the entirety of changes
 I was working) soldermask arbitrary color / silkscreen arbitrary color
 enhancement - I noticed that the soldermask bottom side obstructed
 traces so I had to adjust the transparency until both sides were
 balanced.  I didn't spend much time trying to determine what the root
 cause was - but did verify that layers were balanced and I added
 lighting to try to change the behavior with no reasonable results
 whereas transparency seemed to fix whatever the root cause was.
 
 
 I cannot get to the build server at the moment but would be happy to
 trade notes.
 
 
 Regards,
 Jason
 
 
 
 
 On Sat, Aug 16, 2014 at 9:50 PM, Andrew Zonenberg
 azonenb...@drawersteak.com wrote:
 Testing your patch against latest BZR kicad with latest wx
 from SVN on
 Debian 7 amd64, GTX 460m with binary nvidia drivers. Board is
 4 layers.
 
 The board looks fine as seen from the top
 (http://i.imgur.com/jv4Rfvg.png). Purple color is intentional,
 I was
 trying to make it look like the OSHpark standard process.
 
 On the bottom (http://i.imgur.com/HrKT2Em.png long shot,
 http://i.imgur.com/9CMyI4X.png closeup) there are a few
 issues:
 
 1) The vias under the QFN should go all the way through the
 board but
 they appear plugged by copper in the underside view.
 
 2) Bottom-side traces have very low contrast and are nearly
 invisible.
 Top-side traces look fine.
 
 I also have intermittent issues with what seems to be bad
 normals
 calculated for some 3D models. Not sure if this is a bug in my
 parallelization of normal calculation or in your original code
 but it's
 worth investigating; I haven't had time to poke around with it
 too much.
 
 On Sat, 2014-08-16 at 22:45 +, Mário Luzeiro wrote:
  Hi all,
  I implemented some new (old wishes) improvements to
 3D-Viewer.
  Also, the overall render was improved.
 
  All changes related with 3D-Viewer:
  - Remove HightQualityMode (now is remove holes option)
  + Render smooth option
  + Render shadow option
  + Render textures option
  + Render remove holes option (old highQualityMode)
  + Render materials option
  + Color option background top
  + Color option background bottom
  + Color option copper
  + Color option solder mask
  + Auto silk screen color (white or black)
  Rearrange menu options
  New pcb and silk textures
  Fix an issue related with wx3 selection grid
  Fix an issue related with wx3/x3d parser VRML conversion
 
  Dear humans merger masters, would you mind to add this patch
 to main branch?!
  Sorry for any miss coding style (I had problems before with
 tabs vs spaces, hope that is a bit more fixed now..)
  The patch is against the very last repository version so
 should be just automerge it.
 
  Thank you!
 
  Mario Luzeiro
  ___ Mailing
 list: https://launchpad.net/~kicad-developers Post to :
 kicad-developers@lists.launchpad.net Unsubscribe :
 https://launchpad.net/~kicad-developers More help :
 https://help.launchpad.net/ListHelp
 
 --
 Andrew Zonenberg
 PhD student, security group
 Computer Science Department
 Rensselaer Polytechnic Institute
 http://colossus.cs.rpi.edu/~azonenberg/
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
 
 
 

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] New 3D Viewer options patch

[Andrew Zonenberg]

Also it appears that the show 3D models option is broken. It defaults
to unchecked and whether I click or not the 3D models are still drawn.

On Sat, 2014-08-16 at 23:20 -0400, Andrew Zonenberg wrote:
 Possibly a bug in the order layers are drawn in? Alpha blending requires
 specific draw orders to get good results. Top-down requires one order,
 bottom-up another
 
 On Sat, 2014-08-16 at 22:13 -0500, Jason Whiteman wrote:
  In my unreleased (due to incomplete status of the entirety of changes
  I was working) soldermask arbitrary color / silkscreen arbitrary color
  enhancement - I noticed that the soldermask bottom side obstructed
  traces so I had to adjust the transparency until both sides were
  balanced.  I didn't spend much time trying to determine what the root
  cause was - but did verify that layers were balanced and I added
  lighting to try to change the behavior with no reasonable results
  whereas transparency seemed to fix whatever the root cause was.
  
  
  I cannot get to the build server at the moment but would be happy to
  trade notes.
  
  
  Regards,
  Jason
  
  
  
  
  On Sat, Aug 16, 2014 at 9:50 PM, Andrew Zonenberg
  azonenb...@drawersteak.com wrote:
  Testing your patch against latest BZR kicad with latest wx
  from SVN on
  Debian 7 amd64, GTX 460m with binary nvidia drivers. Board is
  4 layers.
  
  The board looks fine as seen from the top
  (http://i.imgur.com/jv4Rfvg.png). Purple color is intentional,
  I was
  trying to make it look like the OSHpark standard process.
  
  On the bottom (http://i.imgur.com/HrKT2Em.png long shot,
  http://i.imgur.com/9CMyI4X.png closeup) there are a few
  issues:
  
  1) The vias under the QFN should go all the way through the
  board but
  they appear plugged by copper in the underside view.
  
  2) Bottom-side traces have very low contrast and are nearly
  invisible.
  Top-side traces look fine.
  
  I also have intermittent issues with what seems to be bad
  normals
  calculated for some 3D models. Not sure if this is a bug in my
  parallelization of normal calculation or in your original code
  but it's
  worth investigating; I haven't had time to poke around with it
  too much.
  
  On Sat, 2014-08-16 at 22:45 +, Mário Luzeiro wrote:
   Hi all,
   I implemented some new (old wishes) improvements to
  3D-Viewer.
   Also, the overall render was improved.
  
   All changes related with 3D-Viewer:
   - Remove HightQualityMode (now is remove holes option)
   + Render smooth option
   + Render shadow option
   + Render textures option
   + Render remove holes option (old highQualityMode)
   + Render materials option
   + Color option background top
   + Color option background bottom
   + Color option copper
   + Color option solder mask
   + Auto silk screen color (white or black)
   Rearrange menu options
   New pcb and silk textures
   Fix an issue related with wx3 selection grid
   Fix an issue related with wx3/x3d parser VRML conversion
  
   Dear humans merger masters, would you mind to add this patch
  to main branch?!
   Sorry for any miss coding style (I had problems before with
  tabs vs spaces, hope that is a bit more fixed now..)
   The patch is against the very last repository version so
  should be just automerge it.
  
   Thank you!
  
   Mario Luzeiro
   ___ Mailing
  list: https://launchpad.net/~kicad-developers Post to :
  kicad-developers@lists.launchpad.net Unsubscribe :
  https://launchpad.net/~kicad-developers More help :
  https://help.launchpad.net/ListHelp
  
  --
  Andrew Zonenberg
  PhD student, security group
  Computer Science Department
  Rensselaer Polytechnic Institute
  http://colossus.cs.rpi.edu/~azonenberg/
  
  ___
  Mailing list: https://launchpad.net/~kicad-developers
  Post to : kicad-developers@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~kicad-developers
  More help   : https://help.launchpad.net/ListHelp
  
  
  
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science

Re: [Kicad-developers] New 3D Viewer options patch

[Andrew Zonenberg]

Managed to grab a screenshot of the bad normals:
http://i.imgur.com/Z9Wy34a.png

I can upload the board and 3D files if anybody wants. It seems to be
somewhat intermittent and only happen on some instances of the model and
not all the time.

On Sat, 2014-08-16 at 23:56 -0400, Andrew Zonenberg wrote:
 Also it appears that the show 3D models option is broken. It defaults
 to unchecked and whether I click or not the 3D models are still drawn.
 
 On Sat, 2014-08-16 at 23:20 -0400, Andrew Zonenberg wrote:
  Possibly a bug in the order layers are drawn in? Alpha blending requires
  specific draw orders to get good results. Top-down requires one order,
  bottom-up another
  
  On Sat, 2014-08-16 at 22:13 -0500, Jason Whiteman wrote:
   In my unreleased (due to incomplete status of the entirety of changes
   I was working) soldermask arbitrary color / silkscreen arbitrary color
   enhancement - I noticed that the soldermask bottom side obstructed
   traces so I had to adjust the transparency until both sides were
   balanced.  I didn't spend much time trying to determine what the root
   cause was - but did verify that layers were balanced and I added
   lighting to try to change the behavior with no reasonable results
   whereas transparency seemed to fix whatever the root cause was.
   
   
   I cannot get to the build server at the moment but would be happy to
   trade notes.
   
   
   Regards,
   Jason
   
   
   
   
   On Sat, Aug 16, 2014 at 9:50 PM, Andrew Zonenberg
   azonenb...@drawersteak.com wrote:
   Testing your patch against latest BZR kicad with latest wx
   from SVN on
   Debian 7 amd64, GTX 460m with binary nvidia drivers. Board is
   4 layers.
   
   The board looks fine as seen from the top
   (http://i.imgur.com/jv4Rfvg.png). Purple color is intentional,
   I was
   trying to make it look like the OSHpark standard process.
   
   On the bottom (http://i.imgur.com/HrKT2Em.png long shot,
   http://i.imgur.com/9CMyI4X.png closeup) there are a few
   issues:
   
   1) The vias under the QFN should go all the way through the
   board but
   they appear plugged by copper in the underside view.
   
   2) Bottom-side traces have very low contrast and are nearly
   invisible.
   Top-side traces look fine.
   
   I also have intermittent issues with what seems to be bad
   normals
   calculated for some 3D models. Not sure if this is a bug in my
   parallelization of normal calculation or in your original code
   but it's
   worth investigating; I haven't had time to poke around with it
   too much.
   
   On Sat, 2014-08-16 at 22:45 +, Mário Luzeiro wrote:
Hi all,
I implemented some new (old wishes) improvements to
   3D-Viewer.
Also, the overall render was improved.
   
All changes related with 3D-Viewer:
- Remove HightQualityMode (now is remove holes option)
+ Render smooth option
+ Render shadow option
+ Render textures option
+ Render remove holes option (old highQualityMode)
+ Render materials option
+ Color option background top
+ Color option background bottom
+ Color option copper
+ Color option solder mask
+ Auto silk screen color (white or black)
Rearrange menu options
New pcb and silk textures
Fix an issue related with wx3 selection grid
Fix an issue related with wx3/x3d parser VRML conversion
   
Dear humans merger masters, would you mind to add this patch
   to main branch?!
Sorry for any miss coding style (I had problems before with
   tabs vs spaces, hope that is a bit more fixed now..)
The patch is against the very last repository version so
   should be just automerge it.
   
Thank you!
   
Mario Luzeiro
___ Mailing
   list: https://launchpad.net/~kicad-developers Post to :
   kicad-developers@lists.launchpad.net Unsubscribe :
   https://launchpad.net/~kicad-developers More help :
   https://help.launchpad.net/ListHelp
   
   --
   Andrew Zonenberg
   PhD student, security group
   Computer Science Department
   Rensselaer Polytechnic Institute
   http://colossus.cs.rpi.edu/~azonenberg/
   
   ___
   Mailing list: https://launchpad.net/~kicad-developers
   Post to : kicad-developers@lists.launchpad.net
   Unsubscribe : https://launchpad.net/~kicad-developers

Re: [Kicad-developers] eeschema modular kicad work

[Andrew Zonenberg]

Understood. I actually just found an unofficial wx 3.0 package for
Debian stable, so I may end up switching over to that as well just for
crazy_imp's antialiasing fix.

On Fri, 2014-08-15 at 15:42 -0500, Dick Hollenbeck wrote:
 On 08/15/2014 02:05 PM, Andrew Zonenberg wrote:
  As a user of wx 2.8 on Debian I would like to ensure that, as a minimum,
  kicad continues to build on it until the next stable Debian version
  (presumably shipping wx 3.0) is released.
 
 You have that capability.  Probably I will uninstall wx2.8 tomorrow.
 
 There would be no reason to reject your patches on this topic, and you could 
 easily make a
 lot of people happy.
 
 But don't think I was bullshitting you when I said I would not spend another 
 minute on it.
 
 
 
  If new features can't be easily made to work on wx2.8 that's
  understandable as long as there's some graceful downgrade in
  functionality rather than a total build failure.
  
  My motive to support wx2.8 is now zilch.  The project can make its own 
  policy without my
  input on wx2.8 support, but I personally won't spend another minute on it.
 
  Here is my personal reasoning:  Ubuntu Trusty is free, my time is not.
 
 
  Dick
 
 
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Segfault when running DRC

[Andrew Zonenberg]

Happens every time I run DRC on this board. I don't want to change the
design for fear of not being able to reproduce it.

This is with the Codelite packages of wx3.0.1 and BZR 5073 kicad on
Debian 7.

Program received signal SIGSEGV, Segmentation fault.
IA__gdk_cursor_ref (cursor=cursor@entry=0xf2e66c318c48348)
at /tmp/buildd/gtk+2.0-2.24.10/gdk/gdkcursor.c:57
57  /tmp/buildd/gtk+2.0-2.24.10/gdk/gdkcursor.c: No such file or
directory.
(gdb) bt
#0  IA__gdk_cursor_ref (cursor=cursor@entry=0xf2e66c318c48348)
at /tmp/buildd/gtk+2.0-2.24.10/gdk/gdkcursor.c:57
#1  0x747cc691 in IA__gdk_window_set_cursor (window=0xbe3120,
cursor=0xf2e66c318c48348) at /tmp/buildd/gtk
+2.0-2.24.10/gdk/gdkwindow.c:8199
#2  0x76b8897f in wxWindow::GTKUpdateCursor (this=0x8273f0,
isBusyOrGlobalCursor=optimized out, isRealize=false)
at ../src/gtk/window.cpp:3761
#3  0x76b682a1 in UpdateCursors (win=win@entry=0x8273f0,
isBusyOrGlobalCursor=optimized out) at ../src/gtk/cursor.cpp:331
#4  0x76b68f43 in SetGlobalCursor (cursor=...)
at ../src/gtk/cursor.cpp:350
#5  0x76b6909d in wxEndBusyCursor ()
at ../src/gtk/cursor.cpp:376
#6  0x7fffe26f4cdc in DIALOG_DRC_CONTROL::OnStartdrcClick
(this=0x3645700, event=...)
at 
/nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad/pcbnew/dialogs/dialog_drc.cpp:172
#7  0x7627c2df in wxAppConsoleBase::CallEventHandler
(this=0x7b29e0, handler=0x3645700, functor=..., event=...)
at ../src/common/appbase.cpp:623


-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Segfault when running DRC

[Andrew Zonenberg]

Does not crash when run under Valgrind, instead gives this error:

==32723== Invalid read of size 8
==32723==at 0x5D00EC0: wxCursor::GetCursor() const (cursor.cpp:287)
==32723==by 0x5D20A8D: wxWindow::GTKUpdateCursor(bool, bool)
(window.cpp:3752)
==32723==by 0x5D002A0: UpdateCursors(wxWindow*, bool)
(cursor.cpp:331)
==32723==by 0x5D00F42: SetGlobalCursor(wxCursor const)
(cursor.cpp:350)
==32723==by 0x5D0109C: wxEndBusyCursor() (cursor.cpp:376)
==32723==by 0x1D3FCCDB:
DIALOG_DRC_CONTROL::OnStartdrcClick(wxCommandEvent)
(dialog_drc.cpp:172)
==32723==by 0x65F92DE:
wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor,
wxEvent) const (appbase.cpp:623)
==32723==by 0x6750FF1:
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const,
wxEvtHandler*, wxEvent) (event.cpp:1384)
==32723==by 0x67513A5:
wxEvtHandler::SearchDynamicEventTable(wxEvent) (event.cpp:1743)
==32723==by 0x6751445: wxEvtHandler::TryHereOnly(wxEvent)
(event.cpp:1577)
==32723==by 0x6751502: wxEvtHandler::ProcessEventLocally(wxEvent)
(event.h:3671)
==32723==by 0x6751564: wxEvtHandler::ProcessEvent(wxEvent)
(event.cpp:1487)
==32723==  Address 0x7feffdee8 is not stack'd, malloc'd or (recently)
free'd


On Fri, 2014-08-15 at 21:19 -0400, Andrew Zonenberg wrote:
 Happens every time I run DRC on this board. I don't want to change the
 design for fear of not being able to reproduce it.
 
 This is with the Codelite packages of wx3.0.1 and BZR 5073 kicad on
 Debian 7.
 
 Program received signal SIGSEGV, Segmentation fault.
 IA__gdk_cursor_ref (cursor=cursor@entry=0xf2e66c318c48348)
 at /tmp/buildd/gtk+2.0-2.24.10/gdk/gdkcursor.c:57
 57/tmp/buildd/gtk+2.0-2.24.10/gdk/gdkcursor.c: No such file or
 directory.
 (gdb) bt
 #0  IA__gdk_cursor_ref (cursor=cursor@entry=0xf2e66c318c48348)
 at /tmp/buildd/gtk+2.0-2.24.10/gdk/gdkcursor.c:57
 #1  0x747cc691 in IA__gdk_window_set_cursor (window=0xbe3120,
 cursor=0xf2e66c318c48348) at /tmp/buildd/gtk
 +2.0-2.24.10/gdk/gdkwindow.c:8199
 #2  0x76b8897f in wxWindow::GTKUpdateCursor (this=0x8273f0,
 isBusyOrGlobalCursor=optimized out, isRealize=false)
 at ../src/gtk/window.cpp:3761
 #3  0x76b682a1 in UpdateCursors (win=win@entry=0x8273f0,
 isBusyOrGlobalCursor=optimized out) at ../src/gtk/cursor.cpp:331
 #4  0x76b68f43 in SetGlobalCursor (cursor=...)
 at ../src/gtk/cursor.cpp:350
 #5  0x76b6909d in wxEndBusyCursor ()
 at ../src/gtk/cursor.cpp:376
 #6  0x7fffe26f4cdc in DIALOG_DRC_CONTROL::OnStartdrcClick
 (this=0x3645700, event=...)
 at 
 /nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad/pcbnew/dialogs/dialog_drc.cpp:172
 #7  0x7627c2df in wxAppConsoleBase::CallEventHandler
 (this=0x7b29e0, handler=0x3645700, functor=..., event=...)
 at ../src/common/appbase.cpp:623
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Segfault when running DRC

[Andrew Zonenberg]

I'm not using codelight itself, just their precompiled wx binaries, so I
can easily remove the binary package, it was just less work than
compiling from source.

I'm investigating further now, I fixed an unrelated missing variable
initializer in the process and will be submitting a patch to that
shortly.

On Fri, 2014-08-15 at 22:14 -0500, Dick Hollenbeck wrote:
 On 08/15/2014 08:32 PM, Andrew Zonenberg wrote:
  Does not crash when run under Valgrind, instead gives this error:
  
  ==32723== Invalid read of size 8
 
 ^ this error?  I've seen that before and never could figure it out, nor was 
 it ever the
 cause of any problem running valgrind.
 
 I would say build your own wxwidgets from the 3.0.1 source.  We're dealing 
 with an unknown
 problem, so one has to revert to probabilities at that point.
 
 I think the highest probability is that there is some incompatibility in your 
 software
 stack.  Building wx from source is an easy experiment.  You do not have to 
 remove the wx
 package if it makes codelight happy.
 
 Follow the instructions I gave in an earlier email today.  Then after 
 configuring the
 kicad build, I run
 
 (ccmake is in the package cmake-curses-gui I think.)
 
 $ ccmake .
 
 in the build directory.  Then I paste in
 
   /opt/wx3.0-stl/bin/wx-config
 
 into the field named:  wxWidgets_CONFIG_EXECUTABLE and reconfigure in ccmake.
 
 Likewise for the debug build, which over time will be very helpful for you.
 
 
 Obviously the first part of the /opt/wx3.0-stl/bin/wx-config string came from 
 the --prefix
 argument to the wx configure command.
 
 Don't forget to run $ sudo ldconfig
 after installing the home made wx libraries.
 
 
 
 
 
  ==32723==at 0x5D00EC0: wxCursor::GetCursor() const (cursor.cpp:287)
  ==32723==by 0x5D20A8D: wxWindow::GTKUpdateCursor(bool, bool)
  (window.cpp:3752)
  ==32723==by 0x5D002A0: UpdateCursors(wxWindow*, bool)
  (cursor.cpp:331)
  ==32723==by 0x5D00F42: SetGlobalCursor(wxCursor const)
  (cursor.cpp:350)
  ==32723==by 0x5D0109C: wxEndBusyCursor() (cursor.cpp:376)
  ==32723==by 0x1D3FCCDB:
  DIALOG_DRC_CONTROL::OnStartdrcClick(wxCommandEvent)
  (dialog_drc.cpp:172)
  ==32723==by 0x65F92DE:
  wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor,
  wxEvent) const (appbase.cpp:623)
  ==32723==by 0x6750FF1:
  wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const,
  wxEvtHandler*, wxEvent) (event.cpp:1384)
  ==32723==by 0x67513A5:
  wxEvtHandler::SearchDynamicEventTable(wxEvent) (event.cpp:1743)
  ==32723==by 0x6751445: wxEvtHandler::TryHereOnly(wxEvent)
  (event.cpp:1577)
  ==32723==by 0x6751502: wxEvtHandler::ProcessEventLocally(wxEvent)
  (event.h:3671)
  ==32723==by 0x6751564: wxEvtHandler::ProcessEvent(wxEvent)
  (event.cpp:1487)
  ==32723==  Address 0x7feffdee8 is not stack'd, malloc'd or (recently)
  free'd
  
  
  On Fri, 2014-08-15 at 21:19 -0400, Andrew Zonenberg wrote:
  Happens every time I run DRC on this board. I don't want to change the
  design for fear of not being able to reproduce it.
 
  This is with the Codelite packages of wx3.0.1 and BZR 5073 kicad on
  Debian 7.
 
  Program received signal SIGSEGV, Segmentation fault.
  IA__gdk_cursor_ref (cursor=cursor@entry=0xf2e66c318c48348)
  at /tmp/buildd/gtk+2.0-2.24.10/gdk/gdkcursor.c:57
  57 /tmp/buildd/gtk+2.0-2.24.10/gdk/gdkcursor.c: No such file or
  directory.
  (gdb) bt
  #0  IA__gdk_cursor_ref (cursor=cursor@entry=0xf2e66c318c48348)
  at /tmp/buildd/gtk+2.0-2.24.10/gdk/gdkcursor.c:57
  #1  0x747cc691 in IA__gdk_window_set_cursor (window=0xbe3120,
  cursor=0xf2e66c318c48348) at /tmp/buildd/gtk
  +2.0-2.24.10/gdk/gdkwindow.c:8199
  #2  0x76b8897f in wxWindow::GTKUpdateCursor (this=0x8273f0,
  isBusyOrGlobalCursor=optimized out, isRealize=false)
  at ../src/gtk/window.cpp:3761
  #3  0x76b682a1 in UpdateCursors (win=win@entry=0x8273f0,
  isBusyOrGlobalCursor=optimized out) at ../src/gtk/cursor.cpp:331
  #4  0x76b68f43 in SetGlobalCursor (cursor=...)
  at ../src/gtk/cursor.cpp:350
  #5  0x76b6909d in wxEndBusyCursor ()
  at ../src/gtk/cursor.cpp:376
  #6  0x7fffe26f4cdc in DIALOG_DRC_CONTROL::OnStartdrcClick
  (this=0x3645700, event=...)
  at 
  /nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad/pcbnew/dialogs/dialog_drc.cpp:172
  #7  0x7627c2df in wxAppConsoleBase::CallEventHandler
  (this=0x7b29e0, handler=0x3645700, functor=..., event=...)
  at ../src/common/appbase.cpp:623
 
 
  ___
  Mailing list: https://launchpad.net/~kicad-developers
  Post to : kicad-developers@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~kicad-developers
  More help   : https://help.launchpad.net/ListHelp
  
  
  
  ___
  Mailing list: https://launchpad.net/~kicad-developers
  Post to : kicad-developers@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~kicad

Re: [Kicad-developers] Segfault when running DRC

[Andrew Zonenberg]

The invalid read seems to be a bug in wxWidgets:

src/gtk/window.cpp:1543

static void SendSetCursorEvent(wxWindowGTK* win, int x, int y)
{
wxSetCursorEvent event(x, y);
wxWindowGTK* w = win;
do {
if (w-GTKProcessEvent(event))
{
gs_overrideCursor = event.GetCursor();
win-GTKUpdateCursor();
gs_needCursorResetMap[win] = true;
return;
}
// this is how wxMSW works...
if (w-GetCursor().IsOk())
break;
w = w-GetParent();
} while (w);
if (gs_needCursorResetMap[win])
win-GTKUpdateCursor();
}

event is a local variable on the stack and as a result, as soon as this
function returns gs_overrideCursor is invalid.

I'm not yet sure if this has any relationship whatsoever to the crash
I'm hunting.

On Fri, 2014-08-15 at 23:31 -0400, Andrew Zonenberg wrote:
 I'm not using codelight itself, just their precompiled wx binaries, so I
 can easily remove the binary package, it was just less work than
 compiling from source.
 
 I'm investigating further now, I fixed an unrelated missing variable
 initializer in the process and will be submitting a patch to that
 shortly.
 
 On Fri, 2014-08-15 at 22:14 -0500, Dick Hollenbeck wrote:
  On 08/15/2014 08:32 PM, Andrew Zonenberg wrote:
   Does not crash when run under Valgrind, instead gives this error:
   
   ==32723== Invalid read of size 8
  
  ^ this error?  I've seen that before and never could figure it out, nor was 
  it ever the
  cause of any problem running valgrind.
  
  I would say build your own wxwidgets from the 3.0.1 source.  We're dealing 
  with an unknown
  problem, so one has to revert to probabilities at that point.
  
  I think the highest probability is that there is some incompatibility in 
  your software
  stack.  Building wx from source is an easy experiment.  You do not have to 
  remove the wx
  package if it makes codelight happy.
  
  Follow the instructions I gave in an earlier email today.  Then after 
  configuring the
  kicad build, I run
  
  (ccmake is in the package cmake-curses-gui I think.)
  
  $ ccmake .
  
  in the build directory.  Then I paste in
  
/opt/wx3.0-stl/bin/wx-config
  
  into the field named:  wxWidgets_CONFIG_EXECUTABLE and reconfigure in 
  ccmake.
  
  Likewise for the debug build, which over time will be very helpful for you.
  
  
  Obviously the first part of the /opt/wx3.0-stl/bin/wx-config string came 
  from the --prefix
  argument to the wx configure command.
  
  Don't forget to run $ sudo ldconfig
  after installing the home made wx libraries.
  
  
  
  
  
   ==32723==at 0x5D00EC0: wxCursor::GetCursor() const (cursor.cpp:287)
   ==32723==by 0x5D20A8D: wxWindow::GTKUpdateCursor(bool, bool)
   (window.cpp:3752)
   ==32723==by 0x5D002A0: UpdateCursors(wxWindow*, bool)
   (cursor.cpp:331)
   ==32723==by 0x5D00F42: SetGlobalCursor(wxCursor const)
   (cursor.cpp:350)
   ==32723==by 0x5D0109C: wxEndBusyCursor() (cursor.cpp:376)
   ==32723==by 0x1D3FCCDB:
   DIALOG_DRC_CONTROL::OnStartdrcClick(wxCommandEvent)
   (dialog_drc.cpp:172)
   ==32723==by 0x65F92DE:
   wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor,
   wxEvent) const (appbase.cpp:623)
   ==32723==by 0x6750FF1:
   wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const,
   wxEvtHandler*, wxEvent) (event.cpp:1384)
   ==32723==by 0x67513A5:
   wxEvtHandler::SearchDynamicEventTable(wxEvent) (event.cpp:1743)
   ==32723==by 0x6751445: wxEvtHandler::TryHereOnly(wxEvent)
   (event.cpp:1577)
   ==32723==by 0x6751502: wxEvtHandler::ProcessEventLocally(wxEvent)
   (event.h:3671)
   ==32723==by 0x6751564: wxEvtHandler::ProcessEvent(wxEvent)
   (event.cpp:1487)
   ==32723==  Address 0x7feffdee8 is not stack'd, malloc'd or (recently)
   free'd
   
   
   On Fri, 2014-08-15 at 21:19 -0400, Andrew Zonenberg wrote:
   Happens every time I run DRC on this board. I don't want to change the
   design for fear of not being able to reproduce it.
  
   This is with the Codelite packages of wx3.0.1 and BZR 5073 kicad on
   Debian 7.
  
   Program received signal SIGSEGV, Segmentation fault.
   IA__gdk_cursor_ref (cursor=cursor@entry=0xf2e66c318c48348)
   at /tmp/buildd/gtk+2.0-2.24.10/gdk/gdkcursor.c:57
   57   /tmp/buildd/gtk+2.0-2.24.10/gdk/gdkcursor.c: No such file or
   directory.
   (gdb) bt
   #0  IA__gdk_cursor_ref (cursor=cursor@entry=0xf2e66c318c48348)
   at /tmp/buildd/gtk+2.0-2.24.10/gdk/gdkcursor.c:57
   #1  0x747cc691 in IA__gdk_window_set_cursor (window=0xbe3120,
   cursor=0xf2e66c318c48348) at /tmp/buildd/gtk
   +2.0-2.24.10/gdk/gdkwindow.c:8199
   #2  0x76b8897f in wxWindow::GTKUpdateCursor (this=0x8273f0,
   isBusyOrGlobalCursor=optimized out, isRealize=false)
   at ../src/gtk/window.cpp:3761
   #3  0x76b682a1 in UpdateCursors (win=win@entry=0x8273f0,
   isBusyOrGlobalCursor=optimized out) at ../src/gtk/cursor.cpp:331
   #4

Re: [Kicad-developers] Segfault when running DRC

[Andrew Zonenberg]

I filed a ticket with upstream
http://trac.wxwidgets.org/ticket/16423#ticket so we'll see what they
say.

On Fri, 2014-08-15 at 23:53 -0400, Andrew Zonenberg wrote:
 The invalid read seems to be a bug in wxWidgets:
 
 src/gtk/window.cpp:1543
 
 static void SendSetCursorEvent(wxWindowGTK* win, int x, int y)
 {
 wxSetCursorEvent event(x, y);
 wxWindowGTK* w = win;
 do {
 if (w-GTKProcessEvent(event))
 {
 gs_overrideCursor = event.GetCursor();
 win-GTKUpdateCursor();
 gs_needCursorResetMap[win] = true;
 return;
 }
 // this is how wxMSW works...
 if (w-GetCursor().IsOk())
 break;
 w = w-GetParent();
 } while (w);
 if (gs_needCursorResetMap[win])
 win-GTKUpdateCursor();
 }
 
 event is a local variable on the stack and as a result, as soon as this
 function returns gs_overrideCursor is invalid.
 
 I'm not yet sure if this has any relationship whatsoever to the crash
 I'm hunting.
 
 On Fri, 2014-08-15 at 23:31 -0400, Andrew Zonenberg wrote:
  I'm not using codelight itself, just their precompiled wx binaries, so I
  can easily remove the binary package, it was just less work than
  compiling from source.
  
  I'm investigating further now, I fixed an unrelated missing variable
  initializer in the process and will be submitting a patch to that
  shortly.
  
  On Fri, 2014-08-15 at 22:14 -0500, Dick Hollenbeck wrote:
   On 08/15/2014 08:32 PM, Andrew Zonenberg wrote:
Does not crash when run under Valgrind, instead gives this error:

==32723== Invalid read of size 8
   
   ^ this error?  I've seen that before and never could figure it out, nor 
   was it ever the
   cause of any problem running valgrind.
   
   I would say build your own wxwidgets from the 3.0.1 source.  We're 
   dealing with an unknown
   problem, so one has to revert to probabilities at that point.
   
   I think the highest probability is that there is some incompatibility in 
   your software
   stack.  Building wx from source is an easy experiment.  You do not have 
   to remove the wx
   package if it makes codelight happy.
   
   Follow the instructions I gave in an earlier email today.  Then after 
   configuring the
   kicad build, I run
   
   (ccmake is in the package cmake-curses-gui I think.)
   
   $ ccmake .
   
   in the build directory.  Then I paste in
   
 /opt/wx3.0-stl/bin/wx-config
   
   into the field named:  wxWidgets_CONFIG_EXECUTABLE and reconfigure in 
   ccmake.
   
   Likewise for the debug build, which over time will be very helpful for 
   you.
   
   
   Obviously the first part of the /opt/wx3.0-stl/bin/wx-config string came 
   from the --prefix
   argument to the wx configure command.
   
   Don't forget to run $ sudo ldconfig
   after installing the home made wx libraries.
   
   
   
   
   
==32723==at 0x5D00EC0: wxCursor::GetCursor() const (cursor.cpp:287)
==32723==by 0x5D20A8D: wxWindow::GTKUpdateCursor(bool, bool)
(window.cpp:3752)
==32723==by 0x5D002A0: UpdateCursors(wxWindow*, bool)
(cursor.cpp:331)
==32723==by 0x5D00F42: SetGlobalCursor(wxCursor const)
(cursor.cpp:350)
==32723==by 0x5D0109C: wxEndBusyCursor() (cursor.cpp:376)
==32723==by 0x1D3FCCDB:
DIALOG_DRC_CONTROL::OnStartdrcClick(wxCommandEvent)
(dialog_drc.cpp:172)
==32723==by 0x65F92DE:
wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor,
wxEvent) const (appbase.cpp:623)
==32723==by 0x6750FF1:
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const,
wxEvtHandler*, wxEvent) (event.cpp:1384)
==32723==by 0x67513A5:
wxEvtHandler::SearchDynamicEventTable(wxEvent) (event.cpp:1743)
==32723==by 0x6751445: wxEvtHandler::TryHereOnly(wxEvent)
(event.cpp:1577)
==32723==by 0x6751502: wxEvtHandler::ProcessEventLocally(wxEvent)
(event.h:3671)
==32723==by 0x6751564: wxEvtHandler::ProcessEvent(wxEvent)
(event.cpp:1487)
==32723==  Address 0x7feffdee8 is not stack'd, malloc'd or (recently)
free'd


On Fri, 2014-08-15 at 21:19 -0400, Andrew Zonenberg wrote:
Happens every time I run DRC on this board. I don't want to change the
design for fear of not being able to reproduce it.
   
This is with the Codelite packages of wx3.0.1 and BZR 5073 kicad on
Debian 7.
   
Program received signal SIGSEGV, Segmentation fault.
IA__gdk_cursor_ref (cursor=cursor@entry=0xf2e66c318c48348)
at /tmp/buildd/gtk+2.0-2.24.10/gdk/gdkcursor.c:57
57 /tmp/buildd/gtk+2.0-2.24.10/gdk/gdkcursor.c: No such file or
directory.
(gdb) bt
#0  IA__gdk_cursor_ref (cursor=cursor@entry=0xf2e66c318c48348)
at /tmp/buildd/gtk+2.0-2.24.10/gdk/gdkcursor.c:57
#1  0x747cc691 in IA__gdk_window_set_cursor (window=0xbe3120,
cursor=0xf2e66c318c48348) at /tmp/buildd/gtk
+2.0-2.24.10/gdk/gdkwindow.c:8199

[Kicad-developers] wxString conversion issues in pcbnew/netlist.cpp [PATCH]

[Andrew Zonenberg]

I was investigating some memory corruption segfaults with Valgrind and
found that the netlist-import code in pcbnew is calling
wxString::Printf() with a char* using the %s format specifier.

While this may look right, the _() macro (through many levels of
indirection) converts %s to %ls, which expects a wide character string.

The end result is that wcslen() gets called with a char* string, fails
to stop at the 1-byte null character, and keeps on reading off the end
causing garbage to be strewn through memory and sometimes crash pcbnew.
This can be fixed by forcibly converting the incoming UTF-8 string to
wchar_t* before passing it to wxString::Printf().

The attached patch was tested on wx 2.8 on Debian 7 64-bit. I'm not sure
if it breaks anything on Windows or wx 3.0 so please test carefully :)

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/

=== modified file 'pcbnew/netlist.cpp'
--- pcbnew/netlist.cpp	2014-06-05 07:54:47 +
+++ pcbnew/netlist.cpp	2014-08-13 06:18:06 +
@@ -242,8 +242,8 @@
 {
 msg.Printf( _( * Warning: component '%s' has footprint '%s' and should be '%s'\n ),
 GetChars( component-GetReference() ),
-fpOnBoard-GetFPID().GetFootprintName().c_str(),
-component-GetFPID().GetFootprintName().c_str() );
+wxString( fpOnBoard-GetFPID().GetFootprintName() ).wc_str(),
+wxString( component-GetFPID().GetFootprintName() ).wc_str() );
 aReporter-Report( msg );
 }
 
@@ -272,7 +272,7 @@
 msg.Printf( _( *** Warning: Component '%s' footprint ID '%s' is not 
valid. ***\n ),
 GetChars( component-GetReference() ),
-component-GetFPID().GetFootprintName().c_str() );
+wxString( component-GetFPID().GetFootprintName() ).wc_str() );
 aReporter-Report( msg );
 }
 
@@ -294,7 +294,7 @@
 msg.Printf( _( *** Warning: component '%s' footprint '%s' was not found in 
any libraries in the footprint library table. ***\n ),
 GetChars( component-GetReference() ),
-component-GetFPID().GetFootprintName().c_str() );
+wxString( component-GetFPID().GetFootprintName() ).wc_str() );
 aReporter-Report( msg );
 }
 



signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxString conversion issues in pcbnew/netlist.cpp [PATCH]

[Andrew Zonenberg]

On Wed, 2014-08-13 at 10:47 +0200, jp charras wrote:
 Le 13/08/2014 08:52, Andrew Zonenberg a écrit :
  I was investigating some memory corruption segfaults with Valgrind and
  found that the netlist-import code in pcbnew is calling
  wxString::Printf() with a char* using the %s format specifier.
  
  While this may look right, the _() macro (through many levels of
  indirection) converts %s to %ls, which expects a wide character string.
  
  The end result is that wcslen() gets called with a char* string, fails
  to stop at the 1-byte null character, and keeps on reading off the end
  causing garbage to be strewn through memory and sometimes crash pcbnew.
  This can be fixed by forcibly converting the incoming UTF-8 string to
  wchar_t* before passing it to wxString::Printf().
  
  The attached patch was tested on wx 2.8 on Debian 7 64-bit. I'm not sure
  if it breaks anything on Windows or wx 3.0 so please test carefully :)
 
 
 Thanks, Andrew.
 
 wxString( fpOnBoard-GetFPID().GetFootprintName() ).GetData()
 
 instead of
 wxString( fpOnBoard-GetFPID().GetFootprintName() ).wc_str()
 
 could be a better fix for this issue.
 
 

Updated patch, attached, confirmed for working without any errors on my
machine. Anybody want to test on Windows or wx3.0?

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/
=== modified file 'pcbnew/netlist.cpp'
--- pcbnew/netlist.cpp	2014-06-05 07:54:47 +
+++ pcbnew/netlist.cpp	2014-08-13 12:20:51 +
@@ -242,8 +242,8 @@
 {
 msg.Printf( _( * Warning: component '%s' has footprint '%s' and should be '%s'\n ),
 GetChars( component-GetReference() ),
-fpOnBoard-GetFPID().GetFootprintName().c_str(),
-component-GetFPID().GetFootprintName().c_str() );
+wxString( fpOnBoard-GetFPID().GetFootprintName() ).GetData(),
+wxString( component-GetFPID().GetFootprintName() ).GetData() );
 aReporter-Report( msg );
 }
 
@@ -272,7 +272,7 @@
 msg.Printf( _( *** Warning: Component '%s' footprint ID '%s' is not 
valid. ***\n ),
 GetChars( component-GetReference() ),
-component-GetFPID().GetFootprintName().c_str() );
+wxString( component-GetFPID().GetFootprintName() ).GetData() );
 aReporter-Report( msg );
 }
 
@@ -294,7 +294,7 @@
 msg.Printf( _( *** Warning: component '%s' footprint '%s' was not found in 
any libraries in the footprint library table. ***\n ),
 GetChars( component-GetReference() ),
-component-GetFPID().GetFootprintName().c_str() );
+wxString( component-GetFPID().GetFootprintName() ).GetData() );
 aReporter-Report( msg );
 }
 



signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxString conversion issues in pcbnew/netlist.cpp [PATCH]

[Andrew Zonenberg]

Hmm, yes that should do the conversion inline.

Updated patch attached, tested on Debian wx 2.8.

 static inline const wxChar* GetChars( const wxString s )
 {
 #if wxCHECK_VERSION( 2, 9, 0 )
 return (const wxChar*) s.c_str();
 #else
 return s.GetData();
 #endif
 }
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/
=== modified file 'pcbnew/netlist.cpp'
--- pcbnew/netlist.cpp	2014-06-05 07:54:47 +
+++ pcbnew/netlist.cpp	2014-08-13 18:08:57 +
@@ -242,8 +242,8 @@
 {
 msg.Printf( _( * Warning: component '%s' has footprint '%s' and should be '%s'\n ),
 GetChars( component-GetReference() ),
-fpOnBoard-GetFPID().GetFootprintName().c_str(),
-component-GetFPID().GetFootprintName().c_str() );
+GetChars( fpOnBoard-GetFPID().GetFootprintName() ),
+GetChars( component-GetFPID().GetFootprintName() ) );
 aReporter-Report( msg );
 }
 
@@ -272,7 +272,7 @@
 msg.Printf( _( *** Warning: Component '%s' footprint ID '%s' is not 
valid. ***\n ),
 GetChars( component-GetReference() ),
-component-GetFPID().GetFootprintName().c_str() );
+GetChars( component-GetFPID().GetFootprintName() ) );
 aReporter-Report( msg );
 }
 
@@ -294,7 +294,7 @@
 msg.Printf( _( *** Warning: component '%s' footprint '%s' was not found in 
any libraries in the footprint library table. ***\n ),
 GetChars( component-GetReference() ),
-component-GetFPID().GetFootprintName().c_str() );
+GetChars( component-GetFPID().GetFootprintName() ) );
 aReporter-Report( msg );
 }
 



signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Status of my merge request (parallelization of 3D model normal calculation using OpenMP)

[Andrew Zonenberg]

Hi all,

I submitted a merge request a week or two ago via Launchpad:
https://code.launchpad.net/~azonenberg/kicad/advanced-feature-bugfixes/+merge/229341

Orson and Wayne both commented on it with some minor concerns related to
#ifdefs and code formatting. I pushed an updated version a few hours
later addressing their concerns. Orson told me via IRC that he's fine
with the updated code, and that's the last I've heard from anyone.

Are you guys just too busy to look at it right now? Did it get
misplaced/forgotten? Are there any other issues with my code that
nobody's told me about? It's not exactly urgent, but I'd like to get it
merged eventually.

Thanks :)

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Status of my merge request (parallelization of 3D model normal calculation using OpenMP)

[Andrew Zonenberg]

Hmm, let me take a look at the existing code. I'm pretty sure that was
already there, since all I did was indent the entire block by one level
and put the OpenMP pragma around it.

In any case, I'll fix it.

On Mon, 2014-08-11 at 20:43 -0500, Dick Hollenbeck wrote:
 On 08/11/2014 07:51 PM, Andrew Zonenberg wrote:
  Hi all,
  
  I submitted a merge request a week or two ago via Launchpad:
  https://code.launchpad.net/~azonenberg/kicad/advanced-feature-bugfixes/+merge/229341
  
  Orson and Wayne both commented on it with some minor concerns related to
  #ifdefs and code formatting. I pushed an updated version a few hours
  later addressing their concerns. Orson told me via IRC that he's fine
  with the updated code, and that's the last I've heard from anyone.
  
  Are you guys just too busy to look at it right now? Did it get
  misplaced/forgotten? Are there any other issues with my code that
  nobody's told me about? It's not exactly urgent, but I'd like to get it
  merged eventually.
  
  Thanks :)
 
 
 Probably too busy.
 
 line 41 of this:
 
 https://code.launchpad.net/~azonenberg/kicad/advanced-feature-bugfixes/+merge/229341
 
 is showing one indent level on a switch(), and this is incorrect.  Case 
 statements are at
 the same indent level as the switch().
 
  switch( m_CoordIndex[idx].size() )
 40{
 41case 3: glBegin( GL_TRIANGLES );break;
 42case 4: glBegin( GL_QUADS ); break;
 43default: glBegin( GL_POLYGON ); break;
 44}
 
 
 Email formatting is not reliable here.
 
 I am not taking any responsibility for committing it.   But this is one 
 obvious deficiency.
 
 
 You did good reminding those that have already commented.
 
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Crash (std::bad_alloc exception) when importing netlist

[Andrew Zonenberg]

This has been happening pretty regularly to me, this is the fourth time
it's happened to me on this board alone. I finally managed to trigger it
in a debug build so here's some info.

It appears that the bug happens when the ratsnest calculator resizes a
std::vector to an absurd size (in this case, about 88 million 496-byte
RN_NET objects, which comes out to about 40 GB).

The code triggering the issue is:

for( const D_PAD* pad = module-Pads().GetFirst(); pad; pad =
pad-Next() )
{
net = pad-GetNetCode();

if( net  1 )   // do not process unconnected items
continue;

if( net = (int) m_nets.size() )// Autoresize
m_nets.resize( net + 1 );

m_nets[net].AddItem( pad );
}

Tracing back, pad-GetNetCode() must have returned 8849. I'm not
sure how this happened, though... my laptop froze for unrelated reasons
right as I was stepping through the code and I wasn't able to figure out
what is going on.

Steps to reproduce:

Open pcbnew with an existing board that has some unassigned footprints
Switch to GAL
Open cvpcb
Assign to existing passive library footprint
Import to pcbnew
No crash
Make new footprint
Save it in library
Assign to component in cvpcb
Move a passive around
Import netlist
Crash

#0  0x7638fb90 in __cxa_throw ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x763900dd in operator new(unsigned long) ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2  0x7fffd768107e in __gnu_cxx::new_allocatorRN_NET::allocate
(this=0x3081488, __n=88490001) at /usr/include/c
++/4.7/ext/new_allocator.h:94
#3  0x7fffd767d32d in std::_Vector_baseRN_NET,
std::allocatorRN_NET ::_M_allocate (this=0x3081488, __n=88490001)
at /usr/include/c++/4.7/bits/stl_vector.h:169
#4  0x7fffd7676aef in std::vectorRN_NET, std::allocatorRN_NET
::_M_fill_insert (this=0x3081488, __position=..., __n=88489817,
__x=...) at /usr/include/c++/4.7/bits/vector.tcc:481
#5  0x7fffd7670136 in std::vectorRN_NET, std::allocatorRN_NET
::insert (this=0x3081488, __position=..., __n=88489817, __x=...)
at /usr/include/c++/4.7/bits/stl_vector.h:1004
#6  0x7fffd7669f05 in std::vectorRN_NET, std::allocatorRN_NET
::resize (this=0x3081488, __new_size=88490001, __x=...)
at /usr/include/c++/4.7/bits/stl_vector.h:687
#7  0x7fffd7664193 in RN_DATA::Add (this=0x3081480, aItem=0x4703bd0)
at 
/nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad/pcbnew/ratsnest_data.cpp:858
#8  0x7fffd761fff5 in BOARD::Add (this=0x307bd60,
aBoardItem=0x4703bd0, aControl=1)
at 
/nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad/pcbnew/class_board.cpp:717
#9  0x7fffd76241be in BOARD::ReplaceNetlist (this=0x307bd60,
aNetlist=..., aDeleteSinglePadNets=true, aReporter=0x7fffb9a0)
at 
/nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad/pcbnew/class_board.cpp:2252
#10 0x7fffd74fc547 in PCB_EDIT_FRAME::ReadPcbNetlist
(this=0x10e04d0, aNetlistFileName=..., aCmpFileName=...,
aReporter=0x7fffb9a0, aChangeFootprints=false,
aDeleteUnconnectedTracks=false, aDeleteExtraFootprints=false, 
aSelectByTimeStamp=false, aDeleteSinglePadNets=true,
aIsDryRun=false)
at 
/nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad/pcbnew/netlist.cpp:112
#11 0x7fffd7435130 in DIALOG_NETLIST::OnReadNetlistFileClick
(this=0x7fffcae0, event=...)
at 
/nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad/pcbnew/dialogs/dialog_netlist.cpp:202
#12 0x769273f6 in
wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const,
wxEvtHandler*, wxEvent) ()
from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#13 0x7692779f in
wxEvtHandler::SearchDynamicEventTable(wxEvent) ()
from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#14 0x76927852 in wxEvtHandler::ProcessEvent(wxEvent) ()
from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0


-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Crash (std::bad_alloc exception) when importing netlist

[Andrew Zonenberg]

It appears to be a bad pointer, somehow a chunk of bad memory that was
once a wxBrush is being interpreted as a NETINFO_ITEM and all hell
breaks loose.

Valgrind trace of the failure: http://pastebin.com/ax6RDF3u

Anybody have ideas on how to proceed at this point?

On Mon, 2014-08-11 at 23:10 -0400, Andrew Zonenberg wrote:
 This has been happening pretty regularly to me, this is the fourth time
 it's happened to me on this board alone. I finally managed to trigger it
 in a debug build so here's some info.
 
 It appears that the bug happens when the ratsnest calculator resizes a
 std::vector to an absurd size (in this case, about 88 million 496-byte
 RN_NET objects, which comes out to about 40 GB).
 
 The code triggering the issue is:
 
 for( const D_PAD* pad = module-Pads().GetFirst(); pad; pad =
 pad-Next() )
 {
   net = pad-GetNetCode();
 
   if( net  1 )   // do not process unconnected items
   continue;
 
   if( net = (int) m_nets.size() )// Autoresize
   m_nets.resize( net + 1 );
 
   m_nets[net].AddItem( pad );
 }
 
 Tracing back, pad-GetNetCode() must have returned 8849. I'm not
 sure how this happened, though... my laptop froze for unrelated reasons
 right as I was stepping through the code and I wasn't able to figure out
 what is going on.
 
 Steps to reproduce:
 
 Open pcbnew with an existing board that has some unassigned footprints
 Switch to GAL
 Open cvpcb
 Assign to existing passive library footprint
 Import to pcbnew
 No crash
 Make new footprint
 Save it in library
 Assign to component in cvpcb
 Move a passive around
 Import netlist
 Crash
 
 #0  0x7638fb90 in __cxa_throw ()
 from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
 #1  0x763900dd in operator new(unsigned long) ()
 from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
 #2  0x7fffd768107e in __gnu_cxx::new_allocatorRN_NET::allocate
 (this=0x3081488, __n=88490001) at /usr/include/c
 ++/4.7/ext/new_allocator.h:94
 #3  0x7fffd767d32d in std::_Vector_baseRN_NET,
 std::allocatorRN_NET ::_M_allocate (this=0x3081488, __n=88490001)
 at /usr/include/c++/4.7/bits/stl_vector.h:169
 #4  0x7fffd7676aef in std::vectorRN_NET, std::allocatorRN_NET
 ::_M_fill_insert (this=0x3081488, __position=..., __n=88489817,
 __x=...) at /usr/include/c++/4.7/bits/vector.tcc:481
 #5  0x7fffd7670136 in std::vectorRN_NET, std::allocatorRN_NET
 ::insert (this=0x3081488, __position=..., __n=88489817, __x=...)
 at /usr/include/c++/4.7/bits/stl_vector.h:1004
 #6  0x7fffd7669f05 in std::vectorRN_NET, std::allocatorRN_NET
 ::resize (this=0x3081488, __new_size=88490001, __x=...)
 at /usr/include/c++/4.7/bits/stl_vector.h:687
 #7  0x7fffd7664193 in RN_DATA::Add (this=0x3081480, aItem=0x4703bd0)
 at 
 /nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad/pcbnew/ratsnest_data.cpp:858
 #8  0x7fffd761fff5 in BOARD::Add (this=0x307bd60,
 aBoardItem=0x4703bd0, aControl=1)
 at 
 /nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad/pcbnew/class_board.cpp:717
 #9  0x7fffd76241be in BOARD::ReplaceNetlist (this=0x307bd60,
 aNetlist=..., aDeleteSinglePadNets=true, aReporter=0x7fffb9a0)
 at 
 /nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad/pcbnew/class_board.cpp:2252
 #10 0x7fffd74fc547 in PCB_EDIT_FRAME::ReadPcbNetlist
 (this=0x10e04d0, aNetlistFileName=..., aCmpFileName=...,
 aReporter=0x7fffb9a0, aChangeFootprints=false,
 aDeleteUnconnectedTracks=false, aDeleteExtraFootprints=false, 
 aSelectByTimeStamp=false, aDeleteSinglePadNets=true,
 aIsDryRun=false)
 at 
 /nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad/pcbnew/netlist.cpp:112
 #11 0x7fffd7435130 in DIALOG_NETLIST::OnReadNetlistFileClick
 (this=0x7fffcae0, event=...)
 at 
 /nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad/pcbnew/dialogs/dialog_netlist.cpp:202
 #12 0x769273f6 in
 wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const,
 wxEvtHandler*, wxEvent) ()
 from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
 #13 0x7692779f in
 wxEvtHandler::SearchDynamicEventTable(wxEvent) ()
 from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
 #14 0x76927852 in wxEvtHandler::ProcessEvent(wxEvent) ()
 from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad

[Kicad-developers] Very inefficient loading of 3D models

[Andrew Zonenberg]

So I added a few print statements to my copy of the 3D viewer in order
to figure out why the 3D viewer was so slow...

The results were very interesting.

http://pastebin.com/7s8gXVjY

1) There is no caching whatsoever! The VRML/X3D files are loaded from
scratch each time they're instantiated in the board. If I have three
copies of a high-poly connector model, the VRML is loaded from disk and
parsed three times. This should be an O(1) operation rather than O(n),
with polygon data stored in some kind of application-wide cache and
referenced for each model instance.

2) The instantiated models are thrown out as soon as the 3D viewer
window is closed or the reload board button in the 3D viewer window is
clicked.

3) Models take an absurd amount of time to load. Three seconds for an
optimized release build to load a Molex HDMI connector (14k vertices and
9k faces) is completely unreasonable, FreeCad loads it in a few hundred
ms (too fast to measure easily).

Is anybody working on this already or should I start optimizing myself?

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Very inefficient loading of 3D models

[Andrew Zonenberg]

I think one of the easiest optimizations is to add some kind of
application-wide cache in RAM such that individual models are only
loaded once (but still of course reloaded when kicad is restarted).

It's OK to have O(n) load time for N distinct models, even with a large
constant factor. What's not OK is to have O(N*M*P) load time if you have
M instances each of N models and refresh the 3D view P times.

Based on my measurements of X3D files in particular (as this is what all
of my large models are) normal calculation is indeed one of the biggest
bottlenecks.

For the Molex HDMI connector in particular, I measure:
* 502.45 ms for wxXmlDocument::Load()
* 217.92 ms for the sum of all of the ReadTransform() calls
* 2092.19 ms for the sum of all openGL_RenderAllChilds() calls
* Of this, 2082.76 ms is spent in calcPerFaceNormals().

I'm going to try slightly refactoring calcPerFaceNormals to use OpenMP
and multithread the normal calculations, will report on my results
shortly.

On Sat, 2014-08-02 at 17:53 +, Mário Luzeiro wrote:
 Hi Andrew,
 
 You are right, it will be special noticeable for very large ( 10K faces) 
 models.
 The major time consuming are now in normal calculation. The algorithm I had 
 implemented IMO is good (probably can be optimized a little more) but it is a 
 nature slow algorithm. (you can see lots of for loops)..
 
 Since I post my first patch with this new additions I point some of this 
 issues, see Know issues / missing features
 https://lists.launchpad.net/kicad-developers/msg14136.html
 
 I believe that a correct proper implementation for this will need some 
 internal discussion with KiCad masters, because I think we have some options 
 to be discussed:
 
 - Calc the normals and update the original file with the processed normals so 
 next time they don't need to be calculated. (it will change / overwrite the 
 original file. It need some type of exporter to that file or to some unique 
 format for all models).
 - Calc the normals per project and store it in a cache folder in the project?
 - Use faster normal algorithm for large models.
 - Do not calc normals, just use if the model have embedded normals. (So you 
 must use an external software to process it)
 
 
 Meanwhile there are some options that can be made:
 First read all different files, then, render it. (Now as you pointed it reads 
 and process every copies :/ .. It was like that and I didn't had time to 
 change)
 For this, the functions
 BuildFootprintShape3DList
 ReadAndInsert3DComponentShape
 ReadData and all S3D_MODEL_PARSER Load (for the different filetypes) must be 
 changed in the way it removes the openGL render from Loadfile.. so it will 
 first load then other function will call the render.
 
 This is relative easy to be done, but sorry I don't have time now to spend on 
 this improvement. so answering your question, I am not working on it and I 
 don't thing anybody is working.
 
 If you will start doing it, fell free to enter in contact with me and I can 
 help and discuss ideas / implementation with you!
 
 thanks!
 
 Regards,
 Mario Luzeiro
 
 p.s.: because I will soon start using kicad again as a user and will need to 
 load beautiful 3d models.. and faster :) so it would be nice to have this 
 optimized feature!
 
 
 From: Kicad-developers 
 [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of 
 Andrew Zonenberg [azonenb...@drawersteak.com]
 Sent: 02 August 2014 19:30
 To: kicad-developers@lists.launchpad.net
 Subject: [Kicad-developers] Very inefficient loading of 3D models
 
 So I added a few print statements to my copy of the 3D viewer in order
 to figure out why the 3D viewer was so slow...
 
 The results were very interesting.
 
 http://pastebin.com/7s8gXVjY
 
 1) There is no caching whatsoever! The VRML/X3D files are loaded from
 scratch each time they're instantiated in the board. If I have three
 copies of a high-poly connector model, the VRML is loaded from disk and
 parsed three times. This should be an O(1) operation rather than O(n),
 with polygon data stored in some kind of application-wide cache and
 referenced for each model instance.
 
 2) The instantiated models are thrown out as soon as the 3D viewer
 window is closed or the reload board button in the 3D viewer window is
 clicked.
 
 3) Models take an absurd amount of time to load. Three seconds for an
 optimized release build to load a Molex HDMI connector (14k vertices and
 9k faces) is completely unreasonable, FreeCad loads it in a few hundred
 ms (too fast to measure easily).
 
 Is anybody working on this already or should I start optimizing myself?
 
 --
 Andrew Zonenberg
 PhD student, security group
 Computer Science Department
 Rensselaer Polytechnic Institute
 http://colossus.cs.rpi.edu/~azonenberg/

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg

Re: [Kicad-developers] Very inefficient loading of 3D models

[Andrew Zonenberg]

The attached patch parallelizes per-vertex normal calculation using
OpenMP. I see a nearly 4x speedup of model loading on my quad-core
machine.

This does not address the fact that models are constantly reloaded in
lots of places they don't need to be. It's a band-aid on top of that
problem but it will also speed up first-time loading of models when
proper caching is implemented.

On Sat, 2014-08-02 at 14:14 -0400, Andrew Zonenberg wrote:
 I think one of the easiest optimizations is to add some kind of
 application-wide cache in RAM such that individual models are only
 loaded once (but still of course reloaded when kicad is restarted).
 
 It's OK to have O(n) load time for N distinct models, even with a large
 constant factor. What's not OK is to have O(N*M*P) load time if you have
 M instances each of N models and refresh the 3D view P times.
 
 Based on my measurements of X3D files in particular (as this is what all
 of my large models are) normal calculation is indeed one of the biggest
 bottlenecks.
 
 For the Molex HDMI connector in particular, I measure:
 * 502.45 ms for wxXmlDocument::Load()
 * 217.92 ms for the sum of all of the ReadTransform() calls
 * 2092.19 ms for the sum of all openGL_RenderAllChilds() calls
 * Of this, 2082.76 ms is spent in calcPerFaceNormals().
 
 I'm going to try slightly refactoring calcPerFaceNormals to use OpenMP
 and multithread the normal calculations, will report on my results
 shortly.
 
 On Sat, 2014-08-02 at 17:53 +, Mário Luzeiro wrote:
  Hi Andrew,
  
  You are right, it will be special noticeable for very large ( 10K faces) 
  models.
  The major time consuming are now in normal calculation. The algorithm I had 
  implemented IMO is good (probably can be optimized a little more) but it is 
  a nature slow algorithm. (you can see lots of for loops)..
  
  Since I post my first patch with this new additions I point some of this 
  issues, see Know issues / missing features
  https://lists.launchpad.net/kicad-developers/msg14136.html
  
  I believe that a correct proper implementation for this will need some 
  internal discussion with KiCad masters, because I think we have some 
  options to be discussed:
  
  - Calc the normals and update the original file with the processed normals 
  so next time they don't need to be calculated. (it will change / overwrite 
  the original file. It need some type of exporter to that file or to some 
  unique format for all models).
  - Calc the normals per project and store it in a cache folder in the 
  project?
  - Use faster normal algorithm for large models.
  - Do not calc normals, just use if the model have embedded normals. (So you 
  must use an external software to process it)
  
  
  Meanwhile there are some options that can be made:
  First read all different files, then, render it. (Now as you pointed it 
  reads and process every copies :/ .. It was like that and I didn't had time 
  to change)
  For this, the functions
  BuildFootprintShape3DList
  ReadAndInsert3DComponentShape
  ReadData and all S3D_MODEL_PARSER Load (for the different filetypes) must 
  be changed in the way it removes the openGL render from Loadfile.. so it 
  will first load then other function will call the render.
  
  This is relative easy to be done, but sorry I don't have time now to spend 
  on this improvement. so answering your question, I am not working on it and 
  I don't thing anybody is working.
  
  If you will start doing it, fell free to enter in contact with me and I can 
  help and discuss ideas / implementation with you!
  
  thanks!
  
  Regards,
  Mario Luzeiro
  
  p.s.: because I will soon start using kicad again as a user and will need 
  to load beautiful 3d models.. and faster :) so it would be nice to have 
  this optimized feature!
  
  
  From: Kicad-developers 
  [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of 
  Andrew Zonenberg [azonenb...@drawersteak.com]
  Sent: 02 August 2014 19:30
  To: kicad-developers@lists.launchpad.net
  Subject: [Kicad-developers] Very inefficient loading of 3D models
  
  So I added a few print statements to my copy of the 3D viewer in order
  to figure out why the 3D viewer was so slow...
  
  The results were very interesting.
  
  http://pastebin.com/7s8gXVjY
  
  1) There is no caching whatsoever! The VRML/X3D files are loaded from
  scratch each time they're instantiated in the board. If I have three
  copies of a high-poly connector model, the VRML is loaded from disk and
  parsed three times. This should be an O(1) operation rather than O(n),
  with polygon data stored in some kind of application-wide cache and
  referenced for each model instance.
  
  2) The instantiated models are thrown out as soon as the 3D viewer
  window is closed or the reload board button in the 3D viewer window is
  clicked.
  
  3) Models take an absurd amount of time to load. Three seconds for an
  optimized release build

Re: [Kicad-developers] Very inefficient loading of 3D models

[Andrew Zonenberg]

Good idea.

Let me work on getting a RAM cache working first, then we can update the
load file from disk code later on.

On Sat, 2014-08-02 at 21:35 +0200, Tomasz Wlostowski wrote:
 On 02.08.2014 20:30, Andrew Zonenberg wrote:
  The attached patch parallelizes per-vertex normal calculation using
  OpenMP. I see a nearly 4x speedup of model loading on my quad-core
  machine.
 
 Hi Andrew,
 
 Caching the meshes including normals on disk could speed up loading even 
 further:
 - take the model file,
 - mesh it (STEP) and calculate normals/other per-vertex/face stuff,
 - save in internal binary format on disk along with the hash/name/date 
 of the source model file.
 
 On loading:
 - first look in the RAM (the file might have been loaded already by 
 another viewer instance),
 - check the disk cache,
 - if not found, mesh the model and update the disk cache.
 
 Cheers,
 Tom
 

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Segfault in X3D module parser (build 5041, did not happen in 5034)

[Andrew Zonenberg]

When loading this model:
http://colossus.cs.rpi.edu/~azonenberg/downloads/molex-1051561008.x3d

I get a crash in the X3D model parser.

It appears to be due to a null dereference accessing color[0] since
color has a size of zero and the internal array is null. I'm not sure if
the model is well-formed or not (I converted the Molex model from I
think STEP or IGES format via Freecad and Blender, then exported to X3D)
but the loader shouldn't crash regardless of the input.

Program received signal SIGSEGV, Segmentation fault.
0x7fffe6a423bb in X3D_MODEL_PARSER::readIndexedFaceSet
(this=0x63ea870, aFaceNode=0x64a1970, aTransformProps=...)
at 
/nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad.bzr/3d-viewer/x3dmodelparser.cpp:527
527 GetNodeProperties( color[0], color_properties );

(gdb) print color
$1 = {std::_Vector_basewxXmlNode*, std::allocatorwxXmlNode*  =
{_M_impl = {std::allocatorwxXmlNode* =
{__gnu_cxx::new_allocatorwxXmlNode* = {No data fields}, No data
fields}, _M_start = 0x0, _M_finish = 0x0, 
  _M_end_of_storage = 0x0}}, No data fields}
(gdb) print color_properties
$2 = {_M_t = {_M_impl =
{std::allocatorstd::_Rb_tree_nodestd::pairwxString const, wxString
  = {__gnu_cxx::new_allocatorstd::_Rb_tree_nodestd::pairwxString
const, wxString   = {No data fields}, No data fields}, 
  _M_key_compare = {std::binary_functionwxString, wxString, bool
= {No data fields}, No data fields}, _M_header = {_M_color =
std::_S_red, _M_parent = 0x0, _M_left = 0x7fffb3a8, _M_right =
0x7fffb3a8}, 
  _M_node_count = 0}}}

(gdb) bt
#0  0x7fffe6a423bb in X3D_MODEL_PARSER::readIndexedFaceSet
(this=0x63ea870, aFaceNode=0x64a1970, aTransformProps=...)
at 
/nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad.bzr/3d-viewer/x3dmodelparser.cpp:527
#1  0x7fffe6a404d5 in X3D_MODEL_PARSER::readTransform
(this=0x63ea870, aTransformNode=0x63d9ec0)
at 
/nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad.bzr/3d-viewer/x3dmodelparser.cpp:222
#2  0x7fffe6a3fd26 in X3D_MODEL_PARSER::Load (this=0x63ea870,
aFilename=...)
at 
/nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad.bzr/3d-viewer/x3dmodelparser.cpp:109
#3  0x7fffe6a34251 in S3D_MASTER::ReadData (this=0x521fc60)
at 
/nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad.bzr/3d-viewer/3d_read_mesh.cpp:122
#4  0x7fffe6a4f4e2 in MODULE::ReadAndInsert3DComponentShape
(this=0x721f0c0, glcanvas=0x63fb660, aAllowNonTransparentObjects=true,
aAllowTransparentObjects=false, aSideToLoad=false)

at 
/nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad.bzr/3d-viewer/3d_draw.cpp:1703
#5  0x7fffe6a4e719 in EDA_3D_CANVAS::BuildFootprintShape3DList
(this=0x63fb660, aOpaqueList=7, aTransparentList=8, aSideToLoad=false)
at 
/nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad.bzr/3d-viewer/3d_draw.cpp:1471
#6  0x7fffe6a4e5e3 in EDA_3D_CANVAS::CreateDrawGL_List
(this=0x63fb660)
at 
/nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad.bzr/3d-viewer/3d_draw.cpp:1436
#7  0x7fffe6a4ad6c in EDA_3D_CANVAS::GenerateFakeShadowsTextures
(this=0x63fb660)
at 
/nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad.bzr/3d-viewer/3d_draw.cpp:302
#8  0x7fffe6a4b1be in EDA_3D_CANVAS::Redraw (this=0x63fb660)
at 
/nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad.bzr/3d-viewer/3d_draw.cpp:371
#9  0x7fffe6a48dba in EDA_3D_CANVAS::OnPaint (this=0x63fb660,
event=...)
at 
/nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad.bzr/3d-viewer/3d_canvas.cpp:490
#10 0x769273f6 in
wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const,
wxEvtHandler*, wxEvent) ()
from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0

(remainder of backtrace trimmed, can supply if necessary)

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Segfault in X3D module parser (build 5041, did not happen in 5034) [PATCH]

[Andrew Zonenberg]

The attached patch causes the model to load properly on my machine. It
adds a check to disable loading color information if no color nodes were
found.

On Fri, 2014-08-01 at 15:29 -0400, Andrew Zonenberg wrote:
 When loading this model:
 http://colossus.cs.rpi.edu/~azonenberg/downloads/molex-1051561008.x3d
 
 I get a crash in the X3D model parser.
 
 It appears to be due to a null dereference accessing color[0] since
 color has a size of zero and the internal array is null. I'm not sure if
 the model is well-formed or not (I converted the Molex model from I
 think STEP or IGES format via Freecad and Blender, then exported to X3D)
 but the loader shouldn't crash regardless of the input.
 
 Program received signal SIGSEGV, Segmentation fault.
 0x7fffe6a423bb in X3D_MODEL_PARSER::readIndexedFaceSet
 (this=0x63ea870, aFaceNode=0x64a1970, aTransformProps=...)
 at 
 /nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad.bzr/3d-viewer/x3dmodelparser.cpp:527
 527   GetNodeProperties( color[0], color_properties );
 
 (gdb) print color
 $1 = {std::_Vector_basewxXmlNode*, std::allocatorwxXmlNode*  =
 {_M_impl = {std::allocatorwxXmlNode* =
 {__gnu_cxx::new_allocatorwxXmlNode* = {No data fields}, No data
 fields}, _M_start = 0x0, _M_finish = 0x0, 
   _M_end_of_storage = 0x0}}, No data fields}
 (gdb) print color_properties
 $2 = {_M_t = {_M_impl =
 {std::allocatorstd::_Rb_tree_nodestd::pairwxString const, wxString
   = {__gnu_cxx::new_allocatorstd::_Rb_tree_nodestd::pairwxString
 const, wxString   = {No data fields}, No data fields}, 
   _M_key_compare = {std::binary_functionwxString, wxString, bool
 = {No data fields}, No data fields}, _M_header = {_M_color =
 std::_S_red, _M_parent = 0x0, _M_left = 0x7fffb3a8, _M_right =
 0x7fffb3a8}, 
   _M_node_count = 0}}}
 
 (gdb) bt
 #0  0x7fffe6a423bb in X3D_MODEL_PARSER::readIndexedFaceSet
 (this=0x63ea870, aFaceNode=0x64a1970, aTransformProps=...)
 at 
 /nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad.bzr/3d-viewer/x3dmodelparser.cpp:527
 #1  0x7fffe6a404d5 in X3D_MODEL_PARSER::readTransform
 (this=0x63ea870, aTransformNode=0x63d9ec0)
 at 
 /nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad.bzr/3d-viewer/x3dmodelparser.cpp:222
 #2  0x7fffe6a3fd26 in X3D_MODEL_PARSER::Load (this=0x63ea870,
 aFilename=...)
 at 
 /nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad.bzr/3d-viewer/x3dmodelparser.cpp:109
 #3  0x7fffe6a34251 in S3D_MASTER::ReadData (this=0x521fc60)
 at 
 /nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad.bzr/3d-viewer/3d_read_mesh.cpp:122
 #4  0x7fffe6a4f4e2 in MODULE::ReadAndInsert3DComponentShape
 (this=0x721f0c0, glcanvas=0x63fb660, aAllowNonTransparentObjects=true,
 aAllowTransparentObjects=false, aSideToLoad=false)
 
 at 
 /nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad.bzr/3d-viewer/3d_draw.cpp:1703
 #5  0x7fffe6a4e719 in EDA_3D_CANVAS::BuildFootprintShape3DList
 (this=0x63fb660, aOpaqueList=7, aTransparentList=8, aSideToLoad=false)
 at 
 /nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad.bzr/3d-viewer/3d_draw.cpp:1471
 #6  0x7fffe6a4e5e3 in EDA_3D_CANVAS::CreateDrawGL_List
 (this=0x63fb660)
 at 
 /nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad.bzr/3d-viewer/3d_draw.cpp:1436
 #7  0x7fffe6a4ad6c in EDA_3D_CANVAS::GenerateFakeShadowsTextures
 (this=0x63fb660)
 at 
 /nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad.bzr/3d-viewer/3d_draw.cpp:302
 #8  0x7fffe6a4b1be in EDA_3D_CANVAS::Redraw (this=0x63fb660)
 at 
 /nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad.bzr/3d-viewer/3d_draw.cpp:371
 #9  0x7fffe6a48dba in EDA_3D_CANVAS::OnPaint (this=0x63fb660,
 event=...)
 at 
 /nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad.bzr/3d-viewer/3d_canvas.cpp:490
 #10 0x769273f6 in
 wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const,
 wxEvtHandler*, wxEvent) ()
 from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
 
 (remainder of backtrace trimmed, can supply if necessary)
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/
=== modified file '3d-viewer/x3dmodelparser.cpp'
--- 3d-viewer/x3dmodelparser.cpp	2014-07-31 07:01:30 +
+++ 3d-viewer/x3dmodelparser.cpp	2014-08-01 19:34:32 +
@@ -521,47 +521,50 @@
 std::vector double  color_points;
 NODE_LIST color;
 GetChildsByName( aFaceNode, wxT( Color ), color);
-
-PROPERTY_MAP color_properties;
-// IndexedFaceSet has one Coordinate child node
-GetNodeProperties( color[0], color_properties );
-
-// Save points

Re: [Kicad-developers] SIGFPE in pad properties using GAL module editor

[Andrew Zonenberg]

Exact pad properties I was using if it's any help:

http://i.imgur.com/DvnE9sI.png

http://i.imgur.com/1f32yDz.png

Fully reproducible, I can trigger it on command.

On Sun, 2014-07-27 at 20:22 +0200, Nick Østergaard wrote:
 I cannot reproduce with 5018 on linux.
 
 2014-07-27 20:17 GMT+02:00 Andrew Zonenberg azonenb...@drawersteak.com:
  Steps to reproduce:
  * Open the GAL module editor
  * Add a new pad to the module
  * Highlight the size X field
  * Begin to type 0.5 or any other decimal with a leading zero
  * As soon as the 0 is entered, a SIGFPE is thrown
 
  --
  Andrew Zonenberg
  PhD student, security group
  Computer Science Department
  Rensselaer Polytechnic Institute
  http://colossus.cs.rpi.edu/~azonenberg/
 
  ___
  Mailing list: https://launchpad.net/~kicad-developers
  Post to : kicad-developers@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~kicad-developers
  More help   : https://help.launchpad.net/ListHelp
 

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] SIGFPE in pad properties using GAL module editor

[Andrew Zonenberg]

Should have mentioned earlier, I'm using 5025 plus my PNS blind via
patch (which shouldn't be connected to this at all as I never used the
PNS router before the crash) in debug configuration on 64-bit Debian 7
with WX 2.8.

On Sun, 2014-07-27 at 14:23 -0400, Andrew Zonenberg wrote:
 Exact pad properties I was using if it's any help:
 
 http://i.imgur.com/DvnE9sI.png
 
 http://i.imgur.com/1f32yDz.png
 
 Fully reproducible, I can trigger it on command.
 
 On Sun, 2014-07-27 at 20:22 +0200, Nick Østergaard wrote:
  I cannot reproduce with 5018 on linux.
  
  2014-07-27 20:17 GMT+02:00 Andrew Zonenberg azonenb...@drawersteak.com:
   Steps to reproduce:
   * Open the GAL module editor
   * Add a new pad to the module
   * Highlight the size X field
   * Begin to type 0.5 or any other decimal with a leading zero
   * As soon as the 0 is entered, a SIGFPE is thrown
  
   --
   Andrew Zonenberg
   PhD student, security group
   Computer Science Department
   Rensselaer Polytechnic Institute
   http://colossus.cs.rpi.edu/~azonenberg/
  
   ___
   Mailing list: https://launchpad.net/~kicad-developers
   Post to : kicad-developers@lists.launchpad.net
   Unsubscribe : https://launchpad.net/~kicad-developers
   More help   : https://help.launchpad.net/ListHelp
  
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] SIGFPE in pad properties using GAL module editor

[Andrew Zonenberg]

Interesting. I'll add a divide-by-zero check to the line that it died on
and see if that fixes the problem. Will send a patch if it works.

On Sun, 2014-07-27 at 20:32 +0200, Nick Østergaard wrote:
 Tried it with your exact settings, no difference. I do see that the
 preview vanishes when I enter zero in that field, and will not refresh
 even if I write a non-zero value -- untill I accpet the settings and
 open the properties again. But my build is not a debug build, so I
 guess that the exception you get is just silenced for me.
 
 2014-07-27 20:23 GMT+02:00 Andrew Zonenberg azonenb...@drawersteak.com:
  Exact pad properties I was using if it's any help:
 
  http://i.imgur.com/DvnE9sI.png
 
  http://i.imgur.com/1f32yDz.png
 
  Fully reproducible, I can trigger it on command.
 
  On Sun, 2014-07-27 at 20:22 +0200, Nick Østergaard wrote:
  I cannot reproduce with 5018 on linux.
 
  2014-07-27 20:17 GMT+02:00 Andrew Zonenberg azonenb...@drawersteak.com:
   Steps to reproduce:
   * Open the GAL module editor
   * Add a new pad to the module
   * Highlight the size X field
   * Begin to type 0.5 or any other decimal with a leading zero
   * As soon as the 0 is entered, a SIGFPE is thrown
  
   --
   Andrew Zonenberg
   PhD student, security group
   Computer Science Department
   Rensselaer Polytechnic Institute
   http://colossus.cs.rpi.edu/~azonenberg/
  
   ___
   Mailing list: https://launchpad.net/~kicad-developers
   Post to : kicad-developers@lists.launchpad.net
   Unsubscribe : https://launchpad.net/~kicad-developers
   More help   : https://help.launchpad.net/ListHelp
  
 
  --
  Andrew Zonenberg
  PhD student, security group
  Computer Science Department
  Rensselaer Polytechnic Institute
  http://colossus.cs.rpi.edu/~azonenberg/

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] SIGFPE in pad properties using GAL module editor

[Andrew Zonenberg]

The attached patch fixes the crash but it appears that the vanishing
pads is a separate, unrelated bug.

Want me to look into that too? The crash was my main priority (my focus
right now is fixing bugs that keep me from getting my work done) but if
I get time I can investigate the disappearing pad bug too.

On Sun, 2014-07-27 at 14:36 -0400, Andrew Zonenberg wrote:
 Interesting. I'll add a divide-by-zero check to the line that it died on
 and see if that fixes the problem. Will send a patch if it works.
 
 On Sun, 2014-07-27 at 20:32 +0200, Nick Østergaard wrote:
  Tried it with your exact settings, no difference. I do see that the
  preview vanishes when I enter zero in that field, and will not refresh
  even if I write a non-zero value -- untill I accpet the settings and
  open the properties again. But my build is not a debug build, so I
  guess that the exception you get is just silenced for me.
  
  2014-07-27 20:23 GMT+02:00 Andrew Zonenberg azonenb...@drawersteak.com:
   Exact pad properties I was using if it's any help:
  
   http://i.imgur.com/DvnE9sI.png
  
   http://i.imgur.com/1f32yDz.png
  
   Fully reproducible, I can trigger it on command.
  
   On Sun, 2014-07-27 at 20:22 +0200, Nick Østergaard wrote:
   I cannot reproduce with 5018 on linux.
  
   2014-07-27 20:17 GMT+02:00 Andrew Zonenberg azonenb...@drawersteak.com:
Steps to reproduce:
* Open the GAL module editor
* Add a new pad to the module
* Highlight the size X field
* Begin to type 0.5 or any other decimal with a leading zero
* As soon as the 0 is entered, a SIGFPE is thrown
   
--
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/
   
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp
   
  
   --
   Andrew Zonenberg
   PhD student, security group
   Computer Science Department
   Rensselaer Polytechnic Institute
   http://colossus.cs.rpi.edu/~azonenberg/
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/
=== modified file 'pcbnew/class_pad.cpp'
--- pcbnew/class_pad.cpp	2014-07-09 12:01:06 +
+++ pcbnew/class_pad.cpp	2014-07-27 18:52:30 +
@@ -965,6 +965,11 @@
 // Netnames will be shown only if zoom is appropriate
 if( IsNetnameLayer( aLayer ) )
 {
+// Pad sizes can be zero briefly when someone is typing a number like 0.5 in the pad properties dialog.
+// Fail gracefully if this happens.
+if( (m_Size.x == 0)  (m_Size.y == 0) )
+return UINT_MAX;
+
 return ( 1 / std::max( m_Size.x, m_Size.y ) );
 }
 



signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Push-and-shove router issues with blind vias [PATCH]

[Andrew Zonenberg]

Updated patch attached.

Fixes the following two bugs in the PNS router:
1) Shoved micro/blind/buried vias are silently converted to normal vias
2) Collision detection avoids micro/blind/buried vias regardless of
whether they cross the layer that the current track is on

Known bugs not addressed by this patch:
3) The insert blind via key does nothing in GAL mode

This patch is functionally equivalent to my previously submitted
microvia-shove-v2.patch but fixes a few code-formatting issues.

On Tue, 2014-07-22 at 14:28 -0400, Andrew Zonenberg wrote:
 See attached patch. Should fully support both blind/buried and micro
 vias.
 
 Are you saying you're going to add support for the insert blind via
 and insert microvia keys in the interactive router? That would be
 awesome :D
 
 Also GAL currently doesn't seem to make any visual distinction between
 standard, micro, and blind vias. Maybe this can be fixed too?
 
 On Tue, 2014-07-22 at 20:17 +0200, Tomasz Wlostowski wrote:
  On 22.07.2014 20:12, Andrew Zonenberg wrote:
   The current code in the repo would silently convert all vias to standard
   through-hole vias, my code makes it behave properly for blind/buried
   vias. With some additional modifications it could support microvias too
   but I haven't implemented that.
  
  
  Hi Andrew,
  
  You could add the type of the via taken from Kicad's model to PNS_VIA 
  and update syncVia/commitRouting accordingly. I'll do the menus/shortcuts.
  
  Tom.
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/
=== modified file 'pcbnew/router/pns_router.cpp'
--- pcbnew/router/pns_router.cpp	2014-07-09 14:57:01 +
+++ pcbnew/router/pns_router.cpp	2014-07-24 14:55:12 +
@@ -227,12 +227,15 @@
 
 PNS_ITEM* PNS_ROUTER::syncVia( VIA* aVia )
 {
+LAYER_ID top, bottom;
+aVia-LayerPair(top, bottom);
 PNS_VIA* v = new PNS_VIA(
 aVia-GetPosition(),
-PNS_LAYERSET( 0, MAX_CU_LAYERS - 1 ),
+PNS_LAYERSET( top, bottom ),
 aVia-GetWidth(),
 aVia-GetDrillValue(),
-aVia-GetNetCode() );
+aVia-GetNetCode(),
+aVia-GetViaType() );
 
 v-SetParent( aVia );
 
@@ -759,8 +762,9 @@
 via_board-SetWidth( via-Diameter() );
 via_board-SetDrill( via-Drill() );
 via_board-SetNetCode( via-Net() );
-via_board-SetLayerPair( ToLAYER_ID( m_settings.GetLayerTop() ),
- ToLAYER_ID( m_settings.GetLayerBottom() ) );
+via_board-SetLayerPair( ToLAYER_ID( via-Layers().Start() ),
+ ToLAYER_ID( via-Layers().End() ) );
+via_board-SetViaType(via-ViaType());
 newBI = via_board;
 break;
 }

=== modified file 'pcbnew/router/pns_via.cpp'
--- pcbnew/router/pns_via.cpp	2014-05-16 11:37:31 +
+++ pcbnew/router/pns_via.cpp	2014-07-24 14:43:42 +
@@ -91,6 +91,7 @@
 v-m_shape = SHAPE_CIRCLE( m_pos, m_diameter / 2 );
 v-m_rank = m_rank;
 v-m_marker = m_marker;
+v-m_viaType = m_viaType;
 
 return v;
 }

=== modified file 'pcbnew/router/pns_via.h'
--- pcbnew/router/pns_via.h	2014-05-29 11:48:14 +
+++ pcbnew/router/pns_via.h	2014-07-24 14:46:14 +
@@ -24,6 +24,8 @@
 #include geometry/shape_line_chain.h
 #include geometry/shape_circle.h
 
+#include ../class_track.h
+
 #include pns_item.h
 
 class PNS_NODE;
@@ -36,7 +38,7 @@
 {}
 
 PNS_VIA( const VECTOR2I aPos, const PNS_LAYERSET aLayers,
- int aDiameter, int aDrill, int aNet = -1 ) :
+ int aDiameter, int aDrill, int aNet = -1, VIATYPE_T aViaType = VIA_THROUGH ) :
 PNS_ITEM( VIA )
 {
 SetNet( aNet );
@@ -45,6 +47,7 @@
 m_diameter = aDiameter;
 m_drill = aDrill;
 m_shape = SHAPE_CIRCLE( aPos, aDiameter / 2 );
+m_viaType = aViaType;
 }
 
 
@@ -60,6 +63,7 @@
 m_rank = aB.m_rank;
 m_owner = aB.m_owner;
 m_drill = aB.m_drill;
+m_viaType = aB.m_viaType;
 }
 
 const VECTOR2I Pos() const
@@ -72,6 +76,16 @@
 m_pos = aPos;
 m_shape.SetCenter( aPos );
 }
+
+VIATYPE_T ViaType() const
+{
+		return m_viaType;
+	}
+	
+	void SetViaType(VIATYPE_T aViaType)
+	{
+		m_viaType = aViaType;
+	}
 
 int Diameter() const
 {
@@ -124,6 +138,7 @@
 int m_drill;
 VECTOR2I m_pos;
 SHAPE_CIRCLE m_shape;
+VIATYPE_T m_viaType;
 };
 
 #endif



signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post

[Kicad-developers] Push-and-shove router issues with blind vias

[Andrew Zonenberg]

I've found three problems so far:

1) Pressing the insert blind via key when using the push-and-shove
router does not actually add a blind via.

2) In both avoid and shove mode, the router treats blind vias as
through-board vias and will move or avoid them even if there's no real
collision (for example, routing a layer 4 trace under a blind layer 1-2
via doesn't work). I've been mitigating this by drawing the portion of
the track that goes under a blind via by hand, but all of the mode
switching is awkward.

3) When a blind via is moved by the router in shove mode, it is
converted to a through-board via.


4) Somewhat unrelated, but pressing home in the GAL view to
zoom-to-fit moves the view to the grid origin with extremely high zoom
(all I can see is the dark-red page outline, and the line fills almost
the entire screen).

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Push-and-shove router issues with blind vias

[Andrew Zonenberg]

I've already fixed item 2 in a pending patch (three-line change to
PNS_ROUTER::syncVia, works experimentally but not heavily tested).

With any luck there will be a fix for 3 soon as well. 1 will be more
work and I'm not sure I have time to patch that right now.

On Tue, 2014-07-22 at 17:37 +0200, Tomasz Wlostowski wrote:
 On 22.07.2014 17:32, Andrew Zonenberg wrote:
  I've found three problems so far:
 
  1) Pressing the insert blind via key when using the push-and-shove
  router does not actually add a blind via.
 
  2) In both avoid and shove mode, the router treats blind vias as
  through-board vias and will move or avoid them even if there's no real
  collision (for example, routing a layer 4 trace under a blind layer 1-2
  via doesn't work). I've been mitigating this by drawing the portion of
  the track that goes under a blind via by hand, but all of the mode
  switching is awkward.
 
  3) When a blind via is moved by the router in shove mode, it is
  converted to a through-board via.
 
 Hi Andrew,
 
 There's no support yet for blind/buried vias in the PS. We may add it 
 in the near future.
 
 Regards,
 Tom
 

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Push-and-shove router issues with blind vias

[Andrew Zonenberg]

With the attached patch, the router fully supports both routing
over/under blind/buried vias and shoving them, but cannot yet add new
blind vias.

The current code cannot distinguish between blind vias and microvias. It
uses a simple heuristic: if a via goes from the top to the bottom it
must be a through-board via, otherwise blind/buried. This means that
when a microvia is shoved, it's silently converted to a regular blind
via.

This may be the time for a discussion of why microvias are considered
special compared to normal blind vias. I'm working on a board now that
uses layer 1-2 and 1-3 microvias. These are implemented at the fab by
drilling from layer 2-3 anywhere that a layer 1-3 via is needed, then
laminating layer 1 and drilling from 1-2 anywhere that either 1-2 or 1-3
vias are used.

In other words, real microvias (when using a stacked process) can go to
layers other than 2 and N-1. If this is the only distinction between
microvias and blind vias in KiCAD, I propose eliminating the microvia
entity entirely. There could perhaps be a DRC mode to only allow blind
vias between specific layer pairs if you're targeting a process with a
limited number of microvia layers.

On Tue, 2014-07-22 at 12:16 -0400, Andrew Zonenberg wrote:
 I've already fixed item 2 in a pending patch (three-line change to
 PNS_ROUTER::syncVia, works experimentally but not heavily tested).
 
 With any luck there will be a fix for 3 soon as well. 1 will be more
 work and I'm not sure I have time to patch that right now.
 
 On Tue, 2014-07-22 at 17:37 +0200, Tomasz Wlostowski wrote:
  On 22.07.2014 17:32, Andrew Zonenberg wrote:
   I've found three problems so far:
  
   1) Pressing the insert blind via key when using the push-and-shove
   router does not actually add a blind via.
  
   2) In both avoid and shove mode, the router treats blind vias as
   through-board vias and will move or avoid them even if there's no real
   collision (for example, routing a layer 4 trace under a blind layer 1-2
   via doesn't work). I've been mitigating this by drawing the portion of
   the track that goes under a blind via by hand, but all of the mode
   switching is awkward.
  
   3) When a blind via is moved by the router in shove mode, it is
   converted to a through-board via.
  
  Hi Andrew,
  
  There's no support yet for blind/buried vias in the PS. We may add it 
  in the near future.
  
  Regards,
  Tom
  
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/
=== modified file 'pcbnew/router/pns_router.cpp'
--- pcbnew/router/pns_router.cpp	2014-07-09 14:57:01 +
+++ pcbnew/router/pns_router.cpp	2014-07-22 16:40:01 +
@@ -227,9 +227,12 @@
 
 PNS_ITEM* PNS_ROUTER::syncVia( VIA* aVia )
 {
+	LAYER_ID top, bottom;
+	aVia-LayerPair(top, bottom);
+
 PNS_VIA* v = new PNS_VIA(
 aVia-GetPosition(),
-PNS_LAYERSET( 0, MAX_CU_LAYERS - 1 ),
+PNS_LAYERSET( top, bottom),
 aVia-GetWidth(),
 aVia-GetDrillValue(),
 aVia-GetNetCode() );
@@ -759,8 +762,23 @@
 via_board-SetWidth( via-Diameter() );
 via_board-SetDrill( via-Drill() );
 via_board-SetNetCode( via-Net() );
-via_board-SetLayerPair( ToLAYER_ID( m_settings.GetLayerTop() ),
- ToLAYER_ID( m_settings.GetLayerBottom() ) );
+via_board-SetLayerPair( ToLAYER_ID( via-Layers().Start() ),
+ ToLAYER_ID( via-Layers().End() ) );
+ 
+//If we're on all layers of the board, we must be a through via
+if( (via-Layers().Start() == m_settings.GetLayerTop()) 
+(via-Layers().End() == m_settings.GetLayerBottom())
+)
+			{
+via_board-SetViaType(VIA_THROUGH);
+			}
+			
+			//Otherwise we're a blind/buried via or microvia.
+//There's no way to tell without adding extra fields to the PNS_VIA class so for now, guess blind/buried.
+//Note that shoved microvias will be converted silently to blind/buried vias of the same size until fixed.
+			else
+via_board-SetViaType(VIA_BLIND_BURIED);
+
 newBI = via_board;
 break;
 }



signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Push-and-shove router issues with blind vias

[Andrew Zonenberg]

The current code in the repo would silently convert all vias to standard
through-hole vias, my code makes it behave properly for blind/buried
vias. With some additional modifications it could support microvias too
but I haven't implemented that.

Are you saying you don't think this patch should be accepted until it
also supports microvias?

On Tue, 2014-07-22 at 20:06 +0200, jp charras wrote:
 Le 22/07/2014 18:47, Andrew Zonenberg a écrit :
  With the attached patch, the router fully supports both routing 
  over/under blind/buried vias and shoving them, but cannot yet add 
  new blind vias.
  
  The current code cannot distinguish between blind vias and 
  microvias. It uses a simple heuristic: if a via goes from the top 
  to the bottom it must be a through-board via, otherwise 
  blind/buried. This means that when a microvia is shoved, it's 
  silently converted to a regular blind via.
 
 it's silently converted to a regular blind via.
 This is not a good idea. Why to convert them?
 I do not understand the reason.
 
  
  This may be the time for a discussion of why microvias are 
  considered special compared to normal blind vias. I'm working on 
  a board now that uses layer 1-2 and 1-3 microvias. These are 
  implemented at the fab by drilling from layer 2-3 anywhere that a 
  layer 1-3 via is needed, then laminating layer 1 and drilling from 
  1-2 anywhere that either 1-2 or 1-3 vias are used.
  
  In other words, real microvias (when using a stacked process) can 
  go to layers other than 2 and N-1. If this is the only distinction 
  between microvias and blind vias in KiCAD, I propose eliminating 
  the microvia entity entirely. There could perhaps be a DRC mode to 
  only allow blind vias between specific layer pairs if you're 
  targeting a process with a limited number of microvia layers.
 
 Eliminating the micro vias is perhaps not a good idea.
 
 I agree the fact a micro via is a blind/buried via, just with
 constraints on layers count.
 
 Micro vias are laser drilled and the hole has a limited depth.
 (this is not the case for blind/buried vias which are not laser drilled)
 
 Most of time they are used to connect a footprint like a bga therefore
 an external copper layer to the next internal layer.
 
 Having a special type for this kind of via is an easy way to handle
 layers count constraints and make placing very small vias more easy.
 
 It also allows to easy place 3 different vias: through, blind and very
 small (said microvias, with constraints) vias.
 
 If you are thinking eliminating the micro vias is a good idea, I
 suggest you first to write an user documentation about usage of vias,
 blind vias with no constraints and vias with constraints.
 
 In Kicad, micro vias (only allowed from an external layer to the first
 internal layer) is just a convenient way to place very small vias,
 which are expected laser drilled, i.e. which have a limited depth.
 
 However you easily can add a DRC test on vias which have a limited
 depth, depending on the drill hole, and use only blind/buried vias.
 

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Push-and-shove router issues with blind vias

[Andrew Zonenberg]

See attached patch. Should fully support both blind/buried and micro
vias.

Are you saying you're going to add support for the insert blind via
and insert microvia keys in the interactive router? That would be
awesome :D

Also GAL currently doesn't seem to make any visual distinction between
standard, micro, and blind vias. Maybe this can be fixed too?

On Tue, 2014-07-22 at 20:17 +0200, Tomasz Wlostowski wrote:
 On 22.07.2014 20:12, Andrew Zonenberg wrote:
  The current code in the repo would silently convert all vias to standard
  through-hole vias, my code makes it behave properly for blind/buried
  vias. With some additional modifications it could support microvias too
  but I haven't implemented that.
 
 
 Hi Andrew,
 
 You could add the type of the via taken from Kicad's model to PNS_VIA 
 and update syncVia/commitRouting accordingly. I'll do the menus/shortcuts.
 
 Tom.

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/
=== modified file 'pcbnew/router/pns_router.cpp'
--- pcbnew/router/pns_router.cpp	2014-07-09 14:57:01 +
+++ pcbnew/router/pns_router.cpp	2014-07-22 18:24:03 +
@@ -227,12 +227,16 @@
 
 PNS_ITEM* PNS_ROUTER::syncVia( VIA* aVia )
 {
+	LAYER_ID top, bottom;
+	aVia-LayerPair(top, bottom);
+
 PNS_VIA* v = new PNS_VIA(
 aVia-GetPosition(),
-PNS_LAYERSET( 0, MAX_CU_LAYERS - 1 ),
+PNS_LAYERSET( top, bottom),
 aVia-GetWidth(),
 aVia-GetDrillValue(),
-aVia-GetNetCode() );
+aVia-GetNetCode(),
+aVia-GetViaType() );
 
 v-SetParent( aVia );
 
@@ -759,8 +763,10 @@
 via_board-SetWidth( via-Diameter() );
 via_board-SetDrill( via-Drill() );
 via_board-SetNetCode( via-Net() );
-via_board-SetLayerPair( ToLAYER_ID( m_settings.GetLayerTop() ),
- ToLAYER_ID( m_settings.GetLayerBottom() ) );
+via_board-SetLayerPair( ToLAYER_ID( via-Layers().Start() ),
+ ToLAYER_ID( via-Layers().End() ) );
+via_board-SetViaType(via-ViaType());
+
 newBI = via_board;
 break;
 }

=== modified file 'pcbnew/router/pns_via.cpp'
--- pcbnew/router/pns_via.cpp	2014-05-16 11:37:31 +
+++ pcbnew/router/pns_via.cpp	2014-07-22 18:26:28 +
@@ -91,6 +91,7 @@
 v-m_shape = SHAPE_CIRCLE( m_pos, m_diameter / 2 );
 v-m_rank = m_rank;
 v-m_marker = m_marker;
+v-m_viaType = m_viaType;
 
 return v;
 }

=== modified file 'pcbnew/router/pns_via.h'
--- pcbnew/router/pns_via.h	2014-05-29 11:48:14 +
+++ pcbnew/router/pns_via.h	2014-07-22 18:22:04 +
@@ -24,6 +24,8 @@
 #include geometry/shape_line_chain.h
 #include geometry/shape_circle.h
 
+#include ../class_track.h
+
 #include pns_item.h
 
 class PNS_NODE;
@@ -36,7 +38,7 @@
 {}
 
 PNS_VIA( const VECTOR2I aPos, const PNS_LAYERSET aLayers,
- int aDiameter, int aDrill, int aNet = -1 ) :
+ int aDiameter, int aDrill, int aNet = -1, VIATYPE_T aViaType = VIA_THROUGH ) :
 PNS_ITEM( VIA )
 {
 SetNet( aNet );
@@ -45,6 +47,7 @@
 m_diameter = aDiameter;
 m_drill = aDrill;
 m_shape = SHAPE_CIRCLE( aPos, aDiameter / 2 );
+m_viaType = aViaType;
 }
 
 
@@ -60,6 +63,7 @@
 m_rank = aB.m_rank;
 m_owner = aB.m_owner;
 m_drill = aB.m_drill;
+m_viaType = aB.m_viaType;
 }
 
 const VECTOR2I Pos() const
@@ -83,6 +87,16 @@
 m_diameter = aDiameter;
 m_shape.SetRadius( m_diameter / 2 );
 }
+
+VIATYPE_T ViaType() const
+{
+		return m_viaType;
+	}
+	
+	void SetViaType(VIATYPE_T aViaType)
+	{
+		m_viaType = aViaType;
+	}
 
 int Drill() const
 {
@@ -124,6 +138,7 @@
 int m_drill;
 VECTOR2I m_pos;
 SHAPE_CIRCLE m_shape;
+VIATYPE_T m_viaType;
 };
 
 #endif



signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Display issue with blind/buried vias

[Andrew Zonenberg]

When viewing the board with some layers turned off, it seems logical to
only draw those vias which cross the layer(s) that are being drawn. As
of now, for example, layer 1-2 blind vias are drawn when both layers 1
and 2 are disabled.

This occurs in both GAL and legacy views.

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Display issue with blind/buried vias

[Andrew Zonenberg]

Proposed fix attached.

With this patch, vias are displayed if
a) via display is turned on, and
b) at least one of the layers the via crosses is displayed.

On Tue, 2014-07-22 at 18:11 -0400, Andrew Zonenberg wrote:
 When viewing the board with some layers turned off, it seems logical to
 only draw those vias which cross the layer(s) that are being drawn. As
 of now, for example, layer 1-2 blind vias are drawn when both layers 1
 and 2 are disabled.
 
 This occurs in both GAL and legacy views.
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/
=== modified file 'pcbnew/class_pcb_layer_widget.cpp'
--- pcbnew/class_pcb_layer_widget.cpp	2014-07-20 17:41:12 +
+++ pcbnew/class_pcb_layer_widget.cpp	2014-07-22 23:37:59 +
@@ -413,6 +413,7 @@
 {
 KIGFX::VIEW* view = galCanvas-GetView();
 view-SetLayerVisible( aLayer, isVisible );
+view-RecacheAllItems(true);
 }
 
 if( isFinal )

=== modified file 'pcbnew/class_track.cpp'
--- pcbnew/class_track.cpp	2014-06-30 05:46:18 +
+++ pcbnew/class_track.cpp	2014-07-22 22:56:28 +
@@ -786,6 +786,16 @@
 if( brd-IsElementVisible( PCB_VISIBLE(VIAS_VISIBLE + GetViaType()) ) == false
  ( color  HIGHLIGHT_FLAG ) != HIGHLIGHT_FLAG )
 return;
+
+// Only draw the via if at least one of the layers it crosses is being displayed
+bool hit = false;
+for(LAYER_NUM layer = m_Layer; layer = m_BottomLayer; layer ++)
+{
+		if(brd-IsLayerVisible((LAYER_ID)layer) == true)
+			hit = true;
+	}
+	if(!hit)
+		return;
 
 if( DisplayOpt.ContrastModeDisplay )
 {

=== modified file 'pcbnew/pcb_painter.cpp'
--- pcbnew/pcb_painter.cpp	2014-07-21 10:54:58 +
+++ pcbnew/pcb_painter.cpp	2014-07-22 23:39:11 +
@@ -335,6 +335,19 @@
 {
 VECTOR2D center( aVia-GetStart() );
 double   radius;
+
+// Only draw the via if at least one of the layers it crosses is being displayed
+BOARD * brd =  aVia-GetBoard( );
+bool hit = false;
+LAYER_ID top, bottom;
+aVia-LayerPair(top, bottom);
+for(LAYER_NUM layer = top; layer = bottom; layer ++)
+{
+		if(brd-IsLayerVisible((LAYER_ID)layer) == true)
+			hit = true;
+	}
+	if(!hit)
+		return;
 
 // Choose drawing settings depending on if we are drawing via's pad or hole
 if( aLayer == ITEM_GAL_LAYER( VIA_THROUGH_VISIBLE ) )



signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 3D view in module editor doesn't update properly when using GAL

[Andrew Zonenberg]

Is there any technical reason why the updates can't be live, or
triggered upon changing focus to the window? I'm pretty sure that
previous versions did this.

On Sun, 2014-07-20 at 23:01 -0700, Cirilo Bernardo wrote:
 - Original Message -
 
  From: Andrew Zonenberg azonenb...@drawersteak.com
  To: kicad-developers@lists.launchpad.net
  Cc: 
  Sent: Monday, July 21, 2014 10:04 AM
  Subject: [Kicad-developers] 3D view in module editor doesn't update 
  properlywhen using GAL
  
  When I'm using the GAL view in the module editor (OpenGL) and open a 3D
  view, and make changes to the footprint (for example, adding a 3D model
  to it) the 3D render doesn't update.
  
  I can rotate and pan the view, it's definitely re-rendering new frames
  fine, but the changes to the footprint don't take effect. Even turning
  the grid on or off, or enabling/disabling realistic mode, doesn't work
  until I close and reopen the 3D view.
  
  The 3D view behaves sort of as expected (redrawing and applying changes
  any time I click to pan or otherwise force a repaint) when using the old
  renderer in the module editor. Maybe some kind of display list updating
  issues? I'm using a dual-monitor setup with the 3D view on the left
  screen and the module editor on the right.
  
 
 
 After making changes you need to click the Reload Board icon; currently
 this is an icon with a DIP and a green arrow pointing down. At the moment
 I don't believe this behavior is a bug.
 
 - Cirilo
 

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Color of PCB substrate in realistic mode

[Andrew Zonenberg]

Right now the bare FR4 substrate is drawn in the same color as the
soldermask so trying to see details of soldermask cutouts (for example,
when designing a fiducial or PCB antenna that needs mask clearance
around it) is difficult. Does anyone else find this hard to see?

It should probably be displayed in some kind of yellow/tan/brown color
as that's what actual un-masked FR4 looks like (for example, around the
fiducials in
http://upload.wikimedia.org/wikipedia/commons/9/90/Front_of_Raspberry_Pi.jpg)

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp