Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

[Eliot Miranda]

Hi Phil,

On Thu, Nov 10, 2016 at 2:19 AM, p...@highoctane.be 
wrote:

>
>
> On Thu, Nov 10, 2016 at 10:31 AM, Denis Kudriashov 
> wrote:
>
>>
>> 2016-11-10 9:49 GMT+01:00 p...@highoctane.be :
>>
>>> Ah, but then it may be more interesting to have a data image (maybe a
>>> lot of these) and a front end image.
>>>
>>> Isn't Seamless something that could help us here? No need to bring the
>>> data back, just manipulate it through proxies.
>>>
>>
>> Problem that server image will anyway perform GC. And it will be slow if
>> server image is big which will stop all world.
>>
>
> What if we asked it to not do any GC at all? Like if we have tons of RAM,
> why bother? Especially if what it is used to is to keep datasets: load
> them, save image to disk. When needed trash the loaded stuff and reload
> from zero.
>
> Basically that is what happens with Spark.
>
> http://sujee.net/2015/01/22/understanding-spark-caching/#.WCRIgy0rKpo
> https://0x0fff.com/spark-misconceptions/
>

While global GC may not be useful for big-data scavenging probably will be
for any non-trivial query.  But I think I see a misconception here.  The
large RAM on a multiword machine would be divided up between the cores.  It
makes no sense to run a single Smalltalk across lots of cores (we're a long
way from having a thread-safe class library).  It makes much more sense to
have one Smalltalk per core.  So that brings the heap sizes down and makes
GC less scary.


> and Tachyon/Alluxio is kind of solving this kind of issue (may be nice to
> have that interacting with Pharo image). http://www.alluxio.org/ This
> thing basically keeps stuff in memory in case one needs to reuse the data
> between workload runs.
>

Sure.  We have all the facilities we need to do this.  We can add and
remove code at runtime so we can keep live instances running, and send the
code to them along with the data we want them to crunch.


>
> Or have an object memory for work and one for datasets (first one gets
> GC'd, the other one isn't).
>

Or have policies which one can switch.  There are quite a few levers into
the GC from the image and one can easily switch off global GC with the
right levers.  One doesn't need a VM that doesn't contain a GC.  One needs
an image that is using the right policy.

Phil
>

_,,,^..^,,,_
best, Eliot

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

[Eliot Miranda]

On Thu, Nov 10, 2016 at 1:31 AM, Denis Kudriashov 
wrote:

>
> 2016-11-10 9:49 GMT+01:00 p...@highoctane.be :
>
>> Ah, but then it may be more interesting to have a data image (maybe a lot
>> of these) and a front end image.
>>
>> Isn't Seamless something that could help us here? No need to bring the
>> data back, just manipulate it through proxies.
>>
>
> Problem that server image will anyway perform GC. And it will be slow if
> server image is big which will stop all world.
>

Which is why we plan on implementing an incremental global GC that will not
stop the world, but will divide global GC up into many small steps, each of
which will be shorter than 10 milliseconds, and so not be noticeable.

_,,,^..^,,,_
best, Eliot

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

[Thierry Goubier]

Le 14/11/2016 à 21:51, stepharo a écrit :

Hi thierry


did you happen to have a techreport or any description of your work?


It's a chapter in my PhD thesis ;)

Thierry



Stef


Le 11/11/16 à 11:44, Thierry Goubier a écrit :

Le 11/11/2016 à 11:29, Stephan Eggermont a écrit :

On 10/11/16 21:35, Igor Stasenko wrote:

No, no, no! This is simply not true.
It is you, who writes the code that generates a lot of statistical
data/analysis data, and its output is fairly predictable.. else you are
not collecting any data, but just a random noise, isn't?


That would be green field development. In brown field development, I
only get in when people start noticing there is a problem (why do we
need more than 4GBytes for this?). At that point I want to be able to
load everything they can give me in an image so I can start analyzing
and structuring it.


I mean, Doru is light years ahead of me and many others in field of
data
analysis.. so what i can advise to him on his playground?


Well, the current FAMIX model implementation is clearly not well
structured for analyzing large code bases. And it is difficult to
partition because of unpredictable access patterns and high
interconnection.


This is why you look for a general purpose, efficient off-loading
scheme, trying to optimize a general case and get reasonable
performance out of it (a.k.a fuel, but designed for partial unloading
/ loading: allow dangling references in a unit of load, focus on
per-page units to match the underlying storage layer or network).

I wrote one such layer for VW a long time ago, but didn't had time to
experiment / qualify some of the techniques in it. There was an
interesting attempt (IMHO ... wasn't qualified) at combining paging
and automatic refinement of application working set, based on previous
experience implementing a hierarchical 2D object access scheme for
large datasets on slow medium (decreased access time from 30 minutes
to about a few seconds).

The other approach I would look is take some of the support code for
such an automatic layer and use it to unload parts of my model;, and
I'm pretty sure that, if I don't bench intensively, I'll get the
partitioning wrong :(

Overall, an interesting subject, totally not valid from a scientific
point of view (the database guys have already solved everything). Only
valid as a hobby, or if a company is ready to pay for a solution.

Thierry

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

[stepharo]

Hi thierry


did you happen to have a techreport or any description of your work?


Stef


Le 11/11/16 à 11:44, Thierry Goubier a écrit :

Le 11/11/2016 à 11:29, Stephan Eggermont a écrit :

On 10/11/16 21:35, Igor Stasenko wrote:

No, no, no! This is simply not true.
It is you, who writes the code that generates a lot of statistical
data/analysis data, and its output is fairly predictable.. else you are
not collecting any data, but just a random noise, isn't?


That would be green field development. In brown field development, I
only get in when people start noticing there is a problem (why do we
need more than 4GBytes for this?). At that point I want to be able to
load everything they can give me in an image so I can start analyzing
and structuring it.

I mean, Doru is light years ahead of me and many others in field of 
data

analysis.. so what i can advise to him on his playground?


Well, the current FAMIX model implementation is clearly not well
structured for analyzing large code bases. And it is difficult to
partition because of unpredictable access patterns and high
interconnection.


This is why you look for a general purpose, efficient off-loading 
scheme, trying to optimize a general case and get reasonable 
performance out of it (a.k.a fuel, but designed for partial unloading 
/ loading: allow dangling references in a unit of load, focus on 
per-page units to match the underlying storage layer or network).


I wrote one such layer for VW a long time ago, but didn't had time to 
experiment / qualify some of the techniques in it. There was an 
interesting attempt (IMHO ... wasn't qualified) at combining paging 
and automatic refinement of application working set, based on previous 
experience implementing a hierarchical 2D object access scheme for 
large datasets on slow medium (decreased access time from 30 minutes 
to about a few seconds).


The other approach I would look is take some of the support code for 
such an automatic layer and use it to unload parts of my model;, and 
I'm pretty sure that, if I don't bench intensively, I'll get the 
partitioning wrong :(


Overall, an interesting subject, totally not valid from a scientific 
point of view (the database guys have already solved everything). Only 
valid as a hobby, or if a company is ready to pay for a solution.


Thierry

Re: [Pharo-dev] macOS Sierra support

[stepharo]

Good

Tx


Le 14/11/16 à 11:36, Esteban Lorenzano a écrit :
for the moment, I added this nice (?) alert when you press mac 
download button:



On 14 Nov 2016, at 11:30, Esteban Lorenzano > wrote:



On 14 Nov 2016, at 11:01, MartinW > wrote:


Can someone put a note to the website (http://pharo.org/download)? It is
frustrating for users to follow the link to
http://files.pharo.org/platform/Pharo5.0-mac.zip from there and get a
defunct Pharo installation.


no, in fact that link should work.
… and in fact, it works… is just that due the changes in sierra, the 
bundle needs to be put in /Applications to not be copied into a 
sandbox, readonly place.


I’m working on have this working in a different way: is time to make 
PharoLauncher the default download. That way it will be in 
/Applications naturally and your images will be in a correct place 
naturally (I also would like a “add command line tools” option to 
install a pharo and pharo-ui in /usr/local/bin).


Esteban




Sean P. DeNigris wrote


EstebanLM wrote

the regular download by zeroconf should give you an usable VM.

That worked - thanks!


Yes, this VM works well :)



--
View this message in context: 
http://forum.world.st/macOS-Sierra-support-tp4917181p4922891.html
Sent from the Pharo Smalltalk Developers mailing list archive at 
Nabble.com .

[Pharo-dev] [ANN] WKHTML2PDF converted to UFFI

[Torsten Bergmann]

Hi,

WKHTML2PDF was broken in recent Pharo version as my original version of the 
project
was based on NativeBoost and we now meanwhile switched to UFFI with Pharo to 
provide 
a unified foreign function interface.

Long story short: I now found the time to update the project to use UFFI and 
make
it work again.


You can load it from Catalog in Pharo 5/6. So if you like to convert HTML or 
URLs to a 
PDF use 

  HTML2PDFConverter 
convert: 'http://www.pharo.org'
toFile: 'pharo.pdf'

then check it out. Note that I only had the need to make it work on Windows. If 
someone
adopts to Linux/Mac tell me and we include the contribution.

Project is on STHub as before:

 http://smalltalkhub.com/#!/~TorstenBergmann/WKHTML2PDF 

Thanks
T.

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

[Torsten Bergmann]

I was hit by this today already as it made Catalog slow like hell (which I 
fixed):  https://pharo.fogbugz.com/f/cases/19342/.

+1   for the short-term revert
+10  for aligning Squeak and Pharo with a more intention revealing name 

Thx
T.

> Gesendet: Montag, 14. November 2016 um 19:49 Uhr
> Von: "Eliot Miranda" 
> An: "Pharo Development List" 
> Cc: squeak-...@lists.squeakfoundation.org
> Betreff: Re: [Pharo-dev] Pragma keyword / selector / methodSelector
>
> 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  
> > wrote:
> > 
> > 2016-11-14 11:27 GMT-03:00 p...@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
> > 
> 
> 

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

[p...@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.  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
>
>

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

[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



signature.asc
Description: OpenPGP digital signature

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

[Marcus Denker]

> On 14 Nov 2016, at 18:12, Denis Kudriashov  wrote:
> 
> 
> 2016-11-14 17:18 GMT+01:00 Cyril Ferlicot D.  >:
> > 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

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

[Denis Kudriashov]

2016-11-14 17:18 GMT+01:00 Cyril Ferlicot D. :

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

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

[Marcus Denker]

> On 14 Nov 2016, at 17:18, Cyril Ferlicot D.  wrote:
> 
> On 14/11/2016 15:50, Denis Kudriashov wrote:
>> 
>> 2016-11-14 15:37 GMT+01:00 Esteban A. Maringolo > >:
>> 
>>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

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

[Esteban Lorenzano]

> On 14 Nov 2016, at 17:18, Cyril Ferlicot D.  wrote:
> 
> On 14/11/2016 15:50, Denis Kudriashov wrote:
>> 
>> 2016-11-14 15:37 GMT+01:00 Esteban A. Maringolo > >:
>> 
>>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
> 

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

[Thierry Goubier]

Hi Eliot,

2016-11-14 16:57 GMT+01:00 Eliot Miranda :

> Hi Thierry,
>
>
> > On Nov 14, 2016, at 7:04 AM, Thierry Goubier 
> 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
> >
> >
>
>


LatticeBoltzmann-ThierryGoubier.1.mcz
Description: Binary data
# LBM implementation D2Q9
# Thierry Goubier, 2016
main <- function(n = 200, m = 200, nbstep = 200) { 

	f <- array(0.0, c(9, n+1, m+1))
	feq <- array(0.0, c(9, n+1, m+1))

	rho <- array(0.0, c(n+1, m+1))
	uv <- array(0.0, c(2, n+1, m+1))
	t1 <- array(0.0, c(n+1, m+1))
	t2 <- array(0.0, c(9, n+1, m+1))

	w <- c(4.0/9.0, 1.0/9.0, 1.0/9.0, 1.0/9.0, 1.0/9.0, 1.0/36.0, 1.0/36.0, 1.0/36.0, 1.0/36.0)

	uo <- 60.0 / n
	rhoo <- 1.0
	alpha <- 0.06
	omega <- 1.0/(3.0* alpha + 0.5)

	cx <- c(0.0,1.0,0.0,-1.0,0.0,1.0,-1.0,-1.0,1.0)
	cy <- c(0.0,0.0,1.0,0.0,-1.0,1.0,1.0,-1.0,-1.0)

	for (i in 1:9) {
		f[i,,] <- w[i]
	}

	rho[,] <- rhoo
	uv[,,] <- 0.0

	 uv[1,,m+1] <- uo

	rhon <- array(0.0, c(n-1, 1))

	for (i in 1:nbstep) {
		t1[,] <- uv[ 1,, ]*uv[ 1,, ] + uv[ 2,, ]*uv[ 2,, ]
		for (j in 1:9) {
			
t2[ j,, ] <- cx[ j ]*uv[1,,]+cy[ j ]*uv[ 2,, ]
feq[ j,, ] <- 1.0+3.0*t2[ j,, ] +4.5*t2[ j,, ]*t2[ j,,]-1.5*t1
feq[ j,, ] <- rho*w[ j ]*feq[ j,, ]
f[ j,, ] <- omega * feq[ j,, ]+(1.0 - omega)*f[ j,, ]
feq[ j,, ] <- f[ j,, ]
		}
		f[2,2:(n+1),] <- feq[2,1:n,]
		f[3,,2:(m+1)] <- feq[3,,1:m]
		f[4,1:n,] <- feq[4,2:(n+1),]
		f[5,,1:m] <- feq[5,,2:(m+1)]
		f[6,2:(n+1),2:(m+1)] <- feq[6,1:n,1:m]
		f[7,1:n,2:(m+1)] <- feq[7,2:(n+1),1:m]
		f[8,1:n,1:m] <- feq[8,2:(n+1),2:(m+1)]
		f[9,2:(n+1),1:m] <- feq[9,1:n,2:(m+1)]
		f[ 2,1, ] <- f[ 4,1,]
		f[ 6,1, ] <- f[ 8,1,]
		f[ 9,1, ] <- f[ 7,1,]
		f[ 4,n+1, ] <- f[ 2,n+1, ]
		f[ 8,n+1, ] <- f[ 6,n+1, ]
		f[ 7,n+1, ] <- f[ 9,n+1, ]
		f[ 3,,1 ] <- f[ 5,,1 ]
		f[ 6,,1 ] <- f[ 8,,1 ]
		f[ 7,,1] <- f[ 9,,1 ]
			rhon <- f[1,2:n,m+1] + f[2,2:n,m+1] + f[4,2:n,m+1] + 2.*(f[3,2:n,m+1] + f[6,2:n,m+1] + f[7,2:n,m+1])
			f[5,2:n,m+1] <- f[3,2:n,m+1]
			f[9,2:n,m+1] <- f[7,2:n,m+1] + 0.5*(f[4,2:n,m+1] - f[2,2:n,m+1])+0.5*rhon*uo
			f[8,2:n,m+1] <- f[6,2:n,m+1] + 0.5*(f[2,2:n,m+1] - f[4,2:n,m+1])-0.5*rhon*uo
			rho[ , ] <- f[ 1,, ] + f[ 2,, ] + f[ 3,, ] + f[ 4,, ] + f[ 5,, ] + f[ 6,, ] + f[ 7,, ] + f[ 8,, ] + f[ 9,, ]
			uv[ 1,, ] <-  (f[ 1,, ]*cx[ 1 ] + f[ 2,, ]*cx[ 2 ] + f[ 3,, ]*cx[ 3 ] + f[ 4,, ]*cx[ 4 ] + f[ 5,, ]*cx[ 5 ] + f[ 6,, ]*cx[ 6 ] + f[ 7,, ]*cx[ 7 ] + f[ 8,, ]*cx[ 8 ] + f[ 9,, ]*cx[ 9 ]) / rho[ , ]
			uv[ 2,, ] <- (f[ 1,, ]*cy[ 1 ] + f[ 2,, ]*cy[ 2 ] + f[ 3,, ]*cy[ 3 ] + f[ 4,, ]*cy[ 4 ] + f[ 5,, ]*cy[ 5 ] + f[ 6,, ]*cy[ 6 ] + f[ 7,, ]*cy[ 7 ] + f[ 8,, ]*cy[ 8 ] + f[ 9,, ]*cy[ 9 ]) / rho[ , ]
	 }
	return(uv)
}

[Pharo-dev] Saving and retrieving global settings

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

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

[Cyril Ferlicot D.]

On 14/11/2016 15:50, Denis Kudriashov wrote:
> 
> 2016-11-14 15:37 GMT+01:00 Esteban A. Maringolo  >:
> 
> 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



signature.asc
Description: OpenPGP digital signature

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

[Eliot Miranda]

Hi Thierry,


> On Nov 14, 2016, at 7:04 AM, Thierry Goubier  
> 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?

TIA

> 
> Thierry
> 
> 

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

[Thierry Goubier]

2016-11-14 16:24 GMT+01:00 Clément Bera :

> Hi Thierry,
>
> On the speed center you can compare 32 bits and 64 bits linux VMs:
> http://squeak.org/codespeed/
>
> Interesting to see the rsqueak results on that type of benchs. Mandelbrot
would be the closest.


>
> Normally Pharo 64 should be overall slightly slower than Pharo 32 because
> 70% of the memory is used for pointers, implying twice more data to process
> by the processor for pointer operations. Specific things, for example
> SmallFloat arithmetic, should however be faster on 64 bits.
>

Yes, then it is a lot faster.


>
> For numerical code, benchs can be faster for two main reasons:
> - the bench uses SmallFloat instead of BoxedFloat for most floats it uses
> in 64 bits
> - the bench overflows the 31bits signed integer range for SmallIntegers,
> leading to the usage of LargeInteger in 32 bits, while it does not overflow
> the 61 bits signed integer range in 64 bits. This is typically the case for
> int32 benchs.
>
> Other numerical benchs may be faster on 32 bits.
>
>
> On Mon, Nov 14, 2016 at 4:04 PM, Thierry Goubier <
> thierry.goub...@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.
>>
>> Thierry
>>
>>
>>
>
Thierry

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

[Clément Bera]

Hi Thierry,

On the speed center you can compare 32 bits and 64 bits linux VMs:
http://squeak.org/codespeed/

Normally Pharo 64 should be overall slightly slower than Pharo 32 because
70% of the memory is used for pointers, implying twice more data to process
by the processor for pointer operations. Specific things, for example
SmallFloat arithmetic, should however be faster on 64 bits.

For numerical code, benchs can be faster for two main reasons:
- the bench uses SmallFloat instead of BoxedFloat for most floats it uses
in 64 bits
- the bench overflows the 31bits signed integer range for SmallIntegers,
leading to the usage of LargeInteger in 32 bits, while it does not overflow
the 61 bits signed integer range in 64 bits. This is typically the case for
int32 benchs.

Other numerical benchs may be faster on 32 bits.


On Mon, Nov 14, 2016 at 4:04 PM, Thierry Goubier 
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.
>
> Thierry
>
>
>

Re: [Pharo-dev] #printShowingMaxDecimalPlaces: What do you think?

[Brad]

I vote for the NumberFormatter. It adds another layer, which can be a pain, but 
gives you much more flexibility. Plus it decouples the formatting from all of 
the number classes. VA Smalltalk has something like this. 

Brad Selfridge
913-269-2385

> On Nov 14, 2016, at 8:38 AM, Sven Van Caekenberghe  wrote:
> 
> I am voting against because both methods are very similar while we are trying 
> to clean.
> 
> Also, if I would have to present a number I would personally always prefer 
> the .00 for uniformity.
> 
> But I understand what you want. I think a NumberFormatter object would be 
> better -- what about thousands separators, negative and/or positive sign, 
> different scientific notations, ... ?
> 
> Anyway, just my opinion.
> 
>> On 14 Nov 2016, at 14:56, Cyril Ferlicot D.  wrote:
>> 
>> Hi!
>> 
>> I have a problem in an application, I need to print some numbers with 2
>> decimals max. The numbers can be an Integer, Float or Fraction. I
>> checked and found Number>>#printShowingDecimalPlaces:. This is cool but
>> this is not what I want because when I get "10", I want to print "10"
>> and not "10.00".
>> 
>> So I created a method Number>>#printShowingMaxDecimalPlaces: to do so.
>> At first I made a mistake and I was not the only one. To avoid this kind
>> of mistakes I think this method should be in Pharo by default. This is
>> really useful when building a GUI.
>> 
>> This method already exists in Squeak.
>> 
>> I want to ask to the list, do you think this method should make it in
>> the image? I think this is important but I also know that people do not
>> want to have too much things in the kernel.
>> 
>> So, do you think this is important enough or not?
>> 
>> -- 
>> Cyril Ferlicot
>> 
>> http://www.synectique.eu
>> 
>> 2 rue Jacques Prévert 01,
>> 59650 Villeneuve d'ascq France
>> 
> 
> 

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

[Thierry Goubier]

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.

Thierry

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

[Esteban A. Maringolo]

2016-11-14 11:50 GMT-03:00 Denis Kudriashov :
>
> 2016-11-14 15:37 GMT+01:00 Esteban A. Maringolo :
>>
>> 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.

You're right.

> And we only need to fix Pharo version of Metacello which is already fork.

Which is not there yet.

Quoting myself: "... and would require a new version of Metacello that
contemplates the new
selectors based on some criteria."

Criteria being pharo version, or anything else that identifies the new
pragma semantics.

Regards!

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

[Denis Kudriashov]

2016-11-14 15:37 GMT+01:00 Esteban A. Maringolo :

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

Re: [Pharo-dev] #printShowingMaxDecimalPlaces: What do you think?

[Sven Van Caekenberghe]

I am voting against because both methods are very similar while we are trying 
to clean.

Also, if I would have to present a number I would personally always prefer the 
.00 for uniformity.

But I understand what you want. I think a NumberFormatter object would be 
better -- what about thousands separators, negative and/or positive sign, 
different scientific notations, ... ?

Anyway, just my opinion.

> On 14 Nov 2016, at 14:56, Cyril Ferlicot D.  wrote:
> 
> Hi!
> 
> I have a problem in an application, I need to print some numbers with 2
> decimals max. The numbers can be an Integer, Float or Fraction. I
> checked and found Number>>#printShowingDecimalPlaces:. This is cool but
> this is not what I want because when I get "10", I want to print "10"
> and not "10.00".
> 
> So I created a method Number>>#printShowingMaxDecimalPlaces: to do so.
> At first I made a mistake and I was not the only one. To avoid this kind
> of mistakes I think this method should be in Pharo by default. This is
> really useful when building a GUI.
> 
> This method already exists in Squeak.
> 
> I want to ask to the list, do you think this method should make it in
> the image? I think this is important but I also know that people do not
> want to have too much things in the kernel.
> 
> So, do you think this is important enough or not?
> 
> -- 
> Cyril Ferlicot
> 
> http://www.synectique.eu
> 
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
> 

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

[Esteban A. Maringolo]

2016-11-14 11:27 GMT-03:00 p...@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

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

[p...@highoctane.be]

Breaking Metacello in Pharo 6: Not good. Revert: +1

On Mon, Nov 14, 2016 at 2:16 PM, Esteban Lorenzano 
wrote:

> we need to revert.
> this is a huge mess in a very inappropriate moment :)
>
> Esteban
>
> > On 14 Nov 2016, at 13:56, Tudor Girba  wrote:
> >
> > Hi,
> >
> > Indeed, I forgot that #selector is doing something else. This is a bit
> of a mess. Either we revert it today, or we leave it. Otherwise, more
> projects will adopt the new API only to break again afterwards.
> >
> > Doru
> >
> >> On Nov 14, 2016, at 1:50 PM, Cyril Ferlicot D. <
> cyril.ferli...@gmail.com> wrote:
> >>
> >> On 14/11/2016 13:44, Tudor Girba wrote:
> >>> Hi,
> >>>
> >>> Please do not revert the API. Just comment out the deprecation. The
> code in Moose was already updated to the new API and I presume other
> projects might be in the same situation.
> >>>
> >>> Cheers,
> >>> Doru
> >>>
> >>>
> >>> --
> >>> www.tudorgirba.com
> >>> www.feenk.com
> >>>
> >>> "Be rather willing to give than demanding to get."
> >>>
> >>>
> >>>
> >>
> >> Changing the API without a deprecation phase is bad. This kind of
> >> breaking change without warning is something companies can fear. This is
> >> even more important when there is such a dangerous change. #selector is
> >> still here but do something different… This is bad to just change it in
> >> one go.
> >>
> >> Maybe some projects updated but most companies do not follow the
> >> development version of Pharo.
> >>
> >> --
> >> Cyril Ferlicot
> >>
> >> http://www.synectique.eu
> >>
> >> 2 rue Jacques Prévert 01,
> >> 59650 Villeneuve d'ascq France
> >
> > --
> > www.tudorgirba.com
> > www.feenk.com
> >
> > "It's not how it is, it is how we see it."
> >
> >
>
>
>

Re: [Pharo-dev] macOS Sierra support

[MartinW]

If I try to start the Pharo from the Download page e.g. from my Desktop I get
the following information:

-
Pharo cannot write to the changes file named
/private/var/folders/9p/h6h_ntqs2gs9kztvdp9mrm1mgn/T/AppTranslocation/1CA39D30-C5A9-4599-82F0-8FFA46606D5B/d/Pharo5.0.app/Contents/Resources/Pharo5.0.changes.

Please check that you have write permission for this file.

You won't be able to save this image correctly until you fix this.
-

And Pharo does not work at all, because it tries to write to changes all the
time, of course.
The hint on the Website looks good.



kilon.alios wrote
> This is weird but I have never experienced this "sandbox" thing
> 
> I have Sierra, updated to the latest and when I download this zip to my
> downloads folder, I uncompress it and double click the application without
> moving to the application folder it works without doing anything
> additionally or complaining about it.
> 
> I am almost always do this with applications I download because I like to
> test them before copying them to the application folder. Never had any
> issues.
> 
> So apparently my Sierra loves me :D





--
View this message in context: 
http://forum.world.st/macOS-Sierra-support-tp4917181p4922953.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] #printShowingMaxDecimalPlaces: What do you think?

[Cyril Ferlicot D.]

Hi!

I have a problem in an application, I need to print some numbers with 2
decimals max. The numbers can be an Integer, Float or Fraction. I
checked and found Number>>#printShowingDecimalPlaces:. This is cool but
this is not what I want because when I get "10", I want to print "10"
and not "10.00".

So I created a method Number>>#printShowingMaxDecimalPlaces: to do so.
At first I made a mistake and I was not the only one. To avoid this kind
of mistakes I think this method should be in Pharo by default. This is
really useful when building a GUI.

This method already exists in Squeak.

I want to ask to the list, do you think this method should make it in
the image? I think this is important but I also know that people do not
want to have too much things in the kernel.

So, do you think this is important enough or not?

-- 
Cyril Ferlicot

http://www.synectique.eu

2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France



signature.asc
Description: OpenPGP digital signature

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

[Pavel Krivanek]

We should not revert whole update so I created an issue:
https://pharo.fogbugz.com/f/cases/19338/Revert-18233-improving-Pragma-API

-- Pavel

2016-11-14 14:30 GMT+01:00 Tudor Girba :

> Agreed. So who is doing it?
>
> Doru
>
>
> > On Nov 14, 2016, at 2:16 PM, Esteban Lorenzano 
> wrote:
> >
> > we need to revert.
> > this is a huge mess in a very inappropriate moment :)
> >
> > Esteban
> >
> >> On 14 Nov 2016, at 13:56, Tudor Girba  wrote:
> >>
> >> Hi,
> >>
> >> Indeed, I forgot that #selector is doing something else. This is a bit
> of a mess. Either we revert it today, or we leave it. Otherwise, more
> projects will adopt the new API only to break again afterwards.
> >>
> >> Doru
> >>
> >>> On Nov 14, 2016, at 1:50 PM, Cyril Ferlicot D. <
> cyril.ferli...@gmail.com> wrote:
> >>>
> >>> On 14/11/2016 13:44, Tudor Girba wrote:
>  Hi,
> 
>  Please do not revert the API. Just comment out the deprecation. The
> code in Moose was already updated to the new API and I presume other
> projects might be in the same situation.
> 
>  Cheers,
>  Doru
> 
> 
>  --
>  www.tudorgirba.com
>  www.feenk.com
> 
>  "Be rather willing to give than demanding to get."
> 
> 
> 
> >>>
> >>> Changing the API without a deprecation phase is bad. This kind of
> >>> breaking change without warning is something companies can fear. This
> is
> >>> even more important when there is such a dangerous change. #selector is
> >>> still here but do something different… This is bad to just change it in
> >>> one go.
> >>>
> >>> Maybe some projects updated but most companies do not follow the
> >>> development version of Pharo.
> >>>
> >>> --
> >>> Cyril Ferlicot
> >>>
> >>> http://www.synectique.eu
> >>>
> >>> 2 rue Jacques Prévert 01,
> >>> 59650 Villeneuve d'ascq France
> >>
> >> --
> >> www.tudorgirba.com
> >> www.feenk.com
> >>
> >> "It's not how it is, it is how we see it."
> >>
> >>
> >
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Don't give to get. Just give."
>
>
>
>
>
>
>
>

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

[Tudor Girba]

Agreed. So who is doing it?

Doru


> On Nov 14, 2016, at 2:16 PM, Esteban Lorenzano  wrote:
> 
> we need to revert. 
> this is a huge mess in a very inappropriate moment :)
> 
> Esteban
> 
>> On 14 Nov 2016, at 13:56, Tudor Girba  wrote:
>> 
>> Hi,
>> 
>> Indeed, I forgot that #selector is doing something else. This is a bit of a 
>> mess. Either we revert it today, or we leave it. Otherwise, more projects 
>> will adopt the new API only to break again afterwards.
>> 
>> Doru
>> 
>>> On Nov 14, 2016, at 1:50 PM, Cyril Ferlicot D.  
>>> wrote:
>>> 
>>> On 14/11/2016 13:44, Tudor Girba wrote:
 Hi,
 
 Please do not revert the API. Just comment out the deprecation. The code 
 in Moose was already updated to the new API and I presume other projects 
 might be in the same situation.
 
 Cheers,
 Doru
 
 
 --
 www.tudorgirba.com
 www.feenk.com
 
 "Be rather willing to give than demanding to get."
 
 
 
>>> 
>>> Changing the API without a deprecation phase is bad. This kind of
>>> breaking change without warning is something companies can fear. This is
>>> even more important when there is such a dangerous change. #selector is
>>> still here but do something different… This is bad to just change it in
>>> one go.
>>> 
>>> Maybe some projects updated but most companies do not follow the
>>> development version of Pharo.
>>> 
>>> -- 
>>> Cyril Ferlicot
>>> 
>>> http://www.synectique.eu
>>> 
>>> 2 rue Jacques Prévert 01,
>>> 59650 Villeneuve d'ascq France
>> 
>> --
>> www.tudorgirba.com
>> www.feenk.com
>> 
>> "It's not how it is, it is how we see it."
>> 
>> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Don't give to get. Just give."

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

[Esteban Lorenzano]

we need to revert. 
this is a huge mess in a very inappropriate moment :)

Esteban

> On 14 Nov 2016, at 13:56, Tudor Girba  wrote:
> 
> Hi,
> 
> Indeed, I forgot that #selector is doing something else. This is a bit of a 
> mess. Either we revert it today, or we leave it. Otherwise, more projects 
> will adopt the new API only to break again afterwards.
> 
> Doru
> 
>> On Nov 14, 2016, at 1:50 PM, Cyril Ferlicot D.  
>> wrote:
>> 
>> On 14/11/2016 13:44, Tudor Girba wrote:
>>> Hi,
>>> 
>>> Please do not revert the API. Just comment out the deprecation. The code in 
>>> Moose was already updated to the new API and I presume other projects might 
>>> be in the same situation.
>>> 
>>> Cheers,
>>> Doru
>>> 
>>> 
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>> 
>>> "Be rather willing to give than demanding to get."
>>> 
>>> 
>>> 
>> 
>> Changing the API without a deprecation phase is bad. This kind of
>> breaking change without warning is something companies can fear. This is
>> even more important when there is such a dangerous change. #selector is
>> still here but do something different… This is bad to just change it in
>> one go.
>> 
>> Maybe some projects updated but most companies do not follow the
>> development version of Pharo.
>> 
>> -- 
>> Cyril Ferlicot
>> 
>> http://www.synectique.eu
>> 
>> 2 rue Jacques Prévert 01,
>> 59650 Villeneuve d'ascq France
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "It's not how it is, it is how we see it."
> 
> 

Re: [Pharo-dev] macOS Sierra support

[Esteban Lorenzano]

done

> On 14 Nov 2016, at 13:46, Tudor Girba  wrote:
> 
> Hi,
> 
> Looks good. I would only add explicitly that we are talking about Apple’s 
> security policies.
> 
> “… Due to changes in security policies of MacOS …”
> 
> Cheers,
> Doru
> 
> 
>> On Nov 14, 2016, at 11:36 AM, Esteban Lorenzano  wrote:
>> 
>> for the moment, I added this nice (?) alert when you press mac download 
>> button: 
>> 
>> 
>> 
>>> On 14 Nov 2016, at 11:30, Esteban Lorenzano  wrote:
>>> 
>>> 
 On 14 Nov 2016, at 11:01, MartinW  wrote:
 
 Can someone put a note to the website (http://pharo.org/download)? It is
 frustrating for users to follow the link to
 http://files.pharo.org/platform/Pharo5.0-mac.zip from there and get a
 defunct Pharo installation.
>>> 
>>> no, in fact that link should work. 
>>> … and in fact, it works… is just that due the changes in sierra, the bundle 
>>> needs to be put in /Applications to not be copied into a sandbox, readonly 
>>> place. 
>>> 
>>> I’m working on have this working in a different way: is time to make 
>>> PharoLauncher the default download. That way it will be in /Applications 
>>> naturally and your images will be in a correct place naturally (I also 
>>> would like a “add command line tools” option to install a pharo and 
>>> pharo-ui in /usr/local/bin).
>>> 
>>> Esteban
>>> 
 
 
 Sean P. DeNigris wrote
> 
> EstebanLM wrote
>> the regular download by zeroconf should give you an usable VM.
> That worked - thanks!
 
 Yes, this VM works well :)
 
 
 
 --
 View this message in context: 
 http://forum.world.st/macOS-Sierra-support-tp4917181p4922891.html
 Sent from the Pharo Smalltalk Developers mailing list archive at 
 Nabble.com.
 
>>> 
>> 
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "We are all great at making mistakes."
> 
> 
> 
> 
> 
> 
> 
> 
> 

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

[Tudor Girba]

Hi,

Indeed, I forgot that #selector is doing something else. This is a bit of a 
mess. Either we revert it today, or we leave it. Otherwise, more projects will 
adopt the new API only to break again afterwards.

Doru

> On Nov 14, 2016, at 1:50 PM, Cyril Ferlicot D.  
> wrote:
> 
> On 14/11/2016 13:44, Tudor Girba wrote:
>> Hi,
>> 
>> Please do not revert the API. Just comment out the deprecation. The code in 
>> Moose was already updated to the new API and I presume other projects might 
>> be in the same situation.
>> 
>> Cheers,
>> Doru
>> 
>> 
>> --
>> www.tudorgirba.com
>> www.feenk.com
>> 
>> "Be rather willing to give than demanding to get."
>> 
>> 
>> 
> 
> Changing the API without a deprecation phase is bad. This kind of
> breaking change without warning is something companies can fear. This is
> even more important when there is such a dangerous change. #selector is
> still here but do something different… This is bad to just change it in
> one go.
> 
> Maybe some projects updated but most companies do not follow the
> development version of Pharo.
> 
> -- 
> Cyril Ferlicot
> 
> http://www.synectique.eu
> 
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France

--
www.tudorgirba.com
www.feenk.com

"It's not how it is, it is how we see it."

[Pharo-dev] [pharo-project/pharo-core] 75a952: 60290

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 75a9520e8197d944ecb87843f77c9cec5030950b
  
https://github.com/pharo-project/pharo-core/commit/75a9520e8197d944ecb87843f77c9cec5030950b
  Author: Jenkins Build Server 
  Date:   2016-11-14 (Mon, 14 Nov 2016)

  Changed paths:
M AST-Core.package/RBComment.class/README.md
R 
Athens-Morphic.package/extension/TabActionButton/instance/drawOnAthensCanvas_.st
M 
Morphic-Base.package/StringMorph.class/class/examples/exampleFullEmphaisedString.st
M 
Morphic-Examples.package/TabExample.class/instance/initialization/initialize.st
R Morphic-Widgets-Tabs.package/TabActionButton.class/README.md
R Morphic-Widgets-Tabs.package/TabActionButton.class/class/instance 
creation/forAction_.st
R Morphic-Widgets-Tabs.package/TabActionButton.class/definition.st
R 
Morphic-Widgets-Tabs.package/TabActionButton.class/instance/accessing/icon_.st
R 
Morphic-Widgets-Tabs.package/TabActionButton.class/instance/drawing/drawOn_.st
R Morphic-Widgets-Tabs.package/TabActionButton.class/instance/instance 
creation/forAction_.st
A Morphic-Widgets-Tabs.package/TabActionButtonMorph.class/README.md
A Morphic-Widgets-Tabs.package/TabActionButtonMorph.class/class/instance 
creation/forAction_.st
A Morphic-Widgets-Tabs.package/TabActionButtonMorph.class/definition.st
A 
Morphic-Widgets-Tabs.package/TabActionButtonMorph.class/instance/accessing/icon_.st
A 
Morphic-Widgets-Tabs.package/TabActionButtonMorph.class/instance/drawing/drawOn_.st
A Morphic-Widgets-Tabs.package/TabActionButtonMorph.class/instance/instance 
creation/forAction_.st
M 
Morphic-Widgets-Tabs.package/TabBarMorph.class/instance/private/createActionButtonFor_.st
R Morphic-Widgets-Tabs.package/TabManager.class/README.md
R Morphic-Widgets-Tabs.package/TabManager.class/definition.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/accessing/adoptPaneColor_.st
R Morphic-Widgets-Tabs.package/TabManager.class/instance/accessing/model.st
R Morphic-Widgets-Tabs.package/TabManager.class/instance/accessing/model_.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/accessing/setTabs_.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/drawing-private/borderColor.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/drawing/drawLinesOn_.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/drawing/drawSubmorphsOn_.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/initialization/initialize.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/initialize/minExtent.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/initialize/registerBarActions.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/initialize/registerShortcuts.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/private-actions/barDeleted_.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/private-actions/deleteSelectedTabs.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/private-actions/selectLastTab.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/private-actions/selectNext.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/private-actions/selectPrevious.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/private-actions/selectTabAt_.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/private-actions/tabAddedToSelection_.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/private-actions/tabEmptyContents_.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/private-actions/tabRefreshed_.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/private-actions/tabRemovedFromSelection_.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/private-actions/tabResetSelection_.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/private-actions/tabSelected_.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/private-actions/tabsChanged.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/private-contents/addLastTabContents_among_delta_.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/private-contents/addSplitterOn_delta_.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/private-contents/addTabContents_at_delta_.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/private/addMorphs.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/private/cleanProcesses.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/private/setMultipleContents.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/private/setTabContentFrom_.st
R Morphic-Widgets-Tabs.package/TabManager.class/instance/protocol/addTab_.st
R 
Morphic-Widgets-Tabs.package/TabManager.class/instance/protocol/canBeClosed.st
R Morphic-Widgets-T

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/60290
  Home:   https://github.com/pharo-project/pharo-core

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

[Cyril Ferlicot D.]

On 14/11/2016 13:44, Tudor Girba wrote:
> Hi,
> 
> Please do not revert the API. Just comment out the deprecation. The code in 
> Moose was already updated to the new API and I presume other projects might 
> be in the same situation.
> 
> Cheers,
> Doru
> 
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Be rather willing to give than demanding to get."
> 
> 
> 

Changing the API without a deprecation phase is bad. This kind of
breaking change without warning is something companies can fear. This is
even more important when there is such a dangerous change. #selector is
still here but do something different… This is bad to just change it in
one go.

Maybe some projects updated but most companies do not follow the
development version of Pharo.

-- 
Cyril Ferlicot

http://www.synectique.eu

2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] macOS Sierra support

[Tudor Girba]

Hi,

Looks good. I would only add explicitly that we are talking about Apple’s 
security policies.

“… Due to changes in security policies of MacOS …”

Cheers,
Doru


> On Nov 14, 2016, at 11:36 AM, Esteban Lorenzano  wrote:
> 
> for the moment, I added this nice (?) alert when you press mac download 
> button: 
> 
> 
> 
>> On 14 Nov 2016, at 11:30, Esteban Lorenzano  wrote:
>> 
>> 
>>> On 14 Nov 2016, at 11:01, MartinW  wrote:
>>> 
>>> Can someone put a note to the website (http://pharo.org/download)? It is
>>> frustrating for users to follow the link to
>>> http://files.pharo.org/platform/Pharo5.0-mac.zip from there and get a
>>> defunct Pharo installation.
>> 
>> no, in fact that link should work. 
>> … and in fact, it works… is just that due the changes in sierra, the bundle 
>> needs to be put in /Applications to not be copied into a sandbox, readonly 
>> place. 
>> 
>> I’m working on have this working in a different way: is time to make 
>> PharoLauncher the default download. That way it will be in /Applications 
>> naturally and your images will be in a correct place naturally (I also would 
>> like a “add command line tools” option to install a pharo and pharo-ui in 
>> /usr/local/bin).
>> 
>> Esteban
>> 
>>> 
>>> 
>>> Sean P. DeNigris wrote
 
 EstebanLM wrote
> the regular download by zeroconf should give you an usable VM.
 That worked - thanks!
>>> 
>>> Yes, this VM works well :)
>>> 
>>> 
>>> 
>>> --
>>> View this message in context: 
>>> http://forum.world.st/macOS-Sierra-support-tp4917181p4922891.html
>>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>>> 
>> 
> 

--
www.tudorgirba.com
www.feenk.com

"We are all great at making mistakes."

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

[Tudor Girba]

Hi,

Please do not revert the API. Just comment out the deprecation. The code in 
Moose was already updated to the new API and I presume other projects might be 
in the same situation.

Cheers,
Doru


> On Nov 14, 2016, at 10:00 AM, Pavel Krivanek  wrote:
> 
> Revert the new API. It was mistake to integrate it in the code freeze phase.
> 
> -- Pavel
> 
> 2016-11-14 9:53 GMT+01:00 Nicolai Hess :
> 
> 
> 2016-11-14 9:42 GMT+01:00 Pavel Krivanek :
> Well, we will revert the change
> 
> 
> revert the autodeprecation or the new api ? 
> I made a fix for case 19336 Finder and FileList can now work with the new api.
>  
> -- Pavel
> 
> 2016-11-13 17:33 GMT+01:00 Nicolai Hess :
> 
> 
> 2016-11-13 10:06 GMT+01:00 Nicolai Hess :
> 
> 
> 2016-11-11 10:55 GMT+01:00 Pavel Krivanek :
> Hi,
> 
> the API of Pragma was changed in quite dangerous way.
> In past we had: 
> - #selector to access to method selector
> - #keyword to access to pragma selector
> 
> now we have:
> - #methodSelector to access to method selector
> - #selector to access to pragma selector
> 
> That means that the meaning of the message #selector was changed and it can 
> cause some problems (like some currently failing tests [1]). The #selector 
> message was deprecated in the middle of the transition process so most of 
> usages should be already rewritten to #methodSelector but we need to be aware 
> of it.
> 
> [1] 
> https://pharo.fogbugz.com/f/cases/19333/17-more-tests-failing-due-to-MockSettings-class-Object-doesNotUnderstand-mocksystemsettings-SettingTreeBuilder-mocksystemse
> 
> And it broke finder.
> 19336 Finder broken: Can not search for pragmas
> 
> And FileList can not show .cs files anymore.
> I think both has something to do with a lock (?) during the transform of the 
> autodeprecation.
>  
>  
> 
> Cheers
> -- Pavel
> 
> 
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Be rather willing to give than demanding to get."

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

[philippe.b...@highoctane.be]

Great.

Le 14 nov. 2016 11:23, "Esteban Lorenzano"  a écrit :

>
> On 14 Nov 2016, at 10:00, Pavel Krivanek  wrote:
>
> Revert the new API. It was mistake to integrate it in the code freeze
> phase.
>
>
> yep, that’s accurate :)
>
> Esteban
>
>
> -- Pavel
>
> 2016-11-14 9:53 GMT+01:00 Nicolai Hess :
>
>>
>>
>> 2016-11-14 9:42 GMT+01:00 Pavel Krivanek :
>>
>>> Well, we will revert the change
>>>
>>>
>> revert the autodeprecation or the new api ?
>> I made a fix for case 19336 Finder and FileList can now work with the new
>> api.
>>
>>
>>> -- Pavel
>>>
>>> 2016-11-13 17:33 GMT+01:00 Nicolai Hess :
>>>


 2016-11-13 10:06 GMT+01:00 Nicolai Hess :

>
>
> 2016-11-11 10:55 GMT+01:00 Pavel Krivanek :
>
>> Hi,
>>
>> the API of Pragma was changed in quite dangerous way.
>> In past we had:
>> - #selector to access to method selector
>> - #keyword to access to pragma selector
>>
>> now we have:
>> - #methodSelector to access to method selector
>> - #selector to access to pragma selector
>>
>> That means that the meaning of the message #selector was changed and
>> it can cause some problems (like some currently failing tests [1]). The
>> #selector message was deprecated in the middle of the transition process 
>> so
>> most of usages should be already rewritten to #methodSelector but we
>> need to be aware of it.
>>
>> [1] https://pharo.fogbugz.com/f/cases/19333/17-more-tests-fa
>> iling-due-to-MockSettings-class-Object-doesNotUnderstand-moc
>> ksystemsettings-SettingTreeBuilder-mocksystemse
>>
>
> And it broke finder.
> 19336
> 
> Finder broken: Can not search for pragmas
>

 And FileList can not show .cs files anymore.
 I think both has something to do with a lock (?) during the transform
 of the autodeprecation.


>
>
>>
>> Cheers
>> -- Pavel
>>
>
>

>>>
>>
>
>

Re: [Pharo-dev] macOS Sierra support

[Dimitris Chloupis]

This is weird but I have never experienced this "sandbox" thing

I have Sierra, updated to the latest and when I download this zip to my
downloads folder, I uncompress it and double click the application without
moving to the application folder it works without doing anything
additionally or complaining about it.

I am almost always do this with applications I download because I like to
test them before copying them to the application folder. Never had any
issues.

So apparently my Sierra loves me :D

On Mon, Nov 14, 2016 at 12:31 PM Esteban Lorenzano 
wrote:

>
> > On 14 Nov 2016, at 11:01, MartinW  wrote:
> >
> > Can someone put a note to the website (http://pharo.org/download)? It is
> > frustrating for users to follow the link to
> > http://files.pharo.org/platform/Pharo5.0-mac.zip from there and get a
> > defunct Pharo installation.
>
> no, in fact that link should work.
> … and in fact, it works… is just that due the changes in sierra, the
> bundle needs to be put in /Applications to not be copied into a sandbox,
> readonly place.
>
> I’m working on have this working in a different way: is time to make
> PharoLauncher the default download. That way it will be in /Applications
> naturally and your images will be in a correct place naturally (I also
> would like a “add command line tools” option to install a pharo and
> pharo-ui in /usr/local/bin).
>
> Esteban
>
> >
> >
> > Sean P. DeNigris wrote
> >>
> >> EstebanLM wrote
> >>> the regular download by zeroconf should give you an usable VM.
> >> That worked - thanks!
> >
> > Yes, this VM works well :)
> >
> >
> >
> > --
> > View this message in context:
> http://forum.world.st/macOS-Sierra-support-tp4917181p4922891.html
> > Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
> >
>
>
>

Re: [Pharo-dev] macOS Sierra support

[Esteban Lorenzano]

for the moment, I added this nice (?) alert when you press mac download button: 



> On 14 Nov 2016, at 11:30, Esteban Lorenzano  wrote:
> 
> 
>> On 14 Nov 2016, at 11:01, MartinW  wrote:
>> 
>> Can someone put a note to the website (http://pharo.org/download)? It is
>> frustrating for users to follow the link to
>> http://files.pharo.org/platform/Pharo5.0-mac.zip from there and get a
>> defunct Pharo installation.
> 
> no, in fact that link should work. 
> … and in fact, it works… is just that due the changes in sierra, the bundle 
> needs to be put in /Applications to not be copied into a sandbox, readonly 
> place. 
> 
> I’m working on have this working in a different way: is time to make 
> PharoLauncher the default download. That way it will be in /Applications 
> naturally and your images will be in a correct place naturally (I also would 
> like a “add command line tools” option to install a pharo and pharo-ui in 
> /usr/local/bin).
> 
> Esteban
> 
>> 
>> 
>> Sean P. DeNigris wrote
>>> 
>>> EstebanLM wrote
 the regular download by zeroconf should give you an usable VM.
>>> That worked - thanks!
>> 
>> Yes, this VM works well :)
>> 
>> 
>> 
>> --
>> View this message in context: 
>> http://forum.world.st/macOS-Sierra-support-tp4917181p4922891.html
>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>> 
> 

Re: [Pharo-dev] macOS Sierra support

[Esteban Lorenzano]

> On 14 Nov 2016, at 11:01, MartinW  wrote:
> 
> Can someone put a note to the website (http://pharo.org/download)? It is
> frustrating for users to follow the link to
> http://files.pharo.org/platform/Pharo5.0-mac.zip from there and get a
> defunct Pharo installation.

no, in fact that link should work. 
… and in fact, it works… is just that due the changes in sierra, the bundle 
needs to be put in /Applications to not be copied into a sandbox, readonly 
place. 

I’m working on have this working in a different way: is time to make 
PharoLauncher the default download. That way it will be in /Applications 
naturally and your images will be in a correct place naturally (I also would 
like a “add command line tools” option to install a pharo and pharo-ui in 
/usr/local/bin).

Esteban

> 
> 
> Sean P. DeNigris wrote
>> 
>> EstebanLM wrote
>>> the regular download by zeroconf should give you an usable VM.
>> That worked - thanks!
> 
> Yes, this VM works well :)
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/macOS-Sierra-support-tp4917181p4922891.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
> 

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

[Esteban Lorenzano]

> On 14 Nov 2016, at 10:00, Pavel Krivanek  wrote:
> 
> Revert the new API. It was mistake to integrate it in the code freeze phase.

yep, that’s accurate :)

Esteban

> 
> -- Pavel
> 
> 2016-11-14 9:53 GMT+01:00 Nicolai Hess  >:
> 
> 
> 2016-11-14 9:42 GMT+01:00 Pavel Krivanek  >:
> Well, we will revert the change
> 
> 
> revert the autodeprecation or the new api ? 
> I made a fix for case 19336 Finder and FileList can now work with the new api.
>  
> -- Pavel
> 
> 2016-11-13 17:33 GMT+01:00 Nicolai Hess  >:
> 
> 
> 2016-11-13 10:06 GMT+01:00 Nicolai Hess  >:
> 
> 
> 2016-11-11 10:55 GMT+01:00 Pavel Krivanek  >:
> Hi,
> 
> the API of Pragma was changed in quite dangerous way.
> In past we had: 
> - #selector to access to method selector
> - #keyword to access to pragma selector
> 
> now we have:
> - #methodSelector to access to method selector
> - #selector to access to pragma selector
> 
> That means that the meaning of the message #selector was changed and it can 
> cause some problems (like some currently failing tests [1]). The #selector 
> message was deprecated in the middle of the transition process so most of 
> usages should be already rewritten to #methodSelector but we need to be aware 
> of it.
> 
> [1] 
> https://pharo.fogbugz.com/f/cases/19333/17-more-tests-failing-due-to-MockSettings-class-Object-doesNotUnderstand-mocksystemsettings-SettingTreeBuilder-mocksystemse
> 
> And it broke finder.
> 19336 
> 
>  Finder broken: Can not search for pragmas
> 
> And FileList can not show .cs files anymore.
> I think both has something to do with a lock (?) during the transform of the 
> autodeprecation.
>  
>  
> 
> Cheers
> -- Pavel
> 
> 
> 
> 
> 

Re: [Pharo-dev] macOS Sierra support

[MartinW]

Can someone put a note to the website (http://pharo.org/download)? It is
frustrating for users to follow the link to
http://files.pharo.org/platform/Pharo5.0-mac.zip from there and get a
defunct Pharo installation.


Sean P. DeNigris wrote
> 
> EstebanLM wrote
>> the regular download by zeroconf should give you an usable VM.
> That worked - thanks!

Yes, this VM works well :)



--
View this message in context: 
http://forum.world.st/macOS-Sierra-support-tp4917181p4922891.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

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

[Pavel Krivanek]

Revert the new API. It was mistake to integrate it in the code freeze phase.

-- Pavel

2016-11-14 9:53 GMT+01:00 Nicolai Hess :

>
>
> 2016-11-14 9:42 GMT+01:00 Pavel Krivanek :
>
>> Well, we will revert the change
>>
>>
> revert the autodeprecation or the new api ?
> I made a fix for case 19336 Finder and FileList can now work with the new
> api.
>
>
>> -- Pavel
>>
>> 2016-11-13 17:33 GMT+01:00 Nicolai Hess :
>>
>>>
>>>
>>> 2016-11-13 10:06 GMT+01:00 Nicolai Hess :
>>>


 2016-11-11 10:55 GMT+01:00 Pavel Krivanek :

> Hi,
>
> the API of Pragma was changed in quite dangerous way.
> In past we had:
> - #selector to access to method selector
> - #keyword to access to pragma selector
>
> now we have:
> - #methodSelector to access to method selector
> - #selector to access to pragma selector
>
> That means that the meaning of the message #selector was changed and
> it can cause some problems (like some currently failing tests [1]). The
> #selector message was deprecated in the middle of the transition process 
> so
> most of usages should be already rewritten to #methodSelector but we
> need to be aware of it.
>
> [1] https://pharo.fogbugz.com/f/cases/19333/17-more-tests-fa
> iling-due-to-MockSettings-class-Object-doesNotUnderstand-moc
> ksystemsettings-SettingTreeBuilder-mocksystemse
>

 And it broke finder.
 19336
 
 Finder broken: Can not search for pragmas

>>>
>>> And FileList can not show .cs files anymore.
>>> I think both has something to do with a lock (?) during the transform of
>>> the autodeprecation.
>>>
>>>


>
> Cheers
> -- Pavel
>


>>>
>>
>

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

[Nicolai Hess]

2016-11-14 9:42 GMT+01:00 Pavel Krivanek :

> Well, we will revert the change
>
>
revert the autodeprecation or the new api ?
I made a fix for case 19336 Finder and FileList can now work with the new
api.


> -- Pavel
>
> 2016-11-13 17:33 GMT+01:00 Nicolai Hess :
>
>>
>>
>> 2016-11-13 10:06 GMT+01:00 Nicolai Hess :
>>
>>>
>>>
>>> 2016-11-11 10:55 GMT+01:00 Pavel Krivanek :
>>>
 Hi,

 the API of Pragma was changed in quite dangerous way.
 In past we had:
 - #selector to access to method selector
 - #keyword to access to pragma selector

 now we have:
 - #methodSelector to access to method selector
 - #selector to access to pragma selector

 That means that the meaning of the message #selector was changed and it
 can cause some problems (like some currently failing tests [1]). The
 #selector message was deprecated in the middle of the transition process so
 most of usages should be already rewritten to #methodSelector but we
 need to be aware of it.

 [1] https://pharo.fogbugz.com/f/cases/19333/17-more-tests-fa
 iling-due-to-MockSettings-class-Object-doesNotUnderstand-moc
 ksystemsettings-SettingTreeBuilder-mocksystemse

>>>
>>> And it broke finder.
>>> 19336
>>> 
>>> Finder broken: Can not search for pragmas
>>>
>>
>> And FileList can not show .cs files anymore.
>> I think both has something to do with a lock (?) during the transform of
>> the autodeprecation.
>>
>>
>>>
>>>

 Cheers
 -- Pavel

>>>
>>>
>>
>

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

[Pavel Krivanek]

Well, we will revert the change

-- Pavel

2016-11-13 17:33 GMT+01:00 Nicolai Hess :

>
>
> 2016-11-13 10:06 GMT+01:00 Nicolai Hess :
>
>>
>>
>> 2016-11-11 10:55 GMT+01:00 Pavel Krivanek :
>>
>>> Hi,
>>>
>>> the API of Pragma was changed in quite dangerous way.
>>> In past we had:
>>> - #selector to access to method selector
>>> - #keyword to access to pragma selector
>>>
>>> now we have:
>>> - #methodSelector to access to method selector
>>> - #selector to access to pragma selector
>>>
>>> That means that the meaning of the message #selector was changed and it
>>> can cause some problems (like some currently failing tests [1]). The
>>> #selector message was deprecated in the middle of the transition process so
>>> most of usages should be already rewritten to #methodSelector but we
>>> need to be aware of it.
>>>
>>> [1] https://pharo.fogbugz.com/f/cases/19333/17-more-tests-fa
>>> iling-due-to-MockSettings-class-Object-doesNotUnderstand-moc
>>> ksystemsettings-SettingTreeBuilder-mocksystemse
>>>
>>
>> And it broke finder.
>> 19336
>> 
>> Finder broken: Can not search for pragmas
>>
>
> And FileList can not show .cs files anymore.
> I think both has something to do with a lock (?) during the transform of
> the autodeprecation.
>
>
>>
>>
>>>
>>> Cheers
>>> -- Pavel
>>>
>>
>>
>