Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[LordBlick]

In response to a message written on 20.01.2015, 21:15, from Bob Gustafson:

The idea of a 'Standalone' board design app is puzzling to me. If there is
anything in the project file that has project-wide scope, it seems to me that
trying to use the pcbnew application without that information would be
problematic. Maybe I am missing the concept?

Make an experiment - open standalone .kicad_pcb with no any other files in
current dir, then close. What's there new appears ? ;)
Supposedly pcbnew does not need this file ... The contradiction.


Experiment results:

[user1 empty]$ mkdir empty
[user1 empty]$ cd empty
[user1 empty]$ kicad_pcb
bash: kicad_pcb: command not found...
[user1 empty]$ .kicad_pcb
[user1 empty]$ ls
[user1 empty]$ ls -l
total 0
[user1 empty]$ ls -a
.   ..

I'm not sure what I should see..

$ mkdir empty
$ cd empty
$ cp ~/tmp/test.kicad_pcb .
$ ls
test.kicad_pcb
$ pcbnew test.kicad_pcb
sh: segmentation fault (core dumped)  pcbnew test.kicad_pcb
$ ls
test.kicad_pcb  test.pro

--
Best Regards,
LordBlick

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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Bob Gustafson]

On 01/20/2015 01:37 PM, LordBlick wrote:
In response to a message written on 20.01.2015, 20:02, from Bob 
Gustafson:

Is on a kicad roadmap multi-board projecting ? If no, there's no much
difference where one board settings are stored, regardlessly of how 
much

work was done…



The idea of a 'Standalone' board design app is puzzling to me. If 
there is
anything in the project file that has project-wide scope, it seems to 
me that

trying to use the pcbnew application without that information would be
problematic. Maybe I am missing the concept?
Make an experiment - open standalone .kicad_pcb with no any other 
files in

current dir, then close. What's there new appears ? ;)
Supposedly pcbnew does not need this file ... The contradiction.


Experiment results:

[user1 empty]$ mkdir empty
[user1 empty]$ cd empty
[user1 empty]$ kicad_pcb
bash: kicad_pcb: command not found...
[user1 empty]$ .kicad_pcb
[user1 empty]$ ls
[user1 empty]$ ls -l
total 0
[user1 empty]$ ls -a
.   ..

I'm not sure what I should see..

Best regards

Bob G




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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[LordBlick]

In response to a message written on 20.01.2015, 20:02, from Bob Gustafson:

Is on a kicad roadmap multi-board projecting ? If no, there's no much
difference where one board settings are stored, regardlessly of how much
work was done…



The idea of a 'Standalone' board design app is puzzling to me. If there is
anything in the project file that has project-wide scope, it seems to me that
trying to use the pcbnew application without that information would be
problematic. Maybe I am missing the concept?

Make an experiment - open standalone .kicad_pcb with no any other files in
current dir, then close. What's there new appears ? ;)
Supposedly pcbnew does not need this file ... The contradiction.

--
Best Regards,
LordBlick

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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[LordBlick]

In response to a message written on 20.01.2015, 18:53, from Tomasz Wlostowski:

Is on a kicad roadmap multi-board projecting ? If no, there's no much
difference where one board settings are stored, regardlessly of how much
work was done…



I'm not 100% sure what you mean by multi-board projects.  Are you talking
about multiple copies of the same board (arrays for panelization) or
different boards from a single schematic?  I'm not sure how the latter
would even work.  Generally speaking there is a one to one correlation
between a schematic and a board.  We sort of support multiple copies of the
same board using the append board feature.  The short answer to your
question is there are no plans for multi-board projects at this time.


I understood it as being able to design multiple PCBs from multiple schematic
files within a single project, i.e. split compiled schematic netlist across
multiple separate boards. Am I correct, LordBlick?

Yes, sure. Often one device account for a few PCB's, so that way can simplify
project organization. Today many users for each PCB has separate prj file while
the program doesn't encourage open multiple files at the same time displaying a
warning "KiCAD is already running".

--
Best Regards,
LordBlick

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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Bob Gustafson]

On 01/20/2015 10:04 AM, LordBlick wrote:
In response to a message written on 20.01.2015, 16:19, from Wayne 
Stambaugh:
I think that may be sufficient to add section [gal] to .pro file as 
usual

project setting. In this way you can avoid the next .kicad_pcb format
version change.



I'm not terribly thrilled about that idea.  One of the things we have 
changed
over the years is to move board specific settings out of the project 
file and
into the board file.  This makes the board file more portable. If you 
put
board configuration information in the project file, you will loose 
it when

you try to use the board file as a stand alone board. Ultimately, the
project file should only contain settings that have project wide 
scope. All
board and schematic specific configuration should be saved in the 
appropriate

file.
Is on a kicad roadmap multi-board projecting ? If no, there's no much 
difference
where one board settings are stored, regardlessly of how much work was 
done…




The idea of a 'Standalone' board design app is puzzling to me. If there 
is anything in the project file that has project-wide scope, it seems to 
me that trying to use the pcbnew application without that information 
would be problematic. Maybe I am missing the concept?


Bob G

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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Lorenzo Marcantonio]

On Tue, Jan 20, 2015 at 04:47:27PM +0100, jp charras wrote:
> I am surprising by this sentence:
> 
> the page layout is set for schematic under [schematic_editor] and
> *separately set* for the board editor under [pcbnew]

Fine then; I didn't notice the change; IIRC there was one setting for
both, initially. However IMHO these are better
stored in the schema/pcb file (along with the title, page size and
stuff).

-- 
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] file version compatibility (optional tokens in s-expression files)

[Tomasz Wlostowski]

On 20.01.2015 18:42, Wayne Stambaugh wrote:
> On 1/20/2015 11:04 AM, LordBlick wrote:
>> In response to a message written on 20.01.2015, 16:19, from Wayne
>> Stambaugh:
 I think that may be sufficient to add section [gal] to .pro file as
 usual
 project setting. In this way you can avoid the next .kicad_pcb format
 version change.

>>>
>>> I'm not terribly thrilled about that idea.  One of the things we have
>>> changed
>>> over the years is to move board specific settings out of the project
>>> file and
>>> into the board file.  This makes the board file more portable.  If you
>>> put
>>> board configuration information in the project file, you will loose it
>>> when
>>> you try to use the board file as a stand alone board.  Ultimately, the
>>> project file should only contain settings that have project wide
>>> scope. All
>>> board and schematic specific configuration should be saved in the
>>> appropriate
>>> file.
>> Is on a kicad roadmap multi-board projecting ? If no, there's no much
>> difference
>> where one board settings are stored, regardlessly of how much work was
>> done…
>>
> 
> I'm not 100% sure what you mean by multi-board projects.  Are you
> talking about multiple copies of the same board (arrays for
> panelization) or different boards from a single schematic?  I'm not sure
> how the latter would even work.  Generally speaking there is a one to
> one correlation between a schematic and a board.  We sort of support
> multiple copies of the same board using the append board feature.  The
> short answer to your question is there are no plans for multi-board
> projects at this time.

I understood it as being able to design multiple PCBs from multiple
schematic files within a single project, i.e. split compiled schematic
netlist across multiple separate boards. Am I correct, LordBlick?

Tom

> 
> 
> ___
> 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] file version compatibility (optional tokens in s-expression files)

[Wayne Stambaugh]

On 1/20/2015 12:07 PM, Tomasz Wlostowski wrote:
> On 20.01.2015 17:58, Wayne Stambaugh wrote:
>> On 1/20/2015 10:51 AM, Tomasz Wlostowski wrote:
>>> On 20.01.2015 16:19, Wayne Stambaugh wrote:
 On 1/20/2015 12:44 AM, LordBlick wrote:
> In response to a message written on 13.01.2015, 19:20, from Tomasz
> Wlostowski:
>> Hi all,
>>
>> During my work on diff pairs/matched length tools, I've encountered a
>> rather tricky problem: as the diff pair gap specific to a particular
>> pair of traces is stored nowhere, the shove algorithm will mess up DP
>> coupling after saving and re-loading the board. Ergo: the DP gaps (and
>> possibly other settings) need to be stored somewhere in .kicad_pcb
>> files. Perhaps in a yet another s-expr token.
>>
>> The problem is that adding any new token to the file format causes all
>> precedent versions of pcbnew to drop an error attempting to load the
>> file. I would propose two solutions to overcome this:
>> - (a dumb one) if the version in the file header is newer than the
>> version supported by the running application, issue warnings instead of
>> fatal errors on unknown tokens,
>> - (a bit smarter) enclose all optional tokens in a "minimum" version
>> block ( min_version version_number ( optional_token ( ... ) ) ) that
>> would be ignored if the application version < version_number.
>>
>> I consider this modification quite important from the point of view of
>> adding future features and the upcoming stable version: if we keep
>> things as they are, adding any new feature will either make the files
>> unreadable to the stable version or force us to support saving in
>> multiple format versions.
>>
>> Looking forward to your feedback,
>> Tom
> I think that may be sufficient to add section [gal] to .pro file as
> usual project setting. In this way you can avoid the next .kicad_pcb
> format version change.
>

 I'm not terribly thrilled about that idea.  One of the things we have
 changed over the years is to move board specific settings out of the
 project file and into the board file.  This makes the board file more
 portable. 
>>>
>>> Hi Wayne,
>>>
>>> Fully agree here. What I meant when I started this thread was defining a
>>> way to store more complex DRC constraints than simple clearance/track
>>> width. The current model can't handle differential pair and constrained
>>> trace length. Such parameters surely belong to a PCB design, so their
>>> place is IMHO in the .kicad_pcb file.
>>>
>>> Anyway, for the first release of the new P&S features, I'm not going to
>>> modify the file format.
>>>
>>> Cheers,
>>> Tom
>>>
>>
>> Hey Tom,
>>
>> If it is important to save the design settings, now would be the time to
>> make any file changes rather than after the stable release.  We know we
>> are already going to have issues with users who upgrade from the current
>> stable release due to layer name translations and the 32 to 64 layer
>> transition.  I would rather get it over with now than drag it out over
>> the next development cycle.
> 
> Hi Wayne,
> 
> I meant the merge of diff pairs into product branch, so that people
> could already test and profit from the new features. I hope we'll have
> the time to define and implement file format upgrades before the stable
> release goes out.
> 
> Cheers,
> Tom
> 

That makes sense to me.  I'm sure there are a few users who are looking
forward to trying out the diff pair feature.


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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Wayne Stambaugh]

On 1/20/2015 11:04 AM, LordBlick wrote:
> In response to a message written on 20.01.2015, 16:19, from Wayne
> Stambaugh:
>>> I think that may be sufficient to add section [gal] to .pro file as
>>> usual
>>> project setting. In this way you can avoid the next .kicad_pcb format
>>> version change.
>>>
>>
>> I'm not terribly thrilled about that idea.  One of the things we have
>> changed
>> over the years is to move board specific settings out of the project
>> file and
>> into the board file.  This makes the board file more portable.  If you
>> put
>> board configuration information in the project file, you will loose it
>> when
>> you try to use the board file as a stand alone board.  Ultimately, the
>> project file should only contain settings that have project wide
>> scope. All
>> board and schematic specific configuration should be saved in the
>> appropriate
>> file.
> Is on a kicad roadmap multi-board projecting ? If no, there's no much
> difference
> where one board settings are stored, regardlessly of how much work was
> done…
> 

I'm not 100% sure what you mean by multi-board projects.  Are you
talking about multiple copies of the same board (arrays for
panelization) or different boards from a single schematic?  I'm not sure
how the latter would even work.  Generally speaking there is a one to
one correlation between a schematic and a board.  We sort of support
multiple copies of the same board using the append board feature.  The
short answer to your question is there are no plans for multi-board
projects at this time.


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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Tomasz Wlostowski]

On 20.01.2015 17:58, Wayne Stambaugh wrote:
> On 1/20/2015 10:51 AM, Tomasz Wlostowski wrote:
>> On 20.01.2015 16:19, Wayne Stambaugh wrote:
>>> On 1/20/2015 12:44 AM, LordBlick wrote:
 In response to a message written on 13.01.2015, 19:20, from Tomasz
 Wlostowski:
> Hi all,
>
> During my work on diff pairs/matched length tools, I've encountered a
> rather tricky problem: as the diff pair gap specific to a particular
> pair of traces is stored nowhere, the shove algorithm will mess up DP
> coupling after saving and re-loading the board. Ergo: the DP gaps (and
> possibly other settings) need to be stored somewhere in .kicad_pcb
> files. Perhaps in a yet another s-expr token.
>
> The problem is that adding any new token to the file format causes all
> precedent versions of pcbnew to drop an error attempting to load the
> file. I would propose two solutions to overcome this:
> - (a dumb one) if the version in the file header is newer than the
> version supported by the running application, issue warnings instead of
> fatal errors on unknown tokens,
> - (a bit smarter) enclose all optional tokens in a "minimum" version
> block ( min_version version_number ( optional_token ( ... ) ) ) that
> would be ignored if the application version < version_number.
>
> I consider this modification quite important from the point of view of
> adding future features and the upcoming stable version: if we keep
> things as they are, adding any new feature will either make the files
> unreadable to the stable version or force us to support saving in
> multiple format versions.
>
> Looking forward to your feedback,
> Tom
 I think that may be sufficient to add section [gal] to .pro file as
 usual project setting. In this way you can avoid the next .kicad_pcb
 format version change.

>>>
>>> I'm not terribly thrilled about that idea.  One of the things we have
>>> changed over the years is to move board specific settings out of the
>>> project file and into the board file.  This makes the board file more
>>> portable. 
>>
>> Hi Wayne,
>>
>> Fully agree here. What I meant when I started this thread was defining a
>> way to store more complex DRC constraints than simple clearance/track
>> width. The current model can't handle differential pair and constrained
>> trace length. Such parameters surely belong to a PCB design, so their
>> place is IMHO in the .kicad_pcb file.
>>
>> Anyway, for the first release of the new P&S features, I'm not going to
>> modify the file format.
>>
>> Cheers,
>> Tom
>>
> 
> Hey Tom,
> 
> If it is important to save the design settings, now would be the time to
> make any file changes rather than after the stable release.  We know we
> are already going to have issues with users who upgrade from the current
> stable release due to layer name translations and the 32 to 64 layer
> transition.  I would rather get it over with now than drag it out over
> the next development cycle.

Hi Wayne,

I meant the merge of diff pairs into product branch, so that people
could already test and profit from the new features. I hope we'll have
the time to define and implement file format upgrades before the stable
release goes out.

Cheers,
Tom

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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Wayne Stambaugh]

On 1/20/2015 10:51 AM, Tomasz Wlostowski wrote:
> On 20.01.2015 16:19, Wayne Stambaugh wrote:
>> On 1/20/2015 12:44 AM, LordBlick wrote:
>>> In response to a message written on 13.01.2015, 19:20, from Tomasz
>>> Wlostowski:
 Hi all,

 During my work on diff pairs/matched length tools, I've encountered a
 rather tricky problem: as the diff pair gap specific to a particular
 pair of traces is stored nowhere, the shove algorithm will mess up DP
 coupling after saving and re-loading the board. Ergo: the DP gaps (and
 possibly other settings) need to be stored somewhere in .kicad_pcb
 files. Perhaps in a yet another s-expr token.

 The problem is that adding any new token to the file format causes all
 precedent versions of pcbnew to drop an error attempting to load the
 file. I would propose two solutions to overcome this:
 - (a dumb one) if the version in the file header is newer than the
 version supported by the running application, issue warnings instead of
 fatal errors on unknown tokens,
 - (a bit smarter) enclose all optional tokens in a "minimum" version
 block ( min_version version_number ( optional_token ( ... ) ) ) that
 would be ignored if the application version < version_number.

 I consider this modification quite important from the point of view of
 adding future features and the upcoming stable version: if we keep
 things as they are, adding any new feature will either make the files
 unreadable to the stable version or force us to support saving in
 multiple format versions.

 Looking forward to your feedback,
 Tom
>>> I think that may be sufficient to add section [gal] to .pro file as
>>> usual project setting. In this way you can avoid the next .kicad_pcb
>>> format version change.
>>>
>>
>> I'm not terribly thrilled about that idea.  One of the things we have
>> changed over the years is to move board specific settings out of the
>> project file and into the board file.  This makes the board file more
>> portable. 
> 
> Hi Wayne,
> 
> Fully agree here. What I meant when I started this thread was defining a
> way to store more complex DRC constraints than simple clearance/track
> width. The current model can't handle differential pair and constrained
> trace length. Such parameters surely belong to a PCB design, so their
> place is IMHO in the .kicad_pcb file.
> 
> Anyway, for the first release of the new P&S features, I'm not going to
> modify the file format.
> 
> Cheers,
> Tom
> 

Hey Tom,

If it is important to save the design settings, now would be the time to
make any file changes rather than after the stable release.  We know we
are already going to have issues with users who upgrade from the current
stable release due to layer name translations and the 32 to 64 layer
transition.  I would rather get it over with now than drag it out over
the next development cycle.

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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[LordBlick]

In response to a message written on 20.01.2015, 16:19, from Wayne Stambaugh:

I think that may be sufficient to add section [gal] to .pro file as usual
project setting. In this way you can avoid the next .kicad_pcb format
version change.



I'm not terribly thrilled about that idea.  One of the things we have changed
over the years is to move board specific settings out of the project file and
into the board file.  This makes the board file more portable.  If you put
board configuration information in the project file, you will loose it when
you try to use the board file as a stand alone board.  Ultimately, the
project file should only contain settings that have project wide scope. All
board and schematic specific configuration should be saved in the appropriate
file.

Is on a kicad roadmap multi-board projecting ? If no, there's no much difference
where one board settings are stored, regardlessly of how much work was done…

--
Best Regards,
LordBlick

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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Wayne Stambaugh]

On 1/20/2015 10:27 AM, Lorenzo Marcantonio wrote:
> On Tue, Jan 20, 2015 at 10:19:08AM -0500, Wayne Stambaugh wrote:
>> I'm not terribly thrilled about that idea.  One of the things we have
>> changed over the years is to move board specific settings out of the
>> project file and into the board file.  This makes the board file more
>> portable.  If you put board configuration information in the project
> 
> If you look into the project file there is *almost* nothing that
> couldn't be more usefully placed in the board or schematic files...
> 
> Even the page layout should be chosen at the application level, not at
> the project level (it's confusing for the user too: sets the page layout
> in pcbnew and it get's changed in eeschema!).
> 
> The problem at the moment is that some 'root' level information don't
> have a good place in eeschema (since there is no concept of 'root sheet'
> in itself to keep them).
> 

The schematic file issues will be addressed when the new schematic file
format is implemented.  Hopefully that will happen not too long after
the next stable release so I don't want to make any changes to the
current schematic file format between now and then.

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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Tomasz Wlostowski]

On 20.01.2015 16:19, Wayne Stambaugh wrote:
> On 1/20/2015 12:44 AM, LordBlick wrote:
>> In response to a message written on 13.01.2015, 19:20, from Tomasz
>> Wlostowski:
>>> Hi all,
>>>
>>> During my work on diff pairs/matched length tools, I've encountered a
>>> rather tricky problem: as the diff pair gap specific to a particular
>>> pair of traces is stored nowhere, the shove algorithm will mess up DP
>>> coupling after saving and re-loading the board. Ergo: the DP gaps (and
>>> possibly other settings) need to be stored somewhere in .kicad_pcb
>>> files. Perhaps in a yet another s-expr token.
>>>
>>> The problem is that adding any new token to the file format causes all
>>> precedent versions of pcbnew to drop an error attempting to load the
>>> file. I would propose two solutions to overcome this:
>>> - (a dumb one) if the version in the file header is newer than the
>>> version supported by the running application, issue warnings instead of
>>> fatal errors on unknown tokens,
>>> - (a bit smarter) enclose all optional tokens in a "minimum" version
>>> block ( min_version version_number ( optional_token ( ... ) ) ) that
>>> would be ignored if the application version < version_number.
>>>
>>> I consider this modification quite important from the point of view of
>>> adding future features and the upcoming stable version: if we keep
>>> things as they are, adding any new feature will either make the files
>>> unreadable to the stable version or force us to support saving in
>>> multiple format versions.
>>>
>>> Looking forward to your feedback,
>>> Tom
>> I think that may be sufficient to add section [gal] to .pro file as
>> usual project setting. In this way you can avoid the next .kicad_pcb
>> format version change.
>>
> 
> I'm not terribly thrilled about that idea.  One of the things we have
> changed over the years is to move board specific settings out of the
> project file and into the board file.  This makes the board file more
> portable. 

Hi Wayne,

Fully agree here. What I meant when I started this thread was defining a
way to store more complex DRC constraints than simple clearance/track
width. The current model can't handle differential pair and constrained
trace length. Such parameters surely belong to a PCB design, so their
place is IMHO in the .kicad_pcb file.

Anyway, for the first release of the new P&S features, I'm not going to
modify the file format.

Cheers,
Tom




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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[jp charras]

Le 20/01/2015 16:27, Lorenzo Marcantonio a écrit :
> On Tue, Jan 20, 2015 at 10:19:08AM -0500, Wayne Stambaugh wrote:
>> I'm not terribly thrilled about that idea.  One of the things we have
>> changed over the years is to move board specific settings out of the
>> project file and into the board file.  This makes the board file more
>> portable.  If you put board configuration information in the project
> 
> If you look into the project file there is *almost* nothing that
> couldn't be more usefully placed in the board or schematic files...

Most of these settings are already saved in the .kicad_pcb files
They are useful as default settings for new boards.

> 
> Even the page layout should be chosen at the application level, not at
> the project level

What do you mean ?
This is the same thing for me.

 (it's confusing for the user too: sets the page layout
> in pcbnew and it get's changed in eeschema!).

I am surprising by this sentence:

the page layout is set for schematic under [schematic_editor] and
*separately set* for the board editor under [pcbnew]

> 
> The problem at the moment is that some 'root' level information don't
> have a good place in eeschema (since there is no concept of 'root sheet'
> in itself to keep them).
> 

This is surely the next major change needed in Eeschema.

-- 
Jean-Pierre CHARRAS

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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Lorenzo Marcantonio]

On Tue, Jan 20, 2015 at 10:19:08AM -0500, Wayne Stambaugh wrote:
> I'm not terribly thrilled about that idea.  One of the things we have
> changed over the years is to move board specific settings out of the
> project file and into the board file.  This makes the board file more
> portable.  If you put board configuration information in the project

If you look into the project file there is *almost* nothing that
couldn't be more usefully placed in the board or schematic files...

Even the page layout should be chosen at the application level, not at
the project level (it's confusing for the user too: sets the page layout
in pcbnew and it get's changed in eeschema!).

The problem at the moment is that some 'root' level information don't
have a good place in eeschema (since there is no concept of 'root sheet'
in itself to keep them).

-- 
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] file version compatibility (optional tokens in s-expression files)

[Wayne Stambaugh]

On 1/20/2015 12:44 AM, LordBlick wrote:
> In response to a message written on 13.01.2015, 19:20, from Tomasz
> Wlostowski:
>> Hi all,
>>
>> During my work on diff pairs/matched length tools, I've encountered a
>> rather tricky problem: as the diff pair gap specific to a particular
>> pair of traces is stored nowhere, the shove algorithm will mess up DP
>> coupling after saving and re-loading the board. Ergo: the DP gaps (and
>> possibly other settings) need to be stored somewhere in .kicad_pcb
>> files. Perhaps in a yet another s-expr token.
>>
>> The problem is that adding any new token to the file format causes all
>> precedent versions of pcbnew to drop an error attempting to load the
>> file. I would propose two solutions to overcome this:
>> - (a dumb one) if the version in the file header is newer than the
>> version supported by the running application, issue warnings instead of
>> fatal errors on unknown tokens,
>> - (a bit smarter) enclose all optional tokens in a "minimum" version
>> block ( min_version version_number ( optional_token ( ... ) ) ) that
>> would be ignored if the application version < version_number.
>>
>> I consider this modification quite important from the point of view of
>> adding future features and the upcoming stable version: if we keep
>> things as they are, adding any new feature will either make the files
>> unreadable to the stable version or force us to support saving in
>> multiple format versions.
>>
>> Looking forward to your feedback,
>> Tom
> I think that may be sufficient to add section [gal] to .pro file as
> usual project setting. In this way you can avoid the next .kicad_pcb
> format version change.
> 

I'm not terribly thrilled about that idea.  One of the things we have
changed over the years is to move board specific settings out of the
project file and into the board file.  This makes the board file more
portable.  If you put board configuration information in the project
file, you will loose it when you try to use the board file as a stand
alone board.  Ultimately, the project file should only contain settings
that have project wide scope.  All board and schematic specific
configuration should be saved in the appropriate file.


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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[LordBlick]

In response to a message written on 13.01.2015, 19:20, from Tomasz Wlostowski:

Hi all,

During my work on diff pairs/matched length tools, I've encountered a
rather tricky problem: as the diff pair gap specific to a particular
pair of traces is stored nowhere, the shove algorithm will mess up DP
coupling after saving and re-loading the board. Ergo: the DP gaps (and
possibly other settings) need to be stored somewhere in .kicad_pcb
files. Perhaps in a yet another s-expr token.

The problem is that adding any new token to the file format causes all
precedent versions of pcbnew to drop an error attempting to load the
file. I would propose two solutions to overcome this:
- (a dumb one) if the version in the file header is newer than the
version supported by the running application, issue warnings instead of
fatal errors on unknown tokens,
- (a bit smarter) enclose all optional tokens in a "minimum" version
block ( min_version version_number ( optional_token ( ... ) ) ) that
would be ignored if the application version < version_number.

I consider this modification quite important from the point of view of
adding future features and the upcoming stable version: if we keep
things as they are, adding any new feature will either make the files
unreadable to the stable version or force us to support saving in
multiple format versions.

Looking forward to your feedback,
Tom
I think that may be sufficient to add section [gal] to .pro file as usual 
project setting. In this way you can avoid the next .kicad_pcb format version 
change.


--
Best Regards,
LordBlick

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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Tomasz Wlostowski]

On 15.01.2015 23:40, Miguel Ángel Ajo wrote:
> I was talking about Altium in my previous email, and I believe
> the points you made are quite reasonable (in favor and against).
Hi Miguel,

Fully agree here.
> 
> I also didn’t know about the measures of not saving the unchanged
> defaults, which are quite neat.
Me neither. Did anybody propose to *not* save settings that are
considered default by the current version? What if these defaults need
to be changed (for whatever reason)?

> What about a flag in the loader parameters, disabled by default, but which 
> could be
> used via scripting for extreme situations (recovery of broken files?). Dumping
> warnings to stdout should be ok.
Fine for me.

Cheers,
Tom

> 
> 
> Miguel Ángel Ajo
> 
> 
> On Thursday, 15 de January de 2015 at 21:37, Kaspar Emanuel wrote:
> 
>> My 2c: let the parser ignore unknown/incompatible s-expressions and warn the 
>> user when they are encountered.  
>>  
>> On 14 January 2015 at 22:24, Martijn Kuipers > (mailto:martijn.kuip...@gmail.com)> wrote:
>>>  
 On 14 Jan 2015, at 21:07, Cirilo Bernardo >>> (mailto:cirilo.berna...@gmail.com)> wrote:
  
  
 On Thu, Jan 15, 2015 at 3:27 AM, Tomasz Wlostowski 
 mailto:tomasz.wlostow...@cern.ch)> wrote:
> On 13.01.2015 20:11, Wayne Stambaugh wrote:
>> This is a tricky issue that has been discussed before.  The general
>> consensus in the past has been not to support forward compatibility.  It
>> increases maintenance and complexity of the file parser for a minimal
>> net gain to the user.  My preference is to force users that want to
>> bleed on the edge to use nightly builds rather than try to maintain any
>> forward file compatibility.
 [snip]  
> OK, how about this:
> - No extra version tokens (fits point A)
> - Warning instead of error on unrecognized tokens (point C - no big
> changes needed in the parser)
> - If the opened file is produced by a newer version of Kicad, issue a
> big warning when the user attempts to save it, that certain features
> will be lost (points B and D - if somebody complains we can always tell
> him he was warned). AFAIK this is what most commercial software does.
>  
> Cheers,
> Tom
  
 Except for Acrobat Reader, all the other software I use simply tells me it
 cannot load the new file. In a corporate environment and especially on
 large projects no one wants to take the risk that someone obliterated some
 data. Let's say Person A sends Person B a file with data missing - what
 can Person B possibly do with that now? Person B was never aware of the
 warning that Person A ignored and the software is not psychic so it cannot
 say "hey, the last time you worked on this file it was Version X.Z, not 
 X.Y".
 The problem gets worse and more difficult to detect as the project gets
 more complex. People need to understand the limitations of their tools and
 work with that.  As I said before people can negotiate what version they
 need and if necessary build/install to support a specific project. 
 Otherwise
 why use file versions at all if we're essentially only using it to tell if 
 there
 are newer features and essentially ignore it and write corrupted data 
 anyway?
  
>>>  
>>>  
>>> I would be very happy with backward compatibility, especially if it would 
>>> allow us to safe the file in the older format.
>>> This way, not everybody in the team needs to have the same version to be 
>>> able to work.
>>>  
>>> Of course, if someone saves it in the new format, then I would not expect 
>>> an older kicad to be able to read it.  
>>> Wayne could even decide that every format-change implies a version number 
>>> increment, so we can tell the user to install kicad newer than version x.y
>>>  
>>> I also think, this is not something that will happen every day, so we 
>>> should not overdesign this. Forward compatibility for a EDA tool is not 
>>> something I would advice, as there are just to many things that can go 
>>> wrong.
>>>  
>>> If it makes things simples, an external file-format converter would also be 
>>> fine.
>>>  
>>> Just my 2 cents,
>>> Martijn
>>>  
>>>  
 - Cirilo ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net 
 (mailto:kicad-developers@lists.launchpad.net)
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
>>>  
>>>  
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net 
>>> (mailto:kicad-developers@lists.launchpad.net)
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>  
>>  
>> ___

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Miguel Ángel Ajo]

I was talking about Altium in my previous email, and I believe
the points you made are quite reasonable (in favor and against).

I also didn’t know about the measures of not saving the unchanged
defaults, which are quite neat.

What about a flag in the loader parameters, disabled by default, but which 
could be
used via scripting for extreme situations (recovery of broken files?). Dumping
warnings to stdout should be ok.


Miguel Ángel Ajo


On Thursday, 15 de January de 2015 at 21:37, Kaspar Emanuel wrote:

> My 2c: let the parser ignore unknown/incompatible s-expressions and warn the 
> user when they are encountered.  
>  
> On 14 January 2015 at 22:24, Martijn Kuipers  (mailto:martijn.kuip...@gmail.com)> wrote:
> >  
> > > On 14 Jan 2015, at 21:07, Cirilo Bernardo  > > (mailto:cirilo.berna...@gmail.com)> wrote:
> > >  
> > >  
> > > On Thu, Jan 15, 2015 at 3:27 AM, Tomasz Wlostowski 
> > > mailto:tomasz.wlostow...@cern.ch)> wrote:
> > > > On 13.01.2015 20:11, Wayne Stambaugh wrote:
> > > > > This is a tricky issue that has been discussed before.  The general
> > > > > consensus in the past has been not to support forward compatibility.  
> > > > > It
> > > > > increases maintenance and complexity of the file parser for a minimal
> > > > > net gain to the user.  My preference is to force users that want to
> > > > > bleed on the edge to use nightly builds rather than try to maintain 
> > > > > any
> > > > > forward file compatibility.
> > > [snip]  
> > > > OK, how about this:
> > > > - No extra version tokens (fits point A)
> > > > - Warning instead of error on unrecognized tokens (point C - no big
> > > > changes needed in the parser)
> > > > - If the opened file is produced by a newer version of Kicad, issue a
> > > > big warning when the user attempts to save it, that certain features
> > > > will be lost (points B and D - if somebody complains we can always tell
> > > > him he was warned). AFAIK this is what most commercial software does.
> > > >  
> > > > Cheers,
> > > > Tom
> > >  
> > > Except for Acrobat Reader, all the other software I use simply tells me it
> > > cannot load the new file. In a corporate environment and especially on
> > > large projects no one wants to take the risk that someone obliterated some
> > > data. Let's say Person A sends Person B a file with data missing - what
> > > can Person B possibly do with that now? Person B was never aware of the
> > > warning that Person A ignored and the software is not psychic so it cannot
> > > say "hey, the last time you worked on this file it was Version X.Z, not 
> > > X.Y".
> > > The problem gets worse and more difficult to detect as the project gets
> > > more complex. People need to understand the limitations of their tools and
> > > work with that.  As I said before people can negotiate what version they
> > > need and if necessary build/install to support a specific project. 
> > > Otherwise
> > > why use file versions at all if we're essentially only using it to tell 
> > > if there
> > > are newer features and essentially ignore it and write corrupted data 
> > > anyway?
> > >  
> >  
> >  
> > I would be very happy with backward compatibility, especially if it would 
> > allow us to safe the file in the older format.
> > This way, not everybody in the team needs to have the same version to be 
> > able to work.
> >  
> > Of course, if someone saves it in the new format, then I would not expect 
> > an older kicad to be able to read it.  
> > Wayne could even decide that every format-change implies a version number 
> > increment, so we can tell the user to install kicad newer than version x.y
> >  
> > I also think, this is not something that will happen every day, so we 
> > should not overdesign this. Forward compatibility for a EDA tool is not 
> > something I would advice, as there are just to many things that can go 
> > wrong.
> >  
> > If it makes things simples, an external file-format converter would also be 
> > fine.
> >  
> > Just my 2 cents,
> > Martijn
> >  
> >  
> > > - Cirilo ___
> > > Mailing list: https://launchpad.net/~kicad-developers
> > > Post to : kicad-developers@lists.launchpad.net 
> > > (mailto:kicad-developers@lists.launchpad.net)
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > More help   : https://help.launchpad.net/ListHelp
> >  
> >  
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net 
> > (mailto:kicad-developers@lists.launchpad.net)
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >  
>  
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net 
> (mailto:kicad-developers@lists.launchpad.net)
> Unsubscribe : https://launchpad.net/~kicad-developers
> More 

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Kaspar Emanuel]

My 2c: let the parser ignore unknown/incompatible s-expressions and warn
the user when they are encountered.

On 14 January 2015 at 22:24, Martijn Kuipers 
wrote:

>
> On 14 Jan 2015, at 21:07, Cirilo Bernardo 
> wrote:
>
>
>
> On Thu, Jan 15, 2015 at 3:27 AM, Tomasz Wlostowski <
> tomasz.wlostow...@cern.ch> wrote:
>
>> On 13.01.2015 20:11, Wayne Stambaugh wrote:
>> > This is a tricky issue that has been discussed before.  The general
>> > consensus in the past has been not to support forward compatibility.  It
>> > increases maintenance and complexity of the file parser for a minimal
>> > net gain to the user.  My preference is to force users that want to
>> > bleed on the edge to use nightly builds rather than try to maintain any
>> > forward file compatibility.
>>
> [snip]
>
>> OK, how about this:
>> - No extra version tokens (fits point A)
>> - Warning instead of error on unrecognized tokens (point C - no big
>> changes needed in the parser)
>> - If the opened file is produced by a newer version of Kicad, issue a
>> big warning when the user attempts to save it, that certain features
>> will be lost (points B and D - if somebody complains we can always tell
>> him he was warned). AFAIK this is what most commercial software does.
>>
>> Cheers,
>> Tom
>>
>
> Except for Acrobat Reader, all the other software I use simply tells me it
> cannot load the new file. In a corporate environment and especially on
> large projects no one wants to take the risk that someone obliterated some
> data. Let's say Person A sends Person B a file with data missing - what
> can Person B possibly do with that now? Person B was never aware of the
> warning that Person A ignored and the software is not psychic so it cannot
> say "hey, the last time you worked on this file it was Version X.Z, not
> X.Y".
> The problem gets worse and more difficult to detect as the project gets
> more complex. People need to understand the limitations of their tools and
> work with that.  As I said before people can negotiate what version they
> need and if necessary build/install to support a specific project.
> Otherwise
> why use file versions at all if we're essentially only using it to tell if
> there
> are newer features and essentially ignore it and write corrupted data
> anyway?
>
>
>
> I would be very happy with backward compatibility, especially if it would
> allow us to safe the file in the older format.
> This way, not everybody in the team needs to have the same version to be
> able to work.
>
> Of course, if someone saves it in the new format, then I would not expect
> an older kicad to be able to read it.
> Wayne could even decide that every format-change implies a version number
> increment, so we can tell the user to install kicad newer than version x.y
>
> I also think, this is not something that will happen every day, so we
> should not overdesign this. Forward compatibility for a EDA tool is not
> something I would advice, as there are just to many things that can go
> wrong.
>
> If it makes things simples, an external file-format converter would also
> be fine.
>
> Just my 2 cents,
> Martijn
>
>
> - Cirilo
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> 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] file version compatibility (optional tokens in s-expression files)

[Martijn Kuipers]

> On 14 Jan 2015, at 21:07, Cirilo Bernardo  wrote:
> 
> 
> 
> On Thu, Jan 15, 2015 at 3:27 AM, Tomasz Wlostowski  > wrote:
> On 13.01.2015 20:11, Wayne Stambaugh wrote:
> > This is a tricky issue that has been discussed before.  The general
> > consensus in the past has been not to support forward compatibility.  It
> > increases maintenance and complexity of the file parser for a minimal
> > net gain to the user.  My preference is to force users that want to
> > bleed on the edge to use nightly builds rather than try to maintain any
> > forward file compatibility.
> [snip]
> OK, how about this:
> - No extra version tokens (fits point A)
> - Warning instead of error on unrecognized tokens (point C - no big
> changes needed in the parser)
> - If the opened file is produced by a newer version of Kicad, issue a
> big warning when the user attempts to save it, that certain features
> will be lost (points B and D - if somebody complains we can always tell
> him he was warned). AFAIK this is what most commercial software does.
> 
> Cheers,
> Tom
> 
> Except for Acrobat Reader, all the other software I use simply tells me it
> cannot load the new file. In a corporate environment and especially on
> large projects no one wants to take the risk that someone obliterated some
> data. Let's say Person A sends Person B a file with data missing - what
> can Person B possibly do with that now? Person B was never aware of the
> warning that Person A ignored and the software is not psychic so it cannot
> say "hey, the last time you worked on this file it was Version X.Z, not X.Y".
> The problem gets worse and more difficult to detect as the project gets
> more complex. People need to understand the limitations of their tools and
> work with that.  As I said before people can negotiate what version they
> need and if necessary build/install to support a specific project. Otherwise
> why use file versions at all if we're essentially only using it to tell if 
> there
> are newer features and essentially ignore it and write corrupted data anyway?
> 


I would be very happy with backward compatibility, especially if it would allow 
us to safe the file in the older format.
This way, not everybody in the team needs to have the same version to be able 
to work.

Of course, if someone saves it in the new format, then I would not expect an 
older kicad to be able to read it.
Wayne could even decide that every format-change implies a version number 
increment, so we can tell the user to install kicad newer than version x.y

I also think, this is not something that will happen every day, so we should 
not overdesign this. Forward compatibility for a EDA tool is not something I 
would advice, as there are just to many things that can go wrong.

If it makes things simples, an external file-format converter would also be 
fine.

Just my 2 cents,
Martijn


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



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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Cirilo Bernardo]

On Thu, Jan 15, 2015 at 3:27 AM, Tomasz Wlostowski <
tomasz.wlostow...@cern.ch> wrote:

> On 13.01.2015 20:11, Wayne Stambaugh wrote:
> > This is a tricky issue that has been discussed before.  The general
> > consensus in the past has been not to support forward compatibility.  It
> > increases maintenance and complexity of the file parser for a minimal
> > net gain to the user.  My preference is to force users that want to
> > bleed on the edge to use nightly builds rather than try to maintain any
> > forward file compatibility.
>
[snip]

> OK, how about this:
> - No extra version tokens (fits point A)
> - Warning instead of error on unrecognized tokens (point C - no big
> changes needed in the parser)
> - If the opened file is produced by a newer version of Kicad, issue a
> big warning when the user attempts to save it, that certain features
> will be lost (points B and D - if somebody complains we can always tell
> him he was warned). AFAIK this is what most commercial software does.
>
> Cheers,
> Tom
>

Except for Acrobat Reader, all the other software I use simply tells me it
cannot load the new file. In a corporate environment and especially on
large projects no one wants to take the risk that someone obliterated some
data. Let's say Person A sends Person B a file with data missing - what
can Person B possibly do with that now? Person B was never aware of the
warning that Person A ignored and the software is not psychic so it cannot
say "hey, the last time you worked on this file it was Version X.Z, not
X.Y".
The problem gets worse and more difficult to detect as the project gets
more complex. People need to understand the limitations of their tools and
work with that.  As I said before people can negotiate what version they
need and if necessary build/install to support a specific project. Otherwise
why use file versions at all if we're essentially only using it to tell if
there
are newer features and essentially ignore it and write corrupted data
anyway?

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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Wayne Stambaugh]

On 1/14/2015 2:13 PM, jp charras wrote:
> Le 14/01/2015 19:32, Miguel Angel Ajo Pelayo a écrit :
>> As a reference: In other EDA tools they can load newer files on older
>> versions of the software.  They just open a warning window with
>> everything which is not read/processed, and tell you everything not
>> readed will be lost at next save.
>>
> 
> There is not a lot of free EDA tools so I don't know the actual meaning
> of "In other EDA tools"
> 
> Keep in mind commercial software has very different constrains:
> 
> 1 - they have much more (I am expecting) man-hours we have.
> 2 - because they are very expensive, they *cannot* ask for user to
> update the software. Kicad is free and free of charges. We can ask.
> 3 - This issue is widely due to the fact we have a repos to which allows
> user to download, compile and use current development versions. How many
> commercial software have such a repos ?
> 
> To tell the true, I am not sure an old version opening and saving a file
> still gives a working file: you don't know what is lost ( and be sure
> the user is not able to know what is lost, and if this is an important
> info, and warn he is not usefull).
> 
> To minimize issues when a old Kicad version open files created by new
> versions, I am using this way:
> When a new feature/option exists, it can have default values.
> When this option uses default values, theses values are not saved, and
> therefore do not create issues.
> For new features, obviously if they are not used, avoid to save any info
> about theses features.
> This is not perfect ( mainly do not save defaults creates a major
> constraint: defaults cannot be modified ) but it helps.
> 
> Having said that, I am also thinking we just skip data not recognized by
> a old kicad version when reading a new file, warn the user and do not
> reject the entire file, but we ask the user to update the Kicad version.
> 

I just thought of another potential issue caused by ignoring unknown
tokens.  What if the tokens are actually invalid due to file corruption
or someone wrote a bad board generation script.  What do you do in that
case?  The file is invalid but you still parse it anyway and throw away
the invalid stuff.  I'm not sure that is necessarily a good thing.

Each new argument seems to support the original decision to not attempt
forward compatibility.  We have one argument in favor of forward
compatibility (user convenience) and a whole bunch of valid arguments
against forward compatibility.  To me, it seems like the effort and
risks don't justify the gain.


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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[jp charras]

Le 14/01/2015 19:32, Miguel Angel Ajo Pelayo a écrit :
> As a reference: In other EDA tools they can load newer files on older
> versions of the software.  They just open a warning window with
> everything which is not read/processed, and tell you everything not
> readed will be lost at next save.
> 

There is not a lot of free EDA tools so I don't know the actual meaning
of "In other EDA tools"

Keep in mind commercial software has very different constrains:

1 - they have much more (I am expecting) man-hours we have.
2 - because they are very expensive, they *cannot* ask for user to
update the software. Kicad is free and free of charges. We can ask.
3 - This issue is widely due to the fact we have a repos to which allows
user to download, compile and use current development versions. How many
commercial software have such a repos ?

To tell the true, I am not sure an old version opening and saving a file
still gives a working file: you don't know what is lost ( and be sure
the user is not able to know what is lost, and if this is an important
info, and warn he is not usefull).

To minimize issues when a old Kicad version open files created by new
versions, I am using this way:
When a new feature/option exists, it can have default values.
When this option uses default values, theses values are not saved, and
therefore do not create issues.
For new features, obviously if they are not used, avoid to save any info
about theses features.
This is not perfect ( mainly do not save defaults creates a major
constraint: defaults cannot be modified ) but it helps.

Having said that, I am also thinking we just skip data not recognized by
a old kicad version when reading a new file, warn the user and do not
reject the entire file, but we ask the user to update the Kicad version.

-- 
Jean-Pierre CHARRAS

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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Miguel Angel Ajo Pelayo]

As a reference: In other EDA tools they can load newer files on older versions 
of the software.  They just open a warning window with everything which is not 
readed/processed, and tell you everything not readed will be lost at next save. 

Sent from my Android phone using TouchDown (www.nitrodesk.com)


-Original Message-
From: Wayne Stambaugh [stambau...@gmail.com]
Received: Wednesday, 14 Jan 2015, 7:12PM
To: Tomasz Wlostowski [tomasz.wlostow...@cern.ch]; 
kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] file version compatibility (optional tokens in 
s-expression files)

On 1/14/2015 11:27 AM, Tomasz Wlostowski wrote:
> On 13.01.2015 20:11, Wayne Stambaugh wrote:
>> This is a tricky issue that has been discussed before.  The general
>> consensus in the past has been not to support forward compatibility.  It
>> increases maintenance and complexity of the file parser for a minimal
>> net gain to the user.  My preference is to force users that want to
>> bleed on the edge to use nightly builds rather than try to maintain any
>> forward file compatibility.  
> 
> Hi Wayne,
> 
> The only argument I see for limited forward compatibility is when
> someone uses a bleeding edge build to benefit from the latest features
> (or just adds them them as needed), but must be able to share the design
> (read only is OK) with other people who are forced to stick to the
> stable version (think of corporate/university users where software is
> centrally managed by some IT department).
> 
>> I also don't like idea of creating special tokens just for version
>> compatibility.  I would like to keep the file format as readable as
>> possible.  My guess is that any version compatibility tokens will have
>> to reference the other objects in the file making the file less readable
>> which is something that I will be reluctant to support.
> 
> I didn't consider impact on file readability. I'm not the type who edits
> graphics with a text editor (and a PCB, after all is mostly a graphical
> design), so as long as the file structure is easy to figure out, I'm OK
> with it. I understand your point though and I'm not going to argue here
> (especially given the fact that you've put quite a lot of effort to make
> the format readable).
> 
>>
>> How do you plan to prevent data loss when editing newer files with older
>> versions of pcbnew? 
> 
> 
> 
>> One solution might be to ignore any unsupported tokens and warn the user
>> that there may (will?) be data loss if the board is modified and saved.
>> Even this solution I think has a lot of potential pitfalls.  Make newer
>> files read only is also a possibility.
>>
>> The only way I would support forward file compatibility is if there is:
>>
>> a) no loss of file readability
>> b) no loss of user data
>> d) no unnecessary increase in the complexity of the file parser code.
>> c) no hoard of angry users who want to edit a new file version with and
>> older version of pcbnew.
> 
> OK, how about this:
> - No extra version tokens (fits point A)
> - Warning instead of error on unrecognized tokens (point C - no big
> changes needed in the parser)
> - If the opened file is produced by a newer version of Kicad, issue a
> big warning when the user attempts to save it, that certain features
> will be lost (points B and D - if somebody complains we can always tell
> him he was warned). AFAIK this is what most commercial software does.

This seems plausible but a bit risky.  How would you handle new file
objects that an older version of pcbnew knows nothing about?  These
objects would not be rendered and the user might get a false sense of
security that a complete file load was performed.  A warning may work or
it may not.  I guess you get to pick who you want to scream at you.  The
user who can't open a new file version or the user who just lost
valuable file information.  Pick your poison.  I'm more comfortable
telling people to upgrade rather than saying "Sorry, you were warned".

> 
> Cheers,
> Tom
> 
> 


___
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] file version compatibility (optional tokens in s-expression files)

[Wayne Stambaugh]

On 1/14/2015 11:27 AM, Tomasz Wlostowski wrote:
> On 13.01.2015 20:11, Wayne Stambaugh wrote:
>> This is a tricky issue that has been discussed before.  The general
>> consensus in the past has been not to support forward compatibility.  It
>> increases maintenance and complexity of the file parser for a minimal
>> net gain to the user.  My preference is to force users that want to
>> bleed on the edge to use nightly builds rather than try to maintain any
>> forward file compatibility.  
> 
> Hi Wayne,
> 
> The only argument I see for limited forward compatibility is when
> someone uses a bleeding edge build to benefit from the latest features
> (or just adds them them as needed), but must be able to share the design
> (read only is OK) with other people who are forced to stick to the
> stable version (think of corporate/university users where software is
> centrally managed by some IT department).
> 
>> I also don't like idea of creating special tokens just for version
>> compatibility.  I would like to keep the file format as readable as
>> possible.  My guess is that any version compatibility tokens will have
>> to reference the other objects in the file making the file less readable
>> which is something that I will be reluctant to support.
> 
> I didn't consider impact on file readability. I'm not the type who edits
> graphics with a text editor (and a PCB, after all is mostly a graphical
> design), so as long as the file structure is easy to figure out, I'm OK
> with it. I understand your point though and I'm not going to argue here
> (especially given the fact that you've put quite a lot of effort to make
> the format readable).
> 
>>
>> How do you plan to prevent data loss when editing newer files with older
>> versions of pcbnew? 
> 
> 
> 
>> One solution might be to ignore any unsupported tokens and warn the user
>> that there may (will?) be data loss if the board is modified and saved.
>> Even this solution I think has a lot of potential pitfalls.  Make newer
>> files read only is also a possibility.
>>
>> The only way I would support forward file compatibility is if there is:
>>
>> a) no loss of file readability
>> b) no loss of user data
>> d) no unnecessary increase in the complexity of the file parser code.
>> c) no hoard of angry users who want to edit a new file version with and
>> older version of pcbnew.
> 
> OK, how about this:
> - No extra version tokens (fits point A)
> - Warning instead of error on unrecognized tokens (point C - no big
> changes needed in the parser)
> - If the opened file is produced by a newer version of Kicad, issue a
> big warning when the user attempts to save it, that certain features
> will be lost (points B and D - if somebody complains we can always tell
> him he was warned). AFAIK this is what most commercial software does.

This seems plausible but a bit risky.  How would you handle new file
objects that an older version of pcbnew knows nothing about?  These
objects would not be rendered and the user might get a false sense of
security that a complete file load was performed.  A warning may work or
it may not.  I guess you get to pick who you want to scream at you.  The
user who can't open a new file version or the user who just lost
valuable file information.  Pick your poison.  I'm more comfortable
telling people to upgrade rather than saying "Sorry, you were warned".

> 
> Cheers,
> Tom
> 
> 


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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Tomasz Wlostowski]

On 13.01.2015 20:11, Wayne Stambaugh wrote:
> This is a tricky issue that has been discussed before.  The general
> consensus in the past has been not to support forward compatibility.  It
> increases maintenance and complexity of the file parser for a minimal
> net gain to the user.  My preference is to force users that want to
> bleed on the edge to use nightly builds rather than try to maintain any
> forward file compatibility.  

Hi Wayne,

The only argument I see for limited forward compatibility is when
someone uses a bleeding edge build to benefit from the latest features
(or just adds them them as needed), but must be able to share the design
(read only is OK) with other people who are forced to stick to the
stable version (think of corporate/university users where software is
centrally managed by some IT department).

> I also don't like idea of creating special tokens just for version
> compatibility.  I would like to keep the file format as readable as
> possible.  My guess is that any version compatibility tokens will have
> to reference the other objects in the file making the file less readable
> which is something that I will be reluctant to support.

I didn't consider impact on file readability. I'm not the type who edits
graphics with a text editor (and a PCB, after all is mostly a graphical
design), so as long as the file structure is easy to figure out, I'm OK
with it. I understand your point though and I'm not going to argue here
(especially given the fact that you've put quite a lot of effort to make
the format readable).

> 
> How do you plan to prevent data loss when editing newer files with older
> versions of pcbnew? 



> One solution might be to ignore any unsupported tokens and warn the user
> that there may (will?) be data loss if the board is modified and saved.
> Even this solution I think has a lot of potential pitfalls.  Make newer
> files read only is also a possibility.
> 
> The only way I would support forward file compatibility is if there is:
> 
> a) no loss of file readability
> b) no loss of user data
> d) no unnecessary increase in the complexity of the file parser code.
> c) no hoard of angry users who want to edit a new file version with and
> older version of pcbnew.

OK, how about this:
- No extra version tokens (fits point A)
- Warning instead of error on unrecognized tokens (point C - no big
changes needed in the parser)
- If the opened file is produced by a newer version of Kicad, issue a
big warning when the user attempts to save it, that certain features
will be lost (points B and D - if somebody complains we can always tell
him he was warned). AFAIK this is what most commercial software does.

Cheers,
Tom



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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Lorenzo Marcantonio]

On Tue, Jan 13, 2015 at 09:44:18PM +0100, Nick Østergaard wrote:
> Not sure what you mean there Lorenzo, but what I am advocating is that
> kicad would not fail with a cryptic error when it encounters a future
> format, and just state this file is incompatible and the user should
> upgrade. No backward or forward compatibility is kept here, just
> indication about compatibility. As you say, the files already has a
> version number.

Ah OK, my fault then. I misunderstood the issue.

Completely agree with a simple 'version check'

-- 
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] file version compatibility (optional tokens in s-expression files)

[José Ignacio]

I really like the idea of opening newer files as read only, that will
force the user to do a conscious decision to save with data loss, and
would practically eliminate the issues of accidental data loss. Also
it would accommodate the issue of people using different versions
being able to "check out" the files made in a newer version, say, look
at some schematics made by someone else with another version in a
school computer (which you don't have permission to upgrade software)
degrading in a moreless graceful way. It would be also nice to be able
to do the information loss step in the "future" version, (ie "save as
x stable version format" like in microsoft word/libreoffice et al.),
so that you don't need to have multiple versions of kicad installed to
be able to collaborate with people using older versions (or submitting
work to places that require X version). It would really suck if you
took your file home from school, did a couple edits in your newer
version and then it wouldn't open (properly) in the school computer.

On Tue, Jan 13, 2015 at 11:13 PM, Cirilo Bernardo
 wrote:
>
>
> On Wed, Jan 14, 2015 at 10:38 AM, Adam Wolf 
> wrote:
>>
>> Cirilo,
>>
>> I like that.
>>
>> Adam Wolf
>>
>>
> [snip]
>
> I'd love to take credit, but numerous software packages use that scheme for
> file
> version control and loading. When it's proprietary like SolidWorks you go
> through
> hell working around the problems, but with Free and Open Source software
> there
> is a lot more flexibility for all collaborators.
>
> - Cirilo
>
>
> ___
> 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] file version compatibility (optional tokens in s-expression files)

[Cirilo Bernardo]

On Wed, Jan 14, 2015 at 10:38 AM, Adam Wolf 
wrote:

> Cirilo,
>
> I like that.
>
> Adam Wolf
>
> [snip]

I'd love to take credit, but numerous software packages use that scheme for
file
version control and loading. When it's proprietary like SolidWorks you go
through
hell working around the problems, but with Free and Open Source software
there
is a lot more flexibility for all collaborators.

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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Adam Wolf]

Cirilo,

I like that.

Adam Wolf
On Jan 13, 2015 2:45 PM, "Cirilo Bernardo" 
wrote:

>
> On Wed, Jan 14, 2015 at 5:20 AM, Tomasz Wlostowski <
> tomasz.wlostow...@cern.ch> wrote:
>
>> Hi all,
>>
>> During my work on diff pairs/matched length tools, I've encountered a
>> rather tricky problem: as the diff pair gap specific to a particular
>> pair of traces is stored nowhere, the shove algorithm will mess up DP
>> coupling after saving and re-loading the board. Ergo: the DP gaps (and
>> possibly other settings) need to be stored somewhere in .kicad_pcb
>> files. Perhaps in a yet another s-expr token.
>>
>> The problem is that adding any new token to the file format causes all
>> precedent versions of pcbnew to drop an error attempting to load the
>> file. I would propose two solutions to overcome this:
>> - (a dumb one) if the version in the file header is newer than the
>> version supported by the running application, issue warnings instead of
>> fatal errors on unknown tokens,
>> - (a bit smarter) enclose all optional tokens in a "minimum" version
>> block ( min_version version_number ( optional_token ( ... ) ) ) that
>> would be ignored if the application version < version_number.
>>
>> I consider this modification quite important from the point of view of
>> adding future features and the upcoming stable version: if we keep
>> things as they are, adding any new feature will either make the files
>> unreadable to the stable version or force us to support saving in
>> multiple format versions.
>>
>> Looking forward to your feedback,
>> Tom
>>
>
> I would prefer to do what had been done in the past - simply increase
> the File Version number and don't expect earlier versions to support
> the new features (or to read the board at all).  What we *can* safely
> do is check the file version number when parsing and if the parser
> does not recognize it then we can display a message to say that it
> is a newer file version and we cannot read it. If people are collaborating
> and this can be an issue then they must agree on a version of KiCad
> to use; after all in most cases they can build any historical version
> from the past 2 years.
>
> - Cirilo
>
> ___
> 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] file version compatibility (optional tokens in s-expression files)

[Adam Wolf]

If Cirilo is right, I like that.

"Why solve today what you can solve in the future?" :)

Adam Wolf

On Tue, Jan 13, 2015 at 2:45 PM, Cirilo Bernardo 
wrote:

>
> On Wed, Jan 14, 2015 at 5:20 AM, Tomasz Wlostowski <
> tomasz.wlostow...@cern.ch> wrote:
>
>> Hi all,
>>
>> During my work on diff pairs/matched length tools, I've encountered a
>> rather tricky problem: as the diff pair gap specific to a particular
>> pair of traces is stored nowhere, the shove algorithm will mess up DP
>> coupling after saving and re-loading the board. Ergo: the DP gaps (and
>> possibly other settings) need to be stored somewhere in .kicad_pcb
>> files. Perhaps in a yet another s-expr token.
>>
>> The problem is that adding any new token to the file format causes all
>> precedent versions of pcbnew to drop an error attempting to load the
>> file. I would propose two solutions to overcome this:
>> - (a dumb one) if the version in the file header is newer than the
>> version supported by the running application, issue warnings instead of
>> fatal errors on unknown tokens,
>> - (a bit smarter) enclose all optional tokens in a "minimum" version
>> block ( min_version version_number ( optional_token ( ... ) ) ) that
>> would be ignored if the application version < version_number.
>>
>> I consider this modification quite important from the point of view of
>> adding future features and the upcoming stable version: if we keep
>> things as they are, adding any new feature will either make the files
>> unreadable to the stable version or force us to support saving in
>> multiple format versions.
>>
>> Looking forward to your feedback,
>> Tom
>>
>
> I would prefer to do what had been done in the past - simply increase
> the File Version number and don't expect earlier versions to support
> the new features (or to read the board at all).  What we *can* safely
> do is check the file version number when parsing and if the parser
> does not recognize it then we can display a message to say that it
> is a newer file version and we cannot read it. If people are collaborating
> and this can be an issue then they must agree on a version of KiCad
> to use; after all in most cases they can build any historical version
> from the past 2 years.
>
> - Cirilo
>
> ___
> 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] file version compatibility (optional tokens in s-expression files)

[Cirilo Bernardo]

On Wed, Jan 14, 2015 at 5:20 AM, Tomasz Wlostowski <
tomasz.wlostow...@cern.ch> wrote:

> Hi all,
>
> During my work on diff pairs/matched length tools, I've encountered a
> rather tricky problem: as the diff pair gap specific to a particular
> pair of traces is stored nowhere, the shove algorithm will mess up DP
> coupling after saving and re-loading the board. Ergo: the DP gaps (and
> possibly other settings) need to be stored somewhere in .kicad_pcb
> files. Perhaps in a yet another s-expr token.
>
> The problem is that adding any new token to the file format causes all
> precedent versions of pcbnew to drop an error attempting to load the
> file. I would propose two solutions to overcome this:
> - (a dumb one) if the version in the file header is newer than the
> version supported by the running application, issue warnings instead of
> fatal errors on unknown tokens,
> - (a bit smarter) enclose all optional tokens in a "minimum" version
> block ( min_version version_number ( optional_token ( ... ) ) ) that
> would be ignored if the application version < version_number.
>
> I consider this modification quite important from the point of view of
> adding future features and the upcoming stable version: if we keep
> things as they are, adding any new feature will either make the files
> unreadable to the stable version or force us to support saving in
> multiple format versions.
>
> Looking forward to your feedback,
> Tom
>

I would prefer to do what had been done in the past - simply increase
the File Version number and don't expect earlier versions to support
the new features (or to read the board at all).  What we *can* safely
do is check the file version number when parsing and if the parser
does not recognize it then we can display a message to say that it
is a newer file version and we cannot read it. If people are collaborating
and this can be an issue then they must agree on a version of KiCad
to use; after all in most cases they can build any historical version
from the past 2 years.

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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Nick Østergaard]

2015-01-13 20:24 GMT+01:00 Lorenzo Marcantonio :
> On Tue, Jan 13, 2015 at 02:16:46PM -0500, Wayne Stambaugh wrote:
>> bit of inconvenience, bandwidth, and time.  Once we get the nightly
>> builds up to snuff for all platforms, I'll feel even less guilty.
>
> Also: do we *really* need to keep files made with nightlies compatible
> with the stable version?

Not sure what you mean there Lorenzo, but what I am advocating is that
kicad would not fail with a cryptic error when it encounters a future
format, and just state this file is incompatible and the user should
upgrade. No backward or forward compatibility is kept here, just
indication about compatibility. As you say, the files already has a
version number.

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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Lorenzo Marcantonio]

On Tue, Jan 13, 2015 at 02:16:46PM -0500, Wayne Stambaugh wrote:
> bit of inconvenience, bandwidth, and time.  Once we get the nightly
> builds up to snuff for all platforms, I'll feel even less guilty.

Also: do we *really* need to keep files made with nightlies compatible
with the stable version?

-- 
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] file version compatibility (optional tokens in s-expression files)

[Lorenzo Marcantonio]

On Tue, Jan 13, 2015 at 07:47:25PM +0100, Nick Østergaard wrote:
> Which is easy to handle if the file tells the minimum version. Then
> there should just be a check if the kicad that reads is new enough,
> and it can tell you to update. This will remove the fatal failure, and
> we don't have to support older versions in a simple way. IMHO.

Well, there is a version tag even in the legacy file format (the version
header line), so that shouldn't be a 'big' new. Checking that should be
easy. Deciding when to bump it, it's too: when the format (or maybe even
the meaning in some case) of any sexp changes. For supporting loading of
'legacy' forms there is a (relatively big) problem since the current
architecture is grammar driven (a recursive descent parser last time
I've checked) and not data driven (like true sexps) you need to special
case every time the old versions during parsing. Look at the layer table
for the most awful case ever encountered :P

In short, the needed infrastructure is already there but it's not
immediate to maintain every time the format changes...

As for allowing 'optional' forms in the format IIRC it was already
discussed and rejected a long time ago.

-- 
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] file version compatibility (optional tokens in s-expression files)

[Wayne Stambaugh]

On 1/13/2015 1:47 PM, Nick Østergaard wrote:
> 2015-01-13 19:39 GMT+01:00 Nick Østergaard :
>> 2015-01-13 19:36 GMT+01:00 Lorenzo Marcantonio :
>>> On Tue, Jan 13, 2015 at 07:20:42PM +0100, Tomasz Wlostowski wrote:
 The problem is that adding any new token to the file format causes all
 precedent versions of pcbnew to drop an error attempting to load the
 file. I would propose two solutions to overcome this:
>>>
>>> AFAIK the current policy in kicad is simply to force to upgrade :D
>>
>> Which is bad, if we want to distribute stable releases and some OS do
>> not update straight away.

This would really be bad if we charged them $295 to upgrade to the
latest version so they could open the latest file version. ;)  I feel a
bit less guilty about asking users to upgrade when the cost is a little
bit of inconvenience, bandwidth, and time.  Once we get the nightly
builds up to snuff for all platforms, I'll feel even less guilty.

> 
> Which is easy to handle if the file tells the minimum version. Then
> there should just be a check if the kicad that reads is new enough,
> and it can tell you to update. This will remove the fatal failure, and
> we don't have to support older versions in a simple way. IMHO.
> 
>>> --
>>> 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
> 
> ___
> 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] file version compatibility (optional tokens in s-expression files)

[Wayne Stambaugh]

This is a tricky issue that has been discussed before.  The general
consensus in the past has been not to support forward compatibility.  It
increases maintenance and complexity of the file parser for a minimal
net gain to the user.  My preference is to force users that want to
bleed on the edge to use nightly builds rather than try to maintain any
forward file compatibility.  I think you'll find that trying to provide
forward file format capability will quickly create a huge mess that will
be difficult to maintain.  Give our limited manpower, I would rather
that time be spent moving kicad forward.

I also don't like idea of creating special tokens just for version
compatibility.  I would like to keep the file format as readable as
possible.  My guess is that any version compatibility tokens will have
to reference the other objects in the file making the file less readable
which is something that I will be reluctant to support.

How do you plan to prevent data loss when editing newer files with older
versions of pcbnew?  You would have to store all of the unrecognized
tokens and then attempt to put them back where they belong in the file
if you allow older versions of pcbnew to modify newer file versions.  I
see this as being problematic at best.

One solution might be to ignore any unsupported tokens and warn the user
that there may (will?) be data loss if the board is modified and saved.
 Even this solution I think has a lot of potential pitfalls.  Make newer
files read only is also a possibility.

The only way I would support forward file compatibility is if there is:

a) no loss of file readability
b) no loss of user data
d) no unnecessary increase in the complexity of the file parser code.
c) no hoard of angry users who want to edit a new file version with and
older version of pcbnew.

It's generally easier to tell users if they want edit the latest file
formats to install the latest version of kicad.  Under normal
circumstances, only developers and users using nightly builds should be
using new file formats so I don't see this as a major problem.

I'm not saying under no circumstances that I would not support forward
file compatibility but someone would have to write some really
impressive code to pull it off and then convince me that this is the way
to go.


On 1/13/2015 1:20 PM, Tomasz Wlostowski wrote:
> Hi all,
> 
> During my work on diff pairs/matched length tools, I've encountered a
> rather tricky problem: as the diff pair gap specific to a particular
> pair of traces is stored nowhere, the shove algorithm will mess up DP
> coupling after saving and re-loading the board. Ergo: the DP gaps (and
> possibly other settings) need to be stored somewhere in .kicad_pcb
> files. Perhaps in a yet another s-expr token.
> 
> The problem is that adding any new token to the file format causes all
> precedent versions of pcbnew to drop an error attempting to load the
> file. I would propose two solutions to overcome this:
> - (a dumb one) if the version in the file header is newer than the
> version supported by the running application, issue warnings instead of
> fatal errors on unknown tokens,
> - (a bit smarter) enclose all optional tokens in a "minimum" version
> block ( min_version version_number ( optional_token ( ... ) ) ) that
> would be ignored if the application version < version_number.
> 
> I consider this modification quite important from the point of view of
> adding future features and the upcoming stable version: if we keep
> things as they are, adding any new feature will either make the files
> unreadable to the stable version or force us to support saving in
> multiple format versions.
> 
> Looking forward to your feedback,
> Tom
> 
> ___
> 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] file version compatibility (optional tokens in s-expression files)

[Nick Østergaard]

2015-01-13 19:39 GMT+01:00 Nick Østergaard :
> 2015-01-13 19:36 GMT+01:00 Lorenzo Marcantonio :
>> On Tue, Jan 13, 2015 at 07:20:42PM +0100, Tomasz Wlostowski wrote:
>>> The problem is that adding any new token to the file format causes all
>>> precedent versions of pcbnew to drop an error attempting to load the
>>> file. I would propose two solutions to overcome this:
>>
>> AFAIK the current policy in kicad is simply to force to upgrade :D
>
> Which is bad, if we want to distribute stable releases and some OS do
> not update straight away.

Which is easy to handle if the file tells the minimum version. Then
there should just be a check if the kicad that reads is new enough,
and it can tell you to update. This will remove the fatal failure, and
we don't have to support older versions in a simple way. IMHO.

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

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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Nick Østergaard]

2015-01-13 19:36 GMT+01:00 Lorenzo Marcantonio :
> On Tue, Jan 13, 2015 at 07:20:42PM +0100, Tomasz Wlostowski wrote:
>> The problem is that adding any new token to the file format causes all
>> precedent versions of pcbnew to drop an error attempting to load the
>> file. I would propose two solutions to overcome this:
>
> AFAIK the current policy in kicad is simply to force to upgrade :D

Which is bad, if we want to distribute stable releases and some OS do
not update straight away.

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

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

Re: [Kicad-developers] file version compatibility (optional tokens in s-expression files)

[Lorenzo Marcantonio]

On Tue, Jan 13, 2015 at 07:20:42PM +0100, Tomasz Wlostowski wrote:
> The problem is that adding any new token to the file format causes all
> precedent versions of pcbnew to drop an error attempting to load the
> file. I would propose two solutions to overcome this:

AFAIK the current policy in kicad is simply to force to upgrade :D

-- 
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] file version compatibility (optional tokens in s-expression files)

[Adam Wolf]

In general, I like the min version idea.  It matches many web APIs with
including the version number.

However, I don't want to have to maintain users who want to run five stable
versions old and have them expect their software will still work with new
stuff.

Adam Wolf
On Jan 13, 2015 12:20 PM, "Tomasz Wlostowski" 
wrote:

> Hi all,
>
> During my work on diff pairs/matched length tools, I've encountered a
> rather tricky problem: as the diff pair gap specific to a particular
> pair of traces is stored nowhere, the shove algorithm will mess up DP
> coupling after saving and re-loading the board. Ergo: the DP gaps (and
> possibly other settings) need to be stored somewhere in .kicad_pcb
> files. Perhaps in a yet another s-expr token.
>
> The problem is that adding any new token to the file format causes all
> precedent versions of pcbnew to drop an error attempting to load the
> file. I would propose two solutions to overcome this:
> - (a dumb one) if the version in the file header is newer than the
> version supported by the running application, issue warnings instead of
> fatal errors on unknown tokens,
> - (a bit smarter) enclose all optional tokens in a "minimum" version
> block ( min_version version_number ( optional_token ( ... ) ) ) that
> would be ignored if the application version < version_number.
>
> I consider this modification quite important from the point of view of
> adding future features and the upcoming stable version: if we keep
> things as they are, adding any new feature will either make the files
> unreadable to the stable version or force us to support saving in
> multiple format versions.
>
> Looking forward to your feedback,
> Tom
>
> ___
> 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] file version compatibility (optional tokens in s-expression files)

[Tomasz Wlostowski]

Hi all,

During my work on diff pairs/matched length tools, I've encountered a
rather tricky problem: as the diff pair gap specific to a particular
pair of traces is stored nowhere, the shove algorithm will mess up DP
coupling after saving and re-loading the board. Ergo: the DP gaps (and
possibly other settings) need to be stored somewhere in .kicad_pcb
files. Perhaps in a yet another s-expr token.

The problem is that adding any new token to the file format causes all
precedent versions of pcbnew to drop an error attempting to load the
file. I would propose two solutions to overcome this:
- (a dumb one) if the version in the file header is newer than the
version supported by the running application, issue warnings instead of
fatal errors on unknown tokens,
- (a bit smarter) enclose all optional tokens in a "minimum" version
block ( min_version version_number ( optional_token ( ... ) ) ) that
would be ignored if the application version < version_number.

I consider this modification quite important from the point of view of
adding future features and the upcoming stable version: if we keep
things as they are, adding any new feature will either make the files
unreadable to the stable version or force us to support saving in
multiple format versions.

Looking forward to your feedback,
Tom

___
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