Re: [Kicad-developers] Scripting hooks

[mitjan696-ubu...@yahoo.co.uk]

 While I like the idea of hooks I think there are a couple of things that 
should be implemented before and they should enable part of the workflow that 
you envision.
To be specific, implementing action plugin interface in Project manager. Once 
this is in place a lot of hook actions could be implemented semi-automatic as 
an action plugins.

On Tuesday, 30 June 2020, 19:17:28 CEST, Eeli Kaikkonen 
 wrote:  
 
 This post is partly inspired by "Auto-generated backup files: are they
useful?" but I have been thinking about this for a longer time.

KiCad could benefit from a scripting hook system. There could be
pre-hooks and post-hooks for certain actions. Let's take this backup
file discussion as an example. One system of backups or file history
may not make everyone happy. What if KiCad had hooks for Save etc.? It
would call, let's say pcbnew_save_pre() and pcbnew_save_post() python
functions which could do anything they want to do with the project. In
this case it could create backup files. The script writer would decide
how it would be done.

It could even use a third-party git or svn python library or external
program and make a commit every time the user Saves the document.

Let's take another example which was problematic in the past. I don't
remember the details, but I think an attempt to enhance the window
titles was abandoned because it was somehow problematic. What if there
was pcbnew_mainwindow_printwindowtitle_pre(arg1, arg2...) hook which
would return a string from the python function? It would take possible
parts of the window title as arguments.  The python function could
form the title as it likes.

Third example: pcbnew_plot_gerber_post() could rename and zip the
plotted gerber files. See
https://gitlab.com/kicad/code/kicad/-/issues/2076.

Fourth example: https://gitlab.com/kicad/code/kicad/-/issues/2339.
This is obviously something which is impossible to make to satisfy all
use cases, but create_new_project_post() hook could create any folders
the user wants.

It's easy to see that only imagination is the limit, and this would
take some needless responsibilities and decisions from the developers
and would give freedom to the users. There could and often should be
some reasonable default behavior, but the user could decide if it's
enough. If the proper infrastructure (asset installer and repository)
will be made, the users could share what they have.

Eeli Kaikkonen

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

Re: [Kicad-developers] Scripting hooks

[Eeli Kaikkonen]

On Wed, Jul 1, 2020 at 10:12 AM mitjan696-ubu...@yahoo.co.uk
 wrote:
>
> While I like the idea of hooks I think there are a couple of things that 
> should be implemented before and they should enable part of the workflow that 
> you envision.
>
> To be specific, implementing action plugin interface in Project manager. Once 
> this is in place a lot of hook actions could be implemented semi-automatic as 
> an action plugins.

I have many times wondered why plugins can't be run from the project
manager. There's even no need to add any API; it would be enough if an
action plugin could be defined as "generic", not pcbnew specific, and
would be visible in the Tools menu of the project manager. There are
many tasks which don't need to use KiCad python API.

Anyways, I don't think that a better API is a prerequisite for the
hook system. There are do difference between the current plugins and
the envisioned hooks:

1) Hooks don't need to use KiCad API. Many tasks could be done with
the standard python libraries, for example string manipulation and
file system manipulation. The hook call could give the necessary data
as arguments and the function could return a string or a string list
or numerical value. A hook could of course be also more generic
without arguments, for example when it manipulates the project
folders. And the full KiCad python API would of course be available if
needed.

2) Calling hooks is "event based", while calling an action script is
done explicitly by the user. Some hook use cases could be replaced by
a better action script system (namely implementing free hotkey
assignment to call action scripts so that e.g. Save could be replaced
by an action script which then calls Save), but not all (like the
window title example mentioned in a previous post).

Eeli Kaikkonen

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

Re: [Kicad-developers] Scripting hooks

[Greg Smith]

Regarding the plugin manager: it would be awesome if it could pull updates from 
the plugin author’s GitHub. Not sure exactly how to handle plugin version 
checking, KiCAD version compatibility and all the related issues (like 
security, forks, etc). But it’d be nice if there were a central registry or a 
simple text box where something as simple as “HiGregSmith/KiCommand” could be 
entered and the rest happens fairly automatically based either on the structure 
of the source repo, or a config file supplied in the repo by the plugin author.

Simple date check or SHA hash could be used for a “quick” check of config file 
updates.

I’d be happy to collaborate on this and discuss ideas, but I also understand 
the productivity of getting something up and running with your own ideas first.

Greg S.

> On Jun 30, 2020, at 6:08 PM, Andrew Lutsenko  wrote:
> 
> Plugin manager is in the works:  
> https://gitlab.com/kicad/code/kicad/-/issues/2242
> There will be some progress over the long weekend.
> 
>> On Tue, Jun 30, 2020 at 3:06 PM Nick Østergaard  wrote:
>> I like the sound of this idea, it could definitely help the workflow
>> for a lot of people.
>> 
>> What may be related to this is some properly "plugin" manager such
>> that it is easier to bundle some script and have some script installed
>> external, similar to the freecad addon manager.
>> 
>> I don't remember if anyone is seriously working on that, I sorta
>> expect that to be on hold unstill eeschema gets scripting support.
>> 
>> On Tue, 30 Jun 2020 at 21:43, Eeli Kaikkonen  
>> wrote:
>> >
>> > On Tue, Jun 30, 2020 at 9:17 PM Mark Roszko  wrote:
>> >>
>> >> While more extensibility is great. I can only say expecting the user to 
>> >> use python exclusively for adding the new behavior like for issue #2339 
>> >> is very crude.
>> >
>> >
>> > I'm not saying any possible feature which can be replaced with a script 
>> > should be replaced. It must be decided case by case. I don't even say that 
>> > these examples are something where an internal feature should be replaced 
>> > with a hook. They are just possible examples to show what could be 
>> > possible. Just think about it this way:
>> >
>> > 1. Which one is better, just let the users wait for the feature to be 
>> > implemented, or add a hook which makes it possible to implement it right 
>> > away in a simple way in a script and then let the users wait for it to be 
>> > implemented in KiCad proper later?
>> >
>> > 2. Each hook makes it possible to add any imaginable functionality, not 
>> > just one feature wish.
>> >
>> > 3. Adding a hook doesn't take anything away, it just adds possibilities.
>> >
>> > 4. Any developer is still free to implement anything  in C++. Like now 
>> > they are free to implement a functionality which has existed only in an 
>> > action script before.
>> >
>> > 5. Adding a hook doesn't change the UI or the behavior in any way. They 
>> > wouldn't cause any bugs if the backend for the hook system is good. Hooks 
>> > could be added even for bugfix releases. It may be much better than 
>> > waiting for one or two years for the next feature release.
>> >
>> >
>> >>
>> >> Not everyone is a programmer
>> >
>> >
>> > Sure. But big problems with scripting have been 1) the unstable API and 2) 
>> > the lack of asset infrastructure. Both are being worked on. When KiCad 
>> > scripting gets more traction and the scripts are easier to share and 
>> > install, not everyone needs to be a programmer and still can easily 
>> > benefit from the work from others. The potential number of python 
>> > developers for simple scripts like string  handling and generic file 
>> > manipulation is certainly larger than the amount of potential C++ 
>> > developers.
>> >
>> > And if we take that #2339 as an example, it would require a real GUI in 
>> > KiCad proper (because it would need a way to manipulate the list of 
>> > folders). A python script would be one a couple of python functions and a 
>> > list of text strings. If  someone writes the script, anyone can change the 
>> > list of strings, there's no need to be a programmer to change the names of 
>> > the folders. So, which one would be the better option: 1) add a simple 
>> > hook to make it possible and implement the GUI later, or 2) not make it 
>> > possible until someone implements the GUI?
>> >
>> > Eeli Kaikkonen
>> > ___
>> > Mailing list: https://launchpad.net/~kicad-developers
>> > Post to : kicad-developers@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> > More help   : https://help.launchpad.net/ListHelp
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> ___
> Mailing list: 

Re: [Kicad-developers] Scripting hooks

[Andrew Lutsenko]

Plugin manager is in the works:
https://gitlab.com/kicad/code/kicad/-/issues/2242
There will be some progress over the long weekend.

On Tue, Jun 30, 2020 at 3:06 PM Nick Østergaard  wrote:

> I like the sound of this idea, it could definitely help the workflow
> for a lot of people.
>
> What may be related to this is some properly "plugin" manager such
> that it is easier to bundle some script and have some script installed
> external, similar to the freecad addon manager.
>
> I don't remember if anyone is seriously working on that, I sorta
> expect that to be on hold unstill eeschema gets scripting support.
>
> On Tue, 30 Jun 2020 at 21:43, Eeli Kaikkonen 
> wrote:
> >
> > On Tue, Jun 30, 2020 at 9:17 PM Mark Roszko 
> wrote:
> >>
> >> While more extensibility is great. I can only say expecting the user to
> use python exclusively for adding the new behavior like for issue #2339 is
> very crude.
> >
> >
> > I'm not saying any possible feature which can be replaced with a script
> should be replaced. It must be decided case by case. I don't even say that
> these examples are something where an internal feature should be replaced
> with a hook. They are just possible examples to show what could be
> possible. Just think about it this way:
> >
> > 1. Which one is better, just let the users wait for the feature to be
> implemented, or add a hook which makes it possible to implement it right
> away in a simple way in a script and then let the users wait for it to be
> implemented in KiCad proper later?
> >
> > 2. Each hook makes it possible to add any imaginable functionality, not
> just one feature wish.
> >
> > 3. Adding a hook doesn't take anything away, it just adds possibilities.
> >
> > 4. Any developer is still free to implement anything  in C++. Like now
> they are free to implement a functionality which has existed only in an
> action script before.
> >
> > 5. Adding a hook doesn't change the UI or the behavior in any way. They
> wouldn't cause any bugs if the backend for the hook system is good. Hooks
> could be added even for bugfix releases. It may be much better than waiting
> for one or two years for the next feature release.
> >
> >
> >>
> >> Not everyone is a programmer
> >
> >
> > Sure. But big problems with scripting have been 1) the unstable API and
> 2) the lack of asset infrastructure. Both are being worked on. When KiCad
> scripting gets more traction and the scripts are easier to share and
> install, not everyone needs to be a programmer and still can easily benefit
> from the work from others. The potential number of python developers for
> simple scripts like string  handling and generic file manipulation is
> certainly larger than the amount of potential C++ developers.
> >
> > And if we take that #2339 as an example, it would require a real GUI in
> KiCad proper (because it would need a way to manipulate the list of
> folders). A python script would be one a couple of python functions and a
> list of text strings. If  someone writes the script, anyone can change the
> list of strings, there's no need to be a programmer to change the names of
> the folders. So, which one would be the better option: 1) add a simple hook
> to make it possible and implement the GUI later, or 2) not make it possible
> until someone implements the GUI?
> >
> > Eeli Kaikkonen
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Scripting hooks

[Nick Østergaard]

I like the sound of this idea, it could definitely help the workflow
for a lot of people.

What may be related to this is some properly "plugin" manager such
that it is easier to bundle some script and have some script installed
external, similar to the freecad addon manager.

I don't remember if anyone is seriously working on that, I sorta
expect that to be on hold unstill eeschema gets scripting support.

On Tue, 30 Jun 2020 at 21:43, Eeli Kaikkonen  wrote:
>
> On Tue, Jun 30, 2020 at 9:17 PM Mark Roszko  wrote:
>>
>> While more extensibility is great. I can only say expecting the user to use 
>> python exclusively for adding the new behavior like for issue #2339 is very 
>> crude.
>
>
> I'm not saying any possible feature which can be replaced with a script 
> should be replaced. It must be decided case by case. I don't even say that 
> these examples are something where an internal feature should be replaced 
> with a hook. They are just possible examples to show what could be possible. 
> Just think about it this way:
>
> 1. Which one is better, just let the users wait for the feature to be 
> implemented, or add a hook which makes it possible to implement it right away 
> in a simple way in a script and then let the users wait for it to be 
> implemented in KiCad proper later?
>
> 2. Each hook makes it possible to add any imaginable functionality, not just 
> one feature wish.
>
> 3. Adding a hook doesn't take anything away, it just adds possibilities.
>
> 4. Any developer is still free to implement anything  in C++. Like now they 
> are free to implement a functionality which has existed only in an action 
> script before.
>
> 5. Adding a hook doesn't change the UI or the behavior in any way. They 
> wouldn't cause any bugs if the backend for the hook system is good. Hooks 
> could be added even for bugfix releases. It may be much better than waiting 
> for one or two years for the next feature release.
>
>
>>
>> Not everyone is a programmer
>
>
> Sure. But big problems with scripting have been 1) the unstable API and 2) 
> the lack of asset infrastructure. Both are being worked on. When KiCad 
> scripting gets more traction and the scripts are easier to share and install, 
> not everyone needs to be a programmer and still can easily benefit from the 
> work from others. The potential number of python developers for simple 
> scripts like string  handling and generic file manipulation is certainly 
> larger than the amount of potential C++ developers.
>
> And if we take that #2339 as an example, it would require a real GUI in KiCad 
> proper (because it would need a way to manipulate the list of folders). A 
> python script would be one a couple of python functions and a list of text 
> strings. If  someone writes the script, anyone can change the list of 
> strings, there's no need to be a programmer to change the names of the 
> folders. So, which one would be the better option: 1) add a simple hook to 
> make it possible and implement the GUI later, or 2) not make it possible 
> until someone implements the GUI?
>
> Eeli Kaikkonen
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Scripting hooks

[Eeli Kaikkonen]

On Tue, Jun 30, 2020 at 9:17 PM Mark Roszko  wrote:

> While more extensibility is great. I can only say expecting the user to
> use python exclusively for adding the new behavior like for issue #2339 is
> very crude.
>

I'm not saying any possible feature which can be replaced with a script
should be replaced. It must be decided case by case. I don't even say that
these examples are something where an internal feature should be replaced
with a hook. They are just possible examples to show what could be
possible. Just think about it this way:

1. Which one is better, just let the users wait for the feature to be
implemented, or add a hook which makes it possible to implement it right
away in a simple way in a script and then let the users wait for it to be
implemented in KiCad proper later?

2. Each hook makes it possible to add any imaginable functionality, not
just one feature wish.

3. Adding a hook doesn't take anything away, it just adds possibilities.

4. Any developer is still free to implement anything  in C++. Like now they
are free to implement a functionality which has existed only in an action
script before.

5. Adding a hook doesn't change the UI or the behavior in any way. They
wouldn't cause any bugs if the backend for the hook system is good. Hooks
could be added even for bugfix releases. It may be much better than waiting
for one or two years for the next feature release.



> Not everyone is a programmer
>

Sure. But big problems with scripting have been 1) the unstable API and 2)
the lack of asset infrastructure. Both are being worked on. When KiCad
scripting gets more traction and the scripts are easier to share and
install, not everyone needs to be a programmer and still can easily benefit
from the work from others. The potential number of python developers for
simple scripts like string  handling and generic file manipulation is
certainly larger than the amount of potential C++ developers.

And if we take that #2339 as an example, it would require a real GUI in
KiCad proper (because it would need a way to manipulate the list of
folders). A python script would be one a couple of python functions and a
list of text strings. If  someone writes the script, anyone can change the
list of strings, there's no need to be a programmer to change the names of
the folders. So, which one would be the better option: 1) add a simple hook
to make it possible and implement the GUI later, or 2) not make it possible
until someone implements the GUI?

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

Re: [Kicad-developers] Scripting hooks

[Mark Roszko]

While more extensibility is great. I can only say expecting the user to use
python exclusively for adding the new behavior like for issue #2339 is very
crude. Not everyone is a programmer or wants to be to draw a schematic. A
lot of functionality that's not overly specific should be considered
integrated in KiCad itself rather than turning KiCad into a strange python
IDE.

On Tue, Jun 30, 2020 at 1:17 PM Eeli Kaikkonen 
wrote:

> This post is partly inspired by "Auto-generated backup files: are they
> useful?" but I have been thinking about this for a longer time.
>
> KiCad could benefit from a scripting hook system. There could be
> pre-hooks and post-hooks for certain actions. Let's take this backup
> file discussion as an example. One system of backups or file history
> may not make everyone happy. What if KiCad had hooks for Save etc.? It
> would call, let's say pcbnew_save_pre() and pcbnew_save_post() python
> functions which could do anything they want to do with the project. In
> this case it could create backup files. The script writer would decide
> how it would be done.
>
> It could even use a third-party git or svn python library or external
> program and make a commit every time the user Saves the document.
>
> Let's take another example which was problematic in the past. I don't
> remember the details, but I think an attempt to enhance the window
> titles was abandoned because it was somehow problematic. What if there
> was pcbnew_mainwindow_printwindowtitle_pre(arg1, arg2...) hook which
> would return a string from the python function? It would take possible
> parts of the window title as arguments.  The python function could
> form the title as it likes.
>
> Third example: pcbnew_plot_gerber_post() could rename and zip the
> plotted gerber files. See
> https://gitlab.com/kicad/code/kicad/-/issues/2076.
>
> Fourth example: https://gitlab.com/kicad/code/kicad/-/issues/2339.
> This is obviously something which is impossible to make to satisfy all
> use cases, but create_new_project_post() hook could create any folders
> the user wants.
>
> It's easy to see that only imagination is the limit, and this would
> take some needless responsibilities and decisions from the developers
> and would give freedom to the users. There could and often should be
> some reasonable default behavior, but the user could decide if it's
> enough. If the proper infrastructure (asset installer and repository)
> will be made, the users could share what they have.
>
> Eeli Kaikkonen
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>


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

[Kicad-developers] Scripting hooks

[Eeli Kaikkonen]

This post is partly inspired by "Auto-generated backup files: are they
useful?" but I have been thinking about this for a longer time.

KiCad could benefit from a scripting hook system. There could be
pre-hooks and post-hooks for certain actions. Let's take this backup
file discussion as an example. One system of backups or file history
may not make everyone happy. What if KiCad had hooks for Save etc.? It
would call, let's say pcbnew_save_pre() and pcbnew_save_post() python
functions which could do anything they want to do with the project. In
this case it could create backup files. The script writer would decide
how it would be done.

It could even use a third-party git or svn python library or external
program and make a commit every time the user Saves the document.

Let's take another example which was problematic in the past. I don't
remember the details, but I think an attempt to enhance the window
titles was abandoned because it was somehow problematic. What if there
was pcbnew_mainwindow_printwindowtitle_pre(arg1, arg2...) hook which
would return a string from the python function? It would take possible
parts of the window title as arguments.  The python function could
form the title as it likes.

Third example: pcbnew_plot_gerber_post() could rename and zip the
plotted gerber files. See
https://gitlab.com/kicad/code/kicad/-/issues/2076.

Fourth example: https://gitlab.com/kicad/code/kicad/-/issues/2339.
This is obviously something which is impossible to make to satisfy all
use cases, but create_new_project_post() hook could create any folders
the user wants.

It's easy to see that only imagination is the limit, and this would
take some needless responsibilities and decisions from the developers
and would give freedom to the users. There could and often should be
some reasonable default behavior, but the user could decide if it's
enough. If the proper infrastructure (asset installer and repository)
will be made, the users could share what they have.

Eeli Kaikkonen

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

Re: [Kicad-developers] Scripting action menu in packages

[Wayne Stambaugh]

The problem here is not the maturity of the scripting menu support but
rather the scripts themselves.  I'm fine with enabling this for 5.0.1.
In the end the user will bear the responsibility of bad scripts although
we will end up with the headache of supporting it.  Much like many of
the issue with the wxPython scripting support.  It takes one bug in a
python script to bring KiCad to it's knees.

Wayne

On 07/27/2018 06:03 PM, Adam Wolf wrote:
> How about we make it officially included in 5.1?
> 
> 
> 
> On Fri, Jul 27, 2018, 4:29 PM Simon Richter  > wrote:
> 
> Hi,
> 
> On 27.07.2018 21:57, Adam Wolf wrote:
> 
> > Do we think the scripting menu stuff will be mature enough to turn
> on by
> > default soon?
> 
> It's enabled in the nightlies, but disabled in the release build. One
> user has complained already[1], and I've given them a build with the
> action menu enabled and a request to report problems.
> 
> I haven't moved this to the "stable" directory though, because I'm not
> sure it's supposed to be released, but I need a decision soon before
> more users have different versions with the same number.
> 
>    Simon
> 
> [1] https://bugs.launchpad.net/kicad/+bug/1783690
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

Re: [Kicad-developers] Scripting action menu in packages

[Adam Wolf]

How about we make it officially included in 5.1?



On Fri, Jul 27, 2018, 4:29 PM Simon Richter 
wrote:

> Hi,
>
> On 27.07.2018 21:57, Adam Wolf wrote:
>
> > Do we think the scripting menu stuff will be mature enough to turn on by
> > default soon?
>
> It's enabled in the nightlies, but disabled in the release build. One
> user has complained already[1], and I've given them a build with the
> action menu enabled and a request to report problems.
>
> I haven't moved this to the "stable" directory though, because I'm not
> sure it's supposed to be released, but I need a decision soon before
> more users have different versions with the same number.
>
>Simon
>
> [1] https://bugs.launchpad.net/kicad/+bug/1783690
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Scripting action menu in packages

[Simon Richter]

Hi,

On 27.07.2018 21:57, Adam Wolf wrote:

> Do we think the scripting menu stuff will be mature enough to turn on by
> default soon?

It's enabled in the nightlies, but disabled in the release build. One
user has complained already[1], and I've given them a build with the
action menu enabled and a request to report problems.

I haven't moved this to the "stable" directory though, because I'm not
sure it's supposed to be released, but I need a decision soon before
more users have different versions with the same number.

   Simon

[1] https://bugs.launchpad.net/kicad/+bug/1783690



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

[Kicad-developers] Scripting action menu in packages

[Adam Wolf]

Hi folks!

Do we think the scripting menu stuff will be mature enough to turn on by
default soon?

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

Re: [Kicad-developers] scripting version check

[Wayne Stambaugh]

On 10/21/2015 2:49 AM, Lachlan Audas wrote:
> I can't see any way of scripting a version check in Kicad,  Pcbnew, or
> Eeschema,

There is no scripting for Eeschema or KiCad.  Only Pcbnew supports
scripting at this time.  Do you need the version of kicad or the pcb
file version.  If it's the pcb file version, you can get that by loading
a board file an calling BOARD::GetFileFormatVersionAtLoad().

> Most application  print version, given -v  or -version then exit.
> This allows script's to version check,  is there some other way for a
> shell script to check
> what version of Kicad it has ?,  if not, would there be any objection to
> adding
> a --version, which prints version and exit's for all the commands ?

In the short term, I would prefer that this be added to the swig
scripting generation code.  The GetBuildVersion() function would need to
be added.

In the long term, I'm not opposed to adding command line switches to
KiCad assuming it is done properly.  This means using wxCmdLineParser
and friends rather than some ad-hoc way of handling command line options.

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

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

[Kicad-developers] scripting version check

[Lachlan Audas]

I can't see any way of scripting a version check in Kicad,  Pcbnew, or
Eeschema,
Most application  print version, given -v  or -version then exit.
This allows script's to version check,  is there some other way for a shell
script to check
what version of Kicad it has ?,  if not, would there be any objection to
adding
a --version, which prints version and exit's for all the commands ?

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

Re: [Kicad-developers] Scripting

[Miguel Angel Ajo]

Thanks Chris it’d be awesome!!, ping me anytime if you need me to clarify  
or fix anything of the design.

A little bit in the heart of everything is this to let you “wrap” any given 
swig object (known by the library, of course):
https://github.com/KiCad/kicad-python/blob/master/kicad/obj.py

and the “new” method:

https://github.com/KiCad/kicad-python/blob/master/kicad/__init__.py#L28


In C++ you’d do something like this with operator overload in the constructor, 
but python knows nothing about operator overloading, since it’s weakly typed.  

Best,
Miguel Ángel Ajo


On Sunday 14 June 2015 at 14:48, Chris Pavlina wrote:

> Oh, sweet! I'll definitely contribute to this. Hopefully we can get it  
> in usable condition soon. Thanks!
>  
> On Sun, Jun 14, 2015 at 12:23:16PM +0200, Miguel Angel Ajo wrote:
> > I can't do more than agree, and this is why (very slowly) I'm working on
> > this:
> >  
> > https://github.com/kicad/kicad-python
> >  
> > https://github.com/KiCad/kicad-python/blob/master/doc/source/index.rst
> >  
> > https://github.com/KiCad/kicad-python/blob/master/kicad/pcbnew/board.py
> >  
> > https://github.com/KiCad/kicad-python/blob/master/tests/unit/pcbnew/test_pcbnew_board.py
> >  
> >  
> > This is a work that Piers Titus van der Torren started, and that I perverted
> > a bit to
> > add documentation, testing, and trying to keep uniformity across all object
> > interfaces.
> >  
> > If you want to contribute, it can be done via pull requests to the main
> > repository,
> > those are automatically checked by CI, and reported back to github.
> >  
> > I haven't wrote any rules yet, but I really believe we should:
> >  
> > 1) Document as we code
> > 2) Write unit tests as we code
> >  
> > So we avoid regressions and provide a very consistent API for the users,
> > where
> > we can detect regressions or any issues.
> >  
> >  
> > Chris Pavlina wrote:
> > >  
> > > wrt scripting and SWIG - SWIG's good for generating a low-level wrapper,
> > > but if we'd like scripting to go anywhere, I really think we should come
> > > up with a more scripting-friendly API and high-level wrapper. Something
> > > with more proper iterables, fewer integer enums, fewer getters and
> > > setters, objects that are fully and usefully introspectable at the
> > > console, etc. Fewer things like this scattered about:
> > >  
> > > http://ci.kicad-pcb.org/job/kicad-doxygen/ws/build/pcbnew/doxygen-python/html/classpcbnew_1_1MODULE.html#a549dccf2a9eecffa83f76cfe8d1a7d19
> > >  
> > > Anyone else interested in seeing scripting improve? I'd be willing to
> > > contribute to this.
> > >  
> > >  
> > > On Sat, Jun 13, 2015 at 05:26:58PM -0400, Wayne Stambaugh wrote:
> > > >  
> > > > On 6/12/2015 10:48 AM, Rob Maris wrote:
> > > > >  
> > > > > Hi,
> > > > >  
> > > > > I'm interested in adding Lua scripting to Kicad as an alternative to
> > > > > Python. Can anybody present some information about complexity and API 
> > > > > in
> > > > > order to integrate a lua interpreter?
> > > > >  
> > > > > Regards,
> > > > >  
> > > > > Rob
> > > >  
> > > > Rob,
> > > >  
> > > > There has been some interest in lua in the past. I'm not opposed to
> > > > adding lua as another scripting language. I not sure if lua can be
> > > > swigged. That would be the preferred method for generating the lua
> > > > scripting libraries. To get an idea of the complexity of the kicad API,
> > > > look at the python swig code and the c++ code documentation at
> > > > kicad-pcb.org (http://kicad-pcb.org). At this time only Pcbnew is 
> > > > scripted. Eeschema is due a
> > > > major over hall after the next stable release so I expected it to be
> > > > scripted at that point. Also, we are pretty much in feature freeze for
> > > > the next stable release so anything major like supporting another
> > > > scripting language will have to wait until after the next stable 
> > > > release.
> > > >  
> > > > 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 to : kicad-developers@lists.launchpad.net 
> (mailto:kicad-developers@lists.launchpad.net)
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https

Re: [Kicad-developers] Scripting

[Chris Pavlina]

Oh, sweet! I'll definitely contribute to this. Hopefully we can get it 
in usable condition soon. Thanks!

On Sun, Jun 14, 2015 at 12:23:16PM +0200, Miguel Angel Ajo wrote:
> I can't do more than agree, and this is why (very slowly) I'm working on
> this:
> 
> https://github.com/kicad/kicad-python
> 
> https://github.com/KiCad/kicad-python/blob/master/doc/source/index.rst
> 
> https://github.com/KiCad/kicad-python/blob/master/kicad/pcbnew/board.py
> 
> https://github.com/KiCad/kicad-python/blob/master/tests/unit/pcbnew/test_pcbnew_board.py
> 
> 
> This is a work that Piers Titus van der Torren started, and that I perverted
> a bit to
> add documentation, testing, and trying to keep uniformity across all object
> interfaces.
> 
> If you want to contribute, it can be done via pull requests to the main
> repository,
> those are automatically checked by CI, and reported back to github.
> 
> I haven't wrote any rules yet, but I really believe we should:
> 
> 1) Document as we code
> 2) Write unit tests as we code
> 
> So we avoid regressions and provide a very consistent API for the users,
> where
> we can detect regressions or any issues.
> 
> 
> Chris Pavlina wrote:
> >
> >wrt scripting and SWIG - SWIG's good for generating a low-level wrapper,
> >but if we'd like scripting to go anywhere, I really think we should come
> >up with a more scripting-friendly API and high-level wrapper. Something
> >with more proper iterables, fewer integer enums, fewer getters and
> >setters, objects that are fully and usefully introspectable at the
> >console, etc. Fewer things like this scattered about:
> >
> >http://ci.kicad-pcb.org/job/kicad-doxygen/ws/build/pcbnew/doxygen-python/html/classpcbnew_1_1MODULE.html#a549dccf2a9eecffa83f76cfe8d1a7d19
> >
> >Anyone else interested in seeing scripting improve? I'd be willing to
> >contribute to this.
> >
> >
> >On Sat, Jun 13, 2015 at 05:26:58PM -0400, Wayne Stambaugh wrote:
> >>
> >>On 6/12/2015 10:48 AM, Rob Maris wrote:
> >>>
> >>>Hi,
> >>>
> >>>I'm interested in adding Lua scripting to Kicad as an alternative to
> >>>Python. Can anybody present some information about complexity and API in
> >>>order to integrate a lua interpreter?
> >>>
> >>>Regards,
> >>>
> >>>Rob
> >>
> >>Rob,
> >>
> >>There has been some interest in lua in the past. I'm not opposed to
> >>adding lua as another scripting language. I not sure if lua can be
> >>swigged. That would be the preferred method for generating the lua
> >>scripting libraries. To get an idea of the complexity of the kicad API,
> >>look at the python swig code and the c++ code documentation at
> >>kicad-pcb.org. At this time only Pcbnew is scripted. Eeschema is due a
> >>major over hall after the next stable release so I expected it to be
> >>scripted at that point. Also, we are pretty much in feature freeze for
> >>the next stable release so anything major like supporting another
> >>scripting language will have to wait until after the next stable release.
> >>
> >>Cheers,
> >>
> >>Wayne
> >>
> >>___
> >>Mailing list: https://launchpad.net/~kicad-developers
> >>Post to : kicad-developers@lists.launchpad.net
> >>Unsubscribe : https://launchpad.net/~kicad-developers
> >>More help : https://help.launchpad.net/ListHelp
> >
> >
> >___
> >Mailing list: https://launchpad.net/~kicad-developers
> >Post to : kicad-developers@lists.launchpad.net
> >Unsubscribe : https://launchpad.net/~kicad-developers
> >More help : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Scripting

[Miguel Angel Ajo]

Btw, I forgot, if you clone it to test, you need kicad installed with 
scripting support
so it will find the "raw" C++ interface generated by swig as "pcbnew" on 
the system.


Then, you can run

tox -epy27 # to run unit test validation
tox -epep8 # to run the standard python code style checks
tox -edocs # to generate/render the documentation



Miguel Angel Ajo wrote:


I can't do more than agree, and this is why (very slowly) I'm working
on this:

https://github.com/kicad/kicad-python

https://github.com/KiCad/kicad-python/blob/master/doc/source/index.rst

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

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


This is a work that Piers Titus van der Torren started, and that I
perverted a bit to
add documentation, testing, and trying to keep uniformity across all
object interfaces.

If you want to contribute, it can be done via pull requests to the
main repository,
those are automatically checked by CI, and reported back to github.

I haven't wrote any rules yet, but I really believe we should:

1) Document as we code
2) Write unit tests as we code

So we avoid regressions and provide a very consistent API for the
users, where
we can detect regressions or any issues.


Chris Pavlina wrote:



wrt scripting and SWIG - SWIG's good for generating a low-level wrapper,
but if we'd like scripting to go anywhere, I really think we should come
up with a more scripting-friendly API and high-level wrapper. Something
with more proper iterables, fewer integer enums, fewer getters and
setters, objects that are fully and usefully introspectable at the
console, etc. Fewer things like this scattered about:

http://ci.kicad-pcb.org/job/kicad-doxygen/ws/build/pcbnew/doxygen-python/html/classpcbnew_1_1MODULE.html#a549dccf2a9eecffa83f76cfe8d1a7d19

Anyone else interested in seeing scripting improve? I'd be willing to
contribute to this.


On Sat, Jun 13, 2015 at 05:26:58PM -0400, Wayne Stambaugh wrote:



On 6/12/2015 10:48 AM, Rob Maris wrote:



Hi,

I'm interested in adding Lua scripting to Kicad as an alternative to
Python. Can anybody present some information about complexity and
API in
order to integrate a lua interpreter?

Regards,

Rob



Rob,

There has been some interest in lua in the past. I'm not opposed to
adding lua as another scripting language. I not sure if lua can be
swigged. That would be the preferred method for generating the lua
scripting libraries. To get an idea of the complexity of the kicad API,
look at the python swig code and the c++ code documentation at
kicad-pcb.org. At this time only Pcbnew is scripted. Eeschema is due a
major over hall after the next stable release so I expected it to be
scripted at that point. Also, we are pretty much in feature freeze for
the next stable release so anything major like supporting another
scripting language will have to wait until after the next stable
release.

Cheers,

Wayne

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




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

Re: [Kicad-developers] Scripting

[Miguel Angel Ajo]

I can't do more than agree, and this is why (very slowly) I'm working on 
this:


https://github.com/kicad/kicad-python

https://github.com/KiCad/kicad-python/blob/master/doc/source/index.rst

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

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


This is a work that Piers Titus van der Torren started, and that I 
perverted a bit to
add documentation, testing, and trying to keep uniformity across all 
object interfaces.


If you want to contribute, it can be done via pull requests to the main 
repository,

those are automatically checked by CI, and reported back to github.

I haven't wrote any rules yet, but I really believe we should:

1) Document as we code
2) Write unit tests as we code

So we avoid regressions and provide a very consistent API for the users, 
where

we can detect regressions or any issues.


Chris Pavlina wrote:


wrt scripting and SWIG - SWIG's good for generating a low-level wrapper,
but if we'd like scripting to go anywhere, I really think we should come
up with a more scripting-friendly API and high-level wrapper. Something
with more proper iterables, fewer integer enums, fewer getters and
setters, objects that are fully and usefully introspectable at the
console, etc. Fewer things like this scattered about:

http://ci.kicad-pcb.org/job/kicad-doxygen/ws/build/pcbnew/doxygen-python/html/classpcbnew_1_1MODULE.html#a549dccf2a9eecffa83f76cfe8d1a7d19

Anyone else interested in seeing scripting improve? I'd be willing to
contribute to this.


On Sat, Jun 13, 2015 at 05:26:58PM -0400, Wayne Stambaugh wrote:


On 6/12/2015 10:48 AM, Rob Maris wrote:


Hi,

I'm interested in adding Lua scripting to Kicad as an alternative to
Python. Can anybody present some information about complexity and API in
order to integrate a lua interpreter?

Regards,

Rob


Rob,

There has been some interest in lua in the past. I'm not opposed to
adding lua as another scripting language. I not sure if lua can be
swigged. That would be the preferred method for generating the lua
scripting libraries. To get an idea of the complexity of the kicad API,
look at the python swig code and the c++ code documentation at
kicad-pcb.org. At this time only Pcbnew is scripted. Eeschema is due a
major over hall after the next stable release so I expected it to be
scripted at that point. Also, we are pretty much in feature freeze for
the next stable release so anything major like supporting another
scripting language will have to wait until after the next stable release.

Cheers,

Wayne

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



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

Re: [Kicad-developers] Scripting

[Chris Pavlina]

wrt scripting and SWIG - SWIG's good for generating a low-level wrapper, 
but if we'd like scripting to go anywhere, I really think we should come 
up with a more scripting-friendly API and high-level wrapper. Something 
with more proper iterables, fewer integer enums, fewer getters and 
setters, objects that are fully and usefully introspectable at the 
console, etc. Fewer things like this scattered about:

http://ci.kicad-pcb.org/job/kicad-doxygen/ws/build/pcbnew/doxygen-python/html/classpcbnew_1_1MODULE.html#a549dccf2a9eecffa83f76cfe8d1a7d19

Anyone else interested in seeing scripting improve? I'd be willing to 
contribute to this.


On Sat, Jun 13, 2015 at 05:26:58PM -0400, Wayne Stambaugh wrote:
> On 6/12/2015 10:48 AM, Rob Maris wrote:
> > Hi,
> > 
> > I'm interested in adding Lua scripting to Kicad as an alternative to
> > Python. Can anybody present some information about complexity and API in
> > order to integrate a lua interpreter?
> > 
> > Regards,
> > 
> > Rob
> 
> Rob,
> 
> There has been some interest in lua in the past.  I'm not opposed to
> adding lua as another scripting language.  I not sure if lua can be
> swigged.  That would be the preferred method for generating the lua
> scripting libraries.  To get an idea of the complexity of the kicad API,
> look at the python swig code and the c++ code documentation at
> kicad-pcb.org.  At this time only Pcbnew is scripted.  Eeschema is due a
> major over hall after the next stable release so I expected it to be
> scripted at that point.  Also, we are pretty much in feature freeze for
> the next stable release so anything major like supporting another
> scripting language will have to wait until after the next stable release.
> 
> Cheers,
> 
> Wayne
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Scripting

[Wayne Stambaugh]

On 6/12/2015 10:48 AM, Rob Maris wrote:
> Hi,
> 
> I'm interested in adding Lua scripting to Kicad as an alternative to
> Python. Can anybody present some information about complexity and API in
> order to integrate a lua interpreter?
> 
> Regards,
> 
> Rob

Rob,

There has been some interest in lua in the past.  I'm not opposed to
adding lua as another scripting language.  I not sure if lua can be
swigged.  That would be the preferred method for generating the lua
scripting libraries.  To get an idea of the complexity of the kicad API,
look at the python swig code and the c++ code documentation at
kicad-pcb.org.  At this time only Pcbnew is scripted.  Eeschema is due a
major over hall after the next stable release so I expected it to be
scripted at that point.  Also, we are pretty much in feature freeze for
the next stable release so anything major like supporting another
scripting language will have to wait until after the next stable release.

Cheers,

Wayne

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

[Kicad-developers] Scripting

[Rob Maris]

Hi,

I'm interested in adding Lua scripting to Kicad as an alternative to Python. 
Can anybody present some information about complexity and API in order to 
integrate a lua interpreter?

Regards,

Rob

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

Re: [Kicad-developers] Scripting importing Eaggle 6.xx PCB file, and saving as KiCad pcb file.

[Nick Østergaard]

It should be easily possible to read and save boards from the
scripting interface. The only problem when you want to read the eagle
pcb is that the read pcb will be interpreted as the legacy kicad
format, because they share the same extension.

The handling of the plugins are around:
https://github.com/KiCad/kicad-source-mirror/blob/master/pcbnew/files.cpp#L359

2015-04-26 8:37 GMT+02:00 Lachlan Audas :
>
>
> I wont to call PCBNEW from a command line,  IE in linux or windows,
> load/import a Eagle 6.xx PCB, file and save it to a KiCad PCB file name of
> my choice, and exit the
> PCBNEW program,   It would also be nice to open a project in KiCad from the
> command line too.
>
> Thanks in advance.
>
> Lachlan
>
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

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

[Kicad-developers] Scripting importing Eaggle 6.xx PCB file, and saving as KiCad pcb file.

[Lachlan Audas]

I wont to call PCBNEW from a command line,  IE in linux or windows,
load/import a Eagle 6.xx PCB, file and save it to a KiCad PCB file name of
my choice, and exit the
PCBNEW program,   It would also be nice to open a project in KiCad from the
command line too.

Thanks in advance.

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

Re: [Kicad-developers] Scripting Build Failing

[Kaspar Emanuel]

Thanks for the suggestions. I tried a make clean but that didn't help. I
had kept making new out of source builds anyway. Then I realized that CMake
was reporting:

-- Found PythonLibs: /usr/lib/libpython3.2mu.so (found version "3.2.4")

Which led me to a report and workaround Adam Wolf posted in April:
https://lists.launchpad.net/kicad-developers/msg09960.html


On 15 August 2013 16:33, Miguel Angel Ajo Pelayo wrote:

> Let me know if that doesn't fix it in your system, but as dick says it
> could be a dependency / swig rebuild problem.
>
> In such case please provide more information of your build system and
> python libraries version and I will try to help ( I'm on vacation,
> hurray!!! ;) )
>
>
>
>
> 2013/8/15 Dick Hollenbeck 
>
>> On 08/15/2013 09:59 AM, Kaspar Emanuel wrote:
>> > Hey,
>> >
>> > I have been having trouble building pcbnew with -DKICAD_SCRIPTING=ON and
>> > -DKICAD_SCRIPTING_MODULES=ON. I tried a few days ago with and without
>> and it's definitely
>> > one of those flags, not surprising considering the error:
>> >
>> > |[ 61%] Building CXX object
>> pcbnew/CMakeFiles/_pcbnew.dir/__/scripting/wx_python_helpers.cpp.o
>> > /home/kaspar/kicad/kicad.bzr2/scripting/wx_python_helpers.cpp: In
>> function ‘wxString* newWxStringFromPy(PyObject*)’:
>> >  /home/kaspar/kicad/kicad.bzr2/scripting/wx_python_helpers.cpp:77:30:
>> error: ‘PyString_Check’ was not declared in this scope
>> >  if( !PyString_Check( src ) && !PyUnicode_Check( src ) )
>> >   ^
>> >  /home/kaspar/kicad/kicad.bzr2/scripting/wx_python_helpers.cpp:86:29:
>> error: ‘PyString_Check’ was not declared in this scope
>> >  if( PyString_Check( obj ) )
>> >  ^
>> > /home/kaspar/kicad/kicad.bzr2/scripting/wx_python_helpers.cpp:101:67:
>> error: cannot convert ‘PyUnicodeObject*’ to ‘PyObject* {aka _object*}’ for
>> argument ‘1’ to ‘Py_ssize_t PyUnicodeUCS4_AsWideChar(PyObject*, wchar_t*,
>> Py_ssize_t)’
>> > wxStringBuffer( *result, len ), len );
>> >^
>> > make[2]: ***
>> [pcbnew/CMakeFiles/_pcbnew.dir/__/scripting/wx_python_helpers.cpp.o] Error 1
>> >  make[1]: *** [pcbnew/CMakeFiles/_pcbnew.dir/all] Error 2|
>> >
>> > I just tried with -DKICAD_SCRIPTING_WXPYTHON=ON as well and that gives
>> the same error.
>> >
>> > I don't have time right now to do a proper regression test but it
>> definitely occurs with
>> > revisions 4242 onwards.
>> >
>> > Anyone know anything about this?
>>
>>
>> Scripting builds often require that you do a
>>
>> $ make clean
>>
>> before your
>>
>> $ make
>>
>>
>> There are some disconnects in the dependency tree, mostly because of
>> incomplete cmake
>> macros/functions for swig.
>>
>>
>> $ make clean
>>
>> is the work around.
>>
>>
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> --
>
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 636 52 25 69
> skype: ajoajoajo
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Scripting Build Failing

[Miguel Angel Ajo Pelayo]

Let me know if that doesn't fix it in your system, but as dick says it
could be a dependency / swig rebuild problem.

In such case please provide more information of your build system and
python libraries version and I will try to help ( I'm on vacation,
hurray!!! ;) )




2013/8/15 Dick Hollenbeck 

> On 08/15/2013 09:59 AM, Kaspar Emanuel wrote:
> > Hey,
> >
> > I have been having trouble building pcbnew with -DKICAD_SCRIPTING=ON and
> > -DKICAD_SCRIPTING_MODULES=ON. I tried a few days ago with and without
> and it's definitely
> > one of those flags, not surprising considering the error:
> >
> > |[ 61%] Building CXX object
> pcbnew/CMakeFiles/_pcbnew.dir/__/scripting/wx_python_helpers.cpp.o
> > /home/kaspar/kicad/kicad.bzr2/scripting/wx_python_helpers.cpp: In
> function ‘wxString* newWxStringFromPy(PyObject*)’:
> >  /home/kaspar/kicad/kicad.bzr2/scripting/wx_python_helpers.cpp:77:30:
> error: ‘PyString_Check’ was not declared in this scope
> >  if( !PyString_Check( src ) && !PyUnicode_Check( src ) )
> >   ^
> >  /home/kaspar/kicad/kicad.bzr2/scripting/wx_python_helpers.cpp:86:29:
> error: ‘PyString_Check’ was not declared in this scope
> >  if( PyString_Check( obj ) )
> >  ^
> > /home/kaspar/kicad/kicad.bzr2/scripting/wx_python_helpers.cpp:101:67:
> error: cannot convert ‘PyUnicodeObject*’ to ‘PyObject* {aka _object*}’ for
> argument ‘1’ to ‘Py_ssize_t PyUnicodeUCS4_AsWideChar(PyObject*, wchar_t*,
> Py_ssize_t)’
> > wxStringBuffer( *result, len ), len );
> >^
> > make[2]: ***
> [pcbnew/CMakeFiles/_pcbnew.dir/__/scripting/wx_python_helpers.cpp.o] Error 1
> >  make[1]: *** [pcbnew/CMakeFiles/_pcbnew.dir/all] Error 2|
> >
> > I just tried with -DKICAD_SCRIPTING_WXPYTHON=ON as well and that gives
> the same error.
> >
> > I don't have time right now to do a proper regression test but it
> definitely occurs with
> > revisions 4242 onwards.
> >
> > Anyone know anything about this?
>
>
> Scripting builds often require that you do a
>
> $ make clean
>
> before your
>
> $ make
>
>
> There are some disconnects in the dependency tree, mostly because of
> incomplete cmake
> macros/functions for swig.
>
>
> $ make clean
>
> is the work around.
>
>
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>



-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Scripting Build Failing

[Dick Hollenbeck]

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


Scripting builds often require that you do a

$ make clean

before your

$ make


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


$ make clean

is the work around.





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

[Kicad-developers] Scripting Build Failing

[Kaspar Emanuel]

Hey,

I have been having trouble building pcbnew with -DKICAD_SCRIPTING=ON and
-DKICAD_SCRIPTING_MODULES=ON. I tried a few days ago with and without and
it's definitely one of those flags, not surprising considering the error:

[ 61%] Building CXX object
pcbnew/CMakeFiles/_pcbnew.dir/__/scripting/wx_python_helpers.cpp.o
/home/kaspar/kicad/kicad.bzr2/scripting/wx_python_helpers.cpp: In
function ‘wxString* newWxStringFromPy(PyObject*)’:
 /home/kaspar/kicad/kicad.bzr2/scripting/wx_python_helpers.cpp:77:30:
error: ‘PyString_Check’ was not declared in this scope
 if( !PyString_Check( src ) && !PyUnicode_Check( src ) )
  ^
 /home/kaspar/kicad/kicad.bzr2/scripting/wx_python_helpers.cpp:86:29:
error: ‘PyString_Check’ was not declared in this scope
 if( PyString_Check( obj ) )
 ^
/home/kaspar/kicad/kicad.bzr2/scripting/wx_python_helpers.cpp:101:67:
error: cannot convert ‘PyUnicodeObject*’ to ‘PyObject* {aka _object*}’
for argument ‘1’ to ‘Py_ssize_t PyUnicodeUCS4_AsWideChar(PyObject*,
wchar_t*, Py_ssize_t)’
wxStringBuffer( *result, len ), len );
   ^
make[2]: *** 
[pcbnew/CMakeFiles/_pcbnew.dir/__/scripting/wx_python_helpers.cpp.o]
Error 1
 make[1]: *** [pcbnew/CMakeFiles/_pcbnew.dir/all] Error 2

I just tried with -DKICAD_SCRIPTING_WXPYTHON=ON as well and that gives the
same error.

I don't have time right now to do a proper regression test but it
definitely occurs with revisions 4242 onwards.

Anyone know anything about this?

Cheers,

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

Re: [Kicad-developers] Scripting/hacking tracks using new pcbnew format

[Adam Wolf]

I've been out the last week for a funeral, but I'm making progress on the
kicad-w-scripting-daily PPA.  Until then--

It really isn't hard to compile it yourself.  The instructions here work
pretty well (
http://www.wayneandlayne.com/blog/2010/12/03/how-to-build-kicad-on-ubuntu/)
and you just change two things to get scripting support.

Change the cmake line to:

cmake ../ -DKICAD_TESTING_VERSION=ON \
-DKICAD_SCRIPTING=ON \
-DKICAD_SCRIPTING_MODULES=ON \
-DKICAD_SCRIPTING_WXPYTHON=ON \
-DCMAKE_BUILD_TYPE=DEBUG

My current working list of dependencies for the Ubuntu package is basically
equivalent to

sudo apt-get install build-essential libx11-dev libglu1-mesa-dev
libgl1-mesa-dev mesa-common-dev libwxbase2.8-dev libwxgtk2.8-dev cmake
python-wxgtk2.8 swig bzr doxygen

Adam Wolf
Wayne and Layne, LLC


On Sat, Apr 6, 2013 at 9:06 AM, Senthil Seveelavanan <
s.seveelava...@gmail.com> wrote:

> Hi all,
>
> In the absence of known compiled 'Kicad with scripting', and current
> project on the go I have dug into scripting/hacking the file directly. My
> circuit has 50 identical modules within the pcb (but sharing common
> components so I can't just design the circuit once make 50x).
>
> By parsing the new .kicad_pcb file directly I can successfully get/set
> the position/rotation of any module (using its fp_text reference):
>
> (module LUXEON_REBEL_COOLPAD   locked (layer Layer0) (tedit 515EAFE6)
> (tstamp 512A9571)
> (at 369.89766 234.99826)
> (path /51225974/511E3F14/51192821)
> (fp_text reference D7001 (at 7.112 4.699) (layer F.SilkS)
>
>
> But scripting nets/tracks is driving me crazy!:
>
> (segment (start 122.9474 228.74) (end 122.795 228.8924) (width 0.2032)
> (layer Layer0) (net 51))
>
> My goal is to draw tracks in kicad for one of my 50 identical modules, and
> then 'copy' the tracks. The would be done using the said script, which
> would create new segments, and applying an offset for the x&y values. This
> works to a point,
> I can get/set the position of segment(track) and also changing its net
> numer appropriately .. and it works SOMETIMES.
>
> From looking at the .kicad_pcb files generated when saving from pcb_new it
> seems like there are added 'status' and/or 'tstamp' flags added at
> different times for unknown reasons - I assume that it is these flags that
> is causing the my segment/track hack to fail sometimes and work other
> times. By fail, when the file is loaded there is just a blank screen.
>
> How can I make it work at all? If I delete all these (extra?) flags will
> it work... help!! I have been trying this for couple of days now, making
> different test files and comparing the differences etc, in order work out
> why it works in some instance and fails in other, and why certain tags are
> only applied to certain segments etc etc help help!
>
> Any help gratefully appreciated
>
> Senthil
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Scripting/hacking tracks using new pcbnew format

[Senthil Seveelavanan]

Hi all,

In the absence of known compiled 'Kicad with scripting', and current
project on the go I have dug into scripting/hacking the file directly. My
circuit has 50 identical modules within the pcb (but sharing common
components so I can't just design the circuit once make 50x).

By parsing the new .kicad_pcb file directly I can successfully get/set
the position/rotation of any module (using its fp_text reference):

(module LUXEON_REBEL_COOLPAD   locked (layer Layer0) (tedit 515EAFE6)
(tstamp 512A9571)
(at 369.89766 234.99826)
(path /51225974/511E3F14/51192821)
(fp_text reference D7001 (at 7.112 4.699) (layer F.SilkS)


But scripting nets/tracks is driving me crazy!:

(segment (start 122.9474 228.74) (end 122.795 228.8924) (width 0.2032)
(layer Layer0) (net 51))

My goal is to draw tracks in kicad for one of my 50 identical modules, and
then 'copy' the tracks. The would be done using the said script, which
would create new segments, and applying an offset for the x&y values. This
works to a point,
I can get/set the position of segment(track) and also changing its net
numer appropriately .. and it works SOMETIMES.

>From looking at the .kicad_pcb files generated when saving from pcb_new it
seems like there are added 'status' and/or 'tstamp' flags added at
different times for unknown reasons - I assume that it is these flags that
is causing the my segment/track hack to fail sometimes and work other
times. By fail, when the file is loaded there is just a blank screen.

How can I make it work at all? If I delete all these (extra?) flags will it
work... help!! I have been trying this for couple of days now, making
different test files and comparing the differences etc, in order work out
why it works in some instance and fails in other, and why certain tags are
only applied to certain segments etc etc help help!

Any help gratefully appreciated

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

Re: [Kicad-developers] Scripting on Windows Fix

[Brian Sidebotham]

On 15 March 2013 19:57, Adam Wolf  wrote:

> Hi Brian,
>
> Good work!  Are these patches available somewhere?  I'd like to throw it
> on my build cluster this weekend if you get a chance to post the patches
> and the versions they need to be applied against.
>
> Thanks!
>
> Adam Wolf
> W&L
>

Hi Adam,

Sorry for the delayed response, my impending wedding is eating up virtually
all available spare time at the moment.

Patches need completing for this job, there are some things for me to
figure out with how we build wxPython. At the moment it requires patching
distutils in python ( It really is *that* bit-rotten for the mingw
compiler! ). I hate that patch anyway, and I wouldn't like to suggest that
the patch won't break distutils for other build configurations ( like
building with mingw in a cygwin environment. *shudder* ! )

I'll post an update ASAP and we can decide on a way forward.

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

Re: [Kicad-developers] Scripting on Windows Fix

[Adam Wolf]

Hi Brian,

Good work!  Are these patches available somewhere?  I'd like to throw it on
my build cluster this weekend if you get a chance to post the patches and
the versions they need to be applied against.

Thanks!

Adam Wolf
W&L
On Tue, Mar 12, 2013 at 6:31 PM, Brian Sidebotham <
brian.sidebot...@gmail.com> wrote:

> Hi Guys,
>
> BZR3998 is all good and works well on Windows. Yay!
>
> So now I'll try and either send patches to the relevant projects to fix up
> the building process of the dependencies, or generate our own patches to
> maintain.
>
> Should we start a new project in a similar fashion to the
> inkscape-dev-libs project to provide the binaries necessary to build KiCad
> against?
>
> Best Regards, Brian.
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Scripting on Windows Fix

[Brian Sidebotham]

Hi Guys,

BZR3998 is all good and works well on Windows. Yay!

So now I'll try and either send patches to the relevant projects to fix up
the building process of the dependencies, or generate our own patches to
maintain.

Should we start a new project in a similar fashion to the inkscape-dev-libs
project to provide the binaries necessary to build KiCad against?

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

Re: [Kicad-developers] Scripting on Windows Fix

[Brian Sidebotham]

On 12 March 2013 00:53, Miguel Angel Ajo Pelayo  wrote:

> Pushed to revision 3996,   Brian, can you re-test Dick's class-lock now
> with those fixes in place?
>
> ---
> PS:
>
>
> There is something broken yet with datatypes flying to python when you
> change parameters for a wizard
>
> [Pads][*steps]<= 3.0
> [Pads][length]<= 5000,00
> [Pads][clearance]<= 100,00
> [Pads][width]<= 1000,00
> calling GetModule()
> Exception: invalid literal for float(): 5000,00
>  : 
> m_FootprintWizard->GetModule() returns NULL
>
>
> looks like something related to locale conversion, that's been there
> broken for a while, I will work on fixing it back tomorrow, almost 2am here
> ':D
>
>
Hi Miguel,

Thanks, that looks like a possibility. I'll get to test it tonight.

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

Re: [Kicad-developers] Scripting on Windows Fix

[Miguel Angel Ajo Pelayo]

Pushed to revision 3996,   Brian, can you re-test Dick's class-lock now with 
those fixes in place?

---
PS:


There is something broken yet with datatypes flying to python when you change 
parameters for a wizard

[Pads][*steps]<= 3.0
[Pads][length]<= 5000,00
[Pads][clearance]<= 100,00
[Pads][width]<= 1000,00
calling GetModule()
Exception: invalid literal for float(): 5000,00
 : 
m_FootprintWizard->GetModule() returns NULL


looks like something related to locale conversion, that's been there broken for 
a while, I will work on fixing it back tomorrow, almost 2am here ':D




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

On 12/03/2013, at 01:44, Miguel Angel Ajo Pelayo  wrote:

> Don't worry Wayne, I will commit it in a few seconds, I'm trying, but my bzr 
> just not logged in in a new dev machine I'm using :)
> 
> I sometimes yet need to look at my notes to re-discover what did each python 
> related define… 
> 
> 
> Miguel Angel Ajo
> http://www.nbee.es
> +34911407752
> skype: ajoajoajo
> 
> On 12/03/2013, at 01:37, Wayne Stambaugh  wrote:
> 
>> On 3/11/2013 7:48 PM, Miguel Angel Ajo Pelayo wrote:
>>> Hmm, I recompiled several times (without the WXPYTHON option) , not
>>> getting the footprint wizard, and then I realized that somebody changed
>>> this ifdef:
>>> 
>>> #ifdef KICAD_SCRIPTING_WXPYTHON
>>>m_mainToolBar->AddTool( ID_MODEDIT_NEW_MODULE_FROM_WIZARD,
>>> wxEmptyString,
>>>KiBitmap( module_wizard_xpm ),
>>>_( "New module from footprint wizard" ) );
>>> #endif
>>> 
>>> 
>>> in tool_modedit.cpp
>>> 
>>> it only needs to be KICAD_SCRIPTING, there is no WXPYTHON dependency in
>>> the footprint wizard :-),
>> 
>> Sorry about that.  I didn't realize that wxPython was not in play here.  I 
>> incorrectly assumed since it was dealing with UI elements (the toolbar) that 
>> wxPython was in play.  I'll fix it to look for KICAD_SCRIPTING.
>> 
>> Wayne
>> 
>>> when I made that I wanted to be scripting language agnostic, we can even
>>> write C++ wizards with current
>>> implementation just subclassing the FootprintWizard class
>>> (class_footprint_wizard.h/cpp) :)
>>> 
>>> I'm going to change it, and make the test :-)
>>> 
>>> 
>>> Miguel Angel Ajo
>>> http://www.nbee.es
>>> +34911407752
>>> skype: ajoajoajo
>>> 
>>> On 11/03/2013, at 15:30, Miguel Angel Ajo Pelayo >> > wrote:
>>> 
 Ok, more than 5 minutes, removing WXPYTHON scripting needs a full
 pcbnew rebuild, probably around 15 min… :)
 
 Miguel Angel Ajo
 http://www.nbee.es 
 +34911407752
 skype: ajoajoajo
 
 On 11/03/2013, at 15:26, Miguel Angel Ajo Pelayo >>> > wrote:
 
> I'm going to test it right now, give me 5 minutes :)
> 
> Miguel Angel Ajo
> http://www.nbee.es 
> +34911407752
> skype: ajoajoajo
> 
> On 11/03/2013, at 15:25, Dick Hollenbeck  > wrote:
> 
>> class PyLOCK
>> {
>>  PyGILState gil_state;
>> 
>> public:
>>  PyLOCK()  { gil_state = PyGILState_Ensure(); }
>>  ~PyLOCK() { PyGILState_Release( gil_state ); }
>> };
> 
 
>>> 
>>> 
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>> 
>> 
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 


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

Re: [Kicad-developers] Scripting on Windows Fix

[Miguel Angel Ajo Pelayo]

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

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


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

On 12/03/2013, at 01:37, Wayne Stambaugh  wrote:

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


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

Re: [Kicad-developers] Scripting on Windows Fix

[Wayne Stambaugh]

On 3/11/2013 7:48 PM, Miguel Angel Ajo Pelayo wrote:

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

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


in tool_modedit.cpp

it only needs to be KICAD_SCRIPTING, there is no WXPYTHON dependency in
the footprint wizard :-),


Sorry about that.  I didn't realize that wxPython was not in play here. 
 I incorrectly assumed since it was dealing with UI elements (the 
toolbar) that wxPython was in play.  I'll fix it to look for 
KICAD_SCRIPTING.


Wayne


when I made that I wanted to be scripting language agnostic, we can even
write C++ wizards with current
implementation just subclassing the FootprintWizard class
  (class_footprint_wizard.h/cpp) :)

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


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

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


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

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

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


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

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

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


class PyLOCK
{
   PyGILState gil_state;

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








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





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

Re: [Kicad-developers] Scripting on Windows Fix

[Miguel Angel Ajo Pelayo]

I get a crash too, sightly different, it's like if the GetParametersPageName 
was unable to build the passing parameters, hmmm….

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   pcbnew.bin  0x0001062ef38c 
PYTHON_FOOTPRINT_WIZARD::GetParameterPageName(int) + 140
1   pcbnew.bin  0x000105e664d7 
FOOTPRINT_WIZARD_FRAME::ReCreatePageList() + 199
2   pcbnew.bin  0x000105e643d8 
FOOTPRINT_WIZARD_FRAME::SelectFootprintWizard() + 456
3   pcbnew.bin  0x000105e66288 
FOOTPRINT_WIZARD_FRAME::FOOTPRINT_WIZARD_FRAME(FOOTPRINT_EDIT_FRAME*, 
wxSemaphore*, long) + 5480
4   pcbnew.bin  0x000105e64d0d 
FOOTPRINT_WIZARD_FRAME::FOOTPRINT_WIZARD_FRAME(FOOTPRINT_EDIT_FRAME*, 
wxSemaphore*, long) + 45
5   pcbnew.bin  0x000105eee068 
FOOTPRINT_EDIT_FRAME::Process_Special_Functions(wxCommandEvent&) + 3288
6   libwx_osx_cocoau-2.9.dylib  0x000106f2ce35 
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&) + 93


and this on the console:

calling GetParameterPageName()
Exception: GetParameterPageName() takes exactly 2 arguments (1 given)
 : 
./pcbnew.app/Contents/MacOS/pcbnew:


--

Dick, I think you reformatted the "(i)" etc inside commas , that are used to 
build the python object parameters, we cannot
change the spaces etc inside those lines.

 I'm revertingPyObject* arglist = Py_BuildValue( "( i )", aPage );  to  
PyObject* arglist = Py_BuildValue( "(i)", aPage );  (and all the others), and 
re-testing.

May be your class-locker works, and that's the crash brian is getting now :)


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

On 11/03/2013, at 22:26, Brian Sidebotham  wrote:

> 
> On 11 March 2013 08:12, Dick Hollenbeck  wrote:
> > I will commit something in a few minutes.
> >
> > Brian if you can test that please, then you are da man.
> 
> Its very late here, it was rushed, but I checked in something that might help.
> 
> in rev 3994.
> 
> Hi Dick,
> 
> rev 3994 still crashes at the same place - Py_DECREF( arglist ) Line 177 in 
> pcbnew_footprint_wizards.cpp rev 3994.
> 
> I will look into it and see what's up - in principle the rev changes look 
> entirely sane (and really neat!). I'll get to look at it real soon, but not 
> tonight unfortunately. I'll carry on with gdb and read some more about the 
> GIL to see what's up.
> 
> Thanks for your quick turn-around.
> 
> Brian.

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

Re: [Kicad-developers] Scripting on Windows Fix

[Miguel Angel Ajo Pelayo]

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

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


in tool_modedit.cpp

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

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


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

On 11/03/2013, at 15:30, Miguel Angel Ajo Pelayo  wrote:

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

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

Re: [Kicad-developers] Scripting on Windows Fix

[Brian Sidebotham]

On 11 March 2013 08:12, Dick Hollenbeck  wrote:

> > I will commit something in a few minutes.
> >
> > Brian if you can test that please, then you are da man.
>
> Its very late here, it was rushed, but I checked in something that might
> help.
>
> in rev 3994.
>

Hi Dick,

rev 3994 still crashes at the same place - Py_DECREF( arglist ) Line 177 in
pcbnew_footprint_wizards.cpp rev 3994.

I will look into it and see what's up - in principle the rev changes look
entirely sane (and really neat!). I'll get to look at it real soon, but not
tonight unfortunately. I'll carry on with gdb and read some more about the
GIL to see what's up.

Thanks for your quick turn-around.

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

Re: [Kicad-developers] Scripting on Windows Fix

[Miguel Angel Ajo Pelayo]

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

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

On 11/03/2013, at 15:26, Miguel Angel Ajo Pelayo  wrote:

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

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

Re: [Kicad-developers] Scripting on Windows Fix

[Miguel Angel Ajo Pelayo]

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

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

On 11/03/2013, at 15:25, Dick Hollenbeck  wrote:

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

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

Re: [Kicad-developers] Scripting on Windows Fix

[Dick Hollenbeck]

On 03/11/2013 03:50 AM, Miguel Angel Ajo Pelayo wrote:
> Thanks dick, 
> I think the class constructor it's a very clean/smart  solution (set
> and forget at block level).
>
> I wonder if the wx/python , takes care of double-locks from the same
> thread.


Good question, can you find out please?
If not, some protection against this would be prudent.

>
>
> Totally right, was thinking the same, just that we don't have
> concurrency now without wxpython running on top, doesn't mean that
> this won't happen at any time:
> 0
> public:
>  
> 51
> // @todo: this is wrong, python docs clearly say we need the GIL,
>  
> 52
> // irrespective of wxPython.
>
>
> At that point without wx I think we should do this: 
>

Right, why put a time bomb in your jock strap?


> PyGILState_STATEgstate;   
> gstate = PyGILState_Ensure();
>
> /* Perform Python actions here. */
> result = CallSomeFunction();
> /* evaluate result or handle exception */
>
> /* Release the thread. No Python API allowed beyond this point. */
> PyGILState_Release(gstate);
>

>From reading the docs, that should do it.  We put the return value of
PyGILState_Ensure() into an instance variable within PyLOCK:


class PyLOCK
{
PyGILState gil_state;

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


If you can test that on some platform, and it works, it will likely
work on all.  I'm in meetings rest of today.  Thanks for the suggestion.



>
> About the coding style fixes, I must reread the coding style policy,
> and use uncrustify + diff before any push, it seems that
> at that time I was yet unaware of some coding policies.




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

Re: [Kicad-developers] Scripting on Windows Fix

[Miguel Angel Ajo Pelayo]

Thanks dick, 
I think the class constructor it's a very clean/smart  solution (set and forget 
at block level).

I wonder if the wx/python , takes care of double-locks from the same thread.


Totally right, was thinking the same, just that we don't have concurrency now 
without wxpython running on top, doesn't mean that this won't happen at any 
time:
0public:
 51// @todo: this is wrong, python docs clearly say we need the GIL,
 52// irrespective of wxPython.


At that point without wx I think we should do this: 

PyGILState_STATE gstate;   
gstate = PyGILState_Ensure();

/* Perform Python actions here. */
result = CallSomeFunction();
/* evaluate result or handle exception */

/* Release the thread. No Python API allowed beyond this point. */
PyGILState_Release(gstate);


About the coding style fixes, I must reread the coding style policy, and use 
uncrustify + diff before any push, it seems that
at that time I was yet unaware of some coding policies.




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

On 11/03/2013, at 09:12, Dick Hollenbeck  wrote:

>> I will commit something in a few minutes.
>> 
>> Brian if you can test that please, then you are da man.
> 
> Its very late here, it was rushed, but I checked in something that might help.
> 
> in rev 3994.

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

Re: [Kicad-developers] Scripting on Windows Fix

[Brian Sidebotham]

On 11 March 2013 08:12, Dick Hollenbeck  wrote:

> > I will commit something in a few minutes.
> >
> > Brian if you can test that please, then you are da man.
>
> Its very late here, it was rushed, but I checked in something that might
> help.
>
> in rev 3994.
>

Thanks Dick and Miguel!

I will have to check that tonight Dick, but thanks for the explanation and
quick turn-around. Hopefully this'll fix things up in KiCad and then it's
just external issues to deal with in order to build the scripting support
into KiCad in an easier fashion. At the moment it's still a bit manual.

Thanks for both of your time.

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

Re: [Kicad-developers] Scripting on Windows Fix

[Dick Hollenbeck]

> I will commit something in a few minutes.
>
> Brian if you can test that please, then you are da man.

Its very late here, it was rushed, but I checked in something that might help.

in rev 3994.

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

Re: [Kicad-developers] Scripting on Windows Fix

[Dick Hollenbeck]

On Sun, Mar 10, 2013 at 6:53 PM, Miguel Angel Ajo Pelayo
 wrote:
> I'm starting to remember, yes,
>
> scripting/python_scripting.h:#define PY_BLOCK_THREADS(name)wxPyBlock_t 
> name = wxPyBeginBlockThreads()
> scripting/python_scripting.h:#define PY_BLOCK_THREADS(name)
>
>
> We needed that blocking, because, when using wxpython, If I'm not wrong (and 
> I use to be more often than I like),
> when using wxpython, the event loop is handled from python itself, that means 
> that at any time we call
> most probably we're making a concurrent call to python's VM.
>
> I think that you not only fixed a bug for windows, but for a broader 
> audience, only that other audiences where
> not "lucky" enough to get the into the concurrence problems,
>
> I misplaced the wxPyBeginBlockThreads, that also needed to protect other 
> calls to python runtimes….
>
> but ok, that's a start, I must re-investigate how that wxPython thing worked….
>
> thanks again Brian!! :)

Now at my computer, instead of phone, so I can do more digging.
I was thinking the lock used thread local storage, and it was not
being setup correctly at dll initialization time.

It looks like Miguel is right and Brian's patch is a step in the right
direction:


http://docs.python.org/2/c-api/init.html#thread-state-and-the-global-interpreter-lock

But I don't think the patch goes far enough, and when using lock's
I've had good results with C++ wrapper classes to get the unlocking
right.

For locks like this I like to use C++'s constructor and destructor to
ensure that the unlock is called, even if there is an exception or a
programmer bug, and that a well defined scope is in play.

I will commit something in a few minutes.

Brian if you can test that please, then you are da man.

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

Re: [Kicad-developers] Scripting on Windows Fix

[Dick Hollenbeck]

On Mar 10, 2013 4:52 PM, "Brian Sidebotham" 
wrote:
>
> Hi Guys,
>
> I have "fixed" the final issue with python scripting on Windows. I've
attached a patch which fixes the sigsegv problem I see on Windows.
>
> I'd like to discuss it so that I can fully understand why this fixes the
issue, or if this is simply a kludge that's putting a plaster on a bone
break.
>
> The issue boiled down to the following code in
pcbnew_footprint_wizards.cpp:
>
> /* Time to call the callback */
> arglist = Py_BuildValue( "(i)", aPage );
> result = CallMethod( "GetParameterPageName", arglist );
> Py_DECREF( arglist );
>
> There was a SIGSEGV in Py_DECREF( arglist ). In Py_DECREF() the code was
breaking in tupledealloc() (in Objects/tupleobject.c).
>
> The specific issue was in the macro Py_TRASHCAN_SAFE_BEGIN(op) where
PyThreadState_GET() returns NULL.

It looks like that null is unexpected.  I thought we were seeing a thread
context fetch function returning null earlier also, during dll
initialization.  Might be same underlying problem.

Dllmain () function as I recall, was calling a thread context function and
coming up dry.

See if they are related by common data or variable name of a saved value.

Is this "thread local storage" failing?

The next line would SIGSEV.
>
> The PY_BLOCK_THREADS( ) and PY_UNBLOCK_THREADS( ) macro's surrounding the
python calls appear to fix the thread state issue.
>
> I haven't had a chance to look into wxPyBeginBlockThreads() yet to see
what's going on.
>
> The trouble is that I don't really understand what is going on. I could
do with someone versed in python extensions explaining the use of the GIL
and the PY_BLOCK_THREADS and PY_UNBLOCK_THREADS macros for me so I can
understand some more.
>
> I've also attached a quick image of the footprint wizard working okay. It
generates footprints successfully with this patch in place. So at least
that's something positive! :D
>
> I'm interested to understand what is wrong here. Why does Linux (and
presumably MAC) work okay without doing this?
>
> Perhaps the Windows build is broken in some other way that shouldn't be
fixed like this?
>
> At least there is progress.
>
> Best Regards, Brian.
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Scripting on Windows Fix

[Miguel Angel Ajo Pelayo]

I'm starting to remember, yes,

scripting/python_scripting.h:#define PY_BLOCK_THREADS(name)wxPyBlock_t name 
= wxPyBeginBlockThreads()
scripting/python_scripting.h:#define PY_BLOCK_THREADS(name)


We needed that blocking, because, when using wxpython, If I'm not wrong (and I 
use to be more often than I like), 
when using wxpython, the event loop is handled from python itself, that means 
that at any time we call
most probably we're making a concurrent call to python's VM.

I think that you not only fixed a bug for windows, but for a broader audience, 
only that other audiences where 
not "lucky" enough to get the into the concurrence problems, 

I misplaced the wxPyBeginBlockThreads, that also needed to protect other calls 
to python runtimes….

but ok, that's a start, I must re-investigate how that wxPython thing worked….

thanks again Brian!! :)


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

On 11/03/2013, at 00:26, Miguel Angel Ajo Pelayo  wrote:

> Awesome!, 
> 
>Brian, I'm sorry that I left that gift for you to debug. I really don't 
> understand the situation yet, It's supposed that 
> one must block the python VM thread before launching any new call into it.  
> All the call methods should be 
> surrounded by the lock, because python VM always run in a single thread, even 
> if you launch a thread inside, they
> won't even run in parallel as the VM can't (one of biggest python failures)
> 
>It clearly seems that also building values, or even using the Py_DECREF to 
> dereference a created
> value needs to be locked too.
> 
>   Thanks brian, I must finish something for a deadline tomorrow (taking 
> longer than expected, and spent more 
> time on Kicad that I should have spent) but I really want to discover the 
> underlying reason.
> 
> Miguel Angel Ajo
> http://www.nbee.es
> +34911407752
> skype: ajoajoajo
> 
> On 10/03/2013, at 23:52, Brian Sidebotham  wrote:
> 
>> Hi Guys,
>> 
>> I have "fixed" the final issue with python scripting on Windows. I've 
>> attached a patch which fixes the sigsegv problem I see on Windows.
>> 
>> I'd like to discuss it so that I can fully understand why this fixes the 
>> issue, or if this is simply a kludge that's putting a plaster on a bone 
>> break.
>> 
>> The issue boiled down to the following code in pcbnew_footprint_wizards.cpp:
>> 
>> /* Time to call the callback */
>>arglist = Py_BuildValue( "(i)", aPage );
>>result = CallMethod( "GetParameterPageName", arglist );
>>Py_DECREF( arglist );
>> 
>> There was a SIGSEGV in Py_DECREF( arglist ). In Py_DECREF() the code was 
>> breaking in tupledealloc() (in Objects/tupleobject.c).
>> 
>> The specific issue was in the macro Py_TRASHCAN_SAFE_BEGIN(op) where 
>> PyThreadState_GET() returns NULL. The next line would SIGSEV.
>> 
>> The PY_BLOCK_THREADS( ) and PY_UNBLOCK_THREADS( ) macro's surrounding the 
>> python calls appear to fix the thread state issue.
>> 
>> I haven't had a chance to look into wxPyBeginBlockThreads() yet to see 
>> what's going on.
>> 
>> The trouble is that I don't really understand what is going on. I could do 
>> with someone versed in python extensions explaining the use of the GIL and 
>> the PY_BLOCK_THREADS and PY_UNBLOCK_THREADS macros for me so I can 
>> understand some more.
>> 
>> I've also attached a quick image of the footprint wizard working okay. It 
>> generates footprints successfully with this patch in place. So at least 
>> that's something positive! :D
>> 
>> I'm interested to understand what is wrong here. Why does Linux (and 
>> presumably MAC) work okay without doing this?
>> 
>> Perhaps the Windows build is broken in some other way that shouldn't be 
>> fixed like this?
>> 
>> At least there is progress.
>> 
>> Best Regards, Brian.
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 


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

Re: [Kicad-developers] Scripting on Windows Fix

[Miguel Angel Ajo Pelayo]

Awesome!, 

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

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

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

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

On 10/03/2013, at 23:52, Brian Sidebotham  wrote:

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


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

Re: [Kicad-developers] scripting ppa builds failing

[Dick Hollenbeck]

On 03/08/2013 11:47 AM, Dick Hollenbeck wrote:
> On 03/08/2013 07:22 AM, Adam Wolf wrote:
>> If no one else will get to it until tomorrow, I can test this and
>> submit the patch tomorrow.  Somehow I'm doubting it'll last that
>> long, but if it does, it'll be my first patch to Kicad!
>
> Thanks Adam.  It's possible you can trace the macros

err...  cmake symbols.

>  all the way up
> into the find python module, and direct them to your staging directory
> by use of the proper define on the command line.
>
> If you are lucky  :)
>
> Otherwise not.
>
>


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

Re: [Kicad-developers] scripting ppa builds failing

[Dick Hollenbeck]

On 03/08/2013 07:22 AM, Adam Wolf wrote:
> If no one else will get to it until tomorrow, I can test this and
> submit the patch tomorrow.  Somehow I'm doubting it'll last that
> long, but if it does, it'll be my first patch to Kicad!


Thanks Adam.  It's possible you can trace the macros all the way up
into the find python module, and direct them to your staging directory
by use of the proper define on the command line.

If you are lucky  :)

Otherwise not.



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

Re: [Kicad-developers] scripting ppa builds failing

[Adam Wolf]

If no one else will get to it until tomorrow, I can test this and submit
the patch tomorrow.  Somehow I'm doubting it'll last that long, but if it
does, it'll be my first patch to Kicad!

Adam Wolf
Wayne and Layne, LLC


On Fri, Mar 8, 2013 at 6:40 AM, Dick Hollenbeck  wrote:

>
> On Mar 8, 2013 6:07 AM, "Dick Hollenbeck"  wrote:
> >
> > Check the install command in cmakelists.txt.  it should not have a / in
> front of usr.
>
> On the ppa server the install will alway go into a staging directory, for
> susequent packaging.
>
>
> >
> > On Mar 8, 2013 2:02 AM, "Hans Henry von Tresckow" 
> wrote:
> >>
> >> I just noticed that the nightly builds for the scripting branch are
> failing with the following message in the buildlog:
> >>
> >> -- Installing: /usr/lib/python2.7/dist-packages/pcbnew.py
> >> CMake Error at cmake_install.cmake:54 (FILE):
> >>   file INSTALL cannot copy file
> >>
> "/build/buildd/kicad-0.201303071307+3986~13~precise1/build/kicad/pcbnew/pcbnew.py"
> >>   to "/usr/lib/python2.7/dist-packages/pcbnew.py".
> >>
> >> It looks like python 2.7 is being installed, so maybe pcbnew.py is not
> getting built.
> >>
> >> --
> >> Henry von Tresckow (hvontres)
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] scripting ppa builds failing

[Dick Hollenbeck]

On Mar 8, 2013 6:07 AM, "Dick Hollenbeck"  wrote:
>
> Check the install command in cmakelists.txt.  it should not have a / in
front of usr.

On the ppa server the install will alway go into a staging directory, for
susequent packaging.


>
> On Mar 8, 2013 2:02 AM, "Hans Henry von Tresckow" 
wrote:
>>
>> I just noticed that the nightly builds for the scripting branch are
failing with the following message in the buildlog:
>>
>> -- Installing: /usr/lib/python2.7/dist-packages/pcbnew.py
>> CMake Error at cmake_install.cmake:54 (FILE):
>>   file INSTALL cannot copy file
>>
"/build/buildd/kicad-0.201303071307+3986~13~precise1/build/kicad/pcbnew/pcbnew.py"
>>   to "/usr/lib/python2.7/dist-packages/pcbnew.py".
>>
>> It looks like python 2.7 is being installed, so maybe pcbnew.py is not
getting built.
>>
>> --
>> Henry von Tresckow (hvontres)
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] scripting ppa builds failing

[Dick Hollenbeck]

Check the install command in cmakelists.txt.  it should not have a / in
front of usr.
 On Mar 8, 2013 2:02 AM, "Hans Henry von Tresckow" 
wrote:

> I just noticed that the nightly builds for the scripting branch are
> failing with the following message in the buildlog:
>
> -- Installing: /usr/lib/python2.7/dist-packages/pcbnew.py
> CMake Error at cmake_install.cmake:54 (FILE):
>   file INSTALL cannot copy file
>
> "/build/buildd/kicad-0.201303071307+3986~13~precise1/build/kicad/pcbnew/pcbnew.py"
>   to "/usr/lib/python2.7/dist-packages/pcbnew.py".
>
> It looks like python 2.7 is being installed, so maybe pcbnew.py is not
> getting built.
>
> --
> Henry von Tresckow (hvontres)
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://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] scripting ppa builds failing

[Hans Henry von Tresckow]

I just noticed that the nightly builds for the scripting branch are failing
with the following message in the buildlog:

-- Installing: /usr/lib/python2.7/dist-packages/pcbnew.py
CMake Error at cmake_install.cmake:54 (FILE):
  file INSTALL cannot copy file

"/build/buildd/kicad-0.201303071307+3986~13~precise1/build/kicad/pcbnew/pcbnew.py"
  to "/usr/lib/python2.7/dist-packages/pcbnew.py".

It looks like python 2.7 is being installed, so maybe pcbnew.py is not
getting built.

--
Henry von Tresckow (hvontres)
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Scripting build on Windows

[Brian Sidebotham]

Hi Wayne,

Thanks for this reply, it helps a lot. I believe that the pcbnew .a file
was built and I placed this in the standard python 2.7 lib directory along
with the .pyd file.

I'll start having a look at this again soon so that we can work out what to
do regarding python scripting on Windows builds.

Best Regards, Brian.


On 2 November 2012 13:52, Wayne Stambaugh  wrote:

> On 11/2/2012 6:21 AM, Brian Sidebotham wrote:
>
>> On 31 October 2012 06:16, Miguel Angel Ajo Pelayo > > wrote:
>>
>> Hi Brian, I'm not sure how dependent is wxPython on Cairo, if it's
>> recommended as '0' but they enable it,
>> may by it's needed. But it's just a feeling, 0-knowledge.
>>
>> Do you have some branch for this that I could replicate and play
>> around to figure out what's happening?
>> or it's tested manually at the moment?
>>
>> Also a binary package (with some debug info) could do the trick for me
>>
>> I'd like to trace that wxpython init call down, and find where does
>> it stop (and why).
>>
>> Thanks a lot for your effort,
>>
>> Mike,
>>
>>
>> Hi Mike,
>> I had to stop looking at the build for a while, but I should get another
>> chance to look at it earlier next week. It would seem that we need to
>> compile Python with MinGW, and wxPython.
>>
>> I had a quick look at the source for Inkscape and they have a separate
>> repository which includes a pre-built python for Windows which gets
>> included with their installer. They do not have it as a build process
>> for building Inkscape though, only as a separate pre-built binary:
>> https://launchpad.net/**inkscape-devlibs
>>
>> I suspect this may have to be the route that KiCad goes down in order to
>> package the new scripting functionality. At least it means that we can
>> totally control the python version on Windows.
>>
>> I don't have a branch, but maybe I should create one. It is likely there
>> will have to be changes in order to build scripting support for Windows.
>> Even the find_package( stuff uses the registry (yuck!) entries to
>> discover where python is located and this will always be wrong because
>> we are using MinGW to build the KiCad binaries, not MSVC which the
>> standard python install is built with.
>>
>> Best Regards, Brian.
>>
>
> Brian,
>
> I wanted to respond to this a few days ago but I had a system hard drive
> failure and I've spent all week recovering my development system.  You
> shouldn't have to build Python and wxPython from source with MinGW to get
> this to work.  The MinGW version of GCC can link to MSVC libraries.  You
> have to create the library link file using pexports which is an optional
> part of MinGW.  The instructions on how to do this can be found here:
> http://www.mingw.org/wiki/**MSVC_and_MinGW_DLLs.
>  I've created Python libraries this way so I know this works.  I would
> think as long as you are using the same version of wxPython and wxWidgets
> you should be OK.  The tricky part may be making sure to include all of the
> library dependencies for wxWidgets, wxPython, and Python the installer.  I
> assuming that you would want to just include a stand alone copy of Python
> similar to the bazaar windows installer rather than download and install
> Python and have the user deal with path issues.  I plan on trying to build
> the KiCad python scripting from source over the next few days.  If I manage
> do discover anything useful, I will pass that information along to you.
>
> Wayne
>
>
>
>>
>>
>> __**_
>> Mailing list: 
>> https://launchpad.net/~kicad-**developers
>> Post to : 
>> kicad-developers@lists.**launchpad.net
>> Unsubscribe : 
>> https://launchpad.net/~kicad-**developers
>> More help   : 
>> https://help.launchpad.net/**ListHelp
>>
>>
>
> __**_
> Mailing list: 
> https://launchpad.net/~kicad-**developers
> Post to : 
> kicad-developers@lists.**launchpad.net
> Unsubscribe : 
> https://launchpad.net/~kicad-**developers
> More help   : 
> https://help.launchpad.net/**ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Scripting build on Windows

[Carl Rash]

Windows allows exporting DLL objects by ordinal rather than name, removing
the C++ name decoration issue.

-Original Message-
From: kicad-developers-bounces+crash=triad.rr@lists.launchpad.net
[mailto:kicad-developers-bounces+crash=triad.rr@lists.launchpad.net] On
Behalf Of Dick Hollenbeck
Sent: Friday, November 02, 2012 10:17 AM
To: kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] Scripting build on Windows

On 11/02/2012 08:52 AM, Wayne Stambaugh wrote:
> On 11/2/2012 6:21 AM, Brian Sidebotham wrote:
>> On 31 October 2012 06:16, Miguel Angel Ajo Pelayo 
>> mailto:miguelan...@nbee.es>> wrote:
>>
>> Hi Brian, I'm not sure how dependent is wxPython on Cairo, if it's
>> recommended as '0' but they enable it,
>> may by it's needed. But it's just a feeling, 0-knowledge.
>>
>> Do you have some branch for this that I could replicate and play
>> around to figure out what's happening?
>> or it's tested manually at the moment?
>>
>> Also a binary package (with some debug info) could do the trick 
>> for me
>>
>> I'd like to trace that wxpython init call down, and find where does
>> it stop (and why).
>>
>> Thanks a lot for your effort,
>>
>> Mike,
>>
>>
>> Hi Mike,
>> I had to stop looking at the build for a while, but I should get 
>> another chance to look at it earlier next week. It would seem that we 
>> need to compile Python with MinGW, and wxPython.
>>
>> I had a quick look at the source for Inkscape and they have a 
>> separate repository which includes a pre-built python for Windows 
>> which gets included with their installer. They do not have it as a 
>> build process for building Inkscape though, only as a separate pre-built
binary:
>> https://launchpad.net/inkscape-devlibs
>>
>> I suspect this may have to be the route that KiCad goes down in order 
>> to package the new scripting functionality. At least it means that we 
>> can totally control the python version on Windows.
>>
>> I don't have a branch, but maybe I should create one. It is likely 
>> there will have to be changes in order to build scripting support for
Windows.
>> Even the find_package( stuff uses the registry (yuck!) entries to 
>> discover where python is located and this will always be wrong 
>> because we are using MinGW to build the KiCad binaries, not MSVC 
>> which the standard python install is built with.
>>
>> Best Regards, Brian.
> Brian,
>
> I wanted to respond to this a few days ago but I had a system hard 
> drive failure and I've spent all week recovering my development 
> system.  You shouldn't have to build Python and wxPython from source 
> with MinGW to get this to work.  The MinGW version of GCC can link to MSVC
libraries.
>   You have to create the library link file using pexports which is an 
> optional part of MinGW.  The instructions on how to do this can be 
> found
> here: http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs.  I've created 
> Python libraries this way so I know this works.  I would think as long 
> as you are using the same version of wxPython and wxWidgets you should 
> be OK.  The tricky part may be making sure to include all of the 
> library dependencies for wxWidgets, wxPython, and Python the 
> installer.  I assuming that you would want to just include a stand 
> alone copy of Python similar to the bazaar windows installer rather 
> than download and install Python and have the user deal with path 
> issues.  I plan on trying to build the KiCad python scripting from 
> source over the next few days.  If I manage do discover anything 
> useful, I will pass that information along to you.
>
> Wayne


Windows does have a common ABI for calling DLL's which should be compiler
vendor agnostic, at least for C code.  C++ will offer different name
mangling strategies to trip on.

Getting static libraries to come in is slightly more difficult because of
potential static library file formats. 

But the ABI for passing parameters in registers and on the stack should be
unified between VC and Mingw, for functions declared as DLL entrypoints.

Dick


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


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

Re: [Kicad-developers] Scripting build on Windows

[Dick Hollenbeck]

On 11/02/2012 08:52 AM, Wayne Stambaugh wrote:
> On 11/2/2012 6:21 AM, Brian Sidebotham wrote:
>> On 31 October 2012 06:16, Miguel Angel Ajo Pelayo > > wrote:
>>
>> Hi Brian, I'm not sure how dependent is wxPython on Cairo, if it's
>> recommended as '0' but they enable it,
>> may by it's needed. But it's just a feeling, 0-knowledge.
>>
>> Do you have some branch for this that I could replicate and play
>> around to figure out what's happening?
>> or it's tested manually at the moment?
>>
>> Also a binary package (with some debug info) could do the trick for me
>>
>> I'd like to trace that wxpython init call down, and find where does
>> it stop (and why).
>>
>> Thanks a lot for your effort,
>>
>> Mike,
>>
>>
>> Hi Mike,
>> I had to stop looking at the build for a while, but I should get another
>> chance to look at it earlier next week. It would seem that we need to
>> compile Python with MinGW, and wxPython.
>>
>> I had a quick look at the source for Inkscape and they have a separate
>> repository which includes a pre-built python for Windows which gets
>> included with their installer. They do not have it as a build process
>> for building Inkscape though, only as a separate pre-built binary:
>> https://launchpad.net/inkscape-devlibs
>>
>> I suspect this may have to be the route that KiCad goes down in order to
>> package the new scripting functionality. At least it means that we can
>> totally control the python version on Windows.
>>
>> I don't have a branch, but maybe I should create one. It is likely there
>> will have to be changes in order to build scripting support for Windows.
>> Even the find_package( stuff uses the registry (yuck!) entries to
>> discover where python is located and this will always be wrong because
>> we are using MinGW to build the KiCad binaries, not MSVC which the
>> standard python install is built with.
>>
>> Best Regards, Brian.
> Brian,
>
> I wanted to respond to this a few days ago but I had a system hard drive 
> failure and I've spent all week recovering my development system.  You 
> shouldn't have to build Python and wxPython from source with MinGW to 
> get this to work.  The MinGW version of GCC can link to MSVC libraries. 
>   You have to create the library link file using pexports which is an 
> optional part of MinGW.  The instructions on how to do this can be found 
> here: http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs.  I've created 
> Python libraries this way so I know this works.  I would think as long 
> as you are using the same version of wxPython and wxWidgets you should 
> be OK.  The tricky part may be making sure to include all of the library 
> dependencies for wxWidgets, wxPython, and Python the installer.  I 
> assuming that you would want to just include a stand alone copy of 
> Python similar to the bazaar windows installer rather than download and 
> install Python and have the user deal with path issues.  I plan on 
> trying to build the KiCad python scripting from source over the next few 
> days.  If I manage do discover anything useful, I will pass that 
> information along to you.
>
> Wayne


Windows does have a common ABI for calling DLL's which should be compiler 
vendor agnostic,
at least for C code.  C++ will offer different name mangling strategies to trip 
on.

Getting static libraries to come in is slightly more difficult because of 
potential static
library file formats. 

But the ABI for passing parameters in registers and on the stack should be 
unified between
VC and Mingw, for functions declared as DLL entrypoints.

Dick


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

Re: [Kicad-developers] Scripting build on Windows

[Dick Hollenbeck]

What I see from the 50,000 ft. view:


a) KiCad for windows is best built with a 2.9.x wx.


b) we really are only trying to achieve support for "the windows user compiling 
KiCad",
since that is what we change and control, KiCad source code.   (Let's remember 
that the
linux user is not having to build python or wxPython, unless he wants to use a 
version of
wx different from what is in the package repo.  So why ask a Windows user to 
build
wxPython or python?)


c) This leads to the conclusion that *if* the "stock" wxPython for windows, or 
python for
windows for that matter do not dovetail nicely with our required version of wx 
(i.e.
2.9.x), then an option worthy of consideration is to simply supply those two 
(wxPython and
python) in binary from a download site, in a form compatible with our required 
wx version,
rather than KiCad windows users/builders/people having to build them (wxPython 
and
python).   This c) has an "if" statement in it, please don't miss that.   
Retained is the
windows user's ability to compile KiCad, but only KiCad, i.e. b).



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

Re: [Kicad-developers] Scripting build on Windows

[Wayne Stambaugh]

On 11/2/2012 6:21 AM, Brian Sidebotham wrote:

On 31 October 2012 06:16, Miguel Angel Ajo Pelayo mailto:miguelan...@nbee.es>> wrote:

Hi Brian, I'm not sure how dependent is wxPython on Cairo, if it's
recommended as '0' but they enable it,
may by it's needed. But it's just a feeling, 0-knowledge.

Do you have some branch for this that I could replicate and play
around to figure out what's happening?
or it's tested manually at the moment?

Also a binary package (with some debug info) could do the trick for me

I'd like to trace that wxpython init call down, and find where does
it stop (and why).

Thanks a lot for your effort,

Mike,


Hi Mike,
I had to stop looking at the build for a while, but I should get another
chance to look at it earlier next week. It would seem that we need to
compile Python with MinGW, and wxPython.

I had a quick look at the source for Inkscape and they have a separate
repository which includes a pre-built python for Windows which gets
included with their installer. They do not have it as a build process
for building Inkscape though, only as a separate pre-built binary:
https://launchpad.net/inkscape-devlibs

I suspect this may have to be the route that KiCad goes down in order to
package the new scripting functionality. At least it means that we can
totally control the python version on Windows.

I don't have a branch, but maybe I should create one. It is likely there
will have to be changes in order to build scripting support for Windows.
Even the find_package( stuff uses the registry (yuck!) entries to
discover where python is located and this will always be wrong because
we are using MinGW to build the KiCad binaries, not MSVC which the
standard python install is built with.

Best Regards, Brian.


Brian,

I wanted to respond to this a few days ago but I had a system hard drive 
failure and I've spent all week recovering my development system.  You 
shouldn't have to build Python and wxPython from source with MinGW to 
get this to work.  The MinGW version of GCC can link to MSVC libraries. 
 You have to create the library link file using pexports which is an 
optional part of MinGW.  The instructions on how to do this can be found 
here: http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs.  I've created 
Python libraries this way so I know this works.  I would think as long 
as you are using the same version of wxPython and wxWidgets you should 
be OK.  The tricky part may be making sure to include all of the library 
dependencies for wxWidgets, wxPython, and Python the installer.  I 
assuming that you would want to just include a stand alone copy of 
Python similar to the bazaar windows installer rather than download and 
install Python and have the user deal with path issues.  I plan on 
trying to build the KiCad python scripting from source over the next few 
days.  If I manage do discover anything useful, I will pass that 
information along to you.


Wayne





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




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

Re: [Kicad-developers] Scripting build on Windows

[Miguel Angel Ajo Pelayo]

Thanks a lot Brian, you're doing an awesome work!!!, it seems that it was
harder than expected, but it looks like you already found the way :)

May be it's worth asking them and using their binary build for Python, they
include gtk/etc, that can be useful to us... :), why replicating work?

We could bundle Python with kicad as they (and other) projects do.

Best regards,
Mike,


2012/11/2 Brian Sidebotham 

> On 31 October 2012 06:16, Miguel Angel Ajo Pelayo wrote:
>
>> Hi Brian, I'm not sure how dependent is wxPython on Cairo, if it's
>> recommended as '0' but they enable it,
>> may by it's needed. But it's just a feeling, 0-knowledge.
>>
>> Do you have some branch for this that I could replicate and play around
>> to figure out what's happening?
>> or it's tested manually at the moment?
>>
>> Also a binary package (with some debug info) could do the trick for me
>>
>> I'd like to trace that wxpython init call down, and find where does it
>> stop (and why).
>>
>> Thanks a lot for your effort,
>>
>> Mike,
>>
>>
> Hi Mike,
>
> I had to stop looking at the build for a while, but I should get another
> chance to look at it earlier next week. It would seem that we need to
> compile Python with MinGW, and wxPython.
>
> I had a quick look at the source for Inkscape and they have a separate
> repository which includes a pre-built python for Windows which gets
> included with their installer. They do not have it as a build process for
> building Inkscape though, only as a separate pre-built binary:
> https://launchpad.net/inkscape-devlibs
>
> I suspect this may have to be the route that KiCad goes down in order to
> package the new scripting functionality. At least it means that we can
> totally control the python version on Windows.
>
> I don't have a branch, but maybe I should create one. It is likely there
> will have to be changes in order to build scripting support for Windows.
> Even the find_package( stuff uses the registry (yuck!) entries to discover
> where python is located and this will always be wrong because we are using
> MinGW to build the KiCad binaries, not MSVC which the standard python
> install is built with.
>
> Best Regards, Brian.
>
>


-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Scripting build on Windows

[Brian Sidebotham]

On 31 October 2012 06:16, Miguel Angel Ajo Pelayo wrote:

> Hi Brian, I'm not sure how dependent is wxPython on Cairo, if it's
> recommended as '0' but they enable it,
> may by it's needed. But it's just a feeling, 0-knowledge.
>
> Do you have some branch for this that I could replicate and play around to
> figure out what's happening?
> or it's tested manually at the moment?
>
> Also a binary package (with some debug info) could do the trick for me
>
> I'd like to trace that wxpython init call down, and find where does it
> stop (and why).
>
> Thanks a lot for your effort,
>
> Mike,
>
>
Hi Mike,

I had to stop looking at the build for a while, but I should get another
chance to look at it earlier next week. It would seem that we need to
compile Python with MinGW, and wxPython.

I had a quick look at the source for Inkscape and they have a separate
repository which includes a pre-built python for Windows which gets
included with their installer. They do not have it as a build process for
building Inkscape though, only as a separate pre-built binary:
https://launchpad.net/inkscape-devlibs

I suspect this may have to be the route that KiCad goes down in order to
package the new scripting functionality. At least it means that we can
totally control the python version on Windows.

I don't have a branch, but maybe I should create one. It is likely there
will have to be changes in order to build scripting support for Windows.
Even the find_package( stuff uses the registry (yuck!) entries to discover
where python is located and this will always be wrong because we are using
MinGW to build the KiCad binaries, not MSVC which the standard python
install is built with.

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

Re: [Kicad-developers] Scripting build on Windows

[Miguel Angel Ajo Pelayo]

Hi Brian, I'm not sure how dependent is wxPython on Cairo, if it's
recommended as '0' but they enable it,
may by it's needed. But it's just a feeling, 0-knowledge.

Do you have some branch for this that I could replicate and play around to
figure out what's happening?
or it's tested manually at the moment?

Also a binary package (with some debug info) could do the trick for me

I'd like to trace that wxpython init call down, and find where does it stop
(and why).

Thanks a lot for your effort,

Mike,



2012/10/27 Brian Sidebotham 

> On 27 October 2012 08:16, Lorenzo Marcantonio
>  wrote:
> > On Fri, Oct 26, 2012 at 10:03:17PM +0100, Brian Sidebotham wrote:
> >> > Not sure if it's possible to remove the Cairo dependency in
> wxPython may
> >> > be it's worth trying.
> >
> > No you can't (under unix at least). wxPython uses wxWidget which is
> > based on gtk.
> >
> > gtk needs cairo for drawing the widgets.
> >
> > So cairo has to stay XD
> >
> > Also I'd suggest svg for web stuff since it's imaging model is almost
> > the same and it's client rendered...
> >
>
> Under Windows, removing Cairo should be fine. Straight from the wx sources:
>
> // Enable wxGraphicsContext implementation using Cairo library.
> //
> // This is not needed under Windows and detected automatically by configure
> // under other systems, however you may set this to 1 manually if you
> installed
> // Cairo under Windows yourself and prefer to use it instead the native
> GDI+
> // implementation.
> //
> // Default is 0
> //
> // Recommended setting: 0
> #define wxUSE_CAIRO 0
>
> For some reason through, the wxPython sources have set this to 1.
> Removing Cairo as a dependency under Windows should be run.
>
> Best Regards, Brian.
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>



-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Scripting build on Windows

[Brian Sidebotham]

On 27 October 2012 08:16, Lorenzo Marcantonio
 wrote:
> On Fri, Oct 26, 2012 at 10:03:17PM +0100, Brian Sidebotham wrote:
>> > Not sure if it's possible to remove the Cairo dependency in wxPython 
>> > may
>> > be it's worth trying.
>
> No you can't (under unix at least). wxPython uses wxWidget which is
> based on gtk.
>
> gtk needs cairo for drawing the widgets.
>
> So cairo has to stay XD
>
> Also I'd suggest svg for web stuff since it's imaging model is almost
> the same and it's client rendered...
>

Under Windows, removing Cairo should be fine. Straight from the wx sources:

// Enable wxGraphicsContext implementation using Cairo library.
//
// This is not needed under Windows and detected automatically by configure
// under other systems, however you may set this to 1 manually if you installed
// Cairo under Windows yourself and prefer to use it instead the native GDI+
// implementation.
//
// Default is 0
//
// Recommended setting: 0
#define wxUSE_CAIRO 0

For some reason through, the wxPython sources have set this to 1.
Removing Cairo as a dependency under Windows should be run.

Best Regards, Brian.

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

Re: [Kicad-developers] Scripting build on Windows

[Lorenzo Marcantonio]

On Fri, Oct 26, 2012 at 10:03:17PM +0100, Brian Sidebotham wrote:
> > Not sure if it's possible to remove the Cairo dependency in wxPython may
> > be it's worth trying.

No you can't (under unix at least). wxPython uses wxWidget which is
based on gtk.

gtk needs cairo for drawing the widgets.

So cairo has to stay XD

Also I'd suggest svg for web stuff since it's imaging model is almost
the same and it's client rendered...

-- 
Lorenzo Marcantonio
Logos Srl

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

Re: [Kicad-developers] Scripting build on Windows

[Brian Sidebotham]

On 26 October 2012 10:20, Miguel Angel Ajo Pelayo  wrote:
> Thanks for your effort Brian,
>
> Not sure if it's possible to remove the Cairo dependency in wxPython may
> be it's worth trying.
>
>In the other hand, I had some usage planned for Cairo (like SVG
> rendering, which could be *cool* when we wanted to build web services based
> in pcbnew libraries or similar, for example).
>
>   What do you think? :)
>
> 2012/10/26 Brian Sidebotham 
>>
>> On 25 October 2012 11:50, Brian Sidebotham 
>> wrote:
>> > On 25 October 2012 11:40, Miguel Angel Ajo Pelayo 
>> > wrote:
>> >>
>> >> You're right Brian, that's the reason why you couldn't see the
>> >> scripting
>> >> console button at the toolbar
>> >> and pcbnew didn't incorporate the scripting "ui" things inside, the
>> >> lack of
>> >> wxPython (that as far as I know
>> >> just substitute wx itself).
>> >>
>> >> I think there is another compile switch you must enable yet for
>> >> scripting:
>> >>
>> >> KICAD_SCRIPTING  <-- enables scripting inside pcbnew
>> >>
>> >> KICAD_SCRIPTING_MODULES <--- builds a pcbnew.dll for standalone python
>> >>
>> >> KICAD_SCRIPTING_WXPYTHON  < builds all the UI stuff dependent on
>> >> wxPython inside pcbnew
>> >>
>> >>
>> >> Thanks a lot for taking care of the windows build!! :)
>> >>
>> >
>> > Hi Miguel,
>> >
>> > I cheated by shifting the wxpython headers in to my wxWidgets source
>> > directory quickly and after building, PCBNEW failed to start because
>> > it couldn't init wxPython. So tonight I'll build wxPython from source
>> > and point KiCad towards it. That should get me a sane build on Windows
>> > and we can see how it goes from there.
>> >
>> > Luckily wxPython have a 2.9.4 source tree, which is what we need on
>> > Windows.
>> >
>> > Thanks for adding scripting support to KiCad! :-D
>> >
>> > Best Regards, Brian.
>>
>> I didn't have much time last night, but I pointed KiCad to wxPython
>> instead of wxWidgets for building. It got so far and choked because
>> wxPython appears to have a dependency on Cairo. It required too much
>> time to investigate last night, but I'll try and look at it again
>> tonight to see if that is a requirement, or if it is optional.
>>
>> If Cario's optional it'd be good to get rid of it, otherwise it'll be
>> another dependency to add to the list.
>>
>> Best Regards, Brian.

Well, removing Cairo didn't appear to harm the build, but I get the
following error when trying to start PCBNEW:

* Error importing the wxPython API! *

which is from /scripting/python_scripting.cpp

So further investigation is required as to why that is occurring. I
installed the _pcbnew.pyd lib under the python install in the DLLs
directory as I'm pretty sure that's the default PYTHONPATH.

...

Oh, the above error ocurrs after another error - "An application has
made an attempt to load the C runtime library incorrectly". I think
this is a rather large brick wall. The problem appears to stem from
the fact that python is built with Visual Studio, and I'm compiling
with MinGW. The C runtimes are incompatible as far as I'm aware, and
in which case the only solution (if Windows support is required) is to
build everything with Visual Studio, the same as Python - or else
compile our own Python and include it in the distribution on Windows.
The latter is how Inkscape deals with this problem.

That's what Google suggests anyway.

...

So further along, but not at the candy yet! ;-)

Best Regards, Brian.

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

Re: [Kicad-developers] Scripting build on Windows

[Lorenzo Marcantonio]

On Fri, Oct 26, 2012 at 09:41:52AM -0500, Dick Hollenbeck wrote:
> Where is the windows package management?

MSI actually is the package management system... it runs as a system
service with more privileges than administrator (useful to install
viruses XD)

-- 
Lorenzo Marcantonio
Logos Srl

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

Re: [Kicad-developers] Scripting build on Windows

[Dick Hollenbeck]

Where is the windows package management?

Where are the online source code and executable repositories?

Linux has had this support for what, 15 years or so?

Yet Windows has what share of the desktop market?

Color me baffled.

The sheeple aught to wake up and help themselves.

"Add / Remove Programs" is a package manager not.



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

Re: [Kicad-developers] Scripting build on Windows

[Miguel Angel Ajo Pelayo]

Thanks Brian,  It makes full sense to me,

In the end, with this dependency removed, the user can install cairo later
to it's python installation, and
make use of it if he wanted to do in his own scripts,

Cheers! :)

2012/10/26 Brian Sidebotham 

> On 26 October 2012 10:20, Miguel Angel Ajo Pelayo 
> wrote:
> > Thanks for your effort Brian,
> >
> > Not sure if it's possible to remove the Cairo dependency in wxPython
> may
> > be it's worth trying.
> >
> >In the other hand, I had some usage planned for Cairo (like SVG
> > rendering, which could be *cool* when we wanted to build web services
> based
> > in pcbnew libraries or similar, for example).
> >
> >   What do you think? :)
>
> As far as I know wxPython should be exposing the wxWidgets API to
> python. As such I don't see it getting merged into the main source
> tree if it brings a Cairo dependency with it. I'm not sure why it
> would have this dependency.
>
> The GAL project
> https://code.launchpad.net/~kicad-testing-committers/kicad/kicad-gal
> still rumbles on which will provide a much needed Graphics Abstraction
> Layer to KiCad. This means that Cario or Open-GL or ... can be used
> for the graphics backend, but more importantly it doesn't lock us in
> to a single backend. It's an important project and Torsten and Dick
> appear to have done a lot of work on it. It'll be very exciting to see
> the fruits of that work when it's merged in.
>
> So I don't think KiCad should have a Cario dependency directly. I will
> change the wxPython setup.h file tonight and build without cairo for
> Windows and we'll see how it goes.
>
> Best Regards, Brian.
>



-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Scripting build on Windows

[Brian Sidebotham]

On 26 October 2012 10:20, Miguel Angel Ajo Pelayo  wrote:
> Thanks for your effort Brian,
>
> Not sure if it's possible to remove the Cairo dependency in wxPython may
> be it's worth trying.
>
>In the other hand, I had some usage planned for Cairo (like SVG
> rendering, which could be *cool* when we wanted to build web services based
> in pcbnew libraries or similar, for example).
>
>   What do you think? :)

As far as I know wxPython should be exposing the wxWidgets API to
python. As such I don't see it getting merged into the main source
tree if it brings a Cairo dependency with it. I'm not sure why it
would have this dependency.

The GAL project
https://code.launchpad.net/~kicad-testing-committers/kicad/kicad-gal
still rumbles on which will provide a much needed Graphics Abstraction
Layer to KiCad. This means that Cario or Open-GL or ... can be used
for the graphics backend, but more importantly it doesn't lock us in
to a single backend. It's an important project and Torsten and Dick
appear to have done a lot of work on it. It'll be very exciting to see
the fruits of that work when it's merged in.

So I don't think KiCad should have a Cario dependency directly. I will
change the wxPython setup.h file tonight and build without cairo for
Windows and we'll see how it goes.

Best Regards, Brian.

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

Re: [Kicad-developers] Scripting build on Windows

[Miguel Angel Ajo Pelayo]

Thanks for your effort Brian,

Not sure if it's possible to remove the Cairo dependency in wxPython
may be it's worth trying.

   In the other hand, I had some usage planned for Cairo (like SVG
rendering, which could be *cool* when we wanted to build web services based
in pcbnew libraries or similar, for example).

  What do you think? :)

2012/10/26 Brian Sidebotham 

> On 25 October 2012 11:50, Brian Sidebotham 
> wrote:
> > On 25 October 2012 11:40, Miguel Angel Ajo Pelayo 
> wrote:
> >>
> >> You're right Brian, that's the reason why you couldn't see the scripting
> >> console button at the toolbar
> >> and pcbnew didn't incorporate the scripting "ui" things inside, the
> lack of
> >> wxPython (that as far as I know
> >> just substitute wx itself).
> >>
> >> I think there is another compile switch you must enable yet for
> scripting:
> >>
> >> KICAD_SCRIPTING  <-- enables scripting inside pcbnew
> >>
> >> KICAD_SCRIPTING_MODULES <--- builds a pcbnew.dll for standalone python
> >>
> >> KICAD_SCRIPTING_WXPYTHON  < builds all the UI stuff dependent on
> >> wxPython inside pcbnew
> >>
> >>
> >> Thanks a lot for taking care of the windows build!! :)
> >>
> >
> > Hi Miguel,
> >
> > I cheated by shifting the wxpython headers in to my wxWidgets source
> > directory quickly and after building, PCBNEW failed to start because
> > it couldn't init wxPython. So tonight I'll build wxPython from source
> > and point KiCad towards it. That should get me a sane build on Windows
> > and we can see how it goes from there.
> >
> > Luckily wxPython have a 2.9.4 source tree, which is what we need on
> Windows.
> >
> > Thanks for adding scripting support to KiCad! :-D
> >
> > Best Regards, Brian.
>
> I didn't have much time last night, but I pointed KiCad to wxPython
> instead of wxWidgets for building. It got so far and choked because
> wxPython appears to have a dependency on Cairo. It required too much
> time to investigate last night, but I'll try and look at it again
> tonight to see if that is a requirement, or if it is optional.
>
> If Cario's optional it'd be good to get rid of it, otherwise it'll be
> another dependency to add to the list.
>
> Best Regards, Brian.
>



-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Scripting build on Windows

[Brian Sidebotham]

On 25 October 2012 11:50, Brian Sidebotham  wrote:
> On 25 October 2012 11:40, Miguel Angel Ajo Pelayo  wrote:
>>
>> You're right Brian, that's the reason why you couldn't see the scripting
>> console button at the toolbar
>> and pcbnew didn't incorporate the scripting "ui" things inside, the lack of
>> wxPython (that as far as I know
>> just substitute wx itself).
>>
>> I think there is another compile switch you must enable yet for scripting:
>>
>> KICAD_SCRIPTING  <-- enables scripting inside pcbnew
>>
>> KICAD_SCRIPTING_MODULES <--- builds a pcbnew.dll for standalone python
>>
>> KICAD_SCRIPTING_WXPYTHON  < builds all the UI stuff dependent on
>> wxPython inside pcbnew
>>
>>
>> Thanks a lot for taking care of the windows build!! :)
>>
>
> Hi Miguel,
>
> I cheated by shifting the wxpython headers in to my wxWidgets source
> directory quickly and after building, PCBNEW failed to start because
> it couldn't init wxPython. So tonight I'll build wxPython from source
> and point KiCad towards it. That should get me a sane build on Windows
> and we can see how it goes from there.
>
> Luckily wxPython have a 2.9.4 source tree, which is what we need on Windows.
>
> Thanks for adding scripting support to KiCad! :-D
>
> Best Regards, Brian.

I didn't have much time last night, but I pointed KiCad to wxPython
instead of wxWidgets for building. It got so far and choked because
wxPython appears to have a dependency on Cairo. It required too much
time to investigate last night, but I'll try and look at it again
tonight to see if that is a requirement, or if it is optional.

If Cario's optional it'd be good to get rid of it, otherwise it'll be
another dependency to add to the list.

Best Regards, Brian.

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

Re: [Kicad-developers] Scripting build on Windows

[Brian Sidebotham]

On 25 October 2012 11:40, Miguel Angel Ajo Pelayo  wrote:
>
> You're right Brian, that's the reason why you couldn't see the scripting
> console button at the toolbar
> and pcbnew didn't incorporate the scripting "ui" things inside, the lack of
> wxPython (that as far as I know
> just substitute wx itself).
>
> I think there is another compile switch you must enable yet for scripting:
>
> KICAD_SCRIPTING  <-- enables scripting inside pcbnew
>
> KICAD_SCRIPTING_MODULES <--- builds a pcbnew.dll for standalone python
>
> KICAD_SCRIPTING_WXPYTHON  < builds all the UI stuff dependent on
> wxPython inside pcbnew
>
>
> Thanks a lot for taking care of the windows build!! :)
>

Hi Miguel,

I cheated by shifting the wxpython headers in to my wxWidgets source
directory quickly and after building, PCBNEW failed to start because
it couldn't init wxPython. So tonight I'll build wxPython from source
and point KiCad towards it. That should get me a sane build on Windows
and we can see how it goes from there.

Luckily wxPython have a 2.9.4 source tree, which is what we need on Windows.

Thanks for adding scripting support to KiCad! :-D

Best Regards, Brian.

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

Re: [Kicad-developers] Scripting build on Windows

[Miguel Angel Ajo Pelayo]

2012/10/25 Dick Hollenbeck 

> On 10/24/2012 03:20 PM, Miguel Angel Ajo Pelayo wrote:
> >
> > Wow wow woow!!! :D
> >
> > If you're using console Python, and call import pcbnew, then you should
> use
> > LoadBoard("x"),
> >
> >
> http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/view/head:/pcbnew/scripting/examples/listPcb.py
> > <
> http://bazaar.launchpad.net/%7Ekicad-testing-committers/kicad/testing/view/head:/pcbnew/scripting/examples/listPcb.py
> >
> >
> > if it's a pcbnew console inside pcbnew window, then It really seems like
> the pcbnew is
> > reloading the
> > pcbnew.dll and then GetBoard cannot find the "frame" pcb, in that case
> try to put the
> > .dll out of path
> > for the pcbnew .exe
>
>
> Is this theory anything? :
>
> Linux is I think a little more flexible on dynamic linking than windows
> is.  So we may
> have inadvertently become dependent on a feature of linux that will not be
> present on windows.
>
>
It seems only that wxPython was missing, but we will have to explore how
windows/python works related to the
dynamic load, Brian is our explorer... :)


> Namely, the ability to dynamically link to the startup image of the
> process, i.e. the main
> executable file, rather than the DSO.
>
> In window terms, that means that dynamically linking to the *.EXE is not
> analogously
> possible to my knowledge, only to a *.DLL.
>

I'm not sure to understand what you mean exactly,

   In windows you can dynamically load DLLs after the executable is
running, at any time, as Linux can do,
is that what you mean? :-)




>
>
>
>
> >
> > 2012/10/24 Brian Sidebotham  brian.sidebot...@gmail.com>>
> >
> > Hi guys,
> >
> > Last night I looked at building KiCad with scripting support. I
> merely
> > downloaded SWIG and added it to my build environment's path variable.
> >
> > A python install was detected by find_package(PythonLibs) so that was
> > good. Everything builds correctly as far as I can tell, but I don't
> > appear to be able to get a board instance from python.
> >
> > I paid attention to Miguel's note not to have the python lib in the
> > same directory as the PCBNEW executable, but I only ever get None
> > returned for GetBoard() in python.
> >
> > I've not used SWIG interfaces before so I'm unsure how to go about
> > debugging the interface between python and pcbnew.
> >
> > How can I tell if the PCBNEW lib is connected to the open PCBNEW or
> not?
> >
> > Thanks for any hints!
> >
> > Best Regards, Brian.
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > 
> > Post to : kicad-developers@lists.launchpad.net
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > 
> > More help   : https://help.launchpad.net/ListHelp
> >
> >
> >
> >
> > --
> >
> > Miguel Angel Ajo Pelayo
> > http://www.nbee.es
> > +34 636 52 25 69
> > skype: ajoajoajo
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>



-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Scripting build on Windows

[Miguel Angel Ajo Pelayo]

You're right Brian, that's the reason why you couldn't see the scripting
console button at the toolbar
and pcbnew didn't incorporate the scripting "ui" things inside, the lack of
wxPython (that as far as I know
just substitute wx itself).

I think there is another compile switch you must enable yet for scripting:

KICAD_SCRIPTING  <-- enables scripting inside pcbnew

KICAD_SCRIPTING_MODULES <--- builds a pcbnew.dll for standalone python

KICAD_SCRIPTING_WXPYTHON  < builds all the UI stuff dependent on
wxPython inside pcbnew


Thanks a lot for taking care of the windows build!! :)




2012/10/25 Brian Sidebotham 

> > Well, the version info is correct, in that the following is a result
> > of PCBNEW->Help->Copy Version Information:
> >
> > Application: Pcbnew
> > Version: (2012-10-23 BZR 3779)-testing
> > Build: wxWidgets 2.9.4 (wchar_t,compiler with C++ ABI 1002,GCC
> > 4.7.0,wx containers,compatible with 2.8)
> > Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64
> > bit, Little endian, wxMSW
> > Boost version: 1.49.0
> > Options: USE_PCBNEW_SEXPR_FILE_FORMAT=OFF
> >  USE_PCBNEW_NANOMETRES=ON
> >  USE_PCBNEW_SEXPR_FOOTPRINT_LIBS=OFF
> >  KICAD_GOST=OFF
> >  USE_WX_GRAPHICS_CONTEXT=OFF
> >  USE_WX_OVERLAY=OFF
> >  USE_BOOST_POLYGON_LIBRARY
> >  KICAD_SCRIPTING=ON
> >
> > But what I was after was a menu option, or some visual hint that
> > PCBNEW is honouring the scripting option. i.e. a menu option to show a
> > scripting option or something! :-)
> >
> > Anyway, I just installed wxPython-2.9.4 and am building against that
> > with the KICAD_SCRIPTING_WXPYTHON option now ON.
> >
> > Best Regards, Brian.
>
> I've grabbed wxPython. I have merely installed their binaries in the
> python install, and I've grabbed their dev files and moved the
> /include/wx/wxPython directory to my local wxWidgets build which gets
> built as part of the KiCadWinbuilder script. I assume that on Windows
> we will need to compile the wxPython source as our wxWidgets libs
> instead of a native wxWidgets install.
>
> Best Regards, Brian.
>



-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Scripting build on Windows

[Dick Hollenbeck]

On 10/24/2012 03:20 PM, Miguel Angel Ajo Pelayo wrote:
>
> Wow wow woow!!! :D
>
> If you're using console Python, and call import pcbnew, then you should use
> LoadBoard("x"),
>
> http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/view/head:/pcbnew/scripting/examples/listPcb.py
> 
>
> if it's a pcbnew console inside pcbnew window, then It really seems like the 
> pcbnew is
> reloading the
> pcbnew.dll and then GetBoard cannot find the "frame" pcb, in that case try to 
> put the
> .dll out of path
> for the pcbnew .exe


Is this theory anything? :

Linux is I think a little more flexible on dynamic linking than windows is.  So 
we may
have inadvertently become dependent on a feature of linux that will not be 
present on windows.

Namely, the ability to dynamically link to the startup image of the process, 
i.e. the main
executable file, rather than the DSO.

In window terms, that means that dynamically linking to the *.EXE is not 
analogously
possible to my knowledge, only to a *.DLL.




>
> 2012/10/24 Brian Sidebotham  >
>
> Hi guys,
>
> Last night I looked at building KiCad with scripting support. I merely
> downloaded SWIG and added it to my build environment's path variable.
>
> A python install was detected by find_package(PythonLibs) so that was
> good. Everything builds correctly as far as I can tell, but I don't
> appear to be able to get a board instance from python.
>
> I paid attention to Miguel's note not to have the python lib in the
> same directory as the PCBNEW executable, but I only ever get None
> returned for GetBoard() in python.
>
> I've not used SWIG interfaces before so I'm unsure how to go about
> debugging the interface between python and pcbnew.
>
> How can I tell if the PCBNEW lib is connected to the open PCBNEW or not?
>
> Thanks for any hints!
>
> Best Regards, Brian.
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
>
>
>
>
> -- 
>
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 636 52 25 69
> skype: ajoajoajo
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


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

Re: [Kicad-developers] Scripting build on Windows

[Brian Sidebotham]

> Well, the version info is correct, in that the following is a result
> of PCBNEW->Help->Copy Version Information:
>
> Application: Pcbnew
> Version: (2012-10-23 BZR 3779)-testing
> Build: wxWidgets 2.9.4 (wchar_t,compiler with C++ ABI 1002,GCC
> 4.7.0,wx containers,compatible with 2.8)
> Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64
> bit, Little endian, wxMSW
> Boost version: 1.49.0
> Options: USE_PCBNEW_SEXPR_FILE_FORMAT=OFF
>  USE_PCBNEW_NANOMETRES=ON
>  USE_PCBNEW_SEXPR_FOOTPRINT_LIBS=OFF
>  KICAD_GOST=OFF
>  USE_WX_GRAPHICS_CONTEXT=OFF
>  USE_WX_OVERLAY=OFF
>  USE_BOOST_POLYGON_LIBRARY
>  KICAD_SCRIPTING=ON
>
> But what I was after was a menu option, or some visual hint that
> PCBNEW is honouring the scripting option. i.e. a menu option to show a
> scripting option or something! :-)
>
> Anyway, I just installed wxPython-2.9.4 and am building against that
> with the KICAD_SCRIPTING_WXPYTHON option now ON.
>
> Best Regards, Brian.

I've grabbed wxPython. I have merely installed their binaries in the
python install, and I've grabbed their dev files and moved the
/include/wx/wxPython directory to my local wxWidgets build which gets
built as part of the KiCadWinbuilder script. I assume that on Windows
we will need to compile the wxPython source as our wxWidgets libs
instead of a native wxWidgets install.

Best Regards, Brian.

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

Re: [Kicad-developers] Scripting build on Windows

[Brian Sidebotham]

On 24 October 2012 23:32, Adam Wolf  wrote:
> While I don't want to pollute the title bar, would it be a good idea
> for us to mark scripting builds with -scripting like we do with
> testing?  This wouldn't be a long term thing--just until scripting
> support is in every single build.
>
> Adam Wolf

Well, the version info is correct, in that the following is a result
of PCBNEW->Help->Copy Version Information:

Application: Pcbnew
Version: (2012-10-23 BZR 3779)-testing
Build: wxWidgets 2.9.4 (wchar_t,compiler with C++ ABI 1002,GCC
4.7.0,wx containers,compatible with 2.8)
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64
bit, Little endian, wxMSW
Boost version: 1.49.0
Options: USE_PCBNEW_SEXPR_FILE_FORMAT=OFF
 USE_PCBNEW_NANOMETRES=ON
 USE_PCBNEW_SEXPR_FOOTPRINT_LIBS=OFF
 KICAD_GOST=OFF
 USE_WX_GRAPHICS_CONTEXT=OFF
 USE_WX_OVERLAY=OFF
 USE_BOOST_POLYGON_LIBRARY
 KICAD_SCRIPTING=ON

But what I was after was a menu option, or some visual hint that
PCBNEW is honouring the scripting option. i.e. a menu option to show a
scripting option or something! :-)

Anyway, I just installed wxPython-2.9.4 and am building against that
with the KICAD_SCRIPTING_WXPYTHON option now ON.

Best Regards, Brian.

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

Re: [Kicad-developers] Scripting build on Windows

[Adam Wolf]

While I don't want to pollute the title bar, would it be a good idea
for us to mark scripting builds with -scripting like we do with
testing?  This wouldn't be a long term thing--just until scripting
support is in every single build.

Adam Wolf

On Wed, Oct 24, 2012 at 5:27 PM, Brian Sidebotham
 wrote:
> On 24 October 2012 23:23, Brian Sidebotham  wrote:
>> On 24 October 2012 21:20, Miguel Angel Ajo Pelayo  
>> wrote:
>>>
>>> Wow wow woow!!! :D
>>>
>>> If you're using console Python, and call import pcbnew, then you should use
>>> LoadBoard("x"),
>>>
>>> http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/view/head:/pcbnew/scripting/examples/listPcb.py
>>>
>>> if it's a pcbnew console inside pcbnew window, then It really seems like the
>>> pcbnew is reloading the
>>> pcbnew.dll and then GetBoard cannot find the "frame" pcb, in that case try
>>> to put the .dll out of path
>>> for the pcbnew .exe
>>
>> Thanks for the info Miguel.
>>
>> I can't find any trace of scripting within PCBNEW in this build. Is
>> there something that would hint to me that it is actually a scripting
>> build?
>>
>> I don't see anything that will let me have a scripting window inside
>> the PCBNEW frame. I've tried moving the python.py _python.pyd and
>> libpcbnew.dll.a files outside of the bin directory, but with no
>> change. I have been simply running python from the console, but it
>> sounds like that's not right if I want to interact with PCBNEW
>> directly.
>>
>> The console mode appears to work fine for working on files and stuff
>> using the LoadBoard().
>>
>> Thanks for your continued work on scripting! :-)
>>
>> Best Regards, Brian.
>
> Ah, sorry for the lack of accurate information - I should add that I
> didn't enable the wxpython option as I wanted to keep things simple to
> begin with. Perhaps this is a pre-requisite of having a console window
> in PCBNEW?
>
> Best Regards, Brian.
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Scripting build on Windows

[Brian Sidebotham]

On 24 October 2012 23:23, Brian Sidebotham  wrote:
> On 24 October 2012 21:20, Miguel Angel Ajo Pelayo  wrote:
>>
>> Wow wow woow!!! :D
>>
>> If you're using console Python, and call import pcbnew, then you should use
>> LoadBoard("x"),
>>
>> http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/view/head:/pcbnew/scripting/examples/listPcb.py
>>
>> if it's a pcbnew console inside pcbnew window, then It really seems like the
>> pcbnew is reloading the
>> pcbnew.dll and then GetBoard cannot find the "frame" pcb, in that case try
>> to put the .dll out of path
>> for the pcbnew .exe
>
> Thanks for the info Miguel.
>
> I can't find any trace of scripting within PCBNEW in this build. Is
> there something that would hint to me that it is actually a scripting
> build?
>
> I don't see anything that will let me have a scripting window inside
> the PCBNEW frame. I've tried moving the python.py _python.pyd and
> libpcbnew.dll.a files outside of the bin directory, but with no
> change. I have been simply running python from the console, but it
> sounds like that's not right if I want to interact with PCBNEW
> directly.
>
> The console mode appears to work fine for working on files and stuff
> using the LoadBoard().
>
> Thanks for your continued work on scripting! :-)
>
> Best Regards, Brian.

Ah, sorry for the lack of accurate information - I should add that I
didn't enable the wxpython option as I wanted to keep things simple to
begin with. Perhaps this is a pre-requisite of having a console window
in PCBNEW?

Best Regards, Brian.

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

Re: [Kicad-developers] Scripting build on Windows

[Brian Sidebotham]

On 24 October 2012 21:20, Miguel Angel Ajo Pelayo  wrote:
>
> Wow wow woow!!! :D
>
> If you're using console Python, and call import pcbnew, then you should use
> LoadBoard("x"),
>
> http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/view/head:/pcbnew/scripting/examples/listPcb.py
>
> if it's a pcbnew console inside pcbnew window, then It really seems like the
> pcbnew is reloading the
> pcbnew.dll and then GetBoard cannot find the "frame" pcb, in that case try
> to put the .dll out of path
> for the pcbnew .exe

Thanks for the info Miguel.

I can't find any trace of scripting within PCBNEW in this build. Is
there something that would hint to me that it is actually a scripting
build?

I don't see anything that will let me have a scripting window inside
the PCBNEW frame. I've tried moving the python.py _python.pyd and
libpcbnew.dll.a files outside of the bin directory, but with no
change. I have been simply running python from the console, but it
sounds like that's not right if I want to interact with PCBNEW
directly.

The console mode appears to work fine for working on files and stuff
using the LoadBoard().

Thanks for your continued work on scripting! :-)

Best Regards, Brian.

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

Re: [Kicad-developers] Scripting build on Windows

[Miguel Angel Ajo Pelayo]

Wow wow woow!!! :D

If you're using console Python, and call import pcbnew, then you should use
LoadBoard("x"),

http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/view/head:/pcbnew/scripting/examples/listPcb.py

if it's a pcbnew console inside pcbnew window, then It really seems like
the pcbnew is reloading the
pcbnew.dll and then GetBoard cannot find the "frame" pcb, in that case try
to put the .dll out of path
for the pcbnew .exe

2012/10/24 Brian Sidebotham 

> Hi guys,
>
> Last night I looked at building KiCad with scripting support. I merely
> downloaded SWIG and added it to my build environment's path variable.
>
> A python install was detected by find_package(PythonLibs) so that was
> good. Everything builds correctly as far as I can tell, but I don't
> appear to be able to get a board instance from python.
>
> I paid attention to Miguel's note not to have the python lib in the
> same directory as the PCBNEW executable, but I only ever get None
> returned for GetBoard() in python.
>
> I've not used SWIG interfaces before so I'm unsure how to go about
> debugging the interface between python and pcbnew.
>
> How can I tell if the PCBNEW lib is connected to the open PCBNEW or not?
>
> Thanks for any hints!
>
> Best Regards, Brian.
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>



-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Scripting build on Windows

[Brian Sidebotham]

Hi guys,

Last night I looked at building KiCad with scripting support. I merely
downloaded SWIG and added it to my build environment's path variable.

A python install was detected by find_package(PythonLibs) so that was
good. Everything builds correctly as far as I can tell, but I don't
appear to be able to get a board instance from python.

I paid attention to Miguel's note not to have the python lib in the
same directory as the PCBNEW executable, but I only ever get None
returned for GetBoard() in python.

I've not used SWIG interfaces before so I'm unsure how to go about
debugging the interface between python and pcbnew.

How can I tell if the PCBNEW lib is connected to the open PCBNEW or not?

Thanks for any hints!

Best Regards, Brian.

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