2017-12-28 16:21 GMT+01:00 Pavel Krivanek <pavel.kriva...@gmail.com>:
> > > 2017-12-28 16:00 GMT+01:00 Denis Kudriashov <dionisi...@gmail.com>: > >> Nice. >> >> 2017-12-28 15:50 GMT+01:00 Pavel Krivanek <pavel.kriva...@gmail.com>: >> >>> Hi, >>> >>> when the Pharo 7 image is being built on top of the bootstrapped image, >>> all loaded code is placed in the changes file so this process ends with an >>> empty sources file, huge changes file and the image. We condense the >>> sources file for every build so we distribute the Pharo 7 as three >>> files - image, huge sources (over 30 MB) and almost empty changes file. >>> As consequence every build has own sources file that can be shared >>> between images based on the same build - so when we will release the >>> Pharo 7, the sources file can be shared as it was for previous >>> releases, but as soon as some fixing version of Pharo 7 will be >>> released, it will require a new specific sources file. >>> >>> As one possible solution I tried to create a pull request that >>> resurrects from oblivion an old code made for Squeak 3.7 that introduced >>> option of compressed sources files. Such files use segments that are stored >>> in compressed form so it is not so small as one single zip file but still >>> good enough. From original uncompressed file of size 30.8 MB it generates >>> 7.1 MB file while single zip has 6.1 MB. >>> >>> Of course the image file is bigger but: >>> - the amount of new objects is low so it should not make much more >>> stress on GC >>> >> >> And how many objects it adds? (how many sections are compressed?) >> > > It uses currently 1619 segments of size 20000 bytes but that does not mean > that such amount of objects is needed because in the memory filesystem all > the (compressed) data are in single ByteArray and the stream class uses a > very simple segments table - one big array of 1619 integer items that > contain indexes to the ByteArray. > > >> >>> - we already used to have big images because the condenser was not >>> working and it was not a big issue >>> - the amount of distributed files will be the same as in case of Pharo >>> 6 (image+changes) so it means less troubles >>> - the sources file can be easily restored, deleted from the object >>> memory and used the same way as before >>> - we are not using the nice concept of the image well enough. All data >>> that are not really shared between images or serve as backup information >>> should be stored inside image >>> >> >> Can we avoid empty changes file? We can create it on demand (when user >> modifies code for example). >> > > I think we can because it contains only do-its. We should be able to > simply delete it and only modify the image start-up do do not require it. > It is unbelievable that we can have single image file. I think it is very attractive goal for Pharo 7. And it is so close. > > -- Pavel > > >> >> >>> >>> Please review this PR. As a side effect it makes the sources file >>> mechanism (but not changes file) independent on the FileStream classes >>> that are deprecated. >>> >>> PR: https://github.com/pharo-project/pharo/pull/631 >>> >>> The pre-built image: >>> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20 >>> pull%20request%20and%20branch%20Pipeline/job/PR-631/lastSuccessfulBuild >>> /artifact/bootstrap-cache/Pharo7.0-32bit-57ddc75.zip >>> >>> Cheers, >>> -- Pavel >>> >>> >>> >> >> >
