kicad-developers team mailing list archive

[al davis <ad10@...>]

On Friday 03 April 2009, Dick Hollenbeck wrote:
> The summer of code is only open to students right?
>
> This limits who can win the prize, but does not limit who can
> do the work. Its just that you have to be a student to get
> any money for it?

For anyone who hasn't applied yet, it is probably too late.

Google summer of code is for students. Some projects are 
selected for funding, competitively. Last year, something like 
1/5 of the applications were funded.

Maybe next year.

Even without funding, I still want to make Gnucap work with 
Kicad, and would like help doing it.

> Required Qualifications:
>
> 1) Student
> 2) C++ experience
> 3) Kicad experience
> 4) Gnucap experience

or can learn fast.

> Even if such a person can be found, it is reasonable to
> assume they will come asking for guidance.

:-)

> My suggestion is to use D-BUS. The file formats in Kicad are
> likely to evolve and that will break code that relies on a
> stable format. A series of well designed D-BUS functions
> are likely to be more stable and immune from file format
> changes.

Both approaches are valid.

Gnucap uses "language plugins" to read a variety of formats. 
For now, the supported formats are Spice, Spectre, and Verilog.

There is a need for a stand-alone translator facility, using the 
same plugins, which would provide separate translation 
capability.

It is good that you recognize that the Kicad format will 
evolve. That points to a need for a facility to convert it to 
and from something that is stable and documented, with a 
published document. I like Verilog for this. I can see using 
the structural subset of Verilog as a general format for 
netlist, schematic, and layout. I can explain better after I 
get back home from travelling.

When the Kicad format changes, you will need a way to convert 
files between the new and the old.

gEDA has a translator with plugins for the format being written, 
but the input format is always the gEDA format, which causes 
problems with its ability to evolve. The translator only 
provides a one-way path out.

The translator I am thinking of could eventually provide an 
import and export path for lots of other formats, including 
Pads, Eagle, Qucs, .....

> So, would it then make sense for you to list your needs at
> runtime, since Gnucap would be considered a client of a Kicad
> service? By runtime, I mean in a situation where both
> Gnucap and Kicad are loaded and running concurrently.

A new plugin needs to be created that would provide the needed 
communication. It must be a plugin so it can evolve 
separately, and to stay out of the way when it is not being 
used.


> Maybe you can identify function declarations in psuedo code
> or (cidl) that you would need to make your end work at
> runtime. These can then be evolved into D-BUS interface
> documentation sets, and then we have provided some guidance
> to any one stepping forward, student or otherwise. Obviously
> the final implementation can exceed the requirements.

I am travelling now. I will answer when I get back home.

> That is my suggested path forward. It tries to protect
> investment of effort (by offering better but not perfect
> immunity from file format changes), and it tries to provide a
> path of maximum user experience at runtime.

It really is important to protect against format changes. That 
is why it must be in a plugin.

You might want to use a Gnucap-type plugin system for Kicad. It 
works really well.