- Pharo-dev - lists.pharo.org

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

by Pharo4Stef

the linke o your blog leads to http://www.smalltalkhub.com/#%21/%7Ehernan/ApplicationSecurity On 28 Mar 2014, at 00:58, 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

Fwd: Feedback for Pharo 3

by Pharo4Stef

Begin forwarded message: > From: Richard Sargent <richard.sargent(a)gemtalksystems.com> > Subject: Feedback for Pharo 3 > Date: 27 Mar 2014 18:46:11 GMT+1 > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > Hi StÃ©phane, > > Benjamin Pollack @bitquabit just tweeted the features list for 3.0. I have to say that you folks have some really exciting things happening there. > > However, the naming of the methods for the "Simple Delayed Execution for Blocks" needs work. The #value* methods are so named because they return the value from the Block's execution. Neither #valueWithInterval: nor #valueAfterWaiting: answers the result of the Block's evaluation. > > The naming of the arguments is questionable, too. The name "aDelay" suggests an instance of a given class, but the comment suggests the argument is an integer (milliseconds). I can see argument for a Duration as the argument, in the expression [...something...] evaluateEvery: 100 ms. I don't think it can get clearer than that. But for performance, one might want an integer argument. Here the naming gets challenging. #evaluateEveryMilliseconds: is as close as I can come to readable, but I don't really like it either. > > > Thanks for all your hard work (and good work!). > Richard Sargent >

March 28, 2014

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

by Esteban Lorenzano

(I should stop pressing the âsendâ button before saying everything I has to say) On 28 Mar 2014, at 02:09, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 27 Mar 2014, at 19:47, Ben Coman <btc(a)openinworld.com> wrote: > >> 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. it is not :) Bugs are errors that prevents the system to run. If a system runs, even if slow, then is not an error. An improvement on performance is that: an improvement. Ergo, an enhancement. But ofc, nothing prevent s us to integrate an enhancement to the pharo3 version. Just to the release, but that does not means we are not going to change anything in pharo3 after release. We make releases because we need an order, otherwise we are going to continue incorporate improvements until the infinite, with the result of not a single stable versionâ¦ yes, the system we are going to release will not be perfect. Thatâs why we need a pharo4 version (and after that a pharo5, and so onâ¦). If it wouldnât be needed we would be calling this version âpharo, the ultimateâ. and about the change of API: we do not integrate new features not just because the API, is because we cannot be sure about the side effects of a change, even those that can look like a harmless. >> >> 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. > > it does not need to be integrated to pharo3 because is a backport (that means: is already there) :) butâ¦ if there are more improvements (I did not see the slice), nothing prevents us to integrate it. Just right after the release, or if we are sure (for real) that it will not weak the system (something that I find hard to believe in the case of changes to DateAndTime) :) Esteban > >> >> cheers -ben >> >> >> >

March 28, 2014

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

by Esteban Lorenzano

On 27 Mar 2014, at 19:47, Ben Coman <btc(a)openinworld.com> wrote: > 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. it does not need to be integrated to pharo3 because is a backport (that means: is already there) :) > > cheers -ben > > >

March 28, 2014

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

by Esteban A. Maringolo

Nice! I implemented a RBAC framework with AAA features several years ago, and I'm rewriting several parts of it for my own use now. I remember having read Yoder's publication at that time. I'll take a look into your code to see if there if there is a way we can make them converge. Thank you! Esteban A. Maringolo 2014-03-27 20:58 GMT-03:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > 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

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 28, 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 28, 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