- Pharo-dev - lists.pharo.org

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

by Alistair Grant

Hi David, Thanks very much for your follow-up. On Mon, Jul 24, 2017 at 07:28:07PM -0400, David T. Lewis wrote: > > Hi Alistair, > > I am copying this to vm-dev for follow up on the plugin, see below. > > > On Mon, Jul 24, 2017 at 08:09:10AM +0000, Alistair Grant 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. > > > > I think you are handling this in exactly the right way, kudos. > > > > > Can someone point me to how to submit a new VM plugin? The code is > > contained in a subclass of InterpreterPlugin. > > Following up on the vm-dev list: If your plugin is available in a Monticello > repository, that would be great because VM builders can easily include it > and try it out. Any repository would be fine for starters, or if you have > an account on squeaksource.com I can add you as developer in the somewhat > loosely-related DirectoryPlugin project if that is of any help. Whatever is > convenient for you. smalltalkhub.com is probably easiest for me, thanks. > Your plugin sounds like something that would be stable and require little > maintenance over time, so it might make sense to pull it directly into > the VMMaker package. We can discuss that vm-dev list. I'm hoping this will become a core part of Pharo, so ultimately it should live with the other Pharo core plugins like FilePlugin (assuming it is accepted, of course). > Once your plugin code is available, it should be straighforward to start > including it in the various VM build configurations. Great, thanks. build.linux32x86/pharo.cog.spur is probably the best place to start. I should be able to post the plugin to smalltalkhub.com quite quickly. The smalltalk code will take me a while to repackage as I'll want to test it fairly carefully, and my time is very scattered (this is my hobby, but lots of family demands :-)). As a side effect, once this has been fully integrated it will be possible to get rid of at least some of the "#if Pharo" type conditionals in the FilePlugin, allowing the code to be tidied up. I'll post another reply once I've got the plugin code in smalltalkhub.com. Thanks again, Alistair > Dave > > > > > > 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 25, 2017

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

by Hilaire

Meaning these tow ones ? http://forum.world.st/Regression-with-PNGReaderWriter-in-P6-td4951796.html#… http://forum.world.st/WrapAthen-World-coordinate-td4951750.html#a4951966 Hilaire Le 24/07/2017 Ã 15:11, Hilaire a Ã©crit : > I hope it includes the fixes for the bugs impacting Dr. Geo. -- Dr. Geo http://drgeo.eu

July 25, 2017

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

by Tudor Girba

Thank you very much, indeed! Doru > On Jul 24, 2017, at 10:04 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > HI alistair > > this is supercool that you push this! > I mean it for real. Because this simplnk stuff was always getting on > our way for scripts. > This is really great to see this happening. > Stef > > On Mon, Jul 24, 2017 at 10:43 AM, Max Leske <maxleske(a)gmail.com> wrote: >> 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 >> > -- www.tudorgirba.com www.feenk.com "Innovation comes in the least expected form. That is, if it is expected, it already happened."

July 25, 2017

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

by David T. Lewis

Hi Alistair, I am copying this to vm-dev for follow up on the plugin, see below. On Mon, Jul 24, 2017 at 08:09:10AM +0000, Alistair Grant 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. > I think you are handling this in exactly the right way, kudos. > > Can someone point me to how to submit a new VM plugin? The code is > contained in a subclass of InterpreterPlugin. Following up on the vm-dev list: If your plugin is available in a Monticello repository, that would be great because VM builders can easily include it and try it out. Any repository would be fine for starters, or if you have an account on squeaksource.com I can add you as developer in the somewhat loosely-related DirectoryPlugin project if that is of any help. Whatever is convenient for you. Your plugin sounds like something that would be stable and require little maintenance over time, so it might make sense to pull it directly into the VMMaker package. We can discuss that vm-dev list. Once your plugin code is available, it should be straighforward to start including it in the various VM build configurations. Dave > > 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] Improving formatting [was: Big claps for Epicea (small request!)]

by Nicolas Cellier

2017-07-20 10:02 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi Nicolas > > >> The formatter is dumb. >> Let's illustrate it with literals among other things. >> I might want to write 16rBADA55, but I'm sure i never want to read >> 12245589, it makes no sense ;) > > > I wonder where you see this problem? Formatting method in Nautilus works > fine. Try checkbox "format as you read" or menu command "Format". > > Hi Denis, you're right, for literal numbers it's been solved in Pharo at least since 3.0, or maybe even 2.0 (by usage of RB AST I guess). That's a major improvment over Squeak which is is certainly where I last encountered the problem. Still, formatting does mess line breaking/indenting/commenting in literal arrays. > > 2017-07-19 23:23 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> >> On Wed, Jul 19, 2017 at 2:16 PM, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> format before diff is in the top 5 of my most hated default. >>> As an author, I try to write short methods and adhere to a standard >>> format (Kent Beck like). >>> >>> But I want the freedom to use derogation when the format helps >>> comprehension. >>> If I did the effort of using a special formatting, the last thing that I >>> want is a "smart" tool that undo my work. >>> The best time to format code is when we accept it, and only if there is >>> a quick way to undo/bypass if we don't like it. >>> >>> The formatter is dumb. >>> Let's illustrate it with literals among other things. >>> >>> I might want to write 16rBADA55, but I'm sure i never want to read >>> 12245589, it makes no sense ;) >>> (hey, this is a real example you can find in VMMaker sources, not just >>> the production of my ill brain). >>> >> >> I'd love to see literal nodes in the compilers be intelligent enough to >> know what base a literal number was in. It might be as simple as >> maintaining the literal characters that make up a token and printing using >> those, perhaps only if the token is a member of a particular set of classes. >> >> And remember this applies to numeric literals in Array and ByteArray >> literals too. >> >> >>> And if I make an effort to format a character encoding table on several >>> lines to have it readable >>> #( >>> line1 >>> line2 >>> ... >>> lineN ). >>> I'm pretty sure I never want to diff a single line with about 1024 >>> columns... >>> >> >> Th above approach might also handle this case well, although I wonder >> about comments. >> >> >>> >>> So please make this an option (with a default to false)! >>> >>> 2017-07-19 22:27 GMT+02:00 Mariano Martinez Peck <marianopeck(a)gmail.com> >>> : >>> >>>> Hi Martin, >>>> >>>> Thank you VERY MUCH for Epicea. I just had a crash and it was way more >>>> comfortable to recover changes. >>>> >>>> One small request would be to allow "Pretty Print" in the diff to the >>>> changes to be applied. Many times I changed formatting etc so for when >>>> viewing changes, viewing with same formatting helps me to see the actual >>>> changes and not formatting changes. >>>> >>>> Thanks! >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> >>> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >> > >

July 24, 2017

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

by Alistair Grant

Hi Thierry, On Mon, Jul 24, 2017 at 10:23:49PM +0200, Thierry Goubier wrote: > Le 24/07/2017 ?? 17:05, Alistair Grant a ??crit : > >For Ubuntu users, the updated snap is also available: > > > >sudo snap install pharo --classic --candidate > > Hi Alistair, > > how one update the pharo snap (from 6.0 to 6.1)? sudo snap refresh pharo --candidate Just FYI: My understanding is that if 6.1 had already been pushed to stable, it would update automatically (according to the schedule you have, either by default or set explicitly). Cheers, Alistair > Thierry > > > > >Cheers, > >Alistair > > > >P.S. Should this message be sent to pharo-users as well?

July 24, 2017

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

by Stephane Ducasse

HI alistair this is supercool that you push this! I mean it for real. Because this simplnk stuff was always getting on our way for scripts. This is really great to see this happening. Stef On Mon, Jul 24, 2017 at 10:43 AM, Max Leske <maxleske(a)gmail.com> wrote: > 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 Stephane Ducasse

tx christophe. Launcher is cool and this is nice to see some effort on that front. Stef On Mon, Jul 24, 2017 at 10:41 AM, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > 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

Re: [Pharo-dev] Is there a portable way to check if a string is a block?

by Nicolas Cellier

Presumably, you must parse the string (not evaluate), obtain an Abstract Syntax Tree on return (or an Exception), and check that this AST conforms to some pattern (at worse you code naÃ¯vly the pattern matching, at best you can reuse the refactor/rewrite engine). I've not followed latest Compiler developments, but from what I understand, more and more tools are based on AST... so it sounds pretty straight-forward. 2017-07-24 18:21 GMT+02:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi guys, > > Is there a portable (that would work in GemStone too) and safe way to know > if a String would be a block? > > I must support this kind of strings: > > 'singleString' -> false > 'multi string' -> false > ' [:a | 42]' -> true > ' '' '' [:a | 42]' -> true > '[:a | 42]' -> true > ' "a commet" [:a | 42]' -> true > ' WhateverClass someVeryBadHackishMethod. [:a | 42]' -> true > > I need to identify whether the string is a closure or not. And ideally, I > don't want to do an #evaluate: because I don't want any left hand code to > be executed. > I tried with #parse: why I am having problems. > > Any ideas? > > Thanks in advance > > -- > Mariano > http://marianopeck.wordpress.com >

July 24, 2017

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

by Tim Mackinnon

This is a great step to show we have a stable consistent base for the year ahead - thanks for pulling this off! One small caveat on the 64bit angle - there are still some known outstanding bugs with 64bits - meaning that Fuel is known not to work (which might be for more specialised things - but it does mean we have to careful about how 64bits its advertised : https://pharo.fogbugz.com/f/cases/20120/Fuel-is-not-64bits-ready <https://pharo.fogbugz.com/f/cases/20120/Fuel-is-not-64bits-ready> https://pharo.fogbugz.com/f/cases/20119/ <https://pharo.fogbugz.com/f/cases/20119/> ) Tim > On 24 Jul 2017, at 12: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 <http://pharo.org/download> page, or with zeroconf: > > wget -O- get.pharo.org <http://get.pharo.org/> | bash > > Enjoy! > Esteban

July 24, 2017