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

[teso...@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  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, teso...@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.
teso...@gmail.com

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

[ducasse]

Libgit depends on PCRE. O_o

> On 13 Oct 2020, at 10:20, teso...@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  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, teso...@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.
> teso...@gmail.com

[Pharo-users] Re: Energy efficiency of Pharo/Smalltalk

[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 , 
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  
> > 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
> >
> > jvalte...@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
>

[Pharo-users] Re: Standalone html builder (a la seaside without seaside?)

[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

[Pharo-users] Re: Energy efficiency of Pharo/Smalltalk

[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
> 
> 

[Pharo-users] Re: Energy efficiency of Pharo/Smalltalk

[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

jvalte...@objectguild.com
On 13 Oct 2020, 16:49 +0200, Stéphane Ducasse , 
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
> >
> >

[Pharo-users] Re: Energy efficiency of Pharo/Smalltalk

[Stéphane Ducasse]

> On 13 Oct 2020, at 21:33, Jonathan van Alteren  
> 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/ 
> .

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 
> 

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
> 
> jvalte...@objectguild.com
> On 13 Oct 2020, 16:49 +0200, Stéphane Ducasse , 
> 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