On 3/14/2013 12:50 PM, Miguel Angel Ajo Pelayo wrote: > > You're right, it will be hard to provide compatibility at that point without > doing an extensive/intensive work.
I think for stable releases we should be able to maintain compatibility for the most part. For those folks who like to bleed on the edge and use the testing branch, I don't think it is unfair to ask them to keep their scripts up to date as we make improvements to the code base. > > 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 <[email protected]> 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 <[email protected]> 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 : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
