March 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANN] Application Security for your domains

by Sebastian Sastre

cool stuff, thanks for sharing! Iâve shared your post on social media On Mar 27, 2014, at 8:58 PM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Hello guys, > I'm doing a double announcement here. > > First, a new blog about development with Pharo, and Smalltalk: > > http://80738163270632.blogspot.com.ar/ > > Second, my first entry contains a post about Application Security, a new package to make Pharo applications more secure. You can start playing with the objects right now, while more documentation is being written for the next release. > > Hope you like it and I'm looking forward to hearing from you. > Cheers, > > HernÃ¡n >

March 28, 2014

[ANN] Application Security for your domains

by HernÃ¡n Morales Durand

Hello guys, I'm doing a double announcement here. First, a new blog about development with Pharo, and Smalltalk: http://80738163270632.blogspot.com.ar/ Second, my first entry contains a post about Application Security, a new package to make Pharo applications more secure. You can start playing with the objects right now, while more documentation is being written for the next release. Hope you like it and I'm looking forward to hearing from you. Cheers, HernÃ¡n

March 27, 2014

Re: [Pharo-dev] Smalltalkhub & API

by Stephan Eggermont

Tobias wrote: >I dl'ed the latest that was tagged 2.0, but it comes >just with the configuration loaded. Trying to load that >eventually kills the VMâ¦ Good find. The 0.9.2 baseline only has a pharo3.x version, and that is the one getting buildâ¦ The tests in the Pharo2 version donât seem to catch that :) Iâm not sure why it kills the vm. It hopes to connect to a local mongodb. 0.9.2-baseline might load in 2 by removing the 3.x, but I havenât tried. I canât commit in NicolasPetton/SmalltalkHub Stephan

March 27, 2014

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

by Ben Coman

Sven Van Caekenberghe wrote: > Umbrella issue: > https://pharo.fogbugz.com/f/cases/13139/Speed-Regressions-in-DateAndTime > > I rewrote (and simplified) DateAndTime>>#+ #- #= > I added caching for #epoch > I switched the localTimeZone to an #asFixedTimeZone variant > > My benchmark now runs 40x FASTER than in Pharo 1.4 > > All Chronology tests remain green > I will upload slices when the funding goal of 1,000,000 USD is reached on https://www.kickstarter.com/projects/1003214829/improve-pharo-dateandtime-p… > PS: Half of the funds will go to Camillo for making DateAndTime work in UTC internally ;-) > > PS2: I am not sure I am allowed to fix this so close to release, is it a feature or a bug fix ? ;-) > I would say poor performance is a bug, and if nothing has change in the API, then its not a "new feature" so this should be integrated. Esteban Lorenzano wrote: > > pharo3 is at the corner to be out. > we are not integrating/backporting changes to pharo2 sinceâ¦ well, like 6 months. > so no, it will not be there and it will not be integrated. Can you clarify your position that (hopefully) "will not be integrated" refers to just to Pharo 2. cheers -ben

March 27, 2014

Re: [Pharo-dev] Smalltalkhub & API

by Sven Van Caekenberghe

On 27 Mar 2014, at 23:29, Tobias Pape <Das.Linux(a)gmx.de> wrote: > On 27.03.2014, at 21:36, Stephan Eggermont <stephan(a)stack.nl> wrote: > >> Hi Phil, >> >> Did you take a look at a smalltalkhub image >> https://ci.inria.fr/pharo-contribution/job/SmalltalkHub/ >> The Hub package provides a starting point. > > I dl'ed the latest that was tagged 2.0, but it comes > just with the configuration loaded. Trying to load that > eventually kills the VMâ¦ > > Best > -Tobias > IIRC, you have to have MongoDB running before you start the image.

March 27, 2014

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

by Sven Van Caekenberghe

But if you have a reasonably recent 3.0 image somewhere, you can try merging as well. If all is good you see only 3 changed methods (#- #+ and #<). Even if you see more changes, you could try only importing those. On 27 Mar 2014, at 23:13, Stephan Eggermont <stephan(a)stack.nl> wrote: > Esteban wrote >> How do I test it? >> Do I have to download a whole new 3.0 image? > > Normal way to test is to download latest 3.0 image > and run it (on latest vm). > Open monticello, open Pharo30Inbox, > Type the issue number to find the slice > and merge it to see changes. > > Stephan >

March 27, 2014

Re: [Pharo-dev] Smalltalkhub & API

by Tobias Pape

On 27.03.2014, at 21:36, Stephan Eggermont <stephan(a)stack.nl> wrote: > Hi Phil, > > Did you take a look at a smalltalkhub image > https://ci.inria.fr/pharo-contribution/job/SmalltalkHub/ > The Hub package provides a starting point. I dl'ed the latest that was tagged 2.0, but it comes just with the configuration loaded. Trying to load that eventually kills the VMâ¦ Best -Tobias

March 27, 2014

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

by Stephan Eggermont

Esteban wrote >How do I test it? >Do I have to download a whole new 3.0 image? Normal way to test is to download latest 3.0 image and run it (on latest vm). Open monticello, open Pharo30Inbox, Type the issue number to find the slice and merge it to see changes. Stephan

March 27, 2014

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

by Esteban A. Maringolo

How do I test it? Do I have to download a whole new 3.0 image? Regards! Esteban A. Maringolo 2014-03-27 18:42 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Johan, Esteban, > > Here is the first patch: > > https://pharo.fogbugz.com/f/cases/13145/Speed-Up-DateAndTime-Arithmetic > > The other things that I tried (caching #epoch and switching the #localTimeZone to an #asFixedTimeZone variant) are now almost irrelevant since they no longer appear on the critical path while time profiling. > > Please let me know how it goes. > > Sven > > On 27 Mar 2014, at 20:18, Johan Brichau <johan(a)inceptive.be> wrote: > >> Sven, >> >> FYI, if you have the slice, I can run all our tests against it. >> We do just a little bit of things with DateAndTime in a planning app :-) so potential issues might be exposed. >> >> Johan >> >> On 27 Mar 2014, at 15:17, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> Umbrella issue: >>> >>> https://pharo.fogbugz.com/f/cases/13139/Speed-Regressions-in-DateAndTime >>> >>> I rewrote (and simplified) DateAndTime>>#+ #- #= >>> I added caching for #epoch >>> I switched the localTimeZone to an #asFixedTimeZone variant >>> >>> My benchmark now runs 40x FASTER than in Pharo 1.4 >>> >>> All Chronology tests remain green. >>> >>> I will upload slices when the funding goal of 1,000,000 USD is reached on https://www.kickstarter.com/projects/1003214829/improve-pharo-dateandtime-p… >>> >>> PS: Half of the funds will go to Camillo for making DateAndTime work in UTC internally ;-) >>> >>> PS2: I am not sure I am allowed to fix this so close to release, is it a feature or a bug fix ? ;-) >>> >>> On 27 Mar 2014, at 12:29, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> >>>> 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 >>>> >>> >>> >>> >>> -- >>> Sven Van Caekenberghe >>> Proudly supporting Pharo >>> http://pharo.org >>> http://association.pharo.org >>> http://consortium.pharo.org >>> >>> >>> >>> >>> >> >> > >

March 27, 2014

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

by Sven Van Caekenberghe

Johan, Esteban, Here is the first patch: https://pharo.fogbugz.com/f/cases/13145/Speed-Up-DateAndTime-Arithmetic The other things that I tried (caching #epoch and switching the #localTimeZone to an #asFixedTimeZone variant) are now almost irrelevant since they no longer appear on the critical path while time profiling. Please let me know how it goes. Sven On 27 Mar 2014, at 20:18, Johan Brichau <johan(a)inceptive.be> wrote: > Sven, > > FYI, if you have the slice, I can run all our tests against it. > We do just a little bit of things with DateAndTime in a planning app :-) so potential issues might be exposed. > > Johan > > On 27 Mar 2014, at 15:17, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Umbrella issue: >> >> https://pharo.fogbugz.com/f/cases/13139/Speed-Regressions-in-DateAndTime >> >> I rewrote (and simplified) DateAndTime>>#+ #- #= >> I added caching for #epoch >> I switched the localTimeZone to an #asFixedTimeZone variant >> >> My benchmark now runs 40x FASTER than in Pharo 1.4 >> >> All Chronology tests remain green. >> >> I will upload slices when the funding goal of 1,000,000 USD is reached on https://www.kickstarter.com/projects/1003214829/improve-pharo-dateandtime-p… >> >> PS: Half of the funds will go to Camillo for making DateAndTime work in UTC internally ;-) >> >> PS2: I am not sure I am allowed to fix this so close to release, is it a feature or a bug fix ? ;-) >> >> On 27 Mar 2014, at 12:29, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> >>> 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 >>> >> >> >> >> -- >> Sven Van Caekenberghe >> Proudly supporting Pharo >> http://pharo.org >> http://association.pharo.org >> http://consortium.pharo.org >> >> >> >> >> > >

March 27, 2014