- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

by Hilaire

Thanks guys. I hope it includes the fixes for the bugs impacting Dr. Geo. Hilaire Le 24/07/2017 Ã 13:56, Esteban Lorenzano a Ã©crit : > We are releasing Pharo -- Dr. Geo http://drgeo.eu

July 24, 2017

Re: [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

by Sven Van Caekenberghe

Thank you, sounds like a really cool move. > On 24 Jul 2017, at 13:56, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > We are releasing Pharo 6.1. > Usually, between each major version we just apply bugfixes changing the build number and not announcing new versions but this time is different since the fixes applied required a new VM. > The principal reason for the new version is to update Iceberg support, bringing it to macOS 64bits version. > > So, now Pharo 6.1 comes with Iceberg 0.5.5, which includes: > > - running on macOS 64bits > - adds cherry pick > - adds major improvements on performance for big repositories > - adds pull request review plugin > - repositories browser: group branches by remote > - adds bitbucket and gitlab to recognised providers on metacello integration > - uses libgit v0.25.1 as backend > - several bugfixes > > Other important change: > > - linux vm by default is now vm threaded heartbeat. > > We still miss 64bits Windows (sorry for that), but we are getting there. I hope to have it running right after ESUG. > > To download 6.1 version, you can go to http://pharo.org/download page, or with zeroconf: > > wget -O- get.pharo.org | bash > > Enjoy! > Esteban

July 24, 2017

Re: [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

by Tudor Girba

Great job! Doru > On Jul 24, 2017, at 1:56 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > We are releasing Pharo 6.1. > Usually, between each major version we just apply bugfixes changing the build number and not announcing new versions but this time is different since the fixes applied required a new VM. > The principal reason for the new version is to update Iceberg support, bringing it to macOS 64bits version. > > So, now Pharo 6.1 comes with Iceberg 0.5.5, which includes: > > - running on macOS 64bits > - adds cherry pick > - adds major improvements on performance for big repositories > - adds pull request review plugin > - repositories browser: group branches by remote > - adds bitbucket and gitlab to recognised providers on metacello integration > - uses libgit v0.25.1 as backend > - several bugfixes > > Other important change: > > - linux vm by default is now vm threaded heartbeat. > > We still miss 64bits Windows (sorry for that), but we are getting there. I hope to have it running right after ESUG. > > To download 6.1 version, you can go to http://pharo.org/download page, or with zeroconf: > > wget -O- get.pharo.org | bash > > Enjoy! > Esteban -- www.tudorgirba.com www.feenk.com "To lead is not to demand things, it is to make them happen."

July 24, 2017

[ANN] Pharo 6.1 (summer) released!

by Esteban Lorenzano

Hi, We are releasing Pharo 6.1. Usually, between each major version we just apply bugfixes changing the build number and not announcing new versions but this time is different since the fixes applied required a new VM. The principal reason for the new version is to update Iceberg support, bringing it to macOS 64bits version. So, now Pharo 6.1 comes with Iceberg 0.5.5, which includes: - running on macOS 64bits - adds cherry pick - adds major improvements on performance for big repositories - adds pull request review plugin - repositories browser: group branches by remote - adds bitbucket and gitlab to recognised providers on metacello integration - uses libgit v0.25.1 as backend - several bugfixes Other important change: - linux vm by default is now vm threaded heartbeat. We still miss 64bits Windows (sorry for that), but we are getting there. I hope to have it running right after ESUG. To download 6.1 version, you can go to http://pharo.org/download <http://pharo.org/download> page, or with zeroconf: wget -O- get.pharo.org | bash Enjoy! Esteban

July 24, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60510 Home: https://github.com/pharo-project/pharo-core

July 24, 2017

[pharo-project/pharo-core] f35877: 60510

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: f35877b624a127a40c6abc4aad553ff063fab522 https://github.com/pharo-project/pharo-core/commit/f35877b624a127a40c6abc4a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-07-24 (Mon, 24 Jul 2017) Changed paths: A Iceberg-Libgit.package/IceLibgitLocalRepository.class/instance/accessing/setLongpaths_global_.st A Iceberg-Metacello-Integration.package/IceBitbucketRepositoryType.class/README.md A Iceberg-Metacello-Integration.package/IceBitbucketRepositoryType.class/class/accessing/type.st A Iceberg-Metacello-Integration.package/IceBitbucketRepositoryType.class/definition.st M Iceberg-Metacello-Integration.package/IceGithubRepositoryType.class/README.md M Iceberg-Metacello-Integration.package/IceGithubRepositoryType.class/definition.st M Iceberg-Metacello-Integration.package/IceGithubRepositoryType.class/instance/accessing/mcRepository.st A Iceberg-Metacello-Integration.package/IceGitlabRepositoryType.class/README.md A Iceberg-Metacello-Integration.package/IceGitlabRepositoryType.class/class/accessing/type.st A Iceberg-Metacello-Integration.package/IceGitlabRepositoryType.class/definition.st M Iceberg-Metacello-Integration.package/IceMetacelloPharoPlatform.class/instance/repository creation/createRepository_.st M Iceberg-Metacello-Integration.package/IceMetacelloRepositoryType.class/class/accessing/allTypes.st M Iceberg-Metacello-Integration.package/IceMetacelloRepositoryType.class/class/instance creation/for_.st A Iceberg-Metacello-Integration.package/IceMetacelloRepositoryType.class/class/testing/isAbstract.st A Iceberg-Metacello-Integration.package/IceProviderRepositoryType.class/README.md A Iceberg-Metacello-Integration.package/IceProviderRepositoryType.class/class/testing/isAbstract.st A Iceberg-Metacello-Integration.package/IceProviderRepositoryType.class/definition.st A Iceberg-Metacello-Integration.package/IceProviderRepositoryType.class/instance/accessing/mcRepository.st A Iceberg-Plugin-GitHub.package/IceGitHubPullRequestBrowser.class/instance/accessing/mergeBaseCommitFor_.st A Iceberg-Plugin-GitHub.package/IceGitHubPullRequestBrowser.class/instance/accessing/mergeBaseFor_.st M Iceberg-Plugin-GitHub.package/IceGitHubPullRequestBrowser.class/instance/building/addChangesTreeTo_with_.st M Iceberg-Plugin.package/IcePharoFogbugzModel.class/instance/initialization/initializeWidgets.st M Iceberg-Plugin.package/IcePharoFogbugzModel.class/instance/private/validateIssue_.st A Iceberg.package/IceCommitInfo.class/instance/accessing/compatibleTimestamp.st A Iceberg.package/IceRepository.class/instance/accessing/mergeBaseBetween_and_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60509.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60510.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60509.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60510.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60510 20268 update iceberg v0.5.5 https://pharo.fogbugz.com/f/cases/20268 http://files.pharo.org/image/60/60510.zip

July 24, 2017

Re: [Pharo-dev] New Launcher not working (Windows)

by Jan BlizniÄenko

Hello Alright, thanks for the answer, seems like a nice feature to have :) It would be even nicer, for the future, if it could optionally update already existing VMs to current stable ones (if there is more current stable one suitable for the image and user checked that he wants auto-updating VMs, download it and replace current one if it is not in use right now). Anyway, I will wait for your announcement then, thank you. There is one more problem (much less important though) I have for a very long time with Launcher on Windows so I will mention it now. Directories of Pharo images often contain quite deep structures of directories, like when I download a package from 'github://dalehenrich/filetree:pharo6.0_dev/repository' repository, it creates github-cache\dalehenrich\filetree\pharo6.0_dev\dalehenrich-filetree-8f6bc62\repository\MonticelloFileTree-Git.package\MCFileTreeGitRepository.class\instance\packageDescriptionsFromReadableFileNames.st inside the directory of the image. When I try to delete the github-cache directory manually using Windows file explorer (putting it into recycle bin), I get a dialog window which tells me that it does not fit into the bin and asks whether to remove it completely (yes, path lenght limitations even in most recent version of Windows). If I try to delete such image via Launcher, I get a FileDoesNotExist error for some file in such deep directory. If I remove that github-cache directory manually first (or just those too deep directories), Launcher then removes everything else just fine. It is no great problem to keep removing image folders manually outside of Launcher and there are certainly more important things to improve and fix, but if there was some relatively easy fix (probably there isn't), it would be great. Jan Dne 24.07.2017 v 10:22 demarey [via Smalltalk] napsal(a): > Hi Jan, > > Iâm currently updating the Pharo Launcher so that it can determine the > right VM to use to launch an image and download it if not available on > disk. > It is almost finished but not yet ready! > On Windows, there was indeed a bug in the executable name to find. It > is now fixed on the latest build but I do not think the Launcher will > work because the vm for 60 is buggy. OSProcess (used by the launcher) > cannot work wit this VM. Iâm waiting the publication of Pharo 6.1 with > its VM (with OSProcess bug fixed) to publish and announce the new > Launcher version. > If you do not want to wait, you can replace the pharo 6.0 vm shipped > with the Launcher with a Pharo 70 vm. It will work. > > Regards, > Christophe > > Le 24 juil. 2017 Ã 00:28, Jan BlizniÄenko <[hidden email] > </user/SendEmail.jtp?type=node&node=4956518&i=0>> a Ã©crit : > > > > > Hello > > > > It seems I am not able to open an image via new Launcher for Windows. > > I have downloaded new build of Pharo Launcher for Windows from > > https://ci.inria.fr/pharo/job/Launcher-Win/ ( > pharo_installer-0.2.13.exe ) > > and it starts ok, downloads image ok, but I am unable to open it, > although > > opening images works fine in older launcher ( > pharo_installer-0.2.11.exe > > from 28. 2. 2017). > > > > First time I tried opening the image (double clicking on it in the > list), > > loading bar "Determining Image version" showed up and remained > frozen like > > that without any progress shown in the bar. I gave it 10 minutes, > but no > > change, still stuck like that. UI was not responding, so I > terminated it via > > alt+. > > > > Second time I tried opening the image via the Launcher, that > "Determining" > > bar was there only for a second and then it was replaced by > "Fetching VM to > > run Pharo 60 images" which seemed to be really fetching something, > but after > > another second or two, it got stuck in the middle of the process and > got an > > error "KeyNotFound: key '60' not found in Dictionary". > > > > Well, it seemed like I got further, so third time is a charm. This > time, > > instead of previous error, I got "FileExists: File > > @C:\Users\User\Documents\Pharo\vms\60.zip", which is quite > understandable > > since previous process did not successfully cleaned up after itself. > > > > I tried it repeatedly, tried it with both old (already existing) and > new > > images (downloaded in new Launcher) and I tried removing whole Pharo > folder > > in Documents, but every time I get stuck with one of those problems > above. > > > > There is a PharoDebug.log with logs of interrput and errors > mentioned above: > > PharoDebug.log <http://forum.world.st/file/n4956495/PharoDebug.log> > > > > Note that I can open those images just fine by opening them directly > from > > Windows file explorer or via old Launcher, just not in the new > Launcher. > > > > Windows 10 Pro v1703 64bit. > > > > Thank you > > Jan > > > > > > > > > > -- > > View this message in context: > http://forum.world.st/New-Launcher-not-working-Windows-tp4956495.html > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > > > ------------------------------------------------------------------------ > If you reply to this email, your message will be added to the > discussion below: > http://forum.world.st/New-Launcher-not-working-Windows-tp4956495p4956518.ht… > > To unsubscribe from New Launcher not working (Windows), click here > <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…>. > NAML > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > -- View this message in context: http://forum.world.st/New-Launcher-not-working-Windows-tp4956495p4956532.ht… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 24, 2017

Re: [Pharo-dev] FileSystem file attributes and #isSymlink patch

by Max Leske

Nice work Alistair! On 24 July 2017 at 10:10:09, Alistair Grant (akgrant0710(a)gmail.com) wrote: Hi All, I'm nearly ready to submit a patch that started with the goal of being able to retrieve the device id and fixing FileReference>>isSymlink and also follows Esteban's suggestion of splitting out file existence and other attributes (which provides a performace gain). See the summary below for a description of the changes. The patch involves adding a new VM plugin, FileAttriubutesPlugin. To minimise the chance of any problems along the way I'd like to submit the patch in three steps: 1. Add the VM plugin (FileAttributesPlugin) 2. Add the code the image that allows testing of the code and plugin, but doesn't do any integration with existing functionality. This will allow the plugin to be tested by a few volunteers (hopefully). 3. Add the patches that make the switch over to the new implementation. Can someone point me to how to submit a new VM plugin? The code is contained in a subclass of InterpreterPlugin. I've been using this as my production environment for about 2 months now on a linux 32 bit VM. Running the full test suite results in the same set of test failing before and after applying the patch. I've also ran file related tests on linux 64 bit (run the Test Runner, select all packages with "file" as part of the name and run all the available tests) and the full test suite on Windows 32 bit. The summary is: 1. #isSymlink now works properly on Linux (and it should also work on MacOS and BSD). 2. The list of file attributes available from FileReference now is: #accessTime (new) #changeTime (new) #creationTime #deviceId (new) #exists #gid (new) #inode (new) #isBlock (new) #isCharacter (new) #isDirectory #isExecutable (new) #isFIFO (new) #isFile #isReadable #isRegular (new) #isSocket (new) #isSymlink (works) #isWritable #modificationTime #numberOfHardLinks (new) #permissions #size #targetFile (new) #uid (new) 3. FileReference>>exists is faster than before (well, at least on my linux laptop). This is useful as it is called quite often. 4. It is possible to retrieve symbolic link attributes, e.g. all the attributes listed above plus the target path. Given how similar MacOS and BSD are to linux, I assume that this will all work without problem on those platforms (but it obviously needs to be tested). As implied above, the changes are all backward compatible (except the broken #isSymlink), although a couple deserve mention: 1. Obviously #isSymlink now answers correctly (previously it would only answer correctly for a broken link). 2. Requesting any of the attributes listed above (except #isSymlink) will return the value of the target path. If the FileReference is to a broken symbolic link, it will return the attributes of the symbolic link (keeping existing behaviour). 3. The attributes of a symbolic link can be retrieved using FileReference>>symlinkAttributes. Overall, performance is slightly better than before. Code that needs to access multiple attributes and is written to take advantage of the new behaviour will see significant performance improvements. If you've got this far and forgotten the original question :-) Can someone point me to how to submit a new VM plugin? Thanks, Alistair

July 24, 2017

Re: [Pharo-dev] New Launcher not working (Windows)

by Christophe Demarey

Hi Jan, Iâm currently updating the Pharo Launcher so that it can determine the right VM to use to launch an image and download it if not available on disk. It is almost finished but not yet ready! On Windows, there was indeed a bug in the executable name to find. It is now fixed on the latest build but I do not think the Launcher will work because the vm for 60 is buggy. OSProcess (used by the launcher) cannot work wit this VM. Iâm waiting the publication of Pharo 6.1 with its VM (with OSProcess bug fixed) to publish and announce the new Launcher version. If you do not want to wait, you can replace the pharo 6.0 vm shipped with the Launcher with a Pharo 70 vm. It will work. Regards, Christophe Le 24 juil. 2017 Ã 00:28, Jan BlizniÄenko <bliznjan(a)fit.cvut.cz> a Ã©crit : > > Hello > > It seems I am not able to open an image via new Launcher for Windows. > I have downloaded new build of Pharo Launcher for Windows from > https://ci.inria.fr/pharo/job/Launcher-Win/ ( pharo_installer-0.2.13.exe ) > and it starts ok, downloads image ok, but I am unable to open it, although > opening images works fine in older launcher ( pharo_installer-0.2.11.exe > from 28. 2. 2017). > > First time I tried opening the image (double clicking on it in the list), > loading bar "Determining Image version" showed up and remained frozen like > that without any progress shown in the bar. I gave it 10 minutes, but no > change, still stuck like that. UI was not responding, so I terminated it via > alt+. > > Second time I tried opening the image via the Launcher, that "Determining" > bar was there only for a second and then it was replaced by "Fetching VM to > run Pharo 60 images" which seemed to be really fetching something, but after > another second or two, it got stuck in the middle of the process and got an > error "KeyNotFound: key '60' not found in Dictionary". > > Well, it seemed like I got further, so third time is a charm. This time, > instead of previous error, I got "FileExists: File > @C:\Users\User\Documents\Pharo\vms\60.zip", which is quite understandable > since previous process did not successfully cleaned up after itself. > > I tried it repeatedly, tried it with both old (already existing) and new > images (downloaded in new Launcher) and I tried removing whole Pharo folder > in Documents, but every time I get stuck with one of those problems above. > > There is a PharoDebug.log with logs of interrput and errors mentioned above: > PharoDebug.log <http://forum.world.st/file/n4956495/PharoDebug.log> > > Note that I can open those images just fine by opening them directly from > Windows file explorer or via old Launcher, just not in the new Launcher. > > Windows 10 Pro v1703 64bit. > > Thank you > Jan > > > > > -- > View this message in context: http://forum.world.st/New-Launcher-not-working-Windows-tp4956495.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

July 24, 2017

FileSystem file attributes and #isSymlink patch

by Alistair Grant

Hi All, I'm nearly ready to submit a patch that started with the goal of being able to retrieve the device id and fixing FileReference>>isSymlink and also follows Esteban's suggestion of splitting out file existence and other attributes (which provides a performace gain). See the summary below for a description of the changes. The patch involves adding a new VM plugin, FileAttriubutesPlugin. To minimise the chance of any problems along the way I'd like to submit the patch in three steps: 1. Add the VM plugin (FileAttributesPlugin) 2. Add the code the image that allows testing of the code and plugin, but doesn't do any integration with existing functionality. This will allow the plugin to be tested by a few volunteers (hopefully). 3. Add the patches that make the switch over to the new implementation. Can someone point me to how to submit a new VM plugin? The code is contained in a subclass of InterpreterPlugin. I've been using this as my production environment for about 2 months now on a linux 32 bit VM. Running the full test suite results in the same set of test failing before and after applying the patch. I've also ran file related tests on linux 64 bit (run the Test Runner, select all packages with "file" as part of the name and run all the available tests) and the full test suite on Windows 32 bit. The summary is: 1. #isSymlink now works properly on Linux (and it should also work on MacOS and BSD). 2. The list of file attributes available from FileReference now is: #accessTime (new) #changeTime (new) #creationTime #deviceId (new) #exists #gid (new) #inode (new) #isBlock (new) #isCharacter (new) #isDirectory #isExecutable (new) #isFIFO (new) #isFile #isReadable #isRegular (new) #isSocket (new) #isSymlink (works) #isWritable #modificationTime #numberOfHardLinks (new) #permissions #size #targetFile (new) #uid (new) 3. FileReference>>exists is faster than before (well, at least on my linux laptop). This is useful as it is called quite often. 4. It is possible to retrieve symbolic link attributes, e.g. all the attributes listed above plus the target path. Given how similar MacOS and BSD are to linux, I assume that this will all work without problem on those platforms (but it obviously needs to be tested). As implied above, the changes are all backward compatible (except the broken #isSymlink), although a couple deserve mention: 1. Obviously #isSymlink now answers correctly (previously it would only answer correctly for a broken link). 2. Requesting any of the attributes listed above (except #isSymlink) will return the value of the target path. If the FileReference is to a broken symbolic link, it will return the attributes of the symbolic link (keeping existing behaviour). 3. The attributes of a symbolic link can be retrieved using FileReference>>symlinkAttributes. Overall, performance is slightly better than before. Code that needs to access multiple attributes and is written to take advantage of the new behaviour will see significant performance improvements. If you've got this far and forgotten the original question :-) Can someone point me to how to submit a new VM plugin? Thanks, Alistair

July 24, 2017