|
|
Magic Mailing List |
|
From: John Griessen (john_g AT cibolo DOT com) Date: Mon May 19 2003 - 12:42:27 EDT
On Mon, 2003-05-19 at 10:03, Erwin J. Prinz, Ph.D. wrote: > Friends of Magic: > <snip> > "This is not as elegant as having the Python interpreter compiled in but it works." [jg]Fortunately, layout is desired by practical types, so they don't get hung up on being elegant before being "able".... as in, Magic is evolving rapidly by being open to addons like the python you told us about. I think it's great...I'll go along with the tcl inteface the hard working main developer of Magic is using gladly...even though python sounds good to me too. [jg]Have not gotten into as much use as you to see anything like the labels bug. "ier if the ":" prompt would switch the focus t" [jg]This makes me think of making a keybinding to a python script that gets you all the way between windows, and keeps available any state information like cut and paste. I need to devote some time to using and learning Magic and see what I come up with here... "3. One has to be careful with the "load" and "getcell" commands. If a > ".mag" is appended to the filename in the command, it gets written into > the ".mag" file. Then, when streaming out, cellnames get replaced by > "XXXXXn". Since the tab completion in tkcon appends the ".mag", it is > easy to make this mistake." [jg] Always have a way to go back in time... identify critical places in any workflow where backups are most effective. Automate anything repetitive so it is less of a chance for such mistakes... (So you does not use the nice general tab completion feature when iterating layout versus schematic checks for example. Only use that nice feature for one of a kind items.) Maybe these comments sound like, "just work around it", but from experience doing layout with commercial tools, The software is usually not practical to get changed, and you find also that there are so many different ideas by layout folk about what is a productive way to do anything it's hard to get a consensus. So, with no easy consensus, the thing to aim for is easy customization with minimal risk that your customization breaks functions. Later, if a work flow method is working really well you want to brag about it to this list, and tell of repeatable experiments to demo processing speed of such a method, and that will trigger some looking into speeding such a work flow even more by coding. Usually the breakthroughs in custom layout productivity are by simplifying steps down to the minimum conceptual ones rather than speedy code -- except in things like drc, lvs, parameter extract... John Griessen Austin TX interested in organic semiconductor circuits and light emitters with magic.
|
|
|
|