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

Re: [Pharo-dev] Font problem is still there

by Blondeau Vincent

De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de Igor Stasenko EnvoyÃ© : jeudi 27 mars 2014 16:45 Ã : Pharo Development List Objet : Re: [Pharo-dev] Font problem is still there Btw, guys i need some details: - what platform you using The problem appears on both Linux Ubuntu x64 and Windows 7 platforms. - what default font you using We use this code to grab the default font: LogicalFont familyName: StandardFonts defaultFont familyName pointSize: aSize (aSize is the size of the font that we want). On Windows 7 the standard default font is (by printing âStandardFonts defaultFontâ): "a LogicalFont familyName: Source Sans Pro emphasis: nil pointSize: 10 realFont: FreeTypeFont('Source Sans Pro' 'Regular' 10) weight: 400 stretch: 5 slant: 0" On 26 March 2014 21:27, Tudor Girba <tudor(a)tudorgirba.com<mailto:tudor@tudorgirba.com>> wrote: Thanks, indeed :) Please keep us informed. Doru On Wed, Mar 26, 2014 at 5:57 PM, Alexandre Bergel <alexandre.bergel(a)me.com<mailto:alexandre.bergel@me.com>> wrote: > I didn't tried to debug it, i can't bet it would be easy (need to build a debug version of cairo first) > but it worth trying. > Meanwhile i will put workaround back. Thanks Igor. Let us know! Alexandre > > > Hi! > > > >> there's some kind of caching interference either in cairo or between cairo and freetype, > >> when using identity transformation matrix and integral (integer) font sizes. > >> and there is a simple workaround: > >> > >> canvas pathTransform restoreAfter: [ > >> canvas pathTransform scaleBy: 1.00001. > >> "draw text here" > >> > >> ] > >> > >> this workaround was in font-rendering code, but then i removed it, because i thought problem was solved. > > > > Can we add this back please? > > This font problem is quite serious. It makes people laugh at Pharo... > > > > > -- > Best regards, > Igor Stasenko. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- www.tudorgirba.com<http://www.tudorgirba.com> "Every thing has its own flow" -- Best regards, Igor Stasenko. ________________________________ Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

March 28, 2014

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

by Norbert Hartl

Am 28.03.2014 um 09:17 schrieb Johan Brichau <johan(a)inceptive.be>: > > On 28 Mar 2014, at 06:24, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> Bugs are errors that prevents the system to run. > > <nagging> > Some performance problems make the system impossible to work with > </nagging> > There are always use cases that make a system painful slow. Bugs? Just sayinâ Norbert

March 28, 2014

Re: [Pharo-dev] Fwd: Feedback for Pharo 3

by ClÃ©ment Bera

Hello, About #valueWithInterval: and co, I added that in Pharo because they are present in javascript with the same name and I think they were very convenient to easily implement UI animation. According to the number of discussion about these 2 methods, I think they are useful, but we should rethink the API and the naming. For example one cannot set the Process priority for these methods and it's by default set to background priority which is not very good. A usecase is: process := [myAnimation run] valueWithInterval: 1 second. [ ... ] process terminate. In pharo we use 'Delay wait' so #evaluateEveryMilliseconds: instead of #evaluateEvery: 100 ms does not really make sense to me. Am I missing something there ? What about #evaluateEvery:processPriority: and #evaluateEvery: that sets a default priority ? #valueAfterWaiting: is named valueWithTimeout: in javascript. What about #evaluateLater: and #evaluateLater:priority: 2014-03-28 8:01 GMT+01:00 Pharo4Stef <pharo4Stef(a)free.fr>: > > > 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 Johan Brichau

On 28 Mar 2014, at 06:24, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Bugs are errors that prevents the system to run. <nagging> Some performance problems make the system impossible to work with </nagging> Anyway, going to check in Sven's changes today. cheers Johan

March 28, 2014

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

by Pharo4Stef

Excellent! Thanks for all this good and proactive energy. Stef > 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 28, 2014

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