pharo-project / pharo-launcher Goto Github PK

Linux Ubuntu 16.04 LTS
On latest-linux.zip from https://ci.inria.fr/pharo/view/Launcher/job/Publish-Launcher-stable-Linux/ (build #53)

After running the PharoLauncher and launching a few images with it, if I close the PharoLauncher image, all the other images are killed without save prompts.

And if the "Quit on launch" setting is on, whenever PharoLauncher launches an image, it quits itself, which closes the image just launched. Since "Quit on launch" is on by default, PharoLauncher looks like it doesn't work by default.

sign pharo launcher app for windows to prevent Windows SmartScreen to detect Pharo Launcher as a malicious app.

On Linux Ubuntu 16.04 LTS

Steps to reproduce:

• Downloaded latest-linux.zip from https://ci.inria.fr/pharo/view/Launcher/job/Publish-Launcher-stable-Linux/ (build #53)
• Removed the settings file system-settings.ston to prevent interferences.
• Ran the image
• Observation: Quit on Launch setting checkbox is checked
• Observation: Enable development environment setting checkbox is not checked
• Unchecked Quit on Launch
• Clicked Store Settings
• Killed the image from terminal (without saving it)
• Re-ran the image
• Observation: Another, smaller, PharoLauncher window opened immediately
• Observation: Quit on Launch setting checkbox is still checked
• Observation: Enable development environment setting checkbox is checked
• Trying to close the pharoLauncher image OS window by clicking on the OS cross button throws a "#ifTrue:ifFalse was sent to nil" exception. This message is sent to the "Save" class variable of the PhLDeploymentScript class, which is nil.

leading to unzipping failures and then image launching failure.
ProcessWrapper always returns an exit code of 0. Could check stderr.

reported by Skip Lentz:

On OSX, I renamed the application from "Pharo.app" to "Pharo Launcher.app" with a space in the middle.

"PhLImage>>lauch:" then uses OSProcess with a command containing unescaped spaces.

Need to distinguish pharo image version for VM but also between 64-bits and 32-bits images.
For now, images are stored in a directory named with the pharo version only.

The problem with the existing Launcher and Pharo settings system is that it stores code in a configuration file. It means the Launcher's developer must pay attention not to remove a method that might be called by a configuration file. Otherwise, the user won't be able to launch the Launcher anymore.

When installing the Launcher in the default Windows location, an error is thrown when trying to create a directory for the ombu session.
Would be nice to catch the error.

Stack trace:

WindowsStore(Object)>>primitiveFailed:
WindowsStore(Object)>>primitiveFailed
WindowsStore(DiskStore)>>createDirectory:
WindowsStore(FileSystemStore)>>ensureCreateDirectory:
WindowsStore(FileSystemStore)>>ensureCreateDirectory:
FileSystem>>ensureCreateDirectory:
FileReference>>ensureCreateDirectory
OmSessionStore>>resetWithStoreNamed:
OmSessionStore>>resetWithNextStoreName
OmSessionStore>>store
ByteSymbol(Symbol)>>value:
Array(SequenceableCollection)>>do:
OmSessionStore class(Behavior)>>allInstancesDo:
OmSessionStore class>>startUp
OmSessionStore class(Behavior)>>startUp:
ClassSessionHandler>>startup:
[ :each | each startup: isImageStarting ] in WorkingSession>>runStartup: in Block: [ :each | each startup: isImageStarting ]
[ aBlock value: each ] in [ :each | 
[ aBlock value: each ]
	on: Exception
	do: [ :error | self errorHandler handleError: error ] ] in WorkingSession>>runList:do: in Block: [ aBlock value: each ]
BlockClosure>>on:do:
[ :each | 
[ aBlock value: each ]
	on: Exception
	do: [ :error | self errorHandler handleError: error ] ] in WorkingSession>>runList:do: in Block: [ :each | ...
Array(SequenceableCollection)>>do:
WorkingSession>>runList:do:
WorkingSession>>runStartup:
WorkingSession>>start:
SessionManager>>snapshot:andQuit:
[ ^ SessionManager default snapshot: save andQuit: quit ] in SmalltalkImage>>snapshot:andQuit: in Block: [ ^ SessionManager default snapshot: save andQuit:...etc...
CurrentExecutionEnvironment class>>activate:for:
DefaultExecutionEnvironment(ExecutionEnvironment)>>beActiveDuring:
DefaultExecutionEnvironment class>>beActiveDuring:
SmalltalkImage>>snapshot:andQuit:

It would be cool to be able to add an item in the context menu of an image to launch an image without the startup preferences.
We need to add this after the name of the image: --no-default-preferences

Currently images are run using the VM that PharoLauncher is running with. When trying to track down a bug and wanting to switch an image to run on different VMs, its help would help a lot if the context menu for an image included options for different VMs.

Some possible features are:

• VMs managed either in Preferences or on a tab (with current interface other tab)
• List remote (files.pharo.org) VMs, download, delete
• A configurable default VM for all images
• Particularly images could have a different default VM
• Images could have a short list of associated VMs from
  • System wide static list
  • System-wide recent list
  • Individual image recent list

In Windows, when I ty to select the "latest" item from Pahro 6.0 list I got this error:

#selectedMorphList was sent to nil
UndefinedObject(Object)>>doesNotUnderstand: #selectedMorphList
MorphTreeNodeMorph>>selected:
MorphTreeNodeMorph>>update:
[ :aDependent | aDependent update: aParameter ] in SpecTreeNodeModel(Model)>>changed: in Block: [ :aDependent | aDependent update: aParameter ]
DependentsArray>>do:
SpecTreeNodeModel(Model)>>changed:
[ :w |
w changed: #select.
w model selectionChanged.
w dependents do: [ :e | e changed ] ] in MorphicTreeNodeAdapter>>select in Block: [ :w | ...
BlockClosure>>cull:
SpecTreeNodeModel(ProtoObject)>>ifNotNil:
MorphicTreeNodeAdapter(AbstractAdapter)>>widgetDo:
MorphicTreeNodeAdapter>>select
MorphicTreeNodeAdapter>>selected:
MorphicTreeNodeAdapter(AbstractAdapter)>>update:with:
[ :aDependent | aDependent update: anAspect with: anObject ] in TreeNodeModel(Model)>>changed:with: in Block: [ :aDependent | aDependent update: anAspect with: ...etc...
DependentsArray>>do:
TreeNodeModel(Model)>>changed:with:
[ :aBoolean | self changed: #selected: with: {aBoolean} ] in TreeNodeModel>>initialize in Block: [ :aBoolean | self changed: #selected: with: {aBoo...etc...
BlockClosure>>cull:
BlockClosure>>cull:cull:
BlockClosure>>cull:cull:cull:
BlockClosure>>cull:cull:cull:cull:
[ :announcement :ann |
aBlock
cull: announcement newValue
cull: announcement oldValue
cull: announcement
cull: ann ] in NewValueHolder>>whenChangedDo: in Block: [ :announcement :ann | ...
BlockClosure>>cull:cull:
[ action cull: anAnnouncement cull: announcer ] in AnnouncementSubscription>>deliver: in Block: [ action cull: anAnnouncement cull: announcer ]
BlockClosure>>on:do:
BlockClosure>>on:fork:
AnnouncementSubscription>>deliver:
[ "Ensure delivery to remaining announcements" subscription deliver: anAnnouncement ] in SubscriptionRegistry>>deliver:to:startingAt: in Block: [ "Ensure delivery to remaining announcements" sub...etc...
BlockClosure>>ifCurtailed:
SubscriptionRegistry>>deliver:to:startingAt:

some icons do no show up when PharoLauncher is launch. They only appear when on mouse hover.

Currently, the launcher stores the user images in a hidden directory. Some users prefer when the images are more visible, such as in a ~/Documents directory.

startup scripts could cause a lot of troubles to Pharo Launcher.
They do not make sense in the scope of Pharo Launcher => remove them from the startup list

Reported by Ben Coman:

I'd like to ask your help with a feature I've been wanting for a while. I spent half a day trying but just can't work it out how to get this...

I regularly have 100 images listed. I should clean up more regularly, but even so, I still have many. Many of the builds have a virgin (effectively read-only) version I use for bisecting to find when a problem was introduced; and case I work on may end up with half a dozen images as I test various ideas and that the slice loads back in cleanly.

So when I create an image, sometimes it gets "lost". Maybe I did a typo in the name, or it just takes a while to pinpoint it in the list.

What I'd really like a lot is that when the image is created, it is auto-selected. So its easy to tell which image was created.

I had great difficulty trying to find my way from the context handed to the PhLCommands back to the list.

Have you got any pointers?

use in-memory pharo-local folder to avoid problems when trying to write to a read-only folder.

I found a nasty bug on last stable version of PharoLauncher on Mac OS X.

Apparently this bug occurs only when file name are greater than 255 and because of another bug :
(MacStore new) maxFileNameLength that returns a String instead of an Integer.

I guess this bug will disappear with PharoLauncher based on Pharo 5.0.

Currently, the Launcher searches for images in a particular directory and arranged in a special way: each image must be in a sub-directory with the same name as the image file. This has some drawbacks:

• if a user uses save as... in Pharo, the new image will not appear
• if a user has images downloaded without the launcher, the launcher won't see them unless the user renames and moves the image

It might be better to give the launcher a list of directories to recursively search for images.

Reported by Vincent Blondeau

It would be nice if we can search into the template list for a job.

For instance, if we search Fuel, we will get the jobs: Fuel-Benchmarks, Fuel-Development (in the Pharo Jenkins), ..., Fuel-Moose (in the Moose jenkins).

It might be nice to provide the launcher with a default image the user can play with without downloading more.

In the settings for Launcher. Locations of your images is a plain string whilst VMs directory is a file.

Shouldn't they be the same - I think file is better.

and to be picky the vm label would be better as 'Location of your VMs'

Reported by Ben Coman:

1. Start Launcher. Launch an image.
2. Restart Launcher. Delete same image.

gives cryptic error "PrimativeFailed: primative #delteDirectory: in FilePluginPrims failed"

This exception should be handled to present a clear UI message "Cannot delete image" .

Reported by Tim Mackinnon

On OSX, when you launch an image using the .app "all in" build, you can only run one instance of the image. Trying to launch it again, just refocuses on the already running instance. (Its not clear whether this is a change in OSX Mavericks or something that has changed in the VM).

A proposed solution is to let PharoLauncher specify an alternate VM to use for launching. This has the nice side effect that you can use Launcher to test with alternate VM's.

When trying to launch any image, exception is raised (key '60' not found in Dictionary).

Looks like the problem is in #vmExecutableName method: on Windows, it should return 'Pharo.exe'.

Some users would like the launcher to auto-update. I'm typically not in favor of such solutions because, for me, this is the responsibility of the operating system to update installed software. But, I'm not against either as soon as:

• someone else implements it
• there is a way to deactivate that in systems where this can't work (e.g., if the launcher is installed in a directory owned by root)

Reported by Ben Coman:

Introduce a feature similar to git-bisect. (Disclaimer, I've never used git-bisect but it seems like a really useful feature to have)

git bisect is a tool that allows you to find an offending commit. Let’s say you’ve come across a bug in your codebase and you’re unsure of when it was introduced. If you can find a commit where the code works properly and a commit where it doesn’t, you don’t have to trace down the offending commit by hand; git-bisect will do that for you.

http://robots.thoughtbot.com/post/57797091118/git-bisect

https://www.kernel.org/pub/software/scm/git/docs/git-bisect.html

Could have two modes:

1. In Manual Mode, the user launches the image in the middle of good & bad images. In the background the next two choices of middle could downloaded ready for an immediate start after the user finishes testing. When the user quits the image under test, it automatically returns to Launcher which asks the question "good/bad?" and automatically launches the next test image.
2. In Automated Mode you could design a Test that distinguishes good/bad behaviour and have that supplied as a startup script for the launched image. Based on the result returned to the Launcher, it can selected the next image to try. The additional benefit is the generation of a good Test that can later be integrated into the image.

I've set the priority to "6 - On Hold" since its a stretch goal, but I can seed the idea since I think it is worth considering as a long term plan.

There must be a way to create a list of favorite templates that the user always use. For example, if a user always want the latest Pillar image as built by Jenkins, he should be able to add this to the Favorites.

When trying to run an image, you get a primitive Error on ProcessWrapper class #newProcess.
Probably caused by missing ProcessWrapperPlugin.dll

ProcessWrapper class(Object)>>primitiveFailed:
ProcessWrapper class(Object)>>primitiveFailed
ProcessWrapper class>>newProcess
ProcessWrapper class>>new
PhLProcessWrapper class>>waitForWindowsCommand:
PhLProcessWrapper class>>waitForCommand:
PhLVirtualMachineManager>>imageVersion
PhLVirtualMachineManager>>vmFileName
[ :bar | 
bar label: 'Determining Image version'.
vm := self availableVirtualMachines
    at: self vmFileName
    ifAbsent: [ bar
            label: 'Fetching VM to run Pharo ' , self imageVersion , ' images';
            current: 25.
        self fetchVm.
        vm := self availableVirtualMachines at: self vmFileName.
        bar
            label: 'Fetching sources files for Pharo ' , self imageVersion;
            current: 50.
        self fetchSourcesFiles.
        bar
            label: 'Running the image';
            current: 100.
        vm ] ] in PhLVirtualMachineManager>>vm in Block: [ :bar | ...
[ :bar | aBlock value: bar ] in MorphicUIManager>>informUserDuring: in Block: [ :bar | aBlock value: bar ]
BlockClosure>>cull:
[ ^ block cull: self ] in [ self prepareForRunning.
CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run in Block: [ ^ block cull: self ]
[ activeProcess psValueAt: index put: anObject.
aBlock value ] in CurrentJob(DynamicVariable)>>value:during: in Block: [ activeProcess psValueAt: index put: anObject....
BlockClosure>>ensure:
CurrentJob(DynamicVariable)>>value:during:
CurrentJob class(DynamicVariable class)>>value:during:
[ self prepareForRunning.
CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run in Block: [ self prepareForRunning....
BlockClosure>>ensure:
Job>>run
MorphicUIManager(UIManager)>>displayProgress:from:to:during:
MorphicUIManager>>informUserDuring:
PhLVirtualMachineManager>>vm

Reported by Ben Coman:

When from an image managed by PharoLauncher you do World > Save As, you can no longer use the [Copy] from the PharoLauncher 'Existing images' context menu. In my case I had saved Delay-30852-06-reduced.image as Delay-30852-06-reduced-backup.image, the the latter was being copied and an except coming up saying some file exist.

I guess the copy should ignore the backup.

Hi!
I have linux mint here and I debugged the reason why my downloaded image won't start.

First, after the download of the needed vm the sources file is not situated in
/home/myuser/Pharo/vms/60/lib/pharo/5.0-201705310241
and a PharoDebug.log ist created stating this error,

Second, the /home/myuser/Pharo/vms/60/lib/pharo/5.0-201705310241/pharo is not executable.
Images are not started but no error is presented or logged.

Reason
PhLVirtualMachineManager ensureIsExecutable: is only doing a "chmod u+x" on
/home/myuser/Pharo/vms/60/pharo
and not
/home/myuser/Pharo/vms/60/lib/pharo/5.0-201705310241/pharo

This is an example for pharo6.0 images but the error applies for all versions.

Could somebody please have a look into this?

Thank you!
Sebastian

The recent Pharo VMs don't open the old Pharo images. It means the launcher must has references to several VMs to be able to launch all possible kinds of images. These VMs could be packaged with the launcher to facilitate configuration.

Reported by Ben Coman:

Now that I have really a lot of images registered with PharoLauncher (from working on Fogbugz issues and trying to bisect build numbers to discover when a bug was introduce and also having several images per Case I'm working on) I sometimes have a typo in the name of the image being created and can't find where it ends up.

It would be nice to be able to find it by viewing a log of what was actually done.

Reported by Ben Coman:

Many applications have a 'Update available' auto-install feature. It would be useful if Launcher had one. I envisage:

1. From within Existing-Launcher, monitor PharoLauncherFinalUserImage CI job and notify user of available update.
2. Upon user action, download Latest-Launcher to temporary location.
3. Launch the Latest-Launcher image. After operational testing, user action copies Latest-Launcher over the top of Existing-Launcher. Then launch back to that updated Existing-Launcher.

Suggestion from Stephan:
It might be useful to regularly check for newer vms, at least the stable ones. VMs are supposed to be backwards compatible.

Reported by Ben Coman:

Right now, we are deleting images via an rm -fr like approach

While tracing through Pillar (from Ecstatic) I found this hard to read i.e. even after I'd understood it, I had to decipher it anew each time I tried to read it.

PRCocoonConfiguration>>export: configurationName
self log: 'Exporting ', configurationName.
((self subConfigurationNamed: configurationName)
ifNil: [ self findDefaultConfigurationNamed: configurationName ]
) export.
self log: 'End of exporting ', configurationName

Splitting with a named variable makes it more obvious...

PRCocoonConfiguration>>export: configurationName
| subconfig |
self log: 'Exporting ', configurationName.
subconfig := ((self subConfigurationNamed: configurationName)
ifNil: [ self findDefaultConfigurationNamed: configurationName ]).
subconfig export.
self log: 'End of exporting ', configurationName

http://forum.world.st/PharoLauncher-directories-td5014383.html

In Pharo-users, I wrote:
I run into all kinds of issues with the directory structure used by the new PharoLauncher. pharo-local seems to be shared now for multiple images. That makes using configurations practically impossible as they are not expecting to have to deal with pre-downloaded older and newer monticello files. The missing sources files is less of a problem.

Guille responded with some details on the recent changes:
An analysis of the situation so people out of context can understand better the forces in play here :)

• Working directory and files constant property: files defined using a relative path are created relative to the working directory.
  In other words:
  File named: 'something/other/myfile.txt'
  will be created in FileSystem workingDirectory.
  This was always like this when we used the file primitives.
  The diverging behaviour was introduced actually by FileSystem: FileSystem used to create by default all files relative to the image directory. And at some point all tools adapted to that and the correct behaviour was hidden.

• Change in working directory: Before, pharo always satisfied the following property:
  FileSystem workingDirectory = FileSystem imageDirectory

  This is no longer true for every case.
  Now, the workingDirectory is aligned with the process' working directory (This is the equivalent to getcwd() in C, pwd command in linux, $PWD in bash).
  I explained a couple of weeks ago in an email, this may break some eggs, specially for those tools that wrongly assume FileSystem workingDirectory = FileSystem imageDirectory.
  Tools requiring imageDirectory should use imageDirectory explicit. At least that will keep backwards compatibility.
  For other cases, we should probably study them case by case and provide a satisfying solution.

  This change does however not affect everybody, and most of the times it is backwards compatible:

  ** This does not affect in general people launching usually pharo from the command line and using zeroconf:
  $ wget get.pharo.org/...
  $ ./pharo Pharo.image
  ## Here, FileSystem workingDirectory = FileSystem imageDirectory because I launched my image from the directory where my image is!

  ** This does affect people that are:
  - launching Pharo doing double click.
  In this case, we saw with Denis and Pavel a week ago that osx assigns as working directory the root directory "/"
  Users of files should be aware of this and applications should not abuse the workingDirectory. If they want to enforce the imageDirectory, they should do so explicitly.

  • launching Pharo from the pharo launcher (taken from this thread)
    Apparently the pharo launcher is launching the image from a directory internal to the launcher. This means that the working directory will be assigned to that directory. I'd expect that the directory structure is private to the launcher...
    I find even strange that the launcher puts pharo-local where the image is...

Given this, possible solutions are:

• On fileout, chose a correct directory when launched from double click
• Make the pharo launcher set a well-known working directory when launching an image
  • one possibility is to set $HOME
  • another possibility is to set the image directory (this will keep backwards compatibility)

@stef: about the #fullname. It is not there because it is not implemented :). We did not have the possibility of calculating a correct full path until a couple of weeks ago (and before, even if we did so, it couldn't be done without introducing a dependency to a non-kernel package).

Christophe responded:

 - launching Pharo from the pharo launcher (taken from this thread)
     Apparently the pharo launcher is launching the image from a directory internal to the launcher.

In the Pharo launcher, I explicitly set the current working directory to the VM directory so that the VM can find its files.

This means that the working directory will be assigned to that directory. I'd expect that the directory structure is private to the launcher...
I find even strange that the launcher puts pharo-local where the image is…

Pharo Launcher does not choose where to put pharo-local. It just stands in the standard place aside the launched image.

Given this, possible solutions are:

• On fileout, chose a correct directory when launched from double click
• Make the pharo launcher set a well-known working directory when launching an image
  • one possibility is to set $HOME
  • another possibility is to set the image directory (this will keep backwards compatibility)

I think the last solution: set the working directory to the image directory is the best option.
It will require to find another way to get the vm find its files (probably with LD_LIBRARY_PATH, do not know if it will be enough) and a lot of testing.

Some users reported they can't launch several launchers on OS X.

There is a Jenkins job taking care of building a .dmg file to facilitate installation of the launcher. But this dmg is not recognized by Apple which means users have to workaround to use the Launcher.

I am on Windows behind a proxy and I tried it with pharo 6.1 stable and 7 development. After I create an image, when I try to run it a http fetching process steps in, but it always stop with the following message and stacktrace:

ConnectionClosed: Cannot read data

ZdcSocketStream(ZdcSimpleSocketStream)>>fillBytes:startingAt:count:
ZdcSocketStream>>readInto:startingAt:count:
ZnLimitedReadStream>>readInto:startingAt:count:
ZnLimitedReadStream>>next:into:startingAt:
ZnLimitedReadStream>>next:into:
ZnUtils class>>streamFrom:to:size:
ZnStreamingEntity>>writeOn:
[ self entity writeOn: fileStream ] in [ :fileStream | 
fileStream binary.
self withProgressDo: [ self entity writeOn: fileStream ] ] in ZnClient>>downloadEntityTo: in Block: [ self entity writeOn: fileStream ]
[ ^ block value ] in ZnClient>>withProgressDo: in Block: [ ^ block value ]
[ activeProcess psValueAt: index put: anObject.
aBlock value ] in ZnSignalProgress(DynamicVariable)>>value:during: in Block: [ activeProcess psValueAt: index put: anObject….
BlockClosure>>ensure:
ZnSignalProgress(DynamicVariable)>>value:during:
ZnSignalProgress class(DynamicVariable class)>>value:during:
ZnClient>>withProgressDo:
[ :fileStream | 
fileStream binary.
self withProgressDo: [ self entity writeOn: fileStream ] ] in ZnClient>>downloadEntityTo: in Block: [ :fileStream | …
[ aBlock value: stream ] in FileReference(AbstractFileReference)>>writeStreamDo: in Block: [ aBlock value: stream ]
BlockClosure>>ensure:
FileReference(AbstractFileReference)>>writeStreamDo:
[ self writeStreamDo: doBlock ] in FileReference(AbstractFileReference)>>writeStreamDo:ifPresent: in Block: [ self writeStreamDo: doBlock ]
False>>ifTrue:ifFalse:
FileReference(AbstractFileReference)>>writeStreamDo:ifPresent:
ZnFileSystemUtils class>>newFileNamed:do:
ZnClient>>downloadEntityTo:
ZnClient>>downloadTo:
[ (self newHTTPClientForUrl: url) downloadTo: destinationFile ] in PhLDownloadManager>>download:toFile: in Block: [ (self newHTTPClientForUrl: url) downloadTo: dest…etc…
BlockClosure>>on:do:
[ :bar | 
workBlock
 on: HTTPProgress
 do: [ :progress | 
 bar label: progress printString.
 progress isEmpty
 ifFalse: [ bar current: progress percentage ].
 progress resume ] ] in PhLDownloadManager>>displayProgressDuring: in Block: [ :bar | …
[ :bar | aBlock value: bar ] in MorphicUIManager>>informUserDuring: in Block: [ :bar | aBlock value: bar ]
BlockClosure>>cull:
[ ^ block cull: self ] in [ self prepareForRunning.
CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run in Block: [ ^ block cull: self ]

In the normal settings you can setup a HTTP proxy and also authentication for this proxy. In the Launcher settings you can ony setup the proxy, but not the authentication.

This means the launcher can't be (easily) used if you're located behing a proxy that requires authentication.

I suggest we include (copy-paste?) the authentication settings into the launcher.

Pharo Launcher installer forces you to get privilege elevation (admin) and does not run if you do not have it.

There must be an indication somewhere of the Launcher's version. That way, users can tell us the version they use when they report a problem.

For the users who let the Launcher open all the time, it might make sense to refresh the image list when the window gets the focus.