Re: gEDA-user: multiple attributes
al davis ad...@freeelectron.net writes: How about prefixing simulation attributes with a dot. No, please, use a proper namespace prefix, like spice- verilog- sim- spice: verilog: sim: Backend namespaces, use namespaces, with fallbacks into legacy and global namespaces. spice-value= sim-value= value= -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On Monday 17 January 2011 08:01:53 ge...@igor2.repo.hu wrote: On Mon, Jan 17, 2011 at 08:22:02AM +0100, Stephan Boettcher wrote: ge...@igor2.repo.hu writes: If you edit one object, that won't ever move other objects around by side effect. VCS systems I know depend on this feature. I think PCB already provides this feature, keeping order of objects, Not really. When you edit a line, it somehow gets thrown into an entirely different slot in the list. Like if there is a vector of allocated slots, some marked unused, and when something is changed, it is thrown into the first unused slot. Probably some feature of some glib(?) container class? It's not too bad for vcs diffs, but could be a little better. Not worth the trouble to fix this, I guess. Hmm, maybe I mix it with something then. I recall some efforts, maybe by Peter to get this fixed in PCB or in gschem. Or else my memory just fails. Due to the way the gschem editing model works, and particularly the undo system, stuff tends to get shifted to the end of the file when edited. This is something that I've made a few improvements to in the past, but fundamentally the problem hasn't gone away. This is actually an extremely difficult problem to solve. Saving a file could be considered as mapping a three-dimensional space (x position, y position, z-index) onto a one-dimensional space (file position). At the moment, the file position is mapped 1:1 to z-index, i.e. last-on-top. Other possibilities (assuming that an alternative way of indicating z- ordering can be found) include defining a Hilbert-Peano curve on the x-y schematic plane and mapping position along that curve to file position. There is no easy fix here. Peter -- Peter Brett pe...@peter-b.co.uk Remote Sensing Research Group Surrey Space Centre signature.asc Description: This is a digitally signed message part. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: How to set the margin for printing?
On Monday 17 January 2011 02:07:32 Kai-Martin Knaak wrote: Hi. The print dialog of gschem offers Extents with margins by default. This margin is larger than necessary or my printer. But no margin is too little. Is there a way to set the size of the margin? I couldn't find margin in system-gschemrc. Unfortunately, your current best bet is to export with no margins and then use a tool which can talk CUPS to shrink to the correct printer extents. As usual, I have a remarkable branch which makes gschem do this automagically, but it's nowhere near a usable state yet (i.e. there are many regressions and you *will* lose work if you use it). Peter -- Peter Brett pe...@peter-b.co.uk Remote Sensing Research Group Surrey Space Centre signature.asc Description: This is a digitally signed message part. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
On Jan 17, 2011, at 5:10 PM, Stephan Boettcher wrote: al davis ad...@freeelectron.net writes: How about prefixing simulation attributes with a dot. No, please, use a proper namespace prefix, like spice- verilog- sim- spice: verilog: sim: Backend namespaces, use namespaces, with fallbacks into legacy and global namespaces. spice-value= sim-value= value= Agreed. In most cases, the user is going to want attributes like value= to be common to all flows. It would be good, though, to create a common convention for units in this case. I'm unhappy with tuning gschem/gnetlist to be especially friendly to any specific downstream flow. Al's favorite downstream tool is apparently Verilog, so that seems to be what he wants to target, with every other flow having to adapt. While it is good to have completely generic symbols as a goal, in practice users will need escape hatches to allow more control. So, for example, it is important to have the possibility of SPICE-specific attributes for cases where the SPICE netlister's assumptions turn out to be wrong. Given SPICE's irregularity and multiple incompatible dialects, this is inevitable. --- John Doty Noqsi Aerospace, Ltd. This message contains technical discussion involving difficult issues. No personal disrespect or malice is intended. If you perceive such, your perception is simply wrong. I'm a busy person, and in my business go along to get along causes mission failures and sometimes kills people, so I tend to be a bit blunt. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On Jan 17, 2011, at 5:41 PM, Peter TB Brett wrote: Due to the way the gschem editing model works, and particularly the undo system, stuff tends to get shifted to the end of the file when edited. This is something that I've made a few improvements to in the past, but fundamentally the problem hasn't gone away. This is actually an extremely difficult problem to solve. Saving a file could be considered as mapping a three-dimensional space (x position, y position, z-index) onto a one-dimensional space (file position). At the moment, the file position is mapped 1:1 to z-index, i.e. last-on-top. Other possibilities (assuming that an alternative way of indicating z- ordering can be found) include defining a Hilbert-Peano curve on the x-y schematic plane and mapping position along that curve to file position. There is no easy fix here. When it comes to gschem files, I believe there is a potentially useful compromise. The .sch file structure describes a tree. At each level in this tree the order of the branches does not matter. So, a canonical ordering of a .sch file just requires some sorting criterion. Sort the branches at each level to achieve canonical ordering. Small changes won't scramble the canonical representation much. Canonicalizing .sch files would be easy in our lambda-geda framework. Is there any interest? --- John Doty Noqsi Aerospace, Ltd. This message contains technical discussion involving difficult issues. No personal disrespect or malice is intended. If you perceive such, your perception is simply wrong. I'm a busy person, and in my business go along to get along causes mission failures and sometimes kills people, so I tend to be a bit blunt. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: .sch primitive ordering [was: Collaborative Development of Boards]
On Monday 17 Jan 2011 08:58:18 John Doty wrote: On Jan 17, 2011, at 5:41 PM, Peter TB Brett wrote: Due to the way the gschem editing model works, and particularly the undo system, stuff tends to get shifted to the end of the file when edited. This is something that I've made a few improvements to in the past, but fundamentally the problem hasn't gone away. This is actually an extremely difficult problem to solve. Saving a file could be considered as mapping a three-dimensional space (x position, y position, z-index) onto a one-dimensional space (file position). At the moment, the file position is mapped 1:1 to z-index, i.e. last-on-top. Other possibilities (assuming that an alternative way of indicating z- ordering can be found) include defining a Hilbert-Peano curve on the x-y schematic plane and mapping position along that curve to file position. There is no easy fix here. When it comes to gschem files, I believe there is a potentially useful compromise. The .sch file structure describes a tree. No. The very shallow, wide nature of a .sch file's (at most, if symbols are embedded) two level structure means that it's much more meaningful to consider it as a list. At each level in this tree the order of the branches does not matter. No. It does matter; the ordering indicates the draw order of primitives in any viewer or graphics exporter. Arguably, it shouldn't, but if not, the file format needs to be amended to provide this information in another way. So, a canonical ordering of a .sch file just requires some sorting criterion. Correct. I suggested one in my previous e-mail. Peter -- Peter Brett pe...@peter-b.co.uk Remote Sensing Research Group Surrey Space Centre ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: How to set the margin for printing?
Peter TB Brett wrote: Unfortunately, your current best bet is to export with no margins and then use a tool which can talk CUPS to shrink to the correct printer extents. I filed a feature request on launchpad. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: .sch primitive ordering [was: Collaborative Development of Boards]
On Jan 17, 2011, at 7:26 PM, Peter TB Brett wrote: On Monday 17 Jan 2011 08:58:18 John Doty wrote: On Jan 17, 2011, at 5:41 PM, Peter TB Brett wrote: Due to the way the gschem editing model works, and particularly the undo system, stuff tends to get shifted to the end of the file when edited. This is something that I've made a few improvements to in the past, but fundamentally the problem hasn't gone away. This is actually an extremely difficult problem to solve. Saving a file could be considered as mapping a three-dimensional space (x position, y position, z-index) onto a one-dimensional space (file position). At the moment, the file position is mapped 1:1 to z-index, i.e. last-on-top. Other possibilities (assuming that an alternative way of indicating z- ordering can be found) include defining a Hilbert-Peano curve on the x-y schematic plane and mapping position along that curve to file position. There is no easy fix here. When it comes to gschem files, I believe there is a potentially useful compromise. The .sch file structure describes a tree. No. The very shallow, wide nature of a .sch file's (at most, if symbols are embedded) two level structure means that it's much more meaningful to consider it as a list. It's two levels without embedded symbols (objects, attached attributes). In any case, the sorting must happen separately at each level. At each level in this tree the order of the branches does not matter. No. It does matter; the ordering indicates the draw order of primitives in any viewer or graphics exporter. Arguably, it shouldn't, but if not, the file format needs to be amended to provide this information in another way. But the draw order doesn't matter unless you're using an old-fashioned mechanical plotter. In any case, in gschem, merely cutting something and pasting it back in the same place changes the order, but this is rarely significant. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: .sch primitive ordering [was: Collaborative Development of Boards]
On Mon, Jan 17, 2011 at 10:26:58AM +, Peter TB Brett wrote: On Monday 17 Jan 2011 08:58:18 John Doty wrote: On Jan 17, 2011, at 5:41 PM, Peter TB Brett wrote: Due to the way the gschem editing model works, and particularly the undo system, stuff tends to get shifted to the end of the file when edited. This is something that I've made a few improvements to in the past, but fundamentally the problem hasn't gone away. This is actually an extremely difficult problem to solve. Saving a file could be considered as mapping a three-dimensional space (x position, y position, z-index) onto a one-dimensional space (file position). At the moment, the file position is mapped 1:1 to z-index, i.e. last-on-top. Other possibilities (assuming that an alternative way of indicating z- ordering can be found) include defining a Hilbert-Peano curve on the x-y schematic plane and mapping position along that curve to file position. There is no easy fix here. When it comes to gschem files, I believe there is a potentially useful compromise. The .sch file structure describes a tree. No. The very shallow, wide nature of a .sch file's (at most, if symbols are embedded) two level structure means that it's much more meaningful to consider it as a list. At each level in this tree the order of the branches does not matter. No. It does matter; the ordering indicates the draw order of primitives in any viewer or graphics exporter. Arguably, it shouldn't, but if not, the file format needs to be amended to provide this information in another way. So, a canonical ordering of a .sch file just requires some sorting criterion. Correct. I suggested one in my previous e-mail. Peter Maybe I oversimplify it, but I still suggesting having UUIDs. Long random numbers, like 256 bits, stored in hex. Whenever a new object appears, generate a new one. Whenever an object is transformed, keep the UUID. When saving, order objects numerically by UUID (within each level, if the save file is not flat). Some corner cases: - UUID wouldn't be used for anything else than keep order, so in the extreme case someone deletes something and adds something else and the new object happens to get the same UUID, that only means it will really be at the same place in the file - if two persons editing the same file and there are only a small amount of objects, both adding a new object, the probability of having the new object in between the same existing object is higher, in this case some version control systems may handle it as a conflict. With large enough files the probability is lower, and in any case, it is probably better than not having anything. - if two developers add new objects independently and they happen to get the same UUID against all reasonable odds, well, then the file will contain the same UUID twice after merge. This is a real problem, as if they both change one UUID to random on load, that will be a new conflict the next time they exchange the file. Provided UUIDs are long enough this would probably happen less freuqently than having 2 usres adding new objects to the same file ending up modifying the same section with the current solutions, if I get it right. Regards, Tibor ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: .sch primitive ordering [was: Collaborative Development of Boards]
John Doty: On Jan 17, 2011, at 7:26 PM, Peter TB Brett wrote: On Monday 17 Jan 2011 08:58:18 John Doty wrote: ... At each level in this tree the order of the branches does not matter. No. It does matter; the ordering indicates the draw order of primitives in any viewer or graphics exporter. Arguably, it shouldn't, but if not, the file format needs to be amended to provide this information in another way. But the draw order doesn't matter unless you're using an old-fashioned mechanical plotter. In any case, in gschem, merely cutting something and pasting it back in the same place changes the order, but this is rarely significant. It matters for the program diff and hence the version system. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: .sch primitive ordering [was: Collaborative Development of Boards]
Tibor: ... Maybe I oversimplify it, but I still suggesting having UUIDs. Long random numbers, like 256 bits, stored in hex. Whenever a new object appears, generate a new one. Whenever an object is transformed, keep the UUID. When saving, order objects numerically by UUID (within each level, if the save file is not flat). ... Thoose UUID might not be what a person that edit thoose files by hand wants. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: .sch primitive ordering [was: Collaborative Development of Boards]
On Monday 17 Jan 2011 11:07:16 John Doty wrote: At each level in this tree the order of the branches does not matter. No. It does matter; the ordering indicates the draw order of primitives in any viewer or graphics exporter. Arguably, it shouldn't, but if not, the file format needs to be amended to provide this information in another way. But the draw order doesn't matter unless you're using an old-fashioned mechanical plotter. In any case, in gschem, merely cutting something and pasting it back in the same place changes the order, but this is rarely significant. For someone who is very defensive of features that you see as important, you are very quick to propose that those you don't care about are removed, aren't you? Example: Create square with solid background. Create smaller circle with hashed background, set to a different colour. Move circle on top of square. Obviously, if z-order is not preserved through save and load, this will be rendered incorrectly. See attached schematic. Peter -- Peter Brett pe...@peter-b.co.uk Remote Sensing Research Group Surrey Space Centre v 20110116 2 C 4 4 0 0 0 title-B.sym B 44500 48500 1000 1000 3 0 0 0 -1 -1 1 -1 -1 -1 -1 -1 V 45000 49000 500 8 0 0 0 -1 -1 2 1 0 200 90 200 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: .sch primitive ordering [was: Collaborative Development of Boards]
On Monday 17 Jan 2011 12:17:50 Karl Hammar wrote: Tibor: ... Maybe I oversimplify it, but I still suggesting having UUIDs. Long random numbers, like 256 bits, stored in hex. Whenever a new object appears, generate a new one. Whenever an object is transformed, keep the UUID. When saving, order objects numerically by UUID (within each level, if the save file is not flat). ... Thoose UUID might not be what a person that edit thoose files by hand wants. Yes, it's often useful that the file-format makes it trivial to copy and paste bits of schematic around. I like it. Peter -- Peter Brett pe...@peter-b.co.uk Remote Sensing Research Group Surrey Space Centre ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
John, Stephan, Rick, Tibor, many thanks for your insights. I'm convinced there _has_ to be some sort of leadership when different, but technological equal design solutions appear. Am 16.01.2011 um 22:37 schrieb Rick: To be honest, I was a little turned off when I tried to read your web page and the opening didn't even tell me what you are doing! It referred me to another web site entirely... and then another... The link I gave is only one of many pages of a fascinating bigger project, so you typically find this page from higher level ones. This bigger project is about building self-replicating machines, and the circuitry shall drive their stepper motors. There are at least a dozen competing circuitries, most of them at a commercial, read-only open source level. Am 17.01.2011 um 06:28 schrieb ge...@igor2.repo.hu: While PCB isn't that bad at keeping changes to the saved file small, there's always at least the also stored file creation date letting merges fail. Yes, I agree on this one. I think storing such modification date is just the wrong thing to do. I've filed a bug for this: https://bugs.launchpad.net/pcb/+bug/703914 As I'm not aware of a use case for this data, I suggest to get rid of it entirely. If somebody has a use case, please speak up there. The other problem is diff. Again, I don't think there is anessential difference between team work and VCS in software development and in using the same methods/tools on other fields; at least we have the same methods, but some tools are partially missing. As you mentioned one of the differences is the inspection of changes, but there's another one. Track positions are more like the programmer's object data, than like source code. So they can change often, and often without the intent to change functionality of the layout. One solution would be to not store track positions at all, but always generate them with an autorouter on the fly. As long as autorouters aren't as full-featured as compilers in the software world, this isn't an option, though. Future music :-) there's never a version where the changelog says Deleted 20 unused features. Patched 300 memory leaks. No new features added. Sure there are. Actually, they're my favourite ;-) However, your point is totally valid on the other hand: these little fixes, getting the silk layer look nicer for example, does not make any sense if you will move half of the elements in the near future, for example because you don't even have a decision on the connectors yet. The point isn't about refusing cleanup, it's more about doing such cleanups and all those small changes in seperate commits. Each change in it's own commit, so it can be reviewed or cherry-picked easily. I know, the temptation to do it all in one batch is big, as all the current shortcomings are right in front of your eyes. But you loose a lot later. Probably a matter of demonstration the advantages ;-) Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: FYI [Fwd: [Balloon] Balloon 4]
On Sat, 2011-01-15 at 01:42 +0100, Kai-Martin Knaak wrote: Peter Clifton wrote: It is intended that these will be published in Altium format as that is the CAD package of choice for the design process. Why not geda in the first place? I've mentioned some reasons in other emails - I'll let people know if I find out anything concrete. However we will also explore the possibility of publishing the files for one of the Open ECAD packages such as gEDA. How would the conversion be performed? Unclear at this point. The BOHL will be modified to encompass this change and the onus will be on organisations that decide to use the Balloon 4 design to make the instantiations they create Open and available for purchase. Those who use the schematics are required to make the resulting device available for purchase? How would this be enforced? That wording did strike me as odd. If I get talking to them, I'll ask about it. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: FYI [Fwd: [Balloon] Balloon 4]
On Mon, 2011-01-17 at 08:11 +0100, Stephan Boettcher wrote: I'm lost.. who is Bob? You do not use a thread view in your mail reader, do you? Not normally, no.. and switching it on did clear things up. It looks like I completely missed Bob's email in the thread. I know who Bob Paddock is, but I thought John was talking about one of the Balloon developers. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: FYI [Fwd: [Balloon] Balloon 4]
On Sun, 2011-01-16 at 11:32 -0600, John Griessen wrote: On 01/15/2011 06:32 AM, Bob Paddock wrote: git HEAD rendering speed alone would make it prohibitive. I've been able to layout dense boards. The autorouter for digital wires after the main power is laid out doesn't need rendering I mentioned the PCB auto-router in my earlier email, but when talking about rendering speed, I was just talking about how long it takes for PCB to draw a screen-update whilst manually editing the board. You and Bob seem to have thought I was concerned about rendering speed _during_ auto-routing. You still need to look at the auto-router results, even if you don't care about the intermediate steps ;) From Bob's comments, it seems that perhaps Altium isn't as polished as I've imagined it is. There will still be momentum behind it though, due to: Tool familiarity amongst the designers The designers already bought Altium at some point Existing symbols / schematics which can be reused Production tested and optimised footprints Belief more than logic seems to be what moves people to choose proprietary over open tools. That is probably true. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On Mon, 2011-01-17 at 13:50 +0100, Markus Hitter wrote: As you mentioned one of the differences is the inspection of changes, but there's another one. Track positions are more like the programmer's object data, than like source code. So they can change often, and often without the intent to change functionality of the layout. What about extracting the _topology_ of the tracks (probably using / refactoring some code from the topological auto-router). It should not be too hard to produce a same / different output from comparing to topologies, without caring about he minutiae of every coordinate along the way. Producing a useful diff view would be harder of course. One solution would be to not store track positions at all, but always generate them with an autorouter on the fly. As long as autorouters aren't as full-featured as compilers in the software world, this isn't an option, though. Future music :-) This is an interesting idea. Auto-routing to match a particular topology would be feasible, even if a full auto-route from scratch would not be. The topological auto-router can do this. The hard part of auto-routing is generating an efficient topology to use. there's never a version where the changelog says Deleted 20 unused features. Patched 300 memory leaks. No new features added. Sure there are. Actually, they're my favourite ;-) For my money, it sounds like there should have been at least 21 commits there, if not 320. ;) Still - PCB designs are more like deployed web-software.. very linear in their development, and diverging branches don't make a lot of sense. PCBs are of course harder, as it becomes harder to partition and segregate areas of conflict so individual changes could be reverted. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
On Monday 17 January 2011, John Doty wrote: I'm unhappy with tuning gschem/gnetlist to be especially friendly to any specific downstream flow. Al's favorite downstream tool is apparently Verilog, so that seems to be what he wants to target, with every other flow having to adapt. I'm unhappy with tuning gschem/gnetlist to be especially friendly to any specific downstream flow. John's favorite downstream tool is apparently SPICE, so that seems to be what he wants to target, with every other flow having to adapt. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
On Monday 17 January 2011, Stephan Boettcher wrote: al davis ad...@freeelectron.net writes: How about prefixing simulation attributes with a dot. No, please, use a proper namespace prefix, like spice- verilog- sim- spice: verilog: sim: Backend namespaces, use namespaces, with fallbacks into legacy and global namespaces. spice-value= sim-value= value= If it was just the file, I would agree. That was my first thought. In this case, that means the schematic itself would be visually cluttered with repetitions of the namespace prefix, unless there are changes to gschem. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
On Monday 17 Jan 2011 08:10:24 Stephan Boettcher wrote: al davis ad...@freeelectron.net writes: How about prefixing simulation attributes with a dot. No, please, use a proper namespace prefix, like spice- verilog- sim- spice: verilog: sim: Backend namespaces, use namespaces, with fallbacks into legacy and global namespaces. spice-value= sim-value= value= This looks good to me, although I would suggest using a '.' as the separator, since I think it makes sense to keep '-' available as a character usable in normal attribute names. Also because being able to have a toplevel attribute: spice-sdb.fix-my-netlist-please=yes is a required feature. :-P Peter -- Peter Brett pe...@peter-b.co.uk Remote Sensing Research Group Surrey Space Centre ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On Mon, 2011-01-17 at 13:50 +0100, Markus Hitter wrote: As you mentioned one of the differences is the inspection of changes, but there's another one. Track positions are more like the programmer's object data, than like source code. So they can change often, and often without the intent to change functionality of the layout. What about extracting the _topology_ of the tracks (probably using / refactoring some code from the topological auto-router). It should not be too hard to produce a same / different output from comparing to topologies, without caring about he minutiae of every coordinate along the way. Producing a useful diff view would be harder of course. One solution would be to not store track positions at all, but always generate them with an autorouter on the fly. As long as autorouters aren't as full-featured as compilers in the software world, this isn't an option, though. Future music :-) This is an interesting idea. Auto-routing to match a particular topology would be feasible, even if a full auto-route from scratch would not be. The topological auto-router can do this. The hard part of auto-routing is generating an efficient topology to use. there's never a version where the changelog says Deleted 20 unused features. Patched 300 memory leaks. No new features added. Sure there are. Actually, they're my favourite ;-) For my money, it sounds like there should have been at least 21 commits there, if not 320. ;) Still - PCB designs are more like deployed web-software.. very linear in their development, and diverging branches don't make a lot of sense. PCBs are of course harder, as it becomes harder to partition and segregate areas of conflict so individual changes could be reverted. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
Sorry, I sent this twice. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On Mon, 2011-01-17 at 09:01 +0100, ge...@igor2.repo.hu wrote: On Mon, Jan 17, 2011 at 08:22:02AM +0100, Stephan Boettcher wrote: ge...@igor2.repo.hu writes: If you edit one object, that won't ever move other objects around by side effect. VCS systems I know depend on this feature. I think PCB already provides this feature, keeping order of objects, Not really. When you edit a line, it somehow gets thrown into an entirely different slot in the list. Like if there is a vector of allocated slots, some marked unused, and when something is changed, it is thrown into the first unused slot. Probably some feature of some glib(?) container class? It's not too bad for vcs diffs, but could be a little better. Not worth the trouble to fix this, I guess. Are you guys talking abut PCB or gschem? PCB does often re-use element memory from deleted objects, so could insert new objects mid way into a list. I'm not sure which (if any) edits cause PCB to create a new object though. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Embedded polygon
I would like to embed a polygon within a polygon keeping clearance between the inner an outer. So far I have succeeded by creating the inner shape first and then applying multiple shapes around it. I also drew box around the inner using standard trace. The intent is to create an isolated ground plane with a small trace connecting the planes. Is there a better technique that lends itself to easy adjustment? George ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On 1/17/2011 7:50 AM, Markus Hitter wrote: John, Stephan, Rick, Tibor, many thanks for your insights. I'm convinced there _has_ to be some sort of leadership when different, but technological equal design solutions appear. Am 16.01.2011 um 22:37 schrieb Rick: To be honest, I was a little turned off when I tried to read your web page and the opening didn't even tell me what you are doing! It referred me to another web site entirely... and then another... The link I gave is only one of many pages of a fascinating bigger project, so you typically find this page from higher level ones. This bigger project is about building self-replicating machines, and the circuitry shall drive their stepper motors. There are at least a dozen competing circuitries, most of them at a commercial, read-only open source level. Yes, and I have seen the project before. But it took me a couple of reads to realize what this was. Also, I had the exact same problem when I first encountered this project. I think I had to dig for ten or fifteen minutes just to figure out what the project was about. I see this problem all the time when I go to opencores.org. It seems like every project assumes you understand the purpose and goals of their little project not to mention the status. I'm only trying to say that to get more people interested, it would make sense to have your pages provide a bit more basic info so that someone reading it for the first time doesn't have to turn it into a research project just to understand what it's about. Just my two cents worth... Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
Hi John, Constructive comments below, but first I thought I'd get this out of the way.. From my point of view, you often seem to treat people here with a less respect than they deserve. I get the impression you think of the gEDA developers as being ignorant, blinkered, or incapable directing the future design and architecture of the suite. You also persist in repeating the same design choices you have chosen to make as the panacea for everyone else's work. I really hope this can stop. Your input has proved valuable on many occasions, and it would be useful for us to gain from your insight rather than develop the predilection to dismiss your emails as yet another rant from JPD. I already find myself having to skip them over for later reading, as they often disrupt a thread's natural flow. Your humorous email sign off suggests that you are aware of the problem, but not willing to adjust the courtesy of your replies. We are smart enough to understand a well reasoned design trade-off, and would likely respond better to that than yet another proclamation of why what we have suggested is wrong, or inadequate. I'll humour you with a reply below.. On Mon, 2011-01-17 at 05:31 +0900, John Doty wrote: On Jan 15, 2011, at 1:42 AM, Peter Clifton wrote: I want to see all connectivity code move into libgeda, and flattening be optional. Connectivity is precisely the kind of thing that should not be in libgeda. I (and all other gEDA developers I've talked to) disagree. The connectivity model depends on the application of the schematic. Not really, it just depends on whether we are talking about the same thing. I suspect not. I was not thinking of of assigning the data-type (for want of a better word) of nets, width, whatever. gschem can front schematic entry for various flow based or signal based topological connectivities, where nets might report block interconnections, mathematical relations, pipe-work, whatever. In all these cases, the useful output from libgeda / gschem is the topology / connectivity of the instantiated modules / symbols. The model I was assuming was that the exact topology of nets in gschem is unimportant. It is a common model, but my proposal of handling connectivity in libgeda doesn't _require_ that assumption if it is unwanted. Right now, gEDA basically only supports a topological model. This prevents it from expressing most geometric properties of the connections: parasitic inductances and resistances, high current net segments, single point grounds, etc. A related limitation that some wish to relieve is the fact that busses are mere graphical decoration. One could still wish to query libgeda for a connectivity list or graph for a given design. IMO, it is silly to pretend that nets should be treated as components with parasitic inductance or resistance. For that to be meaningful, one would have to match the topology of one's schematic to the physical layout they wished to simulate. Even with that said, the idea warms to me slightly - and I still cannot see how connectivity in libgeda conflicts with your suggestion. Granted, each junction node would have to be treated explicitly in the graph.. and nets themselves would have to become component entities in the list, rather than flattened - but it is still completely possible. In effect, you look on a view where a net in gschem becomes a two ported component with properties, a peer to other symbols representing components such as resistor, n-mos FET, etc. _Connectivity_ still exists, and libgeda could usefully contain routines to extract that. There cannot be a single correct way to address these issues because the appropriate connectivity model depends on the capabilities of other tools in the flow, not just gschem/gnetlist, as well as the needs of the project. I don't see anything which can't be handled as above. There are other places where the core code implements semantics that are useful in common cases but not universal. Gah, yes - The best example I can think of is that I'd love to get rid of slotting from the core. (Along with all the pinseq nastiness). I've taken steps to put that code at arms length from the rest of libgeda and gschem, so it is not so interwoven with the rest of the suite. I assume you won't have noticed that though, especially because the majority of the changes are in my repo.or.cz branches (it has other issues needing fixing before it can merge). Consider for a moment a dual opamp [snip] I'm familiar with the problem. Now consider hierarchy... [snip] I'm familiar with the problem. It would be very useful to have better standards for the intended meaning of the various attributes, but that won't help the problem of writing universal code to interpret them. The translation to pcb, SPICE, BOM, etc. will remain target and project dependent. Helper functions for common cases are very desirable, but they must not be wired-in to the core code. Better standards
Re: gEDA-user: FYI [Fwd: [Balloon] Balloon 4]
Hi, all. I am that person... Balloon4's design and layout is (at least partly) my baby. I'd like to do it in open tools, and for that, gEDA seems to be the only game in town. (Balloon4 is roughly credit card sized, and has a TI OMAP(3or4) SOC, Xilinx FPGA, power supplies, USB, Ethernet, camera, display interfaces - imagine a Beagle Board XM, with rather more stuff, in about half the space. There a few design challenges, other than the density - fast wide buses (DDR2/3 and others), balanced and impedance controlled USB and Ethernet lines, Gbps MIPI buses, many power domains and planes. We need to be able to manufacture it reliably, in volume, and have it pass EMC standards. We don't have funds to do many aborted runs due to DRC oopses. We don't have time to burn. The project sponsor needs working boards.) Things in gEDA's favour: It exists, it works (in that people are generating boards), it's live and under active development and use. It's free. The autorouter is alleged to work. If I can usefully get other people to collaborate on the design, they don't need expensive tools. It would be great to have Balloon designed in open tools. (I'm a happy user of plenty of other open tools, and electronic design would be fine too. I'd be happy to chip in my Altium support money...) Things in Altium's favour: Momentum. I use it day in, day out. I can get stuff done in it, quickly and correctly, including boards of this complexity. I can import TI's Beagle or Panda reference designs and work from there. No need to generate schematic parts. PCB footprint generation is speedy, and has integrated 3D models. I also have large libraries of tried tested components. (I do have a full Specctra autorouting license, but Altium's interactive router is my preferred layout scheme, on any but the most autorouter-friendly boards). From a perspective of 'just getting it done and shipped', it's (to me) clearly going to be faster in Altium. I know the tools, I know the tools can do the job, and I can import the reference design. I've seen some reasonably complex boards done in gEDA - but have no idea how long they've taken. It's possible to do PCBs in MS-Paint or by cutting tape, given sufficient time, the tools just make things faster and less error-prone. So: Given the board spec, and the constraints, would _you_ say it's sane to use gEDA for this? I'd expect it to take 5-7 weeks end to end, in Altium, from spec to gerbers (with the usual level of spec revisions, datasheet reading, component unavailability, coffee drinking - or 3-4 weeks of uninterrupted work). Or should I fire up gEDA on something smaller and less visible first? Anyone want to hold my hand while I do it? Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: FYI [Fwd: [Balloon] Balloon 4]
On Monday 17 January 2011 18:30:35 Steve Wiseman wrote: Or should I fire up gEDA on something smaller and less visible first? Anyone want to hold my hand while I do it? Smaller and less visible, first, I would say, if only so that you can get a feel for whether gEDA/pcb lacks features *required* for the B4 design before committing to it. I do think it would be really useful to let Peter C sit in with you for a few hours just watching you work with Altium, too. Not only would that be valuable from the perspective of improving gEDA, but also from the point of view of determining whether gEDA can do what you need. Cheers, Peter -- Peter Brett pe...@peter-b.co.uk Remote Sensing Research Group Surrey Space Centre signature.asc Description: This is a digitally signed message part. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
Peter Clifton wrote: What about extracting the topology of the tracks (probably using / refactoring some code from the topological auto-router). Isn't this what gnetlist does? I'd say, the netlist contains all topology but no geometry. ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On Mon, 2011-01-17 at 21:29 +0100, Kai-Martin Knaak wrote: Peter Clifton wrote: What about extracting the topology of the tracks (probably using / refactoring some code from the topological auto-router). Isn't this what gnetlist does? No - we are talking cross purposes I think. gnetlist produces a netlist from a schematic. With regards the PCB, I was thinking more of producing an output which described the _topology_ of the wiring. That is, describing relative to other wiring / obstacles, where various tracks are, but without getting into the minutiae of which XY coordinates each segment of track occupies. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: How to set the margin for printing?
On 01/17/2011 12:47 AM, Colin D Bennett wrote: It seems bad to force the drawing to be designed for a specific printer and page (thus margin in paper space units) size. It also seems bad for printers to not print all they are given, when they are given a standard page size they are advertised to print on. So that is my work around. JG ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On 01/16/2011 11:28 PM, ge...@igor2.repo.hu wrote: Some of the most hardcore ones are even do modifications using text editor on regular basis, and it is often faster than ivoking PCB for a click-around session - you have the same diff tool, and the language is the same, so you jump the same 2 level of abstrsctions. So what's the big deal the two processes still differ so much seamingly? The middle one. Non-programming EEs usually won't do the middle step, which means they won't be able to do the 2nd abstraction either. Without diff, your VCS reduces to a shared file system with backups. Thanks Tibor, Great writing about teams. I thought about this some more after sleeping last night, and what Markus is probably asking for is a position range sensitive diff or auto-merge. When people make changes in PCB that can be merged, it means they are working in different places, zones, quadrants... IOW if you could say easily *where* you were working was different and not overlapping another's work, an auto-merge would work -- if it only over-rode layout traces and footprints in the limited zone of the change made... tag for this concept: zone-diff John -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: .sch primitive ordering [was: Collaborative Development of Boards]
On Jan 17, 2011, at 9:26 PM, Peter TB Brett wrote: On Monday 17 Jan 2011 11:07:16 John Doty wrote: At each level in this tree the order of the branches does not matter. No. It does matter; the ordering indicates the draw order of primitives in any viewer or graphics exporter. Arguably, it shouldn't, but if not, the file format needs to be amended to provide this information in another way. But the draw order doesn't matter unless you're using an old-fashioned mechanical plotter. In any case, in gschem, merely cutting something and pasting it back in the same place changes the order, but this is rarely significant. For someone who is very defensive of features that you see as important, you are very quick to propose that those you don't care about are removed, aren't you? Nobody understands all use cases of the toolkit. Certainly not me. I fell into the trap here, yes. Mea culpa. Example: Create square with solid background. Create smaller circle with hashed background, set to a different colour. Move circle on top of square. Obviously, if z-order is not preserved through save and load, this will be rendered incorrectly. See attached schematic. OK, that's a good point. But there's no easy way to control this in gschem. Is it a feature, or merely accident? Should there be pull forward and push backward commands? John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
On Jan 17, 2011, at 11:22 PM, al davis wrote: On Monday 17 January 2011, John Doty wrote: I'm unhappy with tuning gschem/gnetlist to be especially friendly to any specific downstream flow. Al's favorite downstream tool is apparently Verilog, so that seems to be what he wants to target, with every other flow having to adapt. I'm unhappy with tuning gschem/gnetlist to be especially friendly to any specific downstream flow. John's favorite downstream tool is apparently SPICE, so that seems to be what he wants to target, with every other flow having to adapt. Not true. SPICE is one I use, but in the past year I've also used Mathematica, Osmond, Calay, and PADS. A great strength of gEDA is that it supports all of these, and many more. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Embedded polygon
The git/compile went fine. Using the newly built pcb gets a segfault [ggallant@firefly pcb]$ pcb phm.pcb Something strange here Segmentation fault (core dumped) Some other pcb projects were able to get loaded but their existing polygons did not display. Creating a new rectangle on the empty ground layer segfaults. System is up to date 64-bit Fedora 13. George On 01/17/2011 03:19 PM, Kai-Martin Knaak wrote: George M. Gallant, Jr. wrote: I would like to embed a polygon within a polygon keeping clearance between the inner an outer. So far I have succeeded by creating the inner shape first and then applying multiple shapes around it. (..snip..) Is there a better technique that lends itself to easy adjustment? The current development version of pcb includes a new feature polygon holes :-) See the attached screenshot. To get this version of pcb you'd have to download the current source from git and compile it locally. This page describes how to download the source from the git repository [1]http://geda.seul.org/wiki/geda:scm?s[]=git Compile is straight forward: /- git clone git://git.gpleda.org/pcb.git cd pcb ./autogen.sh ./configure --enable-toporouter-output make sudo make install \ If you do this for the first time, you most probably have to install some additional packages from your distro. When in doubt, also install the package that contains the header files, too. On debian/testing I recently needed these additional packages for pcb: autogen autopoint intltool (draws autoconf, automake and autotools-dev ) libdbus-1-dev libgtk2.0-dev (draws 15 more packagesh) x-ttcidfont-conf libgd2-xpm-dev Hope, this gets you started. ---)kaimartin(--- ___ geda-user mailing list [2]geda-user@moria.seul.org [3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. http://geda.seul.org/wiki/geda:scm?s 2. mailto:geda-user@moria.seul.org 3. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
On Jan 18, 2011, at 2:05 AM, Peter Clifton wrote: Hi John, Constructive comments below, but first I thought I'd get this out of the way.. From my point of view, you often seem to treat people here with a less respect than they deserve. I get the impression you think of the gEDA developers as being ignorant, blinkered, or incapable directing the future design and architecture of the suite. You also persist in repeating the same design choices you have chosen to make as the panacea for everyone else's work. I really hope this can stop. Your input has proved valuable on many occasions, and it would be useful for us to gain from your insight rather than develop the predilection to dismiss your emails as yet another rant from JPD. I already find myself having to skip them over for later reading, as they often disrupt a thread's natural flow. If I was thin skinned, I would be insulted by the above. Your humorous email sign off suggests that you are aware of the problem, but not willing to adjust the courtesy of your replies. Weird. You find it humorous? It's not a joke. We are smart enough to understand a well reasoned design trade-off, and would likely respond better to that than yet another proclamation of why what we have suggested is wrong, or inadequate. I'll humour you with a reply below.. On Mon, 2011-01-17 at 05:31 +0900, John Doty wrote: On Jan 15, 2011, at 1:42 AM, Peter Clifton wrote: I want to see all connectivity code move into libgeda, and flattening be optional. Connectivity is precisely the kind of thing that should not be in libgeda. I (and all other gEDA developers I've talked to) disagree. As a developer of gnetlist back ends, I am frustrated by the way the core code hides critical information. Bas Gjeltes and I developed a partial fix for one of the many problems here. Patrick and Peter B. garbled it and turned it into something that doesn't actually deliver the fix to the end user. At least now I can write a plug-in that fixes it for my flows, publish on gedasymbols, but ordinary users will still trip over it. At the same time, the API available to a gnetlist back end can often make export to printed circuit layout a breeze. This tells me that the existing API is good, but it should be helpers atop the lower level, not primitive. The connectivity model depends on the application of the schematic. Not really, it just depends on whether we are talking about the same thing. I suspect not. I was not thinking of of assigning the data-type (for want of a better word) of nets, width, whatever. Note that there's a bit of terminology confusion. gschem actually manipulates segments of nets (other tools sometimes call these wires), while net in EE theory is usually a topological whole, where the connection is assumed to be structureless. gschem can front schematic entry for various flow based or signal based topological connectivities, where nets might report block interconnections, mathematical relations, pipe-work, whatever. In all these cases, the useful output from libgeda / gschem is the topology / connectivity of the instantiated modules / symbols. Mere topological connectivity can't express the (very common) need for certain wires within a net to be short, others to be thick, others to match the length of a different wire, single-point grounds, etc. The model I was assuming was that the exact topology of nets in gschem is unimportant. It is a common model, but my proposal of handling connectivity in libgeda doesn't _require_ that assumption if it is unwanted. Right now, gEDA basically only supports a topological model. This prevents it from expressing most geometric properties of the connections: parasitic inductances and resistances, high current net segments, single point grounds, etc. A related limitation that some wish to relieve is the fact that busses are mere graphical decoration. One could still wish to query libgeda for a connectivity list or graph for a given design. You mean a graph of wire and pin connectivity corresponding to a given net? That's more primitive than a list of pins associated topologically with a net. But it still wouldn't let someone write a plug-in for bus connectivity, for example. IMO, it is silly to pretend that nets should be treated as components with parasitic inductance or resistance. For that to be meaningful, one would have to match the topology of one's schematic to the physical layout they wished to simulate. You're confusing topology with geometry. A bunch of wires connected together without loops are topologically just a lump of metal. But gschem can schematically represent geometry. And I'd like to do that. Indeed, when I draw a net whose segments have geometric constraints, I try to imitate those constraints, and put in a note to the layout person about this. But it would be nice to be able to pass this information to
