Pharo-dev

By thread

pharo-dev@lists.pharo.org

March 2014

63 participants
1299 messages

Re: [Pharo-dev] someone using Magritte-Morph?

by Tudor Girba

Glamour is embedding Magritte-Morph. But, we do not typically use a list description, though. Doru On Thu, Mar 27, 2014 at 1:02 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > Hi, > > It looks to me that this: > > MAListMorph>>#strings > ^ self options collect: [ :each | self magritteDescription > reference toString: each ] > > should instead be: > > MAListMorph>>#strings > ^ self options collect: [ :each | self magritteDescription > displayStringFor: each ] > > what do you think? > > Esteban > -- www.tudorgirba.com "Every thing has its own flow"

March 27, 2014

someone using Magritte-Morph?

by Esteban Lorenzano

Hi, It looks to me that this: MAListMorph>>#strings ^ self options collect: [ :each | self magritteDescription reference toString: each ] should instead be: MAListMorph>>#strings ^ self options collect: [ :each | self magritteDescription displayStringFor: each ] what do you think? Esteban

March 27, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] fec020: 30804

by Damien Cassou

On Thu, Mar 27, 2014 at 10:00 AM, GitHub <noreply(a)github.com> wrote: > 13128 Use Spotlight to quickly evaluate and inspect short expressions > https://pharo.fogbugz.com/f/cases/13128 > this looks definitely like a feature to me and not a bug fix. I'm not blaming anyone, but it would be good that features stop entering the image. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

March 27, 2014

Re: [Pharo-dev] DateAndTime>>#= slow?

by Sven Van Caekenberghe

On 27 Mar 2014, at 11:55, Johan Brichau <johan(a)inceptive.be> wrote: > On 27 Mar 2014, at 11:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> It is slow(er) in 2 and fast(er) in 3, according to this discussion and my reading of the code. If you see the inverse, than please provide some details. > > We come from Pharo 1.4, where our timing benchmarks that use a lot of DateAndTime operations run 4x faster (in Gemstone too). > It is indeed faster in 3 than in 2. (I believe because of a wait in de DateAndTime creation that has to do with clock precision). > > Johan An x4 (400%) slowdown sounds like an unacceptable regression to me. Could you maybe provide some benchmark ? I did a quick one (in Pharo 3): [ | timestamps | timestamps := Array streamContents: [ :out | 1024 timesRepeat: [ out nextPut: (DateAndTime now - (60*60*24*265) atRandom seconds) ] ]. 64 timesRepeat: [ timestamps sorted ]. timestamps sort. timestamps collect: [ :each | timestamps includes: each ] ] timeToRun. => "0:00:00:09.491" In 1.4, this is indeed about 40 times faster: [ | timestamps | timestamps := Array streamContents: [ :out | 1024 timesRepeat: [ out nextPut: (DateAndTime now - (60*60*24*265) atRandom seconds) ] ]. 64 timesRepeat: [ timestamps sorted ]. timestamps sort. timestamps collect: [ :each | timestamps includes: each ] ] timeToRun milliSeconds. => "0:00:00:00.228" For this test, ZTimestamp is 100 times faster: [ | timestamps | timestamps := Array streamContents: [ :out | 1024 timesRepeat: [ out nextPut: (ZTimestamp now - (60*60*24*265) atRandom seconds) ] ]. 64 timesRepeat: [ timestamps sorted ]. timestamps sort. timestamps collect: [ :each | timestamps includes: each ] ] timeToRun. => "0:00:00:00.07" Looking at this with the Time Profiler, I see that DateAndTime>>#asSeconds (used in #<) takes 95% of the time. I am pretty sure we can fix this. I'll make an issue and slice later on. Sven

March 27, 2014

Re: [Pharo-dev] DateAndTime>>#= slow?

by Johan Brichau

On 27 Mar 2014, at 11:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > It is slow(er) in 2 and fast(er) in 3, according to this discussion and my reading of the code. If you see the inverse, than please provide some details. We come from Pharo 1.4, where our timing benchmarks that use a lot of DateAndTime operations run 4x faster (in Gemstone too). It is indeed faster in 3 than in 2. (I believe because of a wait in de DateAndTime creation that has to do with clock precision). Johan

March 27, 2014

Re: [Pharo-dev] DateAndTime>>#= slow?

by Sven Van Caekenberghe

On 27 Mar 2014, at 11:17, Johan Brichau <johan(a)inceptive.be> wrote: > Hi, > > This is indeed something we noticed moving to Pharo3: all our benchmarks fail because of DateAndTime being slower. ?? It is slow(er) in 2 and fast(er) in 3, according to this discussion and my reading of the code. If you see the inverse, than please provide some details. > Since we use Pharo only for development, it's not a showstopper for us, but definitely an issue we are interested to help solving too. > > Johan > > On 26 Mar 2014, at 22:53, Stephan Eggermont <stephan(a)stack.nl> wrote: > >> DateAndTime is a very good candidate for some slot-tricks, >> and should probably be a value object. >> >> Stephan >> >> > >

March 27, 2014

Re: [Pharo-dev] DateAndTime>>#= slow?

by phil＠highoctane.be

Given the fact that I am using a ton of time series at the moment, I feel that I'll be caught in this as well (Pharo for dev & prod). What about having a look at this through a Google Hangout? Phil On Thu, Mar 27, 2014 at 11:17 AM, Johan Brichau <johan(a)inceptive.be> wrote: > Hi, > > This is indeed something we noticed moving to Pharo3: all our benchmarks > fail because of DateAndTime being slower. > Since we use Pharo only for development, it's not a showstopper for us, > but definitely an issue we are interested to help solving too. > > Johan > > On 26 Mar 2014, at 22:53, Stephan Eggermont <stephan(a)stack.nl> wrote: > > > DateAndTime is a very good candidate for some slot-tricks, > > and should probably be a value object. > > > > Stephan > > > > > > >

March 27, 2014

Re: [Pharo-dev] DateAndTime>>#= slow?

by Johan Brichau

Hi, This is indeed something we noticed moving to Pharo3: all our benchmarks fail because of DateAndTime being slower. Since we use Pharo only for development, it's not a showstopper for us, but definitely an issue we are interested to help solving too. Johan On 26 Mar 2014, at 22:53, Stephan Eggermont <stephan(a)stack.nl> wrote: > DateAndTime is a very good candidate for some slot-tricks, > and should probably be a value object. > > Stephan > >

March 27, 2014

ci shutdown Saturday

by Marcus Denker

Hi, The CI will be down over the weekend: > As you may have been informed, Inria DSI has to perform a major update on > its storage infrastructure on Saturday March 29th 2014. This will induce > the disruption of all the numerical services, including CI. > > To take benefit from this downtime, the CloudStack secondary storage of CI > service will be upgraded, thus the service will likely be unavailable this > weekend. To avoid any issue, you may shutdown your Jenkins servers from the > web portal before the weekend.

March 27, 2014

Re: [Pharo-dev] Replacing SBCI buttons in Nautilus.

by Stephan Eggermont

Phil wrote: >Instead of using PluggableButtonMorphs, you can try with ButtonModels (the Spec way). For Pharo 3 Iâd prefer not adding additional dependencies to Nautilus. I think I remember reading something about a spec-based Nautilus. Switching the themes shows that there are still a few too many hard-coded values in Nautilus. The width of the SBIC bar should be theme dependent. Stephan

March 27, 2014

Jump to page: