| ID: | 5673 |
| From: | rn...@igor2.repo.hu |
| Date: | Tue, 24 May 2022 08:02:59 +0200 (CEST) |
| Subject: | [pcb-rnd] Re: gschem/lepton: gafrc security issue |
On Tue, 24 May 2022, Dan McMahill (dan@mcmahill.net) wrote: (on geda-user@delorie.com, where I am not subscribed, so I can't answer there, but this thread started on the pcb-rnd mailing list.) > Regarding configurable menus and other extensions, a vision I had and started > on some of the infrastructure for ages ago was to be able to support "modes" in > gschem sort of like how emacs has major modes for editing different sorts of > files (C, python, LaTeX, Makefile, etc). Maybe you're using gschem to drive a > spice simulation, so enter spice simulation mode and get menus that are > appropriate for the simulator you have. Maybe it is for driving a pcb layout > and you get those sorts of menus. Unfortunately other commitments in life took > over and I never really got it to the point I wanted. I'm guessing some of > that code is still in place though. Thanks for the clarification! I can totally understand that, especially in the context of "using the same sheet for spice and pcb". I simply refuse to accept the seemingly widespread concept that one has to do simulation separately and then manually copy relevant parts to another sheet for the PCB workflow. That's not automation, that's just "office suite with copy&paste workflows". So I too want to get this basic concept working, drawing one schematics and easily switching between backends/targets/views. The good news is: we have something like what you described above, in sch-rnd (cschem) right from the start! It already works partly and by the beta release (happens before end of October this year) it will fully work. We call them views, and they have plugins to operate them. There's a combo box next to the upper status bar where you can switch which view you want to see on screen. At the moment we have PCB and raw, but later I will add spice. It's very easy to extend sch-rnd with new views for different workflows. In the cschem model this goes way deeper than GUI widgets/menus: it also affects what is displayed in the drawing area, especially things like terminal names. The most trivial/common example is: you get the final "pin numbers" for your quat (slotted) opamp symbols in the PCB view, but if you switch to the raw view you see in-, in+, out, then later if you swtich to the spice view it will display the spice pin number (which is always the same for opamp pins in every slot, similar to pinseq in gschem). If you want to see them all at once, you can use the property editor in any view. About flexibility, scripting vs. config: the plan is that end users can create new views by using user scripts to implement the necessary data filtering, in whatever scripting language they want to use. This is somewhat similar to "writing your netlist backend in gschem", but with a few major differences that makes everything simpler and safer. There are three major differences compared to gschem's approach: 1. view is not tied to a netlist backend, as it has nothing to do with file formats; in other words: how you figure the final "pin number", how you do slotting, how you do pinout mapping (where it's relevant) doesn't depend on the output netlist _file format_, so the code doing these shouldn't be in a different layer 2. sch-rnd doesn't force the user to use one particular scripting language (scheme or python) for implementing such things, the user is free to use whatever language he already knows or prefers for the task (chosen from 13 different languages at the moment) 3. relevant to this tread: full separation of config and code. View config is config and doesn't execute anything. If your project uses a custom view, it will depend on an optional plugins or user scripts, but those are implemented and distributed separately. So your sch project is all data-only, no code is executed from the sch project on load. User may need to download and install 3rd party "view engine" plugins/scripts for the specific view config to work, separately, knowing it's software addon installation, not opening data. Alternatively, without those extra view code installed, the sch project can always be looked at in the "raw" view, which means you see and can edit every aspect of the data, you just can't get sch-rnd to produce the output (netlist, view-specific display). Best regards, Igor2
Reply subtree:
5673 [pcb-rnd] Re: gschem/lepton: gafrc security issue from rn...@igor2.repo.hu