Re: [Kicad-developers] [PATCH] Add online documenation URL to the enu
Sure, I can do it now that I’m back and “operational” after jet lag recovery ;).
I need to point a virtual http server to the jenkins workspace, and set a
redirection.
.htaccess doesn’t apply here since I’m not using apache, but the equivalent in
cherokee may be rather simple.
I’ll ping back on this thread when it’s ready during this week.
Miguel Ángel Ajo
On Wednesday, 27 de May de 2015 at 10:20, Melroy van den Berg wrote:
Dear Miguel Angel Ajo Pelayo,
Would you like to create a new sub-domain:
http://docs.kicad-pcb.org
I understood that you're the only appropriate person for this.
This link should refer (without URL changes, eg .htaccess or DNS) to the
content of the latest build of Jenkins. At that moment the Getting Started
URL will be:
http://docs.kicad-pcb.org/Getting_Started_in_KiCad.html
Then my patch will get accepted.
Kind regards,
Melroy van den Berg
2015-05-18 20:52 GMT+02:00 Nick Østergaard oe.n...@gmail.com
(mailto:oe.n...@gmail.com):
2015-05-18 18:59 GMT+02:00 Melroy van den Berg webmaster1...@gmail.com
(mailto:webmaster1...@gmail.com):
Hi,
It's a good idea to setup an URL like: http://docs.kicad-pcb.org/.
I don't know who has webserver / DNS access besides ajo? .htacess is not
that hard.
You can either use the base_name directly. Or change other parts in the
code, so I can use for example:
event.GetId() == wxID_BLAH or event.GetMenuItem() == wxMenuItem_BLAH. Then
you can still use a switch without hashmap.
Well it's about how complicated you want the code, for opening the online
docs.
I simply want to avoid any switch case, by using the base_name directly as:
helpFile = wxString::Format( https://docs.kicad-pcb.org/%s;,
GetChars( base_name ));
Kind regards,
Melroy van den Berg
2015-05-18 18:40 GMT+02:00 Nick Østergaard oe.n...@gmail.com
(mailto:oe.n...@gmail.com):
2015-05-18 18:35 GMT+02:00 Melroy van den Berg webmaster1...@gmail.com
(mailto:webmaster1...@gmail.com):
Hi Nick and Blair,
@Nick
I choose for a separate wxString to explicitly make a difference
between
a
local file online URL. However, yes you can merge them together using
1
xwString.
If you want, you can change it to your own taste
@Blair
Thanks for your reply. The first remark I agree, but the current
documentation also lacks behind, so it already doesn't match the
current
installed KiCad version ;)
About the second remark, this you can easily solve in the code.
But for now, my patch only ensures that it opens the online
documentation
when no doc-package is installed or can be found.
In my minds it would not be that great to include the patch as is.
Firstly it uses the Jenkins URL directly, which is likely subject to
change when we get the cmake stuff included with the docs.
What I would like to see is that we get some more generic and nicer
url redirects setup, such as http://docs.kicad-pcb.org/pcbnew. Ajo
has expressed his support on IRC, but is busy at the moment.
By doing this we could get away of the hashmap stuff and just use the
base_name directly to construct the url. I would like other peoples
opinion on this approach.
Hopefully this patch will get delivered soon :)!
Thx.
Kind regards,
Melroy van den Berg
2015-05-18 7:31 GMT+02:00 Nick Østergaard oe.n...@gmail.com
(mailto:oe.n...@gmail.com):
2015-05-18 0:44 GMT+02:00 Melroy van den Berg
webmaster1...@gmail.com (mailto:webmaster1...@gmail.com):
Hi devs,
I created a patch which opens the online documentation page in the
web-browser, only when the local help file could not be found.
This way the user don't get the pop-up message: 'PDF could not be
found'.
Instead they can read the latest successfully build documentation
online
:).
Off-topic:
It would be nice if online documentation becomes the default.
This way the users always read the latest version of the
documentation.
See attachment for the patch.
Why do you do the:
if( !helpFile )
{
... helpURL = ...
}
else
{
GetAssociatedDocument( this, helpFile );
if(!helpURL.IsEmpty())
{
GetAssociatedDocument( this, helpURL );
}
Why not just
if( !helpFile )
{
...
helpFile = ...
}
GetAssociatedDocument( this, helpFile );
By that it will just set the helpFile if the helpfile was not found.
Thanks in advance!
Kind regards,
Melroy van den Berg
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
(mailto:kicad-developers@lists.launchpad.net)
Unsubscribe : https://launchpad.net/~kicad
[Kicad-developers] Confluence memory..
Nick, thanks for steadily reporting any issues.
Even in the latest version, it seems that confluence is eventually hitting an
OutOfMemory
situation, even for all the RAM java will let me give it…
So, I have set this into cron:
# restart confluence every saturday
* 0 * * 6 /sbin/service confluence restart
# check confluence every 5 minutes for Memory errors
*/5 * * * * /opt/atlassian/confluence-reviver.sh
And this is the confluence-reviver.sh:
#!/bin/sh
LOGFILE=/var/atlassian/application-data/confluence/logs/atlassian-confluence.log
LINES=2000
tail $LOGFILE --lines $LINES | grep java.lang.OutOfMemoryError
if [[ $? -ne 0 ]]; then
exit 0 # we are ok, no memory error
else
for i in {1..$LINES}
do
echo == BLANK == $LOGFILE
done
service confluence restart
echo Confluence was restarted due to OutOfMemoryError
exit 1
fi
I guess they have memory leaks..
Miguel Ángel Ajo
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Python scripting error in today's compile
That’s one of the risks of the plain C++ api translation, and why we’re (slowly) working on [1] look on [2] and [3] Can you try switching SEGVIA for VIA and see if that works? Please confirm, so I can go and update the example. Best, Miguel Ángel [1] https://github.com/KiCad/kicad-python/ [2] http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/4826 [3] http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/482 (http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/4826)7 Miguel Ángel Ajo On Monday, 30 de March de 2015 at 9:19, Nathan McCorkle wrote: I just compiled from github using all the PYTHON related flags from the python wiki page on compiling. When I run the example on this page (using the .kicad_pcb file in my project's directory): http://www.kicad-pcb.org/display/KICAD/BOARD I get this error output: http://paste.pound-python.org/show/UzjU6mujUSJnnY76vzfW/ Note that I'm using this from a clone that I compiled, then installed using: make install DESTDIR=~/Projects/github/kicad-source-mirror/build_install -- -Nathan ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Feature freeze.
Hi! :) I have kept thinking about the new python API, I still don’t consider it ready, and I believe it could make sense to have them separate from tree, with stable releases tracking the Kicad stable releases, and a development branch. This way, we can use the plain C++ python API in-tree to do CI over KiCad, and have a separate package for python the python API SDK, or have the building tools installing the python modules along. (If we also distribute via pip it could be something as simple as calling “pip install kicad-python”) Thoughts? For stable version tracking, do we have already a name, version numbering, or something equivalent for the soon-to-be stable release, and the next one? Best, Miguel Ángel Ajo On Monday, 30 de March de 2015 at 1:46, Wayne Stambaugh wrote: On 3/29/2015 5:55 PM, Nick Østergaard wrote: 2015-03-29 23:53 GMT+02:00 Wayne Stambaugh stambau...@gmail.com (mailto:stambau...@gmail.com): On 3/29/2015 5:50 PM, Nick Østergaard wrote: 2015-03-29 23:44 GMT+02:00 Wayne Stambaugh stambau...@gmail.com (mailto:stambau...@gmail.com): On 3/29/2015 5:38 PM, Nick Østergaard wrote: Thank you for the announcement. Hopefully we can then close a lot of bugs then, not that this is something that has not been done in the meantime. Thumbs up. I'll have some more info on that over the next few days so we can start focusing on the stable release. But it seems like the newest commit does not build on the build server. Please see: http://ci.kicad-pcb.org/job/kicad-full/319/console Do the environment require an update? Are you building this against wx 2.8? Your build is failing for undefined wxRichMessageDialog which is only available since wx 2.9.5. No, this is against 3.0.1 according to wx-config --version. I wonder if there is a custom build option when building wxWidgets under linux to enable this. I hope not. Otherwise, everyone's linux builds will be broken. I may be implementing our own custom rich message box sooner than I thought. I will try to build it on linux as soon as I can to see if I have the some problem. It builds fine on the fedora20 machine, with wx 3.0.2. This is using Ajo's wx stuff IIRC. I just finished building this on my Debian testing system and it build fine so it appears that it may be something wrong with you wx 3.0.1 build. 2015-03-29 23:23 GMT+02:00 Wayne Stambaugh stambau...@gmail.com (mailto:stambau...@gmail.com): Attention all developers. I have finally committed the environment variable configuration dialog (although I named it the Path Configuration because the term environment variable is apparently too scary) so we are now in feature freeze. This means if you want to add a new feature or change any functional behavior you must run it by the developers list first. This includes me as well. The only thing I'm aware that's already in the pipe line at the moment is the footprint wizard that Orson is working on so that can be committed without approval. Please test the path configuration editor to make sure it is robust for the stable release. I did not do anything too fancy in the wxGrid control used in the editor so the grid editing will be very basic. Also, I kept the default wxGrid tab key behavior which means you will have to use Ctrl+Tab to perform the default action which is the OK button. I also created a warning dialog using wxRichMessageDialog when an externally defined environment variable is modified. I'm not really thrilled with the appearance of this dialog so I will most like roll my own version that will look a bit like our exit dialog but feed back would be appreciated. This also means that KiCad will no longer build against wxWidgets 2.8 for anyone out there still clinging to that version. Now that we are in feature freeze it's time to take stock on what is going on in other areas such as documentation and nightly builds so I will be sending out additional topic specific messages over the next few days. Thanks, Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] thoughts on dependency on SISL library
I’m not sure it fits all use cases I could think of, for example, let’s think you’re a board assembler/manufacturer, and you setup a site that accepts KiCad designs, and processes the files automatically via scripting to send you a cost estimation, and other information. Having SINTEF as AGPL could require them to publish their website scripts?, or their processing scripts?, it would be nice by the way, since other assemblers could have the chance to start doing the same, but… it’s probably an entry barrier for this ti happen. opinions?, Miguel Ángel Ajo On Friday, 27 de March de 2015 at 10:13, Cirilo Bernardo wrote: Well spotted; so it's even less of an issue than I imagined it could be. I hope everyone agrees that the SISL library can become a dependency pending testing on MSWin (and Mac if someone can help me out). I imagine this won't happen for quite a few months yet since I need to work on many other issues including a proposal for managing the various 3D models and the inevitable refactor. I would need to do all that work before I would even start on the IGES exporter code itself; for the time being the IGES library will stand on its own fully capable of a proof-of-concept work but with no link whatsoever to KiCad until the 3D plugin or whatever we call it is done. - Cirilo On Fri, Mar 27, 2015 at 6:55 PM, Javier Serrano javier.serrano.par...@gmail.com (mailto:javier.serrano.par...@gmail.com) wrote: On Fri, Mar 27, 2015 at 12:20 AM, Cirilo Bernardo cirilo.berna...@gmail.com (mailto:cirilo.berna...@gmail.com) wrote: My wording of the initial message must have been vague. AGPLv3 does not prohibit commercial use, but SINTEF as the copyright holder only allows AGPLv3 use if the application is not a commercial cloud service. Sorry to be a PITA Cirilo, but this is still not correct. Look at one example file, say [1]. It has a standard AGPL3 header. That means you are fully free to do with it all the things people do with AGPL-licensed files, including setting up a commercial cloud service. Then, after the standard AGPL3 header, they write this: Other Usage You can be released from the requirements of the license by purchasing a commercial license. Buying such a license is mandatory as soon as you develop commercial activities involving the SISL library *without* disclosing the source code of your own applications. Emphasis on without is mine. Also, the mentioning of commercial activities is superfluous in their sentence. *Any* activity, commercial or not, which breaches AGPL will need their permission. So people are completely free to set up a commercial cloud service using KiCad with SISL in it. They just have to provide users with an easy way to access all the sources of KiCad, including the SISL bits. This is the behaviour we all want (I guess) anyway, so all is good. Cheers, Javier [1] https://github.com/SINTEF-Geometry/SISL/blob/master/src/construct.c ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] thoughts on dependency on SISL library
Not being able to use it for cloud services because of AGPL3+ (I haven’t looked at the license, I say it per your comments, cirilo) means that people could not use Kicad scripting for automating the processing for manufacturing of Kicad files (as an example) without publishing their scripts (I guess). And that’s not necessarily a good thing. Miguel Ángel Ajo On Thursday, 26 de March de 2015 at 9:17, Javier Serrano wrote: On Thu, Mar 26, 2015 at 4:36 AM, Cirilo Bernardo cirilo.berna...@gmail.com (mailto:cirilo.berna...@gmail.com) wrote: [ snip ] The only really tricky part comes from the 'v3' bit - according to the FSF the AGPLv3 is not compatible with GPL2, and not even compatible with GPLv3 but OK to mix with GPLv3 (whatever that means - I can already hear some lawyers laughing). [ IANAL, please take the following as the opinion of a non-expert. ] This is why the '+' (i.e. the or-later) in GPL2+ is really important. The KiCad sources are, to the best of my knowledge, GPL2+ (most) and GPL3+ (the PS router). That means that the mix is effectively GPL3+. SISL seems to be AGPL3+. I see no incompatibility (see section 13 of both licenses), but mixing in AGPL3+ code is a step in the stronger copyleft direction. This is a strategic decision to be taken, IMHO by the project leader. Any thoughts on eventually having SISL as a dependency? What's the current status of licensing of KiCad source modules? I can remove the SISL dependency but this will cripple the IGES code by removing the ability to check the validity of some structures within an input file. There is still the misleading COPYRIGHT.txt in the root of the KiCad sources, which I think should just be removed. This is important, and I hope it can be done before the stable release. Cheers, Javier ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Library developers.
I agree with Wayne, I watch the repositories, but I barely have the time to track all the discussions. So I join his request, if some of those discussions could affect a lot of people using the parts, please bring it to the development list. Looking into the future, it would be awesome if at some point, we were able to track parts by the UUID, regardless of in which library is, so if the part is moved, as long as the library is imported, we can yet use the part (not 100% if that’s the case now. probably is?). Yet more amazing would be to have access to the footprint version history, or be able to pin the footprints to certain versions, I guess something like that would be possible the day we have some sort of footprint/design server, with metadata (versions, comments, votes..) Best regards, Miguel Ángel. Miguel Ángel Ajo On Monday, 23 de March de 2015 at 19:44, Samuel Dolt wrote: For people who want to follow any change in library, Github allow to watch a repo: When you watch a repository, you get notifications (by email) for any new pull requests and issues that are created, including those not mentioning you. https://help.github.com/articles/watching-repositories/ Significant changes often leads to discussion and decisions in issues or pull request. Best regards ___ Samuel Dolt Le 23 mars 2015 à 16:50, Wayne Stambaugh stambau...@gmail.com (mailto:stambau...@gmail.com) a écrit : A quick note to our library developers. I really like some of the recent work you have been doing. It would be nice in the future when you make big changes like renaming files and paths to give everyone a heads up on developers mailing list and possibly the users mailing lists so we don't get blindsided by unexpected changes which affect old projects. Thanks, Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Confluence access
Hi, Adam Sending you an invite link in private. Miguel Ángel Ajo On Saturday, 21 de March de 2015 at 18:13, Nick Østergaard wrote: I can give you access when I get home. Den 21/03/2015 18.09 skrev Adam Wolf adamw...@feelslikeburning.com (mailto:adamw...@feelslikeburning.com): Hi folks! Any chance I can get Confluence access? Additionally, could I make a page in confluence that is the current Installing Kicad page, but just split up per platform? I think it will be less overwhelming for new users. Adam Wolf Cofounder and Engineer WL ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://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 update.
Nice Adam! I wonder what happens with the console, basically it fires up, but most keystrokes are handled as shortcuts.. In the other hand plugin (footprint wizard) loading doesn’t show any wizard (and we bundle a few). (Open footprint editor - New footprint using wizard) check if we’re providing correct env vars, and if this code is valid enough for our OS X bundling. http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/scripting/kicadplugins.i#L70 Otherwise we could extend the places were python looks for plugins at start if that were necessary. Best, Miguel Ángel. Miguel Ángel Ajo On Monday, 16 de March de 2015 at 19:34, Adam Wolf wrote: Hi folks, There is a debug night build of Python scripting on OS X, thanks to Collin. I haven't switched it over because the scripting console is messed up. I posted details on the list a few weeks ago, but here's the link. http://downloads.kicad-pcb.org/osx/DEBUG/ If folks think I should switch it over to be the regular nightlies, I can do that no problem. Adam Wolf Cofounder and Engineer WL On Mon, Mar 16, 2015 at 1:13 PM, Wayne Stambaugh stambau...@gmail.com (mailto:stambau...@gmail.com) wrote: I hope we can get Python scripting working on OSX before the stable release but I cannot guarantee it. Building OSX binaries has been difficult to say the least but I think we're close. The OSX devs can probably give you a better idea than I can. On 3/14/2015 5:00 PM, Jean-Paul Louis wrote: I still cannot build with Python Scripting enabled in OS X, and the build made by Adam was not working (Python console unusable) Will that be fixed before stable release? I am not using it yet because of this. Just curious, Jean-Paul AC9GH On Mar 14, 2015, at 2:47 PM, Wayne Stambaugh stambau...@gmail.com (mailto:stambau...@gmail.com) wrote: As you all know we are currently working towards a stable release. I need to get and idea of what open items are left before I declare a feature freeze. Here is the list of things I know about: * Environment variable path edit dialog (me, in progress). * Add bitmaps and missing entries to GAL canvas context menu (CERN). * Python API (Miguel). * OSX track pad (Garth). Are there any other features that are on the radar for the next stable release? I will make exceptions on a case by case basis after the freeze but I don't want to get blind sided by any unexpected feature requests the week before the stable release. We need to go through the bug tracker and make sure we don't have any known severe bugs which cause crashes and/or data loss that have not been tagged fix committed and take the appropriate action. This number will have to be zero before I will make the stable release. Obviously I would like to get as many of non-critical bugs fixed as well. What is the current status of the documentation and it's CMake build configuration code? Are we far enough along that we can move the repo to https://github.com/KiCad? I want all of the official KiCad repos there for obvious reasons. We also need to get this set up soon so the documentation for the new router features can be added which I'm guessing will take awhile. I will give all of the necessary document developers commit access to that repo once it is set up. I'm going to let the doc developers handle the pull requests so I can keep my involvement to a minimum. Also, what about nightly builds of the documentation? We will need them as well. I think we are in pretty good shape as far as nightly builds go for all of the major platforms. Thanks to all of you who have worked tirelessly on this. If we are missing anything in this regard, please help out if you can so we can have as many bases covered as possible once the stable release is out. Hopefully I can announce the feature freeze in the next few weeks so we can start focusing on the stable release. Thank you all for efforts. I hoping the next stable release of KiCad will meet the needs of our users. Cheers, Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post
[Kicad-developers] Stable Release freeze Python-API
I’ve been pushing a bit lately on the kicad-python Piers started, trying to make everything as consistent as I can, documented [1], and code as easy to type and tested as possible [2] [3] [4] [5]. My intention was to get this for the stable release, together with python, but, given the close deadline, I’m unsure if it’s going to be better to merge it not for this but for the next stable version. One approach could be to do a quick review of the current API interface, merge it now, and keep gradually merging back new objects exposed via the new API (I could do the backports), and automated stable builds could help there, the changes are quite orthogonal to the whole kicad code, so they may not bring regressions. My main concerns are nits: 1) Making parameters consistent across all the exposed functions. pos vs position, ref vs reference, etc... 2) Making parameter ordering consistent across exposed functions. Opinions/Thoughts? [1] http://ci.kicad-pcb.org/job/kicad-python/ws/doc/build/html/index.html [2] https://github.com/KiCad/kicad-python/blob/master/tests/unit/pcbnew/test_pcbnew_board.py [3] https://github.com/KiCad/kicad-python/blob/master/tests/unit/pcbnew/test_pcbnew_module.py [4] https://github.com/KiCad/kicad-python/blob/master/tests/unit/pcbnew/test_pcbnew_drawing.py [5] https://github.com/KiCad/kicad-python/blob/master/tests/unit/test_kicad_point.py Miguel Ángel Ajo ___ Mailing list: https://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] Announcing work on providing windows nightlies
Awesome Nick!, Good work. :) Miguel Ángel Ajo On Thursday, 12 de March de 2015 at 13:14, Nick Østergaard wrote: Greetings Just to announce it for the people interested: Windows nightlies should soon be a reality. A week or so ago I started looking into packaging the windows builds that was created in MSYS2, where I made a script and upgraded the NSIS install script to make it work together, including python scripting. This currently seems to work. My work is currently hosted on [2], but I will try to merge it with [1] soon. I have stashed some builds on [3], that interested people can try out. Be aware that they are in testing, but feedback would be appreciated. I discovered that Brian Sidebotham was looking into making the kicad winbuilder use MSYS2, so I am working together with Brian Sidebotham on upgrading the kicad winbuilder to use the MSYS2 environment, which should ease the creation of the toolchain and the dependencies. This work is currently on [1]. We hope to get the repo under the KiCad umbrella to keep it together in one place. For nightly builds Adam Wolf has offered a build server, so he will eventually start pushing builds to [4] as we do for the OS X builds. Regards Nick Østergaard [1] https://github.com/BrianSidebotham/KiCad-Winbuilder [2] https://github.com/nickoe/kicad-windows-nsis-packaging [3] http://www2.futureware.at/~nickoe/ [4] http://downloads.kicad-pcb.org/ ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] github mirror out of sync
May be we could sync it from ci.kicad-pcb.org if he agrees, so everything is at one place. Best, Miguel Ángel Ajo On Tuesday, 3 de March de 2015 at 20:40, Nick Østergaard wrote: I did report it to Povilas earlier today, who runs the sync. 2015-03-03 20:19 GMT+01:00 Paulo Henrique Silva ph.si...@gmail.com (mailto:ph.si...@gmail.com): Dears, latest commit on https://github.com/KiCad/kicad-source-mirror is from Feb 28th. Nothing since bzr rev 5464 is there. Might have a script somewhere that stopped. Cheers, -- Paulo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://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] Diff Pairs Length tuning in the product branch
A-ma-zing work! ;) Thank you. Miguel Ángel Ajo On Wednesday, 4 de March de 2015 at 3:38, Andrew Zonenberg wrote: So if I understand this correctly, net names must currently be FOO+ and FOO- for differential pair routing. Can you add support for FOO_P and FOO_N naming? These names are legal identifiers in most hardware description languages and will allow PCB and HDL net names to be the same. On 03/03/2015 08:44 AM, Tomasz Wlostowski wrote: Dear all, We've just merged the new features of the Interactive Router to the product branch: - Routing differential pairs (in pushshove mode too). - Tuning trace length. - Tuning differential pair length and skew. There's a video tutorial and a demo available on YouTube [1]. The merge also includes some improvements to the selection/edit tools that we've developed alongside the new router features: - Snapping to the origin axes when moving (allowing to move an item exactly vertically/horizontally wrt its former position) - Editing footprint pad properties directly on PCB. - Moving pads of a footprint directly on PCB. - Opening the footprint editor for selected footprint on a PCB in GAL mode. - Dragging footprints by origin, pad 1 or pad nearest the cursor. - Guessing the best selection candidate instead of displaying the disambiguation menu every time. We did our best to make sure the branch compiles and runs correctly, and we'll greatly appreciate your feedback - be that bugs, feature requests or suggestions for improvements. Please keep in mind this is the first public release of the Diff Pairs, so some fine tuning may be needed in the future. Many thanks to all developers, funders users for your help and support! Cheers, Tom Orson [1] https://www.youtube.com/watch?v=chejn7dqpfQ ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Python Plugin - Use of advanced LSET onstructor
I haven’t been able to try it but the code looks good to me. Can anybody confirm it’s working before merging it to the footprint wizards? Miguel Ángel Ajo On Tuesday, 3 de March de 2015 at 1:08, nats wrote: In response to a message written on 02.03.2015, 01:26, from nats: I add some details I got after more test. Maybe it should be considered as a bug. I can use this constructor: __init__(self, unsigned int aIdCount, LAYER_ID aFirst, v(...) *args) - LSET But only if I put 1 layer in the list (with no respect for the aIdCount value). For example pcbnew.LSET(1, pcbnew.F_Cu) = Works pcbnew.LSET(2, pcbnew.F_Cu) = Works (but it shouldn't !) pcbnew.LSET(2, pcbnew.F_Cu, pcbnew.B_Cu) = Doesn't Work but it should. The Error is indicated in the previous e-mail. Maybe there is a confusion in the type of argument linked to the Python Swig translation ? From some reason C++ input list form is incompatible with python list/tuple. Maybe might this help (ParseHex method): https://github.com/pierstitus/kicad-python/blob/master/pcbnew_easy.py Thanks a lot for this information. I managed to get it working, after some discussion on IRC I copied the LSET code inside the plugin. It'll be removed when kicad python new api will be ready. Here is the link for reference: https://github.com/natsfr/kicad-components/blob/master/python_plugins/qfn_wizard.py If you have any remark on the code don't hesitate. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] What happened to the dxf plotter???
Did you look at the code?, may be it was because some sort of refactor to reunify code (just guessing). I’m not very familiar with that part. Best, Miguel Ángel Ajo On Friday, 27 de February de 2015 at 10:24, LordBlick wrote: In response to a message written on 27.02.2015, 09:28, from Lorenzo Marcantonio: On Fri, Feb 27, 2015 at 09:20:03AM +0100, Lorenzo Marcantonio wrote: On Thu, Feb 26, 2015 at 07:51:34PM -0500, Mark Roszko wrote: I wonder if theres a bug. It literally takes 5 minutes to run a DXF plot of the pic programmer demo kicad has. Gebers are instant. The long processing time could be due of that huge polygon merging operation. However that's not the problem; and for a plot that could be even acceptable. It's the final result that's not suitable for mechanical work. In my opinion, DXF plot should have some checkbox option „milling contour” for present behavior which unchecked orders for past one. Sometimes treatment tracks as tiny lines also gives some useful information in precise orientation mechanical work. -- Best Regards, LordBlick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Mac OS X nightlies are up!
On Thursday, 26 de February de 2015 at 9:41, Nick Østergaard wrote: 2015-02-26 9:39 GMT+01:00 Collin Anderson metacol...@electropi.mp (mailto:metacol...@electropi.mp): Is the script that is used to produce the nightlies available somewhere in the main branch? I haven't been able to find it :(. He said earlier that it is available on https://code.launchpad.net/~adamwolf/+junk/kicad-mac-packaging Thank you Adam!, May be we could put a link library to the packaging repositories all around into the development website, (A packager section?), such thing could other packager life easier, and they can cross-pollinate each other. Best, Miguel Ángel. Anyway, to Adam: The install experience of the support files etc. is effortless and feels very mac-like. Great job nailing that! Also, what exactly is giving you trouble in regards to python scripting? If you could elaborate on the problem, or even better, share the build script, I could help get python going quickly, and without doing any of the stuff I mentioned in some earlier emails on the subject. I figured out how to make wxpython weak link python, allowing one .app bundle to correctly work on 10.7-10.10's libpython. No huge increase in bundle size :). To correctly have GUI python scriptability (using wxpython or anything else, its not unique to this situation) that works across multiple major revisions of OS X, you have to use weak linking, here is the low-down on doing that. MAC_OS_X_VERSION_MIN_REQUIRED is what you want. https://developer.apple.com/legacy/library/technotes/tn2064/_index.html -- Violence is the last refuge of the incompetent. - Isaac Asimov On Feb 23, 2015, at 10:58 PM, Johannes Maibaum jmaib...@gmail.com (mailto:jmaib...@gmail.com) wrote: http://downloads.kicad-pcb.org/osx/DEBUG/ ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://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] Feature freeze and next release terminology
Lol :) Miguel Ángel Ajo On Tuesday, 24 de February de 2015 at 17:28, Wayne Stambaugh wrote: Damn! Too late for 4.0.0. Better one up Linus by using 5.0.0. :) On 2/24/2015 11:30 AM, Adam Wolf wrote: Hi Wayne, Any chance you can make a call on 3.0.0 vs 4.0.0? (Torvalds just took Linux to 4.0 this week :)) Adam Wolf On Tue, Feb 24, 2015 at 10:22 AM, Wayne Stambaugh stambau...@gmail.com (mailto:stambau...@gmail.com) mailto:stambau...@gmail.com wrote: Here is the stable release policy: http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/md_Documentation_development_stable-release-policy.html I still need to add the numbering system to this. On 2/24/2015 11:00 AM, Adam Wolf wrote: Hi folks, I have started and deleted this email multiple times. I really don't enjoy discussions like this, but sometimes they're necessary. I have ran into quite a few misconceptions recently from non-devs about what the upcoming release is going to be. The issues I am seeing seem to hinge around the word stable. As far as I know, every single source commit we make, we intend to be stable and usable, and we don't really commit half-features very often (if ever), and I have been seeing users get very confused about that based on the word stable for the upcoming release. This will always be a goal for the product branch as long as I am project leader. Keeping the development branch usable is important. As far as I know, there are going to be two things that make the upcoming release special: 1) a feature freeze beforehand so we can run manual tests, make sure our features work well, and hopefully fix any packaging issues on the main targets without any churn of new features 2) file format incompatibilities 3) A bunch of new features (gal, pns router, 64 layers, etc.) since the last stable release. What about instead of calling it stable, we called it by a version number? Kicad 2.0? I think more users would understand what we're doing. We discussed using a triplett. Most likely the upcoming release will be 3.0.0 or 4.0.0. Either is fine by me. There will never be a 3.1.X or 3.2.X because features will *not* be back ported under the current policy. Only critical errors (read crash, data loss, memory leaks, etc) will be fixed in the stable release branch so there will only be 3.0.1, 3.0.2, etc, versions. There will be no attempt to maintain compatibility with the development branch file formats. Either you bleed on the edge and help with testing or you live with the features in the current stable release. I am not reopening this subject for discussion for obvious reasons. We've beat this horse to death and given our resource limitations, this is the best compromise. This email is primarily directed at Wayne, but I like to keep things in the open if possible. Adam Wolf Cofounder and Engineer Wayne and Layne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) mailto:kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) mailto:kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://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] Rendering issues with line drawing
That’s correct, at a minimum (if you want to do your own builds), you need at least wxGTK3 from my copr build (and wxPython3 if you want WXPYTHON enabled). wxGTK3 in the copr build is built against gtk2, which will fix your issue with drawing for now. Now that you’re on f21 you should be able to use that copr repo. Miguel Ángel Ajo On Saturday, 21 de February de 2015 at 10:48, Nick Østergaard wrote: 2015-02-20 23:14 GMT+01:00 Rick Walker wal...@omnisterra.com (mailto:wal...@omnisterra.com): Hi Miguel, But you say need at least fc20 I saw you're running f19. Btw f21 works quite well. Thanks for the suggestion. I used fedup to upgrade from 19 to 21 this morning. I still have the same rendering problem with version 5041. Should I try switching from Normal View to OpenGL as Lorenzo suggested? How do I do this? See the options in the View menu, and try the hotkey F11. But this only fixes it in pcbnew, eeschema will still be buggy. So if you want to use kicad, I reccomend the copr build. If you're on fedora, you have the relevant packages here: https://copr.fedoraproject.org/coprs/mangelajo/kicad/ This will be my project for the afternoon. I'll install the mangelajo build and let you know what happened. The default STABLE build and the default Fedora21 bits don't seem to work properly on my laptop. kind regards, -- Rick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Mac OS X nightlies are up!
Awesome job!!! ;) Miguel Ángel Ajo On Monday, 23 de February de 2015 at 09:57, Javier Serrano wrote: On Sat, Feb 21, 2015 at 6:29 PM, Adam Wolf adamw...@feelslikeburning.com (mailto:adamw...@feelslikeburning.com) wrote: Thanks everyone! Even though this was a lot of work from us at Wayne and Layne, what we did was only a drop in the bucket compared to what has already been done by the dev team and the OS X devs! Adam, congratulations to you and the rest of OS X devs. What you guys have done is amazing, and very useful to many people. Cheers, Javier ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Fedora 21 nightlies build
Thanks for testing Bob. I need to go back and pull the footprints, I had to remove that part for now because of different issues. For now you can use the Library table wizard JP made to pull the libraries from github. But I will work to make the footprints packaged. I was considering to drop off the documentation for the nightlies, because they are extremely heavy. In the end nightlies are built on top of the development branch, and they won’t necessarily match the docs. Miguel Ángel Ajo On Friday, 20 de February de 2015 at 16:47, Bob Gustafson wrote: Looks pretty good. Your dnf commands are pretty straightforward. I was able to see a brand new KiCad home page in just a few minutes. The Config info is below. From the install, it was rev-4744 Application: Eeschema Version: (2014-jan-25)-product Release build wxWidgets: Version 2.8.12 (release,Unicode,compiler with C++ ABI 1002,GCC 4.9.2,wx containers,compatible with 2.4,compatible with 2.6) Platform: Linux 3.18.7-200.fc21.x86_64 x86_64, 64 bit, Little endian, wxGTK Boost version: 1.55.0 USE_WX_GRAPHICS_CONTEXT=OFF USE_WX_OVERLAY=OFF KICAD_SCRIPTING=OFF KICAD_SCRIPTING_MODULES=OFF KICAD_SCRIPTING_WXPYTHON=OFF USE_FP_LIB_TABLE=HARD_CODED_ON BUILD_GITHUB_PLUGIN=OFF I haven't spent more than 15 minutes testing, so I haven't seen everything - (no libraries installed..) The doc and help are properly found and look good. Setting the page parameters (A4 to US Letter) in the home page does not seem to carry over to the schematic page parameters, but perhaps that is by design. Still testing (after I find the footprints..) Thanks much Bob G On 02/14/2015 04:18 PM, Miguel Ángel Ajo wrote: Fedora 21 nightlies build is fully working now (no more canvas problems), I had to recompile wxGTK3 with ‘gtk2’ and wxPython with that build, then kicad on top. If you had the repo configured previously, do a: dnf clean all dnf remove wxGTK3 wxPython kicad dnf install kicad Otherwise follow the instructions at: https://copr.fedoraproject.org/coprs/mangelajo/kicad/ To override other wxGTK3 or wxPython versions, I have bumped the revisions of those with +1000, but that’s a bit hacky, and may break when fedora releases new wxGTK3 versions, I will look into a definitive solution as soon as I can, but that may work for now. Please, let me know how if it works/doesn’t work for you. Eventually I will set a builder for the stable version too. Best regards, Miguel Ángel Ajo On Thursday, 15 de January de 2015 at 11:25, Miguel Ángel Ajo wrote: I wanted to announce that I have created this repository with nightly builds for KiCad: https://copr.fedoraproject.org/coprs/mangelajo/kicad/ http://ci.kicad-pcb.org/job/fedora-nightlies/ It has wxPython and python scripting enabled, and it’s based on wxWidgets 3.0.0, as kicad is now. For now you will find it’s a bit broken, as the wxGTK3 canvas is not working correctly (having the same issue if I don’t link to wxPython3 and do it to the fedora stock wxGTK3), that means eeschema is quite unusable, pcbnew only works correctly on the OpenGL or Cairo Canvas. By the way, even broken I believe it’s a good opportunity for anyone willing to have a look on the latest release. Miguel Ángel Ajo ___ Mailing list: https://launchpad.net/~kicad-developers (https://launchpad.net/%7Ekicad-developers) Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers (https://launchpad.net/%7Ekicad-developers) More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] wxPython version check
Awesome Wayne!!, there it was [1]!!! :) :-D
Miguel Ángel Ajo
[1]
https://github.com/KiCad/kicad-source-mirror/commit/04c55f0956b6e69cfc925be77cd9dfaa01537d1a
On Thursday, 19 de February de 2015 at 02:49, Wayne Stambaugh wrote:
I figured it out. The wxPython version was getting initialize after
config.h was getting written. Duh! This should be fixed in r5431. I'm
going to bed now :)
On 2/18/2015 7:26 PM, Miguel Ángel Ajo wrote:
Just a note:
I’m running cmake from an *empty* build dir:
mkdir build
cd build
cmake -D… -D… ..
and I get into the problem, which goes away with the make rebuild_cache.
Miguel Ángel Ajo
On Thursday, 19 de February de 2015 at 01:24, Miguel Ángel Ajo wrote:
Exactly, if I runs make rebuild_cache, or if I simply rerun cmake
twice (no
need to delete config.h) the #define WXPYTHON_VERSION turns from “” to
“3.0”.
When is cmake supposed to generate config.h exactly?
Miguel Ángel Ajo
On Thursday, 19 de February de 2015 at 01:21, Wayne Stambaugh wrote:
They should match so that's the problem. I have the same problem when I
build from an existing build. It appears that config.h is not getting
rebuilt. Try running `make rebuild_cache` or deleting config.h and see
if CMake sets the WXPYTON_VERSION string to 3.0 which is what is found
during the configuration.
On 2/18/2015 6:41 PM, Miguel Ángel Ajo wrote:
Hmm, it seems that in my system it’s getting an empty string ‘’,
where does WXPYTHON_VERSION come from?
/// The wxPython version found during configuration.
#if defined( KICAD_SCRIPTING_WXPYTHON )
#define WXPYTHON_VERSION
#endif
Shouldn’t that match WXPYTHON_VERSION_FOUND from CMakeCache.txt ?
Miguel Ángel Ajo
On Thursday, 19 de February de 2015 at 00:35, Miguel Ángel Ajo wrote:
KICAD_SCRIPTING_WXPYTHON:BOOL=ON
and
WXPYTHON_VERSION_FOUND:STRING=3.0
I wonder what’s wrong with my “wxversion” thing… the exact error is:
[ajo@kicad kicad-5430]$ pcbnew
Traceback (most recent call last):
File string, line 1, in module
File /usr/lib64/python2.7/site-packages/wxversion.py, line 149, in
select
bestMatch = _get_best_match(installed, versions, optionsRequired)
File /usr/lib64/python2.7/site-packages/wxversion.py, line 273, in
_get_best_match
score = pkg.Score(_wxPackageInfo(ver), optionsRequired)
File /usr/lib64/python2.7/site-packages/wxversion.py, line 357, in
__init__
self.version = tuple([int(x) for x in segments[0].split('.')])
ValueError: invalid literal for int() with base 10: ''
ImportError: No module named wx._core_
If I do this in console, it seems to work
import wxversion
wxversion.select('3.0')
I will try to check what’s really getting through WXPYTHON_VERSION,
or why is it failing
in my system when inside pcbnew.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 23:38, Miguel Ángel Ajo
wrote:
Hi Wayne,
I don’t have direct access to the CmakeCache (due that I’m
relying on
copr for my builds),
but I could try to replicate locally, btw, this is from the build
logs:
-- Found wxWidgets:
-pthread;;;-lwx_gtk2u_gl-3.0;-lwx_gtk2u_aui-3.0;-lwx_gtk2u_adv-3.0;-lwx_gtk2u_html-3.0;-lwx_gtk2u_core-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_stc-3.0
(found suitable version 3.0.2, minimum required is 3.0.0)
and I set KICAD_SCRIPTING_WXPYTHON on cmake:
https://copr-be.cloud.fedoraproject.org/results/mangelajo/kicad/fedora-21-x86_64/kicad-5429-nightlies.fc22/build.log.gz
I’m going to debug a bit to see what’s happening, and read the
thread
about the wxPython changes that
I didn’t have time to read in full.
Best reagards,
Miguel Ángel.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 18:05, Wayne Stambaugh
wrote:
Miguel,
What is the output of:
grep WXPYTHON kicad_build_path/CMakeCache.txt
You should see something like this:
KICAD_SCRIPTING_WXPYTHON:BOOL=ON
WXPYTHON_VERSION_FOUND:STRING=3.0
If WXPYTHON_VERSON_FOUND is empty, run `make rebuild_cache`.
Cheers,
Wayne
On 2/18/2015 10:44 AM, Miguel Ángel Ajo wrote:
It looks like something related to the python paths not
being able to find wx._core_.
I’ll put some time tonight on it.
Miguel Ángel Ajo
Re: [Kicad-developers] OSX Nightlies Update
Awesome work Adam!, I will spend some cycles in testing it this night ;) Miguel Ángel Ajo On Wednesday, 18 de February de 2015 at 09:27, Bernhard Stegmaier wrote: Hi Adam, looks great! Small question: I noticed that in the non-extras dmg there are ~370MB 3D-models in kicad/packages3d. Is that on purpose? I would have expected those also in the extra-dmg along with the footprints… Regards, Bernhard On 17.02.2015, at 18:50, Adam Wolf adamw...@feelslikeburning.com (mailto:adamw...@feelslikeburning.com) wrote: Hi folks, I have an updated set of OS X nightlies. I had about 20 users test it out last week, and one user had a horrible problem and pcbnew wouldn't start, and it looked like a classic bundle paths issue that we've had and solved about 10 times, but the other 19 seemed to have everything work fine. If you can take a moment to try them out, that'd be great! If it looks ok, I'll turn on pushing to kicad-pcb.org (http://kicad-pcb.org/), and then work towards Python in the nightlies. https://www.dropbox.com/s/9l3d3m8xbvlrq91/kicad-r5404.20150502-102027.dmg?dl=0 https://www.dropbox.com/s/gulwm6afhflfc5c/kicad-extras.20150502-102112.dmg?dl=0 The extras dmg has the offline footprints. Adam Wolf Cofounder and Engineer WL ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://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] wxPython version check
Hi Wayne,
I don’t have direct access to the CmakeCache (due that I’m relying on copr for
my builds),
but I could try to replicate locally, btw, this is from the build logs:
-- Found wxWidgets:
-pthread;;;-lwx_gtk2u_gl-3.0;-lwx_gtk2u_aui-3.0;-lwx_gtk2u_adv-3.0;-lwx_gtk2u_html-3.0;-lwx_gtk2u_core-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_stc-3.0
(found suitable version 3.0.2, minimum required is 3.0.0)
and I set KICAD_SCRIPTING_WXPYTHON on cmake:
https://copr-be.cloud.fedoraproject.org/results/mangelajo/kicad/fedora-21-x86_64/kicad-5429-nightlies.fc22/build.log.gz
I’m going to debug a bit to see what’s happening, and read the thread about the
wxPython changes that
I didn’t have time to read in full.
Best reagards,
Miguel Ángel.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 18:05, Wayne Stambaugh wrote:
Miguel,
What is the output of:
grep WXPYTHON kicad_build_path/CMakeCache.txt
You should see something like this:
KICAD_SCRIPTING_WXPYTHON:BOOL=ON
WXPYTHON_VERSION_FOUND:STRING=3.0
If WXPYTHON_VERSON_FOUND is empty, run `make rebuild_cache`.
Cheers,
Wayne
On 2/18/2015 10:44 AM, Miguel Ángel Ajo wrote:
It looks like something related to the python paths not
being able to find wx._core_.
I’ll put some time tonight on it.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 16:33, Brian Sidebotham wrote:
On 18 February 2015 at 14:26, Miguel Ángel Ajo majop...@redhat.com
(mailto:majop...@redhat.com)
mailto:majop...@redhat.com wrote:
Hmm, this crashes in the fedora nightly build during pcbnew startup,
I need
to investigate why.
https://github.com/KiCad/kicad-source-mirror/commit/69553d6fa31a60a4694395f0dcadfdbd787c21a8#diff-cdb8e872a96e63280c27292a5845cfbeR147
snprintf( cmd, 1023, import wxversion; wxversion.select('%s'),
WXPYTHON_VERSION );
PyRun_SimpleString( cmd );
Probably a missing
PyLock lock;
Also, we don't need to use snprintf here, we can simply use:
const char* cmd = import wxversion; wxversion.select('
WXPYTHON_VERSION ');
instead.
Sorry I don't have time to investigate the crash right now. Good Luck.
Best Regards,
Brian.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
(mailto:kicad-developers@lists.launchpad.net)
mailto:kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
(mailto:kicad-developers@lists.launchpad.net)
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
(mailto:kicad-developers@lists.launchpad.net)
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] wxPython version check
Hmm, this crashes in the fedora nightly build during pcbnew startup, I need to
investigate why.
https://github.com/KiCad/kicad-source-mirror/commit/69553d6fa31a60a4694395f0dcadfdbd787c21a8#diff-cdb8e872a96e63280c27292a5845cfbeR147
snprintf( cmd, 1023, import wxversion; wxversion.select('%s'),
WXPYTHON_VERSION ); PyRun_SimpleString( cmd );
Miguel Ángel Ajo
On Tuesday, 17 de February de 2015 at 17:31, Brian Sidebotham wrote:
On 16 February 2015 at 17:44, Wayne Stambaugh stambau...@gmail.com
(mailto:stambau...@gmail.com) wrote:
On 2/16/2015 11:44 AM, Brian Sidebotham wrote:
On 16 February 2015 at 15:42, Brian Sidebotham
brian.sidebot...@gmail.com (mailto:brian.sidebot...@gmail.com) wrote:
On 16 February 2015 at 14:17, Wayne Stambaugh stambau...@gmail.com
(mailto:stambau...@gmail.com) wrote:
Brian,
How are you telling the kicad configuration where wxPython build is
located during you winbuilder configuration? Would Garth's solution
below solve your problem? The only issue I see with Garth's solution
is
that if you install wxPython somewhere other than where you defined
PYTHON_SITE_PACKAGE_PATH, you would be right back to where you
started.
In other words you could build kicad but when you launched the python
console, it would most likely crash because wxPython would not be
located at PYTHON_SITE_PACKAGE_PATH or worse a different version of
wxPython would be loaded.
Hi Wayne,
These days however packages like mingw-w64-python2 exist and so really
we should be able to make use of that in KiCad-Winbuilder instead of
the custom projects. I'll look into it.
I just checked
http://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686/mingw-w64-i686-python2-2.7.9-2-any.pkg.tar.xz/download
Unfortunately we get: libgcc_s_dw2-1.dll is missing. This is a
show-stopper in my opinion because dwarf-2 is known to be broken with
regards to throwing exceptions across DLL boundaries. Since the Kiway
work there's no real option but to support exception throwing across
DLL boundaries otherwise exceptions cannot propagate correctly.
After all this time, this issue hasn't been addressed? This was an
issue over 10 years ago. This makes me feel better about the bug fixing
rate in KiCad. I'm not sure which code in KiCad would cause this error.
Most of the exceptions that I can think of do not cross DLL boundaries.
They only cross from the DLL to the main executable which does not
fail. I just tested the pretty library parser which throws an IO_ERROR
from _pcbnew.kiface to pcbnew.exe without any issues. I don't think
wxWidgets raises any an most of Boost is the header libraries so that
wouldn't be an issue either. Do Python exceptions cross over into C++
land? If so, that could be an error.
Hi Wayne,
Thanks so much for doing a quick sanity check. I forget the check I
used to do. Perhaps it is no longer an issue these days and I'm worry
about a past issue. I'll try and re-base KiCad-Winbuilder off the
MSYS2 project MINGW repos for wxPython and python.
With regards to Python throwing exceptions, it's written entirely in C
so there's no risk of it throwing exceptions.
Best Regards,
Brian.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
(mailto:kicad-developers@lists.launchpad.net)
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] OSX Nightlies Update
More path stuff (sorry Adam.. ‘:D ) I tried the kicad templates, but I wasn’t pointed out to the templates when trying to create a project from templates. Miguel Ángel Ajo On Wednesday, 18 de February de 2015 at 14:32, Adam Wolf wrote: Bernhard, I was under the impression that 3d models do not come automatically from github without downloading. If they come through fine, then they should definitely be moved to the extras dmg. Adam Wolf Cofounder and Engineer Wayne and Layne On Feb 18, 2015 2:27 AM, Bernhard Stegmaier stegma...@sw-systems.de (mailto:stegma...@sw-systems.de) wrote: Hi Adam, looks great! Small question: I noticed that in the non-extras dmg there are ~370MB 3D-models in kicad/packages3d. Is that on purpose? I would have expected those also in the extra-dmg along with the footprints… Regards, Bernhard On 17.02.2015, at 18:50, Adam Wolf adamw...@feelslikeburning.com (mailto:adamw...@feelslikeburning.com) wrote: Hi folks, I have an updated set of OS X nightlies. I had about 20 users test it out last week, and one user had a horrible problem and pcbnew wouldn't start, and it looked like a classic bundle paths issue that we've had and solved about 10 times, but the other 19 seemed to have everything work fine. If you can take a moment to try them out, that'd be great! If it looks ok, I'll turn on pushing to kicad-pcb.org (http://kicad-pcb.org/), and then work towards Python in the nightlies. https://www.dropbox.com/s/9l3d3m8xbvlrq91/kicad-r5404.20150502-102027.dmg?dl=0 https://www.dropbox.com/s/gulwm6afhflfc5c/kicad-extras.20150502-102112.dmg?dl=0 The extras dmg has the offline footprints. Adam Wolf Cofounder and Engineer WL ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://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] wxPython version check
It looks like something related to the python paths not
being able to find wx._core_.
I’ll put some time tonight on it.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 16:33, Brian Sidebotham wrote:
On 18 February 2015 at 14:26, Miguel Ángel Ajo majop...@redhat.com
(mailto:majop...@redhat.com) wrote:
Hmm, this crashes in the fedora nightly build during pcbnew startup, I need
to investigate why.
https://github.com/KiCad/kicad-source-mirror/commit/69553d6fa31a60a4694395f0dcadfdbd787c21a8#diff-cdb8e872a96e63280c27292a5845cfbeR147
snprintf( cmd, 1023, import wxversion; wxversion.select('%s'),
WXPYTHON_VERSION );
PyRun_SimpleString( cmd );
Probably a missing
PyLock lock;
Also, we don't need to use snprintf here, we can simply use:
const char* cmd = import wxversion; wxversion.select('
WXPYTHON_VERSION ');
instead.
Sorry I don't have time to investigate the crash right now. Good Luck.
Best Regards,
Brian.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
(mailto:kicad-developers@lists.launchpad.net)
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [Merge] lp:~metacollin/kicad/boosting_boost into lp:kicad
We don’t use boost-python (AFAIK). There was a patch by cirilo proposing to merge, but it’s been rejected because we could (theoretically) pull it via an external library or write it in python. Miguel Ángel Ajo On Wednesday, 18 de February de 2015 at 16:10, Adam Wolf wrote: Hi Collin, What part of boost 1.54 is incompatible with OS X 10.10? Are you having trouble with Python scripting and boost? The reason why I ask, is I have been using boost 1.54 on OS X 10.10 for months without issue, but I haven't enabled Python on my builds yet. Adam Wolf Cofounder and Engineer WL On Wed, Feb 18, 2015 at 9:04 AM, Collin Anderson metacol...@electropi.mp (mailto:metacol...@electropi.mp) wrote: Sorry, I didn't mean to waste anyone's time with this patch, I am still very new to the project and still getting a feel for where things are heading and what is a dead end and what isn't. Additionally, I would be terrified of just jumping versions of such a key component like boost without a lot of testing first. Boost 1.54 unfortunately is incompatible with OS 10.10, that's ultimately the motivation behind this patch. As for ripping all that crap out, that was exactly what I wanted to do too. Originally, my homebrew tap had been using the KICAD_SKIP_BOOST option and using an actual install of regular boost 1.57, and it seemed to work without issue for a wide variety of machines, versions of OS X, and users. Beyond that, all but one of the fixes had been pulled into 1.57. The missing patch curiously was simply commenting out two useless lines in minkowski.hpp, I assumed half out of removing warnings, and half out of sheer principal, lines of code with no purpose should not clutter up source files, in my opinion. However, I discovered, using my own as well as reports from several other people, that the autoroute mode in pcbnew crashes the entire .app almost instantly, and with total consistency. Commenting out those useless lines fix this issue completely. I'm not sure if I discovered anything, or simply rediscovered for myself something well known by other contributors. When you say next stable release, do you mean of KiCad, or of boost? If you mean to say that the 1.58 release of boost will incorporate the minkowski patch, then terrific, I can't wait for all that crap to get ripped out. It proved to be a *huge* headache when making the homebrew tap, thats for sure! Or did you mean next stable release of KiCad? Sorry, I am honestly not sure. Assuming this was all well known to everyone, I was curious if anyone knew the mechanism behind the minkowski autoroute issue? My quick guess is that the unused variables being set equal to vital pointers in the convolve function is causing a compiler optimization to do something unfortunate to those poor pointers, and loss of whatever memory location they were supposed to be holding. *shrug* -- Violence is the last refuge of the incompetent. - Isaac Asimov On Feb 17, 2015, at 2:34 PM, Wayne Stambaugh stambau...@gmail.com (mailto:stambau...@gmail.com) wrote: Review: Disapprove After the next stable release, this patch will be lost. I plan on ripping out all of the custom dependency download, patch, and build code from the CMake files after the next stable. If someone needs this to build dependencies on their platform than it will have to be maintained as an external project. The complexity it has added to the project configure and build has been a major source of pain. I recommend creating a kicad-boost project that downloads, patches, and builds boost for the platforms that need it. -- https://code.launchpad.net/~metacollin/kicad/boosting_boost/+merge/248085 You are the owner of lp:~metacollin/kicad/boosting_boost. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://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] wxPython version check
Hmm, it seems that in my system it’s getting an empty string ‘’,
where does WXPYTHON_VERSION come from?
/// The wxPython version found during configuration.
#if defined( KICAD_SCRIPTING_WXPYTHON )
#define WXPYTHON_VERSION
#endif
Shouldn’t that match WXPYTHON_VERSION_FOUND from CMakeCache.txt ?
Miguel Ángel Ajo
On Thursday, 19 de February de 2015 at 00:35, Miguel Ángel Ajo wrote:
KICAD_SCRIPTING_WXPYTHON:BOOL=ON
and
WXPYTHON_VERSION_FOUND:STRING=3.0
I wonder what’s wrong with my “wxversion” thing… the exact error is:
[ajo@kicad kicad-5430]$ pcbnew
Traceback (most recent call last):
File string, line 1, in module
File /usr/lib64/python2.7/site-packages/wxversion.py, line 149, in select
bestMatch = _get_best_match(installed, versions, optionsRequired)
File /usr/lib64/python2.7/site-packages/wxversion.py, line 273, in
_get_best_match
score = pkg.Score(_wxPackageInfo(ver), optionsRequired)
File /usr/lib64/python2.7/site-packages/wxversion.py, line 357, in
__init__
self.version = tuple([int(x) for x in segments[0].split('.')])
ValueError: invalid literal for int() with base 10: ''
ImportError: No module named wx._core_
If I do this in console, it seems to work
import wxversion
wxversion.select('3.0')
I will try to check what’s really getting through WXPYTHON_VERSION, or why
is it failing
in my system when inside pcbnew.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 23:38, Miguel Ángel Ajo wrote:
Hi Wayne,
I don’t have direct access to the CmakeCache (due that I’m relying on copr
for my builds),
but I could try to replicate locally, btw, this is from the build logs:
-- Found wxWidgets:
-pthread;;;-lwx_gtk2u_gl-3.0;-lwx_gtk2u_aui-3.0;-lwx_gtk2u_adv-3.0;-lwx_gtk2u_html-3.0;-lwx_gtk2u_core-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_stc-3.0
(found suitable version 3.0.2, minimum required is 3.0.0)
and I set KICAD_SCRIPTING_WXPYTHON on cmake:
https://copr-be.cloud.fedoraproject.org/results/mangelajo/kicad/fedora-21-x86_64/kicad-5429-nightlies.fc22/build.log.gz
I’m going to debug a bit to see what’s happening, and read the thread about
the wxPython changes that
I didn’t have time to read in full.
Best reagards,
Miguel Ángel.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 18:05, Wayne Stambaugh wrote:
Miguel,
What is the output of:
grep WXPYTHON kicad_build_path/CMakeCache.txt
You should see something like this:
KICAD_SCRIPTING_WXPYTHON:BOOL=ON
WXPYTHON_VERSION_FOUND:STRING=3.0
If WXPYTHON_VERSON_FOUND is empty, run `make rebuild_cache`.
Cheers,
Wayne
On 2/18/2015 10:44 AM, Miguel Ángel Ajo wrote:
It looks like something related to the python paths not
being able to find wx._core_.
I’ll put some time tonight on it.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 16:33, Brian Sidebotham wrote:
On 18 February 2015 at 14:26, Miguel Ángel Ajo majop...@redhat.com
(mailto:majop...@redhat.com)
mailto:majop...@redhat.com wrote:
Hmm, this crashes in the fedora nightly build during pcbnew startup,
I need
to investigate why.
https://github.com/KiCad/kicad-source-mirror/commit/69553d6fa31a60a4694395f0dcadfdbd787c21a8#diff-cdb8e872a96e63280c27292a5845cfbeR147
snprintf( cmd, 1023, import wxversion; wxversion.select('%s'),
WXPYTHON_VERSION );
PyRun_SimpleString( cmd );
Probably a missing
PyLock lock;
Also, we don't need to use snprintf here, we can simply use:
const char* cmd = import wxversion; wxversion.select('
WXPYTHON_VERSION ');
instead.
Sorry I don't have time to investigate the crash right now. Good Luck.
Best Regards,
Brian.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
(mailto:kicad-developers@lists.launchpad.net)
mailto:kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
(mailto:kicad-developers@lists.launchpad.net)
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
(mailto:kicad-developers
Re: [Kicad-developers] wxPython version check
Hmm, if I re-run cmake or, as Wayne suggested, I run
make rebuild_cache, WXPYTHON_VERSION turns into “3.0” inside config.h
I will add that workaround to the kicad fedora builder, but…
why does that happen?
Miguel Ángel Ajo
On Thursday, 19 de February de 2015 at 00:41, Miguel Ángel Ajo wrote:
Hmm, it seems that in my system it’s getting an empty string ‘’,
where does WXPYTHON_VERSION come from?
/// The wxPython version found during configuration.
#if defined( KICAD_SCRIPTING_WXPYTHON )
#define WXPYTHON_VERSION
#endif
Shouldn’t that match WXPYTHON_VERSION_FOUND from CMakeCache.txt ?
Miguel Ángel Ajo
On Thursday, 19 de February de 2015 at 00:35, Miguel Ángel Ajo wrote:
KICAD_SCRIPTING_WXPYTHON:BOOL=ON
and
WXPYTHON_VERSION_FOUND:STRING=3.0
I wonder what’s wrong with my “wxversion” thing… the exact error is:
[ajo@kicad kicad-5430]$ pcbnew
Traceback (most recent call last):
File string, line 1, in module
File /usr/lib64/python2.7/site-packages/wxversion.py, line 149, in
select
bestMatch = _get_best_match(installed, versions, optionsRequired)
File /usr/lib64/python2.7/site-packages/wxversion.py, line 273, in
_get_best_match
score = pkg.Score(_wxPackageInfo(ver), optionsRequired)
File /usr/lib64/python2.7/site-packages/wxversion.py, line 357, in
__init__
self.version = tuple([int(x) for x in segments[0].split('.')])
ValueError: invalid literal for int() with base 10: ''
ImportError: No module named wx._core_
If I do this in console, it seems to work
import wxversion
wxversion.select('3.0')
I will try to check what’s really getting through WXPYTHON_VERSION, or why
is it failing
in my system when inside pcbnew.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 23:38, Miguel Ángel Ajo wrote:
Hi Wayne,
I don’t have direct access to the CmakeCache (due that I’m relying on
copr for my builds),
but I could try to replicate locally, btw, this is from the build logs:
-- Found wxWidgets:
-pthread;;;-lwx_gtk2u_gl-3.0;-lwx_gtk2u_aui-3.0;-lwx_gtk2u_adv-3.0;-lwx_gtk2u_html-3.0;-lwx_gtk2u_core-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_stc-3.0
(found suitable version 3.0.2, minimum required is 3.0.0)
and I set KICAD_SCRIPTING_WXPYTHON on cmake:
https://copr-be.cloud.fedoraproject.org/results/mangelajo/kicad/fedora-21-x86_64/kicad-5429-nightlies.fc22/build.log.gz
I’m going to debug a bit to see what’s happening, and read the thread
about the wxPython changes that
I didn’t have time to read in full.
Best reagards,
Miguel Ángel.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 18:05, Wayne Stambaugh wrote:
Miguel,
What is the output of:
grep WXPYTHON kicad_build_path/CMakeCache.txt
You should see something like this:
KICAD_SCRIPTING_WXPYTHON:BOOL=ON
WXPYTHON_VERSION_FOUND:STRING=3.0
If WXPYTHON_VERSON_FOUND is empty, run `make rebuild_cache`.
Cheers,
Wayne
On 2/18/2015 10:44 AM, Miguel Ángel Ajo wrote:
It looks like something related to the python paths not
being able to find wx._core_.
I’ll put some time tonight on it.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 16:33, Brian Sidebotham wrote:
On 18 February 2015 at 14:26, Miguel Ángel Ajo majop...@redhat.com
(mailto:majop...@redhat.com)
mailto:majop...@redhat.com wrote:
Hmm, this crashes in the fedora nightly build during pcbnew
startup,
I need
to investigate why.
https://github.com/KiCad/kicad-source-mirror/commit/69553d6fa31a60a4694395f0dcadfdbd787c21a8#diff-cdb8e872a96e63280c27292a5845cfbeR147
snprintf( cmd, 1023, import wxversion; wxversion.select('%s'),
WXPYTHON_VERSION );
PyRun_SimpleString( cmd );
Probably a missing
PyLock lock;
Also, we don't need to use snprintf here, we can simply use:
const char* cmd = import wxversion; wxversion.select('
WXPYTHON_VERSION ');
instead.
Sorry I don't have time to investigate the crash right now. Good
Luck.
Best Regards,
Brian.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
(mailto:kicad-developers@lists.launchpad.net)
mailto:kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] wxPython version check
KICAD_SCRIPTING_WXPYTHON:BOOL=ON
and
WXPYTHON_VERSION_FOUND:STRING=3.0
I wonder what’s wrong with my “wxversion” thing… the exact error is:
[ajo@kicad kicad-5430]$ pcbnew
Traceback (most recent call last):
File string, line 1, in module
File /usr/lib64/python2.7/site-packages/wxversion.py, line 149, in select
bestMatch = _get_best_match(installed, versions, optionsRequired)
File /usr/lib64/python2.7/site-packages/wxversion.py, line 273, in
_get_best_match
score = pkg.Score(_wxPackageInfo(ver), optionsRequired)
File /usr/lib64/python2.7/site-packages/wxversion.py, line 357, in __init__
self.version = tuple([int(x) for x in segments[0].split('.')])
ValueError: invalid literal for int() with base 10: ''
ImportError: No module named wx._core_
If I do this in console, it seems to work
import wxversion
wxversion.select('3.0')
I will try to check what’s really getting through WXPYTHON_VERSION, or why is
it failing
in my system when inside pcbnew.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 23:38, Miguel Ángel Ajo wrote:
Hi Wayne,
I don’t have direct access to the CmakeCache (due that I’m relying on copr
for my builds),
but I could try to replicate locally, btw, this is from the build logs:
-- Found wxWidgets:
-pthread;;;-lwx_gtk2u_gl-3.0;-lwx_gtk2u_aui-3.0;-lwx_gtk2u_adv-3.0;-lwx_gtk2u_html-3.0;-lwx_gtk2u_core-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_stc-3.0
(found suitable version 3.0.2, minimum required is 3.0.0)
and I set KICAD_SCRIPTING_WXPYTHON on cmake:
https://copr-be.cloud.fedoraproject.org/results/mangelajo/kicad/fedora-21-x86_64/kicad-5429-nightlies.fc22/build.log.gz
I’m going to debug a bit to see what’s happening, and read the thread about
the wxPython changes that
I didn’t have time to read in full.
Best reagards,
Miguel Ángel.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 18:05, Wayne Stambaugh wrote:
Miguel,
What is the output of:
grep WXPYTHON kicad_build_path/CMakeCache.txt
You should see something like this:
KICAD_SCRIPTING_WXPYTHON:BOOL=ON
WXPYTHON_VERSION_FOUND:STRING=3.0
If WXPYTHON_VERSON_FOUND is empty, run `make rebuild_cache`.
Cheers,
Wayne
On 2/18/2015 10:44 AM, Miguel Ángel Ajo wrote:
It looks like something related to the python paths not
being able to find wx._core_.
I’ll put some time tonight on it.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 16:33, Brian Sidebotham wrote:
On 18 February 2015 at 14:26, Miguel Ángel Ajo majop...@redhat.com
(mailto:majop...@redhat.com)
mailto:majop...@redhat.com wrote:
Hmm, this crashes in the fedora nightly build during pcbnew startup,
I need
to investigate why.
https://github.com/KiCad/kicad-source-mirror/commit/69553d6fa31a60a4694395f0dcadfdbd787c21a8#diff-cdb8e872a96e63280c27292a5845cfbeR147
snprintf( cmd, 1023, import wxversion; wxversion.select('%s'),
WXPYTHON_VERSION );
PyRun_SimpleString( cmd );
Probably a missing
PyLock lock;
Also, we don't need to use snprintf here, we can simply use:
const char* cmd = import wxversion; wxversion.select('
WXPYTHON_VERSION ');
instead.
Sorry I don't have time to investigate the crash right now. Good Luck.
Best Regards,
Brian.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
(mailto:kicad-developers@lists.launchpad.net)
mailto:kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
(mailto:kicad-developers@lists.launchpad.net)
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
(mailto:kicad-developers@lists.launchpad.net)
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] wxPython version check
What was the problem with download_boost?, PPA builds didn’t allow network
connections?
Miguel Ángel Ajo
On Thursday, 19 de February de 2015 at 01:30, Adam Wolf wrote:
Years ago, when I maintained an Ubuntu PPA pre - download_boost, I had to do
cmake rebuild_cache on every build, but I didn't have to on my PC. Never
tracked that down before download_boost made that methodology impossible.
Adam Wolf
On Feb 18, 2015 6:27 PM, Miguel Ángel Ajo majop...@redhat.com
(mailto:majop...@redhat.com) wrote:
Just a note:
I’m running cmake from an *empty* build dir:
mkdir build
cd build
cmake -D… -D… ..
and I get into the problem, which goes away with the make rebuild_cache.
Miguel Ángel Ajo
On Thursday, 19 de February de 2015 at 01:24, Miguel Ángel Ajo wrote:
Exactly, if I runs make rebuild_cache, or if I simply rerun cmake twice
(no
need to delete config.h) the #define WXPYTHON_VERSION turns from “” to
“3.0”.
When is cmake supposed to generate config.h exactly?
Miguel Ángel Ajo
On Thursday, 19 de February de 2015 at 01:21, Wayne Stambaugh wrote:
They should match so that's the problem. I have the same problem when I
build from an existing build. It appears that config.h is not getting
rebuilt. Try running `make rebuild_cache` or deleting config.h and see
if CMake sets the WXPYTON_VERSION string to 3.0 which is what is found
during the configuration.
On 2/18/2015 6:41 PM, Miguel Ángel Ajo wrote:
Hmm, it seems that in my system it’s getting an empty string ‘’,
where does WXPYTHON_VERSION come from?
/// The wxPython version found during configuration.
#if defined( KICAD_SCRIPTING_WXPYTHON )
#define WXPYTHON_VERSION
#endif
Shouldn’t that match WXPYTHON_VERSION_FOUND from CMakeCache.txt ?
Miguel Ángel Ajo
On Thursday, 19 de February de 2015 at 00:35, Miguel Ángel Ajo wrote:
KICAD_SCRIPTING_WXPYTHON:BOOL=ON
and
WXPYTHON_VERSION_FOUND:STRING=3.0
I wonder what’s wrong with my “wxversion” thing… the exact error is:
[ajo@kicad kicad-5430]$ pcbnew
Traceback (most recent call last):
File string, line 1, in module
File /usr/lib64/python2.7/site-packages/wxversion.py, line 149, in
select
bestMatch = _get_best_match(installed, versions, optionsRequired)
File /usr/lib64/python2.7/site-packages/wxversion.py, line 273, in
_get_best_match
score = pkg.Score(_wxPackageInfo(ver), optionsRequired)
File /usr/lib64/python2.7/site-packages/wxversion.py, line 357, in
__init__
self.version = tuple([int(x) for x in segments[0].split('.')])
ValueError: invalid literal for int() with base 10: ''
ImportError: No module named wx._core_
If I do this in console, it seems to work
import wxversion
wxversion.select('3.0')
I will try to check what’s really getting through WXPYTHON_VERSION,
or why is it failing
in my system when inside pcbnew.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 23:38, Miguel Ángel Ajo
wrote:
Hi Wayne,
I don’t have direct access to the CmakeCache (due that I’m
relying on
copr for my builds),
but I could try to replicate locally, btw, this is from the build
logs:
-- Found wxWidgets:
-pthread;;;-lwx_gtk2u_gl-3.0;-lwx_gtk2u_aui-3.0;-lwx_gtk2u_adv-3.0;-lwx_gtk2u_html-3.0;-lwx_gtk2u_core-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_stc-3.0
(found suitable version 3.0.2, minimum required is 3.0.0)
and I set KICAD_SCRIPTING_WXPYTHON on cmake:
https://copr-be.cloud.fedoraproject.org/results/mangelajo/kicad/fedora-21-x86_64/kicad-5429-nightlies.fc22/build.log.gz
I’m going to debug a bit to see what’s happening, and read the
thread
about the wxPython changes that
I didn’t have time to read in full.
Best reagards,
Miguel Ángel.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 18:05, Wayne Stambaugh
wrote:
Miguel,
What is the output of:
grep WXPYTHON kicad_build_path/CMakeCache.txt
You should see something like this:
KICAD_SCRIPTING_WXPYTHON:BOOL=ON
WXPYTHON_VERSION_FOUND:STRING=3.0
If WXPYTHON_VERSON_FOUND is empty, run `make rebuild_cache`.
Cheers,
Wayne
On 2/18/2015 10:44 AM, Miguel Ángel Ajo wrote:
It looks like something related to the python paths not
being able to find wx._core_
Re: [Kicad-developers] wxPython version check
Exactly, if I runs make rebuild_cache, or if I simply rerun cmake twice (no
need to delete config.h) the #define WXPYTHON_VERSION turns from “” to “3.0”.
When is cmake supposed to generate config.h exactly?
Miguel Ángel Ajo
On Thursday, 19 de February de 2015 at 01:21, Wayne Stambaugh wrote:
They should match so that's the problem. I have the same problem when I
build from an existing build. It appears that config.h is not getting
rebuilt. Try running `make rebuild_cache` or deleting config.h and see
if CMake sets the WXPYTON_VERSION string to 3.0 which is what is found
during the configuration.
On 2/18/2015 6:41 PM, Miguel Ángel Ajo wrote:
Hmm, it seems that in my system it’s getting an empty string ‘’,
where does WXPYTHON_VERSION come from?
/// The wxPython version found during configuration.
#if defined( KICAD_SCRIPTING_WXPYTHON )
#define WXPYTHON_VERSION
#endif
Shouldn’t that match WXPYTHON_VERSION_FOUND from CMakeCache.txt ?
Miguel Ángel Ajo
On Thursday, 19 de February de 2015 at 00:35, Miguel Ángel Ajo wrote:
KICAD_SCRIPTING_WXPYTHON:BOOL=ON
and
WXPYTHON_VERSION_FOUND:STRING=3.0
I wonder what’s wrong with my “wxversion” thing… the exact error is:
[ajo@kicad kicad-5430]$ pcbnew
Traceback (most recent call last):
File string, line 1, in module
File /usr/lib64/python2.7/site-packages/wxversion.py, line 149, in
select
bestMatch = _get_best_match(installed, versions, optionsRequired)
File /usr/lib64/python2.7/site-packages/wxversion.py, line 273, in
_get_best_match
score = pkg.Score(_wxPackageInfo(ver), optionsRequired)
File /usr/lib64/python2.7/site-packages/wxversion.py, line 357, in
__init__
self.version = tuple([int(x) for x in segments[0].split('.')])
ValueError: invalid literal for int() with base 10: ''
ImportError: No module named wx._core_
If I do this in console, it seems to work
import wxversion
wxversion.select('3.0')
I will try to check what’s really getting through WXPYTHON_VERSION,
or why is it failing
in my system when inside pcbnew.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 23:38, Miguel Ángel Ajo wrote:
Hi Wayne,
I don’t have direct access to the CmakeCache (due that I’m relying on
copr for my builds),
but I could try to replicate locally, btw, this is from the build logs:
-- Found wxWidgets:
-pthread;;;-lwx_gtk2u_gl-3.0;-lwx_gtk2u_aui-3.0;-lwx_gtk2u_adv-3.0;-lwx_gtk2u_html-3.0;-lwx_gtk2u_core-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_stc-3.0
(found suitable version 3.0.2, minimum required is 3.0.0)
and I set KICAD_SCRIPTING_WXPYTHON on cmake:
https://copr-be.cloud.fedoraproject.org/results/mangelajo/kicad/fedora-21-x86_64/kicad-5429-nightlies.fc22/build.log.gz
I’m going to debug a bit to see what’s happening, and read the thread
about the wxPython changes that
I didn’t have time to read in full.
Best reagards,
Miguel Ángel.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 18:05, Wayne Stambaugh wrote:
Miguel,
What is the output of:
grep WXPYTHON kicad_build_path/CMakeCache.txt
You should see something like this:
KICAD_SCRIPTING_WXPYTHON:BOOL=ON
WXPYTHON_VERSION_FOUND:STRING=3.0
If WXPYTHON_VERSON_FOUND is empty, run `make rebuild_cache`.
Cheers,
Wayne
On 2/18/2015 10:44 AM, Miguel Ángel Ajo wrote:
It looks like something related to the python paths not
being able to find wx._core_.
I’ll put some time tonight on it.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 16:33, Brian Sidebotham
wrote:
On 18 February 2015 at 14:26, Miguel Ángel Ajo
majop...@redhat.com mailto:majop...@redhat.com
mailto:majop...@redhat.com wrote:
Hmm, this crashes in the fedora nightly build during pcbnew
startup,
I need
to investigate why.
https://github.com/KiCad/kicad-source-mirror/commit/69553d6fa31a60a4694395f0dcadfdbd787c21a8#diff-cdb8e872a96e63280c27292a5845cfbeR147
snprintf( cmd, 1023, import wxversion; wxversion.select('%s'),
WXPYTHON_VERSION );
PyRun_SimpleString( cmd );
Probably a missing
PyLock lock;
Also, we don't need to use snprintf here, we can simply use:
const char* cmd = import wxversion; wxversion.select('
WXPYTHON_VERSION ');
instead.
Sorry I don't have time to investigate the crash right now. Good
Luck.
Best Regards,
Brian
Re: [Kicad-developers] wxPython version check
Just a note:
I’m running cmake from an *empty* build dir:
mkdir build
cd build
cmake -D… -D… ..
and I get into the problem, which goes away with the make rebuild_cache.
Miguel Ángel Ajo
On Thursday, 19 de February de 2015 at 01:24, Miguel Ángel Ajo wrote:
Exactly, if I runs make rebuild_cache, or if I simply rerun cmake twice (no
need to delete config.h) the #define WXPYTHON_VERSION turns from “” to “3.0”.
When is cmake supposed to generate config.h exactly?
Miguel Ángel Ajo
On Thursday, 19 de February de 2015 at 01:21, Wayne Stambaugh wrote:
They should match so that's the problem. I have the same problem when I
build from an existing build. It appears that config.h is not getting
rebuilt. Try running `make rebuild_cache` or deleting config.h and see
if CMake sets the WXPYTON_VERSION string to 3.0 which is what is found
during the configuration.
On 2/18/2015 6:41 PM, Miguel Ángel Ajo wrote:
Hmm, it seems that in my system it’s getting an empty string ‘’,
where does WXPYTHON_VERSION come from?
/// The wxPython version found during configuration.
#if defined( KICAD_SCRIPTING_WXPYTHON )
#define WXPYTHON_VERSION
#endif
Shouldn’t that match WXPYTHON_VERSION_FOUND from CMakeCache.txt ?
Miguel Ángel Ajo
On Thursday, 19 de February de 2015 at 00:35, Miguel Ángel Ajo wrote:
KICAD_SCRIPTING_WXPYTHON:BOOL=ON
and
WXPYTHON_VERSION_FOUND:STRING=3.0
I wonder what’s wrong with my “wxversion” thing… the exact error is:
[ajo@kicad kicad-5430]$ pcbnew
Traceback (most recent call last):
File string, line 1, in module
File /usr/lib64/python2.7/site-packages/wxversion.py, line 149, in
select
bestMatch = _get_best_match(installed, versions, optionsRequired)
File /usr/lib64/python2.7/site-packages/wxversion.py, line 273, in
_get_best_match
score = pkg.Score(_wxPackageInfo(ver), optionsRequired)
File /usr/lib64/python2.7/site-packages/wxversion.py, line 357, in
__init__
self.version = tuple([int(x) for x in segments[0].split('.')])
ValueError: invalid literal for int() with base 10: ''
ImportError: No module named wx._core_
If I do this in console, it seems to work
import wxversion
wxversion.select('3.0')
I will try to check what’s really getting through WXPYTHON_VERSION,
or why is it failing
in my system when inside pcbnew.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 23:38, Miguel Ángel Ajo wrote:
Hi Wayne,
I don’t have direct access to the CmakeCache (due that I’m relying on
copr for my builds),
but I could try to replicate locally, btw, this is from the build
logs:
-- Found wxWidgets:
-pthread;;;-lwx_gtk2u_gl-3.0;-lwx_gtk2u_aui-3.0;-lwx_gtk2u_adv-3.0;-lwx_gtk2u_html-3.0;-lwx_gtk2u_core-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_stc-3.0
(found suitable version 3.0.2, minimum required is 3.0.0)
and I set KICAD_SCRIPTING_WXPYTHON on cmake:
https://copr-be.cloud.fedoraproject.org/results/mangelajo/kicad/fedora-21-x86_64/kicad-5429-nightlies.fc22/build.log.gz
I’m going to debug a bit to see what’s happening, and read the thread
about the wxPython changes that
I didn’t have time to read in full.
Best reagards,
Miguel Ángel.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 18:05, Wayne Stambaugh wrote:
Miguel,
What is the output of:
grep WXPYTHON kicad_build_path/CMakeCache.txt
You should see something like this:
KICAD_SCRIPTING_WXPYTHON:BOOL=ON
WXPYTHON_VERSION_FOUND:STRING=3.0
If WXPYTHON_VERSON_FOUND is empty, run `make rebuild_cache`.
Cheers,
Wayne
On 2/18/2015 10:44 AM, Miguel Ángel Ajo wrote:
It looks like something related to the python paths not
being able to find wx._core_.
I’ll put some time tonight on it.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 16:33, Brian Sidebotham
wrote:
On 18 February 2015 at 14:26, Miguel Ángel Ajo
majop...@redhat.com (mailto:majop...@redhat.com)
mailto:majop...@redhat.com
mailto:majop...@redhat.com wrote:
Hmm, this crashes in the fedora nightly build during pcbnew
startup,
I need
to investigate why.
https://github.com/KiCad/kicad-source-mirror/commit/69553d6fa31a60a4694395f0dcadfdbd787c21a8#diff-cdb8e872a96e63280c27292a5845cfbeR147
snprintf( cmd, 1023, import wxversion;
wxversion.select('%s'),
WXPYTHON_VERSION
Re: [Kicad-developers] KiCad in the (CERN) news
Awesome!! :-) Miguel Ángel Ajo On Tuesday, 17 de February de 2015 at 14:50, Javier Serrano wrote: Dear all, I thought some of you might be interested in this recent piece by one of our colleagues in the Communications group: http://home.web.cern.ch/about/updates/2015/02/kicad-software-gets-cern-treatment Cheers, Javier ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Coverity scan.
This is very nice!!! I requested access :) Miguel Ángel Ajo On Monday, 16 de February de 2015 at 13:33, Nick Østergaard wrote: There is a button in there to ask for access. FYI. Den 16/02/2015 13.15 skrev Brian Sidebotham brian.sidebot...@gmail.com (mailto:brian.sidebot...@gmail.com): On 15 February 2015 at 20:11, Wayne Stambaugh stambau...@gmail.com (mailto:stambau...@gmail.com) wrote: Mark Roszko was kind enough to set up a Coverity scan for KiCad at https://scan.coverity.com/projects/3606?tab=analysis_settings. Thank you Mark. I would at least like my lead developers to sign up and have Mark give you access to see the scan results. If you see a high severity issue that is in your code, please make sure it's not a false positive and tag it as such or fix it if the issue is legitemate. At the very least, we should shoot for no high severity issues. Obviously, zero issues of any severity should be the goal but we have to start somewhere. On the whole, the KiCad error rate is not as bad as I thought it might be. We are currently at 1.52 per 1000 lines of code. The average for open source projects larger than 1M lines of code is 0.65. Let's see if we can do better than average. Cheers, Wayne Thanks for setting this up Mark, Can you give me access? I signed up with my GitHub account, so username should be BrianSidebotham or brian.sidebotham[at]gmail,com Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Fedora 21 nightlies build
Btw, Wayne, thank you for pointing me out that probably wxWidgets+gtk3 was the problem :-) If you have some time to provide me with more information I will try to file bugs where necessary to get that fixed. Miguel Ángel Ajo On Saturday, 14 de February de 2015 at 23:18, Miguel Ángel Ajo wrote: Fedora 21 nightlies build is fully working now (no more canvas problems), I had to recompile wxGTK3 with ‘gtk2’ and wxPython with that build, then kicad on top. If you had the repo configured previously, do a: dnf clean all dnf remove wxGTK3 wxPython kicad dnf install kicad Otherwise follow the instructions at: https://copr.fedoraproject.org/coprs/mangelajo/kicad/ To override other wxGTK3 or wxPython versions, I have bumped the revisions of those with +1000, but that’s a bit hacky, and may break when fedora releases new wxGTK3 versions, I will look into a definitive solution as soon as I can, but that may work for now. Please, let me know how if it works/doesn’t work for you. Eventually I will set a builder for the stable version too. Best regards, Miguel Ángel Ajo On Thursday, 15 de January de 2015 at 11:25, Miguel Ángel Ajo wrote: I wanted to announce that I have created this repository with nightly builds for KiCad: https://copr.fedoraproject.org/coprs/mangelajo/kicad/ http://ci.kicad-pcb.org/job/fedora-nightlies/ It has wxPython and python scripting enabled, and it’s based on wxWidgets 3.0.0, as kicad is now. For now you will find it’s a bit broken, as the wxGTK3 canvas is not working correctly (having the same issue if I don’t link to wxPython3 and do it to the fedora stock wxGTK3), that means eeschema is quite unusable, pcbnew only works correctly on the OpenGL or Cairo Canvas. By the way, even broken I believe it’s a good opportunity for anyone willing to have a look on the latest release. Miguel Ángel Ajo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://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] Fedora 21 nightlies build
Sorry, it seems that we were writing at the same exact moment. If you could point me to where we setup the canvas, and use it to draw, I would try to write a simple reproducer, may be this way we can get the gtk3 version working in the long term :) Best regards, Miguel Ángel Miguel Ángel Ajo On Sunday, 15 de February de 2015 at 00:58, Miguel Ángel Ajo wrote: Btw, Wayne, thank you for pointing me out that probably wxWidgets+gtk3 was the problem :-) If you have some time to provide me with more information I will try to file bugs where necessary to get that fixed. Miguel Ángel Ajo On Saturday, 14 de February de 2015 at 23:18, Miguel Ángel Ajo wrote: Fedora 21 nightlies build is fully working now (no more canvas problems), I had to recompile wxGTK3 with ‘gtk2’ and wxPython with that build, then kicad on top. If you had the repo configured previously, do a: dnf clean all dnf remove wxGTK3 wxPython kicad dnf install kicad Otherwise follow the instructions at: https://copr.fedoraproject.org/coprs/mangelajo/kicad/ To override other wxGTK3 or wxPython versions, I have bumped the revisions of those with +1000, but that’s a bit hacky, and may break when fedora releases new wxGTK3 versions, I will look into a definitive solution as soon as I can, but that may work for now. Please, let me know how if it works/doesn’t work for you. Eventually I will set a builder for the stable version too. Best regards, Miguel Ángel Ajo On Thursday, 15 de January de 2015 at 11:25, Miguel Ángel Ajo wrote: I wanted to announce that I have created this repository with nightly builds for KiCad: https://copr.fedoraproject.org/coprs/mangelajo/kicad/ http://ci.kicad-pcb.org/job/fedora-nightlies/ It has wxPython and python scripting enabled, and it’s based on wxWidgets 3.0.0, as kicad is now. For now you will find it’s a bit broken, as the wxGTK3 canvas is not working correctly (having the same issue if I don’t link to wxPython3 and do it to the fedora stock wxGTK3), that means eeschema is quite unusable, pcbnew only works correctly on the OpenGL or Cairo Canvas. By the way, even broken I believe it’s a good opportunity for anyone willing to have a look on the latest release. Miguel Ángel Ajo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
Sorry, I believe I understood wrong previous Nick suggestion about hosting stuff at the current kicad servers. I’m all for doing CI, and rendering the documentation out to: http://doc.kicad-pcb.org or the chosen subdomain. If that was the suggestion, that’s only static file serving, which is cheap and with 0 maintenance. If the suggestion was “let’s install something like github” to do SCM collaboration, that’s another beast (installs, upgrades, fighting spammers…). Best regards, Miguel Ángel. On Wednesday, 4 de February de 2015 at 21:12, Bob Gustafson wrote: On 02/04/2015 10:13 AM, Nick Østergaard wrote: I'll put a CMake build system in place on the documentation and make sure it works on Windows + Linux. OSX guys will have to help me in making sure it works there. It shouldn't be a problem though. What does this cmake include? Does it reside in the kicad-doc repo or in the kicad repo? On OSX, I am shooting for a directory structure like so: KiCad Common Help Doc Libraries Legacy Fp.. ProjectNumber1 ProjectNumber1.pro ProjectNumber1.cmp ProjectNumber1.pcb . ProjectNumber2 ProjectNumber2.pro ProjectNumber2.cmp ProjectNumber2.pcb . ProjectNumber3 ProjectNumber3.pro ProjectNumber3.cmp ProjectNumber3.pcb . But whatever - but so far the Help and Docs are not hooked up to my GUI Best Regards Bob G ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] documentation format
https://github.com/Fat-Zer/kicad-doc/tree/cmake It’s in a separate branch :-) Miguel Ángel Ajo On Thursday, 5 de February de 2015 at 11:53, Brian Sidebotham wrote: On 5 February 2015 at 10:03, Fat-Zer fatz...@gmail.com (mailto:fatz...@gmail.com) wrote: 2015-02-04 19:52 GMT+03:00 Wayne Stambaugh stambau...@gmail.com (mailto:stambau...@gmail.com): CMake should be used as the build configuration tool which is used to verify all of the required tools are installed on the system and automatically generate the appropriate Makefiles. CMake files would go in the kicad-doc repo and replace the current Makefiles. It would be nice if everything was in one place. That may be a goal for the distant future. For now, we have more important issues to worry about. Hi, I've done some cmake macro scripting for building asciidoc based on Marco's repository some time ago: https://github.com/Fat-Zer/kicad-doc It's ready to use for generate output in several formats like docbook, pdf, html and other. But, by the word, it doesn't check some special additional dependencies for specific formats... may be I'll add a test if specified format may be build in future... I've gonna to report it after I'll add some macro to update the *.po files but have not finished it yet... Hi Fat-Zer, I cannot see any CMakeLists.txt in that repo, am I missing something? Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Update on OpenGL performance on Intel GPUs
Nice, it’s good to know that the 300EUR cpu range runs OpenGL nice for our needs. That means we’re not adding a huge entry barrier with the OpenGL implementation. Miguel Ángel Ajo On Thursday, 5 de February de 2015 at 11:10, Lorenzo Marcantonio wrote: Well, I got rich (more or less) and plundered the store for a 300 EUR laptop for the office. CPU power is slightly better but the GPU is not a 'classic' i915 but an HD one. Performance on the opengl view is *wy* better; this time opengl is better than xlib drawing. (the reason is that in the HD GPUs shaders are run on the GPU, not in the mesa library :D) So I'd say that Intel's GPUs are now adequate, if you have at least an HD one. -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Update on OpenGL performance on Intel GPUs
Where I said CPU, I was meaning Laptop… I must proofread before I click the “Send” button. Miguel Ángel Ajo On Thursday, 5 de February de 2015 at 11:49, Miguel Ángel Ajo wrote: Nice, it’s good to know that the 300EUR cpu range runs OpenGL nice for our needs. That means we’re not adding a huge entry barrier with the OpenGL implementation. Miguel Ángel Ajo On Thursday, 5 de February de 2015 at 11:10, Lorenzo Marcantonio wrote: Well, I got rich (more or less) and plundered the store for a 300 EUR laptop for the office. CPU power is slightly better but the GPU is not a 'classic' i915 but an HD one. Performance on the opengl view is *wy* better; this time opengl is better than xlib drawing. (the reason is that in the HD GPUs shaders are run on the GPU, not in the mesa library :D) So I'd say that Intel's GPUs are now adequate, if you have at least an HD one. -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://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] documentation format
On Wednesday, 4 de February de 2015 at 17:52, Wayne Stambaugh wrote: On 2/4/2015 11:13 AM, Nick Østergaard wrote: 2015-02-04 15:06 GMT+01:00 Wayne Stambaugh stambau...@gmail.com (mailto:stambau...@gmail.com): On 2/4/2015 7:10 AM, Brian Sidebotham wrote: On 4 February 2015 at 00:14, Wayne Stambaugh stambau...@gmail.com (mailto:stambau...@gmail.com) wrote: We need to make a decision soon if we want to get the documentation conversion completed in time for the next stable release. I'm still not sure we can build on Windows. Neither the MSYS2 asciidoc or sphinx implementations worked correctly the last time I tried them and I have no way to test any of this on OSX. Cygwin may work but the last time I tried to build kicad on cygwin, it was more trouble than it was worth. This would limit us to building the documentation only on linux which I'm not terribly thrilled about. This means if you wanted to build a windows installer you would have to run linux in a VM to build the documentation. That would be painful for our auto builders folks. If we get much further along, we may just have to live with the documentation we have now and convert to a plain text format for the next release. I think we're pretty much decided already on asciidoc - it just takes someone to say so. I've included Marco on this email so perhaps he could give us his up-to-date conclusion and we can make the decision now. As for being able to build, well, we need to decide on an output format. I think we've previously been hinting at html rather than PDF. We don't need to support a million output formats. PDF is much harder to support compared to HTML for example. I think HTML and PDF is what is required, I guess some people would like epub, but that is basically not much different to HTML in structure, hence I think that should look equally fine in HTML as in epub. However, nothing requires a POSIX shell, so we definitely don't need to add-in cygwin, MSYS2 or anything else as a dependency for building docs. asciidoc works okay for me under windows, but a2x for PDF conversion doesn't work. However, projects like asciidoctor-fopub and asciidoctor-pdf are well underway to sort that problem out. I'll put a CMake build system in place on the documentation and make sure it works on Windows + Linux. OSX guys will have to help me in making sure it works there. It shouldn't be a problem though. What does this cmake include? Does it reside in the kicad-doc repo or in the kicad repo? CMake should be used as the build configuration tool which is used to verify all of the required tools are installed on the system and automatically generate the appropriate Makefiles. CMake files would go in the kicad-doc repo and replace the current Makefiles. So decide input and output formats and we can start implementing the CMake build system on the Github repo. Best Regards, Brian. Brian, Thank you for stepping up to write the CMake build system. This is what I was looking for. I didn't want to start down that path without the resources in place to get the work done. I would like to hear from the auto builder folks to see what impact it will have on what they are doing. I'll give asciidoc my official blessing (it seems funny to me saying that) so we can get moving on it. The following tasks will need to be completed before the stable release: - Set up repo on some git hosting sight. I heard some negative feedback at FOSDEM about using github since apparently it is not free software so I'm open to suggestion on this. If github is the best choice then I'm OK using it but it might be worth exploring other git based hosting alternatives. Ohh well, it is just a git repo, where exactly it is located does not really matter IMHO. What matters is that pull requests are easy to perform, but I think it is no fault to put it on github for the forseeable future at least. We have the official libs there anyway, please don't do any unnessesary fragmentation of the project. By saying this, I don't want to close the discussion of alternative places. One is hosting it together with kicad-pcb.org (http://kicad-pcb.org) if ajo want to support and help maintain that. Sorry, I missed that part, I really believe externally provided solutions are going to be more reliable and work better. I prefer to spend my very little time in doing things for KiCad than handling software upgrades, backups, etc... Lately, the website has proven to be more reliable, partly it was unreliable because of the huge amount of traffic we have, and that confluence eats a lot of RAM (thanks java..), but it’s
Re: [Kicad-developers] 3D model code for merging
On Wednesday, 4 de February de 2015 at 21:27, Cirilo Bernardo wrote: On Wed, Feb 4, 2015 at 8:39 PM, Miguel Ángel Ajo majop...@redhat.com (mailto:majop...@redhat.com) wrote: Hi Cirilo, awesome work. Don’t want to delay the merge, that’s something on what we could work afterwards, but, are you aware of the higher lever scripting layer we started working on from Piers proposal? [1] I’m trying to splice his work into modules to have a very coherent and well documented python API for KiCad at user level. The idea is to keep the modules as: kicad kicad.pcbnew kicad.eeschema (when we get into such thing..) kicad.gerber may be we could expose your 3D API from kicad.vrml ? We adopted the naming convention of xxx_xxx_xxx for function names, and X for classes, and we are building a higher level python API over the C++ bare implementation, and we don’t plan to break that one to avoid breaking off anybody’s already existing scripts. We could do the same on top of your 3D api, or we could go and do a follow up patch to normalize all function names. (I see you tight controlled how python naming is exposed based on the C++ API), probably the 1st option is going to be the most flexible. If necessary everything can be exposed from kicad.vrml; my only concern here is if many more C++ modules are added then kicad.vrml might become too big. Otherwise changing the library is not a very big job at the moment and since there aren't very many scripts it shouldn't be a big job to update the scripts to use the newer library name. That can be split them in submodules kicad.vrml.xxx kicad.vrml.yyy Think about a logical way to provide them. It’s common also to unify all you want to provide from a module from split modules like this: https://github.com/KiCad/kicad-python/blob/master/kicad/__init__.py Or importing specific stuff. You can also leave the C++ modules as you want, and then we can create simple endpoints in kicad.vrml the same way, I believe that would make it easier, because otherwise the modules could be conflicting at install time. I would be more concerned about providing an unified way of naming methods, do you find reasonable to export them to python with the pep8 naming convention? https://www.python.org/dev/peps/pep-0008/#method-names-and-instance-variables The intention is that [1] is very well documented for all users, and merged back to the kicad code base (when mature enough) so it’s widely available to everybody, and so we can fix any breaking changes on the C++ API by updating the python layer. I would also be very happy about making python-scripting a 1st class citizen by getting [1] merged and, getting all the stable builds with Python, so this is widely available to everybody in the next release. But I want to start a discussion about that. One question: Is it currently possible (from python), to build a 3D model, and attach it to a module right away?, that would be amazing from the footprint wizard perspective. (I didn’t have enough time to fully dig into your code). Models can be built from Python and if the kicad scripting interface allows you to add 3D models then the generated file can be immediately attached to the module. The scripting interface should let you do whatever the c++ module class let’s you do (the positive side of swig, the downside is not having too much control over the naming of your functions if you do it all automatically) The only issue I see here is how do you define model parameters and names from within the PCB script in a useful way. We already have that, http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/pcbnew/scripting/plugins/bga_wizard.py http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/files/head:/pcbnew/scripting/plugins/ The C++ UI talks to the python plugins (which get registered at pcbnew boot), and finds what to ask the user, then when the user changes a parameter, the parameter list is propagated back to the plugin, and the footprint is rebuilt inside python. Within such plugins we could build a 3D model and attach it to the footprint. http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/pcbnew/scripting/plugins/bga_wizard.py#L64 Please, ignore that those parts of the code are based on the C++ naming convention, instead of the “pythonic” one :/ The current workflow is to create a parametric model such as a tubular leaded diode model (which is currently in C++ but could equally be a python module) and to use the python interface to create multiple configurations of the component class through a script like do41.py. To create models from within a PCB script you would need
Re: [Kicad-developers] FOSDEM plans
Sounds good to me!, Sign me up! ;) Miguel Ángel Ajo On Thursday, 29 de January de 2015 at 14:42, Javier Serrano wrote: What about a KiCad dinner on Saturday? Those who would like to join, let me know off-list so I can book a table somewhere. Also, mobile phone numbers for some of the CERN folks can be found in our public phone book [1]. Cheers, Javier [1] https://phonebook.cern.ch ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] FOSDEM plans
Hi, sorry to update too late the topic. I will be earlier finally (8:30 AM), but I need to go to the Centos Dojo to join my colleagues on presenting the openstack RDO distribution. I can’t give many indications about how to move around Brussels, I’ve only been once before, and I remember the center was beautiful, an the beer was good, but not much more. I believe from 3-5pm I will have finished and I will be available to join, dinner sounds great if I’m on time, any place is ok for me. :) Best regards, and see you next Friday. Miguel Ángel Ajo On Sunday, 25 de January de 2015 at 19:50, Wayne Stambaugh wrote: I'll be checking WhatsApp and my email whenever I can. I get there around 7AM so I'll be wandering around Brussels all day. Ping me when you get settled in. I'm up for a beer Friday night. If you get in early enough, we could try to get a group together for dinner. I've never been to Brussels so any help with info on good places to eat would be greatly appreciated. On 1/24/2015 6:20 PM, Kaspar Emanuel wrote: I'll be arriving on Friday at around 5 pm and staying near the University in a small apartment found through AirBnB. Should be up for a beer Friday night. I've installed Whatsapp and added Wayne and Miguel. My number is +44 7543 520224. Maybe send me a message when you add me to see if it works ok. See you in Brussels! Kaspar On 12 January 2015 at 19:54, Wayne Stambaugh stambau...@gmail.com (mailto:stambau...@gmail.com) mailto:stambau...@gmail.com wrote: Miguel, Look me up when you arrive Friday. My flight arrives early Friday morning so I should already be checked into hotel by the time your flight arrives. The best way to get in touch is either WhatsApp or email at stambau...@gmail.com mailto:stambau...@gmail.com. My phone number is 1-757-880-5981. I've never been to Brussels so I could use a tour guide if you know your way around. Looking forward to seeing you at FOSDEM. At the very least we should try to get together for dinner and drinks with all the other kicad devs that can make it Friday evening. Cheers, Wayne On 1/10/2015 5:57 PM, Miguel Ángel Ajo wrote: Hi all, sorry for not replying to the thread earlier, First of all, very sorry to see that Brian will be missing, I suppose the kid makes it more difficult, I really had troubles to make it fit into my schedule, I must say my wife is sponsoring my trip by taking care of our two daughters over the weekend ‘:-). I will be arriving on Fri 14:30, and leaving on Sun 20:50. My initial idea was to join you in any of your hotels to make breakfasts less lonely, but in the end one of my workmates joined me, and we found a nice hotel not so far from the place (1.6Km): Hotel Capital. If somebody want’s to add me on whatsapp or telegram, I will be checking on wifi hotspots during friday to see if I can sync with any of you for sightseeing and/or beers ;-) , my number is +34 636 52 25 69, and it will be easier for me to check “miguelan...@ajo.es mailto:miguelan...@ajo.es” at that time. Best, Miguel Ángel Ajo On Friday, 9 de January de 2015 at 14:57, Wayne Stambaugh wrote: Hey Brian, Sorry to hear your not going to make it to FOSDEM. I hoping to meet you there. Maybe I'll find a way to make it again next year. Thanks, Wayne On 1/9/2015 6:15 AM, Brian Sidebotham wrote: Hi Guys, Sorry I've been AWOL for so long. The new year has been extremely hectic for me. I hope everyone had a good new year. I've tried to fit FOSDEM into my schedule, but it would be flying out early Saturday morning and flying back late Sunday and then back to work on Monday which is not something I can fit in right now I'm afraid. I'm so sorry not to be able to make it. I hope you all get to meet and discuss all the issues while you're over there. I'm sure the presentations will go fine, but good luck with them anyway. I've already written FOSDEM 2016 into our calendar though, so I'll definitely be there for that one. I missed last year too! :( Best Regards, Brian. On 5 January 2015 at 10:38, Maciej Sumiński maciej.sumin...@cern.ch mailto:maciej.sumin...@cern.ch mailto:maciej.sumin...@cern.ch mailto:maciej.sumin...@cern.ch wrote: Hi Miguel, There is a small group from CERN that arrives on Friday evening. We have already booked places at La Madeleine Hotel (most of us, I think). Finally we are going to meet people who have contributed so much to the project! See you there, Orson On 01/02/2015 11:57 AM, Miguel Angel wrote: Hi, I was planning over going to FOSDEM this year. Is anybody going?, if so, can I ask where will you be staying? (thinking of kicad-breakfasts ;) ), I had a look over nearby hotels/hostels and I see a few
Re: [Kicad-developers] more pythonic scripting API for pcbnew
And the version with default units: https://github.com/KiCad/kicad-python/pull/7/files Looks quite clean to me, and yet all the precision from native units is retained, plus we can do things like: p = Point((2**31-1) * nm, (-(2**31)+1) *nm) p.nm (2147483647.0, -2146483648.0) p=Point(1,2) p.inch (0.03937007874015748, 0.07874015748031496) p=Point(1*inch, 1*inch) p.inch (1.0, 1.0) p.mm (25.4, 25.4) p.nm (2540.0, 2540.0) p.rotate(90, around=(0,0)) p Point(-25.4, 25.4) Miguel Ángel Ajo On Sunday, 25 de January de 2015 at 03:03, Miguel Ángel Ajo wrote: A little experiment, with the suggested * mm / * inch notation. https://github.com/KiCad/kicad-python/pull/6/files [1] Look specially at the tests (last files). Feel free to comment over the code. If we could default to mm (my preferred) or inches, we could save a lot of code (specially to process by human brains reading python) while retaining all the precision. Best, Miguel Ángel Ajo [1] Note: 2 builds failed because I didn’t make the C++ “pcbnew” module for the tests. On Sunday, 25 de January de 2015 at 02:56, Tomasz Wlostowski wrote: On 25.01.2015 02:50, Miguel Ángel Ajo wrote: I was just testing that. Python floats (in all architectures) are double, so the 52 bit fraction (11 bit exp) is always going to hold more information that the 32bits wxPoint /wxSize can hold. Hi Miguel, Sorry, I'm a C/C++ guy, so float defaults for me to 32 bits ;) Doubles look ok, although the decimal part will be anyway truncated on the way from Python to C++ (if we decide to keep the nm as default unit) Cheers, T. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] more pythonic scripting API for pcbnew
On Saturday, 24 de January de 2015 at 20:02, LordBlick wrote: In response to a message written on 24.01.2015, 11:58, from Miguel Ángel Ajo: I hope that the current possibility to use the original „import pcbnew” will remain intact. Internal units under KiCAD as integers are the most precise form. As python script writer I don't need nothing else. I also do not want it to previous results of my few months work has become incompatible. No intention to break the C++ pcbnew module. This is partly why I put everything under the kicad.* umbrella. About IU, I believe we should provide access to IU if the user wants to use it. May be we should call the unit NM10 or something similar, so people knows what it means, and in the event the internal unit changed (very unlikely) we could still keep backwards-compatibility. Best, Migue Ángel ___ Mailing list: https://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] more pythonic scripting API for pcbnew
Hmm, I’m actually liking Tom’s suggestion, sounds quite natural to me.
pcb.create_module(ref=‘A1’, position=(10 * mm, 10 * mm))
but also accepting pcb.create_module(ref=‘B1’, position=Point(10 * mm, 10 *
mm))
I’d do the function parameter translation into Point automatically, even if I
believe parameter
input should be easy, having a class for points or sizes makes them easier to
manipulate,
for example if we wanted to rotate them:
point.rotate(2 * rad)
point.rotate(90 * deg, around=(5 * mm, 5 * mm))
or
new_point = point.rotated(90 * deg)
--
Side note, not sure why I thought IUs were 10nm, but they are 1nm (and 10nm for
gerbview, I suppose the
reason for the gerview change is being able to stack the biggest boards 10x10)
http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/include/convert_to_biu.h#L44
Miguel Ángel Ajo
On Saturday, 24 de January de 2015 at 22:37, tiger12506 wrote:
I have no weight in the discussion, but I really like Tom's suggestion here.
It allows you to use them as if they were units. 10 * mm is almost
syntactically identical to 10mm.
And they don't get in the way with a bunch of boilerplate, like some of
the other suggestions do.
~JS
On 1/24/2015 3:55 PM, Tomasz Wlostowski wrote:
On 16.01.2015 18:43, Miguel Ángel Ajo wrote:
The user shouldn’t need to know what an IU is unless he really wants, for
some
reason.
Hi Miguel,
Why make things complicated here? Given that the choice of IUs in pcbnew
is very reasonable and easy to understand, I see no reason for hiding
that knowledge from script writers. A nanometer after all, is just
one-millionth of a millimeter. No rocket science here...
On the other hand, we need to provide a sensible way of
inputting/presenting values with units. For hardcoded values, defining
units could be just multiplying by a fixed scalefactor:
from pcbnew import mm, inch, mils
#pcbnew.mm = 100
#pcbnew.inch = 2540
#pcbnew.mils = 25400
p = Point(10 * mm, 12 * mm)
Concerning UI input/output (dialogs) - recently I had to do some dialogs
for PS with lots of values in mm/inches, so to avoid repeatable unit
conversion code, I developed a class tiny called WX_UNIT_BINDER [1]. It
binds together a WX text control with an unit label:
class MyDialog : public dialog_generated_by_wxfb_base {
WX_UNIT_BINDER m_myValueInUnits;
};
MyDialog::MyDialog() :
m_myValueInUnits ( m_myValueText, m_myValueUnitLabel )
{
m_myValueInUnits.SetValue ( value_in_iu_here )
// x = m_myValueInUnits.GetValue();
}
All unit conversion is done inside the binder class, according to the
current units setting. All the user needs to do is to get/set the value
in IUs. Maybe a similar method could be used in the scripting API?
Cheers,
Tom
[1]
https://github.com/twlostow/kicad-dev/blob/tmp-crap/include/wx_unit_binder.h
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
(mailto:kicad-developers@lists.launchpad.net)
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
(mailto:kicad-developers@lists.launchpad.net)
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://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] more pythonic scripting API for pcbnew
I was just testing that.
Python floats (in all architectures) are double, so the 52 bit fraction (11
bit exp) is always
going to hold more information that the 32bits wxPoint /wxSize can hold.
So that’s not a point.
I’m experimenting with both options, to see what’s more readable.
Miguel Ángel Ajo
On Sunday, 25 de January de 2015 at 02:48, Tomasz Wlostowski wrote:
On 25.01.2015 02:04, Piers Titus van der Torren wrote:
While I understand that for internal units it's good to use integers and
hence small units, for this high level python api I don't see much benefits
for not using floats and sensible default
Dear Peter,
32-bit float is bad simply because the set of 32-bit floats is not a
superset of 32 bit integers. This means merely converting an integer
coordinate to float and back to int may loose accuracy. In case of
tightly packed primitives, one might end up with unwanted DRC errors.
As for small vs big units - units matter on the UI side, when the user
inputs some parameters for the script in a dialog window.
Inputting/outputting values with units should be therefore made as easy
as possible. Processing the data is IMHO a different story - computers
don't care if they do calculations in milli- or nanometers. So why
create yet another unit definition?
Tom
units like degrees and mm.
Keeping the internal api intact still allows for low level scripting and
using internal units. Even combined with this api, as the internal object
currently is easily available as ._module for example.
I see this api as a user interface, where internal units may be hidden just
like in the gui.
Also the * inch syntax can be used if preferred with inch = 25.4.
Piers
Op 24 jan. 2015 23:48 schreef Miguel Ángel Ajo majop...@redhat.com
(mailto:majop...@redhat.com):
Hmm, I’m actually liking Tom’s suggestion, sounds quite natural to me.
pcb.create_module(ref=‘A1’, position=(10 * mm, 10 * mm))
but also accepting pcb.create_module(ref=‘B1’, position=Point(10 * mm, 10
* mm))
I’d do the function parameter translation into Point automatically, even
if I believe parameter
input should be easy, having a class for points or sizes makes them easier
to manipulate,
for example if we wanted to rotate them:
point.rotate(2 * rad)
point.rotate(90 * deg, around=(5 * mm, 5 * mm))
or
new_point = point.rotated(90 * deg)
--
Side note, not sure why I thought IUs were 10nm, but they are 1nm (and
10nm for gerbview, I suppose the
reason for the gerview change is being able to stack the biggest boards
10x10)
http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/include/convert_to_biu.h#L44
Miguel Ángel Ajo
On Saturday, 24 de January de 2015 at 22:37, tiger12506 wrote:
I have no weight in the discussion, but I really like Tom's suggestion
here.
It allows you to use them as if they were units. 10 * mm is almost
syntactically identical to 10mm.
And they don't get in the way with a bunch of boilerplate, like some of
the other suggestions do.
~JS
On 1/24/2015 3:55 PM, Tomasz Wlostowski wrote:
On 16.01.2015 18:43, Miguel Ángel Ajo wrote:
The user shouldn’t need to know what an IU is unless he really wants, for
some
reason.
Hi Miguel,
Why make things complicated here? Given that the choice of IUs in pcbnew
is very reasonable and easy to understand, I see no reason for hiding
that knowledge from script writers. A nanometer after all, is just
one-millionth of a millimeter. No rocket science here...
On the other hand, we need to provide a sensible way of
inputting/presenting values with units. For hardcoded values, defining
units could be just multiplying by a fixed scalefactor:
from pcbnew import mm, inch, mils
#pcbnew.mm = 100
#pcbnew.inch = 2540
#pcbnew.mils = 25400
p = Point(10 * mm, 12 * mm)
Concerning UI input/output (dialogs) - recently I had to do some dialogs
for PS with lots of values in mm/inches, so to avoid repeatable unit
conversion code, I developed a class tiny called WX_UNIT_BINDER [1]. It
binds together a WX text control with an unit label:
class MyDialog : public dialog_generated_by_wxfb_base {
WX_UNIT_BINDER m_myValueInUnits;
};
MyDialog::MyDialog() :
m_myValueInUnits ( m_myValueText, m_myValueUnitLabel )
{
m_myValueInUnits.SetValue ( value_in_iu_here )
// x = m_myValueInUnits.GetValue();
}
All unit conversion is done inside the binder class, according to the
current units setting. All the user needs to do is to get/set the value
in IUs. Maybe a similar method could be used in the scripting API?
Cheers,
Tom
[1]
https://github.com/twlostow/kicad-dev/blob/tmp-crap/include
Re: [Kicad-developers] OS X Menu Icons, Boost, Symlinkery
Hi Nick, in fedora21 it seems they are enabled by default for wxGTK3 at least! (somebody is reasonable in the end!!!) Miguel Ángel Ajo On Friday, 23 de January de 2015 at 18:14, Nick Østergaard wrote: Yeah, and now GTK3 is also doing that crap of removing icons, regardless of having them or not. Pretty annoying, I can't figure out how to reenable them for GTK3 where it works. 2015-01-23 17:15 GMT+01:00 jp charras jp.char...@wanadoo.fr (mailto:jp.char...@wanadoo.fr): Le 23/01/2015 17:08, Bob Gustafson a écrit : Curious that it is turned off for Apple. Maybe bad things will happen? Not curious. The reason is few years ago, we just have a OSX fundamentalist who had write rights to the repository. Also, it is not USE_MENU_ICONS, but USE_IMAGES_IN_MENUS Thanks much Bob G -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://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] more pythonic scripting API for pcbnew
Hi Brian, I see your point, but the problem with that is interoperability, for example if we mix up modules which work with pcbnew, they could change units, and mix them all up. I have proposed on the ether pad to do something like: Point.mm(10, 10), which would, under the hood do: class Point: def __init__(x, y, unit): … @staticmethod def mm(x,y): return Point(x, y, unit=MM) how does it sound? I’m also trying to think if there is any way to handle it within a context, with Units(MM): point = Point(10,10) But I haven’t found how to push the context and make it available to Point.. Miguel Ángel Ajo On Friday, 16 de January de 2015 at 11:03, Brian Sidebotham wrote: On 15 January 2015 at 10:20, Miguel Ángel Ajo majop...@redhat.com (mailto:majop...@redhat.com) wrote: Yesterday I wrote a proposal for discussion here: http://pads.kicad-pcb.org/p/kicad-scripting-layer (please write your name for your color using the top right icon, so what you write can be identified to you). I tried not to look too much into the original Piers proposal, to do a true top-down design (“how do I like to interact with kicad objects?”) In the end, it looks quite much like Piers proposal, just with the difference of Point/Size objects receiving the unit. I was trying to be as pythonic as possible avoiding set_/get_ methods, and instead rely on attributes and implicit setters/getters. The listed options are not exclusive, just different ways of doing the same. Please feel free to write about other use cases, or copy, paste, then modify my blocks to provide different possible interactions. Best, Miguel Ángel. Miguel Ángel Ajo Hi Miguel, I thought I'd add my thoughts here instead of changing what others have done. I see that someone doesn't like the Point( 10, 10, unit=MM ) paradime for creating a 2D vector. Personally, I prefer that construct compared to the proposed point_mm( 10, 10 ) by quite a long way. But, it's of course a pain to always use unit=MM. Generally we know the units we're going to work with when we start with pcbnew scripting so it would be good to be able to do something like pcbnew.default_units = MM somewhere near the start of the script and then all 2D vectors can be created without the unit=MM additional argument, such as: Point( 10, 10 ) instead. That would make a nicer interface in my opinion. I only had a chance to have a quick look at it. Thanks for getting something together for people to look at. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] more pythonic scripting API for pcbnew
In my opinion it’s not a waste of time. A decent API will lead to more standardized scripts, and the people ability to share and look at other’s work. Cheers, Miguel Ángel. Miguel Ángel Ajo On Friday, 16 de January de 2015 at 13:24, LordBlick wrote: In response to a message written on 16.01.2015, 13:09, from Miguel Ángel Ajo: I’m also trying to think if there is any way to handle it within a context, with Units(MM): point = Point(10,10) I think that any similar constructions debate are waste of time. If somebody wants to create some sensible script, then she/he will made own way to ensure using correct units… There is not only right way, there are a number of possible solutions. -- Best Regards, LordBlick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] more pythonic scripting API for pcbnew
First of all, let me first clarify, we’re discussing two things at the same time: [people scripts (2, 2.1, 2.2)] — [kicad-python-api(1)i] — [C++ swigged-API] 1) Building an API to access the kicad objects in a way that is not tightly coupled to the KiCad internals, and that it’s for consumption from python scripts. This API is to be written in python. I believe this API should live in the kicad repository, even if we iterate first on a separate one. This way, when breaking changes happen in the C++ implementation (interface change, object change, etc..) the API layer can be updated to work with the new C++ interface. 2) Having scripts people build on python to provide specific functions. This could live on a separate repo without risk, since the API contract should not change (unless somehow deprecated). If something becomes really useful for the wide community, of course, it can always be packaged together with KiCad. 2.1) At some point, we could even make a repository available via github, the same way we do for footprints. 2.2) I also find interesting another kind of special functions, not to run standalone from kicad, but to run inside kicad: a) Contextual menu hooks: scripts that can hook certain contextual menus, to provide functions, so users can plug those special functions into kicad. b) Tool bar hooks: To install functions in the toolbar. c) I/O plugins: To write I/O plugins in plain python. I’m replying between lines too- On Friday, 16 de January de 2015 at 15:25, LordBlick wrote: In response to a message written on 16.01.2015, 14:35, from Tomasz Wlostowski: On 16.01.2015 14:06, LordBlick wrote: Dear LordBlick, I'm of quite opposite opinion - all scripts of decent quality should be available in some official repository (whether it will be separate from the main Kicad repo is a different discussion) and possibly packaged with the releases of Kicad. Separate repository seems more sensible. My OS packaging environment (RPM) spends 23 minutes to build every release (without docs and libs) and that amount of time still grows. Every element, which can stand alone, should have separate repo as was done with docs and libs. Build time is painful, but I believe it's something which shouldn’t stop us from adding new functionalities, otherwise we should stop development now ;-) A stable and simple API for scripting, that is independent of the pcbnew's internal storage model is a big step in that direction. To me the discussion if: Point(10, 10, Units=MM) is better than Point.mm(10, 10) or point_mm(10, 10) is a waste of time, because I don't see any of these forms making script development significantly more difficult. That's my appointment too, but possibly haven't found proprietary words… Some of ways comes from Python language specific forms. Ok, let’s not spend more time on that part. :) @Miguel: PS - What do you think about adding a GAL canvas object to the scripting API? It could be useful for footprint/import wizards or other PCB feature generators as a preview window, embedded in a GUI form. It will be great to control fast drawing area from external script. Today I use cairo/gtk to my scribbles. Yes, I totally missed that when using scripting, if you could give me an example of how to instantiate the GAL canvas from a standalone simple wxpython application, that should give me an idea on what do we need to provide from the C++ API layer. I've had in mind a Pythonish SVG graphic importer (see attachment), adding a simple OSHW logo to a Kicad PCB project is quite painful now... Curiously, I'm doing svg import work in python with additional ability to simple edit points position. Screenshot contains yet unfinished UI editor. I have some ideas, eg. a choice to import (DrawPolygon footprint or other draws - arcs, circles segments, zone on board or draw elements on board etc ...) Nice! -- Best Regards, LordBlick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] more pythonic scripting API for pcbnew
Miguel Ángel Ajo
On Friday, 16 de January de 2015 at 20:01, LordBlick wrote:
In response to a message written on 16.01.2015, 18:43, from Miguel Ángel Ajo:
About using mm as the default unit, other people may disagree, we should
provide
facilities to let people specify their unit.
wxPoint and wxSize can be subclassed to allow any arithmetical operation and
unit conversion with propietary methods.
As Jean-Pierre Charras wrote in thread nearly, board names for cooper
layers may
vary:
brd = pcbnew
pcb = brd.GetBoard()
pcb.SetLayerName(0, 'Top')
True
pcb.SetLayerName(31, 'Bottom')
True
pcb.SetLayerName(32, 'BottomGlue')
False
Hmm, that’s an important point for not referencing layers by names
dynamically,
(I was proposing that too)
may be we should be defining a set of 32 constants for the layers we can
reference
and keep up to date with any ID changes at the C++ side. Although I suppose
ID’s
are not
going to change for compatibility reasons.
Seems to be unessary creating independent data. Simply:
lsLayers = tuple([(idl, brd.BOARD_GetStandardLayerName(idl)) for idl in
range(brd.LAYER_ID_COUNT)])
lsCuLayers = tuple(filter(lambda idl, layerName: layerName.endswith('.Cu'),
lsLayers))
Yes, you already told me, but wasn’t the point against using provided names
that they could eventualy change?.
This is why I was suggesting constants. It’s not an awful work ;) but I
understand you may
not want to do it ;)
--
Best Regards,
LordBlick
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
(mailto:kicad-developers@lists.launchpad.net)
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [Branch ~kicad-product-committers/kicad/product] Rev 5370: More work on fp lib table wizard: add a button to import the full list of .pretty libs on github.
Jean Pierre, amazing work, that was fast! Compiling, I want to see it in action :) Miguel Ángel Ajo On Thursday, 15 de January de 2015 at 21:03, nore...@launchpad.net wrote: revno: 5370 committer: jean-pierre charras jp.char...@wanadoo.fr (mailto:jp.char...@wanadoo.fr) branch nick: kicad timestamp: Thu 2015-01-15 21:01:53 +0100 message: More work on fp lib table wizard: add a button to import the full list of .pretty libs on github. * if the current select plugin is the github plugin, one can select some of these libraries and add them to the table * if the current select plugin is the kicad plugin, one can select some of these libraries and download them to make alocal copy. They can added to the table after they are downloaded. added: pcbnew/github/github_getliblist.cpp pcbnew/github/github_getliblist.h modified: common/common.cpp common/drawtxt.cpp common/eda_text.cpp common/html_messagebox.cpp cvpcb/dialogs/dialog_config_equfiles.cpp cvpcb/dialogs/dialog_config_equfiles.h cvpcb/dialogs/dialog_config_equfiles_base.cpp cvpcb/dialogs/dialog_config_equfiles_base.fbp cvpcb/dialogs/dialog_config_equfiles_base.h eeschema/sch_text.cpp include/common.h pcbnew/board_items_to_polygon_shape_transform.cpp pcbnew/dialogs/wizard_add_fplib.cpp pcbnew/dialogs/wizard_add_fplib.h pcbnew/dialogs/wizard_add_fplib_base.cpp pcbnew/dialogs/wizard_add_fplib_base.fbp pcbnew/dialogs/wizard_add_fplib_base.h pcbnew/exporters/export_vrml.cpp pcbnew/github/CMakeLists.txt pcbnew/github/github_plugin.cpp pcbnew/plot_brditems_plotter.cpp The size of the diff (1650 lines) is larger than your specified limit of 1000 lines -- lp:kicad https://code.launchpad.net/~kicad-product-committers/kicad/product You are subscribed to branch lp:kicad. To unsubscribe from this branch go to https://code.launchpad.net/~kicad-product-committers/kicad/product/+edit-subscription ___ Mailing list: https://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] file version compatibility (optional tokens in s-expression files)
I was talking about Altium in my previous email, and I believe the points you made are quite reasonable (in favor and against). I also didn’t know about the measures of not saving the unchanged defaults, which are quite neat. What about a flag in the loader parameters, disabled by default, but which could be used via scripting for extreme situations (recovery of broken files?). Dumping warnings to stdout should be ok. Miguel Ángel Ajo On Thursday, 15 de January de 2015 at 21:37, Kaspar Emanuel wrote: My 2c: let the parser ignore unknown/incompatible s-expressions and warn the user when they are encountered. On 14 January 2015 at 22:24, Martijn Kuipers martijn.kuip...@gmail.com (mailto:martijn.kuip...@gmail.com) wrote: On 14 Jan 2015, at 21:07, Cirilo Bernardo cirilo.berna...@gmail.com (mailto:cirilo.berna...@gmail.com) wrote: On Thu, Jan 15, 2015 at 3:27 AM, Tomasz Wlostowski tomasz.wlostow...@cern.ch (mailto:tomasz.wlostow...@cern.ch) wrote: On 13.01.2015 20:11, Wayne Stambaugh wrote: This is a tricky issue that has been discussed before. The general consensus in the past has been not to support forward compatibility. It increases maintenance and complexity of the file parser for a minimal net gain to the user. My preference is to force users that want to bleed on the edge to use nightly builds rather than try to maintain any forward file compatibility. [snip] OK, how about this: - No extra version tokens (fits point A) - Warning instead of error on unrecognized tokens (point C - no big changes needed in the parser) - If the opened file is produced by a newer version of Kicad, issue a big warning when the user attempts to save it, that certain features will be lost (points B and D - if somebody complains we can always tell him he was warned). AFAIK this is what most commercial software does. Cheers, Tom Except for Acrobat Reader, all the other software I use simply tells me it cannot load the new file. In a corporate environment and especially on large projects no one wants to take the risk that someone obliterated some data. Let's say Person A sends Person B a file with data missing - what can Person B possibly do with that now? Person B was never aware of the warning that Person A ignored and the software is not psychic so it cannot say hey, the last time you worked on this file it was Version X.Z, not X.Y. The problem gets worse and more difficult to detect as the project gets more complex. People need to understand the limitations of their tools and work with that. As I said before people can negotiate what version they need and if necessary build/install to support a specific project. Otherwise why use file versions at all if we're essentially only using it to tell if there are newer features and essentially ignore it and write corrupted data anyway? I would be very happy with backward compatibility, especially if it would allow us to safe the file in the older format. This way, not everybody in the team needs to have the same version to be able to work. Of course, if someone saves it in the new format, then I would not expect an older kicad to be able to read it. Wayne could even decide that every format-change implies a version number increment, so we can tell the user to install kicad newer than version x.y I also think, this is not something that will happen every day, so we should not overdesign this. Forward compatibility for a EDA tool is not something I would advice, as there are just to many things that can go wrong. If it makes things simples, an external file-format converter would also be fine. Just my 2 cents, Martijn - Cirilo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad
Re: [Kicad-developers] FOSDEM plans
Hi all, sorry for not replying to the thread earlier, First of all, very sorry to see that Brian will be missing, I suppose the kid makes it more difficult, I really had troubles to make it fit into my schedule, I must say my wife is sponsoring my trip by taking care of our two daughters over the weekend ‘:-). I will be arriving on Fri 14:30, and leaving on Sun 20:50. My initial idea was to join you in any of your hotels to make breakfasts less lonely, but in the end one of my workmates joined me, and we found a nice hotel not so far from the place (1.6Km): Hotel Capital. If somebody want’s to add me on whatsapp or telegram, I will be checking on wifi hotspots during friday to see if I can sync with any of you for sightseeing and/or beers ;-) , my number is +34 636 52 25 69, and it will be easier for me to check “miguelan...@ajo.es” at that time. Best, Miguel Ángel Ajo On Friday, 9 de January de 2015 at 14:57, Wayne Stambaugh wrote: Hey Brian, Sorry to hear your not going to make it to FOSDEM. I hoping to meet you there. Maybe I'll find a way to make it again next year. Thanks, Wayne On 1/9/2015 6:15 AM, Brian Sidebotham wrote: Hi Guys, Sorry I've been AWOL for so long. The new year has been extremely hectic for me. I hope everyone had a good new year. I've tried to fit FOSDEM into my schedule, but it would be flying out early Saturday morning and flying back late Sunday and then back to work on Monday which is not something I can fit in right now I'm afraid. I'm so sorry not to be able to make it. I hope you all get to meet and discuss all the issues while you're over there. I'm sure the presentations will go fine, but good luck with them anyway. I've already written FOSDEM 2016 into our calendar though, so I'll definitely be there for that one. I missed last year too! :( Best Regards, Brian. On 5 January 2015 at 10:38, Maciej Sumiński maciej.sumin...@cern.ch (mailto:maciej.sumin...@cern.ch) wrote: Hi Miguel, There is a small group from CERN that arrives on Friday evening. We have already booked places at La Madeleine Hotel (most of us, I think). Finally we are going to meet people who have contributed so much to the project! See you there, Orson On 01/02/2015 11:57 AM, Miguel Angel wrote: Hi, I was planning over going to FOSDEM this year. Is anybody going?, if so, can I ask where will you be staying? (thinking of kicad-breakfasts ;) ), I had a look over nearby hotels/hostels and I see a few interesting options. Best regards, Miguel Ángel. --- irc: ajo / mangelajo Miguel Angel Ajo Pelayo +34 636 52 25 69 skype: ajoajoajo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://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: Setting OS X KISYSMOD value in bundle
+1 for the GUI! ;) Miguel Ángel Ajo On Friday, 9 de January de 2015 at 18:21, Andy Peters wrote: On Jan 9, 2015, at 4:34 AM, Brian Sidebotham brian.sidebot...@gmail.com (mailto:brian.sidebot...@gmail.com) wrote: On 8 January 2015 at 13:44, Wayne Stambaugh stambau...@gmail.com (mailto:stambau...@gmail.com) wrote: Fully defined paths can be used in the fp-lib-table if that is your preference. Environment variable substitution is optional. You are free to use any environment variable you want. KISYSMOD is merely the variable name used for the default footprint library path. I use KILCLMOD to point to the path of my custom footprint libraries. I set these paths to the same disk partition and and path in both windows and linux so I'm always using the same footprint libraries when I'm developing on either platform. I think it's clear that users of a GUI, and environment variables do not mix well. Personally I like them as they offer me a lot of flexibility and I can make scripts to set-up environments that are useful to me, but I'm a developer and user. I think the best enhancement we could do here is to have an editor for expandable variables in kicad. That is, rather than KISYSMOD having to be an environment variable (which most users appear to think of as a bad disease!) it could instead be a variable set in the KiCad settings. The variable in the KiCad settings with the same name taking precedence, or vice-versa. It's a simple key-value pair editor that means variables can be defined in KiCad options through the GUI. This achieves the same thing as environment variables without the stigma associated with them and offers the interface for editing the values of those variables in the GUI that they're associated with. Add this to my to-do list if you think it's a reasonable idea. It shouldn't take too long to do. These variables would be saved to the kicad config. Of course, we could also complicate things further in the future and have per-project overrides for the variables too if necessary. I think something has to be done before the stable release so we're not swamped with support questions about this. I will just chime in and say I agree with this! On OS X, setting the environment variables so that Kicad will actually recognize them requires a bit of plist-fu that the Average User won't be able to do. The ability to set the library paths from the GUI in a standard way, and have those paths be sticky, makes for a much better user experience. -a ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] The library tables wizard
John, talking of visualizing pull requests to modules, we could setup a hook to your site from the github KiCad org if you want: https://developer.github.com/webhooks/ Miguel Ángel Ajo On Thursday, 8 de January de 2015 at 08:33, Miguel Ángel Ajo wrote: Nice John, very interesting job, It could be very cool if you could visualize pull requests, etc.. Very good point about the unregistered API limit. The unregistered API limit is 60 req/hour. That should be enough for a normal user (used for listing the repos) If that’s found to be exceeded we could cache that response into downloads.kicad-pcb.org (http://downloads.kicad-pcb.org) with a cron script + OAuth key if necessary. Miguel Ángel Ajo On Thursday, 8 de January de 2015 at 01:19, John Beard wrote: On Wed, 2015-01-07 at 23:38 +0100, Miguel Ángel Ajo wrote: Hi Jean Pierre, just an idea for your wizard work: https://api.github.com/orgs/KiCad/repos You could save the need to work with the HTML viewer and pagination problems using the above API endpoint, all the KiCad project repositories are listed into it in json format. The GitHub API is pretty comprehensive, as I found when writing my web footprint viewer [1]. Full GH API access would allow us to be rather more flexible with what we can do, for example: * Only load footprints one at a time, rather than having to download and unzip the whole repo (note that the transfer can still be compressed!) * View and use footprint history (although this can't easily be done in the case that a footprint has moved pretty repo, e.g. from Sockets.pretty to Sockets_Samtec.pretty) * See changes made in all repos (currently quite hard to do, as you have dozens of separate repos to consider) * Contribute new footprints back to the GH repo in the form of a pull request, without leaving KiCad. Similar use could be made of any Git repo locally too (but not the pull request aspect). Additionally, any remote git repo could also be cloned and used from within KiCad. This does not require the GH API, just a Git library, of which there are many (or shell out, even, bleh!) just querying the URL Miguel provided would only count as a single API access, and would not need an API token, unless the user kept on refreshing the list somehow! But you would still get a complete list of repos. However, the API limits are pretty low when you don't have an API token. The web viewer uses a private clientId and secret and then the user gets their own API token via OAuth. This does require that the user has a Github account. We wouldn't be able to distribute the client secret for a KiCad GitHub interface (it could be stolen and used fraudulently for other purposes). We could: * Make the user get their own access token (fairly easy via GitHub's settings page * Have an OAuth server somewhere which can arbitrate this process (user still needs to log into GitHub via Kicad to get the access token, however. This would also allow to dispense with the webviewer WX requirement, which adds another step to the arduous KiCad build process. [1] http://libree.org/tool/kicad_viewer ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://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: Setting OS X KISYSMOD value in bundle
Can’t users just change that reference to their own path on their own fp-lib-table instead of the ENV var reference if they don’t want the system modules? That would be reasonable enough to me. Miguel Ángel Ajo On Thursday, 8 de January de 2015 at 13:53, Adam Wolf wrote: I hear what you're saying. I don't really like the idea of using environment variables to drive the behavior of GUI programs, especially in OS X. They're tricky in OS X, and they're hard to explain to a lot of users. Fixing this through changing the behavior of how KISYSMOD and probably the other environment variables work in Kicad is probably a fair bit of work, at least a week or two--when you include developer discussion, regression testing on other platforms, stuff like that, probably even longer. I'm not 100% happy about it, but would something like this be an OK stopgap measure while we figure out the right thing moving forward? I am fine only putting this patch in my builds. Adam Wolf Cofounder and Engineer Wayne and Layne On Jan 8, 2015 6:26 AM, Bernhard Stegmaier stegma...@sw-systems.de (mailto:stegma...@sw-systems.de) wrote: Hi Adam, hi all, that IMHO could be problematic (depends on what you intend to have). For a single-user environment this might be OK, but it then forces modules to be in a machine specific folder common to all users. In a multi-user environment you probably might not want to have that. And, I never read somewhere that you can override this setting of the bundle somehow, so this could be a once and for all decision (as long as you don't fiddle around with the Info.plist) and you wouldn't need an environment variable at all... Further, I think I tried once to use ~ or $HOME in Info.plist but it doesn't expand such variables. So, you obviously can't set the path to something in user home with this method. Last, I don't know if always any (non-root) user is allowed to write into /Library/Application Support/kicad? In my opinion, the old concept of search paths did fit such hardcoded paths much better than it is currently with environment variables. If environment variables are too hard to set, then probably a configuration setting directly from some Settings menu would be better. My opionion: I wouldn't want to have it that way, but since I am the only one using KiCad on my machines I can also live with some links pushing things into the spot I want to have it. This altogether is somewhat inconsistent, because eeschema will *always* look in base/library with base being (in that order): * $KICAD * ~/Library/Application Support * /Library/Application Support * kicad.app/Contents/SharedSupport So, if the path should be fixed for pcbnew, I would at least expect eeschema to behave the same way (i.e., removing all the other paths and also pointing it to the one global /Library/Application/Support/kicad/library). Regards, Bernhard PS: I just had a brief look at the Apple docs and did see here https://developer.apple.com/library/mac/documentation/General/Reference/InfoPlistKeyReference/Articles/LaunchServicesKeys.html#//apple_ref/doc/uid/20001431-106825 that obviously the environment set in the Info-plist is only valid when launching via an icon, but not via command-line: These environment variables are set only for apps launched through Launch Services. If you run your executable directly from the command line, these environment variables are not set. So, another issue that already now with the KIGITHUB variable might lead to confusion... On 2015-01-08 06:52, Adam Wolf wrote: Hi folks, As you may know, it's harder than it seems to set an environment variable on a bundle in OS X as a user. I have a patch here for the OS X bundle that sets KISYSMOD to /Library/Application Support/kicad/modules Please let me know if there are any questions or comments. Thanks! Adam Wolf Cofounder and Engineer WL ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net
Re: [Kicad-developers] adjust copyright date to 2015?
This is what I see (update as you go) in other open source projects (openstack related ones in my case). Sometimes they do a major sweep for example, removing @author references and stuff like that, as authorship is already tracked by git. Miguel Ángel Ajo On Wednesday, 7 de January de 2015 at 15:42, Wayne Stambaugh wrote: On 1/7/2015 5:34 AM, Blair Bonnett wrote: On 7 January 2015 at 20:03, Cirilo Bernardo cirilo.berna...@gmail.com (mailto:cirilo.berna...@gmail.com) mailto:cirilo.berna...@gmail.com wrote: Do not replace the older dates with a newer date. Instead, as files are modified (and only as they're modified), add '2015'. So Copyright 2014 Mr. X would become Copyright 2014-2015 Mr. X. Book publishers do something similar with their 1st ed. Copyright, 2nd ed. Copyright etc. You don't want to erase your history by saying only 'Copyright 2015'. There is really no point in adding 2015 unless a file has genuinely been altered though; at least in the USA, UK, and Australia the copyright is valid from date of writing to copyright holder's death + some large number of years (150 in the USA thanks to the Mickey Mouse Bill). And its easy enough to find out which files have been worked on this year from git: $ TZ=UTC git whatchanged --date=local --since 1/1/2015 --name-only --oneline --pretty=format: | sort -u I dare say there's a bazaar equivalent. In case anybody is interested I've put a copy of the changed files as of the time of writing up at http://pastebin.com/7eM93EXw -- note that deleting a file counts as a modification and so removed files will appear in the list. From here it should be possible to write a script which opens each file, looks for a copyright header at the top and checks to see if 2015 appears in it. Bit late in the day for me to have a crack at that now though... -- Blair We haven't been as diligent about keeping our copyright dates current as we probably should be. Although I'm not thrilled with the idea of updating the date for every source file at the beginning of every year either. I think updating them whenever we modify a source file is adequate. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] The library tables wizard
Nice John, very interesting job, It could be very cool if you could visualize pull requests, etc.. Very good point about the unregistered API limit. The unregistered API limit is 60 req/hour. That should be enough for a normal user (used for listing the repos) If that’s found to be exceeded we could cache that response into downloads.kicad-pcb.org with a cron script + OAuth key if necessary. Miguel Ángel Ajo On Thursday, 8 de January de 2015 at 01:19, John Beard wrote: On Wed, 2015-01-07 at 23:38 +0100, Miguel Ángel Ajo wrote: Hi Jean Pierre, just an idea for your wizard work: https://api.github.com/orgs/KiCad/repos You could save the need to work with the HTML viewer and pagination problems using the above API endpoint, all the KiCad project repositories are listed into it in json format. The GitHub API is pretty comprehensive, as I found when writing my web footprint viewer [1]. Full GH API access would allow us to be rather more flexible with what we can do, for example: * Only load footprints one at a time, rather than having to download and unzip the whole repo (note that the transfer can still be compressed!) * View and use footprint history (although this can't easily be done in the case that a footprint has moved pretty repo, e.g. from Sockets.pretty to Sockets_Samtec.pretty) * See changes made in all repos (currently quite hard to do, as you have dozens of separate repos to consider) * Contribute new footprints back to the GH repo in the form of a pull request, without leaving KiCad. Similar use could be made of any Git repo locally too (but not the pull request aspect). Additionally, any remote git repo could also be cloned and used from within KiCad. This does not require the GH API, just a Git library, of which there are many (or shell out, even, bleh!) just querying the URL Miguel provided would only count as a single API access, and would not need an API token, unless the user kept on refreshing the list somehow! But you would still get a complete list of repos. However, the API limits are pretty low when you don't have an API token. The web viewer uses a private clientId and secret and then the user gets their own API token via OAuth. This does require that the user has a Github account. We wouldn't be able to distribute the client secret for a KiCad GitHub interface (it could be stolen and used fraudulently for other purposes). We could: * Make the user get their own access token (fairly easy via GitHub's settings page * Have an OAuth server somewhere which can arbitrate this process (user still needs to log into GitHub via Kicad to get the access token, however. This would also allow to dispense with the webviewer WX requirement, which adds another step to the arduous KiCad build process. [1] http://libree.org/tool/kicad_viewer ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] more pythonic scripting API for pcbnew
PEP8 strongly recommends spaces: (I was about to link the same Adam did). The reasoning is tabs is that change width from editor to editor or from configuration to configuration. Spaces are always the same. Python syntax heavily relies on indenting for blocks, and that can result in problems if people starts mixing spaces or tabs. At least mixing spaces and tabs should be totally avoided. My inclination is to use spaces. I do that with those settings in vimdc: set tabstop=4 set shiftwidth=4 set expandtab But I’m not writing too much in KiCad lately, so.. my opinion is not very important here. The only thing I believe super important is not to mix. Best regards, Miguel Ángel. Miguel Ángel Ajo On Wednesday, 7 de January de 2015 at 21:44, LordBlick wrote: In response to a message written on 07.01.2015, 20:48, from Adam Wolf: I have to stop responding to this thread, but it's official Python policy that spaces are preferred over tabs, and has been for a while. https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces OK, I appreciate that, but my heart goes on tabs… :P I leave policies to politicians. I like the programing mainly because it is one of the few oases of freedom in modern times. Also freedom of choice of indentation sign… :P Enforcing „One correct way” is sign of civilization falling. Diversity is a basic rule of survival. In other news, is anyone else from the KiCad community going to Pycon this year? IMHO, flying to USA for foreigner is to costly and complicated(TSA etc…) than visiting profits… ;) -- Best Regards, LordBlick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] more pythonic scripting API for pcbnew
Hi Lordblick, sorry, I was on a run before, and I actually didn’t look into your code, but stepped into tabs vs spaces (thinking it was a discussion about in-KiCad code). Your python extra layer is very nice, actually, at the start I was very reluctant on adding another layer and reusing the C++ interface as much as possible, and, even if that’s cheaper, it has a lot of disadvantages: 1) Resulting code is not very pythonic, and hard to read. 2) If C++ implementation changes, the available python scripts break. 3) The auto generated documentation is poor, if we had a python mid-layer, we could have very nice documentation rendered by sphinx or any equivalent pythonic solution. I must say, that it sounds like an interesting step, and quite motivating, if other people wanted to join forces on this, and discuss about what would be an ideal interface (your implementation seems like a very nice start point to start discusion), I’d love to spend some time on it and re-join forces back to KiCad development. Miguel Ángel Ajo On Wednesday, 7 de January de 2015 at 22:10, LordBlick wrote: In response to a message written on 07.01.2015, 21:54, from Wayne Stambaugh: On 1/7/2015 3:44 PM, LordBlick wrote: In response to a message written on 07.01.2015, 20:48, from Adam Wolf: I have to stop responding to this thread, but it's official Python policy that spaces are preferred over tabs, and has been for a while. https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces OK, I appreciate that, but my heart goes on tabs… :P I leave policies to politicians. I like the programing mainly because it is one of the few oases of freedom in modern times. Also freedom of choice of indentation sign… :P Enforcing „One correct way” is sign of civilization falling. Diversity is a basic rule of survival. For your own personal code, the sky's the limit as far as formatting goes. Any code included in the KiCad source must follow the coding policy. I doubt the KiCad coding policy has much influence on the overall health of civilization ;). I do not intend to violate any of the sacred rules of KiCAD congregation, my code will be published off-project, and here I'll just kindly inspired you all... ;) -- Best Regards, LordBlick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] more pythonic scripting API for pcbnew
Whoops :-), %s/LordBlick/PTT/g Miguel Ángel Ajo On Wednesday, 7 de January de 2015 at 23:31, LordBlick wrote: In response to a message written on 07.01.2015, 23:07, from Miguel Ángel Ajo: Hi Lordblick, sorry, I was on a run before, and I actually didn’t look into your code, but stepped into tabs vs spaces (thinking it was a discussion about in-KiCad code). Your python extra layer is very nice, actually, at the start I was very reluctant on adding another layer and reusing the C++ interface as much as possible, and, even if that’s cheaper, it has a lot of disadvantages: 1) Resulting code is not very pythonic, and hard to read. 2) If C++ implementation changes, the available python scripts break. 3) The auto generated documentation is poor, if we had a python mid-layer, we could have very nice documentation rendered by sphinx or any equivalent pythonic solution. I must say, that it sounds like an interesting step, and quite motivating, if other people wanted to join forces on this, and discuss about what would be an ideal interface (your implementation seems like a very nice start point to start discusion), I’d love to spend some time on it and re-join forces back to KiCad development. Regardless that I'm different person than PTT, I think that some of most useful code pieces (in example LayerSet with modified by me get_layer()) could be included in swig staff… -- Best Regards, LordBlick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] The library tables wizard
Hi Jean Pierre, just an idea for your wizard work: https://api.github.com/orgs/KiCad/repos You could save the need to work with the HTML viewer and pagination problems using the above API endpoint, all the KiCad project repositories are listed into it in json format. Best regards, Miguel Ángel Ajo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
