January 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo 64bit on Ubuntu (was Re: failing tests in Pharo 7)

by Alistair Grant

Hi Ben, Many thanks for taking the trouble to reproduce this. On 8 January 2018 at 15:44, Ben Coman <btc(a)openinworld.com> wrote: > > > On 7 January 2018 at 20:38, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> Hi Ben, >> >> On 7 January 2018 at 05:22, Ben Coman <btc(a)openinworld.com> wrote: >> > Ubuntu 16.04 64bit >> > Build information: >> > Pharo-7.0+alpha.build.409.sha.bb4eaaf976e3fb148b33b6d87598022b77329768 >> > (64 Bit) >> > Virtual Machine: Pharo64/lib/pharo/5.0-201712211450/pharo >> >> I've mostly ignored 64 bit Pharo because I can't get Iceberg stable >> enough. Since you're also using Ubuntu 16.04, could I ask you to try >> (obviously somewhere it is OK to crash the vm :-)): > > > Now first up, is it just Ubuntu 16.04 with this problem? > Can other Linux users report what they get for this? > >> >> >> | pharoRepository | >> >> Iceberg enableMetacelloIntegration: true. >> Metacello new >> repository: 'github://akgrant43/pharo-akgosprocess/mc'; >> baseline: 'AKGOSProcess'; >> load. >> pharoRepository := IceRepository registry detect: [ :each | each name >> = 'pharo-akgosprocess' ]. >> pharoRepository pull. >> >> >> And let me know the result. I get: >> >> pharo: malloc.c:2394: sysmalloc: Assertion `(old_top == initial_top >> (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && >> prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == >> 0)' failed. >> /snap/pharo7/x1/usr/bin/pharo: line 43: 21304 Aborted >> (core dumped) $pharoexe $origargs > > > Downloaded and unzipped... > http://files.pharo.org/vm/pharo-spur64/linux/pharo-linux-x86_64threaded-201… > http://files.pharo.org/image/70/Pharo-7.0.0-alpha.build.412.sha.2e40948.arc… > > Ran your script and Pharo crashed with the following in the console shell... > > https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux > pharo: malloc.c:2394: sysmalloc: Assertion `(old_top == initial_top (av) && > old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse > (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed. > Aborted (core dumped) > > > Also, anther case... > Tools > Iceberg > Clone repository > Remote url = git@github.com:bencoman/pharo.git > Local directory = /home/ben/Apps/Pharo64/pharo-local/iceberg > Code sub directory = src > clicked <Create Repository> > After "pharo master" row appears, > right-clicked on "pharo" and clicked <Synchronise> > added a comment and clicked <Commit on master> > and Pharo crashed with the following on console... > > *** Error in `./lib/pharo/5.0-201712211450/pharo': corrupted size vs. > prev_size: 0x00007fe23c020120 *** > ======= Backtrace: ========= > /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fe241a407e5] > /lib/x86_64-linux-gnu/libc.so.6(+0x7e9dc)[0x7fe241a479dc] > /lib/x86_64-linux-gnu/libc.so.6(+0x82246)[0x7fe241a4b246] > /lib/x86_64-linux-gnu/libc.so.6(__libc_calloc+0xba)[0x7fe241a4ddca] > ./lib/pharo/5.0-201712211450/libgit2.so(+0x6cd9e)[0x7fe23cc77d9e] > ./lib/pharo/5.0-201712211450/libgit2.so(+0x6eda2)[0x7fe23cc79da2] > ./lib/pharo/5.0-201712211450/libgit2.so(git_diff_tree_to_tree+0x224)[0x7fe23cc55461] > ./lib/pharo/5.0-201712211450/pharo[0x4c947e] > ./lib/pharo/5.0-201712211450/pharo[0x457c27] > ./lib/pharo/5.0-201712211450/pharo[0x459c97] > ./lib/pharo/5.0-201712211450/pharo(ceSendsupertonumArgs+0x25c)[0x45ba9c] > [0xf00100] I get the same crash dump if I follow the steps you detailed above. My C debugging skills have accumulated more than 20 years of rust and debris, but I'm almost at the point where I'll try building a debug version of the VM and have a look at this. Thanks again, Alistair

Jan. 8, 2018

Re: [Pharo-dev] Pharo 64bit on Ubuntu (was Re: failing tests in Pharo 7)

by Ben Coman

On 7 January 2018 at 20:38, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Ben, > > On 7 January 2018 at 05:22, Ben Coman <btc(a)openinworld.com> wrote: > > Ubuntu 16.04 64bit > > Build information: > > Pharo-7.0+alpha.build.409.sha.bb4eaaf976e3fb148b33b6d87598022b77329768 > (64 Bit) > > Virtual Machine: Pharo64/lib/pharo/5.0-201712211450/pharo > > I've mostly ignored 64 bit Pharo because I can't get Iceberg stable > enough. Since you're also using Ubuntu 16.04, could I ask you to try > (obviously somewhere it is OK to crash the vm :-)): > Now first up, is it just Ubuntu 16.04 with this problem? Can other Linux users report what they get for this? > > | pharoRepository | > > Iceberg enableMetacelloIntegration: true. > Metacello new > repository: 'github://akgrant43/pharo-akgosprocess/mc'; > baseline: 'AKGOSProcess'; > load. > pharoRepository := IceRepository registry detect: [ :each | each name > = 'pharo-akgosprocess' ]. > pharoRepository pull. > > > And let me know the result. I get: > > pharo: malloc.c:2394: sysmalloc: Assertion `(old_top == initial_top > (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && > prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == > 0)' failed. > /snap/pharo7/x1/usr/bin/pharo: line 43: 21304 Aborted > (core dumped) $pharoexe $origargs Downloaded and unzipped... http://files.pharo.org/vm/pharo-spur64/linux/pharo-linux-x86_64threaded-201… http://files.pharo.org/image/70/Pharo-7.0.0-alpha.build.412.sha.2e40948.arc… Ran your script and Pharo crashed with the following in the console shell... https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux pharo: malloc.c:2394: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed. Aborted (core dumped) Also, anther case... Tools > Iceberg > Clone repository Remote url = git@github.com:bencoman/pharo.git Local directory = /home/ben/Apps/Pharo64/pharo-local/iceberg Code sub directory = src clicked <Create Repository> After "pharo master" row appears, right-clicked on "pharo" and clicked <Synchronise> added a comment and clicked <Commit on master> and Pharo crashed with the following on console... *** Error in `./lib/pharo/5.0-201712211450/pharo': corrupted size vs. prev_size: 0x00007fe23c020120 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fe241a407e5] /lib/x86_64-linux-gnu/libc.so.6(+0x7e9dc)[0x7fe241a479dc] /lib/x86_64-linux-gnu/libc.so.6(+0x82246)[0x7fe241a4b246] /lib/x86_64-linux-gnu/libc.so.6(__libc_calloc+0xba)[0x7fe241a4ddca] ./lib/pharo/5.0-201712211450/libgit2.so(+0x6cd9e)[0x7fe23cc77d9e] ./lib/pharo/5.0-201712211450/libgit2.so(+0x6eda2)[0x7fe23cc79da2] ./lib/pharo/5.0-201712211450/libgit2.so(git_diff_tree_to_tree+0x224)[0x7fe23cc55461] ./lib/pharo/5.0-201712211450/pharo[0x4c947e] ./lib/pharo/5.0-201712211450/pharo[0x457c27] ./lib/pharo/5.0-201712211450/pharo[0x459c97] ./lib/pharo/5.0-201712211450/pharo(ceSendsupertonumArgs+0x25c)[0x45ba9c] [0xf00100] See attached for full dump. cheers -ben

Jan. 8, 2018

identifying source of particular VM

by Ben Coman

This filename of the VM download url... http://files.pharo.org/vm/pharo-spur64/linux/pharo-linux-x86_64threaded-201… includes a hash "276a5ff" that I presumed identified the opensmalltalk-vm commit from which this VM was built. i.e. so I could check that out if I wanted to compile a debug version of that VM. However... $ git checkout 276a5ff says... error: pathspec '276a5ff' did not match any file(s) known to git. so what exactly is that hash 276a5ff in the filename? cheers -ben

Jan. 8, 2018

Re: [Pharo-dev] Hello, Im and a litle confused. Can you help me get started please?

by Ben Coman

On 8 January 2018 at 16:54, Photon <nico-braun(a)live.de> wrote: > Hello, Folks. As is wrote in the title, I`m somewhat confused. I`m new to > programming but I think I understood what OOP is, yessterday before I > discovered Pharo, was I was able to build a simple city model in Visual > Studio (C#), with a city class which was build out of other classes wich > were build out of other classes. > City<-District<-Street<-House<-Room. So I get the idea that we want to > discribe real world systems as network of objects to be able to solve > problems within givin system. > > However I have a super hard time to grasp Pharo for some reason. What I > understood so far is that everything is an object even the classes it self, > wich is super cool by the way. I understand that as I use Pharo I have to > use the libaries aswell since there is no clear cut between language and > package. > I know the browser to a slight degree and I read allready a bit code from > some objects and methods. > But then when i try to call some methods from the classes there I fail 90% > of the time. > Be aware that there are methods on the "instance-side" of a class and also on the "class-side" of a class. One way to think about the class-side is as an implementation of the Factory Pattern. Since classes are objects too, essentially every class in the system has an associated factory-object. An important class-side factory method is #new. Send this to a class to get an instance of that class, on which you can invoke instance-side methods. > > I did not find much learning material online. Only a couple talks on Pharo > and one or two text based tutorials wich were unfortunatly pretty old, > version 1.5 or something like this. > So I really want to dig into this wonderfull subject as the concept seems > fascinating to me. I believe it can be a powerfull tool especially with the > abillity to change things runtime. > > I`d be glad to get a little advice on how to start. > > Do the MOOC and the Pharo By Example book. http://pharo.org/documentation cheers -ben

Jan. 8, 2018

Re: [Pharo-dev] Iceberg merged pull requests?

by Esteban Lorenzano

> On 6 Jan 2018, at 09:27, Bernhard Pieber <bernhard(a)pieber.com> wrote: > > Hi Esteban, > > Thanks for your answer. See more questions below. > >> Am 04.01.2018 um 09:16 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: >> >>> On 3 Jan 2018, at 23:09, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>> You should double click on the pharo lines and looks in the update >>> pane you will see the updates (but you should pull from pharo to sync >>> your repo). >>> >>> Stef >>> >>> On Tue, Jan 2, 2018 at 10:45 PM, Bernhard Pieber <bernhard(a)pieber.com> wrote: >>>> I saw that two pull requests were accepted and merged into the development branch. I had expected that Iceberg would show me them somewhere. However, in the branches pane of my repository the status pharo-project/development is shown as Up to date. >>>> >>>> Shouldn't there be some indication that new code is available to be merged, or am I misunderstanding Iceberg? >> >> you are misunderstanding iceberg :) > That's what I suspected. ;-) > >> your repository shows the status of the image against your local copy of the repository, not the remote one. >> If you want to see those changes, you need to first âfetchâ the remote repository (which will update the commits available in the local one). >> this is a task (fetching) that other tools do in background time to time (for example, sourcetree does it like when you focus on the window), to show this as a âlive experienceâ, but we cannot do the same because a call to fetch would block the image (since FFI is blocking for the moment), then you will need to do that by hand until we get threaded FFI. > Is this fetching from the upstream pharo-project repository something I should be able to do in Iceberg? I had assumed it is, but I could not find it? In SourceTree there is a command called Refresh Remote Status. Is there something akin to that in Iceberg? you have a âfetchâ action. > >> also, notice that updating Pharo from iceberg is a very bad idea, and you can have an unusable image after that (update other projects will usually work). > I am afraid I still don't understand. I thought that was the point of Iceberg? no, is not. the point of iceberg is to provide a modern VCS and to easy the usage of modern tools/processes. to be able to safely upgrade pharo you will need an atomic loader, which not pharo not any smalltalk I know of has (this is why the old update process was broken since couple of years. I know, in other dialects is usually possible but thatâs because they do not change the kernel very often and we cannot ensure that). > > If not, what is the suggested workflow for merged pull requests to the pharo-project upstream? Should I build a new development image whenever new pull requests are merged? yes, you download a new image if you want the new versions. You can always risk and mergeâ¦ there will be a fair amount of times where that can work, but I do not recommend to do that. working âon the edgeâ has this drawbacks, sadly, until we have a reliable atomic loader. cheers, Esteban > > Bernhard

Jan. 8, 2018

[Pharo 7.0-dev] Build #413: 16969-Use-a-Rectangle-instead-of-a-Margin

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #413 was: SUCCESS. The Pull Request #650 was integrated: "16969-Use-a-Rectangle-instead-of-a-Margin" Pull request url: https://github.com/pharo-project/pharo/pull/650 Issue Url: https://pharo.fogbugz.com/f/cases/16969 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 8, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2017-01-01

by Pavel Krivanek

2018-01-08 10:39 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > On 8 Jan 2018, at 10:30, Pavel Krivanek <pavel.krivanek(a)gmail.com> > 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 ? > I use an implementation that should be more memory efficient and make much less stress for the GC. It uses the old concept of pointers to a sources file but the sources file is a set of compressed segments stored in memory. When all sources compressed as a single file take about 6MB, with compression by segments it takes about 7MB. I expect that for very small methods the compressed version can save no memory at all and you would need a next extra object for every method. -- Pavel > > 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 > > > > > > >

Jan. 8, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2017-01-01

by Sven Van Caekenberghe

> On 8 Jan 2018, at 10:30, Pavel Krivanek <pavel.krivanek(a)gmail.com> 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 > >

Jan. 8, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2017-01-01

by Pavel Krivanek

ehh, new year :-D so 2018-01-01 2018-01-08 10:30 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > 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 > > >

Jan. 8, 2018

Pavel's ChangeLog week of 2017-01-01

by Pavel Krivanek

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

Jan. 8, 2018