- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Smalltalkhub & API

by Nicolas Petton

Stephan Eggermont writes: > 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 Hi, Do you want write access to the repo? Cheers, Nico

March 28, 2014

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

by Sergi Reyner

2014-03-28 5:24 GMT+00:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Bugs are errors that prevents the system to run. > If a system runs, even if slow, then is not an error. One could argue that bugs are defects that cause unintended behaviour (including not operating at all). Given that definition, and assuming that poor performance is not intended, slowness may well qualify as a bug. But if someone points me to a formal definition of bug that precludes my interpretation, IÂ´ll shut up until I find something else to rant about :) Cheers, Sergi

March 28, 2014

Re: [Pharo-dev] Smalltalkhub & API

by phil＠highoctane.be

Ah, nice! Thx On Fri, Mar 28, 2014 at 10:44 AM, Nicolas Petton <petton.nicolas(a)gmail.com>wrote: > Hi! > > You can do: > > GET http://smalltalkhub.com/hub/projects/{user,team} > > Cheers, > Nico > > phil(a)highoctane.be writes: > > > Is there a way to ask for a set of project names under a given Team/User? > > > > I don't like maintaining lists like this one: > > > > #( > > 'BitmapCharacterSet' > > 'CollectionArithmetic' > > 'Coral' > > 'EventRecorder' > > 'FFICompatibility' > > 'FileSystemLegacy' > > 'Flotr' > > 'Gettext' > > 'ImageWorker' > > 'JSON' > > 'LDAP' > > 'LEDMorph' > > 'MorphExamplesAndDemos' > > 'NBOpenGL' > > 'OPAX' > > 'OrderPreservingDictionary' > > 'Pastell' > > 'Phexample' > > 'PlotMorph' > > 'PostgresV2' > > 'Postmark' > > 'ProfStef' > > 'RFB' > > 'ROE' > > 'SCouchDBViewServer' > > 'SMark' > > 'Smacc' > > 'Sound' > > 'Soup' > > 'Spotlight2' > > 'Tanker' > > 'XMLParser' > > 'XMLSupport' > > 'XMLWriter' > > 'XPath' > > 'readline') do: [ :projectName | > > MCRepositoryGroup default addRepository: ( > > MCSmalltalkhubRepository > > owner: 'PharoExtras' > > project: projectName) > > ]. > > > > > > Phil > > > -- > Nicolas Petton > http://nicolas-petton.fr > >

March 28, 2014

Re: [Pharo-dev] SmalltalkHub update

by Nicolas Petton

No, I don't have Safari but colleagues do. I'll test it this afternoon. Cheers, Nico Stephan Eggermont writes: > Do you test with Safari? I get lots of restarts.10.9.2 > > Stephan -- Nicolas Petton http://nicolas-petton.fr

March 28, 2014

Re: [Pharo-dev] Smalltalkhub & API

by Nicolas Petton

Hi! You can do: GET http://smalltalkhub.com/hub/projects/{user,team} Cheers, Nico phil(a)highoctane.be writes: > Is there a way to ask for a set of project names under a given Team/User? > > I don't like maintaining lists like this one: > > #( > 'BitmapCharacterSet' > 'CollectionArithmetic' > 'Coral' > 'EventRecorder' > 'FFICompatibility' > 'FileSystemLegacy' > 'Flotr' > 'Gettext' > 'ImageWorker' > 'JSON' > 'LDAP' > 'LEDMorph' > 'MorphExamplesAndDemos' > 'NBOpenGL' > 'OPAX' > 'OrderPreservingDictionary' > 'Pastell' > 'Phexample' > 'PlotMorph' > 'PostgresV2' > 'Postmark' > 'ProfStef' > 'RFB' > 'ROE' > 'SCouchDBViewServer' > 'SMark' > 'Smacc' > 'Sound' > 'Soup' > 'Spotlight2' > 'Tanker' > 'XMLParser' > 'XMLSupport' > 'XMLWriter' > 'XPath' > 'readline') do: [ :projectName | > MCRepositoryGroup default addRepository: ( > MCSmalltalkhubRepository > owner: 'PharoExtras' > project: projectName) > ]. > > > Phil -- Nicolas Petton http://nicolas-petton.fr

March 28, 2014

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