kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 4/9/2012 1:50 PM, lajos kamocsay wrote:
> Hi Wayne-
> 
> 
> I've had a conversation with Dick, and he asked me to clarify my
> suggestion about standardizing the transformation data.
> 
> Standardizing would save you work and debugging time because you would
> only need to write the encoder and decoder (parser) once. Instead of
> every object taking care of the work, they could just call two
> external functions (I don't have the code with me, but let's say
> S_EXPR::EncodeTransformation() and S_EXPR::DecodeTransformation()).
> The same functions could read/write transformation data for modules,
> pads, polygon points etc.
> 
> As a side effect, the data files would be easier to read and write.
> And I don't necessarily mean footprint makers, but opening the brd
> files in emacs. But this is just bonus, the biggest win is less coding
> and more decoupling.
> 
> You don't need to pick 1d vs 2d vs 3d vectors. It can easily be a
> mixture, for example:
> 
> (object
>   (position (vector2 1 1))
>   (rotation (vector1 1))
>   (scale (vector1 1))
> )
> 
> If certain properties are default value, you might not even need to
> write them (no rotation, 100% scale):
> 
> (object
>   (position (vector3 1 1 1))
> )
> 
> You could also separate out the vector encoder and decoder functions,
> like S_EXPR::EncodeVector3() and S_EXPR::DecodeVector3(). (Again, I
> don't have the code with me, so class and function names are just
> examples, and possibly this is how it's already implemented.)
> 
> Naming is a secondary issue, point3 vs vector3 vs xyz doesn't matter
> much (although point or vector seems a bit more generic and reusable).

I don't have a problem with this but Dick has already invested time
writing SWEET using the "at" convention and I wrote the SWEET and new
schematic file format documentation using this notation.  It would
require some effort to update the code and documentation.

Wayne

> 
> 
> 
> 
> Thanks-
> -lajos
> 
> 
> 
> 
> On Mon, Apr 9, 2012 at 10:45 AM, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
>> On 4/8/2012 12:38 PM, lajos kamocsay wrote:
>>> Hi Wayne-
>>>
>>>
>>> The new file format looks awesome. Very simple and readable.
>>>
>>> Would it be possible to standardize the transformation data? Currently
>>> there seems to be a couple different formats, some examples:
>>>
>>>  (draw line (pts xy(76.581 47.9425) xy(77.724 47.9425)) (layer 21)
>>> (width 0.127))
>>>
>>>  (size 1.016 1.651)
>>>
>>>  (at -1.524 0)
>>>
>>>  (at (xyz 0 0 0))
>>>  (scale (xyz 0.17 0.16 0.16))
>>>  (rotate (xyz 0 0 0))
>>>
>>> I think having a standard format would be very helpful for external
>>> utilities reading/writing kicad data, like:
>>>
>>> (object
>>>  (position xyz(1, 1, 1))
>>>  (rotation xyz(0, 0, 0))
>>>  (scale xyz(1, 1, 1))
>>> )
>>
>> Lajos,
>>
>> Thank you for your comments.  I carried over the "at" token from the new
>> schematic and schematic library file formats.  For 2D transforms I want
>> to keep this notation so that it is the same between the schematic and
>> board file formats.  I'm fine with using a different notation for 3D
>> transforms.  My original though was just to use (scale X Y Z) since this
>> is inside a 3D object it may clear enough to the user that 3D transforms
>> require XYZ.
>>
>>>
>>> Or if you want shorter names, you could use the p/r/s letters for
>>> position/rotation/scale or t/s/r for translation/rotation/scale and v3
>>> for a 3d vector:
>>>
>>> (object
>>>  (t v3(1, 1, 1))
>>>  (r v3(0, 0, 0))
>>>  (s v3(1, 1, 1))
>>> )
>>
>> I want to avoid abbreviations that are not obvious.  The file format
>> must be human readable not developer readable.  Most of the developers
>> will know what t/r/s means but a normal user shouldn't be expected to
>> wade thought the source code to find out what t/r/s means.  The goal is
>> the minimum verbosity to achieve human readability.
>>
>> Thanks,
>>
>> Wayne
>>
>>>
>>> Although nowadays storage is usually not an issue, and the file can be
>>> optionally compressed with zlib. So probably the more verbose names
>>> are better. One of the small boards I saved was 28k in the old format,
>>> 52k with s-expr, 6k s-expr compressed.
>>>
>>> Another alternative would be a 3x3 matrix:
>>>
>>> (object
>>>  (transform matrix(1, 1, 1, 0, 0, 0, 1, 1, 1))
>>> )
>>>
>>>
>>>
>>> Thanks-
>>> -lajos
>>>
>>>
>>>
>>>
>>> On Sat, Apr 7, 2012 at 2:58 PM, Miguel Angel Ajo Pelayo
>>> <miguelangel@xxxxxxx> wrote:
>>>> nice!!!, I will start trying it.
>>>>
>>>>
>>>> 2012/4/7 Wayne Stambaugh <stambaughw@xxxxxxxxxxx>
>>>>>
>>>>> Oops!  To be able to save to the new file format you must add
>>>>> -DUSE_PCBNEW_SEXPR_FILE_FORMAT=ON and -DUSE_PCBNEW_NANOMETRES=ON when
>>>>> invoking CMake in order to build the new code.
>>>>>
>>>>> On 4/7/2012 2:09 PM, Wayne Stambaugh wrote:
>>>>>> It took long than I anticipated (doesn't always?) but I just committed
>>>>>> the code to allow saving board files to the new s-expression based file
>>>>>> format.  I would like as many folks as possible to save their favorite
>>>>>> board file using File->Save As to the new format and take a look at the
>>>>>> result.  My goal is to get the final file format nailed down as quickly
>>>>>> as possible.  There are few caveats:
>>>>>>
>>>>>> * I still have to convert angles to degrees from the current tenths of
>>>>>> degrees so please ignore the fact that 270° is saved as 2700°.  This fix
>>>>>> is coming soon.
>>>>>>
>>>>>> * The lead developers have decided to drop support for the old segment
>>>>>> filled zones (SEGZONES) which have not been used in quite some time.  I
>>>>>> will be adding a dialog warning the user that they will need to refill
>>>>>> their zones using the current polygon filling.  I doubt this will effect
>>>>>> very many users but I could be wrong.
>>>>>>
>>>>>> * I rearranged the object ordering slightly compared to the current file
>>>>>> format.  I moved the graphic items (items with no net connection) before
>>>>>> the modules.  This way all of the net connectable objects (modules,
>>>>>> traces, zones, etc.) will be grouped together.
>>>>>>
>>>>>> Please take some time to look over the new format.  If you find a token
>>>>>> (key word) that is not clear, let me know so we can choose names that
>>>>>> are as human readable as possible.  Please keep in mind that the file
>>>>>> size is going to increase dramatically over the current format so try to
>>>>>> keep names as brief as possible while still maintaining readability.
>>>>>> Also, if you find any indentation or other formatting errors, let me
>>>>>> know so I can fix it.  I will be working on reading the new file format
>>>>>> over the next few days (weeks?) so I would like to wrap up the file
>>>>>> format definition in a reasonable amount of time.  Thanks in advance for
>>>>>> you help.
>>>>>>
>>>>>> Wayne
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Miguel Angel Ajo Pelayo
>>>> http://www.nbee.es
>>>> +34 636 52 25 69
>>>> skype: ajoajoajo
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>
>