Mail Archives: geda-user/2015/02/06/23:22:01
On 02/04/2015 04:19 PM, John Doty wrote:
> A toolkit like gEDA winds up making connections to other tools and toolkits. Python is better suited to making these connections than Scheme is.
Python even has allowances for functional programming when contributors use that way.
On 02/04/2015 01:54 PM, Ouabache Designworks wrote:> I want the architects to be able to enter the block diagram
> of an entire system in schematic form. The team can then take this
> and identify which blocks map to real parts (drams, drivers etc) and which ones go into an Digital chip.
> The emulation team can identify multiple FPGAs while the asic team only
> identifies their asic. Both teams work from the same source so that any changes
> are effective in both.
This points out the need for hierarchy in the internals of schematics and in the netlister so
that something standardized like Verilog AMS can be the netlist format. Seems
like this is a chunk of work hurdle to get over somehow.
I agree file format is pretty good density as is and a reason to change
might be to use some open standard for interchange
during a code revamping to allow attributes on everything,
and thus flexibility for buried vias, special shaped pads,
subcircuits as "elements", footprints with other layer/component
than pad or text, etc.
On 02/05/2015 08:27 PM, Jason White wrote:> The files are just data, their is nothing executable about them. This
> is simply using a parser to store numbers and strings on a stack, this
> no different that what geda already does except it uses a preexisting
> library to accomplish it.
Seems harmless to me, and could enable more volunteer coding.
On 02/06/2015 01:24 AM, Evan Foss wrote:> As I see it the things we need are in the
> glue Igor2 mentioned in the 2nd topic. I would really like it if there
> was a small set of utilities that let us move our work from gEDA to
> KiCad and back again with out degradation or frustration.
And yes, the real movement to more sharing of existing libraries doesn't
require adding new scripting languages at all.
On 02/06/2015 03:38 AM, Chris Smith wrote:>> Executable content is a no-no.
> While that’s generally the case, it’s not true of Lua, which was designed from the ground up as an embedded language rather
than a fully fledged scripting language.
Ah so, Lua sounds better and better. But for the data format?
On 02/06/2015 12:52 PM, gedau AT igor2 DOT repo DOT hu wrote:> I find the "easier to handle in one specific language" or "easier to handle
using a specific library" arguments weaker than the
> "easy to parse using a random language" argument.
+1 When we add many name value pairs of data as attributes on objects, we still need something to tell what is the start of
those lists. They can come after the position dependent data that is very compact and not need more surrounding tags or special
words.
On 02/06/2015 01:32 PM, Roland Lutz wrote:> But ultimately, the critical part is not the tools; it is the high-level glue layer
that holds the tools together. For example,
> there is currently no easy way for a standalone script to access the netlister infrastructure; without this information, many
> useful operations are much more complicated or not possible at all (see the red dot problem).
>
> I'd like to go the step from a well documented schematic and symbol interchange format to a well-documented library that provides
> easy-to-use functions for parsing and writing these formats, as well as the higher-level functionality required for analyzing and
> manipulating these files in a useful way, such as the netlister. I believe this is what libgeda was originally intended to be.
Netlisting is the key to consider before any push to write or rewrite gschem code. Thanks for digging into this, I'll spend some
time
looking and reading and testing.
John Griessen
- Raw text -