- Pharo-users - lists.pharo.org

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