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

Re: [Pharo-project] Pharo is exploding

by Jimmie Houchin

On 5/16/2012 10:06 AM, StÃ©phane Ducasse wrote: >> I think that some official >> Pharo blog (maybe written by Esteban) would be very helpful. Some kind >> of not very extensive technical information source that will help >> people to stay in touch with Pharo progress. > Ok we will do a private mailing-list. I would prefer not. I am not a core developer. But I like reading this list. I personally do not find the volume all that big a problem. Any reasonable mail program can present you with the a threaded view. Allow you to mark threads as read. Read what you want and mark all the rest as read. Or whatever. No one has to read all the messages. >> That will explain what is >> being changed in Pharo and why. I think that developers than will see >> the changes like positive not as alien ones. > Why people do not register to pharo-users? Possibly what we need to do is have a few people who can move or forward discussions to the pharo-users list and encourage non-development-of-Pharo messages there. But this will require that all the people that we depend upon to answer messages here also subscribe to and respond on pharo-users. If we can do that then over time we will have a culture of the right messages going to the right list. But ultimately, that won't reduce the volume of anything. Neither will using Stack Overflow. Should one be a subscriber to all. Just MHO. Jimmie

May 16, 2012

Re: [Pharo-project] About process startups

by Guillermo Polito

On Wed, May 16, 2012 at 8:59 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > I do not really like the class idea. > why not? Maybe it does not apply for every process, but for some of them. Morphic UI process could belong to MorphicUIManager, but, does the finalization process belong to weak array? why not to weak registry or weak ordered collection then? :S > May be having a convention + a pragma for the methods is good. > > Stef > > On May 16, 2012, at 3:27 PM, Guillermo Polito wrote: > > > I'm playing with the process initialization for the bootstrap, and some > things come to my mind. > > > > There are some classes that startup processes on the class side > initialize, like > > > > WeakArray -> Finalization process > > Delay -> Timer event loop > > > > What it is not clear to me is if those processes should be installed > when the class is initialized, or when it is startupped for the first time. > Also, I can't stop thinking that the processes in the image are all spread > and not clear. If I want to know where the processes are defined, it's > kind of a mess. > > > > Is having specialized objects for our processes undesired by some reason > I can't see? I'd like to have objects like > > > > MorphicUIProcess > > FinalizationProcess > > TimeEventProcess > > ... > > and so on > > > > Guille > > >

May 16, 2012

Re: [Pharo-project] Epoch returns local offset

by Sean P. DeNigris

David T. Lewis wrote > > So no, it is not a constant. > Let me rephrase: wouldn't it be better if it was a constant, like dos and unix? I find the current behavior confusing e.g. dt := '1/15/2012 0000+00:00' asDateAndTime. DateAndTime localTimeZone: (TimeZone timeZones detect: [ :e | e abbreviation = 'PDT' ]). s := dt asSeconds. "3504013200" "Now I move to Greenwich" DateAndTime localTimeZone: (TimeZone timeZones detect: [ :e | e abbreviation = 'UTC' ]). DateAndTime fromSeconds: s. "2012-01-14T17:00:00+00:00" "Oops!" -- View this message in context: http://forum.world.st/Epoch-returns-local-offset-tp4630549p4630564.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 16, 2012

Re: [Pharo-project] Moving data into new package/image version

by Sean P. DeNigris

Mariano Martinez Peck wrote > > Sorry, I don't have ideas of how to solve that. I ended up using OB to rename the classes in the old image to match the new class names in the new image, then serialized with ReferenceStream, then deserialized in the new image. Mariano Martinez Peck wrote > I can only say > that Fuel *does* suppor that type of problem Would Fuel be better than ReferenceStream for persistence? I thought the use case was saving rarely, but loading often; where serialization is balanced between the two. -- View this message in context: http://forum.world.st/Moving-data-into-new-package-image-version-tp4628820p… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 16, 2012

Re: [Pharo-project] Epoch returns local offset

by David T. Lewis

On Wed, May 16, 2012 at 01:24:20PM -0700, Randal L. Schwartz wrote: > >>>>> "Sean" == Sean P DeNigris <sean(a)clipperadams.com> writes: > > Sean> In New York (EST), "DateAndTime epoch" -> "1901-01-01T00:00:00-04:00" (Squeak > Sean> epoch offset by local timezone). Can that be right? It must be constant, no? > > But it's not even EST right now (it's EDT), so this has nothing to do > with the current time offset, in case that helps. :) > "DateAndTime epoch" refers to the Smalltalk epoch, which is an undefined entity. As long as the value contains 1901-01-01T00:00:00 it is not proveably wrong, because the "definition" of the Smalltalk epoch does not specify if it is intended to refer to a point in time measured in Palo Alto, California, Greenwich England, or New York City. So no, it is not a constant. Dave

May 16, 2012

Re: [Pharo-project] Epoch returns local offset

by Sean P. DeNigris

Randal L. Schwartz wrote > > But it's not even EST right now (it's EDT), so this has nothing to do > with the current time offset, in case that helps. :) > You suck :-P j/k. Thanks Randal. So I guess there's two problems... 1. Pharo doesn't update for daylight savings time 2. epoch shouldn't offset by local offset? -- View this message in context: http://forum.world.st/Epoch-returns-local-offset-tp4630549p4630558.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 16, 2012

Re: [Pharo-project] Pharo Kernel 2.0 Reload by Fuel activated

by Pavel Krivanek

Hi, Mariano extended the FLPackage and we now have FuelCommandLineHandler so (with some little hacks) we are able to reach the state where we have a Pharo Kernel image and pass the single fuel file to it and produce fully working Pharo Core image this way. Compiler is not involved. So we are the next step closer to our goal. I created a Jenkins job for the Guillermo's magic :-) https://ci.lille.inria.fr/pharo/view/Seed%20Project/ Cheers, -- Pavel On Tue, May 15, 2012 at 11:41 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > truly excellent > Next week we should also sit with guillermo, ben and you so that we see how we can merge for the bootstrap because > Guillermo has a 1.3 mb image now. > > > Stef > > On May 15, 2012, at 9:21 AM, Pavel Krivanek wrote: > >> Hi, >> >> we were able to activate the job Pharo Kernel 2.0 Reload by Fuel [1] >> and related tests [2]. In short, this job takes latest Pharo Kernel >> image and with the only single script [3] it creates working Pharo >> Core image. It uses code and some data previously exported by a >> supporting job [4] [5]. >> >> The resultant image is not production-ready because Fuel Package >> Loader currently doesn't work with changes file. >> >> The next step that should be quite simple is to do the same with an >> image without Compiler :-) >> >> [1] https://ci.lille.inria.fr/pharo/view/Pharo-Kernel%202.0/job/Pharo%20Kernel%… >> [2] https://ci.lille.inria.fr/pharo/view/Pharo-Kernel%202.0/job/Pharo%20Kernel%… >> [3] http://gitorious.org/pharo-build/pharo-build/blobs/master/scripts/pharo/Ker… >> [4] https://ci.lille.inria.fr/pharo/view/Pharo-Kernel%202.0/job/Pharo%20Kernel%… >> [5] http://gitorious.org/pharo-build/pharo-build/blobs/master/scripts/pharo/Ker… >> >> Cheers, >> -- Pavel >> > >

May 16, 2012

Re: [Pharo-project] Epoch returns local offset

by merlyn＠stonehenge.com

>>>>> "Sean" == Sean P DeNigris <sean(a)clipperadams.com> writes: Sean> In New York (EST), "DateAndTime epoch" -> "1901-01-01T00:00:00-04:00" (Squeak Sean> epoch offset by local timezone). Can that be right? It must be constant, no? But it's not even EST right now (it's EDT), so this has nothing to do with the current time offset, in case that helps. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion

May 16, 2012

Re: [Pharo-project] Pharo is exploding

by StÃ©phane Ducasse

100% agree with and I was not emotional just playing drama because I found the discussion so funny. So lets move. There are so many cool stuff along the road. Now reviewing Spec chapter :) > > StÃ©phane Ducasse wrote >> >> And can we have a private developer mailing-list :) >> > > What the heck are you guys talking about?! Everyone take a deep breath... > Here's the reality: > One person who is > a) not here to defend himself, and > b) (allegedly) not using Pharo > (allegedly) made an off-list comment that some developers (allegedly, > possibly including himself) may find it jarring that in a year, one could > find an unrecognizable latest version of Pharo. This, by the way, is true, > even if it may not change our vision or plans. It may be unrecognizable. > And, some developers *may* find that unsatisfactory. As we've already > established, people do not like change. > > Now, none of this seems like a reason for all this fuss. It's wasting our > time and energy, which is already at capacity making Pharo the system of our > dreams. Specifically, I think a private developers list would hurt Pharo > both psychologically and physically - we want as many eyes on the issues at > hand as possible. > > Finally, the SO/separate-stackexchange-site/dev/users issue is a separate > thing. If we're going to talk about mailing list discipline, let's stop > hijacking people's threads. > > In closing: > * Let's all get back to work. People will react emotionally to the massive > progress (change) of Pharo. Duly noted, but it's in the damn manifesto ("Not > backward compatible" [1]). > * Maybe we can improve our communication process, both for the devs and > users. Let's discuss that. > > [1] http://code.google.com/p/pharo/ > > -- > View this message in context: http://forum.world.st/Pharo-is-exploding-tp4630233p4630489.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 16, 2012

Re: [Pharo-project] Epoch returns local offset

by Sean P. DeNigris

btw: dos epoch: 1 January 1980 00:00+00:00 unix epoch: 1 January 1970 00:00+00:00 -- View this message in context: http://forum.world.st/Epoch-returns-local-offset-tp4630549p4630552.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 16, 2012