gEDA-user: Notes from last night's Free Dog meeting (11.3.2005) . . . .

[sdb@xxxxxxxxxx (Stuart Brorson)]

. . . for the benefit of those who don't live in Boston.

At last night's meeting our attendance rose by 33%!  Participating
were me (Stuart), Ales, and John, as well as a new visitor -- John
LaChapelle.  Ales spent a lot of time coding while we all talked.
Here's what we talked about:   

*  We discussed the problems people have installing gEDA.  A major
cause of complaint: Many problems occur for people installing over old
gEDA distributions.  This causes all kinds of problems such as: 

   --  $PATH and/or $LD_LIBRARY_PATH pointing to the locations of the
       old gEDA versions, 
   --  Old copies of libgeda.so being found before the new one.
   --  Weird problems with $PKG_CONFIG_PATH finding the wrong
       libgeda.pc file.

Although it sounds incredible for folks used to dealing with unix, I
have seen at least two cases of problems due to this.  It's most
likely a newbie issue.

I fished for ideas about how the installer could mitigate this
problem, but most people thought it was a user-error issue.  In any
event, the solution is easy:  Always install gEDA into its own
directory!  Then, when upgrade time comes, just blow away the
directory and start afresh.  Also, make sure that the env variables
are set correctly!

Note that this is good advice for any application suite on unix, not
just gEDA.

*  John asked: Is there a way to improve the gschem <-> guile
interface?  John wants to be able to issue queries to
a parts database from gschem.   Ales grimaced -- the guile interface
is not full-featured, and still needs some work before being able to
do stuff like that.

We then asked the general question, "Forget about guile, is there any
way for gschem to open a socket and talk to a process via IPC or
something?"  The idea again would be to enable communication with a
database server running in the background.  The problem here is:
gschem would need to open a socket and then send SQL (or whatever)
down the pipe to the database.  This is doable.  Next, however, gschem
would need to accept and interpret the info sent back from the
database, and then munge it so as to display it in a format useful to
the user.  This would probably require a new parts brower at the
least. 

Always wanting to push gattrib, I suggested using it as a front-end
for database queries.  However, this solution would still involve
writing code to attach to the database, issue SQL queries, and then
format the results for display.  Perhaps the spreadsheet is a more
logical way to display database tables, but a lot of work would need
be done to make gattrib do this.

*   GEDA wiki:  Ales volunteered to add a "to do" list to the wiki.
This will be a list of open projects which we'd like to see done.
There will be at least two sections to this list:  "To dos" for the
next release, and then "to dos" for the future.  This will not only
keep the current developers on track, it will also give newbies some
ideas about projects which they might pick up!  I look forward to
adding to this page!

*   John Luciani brought his latest project boards:  a set of 4 layer
PCB supporting a TI microcontroller along with auxiliary interface
boards.  Very nice work -- beautifully layed out!  

He has developed a process whereby he takes the layouts for different
boards and combines them together onto one  large panel which he gets
fabbed.  Then he cuts up the panel using a bandsaw to get the
individual boards.  Since this amortizes the setup cost of the PCB
over a large number of boards, its a good technique to reduce the
per-board cost. However, you need to check with your vendor first;
some vendors don't like it when you panelize!

*   John also brought along a fab drawing which he generated using a
Perl program he wrote.  The Perl program enables him to output from
PCB the .ps files for each layer, and then merge all the .ps layers
together onto one file.  Nice!  John, will we see it on your website
soon?  

*   John LaChapelle stopped by for a visit.  He's a researcher at a
local high-tech facility.  His buddy (and ours) Dan McMahill urged him
to stop by; we had a good long chat.  He showed off a spiffy 2 layer
board he spun to support a MEMS device used at his work.  The board
was approx 3" x 5". He did the board entirely using the gEDA tools and
John Luciani's footprints. He did it using the gEDA tools because he
wanted to bypass the normal  process at his facility and crank out a
board quickly, hassle-free, and completely under his control.
Enabling this amongst the goals of the gEDA project!  

Much of our conversation centered on answering his questions about the
gEDA project itself (such as "why are we doing this?").  We did touch
upon some interesting issues, including: 

   --  How he was introduced to gEDA: through Dan McMahill at Maxim.  
       Thanks for the advocacy, Dan!  As time goes on, I think that
       more engineers working in big corporations can take up the 
       challenge to sneak gEDA in "under the radar screen".  Remember 
       -- that's how Linux spread: on servers under the IT Manager's
       radar screen.  I talked a little bit about the "Trojan Horse" 
       work I have done at my day job.

   --  The work we have done to publicize gEDA (i.e. EE Times article, 
       Circuit Cellar article, advocacy, etc.)  I pointed out that 
       we have been running a guerilla marketing campaign; the 
       publicity didn't spontaneously happen.  The best way to 
       get publicity for any project is to write something 
       ready for a journalist and then send it in.  Preprepared text 
       (like a press release) helps the journalist to spread your
       story.  With pre-written text all he (or she) has to do 
       is cut-'n-paste job from your text into an article.

   --  Various opinions about the gEDA's ease of use.  He opined
       that he is a long-time Linux user, so he is used to tinkering
       a little bit when required to get an application up and going.
       He pointed out that you need to tinker with any complex app; he
       spent many days learning how to use the Cadence tools, so 
       having to spend some time climbing the learning curve with gEDA 
       wasn't a problem.  Perhaps the complaints that gEDA is "hard to 
       use" comes from newbies who have never used an EDA pacakge
       before?  Or perhaps they are used to the baby apps used to
       teach undergrads?  In any event, we all agreed that gEDA is no
       harder to use than any other professional-level EDA package.  
       (Note that this is not an excuse to not work on improving the 
       user's experience with gEDA. . . . . .)

   --  Possibilities for participation.  There are a lot of open
       projects available for folks to get involved in.  The project
       itself needs more documentation.  The wiki is up, and several
       people have passwords.  If you want to participate, get a
       wiki password and start writing!

   --  As far as coding, besides working on several existing projects,
       we threw around ideas for new projects, including:

       *  A Gerber -> PCB file converter.  The idea here is that a
          moderately complex Perl script could take a Gerber file, 
          and turn it into a PCB metal (or silk) component which could
          be edited in PCB.  Why?  Because it is common to have old 
          Gerbers with no other design files.  (Think about the
          situation of inheriting a legacy design which you must
          support.)  Often the Gerbers have design flaws needing 
          fixing.  This converter would enable you to fix small 
          problems in old Gerbers (i.e. cut or move traces).  I 
          this this could be a killer app for gEDA/PCB.  Right now,
          if you want this capability you need to spend a lot of $$$
          to buy CAM350 or something like that.

       *  A set of .dxf <-> .pcb file converters.  Steve Meier asked
          for something like this recently.

   --  Talked about Matlab vs. Scilab vs. Octave.  John has used
       Scicos, the Scilab signal processing toolbox (similar to 
       Matlab's Simulink).  He said it was reasonably useful, although 
       he did have a specific bug involving taking square roots which
       inhibited his ability to do some simulations he needed to do.

       More generally, the Matlab vs. Scilab thing illustrated the way
       in which people tend to use F/OSS applications:  many of them
       are good enough to handle 90% of ordinary work.  Since they are
       license-hassle free, people tend to load them up on their
       laptops

 
*  After John LaChapelle left, Ales showed off some new behavior he
had coded up w.r.t. the "L" nets.  While we were doing that, we found
bug with autosave stuff -- it caused a crash in gschem.  The origin of
the bug was not clear;  Ales will follow up with Carlos.  

*  A demo of PythonCAD.  I have been looking high and low for an app
with which I can do mechanical drawings.  At Free Dog we have already
demoed and discussed QCad and BRL-CAD.  This evening I demoed
PythonCAD for the group, which is a program I have been playing with
for the last month.  Here's a link to the project website:  

http://www.pythoncad.org/

I showed off the beginnings of a drawing I am working on.  Ultimately,
I want to be able to create drawings of a plexiglas cover for a model
railroad table.  I have gotten the very basics of the drawing up in
PythonCAD (i.e. I have a couple of dimensioned rectanges drawn).  In
it's current state, you can enter segments, rectangles, circles,
polylines, and dimensions into PythonCAD using absolute coordinates or
using the mouse.  However, my progress has been slow and painful.
PythonCAD is definately in early alpha stage, and lacks a number of
important features necessary to make it generally useful, such as:
The concept of scale, the concept of entering objects using relative
coordinates, the ability to save out the drawing settings
(preferences), as well as other important features.  I belive the
group shared this opinion after we did the walk-through.

I don't want to slag PythonCAD off.  I think that it will eventually
be a nice package.  I have contributed several patches to the project,
and intend to continue contributing.  I think that the project's
foundations are good.  However, after working with it
for a month I have decided that it is definately an early-alpha stage
project, and isn't ready for general use.  I will say that if you are
a developer looking for an interesting and potentially important
project to which to contribute, consider looking at PythonCAD. 

*  We discussed the PCB fork:  Timothy Edward's Tk PCB.  For folks not
familiar with it, this is a fork of the older XAW PCB which is somehow
slaved to TCL/Tk.  It was announced recently on the "magic" list.
(Magic is the old, augst chip layout program which is still used in a
lot of places, particularly universities).  We decided to check out
this PCB fork at an upcoming meeting soon.

*  Next gEDA release:  I am still testing the install process on
various Linux distributions, and Ales is somewhat far away from
the next gEDA/gaf release.  Happily, other developers have risen to
the challenge of fixing the type bugs laid bare by gcc-4.0.  However,
it will probably be a couple of months before the next gEDA release.

That's all I remember!  Thanks to John and Ales for sending me their
notes from the meeting.  If anybody remembers something different, or
has an opinion on one of these issues, please follow up on my posting!

Stuart