July 2017 - Pharo-dev - lists.pharo.org

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

by Tim Mackinnon

Hi Peter - I am confused now, Iâve always understood that git tags are used to mark important points in history. From the Git online manual - " Tagging Like most VCSs, Git has the ability to tag specific points in history as being important. Typically people use this functionality to mark release points (v1.0, and so on). In this section, youâll learn how to list the available tags, how to create new tags, and what the different types of tags are. â So Iâve always understood that by putting a tag on a commit, I was getting a snapshot of the whole graph at that point in time? Thus - by specifying the â:tag nameâ on the baseline url, you were getting that version? Thinking a bit more, I guess if you want to to actually make some changes from that tag point - you do need to create a -b branch from it (otherwise you have a detached head right?) - is this what you are getting at? Or is there a more obvious thing I am missing that lets you point to a particular version in GIT? I appreciate your insight into this, as I think we all need to learn how to do this properly. Tim > On 31 Jul 2017, at 08:17, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Nono, I don't think you fully understand git's versioning. > > To oversimplify: git's history is composed of commits and parental relationships between them. Nothing more, nothing less; it is just a directed acyclic graph. > > On top of this graph structure you have additional stuff like branches, which are just labels atteched to the commits, and also tags, which are also just labels. > > So when you tag a commit, it doesn't really matter what branch it was on, you've simply said that tag 1.0 points to a particular commit XXXXXX in the history; that commit could belong to master branch, or development branch, or any other branch (or no named branch at all, also known as detached head). > > In another words, your tag points to a commit only, and branches do not play any role in this whatsoever. > > Am I being clear? (I'm sipping my morning coffee so my brain is not fully operational yet ;) ) > > Peter > > > On Sun, Jul 30, 2017 at 05:28:44PM +0200, Tim Mackinnon wrote: >> 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 31, 2017

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

by Peter Uhnak

* you can have metadata-less filetree and metadata-full(?) filetree * metadata are version information like the author name, versions of packages, parent versions, etc. * metadata-less do not store such information as it is assumed that the information is stored elsewhere (e.g. in git history) * gitfiletree is just a filetree format, which in addition performs git commits of the exported files via shell execution of Git executable * gitfiletree can operate both in metadata, and metadata-less mode (the latter is preferable, otherwise you'll have an endless barrage of merge conflicts) * iceberg is metadata-less filetree only, and performs git commits using libgit So yes, the format is the same and you can even use gitfiletree and iceberg at the same time from e.g. different images. Peter On Sun, Jul 30, 2017 at 12:11:48PM -0300, Esteban A. Maringolo wrote: > 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 31, 2017

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

by Peter Uhnak

Nono, I don't think you fully understand git's versioning. To oversimplify: git's history is composed of commits and parental relationships between them. Nothing more, nothing less; it is just a directed acyclic graph. On top of this graph structure you have additional stuff like branches, which are just labels atteched to the commits, and also tags, which are also just labels. So when you tag a commit, it doesn't really matter what branch it was on, you've simply said that tag 1.0 points to a particular commit XXXXXX in the history; that commit could belong to master branch, or development branch, or any other branch (or no named branch at all, also known as detached head). In another words, your tag points to a commit only, and branches do not play any role in this whatsoever. Am I being clear? (I'm sipping my morning coffee so my brain is not fully operational yet ;) ) Peter On Sun, Jul 30, 2017 at 05:28:44PM +0200, Tim Mackinnon wrote: > 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 31, 2017

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

by Christophe Demarey

> Le 30 juil. 2017 Ã 10:39, Guillermo Polito <guillermopolito(a)gmail.com> a Ã©crit : > > 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/> > - https://ci.inria.fr/pharo-contribution/ <https://ci.inria.fr/pharo-contribution/> > - https://ci.inria.fr/pharo-ci-jenkins2/ <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 will create most of slaves today for all projects.

July 31, 2017

Esteban's ChangeLog week of 24 July 2017

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 24 July 2017 to 30 July 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=24/7/2017&to=30/7/2017 ChangeLog ========= 25 July 2017: ------------- * I made a [pull request](https://github.com/hpi-swa/smalltalkCI/pull/311) to enable Pharo 6.1 on SmalltalkCI :) 24 July 2017: ------------- * I just released [Pharo 6.1](http://pharo.org/news/pharo6.1-released) to update VM and Iceberg (which now is version 0.5.5). cheers! Esteban

July 31, 2017

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