Attribute multiplicity

[noqsi]

For attributes like source, it would be better to have a single attribute with a multiline value than the current multiple attributes.

[peter-b]

@noqsi One of the things that really bites us at the moment is attributes that occur multiple times with the same name= component, and source= is one of them.

Rather than using multiple lines, another approach could be to use source=foo;bar;baz. This is a pretty well-established format that's used extensively by e.g. the GKeyFile system that we use for Lepton config files. It would be straightforward to provide UI for manipulating multi-value attributes in gschem, so that users don't need to worry about escaping etc.

[vzh]

@peter-b Today gnetlist and gschem use different approaches wrt source=, and gnetlist one (inherited from the old codebase) is to use either several source= attribs to choose schematics or comma-delimited list in the attrib (or both, as is implemented now). Please look at the procedure comma-separated->list in schematic->xml here. We would lose nothing if we make a list of filename delimiters and add #newline to it. The same for semicolon, I think.

[peter-b]

@vzh I suppose one problem is that , and \n are actually valid Linux filename characters. Probably there is a bug here, because we need to have an escaping system so that users can say, "Yes, this is really a filename character, not a separator." Using a single separator character would make this easier. Maybe source= should stick with ,.

Is there any hope to move towards a single consistent system for all attributes that have value lists?

[vzh]

@peter-b I think John's proposal is just this: a single consistent system for all attributes that have value lists. That is, he proposes multilined attributes for that. I think it would be enough if we also decide on which attributes can have multiple values. I don't see an issue with , or \n. Let those users who want to use such names suggest an escaping system implementation for this. BTW, semicolon is also a valid filename character in Linux filenames. What we need is a good documentation for all this.

[peter-b]

@vzh Ah, I see.

There is a challenge if you have an attribute value that contains both a comma and a \n. Is it a comma-separated value, where one of the elements contains \n? Or is it a \n-separated value, where one of the elements contains a comma?

I suggest the following approach:

• Do an audit of everywhere in the codebase that tries to parse list-valued attributes (I think there's some stuff in liblepton that parses these attributes to support slotting).
• Convert all these locations to use one implementation of splitting, if possible (it may be necessary to have one C implementation and one Scheme implementation)
• Make the splitter understand \n-separated values, according to the following rule: if the value contains \n, then treat the value as multiline; otherwise, if it contains a ,, treat the value as comma-delimited; otherwise treat the value as multiline (but with one line)
• For multiline values only, treat the sequence \\ as a literal \, treat the sequence \n as a literal linefeed. This is actually potentially problematic because liblepton already does some \ magic in order to support the \_...\_ overbar... maybe we need to double-check how to deal with that.
• Make gnetlist emit deprecation warnings when it encounters comma-delimited values
• (In 1.11.x) Remove handling of comma-delimited values except when in backwards-compatibility mode

[vzh]

@peter-b Yes, thanks, something like this. I am not sure that I understood your third point correctly, a couple of examples wouldn't harm.

[vzh]

A suggestion by Karl Hammar on geda-user:

One way to handle the issue of separator is to let the first char after
the "=" be the separator and perhaps terminator. Example:

footprint=|to3|to95|to220|
footprint=zto3zto95zto220z
footprint= to3 to95 to220
footprint=
to3
to95
to220

The last one also depends on the #oflines in the T-line I guess.

[noqsi]

OK, this has bit me again. I have a design that has multiple copies of a subsystem with a complicated interface. To make clear schematics I tried separating the interface into three symbols, representing analog, digital, and power to the subsystem. Give each set of three the same refdes, just like I'd do with a complicated chip. But, if I put source= into each symbol, it includes the source three times, while if it put it only into one symbol, the other two are treated as ordinary components and don't connect to the source schematic.

[vzh]

@noqsi, it would be of much help if you provide here a simple schematic example along with info on what backend you're meaning here (what commands you use), and the result you would desire to have. Then, the next step would be adding this to tests, even XFAIL for now, which we could fix later.

[noqsi]

Ok, here's a project. I expect lepton-netlist -g geda top.sch to yield a netlist with a single component X1/D1 with its pins connected by a single net. This example is, of course, silly and trivial: the real use case is subschematics with complicated interfaces better expressed by multiple symbols than by a huge symbol with too many pins to comprehend.

foo.zip