- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] identifying source of particular VM

by Torsten Bergmann

Hi Ben, Â it is the "short" commit hash from the official OpenSmalltalk github repo so you can reproduce the "VM" build easily: Â Â https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/276a5ff Â >From Pharo 7 onwards now also the "image" is completely bootstrapped - you also have aÂ commit hash for the image to reproduce the image build/commit: Â Â https://github.com/pharo-project/pharo/commits/53eba94 Â Some details for the image hash can be found here: http://forum.world.st/SystemVersion-cleanup-or-the-return-of-the-explicit-b… Â We meanwhile also restored the image build number, so you can load the image with PharoLauncher with the build number again. The latest is 70414 as of today which mean Pharo 7, Build 414. You can go to "http://wiki.astares.com/pharo/30" and click on "alpha" to visit the Pharo CI for the build number. Side note: From some of you last posts I see you still struggling with git or IcebergÂ issues. Had similar trouble in the beginning when Â Â Â Â Â Â Â Â Pharo process was switched to git and Iceberg was introduced. Because I tried always to compare with/tried to apply what Â Â Â Â Â Â Â Â Â I knew from VisualSourceSafe, ClearCase, SVN, Envy, Monticello, ... and many other VCS systemsÂ that I used before. Â Â Â Â Â Â Â Â SoÂ I bought the "Pro Git"Â from Apress book which helped me a lot understanding "git" (also some internals) first. Â Â Â Â Â Â Â Â I can reallyÂ recommend to study it.Â It will safe you a lot of pain. Â Â Â Â Â Â Â Â You can find it on the web too: Â Â Â Â Â Â Â Â Â Â https://git-scm.com/book/en/v1 (first version) Â Â Â Â Â Â Â Â Â Â https://git-scm.com/book/en/v2 (new version) Bye T. Â Â Gesendet:Â Montag, 08. Januar 2018 um 19:45 Uhr Von:Â "Eliot Miranda" <eliot.miranda(a)gmail.com> An:Â "Pharo Development List" <pharo-dev(a)lists.pharo.org> Betreff:Â Re: [Pharo-dev] identifying source of particular VM Hi Ben, Â Â Â I think that the hash is indeed that if a commit. And I thought someone had written a script to find the commit from the hash. Â Alternatively you could look at the various system attributes the Squeak vm uses to identify itself. Â I *think* the Pharo vm has the same info baked in. Â In particular there should be the date of the commit. _,,,^..^,,,_ (phone) On Jan 8, 2018, at 6:36 AM, Ben Coman <btc@openinworld.com[mailto:btc@openinworld.com]> wrote: Â 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] identifying source of particular VM

by Alistair Grant

On 8 January 2018 at 19:45, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Ben, > > I think that the hash is indeed that if a commit. And I thought someone > had written a script to find the commit from the hash. Alternatively you > could look at the various system attributes the Squeak vm uses to identify > itself. I *think* the Pharo vm has the same info baked in. In particular > there should be the date of the commit. E.g.: $ pharo7 --version 5.0-201712221331 Tuesday 26 December 14:19:31 CET 2017 gcc 4.8.5 [Production Spur 64-bit VM] CoInterpreter VMMaker.oscog-eem.2302 uuid: 55ec8f63-cdbe-4e79-8f22-48fdea585b88 Dec 26 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2302 uuid: 55ec8f63-cdbe-4e79-8f22-48fdea585b88 Dec 26 2017 VM: 201712221331 alistair@alistair-xps13:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Date: Fri Dec 22 14:31:01 2017 +0100 $ Plugins: 201712221331 alistair@alistair-xps13:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Linux cbc086ddd661 4.10.0-42-generic #46~16.04.1-Ubuntu SMP Mon Dec 4 15:57:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux plugin path: /snap/pharo7/x1/usr/bin/pharo-vm/5.0-201712221331 [default: /snap/pharo7/x1/usr/bin/pharo-vm/5.0-201712221331/] $ scripts/checkoutVMbyDate 'Fri Dec 22 14:31:01 2017 +0100' Searching for date: (Fri Dec 22 14:31:01 2017 +0100) Note: checking out 'ec439f18e994309de62f64c23b48e35920633f39'. ... Cheers, Alistair > _,,,^..^,,,_ (phone) > > On Jan 8, 2018, at 6:36 AM, Ben Coman <btc(a)openinworld.com> wrote: > > 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] identifying source of particular VM

by Eliot Miranda

Hi Ben, I think that the hash is indeed that if a commit. And I thought someone had written a script to find the commit from the hash. Alternatively you could look at the various system attributes the Squeak vm uses to identify itself. I *think* the Pharo vm has the same info baked in. In particular there should be the date of the commit. _,,,^..^,,,_ (phone) > On Jan 8, 2018, at 6:36 AM, Ben Coman <btc(a)openinworld.com> wrote: > > 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] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Esteban Lorenzano

> On 8 Jan 2018, at 17:57, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Ben, > > On 8 January 2018 at 17:34, Ben Coman <btc(a)openinworld.com> wrote: >> >> [ snip ] >> >> A couple of things would make it even smoother. >> a. An option to save details of my personal fork to auto-fill the Create >> Repository dialog fields in a fresh image anywhere on my system. >> b. An menu item or button to auto-fill the pharo-project remote. this is done usually through startup actions. for example, I have: StartupPreferencesLoader default executeAtomicItems: { StartupAction name: 'Iceberg' code: [ Iceberg enableMetacelloIntegration: true. IceRepository shareRepositoriesBetweenImages: true; sharedRepositoriesLocationString: '/Users/esteban/Dev/Repository'. (IceRepositoryCreator new location: '/Users/esteban/Dev/Repository/pharo-project/pharo' asFileReference; subdirectory: 'src'; createRepository) register ] runOnce: true. }. (you put that in an âiceberg.st <http://iceberg.st/>â in /Users/esteban/Library/Preferences/pharo/7.0 (or the equivalent for your platform, that you can find executing FileLocator preferences fullName) Esteban > > This is the script I used last time to reduce the number of manual > steps. I haven't had a chance to validate it properly, but hopefully > it will help. Run this in a clean imageâ¦ > > > | username pharoRepository | > > Author fullName: '<YourName>'. > > username := '<YourGitUsername>'. > > pharoRepository := (IceRepositoryCreator new > remote: (IceRemote url: 'git(a)github.com:', username, '/pharo.git'); > subdirectory: 'src'; > createRepository) > register. > pharoRepository addRemote: (IceRemote > name: 'pharo-project' > url: 'git@github.com:pharo-project/pharo.git'). > (IcePharoCreateBranchFromIssue on: pharoRepository) execute. > > > 'Loaded pharo-core' inspect. > > > >> Now hopefully someone familiar with FastTable can review my PR >> and discuss options to implement the next step for horizontal scrolling. >> >> cheers -ben >

Jan. 8, 2018

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Alistair Grant

Hi Ben, On 8 January 2018 at 17:34, Ben Coman <btc(a)openinworld.com> wrote: > > [ snip ] > > A couple of things would make it even smoother. > a. An option to save details of my personal fork to auto-fill the Create > Repository dialog fields in a fresh image anywhere on my system. > b. An menu item or button to auto-fill the pharo-project remote. This is the script I used last time to reduce the number of manual steps. I haven't had a chance to validate it properly, but hopefully it will help. Run this in a clean image... | username pharoRepository | Author fullName: '<YourName>'. username := '<YourGitUsername>'. pharoRepository := (IceRepositoryCreator new remote: (IceRemote url: 'git(a)github.com:', username, '/pharo.git'); subdirectory: 'src'; createRepository) register. pharoRepository addRemote: (IceRemote name: 'pharo-project' url: 'git@github.com:pharo-project/pharo.git'). (IcePharoCreateBranchFromIssue on: pharoRepository) execute. 'Loaded pharo-core' inspect. > Now hopefully someone familiar with FastTable can review my PR > and discuss options to implement the next step for horizontal scrolling. > > cheers -ben

Jan. 8, 2018

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

by Ben Coman

On 5 January 2018 at 14:56, Ben Coman <btc(a)openinworld.com> wrote: > > > On 14 December 2017 at 20:19, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> Hi! >> >> Iâm working on simplifying the contribution process, after collecting >> opinions/experiences last couple of months. >> As you know, Pharo contribution process is still WIP and we aim to have >> it as smooth as possible for Pharo 7.0 release. Now, after observe the idea >> of the âsystem repositoriesâ was a bad idea because it introduced extra and >> non standard âpathâ to contribution, I managed to remove that to >> reestablish âthe regular wayâ: you will now need to add pharo repository >> just as any other repository you add, by cloning or adding local repository. >> >> I took Guilleâs doc and moved it to pharo project (it does not has sense >> to have it living in a contributorâs repository when is so important). You >> can find it here: >> >> https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo >> >> This document is also updated to reveal this new process, please read it. >> >> How to update your startup scripts? >> Some people has added startup scripts to easy the first part of >> contribution. Instead enabling system repositories, etc. you now need to >> replace that with this: >> >> (IceRepositoryCreator new >> location: '/path/to/pharo-project/pharo' asFileReference; >> subdirectory: 'src'; >> createRepository) >> register >> >> PLEASE, PLEASE, PLEASEâ¦ take a moment to read and try the document. Is >> very important that document reflects new process and works reliable in >> different scenarios (I validated it on macOS and Windows, and assumed it >> worked fine on linux but you knowâ¦ bad assumptions is the base of failure >> ;) ) >> >> Iâm eager to hear your feedback and continue enhancing the process. >> >> (yes, Stef, I know UI is still cumbersomeâ¦ Iâm working on that :) ) >> >> cheers! >> Esteban >> > > > Using https://github.com/pharo-project/pharo/wiki/ > Contribute-a-fix-to-Pharo > with my pharo branch "22 commits behind pharo-project:master" > https://github.com/bencoman/pharo/tree/master > > > <snip> > A bit disconcerting that buttons <Commit onto master> and <Commit and push > onto master> > are both disabled so there is no action I can do from this default, so I > proceed to [Push] tab. > Thanks to Esteban's help, I learnt that you have to enter a commit message before the buttons are enabled (duh me!) Now given the Iceberg trouble with Ubuntu 64bit, I reverted to 32 bit and followed the wiki Contribute-a-fix-to-Pharo as closely as I could... $ mkdir -p ~/dev/Pharo/Contribute && cd ~/dev/Pharo/Contribute $ wget -O- get.pharo.org/70+vm | bash $ ./pharo-ui Pharo.image On github, I deleted my existing fork and reforked from pharo-project/pharo. My SSH keys were previously set up... $ ls -1 ~/.ssh id_rsa id_rsa.pub known_hosts $ $ ssh -T git(a)github.com Hi bencoman! You've successfully authenticated, but GitHub does not provide shell access. In Pharo... World menu > Iceberg > Clone Repository Remote URL = git@github.com:bencoman/pharo.git Local Directory (default) = /home/ben/dev/Pharo/Contribute/pharo-local/iceberg Code subdirectory = src Clicked <Create Repository> Interesting that the created row "pharo" repository now defaults to the "development" branch. Previously it was defaulting to the "master" branch and part of my difficulty was trying to get onto the "up to date" development branch. This pharo "development" branch status has "uncommitted changes" so right-clicked "pharo" > Synchronise repository. The dialog that came up shows an empty "Local changes" tab. Because it didn't feel right to create a commit for empty changes, I was momentarily confused by this since this dialog covered the parent window where the repo status had changed to "up to date". Yay! [btw, Would it be possible (i.e. make sense) to avoid bringing up this dialog when there are empty changes and just display an #inform: message "No changes" ?] Clicked on [Remotes] tab > Add remote Remote name = pharo-project Remote url = git@github.com:pharo-project/pharo.git Right clicked "pharo" > Pharo > Create new branch from Fogbugz issue... 20937 clicked <Create> Great! the main Iceberg window shows I've changed to that branch and its up to date. Made some changes. Right clicked on "pharo" > Synchronise... Entered commit comment and clicked <Commit onto 20937...> Clicked on [Push] tab > Publish all Github shows my commit. Yay! I can see it here... https://github.com/bencoman/pharo/network Now this is not complete but at the point where I'm seeking advise on how to approach the next step. Following the philosophy that PRs are not just for finished code but a good way to seek collaboration, back in Pharo... rightclicked on "pharo > Github > Create pull request... entered username & password The dialog defaults for "New pull request" looked okay, so clicked <Create a pull request> And I can see my PR here... https://github.com/pharo-project/pharo/pull/657 Yay! Finally cracked it. The start of my first Pharo 7 contribution. I very much like this new workflow. thx esteban. A couple of things would make it even smoother. a. An option to save details of my personal fork to auto-fill the Create Repository dialog fields in a fresh image anywhere on my system. b. An menu item or button to auto-fill the pharo-project remote. Now hopefully someone familiar with FastTable can review my PR and discuss options to implement the next step for horizontal scrolling. cheers -ben

Jan. 8, 2018

[Pharo 7.0-dev] Build #414: 20939-Updating-Shift-to-v1-0-2

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

There is a new Pharo build available! The status of the build #414 was: SUCCESS. The Pull Request #655 was integrated: "20939-Updating-Shift-to-v1-0-2" Pull request url: https://github.com/pharo-project/pharo/pull/655 Issue Url: https://pharo.fogbugz.com/f/cases/20939 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 16:27 GMT+01:00 Martin Dias <tinchodias(a)gmail.com>: > > > On Mon, Jan 8, 2018 at 6:30 AM, 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 ]. >> >> 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 >> >> >> >

Jan. 8, 2018

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

by Martin Dias

On Mon, Jan 8, 2018 at 6:30 AM, 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 ]. > > 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. 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 > > >

Jan. 8, 2018

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