Re: [Kicad-developers] GitHub Plugin (my nemesis)

[Miguel Angel Ajo Pelayo]

I'd try to start with the simpler structure of having all the libraries as
subdirectories of the same git repo.

That doesn't mean that we could eventually add support for submodules, (for
anyone that wants to make use of it)...

But I agree that from the point of view of the librarians it's a mess to
have everything so scattered.


On Thu, Sep 28, 2017 at 1:29 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:

> Simon, David,
>
> Thanks for the synopsis of your idea David, there are certainly some
> advantages to using the submodule approach.
>
> Is it github compatible?
>
>
> Simon, yes git-submodule is compatible with github. I have a test
> repository here - https://github.com/kicad/kicad-footprints - this
> contains a submodule for each of the current footprint directories.
>
> Does it simplify the maintenance of the kicad library by the librarians?
>
>
> Compared to having all the .pretty folders as subdirectories of a single
> repo, no. Reorganising libraries or adding new ones is tedious, and for
> each of the 100+ .pretty repos, we (the librarians) have to manage:
>
> * Pull requests and isues
> * CI tools (e.g. Travis KLC scripts)
> * Updating each library when new requirements are enacted (e.g. KLC)
> * Ensure that changes in one repo do not conflict with a different repo
> * Handle reclassification or moving of footprints between repos
>
> It is also quite possible for submodules to become out of sync. The link
> that Simon posted has some a good example of how this can occur (detached
> head). I have some projects at work that contain about 5 submodules and it
> rapidly becomes difficult to deal with even for a competent user of Git.
>
> It becomes harder for users, too. KiCad users cannot, in the general case,
> be classified as competent users of git. Currently, users who wish to
> contribute to the footprint libraries have a hard time. For each library
> they want to contribute to, they have to fork and manage another
> repository. Personally I have done this for 50 separate repositories.
>
> Further, once changes are made to each submodule, the master repository
> then needs to be updated otherwise it's not up to date with the latest
> changes. Perhaps we can use git hooks here, but this is just further
> complication!
>
> Let's also consider consistency. The footprint libraries are (currently)
> split into separate repos. However the symbol libraries and 3d model
> libraries are not. Should we split them too? Now we have 300+ repositories
> to manage.
>
> Let's not make this an academic problem and say "but it's possible to
> manage with this complex set of tools"! From the perspective of a
> contributor, and as the person who has to manage the libraries, the simpler
> the better.
>
> Oliver
>
>
>
> On Thu, Sep 28, 2017 at 7:25 PM, Simon Küppers 
> wrote:
>
>> Thanks for your detailed description. I think it is a nice way to go.
>> However two remarks:
>> Does it simplify the maintenance of the kicad library by the librarians?
>> Is it github compatible? If not, we would need to find another platform to
>> host the libraries.
>>
>> If I look for git submodule, there is a lot of different opinions on why
>> you should or should not use it. (e.g. https://www.google.de/amp/s/co
>> dingkilledthecat.wordpress.com/2012/04/28/why-your-company-
>> shouldnt-use-git-submodules/amp/). Does it apply in our case? What about
>> git subtree?
>>
>> Best regards
>> Simon
>>
>> Am 28. September 2017 02:37:09 MESZ schrieb David Godfrey <
>> i...@sbts.com.au>:
>>
>>> Hi All
>>>
>>> I have to agree with some of the other posters, why not use git as it
>>> was intended?
>>>
>>> Specifically I think the following makes sense.
>>>
>>> - Keep the multiple repositories, this helps when a company only wants
>>> to make certain sets of libs available to it's staff
>>>
>>> - Have a master repository that includes all other repositories as
>>> submodules.
>>>
>>> - Have branches that are matched to kicad versions. This allows
>>> footprint changes in a version safe way.
>>>
>>> - Use standard "git clone" (initial download) and "git pull" (update) on
>>> the main repo which provides the entire set of available libs without
>>> actually downloading the content for all libs.
>>>
>>> - When a specific lib is needed, do similar to what we do now, and use
>>> "git submodule update --init --recursive $submoduleName" to just pull
>>> that specific submodule
>>>
>>> - Allow the "main" library repo URI to be altered. This enables a
>>> companies fork of the repo to be used.
>>>
>>> - Allow the "main" library repo URI to be ANY valid git URI. That means
>>> a repo on a local fileserver rather than a http server can be used.
>>> Along with various security options etc.
>>>
>>> - Add a fairly simple scripted tool that's run "on release" to retrieve
>>> a README.md (an possibly a descriptor/index file) from each actual
>>> library repo and update those within the "main" repo. This removes the

Re: [Kicad-developers] GitHub Plugin (my nemesis)

[Miguel Angel Ajo Pelayo]

I believe it's better if each library type has a single directory on the
top of the libraries repo, in a single branch.

That would let you have branches like

master
stable/4
stable/5
stable/6 later on,

and point the specific versions of kicad to such branches, in a way that an
old version of kicad would not explode if new features appear in libraries
in a later version.


In that way, it's very easy to backport a change if the library is still
backwards-compatible

git checkout stable/4
git cherry-pick 
git push



On Fri, Sep 22, 2017 at 11:05 AM, Miguel Angel Ajo Pelayo <
majop...@redhat.com> wrote:

> Please don't use branches for that.
>
> Branches are to track separate development efforts or release
> cycles/stabilization.
>
> Using branches, while it's possible was not the intent when git was
> designed.
>
> If you do it that way, then you won't be able to use branches to track
> libraries in different stabilization phases, etc.
>
>
>
>
> On Fri, Sep 22, 2017 at 10:51 AM, Bastian Neumannn <
> neumann.bast...@gmail.com> wrote:
>
>> I really like the idea of having one repo with all the .pretty folders in
>> different branches. The master can have meta data about the branches.
>>
>> That also gives the ability to manage library downloads as you can
>> download the branch as a zip.
>>
>> Using git for library management is ideally implemented as a plugin. With
>> the ability to define own repositories as well. The library downloader can
>> fetch the branch list and present a  selection to the user to fetch
>> whatever the user want to fetch.
>>
>> zip files of the branches can be mirrored on other servers as well for
>> the people not having access to github.
>>
>> Cheers,
>> Basti
>>
>> 2017-09-22 10:39 GMT+02:00 Simon Küppers <simon.kuepp...@rub.de>:
>>
>>> And by the way, this would be a feature that is completely new to the
>>> market (correct me if I'm wrong). Git integration into eda software.
>>> I only know of altium that has an svn interface and a proprietary vault.
>>> The features both of which could be (at some point) realized using git.
>>> Innovation is fun :-)
>>>
>>> The idea of modifying a footprint from the standard lib, and generating
>>> a patch that could be directly send to the maintainers (maybe using the
>>> very new library website) would make contributing very easy!
>>>
>>> Am 22. September 2017 10:13:49 MESZ schrieb Ingo Kletti <
>>> ikle...@htwg-konstanz.de>:
>>>
>>>> Hi,
>>>>
>>>> Am 22.09.2017 um 09:44 schrieb Oliver Walters:
>>>>
>>>>>  [...] svn has the advantage of being able to
>>>>>  pull selective directories from GitHub. You could present the user with a
>>>>>  list of which libraries they actually want to pull down
>>>>>
>>>>
>>>> So, just like JS (@tiger12506) I'm excited any time the git integration
>>>> comes up for discussion.
>>>>
>>>> While I understand the initial focus on Github, it's just like Simon 
>>>> stated:
>>>>
>>>>  Why not just ask the user for a working directory and pull the
>>>>>  libraries there using actual git?
>>>>>  This has the obvious advantage, that anyone can use this not only
>>>>>
>>>> with > github but also with his or her own local repository..
>>>>
>>>> Without in-depth knowledge about git vs. git-plugin vs. svn:
>>>>
>>>> Will it be possible to use another repository besides Github?
>>>>
>>>> In our case, we require our students to maintain their project on a
>>>> Gitlab server. This server also hosts the KiCad libraries that were
>>>> created for internal purposes. ATM, it's not possible to just pull the
>>>> latest version of the internal KiCad libraries from inside KiCad
>>>>
>>>> And it might not just be us. I think having a proper git integration
>>>> could ease the library handling of many users.
>>>>
>>>> In the end, a proper git and/or svn integration would also open the
>>>> possibility to directly handle version management of KiCad projects from
>>>> inside KiCad.
>>>>
>>>> Regards,
>>>>
>>>> Ingo
>>>>
>>>> --
>>>>
>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>> Post to : kicad-developers@lists.launchpa

Re: [Kicad-developers] GitHub Plugin (my nemesis)

[Miguel Angel Ajo Pelayo]

Please don't use branches for that.

Branches are to track separate development efforts or release
cycles/stabilization.

Using branches, while it's possible was not the intent when git was
designed.

If you do it that way, then you won't be able to use branches to track
libraries in different stabilization phases, etc.




On Fri, Sep 22, 2017 at 10:51 AM, Bastian Neumannn <
neumann.bast...@gmail.com> wrote:

> I really like the idea of having one repo with all the .pretty folders in
> different branches. The master can have meta data about the branches.
>
> That also gives the ability to manage library downloads as you can
> download the branch as a zip.
>
> Using git for library management is ideally implemented as a plugin. With
> the ability to define own repositories as well. The library downloader can
> fetch the branch list and present a  selection to the user to fetch
> whatever the user want to fetch.
>
> zip files of the branches can be mirrored on other servers as well for the
> people not having access to github.
>
> Cheers,
> Basti
>
> 2017-09-22 10:39 GMT+02:00 Simon Küppers :
>
>> And by the way, this would be a feature that is completely new to the
>> market (correct me if I'm wrong). Git integration into eda software.
>> I only know of altium that has an svn interface and a proprietary vault.
>> The features both of which could be (at some point) realized using git.
>> Innovation is fun :-)
>>
>> The idea of modifying a footprint from the standard lib, and generating a
>> patch that could be directly send to the maintainers (maybe using the very
>> new library website) would make contributing very easy!
>>
>> Am 22. September 2017 10:13:49 MESZ schrieb Ingo Kletti <
>> ikle...@htwg-konstanz.de>:
>>
>>> Hi,
>>>
>>> Am 22.09.2017 um 09:44 schrieb Oliver Walters:
>>>
  [...] svn has the advantage of being able to
  pull selective directories from GitHub. You could present the user with a
  list of which libraries they actually want to pull down

>>>
>>> So, just like JS (@tiger12506) I'm excited any time the git integration
>>> comes up for discussion.
>>>
>>> While I understand the initial focus on Github, it's just like Simon stated:
>>>
>>>  Why not just ask the user for a working directory and pull the
  libraries there using actual git?
  This has the obvious advantage, that anyone can use this not only

>>> with > github but also with his or her own local repository..
>>>
>>> Without in-depth knowledge about git vs. git-plugin vs. svn:
>>>
>>> Will it be possible to use another repository besides Github?
>>>
>>> In our case, we require our students to maintain their project on a
>>> Gitlab server. This server also hosts the KiCad libraries that were
>>> created for internal purposes. ATM, it's not possible to just pull the
>>> latest version of the internal KiCad libraries from inside KiCad
>>>
>>> And it might not just be us. I think having a proper git integration
>>> could ease the library handling of many users.
>>>
>>> In the end, a proper git and/or svn integration would also open the
>>> possibility to directly handle version management of KiCad projects from
>>> inside KiCad.
>>>
>>> Regards,
>>>
>>> Ingo
>>>
>>> --
>>>
>>> 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
>
>
___
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 (my nemesis)

[Miguel Angel Ajo Pelayo]

My two cents (take with a grain of salt since I can't commit to it):
https://libgit2.github.com/docs/guides/101-samples/

Having the plugin use the libgit2 library would be great, even people could
get incremental updates via git, or even send patches/pull requests if they
wanted...



On Fri, Sep 22, 2017 at 10:03 AM, Maciej Sumiński 
wrote:

> Hi Oliver,
>
> IMHO, the library-download tool is the best choice here. I agree the
> live download is not a good idea in many cases, but I imagine there are
> people taking advantage of that (e.g. a centralized footprint repository
> in a small company).
>
> I think the main problem now, is we are relying too much on the Github
> API, instead of using e.g. libgit2 [1]. Such library is not only more
> flexible but also frees us from the Github. Even though it might
> impossible to download a .zip file of a whole repository, there should
> be an option to select single files to be downloaded or quickly list
> directories. Apart from that, updates will be much faster, as you do not
> need to download everything, but only deltas.
>
> I am sure the downloader could be also implemented in Python and
> integrated with pcbnew. IIRC all nightly builds are build with Python
> scripting emabled, and I am not aware of any problems related to
> compiling such version manually.
>
> Regards,
> Orson
>
> 1. https://github.com/libgit2/libgit2
>
> On 09/22/2017 03:21 AM, Oliver Walters wrote:
> > Hi all,
> >
> > Ok, now that the website integration with the libraries is (pretty much)
> > done, and the licensing issue seems to be sorted, there is one final
> puzzle
> > piece to solve before I'm happy with the state of the libraries for a v5
> > release.
> >
> > *Goal: *Merge all footprint library repositories into a single repo to
> > solve the ongoing dramas of maintaining 100+ repos.
> >
> > *Problem*: The *only* thing standing in the way of just doing this is
> that
> > some users like the GitHub plugin and previous instruction is that this
> > functionality cannot be removed.
> >
> > The GitHub plugin functions by downloading a .zip file of a .pretty repo.
> > If we merge all footprint libs into a single repo with multiple
> > subdirectories, this will not work anymore (as GitHub dosen't allow you
> to
> > download a .zip of a single subdirectory).
> >
> > Merging the repos is the *right thing to do*. But how to proceed?
> >
> > *Options:*
> >
> > *a) Drop github plugin feature, replace with library-download tool*
> >
> > I don't think it is a good idea to live-load library data from GitHub (a
> > lot of other users agree too). It's slow, and a waste of bandwidth to
> > re-download the libs all the time.
> >
> > We drop support for loading libraries direct from GitHub. However, we
> add a
> > tool for downloading libraries from GitHub and storing to disk. Users can
> > update as they like. This can be integrated in KiCad and new users can
> run
> > this tool when they first install KICad. This means that no libs need to
> > distributed with the installer and users can update to latest libs
> whenever
> > they want.
> >
> > *b) Improve github plugin to allow subdirectory traversal*
> >
> > This is difficult and will only result in the plugin being slower. There
> > are two ways I can see to do this:
> >
> > i. Use Git API - tools exist that use this functionality -
> > https://github.com/KinoLien/gitzip
> > ii. Use subversion - GitHub actually provides subversion API -
> > https://www.seanw.org/blog/download-git-repo-subdirectory/
> >
> >
> > *Subversion*
> >
> > In either case, I think that using the subversion tool to partially
> > download the libraries would be a good approach (I assume quicker than
> > using wget and the GitHub API).
> >
> > 1. Does anyone have any experience using the C API for SVN?
> > 2. The Python bindings are pretty good - https://pypi.python.org/pypi/
> svn -
> > and much easier to use. However, can we make the library download tools
> > dependent on enabling the python plugin?
> > 3. Is there a way to checkout a subversion remote to memory (to replicate
> > the functionality of the current GitHub plugin)? If not, I'm not sure how
> > to approach option b) above.
> >
> >
> > Feedback appreciated. I think that it is very important especially for
> new
> > users that this is improved. The GitHub plugin is constantly causing
> > headaches!
> >
> > Cheers,
> > Oliver
> >
> >
> >
> > ___
> > 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] disable icons in menus by default on osx

[Miguel Angel Ajo Pelayo]

I personally (as a user) find the icons visually more intuitive. Specially
for newcomers and better adoption of KiCad.

I know it's out of some guidelines, but this is a very complex software.

My feeling is that it's better with a "on" by default setting, as long as
people already used to the software, or not liking icons could disable them.

On Thu, Sep 7, 2017 at 4:34 PM, Michael Kavanagh  wrote:

> Hi,
>
> Sorry to bring this up again, but for me icons are still enabled by
> default on macOS (and Windows unsurprisingly). I deleted
> /Library/Application Support/kicad, ~/Library/Preferences/kicad and
> /Applications/Kicad, reinstalled from most recent nightly (07-Sep-2017)
> and the icons were there upon startup.
>
> I think the problem was the default value was true when the key wasn't
> found (ie for new install), see http://docs.wxwidgets.org/
> trunk/classwx_config_base.html#a93b700301e0b73f1b42f14497f2e6bc7
>
> I have attached a patch to turn icons off by default on all platforms
> (doing away with "ugly" #if defined()/#endif). I think this would be
> preferable as per both the macOS and Windows guidelines. I am
> unfamiliar with Linux UI's but if Linux users want the icons enabled by
> default the #if will have to be added again.
>
> Cheers,
> Michael
>
>
> On 13 April 2017 at 18:51, Wayne Stambaugh  wrote:
>
>> Simon,
>>
>> I committed your patch since osx expects the icons to be disabled by
>> default.
>>
>> Thanks,
>>
>> Wayne
>>
>> On 4/8/2017 6:42 AM, Simon Wells wrote:
>> > Please see attached patch to disable icons in the menus by default on
>> osx
>> >
>> >
>> >
>> > ___
>> > 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
>
>
___
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] did something happened?

[Miguel Angel Ajo Pelayo]

May be people moved to the discourse forum?, :)

On Jun 1, 2017 17:38, "Fabrizio Tappero"  wrote:

> hi guys,
> I am experiencing a very low email traffic in this mailing list. Did
> something happened?
>
> 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] [PATCH] Footprint Wizards Update

[Miguel Angel Ajo Pelayo]

On Tue, Jan 3, 2017 at 5:07 PM, Miguel Angel Ajo Pelayo <majop...@redhat.com
> wrote:

> I would add some sort of message if an old footprint is being loaded.
>

footprint -> footprint wiard

>
> For example, by detecting the import error, or lookup to the old class
> name,
> it would trigger a message box pointing to the specific plugin that failed
> to load, and a link to the instructions to fix it.
>
> But that could be a follow up on this patch.
>
> On Tue, Jan 3, 2017 at 4:30 PM, Wayne Stambaugh <stambau...@gmail.com>
> wrote:
>
>> On 1/3/2017 10:08 AM, jp charras wrote:
>> > Le 03/01/2017 à 15:30, jp charras a écrit :
>> >> Le 03/01/2017 à 14:03, Miguel Angel Ajo Pelayo a écrit :
>> >>> Sorry, I just found the email. Sorry for my delayed answer.
>> >>>
>> >>> The code looks good to me, I believe it's a good change, it's not
>> backwards compatible with the
>> >>> older footprint wizards, but the changes to make them compatible seem
>> simple enough, and well
>> >>> documented.
>> >>>
>> >>>
>> >>> If I had comments to make, it'd be why are we using uInteger, uEtc
>> for parameter types.
>> >>>
>> >>> Could we use the python convention to have constants in upcase, and
>> may be se
>> >>>
>> >>> INTEGER_PARAM,  ETC_PARAM on the python side ?
>> >>>
>> >>> this is more nitpicking than anything.
>> >>>
>> >>>
>> >>> Nice work.
>> >>
>> >> I agree, and I am willing to commit this change (the API is better),
>> but because it breaks the
>> >> compatibility (yes, the changes to make old wizards compatible is
>> simple and documented) I need the
>> >> Wayne's opinion before committing the changes.
>> >>
>> >> Attached a patch against the lastest kicad version (the initial patch
>> is not applicable to the
>> >> current kicad version).
>> >>
>> >
>> > My previous patch is perhaps missing some changes. Here is the full
>> patch.
>>
>> It looks fine to me except for some coding policy issues ( missing
>> spaces between ( and ) and some trailing white space).  The only issue I
>> see is anyone using the python code in custom scripts may not be very
>> happy about the changes.  It would be nice to hear from the original
>> author about the changes.  If no one has any serious objections, then
>> feel free to commit the patch.
>>
>> Cheers,
>>
>> 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
>>
>
>
___
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] Footprint Wizards Update

[Miguel Angel Ajo Pelayo]

I would add some sort of message if an old footprint is being loaded.

For example, by detecting the import error, or lookup to the old class name,
it would trigger a message box pointing to the specific plugin that failed
to load, and a link to the instructions to fix it.

But that could be a follow up on this patch.

On Tue, Jan 3, 2017 at 4:30 PM, Wayne Stambaugh <stambau...@gmail.com>
wrote:

> On 1/3/2017 10:08 AM, jp charras wrote:
> > Le 03/01/2017 à 15:30, jp charras a écrit :
> >> Le 03/01/2017 à 14:03, Miguel Angel Ajo Pelayo a écrit :
> >>> Sorry, I just found the email. Sorry for my delayed answer.
> >>>
> >>> The code looks good to me, I believe it's a good change, it's not
> backwards compatible with the
> >>> older footprint wizards, but the changes to make them compatible seem
> simple enough, and well
> >>> documented.
> >>>
> >>>
> >>> If I had comments to make, it'd be why are we using uInteger, uEtc for
> parameter types.
> >>>
> >>> Could we use the python convention to have constants in upcase, and
> may be se
> >>>
> >>> INTEGER_PARAM,  ETC_PARAM on the python side ?
> >>>
> >>> this is more nitpicking than anything.
> >>>
> >>>
> >>> Nice work.
> >>
> >> I agree, and I am willing to commit this change (the API is better),
> but because it breaks the
> >> compatibility (yes, the changes to make old wizards compatible is
> simple and documented) I need the
> >> Wayne's opinion before committing the changes.
> >>
> >> Attached a patch against the lastest kicad version (the initial patch
> is not applicable to the
> >> current kicad version).
> >>
> >
> > My previous patch is perhaps missing some changes. Here is the full
> patch.
>
> It looks fine to me except for some coding policy issues ( missing
> spaces between ( and ) and some trailing white space).  The only issue I
> see is anyone using the python code in custom scripts may not be very
> happy about the changes.  It would be nice to hear from the original
> author about the changes.  If no one has any serious objections, then
> feel free to commit the patch.
>
> Cheers,
>
> 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
>
___
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] Footprint Wizards Update

[Miguel Angel Ajo Pelayo]

Sorry, I just found the email. Sorry for my delayed answer.

The code looks good to me, I believe it's a good change, it's not backwards
compatible with the older footprint wizards, but the changes to make them
compatible seem simple enough, and well documented.


If I had comments to make, it'd be why are we using uInteger, uEtc for
parameter types.

Could we use the python convention to have constants in upcase, and may be
se

INTEGER_PARAM,  ETC_PARAM on the python side ?

this is more nitpicking than anything.


Nice work.


On Mon, Nov 14, 2016 at 8:33 PM, jp charras  wrote:

> Le 10/10/2016 à 02:30, Oliver Walters a écrit :
> > Anyone have any comments on this? I have fixed many issues that were
> raised last time. If I can get
> > some feedback, we can progress towards merge.
> >
> > On Thu, Sep 29, 2016 at 6:18 PM, Oliver Walters <
> oliver.henry.walt...@gmail.com
> > > wrote:
> >
> > Hi All,
> >
> > I have improved upon the footprint wizards patch, taking suggestions
> into account.
> >
> > patch file attached.
> >
> > There is an in-depth discussion of the new
> > format: https://github.com/KiCad/Footprint_Wizards/wiki
> > 
> >
> > In particular, instructions on how to update old wizards to the new
> format:
> >
> > https://github.com/KiCad/Footprint_Wizards/wiki/
> Updating-Older-Wizards
> >  Updating-Older-Wizards>
> >
> > Cheers,
> >
> > Oliver
>
> Hi Oliver,
>
> Sorry for the delay.
> The patch works fine for me.
> Be patient.
>
> The only drawback for me is the fact it breaks the compatibility with old
> wizards (not blocking).
> Just a decision to take.
>
>
> --
> Jean-Pierre CHARRAS
>
> ___
> 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] SWIG binding

[Miguel Angel Ajo Pelayo]

A transition time as wayne suggests could be a reasonable thing, with
enough time,
and a proper deprecation notice users would be able to transition into a new API
(please consider looking at [1], I spent quite a long time modeling that based
on the initial work of Piers Titus van der Torren)

Let me add some notes to the discussion as author of the bindings (the
guilty one ;-) ):

  At the time when I started working on the bindings, I was only able to
recognise two options that were suitable for us, we either a) built our own
bindings manually with C, or b) we had swig, which at that time, was the
same solution that wxWidgets was using. I remember I examined other
automated binding solutions, but having wxWidgets compatibility was a
strong point, it all got discussed in the community and we weighted our
development capacity.

  Also, we had the future eventual change to python3, that may be easier
with an automated tool (I agree, I'm very optimistic sometimes)

  So we picked that path, and I made an initial version, eventually we
got wxpython support contributed, the wx console for python, etc...
around that time my contributions decreased / disappeared because I
had two wonderful daughters (one after another) and I'm still trying to
recover from that.

Around that time, we also started to recognise two things:

   a) The bindings, even if limited in scope to some objects, were troublesome
because any refactor on the objects could break external users of the API.
IMO, that's something the users must understand and accept that eventual
breaking changes will happen to the API.

   b) The bindings didn't allow users to access objects in a python-like and
easy way, all was cluttered with the creation of objects which had to be
passed around.

   c) The documentation was for the C++ side, not for Python.


So, we weighted in again the possibility of writing native bindings, but we
realised that it was easier to layer on top of swig, and do all the
heavy-lifting
of providing a consistent API in python [1].


So we had:

kicad objects <--- swig API bindings <--- kicad-python < user

If any breaking change happens in kicad objects, the kicad-python wrapper
is updated and the user doesn't need to change anything.

While the old users still had access to the swig bindings (knowing that
those could eventually break), they had the chance to pick up something
better.

Some examples here:

Docs: 
http://ci.kicad-pcb.org/view/KiCad's%20pythonic%20python%20API/job/kicad-python/ws/doc/build/html/index.html

https://github.com/KiCad/kicad-python/blob/master/kicad/pcbnew/board.py

https://github.com/KiCad/kicad-python/blob/master/tests/unit/pcbnew/test_pcbnew_board.py


Now, I'm not an active developer (for now) but, I know that you'll take wise
decisions, of course feel free to reuse that -and ask me anything you need-,
keep building on swig, or not and take any other direction. I will be happy
to see anyone stepping in to handle all this work and provide a consistent,
easy to use API for KiCad.


Best regards,
Miguel Ángel.









On Fri, Sep 16, 2016 at 8:30 PM, Wayne Stambaugh  wrote:
> On 9/16/2016 2:13 PM, Michael Steinberg wrote:
>> Hello Wayne,
>>
>>> Yet.  I'm sure they are going to have to implement it at some point.
>>> You can always write your own swig wrapper something like this:
>>> http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig
>>>
>> They had 5+ years to add support, they didn't. So I wouldn't count on it.
>>> As some of you may or may not know, the new wxpython project phoenix is
>>> using sip instead of swig so that in and of itself may put us in a
>>> position where we have to change to sip.  I would rather wait and see
>>> what shakes out with the new wxpython implementation rather than head
>>> down a path that only has to be changed yet again.
>> And another break, will we support SWIG, SIP and an interop layer?
 With this message I want to ask what is the common view whether it is
 okay to have SWIG thumbscrew the project's source code, considering
 there are alternative generators, and generatorless libraries like
 pybind11. Of those alternatives I would *personally* prefer the latter,
 as it is no black box and the binding generation is part of the normal
 c++ source code.
>>> Honestly, changing scripting language generators does not thrill me at
>>> this point in the project.  It would most likely break all of the python
>>> scripting work done thus far which would create a lot backlash.
>> It will only get worse as time is passing by building upon the current
>> state.
>>
>> I think we need
>> 1) a specified python API
>> 2) adapters that match the specified API to the source code
>> 3) Helpers to generate the necessary binding from the API adapters. This
>> can be done with the aid of libraries or manually.
>>
>> It seems none of that is currently available, the current unspecified
>> API holds the source 

Re: [Kicad-developers] Python functionality on Windows

[Miguel Angel Ajo Pelayo]

I understand the issue with dependencies.

I don’t have a windows but, has anybody tried easy_install ? 

https://pythonhosted.org/setuptools/easy_install.html 
<https://pythonhosted.org/setuptools/easy_install.html>

It’s supposed to be lighter than pip, I’m not sure if it comes with the base
python.

> On 24 Feb 2016, at 16:40, Wayne Stambaugh <stambau...@gmail.com> wrote:
> 
> On 2/24/2016 4:15 AM, Miguel Angel Ajo Pelayo wrote:
>> 
>> If it’s not hard to provide pip, IMHO one of the strengths of python is the
>> availability of lots libraries. I believe it’s ok to let the user know they 
>> will
>> need to reinstall their libraries after an update.
> 
> I'm OK with providing pip but all of the python dependencies will have
> to be added to the windows installer.  If someone wants to look at that,
> fine but I would rather we focus on KiCad rather than third Python support.
> 
> I'm OK with informing users about loosing their custom installed Python
> libraries when upgrading kicad but I can assure you there will be
> complaining.
> 
>> 
>> 
>> 
>>> On 24 Feb 2016, at 01:28, Wayne Stambaugh <stambau...@gmail.com> wrote:
>>> 
>>> On 2/23/2016 3:53 PM, Nick Østergaard wrote:
>>>> As far as I can se, we need python2w.exe, that should be easy to add.
>>>> But what I worry about is if we include pip, it might not work as
>>>> expeced for the user, beacause when he upgrades he might get into
>>>> trouble if he uninstalls kicad and then installs. The user will have
>>>> to reinstall the modules that he uses. An other thing is if kicad is
>>>> installed to %PROGRAMFILES%, then you will likely have trouble
>>>> modifying stuff there, because of the user access control. But I have
>>>> not tested this.
>>> 
>>> This was my concern.  Providing a full Python implementation is outside
>>> the scope of the project.  If someone needs this, they should install
>>> msys2 and either build kicad from source or create pacman packages.  If
>>> you don't mind, I would like to cherry pick your changes to PKGBUILD and
>>> push them to the msys2 kicad-git package repo.  I'll also create a kicad
>>> PKGBUID for the stable version of kicad using your PKGBUILD-STABLE so
>>> the msys2 project can provide both git mirror and stable version kicad
>>> packages.
>>> 
>>> Thanks,
>>> 
>>> Wayne
>>> 
>>>> 
>>>> 2016-02-23 20:32 GMT+01:00 Wayne Stambaugh <stambau...@gmail.com>:
>>>>> AFAIK kicad-winbuilder is no longer used or maintained.  KiCad is now
>>>>> built using msys2/mingw32 and msys2/mingw64 and the appropriate python
>>>>> run time requirements are installed in the same path as kicad.  Package
>>>>> devs correct me if I'm wrong but this is a partial install of the
>>>>> mingw32 or mingw64 python system containing only the run time
>>>>> requirements to use the python console and the Pcbnew Python modules and
>>>>> scripts.
>>>>> 
>>>>> If you want to maintain kicad-winbuilder, feel free to modify it any way
>>>>> you see fit but the windows installers will still continue to use msys2
>>>>> as the build environment.  We are using msys2/mingw32/64 because all of
>>>>> the dependency libraries required to build kicad are supplied by the
>>>>> msys2 project.  There is no need to build wxwidgets, boost, cairo, etc.
>>>>> from source to build kicad.
>>>>> 
>>>>> On 2/23/2016 1:51 PM, Константин Барановский wrote:
>>>>>> I'm confused. I'm not understand what is your point of view about
>>>>>> integration python to the installation of kicad on Windows. Will it
>>>>>> still done with kicad-winbuilder or you planning to separate python from
>>>>>> kicad installation and to use system-wide?
>>>>>> As I see (thank you xarx and Torsten Hüter), simplest way to include
>>>>>> full-featured python - it modify kicad-winbuilder. If you do not mind,
>>>>>> I'll try to do it.
>>>>>> 
>>>>>> Regards, Konstantin.
>>>>>> 
>>>>>> 
>>>>>> ___
>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>> Post to : kicad-developers@lists.launchpad.net
>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>

Re: [Kicad-developers] Python functionality on Windows

[Miguel Angel Ajo Pelayo]

If it’s not hard to provide pip, IMHO one of the strengths of python is the
availability of lots libraries. I believe it’s ok to let the user know they will
need to reinstall their libraries after an update.



> On 24 Feb 2016, at 01:28, Wayne Stambaugh  wrote:
> 
> On 2/23/2016 3:53 PM, Nick Østergaard wrote:
>> As far as I can se, we need python2w.exe, that should be easy to add.
>> But what I worry about is if we include pip, it might not work as
>> expeced for the user, beacause when he upgrades he might get into
>> trouble if he uninstalls kicad and then installs. The user will have
>> to reinstall the modules that he uses. An other thing is if kicad is
>> installed to %PROGRAMFILES%, then you will likely have trouble
>> modifying stuff there, because of the user access control. But I have
>> not tested this.
> 
> This was my concern.  Providing a full Python implementation is outside
> the scope of the project.  If someone needs this, they should install
> msys2 and either build kicad from source or create pacman packages.  If
> you don't mind, I would like to cherry pick your changes to PKGBUILD and
> push them to the msys2 kicad-git package repo.  I'll also create a kicad
> PKGBUID for the stable version of kicad using your PKGBUILD-STABLE so
> the msys2 project can provide both git mirror and stable version kicad
> packages.
> 
> Thanks,
> 
> Wayne
> 
>> 
>> 2016-02-23 20:32 GMT+01:00 Wayne Stambaugh :
>>> AFAIK kicad-winbuilder is no longer used or maintained.  KiCad is now
>>> built using msys2/mingw32 and msys2/mingw64 and the appropriate python
>>> run time requirements are installed in the same path as kicad.  Package
>>> devs correct me if I'm wrong but this is a partial install of the
>>> mingw32 or mingw64 python system containing only the run time
>>> requirements to use the python console and the Pcbnew Python modules and
>>> scripts.
>>> 
>>> If you want to maintain kicad-winbuilder, feel free to modify it any way
>>> you see fit but the windows installers will still continue to use msys2
>>> as the build environment.  We are using msys2/mingw32/64 because all of
>>> the dependency libraries required to build kicad are supplied by the
>>> msys2 project.  There is no need to build wxwidgets, boost, cairo, etc.
>>> from source to build kicad.
>>> 
>>> On 2/23/2016 1:51 PM, Константин Барановский wrote:
 I'm confused. I'm not understand what is your point of view about
 integration python to the installation of kicad on Windows. Will it
 still done with kicad-winbuilder or you planning to separate python from
 kicad installation and to use system-wide?
 As I see (thank you xarx and Torsten Hüter), simplest way to include
 full-featured python - it modify kicad-winbuilder. If you do not mind,
 I'll try to do it.
 
 Regards, Konstantin.
 
 
 ___
 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


___
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 in Spanish, again.

[Miguel Angel Ajo Pelayo]

Hi Inigo,

   I registered some time ago kicad.es  with that intention, 
if you want we could try ti bring it up together,
It’s a bit cumbersome to comply with all the regulations in EU currently (data 
protection registration
for the forum database of users, complying with the cookie law, etc…).

   Best regards, and .. Buen trabajo!!! ;)

Miguel Ángel,


> On 19 Feb 2016, at 08:44, i...@elektroquark.com wrote:
> 
> Hi Nick,
> 
> 
>> I think your proposals are fine, I have just been a bit busy and sort
>> of forgot this, and still a bit busy. Could you prepare a pull request
>> on https://github.com/KiCad/kicad-website?
> 
> Of course, and don't worry please. I only wanted the message not to be lost 
> in space without any comment.
> 
>> But I wonder, why did HaD start to have articles in other languages?
>> Are they intending to do that to all articles or what is the point? Or
>> was this just a gimmick to present the spanish kicad forum?
> 
> No idea. I have no relation with Hackaday, I only sent them a note about the 
> Spanish translation and forum.
> 
> Iñigo.
> 
>> 2016-02-19 7:26 GMT+01:00 Iñigo :
>>> Hello,
>>> No comments?
>>> Regards,
>>> Iñigo.
>>> ___
>>> Hello,
>>> A couple of notes...
>>> - The KiCad Spanish translation was featured on hackaday.com (first message
>>> ever in Spanish on hackaday). Maybe it is of interest to publish it on the
>>> KiCad webpage in the (DISCOVER->IN THE MEDIA) section.
>>> Link:http://hackaday.com/2016/02/11/kicad-traducido-al-espanol/
>>> - There has been some interest among some users about a Spanish forum about
>>> KiCad, so I published one here: www.elektroquark.com/forokicad. It's
>>> starting now but, could it be linked from the COMMUNITY section?
>>> Thank you.
>>> Iñigo.
>>> ___
>>> 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] Windows 10 reports stable 4.0.1 installer as malware.

[Miguel Angel Ajo Pelayo]

Ahh, that makes sense :)

> On 18 Feb 2016, at 15:42, Mark Roszko  wrote:
> 
> If the installer was compromised or modified in anyway, Windows would
> be invalidating the
> certificate's signature and you would see "Unknown Publisher" or other
> warnings rather than displaying the name on the certificate "Open
> Source Developer, Mark Roszko". Someone would have to have their own
> trusted CA code signing certificate to resign it.


___
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 StepUp 3D MCAD exporter has landed Hackaday.com!

[Miguel Angel Ajo Pelayo]

Awesome :o

> On 09 Nov 2015, at 13:49, easyw  wrote:
> 
> Hi to all,
> I'm pleased to share that kicad StepUp 3D MCAD exporter has landed 
> Hackaday.com!
> 
> http://hackaday.com/2015/11/08/kicad-script-hack-for-better-mechanical-cad-export/
> http://hackaday.com/
> 
> Thanks a lot to Hackaday staff for the nice review!!! :)
> 
> Maurice
> 
> PS more 3D features for an easier ECAD MCAD collaboration are coming...
> 
> ___
> 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] Windows 10 reports stable 4.0.1 installer as malware.

[Miguel Angel Ajo Pelayo]

For just in case, I’ve checked what’s on the server, not sure if we have 
anything to compare it too, 
I didn’t observe any sign of server being compromised (but one never knows)...

[root@kicadwww stable]# sha256sum *
1f4c899f23d94ecb16982b8a3b21abecfbdf0af2a39cc1e20ca11e887295ce01  
kicad-product-4.0.0-i686.exe
2840c6027429af8e6285a9828e97b0169afe70157496084f072d23c52be019d7  
kicad-product-4.0.0_rc1-i686.exe
2d513df037b13f0f3193d15a1eba71cf6905ff160008bdea3da089779c24cdd5  
kicad-product-4.0.0_rc1-x86_64.exe
8ecd34ecdd0079240d70b63a2c6c47fe51adf469d2fa677280678a3616639c28  
kicad-product-4.0.0_rc2-i686.exe
76c1fef0f3aaeb80ebc929e2d184a30db67252356a83cde571cb781152cfd035  
kicad-product-4.0.0_rc2-x86_64.exe
d45bbcadda06f46fbf3c0d465f1df148c0fa91e61d59d3f8fbb5b4b0b752b8d9  
kicad-product-4.0.0-x86_64.exe
1358e90968dc90f67afe38834c4d0a313e3b7a0f3516a72f5fba68df124abe30  
kicad-product-4.0.1-i686.exe
06b977afc6bdaf7e2432dab575fc79a1b681aa5daf2c8c493e0ff5c99dc5a027  
kicad-product-4.0.1-x86_64.exe

[root@kicadwww stable]# ls -la
total 1847876
drwxrwxr-x. 2 kicad kicad  4096 Dec 11 22:40 .
drwxr-xr-x. 6 kicad kicad 12288 Dec 28 04:58 ..
-rwxr-xr-x. 1 kicad kicad 251037544 Dec  3 09:37 kicad-product-4.0.0-i686.exe
-rwxr-xr-x. 1 kicad kicad 200702545 Sep 13 14:53 
kicad-product-4.0.0_rc1-i686.exe
-rwxr-xr-x. 1 kicad kicad 200389259 Sep 13 14:54 
kicad-product-4.0.0_rc1-x86_64.exe
-rwxr-xr-x. 1 kicad kicad 250784792 Nov 10 02:36 
kicad-product-4.0.0_rc2-i686.exe
-rwxr-xr-x. 1 kicad kicad 250570746 Nov 10 02:37 
kicad-product-4.0.0_rc2-x86_64.exe
-rwxr-xr-x. 1 kicad kicad 250749688 Dec  3 09:38 kicad-product-4.0.0-x86_64.exe
-rwxr-xr-x. 1 kicad kicad 244125112 Dec 11 22:40 kicad-product-4.0.1-i686.exe
-rwxr-xr-x. 1 kicad kicad 243826280 Dec 11 22:40 kicad-product-4.0.1-x86_64.exe


> On 18 Feb 2016, at 03:00, Mark Roszko  wrote:
> 
> Nick,
> 
> Here's a fresh report from a clean Windows system:
> http://pastebin.com/raw/hbKaRMSf
> 
> uninstaller.exe needs to be signed
> http://nsis.sourceforge.net/Signing_an_Uninstaller
> 
> 
> And all of kicad's executables apparently don't mark as having
> manifests (though they do) which I think is a kicad build problem with
> the mingw_resource_compiler.
> 
> ___
> 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] PATCH: Set SMD attribute in footprint wizard

[Miguel Angel Ajo Pelayo]

Hi Mikael, 

   Sorry, my comment is probably irrelevant, 

 sizex = (int(sizex/10)+1)*10

vs

   sizex = (int((sizex+(10-1))/10))*10


for sizex of 0, on the first one you end up with 10
while on the second you end up with 0

and for sizex of 1, both render the same result.

Anyway, given those are 10nm steps, you probably don’t care, and actually you 
want to start by 1mm minimum,
right?, so your function would be more appropriate. 

Cheers :)

> On 14 Feb 2016, at 15:28, Mikael Arguedas <mikael.argue...@gmail.com> wrote:
> 
> Hi Miguel,
> 
> The question may seem silly (sorry I'm an EE guy who doesnt know much about 
> computer science). How is your suggested implementation of ceil better? Is it 
> a matter of stability ? performance ? 
> They seem completely identical to me in terms of performance and result but 
> I'd really like to learn where I mistaken.
> 
> Thanks!
> MIkael
> 
> On Sun, Feb 14, 2016 at 6:07 AM, Mikael Arguedas <mikael.argue...@gmail.com 
> <mailto:mikael.argue...@gmail.com>> wrote:
> Hi guys,
> 
> Here is an updated version of the patch, I removed the textSize fix because 
> it has already been merged here 
> <https://lists.launchpad.net/kicad-developers/msg23113.html>.
> 
> Cheers,
> Mikael Arguedas
> 
> On Fri, Feb 12, 2016 at 8:56 AM, Mikael Arguedas <mikael.argue...@gmail.com 
> <mailto:mikael.argue...@gmail.com>> wrote:
> Hi Miguel,
> 
> I'm new to bazaar and that's the reason I started by just submitting patch 
> files but for any further feature addition I'll send a branch for review.
> 
> Yes the purpose of this function was to perform a ceil. Either of these 
> implementations is good for me given that they have the same complexity and 
> the same result.
> 
> Cheers,
> Mikael Arguedas
> 
> 
> On Fri, Feb 12, 2016 at 1:31 AM, Miguel Angel Ajo Pelayo <majop...@redhat.com 
> <mailto:majop...@redhat.com>> wrote:
> Hi, Mikael, I haven’t fully looked at the patch, it would be easier if you 
> can send a branch for review via launchpad.
> 
> But, Could you explain those changes:
> 
> === modified file 'pcbnew/scripting/plugins/qfp_wizard.py'
> --- pcbnew/scripting/plugins/qfp_wizard.py2016-02-11 15:02:37 +
> +++ pcbnew/scripting/plugins/qfp_wizard.py2016-02-12 03:39:11 +
> @@ -113,6 +113,8 @@
>  self.draw.SetLayer(pcbnew.F_CrtYd)
>  sizex = (lim_x + cmargin) * 2 + pad_length
>  sizey = (lim_y + cmargin) * 2 + pad_length
> +sizex = (int(sizex/10)+1)*10
> +sizey = (int(sizey/10)+1)*10
> 
> 
> --- pcbnew/scripting/plugins/zip_wizard.py2016-02-11 15:02:37 +
> +++ pcbnew/scripting/plugins/zip_wizard.py2016-02-12 03:31:52 +
> @@ -106,6 +106,8 @@
>  thick = self.draw.GetLineThickness()
>  sizex = (pin1posX + cmarginx) * 2 + pad_Hsize + thick
>  sizey = (pin1posY + cmarginy) * 2 + pad_Vsize + thick
> +sizex = (int(sizex/10)+1)*10
> +sizey = (int(sizey/10)+1)*10
> 
> 
> 
> The semantics for size x/y seem very different. :)
> 
> Also, are you trying to round here? 
> +sizex = (int(sizex/10)+1)*10
> +sizey = (int(sizey/10)+1)*10
> 
> Wouldn’t it be better like 
> sizex = (int((sizex+(10-1))/10))*10
> (if you were trying to do a ceil?)
> 
> 
> Cheers,
> Miguel Ángel
> 
> 
>> On 12 Feb 2016, at 05:03, Mikael Arguedas <mikael.argue...@gmail.com 
>> <mailto:mikael.argue...@gmail.com>> wrote:
>> 
>> Hi guys,
>> 
>> Here is the updated patch including changes from 
>> https://lists.launchpad.net/kicad-developers/msg23059.html 
>> <https://lists.launchpad.net/kicad-developers/msg23059.html>
>> This patch fixes the following KLC violations in the generated footprints:
>> - fixes the text size as specified in rule 6.9
>> - rounds the courtyard position on a 0.05mm grid as specified in rule 6.6
>> - set the attribute for SMD components as specified in rule 10.5
>> 
>> Cheers,
>> Mikael Arguedas
>> 
>> On Thu, Feb 11, 2016 at 6:54 PM, Mikael Arguedas <mikael.argue...@gmail.com 
>> <mailto:mikael.argue...@gmail.com>> wrote:
>> Hi guys,
>> 
>> Sorry for spamming.
>> This patch sets the footprint attibute to SMD if needed. This allows the 
>> generated footprints to comply with KLC rule 10.5.
>> 
>> Cheers,
>> Mikael Arguedas
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>>

Re: [Kicad-developers] PATCH: Set SMD attribute in footprint wizard

[Miguel Angel Ajo Pelayo]

Hi, Mikael, I haven’t fully looked at the patch, it would be easier if you can 
send a branch for review via launchpad.

But, Could you explain those changes:

=== modified file 'pcbnew/scripting/plugins/qfp_wizard.py'
--- pcbnew/scripting/plugins/qfp_wizard.py  2016-02-11 15:02:37 +
+++ pcbnew/scripting/plugins/qfp_wizard.py  2016-02-12 03:39:11 +
@@ -113,6 +113,8 @@
 self.draw.SetLayer(pcbnew.F_CrtYd)
 sizex = (lim_x + cmargin) * 2 + pad_length
 sizey = (lim_y + cmargin) * 2 + pad_length
+sizex = (int(sizex/10)+1)*10
+sizey = (int(sizey/10)+1)*10


--- pcbnew/scripting/plugins/zip_wizard.py  2016-02-11 15:02:37 +
+++ pcbnew/scripting/plugins/zip_wizard.py  2016-02-12 03:31:52 +
@@ -106,6 +106,8 @@
 thick = self.draw.GetLineThickness()
 sizex = (pin1posX + cmarginx) * 2 + pad_Hsize + thick
 sizey = (pin1posY + cmarginy) * 2 + pad_Vsize + thick
+sizex = (int(sizex/10)+1)*10
+sizey = (int(sizey/10)+1)*10



The semantics for size x/y seem very different. :)

Also, are you trying to round here? 
+sizex = (int(sizex/10)+1)*10
+sizey = (int(sizey/10)+1)*10

Wouldn’t it be better like 
sizex = (int((sizex+(10-1))/10))*10
(if you were trying to do a ceil?)


Cheers,
Miguel Ángel


> On 12 Feb 2016, at 05:03, Mikael Arguedas  wrote:
> 
> Hi guys,
> 
> Here is the updated patch including changes from 
> https://lists.launchpad.net/kicad-developers/msg23059.html 
> 
> This patch fixes the following KLC violations in the generated footprints:
> - fixes the text size as specified in rule 6.9
> - rounds the courtyard position on a 0.05mm grid as specified in rule 6.6
> - set the attribute for SMD components as specified in rule 10.5
> 
> Cheers,
> Mikael Arguedas
> 
> On Thu, Feb 11, 2016 at 6:54 PM, Mikael Arguedas  > wrote:
> Hi guys,
> 
> Sorry for spamming.
> This patch sets the footprint attibute to SMD if needed. This allows the 
> generated footprints to comply with KLC rule 10.5.
> 
> Cheers,
> Mikael Arguedas
> 
> ___
> 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 Twitter

[Miguel Angel Ajo Pelayo]

Hi Chris!,

  I registered that account, and I have been keeping it, but as you can see, 
I’m way behind with the updates.

  If you could give some help, I’d be very happy to share the password as 
gentlemen. May be there are other volunteers,
not sure if Nickoe asked for this before too.

  Wayne, Chris, Nickoe, how does that sound?


Best regards,
Miguel Ángel.

> On 04 Feb 2016, at 23:07, Chris Gammell  wrote:
> 
> resending from my email account that is linked to the developers list. Sorry 
> if it comes through twice.
> 
> Hi Developers!
> 
> I don't know if I've ever actually emailed this list before. But I'm a big 
> fan of what all of you are doing! I use KiCad every day and it has helped me 
> immensely.
> 
> I was wondering if I could help out with the @kicad_pcb twitter account. I 
> keep an eye on all things KiCad on Tweetdeck and noticed that the official 
> twitter is rather dormant. I emailed with Wayne and he mentioned it was 
> probably set up by a developer. I was wondering if whoever controls it would 
> be interested in some help getting the word out?
> 
> I'd mostly be interested in retweeting what other people are doing and 
> pointing people in the right direction (resources, forum posts as needed, 
> answering questions directly, etc). It's actually been really fun watching 
> the tweets lately where people start with, "I don't GET KiCad!" and then an 
> hour later they start tweeting about how much they love KiCad. That's a sign 
> things are headed in the right direction!
> 
> Anyway, let me know!
> 
> Chris
> 
> ps. The KiCad User Forum (http://forum.kicad.info ) 
> just crossed 1K users! 
> ___
> 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] Release 5 road map

[Miguel Angel Ajo Pelayo]

For the Object Properties and Introspection, I think it could be useful to add
not only name/type/value but context/namespace (or equivalent) too.

That could also be possible by using name as “.”.

I’m specifically thinking, of how could we separate properties related to 
different
things. For example, a parametric footprint derived from a footprint generator 
could
have all it’s “footprint parameters” in the footprint namespace.

* footprint-generator
- generator: PCB Antenna
- freq: 2.4GHz
- A: …
- B: ….


But, as I was saying, it could equally be:

* footprint-generator.generator: PCB Antenna
* footprint-generator.freq: 2.4GHz
* footprint-generator.A: …
* footprint-generator:B: …






> On 05 Feb 2016, at 01:00, Wayne Stambaugh  wrote:
> 
> I think this was originally meant to be a generic plugin object and
> plugin manager to be used as a base classes.  I believe it was something
> I discussed with Tom a while back.  It may or may not still be useful.
> I would be willing to bet most plugin managers and plugins have to do a
> lot of the same basic tasks for loading and unloading the plugins which
> could be unified in well designed base classes.  It's the next level up
> that defines the actual plugin and plugin manager functionality.   I
> agree with your assessment that a do it all plugin manager would be a
> bad idea.
> 
> On 2/4/2016 4:18 PM, Cirilo Bernardo wrote:
>> For the section Dynamic Library Plugin, what is described would
>> not be a reasonable implementation.  We cannot have a "do it all"
>> plugin - that would result in unnecessary complexity and also couple
>> code which should not be coupled. Perhaps we need a more refined
>> description of what people would like to do with these plugins?
>> 
>> I have already created a simple plugin framework and a 3D Plugin
>> class which is responsible for loading and creating rendering data
>> for the 3D viewer. Next on my list is to develop a PCB Plugin which
>> can perform I/O on a BOARD class - this involves creating a
>> PCB Plugin API and a pcbnew API. The pcbnew API can be used 
>> for just about anything - re-implement Python scripting interface,
>> implement various MCAD/ECAD Import/Export etc.
>> 
>> - Cirilo
>> 
>> On Fri, Feb 5, 2016 at 3:04 AM, Wayne Stambaugh > >> wrote:
>> 
>>I committed the release 5 road map yesterday and the developers
>>documentation[1] on the KiCad website has be updated.  Please take a
>>look at it when you get a chance and let me know if you find anything I
>>missed that we discussed for the current development cycle or if you
>>find any errors.  It's pretty ambitious already so I don't know if we
>>should be adding too much to it.  If you find something in there that
>>interests you and you're willing to work on itplease let the dev team
>>know so we are not all working on the same thing.  As of right now, I've
>>assigned myself the schematic object refactor (in progress), I/O
>>manager, and new schematic and component library file formats tasks.
>> 
>>Thanks,
>> 
>>Wayne
>> 
>>[1]
>>
>> http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/v5_road_map.html
>> 
>>___
>>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] [RFC PATCH] No more boost::context

[Miguel Angel Ajo Pelayo]

Tomasz, you’re awesome!! :)

and good catch :)

> On 28 Jan 2016, at 17:42, Tomasz Wlostowski  wrote:
> 
> On 23.01.2016 23:53, Wayne Stambaugh wrote:
>>> I found the issue in Boost causing crashes on x86_64 windows builds.
 
 Now I have no doubt why Windows Boost developers may have a very good
 reason to hate the x86 GNU assembler (well, not the tool itself but its
 infamous AT syntax). Look at the code below:
 
 mov $0x8, %rcx
 mov 0x8, %rcx
 
 Translated to a more human-readable form, these two lines mean:
 
 mov rcx, 0x8
 mov rcx, qword [ds:0x8]
>> Great catch!.  That is just too easy to overlook.
>> 
> 
> Hi all,
> 
> I've filed bug reports & sent patches both to boost & MSYS2 maintainers.
> 
> Cheers,
> T.
> 
> ___
> 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] FOSDEM

[Miguel Angel Ajo Pelayo]

Hi everybody,

   I will be on friday too, and I’d be glad to join that. I shall give a talk 
in the RDO
centos dojo (around 16:00), but after that I’ll checkout to my hotel, and then 
be
free.

My Cell phone for whatsapp is +34636522569, feel free to add me, and keep 
me posted.




> On 25 Jan 2016, at 01:46, Wayne Stambaugh  wrote:
> 
> Just a heads up.  I will be arriving in Brussels at 2:25PM local time
> assuming my flights are on time.  I should get to my hotel by no later
> than 4PM.  If any one else is getting in early enough on Friday and is
> interested in grabbing some dinner and adult beverages, email me or you
> can use whatsapp to contact me as well.  I am staying within a 3 minute
> walk from Gare Centrale (Centraal Station).  Hope to see some of you there.
> 
> Cheers,
> 
> 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


___
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] footprint library table wizard: need testers

[Miguel Angel Ajo Pelayo]

Nice Jean-pierre,  I will make sure tonight that the CI system has the webkit 
library installed or otherwise switch off the compilation flag. 

Sent from my Android phone using TouchDown (www.nitrodesk.com)


-Original Message-
From: jp charras [jp.char...@wanadoo.fr]
Received: Sunday, 21 Dec 2014, 16:46
To: kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] footprint library table wizard: need testers

I committed the first version of a wizard to manage the footprint
library table dialog editor.
It help users to select the right plugin, an existing environment
variable or an absolute path, and add a list of new entries to the table.
Note: the wxWidgets webkit/webview library is needed.
On windows,there is no problem.
On Linux,  the webkitgtk-devel tool (sudo apt-get install
libwebkitgtk-dev) must be installed if it is missing (and wxWidgets
rebuilt after running configure.).
See:
http://docs.wxwidgets.org/3.0/classwx_web_view.html

However, to avoid use of wxwebview, if it creates issues, you can
compile kicad with cmake option -DKICAD_USE_WEBKIT=OFF.
But the github plugin wizard will be not fully available.

Currently this option is ON.
OSX testers are welcome.


-- 
Jean-Pierre CHARRAS

___
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] Track copy - to be or not to be… I'm panelizing, python coder.

[Miguel Angel Ajo Pelayo]

Hi Daniel,

   If your pcbnew is compiled with WXPYTHON support, 
then try: 

   http://zetcode.com/wxpython/firststeps/

I can't remember if you need to take care of the 
app main loop, or it was already enough with the
one pcbnew is running.

For ease of testing, I recommend putting your script 
in a file, and using  execfile(/my/script.py).

Please, consider this is an early alpha feature,
so tell us where it breaks and how it works.


And about the copy, may be it's good to provide .Copy()
specific python operator to automate the magic spells ;)

Best regards,
Miguel Ángel.

- Original Message -
 In response to a message written on 02.10.2014 16:22, from jp charras:
  Can you test the existing method:
  new_item=Cast_to_BOARD_ITEM(item.Clone()).Cast()
  
  to create a copy of an item ?
 Of course, a very much thank you for the hint, because it was not so obvious
 for
 anyone unfamiliar with KiCAD C++ API.
 Is there a way in python interface to create dialog boxes(for user input),
 connected to the pcbnew main window, or I should create a stand-alone
 application (not a plugin)?
 --
 Best Regards,
 LordBlick
 
 ___
 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] Build failed in Jenkins: kicad-qa #358

[Miguel Angel Ajo Pelayo]

Hi Wayne,  I will work on this during today. 

Thanks for pinging me on this,  and thank you Nick for pinging me on my 
personal email.  I'm on PTO until Wednesday and I wasn't reading work emails 
too often. 

If any infrastructure event ever happens,  please feel free to ping me on 
Whatsapp, Telegram, SMS or phone via (+34636522569) or my personal email 
miguelangel (@t) ajo.es 

Best regards, 
Miguel Angel 



Sent from my Android phone using TouchDown (www.nitrodesk.com)


-Original Message-
From: Wayne Stambaugh [stambau...@verizon.net]
Received: Monday, 29 Sep 2014, 2:49
To: kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] Build failed in Jenkins: kicad-qa #358

Hey Miguel,

Can you change the Jenkins build to build against wx3 instead of wx2?
Otherwise, every time there is a commit, this message is going to get
sent to the mailing list.

Thanks,

Wayne

On 9/28/2014 6:02 PM, Miguel Angel Ajo wrote:
 See http://ci.kicad-pcb.org/job/kicad-qa/358/changes
 
 Changes:
 
 [Wayne Stambaugh] Update kicad-install.sh to install wxWidgets 3.0 on Debian 
 based distro builds.
 
 --
 Started by an SCM change
 Building in workspace http://ci.kicad-pcb.org/job/kicad-qa/ws/
 $ bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-qa/ws/
 info result: bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-qa/ws/ 
 returned 0. Command output: 5153 
 jp.char...@wanadoo.fr-2014092817-elbu9i51d6frhkbl
  stderr: 
 [kicad-qa] $ bzr pull --overwrite lp:kicad
 You have not informed bzr of your Launchpad ID, and you must do this to
 write to Launchpad or access private data.  See bzr help launchpad-login.
 http://bazaar.launchpad.net/~kicad-product-committers/kicad/product is 
 permanently redirected to 
 http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/changes
 You have not informed bzr of your Launchpad ID, and you must do this to
 write to Launchpad or access private data.  See bzr help launchpad-login.
  M  scripts/kicad-install.sh
 All changes applied successfully.
 Now on revision 5154.
 [kicad-qa] $ bzr revert
 $ bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-qa/ws/
 info result: bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-qa/ws/ 
 returned 0. Command output: 5154 
 stambau...@verizon.net-20140929001810-s3iobli8y1qbl9ku
  stderr: 
 [kicad-qa] $ bzr log -v -r 
 revid:jp.char...@wanadoo.fr-2014092817-elbu9i51d6frhkbl..revid:stambau...@verizon.net-20140929001810-s3iobli8y1qbl9ku
  --long --show-ids
 Getting local revision...
 $ bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-qa/ws/
 info result: bzr revision-info -d http://ci.kicad-pcb.org/job/kicad-qa/ws/ 
 returned 0. Command output: 5154 
 stambau...@verizon.net-20140929001810-s3iobli8y1qbl9ku
  stderr: 
 RevisionState revno:5154 
 revid:stambau...@verizon.net-20140929001810-s3iobli8y1qbl9ku
 [kicad-qa] $ /bin/sh -xe /tmp/hudson7151316971480031219.sh
 + OPTS=' -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON 
 -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON 
 -DKICAD_SCRIPTING_WXPYTHON=ON'
 + '[' -d build ']'
 + cd build
 + /usr/bin/cmake .. -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON 
 -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON 
 -DKICAD_SCRIPTING_WXPYTHON=ON
 CMake Error at CMakeModules/FindPackageHandleStandardArgs.cmake:136 (message):
   Could NOT find wxWidgets: Found unsuitable version 2.8.12, but required
   is at least 3.0.0 (found
   
 -pthread;;;-lwx_gtk2u_gl-2.8;-lwx_gtk2u_aui-2.8;-lwx_gtk2u_adv-2.8;-lwx_gtk2u_html-2.8;-lwx_gtk2u_core-2.8;-lwx_baseu_net-2.8;-lwx_baseu-2.8;-lwx_baseu_xml-2.8)
 Call Stack (most recent call first):
   CMakeModules/FindPackageHandleStandardArgs.cmake:341 
 (_FPHSA_FAILURE_MESSAGE)
   CMakeModules/FindwxWidgets.cmake:901 (find_package_handle_standard_args)
   CMakeLists.txt:376 (find_package)
 
 
 -- Configuring incomplete, errors occurred!
 See also 
 http://ci.kicad-pcb.org/job/kicad-qa/ws/build/CMakeFiles/CMakeOutput.log;.
 Build step 'Execute shell' marked build as failure
 
 ___
 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] OSX Build changes.

[Miguel Angel Ajo Pelayo]

Good work and congratulations on this! 

Sent from my Android phone using TouchDown (www.nitrodesk.com)


-Original Message-
From: Adam Wolf [adamw...@feelslikeburning.com]
Received: Monday, 29 Sep 2014, 4:20
To: Wayne Stambaugh [stambau...@verizon.net]
CC: kicad-developers@lists.launchpad.net [kicad-developers@lists.launchpad.net]
Subject: Re: [Kicad-developers] OSX Build changes.

I actually had this open in a tab for something else I was doing.

https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/EnvironmentVars.html

At the bottom of that page is an explanation how to set an environment
variable for an app bundle.

I am so, so excited for this.  Good work folks!

Adam Wolf
Cofounder and Engineer
WL

On Sun, Sep 28, 2014 at 7:47 PM, Wayne Stambaugh stambau...@verizon.net
wrote:

 On 9/28/2014 12:31 PM, Bernhard Stegmaier wrote:
  Hi all,
 
  as Wayne already mentioned below I made some major changes to the
  creation of OSX application bundles in the build process.
  The most obvious is that now only one application bundle is created
  which starts the kicad launcher.
  From there you can go anywhere else.
  The created bundle now is (should be) completely relocatable, so you can
  just put it anywhere you want as with other OSX apps.
  All the pre-delivered templates, etc. have been moved into the bundle
  and should be found from there.
  Command-Line tools are still contained (and accessible via e.g.
  /Applications/kicad.app/Contents/MacOS/idf…).
 
  I have uploaded a sample dmg image here:
http://ul.to/ypsk7m41
  What you see in the dmg is 1:1 what is created in the build process now…
  this should make packaging and distributing automated builds very easy
  in future.

 I looked at the file layout and it looks good.  At some point we should
 add the documentation, component libraries, and 3D models (possibly
 footprint libraries if the user does not want to use the github plugin).
  This would be a complete install of KiCad.  The footprint libraries can
 be loaded via the github plugin.  Is it possible to set local
 environment variables in a bundle?  It might be a good idea to set the
 kicad environment variables so that the user doesn't have to mess with
 them.

 
  I am still doing some final touches to the patch before it gets
 submitted.
  So, feel free to test and comment…
 
 
  Regards,
  Bernhard
 
  Begin forwarded message:
 
  *From: *Wayne Stambaugh stambau...@verizon.net
  mailto:stambau...@verizon.net
  *Subject: **[Kicad-developers] Build changes.*
  *Date: *27. September 2014 00:09:13 MESZ
  *To: *KiCad Developers kicad-developers@lists.launchpad.net
  mailto:kicad-developers@lists.launchpad.net
 
  I just committed revision r5149 which fails when wxWidgets is less than
  version 3.0.0.  I know that the wx3 is not without it's issues but it is
  becoming too much of a burden to try to keep the code compatible with
  wx2 along the known issues.
 
  I've also added an option when building on OSX that disables downloading
  and building all of the dependencies from source by default.  You must
  now run CMake with -DUSE_OSX_DEPS_BUILDER=ON if you want to use that
  build method.  The are further OSX bundle fixes on the way as well so
  please be patient as we transition away from that build philosophy.  I
  am working with Bernhard (thanks Bernhard) on getting this issue
  resolved so OSX looks for the dependencies on the system and creates OSX
  bundles without external scripts.  I have it on good authority that
  KiCad will build and run just fine using the installed dependencies.
 
  I am also working on getting stock Boost 1.56 to build KiCad.  It does
  appear to work on Linux.  I'm still having some issues on Windows so
  hopefully that will be resolved before too long and thus eliminate the
  last dependency we will have to build from source.
 
  Wayne
 
  ___
  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
 



 ___
 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   : 

[Kicad-developers] kicad-pcb.org

[Miguel Angel Ajo Pelayo]

- Forwarded Message -
From: Miguel Angel Ajo Pelayo mangel...@redhat.com
To: Moses McKnight mo...@texband.net
Cc: Wayne Stambaugh stambau...@verizon.net, KiCad Developers 
kicad-developers@lists.launchpad.net
Sent: Saturday, 30 August, 2014 10:22:16 PM
Subject: Re: [Kicad-developers] kicad-pcb.org


Hi, thank you very much Moses, 

I just discovered that, after I added this address to launchpad,
all the list traffic was being directed here, and ... filtered
along together with a launchpad filter I had to put bug emails
into a folder I don't look in too often.


Wayne, congratulations, I'm happy to see you as our new leader,
sad to see Dick go away, as his contribution was enormous, and
my apologies for the too often kicad-pcb.org downtime. It was 
rather better lately, but my last work on the host probably managed
to freeze it again. I have a deadline now to finish moving all
the remaining VMs to the new datacenter/host.


Wayne, I'll send you a link to register in the website, ping me back
when it's done if you want admin credentials.

Please, if anyone else is willing to help with the website, ask me
for the registration link. It's not public to avoid spam which
at some point became a problem. (fabrizio, brian, me, and some 
others are the current website contributors).


I was about to ask you to get Nbee added to the list of sponsors
(website, CI testing / CPU time) but it's pointless now as I'm closing 
it (for good!) :).

 
Best regards,
Miguel Ángel.



- Original Message -
 Hi,
 
 Miguel said he somehow is not on this list, and wanted me to reply for
 him and tell them it's restored now, and that I'm working on the
 migration to a new host? (I have migrated around 15 vms... and I was
 getting ready to migrate kicad-pcb.org, a backup must have destabilized
 the host)
 He also said the old host was a bit outdated
 
 So hopefully the site will not go down as often now!
 
 Moses
 
 On 08/30/2014 11:20 AM, Wayne Stambaugh wrote:
  Hey Brian,
 
  It looks like the site is down again.  I just tried to take a look at
  your changes.  Thank you by the way.  I'll take a look at it as soon as
  the site is back up.  If I write up a short blurb on the history of
  KiCad, would you be interested in formatting it and creating a project
  history page?  It might be nice to give a nod to the folks who were
  there at the beginning when the project went public.  I would also like
  us to add a sponsor's page.  From a corporate perspective, I think it's
  important to recognize the contributions that helped KiCad get where it
  is today.  The first two sponsors on that list should be SoftPLC and
  CERN.  If I'm missing any other corporate sponsors, please let me know.
I want to make sure credit is given where credit is due.
 
  I'll try to contact Miguel directly if I don't hear from him over the
  next few days.
 
  Cheers,
 
  Wayne
 
  On 8/30/2014 7:19 AM, Brian Sidebotham wrote:
  Looks like it just fell over, however I updated
  http://www.kicad-pcb.org/display/KICAD/About+KiCad last night with the
  information in AUTHORS.txt
 
  There's some more to do, but at least the majority of it is up there.
  I'd like to do some info on the individual programs under About KiCad.
 
  I believe Miguel is the guy to speak to.
 
  Best Regards,
 
  Brian.
 
  On 30 August 2014 01:09, Wayne Stambaugh stambau...@verizon.net wrote:
  Now that I am the project leader, it would be useful for me to know who
  the kicad-pcb.org site maintainer is and who has write access so I can
  enlist (read arm twisting ;)) help getting changes made and keeping
  things up to date.
 
  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
 
 
 
  ___
  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

[Kicad-developers] Fwd: Project proposal

[Miguel Angel Ajo Pelayo]

- Forwarded Message -
From: Miguel Angel Ajo Pelayo mangel...@redhat.com
To: Wayne Stambaugh stambau...@verizon.net
Cc: KiCad Developers kicad-developers@lists.launchpad.net
Sent: Saturday, 30 August, 2014 10:39:24 PM
Subject: Re: [Kicad-developers] Project proposal

Hi Wayne!,


 Since Javier sort of let the cat out of the bag, I thought now would be
 a good time as my first official announcement as project leader to talk
 about creating a stable release of KiCad.  As you may have read in
 Javier's post that this stable release would be a light weight release
 in that there would not be bug fix back ports.  The goal is to attempt
 to strike a balance between the needs of users and the resource
 limitations of the project.  In order for this to work effectively, I
 feel we have to adopt a slightly different development model than we
 currently have.  I am proposing that we move to a model more like the
 Linux kernel where there is a merge window for new features followed by
 a stabilization period.  Once the merge window is closed, we can focus
 on the tasks required for a stable release.  I am *not* suggesting we go
 to a time based release.  I don't believe we are in the position to make
 that happen.  The amount of time the merge window is open will depend on
 what new features are introduced and how disruptive they are.  The
 amount of time between the close of the merge window and the next stable
 release will depend on how long it takes to complete all of the tasks
 required to ready a high quality stable release.  The way I see it, the
 following tasks would need to be completed in order for a stable release.

That's very similar to other projects I work for from my position at
Red Hat (openstack), we have a window to provide specification for new features,
a window to merge new features, and a window to stabilize.

At least for the subproject I work on (neutron) it's 3/4 (new features)- 
1/4(stabilization), in this case we have back ports to stable branches,
because we have resources for that, something that helps on that is 
marking the backportable fixes with  Backport-Potential in the commit message.

I can only say, that removing the time constraints, and the backports, 
it already sounds like a very good enhancement to the project.

 
 1) Bug fixing
 
 At a minimum all bugs that cause segfaults or loss of data need to be
 fixed first.  All new and existing features must perform as expected and
 documented.  We need to flesh out all the new features such as GAL, PS
 router, and Kiway code to make sure it is rock solid.
 
 2) Usability
 
 The user interface should be as consistent as possible between the major
 frame windows as well as the dialog layouts.  Any key board handling
 quirks should be addressed.  I've seen a few bug reports about hot key
 behavior so it would be good to get these resolved if they haven't been
 fixed already.
 
 3) Documentation
 
 All of the features recently added to KiCad must be added to the
 documentation.  The existing documentation needs to be vetted by folks
 whose native language is English or have very strong English skills.
 Quite a bit of wording of the existing documentation can be confusing.
 There has been a suggestion of moving our documentation to a text base
 layout format to make it more version control and translation friendly.
  I'm all for that.  One thing that I ask of whoever steps up to perform
 this task that whatever format is choosen, the tools to edit and build
 the documentation must be readily available on all the major platforms
 support by KiCad.  By readily available, I mean there needs to be binary
 installers.  I'm fine if Windows users have to install MSYS2/MinGW along
 with the required packages to edit an build the documentation.  I don't
 think it's good idea to ask our documentation folks to have to build the
 tools from source.
 
 4) Installers.
 
 High quality binary installers are a must for all of the supported
 platforms.  I cannot stress enough how important this is.  Asking users
 to build and install KiCad from source is insane.
 
 There are Linux distro packagers, corporate users, and potential
 sponsors who consider stable releases a must.  Obviously, none of this
 can happen without your help.  Please take a few days and carefully
 consider this proposal and how you can contribute to help make it a
 reality.  I will be traveling the next two days so please hold off on
 the big barrage of comments and questions until early next week so I can
 make a feeble attempt to keep up with them :).  I also want to extend my
 sincerest thanks to all who have contributed their time, talents, and
 money to help make KiCad what it is today.

I'm not in the position to help on this at this moment, but I also believe 
it's something very necessary if we want to remove the entry barriers for users.

I'm my opinion, the more automated the installer generation is, the better,
this way we could auto build, and auto upload even

[Kicad-developers] New Project Leader

[Miguel Angel Ajo Pelayo]

- Forwarded Message -
From: Miguel Angel Ajo Pelayo mangel...@redhat.com
To: Wayne Stambaugh stambau...@verizon.net, d...@softplc.com
Cc: kicad-developers@lists.launchpad.net
Sent: Saturday, 30 August, 2014 10:44:13 PM
Subject: Re: [Kicad-developers] New Project Leader


Dick, 

   Thank you for all the time and dedication you devoted to KiCad,
without your work the project wouldn't be where it is today.

   My best wishes to Wayne as the new leader. I saw that you started
with a lot of strength and ideas for the project.

   Best regards,
Miguel Ángel.

- Original Message -
 On 8/26/2014 12:44 PM, Brian Sidebotham wrote:
  On 22 August 2014 17:41, Dick Hollenbeck d...@softplc.com wrote:
  Ladies and Gentlemen:
 
  With great respect and humility I am turning over KiCad project leadership
  to
 
 Mr. Wayne Stambaugh.
 
  Wayne has established himself as a seasoned leader and software architect.
 
  His software architectural skills and leadership skills make him in my
  opinion the best of
  available persons to fill this role.  We should hope and wish that he
  finds the job
  rewarding and fulfilling in a way that leads to an extended term in this
  volunteer position.
 
  I obviously have confidence in his abilities, but I don't over estimate
  his staying power,
  nor should you.  Please be kind and respectful to him.
 
 
  It is time for me to move out of the top spot and off the mailing list.
 
 
 
  I want to acknowledge Brian Sidebotham with special thanks for his faith
  in my leadership
  and his exceptional contributions in the realm of KiCad Winbuilder.  It
  was his faith in
  my vision that motivated him to do an unspeakable volunteer effort from
  which hundreds of
  KiCad users benefit.  While I thank him for his confidence in that vision
  of mine, you all
  should thank him for his actual time and leadership in making KiCad on
  Windows worth
  using.  His efforts in promoting CMake as a build engine warrant industry
  and world-wide
  acclaim and he is due a bonus from Kitware.
 
 
  I want to acknowledge and thank Fabrizio Tappero, who's graphics/icons,
  and user manual
  efforts should go down as some of the most important contributions in
  KiCad's history.
 
 
  I want to acknowledge and thank Carl Poirier who is overseeing what is
  quickly becoming a
  world-wide resource.  At my egging, he stepped up and is now overseeing
  what is becoming
  something truly exceptional along with the efforts of generous
  contributors.  I wish him
  the best, I encourage him to be a leader and encourager among reluctant
  volunteers. I am
  proud to have been an inspiration in something that he can proudly put on
  his resume some day.
 
 
  I want to thank Javier Serano, whose confidence in our project direction
  and leadership
  inspired him to join and bring in some additional world class talent and
  team players, Tom
  and Orson, as well as KiCad team leadership and seasoned experience.
 
 
  Lastly I want to thank Jean-Pierre for his friendship, for his faith and
  confidence in my
  sometimes loud and brash leadership.  But were it not for his stabilizing
  influence in all
  things KiCad, we'd all be making less PCB boards, or doing them more
  expensively.
 
 
  Please take care of my good friend Wayne Stambaugh.  I have prayed with
  Wayne, I know his
  son.  You could not have a better man at the helm.
 
 
  Appreciation goes a long way towards keeping this project healthy, and for
  it to be
  healthy you need a class act at the top, you have one in Wayne.
 
 
  Dick
 
 
  P.S.
 
  *) The project has SoftPLC Corporation's permission to re-license its
  copyrights under GPL3.
 
  *) When somebody other than superman Jean-Pierre surpasses this number of
  commits:
 $ bzr log | grep 'dickelbeck\|Hollenbeck' | wc -l
  send me a personal note and I'll send him a congratulatory memo.  :)
 
  *) It would be nice if the kicad-pcb.org website listed SoftPLC
  Corporation as a
  historically significant corporate sponsor.
 
 
  Out.
 
  
  Hi Dick,
  
  Sorry for the late reply!
  
  I'm so sorry to see your time with KiCad come to an end - you've done
  great things with it and should feel extremely proud; As should
  SoftPLC as a corporate sponsor. I will be sure to update
  http://www.kicad-pcb.org/display/KICAD/About+KiCad to include all of
  the lead developers actually and add the SoftPLC corporate sponsor for
  you - it's more than well deserved! Jean-Pierre's university should be
  on there too.
 
 Thanks Brian for taking care of this.  This was on my short list of
 things to get done as one of my first official duties as project leader.
 
  
  Clearly without your dedication and prolific commits we would be
  nowhere near where we are now. Thank-you so much for your continued
  effort throughout the years! You'll be sorely missed. I only wish I
  could have met you in Grenoble.
  
  Good Luck with whatever you find yourself doing next, and I really
  hope

[Kicad-developers] FOSDEM biggest open-source Europen conference just finished

[Miguel Angel Ajo Pelayo]

- Forwarded Message -
From: Miguel Angel Ajo Pelayo mangel...@redhat.com
To: Kaspar Emanuel kaspar.eman...@gmail.com
Cc: Javier Serrano javier.serrano.par...@gmail.com, KiCad Developers 
kicad-developers@lists.launchpad.net
Sent: Saturday, 30 August, 2014 10:46:31 PM
Subject: Re: [Kicad-developers] FOSDEM biggest open-source Europen conference 
just finished

I would be very glad of joining you, I was planning to be there
as I have interests in other projects and meeting other people too.

Javier, could you take care of making a reservation for our topic :)

Best regards,
Miguel Ángel.

- Original Message -
 On 8 August 2014 16:16, Javier Serrano javier.serrano.par...@gmail.com
 wrote:
  Who would be interested if we organized a FOSS EDA dev room?
 
 Sounds amazing! I would attend. Let me know if I can do anything to help.
 
 ___
 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] GITHUB_PLUGIN

[Miguel Angel Ajo Pelayo]

IMHO, RoR can be used to develop web apps faster (not faster web apps..),
and has a wider community and library support, also has libraries to
inteface ruby-python and make use of the kicad scripting wrappers.

But that's just my opinion. Probably, if we get there at any time, it could
make sense to define a common interface (REST?) and basic models, and then
have a good server ecosystem instead of just one, then you connect your
kicad to your favorite part servers.




2013/8/15 Chris Morgan chmor...@gmail.com

 On Wed, Aug 14, 2013 at 6:29 AM, Miguel Angel Ajo Pelayo
 miguelan...@nbee.es wrote:
 
  2013/8/14 Chris Morgan chmor...@gmail.com
 
  miguelan...@nbee.es 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




-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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

[Miguel Angel Ajo Pelayo]

 for that and other things that we want to add.

 In terms of a longer term community maintained system, there isn't any
 reason we can't mimic the git internals to attach things like comments
 and ratings, and to be able to generate a simulated directory listing
 for the github api.

 Dick, thoughts? I think this may address your goal of simple from
 the KiCad side, and my goal of building on something that has the
 potential to be a fancy web managed community site, without breaking
 the KiCad api to do so.

 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




-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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

[Miguel Angel Ajo Pelayo]

I don't have much time to keep track of your talk, just wanted to say that
the work being done here is awesome.

Tomasz, this is awesome:
http://www.youtube.com/watch?**v=kzro0Jc70xIhttp://www.youtube.com/watch?v=kzro0Jc70xI

About the specifications, MVC is proven to result in good, clean, and easy
to test code, so thumbs up for that,

 I've never worked with coroutines in C++, so I can't tell about that, only
used them on high level languages like python or ruby (more extensively
here, specially in metaprogramming, but that's another history.).  The
other approaches seem cleaner anyway.




2013/8/13 Dick Hollenbeck d...@softplc.com


 On Aug 13, 2013 12:31 PM, Lorenzo Marcantonio 
 l.marcanto...@logossrl.com 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




-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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

[Miguel Angel Ajo Pelayo]

 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
  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




-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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

[Miguel Angel Ajo Pelayo]

 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 this can't be expected to change.  A part of me can
  understand it because backporting shit is no fun.
 
  As an alternative it'd be extremely useful to provide daily releases
  to the community.  Something like what Adam Wolf does but for all the
  3 major platforms.  The version string could be updated to the current
  day, this way users could see who runs the most recent version.  This
  and the news section could boost adoption significantly.
 
   Another thing to keep in mind is packager lazyness may hurt Kicad. I
   often hear things like I can't use kicad because it has [this] and
   [that] problem; kicad sucks [blablabla], when the problem they
 describe
   had been fixed months or even years ago.
  
   *** Third paragraph: ***
  
   The release discussion aside, what I was focusing on in the previous
   email was getting kicad GAL into mainline and getting it to be fully
   functional -- where getting is to be understood as someone please
   come do this. I define fully-functional as being able to design a
 board
   in the new rendering modes. If you'll try laying a track in
 non-default
   mode you'll see what I'm saying.
  
   You cannot vote action in this project,
   [...]
   I can tell you now that I will never make a single
   commit to the stable branch, ever.
  
   Not what I was voting on. Anyhow, I withdraw my (invalid) vote.
  
   Anyway, sorry to raise the undead army.
  
   Peace out!
   Alex
  
   (1) This is a great thing actually. It demonstrates the quality of the
   Kicad code base is very high
  
  
   ___
   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
 
 
 
  --
  László Monda http://monda.hu
 
  ___
  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



 --
 László Monda http://monda.hu

 ___
 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




-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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] PCB Mill

[Miguel Angel Ajo Pelayo]

The Othermill: Custom Circuits at Your
Fingertipshttp://www.kickstarter.com/projects/otherfab/the-othermill-custom-circuits-at-your-fingertips

I found this project on kickstarter about an affordable PCB mill.

 :-) Looks interesting.
-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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 MCAD integration

[Miguel Angel Ajo Pelayo]

I have an idea. may be simpler,

If we keep freecad as a dependency, they have python too, so we could call
python freecad to build the model as we want, and save it as we desire.
We would become brothers with freecad, but isn't it free software too? :)



2013/5/5 Lorenzo Marcantonio l.marcanto...@logossrl.com

 People keep asking about this... at the moment DXF is the only useful
 way to export a board to a 3D mcad (then you estrude it 1,6mm, usually,
 but you don't have component boundaries and stuff).

 IDF3 *is* plausible to make, but does actually someone want it? In
 SolidWorks AFAIK you have to buy a special purpose module to import it
 (strange thing: while IDF3 is designed to go both ways, it seems that
 only the ECAD-MCAD route is used). IDF4 exists but AFAIK nobody uses it
 (like IPC356B!)

 General consensus is that STEP is the desiderable format (too bad IGES
 went out of popularity... it was freely documented and it's the
 precursor of STEP). However it's huge, no, bigger than huge, it's
 ISO-committee-designed. I have found this old message around, for more
 information:

 https://www.email-lists.org/pipermail/freearchitecture/2006-May/79.html

 The only STEP toolkit available for open source is the one in
 OpenCASCADE. The zipped tar is more than 110MB (it's a whole geometry
 engine for cad...), I feel it's a little big as a dependency :D It seems
 that freecad uses it.

 I tried to look inside a STEP file. It's quite readable actually, *if*
 you have the schema to cross reference with. Too bad you have to pay,
 a lot, for that. And extremely verbose; it's actually a dump of a graph
 database (a good idea for a cad format IMHO). Too bad that for
 describing a parallelepiped geometry the ST-Developer kit (commercial)
 uses no less than 215 object (*two hundred fifteen* objects). And that
 using the AP-203 (the entry level schema). I reordered and indented the
 thing, it's quite obvious what is going on. I'll try to add a hole in
 that box to see what infernal representation it spawns:D

 However it seems feasible to reverse engineer the format for generating
 at least something like the IDF3 representation: board shape and prisms
 for component shapes. Not exactly like having the 'perfect' model, but
 beats extruding the board profile from the dxf at least.

 Any ideas on this? IIRC there were some people interested in this kind
 of thing.

 --
 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




-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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] Script access to pcb plot

[Miguel Angel Ajo Pelayo]

On 24/03/2013, at 18:08, Lorenzo Marcantonio l.marcanto...@logossrl.com wrote:

 On Sun, Mar 24, 2013 at 12:51:38AM +0100, Miguel Angel Ajo Pelayo wrote:
 More questions,  is it possible to tell the plotter a background color?, 
 something weird for a plotter, right,
 but in SVG it would be great to dump in black background too.
 
 Uhmm no. The only background processing done is the initial black splat
 for the initial negative processing (and only in pcbnew).
 

Makes sense

 Nothing forbid you to do a svg-only interface for background color (or
 else do a virtual in the base class which is a no-op and implement it
 where significative). Both approach have deep philosophical implications XD
 

I think second makes more sense, no-op for everything else but SVG, and SVG
with background method implemented, and, may be some plotting option to set 
background
where available (like stereo),

 Look for 'fat interface' on the net for neverending holy wars (i.e.
 a virtual method against a dynamic cast for checking availability). Also
 known as: C++ has no duck typing XDXD. 

 
 Anyway the PS/PDF drivers already have the required code (the negative
 splat). Sadly ATM this is *not* done in the driver (I don't remember
 why...), look for the FillNegativeKnockout function in pcbnew. That
 could be easy moved in the initial page processing.
 

/** Prefill in black an area a little bigger than the board to prepare for the
 *  negative plot */
static void FillNegativeKnockout( PLOTTER *aPlotter, const EDA_RECT aBbbox )
{
const int margin = 5 * IU_PER_MM;   // Add a 5 mm margin around the board
aPlotter-SetNegative( true );
aPlotter-SetColor( WHITE );   // Which will be plotted as black
EDA_RECT area = aBbbox;
area.Inflate( margin );
aPlotter-Rect( area.GetOrigin(), area.GetEnd(), FILLED_SHAPE );
aPlotter-SetColor( BLACK );
}

SetNegative isn't what I'm looking for?, 
shouldn't I just implement that in SVG plotter? (usually done with a 100% 
width, 100% height rect black element)

 Of course the negative feature *can't* be replaced with something like
 that because gerber (which is in fact the most important driver)
 implements it natively.

 
 -- 
 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] Script access to pcb plot

[Miguel Angel Ajo Pelayo]

Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 23/03/2013, at 22:12, Lorenzo Marcantonio l.marcanto...@logossrl.com wrote:

 On Sat, Mar 23, 2013 at 05:20:37PM +0100, Miguel Angel Ajo Pelayo wrote:
   I've been playing with the PLOT CONTROLLER, and it works great, I added
 this to let SVG  PDF output in colors, but for some reason, the colors
 stay in the default color that kicad uses for a layer, I'm on an ongoing
 investigation about this.
 
 The SetColorMode is only to override the colors into black and white…

Well, for me it was that SVG  PDF remained in BW until I called 
SetColorMode(true)
on the plotter.

 the color is chosen by the individual plot routines, you have to track
 them down. I.e. the choice of the color is not in the plot layer, is in
 the pcbnew entity classes (most of it…)

Ok, now that I have some minutes again will restart my track down,
it would be nice to find a way to force colors at plot time. 


I'm thinking about some pcb-diff tool that takes git/bzr/svn revisions and 
renders
a diff image of the PCB with marks on the zone that changed, it shouldn't be 
very complicated :) pcb-svg-bitmap  pcb-svg-bitmap,   xoring both, and then 
making
some beatufilly marked images .



 
 -- 
 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] Script access to pcb plot

[Miguel Angel Ajo Pelayo]

Ok, the plotter will GetLayerColor from the board object, which makes sense,
but then why does the plotting options has a SetColor, does it work
for dxf? :)

Would it make sense to have a DEFAULT color, and int that case the plotter
asks for the board-GetLayerColor() and otherwise use the color in the 
color set in the plotting options ? 

I could get the same changing the board plotting colors, but may be that's not
desired in some situations.

Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 23/03/2013, at 23:25, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote:

 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 23/03/2013, at 22:12, Lorenzo Marcantonio l.marcanto...@logossrl.com 
 wrote:
 
 On Sat, Mar 23, 2013 at 05:20:37PM +0100, Miguel Angel Ajo Pelayo wrote:
  I've been playing with the PLOT CONTROLLER, and it works great, I added
 this to let SVG  PDF output in colors, but for some reason, the colors
 stay in the default color that kicad uses for a layer, I'm on an ongoing
 investigation about this.
 
 The SetColorMode is only to override the colors into black and white…
 
 Well, for me it was that SVG  PDF remained in BW until I called 
 SetColorMode(true)
 on the plotter.
 
 the color is chosen by the individual plot routines, you have to track
 them down. I.e. the choice of the color is not in the plot layer, is in
 the pcbnew entity classes (most of it…)
 
 Ok, now that I have some minutes again will restart my track down,
 it would be nice to find a way to force colors at plot time. 
 
 
 I'm thinking about some pcb-diff tool that takes git/bzr/svn revisions and 
 renders
 a diff image of the PCB with marks on the zone that changed, it shouldn't be 
 very complicated :) pcb-svg-bitmap  pcb-svg-bitmap,   xoring both, and 
 then making
 some beatufilly marked images .
 
 
 
 
 -- 
 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] Script access to pcb plot

[Miguel Angel Ajo Pelayo]

More questions,  is it possible to tell the plotter a background color?, 
something weird for a plotter, right,
but in SVG it would be great to dump in black background too.


I like the plotting design, is gorgeous 

Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 24/03/2013, at 00:21, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote:

 Ok, the plotter will GetLayerColor from the board object, which makes sense,
 but then why does the plotting options has a SetColor, does it work
 for dxf? :)
 
 Would it make sense to have a DEFAULT color, and int that case the plotter
 asks for the board-GetLayerColor() and otherwise use the color in the 
 color set in the plotting options ? 
 
 I could get the same changing the board plotting colors, but may be that's not
 desired in some situations.
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 23/03/2013, at 23:25, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote:
 
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 23/03/2013, at 22:12, Lorenzo Marcantonio l.marcanto...@logossrl.com 
 wrote:
 
 On Sat, Mar 23, 2013 at 05:20:37PM +0100, Miguel Angel Ajo Pelayo wrote:
 I've been playing with the PLOT CONTROLLER, and it works great, I added
 this to let SVG  PDF output in colors, but for some reason, the colors
 stay in the default color that kicad uses for a layer, I'm on an ongoing
 investigation about this.
 
 The SetColorMode is only to override the colors into black and white…
 
 Well, for me it was that SVG  PDF remained in BW until I called 
 SetColorMode(true)
 on the plotter.
 
 the color is chosen by the individual plot routines, you have to track
 them down. I.e. the choice of the color is not in the plot layer, is in
 the pcbnew entity classes (most of it…)
 
 Ok, now that I have some minutes again will restart my track down,
 it would be nice to find a way to force colors at plot time. 
 
 
 I'm thinking about some pcb-diff tool that takes git/bzr/svn revisions and 
 renders
 a diff image of the PCB with marks on the zone that changed, it shouldn't be 
 very complicated :) pcb-svg-bitmap  pcb-svg-bitmap,   xoring both, and 
 then making
 some beatufilly marked images .
 
 
 
 
 -- 
 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 Coding style checker

[Miguel Angel Ajo Pelayo]

Thanks for the feedback Carl,  I'll add it, it's a good idea, even
launching less if the result is big could also be useful.


2013/3/17 Carl Poirier carl.poirie...@gmail.com

 Hi Miguel,

 I tried your checkcoding tool and it works great. The only comment I can
 give you is I would add some blank lines between each file suggestions
 output so they are easier to find.

 Carl

 On Fri, Mar 15, 2013 at 7:25 PM, Miguel Angel Ajo Pelayo 
 miguelan...@nbee.es wrote:


I wrote it for myself, but as I think it can be interesting for
 everybody I added it to the tools directory,
 it's a tool that checks with 'bzr status' for modified files, and it
 dumps a suggestions from uncrustify,
 if you like them you can just say y , e launches an $EDITOR for the
 file, n or enter ignores.

 kicad ajo$* ./tools/checkcoding.py *
 Suggestions for: pcbnew/scripting/pcbnew_footprint_wizards.cpp
 --- pcbnew/scripting/pcbnew_footprint_wizards.cpp
 +++ pcbnew/scripting/pcbnew_footprint_wizards.cpp.uncrustified
 @@ -106,7 +106,7 @@

  PyObject*   result = CallMethod( aMethod, aArglist );

 -if(result )
 +if( result )
  {
  }

 Shall I clean pcbnew/scripting/pcbnew_footprint_wizards.cpp ? (y/N/E) y
 pcbnew/scripting/pcbnew_footprint_wizards.cpp UPDATED

 kicad ajo$

 At this moment, it will only work when called from the base project
 directory

 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo


 ___
 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





-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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] ncurses for python a-mingw-us

[Miguel Angel Ajo Pelayo]

Awesome Dick, one step closer to have a decent build environment for
python, that *CAN* cross compile, and make our life happier.

Thanks a lot for your efforts.


2013/3/17 Dick Hollenbeck d...@softplc.com


 dick@dick-intel:~/python/Python2.7.4$ bzr ci -m 'add support for
 ncurses, which enables completiion of extensions _curses.pyd and
 _curses_panel.pyd'

 Committing to:
 bzr+ssh://
 bazaar.launchpad.net/~kicad-testing-committers/kicad/python2.7.4-a-mingw-us/


 modified cmake/PythonExternalPackages.cmake
 modified cmake/extensions/CMakeLists.txt
 Committed revision
 9.


 I will add readline or libedit sometime, enabling extension 'readline'




 ___
 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




-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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] Locale fix in KiCAD is not working (breaks my build)

[Miguel Angel Ajo Pelayo]

Thanks edwin, I will try to fix it this night with a 2.8 compatible solution,

Also thanks a lot for the suggestion,

Anyway, I don't like changing the locale back and forth, I know the risk
is minimal, but in a multithreading UI environment It could break anything
running/displaying/printing elsewhere.

So, for the moment I will stay with a replace solution, or use a system printf
ignoring the locale settings. I will check for that other option on the change.

My solution could break if we go into a locale that sets numbers like 
1.000.000,


I'll change that in a few minutes and re-commit.



Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 15/03/2013, at 11:25, Edwin van den Oetelaar 
oetelaar.automatiser...@gmail.com wrote:

 Hello Miguel,
 
 My WX is 2.8
 
 Your WX is 2.9 I guess
 http://wiki.wxwidgets.org/Converting_everything_to_and_from_wxString
 
 I think there should be a cleaner way to handle this kind of thing.
 (comma/dot in floating point)
 Would it be possible to set LC_NUMERIC someway?
 
 char prvlocale[255];
 strcpy( prvlocale, wxSetlocale(LC_NUMERIC, NULL) );
 const char *oldLocale = wxSetlocale(LC_NUMERIC, C);
 
 /* DO STUFF HERE */
 
 if ( !oldLocale )
 {
 /* the current locale was not changed; no need to */
 /* restore the previous one... */
 } else {
 /* restore the original locale */
 wxSetlocale(LC_NUMERIC, prvlocale);
 }
 
 /home/oetelaar/kicad_dev/kicad/pcbnew/footprint_wizard.cpp: In member
 function ‘void FOOTPRINT_WIZARD_FRAME::ParametersUpdated(wxGridEvent)’:
 /home/oetelaar/kicad_dev/kicad/pcbnew/footprint_wizard.cpp:190: error:
 no matching function for call to ‘wxString::Replace(const char [2],
 const char [2])’
 /usr/include/wx-2.8/wx/string.h:1173: note: candidates are: size_t
 wxString::Replace(const wxChar*, const wxChar*, bool)
 make[2]: *** [pcbnew/CMakeFiles/_pcbnew.dir/footprint_wizard.cpp.o] Error 1
 make[1]: *** [pcbnew/CMakeFiles/_pcbnew.dir/all] Error 2


___
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] Locale fix in KiCAD is not working (breaks my build)

[Miguel Angel Ajo Pelayo]

Sorry, this is wxString to double… grr :)  I meant, wxString::FromCDouble :)

Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 15/03/2013, at 12:26, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote:

 From wxString methods, this one looks like our friend. Edwin, is it available 
 in wx2.8 ? 
 
 Conversion to numbers
 
 The string provides functions for conversion to signed and unsigned integer 
 and floating point numbers.
 
 All functions take a pointer to the variable to put the numeric value in and 
 return true if the entire string could be converted to a number. Notice if 
 there is a valid number in the beginning of the string, it is returned in the 
 output parameter even if the function returns false because there is more 
 text following it.
 
 bool  ToDouble (double *val) const
   Attempts to convert the string to a floating point number. 
  
 bool  ToCDouble (double *val) const 
 ---
   Variant of ToDouble() always working in C locale. 
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 15/03/2013, at 12:22, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote:
 
 sprintf and others will render also using the LC_NUMERIC, or locale set in 
 program, yet looking
 how to workaround this...
 
 http://www.stroustrup.com/3rd_loc.pdf
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 15/03/2013, at 11:30, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote:
 
 Thanks edwin, I will try to fix it this night with a 2.8 compatible 
 solution,
 
 Also thanks a lot for the suggestion,
 
 Anyway, I don't like changing the locale back and forth, I know the risk
 is minimal, but in a multithreading UI environment It could break anything
 running/displaying/printing elsewhere.
 
 So, for the moment I will stay with a replace solution, or use a system 
 printf
 ignoring the locale settings. I will check for that other option on the 
 change.
 
 My solution could break if we go into a locale that sets numbers like 
 1.000.000,
 
 
 I'll change that in a few minutes and re-commit.
 
 
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 15/03/2013, at 11:25, Edwin van den Oetelaar 
 oetelaar.automatiser...@gmail.com wrote:
 
 Hello Miguel,
 
 My WX is 2.8
 
 Your WX is 2.9 I guess
 http://wiki.wxwidgets.org/Converting_everything_to_and_from_wxString
 
 I think there should be a cleaner way to handle this kind of thing.
 (comma/dot in floating point)
 Would it be possible to set LC_NUMERIC someway?
 
 char prvlocale[255];
 strcpy( prvlocale, wxSetlocale(LC_NUMERIC, NULL) );
 const char *oldLocale = wxSetlocale(LC_NUMERIC, C);
 
 /* DO STUFF HERE */
 
 if ( !oldLocale )
 {
 /* the current locale was not changed; no need to */
 /* restore the previous one... */
 } else {
 /* restore the original locale */
 wxSetlocale(LC_NUMERIC, prvlocale);
 }
 
 /home/oetelaar/kicad_dev/kicad/pcbnew/footprint_wizard.cpp: In member
 function ‘void FOOTPRINT_WIZARD_FRAME::ParametersUpdated(wxGridEvent)’:
 /home/oetelaar/kicad_dev/kicad/pcbnew/footprint_wizard.cpp:190: error:
 no matching function for call to ‘wxString::Replace(const char [2],
 const char [2])’
 /usr/include/wx-2.8/wx/string.h:1173: note: candidates are: size_t
 wxString::Replace(const wxChar*, const wxChar*, bool)
 make[2]: *** [pcbnew/CMakeFiles/_pcbnew.dir/footprint_wizard.cpp.o] Error 1
 make[1]: *** [pcbnew/CMakeFiles/_pcbnew.dir/all] Error 2
 
 
 

___
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] Locale fix in KiCAD is not working (breaks my build)

[Miguel Angel Ajo Pelayo]

JP, it's a problem to pull a dependency on wxwidgets 2.9.x? and use the  
CDouble methods from
wxString? ,

It seems to work here, and LOCALE_IO seems dangerous regarding threading.

This is the FromCDouble implementation, they used a Replace, as my original 
solution :-)

wxString wxString::FromCDouble(double val, int precision)
{
wxCHECK_MSG( precision = -1, wxString(), Invalid negative precision );

#if wxUSE_STD_IOSTREAM  wxUSE_STD_STRING
// We assume that we can use the ostream and not wstream for numbers.
wxSTD ostringstream os;
if ( precision != -1 )
{
os.precision(precision);
os.setf(std::ios::fixed, std::ios::floatfield);
}

os  val;
return os.str();
#else // !wxUSE_STD_IOSTREAM
// Can't use iostream locale support, fall back to the manual method
// instead.
wxString s = FromDouble(val, precision);
#if wxUSE_INTL
wxString sep = wxLocale::GetInfo(wxLOCALE_DECIMAL_POINT,
 wxLOCALE_CAT_NUMBER);
#else // !wxUSE_INTL
// As above, this is the most common alternative value. Notice that here it
// doesn't matter if we guess wrongly and the current separator is already
// .: we'll just waste a call to Replace() in this case.
wxString sep(,);
#endif // wxUSE_INTL/!wxUSE_INTL

s.Replace(sep, .);
return s;
#endif // wxUSE_STD_IOSTREAM/!wxUSE_STD_IOSTREAM
}


 
Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 15/03/2013, at 12:57, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote:

 Jean Pierre, 
   It sounds like what I need, without adding dependencies on 2.9 or 3.0 (as 
 Edwin was pointing me privately).
 
   Anyway, that cannot be a problem with threading? or it just sets locale 
 locally and not App wide?
 
 Thanks a lot for the help,
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 15/03/2013, at 12:49, jp charras jp.char...@wanadoo.fr wrote:
 
 We have this kind of issue for all I/O file functions.
 
 In KiCad there is a class named LOCALE_IO to fix it
 thee ctor switches on the C fp notation, and the dtor restores the current 
 locale.
 See for instance the line:
 LOCALE_IO   toggle; // toggles on, then off, the C locale.
 in pcb_parser.cpp, line 333
 
 -- 
 Jean-Pierre CHARRAS
 
 
 ___
 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] Locale fix in KiCAD is not working (breaks my build)

[Miguel Angel Ajo Pelayo]

I think I will fix it back to   value.Replace(wxT( , ),wxT( . ));, which 
seems to work 
with wxwidgets 2.8 (was the wxT(..) missing what broke it)

And It's the internal implementation of wxwidgets wxString CDouble things .


Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 15/03/2013, at 13:23, jp charras jp.char...@wanadoo.fr wrote:

 Le 15/03/2013 12:57, Miguel Angel Ajo Pelayo a écrit :
 Jean Pierre,
It sounds like what I need, without adding dependencies on 2.9 or 3.0 (as 
 Edwin was pointing me privately).
 
Anyway, that cannot be a problem with threading? or it just sets locale 
 locally and not App wide?
 
 Thanks a lot for the help,
 I am thinking it is app wide.
 However the switch is only made during a very short time.
 And it is mandatory to read files with fp numbers.
 
 However if you want to convert by hand the fp number,
 value.Replace(,,.);
 should be
 value.Replace( wxT(,), wxT(.) );
 (Assuming there is no other separator used by some other languages).
 
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 15/03/2013, at 12:49, jp charras jp.char...@wanadoo.fr wrote:
 
 We have this kind of issue for all I/O file functions.
 
 In KiCad there is a class named LOCALE_IO to fix it
 thee ctor switches on the C fp notation, and the dtor restores the 
 current locale.
 See for instance the line:
 LOCALE_IO   toggle; // toggles on, then off, the C locale.
 in pcb_parser.cpp, line 333
 
 -- 
 Jean-Pierre CHARRAS
 
 
 ___
 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
 
 
 
 -- 
 Jean-Pierre CHARRAS
 


___
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] Locale fix in KiCAD is not working (breaks my build)

[Miguel Angel Ajo Pelayo]

On 15/03/2013, at 19:32, Dick Hollenbeck d...@softplc.com wrote:

 On 03/15/2013 11:39 AM, Miguel Angel Ajo Pelayo wrote:
 Ok, committed in 4008, cleanups included. 
 
 Finally I used the LOCALE_IO implementation, because converting in
 some situations didn't work, and my time was exhausting for today…
 
 I think there are some locale manipulators in std:: c++ that would
 let us do those conversions without switching system locale, but we will 
 have to try.
 
 
 We don't have to try.  We could wait until there is a problem.
 
 
I feel like planting bombs around ;)


 If or when there is a problem, I would fight to protect the interfaces
 we have become dependent on, one of which is OUTPUTFORMATTER::Print().
 You shouldn't try to re-implement this without my help.
 

In vsnprintf (used in OUTPUTFORMATTER::vprint) is affected by locale too, 
right?,
You mean that on locale changes we should protect those call?



 
 Writing good C++ software is really about placing and using carefully
 crafted interfaces.   After that you can ad lib in between the
 interfaces, so long as you honour them.

Yes :)

 
 
 A C++ thread can be like the quirky guy who walks up the stairs of a
 skyscraper, travelling across each floor and then back into the
 stairwell to continue ascending.
 
 When he travels across each floor, he is wearing the proper attire and
 acting properly.  This is the interface. 
 
 But in the stairwell he very well may be acting quite differently,
 nobody knows, nobody cares.   Could be naked in there, could be
 walking on his hands, screaming, yelling.   This is the implementation.
 

Good simile, 

Yes, I know the problem, and the GIL python think made me remember that one
must not forget, reentrancy, and thread-safety are your friends!!

In pcbnew, I cannot imagine yet a situation when all this could happen, 
somebody printing a report somehow, while hits a key 
or writes a file?, sounds quite improbable. But yet I'm sure there are 
possibilities we didn't think of… or not.. :)



 It pays to know which part of the C++ thread you are dealing with.  
 Saves some embarrassment, and makes for better and more easily
 maintained code.  Because you can always smoke bomb the implementation.
 


Is OUTPUTFORMATTER to be used for tasks like the one I was dealing with above?, 
 printing a %lf to a string?,
For the name, it looks like a class to be used when dealing with file writing, 
didn't have enough time to look inside yet.





___
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] About Scripting and object interface changes,

[Miguel Angel Ajo Pelayo]

http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/revision/4001

Hehe, nice cleanup, it's something that must be done.

Anyway, interface changes to core objects, should be tracked carefully once we 
have scripting published, 
a change like this could break scripts working on the field:

151 void SetPos( const wxPoint aPoint ) { m_Pos = aPoint; }
152 const wxPoint GetPos() const { return m_Pos; }
 174void SetPosition( const wxPoint aPoint ) { m_Pos = aPoint; }
 175const wxPoint GetPosition() const { return m_Pos; }


My opinion is, these changes need to be done, the cleaner, the better, but once 
scripting is widely deployed,
we must provide some (scripting side wrappers) for compatibility, for example 
redirecting SetPos to SetPosition on scripting,
and sending an deprecated warning for some set of releases.




Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

___
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 Scripting and object interface changes,

[Miguel Angel Ajo Pelayo]

Awesome Adam!!,

It really sounds great, that was fast!, if you can, please send me a ssh 
pub-key from your server privately, and 
I will create and account at kicad-pcb.org to let you upload the releases to 
the right place with 
a simple/automated scp :-)

Cheers!! :)


Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 14/03/2013, at 16:52, Adam Wolf adamw...@feelslikeburning.com wrote:

 I've got the Mac version building after every commit internally.  I hope to 
 add Linux tonight, and then as soon as the upstream patches for Windows 
 scripting builds get commited, I'll add that as well.  Once I trust them a 
 bit more, I can push them out to wherever.
  
 I can definitely make the build server run through a set of scripts and fail 
 the build if any of them die.
  
 While I'm hesitant to open up the build server itself (it's on my home 
 network), I'm working on having it pull all the configuration data and build 
 scripts from a publically accessible repository.
  
 If anyone has publically accesible branches they want me to run through my 
 build server, let me know.
  
 Adam Wolf
 Wayne and Layne, LLC
 On Thu, Mar 14, 2013 at 10:45 AM, Miguel Angel Ajo Pelayo 
 miguelan...@nbee.es wrote:
 First and important: Encapsultion must go first, I'm not against it but the 
 opposite. Read what follows for clarification:
 
 
 My concern is about the scripts that build functionality on kicad objects, 
 scripts that people will build and
 should be maintained separately to KiCad. Now it's not important at all 
 because the scripting base is tiny-0,
 when it grows, and we make changes to scriptable object interfaces, we will 
 have to take care about this.
 
 So the earlier we encapsulate, the better.
 
 And in the future, if we change method names, we should (in the script side) 
 provide some fallback/translation
 methods with deprecation warning.
 
 * Automated testing:
 
 , I think the scripting to-do should contain the making of a good bunch of 
 test cases that cover all possible
 object operations that we are willing to support. I talked with Adam Wolf 
 about that, it could be great
 to get them automatically checked on every commit, we can also extend this to 
 check internal KiCad behaviors
 in an automated way :)
 
 
 * About build dependencies  swig:
 
 
 
 Compilation must always work, at this moment, cmake isn't able to fetch 
 dependencies from .i files to .h files,
 or at least, I wasn't able to set it up.
 
 In my case I just remove the pcbnew_wrapper.cpp and 
 scripting/pcbnew_wrapper.cxx and called
 make again, so it compiled gracefully.
 
 Getting dependencies for that automatically would be highly desired, and must 
 be in my todo list at any point.
 
 
 
 
 
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 14/03/2013, at 16:37, Wayne Stambaugh stambau...@verizon.net wrote:
 
  On 3/14/2013 11:07 AM, Miguel Angel Ajo Pelayo wrote:
  http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/revision/4001
 
  Hehe, nice cleanup, it's something that must be done.
 
  Anyway, interface changes to core objects, should be tracked carefully
  once we have scripting published,
  a change like this could break scripts working on the field:
 
  151
 
 void SetPos( const wxPoint aPoint ) { m_Pos = aPoint; }
  152
 
 const wxPoint GetPos() const { return m_Pos; }
 
  174
 void SetPosition( const wxPoint aPoint ) { m_Pos = aPoint; }
 
  175
 const wxPoint GetPosition() const { return m_Pos; }
 
 
  My opinion is, these changes need to be done, the cleaner, the better,
  but once scripting is widely deployed,
  we must provide some (scripting side wrappers) for compatibility, for
  example redirecting SetPos to SetPosition on scripting,
  and sending an deprecated warning for some set of releases.
 
  Sorry about that.  I forgot rebuild the Python scripting support to see
  if I broke anything.  I'm still getting used to the idea that it is now
  part of KiCad.
 
  Doesn't this kind of code automatically get updated the next time the
  scripting code is reSWIGged or is this something that has to be hand
  tweaked every time?  I am familiar with SWIG so if need be, I will fix
  the SWIG stuff from now on.  I'm thinking the python scripting is going
  to have to closely track the compiled KiCad code for the foreseeable
  future.  The will be a great of upheaval with the forthcoming footprint
  library table stuff.  The last thing I want to do is stop the
  encapsulation work just to support Python scripting.
 
 
 
 
 
  Miguel Angel Ajo
  http://www.nbee.es
  +34911407752
  skype: ajoajoajo
 
 
 
 
 ___
 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

Re: [Kicad-developers] About Scripting and object interface changes,

[Miguel Angel Ajo Pelayo]

You're right,  it will be hard to provide compatibility at that point without 
doing an extensive/intensive work.

I think, at that change point we must provide as much back-compatibility as we 
can for the scripting, and that's all.

And we must let use the scripting now, with a little warning about this for 
users. So they can know that the current interface 
isn't frozen yet.



Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 14/03/2013, at 17:44, Wayne Stambaugh stambau...@verizon.net wrote:

 On 3/14/2013 11:45 AM, Miguel Angel Ajo Pelayo wrote:
 First and important: Encapsultion must go first, I'm not against it but the 
 opposite. Read what follows for clarification:
 
 
 My concern is about the scripts that build functionality on kicad objects, 
 scripts that people will build and
 should be maintained separately to KiCad. Now it's not important at all 
 because the scripting base is tiny-0,
 when it grows, and we make changes to scriptable object interfaces, we will 
 have to take care about this.
 
 So the earlier we encapsulate, the better.
 
 This is a work in progress.  I think we are getting to the point where
 there is not too much encapsulation work left.  However, this is only
 the first step in the process.  One of the proposed changes is to create
 a standard geometric model for all base objects in Pcbnew and Eeschema
 which means there will likely be some substantial changes to the base
 objects.  Once the encapsulation work is complete, there should be an
 effort made to clean up the some of the low object interfaces to make
 them more coherent.
 
 
 And in the future, if we change method names, we should (in the script side) 
 provide some fallback/translation 
 methods with deprecation warning.
 
 * Automated testing:
 
 , I think the scripting to-do should contain the making of a good bunch of 
 test cases that cover all possible
 object operations that we are willing to support. I talked with Adam Wolf 
 about that, it could be great
 to get them automatically checked on every commit, we can also extend this 
 to check internal KiCad behaviors 
 in an automated way :)
 
 
 * About build dependencies  swig:
 
 
 
 Compilation must always work, at this moment, cmake isn't able to fetch 
 dependencies from .i files to .h files, 
 or at least, I wasn't able to set it up.
 
 In my case I just remove the pcbnew_wrapper.cpp and 
 scripting/pcbnew_wrapper.cxx and called
 make again, so it compiled gracefully.  
 
 Getting dependencies for that automatically would be highly desired, and 
 must be in my todo list at any point.
 
 
 
 
 
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 14/03/2013, at 16:37, Wayne Stambaugh stambau...@verizon.net wrote:
 
 On 3/14/2013 11:07 AM, Miguel Angel Ajo Pelayo wrote:
 http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/revision/4001
 
 Hehe, nice cleanup, it's something that must be done.
 
 Anyway, interface changes to core objects, should be tracked carefully
 once we have scripting published, 
 a change like this could break scripts working on the field:
 
 151
 
   void SetPos( const wxPoint aPoint ) { m_Pos = aPoint; }
 152
 
   const wxPoint GetPos() const { return m_Pos; }
 
 174
   void SetPosition( const wxPoint aPoint ) { m_Pos = aPoint; }
 
 175
   const wxPoint GetPosition() const { return m_Pos; }
 
 
 My opinion is, these changes need to be done, the cleaner, the better,
 but once scripting is widely deployed,
 we must provide some (scripting side wrappers) for compatibility, for
 example redirecting SetPos to SetPosition on scripting,
 and sending an deprecated warning for some set of releases.
 
 Sorry about that.  I forgot rebuild the Python scripting support to see
 if I broke anything.  I'm still getting used to the idea that it is now
 part of KiCad.
 
 Doesn't this kind of code automatically get updated the next time the
 scripting code is reSWIGged or is this something that has to be hand
 tweaked every time?  I am familiar with SWIG so if need be, I will fix
 the SWIG stuff from now on.  I'm thinking the python scripting is going
 to have to closely track the compiled KiCad code for the foreseeable
 future.  The will be a great of upheaval with the forthcoming footprint
 library table stuff.  The last thing I want to do is stop the
 encapsulation work just to support Python scripting.
 
 
 
 
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 
 
 
 


___
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] Mac OSX build, with scripting, codename wife

[Miguel Angel Ajo Pelayo]

I also think, that it's important to provide a way for users to have access to 
our modules from outside kicad, 
that can be easily fixed letting them set (or appending to) PYTHONPATH, as I'm 
doing now for MacOSX, 

In linux are you sure they do like that?, in windows for sure.

If you bundle your own python in linux you stop getting access to all the 
libraries available systemwide,
that's important too, where possible (win32 is a different story)


Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 11/03/2013, at 14:14, Adam Wolf adamw...@feelslikeburning.com wrote:

 I believe Blender has a Python environment of its own embedded inside of it, 
 and doesn't reuse a system Python.
 
 Adam Wolf
 Wayne and Layne, LLC
 
 
 On Sun, Mar 10, 2013 at 10:21 PM, Dick Hollenbeck d...@softplc.com wrote:
 
 On Mar 10, 2013 8:32 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es 
 wrote:
 
 
  On 11/03/2013, at 03:25, Dick Hollenbeck d...@softplc.com wrote:
 
 
  On Mar 10, 2013 8:10 PM, Adam Wolf adamw...@feelslikeburning.com wrote:
  
   Dick,
  
   We can do it either way.  We can push binaries up to the PPA, or we can 
   continue to do the bzrbuilder recipe-PPA.  I would actually be doing 
   the bzrbuilder recipe on my local machine.
  
   I can always fix the current cmake issue and do the Mac and eventually 
   Windows builds.  I'd like to get Linux builds happening locally for 
   Fedora users anyway.
  
   Anyway, I'm going to fix the cmake pythonpath thing, and get osx 
   autobuilds working first, and we can revisit the others when those are 
   tested and working.
 
  Speaking of pyhonpath, we need to rethink where we are going to put python 
  modules, even for the case when we are not installing to a staging dir for 
  purposes of packaging.
 
  Installing things that may need to be edited, into a read only (root 
  writable)
  dir is not a practice that we have to continue.  If we allow for setting 
  env vars, then pythonpath can be modified to point additionally to a place 
  that is convenient for kicad python module editor people.
 
  So I am not content with current. Cmakelists.txt strategy regarding over 
  usage of system dirs.
 
 My concern remains, as stated above.  Think well beyond the current situation 
 to many more modules.
 
 And to the day when pcbnew is primatily a dso/dll.
 
 So no, I am not on board with your suggestion.
 
 Just lets find a place where modules can go that is a writable dir.
 
 After all don't we want people writing them?
 
 If you want to move into the future you have to be willing to challenge the 
 past. 
 
 How does blender do it?
 
 
 
  There, may be it makes sense to make a second package for 
  KICAD_SCRIPTING_MODULES, as it's just a module to python,
  it could be the case that somebody wanted to install the pcbnew module in a 
  server, without installing kicad itself, for example.
 
  That should go to site-packages of python.
 
  For kicad itself, the modules don't need to be installed anywhere, they are 
  linked together into pcbnew itself to allow introspection,
  so may be for making the normal kicad ppa build, KICAD_SCRIPTING_MODULES 
  should be disabled,
  and then a second build that only makes the KICAD_SCRIPTING_MODULES, that 
  needs some cmake scripts rework.
 
  Does it make sense?
 
  
   Adam Wolf
   Wayne and Layne, LLC
  
   On Mar 10, 2013 8:45 PM, Dick Hollenbeck d...@softplc.com wrote:
  
  
   On Mar 10, 2013 6:50 PM, Adam Wolf adamw...@feelslikeburning.com 
   wrote:
   
Miguel,
   
Wayne and Layne recently purchased a Mac Mini for Kicad builds.  We 
have a spare Windows license too, so I can host a Windows and Linux 
VM on it as well.
   
I can set this up on a Jenkins instance.  I'm considering doing the 
same with the Linux builds.  While I like the PPA autobuilder, the 
build environment isn't like what the devs use, so the PPA breaks on 
a regular basis--and then it's hard to see why, because my box isn't 
emulating the PPA environment exactly.  This is currently the case 
with the cmake thing.
   
I can even push my built packages back up to my PPA, so the 
transition could be seamless to end users.
   
What do you guys think?
  
   The PPA concept is a familiar and trusted one in ubuntu circles, would 
   not want to lose that trust factor among new users of the daily testing 
   builds.
  
   Note I said users.  These binaries are for usage first, testing is a 
   secondary issue, which is in proportion to numbers of users actually 
   using it.
  
   
Adam Wolf
Wayne and Layne, LLC
   
   
On Sun, Mar 10, 2013 at 7:43 PM, Miguel Angel Ajo Pelayo 
miguelan...@nbee.es wrote:
   
This tuesday I must decide if I keep renewing our *ltium license, or 
if we won't.
   
I'm thinking about donating 1/2 - 2/3 of it's cost to buy one of 
those mac minis to 
provide continuous integration/building of kicad binaries for OSX

Re: [Kicad-developers] Mac OSX build, with scripting, codename wife

[Miguel Angel Ajo Pelayo]

I think I understand what you mean Dick, we need to provide a default way 
to compile and install python modules to a prefix, 
and also the set of default scripts  module libraries,  wizards, it's that 
what you mean?

But anyway, when somebody installs a package system wide, we must provide 
our modules to them.

Anyway, if you're talking about pcbnew.py, for example, that should not 
be modified by humans, as it's
auto generated swig mess (nice and useful mess by the way) that get's rebuilt 
/ overwritten by new compilation.

Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 11/03/2013, at 15:06, Dick Hollenbeck d...@softplc.com wrote:

 On 03/11/2013 08:25 AM, Adam Wolf wrote:
 Miguel,
 
 I only know about Blender/Python on Windows.
 
 I think site-packages (dist-packages on Debian/Ubuntu) might be the
 right way to do it.  Put the python modules in a place that's
 already on the PYTHONPATH that package managers already expect folks
 to put modules into.  The idea of having an environment variable to
 tell CMake another place to put it is great, but I think
 site-packages is a sane default.
 
 I know of no python programmers named root.
 
 No thanks.  My name is also not root.
 
 So on my system, this would be considered extremely inconvenient.  I'd
 like to actually be able to edit the scripts.  If the intention is to
 make them not editable, then we should write them in C++ and compile them.
 
 
 


___
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 on Windows Fix

[Miguel Angel Ajo Pelayo]

I'm going to test it right now, give me 5 minutes :)

Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 11/03/2013, at 15:25, Dick Hollenbeck d...@softplc.com wrote:

 class PyLOCK
 {
PyGILState gil_state;
 
 public:
PyLOCK()  { gil_state = PyGILState_Ensure(); }
~PyLOCK() { PyGILState_Release( gil_state ); }
 };

___
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 on Windows Fix

[Miguel Angel Ajo Pelayo]

Ok, more than 5 minutes, removing WXPYTHON scripting needs a full pcbnew 
rebuild, probably around 15 min… :)

Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 11/03/2013, at 15:26, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote:

 I'm going to test it right now, give me 5 minutes :)
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 11/03/2013, at 15:25, Dick Hollenbeck d...@softplc.com wrote:
 
 class PyLOCK
 {
PyGILState gil_state;
 
 public:
PyLOCK()  { gil_state = PyGILState_Ensure(); }
~PyLOCK() { PyGILState_Release( gil_state ); }
 };
 

___
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] Mac OSX build, with scripting, codename wife

[Miguel Angel Ajo Pelayo]

That looks quite much to the wrapping I had to do in MacOX to avoid static 
linking, 
where it's uncommon for normal users to put new libraries in the system paths:

I rename pcbnew to pcbnew.bin and put the loader as pcbnew, same for all the 
other apps,
it just builds a pointer to the libraries, the python path, and kicad stock 
libraries, and then
boots the app itself.

#!/bin/sh

# this is script wraps the original binary application, 
# and sets the library paths just before launching

DIR=$( cd $( dirname ${BASH_SOURCE[0]} )  pwd )

export KICAD_APP=$DIR/../../../kicad.app
export KICAD_DATA=$DIR/../../../data

# let the apps find the libraries at startup
export DYLD_LIBRARY_PATH=$KICAD_APP/Contents/Frameworks:$DYLD_LIBRARY_PATH

# let python scripting find our modules
export 
PYTHONPATH=$KICAD_APP/Contents/Frameworks/python2.7/site-packages/:$PYTHONPATH

export KICAD=$KICAD_DATA

$DIR/`basename $0`.bin $*


Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 11/03/2013, at 15:33, Dick Hollenbeck d...@softplc.com wrote:

 For the 4th time, yes.  And it would not bother me at all to be
 different from a decade of other python users, but like blender users.
 
 I am happy to be different, when I know I am helping myself.
 
 Maintaining a distinction between two categories of kicad python
 modules is a low priority to me.
 
 For linux users, the installer can set PYTHONPATH on the commandline,
 and this can be done in a desktop launcher (icon or menu):
 
 
 $ PYTHONPATH=writeable-convenient-dir:$PATHONPATH  pcbnew
 
 $ PYTHONPATH=writeable-convenient-dir:$PATHONPATH  kicad
 
 
 I believe these settings would last as long as the program is running,
 only.  Which is about what we want.
 
 Might need to to put sh in front of that.

___
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] Mac OSX build, with scripting, codename wife

[Miguel Angel Ajo Pelayo]

For me, the most reasonable solution sounds like providing both options, 
being able to enforce a user-local destination for python modules/libraries,
or a system wide standard one.

In development, or single user installations, first is better, for apt-get 
install
or equivalent system-wide installations, the second sounds correct.

Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 11/03/2013, at 16:20, Adam Wolf adamw...@feelslikeburning.com wrote:

 If we store all the python modules in a user's home directory, how do they 
 get there?  Does kicad put them there, or does the installer?
 
 While we should provide the python modules like footprint_wizard.py for 
 download, we cannot easily provide the swiggy modules like pcbnew.py for 
 download, because they depend upon both the kicad source and state on the 
 user's system.
 
 If the installer is putting them there, I hope we don't have a situation 
 where the dll-like swiggy python modules are only in one home directory.  
 This could create issues if you delete your dotfiles or another user wants to 
 use Python support.
 
 Adam Wolf
 
 On Mar 11, 2013 9:39 AM, Miguel Angel Ajo Pelayo miguelan...@nbee.es 
 wrote:
 
 That looks quite much to the wrapping I had to do in MacOX to avoid static 
 linking, 
 where it's uncommon for normal users to put new libraries in the system paths:
 
 I rename pcbnew to pcbnew.bin and put the loader as pcbnew, same for all 
 the other apps,
 it just builds a pointer to the libraries, the python path, and kicad stock 
 libraries, and then
 boots the app itself.
 
 #!/bin/sh
 
 
 # this is script wraps the original binary application, 
 
 # and sets the library paths just before launching
 
 
 DIR=$( cd $( dirname ${BASH_SOURCE[0]} )  pwd )
 
 
 export KICAD_APP=$DIR/../../../kicad.app
 
 export KICAD_DATA=$DIR/../../../data
 
 
 # let the apps find the libraries at startup
 
 export DYLD_LIBRARY_PATH=$KICAD_APP/Contents/Frameworks:$DYLD_LIBRARY_PATH
 
 
 # let python scripting find our modules
 
 export 
 PYTHONPATH=$KICAD_APP/Contents/Frameworks/python2.7/site-packages/:$PYTHONPATH
 
 
 export KICAD=$KICAD_DATA
 
 
 $DIR/`basename $0`.bin $*
 
 
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 11/03/2013, at 15:33, Dick Hollenbeck d...@softplc.com wrote:
 
 For the 4th time, yes.  And it would not bother me at all to be
 different from a decade of other python users, but like blender users.
 
 I am happy to be different, when I know I am helping myself.
 
 Maintaining a distinction between two categories of kicad python
 modules is a low priority to me.
 
 For linux users, the installer can set PYTHONPATH on the commandline,
 and this can be done in a desktop launcher (icon or menu):
 
 
 $ PYTHONPATH=writeable-convenient-dir:$PATHONPATH  pcbnew
 
 $ PYTHONPATH=writeable-convenient-dir:$PATHONPATH  kicad
 
 
 I believe these settings would last as long as the program is running,
 only.  Which is about what we want.
 
 Might need to to put sh in front of that.
 

___
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 on Windows Fix

[Miguel Angel Ajo Pelayo]

Hmm, I recompiled several times (without the WXPYTHON option) , not getting the 
footprint wizard, and then I realized that somebody changed this ifdef:

#ifdef KICAD_SCRIPTING_WXPYTHON
m_mainToolBar-AddTool( ID_MODEDIT_NEW_MODULE_FROM_WIZARD, wxEmptyString,
KiBitmap( module_wizard_xpm ),
_( New module from footprint wizard ) );
#endif


in tool_modedit.cpp

it only needs to be KICAD_SCRIPTING, there is no WXPYTHON dependency in the 
footprint wizard :-),
when I made that I wanted to be scripting language agnostic, we can even write 
C++ wizards with current
implementation just subclassing the FootprintWizard class  
(class_footprint_wizard.h/cpp) :)

I'm going to change it, and make the test :-)


Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 11/03/2013, at 15:30, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote:

 Ok, more than 5 minutes, removing WXPYTHON scripting needs a full pcbnew 
 rebuild, probably around 15 min… :)
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 11/03/2013, at 15:26, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote:
 
 I'm going to test it right now, give me 5 minutes :)
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 11/03/2013, at 15:25, Dick Hollenbeck d...@softplc.com wrote:
 
 class PyLOCK
 {
PyGILState gil_state;
 
 public:
PyLOCK()  { gil_state = PyGILState_Ensure(); }
~PyLOCK() { PyGILState_Release( gil_state ); }
 };
 
 

___
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 on Windows Fix

[Miguel Angel Ajo Pelayo]

Don't worry Wayne, I will commit it in a few seconds, I'm trying, but my bzr 
just not logged in in a new dev machine I'm using :)

I sometimes yet need to look at my notes to re-discover what did each python 
related define… 


Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 12/03/2013, at 01:37, Wayne Stambaugh stambau...@verizon.net wrote:

 On 3/11/2013 7:48 PM, Miguel Angel Ajo Pelayo wrote:
 Hmm, I recompiled several times (without the WXPYTHON option) , not
 getting the footprint wizard, and then I realized that somebody changed
 this ifdef:
 
 #ifdef KICAD_SCRIPTING_WXPYTHON
 m_mainToolBar-AddTool( ID_MODEDIT_NEW_MODULE_FROM_WIZARD,
 wxEmptyString,
 KiBitmap( module_wizard_xpm ),
 _( New module from footprint wizard ) );
 #endif
 
 
 in tool_modedit.cpp
 
 it only needs to be KICAD_SCRIPTING, there is no WXPYTHON dependency in
 the footprint wizard :-),
 
 Sorry about that.  I didn't realize that wxPython was not in play here.  I 
 incorrectly assumed since it was dealing with UI elements (the toolbar) that 
 wxPython was in play.  I'll fix it to look for KICAD_SCRIPTING.
 
 Wayne
 
 when I made that I wanted to be scripting language agnostic, we can even
 write C++ wizards with current
 implementation just subclassing the FootprintWizard class
  (class_footprint_wizard.h/cpp) :)
 
 I'm going to change it, and make the test :-)
 
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 11/03/2013, at 15:30, Miguel Angel Ajo Pelayo miguelan...@nbee.es
 mailto:miguelan...@nbee.es wrote:
 
 Ok, more than 5 minutes, removing WXPYTHON scripting needs a full
 pcbnew rebuild, probably around 15 min… :)
 
 Miguel Angel Ajo
 http://www.nbee.es http://www.nbee.es/
 +34911407752
 skype: ajoajoajo
 
 On 11/03/2013, at 15:26, Miguel Angel Ajo Pelayo miguelan...@nbee.es
 mailto:miguelan...@nbee.es wrote:
 
 I'm going to test it right now, give me 5 minutes :)
 
 Miguel Angel Ajo
 http://www.nbee.es http://www.nbee.es/
 +34911407752
 skype: ajoajoajo
 
 On 11/03/2013, at 15:25, Dick Hollenbeck d...@softplc.com
 mailto:d...@softplc.com wrote:
 
 class PyLOCK
 {
   PyGILState gil_state;
 
 public:
   PyLOCK()  { gil_state = PyGILState_Ensure(); }
   ~PyLOCK() { PyGILState_Release( gil_state ); }
 };
 
 
 
 
 
 ___
 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] Mac OSX build, with scripting, codename wife

[Miguel Angel Ajo Pelayo]

On 10/03/2013, at 11:30, Martijn Kuipers martijn.kuip...@gmail.com wrote:

 Viva,
 
 On Mar 10, 2013, at 10:23 AM, Miguel Angel Ajo Pelayo miguelan...@nbee.es 
 wrote:
 
 Hehe, yes, you're right, universal is ppc+x86+x64, x86+x64 is only multi 
 binary.
 
 My system cannot compile for ppc (it's a mountain lion and has not ppc sdk 
 or rosseta anymore -the emulation layer-.)
 
 Neither can mine. I usually build single versions, because otherwise you are 
 basically downloading the program twice (or thrice when also including ppc).
 

Hehehe, yes, I talked with Marco about that, and he told me that nobody asked 
for ppc version yet, and his binaries are i386+x64 so probably we shouldn't 
spent time on that as long as we provide the means to build.

 
 Edit the wx patch in patches directory and look for a line that removes ppc 
 (if you want to try with ppc) :)
 Also only Mountain Lion (so happy to not have Rosetta around).
 
 
 I send your thanks to my wife :)
 

Sent them to her, :D, she smiled ;)

 I'm also thinking of a new structure to keep the demos  system libs out of 
 the app bundle but in the app directory, as some other apps do
 
 like
 
 Applications/kicad/kicad.app (with the libs,etc)
 Applications/kicad/pcbnew.app
 Applications/kicad/*.app  
 Applications/kicad/shared/{libs,modules,templates,plugins…}
 
 
 I was always hoping to see the libraries (DLLs) to go into /Library/Kicad, 
 so we can keep the memory footprint down of the separate Kicad components. 
 But it is not a trivial task, so it seems.
 I am not following what you want to do. Is it like:
 /Applications/kicad/kicad.app - the app with the libs
 /Applications/kicad/libraries - footprints, components, etc.
 /Applications/kicad/scripts - python user scripts
 /Applications/kicad/doc - documentation and demos
 ?
 

Look to the patches/loader.sh on github, at this moment, all the libraries 
*.dylib and files go inside kicad.app/Frameworks/ and the other apps use them 
from there (../../../kicad.app/Frameworks) , wx and python-site mainly. 

Also there are the demos+modules+etc in kicad.app/Resources/ or something like 
that  that's what I was planning to pull out of kicad.app again and yet leave 
it findable for all the apps.



 Kind regards,
 Martijn
 
 
 
 
 
 
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 10/03/2013, at 11:18, Martijn Kuipers martijn.kuip...@gmail.com wrote:
 
 Hi Miguel,
 
 Downloading as we speak. On the github page you call it a universal OSX 
 binary, but that would mean it supports both PowerPC and Intel based MACS, 
 whereas is this email announcement you call it i386 +x64 build.
 
 I'm looking forward in compiling it myself, just to see if your solution is 
 portable. 
 
 Thanks also to your wife ;-)
 
 /Martijn
 
 
 On Mar 10, 2013, at 2:19 AM, Miguel Angel Ajo Pelayo miguelan...@nbee.es 
 wrote:
 
 
 
 Hi, 
 
 I've been working on the release of Kicad with scripting for MacOSX, also 
 tried to package it all together with 
 all kicad libs, and the templates.
 
 It's supposed to be a i386 + x64 binary build, with scripting support.
 
 kicad-scripting-osx-latest.zip
 
 
 It has all the new kicad templates system and libraries inside kicad.app, 
 and it's supposed to be accessible from all the other apps.
 
 I'm not sure if it will only work in 10.8, or may be 10.5-10.8, (it has a 
 dependency to system's python2.7).
 
 If there is any adventurous out there, please try, and tell me how does it 
 work (or doesn't).
 
 
 PS:
 
The codename for the release is wife, as my wife has been taking care 
 all saturday of our little Margarita, so she's a time donor to kicad now 
 too ;)
 
 My build  packaging script is temporarily here, for just in case anyone 
 wants to compile himself.. 
 https://github.com/mangelajo/KicadOSXBuilder
 
 Cheers!! ;)
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 ___
 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] Mac OSX build, with scripting, codename wife

[Miguel Angel Ajo Pelayo]

 I was always hoping to see the libraries (DLLs) to go into /Library/Kicad, 
 so we can keep the memory footprint down of the separate Kicad components. 
 But it is not a trivial task, so it seems.
 I am not following what you want to do. Is it like:
 /Applications/kicad/kicad.app - the app with the libs
 /Applications/kicad/libraries - footprints, components, etc.
 /Applications/kicad/scripts - python user scripts
 /Applications/kicad/doc - documentation and demos
 ?
 
 
 Look to the patches/loader.sh on github, at this moment, all the libraries 
 *.dylib and files go inside kicad.app/Frameworks/ and the other apps use them 
 from there (../../../kicad.app/Frameworks) , wx and python-site mainly. 
 
 Also there are the demos+modules+etc in kicad.app/Resources/ or something 
 like that  that's what I was planning to pull out of kicad.app again and yet 
 leave it findable for all the apps.
 


https://github.com/mangelajo/KicadOSXBuilder/commit/c41f116620182d56c07aee75cd751fe1ba922f7f
This is the change, I also re-uploaded 
kicad-scripting-osx-3992.zip

:-)
I think it's better like this, people can go into the data directory and 
change/fetch whatever they like :)


 
 
 Kind regards,
 Martijn
 
 
 
 
 
 
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 10/03/2013, at 11:18, Martijn Kuipers martijn.kuip...@gmail.com wrote:
 
 Hi Miguel,
 
 Downloading as we speak. On the github page you call it a universal OSX 
 binary, but that would mean it supports both PowerPC and Intel based MACS, 
 whereas is this email announcement you call it i386 +x64 build.
 
 I'm looking forward in compiling it myself, just to see if your solution 
 is portable. 
 
 Thanks also to your wife ;-)
 
 /Martijn
 
 
 On Mar 10, 2013, at 2:19 AM, Miguel Angel Ajo Pelayo miguelan...@nbee.es 
 wrote:
 
 
 
 Hi, 
 
 I've been working on the release of Kicad with scripting for MacOSX, also 
 tried to package it all together with 
 all kicad libs, and the templates.
 
 It's supposed to be a i386 + x64 binary build, with scripting support.
 
 kicad-scripting-osx-latest.zip
 
 
 It has all the new kicad templates system and libraries inside kicad.app, 
 and it's supposed to be accessible from all the other apps.
 
 I'm not sure if it will only work in 10.8, or may be 10.5-10.8, (it has a 
 dependency to system's python2.7).
 
 If there is any adventurous out there, please try, and tell me how does 
 it work (or doesn't).
 
 
 PS:
 
The codename for the release is wife, as my wife has been taking 
 care all saturday of our little Margarita, so she's a time donor to 
 kicad now too ;)
 
 My build  packaging script is temporarily here, for just in case anyone 
 wants to compile himself.. 
 https://github.com/mangelajo/KicadOSXBuilder
 
 Cheers!! ;)
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 ___
 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 on Windows Fix

[Miguel Angel Ajo Pelayo]

Awesome!, 

Brian, I'm sorry that I left that gift for you to debug. I really don't 
understand the situation yet, It's supposed that 
one must block the python VM thread before launching any new call into it.  All 
the call methods should be 
surrounded by the lock, because python VM always run in a single thread, even 
if you launch a thread inside, they
won't even run in parallel as the VM can't (one of biggest python failures)

It clearly seems that also building values, or even using the Py_DECREF to 
dereference a created
value needs to be locked too.

   Thanks brian, I must finish something for a deadline tomorrow (taking longer 
than expected, and spent more 
time on Kicad that I should have spent) but I really want to discover the 
underlying reason.

Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 10/03/2013, at 23:52, Brian Sidebotham brian.sidebot...@gmail.com wrote:

 Hi Guys,
 
 I have fixed the final issue with python scripting on Windows. I've 
 attached a patch which fixes the sigsegv problem I see on Windows.
 
 I'd like to discuss it so that I can fully understand why this fixes the 
 issue, or if this is simply a kludge that's putting a plaster on a bone break.
 
 The issue boiled down to the following code in pcbnew_footprint_wizards.cpp:
 
 /* Time to call the callback */
 arglist = Py_BuildValue( (i), aPage );
 result = CallMethod( GetParameterPageName, arglist );
 Py_DECREF( arglist );
 
 There was a SIGSEGV in Py_DECREF( arglist ). In Py_DECREF() the code was 
 breaking in tupledealloc() (in Objects/tupleobject.c).
 
 The specific issue was in the macro Py_TRASHCAN_SAFE_BEGIN(op) where 
 PyThreadState_GET() returns NULL. The next line would SIGSEV.
 
 The PY_BLOCK_THREADS( ) and PY_UNBLOCK_THREADS( ) macro's surrounding the 
 python calls appear to fix the thread state issue.
 
 I haven't had a chance to look into wxPyBeginBlockThreads() yet to see what's 
 going on.
 
 The trouble is that I don't really understand what is going on. I could do 
 with someone versed in python extensions explaining the use of the GIL and 
 the PY_BLOCK_THREADS and PY_UNBLOCK_THREADS macros for me so I can understand 
 some more.
 
 I've also attached a quick image of the footprint wizard working okay. It 
 generates footprints successfully with this patch in place. So at least 
 that's something positive! :D
 
 I'm interested to understand what is wrong here. Why does Linux (and 
 presumably MAC) work okay without doing this?
 
 Perhaps the Windows build is broken in some other way that shouldn't be fixed 
 like this?
 
 At least there is progress.
 
 Best Regards, Brian.
 
 
 kicad-scripting-windows-footprint-working.jpgpcbnew_scripting_windows.diff___
 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] Mac OSX build, with scripting, codename wife

[Miguel Angel Ajo Pelayo]

Awesome!!, thanks for testing Martijn, :-)

I think I used cmake from homebrew: 

MacBook-Air-de-Miguel:src ajo$ which cmake
/Users/ajo/.rvm/bin/cmake
MacBook-Air-de-Miguel:src ajo$ ls -la `which cmake`
lrwxr-xr-x  1 ajo  staff  47  2 mar 00:24 /Users/ajo/.rvm/bin/cmake - 
../../.homebrew/Cellar/cmake/2.8.10.2/bin/cmake

 So we should document how to install brew, and cmake + wget + bzr + swig



Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 11/03/2013, at 01:29, Martijn Kuipers martijn.kuip...@gmail.com wrote:

 Congratulations Miguel!
 
 I just completed a build on a pristine Macbook Air.
 
 Some (minor) comments:
 You need wget, bzr and swig. I installed all of these with homebrew 
 without any problems. And you need cmake (not from homebrew, but cmake has 
 native OSX version).
 
 Other prerequisites:
 XCode and Xcode command line tools (obviously), which you can get from Apple.
 
 Then be patient and just watch the screens scroll by, but the result is 
 really nice :-)
 The entire directory needs about 2.5GB, The zipped Kicad is almost 100 MB, 
 which is around 350MB unpacked.
 
 Um abraço,
 Martijn
 
 
 On Mar 10, 2013, at 6:56 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es 
 wrote:
 
 I was always hoping to see the libraries (DLLs) to go into 
 /Library/Kicad, so we can keep the memory footprint down of the separate 
 Kicad components. But it is not a trivial task, so it seems.
 I am not following what you want to do. Is it like:
 /Applications/kicad/kicad.app - the app with the libs
 /Applications/kicad/libraries - footprints, components, etc.
 /Applications/kicad/scripts - python user scripts
 /Applications/kicad/doc - documentation and demos
 ?
 
 
 Look to the patches/loader.sh on github, at this moment, all the libraries 
 *.dylib and files go inside kicad.app/Frameworks/ and the other apps use 
 them from there (../../../kicad.app/Frameworks) , wx and python-site 
 mainly. 
 
 Also there are the demos+modules+etc in kicad.app/Resources/ or something 
 like that  that's what I was planning to pull out of kicad.app again and 
 yet leave it findable for all the apps.
 
 
 
 https://github.com/mangelajo/KicadOSXBuilder/commit/c41f116620182d56c07aee75cd751fe1ba922f7f
 This is the change, I also re-uploaded 
 kicad-scripting-osx-3992.zip
 
 :-)
 I think it's better like this, people can go into the data directory and 
 change/fetch whatever they like :)
 
 
 
 
 Kind regards,
 Martijn
 
 
 
 
 
 
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 10/03/2013, at 11:18, Martijn Kuipers martijn.kuip...@gmail.com 
 wrote:
 
 Hi Miguel,
 
 Downloading as we speak. On the github page you call it a universal OSX 
 binary, but that would mean it supports both PowerPC and Intel based 
 MACS, whereas is this email announcement you call it i386 +x64 build.
 
 I'm looking forward in compiling it myself, just to see if your solution 
 is portable. 
 
 Thanks also to your wife ;-)
 
 /Martijn
 
 
 On Mar 10, 2013, at 2:19 AM, Miguel Angel Ajo Pelayo 
 miguelan...@nbee.es wrote:
 
 
 
 Hi, 
 
 I've been working on the release of Kicad with scripting for MacOSX, 
 also tried to package it all together with 
 all kicad libs, and the templates.
 
 It's supposed to be a i386 + x64 binary build, with scripting support.
 
 kicad-scripting-osx-latest.zip
 
 
 It has all the new kicad templates system and libraries inside 
 kicad.app, and it's supposed to be accessible from all the other apps.
 
 I'm not sure if it will only work in 10.8, or may be 10.5-10.8, (it has 
 a dependency to system's python2.7).
 
 If there is any adventurous out there, please try, and tell me how does 
 it work (or doesn't).
 
 
 PS:
 
The codename for the release is wife, as my wife has been taking 
 care all saturday of our little Margarita, so she's a time donor to 
 kicad now too ;)
 
 My build  packaging script is temporarily here, for just in case 
 anyone wants to compile himself.. 
 https://github.com/mangelajo/KicadOSXBuilder
 
 Cheers!! ;)
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 ___
 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] Mac OSX build, with scripting, codename wife

[Miguel Angel Ajo Pelayo]

This tuesday I must decide if I keep renewing our *ltium license, or if we 
won't.

I'm thinking about donating 1/2 - 2/3 of it's cost to buy one of those mac 
minis to 
provide continuous integration/building of kicad binaries for OSX on every bzr 
release.

It would be wonderful also if we managed to do same thing for Windows users, I 
can
provide a windows VM for that somewhere, or try to setup a cross compiling from 
linux
once all the python+mingw+wxython mess gets working (and Dick + Brian + Wayne 
are working hard on this).




Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 11/03/2013, at 01:35, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote:

 Awesome!!, thanks for testing Martijn, :-)
 
 I think I used cmake from homebrew: 
 
 MacBook-Air-de-Miguel:src ajo$ which cmake
 /Users/ajo/.rvm/bin/cmake
 MacBook-Air-de-Miguel:src ajo$ ls -la `which cmake`
 lrwxr-xr-x  1 ajo  staff  47  2 mar 00:24 /Users/ajo/.rvm/bin/cmake - 
 ../../.homebrew/Cellar/cmake/2.8.10.2/bin/cmake
 
  So we should document how to install brew, and cmake + wget + bzr + swig
 
 
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 11/03/2013, at 01:29, Martijn Kuipers martijn.kuip...@gmail.com wrote:
 
 Congratulations Miguel!
 
 I just completed a build on a pristine Macbook Air.
 
 Some (minor) comments:
 You need wget, bzr and swig. I installed all of these with homebrew 
 without any problems. And you need cmake (not from homebrew, but cmake has 
 native OSX version).
 
 Other prerequisites:
 XCode and Xcode command line tools (obviously), which you can get from Apple.
 
 Then be patient and just watch the screens scroll by, but the result is 
 really nice :-)
 The entire directory needs about 2.5GB, The zipped Kicad is almost 100 MB, 
 which is around 350MB unpacked.
 
 Um abraço,
 Martijn
 
 
 On Mar 10, 2013, at 6:56 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es 
 wrote:
 
 I was always hoping to see the libraries (DLLs) to go into 
 /Library/Kicad, so we can keep the memory footprint down of the separate 
 Kicad components. But it is not a trivial task, so it seems.
 I am not following what you want to do. Is it like:
 /Applications/kicad/kicad.app - the app with the libs
 /Applications/kicad/libraries - footprints, components, etc.
 /Applications/kicad/scripts - python user scripts
 /Applications/kicad/doc - documentation and demos
 ?
 
 
 Look to the patches/loader.sh on github, at this moment, all the libraries 
 *.dylib and files go inside kicad.app/Frameworks/ and the other apps use 
 them from there (../../../kicad.app/Frameworks) , wx and python-site 
 mainly. 
 
 Also there are the demos+modules+etc in kicad.app/Resources/ or something 
 like that  that's what I was planning to pull out of kicad.app again and 
 yet leave it findable for all the apps.
 
 
 
 https://github.com/mangelajo/KicadOSXBuilder/commit/c41f116620182d56c07aee75cd751fe1ba922f7f
 This is the change, I also re-uploaded 
 kicad-scripting-osx-3992.zip
 
 :-)
 I think it's better like this, people can go into the data directory and 
 change/fetch whatever they like :)
 
 
 
 
 Kind regards,
 Martijn
 
 
 
 
 
 
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 10/03/2013, at 11:18, Martijn Kuipers martijn.kuip...@gmail.com 
 wrote:
 
 Hi Miguel,
 
 Downloading as we speak. On the github page you call it a universal OSX 
 binary, but that would mean it supports both PowerPC and Intel based 
 MACS, whereas is this email announcement you call it i386 +x64 build.
 
 I'm looking forward in compiling it myself, just to see if your 
 solution is portable. 
 
 Thanks also to your wife ;-)
 
 /Martijn
 
 
 On Mar 10, 2013, at 2:19 AM, Miguel Angel Ajo Pelayo 
 miguelan...@nbee.es wrote:
 
 
 
 Hi, 
 
 I've been working on the release of Kicad with scripting for MacOSX, 
 also tried to package it all together with 
 all kicad libs, and the templates.
 
 It's supposed to be a i386 + x64 binary build, with scripting support.
 
 kicad-scripting-osx-latest.zip
 
 
 It has all the new kicad templates system and libraries inside 
 kicad.app, and it's supposed to be accessible from all the other apps.
 
 I'm not sure if it will only work in 10.8, or may be 10.5-10.8, (it 
 has a dependency to system's python2.7).
 
 If there is any adventurous out there, please try, and tell me how 
 does it work (or doesn't).
 
 
 PS:
 
The codename for the release is wife, as my wife has been taking 
 care all saturday of our little Margarita, so she's a time donor to 
 kicad now too ;)
 
 My build  packaging script is temporarily here, for just in case 
 anyone wants to compile himself.. 
 https://github.com/mangelajo/KicadOSXBuilder
 
 Cheers!! ;)
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 ___
 Mailing list: https://launchpad.net/~kicad

Re: [Kicad-developers] Mac OSX build, with scripting, codename wife

[Miguel Angel Ajo Pelayo]

On 11/03/2013, at 02:40, Adam Wolf adamw...@feelslikeburning.com wrote:

 Nah, I think, if my releases are good enough, that I'd rather push them to a 
 central kicad thing, rather than to a WL property.  I don't want to spread 
 things out more than they have to be.
 
 While we're not big enough to pay either one of us full time, all of our 
 designs are done with Kicad, and we didn't pay a dime for that.  We're glad 
 to do what we can.
 
It's more ore less our spirit here, but, anyway, many people use kicad 
extensively and don't contribute, in my opinion (not sure how others feel about 
it), it's not bad to get 
contributions paid back / credited somehow, whenever it sounds reasonable.

Thanks for your efforts, really! :)

 Adam Wolf
 Wayne and Layne, LLC
 
 On Mar 10, 2013 8:21 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es 
 wrote:
   
You're right, your recipes have always been open, :-)
 
Btw, in my opinion, if you will take care of mac osx builds, etc, and want 
 to keep them on your site, 
 to drive you some traffic to WL, for me it looks right (as you would be 
 paying for electricity [at each build] + server + etc…),
 but anyway if we keep a bunch of releases/log and a mirror on the kicad site 
 itself, it's yet better ;)
 
Cheers,
 Mike
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 11/03/2013, at 02:14, Adam Wolf adamw...@feelslikeburning.com wrote:
 
 I like to put the actual commands used in the build server in a source tree 
 somewhere, so there's no magic behind the scenes.
 
 Adam Wolf
 Wayne and Layne LLC
 
 On Mar 10, 2013 8:04 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es 
 wrote:
 Adam, it sounds great, you're killing my excuse to buy a Mac Mini ;-), 
 but ok :D, will reinvest it wisely 
 on KiCad :) 
 
 I can provide you with an account to kicad-pcb.org to upload files as 
 they build, just let me know
 if you need any help for the setup.
 
 I think that's important that we keep the building recipe and 
 enhancements fully open, so 
 anybody can rebuild it easily, even if we're caught by a bus (thing I 
 don't expect or want) :D
 In fact, many parts (like packaging, loading or linking tweaks) would be 
 better integrated into
 KiCad cmake scripts, and pulled out of the build.sh.
 

 PS: I'm remembering that Jean Pierre asked me so long ago about a download 
 area, and I totally forgotten,
 may be soon will be the time for downloads.kicad-pcb.org or equivalent place.
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 11/03/2013, at 01:50, Adam Wolf adamw...@feelslikeburning.com wrote:
 
 Miguel,
 
 Wayne and Layne recently purchased a Mac Mini for Kicad builds.  We have a 
 spare Windows license too, so I can host a Windows and Linux VM on it as 
 well.
 
 I can set this up on a Jenkins instance.  I'm considering doing the same 
 with the Linux builds.  While I like the PPA autobuilder, the build 
 environment isn't like what the devs use, so the PPA breaks on a regular 
 basis--and then it's hard to see why, because my box isn't emulating the 
 PPA environment exactly.  This is currently the case with the cmake thing.
 
 I can even push my built packages back up to my PPA, so the transition 
 could be seamless to end users.
 
 What do you guys think?
 
 Adam Wolf
 Wayne and Layne, LLC
 
 
 On Sun, Mar 10, 2013 at 7:43 PM, Miguel Angel Ajo Pelayo 
 miguelan...@nbee.es wrote:
 This tuesday I must decide if I keep renewing our *ltium license, or if we 
 won't.
 
 I'm thinking about donating 1/2 - 2/3 of it's cost to buy one of those mac 
 minis to 
 provide continuous integration/building of kicad binaries for OSX on every 
 bzr release.
 
 It would be wonderful also if we managed to do same thing for Windows 
 users, I can
 provide a windows VM for that somewhere, or try to setup a cross compiling 
 from linux
 once all the python+mingw+wxython mess gets working (and Dick + Brian + 
 Wayne 
 are working hard on this).
 
 
 
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 11/03/2013, at 01:35, Miguel Angel Ajo Pelayo miguelan...@nbee.es 
 wrote:
 
 Awesome!!, thanks for testing Martijn, :-)
 
 I think I used cmake from homebrew: 
 
 MacBook-Air-de-Miguel:src ajo$ which cmake
 /Users/ajo/.rvm/bin/cmake
 MacBook-Air-de-Miguel:src ajo$ ls -la `which cmake`
 lrwxr-xr-x  1 ajo  staff  47  2 mar 00:24 /Users/ajo/.rvm/bin/cmake - 
 ../../.homebrew/Cellar/cmake/2.8.10.2/bin/cmake
 
  So we should document how to install brew, and cmake + wget + bzr + 
 swig
 
 
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 11/03/2013, at 01:29, Martijn Kuipers martijn.kuip...@gmail.com wrote:
 
 Congratulations Miguel!
 
 I just completed a build on a pristine Macbook Air.
 
 Some (minor) comments:
 You need wget, bzr and swig. I installed all of these with homebrew 
 without any problems. And you need cmake (not from homebrew, but cmake 
 has native

[Kicad-developers] Mac OSX build, with scripting, codename wife

[Miguel Angel Ajo Pelayo]

Hi, 

I've been working on the release of Kicad with scripting for MacOSX, also tried 
to package it all together with 
all kicad libs, and the templates.

It's supposed to be a i386 + x64 binary build, with scripting support.

kicad-scripting-osx-latest.zip


It has all the new kicad templates system and libraries inside kicad.app, and 
it's supposed to be accessible from all the other apps.

I'm not sure if it will only work in 10.8, or may be 10.5-10.8, (it has a 
dependency to system's python2.7).

If there is any adventurous out there, please try, and tell me how does it work 
(or doesn't).


PS:

   The codename for the release is wife, as my wife has been taking care all 
saturday of our little Margarita, so she's a time donor to kicad now too ;)

My build  packaging script is temporarily here, for just in case anyone wants 
to compile himself.. 
https://github.com/mangelajo/KicadOSXBuilder

Cheers!! ;)

Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

___
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] Welcome to Brian Sidebotham

[Miguel Angel Ajo Pelayo]

Congratulations Brian!, your knowledge and expertise helps a lot, 
it will be easier for you to help from inside the team.

As a user, and even more as a developer, I really thank you for all 
the hard work you do for the KiCad project.

Welcome onboard!!! :)

Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 25/02/2013, at 17:38, Dick Hollenbeck d...@softplc.com wrote:

 
 After a 30 second chatamong the lead developers, it was unanimously
 decided to bring in Brian Sidebotham to the team
 
  kicad-testing-committers
 
 Brian has more than earned this new status by being a team player, and
 making significant contributions in areas like Winbuilder, project
 templating,
 
 
 
 and now most recently, work on the Windows wxPython stackfor KiCad.
 
 Congratulations 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] SWEET: multisheet schematic concerns

[Miguel Angel Ajo Pelayo]

Agree about that it's important to let the multi-sheets be split across many 
files.

And I like the functionality you're proposing related to schematics + 
scripting. It's awesome and innovative in fact.

Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 21/02/2013, at 15:06, Dick Hollenbeck d...@softplc.com wrote:

 Exactly.
 
 
 ___
 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] SWEET: multisheet schematic concerns

[Miguel Angel Ajo Pelayo]

I think copypaste is not a perfect scenario for reusability,

git/bzr/svn/etc cloning a module you already tested, that's in an
independent schematic
file/sheet makes a lot of sense for me.




2013/2/21 Wayne Stambaugh stambau...@verizon.net

 On 2/21/2013 10:53 AM, Ryan Sturmer wrote:
  Long time listener, first time writer.
 
  One sheet per file makes the most sense to me, as well.  The way the
  project management is done right now is a little big awkward, IMO.
   KiCAD seems to want to generate project files and stuff when I don't
  want them.  I am also an Altium Designer user, and I find it's project
  management functionality to be pretty sensible, for the most part.
 
  -R

 If you don't have anything to do for a couple of hours (days?), see the
 original discussion about the new schematic file format:

 https://lists.launchpad.net/kicad-developers/msg06358.html

 There is no plan to have separate files for each sheet.  The new design
 will be infinitely more modular than the current design and should
 greatly simplify complex hierarchy code and file format compared to what
 we currently have.  The new design will make it possible to support cut
 and paste and indirectly drag and drop.  Individual files do not make
 the schematic structure more modular.  A superior design does.  Once
 this gets implemented (probably not any time soon), I think it will make
 a lot more sense.

 Wayne

 
 
  On Thu, Feb 21, 2013 at 10:30 AM, Miguel Angel Ajo Pelayo
  miguelan...@nbee.es mailto:miguelan...@nbee.es wrote:
 
  Agree about that it's important to let the multi-sheets be split
  across many files.
 
  And I like the functionality you're proposing related to schematics
  + scripting. It's awesome and innovative in fact.
 
  Miguel Angel Ajo
  http://www.nbee.es
  +34911407752
  skype: ajoajoajo
 
  On 21/02/2013, at 15:06, Dick Hollenbeck d...@softplc.com
  mailto:d...@softplc.com wrote:
 
   Exactly.
  
  
   ___
   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
  mailto:kicad-developers@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~kicad-developers
  More help   : https://help.launchpad.net/ListHelp
 
 
 
 
  --
  Please excuse the crudity of this model.  I didn't have time to build
  it to scale or paint it.
 -Doctor Emmett Brown
  /Back to the Future/
  /
  /
  Ryan Sturmer
  http://about.me/ryansturmer
  ryanstur...@gmail.com mailto:ryanstur...@gmail.com
 
 
  ___
  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




-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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] SWEET: multisheet schematic concerns

[Miguel Angel Ajo Pelayo]

Hi Wayne, sorry for reopening this thread,  I think (may be I'm wrong) I
wasn't here
at the moment that thread happened, and I couldn't expose my opinion.

I understand the copypaste functionality from/to clipboard, although
extremely useful
and something that kicad will benefit from, yet doesn't seem like a natural
way to maintain designs
modules in a [D]VCS environment for me.

Anyway, if we (I) have more time in the future, and I can help on doing
a file format definition review, I'd like to think about the workflow this
format would (or wouldn't)
impose. I don't have the time or strength right now.


   Sincerely,
Mike.







2013/2/21 Wayne Stambaugh stambau...@verizon.net

 On 2/21/2013 11:52 AM, Miguel Angel Ajo Pelayo wrote:
  Makes more sense, because, as it's independent, you can lately (if you
  add an improvement or fix),
  send a pull / merge request on this file to the original author. With
  copypaste you cannot do that.

 When haven't you been able to copy and paste plain text into and from a
 file?  The new file format design should be modular enough (at least
 that was the design intent) that you could cut and paste any object (not
 just  sheets) to and from a schematic.  This way you are free to use any
 plain text sink or source to copy and paste schematic objects not just
 files.  I'm not planning on reopening the schematic file format
 discussion again since I think the current format is pretty well
 defined.  If memory serves (at my age it sometimes doesn't), the
 separate file issue was discussed (see the link in my previous post).
 If someone else wants to reopen the discussion and has the time to own
 the schematic file format document, I will gladly hand it over.

 
 
  2013/2/21 Miguel Angel Ajo Pelayo miguelan...@nbee.es
  mailto:miguelan...@nbee.es
 
  I think copypaste is not a perfect scenario for reusability,
 
  git/bzr/svn/etc cloning a module you already tested, that's in an
  independent schematic
  file/sheet makes a lot of sense for me.
 
 
 
 
  2013/2/21 Wayne Stambaugh stambau...@verizon.net
  mailto:stambau...@verizon.net
 
  On 2/21/2013 10:53 AM, Ryan Sturmer wrote:
   Long time listener, first time writer.
  
   One sheet per file makes the most sense to me, as well.  The
  way the
   project management is done right now is a little big awkward,
 IMO.
KiCAD seems to want to generate project files and stuff when
  I don't
   want them.  I am also an Altium Designer user, and I find it's
  project
   management functionality to be pretty sensible, for the most
 part.
  
   -R
 
  If you don't have anything to do for a couple of hours (days?),
  see the
  original discussion about the new schematic file format:
 
  https://lists.launchpad.net/kicad-developers/msg06358.html
 
  There is no plan to have separate files for each sheet.  The new
  design
  will be infinitely more modular than the current design and
 should
  greatly simplify complex hierarchy code and file format compared
  to what
  we currently have.  The new design will make it possible to
  support cut
  and paste and indirectly drag and drop.  Individual files do not
  make
  the schematic structure more modular.  A superior design does.
  Once
  this gets implemented (probably not any time soon), I think it
  will make
  a lot more sense.
 
  Wayne
 
  
  
   On Thu, Feb 21, 2013 at 10:30 AM, Miguel Angel Ajo Pelayo
   miguelan...@nbee.es mailto:miguelan...@nbee.es
  mailto:miguelan...@nbee.es mailto:miguelan...@nbee.es
 wrote:
  
   Agree about that it's important to let the multi-sheets be
  split
   across many files.
  
   And I like the functionality you're proposing related to
  schematics
   + scripting. It's awesome and innovative in fact.
  
   Miguel Angel Ajo
   http://www.nbee.es
   +34911407752 tel:%2B34911407752
   skype: ajoajoajo
  
   On 21/02/2013, at 15:06, Dick Hollenbeck d...@softplc.com
  mailto:d...@softplc.com
   mailto:d...@softplc.com mailto:d...@softplc.com
 wrote:
  
Exactly.
   
   
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
  mailto:kicad-developers@lists.launchpad.net
   mailto:kicad-developers@lists.launchpad.net
  mailto:kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers

Re: [Kicad-developers] Python Scripting Status?

[Miguel Angel Ajo Pelayo]

As Dick pointed, at this moment we have pcbnew+python only, with the
following support:

1) Linux: full , pcbnew + python + wxpython   (python inside pcbnew, and
also a module to provide pcbnew  objects access inside python)  (I know
there must be some fancy names for this, introspection + pcbnew python
module?, bah..)

2) Win32: partial, just pcbnew + python  and the pcbnew module for python
(you couldn't access wx to build interfaces from python at this moment).
This is what Dick pointed thread is about. :)

3) MacOSX, I've been able to build with the full stack, but yet must find
the way to statically-compile, or build a bundle that we can provide. I
really would like to make an automated system to build that as we do for
all the other systems.

I recommend you to check on this:

http://www.kicad-pcb.org/display/KICAD/KiCad+Scripting+Reference+Manual

http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/view/head:/scripting/kicadplugins.i


Current plans involve:

0) Get the full stuff in win32

1) Make pcbnew python pluggable: a) footprint wizards (done, but must be
enhanced), b) file I/O plugins, to provide a plugin point for python into
the wonderful I/O plugin system that Dick  Wayne built in pcbnew, c)
Action plugins, something like callback triggers inside pcbnew actions,
like a click on a component, right click, opening a menu, so people could
build scripts to really extend everything they need.

1.1) Make python API interface documented, swigging out all the doxygen
information from classes.

2) Make eeschema ready for scripting, get the scripting in...

3) same for other parts, like gerbview...

4) think about adding more languages, like javascript (waiting for a mature
swig javascript support)


Ok, I'm going to copy this into the development wiki as it sounds like a
roadmap for me.

http://www.kicad-pcb.org/display/DEV/Scripting+Support


2013/2/14 Dick Hollenbeck d...@softplc.com

 On 02/13/2013 05:04 AM, Senthil Seveelavanan wrote:
  Hi all,
 
  Firstly I would like to thank all those who have contributed to Kicad.
 Kicad must have
  taken (and must be) a lot of work!
 
  I have seen there have been some movements to provide a Python interface
 to Kicad
  
 http://www.kicad-pcb.org/display/%7Eajo/2012/05/08/KiCad+Scripting+Branch
 .
  - Are there any builds with scripting support?

 linux only.

 windows status can be described as evolving quickly to catch up to linux.

 Start here to learn more, follow the thread.

 https://lists.launchpad.net/kicad-developers/msg09377.html

 It would be boring to have the same conversatin again.

 Only Pcbnew has any python support currently.  For eeschema, it might just
 get in the way
 at this point, there is work to do on eeschema before python would make
 sense.




  - Or has this been integrated in master?
  - Or are there any plans?
 
  As a reasonably competent python programmer but very limited C/C++
 programmer, a
  functioning Python interface/plugin-system would allow contributions
 from people like
  myself. I have various ideas and features for Kicad that I would love to
 try to
  implement, but would have little chance of me getting anywhere without a
 Python
  interface. I am sure there are lots more people in my position out there
 - this would
  unlock a whole new wave of developers.
 
  Freecad 
 http://sourceforge.net/apps/mediawiki/free-cad/index.php?title=Power_users_hub
 
  has made this central to there approach:
 
  **FreeCAD features a built-in Python interpreter, and an API that
 covers almost any
  part of the application, the interface, the geometry and the
 representation of this
  geometry in the 3D viewer. The interpreter can run single commands up to
 complex
  scripts, in fact entire modules can even be programmed completely in
 Python.
 
  Those following Freecad may have also witnessed the rapid addition of
 core features, as
  well as activity from external hackers bending Freecad to their wishes -
 it all seems
  pretty fertile.
 
 
  Finally a minor point. I posted on the yahoo user group, about whether
 there was any
  interest from developers to set up a Flattr http://flattr.com/
 account. It would only
  be pennies (I have some pennies!), but one day perhaps many peoples
 pennies. I wish I
  could contribute more financially and technically.
 
  Thanks and please keep up the good work
 
  Senthil
 
 
  ___
  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




-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype

Re: [Kicad-developers] kicad-pcb.org

[Miguel Angel Ajo Pelayo]

Sorry, about the recent server problems,

This service is running in a host machine owned by nbee, that also has
 (had!) a set of forums that run into it.

Some of them had become very popular, stoping kicad-pcb.org operations, and
also our internal servers so we have moved the forums to a separate
server for their own. Yesterday we needed to call the datacenter to reboot
the machine, and stop the overloaded virtual machines.

From now on kicad-pcb.org operation should run much more smoother, I hope
that this problem won't arise again. In case anyone detects a problem,
please, tell me know, I promise to check it as fast as possible.

My most sincere apologies
Mike.





2013/2/7 Dick Hollenbeck d...@softplc.com

 On 02/07/2013 03:48 PM, Dick Hollenbeck wrote:
  On 02/07/2013 03:26 PM, Wayne Stambaugh wrote:
  On 2/7/2013 4:20 PM, Dick Hollenbeck wrote:
  Is anyone able to reach this website today?
 
  Been out of service since when?
 
 
  I just checked and I'm not having any problems reaching it.
 
  Wayne
  I guess somebody saw my message and got it fixed  :)
 
  Thanks Miguel.

 You should be in bed!  :)




 ___
 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




-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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 cmake build macros.

[Miguel Angel Ajo Pelayo]

On 31/01/2013, at 16:45, Dick Hollenbeck d...@softplc.com wrote:

 On 01/31/2013 08:50 AM, Brian Sidebotham wrote:
 
 On 30 January 2013 19:14, Wayne Stambaugh stambau...@verizon.net
 mailto:stambau...@verizon.net wrote:
 
On 1/30/2013 4:33 AM, Brian Sidebotham wrote:
 Hi Wayne,
 
 You're right - it's not exactly straight forward, there are problems to
 solve.
 
 I got the specs file to work correctly with the variable substitution,
 perhaps you could try the spec90 file I attached to another mail on the
 list? I'm using the latest MinGW version - 4.7.2 too.
 
 I wonder if you have a link library ordering issue as write should
 definitely be linked from any C runtime.
 
 I am getting some other issues, relating to time which I think went
 under breaking changes as Microsoft seem to word it during the VS2005
 (msvcr80) change.
 
 In the link to Anselm's
 notes: 
 http://developer.berlios.de/devlog/akruis/2012/06/10/msvcr90dll-and-mingw/ 
 it's
 worth looking at the section about the MinGW Runtime. There is some
 
Gee, is this all we have to do.;)  It looks like either approach we take
(CMake for Python or get MinGW to play nice with msvcrxx), will require
a significant effort on our part.
 
 patching required to get around the differences between the old CRT and
 the newer CRTs where Microsoft decided to just delete functions and
 types! This breaks the glue.
 
 I haven't yet got around to patching the MinGW Runtime and trying
 compilation with that, hopefully I will at the weekend, but time is very
 tight at the moment.
 
 We are a bit ahead of the curve on this really. But at least the MinGW
 guys are gradually adding this support into MinGW.
 
I'm a bit reluctant to use unreleased stuff from MinGW.  It could change
significantly between now and the time it's released which means we
would have to keep things well maintained.  The CMake solution seems
like it would have a better chance of success no matter which direction
MinGW goes.
 
Thanks again for digging up this information.  It certainly was
enlightening.
 
 
 Hi Wayne,
 
 No problem at all. I'm not ready to give up on it yet, and it'll probably be 
 best if we
 explore all of the possible ways forward. I don't like the chances of 
 compiling the
 pywin32 python package with MinGW.
 
 
 What is pywin32 exactly?  The sourceforge website for it says nothing.  Is 
 this simply
 python for windows, carried to you in an installer?

It's a module/library inside python standard stack, which is used (abstracted, 
of course)
to provide OS related functionality.

Wayne  Brian, thanks a lot for the hard work on this thread you've been doing 
lately, I'm
reading all your efforts, but contributing nothing, big changes at projects 
lately (for good),
but I'm needing more than expected to adapt… 

Please let me know if you want to have some rest on the task at any moment, I 
promise to find
the time for it.





___
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 cmake build macros.

[Miguel Angel Ajo Pelayo]

Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 31/01/2013, at 19:50, Dick Hollenbeck d...@softplc.com wrote:

 On 01/31/2013 11:36 AM, Brian Sidebotham wrote:
 
 
 
 On 24 January 2013 22:42, Brian Sidebotham brian.sidebot...@gmail.com
 mailto:brian.sidebot...@gmail.com wrote:
 
A quick test to build wxPython with a freshly compiled python-mingw with 
 binascii
package results in the next problem. One that looks a bit more 
 fundamental to sort out:
 
This is what I get compiling the most basic of extension with this 
 python-mingw, the
error is the same when trying to build wxPython too:
 

 KiCad-WinbuilderC:\kicad-winbuilder-dev\kicad-winbuilder\src\wx\testmodulepython
setup.py build -c mingw32
running build
running build_ext
Warning: Can't read registry to find the necessary compiler setting
Make sure that Python modules _winreg, win32api or win32con are installed.
building 'hello' extension
C:\kicad-winbuilder-dev\kicad-winbuilder\env\mingw\bin\gcc.exe 
 -mno-cygwin -mdll
 -O -Wall -IC:\kicad-winbuilder-dev\kicad-winbuilder\env\python\include 
 -IC:\kic
ad-winbuilder-dev\kicad-winbuilder\env\python\PC -c testmodule.c -o 
 build\temp.w
in32-2.7\Release\testmodule.o
Traceback (most recent call last):
  File setup.py, line 8, in module
ext_modules = [module1])
  File 
 C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
ils\core.py, line 152, in setup
dist.run_commands()
  File 
 C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
ils\dist.py, line 953, in run_commands
self.run_command(cmd)
  File 
 C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
ils\dist.py, line 972, in run_command
cmd_obj.run()
  File 
 C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
ils\command\build.py, line 127, in run
self.run_command(cmd_name)
  File 
 C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
ils\cmd.py, line 326, in run_command
self.distribution.run_command(command)
  File 
 C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
ils\dist.py, line 972, in run_command
cmd_obj.run()
  File 
 C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
ils\command\build_ext.py, line 340, in run
self.build_extensions()
  File 
 C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
ils\command\build_ext.py, line 449, in build_extensions
self.build_extension(ext)
  File 
 C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
ils\command\build_ext.py, line 499, in build_extension
depends=ext.depends)
  File 
 C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
ils\ccompiler.py, line 624, in compile
self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts)
  File 
 C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
ils\cygwinccompiler.py, line 164, in _compile
extra_postargs)
  File 
 C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
ils\ccompiler.py, line 925, in spawn
spawn(cmd, dry_run=self.dry_run)
  File 
 C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
ils\spawn.py, line 36, in spawn
_spawn_nt(cmd, search_path, dry_run=dry_run)
  File 
 C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
ils\spawn.py, line 69, in _spawn_nt
rc = os.spawnv(os.P_WAIT, executable, cmd)
AttributeError: 'module' object has no attribute 'spawnv'
 
Basically it's down to not having pywin32 installed or any other win32api 
 module.
The trouble is they all seem to require compiling with msvc.
 
I've run out of time again.
 
Best Regards, Brian.
 
 
 
 Hi Guys,
 
 Sorry I missed most of the discussion today, but appear to have dropped and 
 bomb before
 I stopped following!
 
 The mail I sent above details the tie-in with pywin32, although I notice now 
 upon
 re-reading that this may just be python's distutils trying to access the 
 registry and
 failing.
 
 I am assuming here that we need to execute this python build using the new 
 python-mingw
 executable on windows to compile wxPython? I don't see how that part can be 
 done under
 Linux?
 
 This is entirely where the link to pywin32 came from - which is essentially 
 distutils
 rather than wxPython.
 
 
 This sounds like just another windows specific sickness that needs to be 
 rooted out of
 distutils with a patch during the python build.  If linux python's distutils 
 can work
 without a windows registry, why cannot windows?
 
 Admittedly my vision and goals are different than those who have worked on 
 python in the
 past.  But they are probably not that 

Re: [Kicad-developers] kicad scripting autobuilder failure

[Miguel Angel Ajo Pelayo]

Somebody told me about this, I think it was Brian.

I think we must have introduced some change to the cmake scripts that
change the build order in this case, or my cmake scripts were not good...
It was my first cmake script.

This step should happen after swig executed already (and not before), else
the pcbnew.py won't exist.




2013/1/23 Hans Henry von Tresckow hvont...@gmail.com

 I just noticed that the ppa builds are failing with this error:


 [ 79%] Fixing swig_import_helper in Kicad scripting
 Traceback (most recent call last):
   File 
 /build/buildd/kicad-0.201301222033+3918~13~raring1/kicad/pcbnew/../scripting/fixswigimports.py,
  line 26, in module
 f = open(filename,rb)
 IOError: [Errno 2] No such file or directory: 
 '/build/buildd/kicad-0.201301222033+3918~13~raring1/build/kicad/pcbnew/pcbnew.py'
 make[3]: *** [pcbnew/CMakeFiles/FixSwigImportsScripting] Error 1



 --
 Henry von Tresckow (hvontres)

 ___
 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




-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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 scripting autobuilder failure

[Miguel Angel Ajo Pelayo]

Dick if you could take a look at it I'd thank you very very much,you're our
cmake expert :-).

 I haven't ever seen the failure, but will try this night with different -j
values (I usually do it with 5).



2013/1/23 Dick Hollenbeck d...@softplc.com

 On 01/23/2013 08:02 AM, Miguel Angel Ajo Pelayo wrote:
  Somebody told me about this, I think it was Brian.
 
  I think we must have introduced some change to the cmake scripts that
 change the build
  order in this case, or my cmake scripts were not good... It was my first
 cmake script.
 
  This step should happen after swig executed already (and not before),
 else the pcbnew.py
  won't exist.


 I think line 446 in pcbnew/CMakeLists.txt is suspicious.

 Usually use the target name, without path, in the DEPENDS lines.


 Miguel, if you want me to look at this I will, but I need to know how to
 reproduce it.
 Perhaps the
 reproduce-ability is depending on the


 make -jn

 setting, i.e. n.

 It is not simply reproduce-able.


 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




-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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 scripting autobuilder failure

[Miguel Angel Ajo Pelayo]

Hahaha, thanks dick, yes it really sounds like Brian's problem in mingw. :-)

That changes were introduced by me trying to fix compilation in OSX, I will
review them later, and check what was I trying to do, or what did I
drink thanks for cleaning my mess in there.


2013/1/23 Dick Hollenbeck d...@softplc.com

 On 01/23/2013 10:38 AM, Dick Hollenbeck wrote:
  On 01/23/2013 10:21 AM, Dick Hollenbeck wrote:
  On 01/23/2013 10:12 AM, Miguel Angel Ajo Pelayo wrote:
  Dick if you could take a look at it I'd thank you very very
 much,you're our cmake expert
  :-).
 
   I haven't ever seen the failure, but will try this night with
 different -j values (I
  usually do it with 5).
  OK, I think I know what's happening.
 
  I am on it.
 
  Rev 3920 may fix it, PPA willtell us in a day.

 This sounds like Brian's problem too with Mingw.

 If so, and the fix sticks, it'll allow Brian one less concern in
 preparation for his most
 important day.

 Especially since KiCad has always been at the top of his priority list,
 there would have
 been no other way to get this out of his head.

 Just imagine how difficult that would have made reciting the vows...

 :)





-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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 cmake build macros.

[Miguel Angel Ajo Pelayo]

Hi Brian!!, 

On 21/01/2013, at 20:28, Brian Sidebotham brian.sidebot...@gmail.com wrote:

 Hi Guys,
 
 Sorry I'm late to the party, I've been doing wedding stuff for a while. It'll 
 continue for the next few months.
 

Hehehe, are you sure of what you're doing? (just joking, congratulations if I 
didn't already) ;)

 I tried the MinGW python to build wxPython, but it falls over instantly 
 because there's no binascii package. I fear that the base packages all need 
 to be built with this python first before the wxPython can be built with it. 
 It is probably worth noting to anyone desperate that the multiple crt problem 
 is only apparent for Python V2.6 and greater. Python 2.5 does not suffer this 
 problem apparently.
 

Whoops, ok, binascii needed, yes I suppose that we will need packages here and 
there but eventually it must work.

 Another problem is that GLCANVAS is not currently supported by wxPython. But 
 I expect that just means that scripting will not have access to a 3D canvas?
 

Yes, that only means that the python side won't have access to the 3D canvas, 
but wx must be compiled with it enabled.
GLCANVAS is used at the moment or in the GAL?, I've used 3D + wxpython in 
linux, for sure.

 On another note, whilst building with a standard python install I get the 
 following error:
 
 Traceback (most recent call last):
   File 
 C:/kicad-winbuilder-dev/kicad-winbuilder/src/kicad/pcbnew/../scripting/fixswigimports.py,
  line 26, in module
 f = open(filename,rb)
 IOError: [Errno 2] No such file or directory: 
 'C:/kicad-winbuilder-dev/kicad-winbuilder/build/release/pcbnew/pcbnew.py'
 mingw32-make[2]: *** [pcbnew/CMakeFiles/FixSwigImportsScripting] Error 1
 mingw32-make[1]: *** [pcbnew/CMakeFiles/FixSwigImportsScripting.dir/all] 
 Error 2
 mingw32-make[1]: *** Waiting for unfinished jobs
 mingw32-make: *** [all] Error 2
 

Hmm, that .py is looking for the swig generated pcbnew.py file, to fix the way 
it imports. There is no pcbnew.py generated?
is swig executed before that? (the result must be the .cxx/.cpp wrapper and the 
pcbnew.py


 Best Regards, Brian.
 
 On 20 January 2013 20:55, Wayne Stambaugh stambau...@verizon.net wrote:
 On 1/20/2013 2:08 PM, Miguel Angel Ajo Pelayo wrote:
  Argh, no need to apologize Wayne, I hope they can recover your system
  and provide you with something that works in an stable way.
 
  I really hate when those things happen, 4-5 years ago I had a problem like
  this with a couple of laptops, after some time we suspected of power surges
  in the electrical line, because some more little things died around, and
  I was
  astonished with the fact that the power adapter (2 different models)
  didn't kill those surges properly, which surprisingly only killed the
  hard-disks ...
 
  I wish you good luck with the repair.
 
  for the time being, I've been able to build a couple of packages:
 
  http://dev.kicad-pcb.org/pkgs/Python-2.7.1-mingw32.tar.gz
  http://dev.kicad-pcb.org/pkgs/Python-2.7.1-mingw32-builder.tar.gz  --
  those are my cross build scripts at the moment that expect some files in
  archive directory.
 
 I'll download them and take a look at them.  I'm using my laptop right
 now which is way to slow to be building really big projects like Python.
  By the time I get them built, my desktop will be back from HP's repair
 department.
 
 
  The python-2.7.1 we've built runs for win32, and I'm installing it to
  C:\Python, but could go other places
 
 The binary archive is a good start but most Window's users will expect
 an installer.  I didn't see any CPack stuff in the CMake files used to
 build Python so there will be a lot of work to do in that regard.
 
 
  It's important to set those vars before execution:
 
  set PYTHONHOME=C:\Python
  set PYTHONPATH=C:\Python\lib\python2.7;C:\Python\pyd
 
 
  And it also provides include files and .a libs
 
 These are key to building other extensions.
 
 
  It took me ages to figure that I had missaplied one of the patches (the
  05 one, that needed patch -p1 instead of -p0) and didn't let me build
  the .dll version for win32.
 
  Also CRYPT and PYEXPAT packages are disabled now for a lack of
  libraries.
 
 I'm pretty sure libexpat builds on MinGW.  There is an expat package
 available for MinGW.  I'm not sure about the crypt library.
 
 
  This killed all my spare time from the last email on the topic, which
  it's been a lot more than expected.
 
 I'm not surprised, these things always end up taking more time than I
 think they will.  Thank you for all of you efforts.
 
 Wayne
 
 
  I'm afraid that I'll need to ask for a lot of help if we really want to
  build a set of shiny packages.
 
  My next step is trying to compile the wxpython + kicad with this python
  binary package, but I will wait until you can recover your data, may be
  others are happy trying our shiny mingw-win32 python package :-)
 
  Greetings, Mike
 
 
 
 
 
 
 
 
 
 
 
 
 
  2013/1/20 Wayne Stambaugh stambau...@verizon.net

Re: [Kicad-developers] Python scripting cmake build macros.

[Miguel Angel Ajo Pelayo]

Argh, no need to apologize Wayne, I hope they can recover your system
and provide you with something that works in an stable way.

I really hate when those things happen, 4-5 years ago I had a problem like
this with a couple of laptops, after some time we suspected of power surges
in the electrical line, because some more little things died around, and I
was
astonished with the fact that the power adapter (2 different models)
didn't kill those surges properly, which surprisingly only killed the
hard-disks ...

I wish you good luck with the repair.

for the time being, I've been able to build a couple of packages:

http://dev.kicad-pcb.org/pkgs/Python-2.7.1-mingw32.tar.gz
http://dev.kicad-pcb.org/pkgs/Python-2.7.1-mingw32-builder.tar.gz  --
those are my cross build scripts at the moment that expect some files in
archive directory.

The python-2.7.1 we've built runs for win32, and I'm installing it to
C:\Python, but could go other places

It's important to set those vars before execution:

set PYTHONHOME=C:\Python
set PYTHONPATH=C:\Python\lib\python2.7;C:\Python\pyd


And it also provides include files and .a libs

It took me ages to figure that I had missaplied one of the patches (the 05
one, that needed patch -p1 instead of -p0) and didn't let me build the .dll
version for win32.

Also CRYPT and PYEXPAT packages are disabled now for a lack of
libraries.

This killed all my spare time from the last email on the topic, which it's
been a lot more than expected.

I'm afraid that I'll need to ask for a lot of help if we really want to
build a set of shiny packages.

My next step is trying to compile the wxpython + kicad with this python
binary package, but I will wait until you can recover your data, may be
others are happy trying our shiny mingw-win32 python package :-)

Greetings, Mike













2013/1/20 Wayne Stambaugh stambau...@verizon.net

 On 1/16/2013 12:56 PM, Wayne Stambaugh wrote:
  On 1/16/2013 12:16 PM, Miguel Angel Ajo Pelayo wrote:
  Other option we could have right now is compile out the wxpython
 support and provide
  only embedded python scripting + python pcbnew module for windows users.
 
  In that case, next functionalities are lost:
 
  1) PyCrust shell inside pcbnew
  2) Ability to create and run own wx-uis in the embedded python
 scripting.
 
  And we keep:
 
  3) pcbnew module for commandline python scripting
  4) embedded pcbnew wizards  plugins
 
  Wayne, could you document the steps you followed until now so I can try
 to reproduce it and fight a little bit in this war ?
 
  Please see my response to Adam.  I'll add the Pthon command line
  scripting build instructions for Windows using MinGW to
  Documentation/compiling/COMPILING.txt in my next commit.

 Bad news Miguel.  I was almost ready to commit this when my home system,
 which I just got back from HP's warranty repair service the week before
 Christmas, died again.  I've already contacted HP service but it will
 likely be at least a week before I get my system back.  Needless to say
 I am not happy.  This will be the third time (one disk drive and one
 motherboard) the system has had problems since I bought it.  I apologize
 for the delay.  As soon as I get my system back, I'll get this committed.

 Wayne

 
 
 
  Miguel Angel Ajo
  http://www.nbee.es
  +34911407752
  skype: ajoajoajo
 

 snipped




-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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 cmake build macros.

[Miguel Angel Ajo Pelayo]

2013/1/17 Dick Hollenbeck d...@softplc.com

 Nice job, I am glad I was able to inspire you to see the light.


Just did nothing but follow the readme, it's good that you found it. I hope
I will be able to port it to the latest 2.7.x python, anyway, I will
consider that low priority, it's not a stopper at all.



 This approach puts the task firmly in your comfort zone.


Mine, and everybody's I hope, the python build scripts are a mess :-)


 It would not be unreasonable for you to be a maintainer of your very own
 Mingw-Python for
 Windows binaries, you know, like a rock star, I mean package maintainer.


I forked the cmake script so in the case we do some enhancements I will
send them back for merge.



 Remember that python has to compile with gcc for linux, so the python
 source is always
 going to be mostly acceptable for mingw-gcc.
 You only have to worry about the boundaries such as system calls and
 library functions.

 It does not seem overly difficult to maintain a big ass patch indefinitely
 if the python
 guys prove too stubborn for your CMake preferences.


Well, the 2.7.x branch must be maintaned only for security and bugs, but no
new features, so it should be not a problem.


 You could have a separate patch for 3.x python as well, and compete with
 them on superior
 packaging until they see the light.  Use CMake packaging to keep it simple
 and fast.


Hehe, 3.x is another war, that we must fight later :-), but we must keep
that in mind and write 2.7 - 3.x compatible code.



 The benefits of CMake are so extreme that I would not rule out making a
 build environment
 in it for wxWidgets or even wxPython.

 Just think of maintaining your trees in whatever version control system
 the upstream folks
 are using, this way you can always regenerate your patches.  But to be
 honest, you may not
 even have to distribute your patches, depending on license.


Well I have no problem in distributing the patches or build script, I think
it's something important to the community,
to have the freedom to rebuild them as needed.



 The trees do not necessarily comprise your product, your product is the
 6 pre-built
 Windows packages, suitable for download and installation by KiCad users as
 a minimum.


Well, I took all that mess (with the benefits too) to KiCad so It's fair to
make it my task will keep you updated
on the efforts, more during tomorrow night, tomorrow I must deliver some
software release for a client.



 On 01/16/2013 02:52 PM, Miguel Angel Ajo Pelayo wrote:
  cmake + python 2.7.1 mingw cross compilation worked here too, for some
 reason cmake tried to link
  dl and failed, I skipped that manually, and worked :-)
 
  That -ldl failure happened to you too Dick?

 Yes, but I did not mention it because we know how easy it is to edit
 CMakeLists.txt
 files.  Comfortable territory.


Ok, that's good that it wasn't my system only.


I'd love to be able to make the 6 stones, (prebuilt packages) and also
manage to auto-build kicad for win32,
so we can start delivering a testing win32 build for all the users.

Anybody has experience in building windows installers with something free?




 
  Miguel Angel Ajo
  http://www.nbee.es
  +34911407752
  skype: ajoajoajo
 
  On 16/01/2013, at 19:50, Miguel Angel Ajo Pelayo miguelan...@nbee.es
 wrote:
 
  This project is full of valuable developers,
 
  I really like the cmake / cross compiling idea, that could lead to
 success and also
  automated KiCad/Win32 builds at any time …
 
  I'm going to try it!! (pausing the swig-gsoc2012-doxygen tests, which
 look good)
 
  I will also try the cross-path with Wayne instructions when they are
 available and see where do we get.
 
  Miguel Angel Ajo
  http://www.nbee.es
  +34911407752
  skype: ajoajoajo
 
  On 16/01/2013, at 19:31, Dick Hollenbeck d...@softplc.com wrote:
 
  On 01/16/2013 11:16 AM, Miguel Angel Ajo Pelayo wrote:
  Other option we could have right now is compile out the wxpython
 support and provide
  only embedded python scripting + python pcbnew module for windows
 users.
 
  In that case, next functionalities are lost:
 
  1) PyCrust shell inside pcbnew
  2) Ability to create and run own wx-uis in the embedded python
 scripting.
 
  And we keep:
 
  3) pcbnew module for commandline python scripting
  4) embedded pcbnew wizards  plugins
 
  Wayne, could you document the steps you followed until now so I can
 try to reproduce it and fight a little bit in this war ?
 
 
  In a half hour last night, I was able to cross compile python for
 windows, on linux, using
  mingw32.
 
  Just get source to tag v2.7.1 python using hg,  then apply David's
 cmake patch.
 
  Build a simple CMAKE_TOOLCHAIN_FILE for your linux mingw toolset, and
 it built just fine.
 
  CMake, Linux, Mingw, cross-compiling, and money are my answer to any
 problems in this topic.
 
  Since they don't exist in sufficient quantity, I am now dropping out
 of this topic.
 
  The talk about using microsoft tools getting pulled back

Re: [Kicad-developers] Python scripting cmake build macros.

[Miguel Angel Ajo Pelayo]

2013/1/17 Dick Hollenbeck d...@softplc.com

 On 01/17/2013 08:56 AM, Miguel Angel Ajo Pelayo wrote:
 
 
 
  2013/1/17 Dick Hollenbeck d...@softplc.com mailto:d...@softplc.com
 
  Nice job, I am glad I was able to inspire you to see the light.
 
 
  Just did nothing but follow the readme, it's good that you found it. I
 hope I will be
  able to port it to the latest 2.7.x python, anyway, I will consider that
 low priority,
  it's not a stopper at all.
 
 
 
  This approach puts the task firmly in your comfort zone.
 
 
  Mine, and everybody's I hope, the python build scripts are a mess :-)
 
 
  It would not be unreasonable for you to be a maintainer of your very
 own
  Mingw-Python for
  Windows binaries, you know, like a rock star, I mean package
 maintainer.
 
 
  I forked the cmake script so in the case we do some enhancements I will
 send them back
  for merge.

 ??

 Was thinking you would maintain a full hg python tree, with the CMake
 stuff in there all
 the time.
 This way you can pull from upstream, and generate a diff which constitutes
 the CMake patch
 at any time.

 The form of David's work now is actually pretty inconvenient to use, since:

 a) it is not actually a patch but rather an overlay.
 b) he makes the mingw stuff optional, and it should not be.

 In your shoes I would maintain a full separate python tree in hg, say
 perhaps on google
 code if they support hg.



Another DVCS system? (waaa)... ';-)

Will give it a try when we have something that can go upstream for 3.x


 
 
 
  Remember that python has to compile with gcc for linux, so the
 python source is always
  going to be mostly acceptable for mingw-gcc.
  You only have to worry about the boundaries such as system calls and
 library functions.
 
  It does not seem overly difficult to maintain a big ass patch
 indefinitely if the python
  guys prove too stubborn for your CMake preferences.
 
 
  Well, the 2.7.x branch must be maintaned only for security and bugs, but
 no new
  features, so it should be not a problem.

 It will be a larger problem getting the patch accepted here than in 3.x,
 according to
 python mailing list postings I've read.

 Your 3.x work is important now in my opinion.  Feel free to build a team
 of helpers.



 
 
  You could have a separate patch for 3.x python as well, and compete
 with them on
  superior
  packaging until they see the light.  Use CMake packaging to keep it
 simple and fast.
 
 
  Hehe, 3.x is another war, that we must fight later :-), but we must keep
 that in mind
  and write 2.7 - 3.x compatible code.


 I do not agree.  The 3.x patch will be easier for the python developers to
 accept,
 according to mailing list postings.


Yes, but 3.x yet feels like bleeding edge for me (wx python with 3.x still
not available
by default in most linux distros as Wayne investigated).

I feel more like we must be prepared for the 3.x switch, but not to do it
right now, because
that means a some rewriting here and there in our own code (not much
really, but some),
and also more pain for linux users.




 
 
 
  The benefits of CMake are so extreme that I would not rule out
 making a build
  environment
  in it for wxWidgets or even wxPython.
 
  Just think of maintaining your trees in whatever version control
 system the upstream
  folks
  are using, this way you can always regenerate your patches.  But to
 be honest, you
  may not
  even have to distribute your patches, depending on license.
 
 
  Well I have no problem in distributing the patches or build script, I
 think it's
  something important to the community,
  to have the freedom to rebuild them as needed.

 Think reverse psychology  tell them they cannot have them first  :)


I was thinking more about KiCad users, that python users :-), but you're
right in that case :-)



 Use CPack within CMake for your windows pre-built packages, this just keys
 off of the
 install() commands.

 It is a totally elegant solution using NSI installer on windows.


Nice!! :) didn't know that, that makes cmake even more awesome.



 If your deliverable is superior to anything out there, i.e. the
 installation package, then
 folks will want to merge your diffs from your python tree.


 :-)



 
 
 
  The trees do not necessarily comprise your product, your product
 is the 6 pre-built
  Windows packages, suitable for download and installation by KiCad
 users as a minimum.
 
 
  Well, I took all that mess (with the benefits too) to KiCad so It's fair
 to make it my
  task will keep you updated
  on the efforts, more during tomorrow night, tomorrow I must deliver some
 software
  release for a client.
 
 
 
  On 01/16/2013 02:52 PM, Miguel Angel Ajo Pelayo wrote:
   cmake + python 2.7.1 mingw cross compilation worked here too, for
 some reason
  cmake tried to link
   dl and failed, I skipped that manually, and worked :-)
  
   That -ldl

Re: [Kicad-developers] Python scripting cmake build macros.

[Miguel Angel Ajo Pelayo]

Thanks a lot Wayne, 

Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 16/01/2013, at 18:56, Wayne Stambaugh stambau...@verizon.net wrote:

 On 1/16/2013 12:16 PM, Miguel Angel Ajo Pelayo wrote:
 Other option we could have right now is compile out the wxpython support and 
 provide
 only embedded python scripting + python pcbnew module for windows users.
 
 In that case, next functionalities are lost:
 
 1) PyCrust shell inside pcbnew
 2) Ability to create and run own wx-uis in the embedded python scripting.
 
 And we keep:
 
 3) pcbnew module for commandline python scripting
 4) embedded pcbnew wizards  plugins
 
 Wayne, could you document the steps you followed until now so I can try to 
 reproduce it and fight a little bit in this war ?
 
 Please see my response to Adam.  I'll add the Pthon command line
 scripting build instructions for Windows using MinGW to
 Documentation/compiling/COMPILING.txt in my next commit.
 
 
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 16/01/2013, at 18:09, Wayne Stambaugh stambau...@verizon.net wrote:
 
 On 1/15/2013 1:38 PM, Dick Hollenbeck wrote:
 On 01/15/2013 12:28 PM, Wayne Stambaugh wrote:
 On 1/15/2013 10:16 AM, Wayne Stambaugh wrote:
 On 1/15/2013 9:33 AM, Dick Hollenbeck wrote:
 On 01/15/2013 08:10 AM, Wayne Stambaugh wrote:
 On 1/14/2013 10:15 PM, Dick Hollenbeck wrote:
 On Jan 14, 2013 8:27 PM, Dick Hollenbeck d...@softplc.com
 mailto:d...@softplc.com wrote:
 I want to simplify the conversation and refer to these needed items 
 as
 windows packages.
 Python
 Python-dev
 WxPython
 WxPython-dev
 WxWidgets
 WxWidgets-dev
 wxPython-dev includes wxWidgets-dev so it should work fine for KiCad
 builds without scripting as well.  It should just be a matter of
 creating the MinGW linker stubs to the MSVC built libraries provided by
 the wxPython-dev package.  The only caveat may be if there is any name
 mangling issues between the two linkers. 
 
 We were reminded recently that stub libraries can use ordinals instead 
 of names.
 
 As long as the DLL entry points follow the Windows DLL ABI  for 
 argument passing and stack
 cleanup, then it is in theory possible.
 
 With so many competing ABIs on Windows, it is also in possible that 
 somebody screwed up
 when building the pre-built DLLs, and you won't notice it until you 
 bring in the second
 compiler technology, i.e. Mingw.
 
 In that case it might mean building the DLLs yourself, instead of 
 repackaging standard
 ones.  And at that point you'd want to kick some ass, just to make 
 somebody pay for their
 disregard for the rest of the [non-Microsoft] world.
 Trust me, it's way past that already.  This has been a complete exercise
 in frustration.  It really shouldn't be this difficult.
 The problem I am having with the MinGW build of wxPython is described at
 the end of the the following thread:
 
 https://groups.google.com/forum/?fromgroups=#!topic/wxpython-users/brmQH4FSCo4
 
 I confirmed that both msvcrt and msvcr90 are being linked to all of the
 wxPython extension files.
 
 Below is an explanation of the differences between the MS runtime 
 libraries.
 
 http://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.80).aspx
 
 There are several solutions but none of them are attractive.
 
 1) Rebuild Python with one of the express versions MSVC and link against
 msvcrt instead of the MSVC specific version.
 
 2) Rebuild mingw10.dll and link against the same msvcr??.dll as the
 installed Python is build against.
 
 3) Do as the thread above discussed and modify Python distutils to
 ignore the version of msvcr??.dll that Python is linked against.
 
 4) Figure out how to build Python with MinGW.  See the following link to
 get an idea of how much of a task that will be.
 
 http://bugs.python.org/issue10504
 
 5) Fix KiCad to build with the correct version of the free (as in beer)
 express version of MSVC used to build Python.
 
 6) Run around the room screaming and pulling out what is left of your 
 hair.
 
 At this point, my desire to see this through has dropped substantially.
 In the near term, I'll just use Linux when I need to do scripting.  I
 will continue to chip away at it but don't expect a solution any time
 soon.  If anyone has a better idea, I'm open to suggestion.
 
 
 Yeah, somebody could actually pay for it.
 
 I'm more than OK with that:)  It's just disappointing that we cannot
 provide our Window's users with scripting support without such a huge
 effort.
 
 
 Expertise and time like this is not free,  and this is a case where 
 opensource fails to
 clear this hurdle without funding.
 
 Notice I did not volunteer, it cannot be free.
 
 
 
 
 
 ___
 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 cmake build macros.

[Miguel Angel Ajo Pelayo]

This project is full of valuable developers, 

I really like the cmake / cross compiling idea, that could lead to success and 
also 
automated KiCad/Win32 builds at any time …

I'm going to try it!! (pausing the swig-gsoc2012-doxygen tests, which look good)

I will also try the cross-path with Wayne instructions when they are available 
and see where do we get.

Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 16/01/2013, at 19:31, Dick Hollenbeck d...@softplc.com wrote:

 On 01/16/2013 11:16 AM, Miguel Angel Ajo Pelayo wrote:
 Other option we could have right now is compile out the wxpython support and 
 provide
 only embedded python scripting + python pcbnew module for windows users.
 
 In that case, next functionalities are lost:
 
 1) PyCrust shell inside pcbnew
 2) Ability to create and run own wx-uis in the embedded python scripting.
 
 And we keep:
 
 3) pcbnew module for commandline python scripting
 4) embedded pcbnew wizards  plugins
 
 Wayne, could you document the steps you followed until now so I can try to 
 reproduce it and fight a little bit in this war ?
 
 
 
 In a half hour last night, I was able to cross compile python for windows, on 
 linux, using
 mingw32.
 
 Just get source to tag v2.7.1 python using hg,  then apply David's cmake 
 patch.
 
 Build a simple CMAKE_TOOLCHAIN_FILE for your linux mingw toolset, and it 
 built just fine.
 
 CMake, Linux, Mingw, cross-compiling, and money are my answer to any problems 
 in this topic.
 
 Since they don't exist in sufficient quantity, I am now dropping out of this 
 topic.
 
 The talk about using microsoft tools getting pulled back into the project are 
 too painful
 to even participate in.
 
 
 
 
 


___
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 cmake build macros.

[Miguel Angel Ajo Pelayo]

cmake + python 2.7.1 mingw cross compilation worked here too, for some reason 
cmake tried to link 
dl and failed, I skipped that manually, and worked :-)

That -ldl failure happened to you too Dick? 

Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 16/01/2013, at 19:50, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote:

 This project is full of valuable developers, 
 
 I really like the cmake / cross compiling idea, that could lead to success 
 and also 
 automated KiCad/Win32 builds at any time …
 
 I'm going to try it!! (pausing the swig-gsoc2012-doxygen tests, which look 
 good)
 
 I will also try the cross-path with Wayne instructions when they are 
 available and see where do we get.
 
 Miguel Angel Ajo
 http://www.nbee.es
 +34911407752
 skype: ajoajoajo
 
 On 16/01/2013, at 19:31, Dick Hollenbeck d...@softplc.com wrote:
 
 On 01/16/2013 11:16 AM, Miguel Angel Ajo Pelayo wrote:
 Other option we could have right now is compile out the wxpython support 
 and provide
 only embedded python scripting + python pcbnew module for windows users.
 
 In that case, next functionalities are lost:
 
 1) PyCrust shell inside pcbnew
 2) Ability to create and run own wx-uis in the embedded python scripting.
 
 And we keep:
 
 3) pcbnew module for commandline python scripting
 4) embedded pcbnew wizards  plugins
 
 Wayne, could you document the steps you followed until now so I can try to 
 reproduce it and fight a little bit in this war ?
 
 
 
 In a half hour last night, I was able to cross compile python for windows, 
 on linux, using
 mingw32.
 
 Just get source to tag v2.7.1 python using hg,  then apply David's cmake 
 patch.
 
 Build a simple CMAKE_TOOLCHAIN_FILE for your linux mingw toolset, and it 
 built just fine.
 
 CMake, Linux, Mingw, cross-compiling, and money are my answer to any 
 problems in this topic.
 
 Since they don't exist in sufficient quantity, I am now dropping out of this 
 topic.
 
 The talk about using microsoft tools getting pulled back into the project 
 are too painful
 to even participate in.
 
 
 
 
 
 


___
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 cmake build macros.

[Miguel Angel Ajo Pelayo]

2013/1/15 Brian Sidebotham brian.sidebot...@gmail.com

 On 15 January 2013 03:15, Dick Hollenbeck d...@softplc.com wrote:


 On Jan 14, 2013 8:27 PM, Dick Hollenbeck d...@softplc.com wrote:
 
  I want to simplify the conversation and refer to these needed items as
 windows packages.
 
  Python
  Python-dev
  WxPython
  WxPython-dev
 WxWidgets
 WxWidgets-dev

 6 packages, not 4.

 
  No source, nothing for our windows kicad builders to build.
 
  The 4 Packages are dowloaded from our website, and installed in known
 places on every supported windows os.
 
  4 packages  can have been built by any compiler in advance, or simply
 repackaged by us in advance, but for new mingw kicad code coming in to sit
 on top or to inter-operate thru the windows dll abi.
 
  I'm wanting the goal to be ageeded upon before the work begins.  I
 think I've stated it here clearly.
 
  Windows ABI says the compiler used to build the 4 packages should not
 matter.  Information hiding says only API headers should be necessary.


 Dick, I totally agree with this! It is how Inkscape do it (
 https://launchpad.net/inkscape-devlibs ) and I think it would be the best
 way forward for KiCad.

 I would be tempted to include swig in there too to make it a bit more
 complete as a set of build dependencies.

 Wayne, thanks so much for looking at this too. The last place I got stuck
 was the missing -lrt problem.



I totally agree, a set of libraries, binaries and headers in a separate
project like dick proposed, and inkscape does, would be perfect.

http://bazaar.launchpad.net/~inkscape.dev/inkscape-devlibs/trunk/files

we could keep something like brian's winbuilder that builds everything,
updates the bin, include, etc dirs... and re-uploads to bzr,
would be great.

May be it could be a split of winbuilder, and then winbuilder can be
simplified to just fetch the libs  build. (It's just an idea for you
brian, in the end winbuilder is your project)

In Windows we also have the x32 / x64 issue, how do we handle that? Two
sets of libraries in different directories?



 Best Regards, Brian.




-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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] Script access to pcb plot

[Miguel Angel Ajo Pelayo]

*
*Back to this old, but importan topic about scripting API documentation: *
**
*I found this at swig site:*
**2012/11/07* - Summer of Code
2012http://sourceforge.net/p/swig/news/2012/11/summer-of-code-2012/

GSoC 2012 was SWIG's third Summer of Code, and this year we
received five slots for projects rela.

Parsing of C/C++ source

code has been improved, so that every declaration/definition can

now be commented. Translation of Doxygen tags to Javadoc and
Python docstrings has been improved and corresponding regression
tests have been implemented. The project mentor, Marko Klopcic
has some great ideas for the future GSoC. The work can be tried
out on the branch gsoc2012-doxygen.
  

I'm going to try that gsoc2012-doxygen branch and see how well or bad does
it work.

2012/8/22 Miguel Angel Ajo Pelayo miguelan...@nbee.es

 Hi Lorenzo, about the patch, the scripting-related-part looks fine,

 Dick, you outlined the scripting-doc problem perfectly.

 I think that after  C++-swig--py  the C++ doxygen info could be
 recovered back into python pydoc information, and then back into another
 (scripting only) doxygen, then that could be extended with examples /
 tutorials.

 I've seen some scripts that did the trick (as far as I remember they
 parsed doxygen XML output and reinjected into .py as pydoc, but not sure
 now). I will put this as my next task as soon as I'm back, but if anyone
 finds motivation to do it from now to 29th then it's more than welcome :-)


 Greethings


 2012/8/22 Dick Hollenbeck d...@softplc.com

 On 08/21/2012 06:35 PM, Wayne Stambaugh wrote:
  On 8/21/2012 12:30 PM, Lorenzo Marcantonio wrote:
  On Tue, Aug 21, 2012 at 11:17:28AM -0500, Dick Hollenbeck wrote:
  Pydocs or Doxygen or _.
 
  This is what keeps us from getting lots of questions, or asking them.
  Although the infrastructure that Miguel is thinking about would apply
 here too.
 
  He wants those docs on the website, and I agree with him.
  Just decide the format at least:P 99% is explained in the demo script
  but there are 'interactions' which will behave strangely (mostly those
  disallowed from the plot dialog).
 
  Doxygen supports Python so there may be some merit in using the current
  Doxygen infrastructure already built into KiCad.  You can do a lot of
  interesting things with groups, sections, custom style sheets, etc. with
  Doxygen.  I'm not sure if Pydocs has the same level of formatting
  sophistication as Doxygen.  I would guess most KiCad developers would be
  more comfortable with Doxygen.  That being said, I don't have a strong
  opinion one way or the other.  What ever direction we chose, it should
  be as simple to generate the scripting documentation as it is to
  generate the current source documentation.  In other words it should be
  fully supported by CMake when creating the build environment.
 
  Wayne


 I think the key issues are these:


 *) The scripting APIs will extend indefinitely, well beyond plotting.

 *) The person developing each respective API is best qualified to
 document each respective
 one.

 *) Swig generates code, and that generation process should not overwrite
 documentation.
 This puts a question mark on pydocs.

 *) Perhaps the best place for the documentation to be maintained is in
 the swig source
 files, *.i.  This is scripting language neutral.
 (I would not rule out using javascript as a scripting language in the
 future.)

 *) Doxygen can be invoked on any number of configuration files, and those
 control which
 files are input.  So it is sensible to consider a separate configuration
 file for what
 goes onto the website, because special css or formating is probable.

 *) Having a larger html footprint on the website puts out a larger net
 for google, and
 subsequently potential users.







 ___
 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




 --

 Miguel Angel Ajo Pelayo
 http://www.nbee.es
 +34 636 52 25 69 begin_of_the_skype_highlighting+34 636 52 25
 69  end_of_the_skype_highlighting %2B34%20636%2052%2025%2069
 skype: ajoajoajo




-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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 cmake build macros.

[Miguel Angel Ajo Pelayo]

It's two different problems,

1) the fixswigimports.py fix the way swig (inside pcbnew.py) loads
pcbnew.so/pyd internally, the swig generated .py has problems to support
internal (inside your own program) object bindings. It's documented, but
not widespread used. We fix it to make it work in both cases, when doing
import pcbnew from inside an scripting-pcbnew  and when doing import
pcbnew from standalone/commandline python.

2) At the time we started with scripting, I raised some discussion about
this topic, and thought that python2.x has more widespread library support
(compared to python 3 advantages).


It's also true, that, if we made the move now, and having phoenix in place,
it could be less disruptive if we find ourselves forced to move into
python3 at some moment in time.

Anyway, that most probably would force us to move our wrappers into SIP and
get the both wrappings (internal wrapping, external wrapping).

I'm not really opposed to do it, or do some testing, but I'm really
concerned about:

1) SIP support (no so widespread support at swig, that will let us work
with other languages too)
2) SIP internal/external wrapping
3) Phoenix real support. (is it only a test branch or will it be supported
in time?, it could also become the main branch at some time..)
4) My time has become a little scarce: I have challenging big projects for
this year, and also a new (first) daughter, which I love, but it's a time
black hole 8]


I think I dropped all my thoughts about the topic. :-)




2013/1/14 Dick Hollenbeck d...@softplc.com

 On 01/13/2013 06:57 PM, Wayne Stambaugh wrote:
  On 1/13/2013 4:58 PM, Miguel Angel Ajo Pelayo wrote:
  The CMake module you were looking for is FindPythonInterp which finds
 the Python interpreter and sets the PYTHON_EXECUTABLE variable.  You can
 define a specific Python version by setting PythonInterp_FIND_VERSION. I
 still have some validation to do on Linux when both Python3 and Python2 are
 installed just to make sure everything works as expected.
 
  Also found that using #!/usr/bin/env python2 in fixswigimports.py
 breaks the windows build so I am currently working on a solution to this
 problem.  I changed python2 to python and it fixes the build on windows but
 may cause problems for Linux.  I'm thinking since the python interpreter is
 being called to run this script that the #!/usr/bin/env python2 line is
 even necessary.
  Is there any reason to run this script outside of the KiCad scripting
 build?
  It's only needed when we make a scripting build and the pcbnew.py is
 regenerated. It will fix the way it looks for _pcbnew.so / .pyd so when
 running from a pcbnew with embedded python, it won't
  reload the DLL and use the internal swigs to pcbnew objects.
 
  If not, then I should be able to safely remove this from
 fixswigimports.py.  If it cannot be removed, I may have to use CMake to
 generate this file on the fly to add the correct Python environment string
 to the beginning of the file.
  May be we can just call $PYTHON_EXECUTABLE fixswigimports.py, most
 probably this little script will run within python3, but not sure.
  The last I recall is that code generated by SWIG is not yet compatible
  with Python 3.  That's why Python 2 is still required to build wxPython.
It's been a while since I've used SWIG so maybe that has changed.
  Until I see a wxPython release built against Python 3, I'll stick with
  Python 2.

 Swig is there now:

 http://www.swig.org/Doc1.3/Python.html#Python_python3support

 wxpython for python 3.x is known as Phoenix, and it is also probably
 build-able at this time.


 But they did not do the interface to C++ in Phoenix using SWIG.



 https://groups.google.com/forum/?fromgroups=#!topic/wxpython-users/p69PjUnMN-c

 Used SIP instead:

 http://riverbankcomputing.co.uk/software/sip/intro

 In any case it looks like python 3.x is an option, as it should be, since
 its about 5
 years old or more.






 ___
 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




-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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] Log of opened and closed applications in KiCad launcher

[Miguel Angel Ajo Pelayo]

Hi Jacobo, thanks for the patch!,

Doesn't look bad for me, but please check:

   * You removed the WINDOWS special case, does it work in Windows now
without removing
the aFlags ?

-bool ProcessExecute( const wxString aCommandLine, int aFlags )
+int ProcessExecute( const wxString aCommandLine, int aFlags, wxProcess
*callback )
 {
-#ifdef __WINDOWS__
-intpid = wxExecute( aCommandLine );
-return pid ? true : false;
-#else
-wxProcess* process = wxProcess::Open( aCommandLine, aFlags );
-return (process != NULL) ? true : false;
-#endif
+return wxExecute( aCommandLine, aFlags, callback );
 }


   * Line 280 of patch: +if( pid  0 ) {-- check coding style
policy, opening brace must be at the next line.

   I checked it manually, all the other coding style looks right to my eye.



2013/1/14 Jacobo Aragunde Pérez jaragu...@igalia.com

 Hi,

 we have been doing some changes in the launcher, to make it more aware
 of what's happening with its children applications.

 In particular, we have added a log of the opened and closed
 applications. When the launcher starts another KiCad application a
 message will be logged to the message area in the window. When the
 application is closed, the launcher will be notified and it will show
 another message. And since a picture is worth a thousand words, I'm
 attaching a screenshot to complement the explanation.

 This patch implies some changes in the way children applications are
 spawned. In particular:

 * We modified ProcessExecute at common.cpp to always use wxExecute. It
 was only used in Windows compilations but it works perfectly in Linux
 too, and should work in OS X also. I guess

 * ExecuteFile at gestfich.cpp and ProcessExecute at common.cpp now
 receive a callback as a parameter and return an identifier of the
 process or 0 in case of error.

 Do you think this is useful in upstream KiCad? Also feel free to comment
 on the patch or suggest changes.

 Best regards,
 --
 Jacobo Aragunde
 Software Engineer at Igalia

 ___
 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




-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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 cmake build macros.

[Miguel Angel Ajo Pelayo]

In my OSX system, if we add -lrt to linker, it will fail.

So It should be keep, at least for my OSX version.




2013/1/14 Wayne Stambaugh stambau...@verizon.net

 On 1/12/2013 8:02 PM, Miguel Angel Ajo Pelayo wrote:
 I use all three names without much care, Mac OSX, OSX, Mac OS, but I
 think you're right.
 
  I checked, and it's implemented using gettimeofday :-)
 
  ajo$ otool -t -I -v -V getrunningmicrosecs.cpp.o
  getrunningmicrosecs.cpp.o:
  (__TEXT,__text) section
  __Z19GetRunningMicroSecsv:
    pushq   %rbp
  0001  movq%rsp,%rbp
  0004  subq$0x20,%rsp
  0008  leaq0xf0(%rbp),%rdi
  000c  movq$__Z19GetRunningMicroSecsv,%rsi
  0016  callq   _gettimeofday
  -
  001b  imulq   $0x000f4240,0xf0(%rbp),%rsi
  0023  movslq  0xf8(%rbp),%rdi
  0027  addq%rdi,%rsi
  002a  movl%esi,%ecx
  002c  movl%eax,0xec(%rbp)
  002f  movl%ecx,%eax
  0031  addq$0x20,%rsp
  0035  popq%rbp
  0036  ret
 
  Miguel Angel Ajo
  http://www.nbee.es
  +34911407752
  skype: ajoajoajo

 I guess this means that NOT APPLE should be removed from the
 conditional check to add rt to PCBNEW_EXTRA_LIBS.  Can someone with
 OSX please confirm this?

 
  On 13/01/2013, at 01:41, Dick Hollenbeck d...@softplc.com wrote:
 
  On 01/12/2013 06:05 PM, Miguel Angel Ajo Pelayo wrote:
  Where is it included exactly?, after pulling head now it fails on
 MacOS:
 
  Linking CXX shared module _pcbnew.so
  ld: library not found for -lrt
 
 
  No -lrt on MacOS?
 
  I wonder how common/GetRunningMicroSecs() gets implemented on MacOS?
 
  gettimeofday( tv, 0 );  ?
 
  Besides, what is MacOS?  I thought it was called OSX?
 
 
 
 




-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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 cmake build macros.

[Miguel Angel Ajo Pelayo]

Thank you for checking it so carefully ;-)


2013/1/14 Wayne Stambaugh stambau...@verizon.net

 On 1/14/2013 9:10 AM, Miguel Angel Ajo Pelayo wrote:
  In my OSX system, if we add -lrt to linker, it will fail.
 
  So It should be keep, at least for my OSX version.

 Thanks Miguel. Apparently on OSX gettimeofday() is being pulled in from
 another library already defined in the link list.

 
 
 
 
  2013/1/14 Wayne Stambaugh stambau...@verizon.net
  mailto:stambau...@verizon.net
 
  On 1/12/2013 8:02 PM, Miguel Angel Ajo Pelayo wrote:
  I use all three names without much care, Mac OSX, OSX, Mac OS,
  but I think you're right.
  
   I checked, and it's implemented using gettimeofday :-)
  
   ajo$ otool -t -I -v -V getrunningmicrosecs.cpp.o
   getrunningmicrosecs.cpp.o:
   (__TEXT,__text) section
   __Z19GetRunningMicroSecsv:
     pushq   %rbp
   0001  movq%rsp,%rbp
   0004  subq$0x20,%rsp
   0008  leaq0xf0(%rbp),%rdi
   000c  movq
  $__Z19GetRunningMicroSecsv,%rsi
   0016  callq   _gettimeofday
   -
   001b  imulq   $0x000f4240,0xf0(%rbp),%rsi
   0023  movslq  0xf8(%rbp),%rdi
   0027  addq%rdi,%rsi
   002a  movl%esi,%ecx
   002c  movl%eax,0xec(%rbp)
   002f  movl%ecx,%eax
   0031  addq$0x20,%rsp
   0035  popq%rbp
   0036  ret
  
   Miguel Angel Ajo
   http://www.nbee.es
   +34911407752 tel:%2B34911407752
   skype: ajoajoajo
 
  I guess this means that NOT APPLE should be removed from the
  conditional check to add rt to PCBNEW_EXTRA_LIBS.  Can someone
 with
  OSX please confirm this?
 
  
   On 13/01/2013, at 01:41, Dick Hollenbeck d...@softplc.com
  mailto:d...@softplc.com wrote:
  
   On 01/12/2013 06:05 PM, Miguel Angel Ajo Pelayo wrote:
   Where is it included exactly?, after pulling head now it fails
  on MacOS:
  
   Linking CXX shared module _pcbnew.so
   ld: library not found for -lrt
  
  
   No -lrt on MacOS?
  
   I wonder how common/GetRunningMicroSecs() gets implemented on
 MacOS?
  
   gettimeofday( tv, 0 );  ?
  
   Besides, what is MacOS?  I thought it was called OSX?
  
  
  
  
 
 
 
 
  --
 
  Miguel Angel Ajo Pelayo
  http://www.nbee.es
  +34 636 52 25 69
  skype: ajoajoajo




-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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 cmake build macros.

[Miguel Angel Ajo Pelayo]

As usual, I forgot to hit Reply-all :-)

On 15/01/2013, at 00:04, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote:

 
 
 On 14/01/2013, at 22:59, Wayne Stambaugh stambau...@verizon.net wrote:
 
 On 1/14/2013 3:12 AM, Miguel Angel Ajo Pelayo wrote:
 It's two different problems, 
 
 1) the fixswigimports.py fix the way swig (inside pcbnew.py) loads
 pcbnew.so/pyd http://pcbnew.so/pyd internally, the swig generated .py
 has problems to support internal (inside your own program) object
 bindings. It's documented, but not widespread used. We fix it to make it
 work in both cases, when doing import pcbnew from inside an
 scripting-pcbnew  and when doing import pcbnew from
 standalone/commandline python.
 
 2) At the time we started with scripting, I raised some discussion about
 this topic, and thought that python2.x has more widespread library
 support (compared to python 3 advantages). 
 
 I'll take a look at it and see if I can make the KiCad scripting work on
 Python 2  3.  I may have to write some creative CMake code to get it to
 work but it should be possible.
 
 It might require also some work in initialization of the python engine (may 
 be more),
 because they are initialized in a different way. Python 2 initializes as an 
 static interpreter
 (only one for your process), and Python 3 initializes as an object, so you 
 can have
 many in interpreters in your project, also calls to python api could differ, 
 but not sure.
 
 
 I have a quick question regarding the KICAD_SCRIPTIN_WXPYTHON option.
 When this option is enabled, is wxPython.h included in any of the SWIG
 generated code.  I did quick grep of the scripting folders and didn't
 see wxPython.h included anywhere so the only other place I can think
 that it would end up is in the SWIG generated code.  If it's not, that
 will make life a whole lot easier.  If it is, building wxPython on
 Windows to install the development files is proving to be painful.
 
 
 I don't understand exactly what you mean.
 
 The include to wxpython It's outside the pcbnew directory in 
 kicadroot/scripting/python_scripting.h,
 the wxpython thing is used to be able to create widgets/dialogs from python 
 that can be
 referenced/used in C++, or the other way around. Also for the nice pycrust 
 shell.
 
 
 
 
 It's also true, that, if we made the move now, and having phoenix in
 place, it could be less disruptive if we find ourselves forced to move
 into python3 at some moment in time. 
 
 Anyway, that most probably would force us to move our wrappers into SIP
 and get the both wrappings (internal wrapping, external wrapping).
 
 I'm not really opposed to do it, or do some testing, but I'm really
 concerned about:
 
 1) SIP support (no so widespread support at swig, that will let us work
 with other languages too)
 2) SIP internal/external wrapping
 3) Phoenix real support. (is it only a test branch or will it be
 supported in time?, it could also become the main branch at some time..)
 
 Even if Phoenix becomes the default way to build wxPython, I see no
 reason to switch from SWIG to SIP.  SWIG gives use the opportunity to
 support other scripting languages.  SIP appears to be a Python only code
 generator.
 
 I think you're right 
 
 
 4) My time has become a little scarce: I have challenging big projects
 for this year, and also a new (first) daughter, which I love, but it's a
 time black hole 8]
 
 There is no better way to spend your time than with your family.
 
 Everything must be kept in a balance :-)
 
 
 
 
 I think I dropped all my thoughts about the topic. :-)
 
 
 
 
 2013/1/14 Dick Hollenbeck d...@softplc.com mailto:d...@softplc.com
 
   On 01/13/2013 06:57 PM, Wayne Stambaugh wrote:
 On 1/13/2013 4:58 PM, Miguel Angel Ajo Pelayo wrote:
 The CMake module you were looking for is FindPythonInterp which
   finds the Python interpreter and sets the PYTHON_EXECUTABLE
   variable.  You can define a specific Python version by setting
   PythonInterp_FIND_VERSION. I still have some validation to do on
   Linux when both Python3 and Python2 are installed just to make sure
   everything works as expected.
 
 Also found that using #!/usr/bin/env python2 in
   fixswigimports.py breaks the windows build so I am currently working
   on a solution to this problem.  I changed python2 to python and it
   fixes the build on windows but may cause problems for Linux.  I'm
   thinking since the python interpreter is being called to run this
   script that the #!/usr/bin/env python2 line is even necessary.
 Is there any reason to run this script outside of the KiCad
   scripting build?
 It's only needed when we make a scripting build and the pcbnew.py
   is regenerated. It will fix the way it looks for _pcbnew.so / .pyd
   so when running from a pcbnew with embedded python, it won't
 reload the DLL and use the internal swigs to pcbnew objects.
 
 If not, then I should be able to safely remove this from
   fixswigimports.py.  If it cannot be removed, I may have to use CMake

Re: [Kicad-developers] Python scripting cmake build macros.

[Miguel Angel Ajo Pelayo]

On 14/01/2013, at 23:05, Dick Hollenbeck d...@softplc.com wrote:

 
 On Jan 14, 2013 3:59 PM, Wayne Stambaugh stambau...@verizon.net wrote:
 
  On 1/14/2013 3:12 AM, Miguel Angel Ajo Pelayo wrote:
   It's two different problems,
  
   1) the fixswigimports.py fix the way swig (inside pcbnew.py) loads
   pcbnew.so/pyd http://pcbnew.so/pyd internally, the swig generated .py
   has problems to support internal (inside your own program) object
   bindings. It's documented, but not widespread used. We fix it to make it
   work in both cases, when doing import pcbnew from inside an
   scripting-pcbnew  and when doing import pcbnew from
   standalone/commandline python.
  
   2) At the time we started with scripting, I raised some discussion about
   this topic, and thought that python2.x has more widespread library
   support (compared to python 3 advantages).
 
  I'll take a look at it and see if I can make the KiCad scripting work on
  Python 2  3.  I may have to write some creative CMake code to get it to
  work but it should be possible.
 
  I have a quick question regarding the KICAD_SCRIPTIN_WXPYTHON option.
  When this option is enabled, is wxPython.h included in any of the SWIG
  generated code.  I did quick grep of the scripting folders and didn't
  see wxPython.h included anywhere so the only other place I can think
  that it would end up is in the SWIG generated code.  If it's not, that
  will make life a whole lot easier.  If it is, building wxPython on
  Windows to install the development files is proving to be painful.
 
 
 We talked about providing prebuilt [wx] python binaries.
 

I think we talked about providing python binaries because the .pyd compiled in 
gcc
wouldn't be compatible with mainstream python (compiled in MSVC) or some 
similar problem.

But I think it definitely needed to provide wxpython with the full set, or we 
are loosing a lot
of functionality/scripting power.

I'm trying to make it work at OSX, and I managed to do it, but now I'm trying 
to find
a way to pack it all together (libraries + exe) or build it all statically (as 
Marco Serantoni recommended me),
but I'm yet a little bit lost in OSX.



___
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 cmake build macros.

[Miguel Angel Ajo Pelayo]

 
 The CMake module you were looking for is FindPythonInterp which finds the 
 Python interpreter and sets the PYTHON_EXECUTABLE variable.  You can define a 
 specific Python version by setting PythonInterp_FIND_VERSION. I still have 
 some validation to do on Linux when both Python3 and Python2 are installed 
 just to make sure everything works as expected.
 
 Also found that using #!/usr/bin/env python2 in fixswigimports.py breaks 
 the windows build so I am currently working on a solution to this problem.  I 
 changed python2 to python and it fixes the build on windows but may cause 
 problems for Linux.  I'm thinking since the python interpreter is being 
 called to run this script that the #!/usr/bin/env python2 line is even 
 necessary.  

 Is there any reason to run this script outside of the KiCad scripting build?  

It's only needed when we make a scripting build and the pcbnew.py is 
regenerated. It will fix the way it looks for _pcbnew.so / .pyd so when running 
from a pcbnew with embedded python, it won't
reload the DLL and use the internal swigs to pcbnew objects.

 If not, then I should be able to safely remove this from fixswigimports.py.  
 If it cannot be removed, I may have to use CMake to generate this file on the 
 fly to add the correct Python environment string to the beginning of the file.

May be we can just call $PYTHON_EXECUTABLE fixswigimports.py, most probably 
this little script will run within python3, but not sure.
 
 
 Thanks for the fix!!
 
 Your welcome.  It might take me another day or so to get this all sorted out 
 but I'll get there.  Once I get this part of it working, the next task is to 
 figure out how get the wxPython scripting part of it working which will 
 likely be a lot more involved.  My primary motivation to get Python scripting 
 working is to create pick-n-place report files for auto-insertion machines.  
 It makes more sense to me to use a scripting language to generate the files 
 than C++.
 

Wow, that's a great usage. :-)

 Wayne
 
 
 Enviado desde un móvil
 
 El 12/01/2013, a las 18:15, Wayne Stambaugh stambau...@verizon.net 
 escribió:
 
 I've been attempting to resolve my Python scripting build issues on MinGW32 
 on Windows and I have a few questions for the folks who wrote the cmake 
 build code.  Why are we not using cmake's FindPythonInterp() instead of 
 specifying the python executable on the path?  Specifying the Python 
 interpreter on the command line at build time seems unnecessary to me.  
 CMake's FindPythonInterp supports defining a a specific version of Python 
 by defining Python_ADDITIONAL_VERSIONS.  I'm guessing we would want to do 
 that because python2 is currently defined as the default Python interpreter 
 so I'm also assuming that the scripting code generated does not work with 
 Python3.
 
 There is also a link bug on MinGW because rt is defined as one of the link 
 libraries in SWIG_LINK_LIBRARIES.  Actually, someone attempted to fix it by 
 adding and conditional statement to only add rt on Linux but they forgot to 
 take it out of the original list.
 
 For future reference the indentation level for CMake files is 4 spaces and 
 CMake statements should be lower case.
 
 If no one objects, I will fix these issues which should make the Python 
 scripting builds more reliable.
 
 Thank you for all your efforts in bringing scripting to KiCad.
 
 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
 
 


___
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] Data encapsulation in class_track

[Miguel Angel Ajo Pelayo]

I found what happens, it's no real problem with the patch, but with the
dependency identification from swig .i files to class_track.h ,
dependencies are set manually now because cmake cannot determine that the
.i file depends on class_track.h and that pcbnew_wrap.cxx and
scripting/pcbnewPYTHON_wrap.cxx don't get rebuilt, so they stay trying to
access attributes that have became protected.

just remove pcbnew_wrap.cxx and scripting/pcbnewPYTHON_wrap.cxx and run
make again, they will be regenerated, and it must be fine.

I have this error now, but it seems unrelated to the swig party:

/Users/ajo/Documents/work/kicad/kicad/pcbnew/move_or_drag_track.cpp:631:13:
error: no matching function for call to 'Collect_TrackSegmentsToDrag'
Collect_TrackSegmentsToDrag( GetBoard(), aTrack-GetStart(),
^~~
/Users/ajo/Documents/work/kicad/kicad/pcbnew/./drag.h:179:6: note:
candidate function not viable: 2nd argument ('const wxPoint') would lose
const qualifier
void Collect_TrackSegmentsToDrag( BOARD* aPcb, wxPoint aRefPos, int
aLayerMask,
 ^
1 error generated.
make[2]: *** [pcbnew/CMakeFiles/_pcbnew.dir/move_or_drag_track.cpp.o] Error
1
make[2]: *** Waiting for unfinished jobs



2013/1/11 Miguel Angel Ajo Pelayo miguelan...@nbee.es

 As Dick said, for some reason swig tries to create Python
 accessors for those protected attributes by himself.

 Yesterday night only had time to start testing it  finding the reasons, I
 hope this night will finally get the diff updated.





 2013/1/10 Miguel Angel Ajo Pelayo miguelan...@nbee.es

 Hi Heikki, Dick  Wayne.

 I will be very happy to try it this night and fix the swig/scripting
 things. I will resubmit an updated diff for head.

 In the case I forget for some reason, please send me a remainder email, I
 have many things to do at home tonight,  but I think this is a very good
 change to commit.

 Sincerely,
 Mike


 2013/1/10 Wayne Stambaugh stambau...@verizon.net

 On 1/10/2013 10:30 AM, Dick Hollenbeck wrote:
  Heikki Pulkkinen,
 
  Thanks very much.
 
  I would like to commit this one attached, which is rebased to current
 testing.
  I had to hand add some rejects.
 
 
  But it will not allow building with SCRIPTING enabled.
 
 
  So more work is needed.
 
  Please get some SWIG help if you need it and resubmit the patch.
 
  Your help is appreciated.  Certainly Wayne and I share your goals of
 proper accessor usage.

 Absolutely.  The importance of good coding practices cannot be
 overstated.  Thank you Heikki.


 ___
 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




 --

 Miguel Angel Ajo Pelayo
 http://www.nbee.es
 +34 636 52 25 69
 skype: ajoajoajo




 --

 Miguel Angel Ajo Pelayo
 http://www.nbee.es
 +34 636 52 25 69
 skype: ajoajoajo




-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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 cmake build macros.

[Miguel Angel Ajo Pelayo]

Where is it included exactly?, after pulling head now it fails on MacOS:

Linking CXX shared module _pcbnew.so
ld: library not found for -lrt

can we add an if NOT WIN32 AND NOT APPLE for the -lrt inclusion ? 

Greetings! :-)

Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 12/01/2013, at 22:52, Dick Hollenbeck d...@softplc.com wrote:

 On 01/12/2013 11:15 AM, Wayne Stambaugh wrote:
 I've been attempting to resolve my Python scripting build issues on 
 MinGW32 on Windows and I have a few questions for the folks who wrote 
 the cmake build code.  Why are we not using cmake's FindPythonInterp() 
 instead of specifying the python executable on the path?  Specifying the 
 Python interpreter on the command line at build time seems unnecessary 
 to me.  CMake's FindPythonInterp supports defining a a specific version 
 of Python by defining Python_ADDITIONAL_VERSIONS.  I'm guessing we would 
 want to do that because python2 is currently defined as the default 
 Python interpreter so I'm also assuming that the scripting code 
 generated does not work with Python3.
 
 There is also a link bug on MinGW because rt is defined as one of the 
 link libraries in SWIG_LINK_LIBRARIES.  Actually, someone attempted to 
 fix it by adding and conditional statement to only add rt on Linux but 
 they forgot to take it out of the original list.
 
 
 No, the sequence was the other way around.  The rt was added by me recently, 
 and I
 probably broke the windows DLL doing it, while fixing the linux DEBUG DLL.
 
 So just removing that is evidently not going to be adequate.  Please test the 
 Linux DEBUG
 DSO build with scripting to verify it still works.
 
 Linux + Debug + DSO
 
 is the problem case.
 
 The missing symbol without librt was the profiling helper, clock_gettime() 
 and it was
 getting pulled in because GetRunningMicroSecs() is evidently still in a Debug 
 build, which
 in and of itself is fine.
 That should be allowed.
 
 Thanks for fixing the Windows build.
 
 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] Data encapsulation in class_track

[Miguel Angel Ajo Pelayo]

Hehe, no problem, It would be great to find a way of fixing that dependency 
problems automatically, 
they keep me head-scratching with problems like this from time to time.

I will pull head again, and include the const fix that makes clang compiler 
happier.

Thanks for your time too Dick, and Heikki, thanks for your patch, this work 
it's something the normal
users won't see but it's something that all developers enjoy and that will make 
the work of adding
new features into KiCad easier.

Sincerely,
Mike
 
Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 13/01/2013, at 01:06, Dick Hollenbeck d...@softplc.com wrote:

 
 Committed this patch in 3901.
 
 Thanks Heikki
 
 Miguel, sorry to waste your time.  A preceding make clean would have 
 avoided that confusion.
 
 Thanks for your time however.
 
 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] Data encapsulation in class_track

[Miguel Angel Ajo Pelayo]

As Dick said, for some reason swig tries to create Python
accessors for those protected attributes by himself.

Yesterday night only had time to start testing it  finding the reasons, I
hope this night will finally get the diff updated.





2013/1/10 Miguel Angel Ajo Pelayo miguelan...@nbee.es

 Hi Heikki, Dick  Wayne.

 I will be very happy to try it this night and fix the swig/scripting
 things. I will resubmit an updated diff for head.

 In the case I forget for some reason, please send me a remainder email, I
 have many things to do at home tonight,  but I think this is a very good
 change to commit.

 Sincerely,
 Mike


 2013/1/10 Wayne Stambaugh stambau...@verizon.net

 On 1/10/2013 10:30 AM, Dick Hollenbeck wrote:
  Heikki Pulkkinen,
 
  Thanks very much.
 
  I would like to commit this one attached, which is rebased to current
 testing.
  I had to hand add some rejects.
 
 
  But it will not allow building with SCRIPTING enabled.
 
 
  So more work is needed.
 
  Please get some SWIG help if you need it and resubmit the patch.
 
  Your help is appreciated.  Certainly Wayne and I share your goals of
 proper accessor usage.

 Absolutely.  The importance of good coding practices cannot be
 overstated.  Thank you Heikki.


 ___
 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




 --

 Miguel Angel Ajo Pelayo
 http://www.nbee.es
 +34 636 52 25 69
 skype: ajoajoajo




-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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] Data encapsulation in class_track

[Miguel Angel Ajo Pelayo]

Hi Heikki, Dick  Wayne.

I will be very happy to try it this night and fix the swig/scripting
things. I will resubmit an updated diff for head.

In the case I forget for some reason, please send me a remainder email, I
have many things to do at home tonight,  but I think this is a very good
change to commit.

Sincerely,
Mike


2013/1/10 Wayne Stambaugh stambau...@verizon.net

 On 1/10/2013 10:30 AM, Dick Hollenbeck wrote:
  Heikki Pulkkinen,
 
  Thanks very much.
 
  I would like to commit this one attached, which is rebased to current
 testing.
  I had to hand add some rejects.
 
 
  But it will not allow building with SCRIPTING enabled.
 
 
  So more work is needed.
 
  Please get some SWIG help if you need it and resubmit the patch.
 
  Your help is appreciated.  Certainly Wayne and I share your goals of
 proper accessor usage.

 Absolutely.  The importance of good coding practices cannot be
 overstated.  Thank you Heikki.


 ___
 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




-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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] New here !

[Miguel Angel Ajo Pelayo]

Hi Léo, 

We recently moved to a Confluence instance for the main site at 
http://www.kicad-pcb.org. It works quite well, 
may be what it needs now it's more content. I think main developers are happy 
with bzr and launchpad as it works. (I prefer
other solutions also, but bzr works reasonably well, and right now it lets 
developers put all their effort in the KiCad software
itself.)

  How good are you at C++ ? , may be you could try contributing to the 
software itself. Find a feature you'd like to see on KiCad,
ask as you need, start a branch, follow the guidelines, and then ask for merge 
on testing branch.

   We're also plenty of ideas and a couple of bugs in the bug tracker.

   I started with a little one, and I liked it, code quality in KiCad is 
getting better and better on every commit.

   Greetings,
Mike.
 
Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 17/12/2012, at 18:45, OpenSourceWay opensource...@laposte.net wrote:

 Hello !
 
 
 I'm new here, and I'll introduce myself. I'm french, and I've created a lot 
 of free projects like OpenSourceSoft - http://opensourcesoft.fr.nf - and 
 other, mainly listed in my personal website.
 
 As 2013 will be a new year, I'll try to stop creating open source project 
 alone but I want to participate in usefull big projects, like Kicad. I'm also 
 an electronics student and I want to create some fun PCB over my Linux Laptop 
 but Cadence PSD isn't free and doesn't work.
 
 So, I'll try you to create this really big project, wich is already 
 powerfull. I don't know if you need that but I think the website can be 
 reorganised, without using a lot of external tools as launchpad, libs, chat… 
 CodingTeam is a good soft wich include wiki, source repository, xmpp server, 
 bug tracking tool, localisation tool, forum…
 
  
 Thanks for all, and sorry for my bad english.
 
 
 Léo
 
 -- 
 OpenSourceWay
   opensource...@laposte.net
   opensourceway.fr.nf
 ___
 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 Developers

[Miguel Angel Ajo Pelayo]

On 11/12/2012, at 18:33, Wayne Stambaugh stambau...@verizon.net wrote:
 
 I can't think of a good reason to keep CvPcb around if you can easily
 assign footprints in the schematic editor.  Most of the comments I've
 seen have been fairly negative about having to use a separate tool to
 assign footprints to components in KiCad.  It would also be one less
 thing to maintain.


Avoiding the maintenance of another component is a good point, but, I think
CvPcb is an advantage compared to other EDA tools. It's awesome easy to review
and change footprints thanks to CvPcb compared to other tools I've used,
where you need to go component by component changing every footprint (painful).

Just an opinion.
___
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