- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [pharo-project.org] tweaked download pages a bit...

by stephane ducasse

thanks. We should clean also the Pharo-Contribution CI ;) Stef On Apr 16, 2013, at 1:31 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > I changed a little the download pages > > http://www.pharo-project.org/ > http://www.pharo-project.org/pharo-download > http://www.pharo-project.org/pharo-download/release-2-0 > http://www.pharo-project.org/pharo-download/alpha-3-0 > > -> Do not present a choice to the new visitor but make it clear what to download > -> be a bit more consistent between the 4 places > >

April 16, 2013

Re: [Pharo-project] [update 3.0] #30042

by stephane ducasse

On Apr 16, 2013, at 4:30 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Cool :) > > Next step: Athens :) YESSSSSSSSSSSSSSSSS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! but igor knows it :) > > Ben > > On Apr 16, 2013, at 4:22 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 16 April 2013 15:32, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> 30042 >>> ----- >>> >>> 10028 Integrate Opal >>> https://pharo.fogbugz.com/f/cases/10028 >>> >>> (remove destructive tests) >>> >> >> YESSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >> >> >> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >

April 16, 2013

Re: [Pharo-project] Metacello configuration conventions

by stephane ducasse

Christophe I agree with you > As a general purpose reflexion on dependencies conventions, I would say: > If you are in development mode, it makes sense to rely on latest versions of dependencies (bleeding edge) to be able to detect integration problems as soon as possible. > If you are in a release mode, you should ensure that your code can run at least on fixed dependencies versions (at the best, specify a range of versions you can use with possibly no upper limit if your dependencies ensure backward compatibility). You need reproducible loading of your tool/lib. > in my opinion, you shouldn't use #stable for release version as the only thing it ensure (if well tested) is that you will not have a broken version of the dependency. The stable version of your dependency will evolve and then the configuration of your release too. At a time, your version will not be usable at all because of that. Because even if you milestone against a major version, what you mean is that the package may change (and still work on 20 for example, but be incompatible with your software). I will write something in the metacello chapter and see what I wrote on symbolic version. > so I would specify a dependency with a versionString for release versions of your lib/tool. It ensures a minimum version. So I wonder when we should use stable. Versionner will solve all these points for us :) Stef > > Regards, > Christophe. > > Le 16 avr. 2013 Ã 11:02, Frank Shearar a Ã©crit : > >> On 16 April 2013 09:53, Stephan Eggermont <stephan(a)stack.nl> wrote: >>> Hi, >>> >>> While working with Diego on some configurations, we noticed two different styles >>> of describing the latest non-baseline versions. >>> >>> In one, the versionString version of a dependency is used. >>> That is a defensive strategy, where you want to specify the exact version that >>> will be loaded (and has been tested). >>> >>> In the other the #stable version is used. That is an optimistic strategy. >>> This is much less brittle (but might suddenly not work anymore). >>> >>> Seaside uses defensive/mixed, while Magritte uses optimistic >>> >>> Based on what criteria should I choose which one to use (in a Pharo context)? >> >> I'd argue that since you're declaring that a certain set of versions >> of packages work together, you should _always_ use explicit versions. >> The "optimistic" strategy leaves you vulnerable to third parties >> making seemingly innocuous changes that break your code. (I've been >> bitten by this, by making such an apparently innocuous change.) >> >> frank >> >>> Stephan & Diego >> >

April 16, 2013

Re: [Pharo-project] [regression reporter]regression occurred

by stephane ducasse

On Apr 16, 2013, at 3:51 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > aaah I love to see a response to that :P > > my vicious plan to spam the pharo list when there are new tests failing > seems to work :) Hehehe yes we will conquer the world :)

April 16, 2013

Re: [Pharo-project] How to browse a selected method in code viewer

by stephane ducasse

On Apr 16, 2013, at 2:35 PM, kilon <thekilon(a)yahoo.co.uk> wrote: > Dammien Alt+m is the implementors, and as i said implementors works for me, > however alt+b which is for browsing does nothing. strange and how can we know in which class it is? Browse on a selector => should be equivalent to implementors. similarly implementor on a class => browse We lost this cross binding in 20. Stef

April 16, 2013

[Pharo-project] Pharo 2.0 and Zinc - big thanks!

by Torsten Bergmann

Thanks - Pharo 2.0 and Zinc makes it really easy to work with, write AND test HTTP stuff: ------------------------------------------------------------------------------------------------------------------ testHandleRequestForFavIcon | response mime | response := requestHandler handleRequest: (ZnRequest get: '/favicon.ico' asZnUrl). self assert: response status = 200. "HTTP OK" mime := response entity contentType. self assert: mime main= 'image'; assert: mime sub = 'vnd.microsoft.icon' ------------------------------------------------------------------------------------------------------------------ testSearchEngineIsSatisfied self assert: (ZnEasy get: 'http://www.pharo.org/robots.txt') status = 200 ------------------------------------------------------------------------------------------------------------------ ...

April 16, 2013

Re: [Pharo-project] do you know what is this?

by Esteban Lorenzano

not to say about efficiency. I've been doing some cpu cycle tests. Rendering a 1600@1200 gradient to world canvas (repeat each 50ms): ~90% cpu consumption Same test, but sending it direct to window canvas using bridge: ~40% cpu consumption so... we are in the good path :) Esteban On Apr 16, 2013, at 8:28 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 16 April 2013 19:09, kilon <thekilon(a)yahoo.co.uk> wrote: >> And you guys then say that pharo is not macos first citizen >> >> ha >> >> ha >> >> and >> >> ha >> >> I am a macos user , I love my imac and macos, but my vote goes to cross >> platform. >> >> Still another great library that is more than welcomed, definitely cant do >> any harm ;) >> > > By saying that we don't need Cairo on MacOS i meant following: > > Athens designed to support multiple backends. > It is out of question, that better to use most suitable backend, > available on current platform. > > But apart of it stays ObjC bridge. Which would allow us to speak with > ObjC-runtime > (and Mac VM using it) directly. > >> >> >> -- >> View this message in context: http://forum.world.st/Fwd-do-you-know-what-is-this-tp4681962p4681975.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > > > -- > Best regards, > Igor Stasenko. >

April 16, 2013

[Pharo-project] the fun theory

by Johan Brichau

When I saw this website, I immediately thought about Pharo http://www.thefuntheory.com "This site is dedicated to the thought that something as simple as fun is the easiest way to change peopleâs behaviour for the better." Keep having fun! Johan

April 16, 2013

Re: [Pharo-project] do you know what is this?

by Igor Stasenko

On 16 April 2013 19:09, kilon <thekilon(a)yahoo.co.uk> wrote: > And you guys then say that pharo is not macos first citizen > > ha > > ha > > and > > ha > > I am a macos user , I love my imac and macos, but my vote goes to cross > platform. > > Still another great library that is more than welcomed, definitely cant do > any harm ;) > By saying that we don't need Cairo on MacOS i meant following: Athens designed to support multiple backends. It is out of question, that better to use most suitable backend, available on current platform. But apart of it stays ObjC bridge. Which would allow us to speak with ObjC-runtime (and Mac VM using it) directly. > > > -- > View this message in context: http://forum.world.st/Fwd-do-you-know-what-is-this-tp4681962p4681975.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

April 16, 2013

Re: [Pharo-project] do you know what is this?

by Igor Stasenko

On 16 April 2013 19:31, kilon <thekilon(a)yahoo.co.uk> wrote: > Well to be fair any language that respects itself has an ObjC bridge , and > its definetly a big deal if you want to embrace iOS too. So definetly the > thumbs up from me. I am no way against this. > > well, it is good to stand on the shoulder of giant, but as long as he moves into same direction as you want :) > > -- > View this message in context: http://forum.world.st/Fwd-do-you-know-what-is-this-tp4681962p4681982.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

April 16, 2013