kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

Agreed.

As someone who is likely to use the Python scripting much more than I
will submit patches in C++, I think this is entirely suitable.  Letting
Python scripting "bog down" development right now is a waste.  If someone
has some Python script that they think is their baby, they don't need to
update to something that is incompatible.  These are all development
releases, not "stable" ones.

Adam Wolf

On Thu, Mar 14, 2013 at 11:50 AM, Miguel Angel Ajo Pelayo <
miguelangel@xxxxxxx> wrote:

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