kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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