Mail Archives: geda-user/2016/07/17/20:15:45
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--8323329-1962476018-1468800825=:1534
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
On Sun, 17 Jul 2016, Kai-Martin Knaak wrote:
> What happens if xorn is presented with a box command that has the
> parameters x= and y= swapped? I'd expect the utility to silently read
> the values into their corresponding internal representation. Or is there
> some chatter in the logs?
The XML file is parsed using Expat which handles this transparently. You
can arrange the attributes in any way you like, including additional
whitespace and even line breaks between the attributes (but not within an
attribute). The attributes which are listed in the format description as
having a default value can be omitted.
> What happens on save? Does xorn try to keep the order of the parameters
> as in the original. Or does it rearrange the parameters into some
> "official" order?
The logical contents of the file are the only information which is kept
after reading the file is finished. When saving them, a new XML document
is constructed which contains exactly this information. (This kind of
abstraction is exactly the point of the Xorn storage library.)
> I'd prefer the latter as it straightens irregularities introduced by
> manually messing with the contents. But I can certainly see why people
> would advocate for the former. (Maybe, the user deliberately rearranged
> the order. Keep changes to the file to a minimum to keep version control
> lean)
I did consider this, but not too seriously. Doing this would be *much*
more complicated, and I'm not aware of any other piece of software which
does this.
>> When converting .sch files to XML files, the symbols and pixmaps
>> referenced by the schematic are included in the XML file by default.
>
> this is equivalent to the "embed" action from within gschem, right?
No, it's not. If you apply the "embed" action on a component or picture
in gschem, it basically gets its own copy of the original symbol or pixmap
which is saved within the schematic file and used instead of the original
file. This corresponds to the "embedded" reference mode in the XML
format. The "referenced" reference mode, in contrast, treats the symbol
or pixmap saved within the XML file as informational, only to be used if
the original file isn't available. You could e.g. use this mechanism to
compare the original file with the one saved within the XML file and print
a warning if they don't match (i.e., the referenced file has been changed).
> So this command does not interpret the traditional geda way to tell
> where the libs are. (gafrc, gnetlistrc at their various locations)
That's correct. The Xorn commands don't execute any Scheme code, and I'd
like to establish that as a standard for any new gEDA-related work.
>> When using the default library included with gEDA, you can't use
>> --symbol-library-search=, unfortunately, because it contains symbol
>> name conflicts.
>
> Can you elaborate, please?
When a gEDA/gaf tool is started up, the standard library isn't added as a
whole using (component-library-search ...), but one subdirectory at a time
using (component-library ...), with the exception of the directories
"gnetman", "verilog", and "vhdl" which are, according to a comment,
"commented out […] because there are conflicting filenames within these
libraries."
xorn.geda treats symbol name conflicts as an error because which of the
homonymous symbols should be used is undefined, and undefined behavior is
undesireable, especially in the context of EDA software.
--8323329-1962476018-1468800825=:1534--
- Raw text -