Re: gEDA-user: gschem guile scripting
On Sat, 30 Oct 2010, Oliver King-Smith wrote: Maciej, There is a small development script that allows you to drop into a guile shell on the gEDA website. The shell auto completes so you can see a list of all available commands. You can also try things live. I found this very helpful when I was starting out with gnetlist. Here is the development script in case you can't find it. (use-modules (ice-9 readline)) (activate-readline) (define (devel output-filename) (scm-style-repl) I already tried this before posting, it don't work even for gnetlist producing following output: Backtrace: In current input: 1: 0* (ptest output.net) unnamed port:1:1: In expression (ptest output.net): unnamed port:1:1: Unbound variable: ptest for gschem there is even no such output, i have guile-1.8.5 if that changes anything. I read John P. Doty gnetlist tutorial but unfortunatelly packages variable seems to be gnetlist specific, and it is not present in gschem. Maciej Oliver -- Maciej Pijanka I don't fear computers, I fear lack of them -- Isaac Asimov ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sun, 2010-10-31 at 00:44 +0200, kai-martin knaak wrote: Evan Foss wrote: I may have missed it but has anyone suggested the brlcad format. It might be better than freecad in that it has export/import from a lot of other formats already written. It might be worse in that its user interface is prohibitively non- intuitive. I looked at the application a few years ago, when I was in need for a mechanical CAD application. Even the most simple operations required a number of complex steps. There is a whole chapter in the manual on how to move a component. The user base of brlCAD is marginal and will probably shrink even more, as more intuitive open source CAD applications will become a viable alternative. That may be true, but I am not really happy with the wording. Some kids may be tempted to do something like sed -i -e 's/brlCAD/gEDA-PCB/' ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem guile scripting
On Oct 31, 2010, at 5:07 AM, Maciej Pijanka wrote: I already tried this before posting, it don't work even for gnetlist producing following output: Backtrace: In current input: 1: 0* (ptest output.net) unnamed port:1:1: In expression (ptest output.net): unnamed port:1:1: Unbound variable: ptest It means you haven't defined ptest. for gschem there is even no such output, i have guile-1.8.5 if that changes anything. I read John P. Doty gnetlist tutorial but unfortunatelly packages variable seems to be gnetlist specific, and it is not present in gschem. You seem to be trying to do a gnetlist task from within gschem. Don't do that. Use the right tool for the job. 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: gschem guile scripting
On Sun, 31 Oct 2010, John Doty wrote: On Oct 31, 2010, at 5:07 AM, Maciej Pijanka wrote: I already tried this before posting, it don't work even for gnetlist producing following output: Backtrace: In current input: 1: 0* (ptest output.net) unnamed port:1:1: In expression (ptest output.net): unnamed port:1:1: Unbound variable: ptest It means you haven't defined ptest. Yes, but this is what i get when i created gnet-devel with gnet-ptest name, so i think i missed something important, maybe it need also define procedure which name is derived from invoked backend name that is called by gnetlist after processing schematics. for gschem there is even no such output, i have guile-1.8.5 if that changes anything. I read John P. Doty gnetlist tutorial but unfortunatelly packages variable seems to be gnetlist specific, and it is not present in gschem. You seem to be trying to do a gnetlist task from within gschem. Don't do that. Use the right tool for the job. Why, i wanted to create some scheme script to be invoked from gschem to show/hide pinnumbers on currently opened schematics, why i would use gnetlist for that? John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com -- Maciej Pijanka I don't fear computers, I fear lack of them -- Isaac Asimov ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem guile scripting
On Oct 31, 2010, at 10:18 AM, Maciej Pijanka wrote: On Sun, 31 Oct 2010, John Doty wrote: On Oct 31, 2010, at 5:07 AM, Maciej Pijanka wrote: I already tried this before posting, it don't work even for gnetlist producing following output: Backtrace: In current input: 1: 0* (ptest output.net) unnamed port:1:1: In expression (ptest output.net): unnamed port:1:1: Unbound variable: ptest It means you haven't defined ptest. Yes, but this is what i get when i created gnet-devel with gnet-ptest name, so i think i missed something important, maybe it need also define procedure which name is derived from invoked backend name that is called by gnetlist after processing schematics. Yes. for gschem there is even no such output, i have guile-1.8.5 if that changes anything. I read John P. Doty gnetlist tutorial but unfortunatelly packages variable seems to be gnetlist specific, and it is not present in gschem. You seem to be trying to do a gnetlist task from within gschem. Don't do that. Use the right tool for the job. Why, i wanted to create some scheme script to be invoked from gschem to show/hide pinnumbers on currently opened schematics, why i would use gnetlist for that? For the same reason that you wouldn't want to use pliers as a hammer. gschem has very little knowledge of what the graphics *mean*. This is a very good thing, a key feature of gEDA's design, one that distinguishes it from all the fritterware out there. 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: gschem guile scripting
Why, i wanted to create some scheme script to be invoked from gschem to show/hide pinnumbers on currently opened schematics, why i would use gnetlist for that? For the same reason that you wouldn't want to use pliers as a hammer. gschem has very little knowledge of what the graphics *mean*. This is a very good thing, a key feature of gEDA's design, one that distinguishes it from all the fritterware out there. When a user complains that they can't get their work done, the WRONG answer is to tell them they're better off that way. PCB's plugins can iterate through all the foo on the current board. It's really useful, and something you'd expect a layout app to be able to do. Why shouldn't our schematic editor be able to iterate through all the foo on the current schematic? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
Stefan Salewski wrote: The user base of brlCAD is marginal and will probably shrink even more, as more intuitive open source CAD applications will become a viable alternative. That may be true, but I am not really happy with the wording. Some kids may be tempted to do something like sed -i -e 's/brlCAD/gEDA-PCB/' Well, the usability of geda-PCB is not that far off-road. It is on par, or better than its main competitors kicad and eagle (in my humble opinion). That said, it is certainly true that geda looses potential users because of the command line thing. It makes the newbie expect the need for much more command line magic down the line. In reality, you just issue simple commands a few times per project. And you can avoid even these with xgsch2pcb or pcb-pull. These two work-flows really should be advertised more -- In the documentation, tutorial and in the articles in wikipedia. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem guile scripting
On Sun, 2010-10-31 at 10:41 -0600, John Doty wrote: For the same reason that you wouldn't want to use pliers as a hammer. gschem has very little knowledge of what the graphics *mean*. This is a very good thing, a key feature of gEDA's design, one that distinguishes it from all the fritterware out there. There are some physicists with very less knowledge of electronics, and there are electronics engineers with very less knowledge of physics. That may be OK, but may be a problem in a team doing astronomic space observation. For gEDA, a gschem variant with some more knowledge about electronics may be not too bad, e.g. for detecting wrong wirings during schematic entry. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem guile scripting
On Sun, 31 Oct 2010, John Doty wrote: On Oct 31, 2010, at 10:18 AM, Maciej Pijanka wrote: On Sun, 31 Oct 2010, John Doty wrote: On Oct 31, 2010, at 5:07 AM, Maciej Pijanka wrote: I already tried this before posting, it don't work even for gnetlist producing following output: Backtrace: In current input: 1: 0* (ptest output.net) unnamed port:1:1: In expression (ptest output.net): unnamed port:1:1: Unbound variable: ptest It means you haven't defined ptest. Yes, but this is what i get when i created gnet-devel with gnet-ptest name, so i think i missed something important, maybe it need also define procedure which name is derived from invoked backend name that is called by gnetlist after processing schematics. Yes. So i understand why simple test failed, but my problem this time isn't even near gnetlist for me. for gschem there is even no such output, i have guile-1.8.5 if that changes anything. I read John P. Doty gnetlist tutorial but unfortunatelly packages variable seems to be gnetlist specific, and it is not present in gschem. You seem to be trying to do a gnetlist task from within gschem. Don't do that. Use the right tool for the job. Why, i wanted to create some scheme script to be invoked from gschem to show/hide pinnumbers on currently opened schematics, why i would use gnetlist for that? For the same reason that you wouldn't want to use pliers as a hammer. gschem has very little knowledge of what the graphics *mean*. This is a very good thing, a key feature of gEDA's design, one that distinguishes it from all the fritterware out there. But i don't want app to *know* what it iterates, just to iterate over all items and expose that possibility to scheme so i could skip entities containing attribute graphical=1 and show pin numbers or any other attribute if it exist on them, or hide them. Why command line tool used to extract/convert/process schematics into not schematic would be best idea to just alter visibility of pins or attributes for whole sheet at once, i just want to save time on click on element, edit-attributes, enable visibility of one, and move cursor to next. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com -- Maciej Pijanka I don't fear computers, I fear lack of them -- Isaac Asimov ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
Hi all, -Original Message- From: geda-user-boun...@moria.seul.org [mailto:geda-user-boun...@moria.seul.org] On Behalf Of kai-martin knaak Sent: Sunday, October 31, 2010 6:36 PM To: geda-u...@seul.org Subject: Re: gEDA-user: Ben mode feature request Stefan Salewski wrote: The user base of brlCAD is marginal and will probably shrink even more, as more intuitive open source CAD applications will become a viable alternative. That may be true, but I am not really happy with the wording. Some kids may be tempted to do something like sed -i -e 's/brlCAD/gEDA-PCB/' Well, the usability of geda-PCB is not that far off-road. It is on par, or better than its main competitors kicad and eagle (in my humble opinion). That said, it is certainly true that geda looses potential users because of the command line thing. It makes the newbie expect the need for much more command line magic down the line. In reality, you just issue simple commands a few times per project. And you can avoid even these with xgsch2pcb or pcb-pull. These two work-flows really should be advertised more -- In the documentation, tutorial and in the articles in wikipedia. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 Avoiding the command line won't help you on the gschem -- simulation work flow. Loosing potential users due to a command like thing is probably something a lot of *nix apps and tools suffer from. I can't help people who will not try to learn what is neccesary, or do whatever it takes, to solve their *own* problems. Sad, but true. IMHO there is no true hacker fu in them. Kind regards, Bert Timmerman. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
That said, it is certainly true that geda looses potential users because of the command line thing. The demo I did at Devcon didn't use the command line at all. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sat, Oct 30, 2010 at 5:44 PM, kai-martin knaak k...@familieknaak.de wrote: Evan Foss wrote: I may have missed it but has anyone suggested the brlcad format. It might be better than freecad in that it has export/import from a lot of other formats already written. It might be worse in that its user interface is prohibitively non- intuitive. I looked at the application a few years ago, when I was in need for a mechanical CAD application. Even the most simple operations required a number of complex steps. There is a whole chapter in the manual on how to move a component. The user base of brlCAD is marginal and will probably shrink even more, as more intuitive open source CAD applications will become a viable alternative. Following that logic gEDA will be made extinct by kicad any day now. brlCAD is truely free while freecad is based on opencascade which has a quasi open source licence. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
Bert Timmerman wrote: Avoiding the command line won't help you on the gschem -- simulation work flow. It ain't necessarily so. (cite from a song I'll sing on Wednesday :) The current simulation work flow of geda sucks big time. Absence of a GUI way is only a minor itch when compared with the real issues. Anyway, it is difficult to convince users on the power of your framework, if they refuse to use it from first impressions. Loosing potential users due to a command like thing is probably something a lot of *nix apps and tools suffer from. There are not that many CAD applications that rely on the command line. Unix tools tend to deal with tasks that don't need a GUI in the first place. The same cannot be said of schematic capture and pcb layout. Both lend themselves naturally to graphical user interfaces. In a way, geda+pcb+command line is like a GUI text editor that relies on shell commands to do searchreplace. I can't help people who will not try to learn what is neccesary, or do whatever it takes, to solve their *own* problems. Since there are commandline-less alternatives, they do what it takes to solve *their* problems. However, none of them will contribute to geda/pcb in any way. Sad, but true. A project with a dwindling user base will slowly freeze to death. Sad, but also true. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sun, 2010-10-31 at 19:09 +0100, Bert Timmerman wrote: Avoiding the command line won't help you on the gschem -- simulation work flow. Can you please explain why we will always need the command line for simulation in gEDA? (I have newer found the time doing simulations...) Loosing potential users due to a command like thing is probably something a lot of *nix apps and tools suffer from. I can't help people who will not try to learn what is neccesary, or do whatever it takes, to solve their *own* problems. Sad, but true. IMHO there is no true hacker fu in them. I fully agree. There will not be much real benefit from Windows/Ubuntu-type of users. If they do not understand a line like cp xxx yyy -- can we really hope that these people will at some time do serious coding? Of course it is OK if they use Linux tools, but they don't have to. If someone likes to use proprietary Windows or Apple -- why should they use free software at all. That people do not really care about the word FREE, and they do not care about feeding Gates and Jobs. It's OK. Of course, from time to time we may see some smart people using still Windows, Eagle or similar proprietary stuff, we should try to catch them. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
Evan Foss wrote: Following that logic gEDA will be made extinct by kicad any day now. I tried kicad for a little pet project a few months ago. There were quite a few usability issues. It didn't feel like wow, it was that easy!. On the contrary, I frequently wished they had done things differently. I had these wow-moments with inkscape after several years of coreldraw exposure... brlCAD is truely free while freecad is based on opencascade which has a quasi open source licence. Well, freecad is open source enough to enter the debian repository. The debian policy is certainly on the free side. The only gripe I have with the opencascade license is that it is yet another one. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sun, 2010-10-31 at 21:05 +0100, Stefan Salewski wrote: I fully agree. There will not be much real benefit from Windows/Ubuntu-type of users. Oi.. lets not forget that at least one of the gEDA developers (me) is an Ubuntu user. There is no shame in wanting your tools to just work! /me goes back to writing kernel profiling driver for intel GPUs to squeeze more framerate out of PCB+GL. -- 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: Ben mode feature request
Peter Clifton wrote: /me goes back to writing kernel profiling driver for intel GPUs to squeeze more framerate out of PCB+GL. Side note: I just purchased a used ATI Radeon HD 4670 that free3d.org announces as the fastest card with open sourced drivers. I'll keep you posted on my mileage. What kind of acceleration does your GL enabled version actually use? XAA, EXA, UXA ... just some buzz acronyms I got from the guy who recommanded the ATI card to me. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sun, 31 Oct 2010 19:30:46 + Peter Clifton pc...@cam.ac.uk wrote: On Sun, 2010-10-31 at 21:05 +0100, Stefan Salewski wrote: I fully agree. There will not be much real benefit from Windows/Ubuntu-type of users. Oi.. lets not forget that at least one of the gEDA developers (me) is an Ubuntu user. There is no shame in wanting your tools to just work! /me goes back to writing kernel profiling driver for intel GPUs to squeeze more framerate out of PCB+GL. Seconded - Ubuntu here as well. They do a reasonably good job of making things just work. If something isn't in Ubuntu's repository, or it is broken or outdated, then I'll seek out a .deb or I'll pull down the latest sources and build it myself. So far, only PCB and one or two unrelated programs fall into the build-it-myself category. But, while I may be familiar with the command line, that doesn't automatically mean I *want* to use it. If I can get things done efficiently without touching a terminal, I am happy. :-) -- There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves. http://starbase.globalpc.net/~ezekowitz Vanessa Ezekowitz vanessaezekow...@gmail.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sun, 2010-10-31 at 19:30 +, Peter Clifton wrote: On Sun, 2010-10-31 at 21:05 +0100, Stefan Salewski wrote: I fully agree. There will not be much real benefit from Windows/Ubuntu-type of users. Oi.. lets not forget that at least one of the gEDA developers (me) is an Ubuntu user. There is no shame in wanting your tools to just work! /me goes back to writing kernel profiling driver for intel GPUs to squeeze more framerate out of PCB+GL. Sure -- I wrote Ubuntu-type of users. That type is very close to Windows users, putting the install CD into the drive and using autostart -- having to click on something like Install icon is already too complicated. Ubuntu may be not too bad, and of course there are some really smart people amongst the large quantity of users. Wanting your tools to just work is fine, but crying and complaining if something is not working exactly as one expects is silly. Some people do not describe their problems or send data files to verify the bugs, even when asked to do, they just abuse the developers. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sun, 2010-10-31 at 20:49 +0100, kai-martin knaak wrote: Side note: I just purchased a used ATI Radeon HD 4670 that free3d.org announces as the fastest card with open sourced drivers. I'll keep you posted on my mileage. I hope it will work fine for you -- some months ago you only advertised nvidia... http://archives.seul.org/geda/user/May-2010/msg00192.html ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem guile scripting
On Oct 31, 2010, at 11:00 AM, DJ Delorie wrote: Why, i wanted to create some scheme script to be invoked from gschem to show/hide pinnumbers on currently opened schematics, why i would use gnetlist for that? For the same reason that you wouldn't want to use pliers as a hammer. gschem has very little knowledge of what the graphics *mean*. This is a very good thing, a key feature of gEDA's design, one that distinguishes it from all the fritterware out there. When a user complains that they can't get their work done, Worrying about pin number visibility is not focusing on the work, but focusing on minor aspects of the presentation. That, of course, is the strength of fritterware. the WRONG answer is to tell them they're better off that way. I am extremely grateful that gEDA is not fritterware, but concerned that it might become fritterware. PCB's plugins can iterate through all the foo on the current board. It's really useful, and something you'd expect a layout app to be able to do. PCB is the most troubled tool in the gEDA kit, not a good example for the path forward for the rest of the tools. Why shouldn't our schematic editor be able to iterate through all the foo on the current schematic? For the same reason it's bad to put a hammerhead on a pair of pliers. Most tools should be specialists. Even creating a Swiss Army knife that's genuinely useful requires great discipline in choosing the functions. gEDA is ideally suited for doing this kind of thing with a script *outside* of gschem. I am pleased that gschem remains unusually simple and clean. 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: Ben mode feature request
On Sun, 2010-10-31 at 19:30 +, Peter Clifton wrote: /me goes back to writing kernel profiling driver for intel GPUs to squeeze more framerate out of PCB+GL. Indeed I wonder why framerate is critical -- is this only for rotating the board in 3D view? For other editing operation most of the board should be statical, so we have the static background which we copy for each frame to the display, and only one element (footprint, trace, ...) which needs real new drawing for each frame. (When I started my toy gschem clone in Ruby my fear was indeed a sluggish display, but with smart cairo layer buffers there should be no problem.) Of course you are very smart, so I seem to miss something... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
Am 31.10.2010 um 21:05 schrieb Stefan Salewski: There will not be much real benefit from Windows/Ubuntu-type of users. If they do not understand a line like cp xxx yyy -- can we really hope that these people will at some time do serious coding? Then, there are many people which know cp xxx yyy, but prefer to avoid it anyways. You want to catch these. 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: gschem guile scripting
Worrying about pin number visibility is not focusing on the work, but focusing on minor aspects of the presentation. That, of course, is the strength of fritterware. If fritterware is the best way to give the user an environment in which they can be productive, then fritterware is what we'll provide. gEDA is all about getting work done. If the user can work faster without pin numbers distracting them, let's give them a way of hiding the pin numbers. When editing a board, the user has the option of showing pin numbers or not. They're not usually needed, so you can hide them to keep them from being a distraction, but you can show then when you need to see them. Editing a schematic is no different. Saying that hiding pin numbers while editing is a task for a script *outside* of gschem means you truly don't understand how people edit schematics. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem guile scripting
On Sun, 2010-10-31 at 14:15 -0600, John Doty wrote: Worrying about pin number visibility is not focusing on the work, but focusing on minor aspects of the presentation. That, of course, is the strength of fritterware. Presentation may be the work, if you are writing a textbook. Indeed I asked for something similar long time ago, but my desire was not big enough to start hacking. PCB is the most troubled tool in the gEDA kit, not a good example for the path forward for the rest of the tools. In my opinion PCB is much more complicated as gaf. My current estimation: Writing a gschem/gnetlist clone may take about 1000 hours for a smart guy employing modern tools like GTK/QT/Cairo/Pango and an OO language like C++/Java/Puby/Python... Writing a PCB clone should take much more time and needs really smart guys -- DRC (realtime), all the exporters (Gerber), autorouters, and fast 3D drawing. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem guile scripting
Hi, -Original Message- From: geda-user-boun...@moria.seul.org [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Stefan Salewski Sent: Sunday, October 31, 2010 10:50 PM To: gEDA user mailing list Subject: Re: gEDA-user: gschem guile scripting On Sun, 2010-10-31 at 14:15 -0600, John Doty wrote: ... Some deleted stuff was here In my opinion PCB is much more complicated as gaf. My current estimation: Writing a gschem/gnetlist clone may take about 1000 hours for a smart guy employing modern tools like GTK/QT/Cairo/Pango and an OO language like C++/Java/Puby/Python... Writing a PCB clone should take much more time and needs really smart guys -- DRC (realtime), all the exporters (Gerber), autorouters, and fast 3D drawing. FYI according to ohloh.net: gEDA approx. 31 person years effort (http://www.ohloh.net/p/gEDA) Pcb approx. 32 person years effort (http://www.ohloh.net/p/pcb) The difference in LOC is not much larger: gEDA approx. 126k LOC (excluding blanks and comments). Pcb approx. 127K LOC (excluding blanks and comments). I think it's a draw ;-) Kind regards, Bert Timmerman ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sun, 2010-10-31 at 20:49 +0100, kai-martin knaak wrote: Peter Clifton wrote: /me goes back to writing kernel profiling driver for intel GPUs to squeeze more framerate out of PCB+GL. Side note: I just purchased a used ATI Radeon HD 4670 that free3d.org announces as the fastest card with open sourced drivers. I'll keep you posted on my mileage. What kind of acceleration does your GL enabled version actually use? XAA, EXA, UXA ... just some buzz acronyms I got from the guy who recommanded the ATI card to me. None really.. (because they are 2D acceleration APIs in the X server). My machine uses UXA, which is the X server acceleration technique used by Intel drivers. (Only Intel IIRC). UXA was originally based on EXA, which was designed to accelerate XRender operations. Cairo uses XRender, so EXA (should) be good with Cairo, and a modern desktop. UXA shares that benefit. XAA is the older X acceleration API, designed to accelerate traditional X operations such as blits / line drawing.. basically our old 2D drawing stuff. This is one of the reasons why PCB / gschem got slower on modern hardware and Xservers, that the old XAA APIs which were designed to accelerate those old kind of drawing operations were phased out in favour of acceleration APIs tailored to modern drawing APIs. UXA + DRI2 + GEM play together nicely on Intel. On Radeon / Nouveau open source drivers, I think it is something along the lines of: EXA + DRI2 + TTM. (Although I'm not 100% sure). DRI2 is the kernel / X11-application interface, and GEM/TTM are in kernel graphics memory / buffer managers. I should probably push my latest experimental changes for speed in a separate branch and let you compare the old PCB+GL for one which uses more modern rendering techniques such as VBOs and a pixel shader. -- 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: Any outstanding gaf patches?
Hi folks, I've just briefly trawled through the patch bug trackers for gaf, and committed a bunch of sensible-looking patches. If you've got any patches that haven't yet been dealt with, and you think should have been, please: (1) Make sure they've been submitted to the SF.net patch tracker: https://sourceforge.net/tracker/?group_id=161080atid=818428 (2) Reply to this thread and complain at me for not having dealt with them sooner. :-) Cheers, Peter P.S. Not PCB patches. ;-) -- 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: Any outstanding gaf patches?
P.S. Not PCB patches. ;-) I'm going to start trolling through those separately... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
Stefan Salewski wrote: I hope it will work fine for you -- some months ago you only advertised nvidia... Yes, there was a shift. A year ago, people in de.comp.os.unix.linux.hardware discouraged me from purchasing an ATI card. Now, it is more like both should work, but free ATI drivers can do decent openGL. The drivers radeon and fglrx must have made real progress, recently. ---)kaimartin(--- PS: Writing this on a box with a moderate ATI card (Sapphire HD5450) -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sun, 2010-10-31 at 22:29 +0100, Stefan Salewski wrote: On Sun, 2010-10-31 at 19:30 +, Peter Clifton wrote: /me goes back to writing kernel profiling driver for intel GPUs to squeeze more framerate out of PCB+GL. Indeed I wonder why framerate is critical -- is this only for rotating the board in 3D view? Not just that, but any interactive rendering operation will repaint areas of the frame. I'm looking at moderately complex boards which can only just reach 30fps. Many boards I've got as test cases will struggle to do 10fps, or 5fps even. Above approx 10fps is usable, but you really want 15-20 upwards. Part of the problem is CPU, part is GPU. The 30fps I'm talking about above is JUST graphics render, without any overhead of changing the objects being rendered. That represents the best case frame-rate with caching of static geometry. For other editing operation most of the board should be statical, so we have the static background which we copy for each frame to the display, and only one element (footprint, trace, ...) which needs real new drawing for each frame. PCB (and my GL code) is not smart enough to make use of limited damage regions, and redraws the whole frame every time. Yes, we could do better, but there would still be memory copies involved. If we were _really_ clever, we could use the double buffering of frames, and compute damage VS. the frame _previous_ to the frame on screen, (in the back-buffer). It is already a frame behind, but if it can be updated to current, it saves copying the front-buffer as your rendering start point. (Alternatively, you would have to have a back-buffer copy rather than swapbuffers for each frame). (When I started my toy gschem clone in Ruby my fear was indeed a sluggish display, but with smart cairo layer buffers there should be no problem.) Of course you are very smart, so I seem to miss something... The update code is sadly pretty dumb. What I wanted to ensure was fast, would be panning / zooming, which involved full frame redraws. I want to optimise that first, _then we can make the editing small areas case lightning fast. 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 guile scripting
On Sun, 2010-10-31 at 22:12 +0100, Bert Timmerman wrote: FYI according to ohloh.net: gEDA approx. 31 person years effort (http://www.ohloh.net/p/gEDA) Pcb approx. 32 person years effort (http://www.ohloh.net/p/pcb) The difference in LOC is not much larger: gEDA approx. 126k LOC (excluding blanks and comments). Pcb approx. 127K LOC (excluding blanks and comments). I think it's a draw ;-) Really interesting, I was not aware of such a page. Of course I was talking about writing a clone, which is much less work than writing the original. And for things like an schematic editor or netlist generation we have today much support by OO languages and useful libraries like cairo. For PCB stuff like DRC, autorouter and Gerber there is not much support. Personally I consider gaf bloated, by mixing C/guile and splitting into so many parts. Why can gschem not do netlist generation (optional in a non GUI mode) and do symbol checking. And gattrib -- should be part of gschem too. Having PCB editor and schematics editor separated is really a good choice, both tasks are very different. Best regards Stefan Salewski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sun, 2010-10-31 at 21:43 +, Peter Clifton wrote: The update code is sadly pretty dumb. What I wanted to ensure was fast, would be panning / zooming, which involved full frame redraws. I want to optimise that first, _then we can make the editing small areas case lightning fast. Unfortunately there are not much examples, at least not for clever buffering with cairo. My guess: For zooming we have to do a complete redraw of the visible area. For panning: I intend to draw to a buffer, which dimension increases when we zoom in, and copy a part of that buffer to the smaller cairo drawing area of the GTK window. So panning is fast, only copy. Moving a symbol: Mark that symbol as invisible, draw buffer, copy area of buffer to window, draw moving symbol to window. For each new frame: Copy area of buffer, draw that moving symbol. I guess that may work, even for slow Ruby. Of course for PCB and OpenGL all is more difficult. Recently I was wondering if that Clutter library may be useful, but I think that will make all more complicated. http://www.clutter-project.org/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
Hm, does this mean you can implement a library, but you mustn't use material from the standard to document it? DJ Delorie wrote: STEP is an ISO standard, which likely means you have to buy the standard itself, but you can implement it freely: http://en.wikipedia.org/wiki/ISO_10303 ___ geda-user mailing list geda-user@moria.seul.org 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: gschem guile scripting
On Sunday 31 October 2010, John Doty wrote: I am extremely grateful that gEDA is not fritterware, but concerned that it might become fritterware. to fritter (third-person singular simple present fritters, present participle frittering, simple past and past participle frittered) 1. To occupy oneself idly or without clear purpose, to tinker with an unimportant part of a project, to dally, sometimes as a form of procrastination. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA interview with DJ at DevCon
Perhaps, but its been on my To Do list for a long time to do a wxWidgets port of PCB. Why are so few people interested in FLTK? My reason is that I had to chose a tool kit that I could use for my day job making commercial software. I don't like FLTK's license in that context. While a Windows port of PCB in FLTK would not have such issues, I choose to spend my time elsewhere besides learning an other tool kit. Lets not get into yet an other license discussion on the list here, not the right list. -- http://blog.softwaresafety.net/ http://www.designer-iii.com/ http://www.wearablesmartsensors.com/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Mon, 2010-11-01 at 00:19 +0100, Stefan Salewski wrote: Unfortunately there are not much examples, at least not for clever buffering with cairo. No, although gerbv actually seems to do a good job in this regard. IIRC, just redrawing edges which need repainting after a pan. Zoom can be fudged by stretching your current image up when zooming in, or shrinking it (then repainting the whole screen when you get a moment) when zooming out. With GL, I was looking at storing images of each layer in texture memory. Sounds good.. but I can't store much bigger than my native screen size due to hardware limitations on texture size.. I'd need to split it up into tiles smaller than the hardware limit to be sure of it working at high resolution. (And of course, different chips will have different limits). My guess: For zooming we have to do a complete redraw of the visible area. For panning: I intend to draw to a buffer, which dimension increases when we zoom in, and copy a part of that buffer to the smaller cairo drawing area of the GTK window. So panning is fast, only copy. Fair enough. To be honest, I'd love to instrument a version of PCB with zoom / panning / ... tracked, and have some testers actually work with it for various common tasks: 1. Editing a board 2. Making changes to an existing board 3. Populating / Debugging the board, with reference to the PCB for finding connectivity. Those would all be in my common work-flow, but I've not had cause to design so many boards recently. (Also, I might be biased by having preconceptions about the test). Moving a symbol: Mark that symbol as invisible, draw buffer, copy area of buffer to window, draw moving symbol to window. For each new frame: Copy area of buffer, draw that moving symbol. I guess that may work, even for slow Ruby. As long as the graphics routines are fast (which they ought to be), overhead ought not to be too bad. Of course for PCB and OpenGL all is more difficult. Recently I was wondering if that Clutter library may be useful, but I think that will make all more complicated. http://www.clutter-project.org/ Gnome shell / Ubuntu unity use that. I'm not sure if its clutter's fault, or the underlying mutter window manager (which uses clutter), but it isn't fast enough. That said.. it might be fun, but I don't think it is really suited to be the PCB application's canvas. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- 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: Ben mode feature request
On Oct 31, 2010, at 2:31 PM, Markus Hitter wrote: Then, there are many people which know cp xxx yyy, but prefer to avoid it anyways. You want to catch these. You don't want to dumb down the toolkit. Now, if somebody wants to write a fat, sweet integrated tool using the gEDA file formats, but tuned to the student/hobbyist market, I would cheer. Hobbyists and students are very important: they are the future. But gEDA is not that: instead it is a toolkit of broad capability, far beyond what its designers expected, I think. gEDA is the toolkit for *experts* doing *great* things *now*. Let's not lose that. One size does not fit all here. 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
