> On 8 Jan 2018, at 23:09, Pavel Krivanek <[email protected]> wrote: > > > > 2018-01-08 22:42 GMT+01:00 Stephane Ducasse <[email protected] > <mailto:[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.
cdb cannot because it means “constant database” : once created, cannot be modified and we will need to install sources there. tyrantdb was just a PoC… it was cool, but just that… lot of work to make it a real replacement (and also, there is the FFI dependence problem). > 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. yes. I still didn’t do the “freeze” call because there are tons of things that still need a lot of work. and we still need to introduce SISTA (preview). but I would not introduce anything else right now, and that includes Calypso, image-based-sources (or DB sources) and any of the cool stuff we have in the pipeline… just because if we introduce it we will release super later. Esteban > > -- Pavel > > > > Stef > > On Mon, Jan 8, 2018 at 4:50 PM, Pavel Krivanek <[email protected] > <mailto:[email protected]>> wrote: > > > > > > 2018-01-08 16:27 GMT+01:00 Martin Dias <[email protected] > > <mailto:[email protected]>>: > >> > >> > >> > >> On Mon, Jan 8, 2018 at 6:30 AM, Pavel Krivanek <[email protected] > >> <mailto:[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 > >>> > >>> > >> > > > >
