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

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