Mail Archives: geda-user/2016/01/19/07:35:53
Vladimir Zhbanov:
> Karl,
> ...
> >> I'm working on the fix for this bug.
> >
> > Do you know where the problem is ?
>
> The issue was in incorrect post-processing function you've
> mentioned. It used the 'member' function that gave incorrect
> result if the list contained a searched record twice.
Did you find out what was the strange thing about R8 = 10k:
http://www.delorie.com/archives/browse.cgi?p=geda-user/2015/12/31/14:11:23
> I've written other functions for sorting and am planning to
> replace the current ones with them. Didn't yet decided how to do
> this better. As of now, the code in my 'parts' branch on github
> seem to be working, though since it is a draft, it needs much
> rewriting and commenting before pushing upstream.
Give me a link, I can test it if you like.
...
> >> - Would it be better to upcase or downcase the device= attributes?
..,
> > In the printouts I made, I gravitated towards camelcase with initial
> > capital for the device attribute to keep columns short. Like in:
> >
> > DiodeSchottky sod323_nxp_a.fp RB751V40 16 D3 D4 D5 D6 D7
...
> OK, I see, though some of our "canonical" device names are upper
> case while other are lower case, and I have found that some
> backends (e.g. spice-sdb) sometimes use case-sensitive
> comparison functions for them. Therefore, things get worse, in
> order to make my netlists compatible with most of the backends I
> have to use different letter case in different cases (sorry for
> the pun :)) So probably the case sensitive sorting would be better
> for the device= attributes.
...
> We would have to revisit all the current geda code then (see
> above). And internally we would still be forced to use case
> sensitive comparisons. At least until the backend API will be
> stable and documented somewhere.
...
> > But I do think the output should not have its case changed.
> Then we could not join "Resistor 10k" and "resistor 10k" and count
> them together in some cases.
I think the best thing is to push that problem down to the user.
> > If you want to change anything, wouldn't it be better to have a separate
> > sch/sym beautifier script ?
>
> Why not? However, at least basic things have to be done well.
1, In 2010 I did one to remove numslots=0 attribute which gsymcheck
complains about:
$ find . -type f -name \*.sym | xargs perl -i -ne 'if (m/^numslots\=0/) { undef($old); } else { print $old if $old; undef($old); if (m/^T /) { $old = $_; } else { print; }}'
2, upcase 1st char of device attribute.
Any more, do you have a list ?
> > Have you considered the way I sorted the values, like in:
...
> > Capacitor m2012_a.fp 330p 2 5C2 acC2
> > Capacitor m2012_a.fp 10n 2 3C2 C14
...
> > instead of purely alfabetical ?
...
> I've written different functions for different
> attributes. Refdeses, for instance are transformed to lists of
> strings and numbers, which are compared in order. Values are
> converted into numbers like you've proposed.
Great, I'd like to test that.
Refdeses have a "complication", subsheets gives them a prefix and
possible a separator, e.g.:
$ grep '^(h' .gEDA/gnetlistrc
(hierarchy-uref-separator "")
Unfortunately one cannot have empty values in attributes, e.g. so
you could easily move one part of a big ic to a subsheet without
affecting anything else.
> However, I consider
> aligning by point to be superfluous (at least a feature request
> ;)) because some programs (LaTeX) would do this much better.
Yes.
> > And it would be nice if columns lined up as in first example above.
>
> The same. I believe this is a business for some post-processing
> program, since we just output a TSV lists.
Hmm, maybe we could provide a postprocessor.
Regards,
/Karl Hammar
-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
- Raw text -