- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] a047f3: 50504

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: a047f3e0a1dea3d9fca29d0e212ccbe38d47806a https://github.com/pharo-project/pharo-core/commit/a047f3e0a1dea3d9fca29d0e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-12-16 (Wed, 16 Dec 2015) Changed paths: R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50503.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50504.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50503.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50504.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50504 17249 Integrate weak announcement changes (spur migration) https://pharo.fogbugz.com/f/cases/17249 17252 integrate Compiler changes (spur migration) https://pharo.fogbugz.com/f/cases/17252 http://files.pharo.org/image/50/50504.zip

Dec. 16, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50504 Home: https://github.com/pharo-project/pharo-core

Dec. 16, 2015

Re: [Pharo-dev] Fuel materialization on spur

by H. Hirzel

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 <marianopeck(a)gmail.com> wrote: > On Wed, Dec 16, 2015 at 10:17 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > 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 <marianopeck(a)gmail.com> >> 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 <sven(a)stfx.eu> >> wrote: >> > >> > > On 16 Dec 2015, at 13:46, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> > > >> > > Hi. >> > > >> > > 2015-12-16 13:33 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> > > > On 16 Dec 2015, at 13:24, ClÃ©ment Bera <bera.clement(a)gmail.com> >> 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 >

Dec. 16, 2015

Re: [Pharo-dev] Fuel materialization on spur

by Mariano Martinez Peck

On Wed, Dec 16, 2015 at 10:17 AM, Sven Van Caekenberghe <sven(a)stfx.eu> 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 <marianopeck(a)gmail.com> > 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 <sven(a)stfx.eu> > wrote: > > > > > On 16 Dec 2015, at 13:46, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > > > > > Hi. > > > > > > 2015-12-16 13:33 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > On 16 Dec 2015, at 13:24, ClÃ©ment Bera <bera.clement(a)gmail.com> > 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

Dec. 16, 2015

Re: [Pharo-dev] Fuel materialization on spur

by Sven Van Caekenberghe

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'). (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 ?) > On 16 Dec 2015, at 14:10, Mariano Martinez Peck <marianopeck(a)gmail.com> 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 <sven(a)stfx.eu> wrote: > > > On 16 Dec 2015, at 13:46, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > > Hi. > > > > 2015-12-16 13:33 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 16 Dec 2015, at 13:24, ClÃ©ment Bera <bera.clement(a)gmail.com> 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

Dec. 16, 2015

Re: [Pharo-dev] Fuel materialization on spur

by Mariano Martinez Peck

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 <sven(a)stfx.eu> wrote: > > > On 16 Dec 2015, at 13:46, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > > Hi. > > > > 2015-12-16 13:33 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 16 Dec 2015, at 13:24, ClÃ©ment Bera <bera.clement(a)gmail.com> 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

Dec. 16, 2015

Re: [Pharo-dev] Fuel materialization on spur

by Denis Kudriashov

2015-12-16 13:49 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > 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. Will see what they answer. But supporting different versions of Fuel is not same as supporting single format for any platform

Dec. 16, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50503 Home: https://github.com/pharo-project/pharo-core

Dec. 16, 2015

[pharo-project/pharo-core] 715494: 50503

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 71549497531da1216508a2948b7284d6bbcf0922 https://github.com/pharo-project/pharo-core/commit/71549497531da1216508a294… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-12-16 (Wed, 16 Dec 2015) Changed paths: R Kernel.package/Behavior.class/instance/accessing instances and variables/allInstances.st R Kernel.package/Behavior.class/instance/accessing/typeOfClass.st R Kernel.package/Behavior.class/instance/enumerating/allInstancesDo_.st R Kernel.package/Behavior.class/instance/private/indexIfCompact.st R Kernel.package/Behavior.class/instance/testing class hierarchy/kindOfSubclass.st R Kernel.package/Behavior.class/instance/testing/instSpec.st R Kernel.package/Behavior.class/instance/testing/isBits.st R Kernel.package/Behavior.class/instance/testing/isBytes.st R Kernel.package/Behavior.class/instance/testing/isVariable.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50502.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50503.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50502.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50503.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Traits.package/TraitBehavior.class/instance/testing class hierarchy/kindOfSubclass.st R Traits.package/TraitBehavior.class/instance/testing/instSpec.st R Traits.package/TraitBehavior.class/instance/testing/isBits.st R Traits.package/TraitBehavior.class/instance/testing/isBytes.st R Traits.package/TraitBehavior.class/instance/testing/isVariable.st Log Message: ----------- 50503 17237 restore trait methods (spur migration) https://pharo.fogbugz.com/f/cases/17237 http://files.pharo.org/image/50/50503.zip

Dec. 16, 2015

Re: [Pharo-dev] Fuel materialization on spur

by Sven Van Caekenberghe

> On 16 Dec 2015, at 13:46, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi. > > 2015-12-16 13:33 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 16 Dec 2015, at 13:24, ClÃ©ment Bera <bera.clement(a)gmail.com> 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.

Dec. 16, 2015