- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANN] Mustache moved to github

by Tim Mackinnon

Peter - I meant it as a figurative example - on a master branch you can tag whenever you want right? And so you can point users to a specific tag on master so they have a stable point to load from (possibly while you merge a branch back to master and then update any documentation or config before retagging and updating a BaselineOf? This looks like what the AWS Smalltalk git repo has used as an example. Tim (Ps Apologies for the "rage" iOS autocorrect - apparently that's what Apple thinks tags is corrected to ;) Sent from my iPhone Sent from my iPhone On 30 Jul 2017, at 16:35, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> >> If I've understood correctly, this means you can rage master with a version number like v1.1 and then put that in the URL >> >>> https://github.com/peteruhnak/IconFactory/tree/master:v1.1/ > > I am not sure where you got this url from, but combining branch and tag name makes nor sense... that's like you wanted a version 1.1 AND 2.3 (or whatever would be the latest in master). > > (as mentioned in the syntax: branch name OR commit id OR tag id) > > Peter >

July 30, 2017

Re: [Pharo-dev] [ANN] Mustache moved to github

by Esteban A. Maringolo

Hi all Sorry to Norbert for hijacking this post, but I'd also like to move some of my projects to Github, I used Peter's scripts in the past, but one thing I don't understand is how to automatically convert a ConfigurationOf to a BaselineOf, and if this is really necessary. Is the FileTree format, as used by filetree and gitfiletree MC repos, 100% compatible with the repository format of Iceberg? It seems so to me, but it's better to ask than be sorry. Regards! Esteban A. Maringolo 2017-07-30 11:35 GMT-03:00 Peter Uhnak <i.uhnak(a)gmail.com>: >> >> If I've understood correctly, this means you can rage master with a version number like v1.1 and then put that in the URL >> >> > https://github.com/peteruhnak/IconFactory/tree/master:v1.1/ >> > > I am not sure where you got this url from, but combining branch and tag name makes nor sense... that's like you wanted a version 1.1 AND 2.3 (or whatever would be the latest in master). > > (as mentioned in the syntax: branch name OR commit id OR tag id) > > Peter >

July 30, 2017

Re: [Pharo-dev] [ANN] Mustache moved to github

by Peter Uhnak

> > If I've understood correctly, this means you can rage master with a version number like v1.1 and then put that in the URL > > > https://github.com/peteruhnak/IconFactory/tree/master:v1.1/ > I am not sure where you got this url from, but combining branch and tag name makes nor sense... that's like you wanted a version 1.1 AND 2.3 (or whatever would be the latest in master). (as mentioned in the syntax: branch name OR commit id OR tag id) Peter

July 30, 2017

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

by Alistair Grant

Hi All, I've submitted the FileAttributesPlugin for inclusion in the VM (you can follow on the vm-dev mailing list if interested). As Cyril Ferlicot has been quite interested in the file system and its performance, I thought I might make this available for early testing for anyone that is interested. As mentioned previously, the patch: - Extends the public interface to the file system (FileReference) relating to file attributes and iterating over directories - It doesn't make any changes to existing public behaviour (that I'm aware of). - It does make significant changes to the internals (FileSystem, DiskStore and subclasses) - Functionality relating to opening & closing files, file IO, etc. isn't touched The limitation is that it is only available through the Ubuntu snap, so you need one of: - Ubuntu 14.04 or later (16.04 or later preferred) - A container with Ubuntu 16.04 or later, e.g. Docker - Can build your own 6.1 or 7.0 VM If you: sudo snap install pharo mkdir fatest cd fatest sudo pharo.conf pharo.getimage32 pharo.ui Pharo.image And then follow the instructions at: https://github.com/akgrant43/FileAttributes you'll have the new file attributes code. Cheers, Alistair 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. > > > 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 30, 2017

Re: [Pharo-dev] [ci-announces] IMPORTANT: Virtual Machines loss

by Guillermo Polito

I don't want to be pesimistic, but this means we don't have CI until we restore all slaves. From the Pharo point of view, we lost almost all but 1 or 2 slaves in different ci servers. Check: - https://ci.inria.fr/pharo/ - https://ci.inria.fr/pharo-contribution/ - https://ci.inria.fr/pharo-ci-jenkins2/ I'd like to make for real a call for help in here. We have, for each project (pharo, pharo-contribution, ci-jenkins2), to set-up slaves for windows linux and mac. This means we have to create slaves, check they can connect to jenkins (and otherwise configure them, install dependencies (windows through remote desktop...)). I propose to do a meeting on discord #development tomorrow, monday, at 14h CEST (UTC/GMT+2, Paris/Brussels time) to organize a task force. Like that we can split tasks and share knowledge on this to have less bottlenecks, what do you think? >From my side, I'll try to spend monday morning seeing how we can automatize most of these things... Guille On Sun, Jul 30, 2017 at 8:11 AM, Volkert <volkert(a)nivoba.de> wrote: > Out of curiosity: What is the impact on the Pharo Project? Is the build > process is interrupted? > > Volkert > On 28.07.2017 19:18, Christophe Demarey wrote: > > Dear CI users, > > Due to a manipulation error, a lot of Virtual Machines hosted on > CloudStack were destroyed and are *not recoverable*! > For the projects being impacted, there is no other solution than recreate > new VMs. Please find as attachment the list of virtual machines that are > not affected. > > Jenkins servers are not concerned by this issue, so all your jobs and > history are safe. > > We are deeply sorry for this failure. > Everything was done in an effort to retrieve the lost VMs, but it has > proven to be an impossible task and the VMs cannot be restored. We are now > working on setting up safeguards to prevent such situations. > > With our sincere apologies, > The CI team. > > > > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

July 30, 2017

Re: [Pharo-dev] Launcher and Pharo 6.1

by Esteban Lorenzano

Hi, Yes as Eliot said, it is safe. 6.1 just includes latest bug fixes from Eliot + a new version of libgit2 Esteban > On 30 Jul 2017, at 05:59, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Sean, > > >> On Jul 29, 2017, at 8:07 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Is it safe to replace the Launcher VM with the one required for Pharo 6.1? >> I.e. is that VM backward compatible with a Pharo 6.0 image? > > In general, Squeak/Pharo VMs are backwards compatible at least within a major version. > >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Launcher-and-Pharo-6-1-tp4957770.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >

July 30, 2017

Re: [Pharo-dev] [ci-announces] IMPORTANT: Virtual Machines loss

by Volkert

Out of curiosity: What is the impact on the Pharo Project? Is the build process is interrupted? Volkert On 28.07.2017 19:18, Christophe Demarey wrote: > Dear CI users, > > Due to a manipulation error, a lot of Virtual Machines hosted on > CloudStack were destroyed and are _not recoverable_! > For the projects being impacted, there is no other solution than > recreate new VMs. Please find as attachment the list of virtual > machines that are not affected. > > Jenkins servers are not concerned by this issue, so all your jobs and > history are safe. > > We are deeply sorry for this failure. > Everything was done in an effort to retrieve the lost VMs, but it has > proven to be an impossible task and the VMs cannot be restored. We are > now working on setting up safeguards to prevent such situations. > > With our sincere apologies, > The CI team. > > >

July 30, 2017

Re: [Pharo-dev] Launcher and Pharo 6.1

by Eliot Miranda

Hi Sean, > On Jul 29, 2017, at 8:07 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Is it safe to replace the Launcher VM with the one required for Pharo 6.1? > I.e. is that VM backward compatible with a Pharo 6.0 image? In general, Squeak/Pharo VMs are backwards compatible at least within a major version. > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Launcher-and-Pharo-6-1-tp4957770.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

July 30, 2017

Launcher and Pharo 6.1

by Sean P. DeNigris

Is it safe to replace the Launcher VM with the one required for Pharo 6.1? I.e. is that VM backward compatible with a Pharo 6.0 image? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Launcher-and-Pharo-6-1-tp4957770.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 30, 2017

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

by Torsten Bergmann

July 29, 2017