February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Bug Tracker] Issues that need to be reviewed

by StÃ©phane Ducasse

Henrik yes we are aware of that. Stef On Feb 24, 2012, at 2:17 PM, Henrik Johansen wrote: > On Feb 24, 2012, at 1:35 PM, Nicolas Cellier wrote: > >> I systematically mark my fixes as ReviewNeeded because a second pair >> of eyes don't hurt. >> But this seems to be yet another bottleneck. >> Taking responsibility to review might seem scary and involving >> especially when changes touch obscure/complex part of the system. >> >> So maybe the review could take lighter, more or less automated forms: >> - does automated integration reports a regression ? >> - does the bug report gives enough technical solution details or a >> good rationale ? >> - are there some tests provided ? >> >> Maybe you could handle a confidence score per developer. with a priori >> and a posteriori informations. >> Like "good solution, but the integrator had more work to finish the job"... >> >> On the other hand, Pharo claims the right to do some mistakes (and >> soon correct them), so maybe this review phase could be relaxed a bit. >> >> And one thing I still ask for is a diff log for each SLICE posted in >> the inbox, entirely browsable from the issue tracker or from the bug >> list, because to review you need: >> - to read issue tracker report >> - AND to inspect the changes with Monticello merge in a recent clean image... >> Having the diff would be a great economy for the reviewers. >> Or maybe this already happened? >> >> Maybe the report generated by Monticello that pops up once the package >> commited, could contain such diff that we would manually copy/past in >> the bug entry. Would that be cheap enough ? >> >> Nicolas > > +999. > > I don't mind reviewing changes, but loading up an image, updating it to latest version to ensure any conflicts are caught, opening MC browser, finding the slice, diffing against image, and only THEN be able to do a decent review are just too many manual steps, other than for issues I care very strongly about. (in which case I'm often the one requesting ReviewNeeded to begin withâ¦) > > IMHO, doing all the above, and reporting merge conflicts/ new failed tests/a diff to the issue would be a perfect task for UlyssÃ© :) > (As it is now, "Monkey went bananas" doesn't really tell me anything) > > Cheers, > Henry

Feb. 25, 2012

Re: [Pharo-project] [Bug Tracker] Issues that need to be reviewed

by StÃ©phane Ducasse

On Feb 24, 2012, at 1:35 PM, Nicolas Cellier wrote: > I systematically mark my fixes as ReviewNeeded because a second pair > of eyes don't hurt. Yes I love to read other code. - just in this moment I have too many jobs (second of lab, head of team, pushing companyâ¦) > But this seems to be yet another bottleneck. > Taking responsibility to review might seem scary and involving > especially when changes touch obscure/complex part of the system. > > So maybe the review could take lighter, more or less automated forms: > - does automated integration reports a regression ? > - does the bug report gives enough technical solution details or a > good rationale ? > - are there some tests provided ? Indeed. > Maybe you could handle a confidence score per developer. with a priori > and a posteriori informations. > Like "good solution, but the integrator had more work to finish the job"â¦ Yes :) > On the other hand, Pharo claims the right to do some mistakes (and > soon correct them), so maybe this review phase could be relaxed a bit. It is. We want to totally change the process We want to use Ulyss to automatically load code and report > And one thing I still ask for is a diff log for each SLICE posted in > the inbox, entirely browsable from the issue tracker or from the bug > list, because to review you need: > - to read issue tracker report > - AND to inspect the changes with Monticello merge in a recent clean image... > Having the diff would be a great economy for the reviewers. > Or maybe this already happened? the problem is that squeak source suffered. But yes this would be great. > Maybe the report generated by Monticello that pops up once the package > commited, could contain such diff that we would manually copy/past in > the bug entry. Would that be cheap enough ? > > Nicolas > > Le 24 fÃ©vrier 2012 08:30, Marcus Denker <marcus.denker(a)inria.fr> a Ã©crit : >> >> http://code.google.com/p/pharo/issues/list?can=2&q=status%3AFixReviewNeeded >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >

Feb. 25, 2012

Re: [Pharo-project] [update 1.4] #14355

by StÃ©phane Ducasse

Excellent! Pavel We should add Pharo Kernel as dependent of the head so that we get immediate feedback like that. because this is really great. Stef > On Fri, Feb 24, 2012 at 3:37 PM, Pavel Krivanek > <pavel.krivanek(a)gmail.com> wrote: >> On Fri, Feb 24, 2012 at 2:55 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> 14355 >>> ----- >>> >>> Issue 5338: World menu icons are not updated when a default tool changes >>> http://code.google.com/p/pharo/issues/detail?id=5338 >> >> This fix adds dependency on Morphic to AppRegistry class >> #default >> so Pharo Kernel cannot be produced. >> >> Cheers >> -- Pavel > > http://code.google.com/p/pharo/issues/detail?id=5370 > > -- Pavel > >> >>> >>> Issue 5325: PackageInfo dependent on deprecated MethodReference >>> http://code.google.com/p/pharo/issues/detail?id=5325 >>> >>> >>> >>> >>> -- >>> Marcus Denker -- http://marcusdenker.de >>> >>> >

Feb. 25, 2012

Re: [Pharo-project] Some Community numbers

by StÃ©phane Ducasse

Thanks for the stats. Now lot of people read the mailing-list via forum. What I can say is that we have a lot of new things in the pipeline and we will get there. Just need more time. Now Pharo improves daily. And there is a massive amount of work put into it. Stef > Some numbers to compare it against Pharo: > > Currently 472 people are actively subscribed to the pharo mailing list. > > Looking at the past year until now about 127 people have posted something at least once per month on average (27% of active subscribers as of today). > > The same for the last three months gives 99 people. > > Alex > > 2012/2/24 Alexander LazareviÄ <laza(a)blobworks.com> > Hi! > > Just some estimated[1] numbers[2]: > > Currently 1013 people are actively subscribed to the squeak-dev mailing list. > > Looking at the past year until now about 64 people have posted something at least once per month on average (6% of active subscribers as of today). > > The same for the last three months gives 51 people. > > > So any new Modulesystem or fancy Squeak Map Server gonna change that trend? > > > BTW, the Google+ Page attracted around 200 people. As with squeak-dev there isn't too much going on. > > Alex > > [1] I didn't bother to filter/join crosspostings, commit messages nor people with multiple e-mail addresses > [2] wget, grep, sed, uniq, sort, wc are my friends >

Feb. 25, 2012

[Pharo-project] Thanks Marcus for all these updates...

by StÃ©phane Ducasse

HI marcus Thank thanks thanks and thanks because I love to see all these updates. I got back and dead and now recoveringâ¦ Stef

Feb. 25, 2012

Re: [Pharo-project] Increasing bots traffic

by StÃ©phane Ducasse

http://geekandpoke.typepad.com/geekandpoke/2012/01/enjoy-it.html don;t get used to it. > Yes, thanks and sorry... if I happen to stare at the bug tracker too long > I get strange. > > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > >

Feb. 25, 2012

Re: [Pharo-project] fun with NBOpenGL

by StÃ©phane Ducasse

> > > Also, I remember in OpenCroquet Squeak could parse positional arguments of the form ogl glThis(x,y,x); glThat(x,y,z); -- doesn't it make sense to bring this back, since most of the OpenGL code examples on the internet are in this form ? I guess that you want to know since you ask: the answer is NO! It makes no sense to do that. > On an unrelated note, I'm confused by this ConfigurationOf/Gofer/Montecello system. How do people new to Pharo find out what these URLs and special configuration loading code are ? Read the monticello and metacello chapters on pharo by example 2 and look at MetacelloRepository. > Seems like everyone is just copying and pasting code from forums into workspaces. Couldn't these code fragments for loading configurations be loaded automatically via a URL or something ?

Feb. 25, 2012

Re: [Pharo-project] fun with NBOpenGL

by StÃ©phane Ducasse

> Great to see 3D on Pharo again! > > Just a remark, somewhere there should be stated that directly loading > vertex one by one with glVertex3f(..); is deprecated in the latest > OpenGL. In favor of mechanisms that load the geometry to the renderer > as a whole, as for example vertex buffer objects. > > In short, in the examples is ok to use, for learning the inner > workings of OpenGL. > Newer examples should make use of current practices of OpenGL. > I think that Nehe examples web page states that. > > I think that a framework such as Lumiere, would be needed to provide > higher abstractions and more efficient handling of geometry. > Maybe when i finish my Phd, i can continue to work on it. When you visit us I would like you to sit and pair program with erwan because we would like have a small code city Stef

Feb. 25, 2012

Re: [Pharo-project] So I broke 8k req/s today

by Sven Van Caekenberghe

Philippe, On 25 Feb 2012, at 14:35, Philippe Marschall wrote: > Hi > > I heighten everybody's mood I'll post some positive news. > > After some optimizations in both Seaside and AJP I managed to break 8000 requests / sec with a single Pharo 1.3 image. Thanks to SystemProfiler I knew where to look. > > This is with a single request handler that just returns a two byte response. It doesn't involve any rendering, sessions, continuations or whatsoever but it kicks on the full Seaside request handling machinery with a request context and everything. > > I'm using WASmallRequestHandler from the Seaside-Benchmark package. > > WASmallRequestHandler >> #handleFiltered: aRequestContext > aRequestContext respond: [ :response | > response > binary; > contentType: WAMimeType textHtml; > nextPutAll: 'OK' asByteArray ] > > Apache 2.2.21 mpm_worker mod_proxy_ajp > CPU Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz > SmalltalkImage current vmVersion 'Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.138]' > > Attached you'll find the output of ApacheBench. > > Cheers > Philippe > <8k.txt> Very nice, indeed. What would you get with your setup when you increase the work a bit from the your lower limit 2 byte response to something like this page ? http://zn.stfx.eu/dw-bench (dynamically generated by Zn) http://caretaker.wolf359.be:8080/DW-Bench (dynamically generated by Seaside) http://stfx.eu/static.html (static reference by Apache) The response should be about 8Kb. Sven

Feb. 25, 2012

Re: [Pharo-project] Emergency evaluator refresh problem

by Marcus Denker

On Feb 24, 2012, at 7:46 PM, Usman Bhatti wrote: > After exiting from emergency evaluator in pharo, pharo desktop/home is not repainted/refreshed. Is it an issue or a feature? > I think when the evaluator pops up people just don't care about details like that anymore. (I mean, something *horrible* whent wrong and everyone is happy to just ne able to rescue the image... refresh then is just not on your mind). Marcus -- Marcus Denker -- http://marcusdenker.de

Feb. 25, 2012