June 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo 6 snap package

by phil＠highoctane.be

On Tue, Jun 13, 2017 at 11:34 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > On Tue, Jun 13, 2017 at 11:25:15AM +0200, phil(a)highoctane.be wrote: > > I need to upgrade to 16.04 now :-) > > :-) > > Don't forget you can install snapd on Ubuntu 14.04: > > https://snapcraft.io/docs/core/install-ubuntu > > Ah, wasn't aware of that. Thx Alistair! Phil > Cheers, > Alistair > > > > Phil > > > > On Tue, Jun 13, 2017 at 11:04 AM, Stephane Ducasse < > stepharo.self(a)gmail.com> > > wrote: > > > > THANKS A LOT ALISTAIR. > > I mean it :) > > > > On Tue, Jun 13, 2017 at 10:58 AM, Alistair Grant < > akgrant0710(a)gmail.com> > > wrote: > > > Hi Everyone, > > > > > > I've updated the Pharo 6 snap package for Ubuntu. > > > > > > The major advantages of using the snap package are: > > > > > > - No need to install all the 32 bit dependencies on a 64 bit > system, > > > they're all contained and isolated within the snap package. > > > - Automagically distinguish between 32 bit and 64 bit images and > run the > > > appropriate VM (as with the ZeroConf package, the 64 bit VM still > > > needs more testing). > > > > > > > > > > > > To get Pharo up and running on Ubuntu 16.04 or later: > > > > > > # Install Pharo > > > $ sudo snap install --candidate pharo --classic > > > # If your system isn't configured for threaded heartbeat: > > > $ sudo pharo.config > > > # Download the latest Pharo 6 image > > > $ pharo.getimage > > > # Go... > > > $ pharo.ui Pharo.image > > > # or: > > > $ pharo Pharo.image eval 4+3 > > > > > > To get a list of available commands: > > > > > > $ snap info pharo > > > > > > > > > If you're on Debian or Ubuntu 14.04 you'll need to install snapd, > see > > > https://snapcraft.io/docs/core/install > > > > > > > > > The VM is the threaded heartbeat, dated 201705310241. > > > > > > The installation flags are: > > > > > > --candidate - The edge and beta channels are for development > versions. > > > It progresses to candidate and then stable. > > > --classic - Snap packages are normally sandboxed for security > > > reasons. Since Pharo is a development environment > > > in which we want to be able to run any executable, > > > or load any library, it is installed with access to > > > the entire system (as the running user). > > > > > > Why use snap packages? > > > > > > - They include all dependencies. In particular, for the 32 bit > > > versions, this means that it isn't necessary to install all the > 32 bit > > > architecture and associated dependencies. > > > - Including dependencies means that there shouldn't be any > problems with > > > incompatible library versions when upgrading. > > > > > > Why not use snap packages? > > > > > > - It's a relatively new technology, with a number of rough edges. > > > - There may still be issues with its sandboxing that I haven't > > > discovered yet. > > > - Because the package uses classic confinement, it isn't > > > cross-distribution in practice (unfortunately). > > > > > > Please let me know of any other advantages or disadvantages you > think > > > should be listed here. > > > > > > If you don't trust me to configure your system correctly (which > requires > > > sudo): > > > > > > - All the scripts that make up the sub-commands are visible, e.g. > > > pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG > > > > > > > > > The packaging code is at: https://github.com/akgrant43/pharo-snap > > > > > > > > > Cheers, > > > Alistair > > >

June 13, 2017

Re: [Pharo-users] Pharo 6 snap package

by Alistair Grant

On Tue, Jun 13, 2017 at 11:25:15AM +0200, phil(a)highoctane.be wrote: > I need to upgrade to 16.04 now :-) :-) Don't forget you can install snapd on Ubuntu 14.04: https://snapcraft.io/docs/core/install-ubuntu Cheers, Alistair > Phil > > On Tue, Jun 13, 2017 at 11:04 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > THANKS A LOT ALISTAIR. > I mean it :) > > On Tue, Jun 13, 2017 at 10:58 AM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > > Hi Everyone, > > > > I've updated the Pharo 6 snap package for Ubuntu. > > > > The major advantages of using the snap package are: > > > > - No need to install all the 32 bit dependencies on a 64 bit system, > > they're all contained and isolated within the snap package. > > - Automagically distinguish between 32 bit and 64 bit images and run the > > appropriate VM (as with the ZeroConf package, the 64 bit VM still > > needs more testing). > > > > > > > > To get Pharo up and running on Ubuntu 16.04 or later: > > > > # Install Pharo > > $ sudo snap install --candidate pharo --classic > > # If your system isn't configured for threaded heartbeat: > > $ sudo pharo.config > > # Download the latest Pharo 6 image > > $ pharo.getimage > > # Go... > > $ pharo.ui Pharo.image > > # or: > > $ pharo Pharo.image eval 4+3 > > > > To get a list of available commands: > > > > $ snap info pharo > > > > > > If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see > > https://snapcraft.io/docs/core/install > > > > > > The VM is the threaded heartbeat, dated 201705310241. > > > > The installation flags are: > > > > --candidate - The edge and beta channels are for development versions. > > It progresses to candidate and then stable. > > --classic - Snap packages are normally sandboxed for security > > reasons. Since Pharo is a development environment > > in which we want to be able to run any executable, > > or load any library, it is installed with access to > > the entire system (as the running user). > > > > Why use snap packages? > > > > - They include all dependencies. In particular, for the 32 bit > > versions, this means that it isn't necessary to install all the 32 bit > > architecture and associated dependencies. > > - Including dependencies means that there shouldn't be any problems with > > incompatible library versions when upgrading. > > > > Why not use snap packages? > > > > - It's a relatively new technology, with a number of rough edges. > > - There may still be issues with its sandboxing that I haven't > > discovered yet. > > - Because the package uses classic confinement, it isn't > > cross-distribution in practice (unfortunately). > > > > Please let me know of any other advantages or disadvantages you think > > should be listed here. > > > > If you don't trust me to configure your system correctly (which requires > > sudo): > > > > - All the scripts that make up the sub-commands are visible, e.g. > > pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG > > > > > > The packaging code is at: https://github.com/akgrant43/pharo-snap > > > > > > Cheers, > > Alistair

June 13, 2017

Re: [Pharo-users] Pharo 6 snap package

by Alistair Grant

On Tue, Jun 13, 2017 at 08:58:31AM +0000, Alistair Grant wrote: > Hi Everyone, > > I've updated the Pharo 6 snap package for Ubuntu. > > The major advantages of using the snap package are: > > - No need to install all the 32 bit dependencies on a 64 bit system, > they're all contained and isolated within the snap package. > - Automagically distinguish between 32 bit and 64 bit images and run the > appropriate VM (as with the ZeroConf package, the 64 bit VM still > needs more testing). > > > > To get Pharo up and running on Ubuntu 16.04 or later: > > # Install Pharo > $ sudo snap install --candidate pharo --classic > # If your system isn't configured for threaded heartbeat: > $ sudo pharo.config > # Download the latest Pharo 6 image > $ pharo.getimage I should have added if you want the 32 bit image: $ pharo.getimage32 the rest remains the same > # Go... > $ pharo.ui Pharo.image > # or: > $ pharo Pharo.image eval 4+3 > > To get a list of available commands: > > $ snap info pharo > > > If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see > https://snapcraft.io/docs/core/install > > > The VM is the threaded heartbeat, dated 201705310241. > > The installation flags are: > > --candidate - The edge and beta channels are for development versions. > It progresses to candidate and then stable. > --classic - Snap packages are normally sandboxed for security > reasons. Since Pharo is a development environment > in which we want to be able to run any executable, > or load any library, it is installed with access to > the entire system (as the running user). > > Why use snap packages? > > - They include all dependencies. In particular, for the 32 bit > versions, this means that it isn't necessary to install all the 32 bit > architecture and associated dependencies. > - Including dependencies means that there shouldn't be any problems with > incompatible library versions when upgrading. > > Why not use snap packages? > > - It's a relatively new technology, with a number of rough edges. > - There may still be issues with its sandboxing that I haven't > discovered yet. > - Because the package uses classic confinement, it isn't > cross-distribution in practice (unfortunately). > > Please let me know of any other advantages or disadvantages you think > should be listed here. > > If you don't trust me to configure your system correctly (which requires > sudo): > > - All the scripts that make up the sub-commands are visible, e.g. > pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG > > > The packaging code is at: https://github.com/akgrant43/pharo-snap > > > Cheers, > Alistair

June 13, 2017

Re: [Pharo-users] Pharo 6 snap package

by phil＠highoctane.be

I need to upgrade to 16.04 now :-) Phil On Tue, Jun 13, 2017 at 11:04 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > THANKS A LOT ALISTAIR. > I mean it :) > > On Tue, Jun 13, 2017 at 10:58 AM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > > Hi Everyone, > > > > I've updated the Pharo 6 snap package for Ubuntu. > > > > The major advantages of using the snap package are: > > > > - No need to install all the 32 bit dependencies on a 64 bit system, > > they're all contained and isolated within the snap package. > > - Automagically distinguish between 32 bit and 64 bit images and run the > > appropriate VM (as with the ZeroConf package, the 64 bit VM still > > needs more testing). > > > > > > > > To get Pharo up and running on Ubuntu 16.04 or later: > > > > # Install Pharo > > $ sudo snap install --candidate pharo --classic > > # If your system isn't configured for threaded heartbeat: > > $ sudo pharo.config > > # Download the latest Pharo 6 image > > $ pharo.getimage > > # Go... > > $ pharo.ui Pharo.image > > # or: > > $ pharo Pharo.image eval 4+3 > > > > To get a list of available commands: > > > > $ snap info pharo > > > > > > If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see > > https://snapcraft.io/docs/core/install > > > > > > The VM is the threaded heartbeat, dated 201705310241. > > > > The installation flags are: > > > > --candidate - The edge and beta channels are for development versions. > > It progresses to candidate and then stable. > > --classic - Snap packages are normally sandboxed for security > > reasons. Since Pharo is a development environment > > in which we want to be able to run any executable, > > or load any library, it is installed with access to > > the entire system (as the running user). > > > > Why use snap packages? > > > > - They include all dependencies. In particular, for the 32 bit > > versions, this means that it isn't necessary to install all the 32 bit > > architecture and associated dependencies. > > - Including dependencies means that there shouldn't be any problems with > > incompatible library versions when upgrading. > > > > Why not use snap packages? > > > > - It's a relatively new technology, with a number of rough edges. > > - There may still be issues with its sandboxing that I haven't > > discovered yet. > > - Because the package uses classic confinement, it isn't > > cross-distribution in practice (unfortunately). > > > > Please let me know of any other advantages or disadvantages you think > > should be listed here. > > > > If you don't trust me to configure your system correctly (which requires > > sudo): > > > > - All the scripts that make up the sub-commands are visible, e.g. > > pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG > > > > > > The packaging code is at: https://github.com/akgrant43/pharo-snap > > > > > > Cheers, > > Alistair > > > > >

June 13, 2017

Re: [Pharo-users] [ANN] Pharo 6.0 released!

by Stephane Ducasse

Us too :) On Wed, Jun 7, 2017 at 8:20 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Great news! Thanks to Esteban and the 80+ contributors. > > I have multiple patches waiting for the 7.0 dev cycle to begin. Can't > wait... :-) > > Cheers, > Alistair > > > On 6 June 2017 at 17:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> Dear World, >> >> The time has come for Pharo 6.0! >> >> Pharo is a pure object-oriented programming language and a powerful >> environment, focused on simplicity and immediate feedback. >> >> This is our most significant release yet. Here are some highlights: >> >> - Pharo is now provided in 64-bit version in Linux and OSX and brings even >> better performance and stability (beware, 64bits version is a new technology >> and a small amount of tests is still failing) >> - A new code changes management system named Epicea for easier reviewing and >> recovering of your code easily >> - Integrated support for Git through an easy-to-use tool for repositories >> and commits management named Iceberg (as a preview for Pharo 6, it will be >> the default in Pharo 7) >> - The unified foreign function interface (UnifiedFFI) for interfacing with >> the outside world is significantly improved >> - The PharoVM is now part of OpenSmalltalk initiative >> - Introduction of object immutability, alternative bytecode sets and block >> closures independent of outer context >> - Pharo can now be bootstrapped from source code managed by Git >> - Pharo modularity is improved >> - Pharo is faster >> - The Dark Theme was improved and set as default color theme of Pharo >> >> >> These are just the more prominent highlights, but the details are just as >> important. We have closed 1474 issues in Pharo 6.0 (a more complete >> changelog can be found at >> https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo60Change…) >> >> While the technical improvements are significant (starting the transition to >> 64bits is a remarkable achievement), still the most impressive fact is that >> the new code that got in the main Pharo 6.0 image was contributed by more >> than 80 people. >> >> Pharo is more than code. It is an exciting project involving energetic >> people. We thank all the contributors of this release: >> >> Alberto Bacchelli, Alejandro Infante, Alexandre Bergel, Aliaksei Syrel, >> Alistair Grant, Andrei Chis, Ben Coman, Bernardo Contreras, Bernhard Pieber, >> Boris Spasojevic, Christophe Demarey, Clement Bera, Cyril Ferlicot, Dale >> Henrichs, Damien Cassou, Damien Pollet, Dave Lewis, Denis Kudriashov, Dirk >> Roeleveld, Eliot Miranda, Esteban Lorenzano, Esteban Maringolo, Evan >> Donahue, Federico Balaguer, Franck Warlouzet, Glenn Cavarle, Guillermo >> Polito, Gustavo Santos, Henrik Johansen, Henrik Nergaard, Hilaire Fernandes, >> Holger Hans, Jan Kurs, Jan van de Sandt, Johan Fabry, Juraj Kubelka, K. K. >> Subramaniam, Ken Causey, Kris Gybels, Lionel Akue, Luc Fabresse, Lucas >> Godoy, Marcus Denker, Mariano Martinez Peck, Marion Noirbent, Martin Dias, >> Max Leske, Maxime Roelandt, Merwan Ouddane, Matteo Bellotto, Miguel >> Campusano, Milton Mamani, Myroslava Romaniuk, Nicolai Hess, Nicolas Cellier, >> Nicolas Passerini, Norbert Hartl, Offray Luna, Pablo Tesone, Paul De >> Bruicker, Pavel Krivanek, Peter Uhnak, Philippe Back, Roger Stebler, Ronie >> Salgado, Sean DeNigris, Serge Stinckwich, Skip Lentz, Sophie Kaleba, Stefan >> Reichhart, Stephan Eggermont, Stephane Ducasse, Sven Van Caekenberghe, >> Thibault Arloing, Thibault Arloing, Thibault Raffaillac, Thierry Goubier, >> Thomas Heniart, Tommaso Dal Sasso, Torsten Bergmann, Tudor Girba, Udo >> Schneider, Valentin Ryckewaert, Vincent Blondeau, Werner Kassens, Yuriy >> Tymchuk >> >> (If you contributed with Pharo 6.0 development in any way and we missed your >> name, please send us a mail and we will add you). >> >> Enjoy! >> >> The Pharo Team >> >> Try Pharo: http://pharo.org/download >> Learn Pharo: http://pharo.org/documentation >

June 13, 2017

Re: [Pharo-users] Pharo 6 snap package

by Stephane Ducasse

THANKS A LOT ALISTAIR. I mean it :) On Tue, Jun 13, 2017 at 10:58 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Everyone, > > I've updated the Pharo 6 snap package for Ubuntu. > > The major advantages of using the snap package are: > > - No need to install all the 32 bit dependencies on a 64 bit system, > they're all contained and isolated within the snap package. > - Automagically distinguish between 32 bit and 64 bit images and run the > appropriate VM (as with the ZeroConf package, the 64 bit VM still > needs more testing). > > > > To get Pharo up and running on Ubuntu 16.04 or later: > > # Install Pharo > $ sudo snap install --candidate pharo --classic > # If your system isn't configured for threaded heartbeat: > $ sudo pharo.config > # Download the latest Pharo 6 image > $ pharo.getimage > # Go... > $ pharo.ui Pharo.image > # or: > $ pharo Pharo.image eval 4+3 > > To get a list of available commands: > > $ snap info pharo > > > If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see > https://snapcraft.io/docs/core/install > > > The VM is the threaded heartbeat, dated 201705310241. > > The installation flags are: > > --candidate - The edge and beta channels are for development versions. > It progresses to candidate and then stable. > --classic - Snap packages are normally sandboxed for security > reasons. Since Pharo is a development environment > in which we want to be able to run any executable, > or load any library, it is installed with access to > the entire system (as the running user). > > Why use snap packages? > > - They include all dependencies. In particular, for the 32 bit > versions, this means that it isn't necessary to install all the 32 bit > architecture and associated dependencies. > - Including dependencies means that there shouldn't be any problems with > incompatible library versions when upgrading. > > Why not use snap packages? > > - It's a relatively new technology, with a number of rough edges. > - There may still be issues with its sandboxing that I haven't > discovered yet. > - Because the package uses classic confinement, it isn't > cross-distribution in practice (unfortunately). > > Please let me know of any other advantages or disadvantages you think > should be listed here. > > If you don't trust me to configure your system correctly (which requires > sudo): > > - All the scripts that make up the sub-commands are visible, e.g. > pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG > > > The packaging code is at: https://github.com/akgrant43/pharo-snap > > > Cheers, > Alistair >

June 13, 2017

Pharo 6 snap package

by Alistair Grant

Hi Everyone, I've updated the Pharo 6 snap package for Ubuntu. The major advantages of using the snap package are: - No need to install all the 32 bit dependencies on a 64 bit system, they're all contained and isolated within the snap package. - Automagically distinguish between 32 bit and 64 bit images and run the appropriate VM (as with the ZeroConf package, the 64 bit VM still needs more testing). To get Pharo up and running on Ubuntu 16.04 or later: # Install Pharo $ sudo snap install --candidate pharo --classic # If your system isn't configured for threaded heartbeat: $ sudo pharo.config # Download the latest Pharo 6 image $ pharo.getimage # Go... $ pharo.ui Pharo.image # or: $ pharo Pharo.image eval 4+3 To get a list of available commands: $ snap info pharo If you're on Debian or Ubuntu 14.04 you'll need to install snapd, see https://snapcraft.io/docs/core/install The VM is the threaded heartbeat, dated 201705310241. The installation flags are: --candidate - The edge and beta channels are for development versions. It progresses to candidate and then stable. --classic - Snap packages are normally sandboxed for security reasons. Since Pharo is a development environment in which we want to be able to run any executable, or load any library, it is installed with access to the entire system (as the running user). Why use snap packages? - They include all dependencies. In particular, for the 32 bit versions, this means that it isn't necessary to install all the 32 bit architecture and associated dependencies. - Including dependencies means that there shouldn't be any problems with incompatible library versions when upgrading. Why not use snap packages? - It's a relatively new technology, with a number of rough edges. - There may still be issues with its sandboxing that I haven't discovered yet. - Because the package uses classic confinement, it isn't cross-distribution in practice (unfortunately). Please let me know of any other advantages or disadvantages you think should be listed here. If you don't trust me to configure your system correctly (which requires sudo): - All the scripts that make up the sub-commands are visible, e.g. pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG The packaging code is at: https://github.com/akgrant43/pharo-snap Cheers, Alistair

June 13, 2017

Re: [Pharo-users] Wiring objects, IoC and Service Locator

by aryehof

Consider that in Java, one can /only /achieve polymorphic behavior across objects by using /interfaces /or /inheritance/. In Smalltalk one can achieve polymorphic behavior across objects just by *having them understand the same message*. The need to have complex schemes for the wiring of objects in Java is a consequence of this. -- View this message in context: http://forum.world.st/Wiring-objects-IoC-and-Service-Locator-tp4949280p4951… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 13, 2017

Re: [Pharo-users] Help in thinking about how to save a "program"

by Ben Coman

On Mon, Jun 12, 2017 at 7:22 AM, Glenn Hoetker <ghoetker(a)me.com> wrote: > Hi all. Iâm new to Pharo and loving it. As I transition from a text-file > based mindset, Iâm a little stuck and would appreciate help in how to think > about a situation in a Pharonic (Pharo-ish, Pharoc?) way. > > Iâm crafting a short program to help me process a large text file > (specifically: extract, sorting, and regularizing the âkeywordâ fields of a > large BibTex file). Especially since I donât really know what Iâm doing, > working in a Playground has been a great development environment. Now that > the program is complete (under 30 lines, wonderful), I want to be able to > save it for future reference (and perhaps for future use). If Iâd written > a shell script, Iâd just save âfixBibDeskKeyWords.shâ to a directory. Iâm > not sure what to do in the Pharo environment, thought. > > At the moment, it just lives in the Playground Iâve developed it on. I > could save the image and leave that Playground open, but Iâm just positive > thatâs not a best practice. I also worry about what happens if I > closed/cleared that Playground by accident. > > I think I understand that, if I created a new package, I could use > Monticello to save it to a local cache and load it into a new image > whenever I needed it. But, given that itâs short, highly specialized and > fairly linear, the idea of creating a âGHBibDeskStuffâ package with one > class (âGBibDeskKeywordFixerâ containing a single âFixFileâ method seems > really heavy and awkward. > > Can one save the contents of a Playground in a Pharonic way? Is there a > better approach? > > Thank you to all involved in this wonderful programming ecosystem. I > appreciate any advice. > Great to hear you are enjoying Pharo. The heavy part of saving to disk as a Monticello package is an optional secondary step, but to make you code "permanent" in the image you do need a class to hang it on, and a package to hold that. Doing this only in-Image is quite light and quick to do, and makes it easy to find later. In a System Browser create package "GHBibDeskStuff", class GBibDeskKeywordFixer. Create your method so you can use it from playground like this... GBibDeskKeywordFixer new fixFile. Then to the class side of GBibDeskKeywordFixer also add a method #fixFile like this... GBibDeskKeywordFixer class >> fixFile self new fixFile. so that from playground you can drop the "new" and use it like this... GBibDeskKeywordFixer fixFile Feels like you've added a new command to Pharo? Note that "GBibDeskKeywordFixer class >>" is just a documentation convention indicating you should click the <Class> button to add a method to the class-side. cheers -ben

June 13, 2017

Re: [Pharo-users] Help in thinking about how to save a "program"

by Benoit St-Jean

Hi Glenn, Another very useful tool you can use to save/manipulate/store Smalltalk scripts is ScriptManager (http://catalog.pharo.org/catalog/project/ScriptManager) Â There are plenty of similar tools but this one is very easy to use and simple and has been doing the job for years for me. hthÂ ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein) From: Glenn Hoetker <ghoetker(a)me.com> To: pharo-users(a)lists.pharo.org Sent: Sunday, June 11, 2017 7:23 PM Subject: [Pharo-users] Help in thinking about how to save a "program" Hi all. Â Iâm new to Pharo and loving it. Â As I transition from a text-file based mindset, Iâm a little stuck and would appreciate help in how to think about a situation in a Pharonic (Pharo-ish, Pharoc?) way. Iâm crafting a short program to help me process a large text file (specifically: extract, sorting, and regularizing the âkeywordâ fields of a large BibTex file). Especially since I donât really know what Iâm doing, working in a Playground has been a great development environment. Â Now that the program is complete (under 30 lines, wonderful), I want to be able to save it for future reference (and perhaps for future use). Â If Iâd written a shell script, Iâd just save âfixBibDeskKeyWords.shâ to a directory. Iâm not sure what to do in the Pharo environment, thought. At the moment, it just lives in the Playground Iâve developed it on. Â I could save the image and leave that Playground open, but Iâm just positive thatâs not a best practice. I also worry about what happens if I closed/cleared that Playground by accident. I think I understand that, if I created a new package, I could use Monticello to save it to a local cache and load it into a new image whenever I needed it. Â But, given that itâs short, highly specialized and fairly linear, the idea of creating a âGHBibDeskStuffâ package with one class (âGBibDeskKeywordFixerâ containing a single âFixFileâ method seems really heavy and awkward. Can one save the contents of a Playground in a Pharonic way? Â Is there a better approach? Thank you to all involved in this wonderful programming ecosystem. I appreciate any advice. Glenn Glenn Hoetkerghoetker@me.comhttp://hoetker.faculty.asu.edu

June 13, 2017