| ID: | 559 |
| From: | miloh <fr...@gmail.com> |
| Date: | Thu, 16 Mar 2017 13:40:34 -0700 |
| Subject: | Re: [pcb-rnd] [dev] API fixup - trends |
| in-reply-to: | 554 from ge...@igor2.repo.hu |
| replies: | 560 from ge...@igor2.repo.hu |
On Thu, Mar 16, 2017 at 3:07 AM, <gedau@igor2.repo.hu> wrote: > Hi fellow pcb-rnd developers and cotributors, > > after fixing the "load schematics to buffer" bug, I relized it's probably > the best time to do the minor API cleanup in the layer group code. I'm > writing about this because it'll be a trend in later cleanups and new code > should consider this too. > > The original PCB code we inherited uses a global variable called PCB to hold > the current board. It also has some other random global variables for local > features. This is generally okay, we edit one board at a time. > > However, there are a lot of ugly workarounds in some of the code because of > this. The common pattern is: > > 1. some code once written for manipulating the One Central PCB we have > > 2. later someone figured we need to temporarily work on another PCB struct > > 3. this resulted in workarounds that try to save the global states (the PCB > variable and potentially other global variables), create a new global state, > run the code in question and finally restore the old state. > > This is too easy to break. It's too easy to forget to save and restore, > especially if a function we call calls another which then calls another and > the side effect of changing a global state happens a few calls deep. > > The solution is rather simple: > > - library call should not depend on global states, but should get all > states as arguments; this probably includes everything from I/O through > polygons to utility functions like the layer code > > - the generic, main code, and UI code could still use the global vars, as > we run only one instance and we don't ever need to temporary swap things > there > > - if there are other board specific global variables, like the ones in > rats.c, we should consider moving them in the PCB struct. > > > I don't say we should start now and do this all immediately. I think I will > be doing it in the background. The reason I wrote this mail is to let you > know you will see more calls needing a PCB passed as first argument, and > that if you write new library code and you are writing "PCB" in it, you > should consider getting a pcb_board_t *pcb as first argument instead. > > Best regards, > > Igor2 > > > Thanks for the detail Igor2, it's helpful for me as I'm not familiar with the underlying architecture of pcb/pcb-rnd or of big programs in general, but I am interested to learn more. So it's always exciting to hear this news. The Rhinoceros drafting CAD (not free libre software, only used a windows version) only opens one design at a time. I'm not sure of the official Rhinoceros workflow for importing designs from one draft canvas into another (it's likely to use the 'import' command), but a common method I see is for users to open _two_ copies of 'Rhino' and use cut and paste actions between the two. Yes, afaict, Rhino cannot open more than one design file at a time. I've wondered if this is an intentional UI choice or a development issue.. Also, it looks like subcircuits are more of a future possibility after this redevelopment? regards, r. miloh alexander
Reply subtree:
559 Re: [pcb-rnd] [dev] API fixup - trends from miloh <fr...@gmail.com>
560 Re: [pcb-rnd] [dev] API fixup - trends from ge...@igor2.repo.hu