delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2015/02/07/09:04:37

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.98.4 at av01.lsn.net
Message-ID: <54D61BDF.4020504@ecosensory.com>
Date: Sat, 07 Feb 2015 08:06:23 -0600
From: John Griessen <john AT ecosensory DOT com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0
MIME-Version: 1.0
To: geda-user AT delorie DOT com
Subject: [geda-user] gschem, gnetlist, libgeda, pcb code architecture (was: FOSDEM)
References: <1420499386 DOT 3521 DOT 3 DOT camel AT cam DOT ac DOT uk> <54CFD589 DOT 9040702 AT xs4all DOT nl> <CAHBYzfRkn-nJb4JfrDYyaD0WwPrpZvAgi0QdHCusgz185iNoHA AT mail DOT gmail DOT com> <CAGde_xN-iNZUvHh-E47kx1EyoPRt1018wWiDwHhYQ9+od+cJwA AT mail DOT gmail DOT com> <20150203112631 DOT 3507a0c1 AT Parasomnia DOT thuis DOT lan> <20150204054256 DOT Horde DOT Pm1JV8RJbICk9SHvIGwZ7A3 AT webmail DOT in-berlin DOT de> <CAOP4iL2stWVCy3WK0=SNu2zAbs8t6B0uyAgFuOnzG8v_MrYNfw AT mail DOT gmail DOT com> <CAGde_xN5gs5r_on=HP2RN7cy6E=2EL9eK3cp+sd9BfBaWNLVew AT mail DOT gmail DOT com> <20150204193720 DOT Horde DOT 42xUN-NzhCJRWZne-M5eCQ1 AT webmail DOT in-berlin DOT de> <90236728-E79D-47C7-BFB1-34140DB85ACB AT sbcglobal DOT net> <CAOFvGD4M48Ap=UQzL_T3yzas2rJrNFfxXRUOkOe8gA8J3bQCHg AT mail DOT gmail DOT com> <201502042333 DOT t14NX28o024789 AT envy DOT delorie DOT com> <7C1A5871-3056-482C-BC58-173D90D80F77 AT icloud DOT com> <CAOFvGD7vdircWqDYWKrKPY49gpYo4ZGsw20q9yE+4+gno3ZkhA AT mail DOT gmail DOT com> <F66800B5-AAC3-459C-B6BC-B2F1E4AC98CC AT noqsi DOT com> <A661E96B-1D00-43E8-9C5E-549FBAC7AB6A AT sbcglobal DOT net> <B6A85AD8-D228-40B9-9CCD-69669A29FE9D AT icloud DOT com>
In-Reply-To: <B6A85AD8-D228-40B9-9CCD-69669A29FE9D@icloud.com>
Reply-To: geda-user AT delorie DOT com

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019