- Pharo-dev - lists.pharo.org

Re: [Pharo-project] DateAndTime bug: we should do something about it

by Yanni Chiu

On 16/04/13 5:56 AM, Igor Stasenko wrote: > So, it is 3x slower , 1000x more accurate (milli vs micro), do not > requires startup code > do not need to account for counter wrapping and day change => much > cleaner and nicer. > + less buggy. Is this a candidate for back porting to Pharo-2.0? (Eliminating the startup code is the main concern, I think).

April 16, 2013

Re: [Pharo-project] Understanding Athens

by Igor Stasenko

On 16 April 2013 16:39, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 16/04/2013 16:29, Igor Stasenko a Ã©crit : > >> On 16 April 2013 16:27, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>> >>> Le 16/04/2013 16:12, Igor Stasenko a Ã©crit : >>> >>>> On 16 April 2013 15:47, kilon <thekilon(a)yahoo.co.uk> wrote: >>>>> >>>>> >>>>> Thats awesome but I cant open my pharo image anymore , I dont mind >>>>> starting >>>>> from a new image and reinstalling everything >>>>> but I was wondering if there is a way to recover all that or am I >>>>> screwed >>>>> ? >>>>> :) >>>>> >>>> You have a talent at screwing things up :) >>>> But your feedback is invaluable, which helping to spot details , which >>>> obvious to me but not for a newcomer. >>>> >>>> Yeah, concerning screwed image: in such cases i usually run it with VM >>>> which does not includes NativeBoost, then it fails with error.. and >>>> you can close morphs/debugger save image and can continue work with >>>> Cog VM.. it is , of course not always works, because it depends how >>>> badly things screwed up. :) >>> >>> >>> >>> Igor, could you add code to start the session without gui, run a bit of >>> smalltalk code to destroy the dangling surfaces and save again ? >>> >>> It would probably save the day a few times :) >>> >> yes, i am already thinking on it. >> >> The thing which i want to do is to put a session check in #drawDuring: >> method, >> to check if surface is still valid. >> And if its not, then shoot the caller :) > > > We don't have a framework for handling external resources tracking across > sessions, wher you can specify a reopen/destroy policy ? > Well, NativeBoost has some bits for supporting session-aware code. The problem is that management of external resources almost always specific to what you using... During my development of NB i identified some general patterns, which then shaped into implementation of concrete service classes. We're planning to move some parts of it out of NB to Kernel. But that is the road to walk. > How are servers doing it? They have to close connections on session close > and reopen them at start, no? Why not using the same code for Athens and > recreate the surface on session start or fail (without segfault). > Well, the question is always at which level you should do it. How you can avoid checking every single external resource handle every time you trying to use it, and instead introduce check at higher levels (at root entry to your model) because checking costs resources. But because different frameworks employing different models, it is hard to find one, which is so general and fits all. > Ah yes, shooting the caller is fine if we restart on a system without the > ability to create the surface... What do you think of throwing an exception? > That's what i going to do for the starting. But Athens surface is really low level. And introducing some auto-management will be a mistake. The code which should recreate surface upon image restart should be in user's code, because we cannot predict how new session is different comparing to previous one.. User may decide to choose different backend in new session, reload some files from disk etc... > Thierry > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > -- Best regards, Igor Stasenko.

April 16, 2013

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

by Sven Van Caekenberghe

On 16 Apr 2013, at 13:31, 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 Nice, this is all important but a lot of work as well - Thx. Sven

April 16, 2013

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

by Igor Stasenko

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

[Pharo-project] Jenkins build is back to stable : Pharo-2.0-Tests Â» run 1,vmLatest,win #234

by no-reply＠ci.inria.fr

See <https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vmLatest,lab…>

April 16, 2013

[Pharo-project] Jenkins build is back to stable : Pharo-2.0-Tests Â» run 1,vm,win #234

by no-reply＠ci.inria.fr

See <https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=win…>

April 16, 2013

[Pharo-project] [update 2.0] #20598

by Marcus Denker

20598 ----- 10260 backport 2.0: 10258 DivideByZero in SystemProgressMorph https://pharo.fogbugz.com/f/cases/10260 10109 MNU : SmalltalkEditor>>browseItHere: https://pharo.fogbugz.com/f/cases/10109 Diff information: http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1346.diff

April 16, 2013

Re: [Pharo-project] Understanding Athens

by Goubier Thierry

Le 16/04/2013 16:29, Igor Stasenko a Ã©crit : > On 16 April 2013 16:27, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> Le 16/04/2013 16:12, Igor Stasenko a Ã©crit : >> >>> On 16 April 2013 15:47, kilon <thekilon(a)yahoo.co.uk> wrote: >>>> >>>> Thats awesome but I cant open my pharo image anymore , I dont mind >>>> starting >>>> from a new image and reinstalling everything >>>> but I was wondering if there is a way to recover all that or am I screwed >>>> ? >>>> :) >>>> >>> You have a talent at screwing things up :) >>> But your feedback is invaluable, which helping to spot details , which >>> obvious to me but not for a newcomer. >>> >>> Yeah, concerning screwed image: in such cases i usually run it with VM >>> which does not includes NativeBoost, then it fails with error.. and >>> you can close morphs/debugger save image and can continue work with >>> Cog VM.. it is , of course not always works, because it depends how >>> badly things screwed up. :) >> >> >> Igor, could you add code to start the session without gui, run a bit of >> smalltalk code to destroy the dangling surfaces and save again ? >> >> It would probably save the day a few times :) >> > yes, i am already thinking on it. > > The thing which i want to do is to put a session check in #drawDuring: method, > to check if surface is still valid. > And if its not, then shoot the caller :) We don't have a framework for handling external resources tracking across sessions, wher you can specify a reopen/destroy policy ? How are servers doing it? They have to close connections on session close and reopen them at start, no? Why not using the same code for Athens and recreate the surface on session start or fail (without segfault). Ah yes, shooting the caller is fine if we restart on a system without the ability to create the surface... What do you think of throwing an exception? Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

April 16, 2013

Re: [Pharo-project] Metacello configuration conventions

by Frank Shearar

On 16 April 2013 15:11, Stephan Eggermont <stephan(a)stack.nl> wrote: > Frank wrote: >>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.) > > Thank you. That's a clear vulnerability of the optimistic strategy. > > That sounds nice, but also means getting a change rate that is the sum > of that of all your dependencies. It is also not very nice when you are > depending on things that have known bugs you know will be fixed soon. Why? If you use a baseline during development, you don't specify your own versions at all. It's only when you're preparing a release that you need to harden up the dependencies. Or: I'd be very surprised to see you needing to constantly update your _external_ dependencies. > What does it mean that a certain set of versions work together? > Implicit seems the assumption that #Pharo2x is #stable, and we don't talk > about the vm version or even worse the non-smalltalk dependencies. > > I don't see Metacello descriptions specifying all loaded packages. Indeed: as far as Metacello's concerned there's just #pharo20 or #squeak or whatever. But then, _usually_ you won't need to do special things for, say, Pharo 2.0 prior to some update N versus Pharo 2.0 from update N+1 onwards. (Where "2.0" is a stand-in for any not-bleeding-edge version.) frank > Stephan >

April 16, 2013

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

by Benjamin

Cool :) Next step: Athens :) 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