- Pharo-users - lists.pharo.org

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

Re: [Pharo-users] Test request

by john pfersich

I followed the steps in your mail and it seems to work fine in Ubuntu 16.04 LTS, though I've never tried Dr Geo and the app is mostly in French. It's been 47 years since I've used French extensively, so YMMV. Let you know if I have problems. On Mon, Jun 12, 2017 at 12:59 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > Hi, > > > A Dr. Geo user on Ubuntu 16.04 reported to me instability problem I do > not meet on my 12.04 config. It seems related to Cairo or FreeType. I > will likely update my system on 16.04 later this summer, but I can't > just tweak it as this is the end of the school year with several admin > tasks to conduct. > > Will any one of you with a Ubuntu 16.04 system wish to test Dr. Geo and > report to me any problem? > > If so, here is what to do: > > 1. Download and unzip > https://launchpad.net/drgeo/trunk/17.07/+download/DrGeo.app-17.07a.zip > > 2. Adjust system to 32 bits compatibility if necessary, follow > instructions at > http://www.drgeo.eu/faq#TOC-Debian-Jessie-Ubuntu-LinuxMint-12.04-LTS1 > > 3. Experiment freely then drag'n drop the TortueOrange.fgeo found in the > zip file at > https://www.dropbox.com/s/2n3taeev9mdphdm/TortueOrange.fgeo.zip?dl=0 > > Does it went fine? > > Thanks > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > > >

June 13, 2017

Test request

by Hilaire

Hi, A Dr. Geo user on Ubuntu 16.04 reported to me instability problem I do not meet on my 12.04 config. It seems related to Cairo or FreeType. I will likely update my system on 16.04 later this summer, but I can't just tweak it as this is the end of the school year with several admin tasks to conduct. Will any one of you with a Ubuntu 16.04 system wish to test Dr. Geo and report to me any problem? If so, here is what to do: 1. Download and unzip https://launchpad.net/drgeo/trunk/17.07/+download/DrGeo.app-17.07a.zip 2. Adjust system to 32 bits compatibility if necessary, follow instructions at http://www.drgeo.eu/faq#TOC-Debian-Jessie-Ubuntu-LinuxMint-12.04-LTS1 3. Experiment freely then drag'n drop the TortueOrange.fgeo found in the zip file at https://www.dropbox.com/s/2n3taeev9mdphdm/TortueOrange.fgeo.zip?dl=0 Does it went fine? Thanks Hilaire -- Dr. Geo http://drgeo.eu

June 12, 2017

Re: [Pharo-users] A question of style - pass a context or embed one?

by phil＠highoctane.be

A dynamic variable could work too. But domain objects are somewhat hard to do in my view because we are dealing with an API that has tons of options and customizability in its results + people can define their own types and fields. That's why I went for a JiraBuilder thing that has a reference to a Jira instance. That builder is allowing one to make higher level queries for the users (like doing Epics, Stories, links, custom fields resolution, meta data grabbing, prototype creation etc). I didn't want to have an Epic class, a Story class, etc. Because my idea of an Epic may not be your idea, so we may end up with a PluggableEpic etc and it will never end. My take is that it is better to use the vocabulary of the domain in the method names but still work with dynamic structures like dictionaries and some helpers. I am still curious to see those domain objects because I understand that they would ease inspection etc. Maybe we should have a generator for these so that we can regenerate the classes based on the metadata provided by Jira. Phil On Mon, Jun 12, 2017 at 9:28 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Hello Tim, > > 2017-06-12 16:15 GMT-03:00 Tim Mackinnon <tim(a)testit.works>: > > Hi - Iâm after some ideas or maybe previous examples that might guide me > in the best approach of wrapping a low level library (essentially the Jira > connector that Phil demoâd at Pharo days this year). > > > > There are some low level commands that will fetch json arrays for you > given a âliraâ instance- e.g: > > > > board := JiraBoard fromJira: jira named: âProject'. > > sprints := board sprintsFrom: jira. > > > > My question is related to building on top of this - and its a style > question. > > > > I want model objects that wrap the json arrays and let me navigate > things a bit more simply, and query details more naturally - however I > canât decide whether my model objects should âcontainâ a jira when you > instantiate them - which can be re-used for subsequent queries - OR - > whether I should view jira as a from of context, and keep passing it to > methods when I need to retrieve more details, or child objects? > > > > e.g. > > myBoard := ModelBoard fromJira: jira named: âProjectâ. > > mySprints := myBoard sprints. âNo need to pass the jira againâ. > > > > vs. > > > > mySprints :- myBoard sprintsIn: jira. > > > > > > Iâm wondering if anything might guide me one way or the other? Is one > more tasteful/elegant than the other? > > > I'd go for the first option. It is, every JIRA object knows the "jira" > it belongs to. > > Although the second option is better for decoupling, not having to > pass objects around to obtain properties allows you to better > integrate with the tools (think GTInspector with specific inspector > for cards). > > I don't understand what the "jira" is exactly, if a whole JSON object > (a Dictionary) containing everything, a connection to JIRA API, or > just the JSON object/Dictionary branch containing the attributes > specific of the "wraping" object (the board, in this case). > > Regards! > > Esteban A. Maringolo > > >

June 12, 2017

Re: [Pharo-users] A question of style - pass a context or embed one?

by Esteban A. Maringolo

Hello Tim, 2017-06-12 16:15 GMT-03:00 Tim Mackinnon <tim(a)testit.works>: > Hi - Iâm after some ideas or maybe previous examples that might guide me in the best approach of wrapping a low level library (essentially the Jira connector that Phil demoâd at Pharo days this year). > > There are some low level commands that will fetch json arrays for you given a âliraâ instance- e.g: > > board := JiraBoard fromJira: jira named: âProject'. > sprints := board sprintsFrom: jira. > > My question is related to building on top of this - and its a style question. > > I want model objects that wrap the json arrays and let me navigate things a bit more simply, and query details more naturally - however I canât decide whether my model objects should âcontainâ a jira when you instantiate them - which can be re-used for subsequent queries - OR - whether I should view jira as a from of context, and keep passing it to methods when I need to retrieve more details, or child objects? > > e.g. > myBoard := ModelBoard fromJira: jira named: âProjectâ. > mySprints := myBoard sprints. âNo need to pass the jira againâ. > > vs. > > mySprints :- myBoard sprintsIn: jira. > > > Iâm wondering if anything might guide me one way or the other? Is one more tasteful/elegant than the other? I'd go for the first option. It is, every JIRA object knows the "jira" it belongs to. Although the second option is better for decoupling, not having to pass objects around to obtain properties allows you to better integrate with the tools (think GTInspector with specific inspector for cards). I don't understand what the "jira" is exactly, if a whole JSON object (a Dictionary) containing everything, a connection to JIRA API, or just the JSON object/Dictionary branch containing the attributes specific of the "wraping" object (the board, in this case). Regards! Esteban A. Maringolo

June 12, 2017