Re: [Kicad-developers] boost_root driven by https

[Dick Hollenbeck]

On Aug 22, 2013 7:43 PM, "Brian Sidebotham" 
wrote:
>
>
>
>
> On 20 August 2013 17:39, Dick Hollenbeck  wrote:
>>
>>
>> KiCad Developers:
>>
>> Anyway I've looked, building some compiled libraries for boost is
required and I have
>> augmented CMakeModules/download_boost.cmake to conditionally build some
compiled boost
>> libraries, although that support is not enabled yet.  There is an
alternate execution path
>> in that module that does what it did before except for a new header file
location.
>>
>>
>> I have the boost build scripts mostly done, but want to take a break so
I am committing
>> what I have done so far.
>>
>> The net effect of this upcoming commit, short term, is that the boost
headers are moved into
>>
>> to
>>  /boost_root/include/boost
>>
>> from
>>  include/boost
>>
>> .
>>
>>
>> This immediately paves the way for a sensible
/boost_root/libs/* as needed and
>> as used in the alternate execution path in download_boost.cmake.
>>
>> It also smoked out some bugs in our build scripts which were using a
bogus
>> Boost_INCLUDE_DIR variable, which was dis-functional, but now is
functional.
>>
>> If you have any problems with it let me know.
>>
>> (Thinking of ramifications across 3 platforms has taken its toll.  I can
however see a
>> clear path forward, and will be back at this within a week or two after
I recharge my
>> batteries.  My current thinking is to try and use boost::async and forgo
use of other
>> networking libraries on top of that.  On windows we will have to pick up
openssl support,
>> and that may mean insisting on the python install to pull it from python
a-mingw-us.  I
>> build it there, but not in DLL form yet.)
>>
> This sounds fine to me. I suggest we include a complete "install" of
python-a-mingw-us in the KiCad install anyway. It's the easiest way of
getting controlled Python support on Windows. It's how almost all of the
other open source efforts package their python scripting.
>
> Simply include the complete thing and KiCad can set PYTHONHOME to it's
root dir for it's sub-processes. This is how KiCad-Winbuilder arranges all
the executables and python-a-mingw-us works fine for KiCad scripting like
this.
>
> So it should only be pulling on resources that we'll already have
available anyway in that case.
>

Cool, agreement then.  I've spent 20 minutes twice, separated by 4 months
trying to get openssl to build as a DLL.  It was leading to unresolved
functions.  Will need more than 20 minutes to solve.  Brian if you are
feeling smart some day with some time, you could try and pull that off.

To trigger the attempt of course this is an edit to
pythonexternalprojects.cmake.  We should check for a newer src package.

After that hurdle, then the pyhon module has to be told about linking to
the DLL.  Then there is packaging the DLL, and telling windows how to find
it when running that python extension.

This is more than I can justify in time, since I don't even use windows
myself for 12 years.  The reward for having spent three and a half weekends
on a-mingw-us for my windows friends eludes me.

I know you have a comparable amount of time into the layers above that, so
I will say it in plain English because for some reason others seem to be
reluctant to use a person's name and thank you in the same sentence.
Brian, thank you for your truly exceptional and world class work in
bringing the software stack necessary for windows python scripting to
fruition. Thank you for believing in my vision, and in my a-mingw-us work,
and following my lead.  You were basically the only one.  Now it is your
effort and follow through that *I* salute.  In fact by the time we look at
what you've done in the installer, and in winbuilder, your work easily
surpasses mine.

I find you to be an invaluable member of this team.











> Best Regards,
>
> Brian.
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Github part footprint filenames

[Dick Hollenbeck]

On Aug 20, 2013 7:04 PM, "Chris Morgan"  wrote:
>
> Hello.
>
> Apparently I was living under a bit of a rock until today when I
> created a few test footprints with the new 'pretty' file format. I
> tried to find some documentation about the approach but it seems clear
> from discussion in the github thread and this testing that the idea is
> one part footprint per-file, and use of the new s-expression format. I
> was wondering though why this format isn't the default yet? I have a
> June stable build.
>
> So I was trying to figure out how we might name files that were stored
> in github. If we begin by assuming that pcbnew will use github
> directly, how should part footprints be named? Does the name inside of
> the footprint override the name in the filesystem, in the library
> editor?

It should not, I take your word that it is even in the kicad_mod file.
Think of it as write only information for the computer, and readable and
unnecessessary for the human.  The pretty footprint is named by the
basename of the filename in which it resides, which is the filename minus
the kicad_mod extension.

This is what was discussed when the format was designed, and what makes
fullfilling the PLUGIN::FootprintsEnumerate () call doable by simply doing
a directory listing and stripping extensions.  No need to read content.

As to what names you give to your footprints, I offer no help there.  I am
bad at it.


>
> I'm trying to figure out how we can have kicad use the blob sha. Doing
> so would let us avoid issues where the filename was the same but the
> content differed.
>
> Chris
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] boost_root driven by https

[Dick Hollenbeck]

On 08/20/2013 11:39 AM, Dick Hollenbeck wrote:
> 
> KiCad Developers:
> 
> Anyway I've looked, building some compiled libraries for boost is required 
> and I have
> augmented CMakeModules/download_boost.cmake to conditionally build some 
> compiled boost
> libraries, although that support is not enabled yet.  There is an alternate 
> execution path
> in that module that does what it did before except for a new header file 
> location.
> 
> 
> I have the boost build scripts mostly done, but want to take a break so I am 
> committing
> what I have done so far.
> 
> The net effect of this upcoming commit, short term, is that the boost headers 
> are moved into
> 
> to
>  /boost_root/include/boost
> 
> from
>  include/boost
> 
> .
> 
> 
> This immediately paves the way for a sensible /boost_root/libs/* 
> as needed and
> as used in the alternate execution path in download_boost.cmake.
> 
> It also smoked out some bugs in our build scripts which were using a bogus
> Boost_INCLUDE_DIR variable, which was dis-functional, but now is functional.
> 
> If you have any problems with it let me know.
> 
> (Thinking of ramifications across 3 platforms has taken its toll.  I can 
> however see a
> clear path forward, and will be back at this within a week or two after I 
> recharge my
> batteries.  My current thinking is to try and use boost::async

oops,

boost::asio

(proof its time for a longer break.)

> and forgo use of other
> networking libraries on top of that.  On windows we will have to pick up 
> openssl support,
> and that may mean insisting on the python install to pull it from python 
> a-mingw-us.  I
> build it there, but not in DLL form yet.)
> 
> 
> Dick
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] boost_root driven by https

[Dick Hollenbeck]

KiCad Developers:

Anyway I've looked, building some compiled libraries for boost is required and 
I have
augmented CMakeModules/download_boost.cmake to conditionally build some 
compiled boost
libraries, although that support is not enabled yet.  There is an alternate 
execution path
in that module that does what it did before except for a new header file 
location.


I have the boost build scripts mostly done, but want to take a break so I am 
committing
what I have done so far.

The net effect of this upcoming commit, short term, is that the boost headers 
are moved into

to
 /boost_root/include/boost

from
 include/boost

.


This immediately paves the way for a sensible /boost_root/libs/* as 
needed and
as used in the alternate execution path in download_boost.cmake.

It also smoked out some bugs in our build scripts which were using a bogus
Boost_INCLUDE_DIR variable, which was dis-functional, but now is functional.

If you have any problems with it let me know.

(Thinking of ramifications across 3 platforms has taken its toll.  I can 
however see a
clear path forward, and will be back at this within a week or two after I 
recharge my
batteries.  My current thinking is to try and use boost::async and forgo use of 
other
networking libraries on top of that.  On windows we will have to pick up 
openssl support,
and that may mean insisting on the python install to pull it from python 
a-mingw-us.  I
build it there, but not in DLL form yet.)


Dick


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad presented at Fosdem

[Dick Hollenbeck]

On 08/13/2013 02:53 PM, Fabrizio Tappero wrote:
> Hi Dick,
> request and topic are in. To pump up the chances to get you funded,
> might be worth a 100 word blob about yourself and a 200 word abstract
> about the talk (which will be 30 min or 1 hour). Please you decide.
> You shall know that there is the option of a paper too. If you have
> anything, feel free to send it to me and I'll update it.
> 
> For what I understand about the online topic proposal tool, it looks
> like I did not only propose a talk (KiCad) but a full on topic to
> which others can present too. It would be (would it?) great to make it
> general and get a whole session with maybe: KiCad (you) + On-line
> library parts (somebody) + Eagle people + GEDA people + XYZ people.
> 
> Just thinking out loud.
> 
> cheers
> Fabrizio


Fabrizio,

Things have changed in my life and I will be unable to attend this event.

Hopefully you can find another speaker.  I apologize if the time you spent on 
it goes
wasted, but hopefully someone else can perform this role.


Best regards,

Dick





> 
> 
> 
> On Fri, Aug 9, 2013 at 3:24 PM, Dick Hollenbeck  wrote:
>> Be sure and mention that they can have a say in the topics of the
>> presentation and discussion.
>>
>> Thanks again.
>>
>> On Aug 9, 2013 7:51 AM, "Fabrizio Tappero" 
>> wrote:
>>>
>>> Hi Dick,
>>> sure no worries, it would even be a good change for us to meet !!
>>>
>>> I'll go a head and ask.
>>>
>>> cheers
>>> Fabrizio
>>>
>>> On Thu, Aug 8, 2013 at 7:33 PM, Dick Hollenbeck  wrote:
>>>> On 08/08/2013 10:39 AM, Fabrizio Tappero wrote:
>>>>> Hi guys,
>>>>> Feb next year there will be these annual conf in Belgium:
>>>>>
>>>>> https://fosdem.org/2014/news/2013-08-06-call-for-participation/
>>>>>
>>>>>
>>>>> It would be great to have KiCad presented there. If there is somebody
>>>>> interested in presenting I can ask for a presentation slot and for the
>>>>> money to cover for accommodation and  transportation.
>>>>>
>>>>> Please let me know
>>>>>
>>>>> cheers
>>>>> Fabrizio
>>>>
>>>>
>>>> Yeah, I'd be interested *if* those expenses could be covered all the way
>>>> from Texas.
>>>>
>>>> Fabrizio, I appreciate you doing the request and making it easy for me.
>>>>
>>>>
>>>> Dick
>>>>
>>>>
>>>>
>>>> ___
>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>> Post to : kicad-developers@lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] QFP Footprint Wizard

[Dick Hollenbeck]

On Aug 18, 2013 7:11 PM, "Nils Hesse"  wrote:
>
> Hi,
>
> just in case anyone has any usage for this:
>
> I've written a QFP Footprint wizard using the FootprintWizardPlugin
Python class (see attachment). If there are any problems with the wizard
I'm happy to help.
>
> Nils
>

Thanks for your contribution!

What the development team would have to do to complete this contribution is:

A) Put it in patch form so we know where you think it should go in the
source tree.

B) Make sure that the patch has a cmake install () statement so that it
gets installed into the proper end user directory from its location in the
source tree.

Brian or Miguel can probably help you with these steps if you need help.

Your willingness to offer support on the tool is also appreciated.

Thx.

> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

On 08/10/2013 04:34 PM, Dick Hollenbeck wrote:
> Tom,
> 
> The other thing about your work is that it is important, very important.
> 
> The push and shove router is something I could have used today.  Whatever 
> confidence I
> used to have in freerouter is gone.  It is not working for me very well on 
> this current
> board, and I am frustrated to no end with it and the lack of support now.
> 
> Hoping for a better solution,
> 
> Dick




Alfons,  if you are reading this mailing list:


I regret having said the above.  I have had a change of heart, and wish to 
publicly
apologize to you.  You have written one of the greatest software tools that I 
have ever used.

Rewards are slim when one donates a bunch of valuable time.  The donation is 
even more
costly when that time is filled by valuable expertise.  And having to bear any 
kind of
criticism after one does that is simply painful.  Life need not be about that.  
So I am
sorry Alfons.

So Alfons, if you are reading this, please know that your work is very 
appreciated.  I
find much to like in your work, and in particular the last few hours have been 
one
pleasant surprise after another.  But even without that, I owed you an apology.


So with a new perspective, and humbled by your amazing work, I offer my 
apologies.


Dick


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Layer alignment target default size

[Dick Hollenbeck]

On 08/16/2013 08:36 AM, Wayne Stambaugh wrote:
> On 8/16/2013 9:15 AM, Dick Hollenbeck wrote:
>>
>> Has this been fixed yet?
>>
>> http://tech.groups.yahoo.com/group/kicad-users/message/16069
>>
>>
> 
> Nope.  I just tested it.  I also figured out where the problems is. 
> I'll fix it as soon as I'm done fixing a MinGW build bug that popped up 
> in r4287.

Thanks Wayne.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Layer alignment target default size

[Dick Hollenbeck]

Has this been fixed yet?

http://tech.groups.yahoo.com/group/kicad-users/message/16069


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bug 1204712 - Timestamps in schematic files

[Dick Hollenbeck]

On Aug 16, 2013 5:29 AM, "Brian Sidebotham" 
wrote:
>
> Hi Guys,
>
> The bug report is no longer relevant, or was incorrect to being with.
This bug is not present with EESCHEMA Schematic File Version 2.
>
> However, the *-cache.lib file still gets updated with a fresh timestamp
every time the schematic is saved, even if there are no changes.
>
> Can I get rid of the timestamp that is inserted at the top of .lib files,
or at least track, and only update the *-cache.lib file if it has other
changes?
>
> The library loader entirely ignores the timestamp anyway so my preference
would just be to remove it entirely.
>
> Best Regards, Brian.


Only one voice, but no oppostion here.

>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Scripting Build Failing

[Dick Hollenbeck]

On 08/15/2013 09:59 AM, Kaspar Emanuel wrote:
> Hey,
> 
> I have been having trouble building pcbnew with -DKICAD_SCRIPTING=ON and
> -DKICAD_SCRIPTING_MODULES=ON. I tried a few days ago with and without and 
> it's definitely
> one of those flags, not surprising considering the error:
> 
> |[ 61%] Building CXX object 
> pcbnew/CMakeFiles/_pcbnew.dir/__/scripting/wx_python_helpers.cpp.o
> /home/kaspar/kicad/kicad.bzr2/scripting/wx_python_helpers.cpp: In function 
> ‘wxString* newWxStringFromPy(PyObject*)’:
>  /home/kaspar/kicad/kicad.bzr2/scripting/wx_python_helpers.cpp:77:30: error: 
> ‘PyString_Check’ was not declared in this scope
>  if( !PyString_Check( src ) && !PyUnicode_Check( src ) )
>   ^
>  /home/kaspar/kicad/kicad.bzr2/scripting/wx_python_helpers.cpp:86:29: error: 
> ‘PyString_Check’ was not declared in this scope
>  if( PyString_Check( obj ) )
>  ^
> /home/kaspar/kicad/kicad.bzr2/scripting/wx_python_helpers.cpp:101:67: error: 
> cannot convert ‘PyUnicodeObject*’ to ‘PyObject* {aka _object*}’ for argument 
> ‘1’ to ‘Py_ssize_t PyUnicodeUCS4_AsWideChar(PyObject*, wchar_t*, Py_ssize_t)’
> wxStringBuffer( *result, len ), len );
>^
> make[2]: *** 
> [pcbnew/CMakeFiles/_pcbnew.dir/__/scripting/wx_python_helpers.cpp.o] Error 1
>  make[1]: *** [pcbnew/CMakeFiles/_pcbnew.dir/all] Error 2|
> 
> I just tried with -DKICAD_SCRIPTING_WXPYTHON=ON as well and that gives the 
> same error.
> 
> I don't have time right now to do a proper regression test but it definitely 
> occurs with
> revisions 4242 onwards.
> 
> Anyone know anything about this?


Scripting builds often require that you do a

$ make clean

before your

$ make


There are some disconnects in the dependency tree, mostly because of incomplete 
cmake
macros/functions for swig.


$ make clean

is the work around.





___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] GITHUB_PLUGIN

[Dick Hollenbeck]

On Aug 14, 2013 5:58 PM, "Chris Morgan"  wrote:
>
> On Wed, Aug 14, 2013 at 6:29 AM, Miguel Angel Ajo Pelayo
>  wrote:
> >
> > 2013/8/14 Chris Morgan 
> >>
> >>  wrote:
> >> > (please use nbee/nbeepass as credentials)
> >> >
> >> > http://kicadhub.com/pcbs/2
> >> > http://kicadhub.com/assembly_guides/3
> >> > http://kicadhub.com/components/107
> >> > http://kicadhub.com/kicadnetlists/2
> >> >
> >> > But at this time I thought that my time was rather limited and that I
> >> > was
> >> > better spending it at kicad itself, finishing and polishing what I
> >> > started,
> >> > so I stopped it.
> >> >
> >>
> >> Interested in putting the server code out there so everyone can take a
> >> look at it?
> >>
> > That's exactly my idea right now, but I must clean up, add license
headers,
> > and put API keys into config files, and keep empty keys on the repo
itself.
> >
> >>
> >>
> >> > Now if we mix my old idea, with this new approach:
> >> >
> >> > Everybody has his own github library repositories, and then we could
> >> > build a
> >> > community aggregator, where you can add your git url, it keeps your
> >> > parts
> >> > synced to the aggregator, it also keeps track of voting, pulls your
> >> > library
> >> > updates, and builds an index/categorization that kicad can read,
> >> > then it re-exports on a single github repo (agreggated) and later,
> >> > exports
> >> > an API (extension of the git idea) to keep track of votes, comments,
> >> > etc.
> >> >
> >> > That aggregator might need a server (quite scalable as we relay
> >> > fileserving
> >> > to github), but it must be fully open, same kicad license, so anybody
> >> > could
> >> > build his own server if wanted (for example, within companies...)
> >> >
> >>
> >> Keep in mind that people may do unfortunate things to their github
> >> libraries, such as delete them, change parts etc. That's part of why I
> >> was thinking the server would want to store the data itself.
> >>
> >
> > Yes, most probably would be a good idea keeping all versions of
everything
> > on the exported git repo, this way you can always access the most
popular
> > one or know derivatives. (derivative tracking can be handled on the
server
> > db)
> >
> >>
> >> The analogy I was thinking of was a pool of parts of varying ratings
> >> and authorship. The server could look to kicad as if it were a single
> >> github repository but could use user accounts to protect against the
> >> wrong people deleting/renaming parts.
> >
> >
> > They can delete/rename parts, but they become derivatives  with a parent
> > part, (just an idea)
> >
> >>
> >> As the api is open there
> >> wouldn't be any issue if someone or some organization wanted to copy
> >> parts from one repository to another but imo if we had an official
> >> kicad blessed repository that might be the central go-to place that we
> >> could build into the plugin as a default source.
> >
> >
> >
> >
> > --
> >
> > Miguel Angel Ajo Pelayo
> > http://www.nbee.es
> > +34 636 52 25 69
> > skype: ajoajoajo
>
>
> Please let me know when/if you get this code out there so I can take a
> look. In terms of implementation it might make sense to work with Joe
> Ferner, the guy behind kicadcloud.com, since it looks like kicadcloud
> is trying to do basically what we are trying to do.
>
> Chris

Ok, assuming you are talking to me.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] About the sexp format

[Dick Hollenbeck]

On 08/14/2013 01:44 PM, Dick Hollenbeck wrote:
> On 08/14/2013 12:51 PM, Lorenzo Marcantonio wrote:
>> I'm writing some lisp tooling for working with modules; obviously the
>> sexp files are pretty much lisp favourite food:P 
>>
>> However I have some questions (if there is some documentation on the
>> syntax it would be great) to make the support more robust as possible.
>>
>> - Case sensitivity. It appears it is case sensitive, am I right?
>>
>> - Numbers seems the usual stuff at least for integers. Floating point
>>   could have some peculiar syntax? For example E notation or other
>>   things different than n.
>>
>> - Strings are somewhat bothering me, because these are easily confused
>>   as a symbol or number... in a 'conventional' sexp strings are always
>>   in quotes and symbol aren't (symbols have their own syntactic quirks,
>>   too...)
>>
>>   For example:
>>
>>   (fp_text value 470p (at 0 0 270) (layer F.SilkS) hide
>> (effects (font (size 1 1) (thickness 0.1
>>
>>   Is a problematic sexp because 470p is a string for kicad, but in fact
>>   it's a possible-number (a strange thing due to lisp extensibility...).
>>   One of the advantages of sexp is to be self describing i.e. just doing
>>   (read) slurps the thing whole without needing a schema. Needing to
>>   give a schema lose most of the advantages of using sexps... 
>>
>>   I think that making strings self evident always using quotes would
>>   solve the problem without breaking compatibility. So making an
>>   emission like:
>>
>>   (fp_text value "470p" (at 0 0 270) (layer F.SilkS) hide
>> (effects (font (size 1 1) (thickness 0.1
>>
>>   would a) make the sexp self-parsing and b) better shows that 470p is
>>   some text and not some special symbol or keyword (like F.Silk, for
>>   example). I suppose it shouldn't be a big modification to do.
>>
>> - What about special characters inside strings? for example, is
>>   a " represented as \" ? Other special character that could be found?
>>   IIRC you could put newline in texts, is that stored as \n or other?
>>   (lisp standards vary about this, everyone has it's own escape rule but
>>   AFAIK the \" is universal)
>>
>> - File encoding? is it UTF-8 or something else?
>>
> 
> 
> I like our format and it works.  I am unwilling to change it for a single 
> user of lisp.
> 
> Here is some more info
> 
> 
> a) see OUTPUT_FORMATTER::Quote{s,w}
> 
> b) see /Documentation/s-expressions.txt
> 
> c) keywords are always lowercase ASCII.  The rest of the file is UTF8 with no 
> restrictions
> on case.
> 
> d) multiline strings in the datatree are single line strings in the file, 
> with a separator
> of "slash n", visible.

e) /common/ptree.cpp  which maybe you can SWIG and use it from Python on 
top of
_pcbnew.so.

This way you are using the same parser/writer functions as kicad.  The 
difficulty will be
getting access to the ptree nodes under python.  Maybe somebody has already 
SWIGed boost
property tree.


Or maybe you use ptree.cpp and work in C++.






> 
> 
> Dick
> 
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] About the sexp format

[Dick Hollenbeck]

On 08/14/2013 12:51 PM, Lorenzo Marcantonio wrote:
> I'm writing some lisp tooling for working with modules; obviously the
> sexp files are pretty much lisp favourite food:P 
> 
> However I have some questions (if there is some documentation on the
> syntax it would be great) to make the support more robust as possible.
> 
> - Case sensitivity. It appears it is case sensitive, am I right?
> 
> - Numbers seems the usual stuff at least for integers. Floating point
>   could have some peculiar syntax? For example E notation or other
>   things different than n.
> 
> - Strings are somewhat bothering me, because these are easily confused
>   as a symbol or number... in a 'conventional' sexp strings are always
>   in quotes and symbol aren't (symbols have their own syntactic quirks,
>   too...)
> 
>   For example:
> 
>   (fp_text value 470p (at 0 0 270) (layer F.SilkS) hide
> (effects (font (size 1 1) (thickness 0.1
> 
>   Is a problematic sexp because 470p is a string for kicad, but in fact
>   it's a possible-number (a strange thing due to lisp extensibility...).
>   One of the advantages of sexp is to be self describing i.e. just doing
>   (read) slurps the thing whole without needing a schema. Needing to
>   give a schema lose most of the advantages of using sexps... 
> 
>   I think that making strings self evident always using quotes would
>   solve the problem without breaking compatibility. So making an
>   emission like:
> 
>   (fp_text value "470p" (at 0 0 270) (layer F.SilkS) hide
> (effects (font (size 1 1) (thickness 0.1
> 
>   would a) make the sexp self-parsing and b) better shows that 470p is
>   some text and not some special symbol or keyword (like F.Silk, for
>   example). I suppose it shouldn't be a big modification to do.
> 
> - What about special characters inside strings? for example, is
>   a " represented as \" ? Other special character that could be found?
>   IIRC you could put newline in texts, is that stored as \n or other?
>   (lisp standards vary about this, everyone has it's own escape rule but
>   AFAIK the \" is universal)
> 
> - File encoding? is it UTF-8 or something else?
>


I like our format and it works.  I am unwilling to change it for a single user 
of lisp.

Here is some more info


a) see OUTPUT_FORMATTER::Quote{s,w}

b) see /Documentation/s-expressions.txt

c) keywords are always lowercase ASCII.  The rest of the file is UTF8 with no 
restrictions
on case.

d) multiline strings in the datatree are single line strings in the file, with 
a separator
of "slash n", visible.


Dick



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] kicad-winbuilder compiler version

[Dick Hollenbeck]

Brian,

What version of gcc are you using in winbuilder?

This cpp-netlib I am looking at requires some advanced C++ features.


Dick

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

On Aug 13, 2013 12:31 PM, "Lorenzo Marcantonio" 
wrote:
>
> On Tue, Aug 13, 2013 at 05:58:59PM +0200, Tomasz Wlostowski wrote:
> > Look at the PDF I put on ohwr.org - one can use coroutines, function
> > pointers or enum+switch for the FSMs, depending on his/her coding
> > habits. Nothing is forbidden.
>
> All clear for me. I was trying to explain to Dick that coroutines were
> neither the solution for all the problems neither a blasphemy... they
> have their use (having them more readily available would simplify
> things, however they are not idiomatic in C/C++)

LOL.

You assume far too much Lorenzo.

My metaphor explicitly assumed the mechanic understood how to use the 5 mm
wrench.

I've worked with them very extensively.  Familiarity can be assumed in my
case.  Applicabilty is another topic and no doubt a matter of opinion.



>
> --
> Lorenzo Marcantonio
> Logos Srl
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

On 08/13/2013 10:58 AM, Tomasz Wlostowski wrote:
> On 08/13/2013 05:48 PM, Lorenzo Marcantonio wrote:
>> On Tue, Aug 13, 2013 at 07:14:05AM -0500, Dick Hollenbeck wrote:
>>> If you ignore the context of application, then this is the same thing as 
>>> guessing that a
>>> mechanic hates his 5mm wrench when he goes to loosen a 11mm nut.
>>
>> I think it more than using a ratchet instead of an open wrench to loose
>> the nut. Same result, different way to do it.
>>
>> Of course a really tight nut may require a long wrench and break the
>> ratchet... i.e. not necessarily coroutines are the solution.
> 
> The solution I proposed does not make coroutines obligatory. If you 
> don't want to use them in a particular tool, just don't call any 
> Wait()/Yield() methods. TOOL_INTERACTIVE constructor could have an 
> additional parameter that prevents creating an unnecessary stack frame 
> for coroutine-less tools.
> 
>>
>> As a way to maintain the tool state machine (fed by events), they seem
>> appropriate to me; of course everyone will propose his own 'best' idea
>> (heck, no women here:P)
>>
> Look at the PDF I put on ohwr.org - one can use coroutines, function 
> pointers or enum+switch for the FSMs, depending on his/her coding 
> habits. Nothing is forbidden.
> 
> Tom



I had not seen the PDF before I made my initial positive comments.  I had only 
read the
synopsis on the web page.  Maybe I missed it or maybe you added it recently.


I wonder how important building a team around this code is.   I wonder who will 
be on that
team.

Alfons sunk 7 man years into the code before it was useable.  That suggests a 
team may be
necessary.

When do we see the code?

Dick



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

On 08/13/2013 08:03 AM, Dick Hollenbeck wrote:
> On 08/13/2013 07:09 AM, Dick Hollenbeck wrote:
>>>
>>> I find track laying impossible without mouse warping... there is an
>>> option to disable it. But how could you *emulate* it, if there is no way
>>> to physically move the pointer? 
>>
>>
>> The OS+native windowing system will move the mouse coordinates in the next 
>> mouse move event.
>>
>> Your tool, if pushed onto the wxEvtHandler stack, I am thinking should have 
>> first access
>> to ALL events, (~captured mouse) so as long as you retain state information 
>> the next call
>> to ProcessEvent(), possibly routed to TOOL::OnMouseMove(), you can/could in 
>> there redraw
>> the mouse cursor at the new desired location, or not.
>>
>> See wxEventLoopBase in 
>> http://docs.wxwidgets.org/trunk/classwx_event_loop_base.html
>>
>> This class sucks events out of the os queue, and gets first dibs on any 
>> events, it is the
>> first recipient of any OS events when it is alive, and dispatching happens 
>> from here.
>>
>>
>> If simply residing topmost on the wxEvtHandler stack does not give you 
>> enough control,
>> then there is the option to create another wxEventLoopBase temporarily.
>>
>>
> 
> 
> Here are some nice graphics and explanation of PushEventHandler:
> 
> http://docs.wxwidgets.org/trunk/classwx_window.html#a398c11ab9af7956067a964f560d1978c
> 
> It is my thinking that putting this in the wxFrame, by calling its 
> PushEventHandler will
> give you first dibs on all events. 



That was a guess.  Probably time to stop guessing and write some test code, and 
examine
the source.



>If you follow the wEvent::Skip() protocol, and not
> process events not pertinent to you, and I think this means knowing the 
> client window area
> coord and checking mouse events against that box, then any wxEvent can still 
> find its way
> to its normal destination outside the tool.
> 
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

On 08/13/2013 07:09 AM, Dick Hollenbeck wrote:
>>
>> I find track laying impossible without mouse warping... there is an
>> option to disable it. But how could you *emulate* it, if there is no way
>> to physically move the pointer? 
> 
> 
> The OS+native windowing system will move the mouse coordinates in the next 
> mouse move event.
> 
> Your tool, if pushed onto the wxEvtHandler stack, I am thinking should have 
> first access
> to ALL events, (~captured mouse) so as long as you retain state information 
> the next call
> to ProcessEvent(), possibly routed to TOOL::OnMouseMove(), you can/could in 
> there redraw
> the mouse cursor at the new desired location, or not.
> 
> See wxEventLoopBase in 
> http://docs.wxwidgets.org/trunk/classwx_event_loop_base.html
> 
> This class sucks events out of the os queue, and gets first dibs on any 
> events, it is the
> first recipient of any OS events when it is alive, and dispatching happens 
> from here.
> 
> 
> If simply residing topmost on the wxEvtHandler stack does not give you enough 
> control,
> then there is the option to create another wxEventLoopBase temporarily.
> 
> 


Here are some nice graphics and explanation of PushEventHandler:

http://docs.wxwidgets.org/trunk/classwx_window.html#a398c11ab9af7956067a964f560d1978c

It is my thinking that putting this in the wxFrame, by calling its 
PushEventHandler will
give you first dibs on all events.  If you follow the wEvent::Skip() protocol, 
and not
process events not pertinent to you, and I think this means knowing the client 
window area
coord and checking mouse events against that box, then any wxEvent can still 
find its way
to its normal destination outside the tool.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

On 08/13/2013 02:00 AM, Lorenzo Marcantonio wrote:
> On Tue, Aug 13, 2013 at 12:54:10AM -0500, Dick Hollenbeck wrote:
> 
> Huge mail, but very interesting...
> 
>> I cannot see how coroutines would work in a wx GUI program. Coroutines by 
>> definition are
>> the same OS thread under a second or more CPU stack region.  So we are 
>> talking about one
>> thread mimicking multiple.  Or are you using a contorted definition?  No way 
>> coroutines
>> will work in a wx program IMO.
> 
> More or less the reason for which I doubted it works... coroutines in
> this case are used to suspend/restart the process to avoid a state
> variable in a state machine. The main issue here is what to do when a
> coroutine need to exit... *if* these are created in the right
> environment you could just dispose of the stack and then return to the
> caller (unwinding the last frame would be tricky). There is a whole
> theory of continuation-style programming, most of that can't be applied
> to C++, since it requires a branched stack (IIRC that's the reason for
> the call limitation in python generators)
> 
> I think that if:
> - Coroutine are created with a 'neutral' stack (i.e. nothing living
>   after their return)
> - Every event dispatch to the coroutine until a yield or terminate
>   occur
> 
> It should work without any big trouble (maybe some limitation in what
> can be done in the coroutine, but I don't think a lot).
> 
>> The goal of the tool event handler should be to cooperatively return as fast 
>> as it can,
>> since it is being called on the wx event handler thread.  If you cannot 
>> process the event
>> and cooperatively return as fast as you can, you need a separate wxThread to 
>> do on going
>> work.  This, at least if you want the user to continue to see quick 
>> interactive behaviour.
> 
> Well, that's not very different using a coroutine... in fact the old
> windows 3.1 application ran as huge coroutines from the OS yielding on
> GetMessage (and few other functions). MacOS class was cooperative too,
> AFAIK.
> 
> Paraphrasing: "the goal of the tool coroutine handler should be to
> *yield* as fast as it can, since it is being called on the wx event
> handler thread". The key here is that it yields, not return, so it keeps
> the whole processing state. All your consideration about a competing
> tool thread are correct *but* we have *no thread safety whatsoever* in
> kicad so it will be a huge work and source of race conditions.
> 
> Also there should be a theorem somewhere stating that all what you can
> do with a state machine can be done with a coroutine (and the converse);
> it's only a programming convenience (just like you could program kicad
> on a Turing machine, yeah:D)
> 
> A more realistic stance: what would have to do the tool code that would
> need a separate thread? Since it need to provide feedback, he would have
> to wait for that thread anyway (making the fork not useful...). IMHO
> most performance problems in pcbnew can be solved with better data
> structures (like spatial indices as discussed).
> 
>> If you were to duplicate the pcbnew behaviours we have now under the new tool
>> architecture, your tools would mostly all have one state in them.  The act 
>> of changing
>> tools would be the main state machine.  You only need more than one state, 
>> within the same
>> tool, when you plan on doing something different with the same kind of 
>> event.  If you
>> always intend to do the same thing with any given event type, you do not 
>> need more than
>> one state in a tool.  The tool can be thought of as a sub-state machine.  
>> The tool change
>> is the topmost state machine.
> 
> I don't feel the 'tool change' is a transition... otherwise even moving
> the cursor would be:D is more like swapping one state machine with
> another and aborting the previous one. Your sub-state machine would be
> the tool state machine, I agree with that. Track lying use case
> (extremely simplified)
> 
> S1: pick the start point
> S2: drag trace
> 
> With a pure state machine that would be like:
> 
> S1/mouse move -> update cursor -> S1
> S1/click -> validate start position, pin start -> S2
> S2/mouse move -> update rubber track -> S2
> S2/click -> validate rubber track, pin start -> S2
> S2/end track -> validate rubber track -> S1
> 
> With a coroutine it would be like (heavily pseudocoded, I'm focusing on
> the coroutine view *not* on how event are dispatched in it). Please
> correct me if I misunderstood something here
> 
> forever {
&g

Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

> 
> I find track laying impossible without mouse warping... there is an
> option to disable it. But how could you *emulate* it, if there is no way
> to physically move the pointer? 


The OS+native windowing system will move the mouse coordinates in the next 
mouse move event.

Your tool, if pushed onto the wxEvtHandler stack, I am thinking should have 
first access
to ALL events, (~captured mouse) so as long as you retain state information the 
next call
to ProcessEvent(), possibly routed to TOOL::OnMouseMove(), you can/could in 
there redraw
the mouse cursor at the new desired location, or not.

See wxEventLoopBase in 
http://docs.wxwidgets.org/trunk/classwx_event_loop_base.html

This class sucks events out of the os queue, and gets first dibs on any events, 
it is the
first recipient of any OS events when it is alive, and dispatching happens from 
here.


If simply residing topmost on the wxEvtHandler stack does not give you enough 
control,
then there is the option to create another wxEventLoopBase temporarily.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

On 08/12/2013 01:29 PM, Tomasz Wlostowski wrote:
> On 08/12/2013 04:24 PM, Dick Hollenbeck wrote:
>>
>>
>> Unfortunately, I guess I am losing my hope that we have a unified vision.
>>
>> We apparently do not.
>>
>> The project is based on wx.  The portions of wx that are objectionable, to 
>> me are:
> 
> Dick, Wayne,
> 
> I said I'd prefer to not use wxEvtHandler for deriving the tools from, 
> but the tool framework code is at a proposal stage, so everything can be 
> changed.
> 
> I did my own event system, because I wanted to test some concepts (such 
> as FSM state switching and coroutines) which are orthogonal to any UI 
> library. I'm not a wxWidgets guru, and perhaps most of my requirements 
> could be met with some hacking of the wx's event system - I'm asking for 
> your help here. The reasons why I didn't use wxEvent/wxEvtHandler right 
> away are below:
> 
> - wxEvtHandler specifies a single method for handling events:
> 
> virtual bool ProcessEvent().
> 
> My idea was to have states in separate methods. One reason is avoid 
> enumerating states (and a big switch() statement in 
> MY_TOOL::ProcessEvent()), another is that with states in methods, FSMs 
> could be easily specialized by inheritance. I guess it should be 
> possible to do the same using a wxEventHandler. The base tool class 
> derived from wxEvtHandler could implement its own ProcessEvent() with 
> reworked dispatching code from TOOL_MANAGER, that calls the actual state 
> handlers and/or wakes them coroutines.

I cannot see how coroutines would work in a wx GUI program. Coroutines by 
definition are
the same OS thread under a second or more CPU stack region.  So we are talking 
about one
thread mimicking multiple.  Or are you using a contorted definition?  No way 
coroutines
will work in a wx program IMO.


The goal of the tool event handler should be to cooperatively return as fast as 
it can,
since it is being called on the wx event handler thread.  If you cannot process 
the event
and cooperatively return as fast as you can, you need a separate wxThread to do 
on going
work.  This, at least if you want the user to continue to see quick interactive 
behaviour.
 If you were doing a print run, where the user might have lower expectations on
responsiveness, then you don't need the wxThread helper thread.  If the 
wxThread also had
its own wxEvtHandler, you can queue wxEvents through there, so it becomes a way 
to
dispatch work tasks to a helper thread, say long compute runs, or whatever.  
The two
threads could simply use wxEvents to talk to each other, each by poking 
something into the
others event queue.  Let's hope wxThread helpers are not often needed.  Most 
tools won't
need them.


If you were to duplicate the pcbnew behaviours we have now under the new tool
architecture, your tools would mostly all have one state in them.  The act of 
changing
tools would be the main state machine.  You only need more than one state, 
within the same
tool, when you plan on doing something different with the same kind of event.  
If you
always intend to do the same thing with any given event type, you do not need 
more than
one state in a tool.  The tool can be thought of as a sub-state machine.  The 
tool change
is the topmost state machine.

I have used member function pointers and switch statements to put a state 
machine into a
class.  Here we are talking about 're-enterable' state machines, since we 
cooperatively
return as fast as we can after each event.  When we come back in to the tool via
ProcessEvent(), the tool can route execution to the state specific code.  When 
picking
between member function pointer or enums to identify states, enums are my 
preference,
because under a debugger if you have a variable that is an

enum STATE_T
{
}  m_state;


Then in the debugger m_state will always show with its *named* value.  No such 
joy with a
member function pointer.  If the enums are all sequential from zero, then the

 switch( m_state )

statement will be translated to an array like jump table by the compiler and 
this is only
basically two machine instructions.

The base tool class could be rigged to duplicate some of the event 
classification that
wxWindow::ProcessEvent() does.  This way you can at least get your mouse events 
and
keyboard events into to separate virtual functions, and derived tool classes 
would need to
override these if they want to do anything tool specific within these 
categories of
events.  It could also be a runtime decision as to whether the base tool class 
does the
classification and routes mouse events to OnMouseHandler(), or not.  A boolean 
to the
constructor could decide yeah or nay at the base tool class.

If you are going to use multiple states in a tool, and a OnMouseHandler(), and a
OnKeyHandler(), then you would need a s

Re: [Kicad-developers] GITHUB_PLUGIN

[Dick Hollenbeck]

On 08/12/2013 11:54 PM, Dick Hollenbeck wrote:
> On 08/12/2013 01:11 PM, Chris Morgan wrote:
>> On Mon, Aug 12, 2013 at 12:05 PM, Dick Hollenbeck  wrote:
>>> On 08/12/2013 10:22 AM, Chris Morgan wrote:
>>>> On Mon, Aug 12, 2013 at 11:13 AM, Dick Hollenbeck  wrote:
>>>>> FYI,
>>>>>
>>>>> In looking at an http plugin for pcbnew, here are my findings so far:
>>>>>
>>>>> It occurred to me that only three class PLUGIN functions seem to be 
>>>>> necessary
>>>>>
>>>>>   *) IsWriteable()  this is one line, "return false".
>>>>>   *) FootprintEnumerate()
>>>>>   *) FootprintLoad()
>>>>>
>>>>>
>>>>> So basically two functions.  I wrote FootprintLoad() in about 4 hours 
>>>>> using wxHTTP,
>>>>> complete with "redirect" handling that I added.  FootprintEnumerate() is 
>>>>> website dependent
>>>>> since you have to parse the dir listing coming back.
>>>>>
>>>>>
>>>>> This is a trivial amount of work, but you have something website specific 
>>>>> that is read
>>>>> only for ever.  And that is not a terrible thing, quite useful.
>>>>>
>>>>>
>>>>> Then and found an API at GITHUB, and formulated more thoughts about that, 
>>>>> so what follows
>>>>> is the formation of a work package:
>>>>> ==
>>>>>
>>>>>
>>>>>
>>>>>http://developer.github.com/v3/
>>>>>
>>>>>
>>>>> is a marriage made in heaven for pcbnew.  The only missing building block 
>>>>> is https
>>>>> support.  We have to parse a little JSON, but this is in boost::property 
>>>>> tree already in
>>>>> the source tree.
>>>>>
>>>>> It also gave me a better handle on the use cases of the fp lib table 
>>>>> dialog window, which
>>>>> now seems to require a little better support for the options column.  I 
>>>>> can envision a
>>>>> property table two column popup dialog that lets you show the options in 
>>>>> name value form.
>>>>>  (Also maybe an additional PLUGIN api function that returns the options 
>>>>> that each plugin
>>>>> knows about as fodder for this generic dialog window.)  Upon return from 
>>>>> the popup dialog,
>>>>> you get a string in form
>>>>>
>>>>>   "option1=value1,option2,option3=value3"
>>>>>
>>>>> That goes back into the fp lib table dialog "options" column.
>>>>>
>>>>> And of course this property dialog must parse this string upon 
>>>>> invocation.  The parser can
>>>>> be re-used if the results go into a PROPERTIES class instance so it can 
>>>>> also be passed to
>>>>> the PLUGIN api functions too.
>>>>>
>>>>> RE: https.  I have a couple of options in mind for that, after which I am 
>>>>> thinking we
>>>>> could start with a read only GITHUB_PLUGIN implementation, and grow into 
>>>>> something with
>>>>> write capabilities down the line.
>>>>>
>>>>>
>>>>> I need to solve the https gap in the least painful way.  Possibilities I 
>>>>> see are:
>>>>>
>>>>> a) cpp-netlib which has HTTPS client, looks like it needs g++ 4.7 to 
>>>>> compile, although
>>>>> I've yet to verify this is the case when sub-setting it.
>>>>>
>>>>> b) cherry pick libpoco, which I have used, and has HTTPS client.
>>>>>
>>>>> c) add ssl support on top of wxHTTP using boost and openssl in the same 
>>>>> way boost does it
>>>>> for non SSL boost::ASIO sockets.
>>>>>
>>>>>
>>>>> These are currently about equal in my mind.  Note that merely having SSL 
>>>>> sockets is not as
>>>>> rich as having an HTTPS client, since much header and replay parsing 
>>>>> support is need.
>>>>>
>>>>> If anyone is a networking jockey and wants to work with me on this let me 
>>>>> know.  I think I
>&

Re: [Kicad-developers] GITHUB_PLUGIN

[Dick Hollenbeck]

On 08/12/2013 01:11 PM, Chris Morgan wrote:
> On Mon, Aug 12, 2013 at 12:05 PM, Dick Hollenbeck  wrote:
>> On 08/12/2013 10:22 AM, Chris Morgan wrote:
>>> On Mon, Aug 12, 2013 at 11:13 AM, Dick Hollenbeck  wrote:
>>>> FYI,
>>>>
>>>> In looking at an http plugin for pcbnew, here are my findings so far:
>>>>
>>>> It occurred to me that only three class PLUGIN functions seem to be 
>>>> necessary
>>>>
>>>>   *) IsWriteable()  this is one line, "return false".
>>>>   *) FootprintEnumerate()
>>>>   *) FootprintLoad()
>>>>
>>>>
>>>> So basically two functions.  I wrote FootprintLoad() in about 4 hours 
>>>> using wxHTTP,
>>>> complete with "redirect" handling that I added.  FootprintEnumerate() is 
>>>> website dependent
>>>> since you have to parse the dir listing coming back.
>>>>
>>>>
>>>> This is a trivial amount of work, but you have something website specific 
>>>> that is read
>>>> only for ever.  And that is not a terrible thing, quite useful.
>>>>
>>>>
>>>> Then and found an API at GITHUB, and formulated more thoughts about that, 
>>>> so what follows
>>>> is the formation of a work package:
>>>> ==
>>>>
>>>>
>>>>
>>>>http://developer.github.com/v3/
>>>>
>>>>
>>>> is a marriage made in heaven for pcbnew.  The only missing building block 
>>>> is https
>>>> support.  We have to parse a little JSON, but this is in boost::property 
>>>> tree already in
>>>> the source tree.
>>>>
>>>> It also gave me a better handle on the use cases of the fp lib table 
>>>> dialog window, which
>>>> now seems to require a little better support for the options column.  I 
>>>> can envision a
>>>> property table two column popup dialog that lets you show the options in 
>>>> name value form.
>>>>  (Also maybe an additional PLUGIN api function that returns the options 
>>>> that each plugin
>>>> knows about as fodder for this generic dialog window.)  Upon return from 
>>>> the popup dialog,
>>>> you get a string in form
>>>>
>>>>   "option1=value1,option2,option3=value3"
>>>>
>>>> That goes back into the fp lib table dialog "options" column.
>>>>
>>>> And of course this property dialog must parse this string upon invocation. 
>>>>  The parser can
>>>> be re-used if the results go into a PROPERTIES class instance so it can 
>>>> also be passed to
>>>> the PLUGIN api functions too.
>>>>
>>>> RE: https.  I have a couple of options in mind for that, after which I am 
>>>> thinking we
>>>> could start with a read only GITHUB_PLUGIN implementation, and grow into 
>>>> something with
>>>> write capabilities down the line.
>>>>
>>>>
>>>> I need to solve the https gap in the least painful way.  Possibilities I 
>>>> see are:
>>>>
>>>> a) cpp-netlib which has HTTPS client, looks like it needs g++ 4.7 to 
>>>> compile, although
>>>> I've yet to verify this is the case when sub-setting it.
>>>>
>>>> b) cherry pick libpoco, which I have used, and has HTTPS client.
>>>>
>>>> c) add ssl support on top of wxHTTP using boost and openssl in the same 
>>>> way boost does it
>>>> for non SSL boost::ASIO sockets.
>>>>
>>>>
>>>> These are currently about equal in my mind.  Note that merely having SSL 
>>>> sockets is not as
>>>> rich as having an HTTPS client, since much header and replay parsing 
>>>> support is need.
>>>>
>>>> If anyone is a networking jockey and wants to work with me on this let me 
>>>> know.  I think I
>>>> could and would code the read only form of the plugin in about 2 days if 
>>>> we had the HTTPS
>>>> client support in place.  That is bogging me down right now, and brings 
>>>> the total work to
>>>> over 3 days, which I have to defer because of other work.
>>>>
>>>>
>>>> Dick
>>>>
>>>
>>>
>>> I had seen

Re: [Kicad-developers] GITHUB_PLUGIN

[Dick Hollenbeck]

On 08/12/2013 10:22 AM, Chris Morgan wrote:
> On Mon, Aug 12, 2013 at 11:13 AM, Dick Hollenbeck  wrote:
>> FYI,
>>
>> In looking at an http plugin for pcbnew, here are my findings so far:
>>
>> It occurred to me that only three class PLUGIN functions seem to be necessary
>>
>>   *) IsWriteable()  this is one line, "return false".
>>   *) FootprintEnumerate()
>>   *) FootprintLoad()
>>
>>
>> So basically two functions.  I wrote FootprintLoad() in about 4 hours using 
>> wxHTTP,
>> complete with "redirect" handling that I added.  FootprintEnumerate() is 
>> website dependent
>> since you have to parse the dir listing coming back.
>>
>>
>> This is a trivial amount of work, but you have something website specific 
>> that is read
>> only for ever.  And that is not a terrible thing, quite useful.
>>
>>
>> Then and found an API at GITHUB, and formulated more thoughts about that, so 
>> what follows
>> is the formation of a work package:
>> ==
>>
>>
>>
>>http://developer.github.com/v3/
>>
>>
>> is a marriage made in heaven for pcbnew.  The only missing building block is 
>> https
>> support.  We have to parse a little JSON, but this is in boost::property 
>> tree already in
>> the source tree.
>>
>> It also gave me a better handle on the use cases of the fp lib table dialog 
>> window, which
>> now seems to require a little better support for the options column.  I can 
>> envision a
>> property table two column popup dialog that lets you show the options in 
>> name value form.
>>  (Also maybe an additional PLUGIN api function that returns the options that 
>> each plugin
>> knows about as fodder for this generic dialog window.)  Upon return from the 
>> popup dialog,
>> you get a string in form
>>
>>   "option1=value1,option2,option3=value3"
>>
>> That goes back into the fp lib table dialog "options" column.
>>
>> And of course this property dialog must parse this string upon invocation.  
>> The parser can
>> be re-used if the results go into a PROPERTIES class instance so it can also 
>> be passed to
>> the PLUGIN api functions too.
>>
>> RE: https.  I have a couple of options in mind for that, after which I am 
>> thinking we
>> could start with a read only GITHUB_PLUGIN implementation, and grow into 
>> something with
>> write capabilities down the line.
>>
>>
>> I need to solve the https gap in the least painful way.  Possibilities I see 
>> are:
>>
>> a) cpp-netlib which has HTTPS client, looks like it needs g++ 4.7 to 
>> compile, although
>> I've yet to verify this is the case when sub-setting it.
>>
>> b) cherry pick libpoco, which I have used, and has HTTPS client.
>>
>> c) add ssl support on top of wxHTTP using boost and openssl in the same way 
>> boost does it
>> for non SSL boost::ASIO sockets.
>>
>>
>> These are currently about equal in my mind.  Note that merely having SSL 
>> sockets is not as
>> rich as having an HTTPS client, since much header and replay parsing support 
>> is need.
>>
>> If anyone is a networking jockey and wants to work with me on this let me 
>> know.  I think I
>> could and would code the read only form of the plugin in about 2 days if we 
>> had the HTTPS
>> client support in place.  That is bogging me down right now, and brings the 
>> total work to
>> over 3 days, which I have to defer because of other work.
>>
>>
>> Dick
>>
> 
> 
> I had seen the github api when I was putting together some of the
> ideas about the online library sharing. It looks like a lot of the
> approaches they've used could be borrowed. I presume you are referring
> to using github directly?

Correct.

 I was more thinking the api was suitable to
> build upon for a custom server implementation with additional commands
> to handle our application specific usage.


That is also possible if you find the development resources to do it.   There 
are no fixed
limits on the number nor the types of pcbnew PLUGINs that get written.


If you decide to do that, *start by identifying the development resources*.  In 
my case of
GITHUB plugin, because of past discussions that we have had on the topic, and 
all the work
and planning that I put into the PLUGIN API so that it COULD HANDLE REMOTE 
ACCESS,

   *I am prepared to provide the development resources*

to do GITHUB_PLUGIN.  Although if I

Re: [Kicad-developers] GITHUB_PLUGIN

[Dick Hollenbeck]

On 08/12/2013 10:13 AM, Dick Hollenbeck wrote:
> FYI,
> 
> In looking at an http plugin for pcbnew, here are my findings so far:
> 
> It occurred to me that only three class PLUGIN functions seem to be necessary
> 
>   *) IsWriteable()  this is one line, "return false".
>   *) FootprintEnumerate()
>   *) FootprintLoad()
> 
> 
> So basically two functions.  I wrote FootprintLoad() in about 4 hours using 
> wxHTTP,
> complete with "redirect" handling that I added.  FootprintEnumerate() is 
> website dependent
> since you have to parse the dir listing coming back.

What makes this possible is the use of the pretty format and individual 
*.kicad_mod files
in the libpath.  The "libpath" for this plugin is all but the filename portion 
of the URL,
libpath = http://path_to_dir.

So to get the footprint, you just http GET 
http://path_to_dir/footprintname.kicad_mod.

Dick




> 
> 
> This is a trivial amount of work, but you have something website specific 
> that is read
> only for ever.  And that is not a terrible thing, quite useful.
> 
> 
> Then and found an API at GITHUB, and formulated more thoughts about that, so 
> what follows
> is the formation of a work package:
> ==
> 
> 
> 
>http://developer.github.com/v3/
> 
> 
> is a marriage made in heaven for pcbnew.  The only missing building block is 
> https
> support.  We have to parse a little JSON, but this is in boost::property tree 
> already in
> the source tree.
> 
> It also gave me a better handle on the use cases of the fp lib table dialog 
> window, which
> now seems to require a little better support for the options column.  I can 
> envision a
> property table two column popup dialog that lets you show the options in name 
> value form.
>  (Also maybe an additional PLUGIN api function that returns the options that 
> each plugin
> knows about as fodder for this generic dialog window.)  Upon return from the 
> popup dialog,
> you get a string in form
> 
>   "option1=value1,option2,option3=value3"
> 
> That goes back into the fp lib table dialog "options" column.
> 
> And of course this property dialog must parse this string upon invocation.  
> The parser can
> be re-used if the results go into a PROPERTIES class instance so it can also 
> be passed to
> the PLUGIN api functions too.
> 
> RE: https.  I have a couple of options in mind for that, after which I am 
> thinking we
> could start with a read only GITHUB_PLUGIN implementation, and grow into 
> something with
> write capabilities down the line.
> 
> 
> I need to solve the https gap in the least painful way.  Possibilities I see 
> are:
> 
> a) cpp-netlib which has HTTPS client, looks like it needs g++ 4.7 to compile, 
> although
> I've yet to verify this is the case when sub-setting it.
> 
> b) cherry pick libpoco, which I have used, and has HTTPS client.
> 
> c) add ssl support on top of wxHTTP using boost and openssl in the same way 
> boost does it
> for non SSL boost::ASIO sockets.
> 
> 
> These are currently about equal in my mind.  Note that merely having SSL 
> sockets is not as
> rich as having an HTTPS client, since much header and replay parsing support 
> is need.
> 
> If anyone is a networking jockey and wants to work with me on this let me 
> know.  I think I
> could and would code the read only form of the plugin in about 2 days if we 
> had the HTTPS
> client support in place.  That is bogging me down right now, and brings the 
> total work to
> over 3 days, which I have to defer because of other work.
> 
> 
> Dick
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] GITHUB_PLUGIN

[Dick Hollenbeck]

FYI,

In looking at an http plugin for pcbnew, here are my findings so far:

It occurred to me that only three class PLUGIN functions seem to be necessary

  *) IsWriteable()  this is one line, "return false".
  *) FootprintEnumerate()
  *) FootprintLoad()


So basically two functions.  I wrote FootprintLoad() in about 4 hours using 
wxHTTP,
complete with "redirect" handling that I added.  FootprintEnumerate() is 
website dependent
since you have to parse the dir listing coming back.


This is a trivial amount of work, but you have something website specific that 
is read
only for ever.  And that is not a terrible thing, quite useful.


Then and found an API at GITHUB, and formulated more thoughts about that, so 
what follows
is the formation of a work package:
==



   http://developer.github.com/v3/


is a marriage made in heaven for pcbnew.  The only missing building block is 
https
support.  We have to parse a little JSON, but this is in boost::property tree 
already in
the source tree.

It also gave me a better handle on the use cases of the fp lib table dialog 
window, which
now seems to require a little better support for the options column.  I can 
envision a
property table two column popup dialog that lets you show the options in name 
value form.
 (Also maybe an additional PLUGIN api function that returns the options that 
each plugin
knows about as fodder for this generic dialog window.)  Upon return from the 
popup dialog,
you get a string in form

  "option1=value1,option2,option3=value3"

That goes back into the fp lib table dialog "options" column.

And of course this property dialog must parse this string upon invocation.  The 
parser can
be re-used if the results go into a PROPERTIES class instance so it can also be 
passed to
the PLUGIN api functions too.

RE: https.  I have a couple of options in mind for that, after which I am 
thinking we
could start with a read only GITHUB_PLUGIN implementation, and grow into 
something with
write capabilities down the line.


I need to solve the https gap in the least painful way.  Possibilities I see 
are:

a) cpp-netlib which has HTTPS client, looks like it needs g++ 4.7 to compile, 
although
I've yet to verify this is the case when sub-setting it.

b) cherry pick libpoco, which I have used, and has HTTPS client.

c) add ssl support on top of wxHTTP using boost and openssl in the same way 
boost does it
for non SSL boost::ASIO sockets.


These are currently about equal in my mind.  Note that merely having SSL 
sockets is not as
rich as having an HTTPS client, since much header and replay parsing support is 
need.

If anyone is a networking jockey and wants to work with me on this let me know. 
 I think I
could and would code the read only form of the plugin in about 2 days if we had 
the HTTPS
client support in place.  That is bogging me down right now, and brings the 
total work to
over 3 days, which I have to defer because of other work.


Dick


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

On 08/12/2013 09:09 AM, Tomasz Wlostowski wrote:
> On 08/12/2013 03:46 PM, Dick Hollenbeck wrote:
>> On 08/12/2013 04:19 AM, Tomasz Wlostowski wrote:
> 
>>
>> http://docs.wxwidgets.org/trunk/classwx_evt_handler.html#a78719e8b82c9f9c6e4056b3449df1943
>>
>>
>> The Connect() method lets you connect wxEvtHandlers together.  Seems like 
>> the base tool
>> clase should be derived from wxEvtHandler.  Significant building blocks of 
>> the
>> infrastructure is already in wx that I can tell.
> Hi,
> 
> I would really prefer to avoid mixing wxWidgets classes with the tool 
> classes. My reasons are:
> - tools should be invoke-able without launching any GUI or even without 
> dependencies on the GUI library,
> - tool events are board-space (coordinates) and adjusted to 
> misbehaviours of wx on different platforms.
> - deriving TOOL_BASE/TOOL_INTERACTIVE classes from wxEvtHandler will 
> drag in wx dependency everywhere, which I find against the modularity 
> concept. That's why I decided to have a separate TOOL_DISPATCHER class, 
> which proxies wx events between the GUI (both frame and the draw panel) 
> and the tools.


Unfortunately, I guess I am losing my hope that we have a unified vision.

We apparently do not.

The project is based on wx.  The portions of wx that are objectionable, to me 
are:

graphics api, and wxString.


The rest of it are pretty nice.  We/you dodged the graphics api issue.  
wxString is just a
disease we can live with.

If your concern is the ability to "link" a tool as a separate DLL/DSO without 
pulling in
wx code into that DLL/DSO, then I share that concern, but I don't think it is a 
problem, I
believe it can be done with some close investigation.


I am going to go away and cry now.  Go silent.  I was hopeful we had a unified 
vision, but
I fear we do not. Your document did not expose enough details.

When I was young like you my tendency was to over design everything.  I have 
since changed
to trying to find the simplest solution possible.  This has numerous benefits, 
not the
least of which is getting other folks to understand your concepts.  This is 
important in
our current situation because other folks have to write tools, and the API 
documentation
and infrastructure of wxEvtHandler is in place.

Maybe a way forward is for you to state why wxEvtHandler is not up to the task, 
without
using the explanation, "it is part of wx".

Ultimately, KiCad is built on wx, and to try and deny that seems like a pursuit 
without a
reward.  If and when you want to port KiCad to Qt, then replace wxEvtHandler 
then.

I don't have time to back and forth much on this right now.

Dick





> 
>>
>> My "buy in" for the tool concept is premised on the notion that the handler 
>> functions
>> would exist in the tool which received the event, this is the knowledge 
>> encapsulation and
>> the modularity value proposition.
> 
> This is the current situation. Tools request certain types of events 
> using Go() or Wait() statements, and the events are propagated to either 
> the state handler (Go) or the next line of code (Wait).
> 
> Imagine the following chain of events
> - router tool (top of stack) and persistent behaviour tool (bottom of 
> stack) are active,
> - user clicks CTRL-LMB,
> - route tool hasn't requested such type of event, so it gets handled by 
> the next tool in the stack,
> - persistent behaviour tool receives the CTRL+LMB click and highlights 
> the net below the cursor.
> 
>>
>> b) expand the event arguments into primitive variable types and call a 
>> member function,
>> still in the tool, using non-event i.e. primitive argument types, so that 
>> such latter
>> function can be SWIGed.
> I don't know much about abilities of SWIG, but can't it pass complex 
> objects to C++ functions?
>>
>>
>> The talk about delegates makes me slightly nervous, because to me it 
>> connotes an
>> additional class, and that is not what I bought into.  It strays from the 
>> encapsulation
>> concept that I found so attractive.
> They are not exposed to the programmer. By delegate I mean simply a 
> pointer to a method in a particular object:
> 
> class myclass { void method() {} };
> myclass myobject;
> 
> DELEGATE0 ptr (&myobject, &myclass::method );
> 
> ptr(); -> calls myobject::method.
> 
> So a transition in a tool FSM is defined by a set of trigger events and 
> a state handler (the delegate).
> 
> Tom
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

On 08/12/2013 04:19 AM, Tomasz Wlostowski wrote:
> On 08/10/2013 04:28 PM, Lorenzo Marcantonio wrote:
>> On Sat, Aug 10, 2013 at 08:27:26AM -0500, Dick Hollenbeck wrote:
>>> a) If tools are extended from a base class, the persistent behaviours could 
>>> be inherited.
>>>
>>> b) If tools are pushed on a stack when they become active, and if you have 
>>> a mechanism(...)
>>
>> Both of those are good for me, the second one is a little more complex
>> and in fact emulates at runtime the VTBL (for example in
>> lua virtual calls work *exactly* like that: when a method is not found
>> it get searched in the ancestor class).
>  > (...)
>  > Another simpler idea is to install fallback handlers, i.e.  everything
>  > that's not handled by the current tool is subject to 'default
>  > processing'.
> 
> Hi Lorenzo,
> 
> IMHO It's a bit similar, but not exactly the same: events come to a tool 
> - it can then react and sometimes consume some of them so that other 
> tools (lower on the stack) don't receive these events anymore. Event 
> handlers are delegates (somewhat similar to signals/slots in Qt) and are 
> dispatched dynamically by the TOOL_MANAGER. This could be probably seen 
> as an enhanced virtual method mechanism... As for the default handlers - 
> there can be a tool permanently residing on the bottom of the stack and 
> dedicated for catching such events.


http://docs.wxwidgets.org/trunk/classwx_evt_handler.html#a78719e8b82c9f9c6e4056b3449df1943


The Connect() method lets you connect wxEvtHandlers together.  Seems like the 
base tool
clase should be derived from wxEvtHandler.  Significant building blocks of the
infrastructure is already in wx that I can tell.

My "buy in" for the tool concept is premised on the notion that the handler 
functions
would exist in the tool which received the event, this is the knowledge 
encapsulation and
the modularity value proposition.


If we extend wxEvtHandler, then we can examine events either in

virtual boolProcessEvent (wxEvent &event)

or in a hooked in handler via Connect() but in either case it would be nice to 
have the
initial handler:

a) reside in the tool, and

b) expand the event arguments into primitive variable types and call a member 
function,
still in the tool, using non-event i.e. primitive argument types, so that such 
latter
function can be SWIGed.


The talk about delegates makes me slightly nervous, because to me it connotes an
additional class, and that is not what I bought into.  It strays from the 
encapsulation
concept that I found so attractive.


Dick





> 
>   Do we need dynamic method
>> composition? I.e. will tool A be *always* below tool B or there may be
>> a tool C below tool B?
> I wouldn't preclude such scenario. Having a 2-level stack is as complex 
> as having an N-level one.
>>
>> I agree. The current 'left button' and 'right button' handlers are
>> awfully huge switch statements. Something a little more modular would be
>> helpful for the future :D
> Fully agree :)
>>
>>> Exciting stuff,
>>
>> That's independently of the GAL, I think some/most of this stuff would
>> be useful even for 'stock' kicad, however the GAL *requires* them... too
>> bad you can't have the xor blend in opengl:((( I really prefer the xor
>> contrast compared to Porter/Duff composition (maybe there is some shader
>> trick but good luck having it work fast on the Intel GPUs...).
> Shaders aren't that bad under intel drivers (the GAL works just fine on 
> a core i7 integrated graphics on my latptop, although Half-life 2 - a 
> 10-year old game doesn't because some texture formats are not 
> supported). Under Linux, if you want performance and truly 
> standard-compliant OpenGL, I'm afraid you have to use the evil Nvidia 
> binary driver...
> 
> Regard,
> Tom
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

On 08/12/2013 07:00 AM, Tomasz Wlostowski wrote:
> On 08/11/2013 06:39 PM, Dick Hollenbeck wrote:
> 
>>>
>>> I think that these doubt should be cleared thinking on 'what about if we
>>> could have two views on the same board' (which, incidentally, could be
>>> a good feature in the far future)
>>>
>>
>>
>> That is a fairly fundamental decision, sort of like the decision you have to 
>> make before
>> you start building:
>>
>> either a house or a boat.
>>
>> With rapid zoom in and out, a competing idea might be to store viewports as 
>> bookmarks.
>> This is a combo of zoom and viewport origin, and maybe cursor position also. 
>>  With the
>> bookmark you could rapidly BOARD hop.
> This is trivial to implement with the existing VIEW.
>>
>> I like full screen views, so I am less than neutral about multiple views for 
>> a BOARD.
> Me too.
>>
>> Schematic editor is a different discussion, there you can argue effectively 
>> for a tabbed
>> multisheet frame, but I prefer a full frame view of each sheet.
> IMHO the question is if we should have a possibility of multiple VIEWs 
> of the a single BOARD/schematic sheet. If its only about tabs, I'd say 
> its easier and less invasive to have a separate frame, view and 
> board/sch sheet for each tab. An application that could really take 
> advantage of multiple VIEWs would be some sort of collaborative PCB 
> editor allowing many designers to route the same, big board. But that's 
> far, far future, if ever...



I do that.  In our softplc runtime product multiple developers can work on the 
same
control program at the same time from various locations over TCP, and an edit 
that one
developer makes is propagated to other developer's views over TCP.

It gets even more interesting when you understand that the program can actually 
be
executing while you are editing it.  There is a built in incremental compiler 
in the
softplc runtime.

They use it to entirely run the largest power plant in the USA.  And about 10 
additional
smaller ones.

And anywhere else you might find PLCs in countless industries.

We recently ported it to the beaglebone, and we're doing some I/O boards for the
beaglebone now.


How important is realtime collaboration, vs. git repo collaboration for an EDA? 
 Or is
that simply a concurrent skype conversation or a form of a meeting using show 
and tell?

Like I said, I know how to do that.  Same old story, there is know how but no 
motive.


Dick





> 
> Regards,
> Tom
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

> 
> That's independently of the GAL, I think some/most of this stuff would
> be useful even for 'stock' kicad, 


Lorenzo,

I think it is positive for the project that you and I agree with Tom on this 
design
concept.  We are approaching a unified vision for the project moving forward.  
This
architecture also allows folks to contribute new tools and do so in a less 
disruptive and
modular fashion.

So if tools are the destination of code, then what are the sources of code for 
those
destination buckets?

Basically:  old code and new code.

You like it so much that you want to move old code into tools for 'stock" 
KiCad.  That is
a solid endorsement of the idea.

But I think Tom sees it as an opportunity to transport code into the new 
architecture.
The act of transporting code is a healthy endeavour because it lets you 
scrutinize and
revitalize and quality enhance.  It is like pouring a dirty liquid through a 
filter into a
new container.

So I hear Tom saying that the new containers could define the new GAL pcbnew.

One has to ask then:

"if the the GAL display code is working well enough, why don't we merge it in 
and start
writing tools?"  Clearly the P&S router is not the only thing that needs to be 
done.

With a #ifdef we can keep the new code out of the stock build binaries for 
awhile.
Co-mingling the source is possible, some minor drawbacks no doubt, but how bad 
are they?


Dick



> however the GAL *requires* them... too
> bad you can't have the xor blend in opengl:((( I really prefer the xor 
> contrast compared to Porter/Duff composition (maybe there is some shader
> trick but good luck having it work fast on the Intel GPUs...). Well,
> there *was* but it was deprecated together with color index mode and
> other 'non-photorealistic' stuff.
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

On 08/10/2013 01:22 PM, Lorenzo Marcantonio wrote:
> On Sat, Aug 10, 2013 at 09:53:40AM -0500, Dick Hollenbeck wrote:
> 
>> After more thought, and a long walk, I like it even more.  I guess you are 
>> talking putting
>> full featured board actions or procedural handlers in the tool also?  This 
>> opens up the
>> architecture quite a bit to extensions and is an outstanding idea Tom.
> 
> I only have one thing to say: please take care to not mix the model and
> the view/controller... sanity check: could the same operation be done
> from the scripting interface without calling the tool UI stuff? if not,
> some refactoring could be useful.
> 
>> I still think the frame is the best place for that data, if it cross-tool, 
>> else of course
>> in the tool.  For the data in the frame, maybe try and put the accessors in 
>> the base class
>> tool.  And declare that class a friend of the frame.   This at least keeps 
>> the interface
>> to the data clean, the tools really don't have to know where such frame 
>> resident data is.
> 
> 100% agree on that. 'General' display/control stuff IMHO should reside
> in the frame, unless it's some board-related preference: what is where
> is debatable and subject to a design decision; example: the aux origin
> is undeniably on the board, but should, say, the grid be tied to the
> board or to the view?

Data can reside on the moon if you have accessors that hide that fact.  The 
interface is
the important thing, since it is what is propagated through the client code.

In the case of the grid origin *data*, it had to be moved to the BOARD because 
PLUGINs
have no access to the frame, only to the BOARD, and the grid origin wanted to 
be saved to
disk as part of the board file.  And BOARDs should not know about frames, so no 
accessor
magic in the BOARD was possible.

But again, the grid origin accessor is the important thing, and the code that 
uses it can
use it just fine since it is in the frame.


> 
> I think that these doubt should be cleared thinking on 'what about if we
> could have two views on the same board' (which, incidentally, could be
> a good feature in the far future)
> 


That is a fairly fundamental decision, sort of like the decision you have to 
make before
you start building:

either a house or a boat.

With rapid zoom in and out, a competing idea might be to store viewports as 
bookmarks.
This is a combo of zoom and viewport origin, and maybe cursor position also.  
With the
bookmark you could rapidly BOARD hop.

I like full screen views, so I am less than neutral about multiple views for a 
BOARD.

Schematic editor is a different discussion, there you can argue effectively for 
a tabbed
multisheet frame, but I prefer a full frame view of each sheet.

Near term, I would vote against multiple BOARD views and how that would affect 
the pcbnew
code.


Dick


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

On 08/11/2013 01:44 AM, Lorenzo Marcantonio wrote:
> On Sat, Aug 10, 2013 at 04:34:03PM -0500, Dick Hollenbeck wrote:
>> The push and shove router is something I could have used today.  Whatever 
>> confidence I
>> used to have in freerouter is gone.  It is not working for me very well on 
>> this current
>> board, and I am frustrated to no end with it and the lack of support now.
> 
> Strange... what has freerouter of bad other than is java-slowness and
> foggy display?


Under freerouter, I saved to a dsn file after 5 hours of push and shove 
routing, a
partially complete design, and went to lunch figuratively, shutdown freerouter, 
when I
came back to load back in the dsn file, it could not load its own file.  This 
is the file
that *it* wrote to disk, presumably with the commitment that it could reload it 
later.  My
mistake was in believing that.  I could have concurrently saved to *.ses file 
also, at
least that way my intermediate work progress could have come back through 
pcbnew, then
back to freerouter. *.ses -> pcbnew -> *.dsn -> freerouter.

For years I have had numerous conversations with Alfons, mostly always the same 
two questions:

a) why he does not go open source?

b) why do you not report line numbers when you puke loading a file?  The 
procedure has
been "send him the file in personal email, and he walks through the code under 
a debugger
to find the problem".  This is now rubbish since he has retired.  So you are 
stuck
guessing.  This is guessing:  load the *.dsn file into a text editor, cut huge 
portions
out, try reloading again, when it finally loads, add back in the content in 
smaller
increments until you find the problem.  Then doctor it, load it and proceed.


So when I wrote my posting about freerouter, I was at that point of losing 5 
hours of work.

Fortunately in this case just this morning before church, I ran the freerouter 
written dsn
file through my s-expression beautifier, which you build under our 
/tools dir by


$ make property_tree

Then tried beautifying Alfons' file:

$ tools/property_tree a.dsn > /tmp/pray_hard.dsn

I got lucky.  /tmp/pray_hard.dsn loaded.  (Remember, I was on my way to church.)

In my tech support thread on his forum, I finally asked what I hope is a 
profoundly
important question to his many man years of excellent work.  The question is: 
"now that
you are retired, is it your intention to let freerouter simply fade into 
retirement also?
 Why not take pride in your retirement and let freerouter live on so you can at 
least take
a sense of pride in this extraordinary work?"

Of course I am nobody to him, and in retirement, freerouter may not be 
important to him
either.

That leaves us vulnerable.  Without a push and shove option to route, I would 
simply bite
the bullet and go buy a linux based EDA package, and quit with KiCad.  P&S is 
that
important to me.

Dick



> 
> OTOH I agree, the P&S would be very useful (100 pin packages, only two
> signal layers, 0,2mm clearance and a way-too-small board... I've ripped
> up the thing almost 6 times now...)
> 



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

Tom,

The other thing about your work is that it is important, very important.

The push and shove router is something I could have used today.  Whatever 
confidence I
used to have in freerouter is gone.  It is not working for me very well on this 
current
board, and I am frustrated to no end with it and the lack of support now.

Hoping for a better solution,

Dick





___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

On 08/10/2013 09:28 AM, Lorenzo Marcantonio wrote:
> On Sat, Aug 10, 2013 at 08:27:26AM -0500, Dick Hollenbeck wrote:
>> a) If tools are extended from a base class, the persistent behaviours could 
>> be inherited.
>>
>> b) If tools are pushed on a stack when they become active, and if you have a 
>> mechanism
>> which the tool uses to report whether it handled an event or not, then if 
>> not handled you
>> can pass the event to the next tool on the stack.  With this strategy you 
>> put the
>> persistent behaviours into the baseline tool, and stack temporary other 
>> tools onto the
>> stack above it.  Although you can go to more that two high, this 
>> architecture does not
>> require that you do.
> 
> Both of those are good for me, the second one is a little more complex
> and in fact emulates at runtime the VTBL (for example in
> lua virtual calls work *exactly* like that: when a method is not found
> it get searched in the ancestor class). Do we need dynamic method
> composition? I.e. will tool A be *always* below tool B or there may be
> a tool C below tool B? 


wx has a stack of event handlers built into each event context.
So what I describe is already written for you in wx, except the tests of the 
events, and
that is either a switch or else ifs.

I think this entire infrastructure in b) probably came from wx, its just that 
it lurked in
my subconscious for a few months until I wrote that.

The tools could be SWIGed, and this partitions the python function space into 
logical
categories.  That is, assuming you put the C++ handlers which to the actual 
work in the
tools, maybe without wxEvent parameters, but with expanded C++ arguments so 
python does
not have to fabricate an event to call them.



The second scenario rules out inheritance but
> I don't think we ever need that. As an aside object pickers could be
> handled as mixins or something similar...
> 
> Another simpler idea is to install fallback handlers, i.e.  everything
> that's not handled by the current tool is subject to 'default
> processing'. If this default processing is static in code or driven by
> some event processor depends on the degree of modularity required (think
> about 'event sieves', everything not handled pass down thru a 'chain' of
> handlers). IIRC gtk works that way.
> 
>> In general, those that have worked with state machines know that they 
>> provide benefits in
>> troubleshooting.  What you have done is to essentially divide what would 
>> otherwise be one
>> big state machine into smaller ones.  And I think this is a great idea.  :)
> 
> I agree. The current 'left button' and 'right button' handlers are
> awfully huge switch statements. Something a little more modular would be
> helpful for the future :D
> 
>> Exciting stuff,
> 
> That's independently of the GAL, I think some/most of this stuff would
> be useful even for 'stock' kicad, however the GAL *requires* them... too
> bad you can't have the xor blend in opengl:((( I really prefer the xor 
> contrast compared to Porter/Duff composition (maybe there is some shader
> trick but good luck having it work fast on the Intel GPUs...). Well,
> there *was* but it was deprecated together with color index mode and
> other 'non-photorealistic' stuff.
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

On 08/10/2013 08:27 AM, Dick Hollenbeck wrote:
> On 08/02/2013 12:10 PM, Tomasz Wlostowski wrote:
>>
>> There is a demo available (kicad-gal-orson branch), that shows a simple 
>> selection tool (Go to Edit->Selection tool with the GAL view enabled). 
>> It's not yet useful for any practical purposes and very unstable - It's 
>> purpose is it just to show the overall idea and prepare ground for 
>> technical discussion.
>>
>> Thanks in advance for your feedback,
>> Tom
> 
> 
> It looks great.
> 
> I have one minor feature that you would have probably added anyways, and that 
> is a way to
> handle persistent or default behaviours that are not addressed in any 
> particular tool.
> 
> What do I mean by persistent behaviours?  Example:
> 
> I like being able to hit the space bar at any time to set the relative 
> origin.  Would be
> pain to put that into every tool.
> 
> 
> For that I can suggest two things for you to think about:
> 
> a) If tools are extended from a base class, the persistent behaviours could 
> be inherited.
> 
> b) If tools are pushed on a stack when they become active, and if you have a 
> mechanism
> which the tool uses to report whether it handled an event or not, then if not 
> handled you
> can pass the event to the next tool on the stack.  With this strategy you put 
> the
> persistent behaviours into the baseline tool, and stack temporary other tools 
> onto the
> stack above it.  Although you can go to more that two high, this architecture 
> does not
> require that you do.
> 
> In general, those that have worked with state machines know that they provide 
> benefits in
> troubleshooting.  What you have done is to essentially divide what would 
> otherwise be one
> big state machine into smaller ones.  And I think this is a great idea.  :)

After more thought, and a long walk, I like it even more.  I guess you are 
talking putting
full featured board actions or procedural handlers in the tool also?  This 
opens up the
architecture quite a bit to extensions and is an outstanding idea Tom.

The question of data accessors comes up though, and where is the data kept 
pertinent to
the display, stuff which might be shared across tools yet is not related to the 
BOARD.

I still think the frame is the best place for that data, if it cross-tool, else 
of course
in the tool.  For the data in the frame, maybe try and put the accessors in the 
base class
tool.  And declare that class a friend of the frame.   This at least keeps the 
interface
to the data clean, the tools really don't have to know where such frame 
resident data is.

Other than that sticky spot, I think the benefits of bundling the know how with 
the state
machine is a very major positive architectural change.

Well done Tom.

Dick


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

On 08/02/2013 12:10 PM, Tomasz Wlostowski wrote:
> 
> There is a demo available (kicad-gal-orson branch), that shows a simple 
> selection tool (Go to Edit->Selection tool with the GAL view enabled). 
> It's not yet useful for any practical purposes and very unstable - It's 
> purpose is it just to show the overall idea and prepare ground for 
> technical discussion.
> 
> Thanks in advance for your feedback,
> Tom


It looks great.

I have one minor feature that you would have probably added anyways, and that 
is a way to
handle persistent or default behaviours that are not addressed in any 
particular tool.

What do I mean by persistent behaviours?  Example:

I like being able to hit the space bar at any time to set the relative origin.  
Would be
pain to put that into every tool.


For that I can suggest two things for you to think about:

a) If tools are extended from a base class, the persistent behaviours could be 
inherited.

b) If tools are pushed on a stack when they become active, and if you have a 
mechanism
which the tool uses to report whether it handled an event or not, then if not 
handled you
can pass the event to the next tool on the stack.  With this strategy you put 
the
persistent behaviours into the baseline tool, and stack temporary other tools 
onto the
stack above it.  Although you can go to more that two high, this architecture 
does not
require that you do.

In general, those that have worked with state machines know that they provide 
benefits in
troubleshooting.  What you have done is to essentially divide what would 
otherwise be one
big state machine into smaller ones.  And I think this is a great idea.  :)

Exciting stuff,

Dick


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

On 08/09/2013 10:15 PM, Dick Hollenbeck wrote:
> On 08/02/2013 12:10 PM, Tomasz Wlostowski wrote:
>> Hello,
>>
>> Thanks to Orson, Camille, Vesa and others we now have the cool and 
>> lightning-fast GAL-driven graphics view in pcbnew. Now it's time to make 
>> it do some real work, that means editing operations.
>>
>> Since the GAL does not allow XOR rendering, some significant refactoring 
>> of the editing tools' code will have to happen at some point. I took it 
>> as an opportunity to propose a tiny library/framework/abstraction (pick 
>> your favorite name) for the editing tools. Its main goals are:
>> - separate tool = separate class, contrary to the current state where 
>> all tools reside in PCB_EDIT_FRAME event handlers. This would allow for
>> writing new tools without touching the frame code (which is quite 
>> complex) and abstract tools into plugins.
>> - no "asynchronous" drawing. If a tool wants to draw something, it adds 
>> it to a VIEW, and the VIEW makes sure it's displayed in correct order 
>> and without damaging other parts of screen.
>> - eliminate static/global tool states.
>> - independence from the GUI toolkit and its quirks on different systems. 
>> Tools get the events in world space that are already adjusted to what's 
>> going on with the view (panning, scrolling, zoom, etc.)
>> - tools accessible from scripts
>>
>> I wrote a slightly longer technical description and uploaded it to the 
>> CERN project Wiki: http://www.ohwr.org/projects/cern-kicad/wiki/Kicad-tool.
>>
>> There is a demo available (kicad-gal-orson branch), that shows a simple 
>> selection tool (Go to Edit->Selection tool with the GAL view enabled). 
>> It's not yet useful for any practical purposes and very unstable - It's 
>> purpose is it just to show the overall idea and prepare ground for 
>> technical discussion.
>>
>> Thanks in advance for your feedback,
>> Tom
> 
> Tom,
> 
> You deserve better than this buddy.  Anyone give you feedback yet?
> 
> I will try to this weekend.  Please don't take the silence as anyone thinking 
> your work is
> not exceedingly important.


Wayne, JP, anyone else, please give this document a look over, or live with the 
choices
Tom makes.   (Neither path is likely to be bad.)

Thanks,

Dick


> 
> 
> Thanks,
> 
> 
> Dick
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Tool Framework

[Dick Hollenbeck]

On 08/02/2013 12:10 PM, Tomasz Wlostowski wrote:
> Hello,
> 
> Thanks to Orson, Camille, Vesa and others we now have the cool and 
> lightning-fast GAL-driven graphics view in pcbnew. Now it's time to make 
> it do some real work, that means editing operations.
> 
> Since the GAL does not allow XOR rendering, some significant refactoring 
> of the editing tools' code will have to happen at some point. I took it 
> as an opportunity to propose a tiny library/framework/abstraction (pick 
> your favorite name) for the editing tools. Its main goals are:
> - separate tool = separate class, contrary to the current state where 
> all tools reside in PCB_EDIT_FRAME event handlers. This would allow for
> writing new tools without touching the frame code (which is quite 
> complex) and abstract tools into plugins.
> - no "asynchronous" drawing. If a tool wants to draw something, it adds 
> it to a VIEW, and the VIEW makes sure it's displayed in correct order 
> and without damaging other parts of screen.
> - eliminate static/global tool states.
> - independence from the GUI toolkit and its quirks on different systems. 
> Tools get the events in world space that are already adjusted to what's 
> going on with the view (panning, scrolling, zoom, etc.)
> - tools accessible from scripts
> 
> I wrote a slightly longer technical description and uploaded it to the 
> CERN project Wiki: http://www.ohwr.org/projects/cern-kicad/wiki/Kicad-tool.
> 
> There is a demo available (kicad-gal-orson branch), that shows a simple 
> selection tool (Go to Edit->Selection tool with the GAL view enabled). 
> It's not yet useful for any practical purposes and very unstable - It's 
> purpose is it just to show the overall idea and prepare ground for 
> technical discussion.
> 
> Thanks in advance for your feedback,
> Tom

Tom,

You deserve better than this buddy.  Anyone give you feedback yet?

I will try to this weekend.  Please don't take the silence as anyone thinking 
your work is
not exceedingly important.


Thanks,


Dick


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Online library sharing idea

[Dick Hollenbeck]

On 08/09/2013 05:22 PM, schneidersoft wrote:
> Hi Dick,
> 
> this is Santa Claus, and I think I need to have a talk with you. If you 
> want to get rich go to Wall Street, if you simply want to make a living 
> focus on something what you can sell for money. But do me one favor 
> before you ticking off other people which are willing to contribute, 
> stop whining about this open source stuff not compensating your efforts. 
> Maybe you have not been able to raise 100 gran because nobody 
> needs/wants 'sweet'. Thought about that? You sound like a grumpy old 
> man. Even if you want to come across like that do it somewhere else, go 
> down to the sports-bar, moan to your barber but not to the KiCad community.
> 
> Greetings from Santa Claus (and Rudy)
> 
> aka Martin


Martin, I see that you have not contributed anything to our project.

So you have no standing to come in here and decide what will consume my mailing 
lists'
bandwidth.

I am removing you from our work studio.

We have had the conversation about remote libraries, in detail many time.

If and when you can contribute either funding, a spec, or a patch, then you may 
contact me
for possible re-admission to the mailing list.

This mailing list is for developers of KiCad.  Not for users wanting to hope 
stuff falls
out of the sky.  Nor for drive by assholes like you.


Dick




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Online library sharing idea

[Dick Hollenbeck]

On 08/09/2013 04:21 PM, Rick Walker wrote:
> 
> Here's what I'd like to see:


If I could give you guys Santa Claus's address, I would.  But I don't know it.  
So unless
you do know it, I suggest you start by deciding what you are willing to fund, 
or what
patch you are willing to contribute.


I know precisely what I am willing to do.

If its simply going to be more fun to ask for stuff without deciding how it is 
going to be
funded, then we should change the name of the mailing list to summertime santa 
claus.

By the way, I would like a shiny new Suburban, one that does not burn fuel, 
simply drives
down the road.


All purchase orders and patches will be given serious consideration.


Dick



> 
> 1) I can upload my footprints and symbols and they get tagged
> as "mine".   If I only want to share, but not take, then I
> can set the system up to only use my twork.
> 
> 2) If I find someone else has a similar esthetic to mine,
> then I can add their work to my usage list, either
> individually, or as a group.  So if I decide that "Joe" and I
> agree on grids, labelling and other criteria, I can select
> Joe's horde and make it part of my horde.  I can either
> select only stuff made by Joe, or select all of Joe's horde,
> which includes things that Joe has selected from other
> people.  Obviously, my choice depends on how much I trust
> Joe's stuff.  I can either just a selected number of his footprints,
> his entire personal library, or all his work and all the community
> work he thinks is worth adding to his search list. 
> 
> 3) When I select other peoples work to add to my horde, I can
> select a search order which allows better curated hordes to
> take precedence over less disciplined work.
> 
> This sort of a mechanism makes it easy for there to spontaneously
> emerge multiple libraries. 
> 
> For instance, I'm constantly annoyed by the lack of consistent scale
> between schematic symbols.  Why should a bypass cap symbol be as big as
> an entire op-amp?  The mechanism I propose would allow simultaneous
> growth of a "high layout density" schematic lib in parallel with a
> "large and airy" schematic lib. 
> 
> If a voting mechanism is included, and some way for people to search for
> various stylistic attributes (density, grid pitch, ansi/euro, etc), then
> people could easily query the system for "the highest voted fine grid,
> ansi library" as their primary horde, and the best voted "low density"
> lib as a fallback. 
> 
> Every person becomes a librarian of their own little niche of
> parts.  Some will curate lots of micros, some will be interested
> in vacuum tubes.  Some will work at the meta level and cherry
> pick the best of different categories to make a more complete
> overall lib with consistent layout style.
> 
> Absent such a mechanism, I'll probably just keep my own private
> libs the way I like them, and plan on building my own symbols for
> every new project.
> 
> There is a certain level of nuance that is required before a
> community horde mechanism is viable or even worth attempting.
> This probably involves some degree of self filtering, searching,
> and intelligent aggregation of multiple efforts into larger
> collections.
> 
> kind regards,
> --
> Rick Walker
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Install KiCad on non Ubuntu distros - best way?

[Dick Hollenbeck]

On 08/09/2013 09:08 AM, Kaspar Emanuel wrote:
> My issue was rather that root was used during the compilation process. I 
> would suggest
> building somewhere in the user's home directory rather than /opt which is 
> meant for
> installed software that doesn't use conventional paths. I now have access and 
> will edit
> the page when I find some time.
> 
> 
> On 9 August 2013 00:31, Cirilo Bernardo  <mailto:cirilo_berna...@yahoo.com>> wrote:
> 
> - Original Message -
> 
> > From: Dick Hollenbeck mailto:d...@softplc.com>>
> > To: kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> > Cc:
> > Sent: Friday, August 9, 2013 3:56 AM
> > Subject: Re: [Kicad-developers] Install KiCad on non Ubuntu distros - 
> best way?
> >
> > On 08/08/2013 10:35 AM, Fabrizio Tappero wrote:
> >>  I Kaspar,
> >>  yes please contribute to it. I did write these instructions while
> >>  installing Kicad. for access to the web ask Miguel. He is the boss if
> >>  it.
> >>  Alternatively I can make the modifications you want. Send them to
> >>  fabrizio.tappero (at) gmail dot com
> >>  cheers
> >>  Fab.
> >>
> >>
> >>  On Fri, Jul 5, 2013 at 9:25 PM, Kaspar Bumke  <mailto:kaspar.bu...@gmail.com>>
> > wrote:
> >>>  Thanks for these instructions. I am switching to Debian myself and 
> they
> >>>  helped me quickly get KiCAD installed again to look at board I need 
> to
> >>>  solder!
> >>>
> >>>  However, there are quite a few bad practices in there mainly in using
> > sudo
> >>>  when you don't need to (also, unlike in Ubuntu sudo isn't
> > necessarily
> >>>  installed on Debian) and using /opt/ to build which should be for
> > installed
> >>>  software. Is there a way I can edit this page?
> >
> >
> > I think currently you are limited under linux as to where you can 
> install KiCad,
> > and still
> > have it function correctly.  This is one of the things on my to do 
> list, to look
> > at in
> > detail.  I have to finish up a board first.
> >
> > But with the current constraints, I actually do think you have to use 
> sudo.  So
> > be careful
> > that whatever you'd like to write about is currently actually true.
> >
> > I do agree that it should be possible to install on linux without sudo, 
> but I
> > don't
> > understand how that is currently true.
> >
> >
> > Dick
> >
> 
> 
> In UNIX I expect it will always be the case that certain root privileges 
> are required
> to install system-wide software; offhand I don't know if it's possible to 
> create a
> system user who can install new software without essentially having full 
> root
> privileges.  Users can always install a local copy in their home 
> directory for
> themselves and if they set appropriate permissions and other users set 
> appropriate
> PATH and LD_LIBRARY_PATH variables, then other users can use that local 
> copy.
>  Installing locally is as easy as:
> make install DESTDIR=${HOME}
> Unless a user has explicitly set installation path variables, things will 
> go into
> ${HOME}/usr/local



Yeah, but I don't think kicad "works" when installed just anywhere on linux.




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad presented at Fosdem

[Dick Hollenbeck]

Be sure and mention that they can have a say in the topics of the
presentation and discussion.

Thanks again.

On Aug 9, 2013 7:51 AM, "Fabrizio Tappero" 
wrote:
>
> Hi Dick,
> sure no worries, it would even be a good change for us to meet !!
>
> I'll go a head and ask.
>
> cheers
> Fabrizio
>
> On Thu, Aug 8, 2013 at 7:33 PM, Dick Hollenbeck  wrote:
> > On 08/08/2013 10:39 AM, Fabrizio Tappero wrote:
> >> Hi guys,
> >> Feb next year there will be these annual conf in Belgium:
> >>
> >> https://fosdem.org/2014/news/2013-08-06-call-for-participation/
> >>
> >>
> >> It would be great to have KiCad presented there. If there is somebody
> >> interested in presenting I can ask for a presentation slot and for the
> >> money to cover for accommodation and  transportation.
> >>
> >> Please let me know
> >>
> >> cheers
> >> Fabrizio
> >
> >
> > Yeah, I'd be interested *if* those expenses could be covered all the
way from Texas.
> >
> > Fabrizio, I appreciate you doing the request and making it easy for me.
> >
> >
> > Dick
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Online library sharing idea

[Dick Hollenbeck]

On 08/08/2013 05:43 PM, Chris Morgan wrote:
> On Thu, Aug 8, 2013 at 6:09 PM, Dick Hollenbeck  <mailto:d...@softplc.com>> wrote:
> 
> On 08/08/2013 04:44 PM, Chris Morgan wrote:
> > On Thu, Aug 8, 2013 at 12:12 AM, Dick Hollenbeck  <mailto:d...@softplc.com>
> > <mailto:d...@softplc.com <mailto:d...@softplc.com>>> wrote:
> >
> > On 08/07/2013 05:25 AM, Chris Morgan wrote:
> > > On Tue, Aug 6, 2013 at 9:50 PM, Dick Hollenbeck  <mailto:d...@softplc.com>
> > <mailto:d...@softplc.com <mailto:d...@softplc.com>>> wrote:
> > >> On 08/06/2013 06:40 PM, Chris Morgan wrote:
> > >>> Hello.
> > >>>
> > >>> Sites like http://www.kicadlib.org/ are great for sharing 
> libraries
> > >>> but I was thinking that having integrated online library 
> sharing could
> > >>> better distribute the work while making it easier to share and 
> use
> > >>> parts. A user could add add trusted sources to their remote 
> libraries,
> > >>> contribute new parts, vote on parts etc.
> > >>>
> > >>> Thoughts? It would probably take a bit of effort to spec out and
> > >>> implement things, I was thinking of an indiegogo or kickstarter
> > >>> approach to fund the work.
> > >>>
> > >>> Chris
> > >>
> > >>
> > >> This has been discussed numerous times, both for eeschema and 
> for pcbnew.
> > >>
> > >> In fact I mentioned it for pcbnew about 4 days ago again.
> > >>
> > >> The eeschema conversation is longer, and archives have it 
> already.
> > >>
> > >
> > > I've done a couple of searches like "kicad online library" and 
> "kicad
> > > network library" that didn't turn up anything. Were different 
> terms
> > > used in the discussion?
> >
> >
> > SWEET
> >
> > This design is one I wrote as a result of endless emails and 
> thinking about it:
> >
> > http://dev.kicad-pcb.org/sweet/
> >
> > In the source tree you find the doxygen source to this design 
> document named
> new/design.h
> >
> > SWEET is different than PRETTY in that SWEET is designed to be 
> human writable, human
> > readable.  Whereas PRETTY was intended only to be human readable.
> >
> > In the end, I decided that eeschema needed to be rewritten, not 
> adapted.  This
> is where
> > you start in a new directory and start over, but are free to copy 
> pieces from
> the original
> > work with scrutiny and refinement as you go.
> >
> > It ended up being too much work for me to fund.  Get about $100,000 
> and I might be
> > interested in doing the work.  Some of it is done already however, 
> the parser and I
> > started writing a GAL client before GAL was a good as it is now.
> >
> >
> > Dick
> >
> >
> >
> > Hi Dick.
> >
> > I went through the documents and it looks like an interesting approach 
> to versioning
> > parts. Clearly you've spent a lot of time building that up. I'm 
> wondering if we should
> > consider using a simpler, full part, versioning for the first round of 
> any client/server
> > api. It might not be as efficient but it would likely simplify the 
> implementation
> and make
> > it easier to move parts around.
> >
> > Chris
> 
> 
> KiCad treats footprints and schematic parts differently.  (Yet does not 
> prevent you from
> adding references from one to another.)  So if you want "to simplify", 
> you should have one
> conversation about each realms, footprints and schematic parts.  Two 
> separate
> conversations.  One in my mind is a $100,000 undertaking, the other is a 
> mere 3 weeks
> of work.
> 
> Simple is the latter.  You started by saying the remote library should 
> work just like a
> local library for access.  Let's say that is true for read only access.  
> For admin, you
> develop your webbrowser submission and patch approval process with human 
> 

Re: [Kicad-developers] Online library sharing idea

[Dick Hollenbeck]

On 08/08/2013 04:44 PM, Chris Morgan wrote:
> On Thu, Aug 8, 2013 at 12:12 AM, Dick Hollenbeck  <mailto:d...@softplc.com>> wrote:
> 
> On 08/07/2013 05:25 AM, Chris Morgan wrote:
> > On Tue, Aug 6, 2013 at 9:50 PM, Dick Hollenbeck  <mailto:d...@softplc.com>> wrote:
> >> On 08/06/2013 06:40 PM, Chris Morgan wrote:
> >>> Hello.
> >>>
> >>> Sites like http://www.kicadlib.org/ are great for sharing libraries
> >>> but I was thinking that having integrated online library sharing could
> >>> better distribute the work while making it easier to share and use
> >>> parts. A user could add add trusted sources to their remote libraries,
> >>> contribute new parts, vote on parts etc.
> >>>
> >>> Thoughts? It would probably take a bit of effort to spec out and
> >>> implement things, I was thinking of an indiegogo or kickstarter
> >>> approach to fund the work.
> >>>
> >>> Chris
> >>
> >>
> >> This has been discussed numerous times, both for eeschema and for 
> pcbnew.
> >>
> >> In fact I mentioned it for pcbnew about 4 days ago again.
> >>
> >> The eeschema conversation is longer, and archives have it already.
> >>
> >
> > I've done a couple of searches like "kicad online library" and "kicad
> > network library" that didn't turn up anything. Were different terms
> > used in the discussion?
> 
> 
> SWEET
> 
> This design is one I wrote as a result of endless emails and thinking 
> about it:
> 
> http://dev.kicad-pcb.org/sweet/
> 
> In the source tree you find the doxygen source to this design document 
> named new/design.h
> 
> SWEET is different than PRETTY in that SWEET is designed to be human 
> writable, human
> readable.  Whereas PRETTY was intended only to be human readable.
> 
> In the end, I decided that eeschema needed to be rewritten, not adapted.  
> This is where
> you start in a new directory and start over, but are free to copy pieces 
> from the original
> work with scrutiny and refinement as you go.
> 
> It ended up being too much work for me to fund.  Get about $100,000 and I 
> might be
> interested in doing the work.  Some of it is done already however, the 
> parser and I
> started writing a GAL client before GAL was a good as it is now.
> 
> 
> Dick
> 
> 
> 
> Hi Dick.
> 
> I went through the documents and it looks like an interesting approach to 
> versioning
> parts. Clearly you've spent a lot of time building that up. I'm wondering if 
> we should
> consider using a simpler, full part, versioning for the first round of any 
> client/server
> api. It might not be as efficient but it would likely simplify the 
> implementation and make
> it easier to move parts around.
> 
> Chris


KiCad treats footprints and schematic parts differently.  (Yet does not prevent 
you from
adding references from one to another.)  So if you want "to simplify", you 
should have one
conversation about each realms, footprints and schematic parts.  Two separate
conversations.  One in my mind is a $100,000 undertaking, the other is a mere 3 
weeks of work.

Simple is the latter.  You started by saying the remote library should work 
just like a
local library for access.  Let's say that is true for read only access.  For 
admin, you
develop your webbrowser submission and patch approval process with human 
intervention.
The 3 week effort includes only the read only access, as I measure it.

I don't think eeschema is a foundation that should be built upon.  So I don't 
wish to say
anything more about schematic part remoting, other than I will rewrite eeschema 
and do
sweet for $100,000.  Short of that is of no interest, you'd be building on sand.

So the conversation I can help with is the pcbnew one, and writing a "read 
only" http
footprint PLUGIN is quite easy IMO.  As I look at it now, there are really 3 
separate
conversations.  One I don't want to have again, until there is money, a second 
one on read
only access of footprints, and a third one I don't care about which is the "web 
admin" of
the read only footprint access.  You could do the latter using github pull 
requests.  Keep
it easy.  There is no versioning in the footprint PLUGIN api.

Hopefully you can best utilize my time based on what I've said here.

Dick









___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Install KiCad on non Ubuntu distros - best way?

[Dick Hollenbeck]

On 08/08/2013 10:35 AM, Fabrizio Tappero wrote:
> I Kaspar,
> yes please contribute to it. I did write these instructions while
> installing Kicad. for access to the web ask Miguel. He is the boss if
> it.
> Alternatively I can make the modifications you want. Send them to
> fabrizio.tappero (at) gmail dot com
> cheers
> Fab.
> 
> 
> On Fri, Jul 5, 2013 at 9:25 PM, Kaspar Bumke  wrote:
>> Thanks for these instructions. I am switching to Debian myself and they
>> helped me quickly get KiCAD installed again to look at board I need to
>> solder!
>>
>> However, there are quite a few bad practices in there mainly in using sudo
>> when you don't need to (also, unlike in Ubuntu sudo isn't necessarily
>> installed on Debian) and using /opt/ to build which should be for installed
>> software. Is there a way I can edit this page?


I think currently you are limited under linux as to where you can install 
KiCad, and still
have it function correctly.  This is one of the things on my to do list, to 
look at in
detail.  I have to finish up a board first.

But with the current constraints, I actually do think you have to use sudo.  So 
be careful
that whatever you'd like to write about is currently actually true.

I do agree that it should be possible to install on linux without sudo, but I 
don't
understand how that is currently true.


Dick


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad presented at Fosdem

[Dick Hollenbeck]

On 08/08/2013 10:39 AM, Fabrizio Tappero wrote:
> Hi guys,
> Feb next year there will be these annual conf in Belgium:
> 
> https://fosdem.org/2014/news/2013-08-06-call-for-participation/
> 
> 
> It would be great to have KiCad presented there. If there is somebody
> interested in presenting I can ask for a presentation slot and for the
> money to cover for accommodation and  transportation.
> 
> Please let me know
> 
> cheers
> Fabrizio


Yeah, I'd be interested *if* those expenses could be covered all the way from 
Texas.

Fabrizio, I appreciate you doing the request and making it easy for me.


Dick



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] datasheets as URIs

[Dick Hollenbeck]

I've found it easier to correspond with board stuffers if I use http:// links to
datasheets rather than putting them on my disk.  Plus this way the schematic 
parts which
link to them in the DATASHEET property/field are suddenly more general and 
cross project
capable.

I typically include the datasheet column in the BOM, so the board stuffer gets 
the sheet
links.

So I added a button to show the datasheet row in the 2 property editors this 
morning.
Commit record:


EHNANCE: add a "Show" button to the two text field properties
dialogs which allow editing of component properties. The button
is active when the table row cursor is on the DATASHEET field only.
When active, and your datasheet is a URI, then your default
browser will be launced to show that datasheet if it can find it.
This incentivizes use of http:// links for datasheets.


Too bad my brain's built in spell checker is declining.


FYI,

Dick

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Online library sharing idea

[Dick Hollenbeck]

On 08/07/2013 05:25 AM, Chris Morgan wrote:
> On Tue, Aug 6, 2013 at 9:50 PM, Dick Hollenbeck  wrote:
>> On 08/06/2013 06:40 PM, Chris Morgan wrote:
>>> Hello.
>>>
>>> Sites like http://www.kicadlib.org/ are great for sharing libraries
>>> but I was thinking that having integrated online library sharing could
>>> better distribute the work while making it easier to share and use
>>> parts. A user could add add trusted sources to their remote libraries,
>>> contribute new parts, vote on parts etc.
>>>
>>> Thoughts? It would probably take a bit of effort to spec out and
>>> implement things, I was thinking of an indiegogo or kickstarter
>>> approach to fund the work.
>>>
>>> Chris
>>
>>
>> This has been discussed numerous times, both for eeschema and for pcbnew.
>>
>> In fact I mentioned it for pcbnew about 4 days ago again.
>>
>> The eeschema conversation is longer, and archives have it already.
>>
> 
> I've done a couple of searches like "kicad online library" and "kicad
> network library" that didn't turn up anything. Were different terms
> used in the discussion?


SWEET

This design is one I wrote as a result of endless emails and thinking about it:

http://dev.kicad-pcb.org/sweet/

In the source tree you find the doxygen source to this design document named 
new/design.h

SWEET is different than PRETTY in that SWEET is designed to be human writable, 
human
readable.  Whereas PRETTY was intended only to be human readable.

In the end, I decided that eeschema needed to be rewritten, not adapted.  This 
is where
you start in a new directory and start over, but are free to copy pieces from 
the original
work with scrutiny and refinement as you go.

It ended up being too much work for me to fund.  Get about $100,000 and I might 
be
interested in doing the work.  Some of it is done already however, the parser 
and I
started writing a GAL client before GAL was a good as it is now.


Dick



> 
> 
>> I don't see why a PCBNEW plugin could not use http protocol to implement the 
>> PLUGIN
>> interface.  The PLUGIN interface seems adequate, although we'll see soon how 
>> well it fits
>> the needs of pcbnew after the fp lib table work is done.  There is no search 
>> mechanism in
>> the API, but pcbnew can search footprints after retrieving them using the 
>> API.  That may
>> be adequate, performance wise.  The PLUGIN API, which is an interface, does 
>> not prevent
>> caching being used in the implementation.
>>
> 
> Would eeschema require changes to implement a plugin interface as
> well? I'll have to look at the pcbnew plugin api to see.
> 
> 
>> Then there is a server.  For read only access, I think a stock http server 
>> could probably
>> work.  Especially if the footprints were stored in the pretty format so they 
>> were all in
>> separate files.
>>
> 
> I would think that support for things like pushing new versions of
> symbols and footprints, tracking old versions, meta-data such as who
> created the models, support for 3D models, voting, comments etc would
> be some of the bigger wins with a networked approach. The idea would
> be to build a system that can be in some way self-maintained by the
> users without requiring someone to manually track all of those
> details.
> 
> 
>> wxWidgets has an http client, and although its reputation is not shiny, it 
>> might be
>> adequate for something so simple as retrieving short files, and grabbing 
>> directory listings.
>>
>> I said before I could write it 3 weeks.
>>
>> Dick
>>
> 
> It might be relatively quick to implement. I'm starting to put
> together a description of the concept, components and features so we
> have something to discuss around. I'll pull in the information from
> the previous discussions if I can find them.
> 
> Chris
> .
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] page settings dialog "(N..." button

[Dick Hollenbeck]

On 08/07/2013 02:27 PM, Carl Poirier wrote:
> Ok I found out that it's "N..." for "None". This is because the 
> wxFilePickerCtrl is
> constructed with the initial file as wxEmptyString. If a file is specified, 
> then the name
> of that file will appear instead on the button - but not in the wxTextCtrl 
> besides it.
> 
> I then upgraded wxWidgets from 2.8 (Ubuntu repository) to 2.9.5, recompiled, 
> and got the
> "Browse" button, as shown in the first screenshot.
> 
> Now there's another option too. We can use the wxFLP_SMALL flag, which will 
> replace the
> "Browse" by "...". The wxTextCtrl then gets larger, as shown in the second 
> screenshot.
> 
> Personally, I would not do anything about it since the newer wxWidgets fixes 
> it, and that
> "Browse" speaks more than three dots. What are your thoughts?


Nobody can know when the distros will start using wx 2.9.x.  The only certainty 
is
disappointment on that note.  So wx 2.8 has to work.

I am happy with the ... button, since it is a common paradigm, if it will work 
on 2.8.x


Thanks for the excellent research.

Dick



> 
> Carl
> 
> On Wed, Aug 7, 2013 at 4:11 AM, Lorenzo Marcantonio 
>  > wrote:
> 
> On Wed, Aug 07, 2013 at 08:14:42AM +0200, jp charras wrote:
> > I also see the 'Browse' text ( Ubuntu 10.04, KDE, wxWidgets 2.9.5)
> > And the widget used in dialog is a wxFilePickerCtrl, which manages
> > both the wxTextCtrl and the button.
> 
> I vote for YAWBO (yet another wx build option) or whatever:P it seems
> that wx is the new java (write once, test everywhere), I'm liking it
> more and more less (requiring C++ was a big minus anyway for me)
> 
> Who cares, most probably it can simply be fixed in the form editor...
> 
> For the records wx 2.9.4, gtk 2.24.10/3.2.2 (I don't know which uses)
> and no desktop environment, here.
> 
> --
> Lorenzo Marcantonio
> Logos Srl
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Online library sharing idea

[Dick Hollenbeck]

On 08/06/2013 06:40 PM, Chris Morgan wrote:
> Hello.
> 
> Sites like http://www.kicadlib.org/ are great for sharing libraries
> but I was thinking that having integrated online library sharing could
> better distribute the work while making it easier to share and use
> parts. A user could add add trusted sources to their remote libraries,
> contribute new parts, vote on parts etc.
> 
> Thoughts? It would probably take a bit of effort to spec out and
> implement things, I was thinking of an indiegogo or kickstarter
> approach to fund the work.
> 
> Chris


This has been discussed numerous times, both for eeschema and for pcbnew.

In fact I mentioned it for pcbnew about 4 days ago again.

The eeschema conversation is longer, and archives have it already.

I don't see why a PCBNEW plugin could not use http protocol to implement the 
PLUGIN
interface.  The PLUGIN interface seems adequate, although we'll see soon how 
well it fits
the needs of pcbnew after the fp lib table work is done.  There is no search 
mechanism in
the API, but pcbnew can search footprints after retrieving them using the API.  
That may
be adequate, performance wise.  The PLUGIN API, which is an interface, does not 
prevent
caching being used in the implementation.

Then there is a server.  For read only access, I think a stock http server 
could probably
work.  Especially if the footprints were stored in the pretty format so they 
were all in
separate files.

wxWidgets has an http client, and although its reputation is not shiny, it 
might be
adequate for something so simple as retrieving short files, and grabbing 
directory listings.

I said before I could write it 3 weeks.

Dick








> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> .
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] USE_PCBNEW_NANOMETRES

[Dick Hollenbeck]

On 08/06/2013 12:34 PM, Carl Poirier wrote:
> Hi guys,
> 
> Attached is the patch for cleaning up the "USE_PCBNEW_NANOMETRES", which 
> removes all
> traces of it. It's built from revision 4272.
> 
> I've gone through some testing to make sure everything is all right, 
> including opening an
> older project which had, at the time, the deci-mils as internal units 
> (confirmed, to my
> belief, by the line "InternalUnit 0.000100 INCH" in the .brd file). I haven't 
> seen any
> anomalies.
> 
> BTW, CMake outputs a warning about "KICAD_TESTING_VERSION" not being used by 
> the project,
> which is still mentioned in the "HOW_TO_CONTRIBUTE.txt".
> 
> Please let me know how it works out.
> 
> Carl

Carl,

Truly great job!

Committed in 4274.

Adios deci-mils.

Thanks,

Dick



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] BUG FIX: module text move

[Dick Hollenbeck]

>> Lastly, I feel a subsetting mechanism other than visibility, or layer, which 
>> we have now,
>> must be done using a python or other type of expression, not just some noisy 
>> dialog with a
>> million checkboxes.

There are two paths to travel down this "python expression" path:

a) either a tricked out "selection filter" which subsets those items which are 
visible, or

b) an elaborate visibility filter which simply draws a very specific subset of 
your board.


How to implement:  a)))


We are actually very close to this capability the infrastructure is actually 
nearly all
there.  We have the COLLECTOR class, and its Inspect() function.  We just have:

1) Create a python interpreter instance within a C++ class.  We need a C++ 
wrapper hide
the details of instantiating a python interpreter instance.  This needs to be 
lean enough
so that expressions can be passed to it and it gives back results in some form. 
 Maybe
that return form is some variable type like double or bool.  Call this the 
"INTERPRETER"
class for the sake of discussion.


2) Extend our current class COLLECTOR, and give such extended class a member 
INTERPRETER.
In the COLLECTOR's Inspect() function, call the INTERPRETER with the 
expression.  The
constructor to this class should take the python expression, and a BOARD 
pointer perhaps.

So now you simply have to use a different kind of COLLECTOR than what we use 
now in hit
testing.  Lets say you have resistors with values in a range:  R29 - R48.  You 
could write
a python expression to allow selection of ONLY those resistors and only 
modules.  Lets say
you have a number of opto isolators.  You could write an expression that allows 
selection
of only opto isolators by having the python expression examine a piece of 
module text, say
the "value" and perform a regular expression check on it or other evaluation.


How to implement: b

The new GAL code uses a VIEW stack, so the python expression can be used as a 
means of
filtering object on their way into one or more of the VIEWs.  After they are in 
there,
this is no performance cost in the python expression evaluation, because the 
BOARD has
been subsetted already, once up front.






___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] BUG FIX: module text move

[Dick Hollenbeck]

On 08/06/2013 07:33 AM, Dick Hollenbeck wrote:
> 
> On Aug 6, 2013 4:05 AM, "Lorenzo Marcantonio"  <mailto:l.marcanto...@logossrl.com>> wrote:
>>
>> On Tue, Aug 06, 2013 at 10:27:08AM +0200, jp charras wrote:
>> > However, a more restrictive filtering could be done, and something
>> > like a "text positioning tool" could be just make by using a
>> > restrictive filtering ( for instance do not include tracks in
>> > search) when a silkscreen layer is the active layer.
>>
>> What about a filter by type like in other (mechanical) cads? a toolbar of
>> toggle button to enable/disable of modules/text/pins/track and so on.
> 
> First, I prefer the way it works now over the way it worked before my 
> restoration.  Second
> I am glad to have conversation about it rather than simply having my code, 
> code I wrote,
> get changed without consultation.
> 
> For deciphering which module is in play while the text is turned off, I 
> currently use two
> facillities, the status bar, and more importantly cross probing on a two 
> monitor setup. 
> The module can be selected from the schematic just fine while module text is 
> not
> visible.   Text should be the last thing moved and until the module is 
> situated is not
> neccessary to be visible.
> 
> Lastly, I feel a subsetting mechanism other than visibility, or layer, which 
> we have now,
> must be done using a python or other type of expression, not just some noisy 
> dialog with a
> million checkboxes.
> 
> As I said, I do not need a module selection tool.  I can turn off text and I 
> have that
> now.  I spent the last several days positionin smt components, the use cases 
> are fresh in my
> mind.  Pcbnew worked damn well after my fix.

The obvious should also be noted, and that is that if you first take the time 
to move the
text out from under your small SMT component (say a small R or C), then you 
don't have
this selection clarification menu popup, nor do you have the need to have a 
module
selection tool.  Simply click on the part body and not the module text, *even 
while the
text is visible*.  That is your module selection tool, it looks like you when 
looking in
the mirror.  In my footprint libraries, I don't put the text under my 
footprints to save
this initial step.






___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] BUG FIX: module text move

[Dick Hollenbeck]

On Aug 6, 2013 4:05 AM, "Lorenzo Marcantonio" 
wrote:
>
> On Tue, Aug 06, 2013 at 10:27:08AM +0200, jp charras wrote:
> > However, a more restrictive filtering could be done, and something
> > like a "text positioning tool" could be just make by using a
> > restrictive filtering ( for instance do not include tracks in
> > search) when a silkscreen layer is the active layer.
>
> What about a filter by type like in other (mechanical) cads? a toolbar of
> toggle button to enable/disable of modules/text/pins/track and so on.

First, I prefer the way it works now over the way it worked before my
restoration.  Second I am glad to have conversation about it rather than
simply having my code, code I wrote, get changed without consultation.

For deciphering which module is in play while the text is turned off, I
currently use two facillities, the status bar, and more importantly cross
probing on a two monitor setup.  The module can be selected from the
schematic just fine while module text is not visible.   Text should be the
last thing moved and until the module is situated is not neccessary to be
visible.

Lastly, I feel a subsetting mechanism other than visibility, or layer,
which we have now, must be done using a python or other type of expression,
not just some noisy dialog with a million checkboxes.

As I said, I do not need a module selection tool.  I can turn off text and
I have that now.  I spent the last several days position smt components,
thevuse cases are fredh in my mind.  Pcbnew worked damn well after my fix.

>
> --
> Lorenzo Marcantonio
> Logos Srl
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] BUG FIX: module text move

[Dick Hollenbeck]

On 08/05/2013 04:01 PM, Dick Hollenbeck wrote:
> Jean-Pierre,
> 
> Rev 4271 probably reverses out a change you made to my original selection 
> clarification work.
> 
> I found I could not move a module text reference with M hotkey if it was 
> tucked under a
> neighboring module.
> 
> My change reverts to how it was originally written, however, it causes more 
> popup menus
> especially if you click on an ambiguous position which as both module text 
> and same
> module.   I don't think the answer to this second problem is a patch 
> reversal, because
> we'd be going in circles then.
> 
> What we probably need is a text positioning tool.  So that text is only in 
> play when when
> you have that tool in play.

No, I revoke that suggestion.   The answer is simply to turn off front or back 
text
visibility, then the module text will not be selected and the selection 
clarification menu
frequency goes down drastically.

So I now stand bolder in defense of this commit, which again, fixes the ability 
to move
module text positioned under a different module.

Dick


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] BUG FIX: module text move

[Dick Hollenbeck]

Jean-Pierre,

Rev 4271 probably reverses out a change you made to my original selection 
clarification work.

I found I could not move a module text reference with M hotkey if it was tucked 
under a
neighboring module.

My change reverts to how it was originally written, however, it causes more 
popup menus
especially if you click on an ambiguous position which as both module text and 
same
module.   I don't think the answer to this second problem is a patch reversal, 
because
we'd be going in circles then.

What we probably need is a text positioning tool.  So that text is only in play 
when when
you have that tool in play.

See my comments in the commit.


Dick

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] big commit

[Dick Hollenbeck]

On 08/05/2013 11:45 AM, Lorenzo Marcantonio wrote:
> On Mon, Aug 05, 2013 at 11:29:40AM -0500, Dick Hollenbeck wrote:
>> Gosh, well maybe not.  After recompiling I could not duplicate it.
> 
> Some kind of heisenbug, maybe? Even the autoscrolling issue I had with
> eeschema is not reproducible on every machine (I suspect some timing
> relationship and/or events arriving in differen order).


Or it can sometimes be failure on CMake's part to track all the dependencies 
and fails to
compile everything it needs to after and edit.  There are some corner cases 
involving
header files in there that lurk for the new code warrior.

$ make clean

is what I run to in such a case.


Dick


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] big commit

[Dick Hollenbeck]

On 08/05/2013 10:14 AM, Dick Hollenbeck wrote:
> On 08/03/2013 01:01 AM, Dick Hollenbeck wrote:
>> Jean-Pierre
>>
>> I committed a big edit recently.  Did not have time to test it extensively.
>>
>> Mildly concerned about eeschema: find operation, and its use of the 
>> GetScreen() stuff,
>> which partially went away.
> 
> 
> Seems I did break eeschema single page find.  Sorry.  Working on a fix now...
> 
> Dick


Gosh, well maybe not.  After recompiling I could not duplicate it.

Sorry for the noise.
(If the noised generated any additional testing, that would not be a bad thing 
however.)

TIA if it did or does.

I am moving on however until I hear otherwise.

Dick


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] big commit

[Dick Hollenbeck]

On 08/03/2013 01:01 AM, Dick Hollenbeck wrote:
> Jean-Pierre
> 
> I committed a big edit recently.  Did not have time to test it extensively.
> 
> Mildly concerned about eeschema: find operation, and its use of the 
> GetScreen() stuff,
> which partially went away.


Seems I did break eeschema single page find.  Sorry.  Working on a fix now...

Dick



> 
> And they way I added the hotkey to pcbnew, modedit.  Do not know if the hot 
> key makes
> sense in gerbview.  Please check that:
> 
> 'S' for set grid origin.
> 
> This is especially helpful when you use the track tool to center the mouse 
> cursor on a
> pad.  Then while there, pressing 'S' or 's' will set the grid origin to that 
> point.  This
> is more functional than the toolbar icon which changes the tool and cannot 
> center on a pad.
> 
> If I broke something I am sorry.  Some things may need fixing before you all 
> win, but
> maybe its fine.
> 
> Dick
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Python Scripting on Windows with KiCad-Winbuilder

[Dick Hollenbeck]

I would think you can put such a file into our CMakeModules dir and it will be 
used
instead of an identically named one installed with CMake.  Yours sound like 
linux related
edits, so those would have to be merged with any similar constructs that are 
done for windows.

We have done this for other CMake modules, overriding the standard CMake ones 
from time to
time.  Or you can simply use another name, unique, and rely on it instead of 
the strategy
used in the CMake package module.

With such a strategy you do not have to sign on to become a life long CMake
committer/maintainer.  :)


Really part of the problem is the mess that python has become wrt to locations 
of
libraries.  IMO it was a mess on nearly the first day, and made worse by the 
laggard
transition to newer versions of python.  It is my understanding that blender 
installs
their own python environment as part of that package, and I don't blame them.

With a little work, the cmake scripts in python a-mingw-us could be used to 
provide a
sensible linux builder for linux python, and as such offer a distro independent 
(neutral)
strategy for installing python libraries into places fully controlled by that 
set of CMake
scripts.  But for now, and until someone else drove said effort, it only 
attempts to
service the needs of windows python a-mingw-us.


Dick



On 08/04/2013 07:04 PM, Adam Wolf wrote:
> Sorry, I was unclear.  The CMake folks haven't had an active maintainer of 
> the Python
> modules for quite some time, and they're not going to make any changes to the 
> Python
> modules until someone steps up to maintain the CMake Python modules on every 
> platform--at
> least that's what they said in May.
> 
> Adam Wolf
> Wayne and Layne, LLC
> 
> 
> On Sun, Aug 4, 2013 at 6:56 PM, Dick Hollenbeck  <mailto:d...@softplc.com>> wrote:
> 
> 
> On Aug 4, 2013 6:51 PM, "Adam Wolf"  <mailto:adamw...@feelslikeburning.com>> wrote:
> >
> > This is a minor aside.  What's all involved in including a custom cmake 
> module in a
> project?  I fixed FindPythonLibs and another Python module for cmake a 
> few months ago,
> because right now those two stock modules don't work on Fedora or 
> Ubuntu--which means
> building Kicad on those platforms is trickier than you'd expect.
> >
> > They said my patches look fine, and they'd be glad to accept them--as 
> soon as they
> get a python maintainer for all of Cmake.
> 
> "They" are python project devs, or distro folks?  Such a maintainer would 
> maintain
> what exactly, what project and what package?  Sorry if I am not reading 
> well.
> 
> 
> >
> > Adam Wolf
> > Wayne and Layne, LLC
> >
> >
> > On Sun, Aug 4, 2013 at 6:21 PM, Brian Sidebotham 
>  <mailto:brian.sidebot...@gmail.com>> wrote:
> >>
>     >> On 4 August 2013 23:45, Brian Sidebotham  <mailto:brian.sidebot...@gmail.com>> wrote:
> >>>
> >>> On 4 August 2013 22:42, Brian Sidebotham  <mailto:brian.sidebot...@gmail.com>> wrote:
> >>>>
> >>>> On 4 August 2013 22:19, Dick Hollenbeck  <mailto:d...@softplc.com>> wrote:
> >>>>>
> >>>>>
> >>>>> Any platform detection tests can cause grief, since we do not claim 
> to be
> Windows in the
> >>>>> python runtime.  We claim to be "gcc compiled" with some other 
> attribute that
> talks about
> >>>>> OS (cannot remember).  If you were to do a diff across the entire 
> bracket of
> a-ming-us
> >>>>> revisions,
> >>>>>
> >>>>> bzr diff -r 1..latest  
> >>>>>
> >>>>> limited to the regression test directories,
> >>>>> you will find one of the patches I applied to test for our platform
> specifically.  It will
> >>>>> be the one with "gcc" in it.  We cannot report "Windows" as our 
> platform because
> mingw and
> >>>>> MSVC actually do a couple weird regression tests differently.
> >>>>>
> >>>>> If PyCrust is assuming a limited set of platforms, it may be coming 
> up short and
> running
> >>>>> into an unsupported platform code path.
> >>>>>
> >>>>>
> >>>>> Dick
> >>>>
> >>>>
> >>>> Thanks for the great information Dick

Re: [Kicad-developers] Python Scripting on Windows with KiCad-Winbuilder

[Dick Hollenbeck]

On Aug 4, 2013 6:51 PM, "Adam Wolf"  wrote:
>
> This is a minor aside.  What's all involved in including a custom cmake
module in a project?  I fixed FindPythonLibs and another Python module for
cmake a few months ago, because right now those two stock modules don't
work on Fedora or Ubuntu--which means building Kicad on those platforms is
trickier than you'd expect.
>
> They said my patches look fine, and they'd be glad to accept them--as
soon as they get a python maintainer for all of Cmake.

"They" are python project devs, or distro folks?  Such a maintainer would
maintain what exactly, what project and what package?  Sorry if I am not
reading well.


>
> Adam Wolf
> Wayne and Layne, LLC
>
>
> On Sun, Aug 4, 2013 at 6:21 PM, Brian Sidebotham <
brian.sidebot...@gmail.com> wrote:
>>
>> On 4 August 2013 23:45, Brian Sidebotham 
wrote:
>>>
>>> On 4 August 2013 22:42, Brian Sidebotham 
wrote:
>>>>
>>>> On 4 August 2013 22:19, Dick Hollenbeck  wrote:
>>>>>
>>>>>
>>>>> Any platform detection tests can cause grief, since we do not claim
to be Windows in the
>>>>> python runtime.  We claim to be "gcc compiled" with some other
attribute that talks about
>>>>> OS (cannot remember).  If you were to do a diff across the entire
bracket of a-ming-us
>>>>> revisions,
>>>>>
>>>>> bzr diff -r 1..latest  
>>>>>
>>>>> limited to the regression test directories,
>>>>> you will find one of the patches I applied to test for our platform
specifically.  It will
>>>>> be the one with "gcc" in it.  We cannot report "Windows" as our
platform because mingw and
>>>>> MSVC actually do a couple weird regression tests differently.
>>>>>
>>>>> If PyCrust is assuming a limited set of platforms, it may be coming
up short and running
>>>>> into an unsupported platform code path.
>>>>>
>>>>>
>>>>> Dick
>>>>
>>>>
>>>> Thanks for the great information Dick. I've just done a quick test
directly through Python-a-mingw-us:
>>>>
>>>> Python 2.7.4 (default, Mar 18 2013, 12:04:44) [gcc] on win32
>>>> Type "help", "copyright", "credits" or "license" for more information.
>>>> >>> import wx
>>>> >>> app = wx.App(redirect=True)
>>>> >>> top = wx.Frame(None, title="PyCrust Helper",size=(800,300))
>>>> >>> import wx.py.crust
>>>> >>> cframe = wx.py.crust.CrustFrame(parent = top)
>>>> >>> top.Show()
>>>> >>> cframe.Show()
>>>> >>> app.MainLoop()
>>>>
>>>> PyCrust crashes as soon as you focus on it. So this can at least be
debugged without KiCad sitting ontop.
>>>>
>>>> PyCrust has worked previously with PyCrust because I've used it. So
this problem shouldn't be too bad to solve.
>>>>
>>>> Thanks again.
>>>>
>>>> Best Regards, Brian.
>>>>
>>>
>>> The STC sample in the wxPython build (From the wxWidgets library, i.e.
the cpp sample) behaves exactly the same, hanging on focus. I need to fix
the wxWidgets-cmake project.
>>>
>>> I'm on the case and a fix should arrive in our inbox shortly! Probably
just got some compiler definitions wrong or something.
>>>
>>> Best Regards, Brian.
>>>
>>
>> Fixed! I'll release updated versions tomorrow (It takes a while to build
all the different versions and upload them to Launchpad!)
>>
>> That means that KiCad build is fully successful as far as I've tested so
far.
>>
>> We just need to sort out the readline module in Python-a-mingw-us.I'd
like to add the FindPythonLibs.cmake modules and what-not to that project
too, and do a debug version along with a source tarball. Then people can
debug their python modules through the python interpreter itself too. That
really helps when you're writing a module in C. I'll include an example
module in the install too.
>>
>> Best Regards, Brian.
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Python Scripting on Windows with KiCad-Winbuilder

[Dick Hollenbeck]

On 08/04/2013 03:46 PM, Brian Sidebotham wrote:
> On 4 August 2013 21:21, Dick Hollenbeck  <mailto:d...@softplc.com>> wrote:
> 
> On 08/04/2013 02:59 PM, Brian Sidebotham wrote:
> > Hi Guys,
> >
> >
> > (2) I get attribute errors when running either of the footprint 
> wizards, but the
> main
> > body of code appears to be working, it just looks like some API 
> breakage or
> something.
> >
> >
> > I just build 4267 and the footprint wizard problems have gone away. 
> Looks like
> everything
> > is good there. Just a problem with the PyCrust console. I assume that 
> this is not a
> global
> > problem and is something specific to the Windows python scripting 
> build? It's the last
> > thing to fix now.
> 
> Either 1) the swig generated *.cc file must be manually deleted, or 2) 
> you have do a "make
> clean" before building "scripting enabled" pcbnew.  Ensure that, then 
> report back if still
> problems, else not.
> 
> 
> I removed them manually before it would build correctly as there were a few 
> changes which
> had fixed the footprint wizards. The PyCrust console still hangs when focused 
> on a new build.
> 
> 
> >
> > I'm going to apply the CMake changes to KiCad now to support 
> Python-a-mingw-us. It
> should
> > be safe.
> 
> or awesome.
> 
> 
> Committed in 4268.
> 
>> That readline module was never tested by me, and I am not sure what causes 
>> it to even
>> load.  Let me know if and when you understand that.  :)   We had been 
>> running without it
>> for a couple of months fine.
> 
> I have renamed this to stop it loading, and this means the interactive 
> sessions work.
> However, it does not stop PyCrust hanging.

Any platform detection tests can cause grief, since we do not claim to be 
Windows in the
python runtime.  We claim to be "gcc compiled" with some other attribute that 
talks about
OS (cannot remember).  If you were to do a diff across the entire bracket of 
a-ming-us
revisions,

bzr diff -r 1..latest  

limited to the regression test directories,
you will find one of the patches I applied to test for our platform 
specifically.  It will
be the one with "gcc" in it.  We cannot report "Windows" as our platform 
because mingw and
MSVC actually do a couple weird regression tests differently.

If PyCrust is assuming a limited set of platforms, it may be coming up short 
and running
into an unsupported platform code path.


Dick



 We could just temporarily disable this module
> in Python-a-mingw-us, but I've just done a debug build of Python-a-mingw-us 
> to see what's
> going on with that module.
> 
> Best Regards,
> 
> Brian.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Why pcbnew is statting so much?

[Dick Hollenbeck]

> 
> (The sooner we can stop talking about library search paths the less confused 
> I will be.
> This whole effort is an attempt to kill off that concept.)
> 
> 
> KISYSMOD is merely a path fragment, i.e. an abbreviation, not a search path.  
> It is no
> different than any other environment variable which you might use in an fp 
> lib table,
> except that Wayne makes a big effort to set KISYSMOD for you if you forget.
> 


KISYSMOD contains the platform specific portion of the path your "KiCad system" 
footprint
libraries.  It can be used to achieve cross platform neutrality within a 
potentially
platforn neutral, i.e. 'common' fp library table on *your* systems.  (No effort 
is made to
have a common table for all KiCad installations, since you will go off and 
customize the
table for your needs.

Here is perhaps your first look at one, both in s-expr data file format and in 
CSV format:


A) s-expression:

http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/view/head:/template/fp_global_table


B) CSV format, which you can use to copy from a spreadsheet into the fp library 
table
dialog or vice versa:

http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/view/head:/template/fp_global_table.csv


The logical fp library table is a conceptual concatenation of a global table 
fragment and
a "project specific" table fragment, with priority given to "project specific" 
portion.
Loading the referenced CSV file into your favorite spreadsheet will give you a 
view of the
fp library table columns.  The link points to a sensible global table fragment.

NICKNAME is a short name for the library pointed to in the URI.  TYPE is the 
PLUGIN type.
 If you want to write a plugin that uses http to grab footprints, you can put 
the http URI
in the correct column, and you can put web-library password or other options in 
the
OPTIONS column.

The OPTIONS column is or will be passed to the PLUGIN API functions through the 
PROPERTY
table that is the last argument to most all PLUGIN API functions, although I 
think this
still needs to be done.

tada.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Python Scripting on Windows with KiCad-Winbuilder

[Dick Hollenbeck]

On 08/04/2013 02:59 PM, Brian Sidebotham wrote:
> Hi Guys,
> 
> 
> (2) I get attribute errors when running either of the footprint wizards, 
> but the main
> body of code appears to be working, it just looks like some API breakage 
> or something.
> 
> 
> I just build 4267 and the footprint wizard problems have gone away. Looks 
> like everything
> is good there. Just a problem with the PyCrust console.


That readline module was never tested by me, and I am not sure what causes it 
to even
load.  Let me know if and when you understand that.  :)   We had been running 
without it
for a couple of months fine.


You can temporarily remove that module and see what you get, maybe rename it so 
it is not
visible.  This will at least narrow the search scope, and focus fixing efforts 
thereafter.


Dick




 I assume that this is not a global
> problem and is something specific to the Windows python scripting build? It's 
> the last
> thing to fix now.
> 
> I'm going to apply the CMake changes to KiCad now to support 
> Python-a-mingw-us. It should
> be safe.
> 
> Best Regards, Brian.
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Python Scripting on Windows with KiCad-Winbuilder

[Dick Hollenbeck]

On 08/04/2013 02:59 PM, Brian Sidebotham wrote:
> Hi Guys,
> 
> 
> (2) I get attribute errors when running either of the footprint wizards, 
> but the main
> body of code appears to be working, it just looks like some API breakage 
> or something.
> 
> 
> I just build 4267 and the footprint wizard problems have gone away. Looks 
> like everything
> is good there. Just a problem with the PyCrust console. I assume that this is 
> not a global
> problem and is something specific to the Windows python scripting build? It's 
> the last
> thing to fix now.

Either 1) the swig generated *.cc file must be manually deleted, or 2) you have 
do a "make
clean" before building "scripting enabled" pcbnew.  Ensure that, then report 
back if still
problems, else not.


> 
> I'm going to apply the CMake changes to KiCad now to support 
> Python-a-mingw-us. It should
> be safe.

or awesome.





> 
> Best Regards, Brian.
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Why pcbnew is statting so much?

[Dick Hollenbeck]

On 08/04/2013 02:09 PM, Wayne Stambaugh wrote:
> On 8/4/2013 2:32 PM, Lorenzo Marcantonio wrote:
>> On Sun, Aug 04, 2013 at 02:08:17PM -0400, Wayne Stambaugh wrote:
>>> I apologize for the annoyance.  I've been on vacation and busy
>>> training for a bike race next weekend so I haven't spent as much
>>> time working on KiCad as I normally do.  Hopefully it wont be too
>>> much longer.  I'm close to having the footprint library table code
>>> done for CvPcb.  Please bear with me for a few more weeks.
>>
>> It's no problem, since the workaround is trivial (i.e. put the file
>> somewhere else). Just wanted to raise the flag if it wasn't noticed yet.
>>
>> Have good vacations :D
>>
> 
> A better option would be to do an #export 
> KISYSMOD="/path/to/footprint/libraries".  This will prevent the path 
> search from occurring.  This was done for debugging new footprint 
> libraries.  If the KISYSMOD environment variable is defined when Pcbnew 
> is started, it will respect the user's preference and not 


  ...try and set environment variable KISYSMOD itself [period].


(having the term "library search paths" in that same sentence could cause 
confusion, since
it mixes mutually exclusive paradigms.)

not:  "...use any of the library search paths."


(The sooner we can stop talking about library search paths the less confused I 
will be.
This whole effort is an attempt to kill off that concept.)


KISYSMOD is merely a path fragment, i.e. an abbreviation, not a search path.  
It is no
different than any other environment variable which you might use in an fp lib 
table,
except that Wayne makes a big effort to set KISYSMOD for you if you forget.



> This wont have any impact if you don't have 
> USE_FP_LIB_TABLE=ON when you build KiCad.
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] USE_PCBNEW_NANOMETRES

[Dick Hollenbeck]

On 08/04/2013 01:53 PM, Carl Poirier wrote:
> Hi guys,
> 
> If you want to put your efforts on some more important and complex tasks, I 
> can surely
> volunteer to take care of it, if it has not been done already. I'll attach 
> the patch once
> I'm done going over all the code.


I support this idea, and will volunteer to commit such a working patch from you.

Thank you.

This is a good way to ramp up into a larger role.


Dick



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [Bug 1208116] [NEW] boost Library has Problems

[Dick Hollenbeck]

On 08/04/2013 12:44 PM, Dick Hollenbeck wrote:
> On 08/04/2013 11:01 AM, l.marcanto...@logossrl.com wrote:
>> On Sun, Aug 04, 2013 at 12:35:44PM -0000, Dick Hollenbeck wrote:
>>> Patch under bzr is found in bzr plugin 'bzrtools'.  Install that bitte.
>>
>> I had the same issue... maybe a notice in the dev doc that bzrtools are
>> required could be useful (OTOH searching for bzr patch immediately pop
>> up the relevant site...)
>>
> 
> 
> No objection from me to you doing that.
> 
> Brian's work for Windows builders will eventually mask this issue, and be an 
> invaluable
> resource for users who are not actually developer, but want to stay really 
> current with
> recent source.  I would call them "windows builders", because a builder is 
> somewhere
> between a user and a developer.
> 
> I cannot express how important I feel Brian's work is.  He certainly gets my 
> vote for MVP
> of the month.


I'd give it to Orson for last month.


> 
> An actual Windows developer could probably figure out the problem himself, to 
> be honest.
> 
> Dick
> 
> 
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [Bug 1208116] [NEW] boost Library has Problems

[Dick Hollenbeck]

On 08/04/2013 11:01 AM, l.marcanto...@logossrl.com wrote:
> On Sun, Aug 04, 2013 at 12:35:44PM -0000, Dick Hollenbeck wrote:
>> Patch under bzr is found in bzr plugin 'bzrtools'.  Install that bitte.
> 
> I had the same issue... maybe a notice in the dev doc that bzrtools are
> required could be useful (OTOH searching for bzr patch immediately pop
> up the relevant site...)
> 


No objection from me to you doing that.

Brian's work for Windows builders will eventually mask this issue, and be an 
invaluable
resource for users who are not actually developer, but want to stay really 
current with
recent source.  I would call them "windows builders", because a builder is 
somewhere
between a user and a developer.

I cannot express how important I feel Brian's work is.  He certainly gets my 
vote for MVP
of the month.

An actual Windows developer could probably figure out the problem himself, to 
be honest.

Dick




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Position for variable declaration (trivial style issue)

[Dick Hollenbeck]

On Aug 4, 2013 11:09 AM, "Lorenzo Marcantonio" 
wrote:
>
> During today merge I noticed that some 'new style' variable
> declarations:
>
> function blah()
> {
> int a = 0;
>
> // code
>
> int b = stuff_from_a(a);
>
> // code
> }
>
> were converted to the traditional:
>
> function blah()
> {
> int a = 0;
> int b;
>
> // code
>
> b = stuff_from_a(a);
>
> // code
> }
>
> My preference is to try to restrict the scope of a variable (i.e.
> declare it at the initialization point); the 'old' style could have the
> advantage of seeing from the start all the stuff used. Of course, no
> RAII or collaterals from cons/des, the semantic should be the same (I'd
> say the compiler would optimize both of these in the same way).
>
> Is the traditional style preferred for some reason?

I tend also to prefer the limited scope style.  So if it was some change I
made it was inadvertent, not deliberate.

Getting volunteers to do exact performance is always difficult.




 Just to tune my
> writing style
>
> --
> Lorenzo Marcantonio
> Logos Srl
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] USE_PCBNEW_NANOMETRES

[Dick Hollenbeck]

Can any one see a reason not to yank this conditional, and make its enabled 
code the norm?

It seems as good as old school now.

Dick

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] big commit

[Dick Hollenbeck]

On Aug 3, 2013 11:40 AM, "jean-pierre charras" 
wrote:
>
> On 08/03/2013 06:06 PM, Dick Hollenbeck wrote:
>>
>>
>> On Aug 3, 2013 4:27 AM, "Lorenzo Marcantonio" 
wrote:
>> >
>> > On Sat, Aug 03, 2013 at 01:01:03AM -0500, Dick Hollenbeck wrote:
>> > > 'S' for set grid origin.
>> > >
>> > > This is especially helpful when you use the track tool to center the
mouse cursor on a
>> > > pad.  Then while there, pressing 'S' or 's' will set the grid origin
to that point.  This
>> > > is more functional than the toolbar icon which changes the tool and
cannot center on a pad.
>> >
>> > Yep, that key is a really good idea.
>>
>> Is ctl-space a possible and better key?
>>
>> That is similar to space for relative origin, and its perhaps less
likely to be hit by accident.
>>
>> I don't remember if this key is possible.
>>
>>
> On my computer, ctl-space works under Linux, but does not work under W7
>
> JP Charras

S was chosen among limted choices for 'Snap' grid.

Ultimately its what you commit to memory I guess.

>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] big commit

[Dick Hollenbeck]

On Aug 3, 2013 4:27 AM, "Lorenzo Marcantonio" 
wrote:
>
> On Sat, Aug 03, 2013 at 01:01:03AM -0500, Dick Hollenbeck wrote:
> > 'S' for set grid origin.
> >
> > This is especially helpful when you use the track tool to center the
mouse cursor on a
> > pad.  Then while there, pressing 'S' or 's' will set the grid origin to
that point.  This
> > is more functional than the toolbar icon which changes the tool and
cannot center on a pad.
>
> Yep, that key is a really good idea.

Is ctl-space a possible and better key?

That is similar to space for relative origin, and its perhaps less likely
to be hit by accident.

I don't remember if this key is possible.

>
> I'll tell if something is going wrong:P
>
> --
> Lorenzo Marcantonio
> Logos Srl
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] big commit

[Dick Hollenbeck]

Jean-Pierre

I committed a big edit recently.  Did not have time to test it extensively.

Mildly concerned about eeschema: find operation, and its use of the GetScreen() 
stuff,
which partially went away.

And they way I added the hotkey to pcbnew, modedit.  Do not know if the hot key 
makes
sense in gerbview.  Please check that:

'S' for set grid origin.

This is especially helpful when you use the track tool to center the mouse 
cursor on a
pad.  Then while there, pressing 'S' or 's' will set the grid origin to that 
point.  This
is more functional than the toolbar icon which changes the tool and cannot 
center on a pad.

If I broke something I am sorry.  Some things may need fixing before you all 
win, but
maybe its fine.

Dick

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Python-a-mingw-us final preps

[Dick Hollenbeck]

> For a similar project I upgraded to zlib 1.28 without issue.  I might play 
> with that
> possibility instead if you don't mind.  


The painless playtime is over:



=== modified file 'cmake/PythonExternalPackages.cmake'
--- cmake/PythonExternalPackages.cmake  2013-07-02 22:42:01 +
+++ cmake/PythonExternalPackages.cmake  2013-07-29 19:39:37 +
@@ -58,15 +58,15 @@
 if( MINGW32 OR MINGW64 )

 
#--
-set( ZLIB_RELEASE "1.2.7" )
-set( ZLIB_MD5 60df6a37c56e7c1366cca812414f7b85 ) # re-calc this on every 
RELEASE change
+set( ZLIB_RELEASE "1.2.8" )
+set( ZLIB_MD5 44d667c142d7cda120332623eab69f40 ) # re-calc this on every 
RELEASE change
 set( PREFIX ${CMAKE_CURRENT_BINARY_DIR}/zlib-${ZLIB_RELEASE} )

 ExternalProject_Add(
 zlib
 DOWNLOAD_DIR ${DOWNLOAD_DIR}
 PREFIX ${PREFIX}
-URL 
http://prdownloads.sourceforge.net/libpng/zlib-${ZLIB_RELEASE}.tar.gz
+URL http://zlib.net/zlib-${ZLIB_RELEASE}.tar.gz
 URL_MD5 ${ZLIB_MD5}
 CONFIGURE_COMMAND
 ${CMAKE_COMMAND}


committed.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Python-a-mingw-us final preps

[Dick Hollenbeck]

On 07/21/2013 06:46 PM, Brian Sidebotham wrote:
> Hi Dick,
> 
> I've just committed some fixes for the installer, and a fix for ZLIB because 
> the download
> URL is broken since their latest release (They do not keep older files on 
> their server). I
> simply switched it to sourceforge instead.


For a similar project I upgraded to zlib 1.28 without issue.  I might play with 
that
possibility instead if you don't mind.  But I cannot fault the less risky path 
you took.

But zlib has been pretty stable in it core support for some time, and I 
structured the
CMake script so we can roll with the latest of all external libraries quite 
easily.



> The installer now has separate copies of the cmake NSIS installer templates 
> so they can be
> easily modified to add the extra functionality we require. I've added an 
> extra option to
> set PYTHONHOME on install, and also fixed the PATH setting.


This is very excellent.  Going around the built in CMake NSIS support to extend 
the NSIS
support is very smart and *ambitious*.  This is sounding like a quality effort.

I wonder if we should look at doing this for KiCad?


It will certainly make a nicer impression having a glitzy installer for 
a-mingw-us.


> 
> I'm also working on the wxWidgets-cmake project as it's in desperate need of 
> supporting
> MSVC builds. At the moment it's still MinGW only, but it's getting close to 
> having MSVC
> support.


No idea what MSVC is?  (... probably intentional amnesia, but I forgot 
forgetting.)


> 
> I think next weekend I might be able to have the binaries ready and it looks 
> like a
> KiCad-Winbuilder with scripting support is not long away. There are only 
> minimal changes
> required to our current CMakeLists.txt file in KiCad.



> I do have a problem with Python-a-mingw-us though. The Readline module forces 
> python to
> quit straight away. If I simply rename the readline module so it fails to 
> load,
> python-a-mingw-us appears to work well. I've attached the output from 
> python-a-mingw-us
> with the readline module in place using the -v option.
> 
> When redirecting this output, like:
> 
> python -v > python-a-mingw-us-v.txt 2>&1
> 
> it did not quit straight away - instead I had to quit() properly. But if I 
> run this
> without the output redirection it quits straight away.


Have you had any luck with the thought that it might be un-findable 'terminal 
data' files
(for Windows).  If so, maybe a windows specific subset put in the right place 
may appease.


> 
> There is a long pause in the installer, but it executes successfully. I'm 
> unsure what's
> causing the pause at the moment.
> 
> I can roll the new release files for python-a-mingw-us if you add me to the 
> project. My
> "username" should simply be brian.sidebot...@gmail.com 
> 


Done, you are an admin of that project on code.google.com.

I was on vacation last week and half, sorry it took so long.


Dick



> 
> Best Regards, Brian.
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Fwd: [PATCH] fp_lib_table minor changes to support .pretty folders

[Dick Hollenbeck]

On 07/19/2013 10:33 PM, Ben Harris wrote:
> I think I sent this before I was a member of the group.
> 
> -- Forwarded message --
> From: "Ben Harris" mailto:m...@bharr.is>>
> Date: 19/07/2013 10:04 PM
> Subject: [PATCH] fp_lib_table minor changes to support .pretty folders
> To:  >
> Cc:
> 
> Hi everyone,
> 
> Just tried to give FP_LIB_TABLE a go but it wasn't working with the new 
> [folder of
> kicad_mod] style. Traced it to librari not accepting directories as a 
> library, and
> kicad_plugin incorrectly creating a FILE_LINE_READER (I used the method from 
> gpcb_plugin
> to fix it.
> 
> Sorry if I've sent the patch incorrectly - first time.
> 
> Regards
> -Ben


Ben,


In rev. 4259 I committed scripts/lib_convert.py which converts from one library 
format to
another.  It will be generally useful moving forward for a large number of 
tests and purposes.


Using this script I was able to verify the bug in FP_CACHE::Load() which you 
found.  Thank
you.  I committed a fix similar to your patch under your name in rev 4260.


To run the script to create a *.mod library from a *.pretty library, I used 
this command line:

$ PYTHONPATH=. /svn/kicad/testing.checkout/scripts/lib_convert.py 
/tmp/smd_dil.pretty
/tmp/smd_dil.mod


with my current directory parked in debug/pcbnew which is an out of tree build 
dir.


I did not commit the librairi.cpp portion of your patch since much of that 
module will get
rewritten to use much higher abstraction of libpaths during the final fp lib 
table work.

It should not be necessary to know if a libpath is a directory or a file 
outside the
plugin API.  The API is supposed to hide these kinds of details.

Wayne is working on this whole fp lib table area now.

Dick


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] The KiCad GAL new release

[Dick Hollenbeck]

On Jul 25, 2013 4:27 AM, "László Monda"  wrote:
>
> On Thu, Jul 25, 2013 at 4:28 AM, Alex G.  wrote:
> > On 07/24/2013 08:51 PM, Dick Hollenbeck wrote:
> >>
> >> On Jul 24, 2013 4:26 PM, "Alex G."  >> <mailto:mr.nuke...@gmail.com>> wrote:
> >>>
> >>> On 07/24/2013 03:41 PM, Dick Hollenbeck wrote:
> >>> >
> >>> > On Jul 24, 2013 3:05 PM, "Alex G."  >> <mailto:mr.nuke...@gmail.com>
> >>> >>
> >>> >> P.S. I can't emphasize enough how much I like the new rendering
modes.
> >>> >
> >>> > To hear this is good news, I have yet to spend this time to review
the
> >>> > intermediary work.  But I am extremely happy to hear that someone
finds
> >>> > this massive body of work promising.
> >>> >
> >>> > I think your opinion of "releases" may be overrated however.  What
is a
> >>> > release wrt kicad?  Its fools gold IMO. Just use your own build, you
> >>> > obviously know how to build it.
> >>> >
> >>> A "release" or "stable branch" in distro packager terms is code that
the
> >>> developers, to the best of their ability certify is stable and good
for
> >>> production use. In fact distros have specific guidelines about not
> >>> packaging "development" code. What this usually means is distros want
a
> >>> tarball without the terms "rc", "nightly", "devel", "alpha", "beta",
etc
> >>> (a release). If that is not available, distros are also willing to
> >>> accept a snapshot of the repository, but strongly encourage
> >>> (gun-aimed-to-your-head type encouragement) a "stable" branch is
packaged.
> >>>
> >>> What this usually means is, as long as GAL is just another branch, it
> >>> won't get into the hands of the majority of users.
> >>>
> >>> There are also a few "things" that make merging GAL non-trivial. First
> >>> of all, the tools do not (yet) work in OpenGL/Cairo modes. This will
> >>> require a smarte(er) merge strategy. In merge ASCII art, it would look
> >>> something like:
> >>>
> >>>  - (devel) |---*
> >>>|  /
> >>>  - (gal_merge) |  *---(make tools work, etc) *
> >>>| /
> >>>  - (gal)   |*--(continue normal GAL cycle)-
> >>>
> >>> (You'll need to read this in monospace for it to make sense)
> >>>
> >>> Now this requires some work. I am not qualified to operate the Kicad
> >>> source tree, but I'm willing to bet it should be doable in a
reasonable
> >>> timeframe.
> >>>
> >>> Is it worth it? I vote "yes".
> >>
> >> Distro kicad  packages are not even worth the effort in several of the
> >> distros, they are so far behind current code as to be irrelevant for a
> >> serious kicad user.
> >>
> > DISCLAIMER: Skip to third paragraph if you are not interested in
> > discussions about releases. I won't mind.
> > DISCLAIMER2: I'm perfectly fine with the current no-release philosophy.
> >
> > And distro packages being so far behind is partly due to the
> > release-less philosophy. First of all you lose all the bells and
> > whistles of a release (blog posts, articles, users seeing a higher
> > number). You lose, all the publicity, and you lose the users saying "My
> > kicad is newer than yours", and hence you lose pressure on the packagers
> > to update. There's no concept of newness. A Kicad branch from two years
> > ago is just as good as today's Kicad (1) (exceptions exist). I speak
> > from the perspective of a packager who is not necessarily a "serious
> > kicad user". Not all packagers are.
>
> PR is one of the strongest reasons, I believe.  Something like
> http://kernelnewbies.org/LinuxChanges is badly needed for KiCad
> because users have zero high-level visibility regarding new features.
> For example the middle button panning feature might seem like a minor
> change development-wise but it's extremely useful for users.
>
> I agree that the no release philosophy directly contributes to
> outdated packages on distros but seeing the resistance on the
> development side thi

Re: [Kicad-developers] The KiCad GAL new release

[Dick Hollenbeck]

On Jul 24, 2013 10:14 PM, "Cirilo Bernardo" 
wrote:
>
> >____
> > From: Dick Hollenbeck 
> >To: Alex G. 
> >Cc: KiCad Developers 
> >Sent: Thursday, July 25, 2013 11:51 AM
> >Subject: Re: [Kicad-developers] The KiCad GAL new release
> >
> >
> >
> >
> >On Jul 24, 2013 4:26 PM, "Alex G."  wrote:
> >>
> >> On 07/24/2013 03:41 PM, Dick Hollenbeck wrote:
> >> >
> >> > On Jul 24, 2013 3:05 PM, "Alex G."  >> >>
> >> >> P.S. I can't emphasize enough how much I like the new rendering
modes.
> >> >
> >> > To hear this is good news, I have yet to spend this time to review
the
> >> > intermediary work.  But I am extremely happy to hear that someone
finds
> >> > this massive body of work promising.
> >> >
> >> > I think your opinion of "releases" may be overrated however.  What
is a
> >> > release wrt kicad?  Its fools gold IMO. Just use your own build, you
> >> > obviously know how to build it.
> >> >
> >> A "release" or "stable branch" in distro packager terms is code that
the
> >> developers, to the best of their ability certify is stable and good for
> >> production use. In fact distros have specific guidelines about not
> >> packaging "development" code. What this usually means is distros want a
> >> tarball without the terms "rc", "nightly", "devel", "alpha", "beta",
etc
> >> (a release). If that is not available, distros are also willing to
> >> accept a snapshot of the repository, but strongly encourage
> >> (gun-aimed-to-your-head type encouragement) a "stable" branch is
packaged.
> >>
> >> What this usually means is, as long as GAL is just another branch, it
> >> won't get into the hands of the majority of users.
> >>
> >> There are also a few "things" that make merging GAL non-trivial. First
> >> of all, the tools do not (yet) work in OpenGL/Cairo modes. This will
> >> require a smarte(er) merge strategy. In merge ASCII art, it would look
> >> something like:
> >>
> >>  - (devel) |---*
> >>|  /
> >>  - (gal_merge) |  *---(make tools work, etc) *
> >>| /
> >>  - (gal)   |*--(continue normal GAL cycle)-
> >>
> >> (You'll need to read this in monospace for it to make sense)
> >>
> >> Now this requires some work. I am not qualified to operate the Kicad
> >> source tree, but I'm willing to bet it should be doable in a reasonable
> >> timeframe.
> >>
> >> Is it worth it? I vote "yes".
> >Distro kicad  packages are not even worth the effort in several of the
distros, they are so far behind current code as to be irrelevant for a
serious kicad user.
> >You cannot vote action in this project, except when you have a volunteer
that is soliciting opinion and willing to do what is decided by others
according to vote.  I can tell you now that I will never make a single
commit to the stable branch, ever.
> >I think it is a dilution of testing and development resources that keeps
folks from testing the testing branch.  The end result is both branches are
of reduced quality relative to a scheme where bugs were smoked out faster
because everyone is using the same tree.  Again, the stable branch is fools
gold.  True gold is rapid fixing of breakage in one branch.
> >Package maintainers can establish their own policies, but they need not
have an effect on my opimions, any more than my opimions affect their
policies.
> >
>
>
> Ah, 'stable' release ... I thought the software world threw out that
notion years ago - everything is simply branded Beta software these days,
even the stuff I pay $$$ for.

Each software project has different dynamics of evolution.  Bunching them
all into one broad statement is incorrectly crude.

>From the user's manager's distorted point of view, software should simply
work and if there are bugs then the vendor should provide a fix. From the
user's point of view, they don't want to learn to compile software. Neither
the user nor any managers would want someone to waste time when something
breaks and neither would want an incompatible change in file formats.

The builder simply rebuilds, usually within a half day of when the broken
code is fixed by a project developer.  Its simpler than y

Re: [Kicad-developers] The KiCad GAL new release

[Dick Hollenbeck]

On Jul 24, 2013 4:26 PM, "Alex G."  wrote:
>
> On 07/24/2013 03:41 PM, Dick Hollenbeck wrote:
> >
> > On Jul 24, 2013 3:05 PM, "Alex G."  >>
> >> P.S. I can't emphasize enough how much I like the new rendering modes.
> >
> > To hear this is good news, I have yet to spend this time to review the
> > intermediary work.  But I am extremely happy to hear that someone finds
> > this massive body of work promising.
> >
> > I think your opinion of "releases" may be overrated however.  What is a
> > release wrt kicad?  Its fools gold IMO. Just use your own build, you
> > obviously know how to build it.
> >
> A "release" or "stable branch" in distro packager terms is code that the
> developers, to the best of their ability certify is stable and good for
> production use. In fact distros have specific guidelines about not
> packaging "development" code. What this usually means is distros want a
> tarball without the terms "rc", "nightly", "devel", "alpha", "beta", etc
> (a release). If that is not available, distros are also willing to
> accept a snapshot of the repository, but strongly encourage
> (gun-aimed-to-your-head type encouragement) a "stable" branch is packaged.
>
> What this usually means is, as long as GAL is just another branch, it
> won't get into the hands of the majority of users.
>
> There are also a few "things" that make merging GAL non-trivial. First
> of all, the tools do not (yet) work in OpenGL/Cairo modes. This will
> require a smarte(er) merge strategy. In merge ASCII art, it would look
> something like:
>
>  - (devel) |---*
>|  /
>  - (gal_merge) |  *---(make tools work, etc) *
>| /
>  - (gal)   |*--(continue normal GAL cycle)-
>
> (You'll need to read this in monospace for it to make sense)
>
> Now this requires some work. I am not qualified to operate the Kicad
> source tree, but I'm willing to bet it should be doable in a reasonable
> timeframe.
>
> Is it worth it? I vote "yes".

Distro kicad  packages are not even worth the effort in several of the
distros, they are so far behind current code as to be irrelevant for a
serious kicad user.

You cannot vote action in this project, except when you have a volunteer
that is soliciting opinion and willing to do what is decided by others
according to vote.  I can tell you now that I will never make a single
commit to the stable branch, ever.

I think it is a dilution of testing and development resources that keeps
folks from testing the testing branch.  The end result is both branches are
of reduced quality relative to a scheme where bugs were smoked out faster
because everyone is using the same tree.  Again, the stable branch is fools
gold.  True gold is rapid fixing of breakage in one branch.

Package maintainers can establish their own policies, but they need not
have an effect on my opimions, any more than my opimions affect their
policies.







>
> > I regret ever creating the stable release.  It is simply fools gold.
> > The testing tree almost always has fewer bugs simply because they get
> > fixed faster.
> >
> As a Fedora package maintainer, I can vouch that lacking a stable branch
> would be a headache hell for a packager. A stable branch prevents cases
> where a deadly bug is introduced, and very quickly fixed, but a distro
> taking the source snapshot right in-between. Fool's gold or not, it
> serves its purpose.
> DISCLAIMER: I am not involved in packaging Kicad for Fedora.
>
> Alex
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] The KiCad GAL new release

[Dick Hollenbeck]

On Jul 24, 2013 3:05 PM, "Alex G."  wrote:
>
> On 07/08/2013 02:35 PM, Maciej Sumiński wrote:
> > Ladies and Gentlemen,
> > [...]
> > Thanks in advance for your feedback.
> >
> I've just tested this on a 9800GT with nouveau drivers. Default
> rendering mode is really laggy (as is in the vanilla pcbnew). On the
> other hand OpenGL mode is much better, and OpenGL with shaders is
> super-smooth.
>
> Is there any chance GAL can be incorporated into a Kicad release, even
> if GAL development will continue to be branched? I'd love to be able to
> design my PCBs in one of the new graphic modes. Also, this would bring a
> lot more bug reports.
>
> Alex
>
> P.S. I can't emphasize enough how much I like the new rendering modes.
>
>

To hear this is good news, I have yet to spend this time to review the
intermediary work.  But I am extremely happy to hear that someone finds
this massive body of work promising.

I think your opinion of "releases" may be overrated however.  What is a
release wrt kicad?  Its fools gold IMO. Just use your own build, you
obviously know how to build it.

I regret ever creating the stable release.  It is simply fools gold.  The
testing tree almost always has fewer bugs simply because they get fixed
faster.

Dick
___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Fwd: [wxWidgets] CMake files could be included into wxWidgets build system

[Dick Hollenbeck]

There are some pro cmake folks in that group, that have been sidelined
until now.  I very strongly suggest that you join that list, if only to
post one message about your amazing work, NOW.
On Jul 18, 2013 7:54 AM, "Dick Hollenbeck"  wrote:

> Where did you push to?
>
> The wx-dev guys can possibly help.  Main thing is that they get notified
> of what you have done so far, soon.
>
> So they can unify efforts.
>
> On Jul 18, 2013 2:52 AM, "Brian Sidebotham" 
> wrote:
> >
> > Excellent, Thanks for forwarding Dick. I've just pushed the project, but
> I have another week or so of work to do. It currently builds wxWidgets +
> wxPython using MinGW. There's a lot of work with compiler definitions
> though that needs to be dealt with so MSVC can be used to compile the
> project. Then I need to get the Linux work done.
> >
> > At the moment the project is good to make the binaries needed for KiCad
> at least. We're in the process of moving house so time has been really
> scarce.
> >
> > I will commit the python-a-mingw-us installer fixes at the weekend.
> They're pretty much ready to go bar a bit of testing on my part.
> >
> > Best Regards, Brian.
> >
> >
> >
> > On 17 July 2013 23:05, Dick Hollenbeck  wrote:
> >>
> >> Brian,
> >>
> >> I got this from a member of the wx-dev mailing list today.
> >>
> >> I asked about it a month ago, and VZ has yielded a little it seems.
> >>
> >> Now is you time to pounce.
> >>
> >> Haven't heard from you in a while.
> >>
> >> Also please commit to python-a-mingw-us what you've done re: installer.
> >>
> >>
> >> Dick
> >>
> >> ==
> >>
> >>
> >>
> >> Hello,
> >>
> >> For your information
> >>
> http://thread.gmane.org/gmane.comp.lib.wxwidgets.devel/149823/focus=149869
> >>
> >> Regards,
> >> Kolya.
> >>
> >>
> >>
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >
> >
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Fwd: [wxWidgets] CMake files could be included into wxWidgets build system

[Dick Hollenbeck]

Where did you push to?

The wx-dev guys can possibly help.  Main thing is that they get notified of
what you have done so far, soon.

So they can unify efforts.

On Jul 18, 2013 2:52 AM, "Brian Sidebotham" 
wrote:
>
> Excellent, Thanks for forwarding Dick. I've just pushed the project, but
I have another week or so of work to do. It currently builds wxWidgets +
wxPython using MinGW. There's a lot of work with compiler definitions
though that needs to be dealt with so MSVC can be used to compile the
project. Then I need to get the Linux work done.
>
> At the moment the project is good to make the binaries needed for KiCad
at least. We're in the process of moving house so time has been really
scarce.
>
> I will commit the python-a-mingw-us installer fixes at the weekend.
They're pretty much ready to go bar a bit of testing on my part.
>
> Best Regards, Brian.
>
>
>
> On 17 July 2013 23:05, Dick Hollenbeck  wrote:
>>
>> Brian,
>>
>> I got this from a member of the wx-dev mailing list today.
>>
>> I asked about it a month ago, and VZ has yielded a little it seems.
>>
>> Now is you time to pounce.
>>
>> Haven't heard from you in a while.
>>
>> Also please commit to python-a-mingw-us what you've done re: installer.
>>
>>
>> Dick
>>
>> ==
>>
>>
>>
>> Hello,
>>
>> For your information
>>
http://thread.gmane.org/gmane.comp.lib.wxwidgets.devel/149823/focus=149869
>>
>> Regards,
>> Kolya.
>>
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Fwd: [wxWidgets] CMake files could be included into wxWidgets build system

[Dick Hollenbeck]

Brian,

I got this from a member of the wx-dev mailing list today.

I asked about it a month ago, and VZ has yielded a little it seems.

Now is you time to pounce.

Haven't heard from you in a while.

Also please commit to python-a-mingw-us what you've done re: installer.


Dick

==



Hello,

For your information
http://thread.gmane.org/gmane.comp.lib.wxwidgets.devel/149823/focus=149869

Regards,
Kolya.




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Install KiCad on non Ubuntu distros - best way?

[Dick Hollenbeck]

On 07/02/2013 01:35 PM, Dick Hollenbeck wrote:
> 
>> how about an install script for all linux distro? 
> 
> "all"  :)
> 
> 
> Must we really make "all" linux distros our problem?
> I run linux on a PLC, and oh, my Android cell phone.
> 
> 
> The build and install procedure for most contemporary desktop linux distros 
> will have
> these  basic steps in common:
> 
> 
> install prerequisites
> checkout kicad source using bzr
> build it using Cmake
> install it using CMake
> 
> checkout kicad.library using bzr
> install it using CMake
> 
> 
> The last two steps can be replaced with a tar file procedure.
> 
> So really the main variance is the very first step.  If you can find a way to 
> abstract
> that, then the rest is common.


"finding a way to abstract that" means:

I suggest creating a number of equivalent distro specific scripts which did 
that first
step, "install prerequisites".  Then simply call the distro specific first 
script from a
common script.


Its the best I can think of, Fabrizio.


You already have the first step in hand for ubuntu/debian.  It could be put 
into a shell
script, say "install-prerequisites-ubuntu-debian.sh"  That is a good share of 
linux
distros already.


The RPM based distros may have some commonality between them also, provided 
there are any
common package names, so with two "step one scripts", you'd have a number of 
linux distros
covered.


This is the "build your own" on linux discussion winding down.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Install KiCad on non Ubuntu distros - best way?

[Dick Hollenbeck]

> how about an install script for all linux distro? 

"all"  :)


Must we really make "all" linux distros our problem?
I run linux on a PLC, and oh, my Android cell phone.


The build and install procedure for most contemporary desktop linux distros 
will have
these  basic steps in common:


install prerequisites
checkout kicad source using bzr
build it using Cmake
install it using CMake

checkout kicad.library using bzr
install it using CMake


The last two steps can be replaced with a tar file procedure.

So really the main variance is the very first step.  If you can find a way to 
abstract
that, then the rest is common.


Dick




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Install KiCad on non Ubuntu distros - best way?

[Dick Hollenbeck]

On 07/02/2013 12:48 PM, Fabrizio Tappero wrote:
> Hello,
> I have updated the instructions to install KiCad on Debian and other 
> distros...
> http://www.kicad-pcb.org/display/KICAD/KiCad+EDA+Software+Suite

Quoting from the site:

"
That is it. You now have the latest version of KiCad. If, at any time, you want 
to update
your version of KiCad you do the following:

cd /opt/kicad.bzr
bzr update
cd build
rm -rf *
cmake ../
make
sudo make install
"



Fabrizio,

I think the update procedure is not correct.  If you do "rm -rf *" then your
CMakeCache.txt file is gone, and the line

cmake ../

becomes insufficient.

I would replace these two lines which I mention, with one line:

make clean

which is followed by
make

This is probably adequate.



> 
> the whole process takes however very long time a lots of space.


Really?  Can you elaborate on what is consuming the time and the space.  Narrow 
down the
problem as you see it please.



> Does any body knows a better way? I am not sure a direct link like
> this
> http://kicad.tuturutu.cz/
> 
> could be a solution because the software update process would be not
> really automatic.
> 
> Is there any change we could add here:
> 
> sudo add-apt-repository ppa:adamwolf/kicad-testing-daily
> 
> a non-ubuntu repo?
> 
> how about an install script for all linux distro?


Has anyone had success packaging wxWidgets in a premade DSO format, same 
binaries for all
linux platforms?  If not, then it seems unlikely we could do this.  What other
(commercial) EDA tools do is provide many of the GUI libraries as part of the 
prebuilt
binaries.  Check around about a prebuilt wxWidgets DSO set that could accompany 
a
pre-built KiCad.  This is more of a wx investigation.





> how about a check
> for updates inside KiCad itself? ... just throwing ideas...
> 
> 
> Cheers
> Fabrizio
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Oscad an EDA tool

[Dick Hollenbeck]

On 07/01/2013 01:25 PM, Oscad Team wrote:
> Hello Dick, Martijn, Edwin
> 
> We have not modified/bug-fixed/enhanced the KiCad source code. We have only 
> used the
> binary version (installable through Ubuntu package manager for Ubuntu and the 
> .exe file
> for Windows available on the KiCad webpg). We are using KiCad as the 
> schematic editor and
> layout editor tool in Oscad. We mention that in our documents as well. In 
> fact, in our
> tutorial series, we have made 4 tutorials on KiCad. We refer to them in our 
> Oscad tutorial
> for the users to know more about schematic creation and PCB design. We have 3 
> tutorials on
> Oscad. All these tutorials are available on our webpage oscad.in 
> <http://oscad.in> .


Awesome, sounds like a good way for me to finally learn how to use KiCad  
(better).
My "number of boards produced to lines of code contributed ratio" is 
embarrassing.


>  We only call eeschema, pcbnew and cvpcb using a script and launch them. All 
> our scripts
> are available on the webpage. Requesting you to kindly check the same.


Read section 3. of the GPLv2.  This only applies if you are *distributing* 
binaries of
unmodified source or binaries of modified source.  If you are pointing folks to 
a separate
resource from which users will obtain their own binaries, then there is no 
concern.  In at
least the linux installer, I don't see where you are *distributing* KiCad 
binaries at all.
 I don't know about the Windows installer.


The GPLv2 is present in file COPYRIGHT.txt in the KiCad source distribution if 
you do not
have prior familiarity.



> Kindly let us know of any issues/concerns/feedback.


I do like the conceptual approach that you have taken.  It sounds like you have 
displaced
the kicad project manager with python code?  (I don't know when I will find 
time to look
at it in detail.)

But using python to glue solution spaces together seems like a very sensible 
idea.  That
top level code is not performance critical, so using the highest level language 
to do it
in makes perfect sense to me.  Why program on your hands and knees when you can 
get up and
run?


Best regards,

Dick




> 
> Thanks and regards
> Rakhi
> Oscad Team
> 
> 
> On Mon, Jul 1, 2013 at 8:31 PM, Dick Hollenbeck  <mailto:d...@softplc.com>> wrote:
> 
> On 07/01/2013 07:31 AM, Edwin van den Oetelaar wrote:
> > On Mon, Jul 1, 2013 at 10:00 AM, Martijn Kuipers 
>  <mailto:martijn.kuip...@gmail.com>
> > <mailto:martijn.kuip...@gmail.com <mailto:martijn.kuip...@gmail.com>>> 
> wrote:
> >
> > Just wondering if you (the OSCAD team) made any changes to KiCAD. I 
> went to your
> site,
> > but was unable to find any source code to do a comparison.
> >
> > So, my question is: did you do any enhancement/bug-fixing/changed 
> to KiCAD code ?
> >
> > Were any of "our" main debs aware of OSCAD launching? It seemed to 
> me to come out of
> > the blue...
> >
> > Kind regards,
> > Martijn
> >
> >
> > I have never heard of this.
> > Furthermore, no source code, not even a link to the KiCAD sources on 
> the website.
> > Looks like somebody made a closed binary installer/distribution and 
> forgot who is doing
> > most of the work.
> > I think this is a bad development, not the way to help the project or 
> the users of
> KiCAD.
> > Greetings,
> > Edwin van den Oetelaar
> 
> 
> Thanks Edwin, let's all keep an eye on this relative to the GPLv2 
> licensing requirements.
> 
> if( distribute_code )
> {
> 
> // read the damn license, do what it says
> }
> 
> Their stated intentions seem to comply, while their actions are not in 
> obvious compliance.
> Help monitoring this is appreciated.
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Oscad an EDA tool

[Dick Hollenbeck]

On 07/01/2013 07:31 AM, Edwin van den Oetelaar wrote:
> On Mon, Jul 1, 2013 at 10:00 AM, Martijn Kuipers  > wrote:
> 
> Just wondering if you (the OSCAD team) made any changes to KiCAD. I went 
> to your site,
> but was unable to find any source code to do a comparison.
> 
> So, my question is: did you do any enhancement/bug-fixing/changed to 
> KiCAD code ? 
> 
> Were any of "our" main debs aware of OSCAD launching? It seemed to me to 
> come out of
> the blue...
> 
> Kind regards,
> Martijn
> 
> 
> I have never heard of this.
> Furthermore, no source code, not even a link to the KiCAD sources on the 
> website.
> Looks like somebody made a closed binary installer/distribution and forgot 
> who is doing
> most of the work. 
> I think this is a bad development, not the way to help the project or the 
> users of KiCAD.
> Greetings,
> Edwin van den Oetelaar


Thanks Edwin, let's all keep an eye on this relative to the GPLv2 licensing 
requirements.

if( distribute_code )
{

// read the damn license, do what it says
}

Their stated intentions seem to comply, while their actions are not in obvious 
compliance.
Help monitoring this is appreciated.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] *.kicad_pcb file loading speedup success

[Dick Hollenbeck]

For months I have been wanting to experiment with DSNLEXER::findToken() and see 
if there
were faster techniques than the binary search of C strings that I initially 
used.  I had a
hunch that a hashtable might be faster.

After bringing in boost unordered_map< std::string, int > and instrumenting 
files.cpp to
tell how many microseconds a PLUGIN::Load() would take, the results were 
surprising to me.
The moral of this story is never guess what you can measure, unless you are 
willing to be
wrong.  I was able to measure before and after results.

The hashtable unordered_map< std::string ..> was slower than the bsearch().  
Then I
swapped out the hash function with a custom one.  This was nearly identical in 
results.

About the time I was ready then to yank out the experimental code, i.e. give 
up, I said
"well why not try one last thing".  How about a tricked out hashtable that uses 
C strings
rather than std::string, and a hashfunction that works directly on C string and 
an
equality test that distills down to C's strcmp()?


The result was again surprising.  I bagged a 13% reduction/speedup in overall 
*.kicad_pcb
file loading times on larger files.  Note that this was a specialized hashtable 
that I
basically invented, you will probably not find this in books.  Because if you 
pass "const
char*" pointer to a boost hashtable, you basically get const char* (32 or 64 
bits) being
treated as a large integer, and no de-referencing is made to the actual C 
string.  Of
course the reason is that no storage is provided for the C string within the 
hashtable.

Yours truly was rewarded with a little experimentation and out of the box 
thinking.

I cannot image how much faster this technique is relative to 
DSNLEXER::findToken()
considered alone.  What I am reporting is the effect on all of board loading 
time, so you
know that findToken() has to be enormously much faster now than the 13% effect 
on over all
load time.


Regards,

Dick


P.S.

The bad news is that *.kicad_pcb file loading is still slower than legacy.  And 
it will
probably always be so.  But we are now within ball park, so don't let it bother 
you, it
won't bother me.  I gave it my best, and don't think there are any more low 
hanging fruit
to reap here.

A certain portion of this gain, say about 20% of the total gain, was due to 
giving up case
independent compare.  Now your keywords must match, you don't get case 
independence on
token matching.  (I forgot that was even in there, and I don't think any 
s-expression
files became dependent on upper case keywords, since we complain in CMake about 
them in
the grammar files.)

If it breaks anything, yell.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] some crashes reported to Debian

[Dick Hollenbeck]

On 06/27/2013 11:18 AM, Kaspar Bumke wrote:
> Hey,
> 
> some people from Carnegie Melon Uni have reported 1200 crashes that occur 
> with programs
> from the Debian repos when they run their automated test-suite[1] . There are 
> 3 KiCAD ones
> if you look at the summary [2].
> 
> Ciao,
> 
> Kaspar
> 
> [1] http://lists.debian.org/debian-devel/2013/06/msg00720.html
> [2] http://forallsecure.com/reports/dd-list.txt


Let's all look at it, and see if we can tell what it is telling us:


Daniel J. Priem 
   kicad (U)

Georges Khaznadar 
   kicad

Richard Antony Burton 
   kicad (U)


I am drawing a blank, will need help interpreting the above.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Hotkey for moving zone corner?

[Dick Hollenbeck]

On 06/25/2013 05:32 AM, Chris Morgan wrote:
> I searched but couldn't find a hotkey for moving zone edges or a command to 
> do so in the
> hotkey list. Should I send a patch to add a new hotkey for that?
> 
> Chris
> 


I last used zone editing quite some time ago, on a board with over 10 zones.

I don't know enough about current behavior to be helpful, will find out in 
another day,
doing a new board now.

When I last looked, the biggest difficulty with zone editing was hit-testing of 
the zone
edges.  At that time it would often not find the edge correctly, and when it 
did, it would
find one from a neighboring zone on the same layer as well.  This may have 
improved.

The hotkey by comparison, for me, is a smaller need than accurate hit-testing, 
and I
personally see no reason to oppose such a new feature.

Your hotkey will also have to contend with hit-testing, should use the same 
code as mouse
does, at least after the dust settles.


Dick





___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] - pcad2kicadpcb: check for file format.

[Dick Hollenbeck]

On 06/24/2013 01:53 PM, Alexander Lunev wrote:
> pcad2kicadpcb: check for file format.
> 
> The patch is against revision 4221 of lp:kicad branch.
> 

committed in 4223.




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] There's something wrong with dragging in eeschema...

[Dick Hollenbeck]

On 06/21/2013 02:11 AM, Lorenzo Marcantonio wrote:
> On Wed, Jun 19, 2013 at 12:30:07PM +0200, Lorenzo Marcantonio wrote:
>> OK, I'll try to do a vanilla build to see if something broke during
>> merge (I didn't change anything about that, I have no idea...)
> 
> Hrr... even vanilla sometimes give the issue; not always and not on
> faster boxes... could it be a timing condition or something about the
> order of the event arrival??? On the atom box it does it *always*
> (should be easier to debug at least :D)
> 
> I'll need more intensive tracing to find the culprit; I suppose the
> auto-pan code is in the common frame, right?
> 


$ bzr diff -r 4206..4207  common/draw_panel.cpp  > reverse_me_out.patch



If you reverse out the patch generated from the above, this was the most recent 
change to
autopan.  But unless you are dragging off the screen, this may not be it.

I offer the above only as a test of course, since neither JP nor several others 
have
experienced any problem with this change.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Request in s-expression format: general user data or comment

[Dick Hollenbeck]

On 06/23/2013 10:25 AM, Thiadmer Riemersma wrote:
> Hello Dick,
> 
>> Are you using wx as your ui?
> 
> Yes, but I am not linking to the KiCad code.
> 
>> I would accept a patch which preserves a multiline comment block thru a Load 
>> / Save ()
>> cycle if that muliline comment is first in kicad_mod file.
> 
> OK. But I will focus on the footprint manager/wizard first. It is a long way 
> from
> finished. When that is done, I will see whether I can patch the module editor.
> 
> Thanks for pointing me to DSNLEXER. It is a bit clearer now, how the 
> s-expressions are
> parsed and formed. One question about the quotation marks, though: apparently 
> these can be
> changed from a double quote to either a singe quote or a dollar sign.

No, not in "non-specctrMode".  non-specctraMode equals KiCad mode within 
DSNLEXER.

See /Documentation/s-expressions.txt

In KiCad mode (aka non-specctraMode), *only double quotes are to be used*.


Then when preparing a non-numeric string for output, we always call
OUTPUTFORMATTER::Quotes() or OUTPUTFORMATTER::Quotew(), unless it is a number, 
in which
case you can be certain it will not need to be quoted.  Quote{s,w} will not 
quote unless
quoting is needed, and will also escape any interior double quote.




 But how does that
> work? Must the new quote character indeed be prefixed by ASCII code -9? If 
> so, is that the
> same as ASCII 247?


1) Is your code GPLv2?

If yes, then you should be using PCBIO class (in kicad_plugin.{h,cpp} and 
DSNLEXER and
OUTPUTFORMATTER at this point.

Otherwise your code is based on sand.

PCBIO may not be truly the opposite of sand, but as it moves you will move if 
you are
based on it.

In fact I will not even answer any more questions which indicate that you are 
not using
the foundational classes or APIs and trying to roll your own in C++.


2) madparts is ahead of KiCad itself regarding the *use of* the new "pretty" 
format.  I do
not know about your code, but spent some time looking at madparts.  The guy 
understands
the pretty format, how to store parts in a pretty directory, and fully 
understands that
that is our future, not the legacy format.  The moment the fp lib table is 
done, anyone
can switch over immediately or continue to operating using a blend of legacy, 
eagle,
pretty, or geda footprints, each in their own fp libraries.


I just *now* completed the ability to round trip leading (initial) comments in 
the
standalone pretty modules/footprints.  This does not apply to modules found in 
boards,
only stand alone modules, such as *.kicad_mod files either as exports or in 
pretty libraries.


For the madparts dude, he can probably put the entire coffee script in a 
comment block at
the front end of the module if he wants.  You can also now put your templating 
information
there also.  This was a planned feature from day one, actually not driven by 
you, and this
is why I did it so fast.  I meant to do it way back when.


Regards,


Dick


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Request in s-expression format: general user data or comment

[Dick Hollenbeck]

On Jun 23, 2013 5:16 AM, "Dick Hollenbeck"  wrote:
>
>
> On Jun 23, 2013 4:45 AM, "Thiadmer Riemersma" <
thiadmer.riemer...@gmail.com> wrote:
> >
> > Hello everyone,
> >
> > I have a request for the s-expression format for footprints: a field
for data that is not used by pcbnew or the module editor, but that is
preserved (by the module editor). Something like (fp_userdata "general text
string").
> >
> > In the alternative, I would like to request to be able to put comments
in an s-expression. Those comments need not be preserved (by the module
editor).
>
> Any line whose first character is a # is a comment now.  Should be no
limit to th numbrr of such lines.  So your alternative is being fulfilled
already, courtesy of yours truly.
>
> >
> > Rationale:
> >
> > I am developing a "footprint wizard", based on templates. But a wizard
won't be of much use if you cannot modify the footprints later. So, this
wizard reads back footprints and allows you to adjust them. However,
detecting which template was used (and with what settings) may not be
deterministically feasible, given the number of options.
> >
> > So, the best option is to store that information in the generated
footprint. Even if the user changes the footprint in the module editor, the
wizard would still be able to get the correct template.
> >
> > In the alternative (store the information in a comment), the user would
be able to adjust the footprint with the wizard, as long as no changes have
been made to it in the module editor. This is good enough for me.
> >
> > Question:
> >
> > I do not appear to be able to select an s-expression library in pcbnew.
Is this correct? Or do I need to build KiCad with a special option?
>
> Look at how the test program is built down in /tools.  I wrote a document
model parsing function that gives you a boost propert tree as a document.
>
> A second path is to try and lind to libcommon, but this will flop due to
unredolved ecternals if you stray too far from richio and dsnlexer.
>
> A final and third option is to link with _pcbnew.so which basically all
of pcbnew in DSO form.

Look at KICAD_PLUGIN::Footprint*() functions.  I would accept a patch which
preserves a multiline comment block thru a Load / Save () cycle if that
muliline comment is first in kicad_mod file.  Telling DSNLEXER to announce
comments is already there, just have to turn it on after construction, then
concatonate initial single line comments for subsequent Save (). Do not
change DSNLEXER.

This form of DSNLEXER usage is not document model.

Currently this is only built is SCRIPTING is bulit, but I will be changing
this in the next handful of weeks so it always gets built.
>
> Are you using wx as your ui?
>
> Dick
>
> >
> > Regards,
> > Thiadmer Riemersma
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Request in s-expression format: general user data or comment

[Dick Hollenbeck]

On Jun 23, 2013 4:45 AM, "Thiadmer Riemersma" 
wrote:
>
> Hello everyone,
>
> I have a request for the s-expression format for footprints: a field for
data that is not used by pcbnew or the module editor, but that is preserved
(by the module editor). Something like (fp_userdata "general text string").
>
> In the alternative, I would like to request to be able to put comments in
an s-expression. Those comments need not be preserved (by the module
editor).

Any line whose first character is a # is a comment now.  Should be no limit
to th numbrr of such lines.  So your alternative is being fulfilled
already, courtesy of yours truly.

>
> Rationale:
>
> I am developing a "footprint wizard", based on templates. But a wizard
won't be of much use if you cannot modify the footprints later. So, this
wizard reads back footprints and allows you to adjust them. However,
detecting which template was used (and with what settings) may not be
deterministically feasible, given the number of options.
>
> So, the best option is to store that information in the generated
footprint. Even if the user changes the footprint in the module editor, the
wizard would still be able to get the correct template.
>
> In the alternative (store the information in a comment), the user would
be able to adjust the footprint with the wizard, as long as no changes have
been made to it in the module editor. This is good enough for me.
>
> Question:
>
> I do not appear to be able to select an s-expression library in pcbnew.
Is this correct? Or do I need to build KiCad with a special option?

Look at how the test program is built down in /tools.  I wrote a document
model parsing function that gives you a boost propert tree as a document.

A second path is to try and lind to libcommon, but this will flop due to
unredolved ecternals if you stray too far from richio and dsnlexer.

A final and third option is to link with _pcbnew.so which basically all of
pcbnew in DSO form.  Currently this is only built is SCRIPTING is bulit,
but I will be changing this in the next handful of weeks so it always gets
built.

Are you using wx as your ui?

Dick

>
> Regards,
> Thiadmer Riemersma
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] libgnomeprint issues are back.

[Dick Hollenbeck]

> Anybody else have any better ideas or
> thoughts on this?


Suddenly an additional idea pops up:


   https://launchpad.net/~q3aiml/+archive/wxwidgets2.9


This might be a silver bullet for the problem, depending on build options.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] libgnomeprint issues are back.

[Dick Hollenbeck]

On 06/21/2013 11:23 AM, Wayne Stambaugh wrote:
> KiCad failed to build against the latest build of wxWidgets 2.8.12 on
> Debian testing.  Apparently they have dropped building wxWidgets with
> libgnomeprint since it has been deprecated from the Gnome project for
> quite some time. 


By "they" you must surely mean the wxWidgets debian package maintainer.  It 
would be nice
to have some  influence over that maintainer.  I would ask, "why are you using 
2.8.x at all"?



Attached is the the output of

$ ./configure --help


and it shows that wxWidgets subversion head still supports

--with-gnomeprint
--with-gtkprint'

and that perhaps they are default settings.  This subversion head would 
correspond more
with 2.9.5 than with 2.9.4.

So the package maintainer must have added the without option.



> My guess is other Debian based distros will soon
> follow suit so this is just the tip of the iceberg.  I propose we change:
> 
> #if defined( __WXGTK__ )
> #   if !wxUSE_LIBGNOMEPRINT && !wxUSE_GTKPRINT && !SWIG
> #   error "You must use '--with-gnomeprint' or '--with-gtkprint' in
> your wx library configuration."
> #   endif
> #endif
> 
> to:
> 
> #if defined( __WXGTK__ )
> #   if !wxUSE_LIBGNOMEPRINT && !wxUSE_GTKPRINT && !SWIG
> #   warning "You must use '--with-gnomeprint' or '--with-gtkprint'
> in your wx library configuration to enable full printing capability."
> #   endif
> #endif


What you suggest is the easiest, and I support it.


The next harder solution but more flexible solution, is for folks to build 
their own wx or
at least have an option to.  With Brian's work this is not going to be 
impossibly difficult.



Dick




> 
> 
> This way you will at least be able to build KiCad even though you wont
> have full printing capability.  Is the printing situation for Linux
> using wxWidgets 2.9.4 any better?  Anybody else have any better ideas or
> thoughts on this?
> 
> Wayne
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

`configure' configures wxWidgets 2.9.5 to adapt to many kinds of systems.

Usage: ./configure [OPTION]... [VAR=VALUE]...

To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE.  See below for descriptions of some of the useful variables.

Defaults for the options are specified in brackets.

Configuration:
  -h, --help  display this help and exit
  --help=shortdisplay options specific to this package
  --help=recursivedisplay the short help of all the included packages
  -V, --version   display version information and exit
  -q, --quiet, --silent   do not print `checking ...' messages
  --cache-file=FILE   cache test results in FILE [disabled]
  -C, --config-cache  alias for `--cache-file=config.cache'
  -n, --no-create do not create output files
  --srcdir=DIRfind the sources in DIR [configure dir or `..']

Installation directories:
  --prefix=PREFIX install architecture-independent files in PREFIX
  [/usr/local]
  --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
  [PREFIX]

By default, `make install' will install all the files in
`/usr/local/bin', `/usr/local/lib' etc.  You can specify
an installation prefix other than `/usr/local' using `--prefix',
for instance `--prefix=$HOME'.

For better control, use the options below.

Fine tuning of the installation directories:
  --bindir=DIRuser executables [EPREFIX/bin]
  --sbindir=DIR   system admin executables [EPREFIX/sbin]
  --libexecdir=DIRprogram executables [EPREFIX/libexec]
  --sysconfdir=DIRread-only single-machine data [PREFIX/etc]
  --sharedstatedir=DIRmodifiable architecture-independent data [PREFIX/com]
  --localstatedir=DIR modifiable single-machine data [PREFIX/var]
  --libdir=DIRobject code libraries [EPREFIX/lib]
  --includedir=DIRC header files [PREFIX/include]
  --oldincludedir=DIR C header files for non-gcc [/usr/include]
  --datarootdir=DIR   read-only arch.-independent data root [PREFIX/share]
  --datadir=DIR   read-only architecture-independent data [DATAROOTDIR]
  --infodir=DIR   info documentation [DATAROOTDIR/info]
  --localedir=DIR locale-dependent data [DATAROOTDIR/locale]
  --mandir=DIRman documentation [DATAROOTDIR/man]
  --docdir=DIRdocumentation root [DATAROOTDIR/doc/wxwidgets]
  --htmldir=DIR   html documentation [DOCDIR]
  --dvidir=DIRdvi documentation [DOCDIR]
  --pdfdir=DIRpdf documentation [DOCDIR]
  --psdir=DIR ps documentation [DOCDIR]

X features:
  --x-includes=DIRX include files are in DIR
  --x-libraries=DIR   X library files are in