Mail Archives: geda-user/2015/02/07/09:04:37
On 02/07/2015 03:01 AM, Chris Smith wrote:
>> it becomes more difficult to create a GUI to edit the data when the data uses a complex file format.
> I don't follow that. We already have the GUI: gschem. The complexity of the data is defined by the complexity of the objects and facilities implemented by gschem.
gschem is not complete though... Ease of adding improvements is top importance for volunteer projects.
I can see the use case of p-cells, (parameterized cells), being valuable enough to allow a script-as-data
to run with warnings and not be enabled by default. Board and chip design are converging as printable
electronics. All the chip design features, and dangers of virii installed in a p-cell that is shared, and maybe the internal code
being scheme/LISP?Cadence_Skill code as well as "one of" the scripting languages are problems worth addressing.
On 02/07/2015 03:20 AM, Chris Smith wrote:> There will be problems serializing that back to disk though, so it would be better to
support those features for templates, library shapes, etc. but not for the schematics themselves.
One of the biggest goals of EDA tools needs to be hierarchic schematics and netlists, which means schematic
and symbol have one to one input output match. IOW, schematics within schematics. Whatever it is HAS to work for
schematics including the top level schematic, which is often the only one that is a graphical diagram.
On 02/07/2015 04:24 AM, gedau AT igor2 DOT repo DOT hu wrote:> I believe a full lua parser would not be too easy either.
> To me it seems lua syntax is much more complex (and powerful) than what
> I would think is needed for describing a schematics or a footprint or a PCB. The more extra features
> it has over the minimum, the more effort it is to implement a correct parser.
+1, and even p-cells can be worked into the file format with generic attributes and some internal code
to deal with special words. Parameterization makes sense only in a module/schematic/symbol in the EDA
context, so stuffing it into a transistor width by scripted data would still have to refer to
other parameters that are within one module to be useful, and without the limitation of "within one module",
the names and netlist-like paths needed to relate them would grow out of hand quickly. But when you
keep it on point, to the EDA point, it reduces down to "keep these items at such a ratio -- within one module,
and it's feasible.
On 02/07/2015 05:08 AM, Chris Smith wrote:> The Lua syntax is very simple and easy to parse without the Lua library. As I said in
another email one of the primary use cases for Lua is configuration and data files, so it is intentionally easy to parse - it even
has a few syntactic niceties to/help/ parsing, such as allowing a list to end with a dangling comma, e.g list = { 1, 2, 3, }.
And yet again, from another person, we get educated about lua being, "Made for this."
Seems like it. Probably needs more study by those objecting on grounds of "lua having an image problem"
Especially if the file format could be standardized on it without having to say the code depends on lua.
For many users of gEDA tools, like KiCAD users, it should work out of the box in a mode that
hobbyists can run with, so P-cells disabled, as virus safe as can be, with symbol and footprint libraries
that are easy to use and adapt for beginners, etc.
- Raw text -