March 2018 - Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #724: 21370 integrate fuel 300

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #724 was: SUCCESS. The Pull Request #914 was integrated: "21370 integrate fuel 300" Pull request url: https://github.com/pharo-project/pharo/pull/914 Issue Url: https://pharo.fogbugz.com/f/cases/21370 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 26, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-03-19

by Tudor Girba

This sounds really exciting! Iâd be very curious to learn more about this. Cheers, Doru > On Mar 26, 2018, at 10:37 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Hi, > > I did some serious Ring 2 refactorings that I wanted to have finished > before the integration into Pharo. > Because Pharo now starts to support the stateful traits, it needs to > be supported by the metamodel too. However, we need to be able to > model the images with the old traits as well and from the internal > point of view, they are quite different. > Moreover, if you load a code into the Ring model, you sometimes do not > know if the behavior, where you load a method, is a class or you later > will realize that it is a trait. The Ring 2 used for this a complex > machinery that was able to switch the behavior kind using the > #becomeForward: message. > Some time ago I decided to solve both problems by introducing of the > behavior strategies. That means that every behavior is a composition > of an instance of the RGBehavior class and a behavior strategy (e.g. > RGClassStrategy). Then changing of the behavior kind is then only a > matter of swapping of the strategy (which has a state so it not so > straightforward but still easy). The classes like RGClass or RGTrait > are still present but now they are only the factories that produce the > behaviors and they have no real instances. > > The next big thing I decided to do in Ring is renaming of the > entities. From the beginning, I used the prefix "RG2" to avoid the > collisions with the old Ring implementation but I supposed that before > the final release it will be renamed because, from the user > perspective, the Ring 2 should be a replacement for the old Ring and > not completely separate project. The attempts to replace the old Ring > with the new one showed me, that it is possible, but the old Ring is > so deeply used in the system that it leads to a huge amount of > instabilities. > So I decided to rename the Ring 2 classes and some methods to do not > make collisions with the old implementation. While the old Ring class > was named RGClassDefinition and in Ring 2 it was RG2ClassDefinition, > now it is renamed simply to RGClass. RG2Definition was renamed to > RGObject. The only ugly exception is RG2Package which is now named > RGPackageDefinition because the old Ring does not follow the naming > convention and uses the name "RGPackage". The old Ring packages will > get suffix "Deprecated" into their names. The old Ring and the Ring2 > can coexist in one image and it is still possible to load the new Ring > into the Pharo 6. > > Then I started to work on the changes metamodel for Ring with the goal > to be able to record, reproduce and revert (almost) all changes that > the user does in the model. The main goal of it is to be able to get > comparisons of two models and compute loading order of the changes so > it will be more easy to replace the Monticello metamodel and the > metamodel for code differences with a single solid solution based on > Ring. > > Cheers, > -- Pavel > -- www.tudorgirba.com www.feenk.com "It's not how it is, it is how we see it."

March 26, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-03-19

by Stephane Ducasse

Thanks Pavel. Carolina will start to work with Ring2 and Calypso to work on micro kernels :) Stef On Mon, Mar 26, 2018 at 11:41 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Maybe, but it does not solve the issue because, in Ring, every model is a > full, closed and complete environment where every message tries to return > you reasonable value even for unresolved parts of the model. You can start > to build your model from everywhere you want. > > method := RGMethod named: #someMethod. > self assert: (method parent localMethods size = 1). > self assert: (method parent name = #unresolved). > self assert: (method parent package = method package). > > method parent name: #SomeBehavior. > self assert: method parent isTrait not. > method environment ensureTraitNamed: #SomeBehavior. > method package: (method environment ensurePackageNamed: > #PackageWithExtension). > self assert: method parent isTrait. > self assert: (method parent package ~~ method package). > > Cheers, > -- Pavel > > 2018-03-26 11:21 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> Can't we make Extensions first class objects in ring? >> >> On Mon, Mar 26, 2018 at 11:02 AM, Pavel Krivanek < >> pavel.krivanek(a)gmail.com> wrote: >> >>> 2018-03-26 10:52 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>> > Pavel >>> > >>> > Why we do not know if this is a class or trait? >>> >>> Imagine that you are loading a package that has an extension method to >>> a class in a foreign package. It is identified only by the behavior >>> name, e.g. "TBehavior". But later, e.g. during merging of the package >>> model with some other, you will realize that the method is in fact a >>> part of a trait so you need to change kind of the class stub you >>> already have. >>> >>> > Maybe we could have decided that Ring2 only works for new traits if >>> > this simplifies your life. >>> >>> Because the traits are now a library and anyone can come with its own >>> metaclass that modifies the behavior metamodel, it is reasonable to >>> support it. And anyway, this work is already done ;-) >>> >>> -- Pavel >>> >>> > Stef >>> > >>> > On Mon, Mar 26, 2018 at 10:37 AM, Pavel Krivanek >>> > <pavel.krivanek(a)gmail.com> wrote: >>> >> Hi, >>> >> >>> >> I did some serious Ring 2 refactorings that I wanted to have finished >>> >> before the integration into Pharo. >>> >> Because Pharo now starts to support the stateful traits, it needs to >>> >> be supported by the metamodel too. However, we need to be able to >>> >> model the images with the old traits as well and from the internal >>> >> point of view, they are quite different. >>> >> Moreover, if you load a code into the Ring model, you sometimes do not >>> >> know if the behavior, where you load a method, is a class or you later >>> >> will realize that it is a trait. The Ring 2 used for this a complex >>> >> machinery that was able to switch the behavior kind using the >>> >> #becomeForward: message. >>> >> Some time ago I decided to solve both problems by introducing of the >>> >> behavior strategies. That means that every behavior is a composition >>> >> of an instance of the RGBehavior class and a behavior strategy (e.g. >>> >> RGClassStrategy). Then changing of the behavior kind is then only a >>> >> matter of swapping of the strategy (which has a state so it not so >>> >> straightforward but still easy). The classes like RGClass or RGTrait >>> >> are still present but now they are only the factories that produce the >>> >> behaviors and they have no real instances. >>> >> >>> >> The next big thing I decided to do in Ring is renaming of the >>> >> entities. From the beginning, I used the prefix "RG2" to avoid the >>> >> collisions with the old Ring implementation but I supposed that before >>> >> the final release it will be renamed because, from the user >>> >> perspective, the Ring 2 should be a replacement for the old Ring and >>> >> not completely separate project. The attempts to replace the old Ring >>> >> with the new one showed me, that it is possible, but the old Ring is >>> >> so deeply used in the system that it leads to a huge amount of >>> >> instabilities. >>> >> So I decided to rename the Ring 2 classes and some methods to do not >>> >> make collisions with the old implementation. While the old Ring class >>> >> was named RGClassDefinition and in Ring 2 it was RG2ClassDefinition, >>> >> now it is renamed simply to RGClass. RG2Definition was renamed to >>> >> RGObject. The only ugly exception is RG2Package which is now named >>> >> RGPackageDefinition because the old Ring does not follow the naming >>> >> convention and uses the name "RGPackage". The old Ring packages will >>> >> get suffix "Deprecated" into their names. The old Ring and the Ring2 >>> >> can coexist in one image and it is still possible to load the new Ring >>> >> into the Pharo 6. >>> >> >>> >> Then I started to work on the changes metamodel for Ring with the goal >>> >> to be able to record, reproduce and revert (almost) all changes that >>> >> the user does in the model. The main goal of it is to be able to get >>> >> comparisons of two models and compute loading order of the changes so >>> >> it will be more easy to replace the Monticello metamodel and the >>> >> metamodel for code differences with a single solid solution based on >>> >> Ring. >>> >> >>> >> Cheers, >>> >> -- Pavel >>> >> >>> > >>> >>> >> >> >> -- >> >> >> >> Guille Polito >> >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> >> CRIStAL - UMR 9189 >> >> 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 <+33%206%2052%2070%2066%2013> >> > >

March 26, 2018

[Pharo 7.0-dev] Build #723: 21473 Cleanup CharacterSet class

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #723 was: FAILURE. The Pull Request #1008 was integrated: "21473 Cleanup CharacterSet class" Pull request url: https://github.com/pharo-project/pharo/pull/1008 Issue Url: https://pharo.fogbugz.com/f/cases/21473 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 26, 2018

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

by Ben Coman

On 26 March 2018 at 22:08, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > Hi Ben, > > Le 23 mars 2018 Ã 19:53, Ben Coman <btc(a)openinworld.com> a Ã©crit : > > Coincidentally I have returned to Windows for a short while so thought I > should > put my money where my mouth is and have a stab at this. After a few hours > trying with NSIS, > I went searching for an alternative and Advanced Installer looked like a > good chance. > https://www.advancedinstaller.com/feats-list.html > The important part of (free) Basic Features is "Windows 10/8/7/Vista and > UAC installs" > Also further down are some CI options. > > > What bothers me is that it is not a free tool. > Its not open source, but its (beer) free for the basic features we need. The msi-installer I created was a 'Simple' project. https://www.advancedinstaller.com/licenses.html says... "The 'Simple' projects use only freeware features ... No license is necessary when using only freeware features in "Simple" projects. Install packages created using these features can be freely redistributed and used both in commercial and non-commercial purpose (subject to EULA)." The EULA (https://www.advancedinstaller.com/eula.html) says... "2.1 Freeware Features License. Caphyon grants you an unlimited license to use the Freeware Features of the Software. The install packages created using only the Freeware Features can be freely redistributed and used both in commercial and non-commercial purpose. and except for Part 11 the rest seems fairly innocuous. > I can see the list of features here: https://www. > advancedinstaller.com/feats-list.html > > > After just the "Simple Installation" tutorial and experimenting a few > hours I ironed out > a potential solution uploaded for testing to http://www.mediafire.com/ > file/3g579bmzqspt8e1/BCPharoLauncher.msi > with the full build tree at http://www.mediafire.com/ > file/5ijiww848lbkk7m/PharoLauncher%20Advanced%20Installer.zip > Links should be live for 30 days. > I've directly attached the much smaller installer-configuration file > "PharoLauncher.aip". > > > PharoLauncher was built with some minor changes from above... > 1. Download/extracted http://files.pharo.org/platform/Pharo6.1-win.zip > > 2. Renamed Pharo6.1 folder to BCPharoLauncher > Renamed Pharo6.1.* files to PharoLauncher1.1.* > > 3. Metacello new > smalltalkhubUser: 'Pharo' > project: 'PharoLauncher'; > configuration: 'PharoLauncher'; > load. > PharoLauncher hardResetPersistanceState: true. > PhLDeploymentScript doAll. > PhLDeploymentScript closeWindowsAndOpenLauncher. > Smalltalk snapshot: true andQuit: true. > > 4. Moved the image & changes files into a subfolder "PerUserFiles" > > 5. Built BCPharoLauncher.msi > > I prefixed my initials to distinguish it from the current official > PharoLauncher installer. > Hopefully this can be adopted as the official installer and they can be > dropped off. > > > Key features: > a. Provides a choice to install for "Everybody" (i.e. C:\Program Files > (x86)\Pharo\BCPharoLauncher\) > or "Only for me" (i.e. C:\Users\Ben\AppData\Local\Programs\Pharo\ > BCPharoLauncher\) > per attached screen snapshot. > > b. Start the install as a Standard User and it escalates only as needed. > > c. The Desktop and Start Menu shortcuts run the following script... > > // File: PharoLauncher.js > // Author: Ben Coman 2018.03.24 > // Purpose: Facilitate each user to run a personal copy of > PharoLauncher.image in their own data area. > > // Locations > basename = "\\PharoLauncher1.1"; > WshShell = WScript.CreateObject("WScript.Shell"); > fso = WScript.CreateObject("Scripting.FileSystemObject"); > systemFolder = fso.GetAbsolutePathName("."); > vmFilename = systemFolder + "\\Pharo.exe" > systemBasename = systemFolder + "\\PerUserFiles" + basename; > userFolder = WshShell.ExpandEnvironmentStrings("% > LOCALAPPDATA%\\Pharo"); > userFolder2 = userFolder + "\\PharoLauncher"; > userBasename = userFolder2 + basename; > > // Ensure user data folder exists for PharoLauncher > if( ! fso.FolderExists(userFolder)) > { fso.CreateFolder(userFolder); > fso.CreateFolder(userFolder2) > } > > // If either image or changes files missing from user folder, > copy from system folder. > if( ! fso.FileExists(userBasename + ".image") || ! > fso.FileExists(userBasename + ".changes")) > { > //WScript.Echo("Setting up user environment"); > fso.CopyFile(systemBasename + ".image", userBasename + > ".image", true); > fso.CopyFile(systemBasename + ".changes", userBasename + > ".changes", true); > } > > // Start personal copy of PharoLauncher > WshShell.Exec(vmFilename + " " + userBasename + ".image Â») > > > UAC support is really nice. > I would like to have the community opinion on using a non-free tool like > advancedinstaller. > If there is no objection, I would consider it seriously for a next Pharo > Launcher version. > Another alternative or subsequent step might be to decompile the msi-installer I supplied into Wix configuration files using dark.exe ( https://support.smartbear.com/viewarticle/10196/) and build the installer using Wix, which is open source ( http://wixtoolset.org/about/license/) Thanks for this work Ben! > Your welcome. Just an itch I had to scratch.... if you can't solve the problem, change the problem ;) cheers -ben

March 26, 2018

Re: [Pharo-dev] Some segfault crashes and freezes when trying to re-run saved pharo 7 images

by Holger Freyther

> On 26. Mar 2018, at 00:00, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Holger, Hey! > Is the intent of CCallOut with: aBlock to collect and defer deallocations until the block completes? I think it's nice but complex and wonder how general it is. But it seems like it would impact a lot of code and require a lot of effort changing existing code bases. My handle scheme is only intended to fix the issue of images crashing on startup. The problems with crashing on startup being a) one loses one's work and b) the issue is hard to debug. That, for me, motivates something like the simple fix I p[roposed. I'm not standing in the way of something more beautiful, but I do believe that one shouldn't make the perfect the enemy of the good. By all means, let's have a smart pointer! It will be beneficial for freetype and many other places. Nobody likes crashing images (for a mistake made in a previous run). My intent with the CCallOut is inhibit image saving until the code is outside a sequence of (interruptible, hence the backward jump int the example) C calls working with one or more pieces of manually managed memory. But maybe it is best to call it by what it does instead of finding a name of where it is used. I can't come up with a better example right now. But I think a Smartpointer wouldn't be of much help with a sequence of strtok calls. word := CStringAPI strtok: cStringPtr safeBytes separator: '\r'. [word isNil] whileFalse: [ word = 'Foo'... word = 'Bla'... word := CStringAPI strtok: nil separator: '\r' ------------- Image Save happening right here and word is not nil ----- ]. I hope this is more clear. holger

March 26, 2018

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

by Ben Coman

On 26 March 2018 at 21:56, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > Hi Ben, > > Le 23 mars 2018 Ã 04:31, Ben Coman <btc(a)openinworld.com> a Ã©crit : > > P.S. I was going to suggest also renaming Pharo.exe to > PharoLauncher.exe > but with an empty Documents\Pharo\vms > I get... "Error: Cannot detect Pharo executable in C:\Temp\MyPharoLauncher\ > PharoLauncher" > in PhLVirtualMachine>>initializeOn: "File @ C:\Temp\MyPharoLauncher\ > PharoLauncher" > since "executables := aFolder allChildrenMatching: self class > executableName." > is empty since "self class executableName" ==> "Pharo.exe" > > It would be nice for that to not be hard coded. > > > Where would you put this information? > I was thinking the filter could be broader with a wildcard match " *.exe ". There shouldn't be too many exe files in the folder, and any non-Pharo-exe should just fail to match the VM magic numbers and not affect anything anyway. On the other hand, perhaps this would cause the user's Image to show up in Task Manager as being run by PharoLauncher rather than Pharo, which again blurs the line between the two that I'd like to avoid. So I'll back away from that idea. > > I tried digging further but ran out of time. > I am curious it mattered since using "Pharo.exe" the Launcher went on to > download a VM anyway. > > > I use the vm shipped with the launcher when possible (e.g. to determine > pharo images version format or run current stable images. > If I cannot find the proper vm, then I download it from files.pharo.org. > > P.S.2. > I believe the best path forward for system-wide PharoLauncher installed > under "C:\Program Files" > would be to install there only... > * the VM > * PharoLauncher.ZIP > * a tiny non-Pharo wrapper program as the shortcut linked from AllUsers > > Start Menu > PharoLauncher > that extracts PharoLauncher.ZIP to the user's data area and then starts > that user specific PharoLauncher. > > Then regardless whether: > * they individually download/extract PharoLauncher.ZIP > * the system-wide-wrapper extracts PharoLauncher.ZIP > its a similar experience for users which should aid reliability by > reducing the number of "different " use cases. > > > I now install PharoLauncher in user LOCALAPPDATA folder on windows. > Does it solve the issue for you? > > Christophe > Using my day-to-day account "Ben" which is a Standard User account, I did the following... 1. Downloaded "pharo-launcher-installer-bleedingEdge-2018.03.23-x86.exe" 2. Double-clicked it and got "Windows Defender SmartScreen prevented an unrecognized app from starting." [1] (btw, I didn't get this with the msi-installer generated from Advanced Installer which I linked above. But maybe that was because the msi-installer was created and installed on the same PC, so it was just trusting itself by default. The msi wasn't signed, so is the experience different on other people's machine?) 3. Clicked "More Info" which allowed me to click "Run Anyway" and got... "To continue, enter admin user name and password" [2] so this is not really suited to students doing a user-level install on locked down lab machines. 4. After entering the password for user "Admin" (i.e. not Administrator, just another account in Administrators group) the install location was (as expected) given as.... "C:\Users\Admin\AppData\Local\PharoLauncher" [3] which again is not friendly to non-admin users. But just for kicks, I changed the install location to... "C:\Users\Ben\AppData\Local\PharoLauncher" and clicking on the PharoLauncher icon in the Start Menu it opened okay, and downloaded a 60539 image and associated VM and that image ran okay. So its a step in the right direction, however... the Start Menu shortcut entry is for All User per its location here... C:\ProgramData\Microsoft\Windows\Start Menu\Programs\PharoLauncher and the target of the shortcut is... C:\Users\Ben\AppData\Local\PharoLauncher\Pharo.exe so it only worked coincidentally because I'm clicking the Start Menu icon as user "Ben" and it would be broken for a second Standard User. >From my reading it will be a struggle to get NSIS working smoothly for multiple use cases at different privilege levels. i.e. both non-admin and admin users. cheers -ben

March 26, 2018

Re: [Pharo-dev] Windows PharoLauncher cannot create "C:\Program Files (x86)\Pharo\Pharo.image"

by Christophe Demarey

> Le 16 mars 2018 Ã 17:05, Ben Coman <btc(a)openinworld.com> a Ã©crit : > > > > On 16 March 2018 at 22:23, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > > For now, if you are admin, you could install PharoLauncher under Â« Program Files Â» but then, you also need to be admin to run it. If you are not admin, you should install PharoLauncher elsewhere. > > As I see this recommendation for the Nth time, maybe it is time the default location to C:\Pharo (or C:\PharoLauncher) ... > > other languages don't seem to have any problem with that whatsoever (I see in my dir C:\Python27, C:\Ruby24-x64, cygwin, msys, mingw, ...) > > If the installer cannot escalate on its own, it shouldn't try in the first place. Otherwise it's just bad experience in literally the first step people will take with Pharo. > > Interestingly Python 3 has installed itself in %APPDATA%\Local\Programs\Python\Python36-32 ... so maybe that's also a location to consider which doesn't require admin rights. > > Peter > > I think Python 3 has it right. Its also where GitForWindows installs itself. > > Alternatively the parent %APPDATA%\Local\ > (equivalently %LOCALAPPDATA% which can be typed into Windows Explorer) > is where many apps seem to put their main executable. > On my system I discover... > %LOCALAPPDATA% \ Discord \ app-0.0.298 \ Discord.exe > %LOCALAPPDATA% \ Atom \ atom.exe > %LOCALAPPDATA% \ GitHubDesktop \ GitHubDesktop.exe > %LOCALAPPDATA% \ slack \ slack.exe > %LOCALAPPDATA% \ Roblox \ Versions \ RobloxStudioLauncherBeta.exe Very good idea. I updated Pharo Launcher to use LOCALAPPDATA. Thanks Ben

March 26, 2018

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

by Christophe Demarey

Hi Ben, > Le 23 mars 2018 Ã 19:53, Ben Coman <btc(a)openinworld.com> a Ã©crit : > > Coincidentally I have returned to Windows for a short while so thought I should > put my money where my mouth is and have a stab at this. After a few hours trying with NSIS, > I went searching for an alternative and Advanced Installer looked like a good chance. > https://www.advancedinstaller.com/feats-list.html <https://www.advancedinstaller.com/feats-list.html> > The important part of (free) Basic Features is "Windows 10/8/7/Vista and UAC installs" > Also further down are some CI options. What bothers me is that it is not a free tool. I can see the list of features here: https://www.advancedinstaller.com/feats-list.html > > After just the "Simple Installation" tutorial and experimenting a few hours I ironed out > a potential solution uploaded for testing to http://www.mediafire.com/file/3g579bmzqspt8e1/BCPharoLauncher.msi <http://www.mediafire.com/file/3g579bmzqspt8e1/BCPharoLauncher.msi> > with the full build tree at http://www.mediafire.com/file/5ijiww848lbkk7m/PharoLauncher%20Advanced%20In… <http://www.mediafire.com/file/5ijiww848lbkk7m/PharoLauncher%20Advanced%20In…> > Links should be live for 30 days. > I've directly attached the much smaller installer-configuration file "PharoLauncher.aip". > > > PharoLauncher was built with some minor changes from above... > 1. Download/extracted http://files.pharo.org/platform/Pharo6.1-win.zip <http://files.pharo.org/platform/Pharo6.1-win.zip> > > 2. Renamed Pharo6.1 folder to BCPharoLauncher > Renamed Pharo6.1.* files to PharoLauncher1.1.* > > 3. Metacello new > smalltalkhubUser: 'Pharo' > project: 'PharoLauncher'; > configuration: 'PharoLauncher'; > load. > PharoLauncher hardResetPersistanceState: true. > PhLDeploymentScript doAll. > PhLDeploymentScript closeWindowsAndOpenLauncher. > Smalltalk snapshot: true andQuit: true. > > 4. Moved the image & changes files into a subfolder "PerUserFiles" > > 5. Built BCPharoLauncher.msi > > I prefixed my initials to distinguish it from the current official PharoLauncher installer. > Hopefully this can be adopted as the official installer and they can be dropped off. > > > Key features: > a. Provides a choice to install for "Everybody" (i.e. C:\Program Files (x86)\Pharo\BCPharoLauncher\) > or "Only for me" (i.e. C:\Users\Ben\AppData\Local\Programs\Pharo\BCPharoLauncher\) > per attached screen snapshot. > > b. Start the install as a Standard User and it escalates only as needed. > > c. The Desktop and Start Menu shortcuts run the following script... > // File: PharoLauncher.js > // Author: Ben Coman 2018.03.24 > // Purpose: Facilitate each user to run a personal copy of PharoLauncher.image in their own data area. > > // Locations > basename = "\\PharoLauncher1.1 <smb://PharoLauncher1.1>"; > WshShell = WScript.CreateObject("WScript.Shell"); > fso = WScript.CreateObject("Scripting.FileSystemObject"); > systemFolder = fso.GetAbsolutePathName("."); > vmFilename = systemFolder + "\\Pharo.exe <smb://Pharo.exe>" > systemBasename = systemFolder + "\\PerUserFiles <smb://PerUserFiles>" + basename; > userFolder = WshShell.ExpandEnvironmentStrings("%LOCALAPPDATA%\\Pharo"); > userFolder2 = userFolder + "\\PharoLauncher <smb://PharoLauncher>"; > userBasename = userFolder2 + basename; > > // Ensure user data folder exists for PharoLauncher > if( ! fso.FolderExists(userFolder)) > { fso.CreateFolder(userFolder); > fso.CreateFolder(userFolder2) > } > > // If either image or changes files missing from user folder, copy from system folder. > if( ! fso.FileExists(userBasename + ".image") || ! fso.FileExists(userBasename + ".changes")) > { > //WScript.Echo("Setting up user environment"); > fso.CopyFile(systemBasename + ".image", userBasename + ".image", true); > fso.CopyFile(systemBasename + ".changes", userBasename + ".changes", true); > } > > // Start personal copy of PharoLauncher > WshShell.Exec(vmFilename + " " + userBasename + ".image Â») UAC support is really nice. I would like to have the community opinion on using a non-free tool like advancedinstaller. If there is no objection, I would consider it seriously for a next Pharo Launcher version. Thanks for this work Ben!

March 26, 2018

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

by Christophe Demarey

Hi Ben, > Le 23 mars 2018 Ã 04:31, Ben Coman <btc(a)openinworld.com> a Ã©crit : > > P.S. I was going to suggest also renaming Pharo.exe to PharoLauncher.exe > but with an empty Documents\Pharo\vms > I get... "Error: Cannot detect Pharo executable in C:\Temp\MyPharoLauncher\PharoLauncher" > in PhLVirtualMachine>>initializeOn: "File @ C:\Temp\MyPharoLauncher\PharoLauncher" > since "executables := aFolder allChildrenMatching: self class executableName." > is empty since "self class executableName" ==> "Pharo.exe" > > It would be nice for that to not be hard coded. Where would you put this information? > I tried digging further but ran out of time. > I am curious it mattered since using "Pharo.exe" the Launcher went on to download a VM anyway. I use the vm shipped with the launcher when possible (e.g. to determine pharo images version format or run current stable images. If I cannot find the proper vm, then I download it from files.pharo.org. > P.S.2. > I believe the best path forward for system-wide PharoLauncher installed under "C:\Program Files" > would be to install there only... > * the VM > * PharoLauncher.ZIP > * a tiny non-Pharo wrapper program as the shortcut linked from AllUsers > Start Menu > PharoLauncher > that extracts PharoLauncher.ZIP to the user's data area and then starts that user specific PharoLauncher. > > Then regardless whether: > * they individually download/extract PharoLauncher.ZIP > * the system-wide-wrapper extracts PharoLauncher.ZIP > its a similar experience for users which should aid reliability by reducing the number of "different " use cases. I now install PharoLauncher in user LOCALAPPDATA folder on windows. Does it solve the issue for you? Christophe

March 26, 2018