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

Re: [Pharo-users] How to use uFFI with String

by Ben Coman

Cool. Looks good. cheers -ben On Wed, Jun 7, 2017 at 2:20 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi ben > > Yes I changed it :) > Stef > > On Mon, May 29, 2017 at 10:16 AM, Ben Coman <btc(a)openinworld.com> wrote: > > On Mon, May 29, 2017 at 7:24 AM, horrido <horrido.hobbies(a)gmail.com> > wrote: > >> I don't use GitHub. I've never used GitHub. I don't know how to use > GitHub. > >> > >> I looked at making a pull request and I was totally stymied. "Clueless" > >> doesn't even begin to describe how I felt. > > > > Everyone starts there. Its a useful skill to have, so if you are > > interested to learn, here's a quickstart guide... > > (Note since its a text file, we are shortcutting so you don't even > > need git on your local machine) > > 1. Click on this link. > > https://github.com/SquareBracketAssociates/UpdatedPharoByExample/blob/ > master/Morphic/Morphic.pier > > 2. Click the <Fork> button in the top tight, then browse to > > "Morphic.pier" in your fork. > > 3. To the right of the <Raw/Blame/History> buttons, click the <Pencil> > > button to edit the file. > > 4. After editing, at the bottom select "Create a new branch for this > > commit and start a pull request" > > and enter commit title, comment and new-branch-name to reflect your > > contribution. Click <Propose file change> > > 5. Now looking at "Open a pull request", this is issuing a PR to your > > own fork. We need to change to the upstream fork. At the top click > > on "forked from SquareBracketAssociates/UpdatedPharoByExample" . > > 6. Under "Your recently pushed branches" click <Compare & pull request> > > 7. Check... > > base fork: SquareBracketAssociates/UpdatedPharoByExample > > base: master > > head fork: YourName/UpdatedPharoByExample > > compare: your new-branch-name > > Review the diff, enter PR title and comment, then click <Create pull > request>. > > > > If you have problems, try to catch me on Discord... > > https://discord.gg/dKv4qR/KCKQSSt > > > > cheers -ben > > > > P.S. @Stef, btw, it looks like "the guidelines for contributing" is > > out of date... > > https://github.com/SquareBracketAssociates/ > UpdatedPharoByExample/blob/master/CONTRIBUTING.md > > "This is a test to see if it makes sense to convert PharoByExample > > into pier format." > > > > > >> > >> > >> Ben Coman wrote > >>> On Sat, May 27, 2017 at 9:15 PM, horrido < > >> > >>> horrido.hobbies@ > >> > >>> > wrote: > >>>> Yes, I did. I found it difficult to understand. It would be nice to > have > >>>> some > >>>> clear examples in the documentation, for example, really simple and > >>>> common > >>>> situations such as a C function returning an integer in a > >>>> passed-by-reference argument. > >>>> > >>>> Speaking of documentation, in "Pharo by Example 50," I found this > >>>> statement: > >>>> > >>>>> (Recall that you should set halosEnabled in the Preferences > >>>> browser.) > >>>> > >>>> However, nowhere else in the book is there any reference to > halosEnabled > >>>> or > >>>> Preferences browser. > >>> > >>> Nice pick up. Now in Settings (in a fresh 60473 image), filtering on > >>> "halo" shows only: > >>> * Cycle both directions > >>> * Encloses fullbounds > >>> * Exhibits bounds > >>> so the comment seems irrelevant > >>> > >>> and #halosEnabled & #halosEnabled: each have one implementor > class-side of > >>> Morph > >>> with one sender from MorphTest each, and one sender from > Morph>>addHalo: > >>> > >>> and "Morph halosEnabled" ==> true, so the statement seems unnecessary. > >>> Would you like to contribute a pull request removing it? > >>> https://github.com/SquareBracketAssociates/UpdatedPharoByExample/blob/ > master/Morphic/Morphic.pier > >>> > >>> > >>>> Did you guys forget and leave out a chunk of the book? > >>> > >>> Its an evolutionary book originally from Squeak. It could well be > >>> that some parts of the book have been cleaned > >>> better than others to match Image changes. Thanks for reporting, and > >>> even better if you can correct it. > >>> > >>> cheers -ben > >> > >> > >> > >> > >> > >> -- > >> View this message in context: http://forum.world.st/How-to- > use-uFFI-with-String-tp4947890p4948512.html > >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >> > > > >

June 7, 2017

Re: [Pharo-users] How to deploy headless app without changes and source files?

by Andreas Sunardi

Hi Stef, I can't have changes file bundled with the tool because the tool is installed in a centralized location in my network and multiple users will run it. So the image is in a central location and read-only and so is the changes file (if I must have a changes file). The tool is only a processor. It does not need to keep/save its state. Hence, I cannot have multiple users writing to that one and the same changes file. I'm trying to dissect the call chain to ChangesLog and try to cut it so Pharo won't write to the changes file. I'm sure I should not do this. There must be a better way. On Tue, Jun 6, 2017 at 11:55 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > We started to work on making the system ready to stop using these files. > There are two things. > - the changes are a tape that logs what you are doing and right now > the system is not done to accept not to log > So I imagine that you can remove the changes file but then do not compile > code. > - I do not get the "so I can't have changes file bundled with the tool." > you do not have a bat or script that launches the application that is > somewhere in a folder where you have the vm and the image? you could > have the changes file there. > > We are interested in your scenario because last year I got a guy > working on making pharo silent. I do not know if its changes got > integrated into pharo. > This is really something that we want to have. > - having sources and changes in a specific location > - having no source and no changes (even if it means lose your code). > - ... > > Stef > > On Tue, Jun 6, 2017 at 8:14 PM, Andreas Sunardi <a.sunardi(a)gmail.com> > wrote: > > Sorry to bring this up again. But it turns out that I had the image > > directory writable by myself, so it created a new changes file. That's > why > > Pharo didn't complain about missing changes file. When I removed write > > permission in the tool installation, Pharo gives error for not having or > not > > able to write to changes file. > > > > I guess I'm back to the problem how to deploy a tool without changes > file. I > > have multiple users that will be running this tool, which is installed > in a > > centralized site, so I can't have changes file bundled with the tool. > > > > On Mon, Jun 5, 2017 at 5:47 PM, Andreas Sunardi <a.sunardi(a)gmail.com> > wrote: > >> > >> I had my changes and sources files in the bundle but has their write > >> permission removed, and that causes the error. Simply deploying the tool > >> without the changes file seems to fix it. Pharo5 doesn't complain if the > >> changes file isn't there. > >> > >> However, without the sources file, I get this warning that pharo cannot > >> locate the sources file. Including the sources file in the deployed > tool is > >> fine with me. > >> > >> So, I think that's my solution. Thanks! > >> > >> > >> On Mon, Jun 5, 2017 at 5:07 PM, Andreas Sunardi <a.sunardi(a)gmail.com> > >> wrote: > >>> > >>> I found this StackOverflow question: > >>> > >>> https://stackoverflow.com/questions/14737695/is-it- > possible-to-deploy-a-pharo-image-without-changes-and- > sources-files/14747328 > >>> > >>> and this older forum thread: > >>> > >>> https://www.mail-archive.com/pharo-project@lists.gforge. > inria.fr/msg21170.html > >>> > >>> I'm using Pharo5.0 and neither of these options is available anymore. > >>> What is the new way to do this? > >>> > >>> -- > >>> Andreas Sunardi > >> > >> > > > >

June 6, 2017

Re: [Pharo-users] How to deploy headless app without changes and source files?

by Stephane Ducasse

We started to work on making the system ready to stop using these files. There are two things. - the changes are a tape that logs what you are doing and right now the system is not done to accept not to log So I imagine that you can remove the changes file but then do not compile code. - I do not get the "so I can't have changes file bundled with the tool." you do not have a bat or script that launches the application that is somewhere in a folder where you have the vm and the image? you could have the changes file there. We are interested in your scenario because last year I got a guy working on making pharo silent. I do not know if its changes got integrated into pharo. This is really something that we want to have. - having sources and changes in a specific location - having no source and no changes (even if it means lose your code). - ... Stef On Tue, Jun 6, 2017 at 8:14 PM, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: > Sorry to bring this up again. But it turns out that I had the image > directory writable by myself, so it created a new changes file. That's why > Pharo didn't complain about missing changes file. When I removed write > permission in the tool installation, Pharo gives error for not having or not > able to write to changes file. > > I guess I'm back to the problem how to deploy a tool without changes file. I > have multiple users that will be running this tool, which is installed in a > centralized site, so I can't have changes file bundled with the tool. > > On Mon, Jun 5, 2017 at 5:47 PM, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: >> >> I had my changes and sources files in the bundle but has their write >> permission removed, and that causes the error. Simply deploying the tool >> without the changes file seems to fix it. Pharo5 doesn't complain if the >> changes file isn't there. >> >> However, without the sources file, I get this warning that pharo cannot >> locate the sources file. Including the sources file in the deployed tool is >> fine with me. >> >> So, I think that's my solution. Thanks! >> >> >> On Mon, Jun 5, 2017 at 5:07 PM, Andreas Sunardi <a.sunardi(a)gmail.com> >> wrote: >>> >>> I found this StackOverflow question: >>> >>> https://stackoverflow.com/questions/14737695/is-it-possible-to-deploy-a-pha… >>> >>> and this older forum thread: >>> >>> https://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg21170.h… >>> >>> I'm using Pharo5.0 and neither of these options is available anymore. >>> What is the new way to do this? >>> >>> -- >>> Andreas Sunardi >> >> >

June 6, 2017

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

by Stephan Eggermont

On 06/06/17 17:11, Esteban Lorenzano wrote: > Dear World, > > The time has come for Pharo 6.0! Yes! Well done! Stephan

June 6, 2017

Re: [Pharo-users] is it related to Freetype or Athens?

by Stephane Ducasse

Hilaire If I remember correcly, there is a bug in cairo so igor was sometimes forced to change the font size multiplying a little to force the plugin to react. Stef On Tue, Jun 6, 2017 at 7:33 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > Hi there, > > A Dr. Geo user on Ubuntu 64bits 16.04 got that buggy rendering of the > canvas, then on some situation the rendering completely stop on a red > screen, with a stack showing may be a zero divide error. I did not get > access to the PharoDebog yet. > > Fonts on the screenshot is not right too. Could it be a mixed problem > between FreeType and Cairo? Any first though on the issue welcome. > > Given the fact Dr. Geo is still based on Pharo3 and it works pretty fine > on my old Ubuntu 12.07 derived system, it may be time to port the newer > Pharo6. > > Congrats for the Pharo6 release. > > Hilaire > > -- > Dr. Geo > http://drgeo.eu >

June 6, 2017

Re: [Pharo-users] How to use uFFI with String

by Stephane Ducasse

Hi ben Yes I changed it :) Stef On Mon, May 29, 2017 at 10:16 AM, Ben Coman <btc(a)openinworld.com> wrote: > On Mon, May 29, 2017 at 7:24 AM, horrido <horrido.hobbies(a)gmail.com> wrote: >> I don't use GitHub. I've never used GitHub. I don't know how to use GitHub. >> >> I looked at making a pull request and I was totally stymied. "Clueless" >> doesn't even begin to describe how I felt. > > Everyone starts there. Its a useful skill to have, so if you are > interested to learn, here's a quickstart guide... > (Note since its a text file, we are shortcutting so you don't even > need git on your local machine) > 1. Click on this link. > https://github.com/SquareBracketAssociates/UpdatedPharoByExample/blob/maste… > 2. Click the <Fork> button in the top tight, then browse to > "Morphic.pier" in your fork. > 3. To the right of the <Raw/Blame/History> buttons, click the <Pencil> > button to edit the file. > 4. After editing, at the bottom select "Create a new branch for this > commit and start a pull request" > and enter commit title, comment and new-branch-name to reflect your > contribution. Click <Propose file change> > 5. Now looking at "Open a pull request", this is issuing a PR to your > own fork. We need to change to the upstream fork. At the top click > on "forked from SquareBracketAssociates/UpdatedPharoByExample" . > 6. Under "Your recently pushed branches" click <Compare & pull request> > 7. Check... > base fork: SquareBracketAssociates/UpdatedPharoByExample > base: master > head fork: YourName/UpdatedPharoByExample > compare: your new-branch-name > Review the diff, enter PR title and comment, then click <Create pull request>. > > If you have problems, try to catch me on Discord... > https://discord.gg/dKv4qR/KCKQSSt > > cheers -ben > > P.S. @Stef, btw, it looks like "the guidelines for contributing" is > out of date... > https://github.com/SquareBracketAssociates/UpdatedPharoByExample/blob/maste… > "This is a test to see if it makes sense to convert PharoByExample > into pier format." > > >> >> >> Ben Coman wrote >>> On Sat, May 27, 2017 at 9:15 PM, horrido < >> >>> horrido.hobbies@ >> >>> > wrote: >>>> Yes, I did. I found it difficult to understand. It would be nice to have >>>> some >>>> clear examples in the documentation, for example, really simple and >>>> common >>>> situations such as a C function returning an integer in a >>>> passed-by-reference argument. >>>> >>>> Speaking of documentation, in "Pharo by Example 50," I found this >>>> statement: >>>> >>>>> (Recall that you should set halosEnabled in the Preferences >>>> browser.) >>>> >>>> However, nowhere else in the book is there any reference to halosEnabled >>>> or >>>> Preferences browser. >>> >>> Nice pick up. Now in Settings (in a fresh 60473 image), filtering on >>> "halo" shows only: >>> * Cycle both directions >>> * Encloses fullbounds >>> * Exhibits bounds >>> so the comment seems irrelevant >>> >>> and #halosEnabled & #halosEnabled: each have one implementor class-side of >>> Morph >>> with one sender from MorphTest each, and one sender from Morph>>addHalo: >>> >>> and "Morph halosEnabled" ==> true, so the statement seems unnecessary. >>> Would you like to contribute a pull request removing it? >>> https://github.com/SquareBracketAssociates/UpdatedPharoByExample/blob/maste… >>> >>> >>>> Did you guys forget and leave out a chunk of the book? >>> >>> Its an evolutionary book originally from Squeak. It could well be >>> that some parts of the book have been cleaned >>> better than others to match Image changes. Thanks for reporting, and >>> even better if you can correct it. >>> >>> cheers -ben >> >> >> >> >> >> -- >> View this message in context: http://forum.world.st/How-to-use-uFFI-with-String-tp4947890p4948512.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >

June 6, 2017

Re: [Pharo-users] How to deploy headless app without changes and source files?

by Andreas Sunardi

Sorry to bring this up again. But it turns out that I had the image directory writable by myself, so it created a new changes file. That's why Pharo didn't complain about missing changes file. When I removed write permission in the tool installation, Pharo gives error for not having or not able to write to changes file. I guess I'm back to the problem how to deploy a tool without changes file. I have multiple users that will be running this tool, which is installed in a centralized site, so I can't have changes file bundled with the tool. On Mon, Jun 5, 2017 at 5:47 PM, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: > I had my changes and sources files in the bundle but has their write > permission removed, and that causes the error. Simply deploying the tool > without the changes file seems to fix it. Pharo5 doesn't complain if the > changes file isn't there. > > However, without the sources file, I get this warning that pharo cannot > locate the sources file. Including the sources file in the deployed tool is > fine with me. > > So, I think that's my solution. Thanks! > > > On Mon, Jun 5, 2017 at 5:07 PM, Andreas Sunardi <a.sunardi(a)gmail.com> > wrote: > >> I found this StackOverflow question: >> https://stackoverflow.com/questions/14737695/is-it-possible- >> to-deploy-a-pharo-image-without-changes-and-sources-files/14747328 >> >> and this older forum thread: >> https://www.mail-archive.com/pharo-project@lists.gforge.inri >> a.fr/msg21170.html >> >> I'm using Pharo5.0 and neither of these options is available anymore. >> What is the new way to do this? >> >> -- >> Andreas Sunardi >> > >

June 6, 2017

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

by Stephane Ducasse

Tx torsten. New space is opening to us :) On Tue, Jun 6, 2017 at 7:49 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Dear friends, > > Yes - really an impressive release. With many cleanups and new treasures in the image - but also many > shiny new/updated external packages and projects (like Roassal, Polymath, Calypso browser, ... to name just a few). > > Thanks to all who helped - especially to the ones who cared and also worked on the not so interesting but > often hard to solve issues or boring but necessary parts or infrastructure. > > The new git integration in Pharo and the included Iceberg tool will allow us to work with services > like GitHub, GitLab, BitBucket - even own local git servers (for instance setups using Gogs.io). We can now manage > project resources beside code, commit several packages at once and branch and merge as necessary. > This really rocks! > > Many thanks also to all the contributors of the OpenSmalltalk initiative - it is also impressive > how much progress was done on VM side. Also thanks to the ones writing new books, articles and tutorials > so other can learn and enjoy such a fantastic dynamic and lively system. > > We still have a way to go for Pharo 7 and onwards. I'm eager to play with the new git based development process and > interested on how we can manage to build our future Pharo based on the bootstrap efforts. > > Even when not finally there ... step by step it goes! > > Bye > T. > > > > Gesendet: Dienstag, 06. Juni 2017 um 17:11 Uhr > Von: "Esteban Lorenzano" <estebanlm(a)gmail.com> > An: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org>, "Pharo Development List" <pharo-dev(a)lists.pharo.org>, members-consortium(a)pharo.org, "Seaside - general discussion" <seaside(a)lists.squeakfoundation.org>, "list ESUG Mailing" <esug-list(a)lists.esug.org> > Betreff: [Pharo-dev] [ANN] Pharo 6.0 released! > > 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[http://pharo.org/download] > Learn Pharo: http://pharo.org/documentation[http://pharo.org/documentation] >

June 6, 2017

[Pharo-dev] [ANN] Pharo 6.0 released!

by Torsten Bergmann

Dear friends, Yes - really an impressive release. With many cleanups and new treasures in the image - but also many shiny new/updated external packages and projects (like Roassal, Polymath, Calypso browser, ... to name just a few). Thanks to all who helped - especially to the ones who cared and also worked on the not so interesting but often hard to solve issues or boring but necessary parts or infrastructure. The new git integration in Pharo and the included Iceberg tool will allow us to work with services like GitHub, GitLab, BitBucket - even own local git servers (for instance setups using Gogs.io). We can now manage project resources beside code, commit several packages at once and branch and merge as necessary. This really rocks! Many thanks also to all the contributors of the OpenSmalltalk initiative - it is also impressive how much progress was done on VM side. Also thanks to the ones writing new books, articles and tutorials so other can learn and enjoy such a fantastic dynamic and lively system. We still have a way to go for Pharo 7 and onwards. I'm eager to play with the new git based development process and interested on how we can manage to build our future Pharo based on the bootstrap efforts. Even when not finally there ... step by step it goes! Bye T. Â Gesendet:Â Dienstag, 06. Juni 2017 um 17:11 Uhr Von:Â "Esteban Lorenzano" <estebanlm(a)gmail.com> An:Â "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org>, "Pharo Development List" <pharo-dev(a)lists.pharo.org>, members-consortium(a)pharo.org, "Seaside - general discussion" <seaside(a)lists.squeakfoundation.org>, "list ESUG Mailing" <esug-list(a)lists.esug.org> Betreff:Â [Pharo-dev] [ANN] Pharo 6.0 released! 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[http://pharo.org/download] Learn Pharo: http://pharo.org/documentation[http://pharo.org/documentation]

June 6, 2017

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

by Hilaire

Congratulations ! Le 06/06/2017 Ã 17:11, Esteban Lorenzano a Ã©crit : > The time has come for Pharo 6.0! > -- Dr. Geo http://drgeo.eu

June 6, 2017

is it related to Freetype or Athens?

by Hilaire

Hi there, A Dr. Geo user on Ubuntu 64bits 16.04 got that buggy rendering of the canvas, then on some situation the rendering completely stop on a red screen, with a stack showing may be a zero divide error. I did not get access to the PharoDebog yet. Fonts on the screenshot is not right too. Could it be a mixed problem between FreeType and Cairo? Any first though on the issue welcome. Given the fact Dr. Geo is still based on Pharo3 and it works pretty fine on my old Ubuntu 12.07 derived system, it may be time to port the newer Pharo6. Congrats for the Pharo6 release. Hilaire -- Dr. Geo http://drgeo.eu

June 6, 2017

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

by Raffaello Giulietti

> On Tue, Jun 6, 2017 at 11:11 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Dear World, > > The time has come for Pharo 6.0! > Nice! Thanks to all contributors. Greetings Raffaello

June 6, 2017

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

by Sven Van Caekenberghe

> On 6 Jun 2017, at 18:18, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Tue, Jun 6, 2017 at 11:11 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Dear World, > > The time has come for Pharo 6.0! > > Woot! > cheers -ben Super. Thank you all.

June 6, 2017

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

by Ben Coman

On Tue, Jun 6, 2017 at 11:11 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Dear World, > > The time has come for Pharo 6.0! > Woot! cheers -ben

June 6, 2017

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

by Norbert Hartl

It is really great! Thank you all! I'm glad the struggles with 32 bit libraries will have an end for normal deployments. The same goes for uFFI that makes things so much easier. And of course the rest of the list of changes is impressive as always. Glad to be part of this community. You rock! Norbert > Am 06.06.2017 um 17:11 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > 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 > > <Pharo6.jpeg> > > 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… <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 <http://pharo.org/download> > Learn Pharo: http://pharo.org/documentation <http://pharo.org/documentation>

June 6, 2017

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

by Ben Coman

On Tue, Jun 6, 2017 at 9:11 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > Thanks for the detailed answer ben :) > > I will try to clarify a little: the question is how to loosely wire > objects, such as MovieLister to MovieFinder, so that changes in the wiring > can be made without effort. In Java, people use DI containers and xml files > or annotations to provide the wiring configuration, which is easy to switch > entirely. For example, I could have a xml file for production code and > another for testing purposes. > > Also, another advantage is that the container takes care of ordering > object creation for me. For example, if the object A, B and C needed to be > injected on the object Y, I just have to declare each one of those objects > on the configuration file, the container arranges the creation order for > me. > I don't see what is special about this. You can easily arrange instance creation order with methods on the class-side of your domain classes. Indeed, the GTTools are set up to work with in-Image sample data. Look at implementors of #sample and #example. There was quite some bike-shedding over the naming convention (and I forget the final result), but hopefully it provide the general idea... http://forum.world.st/a-request-to-change-the-meaning-of-lt-example-gt-prag… http://forum.world.st/lt-example-gt-lt-examplar-gt-td4911728i20.html http://forum.world.st/Existing-lt-script-gt-lt-example-gt-pragmas-and-new-G… > > I started, however, to question DI as a valid mechanisms because of it's > complexities and other problems. The article from Fowler provides the > service locator as an alternative which seems to me much simpler and > completely fine solution for the problem. > If it seems suitable, then to quote Nike, just do it ;) > So, to answer you question "Is it any more complicated than that?": In > the DI approach, yes it can be, but I don't think so in the service locator > approach. > > I am asking here because I wanted to know how people from Smalltalk deal > with this problem. As it seems there is no standard approach, nor this is > perceived as a problem... > DI or Service Locator are both "implementations" of your need. Can we take step backward to see what is your need? To kick off, I hazard a guess at some possible needs... 1. To switch between configurations to use production data and test data ? 2. To make this switch during CI testing and production deployment ? 3. To switch from the command line ? 4. Want the configuration to editable remotely? e.g. from a text editor? ? ... > You think it is enough to do the wiring by hand? > I'm having trouble understanding this "by hand" concept. Don't you create the xml configuration file by hand? You can just as easily > It is ok to use a service locator approach? Or wouldn't you care about > that? > If it works, its okay. So very generally, I'd avoid starting with any external test data, so as to not distract myself by that implementation. I'd copy-paste some test data into the class-side-methods of the domain classes and hack some instance creation code around them. Build your first tests around those. Then later, consolidate them via an InImageTestData object that you'll later replace with ExternalTestData > > > but I'll add, it was so much simpler to understand without all that Java >> typing boiler plate. > > > Yeah, that's for sure! I am just used to read Java code. > > []s, > Vitor > > > As an aside, try evaluting "Smalltalk tools inspect" and debugging "Smalltalk tools browser open" cheers -ben

June 6, 2017

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

by Offray Vladimir Luna CÃ¡rdenas

Thanks community and specially Esteban! Happy of this release and put my two pesos into this! Congrats, Offray On 06/06/17 10:11, Esteban Lorenzano 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 6, 2017

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

by Attila Magyar

I don't think using a DI container worth the effort. They add lots of complexities and solve very little. For some reason DI containers became very popular in the Java world, but if you take a look at other programming communities you'll realize that many people are perfectly happy without using these containers. Using DI and using a DI container is orthogonal. As you also said you can just pass dependencies to objects to achieve loose coupling. Yes, you have to do this manually but what's the big deal? We're talking about code with cyclomatic complexity of 1. Calling a constructor is not a problem that need to be solved. Using an external XML configuration to describe object wiring is the worst idea ever. Here is an article about using plain old object composition to do DI http://blog.davidpeterson.co.uk/2011/01/object-oriented-example.html Some more thoughts about the problems associated with DI containers: http://www.natpryce.com/articles/000783.html http://higherorderlogic.com/2011/07/is-dependency-injection-like-facebook -- View this message in context: http://forum.world.st/Wiring-objects-IoC-and-Service-Locator-tp4949280p4949… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 6, 2017

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

by Tudor Girba

Great work! Doru > On Jun 6, 2017, at 5:11 PM, 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 > > <Pharo6.jpeg> > > 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 -- www.tudorgirba.com www.feenk.com âSoftware has no shape. Actually, it has no one shape. It has many."

June 6, 2017

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

by volkert

Thank you Estaban for all your hard work. Volkert Am 06.06.2017 um 17:11 schrieb Esteban Lorenzano: > 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 6, 2017

[ANN] Pharo 6.0 released!

by Esteban Lorenzano

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 6, 2017

Re: [Pharo-users] Bloc/Brick/Spec

by Ben Coman

On Tue, Jun 6, 2017 at 9:20 AM, Brad Selfridge <bsselfridge(a)gmail.com> wrote: > I'm confused. I see the latest news and documentation about Bloc. Is Brick > now dead and Bloc the default? I thought Brick was a layer on top of Bloc > and Spec was layer on top on Brick? What is the direction now? > > Brad Selfridge > > Can you link to this latest news? cheers -ben

June 6, 2017

Re: [Pharo-users] How to use uFFI with String

by Pierce Ng

On Sat, May 27, 2017 at 06:15:47AM -0700, horrido wrote: > Yes, I did. I found it difficult to understand. It would be nice to have some > clear examples in the documentation, for example, really simple and common > situations such as a C function returning an integer in a > passed-by-reference argument. I've written such a thing: https://github.com/PierceNg/libffidemo See these functions in the C library: int get_by_filling_pointer(demo_thing *pthing, int *pvalue) int get_by_returned_value(demo_thing *pthing) Two follow-up blog posts: http://www.samadhiweb.com/blog/2016.03.12.demoffi.html http://www.samadhiweb.com/blog/2016.03.17.demoffi.html I intend to modify my blog posts to contribute to the booklet, sometime in this month of June. Pierce

June 6, 2017

Re: [Pharo-users] Morphic or forking bug?

by Sven Van Caekenberghe

You are mixing 3 different aspects: - how to update a UI from a background process - how to maintain a background process over image save/open - how to communicate between the 2 Safe UI updating has to happen using #step or #defer: and should be quick/short as not to block the UI. Although processes survive over image save/open (provided they did not become garbage), this is dangerous as they come up immediately (too soon) and will probably hold external resources (files/sockets/..) that will have changed (and result in a crash). It is better to manage this explicitly using #startUp and #shutDown. Communication between the 2 should be protected using a semaphore. Here is an example of a 'file watcher', a little window that shows the first line of a specific file, updating it every 3 seconds (silly and too resource intensive, it is just a demo). You can edit the file manually to modify the contents of the first line and see it being picked up in Pharo (within 3 seconds). Here is the code as 1 file/class in '_UnpackagedPackage': See the class side #initialize for the #startUp and #shutDown registration, sent to all instances as #start and #stop (a bit rude but good enough for the demo). Instance side #initialize sets up the mutex that gets used in the #firstLine and #firstLine: accessors. The actual process is in #run which calls #updateFirstLine The UI updating is in #step which calls #updateFileLineDisplay Subscribing to MorphDeleted via the announcer allows for the process to stop when the window closes. The file watcher window and process survive an image save/open (i.e. they keep on working). HTH, Sven > On 3 Jun 2017, at 15:44, horrido <horrido.hobbies(a)gmail.com> wrote: > > Okay, let me explain my application... > > It displays a Morphic window containing lines of information that are > updateable in real time on a periodic basis. As I indicated in the original > post, the code skeleton is basically: > > initA > a := ((StringMorph contents: '####') color: Color white) position: (0@0). > m addMorph: a > > initialize > f := Form fromFileNamed: 'hot_air_balloon_mysticmorning.jpg'. > m := ImageMorph new. > m form: f. > self initA. > m openInWindowLabeled: 'Cranky'. > delay := (Delay forSeconds: 5). > [ [ true ] whileTrue: [ a contents: 0 asString. delay wait ] fork > > Imagine that #initA creates many such StringMorphs, each displaying a > different kind of information. > > In the endless loop, imagine that instead of 'a contents: 0 asString', I'm > updating all of the StringMorphs I created in #initA. > > The need to do this in a separate thread is to prevent Pharo from being > completely frozen during the 'delay wait', which is practically all the > time! > > Now, I did try Hilaire's suggestion to use Morphic's step protocol instead. > But in my test scenario of closing the app/saving and exiting the > image/restarting the image, repeatedly (in may take 10-20 times), it still > causes the occasional segmentation fault. > > So if the problem is updating a structure in the main thread from another > process, then why did Hilaire's suggestion not solve the problem? > > It seems to me, then, either way, it's an issue of multithreading...whether > my way or Hilaire's way. > > > > Sven Van Caekenberghe-2 wrote >> Hi Horrido, >> >> It is very hard to follow what you are exactly doing or trying to do. >> >> Here is the simplest example I can think of that updates something in >> Morphic on a regular basis. >> >> StringMorph subclass: #MyClock >> instanceVariableNames: '' >> classVariableNames: '' >> package: '_UnpackagedPackage' >> >> MyClock>>#initialize >> super initialize. >> self updateClock >> >> MyClock>>#step >> self updateClock >> >> MyClock>>#updateClock >> self contents: Time now printString >> >> MyClock class>>#open >> "self open" >> >> ^ self new openInWindow >> >> This inherits #stepTime as 1 second. If I open such a window and save my >> image, it is still there when the image is restarted, with the clock still >> working. >> >> Updating (data structures in) the main UI process from another process is >> dangerous. Saving such constructs is even more dangerous. >> >> HTH, >> >> Sven >> >>> On 2 Jun 2017, at 15:54, horrido < > >> horrido.hobbies@ > >> > wrote: >>> >>> Sorry, I could be mistaken. I just checked my notes. The *0 asString* >>> test >>> failed once, but I've not been able to replicate it. I might've been >>> working >>> with an unclean image. >>> >>> So perhaps it is related to Morphic, after all. >>> >>> >>> horrido wrote >>>> Yup, they all fail. Interesting that >>> * >>>> 0 asString >>> * >>>> fails. This means it has NOTHING to do with Morphic (or Morphic being >>>> thread-unsafe). >>>> >>>> Ben Coman wrote >>>>> On Wed, May 31, 2017 at 10:23 PM, horrido < >>> >>>>> horrido.hobbies@ >>> >>>>> > wrote: >>>>> >>>>> Can you try a few other variations... >>>>> [ [ true ] whileTrue: [ 0 asString. delay wait ] fork. >>>>> [ [ true ] whileTrue: [ a contents: '0'. delay wait ] fork. >>>>> [ [ true ] whileTrue: [ a contents: '0'. ] forkAt: 20. >>>>> >>>>> cheers -ben >>> >>> >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Morphic-or-forking-bug-tp4948727p4948984.html >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > > -- > View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4949166.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 6, 2017

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

by Vitor Medina Cruz

Thanks for the detailed answer ben :) I will try to clarify a little: the question is how to loosely wire objects, such as MovieLister to MovieFinder, so that changes in the wiring can be made without effort. In Java, people use DI containers and xml files or annotations to provide the wiring configuration, which is easy to switch entirely. For example, I could have a xml file for production code and another for testing purposes. Also, another advantage is that the container takes care of ordering object creation for me. For example, if the object A, B and C needed to be injected on the object Y, I just have to declare each one of those objects on the configuration file, the container arranges the creation order for me. I started, however, to question DI as a valid mechanisms because of it's complexities and other problems. The article from Fowler provides the service locator as an alternative which seems to me much simpler and completely fine solution for the problem. So, to answer you question "Is it any more complicated than that?": In the DI approach, yes it can be, but I don't think so in the service locator approach. I am asking here because I wanted to know how people from Smalltalk deal with this problem. As it seems there is no standard approach, nor this is perceived as a problem... You think it is enough to do the wiring by hand? It is ok to use a service locator approach? Or wouldn't you care about that? but I'll add, it was so much simpler to understand without all that Java > typing boiler plate. Yeah, that's for sure! I am just used to read Java code. []s, Vitor On Mon, Jun 5, 2017 at 9:46 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Tue, Jun 6, 2017 at 5:11 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> Tx ben. >> When I see all this complexity for something that looks not that complex: >> I prefer to pass the class and get done. >> May be I missed something obvious... but when I see something too complex >> I start to get worried. >> >> I think that thinking about the contract between classes at runtime is >> important and to me a MovieLister should be using at runtime and instance >> of the *Finder* >> Now needing an extra class just to set this should really be evaluated >> with the tradeoff: "flexibility win" (our simple solution is still really >> flexible - I decide when I want to pass the correct finder) vs. the code >> and conceptual bloat. >> >> >> I'm happy not to face the hyper super over engineering of Java >> "solutions". >> >> I like the "Of course this just shifts the burden a tad, we still have >> to get the locator into the lister" >> but the solution is super simple let us use another "Singleton and a >> Factory...." :) >> >> Stef >> >> On Mon, Jun 5, 2017 at 8:43 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >>> >>> >>> On Tue, Jun 6, 2017 at 1:26 AM, Vitor Medina Cruz <vitormcruz(a)gmail.com> >>> wrote: >>> >>>> Thanks for the answer Ben and Stephane. >>>> >>>> I already read A Mentoring Course on Smalltalk, Valloud, there is >>>> nothing there I could use in this case :( . I will look after for The >>>> Design Patterns Smalltalk Companion. Most of the sources provided I already >>>> know of or went in the same lines lines of what I have already found. >>>> >>>> About TDD, I am experienced with the discipline and have tested it on >>>> Pharo living system already, but I could not understand how this is related >>>> with object wiring, DI and service locator. >>>> >>> >>> I guess I don't properly understand your need and those topics. That >>> was my quick pass. Now if I take the time to actually read Fowler's long >>> article >>> >>> "the inversion is about how they lookup a plugin implementation ... to >>> ensure that any user of a plugin follows some convention that allows a >>> separate assembler module to inject the implementation into the lister." >>> >>> "The basic idea of the Dependency Injection is to have a separate >>> object, an assembler, that populates a field in the lister class with an >>> appropriate implementation for the finder interface. There are three main >>> styles of dependency injection. The names I'm using for them are >>> Constructor Injection, Setter Injection, and Interface Injection." >>> >>> Now there was too much syntactical noise in those Java examples for me >>> to think clearly, so I converted them all to Smalltalk. >>> >>> >>> ##CONSTRUCTOR INJECTION >>> >>> Object subclass: MovieLister >>> instanceVariables: 'finder' >>> >>> >>> MovieLister class >> newWith: aFinder >>> ^ self basicNew initializeWith: aFinder >>> >>> MovieLister >> initializeWith: aFinder >>> finder := aFinder >>> >>> >>> ColonMovieFinder class >> newWith: aFilename >>> ^ self basicNew initializeWith: aFilename >>> >>> ColonMovieFinder >> initializeWith: aFilename >>> filename := aFilename. >>> >>> >>> ConstructorInjectionContainer >> new >>> container := DefaultContainer new. "the article doesn't specify >>> where this comes from" >>> finderParams := ConstantParameter newWith: 'movies1.txt'. >>> container registerComponentInterface: MovieFinderInterface >>> implementation: ColonMovieFinder >>> params: finderParams. >>> container registerComponentImplementation: MovieLister >>> ^container >>> >>> to be used like this... >>> ConstructorInjectionTest >> testWithContainer >>> container := ConstructorInjectionContainer new. >>> lister := container getComponentInstance( MovieLister ). >>> movies = lister moviesDirectedBy: 'Sergio Leone'. >>> self assert: (movies includes: 'Once Upon a Time in the West') >>> >>> The article poorly defines registerComponentXXX: or getComponentInstance: >>> methods, so I don't dwell on them. I presume its little relevant to the >>> main theme. >>> >>> >>> ##SETTER INJECTION >>> >>> MovieLister >> setFinder: aFinder >>> finder := aFinder. >>> >>> ColonMovieFinder >> setFilename: aFilename >>> filename := aFilename. >>> >>> SetterInjectionTest >> testWithConfigurationFile >>> ctx := SomeXmlApplicationConfiguration on: 'config.xml'. >>> lister := ctx getConfigOf: 'MovieLister'. >>> movies = lister moviesDirectedBy: 'Sergio Leone'. >>> self assert: (movies includes: 'Once Upon a Time in the West') >>> >>> >>> ##INTERFACE INJECTION >>> >>> MovieLister >> injectFinder: aFinder >>> finder := aFinder >>> >>> ColonMovieFinder >> injectFilename: aFilename >>> filename := aFilename >>> >>> InterfaceInjectionTest >> configureContainer >>> container := InterfaceInjectionContainer new. >>> self registerComponents. >>> self registerInjectors. >>> container start. >>> >>> InterfaceInjectionTest >> registerComponents >>> container registerComponent: 'MovieLister' with: MovieLister. >>> container registerComponent: 'MovieFinder' with: ColonMovieFinder. >>> >>> InterfaceInjectionTest >> registerInjectors >>> container registerInjector: Injector with: (container lookup: >>> 'MovieFinder'). >>> container registerInjector: InjectorFinderFilename with: >>> FinderFilenameInjector new. >>> >>> ColonMovieFinder >> inject: anObject >>> anObject injectFinder: self. >>> >>> FinderFilenameInjector >> inject: anObject >>> anObject injectFilename: 'movies1.txt'. >>> >>> InterfaceInjectionTester >> testInterface >>> self configureContainer. >>> lister := container lookup: 'MovieLister'. >>> movies = lister moviesDirectedBy: 'Sergio Leone'. >>> self assert: (movies includes: 'Once Upon a Time in the West') >>> >>> The article doesn't define InterfaceInjectionContainer, but I guess it >>> could look like this... >>> >>> InterfaceInjectionContainer >> registerComponent: componentName with: >>> aComponent >>> container ifNil: [ container := Dictionary new]. >>> container at: componentName put: aComponent >>> >>> InterfaceInjectionContainer >> lookup: componentName >>> ^ container at: componentName >>> >>> >>> ##SERVICE LOCATOR >>> >>> "The basic idea behind a service locator is to have an object that knows >>> how to get hold of all of the services that an application might need. So a >>> service locator for this application would have a method that returns a >>> movie finder when one is needed. Of course this just shifts the burden a >>> tad, we still have to get the locator into the lister" >>> >>> MovieLister >> initialize >>> finder := ServiceLocator movieFinder. >>> >>> >>> Object subclass: ServiceLocator >>> instanceVariable: 'movieFinder' >>> classVariable: 'SoleInstance' >>> >>> ServiceLocator class >> load: aServiceLocator >>> SoleInstance := aServiceLocator >>> >>> ServiceLocator class >> soleInstance >>> ^ SoleInstance >>> >>> ServiceLocator class >> movieFinder >>> ^ self soleInstance movieFinder >>> >>> ServiceLocator >> movieFinder >>> ^movieFinder >>> >>> >>> ServiceLocatorTest >> configure >>> ServiceLocator load: (ServiceLocator newWith: (ColonMovieFinder >>> newWith: 'movies1.txt')) >>> >>> >>> ServiceLocator class >> newWith: aMovieFinder >>> ^ self basicNew initializeWithFinder: aMovieFinder >>> >>> ServiceLocator >> initializeWithFinder: aMovieFinder >>> movieFinder := aMovieFinder >>> >>> >>> ServiceLocatorTest >> testSimple >>> self configure. >>> lister := MovieLister new. >>> movies = lister moviesDirectedBy: 'Sergio Leone'. >>> self assert: (movies includes: 'Once Upon a Time in the West') >>> >>> So it seems that a service locator is just a Singleton pattern having a >>> class variable for each service of interest ?? >>> >> > It was late and I mispoke here, of course this should have said... > * a Singleton pattern having an instance variable for each service of > interest > * a Singleton pattern having a getter method (with hidden implementation) for > each service of interest > > > >> So in good faith** I ask... "Is it any more complicated than that?" >>> >>> **Since its taken me a couple of hours to convert the Java to this point >>> so I stopped reading to seek your feedback. >>> >> > but I'll add, it was so much simpler to understand without all that Java > typing boiler plate. > > cheers -ben > > >> Is that enough insight to adapt to your needs, or is there something else >>> further down the article that invalidates my analysis? >>> >>> >>> >>> >>> >>>> >>>> From ben: >>>> >>>> "I'm not really familiar with IoC or DI patterns, so just taking your >>>>> example at face value, in Pharo I'd do... >>>>> >>>>> MovieLister>>moviesDirectedBy: director >>>>> allMovies := finder allMovies. >>>>> ^ allMovies select: [ :movie | movie getDirector = director ]. >>>>> "although typically #getDirector would be renamed #director" >>>>> >>>>> MovieLister>>finder: movieFinder >>>>> finder := movieFinder. >>>>> >>>>> to be used like this... >>>>> lister := MovieLister new finder: (ColonDelimitedMovieFinder on: >>>>> 'movies1.txt'). >>>>> movies := lister moviesDirectedBy: 'Tarantino'." >>>> >>>> >>> >>> So per Fowler, the above is equivalent to "Setter Injection with Spring" >>> >>> >>>> >>>> and Stephane: >>>> >>>> Why don't you simply pass the class and use that class in your >>>>> MovieLister? >>>>> >>>>> MovieLister new >>>>> finderClass: MySuperCoolFinderClass >>>>> >>>>> ... >>>>> MovieLister finder >>>>> finderClass new ..... >>>>> >>>>> What is wrong with that. >>>> >>>> >>>> That was what I meant when I said: "I know that in Smalltalk I can >>>> make MovieLister to receive, upon construction, a class representing >>>> MovieFinder and call it construction message.". The code I had in mind >>>> is a bit of mix from the one provided by you both: >>>> >>>> MovieLister>>moviesDirectedBy: director >>>> allMovies := finder allMovies. >>>> ^ allMovies select: [ :movie | movie getDirector = director ]. >>>> "although typically #getDirector would be renamed #director" >>>> >>>> MovieLister>>finder: aMovieFinderBuilder >>>> finder := aMovieFinderClass new. >>>> >>>> to be used like this... >>>> lister := MovieLister new finder: (ColonDelimitedMovieFinder >>>> builderOn: 'movies1.txt'). >>>> movies := lister moviesDirectedBy: 'Tarantino'." >>>> >>>> But that means I will have to wire dependencies by hand whenever I >>>> create a MovieLister and seek through code when and if those dependencies >>>> change. When there are lot's of dependencies it's is a considerable and >>>> tedious work. Let's see an image from Fowlers article: >>>> >>>> [image: Inline image 1] >>>> >>>> In this case, the service locator provides me with an instance and I >>>> configure the instance in the assembler, the scheme is alike for an IoC, >>>> and that would mean my implementation could be like this: >>>> >>>> >>>> MovieLister>>moviesDirectedBy: director >>>> allMovies := finder allMovies. >>>> ^ allMovies select: [ :movie | movie getDirector = director ]. >>>> "although typically #getDirector would be renamed #director" >>>> >>>> MovieLister>>initialize >>>> finder := ServiceLocator locate: FinderClass <--- This would >>>> bring the instance of finder class configured by the assembler >>>> >>> >>> No, like this... >>> finder := ServiceLocation movieFinder. >>> >>> Now if you want to store a class rather than an instance as I did higher >>> up, you just do this... >>> >>> Object subclass: ServiceLocator >>> instanceVariable: 'movieFinderClass' >>> classVariable: 'SoleInstance' >>> >>> ServiceLocator class >> movieFinder >>> ^ self soleInstance movieFinderClass new >>> >>> >>> >>>> >>>> >>>> to be used like this... >>>> lister := MovieLister new. >>>> movies := lister moviesDirectedBy: 'Tarantino'." >>>> >>>> and the assembler: >>>> >>>> Assember class>>configure: >>>> aMap put: (ColonDelimitedMovieFinder builderOn: 'movies1.txt') at: >>>> FinderClass >>>> >>> >>> Assembler class>>configure >>> ServiceLocator load: >>> (ServiceLocator new >>> movieFinder: (ColonMovieFinder newWith: 'movies1.txt') >>> otherService: MyCustomService new) >>> >>> >>>> >>>> My assembler and service locator could be even more elaborated, and >>>> provide a different MovieFinder in test scope, for different classes or >>>> wharever. >>>> >>> >>> Really, the test should not be updating the class variable global like >>> this... >>> ServiceLocatorTest >> configure >>> ServiceLocator load: (ServiceLocator newWith: (ColonMovieFinder >>> newWith: 'movies1.txt')) >>> >>> you probably want something like (its rough but shows the point...) >>> Object subclass: #MovieLister >>> instanceVariables: 'serviceLocator' >>> >>> MovieLister >> initialize >>> serviceLocator ifNil: [ serviceLocator := ServiceLocator >>> soleInstance ]. >>> finder := serviceLocator movieFinder. >>> >>> MovieLister class >> newWithServiceLocator: aServiceLocator >>> ^ (self basicNew initializeWithServiceLocator: aServiceLocator) >>> initialize. >>> >>> MovieLister >> initializeWithServiceLocator: aServiceLocator >>> serviceLocator := aServiceLocator >>> >>> ServiceLocatorTest >> testSimple2 >>> lister := MovieLister newWithServiceLocator: (ServiceLocator >>> newWith: (ColonMovieFinder newWith: 'movies1.txt')). >>> movies = lister moviesDirectedBy: 'Sergio Leone'. >>> self assert: (movies includes: 'Once Upon a Time in the West') >>> >>> >>> cheers -ben >>> >>> >>>> >>>> It is a little convenience for Smalltalk, I will give that, but I was >>>> wandering if there was something alike in Pharo, by your answers I assuming >>>> there is nothing like that. >>>> >>>> >>>> >>>> On Mon, Jun 5, 2017 at 6:41 AM, Stephane Ducasse < >>>> stepharo.self(a)gmail.com> wrote: >>>> >>>>> Why don't you simply pass the class and use that class in your >>>>> MovieLister? >>>>> >>>>> MovieLister new >>>>> finderClass: MySuperCoolFinderClass >>>>> >>>>> ... >>>>> MovieLister finder >>>>> finderClass new ..... >>>>> >>>>> What is wrong with that. >>>>> >>>>> If you do not want to have a reference at runtime to a Finder then you >>>>> need to use announcement and registration. >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> On Sun, Jun 4, 2017 at 11:17 PM, Vitor Medina Cruz < >>>>> vitormcruz(a)gmail.com> wrote: >>>>> > Hello, >>>>> > >>>>> > I would like to know how people in Pharo ecosystem do to deal with >>>>> object >>>>> > wiring, as described by Marting Fowler in >>>>> > https://martinfowler.com/articles/injection.html#FormsOfDepe >>>>> ndencyInjection: >>>>> > >>>>> > "A common issue to deal with is how to wire together different >>>>> elements: how >>>>> > do you fit together this web controller architecture with that >>>>> database >>>>> > interface backing when they were built by different teams with little >>>>> > knowledge of each other." >>>>> > >>>>> > He gives an example, I will leave it in java as it is simple enough >>>>> to >>>>> > understand: >>>>> > >>>>> > "class MovieLister... >>>>> > >>>>> > public Movie[] moviesDirectedBy(String arg) { >>>>> > List allMovies = finder.findAll(); >>>>> > for (Iterator it = allMovies.iterator(); it.hasNext();) { >>>>> > Movie movie = (Movie) it.next(); >>>>> > if (!movie.getDirector().equals(arg)) it.remove(); >>>>> > } >>>>> > return (Movie[]) allMovies.toArray(new >>>>> Movie[allMovies.size()]); >>>>> > >>>>> > }" >>>>> > >>>>> > The question is how to provide the finder object in a decoupled >>>>> matter, a >>>>> > naive approach would be: >>>>> > >>>>> > " private MovieFinder finder; >>>>> > >>>>> > public MovieLister() { >>>>> > finder = new ColonDelimitedMovieFinder("movies1.txt"); >>>>> > >>>>> > }" >>>>> > >>>>> > Which couples the MovieLister to the specific >>>>> ColonDelimitedMovieFinder >>>>> > class. >>>>> > >>>>> > Fowler explains how to decouple using an IoC framework or a Service >>>>> Locator. >>>>> > In Java and .Net IoC is used most of the time. I Googled how this >>>>> problem is >>>>> > approached in Smalltalk/Pharo, and I generally I found answers "that >>>>> is easy >>>>> > to do in Smalltalk, so there is no need of a framework", what I miss >>>>> is a >>>>> > description on *how* to do that: >>>>> > >>>>> > https://stackoverflow.com/questions/243905/smalltalk-and-ioc >>>>> > https://stackoverflow.com/questions/2684326/is-there-a-depen >>>>> dency-injection-framework-for-smalltalk >>>>> > https://stackoverflow.com/questions/243905/smalltalk-and-ioc >>>>> /347477#347477 >>>>> > >>>>> > I know that in Smalltalk I can make MovieLister to receive, upon >>>>> > construction, a class representing MovieFinder and call it >>>>> construction >>>>> > message. As long an object that responds to this message is >>>>> provided, I can >>>>> > create as many derivations I want and the MovieLister will be >>>>> decoupled from >>>>> > the MovieFinder. That way, however, I still have to wire things by >>>>> hand, and >>>>> > I am not sure if this is what I am supposed to do in order to solve >>>>> the >>>>> > decouple problem. >>>>> > >>>>> > Can you explain me how this is done in Pharo? It's is usually wiring >>>>> by >>>>> > hand? Is there a simple construction that deals with the wiring >>>>> problem that >>>>> > I cannot foresee? >>>>> > >>>>> > Thanks in advance, >>>>> > Vitor >>>>> > >>>>> > >>>>> > >>>>> >>>>> >>>> >>> >> >

June 6, 2017