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

Re: Constraint solver in Pharo?

by Alexandre Bergel

Thanks! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On 28-10-2020, at 04:22, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > > Long time ago Guillaume Grondin ported BackTalk the constraints library by Pierre Roy and FranÃ§ois Pachet from LIP6 to Squeak. http://www.squeaksource.com/@VoaaA0m8tASxYTuS/QN-qUhcD <http://www.squeaksource.com/@VoaaA0m8tASxYTuS/QN-qUhcD> > On Oct 27 2020, at 2:52 pm, Alexandre Bergel via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > Hello! > > Is there a constraint solver available in Pharo? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 29, 2020

Re: Constraint solver in Pharo?

by Noury Bouraqadi

Long time ago Guillaume Grondin ported BackTalk the constraints library by Pierre Roy and FranÃ§ois Pachet from LIP6 to Squeak. http://www.squeaksource.com/@VoaaA0m8tASxYTuS/QN-qUhcD On Oct 27 2020, at 2:52 pm, Alexandre Bergel via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > Hello! > > Is there a constraint solver available in Pharo? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >

Oct. 28, 2020

Re: Constraint solver in Pharo?

by StÃ©phane Ducasse

There is cassowary and deltablue. S. > On 27 Oct 2020, at 14:52, Alexandre Bergel via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > Hello! > > Is there a constraint solver available in Pharo? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > -------------------------------------------- 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. 27, 2020

Constraint solver in Pharo?

by Alexandre Bergel

Hello! Is there a constraint solver available in Pharo? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 27, 2020

[ANN] Next Pharo Sprint: Oct 30

by Marcus Denker

We will organize a Pharo sprint / Moose dojo Oct 30 (this Friday) Goals of this sprint: - Fix issues from tracker https://github.com/pharo-project/pharo/issues This is a Remote Sprint, it happens on Discord. http://pharo.org/contribute-events We have added a Board to coordinate the work: https://github.com/orgs/pharo-project/projects/9 A list of all Pharo Event of the year an be found here: https://association.pharo.org/events

Oct. 27, 2020

GSOC 2021

by Serge Stinckwich

GSOC 2021 is out: https://summerofcode.withgoogle.com/ Anyone is willing to lead the Pharo proposal? Regards, -- Serge Stinckwic h https://twitter.com/SergeStinckwich

Oct. 27, 2020

[Ann] IndieWeb and pocket infrastructures: 6th biweekly workshop this Saturday (3:15 PM - 7:15 PM, GMT-5)

by Offray Vladimir Luna CÃ¡rdenas

Hi all, This is just a short reminder about our biweekly Grafoscopio community workshops about IndieWeb and pocket infrastructures (in Spanish). You can find more information about them on: [1] https://mutabit.com/repos.fossil/indieweb/doc/trunk/docs/es/index.html#tall… It has been really nice to see how workshops, prose and code advance intertwined and feedback each other in this community experience made on a voluntary basis. In the "behind scenes" links below you can see how the writing advances at a pretty good pace. By a happy coincidence, that I think is more a reflection of the spirit of our times, we, at the local community, started to develop a so called decoupled/headless CMS, that suits our writing and publishing workflows better that overcomplicated CMS (like WordPress) and after that I found that there is a complete movement around them, that includes static generators[1] and JAMStack. Our approach aligns with them in some places and in others I think we are more agile and minimalist. As usual, I create an interactive Grafoscopio outline/notebook and a Domain Specific Language that explores the problem and creates some prototypes (see screenshot below). We have biweekly community workshops[2a], where we learn how to build, update and modify our static site and the technologies behind and the companion documentation site[2] is an exampler and explainer of what can be done using the Brea[3] minimalist CMS under construction: [1] https://jamstack.org/generators/ [2] https://mutabit.com/repos.fossil/indieweb/ [2a] https://mutabit.com/repos.fossil/indieweb/doc/trunk/docs/es/index.html#tall… [3] https://mutabit.com/repos.fossil/brea/ As usual, I would like to thanks the remote community that makes this local experience possible, and also I would like to thank ESUG for their key support to this initiative. Cheers, Offray Ps: here are the "behind scenes" links * https://mutabit.com/repos.fossil/indieweb/timeline * https://mutabit.com/repos.fossil/indieweb/tree?ci=tip&name=docs/es&type=tree * https://code.tupale.co/Offray/Brea * https://mutabit.com/repos.fossil/brea/

Oct. 23, 2020

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

by stephan

For some situations, creating something on github might be a perfectly good persistence strategy. Stephan

Oct. 22, 2020

Pharo Mars still not working on Ubuntu

by kmo

I see that the Pharo-Mars code has recently been split into two projects. Unfortunately this has still not fixed the problem with Ubuntu. It is still totally impossible to run pharo mars on ubuntu. Now just loading the GTK-bindings package into ubuntu causes a segfault. This is actually going backwards - at least you used to be able to load the code into pharo, even though it crashed if you tried to use it. i flagged this up in May. I'm beginning to think I'll be dead before I see Ubuntu running Pharo-Mars. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 22, 2020

Re: Energy efficiency of Pharo/Smalltalk

by Richard O'Keefe

The energy comparison web site is a useful reference. However, it measures a combination of - hardware platform - operating system (for example, FASTA does oodles of output) - compiler - runtime system (for example, garbage collector) - algorithm. Where there are multiple algorithms for a single language, we can see that that matters a LOT. For example, the fastest Rust code for FASTA is five times faster than the slowest, and we can expect a similar range in energy use. In the case of Smalltalk, do we expect Pharo and Amber to have the same time or energy costs? One of my earliest papers examined a "language X vs language Y" paper where I pointed out that they had compared moderately bad language X code to appallingly bad language Y code and when you improved both the only real difference was the efficiency of the 'print' function in each language. For this reason, amongst others, if you want to compare *languages*, you need multiple implementations in each language, otherwise what you are measuring is as much programmer skill as anything else. The one supremely useful thing in the language efficiency paper is that all the code they used is on github, including the tool they used to measure energy use. (It's a software-only tool.) That means that you can do your own measurements, and that's what really matters. On Wed, 21 Oct 2020 at 03:29, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Here is an interesting article that could help as a start: > > > https://thenewstack.io/which-programming-languages-use-the-least-electricit… > > Cheers, > > > On Thu, Oct 15, 2020 at 8:41 PM Richard O'Keefe <raoknz(a)gmail.com> wrote: > >> It doesn't make a whole lot of sense to talk about the energy efficiency >> of a programming language. For example, I've seen the run time of a >> C benchmark go from 50 seconds to 1 microsecond when the optimisation >> level was changed. It doesn't even make much sense to talk about the >> energy efficiency of the code generated by a specific compiler with >> specific options: the underlying hardware counts too. A colleague of >> mine, looking at text compression algorithms for an information retrieval >> engine, found that the fastest algorithm depended on just which x86-64 >> chip, even what motherboard, was in use. It's obviously going to be >> the same for energy efficiency. >> >> So let's specify a particular physical machine, a particular compiler, >> and a particular set of compiler options. NOW does it make sense to >> talk about energy efficiency? Nope. It's going to depend on the >> problem as well. And the thing is that people tend to do different >> things in different programming languages, and different communities >> attract different support. There is no portable Smalltalk equivalent >> of NumPy, able to automatically take advantage of GPUs, for example. >> >> You can get some real surprises. >> For example, just now while writing this message, I fired up >> powerstat(8). I had the browser open and power consumption was >> about 12.8 W. I then launched Squeak and ran some benchmarks. >> Power consumption went DOWN to 11.4 W. >> That is, Squeak was "costing" me -1.4 W. >> >> If you understand the kind of things modern CPUs get up to, that >> is not as surprising as it seems. All it demonstrates is that >> getting MEANINGFUL answers is hard enough; getting GENERALISBLE >> answers is going to be, well, if anyone succeeded, I think they >> would have earned at least a Masters. >> >> >> On Tue, 13 Oct 2020 at 23:38, Jonathan van Alteren < >> jvalteren(a)objectguild.com> 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. >>> >>> 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 >>> >>> > > -- > Mariano Martinez Peck > Email: marianopeck(a)gmail.com > Twitter: @MartinezPeck > LinkedIn: www.linkedin.com/in/mariano-martinez-peck > <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/> > Blog: https://marianopeck.wordpress.com/ >

Oct. 21, 2020

Re: Zinc question (may be this is an HTML one)

by StÃ©phane Ducasse

> > This is an HTTP question (the protocol, not HTML the document format). Yes this is what I meant but the mail was sent. > And you solved your problem well, I never tried it like that myself ;-) > > I would not write it differently. > > Like the comment says, it will only work with those types recognised by ImageReadWriter, which are the most common ones, JPG, GIF and PNG. > > Image/* is a wildcard matching any image type, and there are many, many more. > > The current mechanism in Zinc with #accept: and #enforceAcceptContentType: true assumes a singular 'Accept' header. But indeed, technically, it is possible to specify more than one. > > For example, this also works: > > ZnClient new > url: 'http://pharo.org/files/pharo.png <http://pharo.org/files/pharo.png>'; > headerAt: 'Accept' add: ZnMimeType imageGif asString; > headerAt: 'Accept' add: ZnMimeType imagePng asString; > headerAt: 'Accept' add: ZnMimeType imageJpeg asString; > contentReader: [ :entity | ImageReadWriter formFromStream: entity readStream ]; > get. Ah this would be better for me because like that I can probably control which exception is raised. Because we do not support image/svg > But I have to think a bit about this issue. > > Another approach is to use the extension of the URL. > > ZnMimeType forFilenameExtension: 'http://pharo.org/files/pharo.png <http://pharo.org/files/pharo.png>' asUrl file asFileReference extension. > > It all depends at what level you want to tell your user they tried getting an unsupported file type. Broad :) but soon you will be my user and you will have the right to complain :) > > Sven > >> S. >> >> >> -------------------------------------------- >> StÃ©phane Ducasse >> http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> / http://www.pharo.org <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 -------------------------------------------- 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. 20, 2020

Re: Energy efficiency of Pharo/Smalltalk

by Mariano Martinez Peck

Here is an interesting article that could help as a start: https://thenewstack.io/which-programming-languages-use-the-least-electricit… Cheers, On Thu, Oct 15, 2020 at 8:41 PM Richard O'Keefe <raoknz(a)gmail.com> wrote: > It doesn't make a whole lot of sense to talk about the energy efficiency > of a programming language. For example, I've seen the run time of a > C benchmark go from 50 seconds to 1 microsecond when the optimisation > level was changed. It doesn't even make much sense to talk about the > energy efficiency of the code generated by a specific compiler with > specific options: the underlying hardware counts too. A colleague of > mine, looking at text compression algorithms for an information retrieval > engine, found that the fastest algorithm depended on just which x86-64 > chip, even what motherboard, was in use. It's obviously going to be > the same for energy efficiency. > > So let's specify a particular physical machine, a particular compiler, > and a particular set of compiler options. NOW does it make sense to > talk about energy efficiency? Nope. It's going to depend on the > problem as well. And the thing is that people tend to do different > things in different programming languages, and different communities > attract different support. There is no portable Smalltalk equivalent > of NumPy, able to automatically take advantage of GPUs, for example. > > You can get some real surprises. > For example, just now while writing this message, I fired up > powerstat(8). I had the browser open and power consumption was > about 12.8 W. I then launched Squeak and ran some benchmarks. > Power consumption went DOWN to 11.4 W. > That is, Squeak was "costing" me -1.4 W. > > If you understand the kind of things modern CPUs get up to, that > is not as surprising as it seems. All it demonstrates is that > getting MEANINGFUL answers is hard enough; getting GENERALISBLE > answers is going to be, well, if anyone succeeded, I think they > would have earned at least a Masters. > > > On Tue, 13 Oct 2020 at 23:38, Jonathan van Alteren < > jvalteren(a)objectguild.com> 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. >> >> 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 >> >> -- Mariano Martinez Peck Email: marianopeck(a)gmail.com Twitter: @MartinezPeck LinkedIn: www.linkedin.com/in/mariano-martinez-peck <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/> Blog: https://marianopeck.wordpress.com/

Oct. 20, 2020

Re: Zinc question (may be this is an HTML one)

by Sven Van Caekenberghe

Hi Stef, > On 20 Oct 2020, at 09:35, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > Hi sven and others > > > While trying to improve microdown I have the following question. > How can I have a more generic getImage: method. > > Right now I use getPng: and I would like to support getPng: and getJpeg. > > I saw that there is getImageOfType: mimeType fromUrl: urlObject > > > getImageOfType: mimeType fromUrl: urlObject > | client | > (client := self client) > url: urlObject; > accept: mimeType; > enforceHttpSuccess: true; > enforceAcceptContentType: true; > get. > "ImageReadWriter does automatic type detection" > ^ ImageReadWriter formFromStream: client entity readStream > > So it looks like what I want except that I do not know how to specify a Mime > > So I did > > ZnEasy > getImageOfType: (ZnMimeType main: 'image' sub: '*') > fromUrl: 'http://pharo.org/files/pharo.png' > > Now I would like to know if this is the correct way to do it. > I could imagine that we could give a set of possible mime types. This is an HTTP question (the protocol, not HTML the document format). And you solved your problem well, I never tried it like that myself ;-) I would not write it differently. Like the comment says, it will only work with those types recognised by ImageReadWriter, which are the most common ones, JPG, GIF and PNG. Image/* is a wildcard matching any image type, and there are many, many more. The current mechanism in Zinc with #accept: and #enforceAcceptContentType: true assumes a singular 'Accept' header. But indeed, technically, it is possible to specify more than one. For example, this also works: ZnClient new url: 'http://pharo.org/files/pharo.png'; headerAt: 'Accept' add: ZnMimeType imageGif asString; headerAt: 'Accept' add: ZnMimeType imagePng asString; headerAt: 'Accept' add: ZnMimeType imageJpeg asString; contentReader: [ :entity | ImageReadWriter formFromStream: entity readStream ]; get. But I have to think a bit about this issue. Another approach is to use the extension of the URL. ZnMimeType forFilenameExtension: 'http://pharo.org/files/pharo.png' asUrl file asFileReference extension. It all depends at what level you want to tell your user they tried getting an unsupported file type. Sven > S. > > > -------------------------------------------- > 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. 20, 2020

Zinc question (may be this is an HTML one)

by StÃ©phane Ducasse

Hi sven and others While trying to improve microdown I have the following question. How can I have a more generic getImage: method. Right now I use getPng: and I would like to support getPng: and getJpeg. I saw that there is getImageOfType: mimeType fromUrl: urlObject getImageOfType: mimeType fromUrl: urlObject | client | (client := self client) url: urlObject; accept: mimeType; enforceHttpSuccess: true; enforceAcceptContentType: true; get. "ImageReadWriter does automatic type detection" ^ ImageReadWriter formFromStream: client entity readStream So it looks like what I want except that I do not know how to specify a Mime So I did ZnEasy getImageOfType: (ZnMimeType main: 'image' sub: '*') fromUrl: 'http://pharo.org/files/pharo.png' Now I would like to know if this is the correct way to do it. I could imagine that we could give a set of possible mime types. S. -------------------------------------------- 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. 20, 2020

Re: Energy efficiency of Pharo/Smalltalk

by Richard O'Keefe

It doesn't make a whole lot of sense to talk about the energy efficiency of a programming language. For example, I've seen the run time of a C benchmark go from 50 seconds to 1 microsecond when the optimisation level was changed. It doesn't even make much sense to talk about the energy efficiency of the code generated by a specific compiler with specific options: the underlying hardware counts too. A colleague of mine, looking at text compression algorithms for an information retrieval engine, found that the fastest algorithm depended on just which x86-64 chip, even what motherboard, was in use. It's obviously going to be the same for energy efficiency. So let's specify a particular physical machine, a particular compiler, and a particular set of compiler options. NOW does it make sense to talk about energy efficiency? Nope. It's going to depend on the problem as well. And the thing is that people tend to do different things in different programming languages, and different communities attract different support. There is no portable Smalltalk equivalent of NumPy, able to automatically take advantage of GPUs, for example. You can get some real surprises. For example, just now while writing this message, I fired up powerstat(8). I had the browser open and power consumption was about 12.8 W. I then launched Squeak and ran some benchmarks. Power consumption went DOWN to 11.4 W. That is, Squeak was "costing" me -1.4 W. If you understand the kind of things modern CPUs get up to, that is not as surprising as it seems. All it demonstrates is that getting MEANINGFUL answers is hard enough; getting GENERALISBLE answers is going to be, well, if anyone succeeded, I think they would have earned at least a Masters. On Tue, 13 Oct 2020 at 23:38, Jonathan van Alteren < jvalteren(a)objectguild.com> 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. > > 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. 15, 2020

Re: Why does loading baselines in P8 gives multiple entries in Iceberg?

by Gabriel Cotelli

It's already reported: https://github.com/pharo-project/pharo/issues/5881 On Thu, Oct 15, 2020 at 6:16 PM Tim Mackinnon <tim(a)testit.works> wrote: > Hi guys - having not worked on a proper project in Pharo for a while, I > was a bit surprised in Pharo 8 to see that when I load a project baseline, > it seems to appear multiple times in Iceberg? Is this a known issue - or am > I forgetting to do something? > > I noticed this for CodeParadise, but also have noticed it for my latest > project tooâ¦ it seems benign, the second one appears as a detached copy > when I commit changes on one of the entries - but its not something that I > recall seeing in earlier Pharo versions (like P7). > > Tim > >

Oct. 15, 2020

Why does loading baselines in P8 gives multiple entries in Iceberg?

by Tim Mackinnon

Hi guys - having not worked on a proper project in Pharo for a while, I was a bit surprised in Pharo 8 to see that when I load a project baseline, it seems to appear multiple times in Iceberg? Is this a known issue - or am I forgetting to do something? I noticed this for CodeParadise, but also have noticed it for my latest project tooâ¦ it seems benign, the second one appears as a detached copy when I commit changes on one of the entries - but its not something that I recall seeing in earlier Pharo versions (like P7). Tim

Oct. 15, 2020

Re: AthensCairoSDLSurface P8 Error

by Alvaro Piorno

HI StÃ©phane, It works fine in P9 changing for the new implementors of handle. Thanks El dom., 11 oct. 2020 a las 11:57, StÃ©phane Ducasse (< stephane.ducasse(a)inria.fr>) escribiÃ³: > Hello alvaro > > can you try with P9 because we got many improvements. > > S > > On 18 Sep 2020, at 22:07, Alvaro Piorno <alvaropiorno100(a)gmail.com> wrote: > > Hello, > > This code that worked for P6 and P7 is now failing in P8. > > *AthensCairoSDLSurface fromSDLSurface: self window handle handle > getWindowSurface.* > > the window is created like this: > > *window := OSWindow createWithAttributes: (OSWindowAttributes new > resizable: false; yourself).* > > The exception is Error: Could not coerce arguments > > from cairo lib. > > > Cheers > > > -------------------------------------------- > 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. 14, 2020

UK Smalltalk User Group Meeting - Wednesday, October 28th

by Giovanni Corriga

The next meeting of the UK Smalltalk User Group will be on Wednesday, October 28th. Alexandre Bergel will talk about Agile Visualization with Roassal3. Visualizing data is probably the easiest part in the field of data visualization. Numerous books and sophisticated libraries exist for that very purpose. One of challenges of data visualization is to identify the right abstractions that make a visualization reusable, composable, extensible, navigable, and produced at a very low cost. Roassal ( https://github.com/ObjectProfile/Roassal3 ) is a visualization engine for Smalltalk that leverage the experience of crafting and using data visualization. This talk will demo Roassal and presents non-trivial visualizations within the field of software visualization. Alexandre Bergel ( http://bergel.eu/ ) is Associate Professor and researcher at the University of Chile. Alexandre Bergel and his collaborators carry out research in software engineering. His focus is on designing tools and methodologies to improve the overall performance and internal quality of software systems, by employing profiling, visualization, and artificial intelligence techniques. Alexandre Bergel has authored over 140 articles, published in international and peer reviewed scientific forums, including the most competitive conferences and journals in the field of software engineering. Alexandre has participated to over 140 program committees of international events. Alexandre has also a strong interest in applying his research results to industry. Several of his research prototypes have been turned into products and adopted by major companies in the semi-conductor industry and certification of critical software systems. Alexandre is member of the editorial board of Empirical Software Engineering. Alexandre authored the book Agile Artificial Intelligence in Pharo, Agile Visualization ( http://agilevisualization.com/ ), and co-authored the book Deep Into Pharo. Given the current COVID-19 restrictions, this will be an online meeting from home. If you'd like to join us, please sign up in advance on the meeting's Meetup page ( https://www.meetup.com/UKSTUG/events/cbklbrybcnblc/ ) to receive the meeting details. Donât forget to bring your laptop and drinks!

Oct. 14, 2020

Re: Energy efficiency of Pharo/Smalltalk

by StÃ©phane Ducasse

> On 13 Oct 2020, at 21:33, Jonathan van Alteren <jvalteren(a)objectguild.com> wrote: > > 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/ <http://s2group.cs.vu.nl/mission/>. Well if you accept that your web browser is going slower may be you will consume less energy. Or may be your speedy web browser consumes less. > This article might be a good read on the subject: https://research.vu.nl/en/publications/a-manifesto-for-energy-aware-software <https://research.vu.nl/en/publications/a-manifesto-for-energy-aware-software> I skimmed over it and it is wishful thinking. How can I engineer a system (besides using good algorithms instead of sloppy one) to consume less energy, if we do not know what means energy aware: At then this is what? - Number of instructions executed, the least the better? - What about missed caches? - What about missed instruction pipelining? For example on your mac when you unplug the cable you have a different card setup because the videos card can consume more. So we can degrade certain operation. But how to measure this seriously. > > Is this something that could be of interest to Inria or the Pharo project? It depends how money is put on the table. :) > 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? To me Iâm sorry but I do not buy without serious measurement that " distinctions in a domain are successfully made explicit at design time, this will improve performance at runtime â Let us play the scientific here for a moment: do you have data? did you measure it? what are you biais in your measurement/experiment. Now to reply to your question in OORP we promote that case statement were bad that we it is better to use message passing. Except that in some domains in some specific circumstances have case statement is faster. Similarly they are domains where GC is a problem. > > 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 >>> >>> -------------------------------------------- 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: 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