Hi Cédrick,

Le 18 avr. 2020 à 10:09, Cédrick Béler <cdrick65@gmail.com> a écrit :

Great Job. It looks indeed nicer.

I found the docs great too (https://pharo-project.github.io/pharo-launcher <https://pharo-project.github.io/pharo-launcher>).

One suggestion would be to add the help contextually. I tried to look at. There is description of commands and SpLinkPresenter but don’t think it’s easy to add. I wanted to add the ling in the help description.

Indeed, good idea. Unfortunately, Spec2 does not yet allow to mix text and links. Probably a new presenter would be needed to support this scenario. Also, it depends on what is doable with the gtk backend. Esteban? Cheers, Christophe

For instance, the one to create an image for template: WebBrowser openOn: 'https://pharo-project.github.io/pharo-launcher/create-images/‘ <https://pharo-project.github.io/pharo-launcher/create-images/%E2%80%98>

Any way of doing that ?

<GraphiqueCollé-7.png>

Cheers,

Cédrick

...

Le 17 avr. 2020 à 18:08, Christophe Demarey <christophe.demarey@inria.fr <mailto:christophe.demarey@inria.fr>> a écrit :

Hi all,

Pharo Launcher 2.0 has just been released! It is available from http://pharo.org/download <http://pharo.org/download>.

This new version introduces major changes: The UI has been fully rewritten using the new Spec2 framework <https://github.com/pharo-spec/Spec> and the Commander2 library <https://github.com/pharo-spec/Commander2>. UI has been revamped to increase usability, especially for newcomers. The main window is now composed of a toolbar and the list of images. The template list is now available when clicking on the new image button. Documentation web site : All Pharo Launcher features are now explained in the new documentation available at https://pharo-project.github.io/pharo-launcher <https://pharo-project.github.io/pharo-launcher>. You can contribute easily by clicking the *edit on GitHub* button. You can now have many launch configurations for an image (VM to use, vm and image arguments). It means you can use headless Pharo VM from Pharo Launcher. When creating a new image, you can specify an initialisation script that will be run once at the first image launch. It is useful to load your project code in a stock Pharo image for example. See https://pharo-project.github.io/pharo-launcher/create-images/#image-initiali... <https://pharo-project.github.io/pharo-launcher/create-images/#image-initiali...> You can now define your own template sources in addition to official sources (see https://pharo-project.github.io/pharo-launcher/templates/#create-your-own-li... <https://pharo-project.github.io/pharo-launcher/templates/#create-your-own-li...>), including authenticated sources. Improved image metadata. Pharo Launcher now manages all image metadata in a single STON file (including description, Pharo version).

Big thanks to all contributors, including issue reports. It is also the opportunity to thanks Damien Cassou, the original author of Pharo Launcher.

Here is the changelog: Pharo Launcher v2.0 <https://github.com/pharo-project/pharo-launcher/releases/tag/2.0>

The list of closed issue is too long (68) to be listed but you can browse it here: https://github.com/pharo-project/pharo-launcher/issues?q=is%3Aissue+is%3Aclo... <https://github.com/pharo-project/pharo-launcher/issues?q=is%3Aissue+is%3Aclo...> Here are some highlights: New features:

Documentation web site Image initialisation script Launch configurations, headless VM support User template file in addition to the official template file Jenkins server template now support pipeline projects Support of private Jenkins server Support of authenticated HTTP server Improvements:

Monitoring of image launch failures to give back the error message (if any) Newly created image is automatically selected in the image list Allow to set image description at creation time Better error management (you will have the choice to ignore them or debug them) Add a poor version column in image list Speedup (especially when image repository has a lot of images)

Bug fixes:

Fix use of system unzip on Windows

Regards, The Pharo team.

Hi Christophe,

If it worked with previous version, there is no reason it should not work with the current Pharo Launcher version.

I think I found the reason - new meta-inf.ston files include absolute paths to image and VM, and those are different on my machines. I'm putting them on the same path. Thanks and best wishes, Tomaz

Hi Cédrick,

Le 7 mai 2020 à 08:24, Cédrick Béler <cdrick65@gmail.com> a écrit :

Hi Christophe,

This version is definitely cooler :)

Thanks

I just wander as for the previous version why deleting image can take some time, whereas it’s quick to delete the image repository. Is it normal ?

In Pharo, deleting files is slow because Pharo visits all the files to delete to check if there are file descriptors opened on these files to close them. I think it is something that could be improved. In many situations, you know you do not have descriptors on these files and we could have a method to delete without doing the check, just the system call, without visiting the tree.

Another thing that might help my way of doing things. I like to "save as" the image so as to have a quick check point, and the launcher is not « friendly » with renaming as it loads the default image.

Any idea on how to integrate that ? Maybe having a list of images that pops-up ?

For this feature, I have no good idea for now. I had in mind to use a tree instead of a list of images. You could expand if there are more than one image and see other images in the folder. The problem is for the metadata file: we could assume that other images should use the same metadata as the core image and use them to run the image. (For now, the metadata filename is the same for all images).

I actually changed once the "save as » in a « save checkpoint charly » where it saves a copy but still load the default name. Might be an option ? :)

« Saves a copy » : do you mean you copy the full folder to another name ? Cheers, Christophe

Thanks for the explanation Christophe. The tree might be a good idea.

...

I actually changed once the "save as » in a « save checkpoint charly » where it saves a copy but still load the default name. Might be an option ? :)

« Saves a copy » : do you mean you copy the full folder to another name ?

I mean that when I « save as », I do it mainly because I know my next code evaluation could crash the image ^^. So basically, what I need is to save a copy of the image (timestamped eventually) but still using the original one. **So later, in case of crash, I can roll back to a previous backup**. That is far easier to implement I guess than the tree and that would be **very** useful to me at least ;-) Not sure, but I also think we should enforce by default to share the iceberg repo. For most people, top save sandwich, etc, it seems a better direction to me. This is optional right now but can’t we change the default ? Cheers, Cédrick

Cheers, Christophe

And thanks you for supporting it and describing it better :) This is an addition I hacked but I lost the code ^^ (was really hacks). I’m pretty sure that would be easy to implement for « core dev » . Basically, this is another save as, maybe « save version » ? Then the "save as » should be deactivated in launcher probably. Cheers, Cédrick

Le 15 mai 2020 à 11:13, Tim Mackinnon <tim@testit.works> a écrit :

I find I do the same sort of precautionary measure (and probably would do it more if launcher supported this use case and helped me manage those snaphot images) - I view it a bit like how TimeMachine lets you see previous versions of files - yes the source code is versioned, but its just the useful execution state and window layouts that are handy to hold on to. Equally, I don't need too many of these images - and indeed want them to expire (but happy to manage that myself - its just a simple counter, or time snapshot that would make this very handy).

Thanks for mentioning it Cedrick

Tim

On Fri, 15 May 2020, at 8:54 AM, Cédrick Béler wrote:

...

Thanks for the explanation Christophe.

The tree might be a good idea.

...

...

I actually changed once the "save as » in a « save checkpoint charly » where it saves a copy but still load the default name. Might be an option ? :)

« Saves a copy » : do you mean you copy the full folder to another name ?

I mean that when I « save as », I do it mainly because I know my next code evaluation could crash the image ^^.

So basically, what I need is to save a copy of the image (timestamped eventually) but still using the original one. **So later, in case of crash, I can roll back to a previous backup**.

That is far easier to implement I guess than the tree and that would be **very** useful to me at least ;-)

Not sure, but I also think we should enforce by default to share the iceberg repo. For most people, top save sandwich, etc, it seems a better direction to me. This is optional right now but can’t we change the default ?

Cheers,

Cédrick

...

Cheers, Christophe