wrote: > One function call in each direction: refdes, net, layer, footprint, = ... There is a need to access objects in different directions or = dimensions, there may also be a need for a notification to gui or = possible dbus then data have changed. >=20 > C or C++ is probably the first choice since it is very common although = I like Ada more. It=92s a lot easier to have a single, simple file format than an API for = for every language. Maybe multiple API=92s, representing different = approaches to the data (procedural, data-driven, =85). Some processing = tools naturally work on files and lack a foreign function interface = anyway. > The major difference for people wanting to parse things themselves is = that the fields have names, Depends on what language you=92re using. It will be different for = different APIs. Is it more convenient to encode x,y as some sort of = pair, or separate? Or are you being LISPy and going for positions within = lists anyway with cadadr et al.? > so you just read the name rather than digging through the spec You still have to dig through a document to figure out the name and how = the API presents it. But first, you have to find the specific document = for your specific API and try to verify that that API is up to date with = both the parser the actual file format. Instead of a single document = that=92s possibly out of date, you have a stack of them. > or running a little experiment to figure out which positional field is = which. With our existing .sch document I=92ve never had to do that. > In other words its easier for that purpose too. >=20 > Using an accessible format is entirely in keeping with the toolbox = philosophy which you normally advocate so strongly for in gEDA. Why = should pcb be the only program that can easily fully parse pcb files? Indeed. Why should the user ever need developer support (beyond = documentation for the file format) to do this? We have a poorly-documented shared C parser for geda-gaf files along = with a couple of different poorly-documented Scheme API=92s. However, we = have useful utilities in a variety of other languages. How is this = possible without a common parser? Simple: we have a format that=92s easy = to parse in pretty much everything. >=20 > Britton John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ jpd AT noqsi DOT com --Apple-Mail=_DFDAFCB8-84AF-4B2B-A08B-DCF94A0A0617 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

On Dec 26, 2015, at 9:04 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 Fri, Dec 25, 2015 at 12:13 PM, John Doty <jpd AT noqsi DOT com> wrote:

On Dec 25, 2015, at 1:38 = 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 Thu, Dec 24, = 2015 at 1:39 PM, John Doty <jpd AT noqsi DOT com> wrote:

On Dec 24, 2015, at = 12:53 PM, Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> = wrote:

Agreed. I like = YAML for this reason. You get a parser in every language for free, = without any other library material = required.
AWK? sed? grep? cut? = sort?

Why not? Unless = a newline in your regex really frightens you that = much...

Records = separated by newline with fields separated by whitespace is *better* = supported than YAML or any of the other candidates mentioned. The only = things it lacks for our purposes is a spiffy name and the need for extra = layers of lasagna = code.

Fine. Put your money = where your mouth is. Send me a full parser for pcb files with = binding for perl, python, ruby, C, and virtually every other extant = language.

I=92m not = talking about pcb. I=92m talking about = geda-gaf

Geda-gaf = is a much cleaner design. The pcb format doesn=92t even represent a = proper model of what a printed circuit board = is.

Writing a parser for geda-gaf files is = simpler than penetrating an API wrapping such a parser. That doesn=92t = mean you can do either in an = instant.

Highly = unlikely for .sch, no chance whatsoever for pcb. We're talking = about one function call in each direction form YAML/JSON. Not that = I would advocate doing anything to sch format.

It's easy so you should be able to get it to me = BEFORE your next bs email.
If having = common parser makes things so easy, you should be able to document API=92s=

I thought you were = the one who thought accessible file formats were a good idea, and = bundling big APIs around them not necessarily? So there's nothing = to document. Parsers are relatively easy but as you admit not = exactly instantaneous, so why not use a setup that obviates the need for = them?

That doesn=92t = seem to be what everyone is discussing.

On Dec = 27, 2015, at 3:47 AM, Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com<= /a>) [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> = wrote:

One function call in each = direction: refdes, net, layer, footprint, ... There is a need to = access objects in different directions or dimensions, there may = also be a need for a notification to gui or possible dbus then data = have changed.

C or C++ is probably the first choice since it is = very common although I like Ada = more.

It=92s a lot easier to have = a single, simple file format than an API for for every language. Maybe = multiple API=92s, representing different approaches to the data = (procedural, data-driven, =85). Some processing tools naturally work on = files and lack a foreign function interface = anyway.

The = major difference for people wanting to parse things themselves is that = the fields have names, =

Depends on what = language you=92re using. It will be different for different APIs. Is it = more convenient to encode x,y as some sort of pair, or separate? Or are = you being LISPy and going for positions within lists anyway with cadadr = et al.?

so you = just read the name rather than digging through the = spec

You still have = to dig through a document to figure out the name and how the API = presents it. But first, you have to find the specific document for your = specific API and try to verify that that API is up to date with both the = parser the actual file format. Instead of a single document that=92s= possibly out of date, you have a stack of = them.

or = running a little experiment to figure out which positional field is = which.

With our = existing .sch document I=92ve never had to do = that.

In = other words its easier for that purpose too.

Using an accessible format is = entirely in keeping with the toolbox philosophy which you normally = advocate so strongly for in gEDA. Why should pcb be the only = program that can easily fully parse pcb = files?

Indeed. Why = should the user ever need developer support (beyond documentation for = the file format) to do this?

We have a = poorly-documented shared C parser for geda-gaf files along with a couple = of different poorly-documented Scheme API=92s. However, we have useful = utilities in a variety of other languages. How is this possible without = a common parser? Simple: we have a format that=92s easy to parse in = pretty much everything.

Britton

John = Doty = Noqsi = Aerospace, Ltd.

http://www.noqsi.com/

jpd AT noqsi DOT com

= --Apple-Mail=_DFDAFCB8-84AF-4B2B-A08B-DCF94A0A0617-- --Apple-Mail=_C35E6EC2-FEB5-4CE1-A306-777202CE407A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWf/2LAAoJEF1Aj/0UKykRqyMQAKx8fgaN/j4nIq2vLyW7CaKW XBYGir6ZP/6OGy4yQi+TLx2qWpVz7l22x7RL8cTX+SIF4quJb6G0S6MbHNMWC0er AutGtswMUr0OAG/JygIYcClSdcZ4sC7atGN4vIMejsmr3Hz5q+Zpk+eaF1UnA48U GnNWau+V9IvPhS2Qvp8rHo3VPRsly/YwL2v3OhUJIJx8E2MUTZQMrVbCz1rYDH/u +6PLnVg7hX9DkKxXrquJSeiWA/kGbQhQc2d831AiPWE0oMct6YjVp4j84rL1Dfg6 hBpthdi7lKGLldWduIxNYMJOgdgzTrXGKoQnCitB4oxko/rTX2xXBvDthJMzX0Wd Tgutu5roqc7gDs6gdjP9jAp0g5RwpkBJq+o4RqSMc/Ciyc2iuXhzSFFLqlCaNJj5 Nej/nogKAFC5xHVpZgmcIZZ4D0z5funBB4gIOJLLPrEdkYJAMYZs2g58cBMiRVQf OAOzVeRWUU0DeyzZyi3HFvkD2GRlezo+zN5NcclzktoMYl0NHWZXsGiDfkm0a128 NLElfsHXR03GtWTuJ1OwLH35O6tRJJDvMoGMs6z1zML26guJ9bQWk3JzeOlekNI1 eliKFxga29WRSU6NjGFVlWSzFCWVs7P9+35LxF3WdQefkYB8w/iqwruekZdHzC51 aVb5IGXf/WLuHQbxX9l0 =enwL -----END PGP SIGNATURE----- --Apple-Mail=_C35E6EC2-FEB5-4CE1-A306-777202CE407A--