Re: [Kicad-developers] WxPython scripting status

[Dick Hollenbeck]

On 11/09/2013 07:53 AM, Vesa Solonen wrote:
> Hi,
> 
> What's the plan with WxPython scripting? The cmake build system doesn't
> seem to cope with missing WxPython dependency at the moment on Ubuntu
> 13.10 at least. Missing WxPython.h is the culprit later during the build
> process with -DKICAD_SCRIPTING_WXPYTHON=ON.

Hi Vesa,

See here:

  http://packages.ubuntu.com/saucy/libwxgtk2.8-dev

This package above, which is an existing prerequisite, gets installed, and 
depends on
wx2.8-headers which should therefore get installed, and it includes wxPython.h. 
 So it
should be fine.  See if package wx2.8-headers is installed please.


$ dpkg -l | grep wx2.8-headers
ii wx2.8-headers 2.8.12.1-6ubuntu2 wxWidgets Cross-platform C++ GUI toolkit 
(header files)




> 
> The rest of the flags (working combination):
> 
> -DKICAD_SCRIPTING_MODULES=ON
> -DUSE_FP_LIB_TABLE=ON
> -DBUILD_GITHUB_PLUGIN=ON
> -DCMAKE_BUILD_TYPE=RELEASE
> 
> As soon as the scripting build is reliably working, scripting support
> would be a good addition to kicad-install.sh -script.
> 
> -Vesa
> 
> ___
> 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] Cairo rendering backend

[Maciej Sumiński]

On 11/08/2013 11:48 PM, "Torsten Hüter" wrote:

Hi Orson,
have a look here:
http://bazaar.launchpad.net/~kicad-testing-committers/kicad/kicad-gal/view/head:/gal/wxdc/wxdc_gal.cpp
With my test examples it was faster than Cairo. I guess it should be
possible to reach the same performance like the old drawing routines.
Downside is the missing transparency and that wxDC drawing is deprecated.
Bye,
Torsten


I would rather stick to Cairo in such case, as disabling transparency 
probably would give a huge speed up and adapting the wxDC backend to the 
current GAL interface could take some time.


Regards,
Orson


Hi Torsten,

To tell the truth, I must have missed the source code for wxDC backend.
Maybe it is worth a try, but probably now it would have to be adapted to
the changes introduced to GAL. If you have a more or less working
version, maybe you can compare performance of both backends?


___
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] Ratsnest for the GAL

[Maciej Sumiński]

On 11/08/2013 03:24 PM, Dick Hollenbeck wrote:

On 10/16/2013 03:19 PM, Dick Hollenbeck wrote:

On 10/16/2013 09:32 AM, Maciej Sumiński wrote:

On 10/16/2013 02:59 PM, Dick Hollenbeck wrote:


On Oct 16, 2013 7:53 AM, "Dick Hollenbeck" mailto:d...@softplc.com>> wrote:
  >
  > Looks promising, and super job on the presentation.
  >
  > Once you have it working, give some thought to using a special
purpose allocator for the elements of your container.   A memory pool
scheme, anchored on the container, might pay dividends if it removes the
size test for element allocations.  If you want the pool anchored on the
container, then overloading operator new is not best, but rather have a
container function do the allocations of its elements (from a pool it
owns.)

Invariably
this means having an "in place" new operator for the element, not a
normal new operator overload.

Such anchoring of pool in container is a separate decision from deciding
to use a fixed block allocator at all.  The fixed block allocator will
be worth it regardless of where the pool lives.  If you have to move
elements from one container to another, then anchoring the pool on the
container is not appropriate.  But you could then have a class that held
all your containers and a pool common to those containers.  I bring this
up because when instantiating hundreds of thousands of elements, memory
heap calls can be the bottleneck.


Thanks for the suggestion - I like the idea. I have briefly read the
boost::pool project page and initially it seems to be an easy solution
to the problem.



That is likely to be a *very* fast solution.  But keep in mind that if you are 
going to
delete the pool, since it is anchored in your ratsnest class, then you really 
don't need
element deletion, i.e. operator delete () on the container element.

This let's you trancend into *very very* fast, if you use it to your advantage. 
 The
problem with supporting pool::free( node ) is that it often requires that a 
pointer to the
big block from which the smaller fixed size block came be saved in the smaller 
block.
There may be other ways, look into this.  This additional pointer, if present,  
is
unnecessary if you don't worry about delete node, since the pool is going to be 
deleted
anyways.  The pointer is a way to figure out which big block to add the small 
fixed block
back into upon a free.  It is overhead you don't need.

Just saving that one pointer can be a big deal.  If the boost scheme is doing 
this, or if
its allocation function uses more than about 3 lines of code, then it may not 
be optimal.

Also, if your algorithm can work with pointers to the node, where moving nodes 
from one
container to another is really a matter of moving pointers, you will also pick 
up some speed.

What I envision is that when the pool would be inclined to return NULL, meaning 
the
current big block is exhausted, that it allocate another big block and then put 
that big
block onto a linked list of big blocks, singly linked is good enough.  After 
that, it puts
each small block within the big block onto another singly linked list, called a 
freelist.
  Each of the lists are held in the pool anchor.  The anchor destructor frees 
all the big
blocks.

operator delete () can be a dummy for the node element, I assume you will need 
one since
the container destructor may be calling it, and this happens before the pool 
destructor
hopefully.



  Especially that nodes are very likely going to be POD

structures with fixed size.
I guess it is already included in C++11 as the emplace() function that
is available for many std containers.



Orson,


You reminded me of a couple of things:

a) regardless of whether in place new() is used or not, if the objects have 
std::string or
wxString, the objects will need destruction to free up their string internals.  
The
objects very well may need a ~destructor().


I am almost sure that structures that describe nodes and connections are 
not going to contain strings. It will be rather a small simple POD, so 
it should perfectly fit memory pool scheme.



b) emplace() is a modern way of doing old school memory block management with 
in place
new().  Real time C++ programmers have been using in place new for awhile.  
emplace() is
an opportunity to use a stock container, but has been limited to C++11.  But 
boost, in it
effort to bring early functionality even to *C++03*, has emplace() support on


boost::container::vector

*and*

boost::container::deque


So for a minimal lines of code implementation of what I was talking about 
above, a person
could simply put a boost::container::deque into your ratsnest class and 
allocate objects
quickly from there, simply by adding them to the deque with emplace(), and 
returning a
pointer to the back().  This is minimal lines of code and I doubt there's a 
faster way,
especically with so few lines of code.


http://www.boost.org/doc/libs/1_48_0/doc/html/container/move_emplace.html#container.move_emplace.emplace

Re: [Kicad-developers] github roll-out plans

[Dick Hollenbeck]

We should not be surprised that SEO expertise plays a role in the life of a 
kicad user also.

There's much to learn here, even as encouraging as Brian's posting is.

And believe me, I am very encouraged and relieved.  Just hungry for more 
knowledge.






Sent from my Galaxy S®III

 Original message 
From: Brian Sidebotham  
Date: 11/09/2013  6:03 AM  (GMT-06:00) 
To: Dick Hollenbeck  
Cc: Carl Poirier ,KiCad Developers 
 
Subject: Re: [Kicad-developers] github roll-out plans 
 
Search for valvers-pcb

Fifth result is the github repository I setup as a test when the Github plugin 
was coming to fruition. So I think github indexing works fine for personal 
repo's.

The key is to get something searchable that is reasonably unique. Everything 
before this is old stuff that I must tidy up.

Searching for kicad_mod tyco multilock also returns the correct result (Top 
answer this time as it's so specific) so there's mileage in Google in being the 
library browser of choice.

Best Regards,

Brian.


On 9 November 2013 04:31, Dick Hollenbeck  wrote:
On 11/08/2013 03:51 PM, Carl Poirier wrote:
> I meant get something out of Google. Without waiting for 10 months.


Its possible there's simply a delay.  But here's another theory:


What if google's policy is to *not ever* index personal github repos, on the 
theory it is
too much, too fleeting, and that a personal repo is often a fork of a project 
repo?  Then
you will wait forever.  There are about 2 million repos on github.

Isn't a "project" repo, on the other hand, one that is registered with github 
as a project?

I am wondering if they only index project repos as a policy decision.  It would 
make sense
to me.



>
> Search for "github kicad 
> Resistor_SMD2010_ReflowWave_RevA_Date21Jun2010.kicad_mod", you'll
> see it doesn't get you anything,
>
>
> On Fri, Nov 8, 2013 at 3:49 PM, Dick Hollenbeck  > wrote:
>
>     At github there are personal repos and project repos.  If I google for
>
>     "github kicad base_screen.cpp"
>
>     I find the file base_screen.cpp, which is from a 10 month old copy of our 
> launchpad repo
>     lodged in a *project* repo.
>
>
>     There is hope, don't know if its the personal vs. project repo that 
> factors into the
>     google policy or not.
>
>     BTW, here are the mug shots of the project owners:
>
>     https://github.com/KiCAD?tab=members
>
>     All two of them.
>
>     Thanks for your time Carl.  You will be hearing a lot more of that from 
> others in the near
>     future.
>
>
>
>
>
>
>     >
>     > I'm experimenting with Google Search and for now the GitHub repos under 
> my name
>     don't seem
>     > to get indexed at all. I've searched in many different ways, including 
> the most obvious
>     > ones. I'll see how we can get something out of it.
>     >
>     >
>     > On Fri, Nov 8, 2013 at 11:58 AM, Dick Hollenbeck      
>     > >> wrote:
>     >
>     >     Switching from openssl thread to a new one:
>     >
>     >
>     >     >
>     >     > With GITHUB_PLUGIN now available to ~ 90% of the KiCad user base 
> (omitting
>     OSX?), I now
>     >     > look forward to folks putting footprint libraries on github and 
> bragging about
>     them,
>     >     under
>     >     > the leadership of Carl Poirier, who has scripts and know how on 
> how to publish
>     them so
>     >     > that they can be "installed" by a single copy and paste through a 
> webbrowser
>     into the
>     >     > fp-lib-table editor.
>     >     >
>     >     > I look forward to that affecting my productivity in a positive 
> way, so that I
>     can spend
>     >     > less time looking for footprints, and more time making boards.
>     >     >
>     >     > I would look forward to collaboration on sharing the "pretty on 
> github
>     publishing" know
>     >     > how on kicad-pcb.org  
>  in the form
>     of documentation, and a link
>     >     to that write up making it
>     >     > to the kicad-user mailing list.  Because I think this would spur 
> more sharing,
>     and yet
>     >     > again help my productivity in making boards.
>     >     >
>     >     > Question: does google index any of the github content, or is it 
> simply too
>     much?  If
>     >     yes,
>     >     > then this is yet another way to find KiCad specific footprints 
> rapidly after this
>     >     > publishing gets some legs.  You should be able to google for
>     >     >
>     >     >    kicad_mod 
>     >     >
>     >     > and turn up something.
>     >     >
>     >
>     >
>     >     I think it would be great if we could gather up some prizes (cash, 
> goodies) of
>     some kind,
>     >     and award them to a "best footprint library maintainer" every six 
> months or so.
>     >
>     >     OK, it's out there, now I hope the community can run with this 
> stuff, OK !?

[Kicad-developers] WxPython scripting status

[Vesa Solonen]

Hi,

What's the plan with WxPython scripting? The cmake build system doesn't
seem to cope with missing WxPython dependency at the moment on Ubuntu
13.10 at least. Missing WxPython.h is the culprit later during the build
process with -DKICAD_SCRIPTING_WXPYTHON=ON.

The rest of the flags (working combination):

-DKICAD_SCRIPTING_MODULES=ON
-DUSE_FP_LIB_TABLE=ON
-DBUILD_GITHUB_PLUGIN=ON
-DCMAKE_BUILD_TYPE=RELEASE

As soon as the scripting build is reliably working, scripting support
would be a good addition to kicad-install.sh -script.

-Vesa

___
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 roll-out plans

[Brian Sidebotham]

Search for valvers-pcb

Fifth result is the github repository I setup as a test when the Github
plugin was coming to fruition. So I think github indexing works fine for
personal repo's.

The key is to get something searchable that is reasonably unique.
Everything before this is old stuff that I must tidy up.

Searching for kicad_mod tyco multilock also returns the correct result (Top
answer this time as it's so specific) so there's mileage in Google in being
the library browser of choice.

Best Regards,

Brian.


On 9 November 2013 04:31, Dick Hollenbeck  wrote:

> On 11/08/2013 03:51 PM, Carl Poirier wrote:
> > I meant get something out of Google. Without waiting for 10 months.
>
>
> Its possible there's simply a delay.  But here's another theory:
>
>
> What if google's policy is to *not ever* index personal github repos, on
> the theory it is
> too much, too fleeting, and that a personal repo is often a fork of a
> project repo?  Then
> you will wait forever.  There are about 2 million repos on github.
>
> Isn't a "project" repo, on the other hand, one that is registered with
> github as a project?
>
> I am wondering if they only index project repos as a policy decision.  It
> would make sense
> to me.
>
>
>
> >
> > Search for "github kicad
> Resistor_SMD2010_ReflowWave_RevA_Date21Jun2010.kicad_mod", you'll
> > see it doesn't get you anything,
> >
> >
> > On Fri, Nov 8, 2013 at 3:49 PM, Dick Hollenbeck  > > wrote:
> >
> > At github there are personal repos and project repos.  If I google
> for
> >
> > "github kicad base_screen.cpp"
> >
> > I find the file base_screen.cpp, which is from a 10 month old copy
> of our launchpad repo
> > lodged in a *project* repo.
> >
> >
> > There is hope, don't know if its the personal vs. project repo that
> factors into the
> > google policy or not.
> >
> > BTW, here are the mug shots of the project owners:
> >
> > https://github.com/KiCAD?tab=members
> >
> > All two of them.
> >
> > Thanks for your time Carl.  You will be hearing a lot more of that
> from others in the near
> > future.
> >
> >
> >
> >
> >
> >
> > >
> > > I'm experimenting with Google Search and for now the GitHub repos
> under my name
> > don't seem
> > > to get indexed at all. I've searched in many different ways,
> including the most obvious
> > > ones. I'll see how we can get something out of it.
> > >
> > >
> > > On Fri, Nov 8, 2013 at 11:58 AM, Dick Hollenbeck  > 
> > > >> wrote:
> > >
> > > Switching from openssl thread to a new one:
> > >
> > >
> > > >
> > > > With GITHUB_PLUGIN now available to ~ 90% of the KiCad user
> base (omitting
> > OSX?), I now
> > > > look forward to folks putting footprint libraries on github
> and bragging about
> > them,
> > > under
> > > > the leadership of Carl Poirier, who has scripts and know how
> on how to publish
> > them so
> > > > that they can be "installed" by a single copy and paste
> through a webbrowser
> > into the
> > > > fp-lib-table editor.
> > > >
> > > > I look forward to that affecting my productivity in a
> positive way, so that I
> > can spend
> > > > less time looking for footprints, and more time making
> boards.
> > > >
> > > > I would look forward to collaboration on sharing the "pretty
> on github
> > publishing" know
> > > > how on kicad-pcb.org  <
> http://kicad-pcb.org> in the form
> > of documentation, and a link
> > > to that write up making it
> > > > to the kicad-user mailing list.  Because I think this would
> spur more sharing,
> > and yet
> > > > again help my productivity in making boards.
> > > >
> > > > Question: does google index any of the github content, or is
> it simply too
> > much?  If
> > > yes,
> > > > then this is yet another way to find KiCad specific
> footprints rapidly after this
> > > > publishing gets some legs.  You should be able to google for
> > > >
> > > >kicad_mod 
> > > >
> > > > and turn up something.
> > > >
> > >
> > >
> > > I think it would be great if we could gather up some prizes
> (cash, goodies) of
> > some kind,
> > > and award them to a "best footprint library maintainer" every
> six months or so.
> > >
> > > OK, it's out there, now I hope the community can run with this
> stuff, OK !?
> > >
> > > (I've got programming work and board work to do.  No time for
> library
> > management, and I
> > > don't have the expertise either.)
> > >
> > >
> > >
> > > ___
> > > Mailing list: https://launchpad.ne