November 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

by phil＠highoctane.be

Here is the CI thing for Travis. https://github.com/hpi-swa/smalltalkCI Phil On Mon, Nov 14, 2016 at 7:15 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com > wrote: > Le 14/11/2016 Ã 18:12, Denis Kudriashov a Ã©crit : > > > > But we already has fork of Metacello in image. Many Metacello packages > > are from integrator. > > So loading latest version is not possible now. And merge will not be > > easy task anyway. > > But maybe I am wrong here. > > For some projects as MaterialDesignLite I need the latest version of > Metacello so I load it. Before the change in pragma it was fine. > > Dale try to keep Metacello running on Pharo with TravisCI I think. > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

Nov. 14, 2016

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

by Eliot Miranda

Hi All, can I suggest that Pharo and Squeak coordinate on a change. First, #selector is bad because it is ambiguous. As already determined #keyword is awful because it's false (it is a message selector, not just a keyword). So could we - use #methodSelector and #pragmaSelector for the next few years, and deprecate #selector and #keyword? - after a suitable time use #selector to mean #pragmaSelector because that's the most useful abbreviation (in my experience I most often access #pragmaSelector)? _,,,^..^,,,_ (phone) > On Nov 14, 2016, at 6:37 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > 2016-11-14 11:27 GMT-03:00 phil(a)highoctane.be <phil(a)highoctane.be>: >> Breaking Metacello in Pharo 6: Not good. Revert: +1 > > Breaking Metacello in any version = Not good. > > Metacello is very backward compatible but breaking pragma semantics > would require a rewrite of many configurations that work okay today > and would require a new version of Metacello that contemplates the new > selectors based on some criteria. > > Regards! > > Esteban A. Maringolo >

Nov. 14, 2016

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

by Cyril Ferlicot D.

Le 14/11/2016 Ã 18:12, Denis Kudriashov a Ã©crit : > > But we already has fork of Metacello in image. Many Metacello packages > are from integrator. > So loading latest version is not possible now. And merge will not be > easy task anyway. > But maybe I am wrong here. For some projects as MaterialDesignLite I need the latest version of Metacello so I load it. Before the change in pragma it was fine. Dale try to keep Metacello running on Pharo with TravisCI I think. -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Nov. 14, 2016

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

by Marcus Denker

> On 14 Nov 2016, at 18:12, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-11-14 17:18 GMT+01:00 Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com <mailto:cyril.ferlicot@gmail.com>>: > > Why? ConfigurationOf~ not collect any pragmas by themselves. They only > > declare versions by pragmas. > > And we only need to fix Pharo version of Metacello which is already fork. > > Changes to Metacello should be done on metacello-work repository and not > only on Pharo. Else we will not be able to load the latest Metacello > > But we already has fork of Metacello in image. Many Metacello packages are from integrator. > So loading latest version is not possible now. And merge will not be easy task anyway. > But maybe I am wrong here. The idea was to integrate small things firstâ¦ in the past we tried to push small changes to projects first, but it is extremely slow and very hard to get anything doneâ¦ Marcus

Nov. 14, 2016

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

by Denis Kudriashov

2016-11-14 17:18 GMT+01:00 Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com>: > > Why? ConfigurationOf~ not collect any pragmas by themselves. They only > > declare versions by pragmas. > > And we only need to fix Pharo version of Metacello which is already fork. > > Changes to Metacello should be done on metacello-work repository and not > only on Pharo. Else we will not be able to load the latest Metacello But we already has fork of Metacello in image. Many Metacello packages are from integrator. So loading latest version is not possible now. And merge will not be easy task anyway. But maybe I am wrong here.

Nov. 14, 2016

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

by Esteban Lorenzano

> On 14 Nov 2016, at 17:18, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > On 14/11/2016 15:50, Denis Kudriashov wrote: >> >> 2016-11-14 15:37 GMT+01:00 Esteban A. Maringolo <emaringolo(a)gmail.com >> <mailto:emaringolo@gmail.com>>: >> >> Breaking Metacello in any version = Not good. >> >> Metacello is very backward compatible but breaking pragma semantics >> would require a rewrite of many configurations that work okay today >> >> >> Why? ConfigurationOf~ not collect any pragmas by themselves. They only >> declare versions by pragmas. >> And we only need to fix Pharo version of Metacello which is already fork. > > Changes to Metacello should be done on metacello-work repository and not > only on Pharo. Else we will not be able to load the latest Metacello > anymore and we will not have the latest cool features of Dale. Metacello should not be a fork. yes, we have problems to keep everything in line, but the fact that we have this problems does not means we should declare the exception a rule :) Esteban > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France >

Nov. 14, 2016

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

by Marcus Denker

> On 14 Nov 2016, at 17:18, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > On 14/11/2016 15:50, Denis Kudriashov wrote: >> >> 2016-11-14 15:37 GMT+01:00 Esteban A. Maringolo <emaringolo(a)gmail.com >> <mailto:emaringolo@gmail.com>>: >> >> Breaking Metacello in any version = Not good. >> >> Metacello is very backward compatible but breaking pragma semantics >> would require a rewrite of many configurations that work okay today >> >> >> Why? ConfigurationOf~ not collect any pragmas by themselves. They only >> declare versions by pragmas. >> And we only need to fix Pharo version of Metacello which is already fork. > > Changes to Metacello should be done on metacello-work repository and not > only on Pharo. Else we will not be able to load the latest Metacello > anymore and we will not have the latest cool features of Dale. > Yes. The change has to be reverted and then later we need to see what to do in a way that is less disruptive. After we decided to freeze is for sure the wrong time for a change like this. Marcus

Nov. 14, 2016

Re: [Pharo-dev] Performance difference between Pharo 32bits and 64bits

by Thierry Goubier

Hi Eliot, 2016-11-14 16:57 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Thierry, > > > > On Nov 14, 2016, at 7:04 AM, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > Has anybody seen performance differences between the 32bits and the > 64bits versions of Pharo 6 ? > > > > I'm seeing a speedup greater than 2 on some intensive numerical code. > > > > Note that, on that code, Pharo 64bits is slower than R, by around 30%. > The code overall is memory bound. > > Can you post (a pointer to?) the R & Pharo code you're comparing? > I join both. It's a simple open lid cavity two dimensions lattice boltzmann code (D2Q9). The Pharo code is a very simple transcription, I didn't try to optimize it at all (I'm not entirely sure it gives the right results, I'll check that tomorrow). Those benchs are the result of the MACH project, an ITEA project, where, with a partner, we wrote a compiler for the R code that is 50 times faster than R (on a dual core i3) (and can use gpus, reaching speedups greater than 1000). Regards, Thierry > > TIA > > > > > Thierry > > > > > >

Nov. 14, 2016

Saving and retrieving global settings

by Nicolas Passerini

Hi, I added some settings into Iceberg and stored them. I expected that they would be automatically loaded into a new image, but it does not work. What I understand is that settings are loaded when the image is opened for the first time, and Iceberg isn't there yet. Then I load Iceberg but it will not load the global settings. So, my question is: what would be the best way to load Iceberg settings just after loading Iceberg into the image?

Nov. 14, 2016

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

by Cyril Ferlicot D.

On 14/11/2016 15:50, Denis Kudriashov wrote: > > 2016-11-14 15:37 GMT+01:00 Esteban A. Maringolo <emaringolo(a)gmail.com > <mailto:emaringolo@gmail.com>>: > > Breaking Metacello in any version = Not good. > > Metacello is very backward compatible but breaking pragma semantics > would require a rewrite of many configurations that work okay today > > > Why? ConfigurationOf~ not collect any pragmas by themselves. They only > declare versions by pragmas. > And we only need to fix Pharo version of Metacello which is already fork. Changes to Metacello should be done on metacello-work repository and not only on Pharo. Else we will not be able to load the latest Metacello anymore and we will not have the latest cool features of Dale. -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Nov. 14, 2016