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 <[email protected]> > 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 >>> <[email protected]> wrote: >>>> nice!!!, I will start trying it. >>>> >>>> >>>> 2012/4/7 Wayne Stambaugh <[email protected]> >>>>> >>>>> 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 : [email protected] >>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>> More help : https://help.launchpad.net/ListHelp >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>> Post to : [email protected] >>>>> 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 : [email protected] >>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> More help : https://help.launchpad.net/ListHelp >>>> >>> > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
