Mail Archives: geda-user/2015/12/29/21:33:13
--Apple-Mail=_C18EF232-9A5A-495B-964C-21484D9D887F
Content-Type: multipart/alternative;
boundary="Apple-Mail=_305A0554-62FD-4A84-B3C7-C3B580E97BF8"
--Apple-Mail=_305A0554-62FD-4A84-B3C7-C3B580E97BF8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Dec 29, 2015, at 5:56 PM, Britton Kerin (britton DOT kerin AT gmail DOT com) =
[via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>=20
> Pcb is fine.
Baloney. For example, for years I=92ve been hearing that users want =
buried vias. A sanely designed tool wouldn=92t prevent a user from =
simply drawing a buried via, even if it didn=92t have such a concept =
built in. Pcb doesn=92t properly model the job it=92s supposed to do.
> It has all the users.
Almost all of them do their drawing with gschem, but if you read this =
list, almost all of the trouble they have is with pcb. Gschem works =
well, but pcb doesn=92t. We really need a decent free/open layout =
program.
> The pcb bias you constantly cry about is very real for that reason.
That makes no sense. Pcb is dependent on geda-gaf to be useful. Geda-gaf =
is useful without pcb.
There=92s nothing to keep my collaborators and layout contractors from =
using pcb. They know of it but it doesn=92t look useful to them. I=92ve =
exported gschem designs to a variety of PCB layout programs. The best =
one in terms of results has been Osmond PCB.
>=20
> > and scheme turns off a
> > lot of wood be contributors. We need people who....
> > 1. Don't fight so much.
> > 2. Know about EDA software.
> > 3. Have time to work on the project.
> > 4. Know all the languages involved in the project.
> >
> > That is a lot to ask.
> >
> > Kai-Martin and I were not the only two.
> >
> >> I never said scheme is over-emphasised in geda-gaf. AFAIR, I always
> >> stated the opposite: Scheme is 'under-emphasized' as a scripting
> >> language in geda.
> >
> > I think something got missed in translation. I was saying you and
> > peter were the only two who wanted to keep advancing scheme's use in
> > geda.
> >
> >>> could be miss interpreting your plan here but it sounds like you =
are
> >>> going to replace more of the C with Scheme.
> >>
> >> Yeah, that's my plan :)
>=20
> Good plan.
>=20
> Terrible plan. Tons more people know C, so you're replacing code that =
people can easily read with code they can=92t.
Vladimir=92s replacing code in a low-level language that is very clumsy =
in this application with a language that is much better suited. C is =
good for writing things like device drivers. There are far better ways =
to process data away from the iron than C.
> That's bad. You've conceded in that past that Lisp probably isn't =
the best way forward,
Lisp may not be the best way forward for *new* tools,. If you want to =
get rid of Lisp, you should write a new tool that isn=92t dependent on =
it. For those of us who want to keep the old tool, it increases =
flexibility to move more of it to Lisp.
> you're just being argumentative here.
Python might be a way, and Xorn supports it. I would be more =
enthusiastic about this path if I could concretely understand what Xorn =
is. At least we know it's a powerful tool in Roland=92s hands, but does =
anybody else understand it?
My position is consistent: protect (and possibly extend in a way =
compatible with its design) our existing infrastructure. If you want to =
do anything else, write a new tool. When you have a toolkit, you =
shouldn't make drastic changes to existing tools. Write new ones. If you =
want to make a schematic capture program with plugins in C, why would =
you *start* with something tangled with Scheme in a very complicated =
way? Easier to untangle by starting with a C architecture designed for =
what you want. In the latter case, you could have a 21st century GUI, =
too. Why kludge the gschem architecture to fit your agenda, when you can =
more easily have a parallel tool? I expect C plugins would still be far =
clumsier than Scheme, but maybe some would have the fortitude to write =
them.
Vladimir=92s going in the other direction, untangling by moving more =
into Scheme. That=92s a good approach, too. More conservative and more =
compatible with what we have.
The big disconnect here is the idea that we can=92t keep our old tools =
while developing new ones. It seems to me that developers who actually =
understand the internals of geda-gaf are the ones who are also =
comfortable with doing more in Scheme.
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
--Apple-Mail=_305A0554-62FD-4A84-B3C7-C3B580E97BF8
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 Dec 29, 2015, at 5:56 PM, Britton =
Kerin (<a =
href=3D"mailto:britton DOT kerin AT gmail DOT com">britton DOT kerin AT gmail DOT com</a>) =
[via <a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] =
<<a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>>=
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div style=3D"">Pcb is =
fine. </div></div></div></div></blockquote><div><br></div><div>Balone=
y. For example, for years I=92ve been hearing that users want buried =
vias. A sanely designed tool wouldn=92t prevent a user from simply =
drawing a buried via, even if it didn=92t have such a concept built in. =
Pcb doesn=92t properly model the job it=92s supposed to =
do.</div><div><br></div><blockquote type=3D"cite"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div style=3D""> It has =
all the users.</div></div></div></div></blockquote><div><br></div>Almost =
all of them do their drawing with gschem, but if you read this list, =
almost all of the trouble they have is with pcb. Gschem works well, but =
pcb doesn=92t. We really need a decent free/open layout =
program.</div><div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div style=3D""> =
The pcb bias you constantly cry about is very real for that =
reason.</div></div></div></div></blockquote><div><br></div>That makes no =
sense. Pcb is dependent on geda-gaf to be useful. Geda-gaf is useful =
without pcb.<br><div><br></div></div><div>There=92s nothing to keep my =
collaborators and layout contractors from using pcb. They know of it but =
it doesn=92t look useful to them. I=92ve exported gschem designs to a =
variety of PCB layout programs. The best one in terms of results has =
been Osmond PCB.</div><div><br></div><div><blockquote type=3D"cite"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div> </div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; =
border-left-color: rgb(204, 204, 204); border-left-style: solid; =
padding-left: 1ex; position: static; z-index: auto;"><span class=3D"">
> and scheme turns off a<br>
> lot of wood be contributors. We need people who....<br>
> 1. Don't fight so much.<br>
> 2. Know about EDA software.<br>
> 3. Have time to work on the project.<br>
> 4. Know all the languages involved in the project.<br>
><br>
> That is a lot to ask.<br>
><br>
> Kai-Martin and I were not the only two.<br>
><br>
>> I never said scheme is over-emphasised in geda-gaf. AFAIR, I =
always<br>
>> stated the opposite: Scheme is 'under-emphasized' as a =
scripting<br>
>> language in geda.<br>
><br>
> I think something got missed in translation. I was saying you =
and<br>
> peter were the only two who wanted to keep advancing scheme's use =
in<br>
> geda.<br>
><br>
>>> could be miss interpreting your plan here but it sounds =
like you are<br>
>>> going to replace more of the C with Scheme.<br>
>><br>
>> Yeah, that's my plan :)<br>
<br>
</span>Good plan.<br></blockquote><div><br></div><div style=3D"">Terrible =
plan. Tons more people know C, so you're replacing code that =
people can easily read with code they =
can=92t.</div></div></div></div></blockquote><div><br></div>Vladimir=92s =
replacing code in a low-level language that is very clumsy in this =
application with a language that is much better suited. C is good for =
writing things like device drivers. There are far better ways to process =
data away from the iron than C.</div><div><br><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div style=3D""> That's bad. You've =
conceded in that past that Lisp probably isn't the best way =
forward,</div></div></div></div></blockquote><div><br></div>Lisp may not =
be the best way forward for *new* tools,. If you want to get rid of =
Lisp, you should write a new tool that isn=92t dependent on it. For =
those of us who want to keep the old tool, it increases flexibility to =
move more of it to Lisp.</div><div><br><blockquote type=3D"cite"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div =
style=3D""> you're just being argumentative =
here.</div></div></div></div></blockquote><div><br></div>Python might be =
a way, and Xorn supports it. I would be more enthusiastic about this =
path if I could concretely understand what Xorn is. At least we know =
it's a powerful tool in Roland=92s hands, but does anybody else =
understand it?</div><div><br></div><div>My position is consistent: =
protect (and possibly extend in a way compatible with its design) our =
existing infrastructure. If you want to do anything else, write a new =
tool. When you have a toolkit, you shouldn't make drastic changes to =
existing tools. Write new ones. If you want to make a schematic capture =
program with plugins in C, why would you *start* with something tangled =
with Scheme in a very complicated way? Easier to untangle by starting =
with a C architecture designed for what you want. In the latter case, =
you could have a 21st century GUI, too. Why kludge the gschem =
architecture to fit your agenda, when you can more easily have a =
parallel tool? I expect C plugins would still be far clumsier than =
Scheme, but maybe some would have the fortitude to write =
them.</div><div><br></div><div>Vladimir=92s going in the other =
direction, untangling by moving more into Scheme. That=92s a good =
approach, too. More conservative and more compatible with what we =
have.</div><div><br></div><div>The big disconnect here is the idea that =
we can=92t keep our old tools while developing new ones. It seems to me =
that developers who actually understand the internals of geda-gaf are =
the ones who are also comfortable with doing more in =
Scheme.</div><div><br></div><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"> =
<span class=3D"Apple-converted-space"> </span><span =
class=3D"Apple-converted-tab"> <span =
class=3D"Apple-converted-space"> </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=_305A0554-62FD-4A84-B3C7-C3B580E97BF8--
--Apple-Mail=_C18EF232-9A5A-495B-964C-21484D9D887F
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
iQIcBAEBCgAGBQJWg0JSAAoJEF1Aj/0UKykRMksP/RLWgIIcmJESLHJRp5PyqeEy
DF/kg3zBSiah8wMaI57qtmJb5FqTUV5w42nAzAjkT/8AMp552q6iSVSuCuVP+uSs
8CjFbT8N5f4dmyw5SXX6T0HfNH2kF/eiJjV5A+yaes+WXn5uKxxpJEggHnEgZqCP
GUm2le2LgOjEdX5cAVMcYamUUzQoYatW1cykHRRpZEd0/RARKcomzPLfyWSUqHip
5SuJmFY8oM/lq/a9VBZSWHEXnLEGnAI6FMZnOjwYeVPsNv6f37DWoQRWLv1wPOaO
d68Rk6tDT1CEpwKxCVEETJ/txWSgYlBw0ngp+iQFykn790s9tsjZ4pmYz7W4qftW
+mferwUunOLa2RVjz29sUNBpqLGndnwftg+wmx85eO2ffTMMOv5Pz77NQAQlBOGM
MODDe0eJGV7HrEeJACqKTgC1+3rX0vRs1tbKBNkrKmNcO4zeX62g2rLN8R1wEEFS
xXsp7rLS1mToJUcmKBK7jr20aG0vCDT9UCJEbthDvp6uqMxqqxefoiam7cCEFy9D
1oTjcmWFKYFAkoMOv8DSo8SfvVVBCKtF8rohxDHCwbDYxd3ijvWOYqzKe+14hWtk
W+B9fyLkRzQP+6YzCuvRn+xzMLRT90NS6lMyu3UhR2qX6KgS6Nw8GyHkNTXU/GAI
32oNhXp6qkf0PCw6HFbu
=SbA8
-----END PGP SIGNATURE-----
--Apple-Mail=_C18EF232-9A5A-495B-964C-21484D9D887F--
- Raw text -