| delorie.com/archives/browse.cgi | search |
--001a114242a4d7555805288790f5 Content-Type: text/plain; charset=UTF-8 On Sun, Jan 3, 2016 at 6:25 PM, John Doty <jpd AT noqsi DOT com> wrote: > > On Jan 3, 2016, at 7:11 PM, Britton Kerin (britton DOT kerin AT gmail DOT com) [via > geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote: > > > On Sun, Jan 3, 2016 at 7:38 AM, Nicklas Karlsson ( > nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com] < > geda-user AT delorie DOT com> wrote: > >> > As I've mentioned previously I'm talking pcb, which is a more painful >> > format to parse (such that so far as I'm aware the parser in pcb is the >> > only one). Personally I find formats like this: >> > >> > device=RESISTOR >> > T 44400 49300 5 10 1 1 90 0 1 >> > >> > substantially less readable than ones with field names, but they are >> indeed >> > easy to parse. The pcb format is quite a bit more elaborate and the >> > savings from not rolling your own parser are more significant. >> >> Yes this is simple to parse, use little file space but do not have field >> name. To use little file space and be simple to parse is actually two good >> properties of a file format. >> >> Lack of field names may be worked around by having a list of field names >> in the beginning. If this list of field names is sorted according to how >> often they are used and each row only have to list used values it would >> probably be a file format with rather good properties. >> >> To enumerate the field names at the beginning of the file may also be a >> solution. Or maybe to use representation of data structures from a >> programming language. >> > > Although these are good measures, once you adopt them you may start asking > yourself why you aren't just using a binary format. The argument for text > is that you can glance at a chunk of it and easily tell what's going on. > > > A stronger argument for text is that you can process it with text-oriented > tools. > But ultimately the reason for wanting to use those text-oriented tools is the same: you can see what you're working on with your own eyes. In every other respect binary is better. --001a114242a4d7555805288790f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= te">On Sun, Jan 3, 2016 at 6:25 PM, John Doty <span dir=3D"ltr"><<a href= =3D"mailto:jpd AT noqsi DOT com" target=3D"_blank">jpd AT noqsi DOT com</a>></span> wr= ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border= -left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word">= <br><div><span class=3D""><div>On Jan 3, 2016, at 7:11 PM, Britton Kerin (<= a href=3D"mailto:britton DOT kerin AT gmail DOT com" target=3D"_blank">britton DOT kerin AT g= mail.com</a>) [via <a href=3D"mailto:geda-user AT delorie DOT com" target=3D"_blan= k">geda-user AT delorie DOT com</a>] <<a href=3D"mailto:geda-user AT delorie DOT com" = target=3D"_blank">geda-user AT delorie DOT com</a>> wrote:</div><br><blockquote= type=3D"cite"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class= =3D"gmail_quote">On Sun, Jan 3, 2016 at 7:38 AM, Nicklas Karlsson (<a href= =3D"mailto:nicklas DOT karlsson17 AT gmail DOT com" target=3D"_blank">nicklas.karlsson= 17 AT gmail DOT com</a>) [via <a href=3D"mailto:geda-user AT delorie DOT com" target=3D"_= blank">geda-user AT delorie DOT com</a>] <span dir=3D"ltr"><<a href=3D"mailto:g= eda-user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com</a>></span= > wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex">> As I've mentioned previ= ously I'm talking pcb, which is a more painful<br> > format to parse (such that so far as I'm aware the parser in pcb i= s the<br> > only one).=C2=A0 Personally I find formats like this:<br> <span>><br> >=C2=A0 =C2=A0device=3DRESISTOR<br> >=C2=A0 =C2=A0T 44400 49300 5 10 1 1 90 0 1<br> ><br> </span><span>> substantially less readable than ones with field names, b= ut they are indeed<br> </span>> easy to parse.=C2=A0 The pcb format is quite a bit more elabora= te and the<br> <span>> savings from not rolling your own parser are more significant.<b= r> <br> </span>Yes this is simple to parse, use little file space but do not have f= ield name. To use little file space and be simple to parse is actually two = good properties of a file format.<br> <br> Lack of field names may be worked around by having a list of field names in= the beginning. If this list of field names is sorted according to how ofte= n they are used and each row only have to list used values it would probabl= y be a file format with rather good properties.<br> <br> To enumerate the field names at the beginning of the file may also be a sol= ution. Or maybe to use representation of data structures from a programming= language.<br></blockquote><div><br></div><div>Although these are good meas= ures, once you adopt them you may start asking yourself why you aren't = just using a binary format.=C2=A0 The argument for text is that you can gla= nce at a chunk of it and easily tell what's going on.</div></div></div>= </div></blockquote><div><br></div></span>A stronger argument for text is th= at you can process it with text-oriented tools.</div></div></blockquote><di= v><br></div><div style=3D"">But ultimately the reason for wanting to use th= ose text-oriented tools is the same: you can see what you're working on= with your own eyes.=C2=A0 In every other respect binary is better.=C2=A0</= div><div style=3D""><br></div></div></div></div> --001a114242a4d7555805288790f5--
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |