Wrong parameter order in lists returned by object-fill

[Vladimir Zhbanov]

Currently, the object-fill function returns each angle parameters
after the corresponding pitch parameter in the list it outputs,
i.e. in a reverse order in comparison with what the file
format specification and geda-scheme.info say, and what gschem
actually outputs.

So "(caddr (object-fill box))" returns a pitch and
"(cadddr (object-fill box))" returns an angle.

The attached patch fixes this changing the order of these
parameters to the proper one.

The reason I put it here and don't commit it directly to the
repository is that there is a chance somebody uses this function
in his/her scripts, and I'm in doubt, whether we should support
bug-for-bug compatibility with previous versions or fix this.

[Peter TB Brett (peter-b)]

Hi Vladimir,

If set-object-fill! and object-fill are consistent (they appear to be), I think the correct thing to do is to preserve API compatibility and to update the documentation.

Thanks,

Peter

[Vladimir Zhbanov (vzhbanov)]

Hi Peter,
set-object-fill! and object-fill are consistent.
However, we cannot just update the documentation (at least the
sch/sym file format documentation since it reflects the current
file format in which gschem actually outputs data).

So I see two possible solutions:
1. do nothing with the sch/sym file format documentation and
   let users deal with this situation themselves;
   we might point them at how they have to obtain the object fill
   data in geda-scheme.info.
2. apply the patch and make a note somewhere in a release notes of
   a future version (and then probably wait for some blaming).

I'd prefer the second solution as I believe a stable API without
bugs is better than merely a stable API.

Thanks,
  Vladimir

[Peter TB Brett (peter-b)]

Hi Vladimir,

It's not important for the Scheme API to match the file format. Many of the API functions work differently to the file format (e.g. using symbols instead of magic numbers, etc.)

I'm not sure why you think the file format is relevant here. I certainly don't think that this is something that it's worth breaking API compatibility for.

Peter

[Vladimir Zhbanov (vzhbanov)]

Peter,
looking at dashlength and dashspace parameters of
"object-stroke-dash" I see the same picture. However, their order
in a list described in the 'geda-scheme.info' seems to be more
consistent than what has been chosen in the sch/sym file format.
Now I'm inclined to the opinion that you were right and we could
choose the first solution: simply fix the geda-scheme.info by
providing a more detailed description of an output list.

[Vladimir Zhbanov (vzhbanov)]

I wrote my last letter too long :)

Peter,
could you fix the info manual providing more detailed info on the fill settings, please?

Vladimir

[gpleda.org commit robot (gpleda-launchpad-robot)]

Bug was fixed by a commit
git master commit 55f875b134285aba81db0e0c339e9c97ae26886b
http://git.geda-project.org/geda-gaf/commit/?id=55f875b134285aba81db0e0c339e9c97ae26886b

commit 55f875b134285aba81db0e0c339e9c97ae26886b
Author: Peter TB Brett <email address hidden>
Commit: Peter TB Brett <email address hidden>

    scheme-api: Correct documentation of object-fill and set-object-fill!

    The object-fill and set-object-fill! use parameters with fill pitches
    ordered before angles. However, the documentation specified angles
    before pitches.

    Reported-by: Vladimir Zhbanov <email address hidden>
    Closes-bug: lp-1286117