delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/01/06/07:36:29

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-TCPREMOTEIP: 63.119.35.194
X-Authenticated-UID: jpd AT noqsi DOT com
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [geda-user] A fileformat library
X-Pgp-Agent: GPGMail 2.5.2
From: John Doty <jpd AT noqsi DOT com>
In-Reply-To: <CACwWb3CcsYJ9KgDFAa5pZqDzfTewhvbuatbxoKUp6PtHRCoa+w@mail.gmail.com>
Date: Wed, 6 Jan 2016 07:36:18 -0500
Message-Id: <6C2FA19B-9B5C-4F6E-841C-4C3031BF9D2D@noqsi.com>
References: <1512221837 DOT AA25291 AT ivan DOT Harhan DOT ORG> <CAJXU7q_qxdvJaejF-VcY=u7VHZ-zrfrc+Z7-qSwfFyPdy-umxw AT mail DOT gmail DOT com> <B02363CD-469D-493A-AC15-1D5DC7836982 AT noqsi DOT com> <20151222232230 DOT 12633 DOT qmail AT stuge DOT se> <0F6F1D0F-4F07-48EA-90FE-836EAD4E2354 AT noqsi DOT com> <CAM2RGhTficnys3a4xs=UBFvk8aPwpzYWUADFLP_pUQ+R1iKs0g AT mail DOT gmail DOT com> <0FCF3774-F93C-4BFF-BB61-636F75DCCACB AT noqsi DOT com> <CAC4O8c_UAiFE-vGfoE2tXppHLhaa0dSYz9o_rkdCBo7_SRRtxw AT mail DOT gmail DOT com> <FFBE7623-E240-4798-96B0-2BECF56C8E29 AT noqsi DOT com> <CAC4O8c980g1gj15=5njstC_BT-WYDgKQx9BRycdFKA8OvgtiOg AT mail DOT gmail DOT com> <B54C0E1F-1986-4C79-9F70-7F1919B8B26D AT noqsi DOT com> <CAC4O8c9bxJP1eMG4yz3YwKkQJRmsDGmLQ0aMd5pJRyu0WpdCtQ AT mail DOT gmail DOT com> <C1CFCCEE-C64A-4E49-AA64-446C061656D6 AT noqsi DOT com> <CAC4O8c-zt8B=joDd+ws77D2jt6aZf3MWfR_dAvpzGcNuBrTURQ AT mail DOT gmail DOT com> <alpine DOT DEB DOT 2 DOT 11 DOT 1601030040320 DOT 2176 AT newt> <D9825C8C-B6FD-4C7F-A8D5-B8AF06253B72 AT noqsi DOT com> <CAC4O8c_R5xWLmzj_cz0g0mPWNs6mR4efjXKGBoup8YO6nwnPTA AT mail DOT gmail DOT com> <CAC4O8c8zk8=Py1yX6fVqF+35SYe39Li=!
y4jZ8bCeZ1Ev8WccAg AT mail DOT gmail DOT com> <20160105182120 DOT 3237F809D79B AT turkos DOT aspodata DOT se> <CAC4O8c8cVr1H3skmbGo4Rhf5ZTZj8bDxJw8a9C4qfHeGyXZ4XA AT mail DOT gmail DOT com> <20160106091006 DOT 5F67B809D7A1 AT turkos DOT aspodata DOT se> <CACwWb3CcsYJ9KgDFAa5pZqDzfTewhvbuatbxoKUp6PtHRCoa+w AT mail DOT gmail DOT com>
To: geda-user AT delorie DOT com
X-Mailer: Apple Mail (2.1878.6)
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

--Apple-Mail=_9DE033FE-F627-441A-9D43-DA9634BB4DDA
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_54402707-1FBE-4453-A9BE-B3C6C50F8B05"


--Apple-Mail=_54402707-1FBE-4453-A9BE-B3C6C50F8B05
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Jan 6, 2016, at 4:58 AM, Levente (leventelist AT gmail DOT com) [via =
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:

>=20
>=20
> You can have any difftool for git, so you can do visual diffs or =
anything what you want, independent of the file format. (as of today, we =
HAVE visual diff for PCB)

And then what do you do with a broken file, with a little bit of garbled =
data in it? Text is more robust.

> You can write your own script in whatever language, as long as it has =
bindings for the file format,

But that=92s more work.

> which is the case.

Not for every language. Certainly not for every text utility.

>=20
> When selecting a file format I would not have such constraints like =
"it should be pretty for a human eye=94.

Not pretty, but comprehensible without processing.

> CAD data is so complex, that one can (and I believe should not) parse =
them with naked eye. For a computer, binary is much more efficient.

It=92s more efficient until something breaks (and something always =
breaks). I note that Mathematica, an enormous, complex program, saves =
its files as text. And every once in a while a rare bug garbles such a =
file. Sometimes they advise =93search for a line like =85 and delete it=94=
 as a recovery strategy.

It=92s more efficient if you never want to use text-oriented tools, but =
for files with lots of text data, like attributes and file names, I =
generally want to use text tools to solve some problems. There are =
thousands of tiny problems that you can efficiently address in this way.

>=20
> So I still prefer the SQLite database, as that library is optimized =
for our purpose. Yes, I prefer to have a library, that parses our files, =
and gives us the possibility to use, or modify the data.

No, it gets in the way of using and modifying the data, as then you =
*must* got through the library with all of its limitations.

> I prefer this way because we have approx. 50 different implementation =
of pcb/gschem file parser.

So what? If you have one parser, then you get 50 different =
implementations of the interface to its API. You only move the problem =
to a more difficult layer.

> There is one in pcb/gaf, and all the other power users wrote their =
own. It would be much better to write the parser once, and other could =
use that.

Why is it better? I think that is an illusion.

> If file format changes, you have to just change one code, and not 50+.

Not true, because the only sane reason to change the format is to change =
something in the semantics. That means that your common parser=92s API =
will have to change, and everything that uses it will have to =
accommodate that change.

>=20
> If we use a standard file format (SQL, YAML, JSON), the parsing =
library could be very thin.

But it will still get in the way.

> The independent parsing code is already written. Only the application =
(gEDA) specific code has to be written. Remember, all of us has very =
limited time to contribute code to gEDA nowadays.

That=92s why we should not be adding extra, unnecessary layers. That=92s =
why we should not be breaking our existing tools and scripts.

>=20
> Lev
>=20
> On Wed, Jan 6, 2016 at 10:10 AM, <karl AT aspodata DOT se> wrote:
> Britton Kerin:
> > On Tue, Jan 5, 2016 at 9:21 AM, <karl AT aspodata DOT se> wrote:
> > > Britton Kerin:
> > > > On Sun, Jan 3, 2016 at 6:25 PM, John Doty <jpd AT noqsi DOT com> wrote:
> > > ...
> > > > > 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.
> > >
> > > I counter that.
> > > . you have to check a binary file for valid values just as you do =
for a
> > >   text file
>=20
> You have not commented this point. Any reader, human or program, have
> to verify its input. Just because you have a binary file you can't =
just
> do
>=20
>  struct some_struct_type data;
>  read(fd, data, sizeof(struct some_struct_type))
>=20
> and pretend that data will contain valid values.
>=20
> > > . if your binary file is in some way invalid, you will have a =
greater
> > >   problem correcting it than a text file
> > > . discussing why a file is invalid is easier with a text file
> > > . a binary file might be smaller, but that does not matter much
> > > . text files are better provided for by version systems (e.g. git)
> > > . it is easier to write tools that write text than binary, because
> > >   debugging the output is easier
> > Regarding vcs of text data files for GUI program, it's a stretch to =
claim
> > that the fact that they're text makes them much more compatible.  =
The diffs
> > are only useful for the most trivial of cases.
>=20
> You used the word "better", now are you judging things around
> "compatible". What do you want ?
> If you want "compatible", then compatible to what ?
>=20
> I write a sym/fp-generators and I prefer text output; I can check the
> output both "textually" and "visually".
>=20
> The diffs out the output of thoose generators are valueable when
> debugging.
>=20
> You might think of gschem and pcb as gui programs, but there is
> ifrastructure around them which is not gui. Don't think about their =
files
> in the same way as a png or jpg, where the fileformats are well
> entrenched and infrastructure is available.
>=20
> >  For it to be really useful
> > you need a (non-text) diff viewer of  some sort.
>=20
> A graphical-diff is provided by
>=20
>  http://www.imagemagick.org/Usage/compare/
>=20
> You can generate png's from sch/pcb files and use that program for
> graphical-diffs.
>=20
> It would be very useful for regression tests, other projects have been
> successful at that.
>=20
> > All the rest of the above still boil down to examples of things that =
are
> > easier because you can see the data, and therefore manipulate and =
validate
> > it more easily.
>=20
> No, validate input and size, is not about "easier to see".
>=20
> But...
> Why do you want to remove the text format for me ?
> What are your complaint of having a textual file format ?
>=20
> By dropping the text you loose something, what is the gain of a binary
> format that outweights that ?
>=20
> > > Also, there is no reason to change a file format unless you change =
the
> > > functionality it provides, I have to "side heavily" with John on =
this.
> > > If you want to change the file format, you first have to provide =
some
> > > goodies that will make people to accept it. And no such "goodie"
> > > thing has appeared.
> > A little while back a PhD Stefan Salewski put together a very good =
start on
> > a very nice router.  IIRC he said 300-400 hours of effort, probably =
about
> > $100k worth with overhead in the american market.  It's not C (for =
good
> > reasons) and currently can't talk to pcb at all.  I would like to =
somehow
> > arrange things such than efforts like this could maybe get used.
>=20
> In what way does his work relate to a decision about text contra =
binary
> file format.
>=20
> > > You might write a library that reads and writes the files and if =
people
> > > find it useful, they will start using it, else, it will be just =
your own
> > > project.
> > True.  It might be useless but should at least be non-destructive.
>=20
> I thought you are for a fileformat library. I'm I wrong ?
> But now you say that such a library is useless. Did I get that right ?
>=20
> I think a fileformat library would be useful, but I still
> would like a textual format for sch/sym/pcb/fp files.
>=20
> Regards,
> /Karl Hammar
>=20
> =
-----------------------------------------------------------------------
> Asp=F6 Data
> Lilla Asp=F6 148
> S-742 94 =D6sthammar
> Sweden
> +46 173 140 57
>=20
>=20
>=20

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com



--Apple-Mail=_54402707-1FBE-4453-A9BE-B3C6C50F8B05
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On Jan 6, 2016, at 4:58 AM, Levente =
(<a href=3D"mailto:leventelist AT gmail DOT com">leventelist AT gmail DOT com</a>) =
[via <a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] =
&lt;<a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>&gt;=
 wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div =
dir=3D"ltr"><div><div><div><div><div><div><br></div><br></div>You can =
have any difftool for git, so you can do visual diffs or anything what =
you want, independent of the file format. (as of today, we HAVE visual =
diff for =
PCB)<br></div></div></div></div></div></blockquote><div><br></div>And =
then what do you do with a broken file, with a little bit of garbled =
data in it? Text is more robust.</div><div><br><blockquote =
type=3D"cite"><div dir=3D"ltr"><div><div><div>You can write your own =
script in whatever language, as long as it has bindings for the file =
format, </div></div></div></div></blockquote><div><br></div><div>But =
that=92s more work.</div><div><br></div><blockquote type=3D"cite"><div =
dir=3D"ltr"><div><div><div>which is the =
case.<br></div></div></div></div></blockquote><div><br></div></div><div>No=
t for every language. Certainly not for every text =
utility.</div><div><br><blockquote type=3D"cite"><div =
dir=3D"ltr"><div><div><div><br></div>When selecting a file format I =
would not have such constraints like "it should be pretty for a human =
eye=94. </div></div></div></blockquote><div><br></div>Not pretty, but =
comprehensible without processing.</div><div><br><blockquote =
type=3D"cite"><div dir=3D"ltr"><div><div>CAD data is so complex, that =
one can (and I believe should not) parse them with naked eye. For a =
computer, binary is much more =
efficient.<br></div></div></div></blockquote><div><br></div>It=92s more =
efficient until something breaks (and something always breaks). I note =
that Mathematica, an enormous, complex program, saves its files as text. =
And every once in a while a rare bug garbles such a file. Sometimes they =
advise =93search for a line like =85 and delete it=94 as a recovery =
strategy.</div><div><br></div><div>It=92s more efficient if you never =
want to use text-oriented tools, but for files with lots of text data, =
like attributes and file names, I generally want to use text tools to =
solve some problems. There are thousands of tiny problems that you can =
efficiently address in this way.</div><div><br><blockquote =
type=3D"cite"><div dir=3D"ltr"><div><div><br></div>So I still prefer the =
SQLite database, as that library is optimized for our purpose. Yes, I =
prefer to have a library, that parses our files, and gives us the =
possibility to use, or modify the =
data.</div></div></blockquote><div><br></div>No, it gets in the way of =
using and modifying the data, as then you *must* got through the library =
with all of its limitations.</div><div><br><blockquote type=3D"cite"><div =
dir=3D"ltr"><div> I prefer this way because we have approx. 50 different =
implementation of pcb/gschem file parser. =
</div></div></blockquote><div><br></div>So what? If you have one parser, =
then you get 50 different implementations of the interface to its API. =
You only move the problem to a more difficult =
layer.</div><div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div>There=
 is one in pcb/gaf, and all the other power users wrote their own. It =
would be much better to write the parser once, and other could use that. =
</div></div></blockquote><br>Why is it better? I think that is an =
illusion.</div><div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div>If=
 file format changes, you have to just change one code, and not =
50+.<br></div></div></blockquote><div><br></div>Not true, because the =
only sane reason to change the format is to change something in the =
semantics. That means that your common parser=92s API will have to =
change, and everything that uses it will have to accommodate that =
change.</div><div><br><blockquote type=3D"cite"><div =
dir=3D"ltr"><div><br></div><div>If we use a standard file format (SQL, =
YAML, JSON), the parsing library could be very thin. =
</div></div></blockquote><div><br></div>But it will still get in the =
way.</div><div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div>The =
independent parsing code is already written. Only the application (gEDA) =
specific code has to be written. Remember, all of us has very limited =
time to contribute code to gEDA =
nowadays.<br></div></div></blockquote><div><br></div>That=92s why we =
should not be adding extra, unnecessary layers. That=92s why we should =
not be breaking our existing tools and =
scripts.</div><div><br><blockquote type=3D"cite"><div =
dir=3D"ltr"><div><br></div>Lev<br></div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Jan 6, 2016 =
at 10:10 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:karl AT aspodata DOT se" =
target=3D"_blank">karl AT aspodata DOT se</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">Britton Kerin:<br>
<span class=3D"">&gt; On Tue, Jan 5, 2016 at 9:21 AM, &lt;<a =
href=3D"mailto:karl AT aspodata DOT se">karl AT aspodata DOT se</a>&gt; wrote:<br>
&gt; &gt; Britton Kerin:<br>
&gt; &gt; &gt; On Sun, Jan 3, 2016 at 6:25 PM, John Doty &lt;<a =
href=3D"mailto:jpd AT noqsi DOT com">jpd AT noqsi DOT com</a>&gt; wrote:<br>
&gt; &gt; ...<br>
&gt; &gt; &gt; &gt; Although these are good measures, once you adopt =
them you may start<br>
&gt; &gt; asking<br>
&gt; &gt; &gt; &gt; yourself why you aren't just using a binary =
format.&nbsp; The argument for<br>
&gt; &gt; text<br>
&gt; &gt; &gt; &gt; is that you can glance at a chunk of it and easily =
tell what's going<br>
&gt; &gt; on.<br>
&gt; &gt; &gt; &gt; A stronger argument for text is that you can process =
it with<br>
&gt; &gt; text-oriented<br>
&gt; &gt; &gt; &gt; tools.<br>
&gt; &gt; &gt; But ultimately the reason for wanting to use those =
text-oriented tools is<br>
&gt; &gt; &gt; the same: you can see what you're working on with your =
own eyes.&nbsp; In<br>
&gt; &gt; every<br>
&gt; &gt; &gt; other respect binary is better.<br>
&gt; &gt;<br>
&gt; &gt; I counter that.<br>
&gt; &gt; . you have to check a binary file for valid values just as you =
do for a<br>
&gt; &gt;&nbsp; &nbsp;text file<br>
<br>
</span>You have not commented this point. Any reader, human or program, =
have<br>
to verify its input. Just because you have a binary file you can't =
just<br>
do<br>
<br>
&nbsp;struct some_struct_type data;<br>
&nbsp;read(fd, data, sizeof(struct some_struct_type))<br>
<br>
and pretend that data will contain valid values.<br>
<span class=3D""><br>
&gt; &gt; . if your binary file is in some way invalid, you will have a =
greater<br>
&gt; &gt;&nbsp; &nbsp;problem correcting it than a text file<br>
&gt; &gt; . discussing why a file is invalid is easier with a text =
file<br>
&gt; &gt; . a binary file might be smaller, but that does not matter =
much<br>
&gt; &gt; . text files are better provided for by version systems (e.g. =
git)<br>
&gt; &gt; . it is easier to write tools that write text than binary, =
because<br>
&gt; &gt;&nbsp; &nbsp;debugging the output is easier<br>
&gt; Regarding vcs of text data files for GUI program, it's a stretch to =
claim<br>
&gt; that the fact that they're text makes them much more =
compatible.&nbsp; The diffs<br>
&gt; are only useful for the most trivial of cases.<br>
<br>
</span>You used the word "better", now are you judging things around<br>
"compatible". What do you want ?<br>
If you want "compatible", then compatible to what ?<br>
<br>
I write a sym/fp-generators and I prefer text output; I can check =
the<br>
output both "textually" and "visually".<br>
<br>
The diffs out the output of thoose generators are valueable when<br>
debugging.<br>
<br>
You might think of gschem and pcb as gui programs, but there is<br>
ifrastructure around them which is not gui. Don't think about their =
files<br>
in the same way as a png or jpg, where the fileformats are well<br>
entrenched and infrastructure is available.<br>
<span class=3D""><br>
&gt;&nbsp; For it to be really useful<br>
&gt; you need a (non-text) diff viewer of&nbsp; some sort.<br>
<br>
</span>A graphical-diff is provided by<br>
<br>
&nbsp;<a href=3D"http://www.imagemagick.org/Usage/compare/" =
rel=3D"noreferrer" =
target=3D"_blank">http://www.imagemagick.org/Usage/compare/</a><br>
<br>
You can generate png's from sch/pcb files and use that program for<br>
graphical-diffs.<br>
<br>
It would be very useful for regression tests, other projects have =
been<br>
successful at that.<br>
<span class=3D""><br>
&gt; All the rest of the above still boil down to examples of things =
that are<br>
&gt; easier because you can see the data, and therefore manipulate and =
validate<br>
&gt; it more easily.<br>
<br>
</span>No, validate input and size, is not about "easier to see".<br>
<br>
But...<br>
Why do you want to remove the text format for me ?<br>
What are your complaint of having a textual file format ?<br>
<br>
By dropping the text you loose something, what is the gain of a =
binary<br>
format that outweights that ?<br>
<span class=3D""><br>
&gt; &gt; Also, there is no reason to change a file format unless you =
change the<br>
&gt; &gt; functionality it provides, I have to "side heavily" with John =
on this.<br>
&gt; &gt; If you want to change the file format, you first have to =
provide some<br>
&gt; &gt; goodies that will make people to accept it. And no such =
"goodie"<br>
&gt; &gt; thing has appeared.<br>
&gt; A little while back a PhD Stefan Salewski put together a very good =
start on<br>
&gt; a very nice router.&nbsp; IIRC he said 300-400 hours of effort, =
probably about<br>
&gt; $100k worth with overhead in the american market.&nbsp; It's not C =
(for good<br>
&gt; reasons) and currently can't talk to pcb at all.&nbsp; I would like =
to somehow<br>
&gt; arrange things such than efforts like this could maybe get =
used.<br>
<br>
</span>In what way does his work relate to a decision about text contra =
binary<br>
file format.<br>
<span class=3D""><br>
&gt; &gt; You might write a library that reads and writes the files and =
if people<br>
&gt; &gt; find it useful, they will start using it, else, it will be =
just your own<br>
&gt; &gt; project.<br>
&gt; True.&nbsp; It might be useless but should at least be =
non-destructive.<br>
<br>
</span>I thought you are for a fileformat library. I'm I wrong ?<br>
But now you say that such a library is useless. Did I get that right =
?<br>
<br>
I think a fileformat library would be useful, but I still<br>
would like a textual format for sch/sym/pcb/fp files.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
Regards,<br>
/Karl Hammar<br>
<br>
=
-----------------------------------------------------------------------<br=
>
Asp=F6 Data<br>
Lilla Asp=F6 148<br>
S-742 94 =D6sthammar<br>
Sweden<br>
<a href=3D"tel:%2B46%20173%20140%2057" value=3D"+4617314057">+46 173 140 =
57</a><br>
<br>
<br>
</div></div></blockquote></div><br></div>
</blockquote></div><br><div apple-content-edited=3D"true">
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px;"><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">John =
Doty<span class=3D"Apple-converted-space">&nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;<span class=3D"Apple-converted-space">&nbsp;</span><span =
class=3D"Apple-converted-tab">&nbsp; &nbsp;<span =
class=3D"Apple-converted-space">&nbsp;</span></span></span>Noqsi =
Aerospace, Ltd.</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><a href=3D"http://www.noqsi.com/">http://www.noqsi.com/</a></p><p =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica"><a =
href=3D"mailto:jpd AT noqsi DOT com">jpd AT noqsi DOT com</a></font></p><br =
class=3D"Apple-interchange-newline"></span>
</div>
<br></body></html>=

--Apple-Mail=_54402707-1FBE-4453-A9BE-B3C6C50F8B05--

--Apple-Mail=_9DE033FE-F627-441A-9D43-DA9634BB4DDA
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

iQIcBAEBCgAGBQJWjQpDAAoJEF1Aj/0UKykRJOAP/jBHbsSFSzYD1rhJP5oz7BB9
8RTBhhuknQWJVRkO+ztXFIFTsW12iSUrH6eutPruQsF7WHmtg032AJQnCSJeVSbS
jlnS9vMIL251yhjTogcDlOCc9xxSpJvruuRhYJ4GXOp3R970nG8TFZPoZ4ZUj4n+
mGqTKhZlwS3t4XbbmVyKOA0InmVMvJarQNW3ku0BSNNa8dxLtA43EYCLvzOF8L5/
BHpjXTx2DcOjEsBMVzP6Ri8dCNKoALkKejJwx23e+8sl68z7cvCtUswq4zHdrUOk
rAw7lrW8DVoImY6qc1uCZpitJIyoPonNnb7BKCWuWruPIjz7lNXdrD8XlPa+DQsp
a1FjqYI/94f40zdveProq56v/+GVxonoJ8XWkzRJihw7dj215sszI3EBCtFMwog9
+OTzoMZMYjN+3Hskgu4ahaVpG9DHe5z8ac+Q1eoYoNeo9fNPzt7lj7vcrqlbWb8i
Llkrh2Lj7TdU+rqZqjciHCJx+2Vyf8iUQdgV+aYB7kAGvG0nLfn1POaYo3waINME
+VCMaG47aLrWAArqqnmCqTTNib9SdtnxcfoiG74tcEpZLkIxaZfMBmxYPfejHuyR
9n/06I9q3FF1KOilaImvdc3QmcowCNHXaxcLVu37tmAv3tsAFmj0h7xpT0DWRJzd
hJ7cKX7JWrkLxUfLroH1
=almu
-----END PGP SIGNATURE-----

--Apple-Mail=_9DE033FE-F627-441A-9D43-DA9634BB4DDA--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019