> On 8 Jan 2018, at 10:30, Pavel Krivanek <[email protected]> wrote: > > In memory sources file > - I slightly improved the PR for integration of the sources file inside the > object memory. Now it will be possible to extract them back to the disk from > the menu so everything can work as before. I'm not sure if it will be > integrated into Pharo 7 or we will wait for Pharo 8 but it seems to be > prepared. > > File API and caching > - because the in-memory sources file do not use deprecated > MultiByteFileStream, I played with the new file API and discovered that > ZnCharacterReadStream on File is about 10 times slower than the old > MultiByteFileStream. That's because ZnCharacterReadStream does not use any > cache. For better speed the ZnBufferedReadStream needs to be used like this: > > readStream := File openForReadFileNamed: 'file.txt'. > zn := ZnCharacterReadStream on: readStream encoding: #UTF8. > buffered := ZnBufferedReadStream on: zn. > [ buffered atEnd ] whileFalse: [ buffered next: 20000 ].
Yes, that is correct. > However the ZnBufferedReadStream is by design only a linear stream and the > position cannot be changed and thus it cannot be used for *.sources files > etc. We will need to prepare a positionable alternative. This is great work, Pavel, I know Marcus wanted this for a loooooong time ;-) Now, I thought (naively maybe) that in memory sources meant that each method object holds a single (compressed) string with its own individual source code. In such a system no positioning in a huge stream would (ever) be necessary, no ? AFAIK, the need for positioning is only to get to the right source bit in this huge pool. > Ring 2 integration > - I was working on replacing of the old Ring with the new reimplementation. > The old Ring is used on many sensitive places in the system. Mainly in tools > however it is used by Monticello and Epicea too so to try to remove it is > like to cut a branch below yourself on an undermined tree. The approach of > the old and new Ring is in many senses very different and the full > compatibility will not be supported. I partly provide compatibility API, > partly adopt the code directly. > - The real system and the model is mixed many times in the users of the old > Ring. For example a model for a method is created but then when the package > of the method is asked, it is already a real package, not its model. Such > places need to be cleaned. > - I already have an image that has no old Ring code at all but because of > some memory leaks caused by the mixtures of the models and real system I was > not able to bootstrap it successfully. More work is needed. > - I discovered that the image has a serious memory leak caused by Iceberg/GT > and Announcers but I still need to find more information about it. > > Smalltalk archeology > - during the free days on the beginning of the year I looked at Smalltalk-78. > I extracted the data from Lively Kernel so the original image can read from > external files, not only the recent updated ones. > - Then I looked at SqueakJS again and tried to reproduce Craig's experiments > with Pharo on it. Generally it is about 100 times slower than native Pharo > which makes it hard to use for real-life tasks. However it would be pity to > do not provide at least basic attention to it because in some cases it may be > really useful. > > Cheers, > -- Pavel > >
