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