October 2020 - Pharo-users - lists.pharo.org

Re: Energy efficiency of Pharo/Smalltalk

by Jonathan van Alteren

Hi StÃ©phane, I dug around a little bit regarding this subject and found that people are working to create software that is aware of its energy consumption. There is a Dutch university research group actively involved with this and related topics here:Â http://s2group.cs.vu.nl/mission/. This article might be a good read on the subject:Â https://research.vu.nl/en/publications/a-manifesto-for-energy-aware-software Is this something that could be of interest to Inria or the Pharo project? What do you mean exactly with your last comment? I think that when distinctions in a domain are successfully made explicit at design time, this will improve performance at runtime and thus should also improve energy efficiency. How does that relate to your comment about message passing/branching/polymorphism? Kind regards, Jonathan van Alteren Founding Member | Object Guild B.V. Sustainable Software for Purpose-Driven Organizations jvalteren(a)objectguild.com On 13 Oct 2020, 16:49 +0200, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>, wrote: > > > Hi StÃ©phane, > > > > Thanks for your feedback. I agree that the usefulness of these results is limited. However, if we (Object Guild) want to make a case for energy efficiency, it can help if the language itself can be shown to be efficient as well. > > I do not know what is energy efficient nor how it is measurable. > Now our objectives is that pharo does not burn the batteries when doing nothing and we start to have that with the headless and idle vm. > > > For now, I think the efficiency will need to come from a good object design. > > this would presume that message passing is faster than branching. > And I remember that we had argument with hardware people about our reengineering pattern > on condition to polymorphism > > > > > > Kind regards, > > > > Jonathan van Alteren > > > > Founding Member | Object Guild B.V. > > Sustainable Software for Purpose-Driven Organizations > > > >

Oct. 13, 2020

Re: Energy efficiency of Pharo/Smalltalk

by StÃ©phane Ducasse

> Hi StÃ©phane, > > Thanks for your feedback. I agree that the usefulness of these results is limited. However, if we (Object Guild) want to make a case for energy efficiency, it can help if the language itself can be shown to be efficient as well. I do not know what is energy efficient nor how it is measurable. Now our objectives is that pharo does not burn the batteries when doing nothing and we start to have that with the headless and idle vm. > For now, I think the efficiency will need to come from a good object design. this would presume that message passing is faster than branching. And I remember that we had argument with hardware people about our reengineering pattern on condition to polymorphism > > Kind regards, > > Jonathan van Alteren > > Founding Member | Object Guild B.V. > Sustainable Software for Purpose-Driven Organizations > >

Oct. 13, 2020

Re: Standalone html builder (a la seaside without seaside?)

by Sean P. DeNigris

Jan BlizniÄenko wrote > ...HtmlDiv... Cool :) I've often felt a suspicion that the lack of logical HTML domain objects leaves a hole in the possibilities for declarative style / meta info ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 13, 2020

Re: Energy efficiency of Pharo/Smalltalk

by Jonathan van Alteren

Hi StÃ©phane, Thanks for your feedback. I agree that the usefulness of these results is limited. However, if we (Object Guild) want to make a case for energy efficiency, it can help if the language itself can be shown to be efficient as well. For now, I think the efficiency will need to come from a good object design. Kind regards, Jonathan van Alteren Founding Member | Object Guild B.V. Sustainable Software for Purpose-Driven Organizations On 11 Oct 2020, 16:49 +0200, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>, wrote: > The problem is that what do you measure. > When you move computation from the CPU to a GPU for example does it consume less or more. > I think that such analyses are totally stupid. > Is a fast execution consume less? I have serious doubts about it. > Now if we measure how fast we drain a battery because of polling vs event based then this is different. > > S. > > > On 1 Oct 2020, at 13:47, Jonathan van Alteren <jvalteren(a)objectguild.com> wrote: > > > > Hi all, > > > > I am interested in energy efficiency metrics for Pharo (version >=8). Just now, I came across this research and related GitHub project: > > > > â¢ https://sites.google.com/view/energy-efficiency-languages > > â¢ https://github.com/greensoftwarelab/Energy-Languages > > > > > > Unfortunately, the paper mentions that Smalltalk was excluded from the results because the (VW) compiler was proprietary :-S However, the GitHub repository does contain Smalltalk code and results, but I haven't been able to evaluate those. > > > > [1] Does anyone here have more information on this topic? > > > > > > The benchmarks seem to be low-level algorithms. Although that is useful, I think that a better argument for Pharo/Smalltalk efficiency is that a good OO design (e.g. created using responsibility-driven design with behaviorally complete objects) will be a better fit, can be much simpler and will thus be more efficient during development, as well as easier to maintain and evolve. > > > > [2] Has anyone done any research in this area that can quantify this aspect? > > > > Kind regards, > > > > Jonathan van Alteren > > > > Founding Member | Object Guild B.V. > > Sustainable Software for Purpose-Driven Organizations > > > > jvalteren(a)objectguild.com > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Aurore Dalle > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France >

Oct. 13, 2020

Re: [Pharo-dev] [ANN] Libgit 1.0.0 in Pharo 9

by ducasse

Libgit depends on PCRE. O_o > On 13 Oct 2020, at 10:20, tesonep(a)gmail.com wrote: > > Hi Martin, > thanks for testing it. Can you tell me the version / flavour of > Debian are you using? > Maybe we need to ship PCRE with the VM. I am not fun of that, but we > need to do it until we can have a proper packaging for each Linux > distribution (Esteban is working on having a nice OBS configuration > for the VM extending what Holger has previously done). > It takes time and a lot of testing, but the idea is to fix (or at > least control better) the dependency nightmare between different Linux > distributions. > > Cheers, > Pablo > > On Tue, Oct 13, 2020 at 7:49 AM Martin McClure <martin(a)hand2mouse.com> wrote: >> >> Thanks, this is great news. >> >> Are there instructions on how to make P9 actually use the new version of >> libgit2? I see that the stable Linux VM for 9.0 does include >> "libgit2.1.0.0.so" but Pharo is still loading libgit2.so.0.25.1. >> >> ...this may be because Pharo's libgit2.1.0.0.so has not-found >> dependencies on libpcre.so.3 and libpcreposix.so.3. >> >> I find Debian's versioning of libpcre somewhat confusing. The package >> "libpcre3" is the *old* libraries, and new stuff is supposed to use >> "pcre2." 2 is apparently newer than 3. At any rate PCRE library naming >> is rather distro-specific, and although I have the right packages >> installed, the libraries have different filenames. >> >> But libgit2 is not supposed to have PCRE as a dependency. The source >> code for PCRE is included in the source for libgit2. Seems like it would >> be possible (and nice!) to compile the libgit2.1.0.0.so included with >> the VM to include the PCRE code internally, rather than depend on an >> external library. >> >> Thanks, >> -Martin >> >> On 10/12/20 2:26 AM, tesonep(a)gmail.com wrote: >>> Hi, a later announcement (this have been done some months ago... but I >>> never send the mail). >>> >>> We have upgraded in Pharo 9 to use the latest stable version of Libgit. >>> It required to have some improvements in Libgit to handle the updated >>> version and also to support the previous version. >>> >>> From the point of view of new features, it does not add new things. >>> However, this version fixes a lot of existing problems in Libgit. >>> >>> We can be sure this was a successful deployment as we don't have >>> problems with it. We are really happy that this has been done >>> transparently and keeping the working version with different >>> configurations of images and VMs. As we should support new and old >>> images, on the same VM. And also running new images in old VMs >>> >>> Thanks. >>> >> > > > -- > Pablo Tesone. > tesonep(a)gmail.com

Oct. 13, 2020

Re: [Pharo-dev] [ANN] Libgit 1.0.0 in Pharo 9

by tesonep＠gmail.com

Hi Martin, thanks for testing it. Can you tell me the version / flavour of Debian are you using? Maybe we need to ship PCRE with the VM. I am not fun of that, but we need to do it until we can have a proper packaging for each Linux distribution (Esteban is working on having a nice OBS configuration for the VM extending what Holger has previously done). It takes time and a lot of testing, but the idea is to fix (or at least control better) the dependency nightmare between different Linux distributions. Cheers, Pablo On Tue, Oct 13, 2020 at 7:49 AM Martin McClure <martin(a)hand2mouse.com> wrote: > > Thanks, this is great news. > > Are there instructions on how to make P9 actually use the new version of > libgit2? I see that the stable Linux VM for 9.0 does include > "libgit2.1.0.0.so" but Pharo is still loading libgit2.so.0.25.1. > > ...this may be because Pharo's libgit2.1.0.0.so has not-found > dependencies on libpcre.so.3 and libpcreposix.so.3. > > I find Debian's versioning of libpcre somewhat confusing. The package > "libpcre3" is the *old* libraries, and new stuff is supposed to use > "pcre2." 2 is apparently newer than 3. At any rate PCRE library naming > is rather distro-specific, and although I have the right packages > installed, the libraries have different filenames. > > But libgit2 is not supposed to have PCRE as a dependency. The source > code for PCRE is included in the source for libgit2. Seems like it would > be possible (and nice!) to compile the libgit2.1.0.0.so included with > the VM to include the PCRE code internally, rather than depend on an > external library. > > Thanks, > -Martin > > On 10/12/20 2:26 AM, tesonep(a)gmail.com wrote: > > Hi, a later announcement (this have been done some months ago... but I > > never send the mail). > > > > We have upgraded in Pharo 9 to use the latest stable version of Libgit. > > It required to have some improvements in Libgit to handle the updated > > version and also to support the previous version. > > > > From the point of view of new features, it does not add new things. > > However, this version fixes a lot of existing problems in Libgit. > > > > We can be sure this was a successful deployment as we don't have > > problems with it. We are really happy that this has been done > > transparently and keeping the working version with different > > configurations of images and VMs. As we should support new and old > > images, on the same VM. And also running new images in old VMs > > > > Thanks. > > > -- Pablo Tesone. tesonep(a)gmail.com

Oct. 13, 2020

Re: [Pharo-dev] [ANN] Libgit 1.0.0 in Pharo 9

by Martin McClure

Thanks, this is great news. Are there instructions on how to make P9 actually use the new version of libgit2? I see that the stable Linux VM for 9.0 does include "libgit2.1.0.0.so" but Pharo is still loading libgit2.so.0.25.1. ...this may be because Pharo's libgit2.1.0.0.so has not-found dependencies on libpcre.so.3 and libpcreposix.so.3. I find Debian's versioning of libpcre somewhat confusing. The package "libpcre3" is the *old* libraries, and new stuff is supposed to use "pcre2." 2 is apparently newer than 3. At any rate PCRE library naming is rather distro-specific, and although I have the right packages installed, the libraries have different filenames. But libgit2 is not supposed to have PCRE as a dependency. The source code for PCRE is included in the source for libgit2. Seems like it would be possible (and nice!) to compile the libgit2.1.0.0.so included with the VM to include the PCRE code internally, rather than depend on an external library. Thanks, -Martin On 10/12/20 2:26 AM, tesonep(a)gmail.com wrote: > Hi, a later announcement (this have been done some months ago... but I > never send the mail). > > We have upgraded in Pharo 9 to use the latest stable version of Libgit. > It required to have some improvements in Libgit to handle the updated > version and also to support the previous version. > > From the point of view of new features, it does not add new things. > However, this version fixes a lot of existing problems in Libgit. > > We can be sure this was a successful deployment as we don't have > problems with it. We are really happy that this has been done > transparently and keeping the working version with different > configurations of images and VMs. As we should support new and old > images, on the same VM. And also running new images in old VMs > > Thanks. >

Oct. 13, 2020

[ANN] Libgit 1.0.0 in Pharo 9

by tesonep＠gmail.com

Hi, a later announcement (this have been done some months ago... but I never send the mail). We have upgraded in Pharo 9 to use the latest stable version of Libgit. It required to have some improvements in Libgit to handle the updated version and also to support the previous version. >From the point of view of new features, it does not add new things. However, this version fixes a lot of existing problems in Libgit. We can be sure this was a successful deployment as we don't have problems with it. We are really happy that this has been done transparently and keeping the working version with different configurations of images and VMs. As we should support new and old images, on the same VM. And also running new images in old VMs Thanks. -- Pablo Tesone. tesonep(a)gmail.com

Oct. 12, 2020

Re: Easiest light weight cloud/web persistence for Pharo?

by StÃ©phane Ducasse

Tim saving in STON is also nice :). S > On 6 Oct 2020, at 22:41, Tim Mackinnon <tim(a)testit.works> wrote: > > Gosh - this is proving much more interesting than I had imagined, and Iâm getting lots of useful input, so I double appreciate the time and thoughts from everyone. > > I probably should have said that my "super awesome idea" is just a little flashcard spelling app for my daughter (and possibly a few friends in her class) - so probably SimplePersistance will do in this case, however the comments about making a persistence decision at the right moment are super interesting - and as always, its about spotting the right moment to do thatâ¦ and ideally you have well factored code with ample tests that help you easily move from the idea, to something more scalable or robustâ¦ however, move too soon and you get bogged down with the details and you lose site of an MVP. > > It has been interesting hearing peoples thoughts on all of thisâ¦ the turning tide on ORMâs, the potential sweet allure of a NoSql (but can you query it easily) - and then the overarching element of just setting this shit up (where hopefully Docker steps in to make that bit at least easy). I suppose this is where the Rails scaffolding was/is? such a jumpstart, you can get a full thing going quite easily, and deploying seems relatively easy tooâ¦ for us in Smalltalk land, its still a bit too much work for my liking, compared to the ease of getting an image and coding, and seeing it all work. It does seem to be getting marginally better at least, but I do wish there was super easy setup with all the pieces nicely in place so it was just your idea that you could focus onâ¦ > > Anyway, that login screenâ¦ oh crap I have to write one of thoseâ¦ > > Tim > >> On 6 Oct 2020, at 20:56, jtuchel(a)objektfabrik.de wrote: >> >> Sean, >> >> thanks for your short overview of what SimplePersistence does. Sounds useful for quite a few scenarios and might even carry you well through production stages for some projects. >> What I was talking about is also not meant to frustrate people. I've only played with Mongo/Voyage for a few hours and I must say I was blown away by the speed and ease of that stack. We got something running in a few hours and it was impressive. So Mongo/Voyage is a cool thing to use. >> >> I always wanted to use Magna on Pharo. I even started to implement my own little clone of Magna in VA Smalltalk. I got into troubles when I tried to nest transactions and get this concurrency stuff streamlined somehow. We all know that besides naming and one-off problems, caching and concurreny are the hardest problems in computing. I think there is something about this. And so I gave up on that project... ;-) >> >> In the end I went with Glorp and DB2 (soon PostgreSQL). So far I am in a very solid state somewhere between complete despair and freaking out about how cool things are. I love and hate that stack from the bottom of my heart. >> >> The cool thing about an RDB is (and will sure be for quite a while) three letters. S, Q and L. There are lots of highly sophisticated GUI tools to query, manage, correct your data. And you can simply do everything form a command prompt, in an ssh session from your smartphone in a hotel toilet on the other side of the planet. >> >> Sure, using pure Smalltalk objects and not worry about n:m relationships, not having to write mappings and not having to end up with an object model that is driven mostly by what your O/R mapper can handle, sound great. And it is. Until you realize you also need to think about query optimizations, reorganizations, indexes and whatnot in an object database. There are also compromises to make. >> >> But, hey, I said all of that before. >> >> So maybe approaches like fuel, SimplePersistence (or BOSS or Object Swapper) are the best thing to start with when you need to find out about your architectural and business ideas first (am I building the right thing, will this feel good to a user, etc.), but once you are beyond that state, you better dive into your options and decide soon. Maybe using image saving or SimplePersistence is even good for production in your case. It was good enough for dabbleDB for quite a while, iirc, so why shouldn't it work for others? And maybe that is even the best you can do to postpone the decision for as long as possible at minimum opportunity cost. >> >> I didn't dig deep enough into Voyage/Mongo to judge how expensive or risky the changes to the design are. How hard is it to restructure the root trees - say you need something that is now beneath some root to be a root of its own? How would you do such changes? >> >> I know I can do a lot of things of that kind with SQL. It is a second looking glass and set of tools to view and manipulate the data. Sometimes things are easier to do in Smalltalk, sometimes it is way too slow on top of an ORM and a SQL query can do the same thing in a few milliseconds. >> >> But maybe I am asking the wrong questions fo Tim's purposes. I think I understand what you (Tim) are looking for is not a big, complex project but more like an experiment? I don't want to invalidate any of the given suggestions, I know or at least believe that they each do a good job. All I really wanted to warn you is that you will not easily be able to go from one option to another, because each will have a deep impact on your object model and application architecture. >> >> Joachim >> >> >> >> >> Am 06.10.20 um 16:34 schrieb Sean P. DeNigris via Pharo-users: >>> jtuchel wrote >>>> Sigh. Forget about the idea that it will be easy to switch your >>>> persistence later....I am not commenting on SimplePersistence here, I >>>> don't even know what it >>>> does or doesn't. >>> Joachim, >>> Thanks for this interesting perspective. I've never had the (mis?!)fortune >>> of a project growing enough to force me to make those tough choices! For >>> SimplePersistence I will say that I view it as a way to *delay* making *any* >>> choices until you are forced to. It's really just a layer of sugar on top of >>> Fuel (it used to use the old school Squeak equivalent serialization >>> mechanism - I forget the name and that might still work). You tell it what >>> classes to serialize. Implement two methods for each class that get and set >>> the data, and then it saves the whole thing as one object graph. >>> >>> Tim, >>> If you use SimplePersistence, please keep me posted about your experience. >>> I'm happy to help. >>> >>> NB I have maintained and extended the library, but it is the work of Ramon >>> Leon >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> >> >> -- >> ----------------------------------------------------------------------- >> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >> Fliederweg 1 http://www.objektfabrik.de >> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >> -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Oct. 11, 2020

Re: [Pharo-dev] [ANN] Pharo Consortium New Gold Member: InfOil

by StÃ©phane Ducasse

us too :) S. > On 30 Sep 2020, at 16:39, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > As a former employee of the company I'm really happy to see this > finally happening! > > Best regards! > > Esteban A. Maringolo > > On Wed, Sep 30, 2020 at 11:13 AM Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> The Pharo Consortium is very happy to announce that InfOil has joined the Consortium as a Gold Member. >> >> InfOil is an Argentinian company focused on software development for the Oil and Gas industry with clients >> in Latin America, Cuba, and Canada. >> >> About >> - InfOil: http://www.infoil.com.ar >> - Pharo Consortium: http://consortium.pharo.org >> >> The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development >> and future of Pharo. >> >> Individuals can support Pharo via the Pharo Association: >> >> - http://association.pharo.org -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Oct. 11, 2020