2018-01-08 22:42 GMT+01:00 Stephane Ducasse <[email protected]>:
> Hi Pavel > > I was thinking that it would be nice to have a simple DB build in > Pharo (I thought that CDB could do the job) to manage source. > Because I like the idea that when the system crashes I only lose at > max the method I'm editing. > Esteban did once a try to connect a tokyo tyrant db now I would prefer > to avoid to have FFI in the middle. > To me we should **********stabilise*********** pharo for real. > There is a lot of things we want to change in the system. Just integration of Calypso and removal of the old FileStream users could cause a lot of issues. So we should really think what to do with Pharo 7 release. Of course I would like to see a lot of the cool new features in Pharo 7 but we will probably need to decide between some of them and stability. Compressed in-memory sources are of course not really important. -- Pavel > Stef > > On Mon, Jan 8, 2018 at 4:50 PM, Pavel Krivanek <[email protected]> > wrote: > > > > > > 2018-01-08 16:27 GMT+01:00 Martin Dias <[email protected]>: > >> > >> > >> > >> On Mon, Jan 8, 2018 at 6:30 AM, 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 ]. > >>> > >>> 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. > >> > >> > >> Great news. I didn't look at Ring 2 code recently but I say your esug > talk > >> and I imagine it will fit well for the change model and UI tool. > >> > >> What may need attention is serialization to text file. Right now, the > Ring > >> 1 object returned by asRingDefinition (+ some tweaks) is serialized and > >> materialized via STON into the .ombu files. With Ring 2 serialized with > >> STON, the file format will be different and in consequence the new > epicea > >> won't be able to open a .ombu file generated in Ring 1. Not sure if > Pharo > >> community find this acceptable. IMO it is. > >> - If not-acceptable, there could be some workaround. > >> - If acceptable, that's the easiest path, and also it could be a good > >> opportunity to improve the file format: It could be more compact and > even > >> have a better extension such as .epicea or something that comunicates > that > >> tthose files have code changes or sessions. > > > > > > I think that the change of the format is not a a practical issue because > > probably no-one will need to read the old Ombu files from a different > Pharo > > version. > > But a change of the format will be handy because every Ring2 model is a > > standalone environment and Ombu thus saves all information that it > includes. > > So a simple method change creates a record with almost 400 lines. It > must be > > of course much slower too. > > > > -- Pavel > > > >> > >> cheers, > >> MartÃn > >> > >>> > >>> - 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 > >>> > >>> > >> > > > >
