Mail Archives: geda-user/2016/01/09/00:26:44
This is a multi-part message in MIME format.
--------------000001060609040008060900
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
On 09/01/16 05:15, Britton Kerin (britton DOT kerin AT gmail DOT com) [via
geda-user AT delorie DOT com] wrote:
>
>
> On Fri, Jan 8, 2016 at 4:03 PM, Lev (leventelist AT gmail DOT com
> <mailto:leventelist AT gmail DOT com>) [via geda-user AT delorie DOT com
> <mailto:geda-user AT delorie DOT com>] <geda-user AT delorie DOT com
> <mailto:geda-user AT delorie DOT com>> wrote:
>
> On Fri, 8 Jan 2016 17:52:59 +0100
> "Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com
> <mailto:nicklas DOT karlsson17 AT gmail DOT com>) [via
> geda-user AT delorie DOT com <mailto:geda-user AT delorie DOT com>]"
> <geda-user AT delorie DOT com <mailto:geda-user AT delorie DOT com>> wrote:
>
> > In preferences-->Layers-->Groups some of the layers are listed but
> > not all are listed. What do you think is missing?
>
> I would add explicitly the insulation layers, and documentation
> layers, silks,
> etc. I'd add user defined layers as well. I'd add some logic like
> "XOR this
> layer with that, and use it as conductive 2."
>
> > For padtack which could be used for: pins, pads, via ordinary, via
> > buried, via blind: I suggested a group of ordinary drawing
> primitives
> > could be grouped together but no one said if this is a bad or good
> > idea. I also suggested this group you call a padstack could be
> placed
> > in a library with sub folders for different package types so they
> > could be used many times. This might be very far out but a
> discussion
> > how it should be done is always a start.
>
> Yes. That would be nice. A library is also a hierarchical
> structure. It
> contains the pads, padstacks, footprints. Yes, the padstacks are
> built up
> from primitives.
>
> If I go on, and implement the SQL based file format, it is easy. I
> defined pad
> and padstack tables.
>
> If we go the YAML way, I don't know how to represent that data.
>
>
> The way to think about YAML/JSON is as portable text-based
> serialization formats for the couple most popular datatypes that get
> built into modern languages, in particular arrays, hashes, and scalar
> values (basically numbers and strings). JSON doesn't support native
> (non-tree) references so you have to add your own id field if what you
> want to refer to doesn't have already have a unique name. YAML does.
> JSON is much more common but unfortunately also more noisy. Some
> people like the noise because they don't trust any whitespace-based
> approach (bad experiences with make).
>
> Britton
>
>
I agree with whoever posted that SQL isn't transferrable, as any
changes/errors in the db schema (ever) breaks things and is hard to
debug. At least with a text-based file format (whether JSON/YAML/XML)
you can human-read the file and see what's gone wrong, and easily make
filters/translators using readily-available tools.
MJE
--------------000001060609040008060900
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 09/01/16 05:15, Britton Kerin
(<a class="moz-txt-link-abbreviated" href="mailto:britton DOT kerin AT gmail DOT com">britton DOT kerin AT gmail DOT com</a>) [via <a class="moz-txt-link-abbreviated" href="mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] wrote:<br>
</div>
<blockquote
cite="mid:CAC4O8c-nqs2+9rgsD-Gsks-wSmJ1eCkJ9PFMi3XqMrYE2FO3Ew AT mail DOT gmail DOT com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Jan 8, 2016 at 4:03 PM, Lev (<a
moz-do-not-send="true" href="mailto:leventelist AT gmail DOT com">leventelist AT gmail DOT com</a>)
[via <a moz-do-not-send="true"
href="mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>]
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:geda-user AT delorie DOT com" target="_blank">geda-user AT delorie DOT com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri,
8 Jan 2016 17:52:59 +0100<br>
"Nicklas Karlsson (<a moz-do-not-send="true"
href="mailto:nicklas DOT karlsson17 AT gmail DOT com">nicklas DOT karlsson17 AT gmail DOT com</a>)
[via<br>
<span class=""><a moz-do-not-send="true"
href="mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>]"
<<a moz-do-not-send="true"
href="mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>>
wrote:<br>
<br>
> In preferences-->Layers-->Groups some of the
layers are listed but<br>
> not all are listed. What do you think is missing?<br>
<br>
</span>I would add explicitly the insulation layers, and
documentation layers, silks,<br>
etc. I'd add user defined layers as well. I'd add some
logic like "XOR this<br>
layer with that, and use it as conductive 2."<br>
<span class=""><br>
> For padtack which could be used for: pins, pads,
via ordinary, via<br>
> buried, via blind: I suggested a group of ordinary
drawing primitives<br>
> could be grouped together but no one said if this
is a bad or good<br>
> idea. I also suggested this group you call a
padstack could be placed<br>
> in a library with sub folders for different package
types so they<br>
> could be used many times. This might be very far
out but a discussion<br>
> how it should be done is always a start.<br>
<br>
</span>Yes. That would be nice. A library is also a
hierarchical structure. It<br>
contains the pads, padstacks, footprints. Yes, the
padstacks are built up<br>
from primitives.<br>
<br>
If I go on, and implement the SQL based file format, it is
easy. I defined pad<br>
and padstack tables.<br>
<br>
If we go the YAML way, I don't know how to represent that
data.<br>
</blockquote>
<div><br>
</div>
<div style="">The way to think about YAML/JSON is as
portable text-based serialization formats for the couple
most popular datatypes that get built into modern
languages, in particular arrays, hashes, and scalar values
(basically numbers and strings). JSON doesn't support
native (non-tree) references so you have to add your own
id field if what you want to refer to doesn't have already
have a unique name. YAML does. JSON is much more common
but unfortunately also more noisy. Some people like the
noise because they don't trust any whitespace-based
approach (bad experiences with make).</div>
<div style=""><br>
</div>
<div style="">Britton</div>
<div><br>
</div>
</div>
<br>
</div>
</div>
</blockquote>
I agree with whoever posted that SQL isn't transferrable, as any
changes/errors in the db schema (ever) breaks things and is hard to
debug. At least with a text-based file format (whether
JSON/YAML/XML) you can human-read the file and see what's gone
wrong, and easily make filters/translators using readily-available
tools.<br>
<br>
MJE<br>
</body>
</html>
--------------000001060609040008060900--
- Raw text -