It probably should be noted here as well that http://pharo.gemtalksystems.com/book/PharoTools/SIXX/ (Smalltalk Instance eXchange in XML) http://www.mars.dti.ne.jp/~umejava/smalltalk/sixx/index.html
allows to transfer data from one image version to another image version / Smalltalk dialect. The format is useful for long-term storage. It is actively maintained. --Hannes On 12/16/15, Mariano Martinez Peck <[email protected]> wrote: > On Wed, Dec 16, 2015 at 10:17 AM, Sven Van Caekenberghe <[email protected]> > wrote: > >> OK, thanks for the explanation, good to hear it. >> >> (But, just nitpicking, it still does not say officially 'you can safely >> save your data in Fuel format and rest assured that you will always be >> able >> to read it back'). >> >> > No, I can't say that (at least myself). It does mean it's not possible, it > simply means that it will take some time to make it work and so if nobody > does it, it won't work. > > However, note that the efforts seem to have been much smaller than years > ago. For example, with very little changes, it's likely we could have > manage automatically from Pharo 3.0 until now. > > >> (Also, if there are compatibility problems between Pharo versions >> (understandably Pharo's doing), how can there be compatibility with other >> Smalltalk implementation, not that I expect any, but again, what is the >> official word ?) >> > > There is none compatibility with other Smalltalk versions in the sense that > a serialized stream in one st could be materialized in another st. > > However, note that what we DO support is that Fuel works in every possible > version of Pharo and in a wide range of latest squeak images. > > >> >> > On 16 Dec 2015, at 14:10, Mariano Martinez Peck <[email protected]> >> wrote: >> > >> > Hi guys, >> > >> > I would like to say a couple of things: >> > >> > 1) Fuel format: Sven is right in the sense that Fuel has problems of >> migrating to another Fuel version. However.... there is some explanation >> needed here. Previously (years ago), a given Fuel version was not >> compatible with previous versions because we were still >> changing/improving >> what we call Fuel format, that is, basically, how objects are written and >> read from the stream. We have stopped with those optimization/changes >> years >> ago. So the "Fuel format" has been stable so far for a couple of years. >> > >> > 2) Fuel gets in the internals: In Pharo 4.0 Fuel was not compatible >> with Fuel from 3.0. I don't remember the exact detail but it was a change >> in Pharo's Date (or DateAndTime I cannot remember). Now the version that >> should work in 5.0 changes the Characater serialization. What I want to >> make clear here is that it's NOT that we are changing the fuel format 1) >> as >> years ago when Fuel as still evolving from this point of view. It's Pharo >> changes that make our incompatibility. But that doesn't mean we cannot >> fix >> it. >> > >> > 3) Yes, compromises for speed: I think that both examples that break >> compatibility in 4.0 (Date / DateAndTime change) and in 5.0 with Spur >> (Character) is because we target speed. We do have special clusters for >> both of those cases (Date and Character), and so, we get into it's >> internals for performance reasons. If the internals change, then we >> break. >> This is why a text serializer for example may simply not break, because >> it >> continues using text representation that might not have been affected by >> the underlaying internal representation. >> > >> > We will try to do a Pharo 40 - Pharo 5.0 (or spur actually) >> compatibility. >> > >> > Best, >> > >> > >> > On Wed, Dec 16, 2015 at 9:49 AM, Sven Van Caekenberghe <[email protected]> >> wrote: >> > >> > > On 16 Dec 2015, at 13:46, Denis Kudriashov <[email protected]> >> wrote: >> > > >> > > Hi. >> > > >> > > 2015-12-16 13:33 GMT+01:00 Sven Van Caekenberghe <[email protected]>: >> > > > On 16 Dec 2015, at 13:24, Clément Bera <[email protected]> >> wrote: >> > > > >> > > > I don't know if SqueakV3 - Spur32 support is needed, however, I >> think it is really important to be able to serialize and materialize >> objects between 32 bits spur images and 64bits spur images. >> > > >> > > I don't know. >> > > >> > > Yes it would be nice, but since Fuel cannot even exchange data >> > > between >> different version itself (If I understand the situation correctly), why >> should that have to work ? >> > > >> > > It is needed to use fuel as communication format between services >> which run on different platforms. For example you can exchange data >> between >> 64bits server and 32bits android phone. >> > >> > What you want might not be the same to what it was designed for. >> > >> > I might be wrong, but that is how I understood it from discussion in >> > the >> past when moving data from one fuel version to another. >> > >> > Let's see what the Fuel guys have to say about this. >> > >> > >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >
