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 ]. 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. 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