April 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Metacello configuration conventions

by Sean P. DeNigris

Christophe Demarey wrote > 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 +1 to the two different modes. Dale had recommended to me to depend on #stable in the baseline and then a specific version in the version. I'd say it depends on the underlying project - something like Zinc which seems to always be rock-solid at the bleeding edge I'd probably put #bleedingEdge in the baseline, where a less stable project I might use #stable. But I say definitely, definitely, definitely use a stable version in the version (unless it's a really loose dependency like OB for Seaside) - people need to be able to depend on loading a specific version being repeatedly identical. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Metacello-configuration-conventions-tp4681777p4682035… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 17, 2013

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

by Ben Coman

Torsten Bergmann wrote: > Thanks - Pharo 2.0 and Zinc makes it really easy > to work with, write AND test HTTP stuff: > > That sparks an idea, perhaps for a student project... That a general HTTP testing framework for use against non-Pharo systems could be just the thing to help the uptake of Pharo in "enterprises". The level of trust required for an internal testing tool is less than that required for an end-user system. This might be a good stepping stone for enterprises which may initially view Smalltalk a bit strange. Unless of course best practice is to use web testing tools from within real web browsers (I not familiar with what the options are). Perhaps a website stress test tool where the live exceptions can be inspected is something that other tools cannot do. cheers -ben

April 17, 2013

Re: [Pharo-project] Metacello configuration conventions

by Camillo Bruni

On 2013-04-16, at 23:25, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 16 April 2013 19:52, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >> 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 :) > > Well, #stable is for people, not machines. It's how you decide whether > to try Foo 1.3 or Foo 1.4. If you're just using the library, that's > one thing - use other people's #stable releases. > > But if you're writing a library, and other people will use your > application (that uses other stuff), that's when tight control over > versions pays off. Your users can know the precise things they need to > run your software. ... and that is more precisely: tests and continuous integration I liked ruby-gems approach more than the one in Metacello. You usually specify a major version (as under linux) for your dependency. That means the dependency might evolve a bit, typically for bugfixes, without you having to update the configuration manually. http://docs.rubygems.org/read/chapter/16 for me is what I'd like to see. As you say, #stable and #development are mostly for humans.

April 16, 2013

Re: [Pharo-project] Metacello configuration conventions

by Frank Shearar

On 16 April 2013 19:52, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > 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 :) Well, #stable is for people, not machines. It's how you decide whether to try Foo 1.3 or Foo 1.4. If you're just using the library, that's one thing - use other people's #stable releases. But if you're writing a library, and other people will use your application (that uses other stuff), that's when tight control over versions pays off. Your users can know the precise things they need to run your software. frank > 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] [update 3.0] #30042

by Igor Stasenko

On 16 April 2013 21:20, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Can you tell me, a lame Pharo developer, why this is so? > > "Extraordinary claims require extraordinary proof." :) > Because compiler is alpha & omega of system. No good compiler => no good debugger. Lack of good design in compiler => no way to improve it and build tools around it No modularity support in compiler => no modularity in image. ... i can go with this list forever :) > Thanks! > > Esteban A. Maringolo > -- Best regards, Igor Stasenko.

April 16, 2013

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

by Sven Van Caekenberghe

Hey Torsten, On 16 Apr 2013, at 20:48, "Torsten Bergmann" <astares(a)gmx.de> wrote: > 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 > > ------------------------------------------------------------------------------------------------------------------ > â¦ Thanks for the feedback ;-) That was indeed one of the main goals: to make it easy to work with HTTP using objects, be it requests or responses, client or server side. If you encounter places to improve the framework, don't hesitate to make suggestions. I would write the second assert in the first test as self assert: response contentType equals: 'image/vnd.microsoft.icon' asZnMimeType There are also test messages you can send to response objects, like #isSuccess even though that is slightly more general than 200. If you are OK with that, you can write self assert: response isSuccess Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

April 16, 2013

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

by Esteban A. Maringolo

Can you tell me, a lame Pharo developer, why this is so? "Extraordinary claims require extraordinary proof." :) Thanks! Esteban A. Maringolo 2013/4/16 Igor Stasenko <siguctua(a)gmail.com>: > I'd like to make sure everyone understands the significance of this. > Everything what we did before for Pharo is NOTHING comparing to Opal. > It's impacts everything: starting from tools we use up to the > frameworks we can build > using it. > > All pharo versions released before introduction of Opal should be renamed to > 0.0001 preview > > today is true 1.0 of Pharo! :) > > Thanks for hard work Marcus, Stef and others who helped to make it! > > On 16 April 2013 16:23, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> :D >> >> On 2013-04-16, at 16:22, 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. >>> >> >> > > > > -- > Best regards, > Igor Stasenko. >

April 16, 2013

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