Re: [Kicad-developers] [RFC] proposal of adjusted netlist dialog

[A. V. Dolganoff]

As a user, the new one makes more sense to me, you've my vote.

On Wed, Oct 22, 2014 at 4:02 AM, Mark Roszko  wrote:

> Hello,
>
> So I've been going through the UI to make it nicer.
>
> The netlist dialog right now is a bit odd.
>
> These marked up images show why, basically the functionality is
> grouped oddly on the dialog.
> http://i.imgur.com/0JK0d3g.png
> http://i.imgur.com/OrfrH14.png
>
> My proposal is this new arrangement:
> http://i.imgur.com/sek8ebW.png
> http://i.imgur.com/izeCybB.png
>
> Main change:
> wxNotebook turned into a wxSimplebook.
> A separate dropdown added to control the netlist formats to allow
> putting the add/remove buttons on the same line.
> A dropdown is nicer because in the end we are only selecting a single
> plugin to generate a netlist with anyway and this is more
> representative of the functionality.
>
>
>
>
> Thoughts? Code wise I've already done it but feedback is nice :D
>
>
>
> --
> Mark
>
> ___
> Mailing list: https://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] Stable release version numbers.

[Brian Sidebotham]

On 21 October 2014 23:25, Wayne Stambaugh  wrote:

> 3.0.0 sounds good to me.
>
> Wayne

I'm good with the triplet, and any number sounds fine to me! :D

Best Regards,

Brian.

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

Re: [Kicad-developers] Updates to authors.txt

[Brian Sidebotham]

> On 21 October 2014 04:37, Andrew Zonenberg  wrote:
>> Hi all,
>>
>> While browsing recent commits I saw some updates to authors.txt which
>> prompted me to take a look at the file and noticed two minor issues.
>>
>> 1) "maintener" (line 15) should be spelled "maintainer"
>> 2) Neither Cirillo Bernardo nor myself are listed as contributors.
>>
>> Thanks :)
>>
>> --
>> Andrew Zonenberg
>> PhD student, security group
>> Computer Science Department
>> Rensselaer Polytechnic Institute
>> http://colossus.cs.rpi.edu/~azonenberg/
>>

Added in BZR 5212.

Thanks for you contributions Andrew!

Best Regards,

Brian.

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

Re: [Kicad-developers] new documentation format

[Maciej Sumiński]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Marco,

Thank you very much for such a comprehensive comparison. Generation of
pdf & html output using the scripts & AsciiDoc files you have provided
was really simple and quick.
AsciiDoc seems easy to read even in the plain text format. Given that
you already have a tested workflow for .odt conversion and
translations, I vote for AsciiDoc. If you, as a translator, find the
tool convenient then it sounds like a good choice.

Regards,
Orson

On 10/21/2014 11:58 PM, Marco Ciampa wrote:
> - file name/extension conventions

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBAgAGBQJUR3uhAAoJEBRwGu1hpbJ12uIH/joHhxYeLm18EdgZEEMgipqc
Pgi+mosFbOdu5dPcup6WGLeMpB203gV//CSvOeYBYNTY0/bT66p1RwbN1MKzZimM
6y/sSCs94QlQMVaUxc5SsP3GQfSZWHUR2kvApqL5LwKloUM1+cd5bOL3hQe/rBIW
fWTcRL0awNmomfNPnYenSCDJ9vbfY3SQmFrelDiEUIvMjPQykxus6XstZJVhk5Xl
tTBydCbCvOf+XcEmxZTjRIXac62Cd3WOp/MpD1a9qCiHtmsFCZ+nHV0MTghZem3s
TlX6nY6/QSoIP+lHZNCenVfUSJdYihJvd5D48Frqa2oS3z//2dEIQs4isB+pMmU=
=iqCJ
-END PGP SIGNATURE-

___
Mailing list: https://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 documentation format

[Brian Sidebotham]

On 21 October 2014 22:58, Marco Ciampa  wrote:
> Hello,
>
> talking about the project of switching the KiCad documentation to an
> easier to maintain and translate format, after some experiments, (I know,
> I am slow ... I am not a real programmer) I have produced something
> to check.
>
> This is in effect something like an RFC: I need your comments,
> suggestions, improvements (and patches are welcome).
>
> I started writing an email, this:
>
> https://github.com/ciampix/kicad-doc/blob/master/doc/kicad-doc-doc.adoc
>
> it got bigger and bigger and it is not finished, but I though that it
> could be useful to publish it before being closed because I do not want
> to write it all alone.
>
> Along with this text there are two dirs in src: asciidoc and rest.
> Basically these folders contain the cvpcb manual converted into asciidoc
> and rest and the small example scripts to create docs into html/pdf/epub.
>
> The complete cycle is:
>
> (odt->)asciidoc/rest
> ->translation extraction
> ->(translation)
> ->merge->nationalized pdf/html/epub
>
> The examples are in asciidoc and rest but the asciidoc toolchain is
> almost the same for markdown. I have reported some comments about
> txt2tags, textile and sisu but I do not have studied these tools enough
> to have a clear idea about.
>
> So I ask you to:
>
>  - have a say about the work
>  - try my examples
>  - express your preferences about:
>
>   a. the documentation text format
>   b. the data organization of the manuals, in particular:
>- file name/extension conventions
>- source files folders,
>- image folders
>- makefiles/cmake configuration (I do not know anything about cmake...)
>- any other thing
>
> If you have any doubt or problem about anything please express yourself.
>
> I do not think we are in a hurry so I think that we can our time to
> decide and clear out any quandary.
>
> When we will have decided the source text format we will start converting
> all the manuals. Please bear in mind that *anything written in a foreign
> language that is not strictly adherent to the english reference manual
> will have to be removed*.
>
> So, if you think that something you have written in a localized manual is
> not present in the reference, try to translate it in English for the
> inclusion in the reference: doing this may save your translation and give
> a hand to the whole project.
>
> PS: ... and please forgive my terrible English.
>
> --
>
>
> Marco Ciampa

Excellent work Marco, firstly your English is not terrible, my Italian is!

Thank-you for doing a thorough job in looking at the various tools
available and it's great to have the view of a translator looking from
the ease of internationalising a document properly as that's not an
easy task.

I've managed to read most of your document and everything looks sound
to me, I agree with your conclusions, but then I use asciidoc every
day of the week, so it's easy for me to agree with! At least, asciidoc
is not very intrusive into the text of the document, it is
light-weight.

I was worried that po4a was not available on Windows, but it appears
it's pretty easy to get going on windows. I'm sure the rest of the
toolchain is easy to get running on Windows. See some information here
with regards to po4a on windows:
http://ehc.ac/p/ourorgan/svn/754/tree//trunk/HOWTO-build-help-on-Windows

I'm excited for us to move to a text based documentation format as
soon as possible.

I imagine our workflow after we've decided on the markup source format
needs to be:

(1) Convert odt to text-based markup
(2) Get a document writer (could be a current dev(s)) to go through
the manuals and tidy up grammar, out-of-date screenshots, layout
issues, etc.
(3) Make sure the documentation build process is documented (which
you've already done an excellent job starting, thanks!!)
(4) Create the po files ready for translation and that should lead to
translators being able to start translating the new manuals.

The fact that everything, including images drops back to the master
English version if there's not a specific language version is
absolutely excellent.

Before reading your article I was pro-Markdown as the solution we
should use, but I am very convinced by your extensive work around the
translation of the documentation and I understand the limitations of
Markdown, so asciidoc is a fine conclusion to me.

Thanks again for the update and hard work!!

Best Regards,

Brian.

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

Re: [Kicad-developers] Updates to authors.txt

[Nick Østergaard]

Hi

I also think that Cirilo Bernardo should not be forgotten, he made
great contributions especially in regard to the 3D tools.

Nick

2014-10-22 11:17 GMT+02:00 Brian Sidebotham :
>> On 21 October 2014 04:37, Andrew Zonenberg  
>> wrote:
>>> Hi all,
>>>
>>> While browsing recent commits I saw some updates to authors.txt which
>>> prompted me to take a look at the file and noticed two minor issues.
>>>
>>> 1) "maintener" (line 15) should be spelled "maintainer"
>>> 2) Neither Cirillo Bernardo nor myself are listed as contributors.
>>>
>>> Thanks :)
>>>
>>> --
>>> Andrew Zonenberg
>>> PhD student, security group
>>> Computer Science Department
>>> Rensselaer Polytechnic Institute
>>> http://colossus.cs.rpi.edu/~azonenberg/
>>>
>
> Added in BZR 5212.
>
> Thanks for you contributions Andrew!
>
> Best Regards,
>
> Brian.
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Updates to authors.txt

[Brian Sidebotham]

On 22 October 2014 11:11, Nick Østergaard  wrote:
> Hi
>
> I also think that Cirilo Bernardo should not be forgotten, he made
> great contributions especially in regard to the 3D tools.
>
> Nick
>

Oh, so sorry - that was mentioned in the original email!!

Will be there in a minute...

Best Regards,

Brian.

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

Re: [Kicad-developers] Updates to authors.txt

[Brian Sidebotham]

On 22 October 2014 11:22, Brian Sidebotham  wrote:
> On 22 October 2014 11:11, Nick Østergaard  wrote:
>> Hi
>>
>> I also think that Cirilo Bernardo should not be forgotten, he made
>> great contributions especially in regard to the 3D tools.
>>
>> Nick
>>
>
> Oh, so sorry - that was mentioned in the original email!!
>
> Will be there in a minute...
>
> Best Regards,
>
> Brian.

Done in 5213, Sorry Cirilo!

Best Regards,

Brian.

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

Re: [Kicad-developers] [RFC] proposal of adjusted netlist dialog

[Sergey A. Borshch]

Sorry, I've lost first message in topic from Mark, so I paste my one as reply to 
this one.


Mark,
 while you are deep inside this dialog source code, is it possible to add a 
checkbox "do not show this dialog again, just silently generate netlist file 
after clicking to icon on toolbar"? Dialog still must be shown from main menu 
but not from toolbar after checking this checkbox.


 Working on project I really _need_ this dialog first time only, all next 
hundred times until route is done I use this dialog to press "Generate" button only.


On 22.10.2014 11:07, A. V. Dolganoff wrote:

As a user, the new one makes more sense to me, you've my vote.

On Wed, Oct 22, 2014 at 4:02 AM, Mark Roszko mailto:mark.ros...@gmail.com>> wrote:

Hello,

So I've been going through the UI to make it nicer.

The netlist dialog right now is a bit odd.

These marked up images show why, basically the functionality is
grouped oddly on the dialog.
http://i.imgur.com/0JK0d3g.png
http://i.imgur.com/OrfrH14.png

My proposal is this new arrangement:
http://i.imgur.com/sek8ebW.png
http://i.imgur.com/izeCybB.png

Main change:
wxNotebook turned into a wxSimplebook.
A separate dropdown added to control the netlist formats to allow
putting the add/remove buttons on the same line.
A dropdown is nicer because in the end we are only selecting a single
plugin to generate a netlist with anyway and this is more
representative of the functionality.




Thoughts? Code wise I've already done it but feedback is nice :D



--
Mark

___
Mailing list: https://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




--
Regards,
  Sergey A. Borshchmailto: sb...@sourceforge.net
SB ELDI ltd. Riga, Latvia

___
Mailing list: https://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] proposal of adjusted netlist dialog

[Tim Hutt]

Or you could add another button to the toolbar which always bypasses the
dialog. (And add it to the menu too! I don't know why so many actions are
toolbar-only in kicad.)

On 22 October 2014 12:43, Sergey A. Borshch 
wrote:

> Sorry, I've lost first message in topic from Mark, so I paste my one as
> reply to this one.
>
> Mark,
>  while you are deep inside this dialog source code, is it possible to add
> a checkbox "do not show this dialog again, just silently generate netlist
> file after clicking to icon on toolbar"? Dialog still must be shown from
> main menu but not from toolbar after checking this checkbox.
>
>  Working on project I really _need_ this dialog first time only, all next
> hundred times until route is done I use this dialog to press "Generate"
> button only.
>
> On 22.10.2014 11:07, A. V. Dolganoff wrote:
>
>> As a user, the new one makes more sense to me, you've my vote.
>>
>> On Wed, Oct 22, 2014 at 4:02 AM, Mark Roszko > > wrote:
>>
>> Hello,
>>
>> So I've been going through the UI to make it nicer.
>>
>> The netlist dialog right now is a bit odd.
>>
>> These marked up images show why, basically the functionality is
>> grouped oddly on the dialog.
>> http://i.imgur.com/0JK0d3g.png
>> http://i.imgur.com/OrfrH14.png
>>
>> My proposal is this new arrangement:
>> http://i.imgur.com/sek8ebW.png
>> http://i.imgur.com/izeCybB.png
>>
>> Main change:
>> wxNotebook turned into a wxSimplebook.
>> A separate dropdown added to control the netlist formats to allow
>> putting the add/remove buttons on the same line.
>> A dropdown is nicer because in the end we are only selecting a single
>> plugin to generate a netlist with anyway and this is more
>> representative of the functionality.
>>
>>
>>
>>
>> Thoughts? Code wise I've already done it but feedback is nice :D
>>
>>
>>
>> --
>> Mark
>>
>> ___
>> Mailing list: https://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
>>
>>
>
> --
> Regards,
>   Sergey A. Borshchmailto: sb...@sourceforge.net
> SB ELDI ltd. Riga, Latvia
>
>
> ___
> Mailing list: https://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] Incremental build speeds.

[Tim Hutt]

Hi,

I'm trying to do some kicad development on windows. I initially downloaded
& built it with kicad-winbuilder which went without a hitch. Kicad runs
fine.

However, if I perform a null-rebuild (i.e. I don't change anything and just
run `make` again), it takes about 70 seconds to run. That's quite a while
isn't it? My PC is pretty fast (quad core 3.3 GHz i5, 16GB RAM), so I
wouldn't have expected it to take so long. Is this just a feature of cmake?

Build output is below. How long does it take for you guys? Am I doing
something wrong?

Cheers,

Tim

-

C:\Users\Tim\Local\kicad-winbuilder-3.4\build\Release>mingw32-make
[  0%] Built target boost
[ 30%] Built target bitmaps
[ 30%] Built target lib-dependencies
[ 38%] Built target common
[ 38%] Generating headers containing GLSL source code
Headers are up-to-date
[ 38%] Built target shader_headers
[ 39%] Built target gal
[ 43%] Built target pcbcommon
[ 44%] Built target 3d-viewer
[ 44%] Built target polygon
[ 45%] Built target pcad2kicadpcb
[ 46%] Built target openssl
[ 46%] Built target avhttp
[ 46%] Built target github_plugin
[ 47%] Built target cvpcb_kiface
[ 47%] Built target cvpcb
[ 57%] Built target eeschema_kiface
[ 58%] Built target eeschema
[ 61%] Built target gerbview_kiface
[ 61%] Built target gerbview
[ 61%] Built target lib_dxf
[ 62%] Built target idf3
[ 64%] Built target pnsrouter
[ 79%] Built target _pcbnew
[ 79%] Fixing swig_import_helper in Kicad scripting modules
swig_import_helper fixed for
C:/Users/Tim/Local/kicad-winbuilder-3.4/build/Relea
se/pcbnew/pcbnew.py
[ 79%] Built target FixSwigImportsModuleScripting
[ 94%] Built target pcbnew_kiface
[ 94%] Built target pcbnew
[ 95%] Built target pl_editor_kiface
[ 95%] Built target pl_editor
[ 96%] Built target potrace
[ 96%] Built target bitmap2component
[ 98%] Built target pcb_calculator_kiface
[ 98%] Built target pcb_calculator
[100%] Built target kicad
[100%] Built target dxf2idf
[100%] Built target idf2vrml
[100%] Built target idfcyl
[100%] Built target idfrect
___
Mailing list: https://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] Incremental build speeds.

[Brian Sidebotham]

On 22 October 2014 14:01, Tim Hutt  wrote:
> Hi,
>
> I'm trying to do some kicad development on windows. I initially downloaded &
> built it with kicad-winbuilder which went without a hitch. Kicad runs fine.
>
> However, if I perform a null-rebuild (i.e. I don't change anything and just
> run `make` again), it takes about 70 seconds to run. That's quite a while
> isn't it? My PC is pretty fast (quad core 3.3 GHz i5, 16GB RAM), so I
> wouldn't have expected it to take so long. Is this just a feature of cmake?
>
> Build output is below. How long does it take for you guys? Am I doing
> something wrong?
>
> Cheers,
>
> Tim
>
> -
>
> C:\Users\Tim\Local\kicad-winbuilder-3.4\build\Release>mingw32-make
> [  0%] Built target boost
> [ 30%] Built target bitmaps
> [ 30%] Built target lib-dependencies
> [ 38%] Built target common
> [ 38%] Generating headers containing GLSL source code
> Headers are up-to-date
> [ 38%] Built target shader_headers
> [ 39%] Built target gal
> [ 43%] Built target pcbcommon
> [ 44%] Built target 3d-viewer
> [ 44%] Built target polygon
> [ 45%] Built target pcad2kicadpcb
> [ 46%] Built target openssl
> [ 46%] Built target avhttp
> [ 46%] Built target github_plugin
> [ 47%] Built target cvpcb_kiface
> [ 47%] Built target cvpcb
> [ 57%] Built target eeschema_kiface
> [ 58%] Built target eeschema
> [ 61%] Built target gerbview_kiface
> [ 61%] Built target gerbview
> [ 61%] Built target lib_dxf
> [ 62%] Built target idf3
> [ 64%] Built target pnsrouter
> [ 79%] Built target _pcbnew
> [ 79%] Fixing swig_import_helper in Kicad scripting modules
> swig_import_helper fixed for
> C:/Users/Tim/Local/kicad-winbuilder-3.4/build/Relea
> se/pcbnew/pcbnew.py
> [ 79%] Built target FixSwigImportsModuleScripting
> [ 94%] Built target pcbnew_kiface
> [ 94%] Built target pcbnew
> [ 95%] Built target pl_editor_kiface
> [ 95%] Built target pl_editor
> [ 96%] Built target potrace
> [ 96%] Built target bitmap2component
> [ 98%] Built target pcb_calculator_kiface
> [ 98%] Built target pcb_calculator
> [100%] Built target kicad
> [100%] Built target dxf2idf
> [100%] Built target idf2vrml
> [100%] Built target idfcyl
> [100%] Built target idfrect
>

Hi Tim,

You can specify parallel jobs with make using the -j option. That will
speed things up for you.

gcc on Windows is slow however, it really does take much more time to
compile on Windows compared to Linux on the same hardware. You will
certainly get down to perhaps 15s using parallel jobs.

Best Regards,

Brian.

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

Re: [Kicad-developers] Incremental build speeds.

[Benoît Roehr]

It takes about 20 seconds for me.

Ubuntu 14.04
i7 @ 2.2GHz

I've read somewhere linux is better for compiling because of something 
called pipelining. It is present on linux (or better implemented) but 
not on windows.


On 22/10/2014 15:01, Tim Hutt wrote:

Hi,

I'm trying to do some kicad development on windows. I initially 
downloaded & built it with kicad-winbuilder which went without a 
hitch. Kicad runs fine.


However, if I perform a null-rebuild (i.e. I don't change anything and 
just run `make` again), it takes about 70 seconds to run. That's quite 
a while isn't it? My PC is pretty fast (quad core 3.3 GHz i5, 16GB 
RAM), so I wouldn't have expected it to take so long. Is this just a 
feature of cmake?


Build output is below. How long does it take for you guys? Am I doing 
something wrong?


Cheers,

Tim

-

C:\Users\Tim\Local\kicad-winbuilder-3.4\build\Release>mingw32-make
[  0%] Built target boost
[ 30%] Built target bitmaps
[ 30%] Built target lib-dependencies
[ 38%] Built target common
[ 38%] Generating headers containing GLSL source code
Headers are up-to-date
[ 38%] Built target shader_headers
[ 39%] Built target gal
[ 43%] Built target pcbcommon
[ 44%] Built target 3d-viewer
[ 44%] Built target polygon
[ 45%] Built target pcad2kicadpcb
[ 46%] Built target openssl
[ 46%] Built target avhttp
[ 46%] Built target github_plugin
[ 47%] Built target cvpcb_kiface
[ 47%] Built target cvpcb
[ 57%] Built target eeschema_kiface
[ 58%] Built target eeschema
[ 61%] Built target gerbview_kiface
[ 61%] Built target gerbview
[ 61%] Built target lib_dxf
[ 62%] Built target idf3
[ 64%] Built target pnsrouter
[ 79%] Built target _pcbnew
[ 79%] Fixing swig_import_helper in Kicad scripting modules
swig_import_helper fixed for 
C:/Users/Tim/Local/kicad-winbuilder-3.4/build/Relea

se/pcbnew/pcbnew.py
[ 79%] Built target FixSwigImportsModuleScripting
[ 94%] Built target pcbnew_kiface
[ 94%] Built target pcbnew
[ 95%] Built target pl_editor_kiface
[ 95%] Built target pl_editor
[ 96%] Built target potrace
[ 96%] Built target bitmap2component
[ 98%] Built target pcb_calculator_kiface
[ 98%] Built target pcb_calculator
[100%] Built target kicad
[100%] Built target dxf2idf
[100%] Built target idf2vrml
[100%] Built target idfcyl
[100%] Built target idfrect



___
Mailing list: https://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] Incremental build speeds.

[Lorenzo Marcantonio]

On Wed, Oct 22, 2014 at 02:01:44PM +0100, Tim Hutt wrote:
> Hi,
> 
> I'm trying to do some kicad development on windows. I initially downloaded
> & built it with kicad-winbuilder which went without a hitch. Kicad runs
> fine.
> 
> However, if I perform a null-rebuild (i.e. I don't change anything and just
> run `make` again), it takes about 70 seconds to run. That's quite a while
> isn't it? My PC is pretty fast (quad core 3.3 GHz i5, 16GB RAM), so I
> wouldn't have expected it to take so long. Is this just a feature of cmake?

It needs to check *a lot* of dependencies and timestamps; also each
submakefile has its own overhead.

Probably cmake is slightly slower than automake, but IMHO not really
significant on a typical build. In fact even with distcc, I find linking
the heaviest step... consider this output for a full debug build:

-rwxr-xr-x 1 lomarcan lomarcan 268684355 ott  4 15:51 _pcbnew.kiface

Yes, it's more than 256MB of stuff :D it takes a while to do that (if
only to read and write from disk).

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

Re: [Kicad-developers] Incremental build speeds.

[Benoît Roehr]

On 22/10/2014 15:16, Lorenzo Marcantonio wrote:

On Wed, Oct 22, 2014 at 02:01:44PM +0100, Tim Hutt wrote:

Hi,

I'm trying to do some kicad development on windows. I initially downloaded
& built it with kicad-winbuilder which went without a hitch. Kicad runs
fine.

However, if I perform a null-rebuild (i.e. I don't change anything and just
run `make` again), it takes about 70 seconds to run. That's quite a while
isn't it? My PC is pretty fast (quad core 3.3 GHz i5, 16GB RAM), so I
wouldn't have expected it to take so long. Is this just a feature of cmake?

It needs to check *a lot* of dependencies and timestamps; also each
submakefile has its own overhead.

Probably cmake is slightly slower than automake, but IMHO not really
significant on a typical build. In fact even with distcc, I find linking
the heaviest step... consider this output for a full debug build:

-rwxr-xr-x 1 lomarcan lomarcan 268684355 ott  4 15:51 _pcbnew.kiface

Yes, it's more than 256MB of stuff :D it takes a while to do that (if
only to read and write from disk).
Yes, and also, some antiviruses are filtering access to disk, which 
takes a bit of time each time a file is accessed. I remember very slow 
build for Arduino (30-40 seconds) in Win7 when using Commodo Firewall.





___
Mailing list: https://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] Incremental build speeds.

[Brian Sidebotham]

On 22 October 2014 14:16, Benoît Roehr  wrote:
> It takes about 20 seconds for me.
>
> Ubuntu 14.04
> i7 @ 2.2GHz
>
> I've read somewhere linux is better for compiling because of something
> called pipelining. It is present on linux (or better implemented) but not on
> windows.
>

The compilers turn source code into pre-processed source code, then
into assembler which is then assembled to get the object code. This
used to use a temporary file at each intermediary stage, however these
days I'm sure the -pipe option is enabled on all platforms for gcc and
uses pipes instead of temporary files.

So I don't think that's any longer a difference between Windows and Linux.

Best Regards,

Brian.

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

Re: [Kicad-developers] Incremental build speeds.

[Benoît Roehr]

On 22/10/2014 15:33, Brian Sidebotham wrote:

On 22 October 2014 14:16, Benoît Roehr  wrote:

It takes about 20 seconds for me.

Ubuntu 14.04
i7 @ 2.2GHz

I've read somewhere linux is better for compiling because of something
called pipelining. It is present on linux (or better implemented) but not on
windows.


The compilers turn source code into pre-processed source code, then
into assembler which is then assembled to get the object code. This
used to use a temporary file at each intermediary stage, however these
days I'm sure the -pipe option is enabled on all platforms for gcc and
uses pipes instead of temporary files.

So I don't think that's any longer a difference between Windows and Linux.

Okay thanks for the info ;)


Best Regards,

Brian.



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

Re: [Kicad-developers] Incremental build speeds.

[Tomasz Wlostowski]

On 22.10.2014 15:01, Tim Hutt wrote:

Hi,




However, if I perform a null-rebuild (i.e. I don't change anything and
just run `make` again), it takes about 70 seconds to run.


Hi Tim,

I found it very annoying while developing the P&S, where I needed to 
very frequently rebuild and re-link a small part of pcbnew. My solution 
was to:

- exclude the P&S sources from CMakeLists.txt
- build the P&S using a standard makefile (using same compiler options 
as CMake)

- link it as a DLL with _pcbnew.kiface

By doing this, I only had to rebuild the P&S DLL (taking few seconds) 
instead of waiting ~2 minutes for the CMake to solve dependencies and 
GCC linker to produce new .kiface image.


It's just a dumb and ugly hack, but may help in some cases.

Cheers,
Tom

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

Re: [Kicad-developers] [RFC] proposal of adjusted netlist dialog

[Wayne Stambaugh]

Very nice.  Much cleaner look and feel.  I see no issues assuming the
underlying netlist generation code still performs properly.


On 10/21/2014 10:02 PM, Mark Roszko wrote:
> Hello,
> 
> So I've been going through the UI to make it nicer.
> 
> The netlist dialog right now is a bit odd.
> 
> These marked up images show why, basically the functionality is
> grouped oddly on the dialog.
> http://i.imgur.com/0JK0d3g.png
> http://i.imgur.com/OrfrH14.png
> 
> My proposal is this new arrangement:
> http://i.imgur.com/sek8ebW.png
> http://i.imgur.com/izeCybB.png
> 
> Main change:
> wxNotebook turned into a wxSimplebook.
> A separate dropdown added to control the netlist formats to allow
> putting the add/remove buttons on the same line.
> A dropdown is nicer because in the end we are only selecting a single
> plugin to generate a netlist with anyway and this is more
> representative of the functionality.
> 
> 
> 
> 
> Thoughts? Code wise I've already done it but feedback is nice :D
> 
> 
> 


___
Mailing list: https://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] parallel builds?

[Wayne Stambaugh]

The reason you don't see either of these problems after the first build
is that boost and the source files created by the make_lexer() cmake
macro are already created so all of the dependencies are satisfied and
the build completes without issues.  You would only see the errors on a
new source build and possibly after running `make clean`.  Although I'm
not sure all of these files get remove on `make clean`.  It's hard to
believe that we have been bit by the missing files generated by
make_lexer() before now because none of the generated files are marked
as dependencies when building their respective targets.  I should have a
fix later today but I have some testing to do.

On 10/22/2014 1:59 AM, Bernhard Stegmaier wrote:
> Hi,
> 
> I didn’t use any other version of boost… always use the custom version that 
> still comes with KiCad.
> I also did a lot of builds recently, mostly with -j4 and never had problems 
> with that…
> 
> 
> Regards,
> Bernhard
> 
> On 21.10.2014, at 21:41, Wayne Stambaugh  wrote:
> 
>> Adam,
>>
>> Try applying the attached patch.  It looks like on osx builds, boost is
>> not being made a dependency so the boost build is not complete before
>> the common library is getting built on parallel builds.  I think
>> Bernhard was using a patched version of boost 1.56 which he has
>> installed on his system so he would not have seen this problem since he
>> wasn't using our custom 1.54 version of boost.  If this doesn't fix it,
>> maybe Bernhard can take a look at it.
>>
>> Wayne
>>
>> On 10/21/2014 3:07 PM, Adam Wolf wrote:
>>> I don't get these errors when building with -j1 *after* a clean.
>>>
>>> Adam Wolf
>>>
>>> On Tue, Oct 21, 2014 at 1:56 PM, Bob Gustafson >> > wrote:
>>>
>>>Do you get that error when building with -j1 ?
>>>
>>>
>>>On 10/21/2014 01:14 PM, Adam Wolf wrote:
Hi folks,

I'm doing a *lot* of builds prepping these nightly builds, and
especially on OS X, I'm seeing a lot of issues with parallel
builds, where something like this happens:

In file included from 
 /Users/jenkins/remoteroot/workspace/KiCadMacBuild/kicad/common/draw_panel_gal.cpp:33:

 /Users/jenkins/remoteroot/workspace/KiCadMacBuild/kicad/include/view/view.h:30:10:
  fatal error: 'boost/unordered/unordered_map.hpp' file not found
#include 

I have a little logic in there where I first try to build with
-j4, and if it fails, i rerun make with -j1, but that doesn't seem
to help.

Any thoughts, folks?

Adam Wolf
Cofounder and Engineer
W&L, LLC


>>>
>>>
>>>___
>>>Mailing list: https://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] Incremental build speeds.

[Henner Zeller]

There are a lot of dependencies (=timestamps) to be checked, so having
a solid state disk can probably speed up things dramatically.

Also, for incremental re-compile after a make clean, you might want to
look into ccache, that allows to locally cache compiler outputs (not
sure if that is available on Windows proper, but an internet search
suggests as such). ccache speeds up a (make clean ; make) to abot 3:20
minutes. It looks like there is a lot of time wasted in partially
re-building and re-packing the boos library, but I think that is a
separate discussion (apparently it makes sense on some systems)

Compiling things in parallel is always a good idea, and as others
pointed out, the -j option is good for that. In my case, I just set
the environment variable
MAKEFLAGS to '-j6' to make sure I never forget that.

(FWIW, just typing 'make' on an already build KiCAD (I think this is
what you are doing) takes about 3.6 seconds on my ~3 year old Linux
machine (4 core i5 2500k, probably similar to yours) - I do have a
solid state disk, but can't compare what difference that makes)

The rest of the differences might be just Linux/Windows differences,
but you can only really tell if you do the same on your Linux
partition and compare.

On 22 October 2014 06:01, Tim Hutt  wrote:
> Hi,
>
> I'm trying to do some kicad development on windows. I initially downloaded &
> built it with kicad-winbuilder which went without a hitch. Kicad runs fine.
>
> However, if I perform a null-rebuild (i.e. I don't change anything and just
> run `make` again), it takes about 70 seconds to run. That's quite a while
> isn't it? My PC is pretty fast (quad core 3.3 GHz i5, 16GB RAM), so I
> wouldn't have expected it to take so long. Is this just a feature of cmake?
>
> Build output is below. How long does it take for you guys? Am I doing
> something wrong?
>
> Cheers,
>
> Tim
>
> -
>
> C:\Users\Tim\Local\kicad-winbuilder-3.4\build\Release>mingw32-make
> [  0%] Built target boost
> [ 30%] Built target bitmaps
> [ 30%] Built target lib-dependencies
> [ 38%] Built target common
> [ 38%] Generating headers containing GLSL source code
> Headers are up-to-date
> [ 38%] Built target shader_headers
> [ 39%] Built target gal
> [ 43%] Built target pcbcommon
> [ 44%] Built target 3d-viewer
> [ 44%] Built target polygon
> [ 45%] Built target pcad2kicadpcb
> [ 46%] Built target openssl
> [ 46%] Built target avhttp
> [ 46%] Built target github_plugin
> [ 47%] Built target cvpcb_kiface
> [ 47%] Built target cvpcb
> [ 57%] Built target eeschema_kiface
> [ 58%] Built target eeschema
> [ 61%] Built target gerbview_kiface
> [ 61%] Built target gerbview
> [ 61%] Built target lib_dxf
> [ 62%] Built target idf3
> [ 64%] Built target pnsrouter
> [ 79%] Built target _pcbnew
> [ 79%] Fixing swig_import_helper in Kicad scripting modules
> swig_import_helper fixed for
> C:/Users/Tim/Local/kicad-winbuilder-3.4/build/Relea
> se/pcbnew/pcbnew.py
> [ 79%] Built target FixSwigImportsModuleScripting
> [ 94%] Built target pcbnew_kiface
> [ 94%] Built target pcbnew
> [ 95%] Built target pl_editor_kiface
> [ 95%] Built target pl_editor
> [ 96%] Built target potrace
> [ 96%] Built target bitmap2component
> [ 98%] Built target pcb_calculator_kiface
> [ 98%] Built target pcb_calculator
> [100%] Built target kicad
> [100%] Built target dxf2idf
> [100%] Built target idf2vrml
> [100%] Built target idfcyl
> [100%] Built target idfrect
>
>
> ___
> Mailing list: https://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] Incremental build speeds.

[Nick Østergaard]

2014-10-22 15:16 GMT+02:00 Lorenzo Marcantonio :
> On Wed, Oct 22, 2014 at 02:01:44PM +0100, Tim Hutt wrote:
>> Hi,
>>
>> I'm trying to do some kicad development on windows. I initially downloaded
>> & built it with kicad-winbuilder which went without a hitch. Kicad runs
>> fine.
>>
>> However, if I perform a null-rebuild (i.e. I don't change anything and just
>> run `make` again), it takes about 70 seconds to run. That's quite a while
>> isn't it? My PC is pretty fast (quad core 3.3 GHz i5, 16GB RAM), so I
>> wouldn't have expected it to take so long. Is this just a feature of cmake?
>
> It needs to check *a lot* of dependencies and timestamps; also each
> submakefile has its own overhead.
>
> Probably cmake is slightly slower than automake, but IMHO not really
> significant on a typical build. In fact even with distcc, I find linking
> the heaviest step... consider this output for a full debug build:
>
> -rwxr-xr-x 1 lomarcan lomarcan 268684355 ott  4 15:51 _pcbnew.kiface
>
> Yes, it's more than 256MB of stuff :D it takes a while to do that (if
> only to read and write from disk).

My _pcbnew.kiface is just 16MB, but I guess that is because it is a
Release build. No wonder a Debug build takes so much longer to build
then. (If that is why your kiface is so big)

___
Mailing list: https://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 documentation format

[Kerusey Karyu]

To: kicad-developers
From: Marco Ciampa
Date: Tue, 21 Oct 2014 23:58:17 +0200

> If you have any doubt or problem about anything please
> express yourself.
>

I consider that the use of formats to create documentation using
translations in the form of translation database (.po files) will,
despite the many advantages, also some disadvantages for translators.

While the use of such forms of translations for the UI is quite
comfortable, the use of that form for translating a continuous text
(which is result of the train of thoughts) can be very uncomfortable
for translators.

Why? The main difficulty will be limited visibility of the logic of the
text and its layout (indentation, spacing). There will be situations
where we will need to translate a fragment out of context. I as a
translator prefer also see more of the text to be able to, among
others, eliminate repetition of words and the use of synonyms. My
native language is very flexible in this topic.

Taking also the specificity of translated texts, unfortunately, it is
in so many cases impossible to translate word for word. Sometimes you
have to break down complex sentence into two (or even three) sentences
that the reader can easily assimilate them.
By translating KiCad user manual I had to just do that many times.
Sometimes adding something from each other to avoid ambiguity.

So. That’s my (maybe wrong) doubts.

Regards
Kerusey Karyu

___
Mailing list: https://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] parallel builds?

[Bernhard Stegmaier]

Hmm… I often did clean builds, i.e., I completely wipe out my build directory 
via “rm -rf *” and do a new cmake configure run afterwards. That doesn’t touch 
and rebuild boost living in the original source folder, yes.
But, the lexer stuff should be deleted when wiping out the build folder and 
they are not created in the source folder (otherwise bzr would show them)?


Regards,
Bernhard


On 22.10.2014, at 17:04, Wayne Stambaugh  wrote:

> The reason you don't see either of these problems after the first build
> is that boost and the source files created by the make_lexer() cmake
> macro are already created so all of the dependencies are satisfied and
> the build completes without issues.  You would only see the errors on a
> new source build and possibly after running `make clean`.  Although I'm
> not sure all of these files get remove on `make clean`.  It's hard to
> believe that we have been bit by the missing files generated by
> make_lexer() before now because none of the generated files are marked
> as dependencies when building their respective targets.  I should have a
> fix later today but I have some testing to do.
> 
> On 10/22/2014 1:59 AM, Bernhard Stegmaier wrote:
>> Hi,
>> 
>> I didn’t use any other version of boost… always use the custom version that 
>> still comes with KiCad.
>> I also did a lot of builds recently, mostly with -j4 and never had problems 
>> with that…
>> 
>> 
>> Regards,
>> Bernhard
>> 
>> On 21.10.2014, at 21:41, Wayne Stambaugh  wrote:
>> 
>>> Adam,
>>> 
>>> Try applying the attached patch.  It looks like on osx builds, boost is
>>> not being made a dependency so the boost build is not complete before
>>> the common library is getting built on parallel builds.  I think
>>> Bernhard was using a patched version of boost 1.56 which he has
>>> installed on his system so he would not have seen this problem since he
>>> wasn't using our custom 1.54 version of boost.  If this doesn't fix it,
>>> maybe Bernhard can take a look at it.
>>> 
>>> Wayne
>>> 
>>> On 10/21/2014 3:07 PM, Adam Wolf wrote:
 I don't get these errors when building with -j1 *after* a clean.
 
 Adam Wolf
 
 On Tue, Oct 21, 2014 at 1:56 PM, Bob Gustafson >>> > wrote:
 
   Do you get that error when building with -j1 ?
 
 
   On 10/21/2014 01:14 PM, Adam Wolf wrote:
>   Hi folks,
> 
>   I'm doing a *lot* of builds prepping these nightly builds, and
>   especially on OS X, I'm seeing a lot of issues with parallel
>   builds, where something like this happens:
> 
>   In file included from 
> /Users/jenkins/remoteroot/workspace/KiCadMacBuild/kicad/common/draw_panel_gal.cpp:33:
>   
> /Users/jenkins/remoteroot/workspace/KiCadMacBuild/kicad/include/view/view.h:30:10:
>  fatal error: 'boost/unordered/unordered_map.hpp' file not found
>   #include 
> 
>   I have a little logic in there where I first try to build with
>   -j4, and if it fails, i rerun make with -j1, but that doesn't seem
>   to help.
> 
>   Any thoughts, folks?
> 
>   Adam Wolf
>   Cofounder and Engineer
>   W&L, LLC
> 
> 
 
 
   ___
   Mailing list: https://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


___
Mailing list: https://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] Incremental build speeds.

[Tim Hutt]

Oh yeah I forgot to mention I have an SSD, and -j4 did not make a huge
difference (can't remember exact time).

I like the DLL solution though! I'm planning to (maybe) do a bit of work on
the 3d viewer as it is not much code and quite self-contained. Seems to be
a static library at the moment so I will maybe have a go at changing it to
a dynamic one.

I might also try porting to QBS (Qt's new build system) which is much
faster than make in my experience.

Cheers,

Tim

On 22 October 2014 14:40, Tomasz Wlostowski 
wrote:

> On 22.10.2014 15:01, Tim Hutt wrote:
>
>> Hi,
>>
>>
>  However, if I perform a null-rebuild (i.e. I don't change anything and
>> just run `make` again), it takes about 70 seconds to run.
>>
>
> Hi Tim,
>
> I found it very annoying while developing the P&S, where I needed to very
> frequently rebuild and re-link a small part of pcbnew. My solution was to:
> - exclude the P&S sources from CMakeLists.txt
> - build the P&S using a standard makefile (using same compiler options as
> CMake)
> - link it as a DLL with _pcbnew.kiface
>
> By doing this, I only had to rebuild the P&S DLL (taking few seconds)
> instead of waiting ~2 minutes for the CMake to solve dependencies and GCC
> linker to produce new .kiface image.
>
> It's just a dumb and ugly hack, but may help in some cases.
>
> Cheers,
> Tom
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] new documentation format

[Nick Østergaard]

2014-10-22 17:57 GMT+02:00 Kerusey Karyu :
>
> To: kicad-developers
> From: Marco Ciampa
> Date: Tue, 21 Oct 2014 23:58:17 +0200
>
>> If you have any doubt or problem about anything please
>> express yourself.
>>
>
> I consider that the use of formats to create documentation using
> translations in the form of translation database (.po files) will,
> despite the many advantages, also some disadvantages for translators.
>
> While the use of such forms of translations for the UI is quite
> comfortable, the use of that form for translating a continuous text
> (which is result of the train of thoughts) can be very uncomfortable
> for translators.

How is this different than translating normally (odf) and what is the
alternative?

___
Mailing list: https://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] parallel builds?

[Wayne Stambaugh]

Using rm -rf * in the build folder doesn't wipe out the files generated
by make_lexer().  They are created in the source tree as well not the
build folder.

On 10/22/2014 12:38 PM, Bernhard Stegmaier wrote:
> Hmm… I often did clean builds, i.e., I completely wipe out my build directory 
> via “rm -rf *” and do a new cmake configure run afterwards. That doesn’t 
> touch and rebuild boost living in the original source folder, yes.
> But, the lexer stuff should be deleted when wiping out the build folder and 
> they are not created in the source folder (otherwise bzr would show them)?
> 
> 
> Regards,
> Bernhard
> 
> 
> On 22.10.2014, at 17:04, Wayne Stambaugh  wrote:
> 
>> The reason you don't see either of these problems after the first build
>> is that boost and the source files created by the make_lexer() cmake
>> macro are already created so all of the dependencies are satisfied and
>> the build completes without issues.  You would only see the errors on a
>> new source build and possibly after running `make clean`.  Although I'm
>> not sure all of these files get remove on `make clean`.  It's hard to
>> believe that we have been bit by the missing files generated by
>> make_lexer() before now because none of the generated files are marked
>> as dependencies when building their respective targets.  I should have a
>> fix later today but I have some testing to do.
>>
>> On 10/22/2014 1:59 AM, Bernhard Stegmaier wrote:
>>> Hi,
>>>
>>> I didn’t use any other version of boost… always use the custom version that 
>>> still comes with KiCad.
>>> I also did a lot of builds recently, mostly with -j4 and never had problems 
>>> with that…
>>>
>>>
>>> Regards,
>>> Bernhard
>>>
>>> On 21.10.2014, at 21:41, Wayne Stambaugh  wrote:
>>>
 Adam,

 Try applying the attached patch.  It looks like on osx builds, boost is
 not being made a dependency so the boost build is not complete before
 the common library is getting built on parallel builds.  I think
 Bernhard was using a patched version of boost 1.56 which he has
 installed on his system so he would not have seen this problem since he
 wasn't using our custom 1.54 version of boost.  If this doesn't fix it,
 maybe Bernhard can take a look at it.

 Wayne

 On 10/21/2014 3:07 PM, Adam Wolf wrote:
> I don't get these errors when building with -j1 *after* a clean.
>
> Adam Wolf
>
> On Tue, Oct 21, 2014 at 1:56 PM, Bob Gustafson  > wrote:
>
>   Do you get that error when building with -j1 ?
>
>
>   On 10/21/2014 01:14 PM, Adam Wolf wrote:
>>   Hi folks,
>>
>>   I'm doing a *lot* of builds prepping these nightly builds, and
>>   especially on OS X, I'm seeing a lot of issues with parallel
>>   builds, where something like this happens:
>>
>>   In file included from 
>> /Users/jenkins/remoteroot/workspace/KiCadMacBuild/kicad/common/draw_panel_gal.cpp:33:
>>   
>> /Users/jenkins/remoteroot/workspace/KiCadMacBuild/kicad/include/view/view.h:30:10:
>>  fatal error: 'boost/unordered/unordered_map.hpp' file not found
>>   #include 
>>
>>   I have a little logic in there where I first try to build with
>>   -j4, and if it fails, i rerun make with -j1, but that doesn't seem
>>   to help.
>>
>>   Any thoughts, folks?
>>
>>   Adam Wolf
>>   Cofounder and Engineer
>>   W&L, LLC
>>
>>
>
>
>   ___
>   Mailing list: https://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
> 
> 



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

Re: [Kicad-developers] Incremental build speeds.

[Lorenzo Marcantonio]

On Wed, Oct 22, 2014 at 08:16:07AM -0700, Henner Zeller wrote:
> There are a lot of dependencies (=timestamps) to be checked, so having
> a solid state disk can probably speed up things dramatically.

Also, with enough RAM (even 4GB should be quite enough) the stat
operation would be done from the cache (it only needs to read the inode
itself, not the file).

> Also, for incremental re-compile after a make clean, you might want to
> look into ccache, that allows to locally cache compiler outputs (not
> sure if that is available on Windows proper, but an internet search
> suggests as such). ccache speeds up a (make clean ; make) to abot 3:20
> minutes. It looks like there is a lot of time wasted in partially
> re-building and re-packing the boos library, but I think that is a
> separate discussion (apparently it makes sense on some systems)

The boost thing is a one-time nuisance and we are talking about
incremental builds... so even ccache wouldn't be useful... unless
dependencies are wrong:P

> Compiling things in parallel is always a good idea, and as others
> pointed out, the -j option is good for that. In my case, I just set
> the environment variable
> MAKEFLAGS to '-j6' to make sure I never forget that.
> 
> (FWIW, just typing 'make' on an already build KiCAD (I think this is
> what you are doing) takes about 3.6 seconds on my ~3 year old Linux
> machine (4 core i5 2500k, probably similar to yours) - I do have a
> solid state disk, but can't compare what difference that makes)

OK, since we are benchmarking, here are my results (on my
sucky-but-nearly-indestructible panasonic CF-30, 2 cores, 5400 RPM HDD,
3GB RAM)

- Cold cache:
  make -j6  15,31s user 2,27s system 126% cpu 13,902 total
- Hot cache:
  make -j6  15,62s user 2,05s system 168% cpu 10,517 total
- Hot cache, not parallel:
  make  13,75s user 1,88s system 98% cpu 15,886 total

So, it seems that there is indeed a *lot* of filesystem overhead
involved (running ext4 BTW)...

Solution of the mystery: cmake adds as dependency *each single* wx
include file and each boost file used. That's something over 100K files,
for building pcbnew alone :P

After epurating the depend.{internal,make} files; the result is:

make  1,13s user 0,33s system 92% cpu 1,579 total

Quite a big improvement only removing excess dependencies, it seems:P

Conclusion: the issue is the cmake dependency extractor; while arguably
the boost_root/ files could be taken as part of the project, files from
/usr/include/wx-3.0 should be definitely 'system' include files (gcc has
some rules about -M and -MM behaviour, I don't know what kind of
extractor cmake uses)

That said... do you really care when compiling just *one* c++ source
usually takes more than all the dependency checking for the whole
project?

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

Re: [Kicad-developers] parallel builds?

[Adam Wolf]

I was going to say the same.  I see this issue because I run the following
before my builds in my source folder:

bzr clean-tree --verbose --force --ignored --unknown --detritus

Adam Wolf
Cofounder and Engineer
W&L

On Wed, Oct 22, 2014 at 12:04 PM, Wayne Stambaugh 
wrote:

> Using rm -rf * in the build folder doesn't wipe out the files generated
> by make_lexer().  They are created in the source tree as well not the
> build folder.
>
> On 10/22/2014 12:38 PM, Bernhard Stegmaier wrote:
> > Hmm… I often did clean builds, i.e., I completely wipe out my build
> directory via “rm -rf *” and do a new cmake configure run afterwards. That
> doesn’t touch and rebuild boost living in the original source folder, yes.
> > But, the lexer stuff should be deleted when wiping out the build folder
> and they are not created in the source folder (otherwise bzr would show
> them)?
> >
> >
> > Regards,
> > Bernhard
> >
> >
> > On 22.10.2014, at 17:04, Wayne Stambaugh  wrote:
> >
> >> The reason you don't see either of these problems after the first build
> >> is that boost and the source files created by the make_lexer() cmake
> >> macro are already created so all of the dependencies are satisfied and
> >> the build completes without issues.  You would only see the errors on a
> >> new source build and possibly after running `make clean`.  Although I'm
> >> not sure all of these files get remove on `make clean`.  It's hard to
> >> believe that we have been bit by the missing files generated by
> >> make_lexer() before now because none of the generated files are marked
> >> as dependencies when building their respective targets.  I should have a
> >> fix later today but I have some testing to do.
> >>
> >> On 10/22/2014 1:59 AM, Bernhard Stegmaier wrote:
> >>> Hi,
> >>>
> >>> I didn’t use any other version of boost… always use the custom version
> that still comes with KiCad.
> >>> I also did a lot of builds recently, mostly with -j4 and never had
> problems with that…
> >>>
> >>>
> >>> Regards,
> >>> Bernhard
> >>>
> >>> On 21.10.2014, at 21:41, Wayne Stambaugh 
> wrote:
> >>>
>  Adam,
> 
>  Try applying the attached patch.  It looks like on osx builds, boost
> is
>  not being made a dependency so the boost build is not complete before
>  the common library is getting built on parallel builds.  I think
>  Bernhard was using a patched version of boost 1.56 which he has
>  installed on his system so he would not have seen this problem since
> he
>  wasn't using our custom 1.54 version of boost.  If this doesn't fix
> it,
>  maybe Bernhard can take a look at it.
> 
>  Wayne
> 
>  On 10/21/2014 3:07 PM, Adam Wolf wrote:
> > I don't get these errors when building with -j1 *after* a clean.
> >
> > Adam Wolf
> >
> > On Tue, Oct 21, 2014 at 1:56 PM, Bob Gustafson  > > wrote:
> >
> >   Do you get that error when building with -j1 ?
> >
> >
> >   On 10/21/2014 01:14 PM, Adam Wolf wrote:
> >>   Hi folks,
> >>
> >>   I'm doing a *lot* of builds prepping these nightly builds, and
> >>   especially on OS X, I'm seeing a lot of issues with parallel
> >>   builds, where something like this happens:
> >>
> >>   In file included from
> /Users/jenkins/remoteroot/workspace/KiCadMacBuild/kicad/common/draw_panel_gal.cpp:33:
> >>
>  
> /Users/jenkins/remoteroot/workspace/KiCadMacBuild/kicad/include/view/view.h:30:10:
> fatal error: 'boost/unordered/unordered_map.hpp' file not found
> >>   #include 
> >>
> >>   I have a little logic in there where I first try to build with
> >>   -j4, and if it fails, i rerun make with -j1, but that doesn't seem
> >>   to help.
> >>
> >>   Any thoughts, folks?
> >>
> >>   Adam Wolf
> >>   Cofounder and Engineer
> >>   W&L, LLC
> >>
> >>
> >
> >
> >   ___
> >   Mailing list: https://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] proposal of adjusted netlist dialog

[Mark Roszko]

Actually I planned to do this:

Rename the netlist dialog to "Netlist Options"
Add a "Generate Netlist" menu option which does the immediate
netlisting with saved settings unless its the first time and theres no
saved settings.

The plan was also to add a menu option for Annotation, a "Silent
Forward Annotation" which annotates with saved settings and only does
new items. Akin to what Altium lets you do.

___
Mailing list: https://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] wxScrolledWindow on OS X

[Garth Corral]

Hi all,

I have a set of changes that I've been maintaining locally for my kicad builds 
that add support for trackpad gestures for panning and zooming on OSX, and 
generally improving the usabilitiy of a trackpad or mousewheel with kicad on 
this platform.

In trying to clean these up to be less platform specific, I ran into an issue 
with wxWidgets on (at least) OS X where a wxScrolledWindow processes scrollwin 
events no matter what, even if the event is already processed by client code.  
This can cause panning to happen in both directions simultaneously when using 
the mousewheel on OS X.   I beat my head against this for a bit before I 
realized it was deep in a wxWidgets handler and not kicad.  Fortunately there’s 
a simple fix for this sitting on wxWidgets trunk that I applied and it does 
resolve the issue.  This affects the current product series on OS X.  Does this 
not impact Linux and Windows?

Since we’re applying patches for OS X anyway, seems like this fix should be 
included.


Garth




smime.p7s
Description: S/MIME cryptographic signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Kicad-winbuilder fails.

[Tim Hutt]

Hi, I have previously used kicad-winbuilder successfully, but I just tried
it again (in a fresh directory) and get the error below. I tried it in a
much shorter path too and it still fails (and it worked with that path
before so I'm pretty sure it's not the path).

Anyone have any ideas?

Cheers,

Tim



C:\Users\Tim\Local\kicad-winbuilder-3.4>make
-- KiCad-Winbuilder V3.4
CMake Warning at KiCadWinbuilder.cmake:182 (message):
  Your install path maybe too long to be able to successfully build KiCad.
  Try re-installing to a root directory if the build fails!


-- Build type: Release
-- Checking for environment problems
-- Checking for installed Bazaar
-- Checking for wxPython
-- Downloading wxPython
-- Decompressing wxPython
-- Downloading Latest Library Archive...
-- Checking out KiCad Documentation source (BZR head)
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".
bzr: ERROR: No such file: '
http://bazaar.launchpad.net/~kicad-developers/kicad/d
oc/.bzr/repository/pack-names'
ERRORChecking out the Documentation source!
-- Checking for BZIP2
-- Downloading BZIP2 Source
-- Building BZIP2 Library
-- Checking for GLEW
-- Downloading
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".
-- Building GLEW/s - Build phase:Apply phase:adding file 10/17
-- GLEW build finished
-- Checking for Cairo
-- Downloading cairo-dev_1.10.2-2_win32.zip
-- Decompressing Cairo
-- Checking out KiCad source code (BZR head)
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".
-- Cleaning PCBNEW Python files to ensure good build...e 50/604
-- Using KiCad Options:
-- -DKICAD_SCRIPTING=ON
-- -DKICAD_SCRIPTING_MODULES=ON
-- -DKICAD_SCRIPTING_WXPYTHON=ON
-- -DPYTHON_ROOT_DIR=C:/Users/Tim/Local/kicad-winbuilder-3.4/env/python
-- -DBUILD_GITHUB_PLUGIN=ON
--
 Configuring KiCad ( Release )
-- Building Release version of KiCad revision: 5215

-- Installing KiCad locally. Use RunKiCad.bat to run this version
CMake Error at KiCadWinbuilder.cmake:1040 (file):
  file COPY cannot find
  "C:/Users/Tim/Local/kicad-winbuilder-3.4/kicad/bin/pylib/_pcbnew.pyd".
___
Mailing list: https://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 documentation format

[Marco Ciampa]

On Wed, Oct 22, 2014 at 05:57:22PM +0200, Kerusey Karyu wrote:
> To: kicad-developers
> From: Marco Ciampa
> Date: Tue, 21 Oct 2014 23:58:17 +0200
> 
> > If you have any doubt or problem about anything please
> > express yourself.
> >
> 
> I consider that the use of formats to create documentation using
> translations in the form of translation database (.po files) will,
> despite the many advantages, also some disadvantages for translators.
> 
> While the use of such forms of translations for the UI is quite
> comfortable, the use of that form for translating a continuous text
> (which is result of the train of thoughts) can be very uncomfortable
> for translators.
> 
> Why? The main difficulty will be limited visibility of the logic of the
> text and its layout (indentation, spacing). There will be situations
> where we will need to translate a fragment out of context. I as a
> translator prefer also see more of the text to be able to, among
> others, eliminate repetition of words and the use of synonyms. My
> native language is very flexible in this topic.
> 
> Taking also the specificity of translated texts, unfortunately, it is
> in so many cases impossible to translate word for word. Sometimes you
> have to break down complex sentence into two (or even three) sentences
> that the reader can easily assimilate them.
> By translating KiCad user manual I had to just do that many times.
> Sometimes adding something from each other to avoid ambiguity.
> 
> So. That’s my (maybe wrong) doubts.

Good point but I think that it is more a theoretical problem than a real
one since such tools such as po4a, xml2po, etc. do not break paragraphs
and in fact aggregate contiguous paragraphs. See for example the GIMP
manual that is actually translated in these languages: Catalá, Dansk,
Deutsch, English, Español, Ελληνικά (Greek) Français, Italiano,
日本語(Japanese), 한국어(Korean) Nederlands, Norwegian, Português,
Pусский, Slovenščina Svenska, 中文 (Chinese). A manual of about 800 pages
long. That kind of problem, for what I may know, never arised.

I hope I have unraveled some doubt.

-- 


Marco Ciampa

I know a joke about UDP, but you might not get it.

++
| Linux User  #78271 |
| FSFE fellow   #364 |
++


___
Mailing list: https://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] Incremental build speeds.

[Martijn Kuipers]

Tim,
On 22 Oct 2014, at 17:45, Tim Hutt  wrote:

> Oh yeah I forgot to mention I have an SSD, and -j4 did not make a huge 
> difference (can't remember exact time).
> 
> I like the DLL solution though! I'm planning to (maybe) do a bit of work on 
> the 3d viewer as it is not much code and quite self-contained. Seems to be a 
> static library at the moment so I will maybe have a go at changing it to a 
> dynamic one.
> 
> I might also try porting to QBS (Qt's new build system) which is much faster 
> than make in my experience.

You can try, but my guess is that you should not expect a warm welcome for 
patches doing so. CMake may be slower, but it has shown to be able to deal with 
a whole lot of weird things on all platforms. The main devs and Dick (I am not) 
have spent so much time on this, that I doubt they´ll be very receptive. Also, 
kicad used Wx, why use a QT build-system?

I am not trying to start a flamefest, but perhaps it convinces you to spend 
that time on other KiCad improvements.

Kind regards,
Martijn

> 
> Cheers,
> 
> Tim
> 
> On 22 October 2014 14:40, Tomasz Wlostowski  wrote:
> On 22.10.2014 15:01, Tim Hutt wrote:
> Hi,
> 
> 
> However, if I perform a null-rebuild (i.e. I don't change anything and
> just run `make` again), it takes about 70 seconds to run.
> 
> Hi Tim,
> 
> I found it very annoying while developing the P&S, where I needed to very 
> frequently rebuild and re-link a small part of pcbnew. My solution was to:
> - exclude the P&S sources from CMakeLists.txt
> - build the P&S using a standard makefile (using same compiler options as 
> CMake)
> - link it as a DLL with _pcbnew.kiface
> 
> By doing this, I only had to rebuild the P&S DLL (taking few seconds) instead 
> of waiting ~2 minutes for the CMake to solve dependencies and GCC linker to 
> produce new .kiface image.
> 
> It's just a dumb and ugly hack, but may help in some cases.
> 
> Cheers,
> Tom
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

[Kicad-developers] Fwd: Re: new documentation format

[Brian Sidebotham]

-- Forwarded message --
From: "Brian Sidebotham" 
Date: 22 Oct 2014 22:50
Subject: Re: [Kicad-developers] new documentation format
To: "Marco Ciampa" 
Cc:


On 22 Oct 2014 22:02, "Marco Ciampa"  wrote:
>
> On Wed, Oct 22, 2014 at 05:57:22PM +0200, Kerusey Karyu wrote:
> > To: kicad-developers
> > From: Marco Ciampa
> > Date: Tue, 21 Oct 2014 23:58:17 +0200
> >
> > > If you have any doubt or problem about anything please
> > > express yourself.
> > >
> >
> > I consider that the use of formats to create documentation using
> > translations in the form of translation database (.po files) will,
> > despite the many advantages, also some disadvantages for translators.
> >
> > While the use of such forms of translations for the UI is quite
> > comfortable, the use of that form for translating a continuous text
> > (which is result of the train of thoughts) can be very uncomfortable
> > for translators.
> >
> > Why? The main difficulty will be limited visibility of the logic of the
> > text and its layout (indentation, spacing). There will be situations
> > where we will need to translate a fragment out of context. I as a
> > translator prefer also see more of the text to be able to, among
> > others, eliminate repetition of words and the use of synonyms. My
> > native language is very flexible in this topic.
> >
> > Taking also the specificity of translated texts, unfortunately, it is
> > in so many cases impossible to translate word for word. Sometimes you
> > have to break down complex sentence into two (or even three) sentences
> > that the reader can easily assimilate them.
> > By translating KiCad user manual I had to just do that many times.
> > Sometimes adding something from each other to avoid ambiguity.
> >
> > So. That’s my (maybe wrong) doubts.
>
> Good point but I think that it is more a theoretical problem than a real
> one since such tools such as po4a, xml2po, etc. do not break paragraphs
> and in fact aggregate contiguous paragraphs. See for example the GIMP

Excellent, that was the answer I was hoping for! So long as that's true,
which I'm sure it should be, we should be on to a winner with the workflow.

Best Regards,

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

Re: [Kicad-developers] Kicad-winbuilder fails.

[Brian Sidebotham]

Kicad-Winbuilder was broke a few commits ago by removing some custom python
finding cmake module. I've not had the time to replace it with another
working version. I was hoping to replace it before it was removed.

Hopefully it should be fixed soon!

Best Regards,

Brian.
On 22 Oct 2014 21:30, "Tim Hutt"  wrote:

> Hi, I have previously used kicad-winbuilder successfully, but I just tried
> it again (in a fresh directory) and get the error below. I tried it in a
> much shorter path too and it still fails (and it worked with that path
> before so I'm pretty sure it's not the path).
>
> Anyone have any ideas?
>
> Cheers,
>
> Tim
>
> 
>
> C:\Users\Tim\Local\kicad-winbuilder-3.4>make
> -- KiCad-Winbuilder V3.4
> CMake Warning at KiCadWinbuilder.cmake:182 (message):
>   Your install path maybe too long to be able to successfully build KiCad.
>   Try re-installing to a root directory if the build fails!
>
>
> -- Build type: Release
> -- Checking for environment problems
> -- Checking for installed Bazaar
> -- Checking for wxPython
> -- Downloading wxPython
> -- Decompressing wxPython
> -- Downloading Latest Library Archive...
> -- Checking out KiCad Documentation source (BZR head)
> 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".
> bzr: ERROR: No such file: '
> http://bazaar.launchpad.net/~kicad-developers/kicad/d
> oc/.bzr/repository/pack-names'
> ERRORChecking out the Documentation source!
> -- Checking for BZIP2
> -- Downloading BZIP2 Source
> -- Building BZIP2 Library
> -- Checking for GLEW
> -- Downloading
> 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".
> -- Building GLEW/s - Build phase:Apply phase:adding file 10/17
> -- GLEW build finished
> -- Checking for Cairo
> -- Downloading cairo-dev_1.10.2-2_win32.zip
> -- Decompressing Cairo
> -- Checking out KiCad source code (BZR head)
> 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".
> -- Cleaning PCBNEW Python files to ensure good build...e 50/604
> -- Using KiCad Options:
> -- -DKICAD_SCRIPTING=ON
> -- -DKICAD_SCRIPTING_MODULES=ON
> -- -DKICAD_SCRIPTING_WXPYTHON=ON
> -- -DPYTHON_ROOT_DIR=C:/Users/Tim/Local/kicad-winbuilder-3.4/env/python
> -- -DBUILD_GITHUB_PLUGIN=ON
> --
>  Configuring KiCad ( Release )
> -- Building Release version of KiCad revision: 5215
>
> -- Installing KiCad locally. Use RunKiCad.bat to run this version
> CMake Error at KiCadWinbuilder.cmake:1040 (file):
>   file COPY cannot find
>   "C:/Users/Tim/Local/kicad-winbuilder-3.4/kicad/bin/pylib/_pcbnew.pyd".
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Fwd: Re: new documentation format

[Marco Ciampa]

On Wed, Oct 22, 2014 at 10:50:38PM +0100, Brian Sidebotham wrote:
> -- Forwarded message --
> From: "Brian Sidebotham" 
> Date: 22 Oct 2014 22:50
> Subject: Re: [Kicad-developers] new documentation format
> To: "Marco Ciampa" 
> Cc:
> 
> On 22 Oct 2014 22:02, "Marco Ciampa"  wrote:
> >
> > On Wed, Oct 22, 2014 at 05:57:22PM +0200, Kerusey Karyu wrote:
> > > To: kicad-developers
> > > From: Marco Ciampa
> > > Date: Tue, 21 Oct 2014 23:58:17 +0200
> > >
> > > > If you have any doubt or problem about anything please
> > > > express yourself.
> > > >
> > >
> > > I consider that the use of formats to create documentation using
> > > translations in the form of translation database (.po files) will,
> > > despite the many advantages, also some disadvantages for translators.
> > >
> > > While the use of such forms of translations for the UI is quite
> > > comfortable, the use of that form for translating a continuous text
> > > (which is result of the train of thoughts) can be very uncomfortable
> > > for translators.
> > >
> > > Why? The main difficulty will be limited visibility of the logic of the
> > > text and its layout (indentation, spacing). There will be situations
> > > where we will need to translate a fragment out of context. I as a
> > > translator prefer also see more of the text to be able to, among
> > > others, eliminate repetition of words and the use of synonyms. My
> > > native language is very flexible in this topic.
> > >
> > > Taking also the specificity of translated texts, unfortunately, it is
> > > in so many cases impossible to translate word for word. Sometimes you
> > > have to break down complex sentence into two (or even three) sentences
> > > that the reader can easily assimilate them.
> > > By translating KiCad user manual I had to just do that many times.
> > > Sometimes adding something from each other to avoid ambiguity.
> > >
> > > So. That’s my (maybe wrong) doubts.
> >
> > Good point but I think that it is more a theoretical problem than a real
> > one since such tools such as po4a, xml2po, etc. do not break paragraphs
> > and in fact aggregate contiguous paragraphs. See for example the GIMP
> 
> Excellent, that was the answer I was hoping for! So long as that's true,
> which I'm sure it should be, we should be on to a winner with the workflow.

Sorry I forgot to show directly the .po files. See by yourself:

https://github.com/ciampix/kicad-doc/blob/master/src/asciidoc/cvpcb/po/cvpcb.pot

You will see that there are many big paragraphs...

-- 


Marco Ciampa

I know a joke about UDP, but you might not get it.

++
| Linux User  #78271 |
| FSFE fellow   #364 |
++


___
Mailing list: https://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] proposal of adjusted netlist dialog

[Brian Sidebotham]

The re-designed layout us much more appealing. It looks much better than
the previous layout.

On 22 Oct 2014 19:14, "Mark Roszko"  wrote:
>
> Actually I planned to do this:
>
> Rename the netlist dialog to "Netlist Options"
> Add a "Generate Netlist" menu option which does the immediate
> netlisting with saved settings unless its the first time and theres no
> saved settings.

This type of behaviour would get my vote, although I also think it's
perhaps better to swap to a netlist button that is a fixed filename and
netlist type (pcbnew) and have this dialog under the heading "export
enlist".

That's because there are other areas like this that need cleaning up in the
same way, e.g eeschema options dialog which asks you for the project file
to save the project specific setting to, whilst at the same time updating
the eeschema (non-project specific) options too! It's really quite awkward
to be asked for these standard named files in a normal workflow.

> The plan was also to add a menu option for Annotation, a "Silent
> Forward Annotation" which annotates with saved settings and only does
> new items. Akin to what Altium lets you do.

This also sounds good. Optimising the "normal" workflow can be a great
bonus, but it may take a hit of hammering out as to the actual workflow and
operation of these options.

Thanks for your work Mark!

Best Regards,

Brian.

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

Re: [Kicad-developers] [RFC] proposal of adjusted netlist dialog

[Brian Sidebotham]

On 22 Oct 2014 23:03, "Brian Sidebotham"  wrote:
>
> The re-designed layout us much more appealing. It looks much better than
the previous layout.
>
> On 22 Oct 2014 19:14, "Mark Roszko"  wrote:
> >
> > Actually I planned to do this:
> >
> > Rename the netlist dialog to "Netlist Options"
> > Add a "Generate Netlist" menu option which does the immediate
> > netlisting with saved settings unless its the first time and theres no
> > saved settings.
>
> This type of behaviour would get my vote, although I also think it's
perhaps better to swap to a netlist button that is a fixed filename and
netlist type (pcbnew) and have this dialog under the heading "export
enlist".
>
> That's because there are other areas like this that need cleaning up in
the same way, e.g eeschema options dialog which asks you for the project
file to save the project specific setting to, whilst at the same time
updating the eeschema (non-project specific) options too! It's really quite
awkward to be asked for these standard named files in a normal workflow.
>
> > The plan was also to add a menu option for Annotation, a "Silent
> > Forward Annotation" which annotates with saved settings and only does
> > new items. Akin to what Altium lets you do.
>
> This also sounds good. Optimising the "normal" workflow can be a great
bonus, but it may take a hit of hammering out as to the actual workflow and
operation of these options.
>
> Thanks for your work Mark!
>
> Best Regards,
>
> Brian.
>

Sorry for all the spelling mistakes, I replied via my phone!

Best Regards,

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

Re: [Kicad-developers] Fwd: Re: new documentation format

[Brian Sidebotham]

On 22 Oct 2014 23:00, "Marco Ciampa"  wrote:
>
> Sorry I forgot to show directly the .po files. See by yourself:
>
>
https://github.com/ciampix/kicad-doc/blob/master/src/asciidoc/cvpcb/po/cvpcb.pot
>
> You will see that there are many big paragraphs

Yeah, that po file looks good. Hopefully the document translators will
agree!

Best Regards,

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

Re: [Kicad-developers] parallel builds?

[Wayne Stambaugh]

Adam,

I just committed the fix with my original patch along with a fix for the
missing files generated by make_lexer() in r5216.  Hopefully, this
solves the problem.

Thanks,

Wayne

On 10/21/2014 10:01 PM, Adam Wolf wrote:
> Wayne, this patch really fixes things on the OS X side.
> 
> Thanks.
> 
> Adam Wolf
> Cofounder and Engineer
> W&L
> 
> On Tue, Oct 21, 2014 at 2:45 PM, Adam Wolf
> mailto:adamw...@feelslikeburning.com>>
> wrote:
> 
> Thanks Wayne.  I'll try it and let you know.
> 
> Adam Wolf
> 
> On Tue, Oct 21, 2014 at 2:41 PM, Wayne Stambaugh
> mailto:stambau...@verizon.net>> wrote:
> 
> Adam,
> 
> Try applying the attached patch.  It looks like on osx builds,
> boost is
> not being made a dependency so the boost build is not complete
> before
> the common library is getting built on parallel builds.  I think
> Bernhard was using a patched version of boost 1.56 which he has
> installed on his system so he would not have seen this problem
> since he
> wasn't using our custom 1.54 version of boost.  If this doesn't
> fix it,
> maybe Bernhard can take a look at it.
> 
> Wayne
> 
> On 10/21/2014 3:07 PM, Adam Wolf wrote:
> > I don't get these errors when building with -j1 *after* a clean.
> >
> > Adam Wolf
> >
> > On Tue, Oct 21, 2014 at 1:56 PM, Bob Gustafson  
> > >> wrote:
> >
> > Do you get that error when building with -j1 ?
> >
> >
> > On 10/21/2014 01:14 PM, Adam Wolf wrote:
> >> Hi folks,
> >>
> >> I'm doing a *lot* of builds prepping these nightly builds, and
> >> especially on OS X, I'm seeing a lot of issues with parallel
> >> builds, where something like this happens:
> >>
> >> In file included from 
> /Users/jenkins/remoteroot/workspace/KiCadMacBuild/kicad/common/draw_panel_gal.cpp:33:
> >> 
> /Users/jenkins/remoteroot/workspace/KiCadMacBuild/kicad/include/view/view.h:30:10:
>  fatal error: 'boost/unordered/unordered_map.hpp' file not found
> >> #include 
> >>
> >> I have a little logic in there where I first try to build with
> >> -j4, and if it fails, i rerun make with -j1, but that doesn't 
> seem
> >> to help.
> >>
> >> Any thoughts, folks?
> >>
> >> Adam Wolf
> >> Cofounder and Engineer
> >> W&L, LLC
> >>
> >>
> >
> >
> > ___
> > Mailing list: https://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] parallel builds?

[Adam Wolf]

Hi Wayne,

Excellent work!  (I can now make CLion build KiCad.  Not sure if it's
useful at all yet, but it builds!)

Adam Wolf

On Wed, Oct 22, 2014 at 6:28 PM, Wayne Stambaugh 
wrote:

> Adam,
>
> I just committed the fix with my original patch along with a fix for the
> missing files generated by make_lexer() in r5216.  Hopefully, this
> solves the problem.
>
> Thanks,
>
> Wayne
>
> On 10/21/2014 10:01 PM, Adam Wolf wrote:
> > Wayne, this patch really fixes things on the OS X side.
> >
> > Thanks.
> >
> > Adam Wolf
> > Cofounder and Engineer
> > W&L
> >
> > On Tue, Oct 21, 2014 at 2:45 PM, Adam Wolf
> > mailto:adamw...@feelslikeburning.com>>
> > wrote:
> >
> > Thanks Wayne.  I'll try it and let you know.
> >
> > Adam Wolf
> >
> > On Tue, Oct 21, 2014 at 2:41 PM, Wayne Stambaugh
> > mailto:stambau...@verizon.net>> wrote:
> >
> > Adam,
> >
> > Try applying the attached patch.  It looks like on osx builds,
> > boost is
> > not being made a dependency so the boost build is not complete
> > before
> > the common library is getting built on parallel builds.  I think
> > Bernhard was using a patched version of boost 1.56 which he has
> > installed on his system so he would not have seen this problem
> > since he
> > wasn't using our custom 1.54 version of boost.  If this doesn't
> > fix it,
> > maybe Bernhard can take a look at it.
> >
> > Wayne
> >
> > On 10/21/2014 3:07 PM, Adam Wolf wrote:
> > > I don't get these errors when building with -j1 *after* a
> clean.
> > >
> > > Adam Wolf
> > >
> > > On Tue, Oct 21, 2014 at 1:56 PM, Bob Gustafson  
> > > >> wrote:
> > >
> > > Do you get that error when building with -j1 ?
> > >
> > >
> > > On 10/21/2014 01:14 PM, Adam Wolf wrote:
> > >> Hi folks,
> > >>
> > >> I'm doing a *lot* of builds prepping these nightly
> builds, and
> > >> especially on OS X, I'm seeing a lot of issues with
> parallel
> > >> builds, where something like this happens:
> > >>
> > >> In file included from
> /Users/jenkins/remoteroot/workspace/KiCadMacBuild/kicad/common/draw_panel_gal.cpp:33:
> > >>
>  
> /Users/jenkins/remoteroot/workspace/KiCadMacBuild/kicad/include/view/view.h:30:10:
> fatal error: 'boost/unordered/unordered_map.hpp' file not found
> > >> #include 
> > >>
> > >> I have a little logic in there where I first try to build
> with
> > >> -j4, and if it fails, i rerun make with -j1, but that
> doesn't seem
> > >> to help.
> > >>
> > >> Any thoughts, folks?
> > >>
> > >> Adam Wolf
> > >> Cofounder and Engineer
> > >> W&L, LLC
> > >>
> > >>
> > >
> > >
> > > ___
> > > Mailing list: https://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
>
___
Mailing list: https://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] Incremental build speeds.

[Lorenzo Marcantonio]

On Wed, Oct 22, 2014 at 10:15:46PM +0100, Martijn Kuipers wrote:
> You can try, but my guess is that you should not expect a warm welcome for 
> patches doing so. CMake may be slower, but it has shown to be able to deal 
> with a whole lot of weird things on all platforms. The main devs and Dick (I 
> am not) have spent so much time on this, that I doubt they´ll be very 
> receptive. Also, kicad used Wx, why use a QT build-system?

From the test I made just 'persuade' cmake to omit unneeded dependencies
(like wx includes and the 'internal' boost, which are very unlikely to
change) and you should have solved the issue. There are also make tricks
(like master touch files) but they 1) probably are not applicable to
cmake and 2) don't gain much as the bulk of dependencies removed.

However the main time hogger is the compiler itself (as it should be :D); you
could try to lower the -O flags at the expense of less performance and,
more importantly, less compile warnings.

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

Re: [Kicad-developers] Incremental build speeds.

[Mark Roszko]

>I might also try porting to QBS (Qt's new build system) which is much faster 
>than make in my experience.

I hope you to plan to provide Debian, Windows, OSX, CentOS, etc binary
packages and maintain them!

The last thing any project needs is to provide more binaries
themselves when they don't need it.

"Binary releases of Qbs are currently only available for Windows"

___
Mailing list: https://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] Demos: Rename "sonde xilinx" to "sonde_xilinx"

[Lorenzo Marcantonio]

On Thu, Oct 23, 2014 at 09:37:31AM +0300, Константин Барановский wrote:
> When I create deb package with checkinstall, I get some error messages

I'd say that's a checkinstall/tar thing (probably an unquoted shell
parameter...), not an issue in kicad:P

Unless of course one of the Debian policies is 'no space in filenames'
:D

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

Re: [Kicad-developers] [PATCH] Demos: Rename "sonde xilinx" to "sonde_xilinx"

[Константин Барановский]

Yes, I understand that problem is not in kicad, but still.

2014-10-23 9:42 GMT+03:00 Lorenzo Marcantonio :

> On Thu, Oct 23, 2014 at 09:37:31AM +0300, Константин Барановский wrote:
> > When I create deb package with checkinstall, I get some error messages
>
> I'd say that's a checkinstall/tar thing (probably an unquoted shell
> parameter...), not an issue in kicad:P
>
> Unless of course one of the Debian policies is 'no space in filenames'
> :D
>
> --
> 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] [PATCH] Demos: Rename "sonde xilinx" to "sonde_xilinx"

[jp charras]

Le 23/10/2014 08:37, Константин Барановский a écrit :
> When I create deb package with checkinstall, I get some error messages
> (something like "tar: xilinx: Function stat failed with error: No such
> file or directory"). Creating of the package are finishing successfully,
> but these messages troubling me (and maybe, someone else).
> I propose rename this demo to "sonde_xilinx", that resolve this problem.
> Attached patch turned so big, but I only done the following:
> - rename folder;
> - rename all files of the demo;
> - edit three files where was found phrase "sonde xilinx":
> sonde_xilinx.net:3 :(source
> "F:/kicad-launchpad/testing/demos/sonde xilinx/sonde xilinx.sch")
> sonde_xilinx.pro:27:LastNetListRead=sonde xilinx.net 
> sonde_xilinx.sch:6:LIBS:sonde xilinx-cache
> 
> Regards, Konstantin.

the space in name is a deliberate choice:

Many times, when a script or code which read/write file is not well
designed, files with spaces in names show an issue.

You can see the folder "sonde xilinx" like a test to verify that kicad
code and/or scripts (python scripts, plugin commands ...) works well.
(usually, when happens, filenames were not quoted)

This is therefore not a good idea to rename it: you'll remove the
interest of this demo.

Regards,

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