1_36 serialization... another issue...
Following my previous post... it seems that there are issues with xml too...
the 1_35 saved file does not load with 1_36 framework...
it seems that the "missing"
On 28 Jun 2008, at 08:28, Mathieu Peyréga wrote:
Following my previous post... it seems that there are issues with xml too...
the 1_35 saved file does not load with 1_36 framework... it seems that the "missing"
0 makes the difference....I hope that may help the developpers... in case i did not misuse the library...
We made 1.36 compatible with all versions <= 1.34
When is the plan'd release of 1.36?
Also is there a plan to release a 1.35.1? Specifically to patch issues like
this?
Cheers,
-Tim
On Sat, Jun 28, 2008 at 12:20 PM, Matthias Troyer
On 28 Jun 2008, at 08:28, Mathieu Peyréga wrote:
Following my previous post... it seems that there are issues with xml
too...
the 1_35 saved file does not load with 1_36 framework... it seems that the "missing"
0 makes the difference....I hope that may help the developpers... in case i did not misuse the library...
We made 1.36 compatible with all versions <= 1.34
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Regards, Timothy St. Clair [timothysc@gmail.com]
Following my previous post... it seems that there are issues with xml too...
the 1_35 saved file does not load with 1_36 framework... it seems that the "missing"
0 makes the difference....I hope that may help the developpers... in case i did not misuse the library...
We made 1.36 compatible with all versions <= 1.34
Hello, shall I understand that it is not compatible with 1.35 ? Regards, Mathieu -- http://www.incub.net/
On 29 Jun 2008, at 19:08, Mathieu Peyréga wrote:
Following my previous post... it seems that there are issues with xml too...
the 1_35 saved file does not load with 1_36 framework... it seems that the "missing"
0 makes the difference....I hope that may help the developpers... in case i did not misuse the library...
We made 1.36 compatible with all versions <= 1.34
Hello,
shall I understand that it is not compatible with 1.35 ?
No, because there is a bug in 1.35
shall I understand that it is not compatible with 1.35 ?
No, because there is a bug in 1.35
Ok, thank you for this clear answer ! So (hopefully it is not a big issue in my case...) i will upgrade to 1.36 and give up a few old files... Or write a small utility to upgrade files... From what I understood, the bug affects only the STL collections am I right ? Regards, and once again, thank you for this great work ! Mathieu -- http://www.incub.net/
On Jun 29, 2008, at 10:16 PM, Mathieu Peyréga wrote:
shall I understand that it is not compatible with 1.35 ?
No, because there is a bug in 1.35
Ok, thank you for this clear answer ! So (hopefully it is not a big issue in my case...) i will upgrade to 1.36 and give up a few old files... Or write a small utility to upgrade files...
From what I understood, the bug affects only the STL collections am I right ?
Only STL collections of builtin types Matthias
On Jun 29, 2008, at 10:16 PM, Mathieu Peyréga wrote:
shall I understand that it is not compatible with 1.35 ?
No, because there is a bug in 1.35
Ok, thank you for this clear answer ! So (hopefully it is not a big issue in my case...) i will upgrade to 1.36 and give up a few old files... Or write a small utility to upgrade files...
From what I understood, the bug affects only the STL collections am I right ?
Actually only std::vector of builtin types
shall I understand that it is not compatible with 1.35 ?
No, because there is a bug in 1.35
Ok, thank you for this clear answer ! So (hopefully it is not a big issue in my case...) i will upgrade to 1.36 and give up a few old files... Or write a small utility to upgrade files...
From what I understood, the bug affects only the STL collections am I right ?
Actually only std::vector of builtin types
Which are it has to be said very commonly used types! It seems very worrying that 1.35 users are going to be deliberately broken to help out <= 1.34.1 users who were broken accidentally. Is there really no plan to help out users load their 1.35 files in 1.36? Even if this can't be rectified within the library through a workaround, maybe a more independent (standalone?) utility could be provided? I have no familiarity with the internals of the library but if there is some way I can help in this regard, I'd be happy to try. Pete Bartlett
It seems very worrying that 1.35 users are going to be deliberately broken to help out <= 1.34.1 users who were broken accidentally. Is there really no plan to help out users load their 1.35 files in 1.36? Even if this can't be rectified within the library through a workaround, maybe a more independent (standalone?) utility could be provided? I have no familiarity with the internals of the library but if there is some way I can help in this regard, I'd be happy to try.
Pete Bartlett
How about a boost/serialization/vector_135.hpp header, analogous to the boost/serialization/shared_ptr_132.hpp header? --Johan
On Jul 1, 2008, at 2:24 PM, Johan Råde wrote:
It seems very worrying that 1.35 users are going to be deliberately broken to help out <= 1.34.1 users who were broken accidentally. Is there really no plan to help out users load their 1.35 files in 1.36? Even if this can't be rectified within the library through a workaround, maybe a more independent (standalone?) utility could be provided? I have no familiarity with the internals of the library but if there is some way I can help in this regard, I'd be happy to try. Pete Bartlett
How about a boost/serialization/vector_135.hpp header, analogous to the boost/serialization/shared_ptr_132.hpp header?
What should the default vector.hpp header be compatible with? all versions but 1.35 or all but 1.34.1? Matthias
Matthias Troyer wrote:
On Jul 1, 2008, at 2:24 PM, Johan Råde wrote:
It seems very worrying that 1.35 users are going to be deliberately broken to help out <= 1.34.1 users who were broken accidentally. Is there really no plan to help out users load their 1.35 files in 1.36? Even if this can't be rectified within the library through a workaround, maybe a more independent (standalone?) utility could be provided? I have no familiarity with the internals of the library but if there is some way I can help in this regard, I'd be happy to try. Pete Bartlett
How about a boost/serialization/vector_135.hpp header, analogous to the boost/serialization/shared_ptr_132.hpp header?
What should the default vector.hpp header be compatible with? all versions but 1.35 or all but 1.34.1?
Matthias
The default vector.hpp header should be compatible with all versions <= 1.34.1. The vector_135.hpp header would be compatible with 1.35. (So I guess this is not quite analogous to shared_ptr_132.hpp). I think you should only add a vector_135.hpp header to Boost 1.36 if anyone really needs it. For instance if anyone has shipped code, that uses the 1.35 vector.hpp, to customers. I do not need a vector_135.hpp header. --Johan
On Wednesday 02 July 2008 08:30:55 Johan Råde wrote:
I think you should only add a vector_135.hpp header to Boost 1.36 if anyone really needs it. For instance if anyone has shipped code, that uses the 1.35 vector.hpp, to customers. I do not need a vector_135.hpp header.
Unfortunately, I do. I can't imagine that I'm the only one that needs this functionality. Thanks, Justin
On 2 Jul 2008, at 17:30, Johan Råde wrote:
Matthias Troyer wrote:
On Jul 1, 2008, at 2:24 PM, Johan Råde wrote:
It seems very worrying that 1.35 users are going to be deliberately broken to help out <= 1.34.1 users who were broken accidentally. Is there really no plan to help out users load their 1.35 files in 1.36? Even if this can't be rectified within the library through a workaround, maybe a more independent (standalone?) utility could be provided? I have no familiarity with the internals of the library but if there is some way I can help in this regard, I'd be happy to try. Pete Bartlett
How about a boost/serialization/vector_135.hpp header, analogous to the boost/serialization/shared_ptr_132.hpp header?
What should the default vector.hpp header be compatible with? all versions but 1.35 or all but 1.34.1? Matthias
The default vector.hpp header should be compatible with all versions <= 1.34.1. The vector_135.hpp header would be compatible with 1.35. (So I guess this is not quite analogous to shared_ptr_132.hpp).
I think you should only add a vector_135.hpp header to Boost 1.36 if anyone really needs it. For instance if anyone has shipped code, that uses the 1.35 vector.hpp, to customers. I do not need a vector_135.hpp header.
Actually vector_135.hpp would be compatible with all versions except 1.34 and vector_134.hpp compatible with all versions but 1.35. Just 1.34.1 and 1.35 are incompatible with each other. I guess since most 1.35 users are aware of the problem the sensible default might be being compatible with all versions but 1.35 Matthias
I dont have the knowledge of the inner coding of the archives... but as far as I understood the issue come from theses lines : if(3 < ar.get_library_version()) ar >> BOOST_SERIALIZATION_NVP(item_version); in the vector.hpp header file (load method) would it be possible to surround these lines with a try catch block in a way like this : try { if(3 < ar.get_library_version()) ar >> BOOST_SERIALIZATION_NVP(item_version); } catch(...) { do something to reset the state of the archive before the ar >> BOOST_SERIALIZATION_NVP(item_version); attempt } Is it something possible or am i just a dreamer ? would it have some performance impact ? In such a case maybe it could be a choice to have a full compatible library with an #ifdef code selection mechanism... I hope this proposal is not too ridiculous.... Regards, Mathieu -- http://www.incub.net/
On 2 Jul 2008, at 23:28, Mathieu Peyréga wrote:
I dont have the knowledge of the inner coding of the archives... but as far as I understood the issue come from theses lines :
if(3 < ar.get_library_version()) ar >> BOOST_SERIALIZATION_NVP(item_version);
in the vector.hpp header file (load method)
would it be possible to surround these lines with a try catch block in a way like this :
try { if(3 < ar.get_library_version()) ar >> BOOST_SERIALIZATION_NVP(item_version); } catch(...) { do something to reset the state of the archive before the ar >> BOOST_SERIALIZATION_NVP(item_version); attempt }
Is it something possible or am i just a dreamer ? would it have some performance impact ? In such a case maybe it could be a choice to have a full compatible library with an #ifdef code selection mechanism...
I hope this proposal is not too ridiculous....
This might or might not throw an exception, and the exception might be thrown somewhere farther along deserialization. Matthias
participants (6)
-
Johan Råde -
KSpam -
Mathieu Peyréga -
Matthias Troyer -
Pete Bartlett -
Tim St. Clair