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

[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  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
> 

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

[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 :
>>
>> 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
>

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

[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

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

[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 +, 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

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

[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  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*




*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Launcher and Pharo 6.1

[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  wrote:
> 
> Hi Sean,
> 
> 
>> On Jul 29, 2017, at 8:07 PM, Sean P. DeNigris  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.
>> 
> 

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

[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.
>
>
>