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

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

by Yanni Chiu

On 17/05/12 3:51 PM, Sean P. DeNigris wrote: > > That could be very useful. How do you "fix up the class references"? What > methods should I look at? Brute force: find all references to the old class (select class name, cmd-shift-N). Go through the list of methods, paste the new class name, accept the change. This works for code. If you have instances of the class, then I guess even more brute force is needed. Or, you could go back to your original method, using class re-naming. (Remember that this technique started with not having an old image, but only having the exported objects).

May 17, 2012

Re: [Pharo-project] Epoch returns local offset

by Sven Van Caekenberghe

On 17 May 2012, at 21:11, Sean P. DeNigris wrote: > This was a complicated change that's obviously at the core of the system. > Although all 385 of KernelTests-Chronology tests pass[1], I'd really > appreciate some feedback and testing... I want to have a look, but after the conference.

May 17, 2012

Re: [Pharo-project] Release of Roassal

by Tudor Girba

Hi, Just a note: Mondrian does not force anyone to use a DSL :). Most people just chose to use it because the API was better. It's not that much different in Roassal, but that is not an important topic :). Doru On 17 May 2012, at 21:54, StÃ©phane Ducasse wrote: > an important one. you can use roassal without been forced to use a dsl. > Then you have a much better way to handle interaction and also the camera (zoom) > > Stef > > > On May 17, 2012, at 2:47 PM, Damien Cassou wrote: > >> Hi Alexandre, >> >> On Thu, May 17, 2012 at 2:38 PM, Alexandre Bergel >> <alexandre.bergel(a)me.com> wrote: >>> Roassal graphically renders objects using short and expressive Smalltalk >>> expressions. A large set of interactions are offered for a better user >>> experience. Painting, brushing, interconnecting, zooming, drag and dropping >>> will just make you more intimate with any arbitrary object model. >>> >>> Screenshot available >>> on http://objectprofile.com/pier/Products/Roassal/Screenshots >> >> I don't understand the differences with Mondrian and the screenshots >> don't help me (probably because they are too small). >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Lambdas are relegated to relative obscurity until Java makes them >> popular by not having them." James Iry >> > > -- www.tudorgirba.com "Every successful trip needs a suitable vehicle."

May 17, 2012

Re: [Pharo-project] Epoch returns local offset

by Sean P. DeNigris

Sven Van Caekenberghe wrote > > But are you sure that this is incorrect ? Hey Sven! It started out as a question about the offset of the epoch. >From the responses, and some of my own problems in the past, it seems clear that having an epoch without a specific timezone does not work (see my example earlier in the thread of converting to seconds, moving to a different timezone, and converting back to a DateAndTime). As David Lewis mentioned, we're back in the world of DOS (which is how I got into this mess to begin with - fixing ZipArchive led me to DOS times, led me to SqueakEpoch...). The only way out that I can see is to assume that all times-as-seconds are in a reference timezone, and the Unix epoch already exists, is widely known, and specifies UTC, so I used that, as David suggested. Sean -- View this message in context: http://forum.world.st/Epoch-returns-local-offset-tp4630549p4630717.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 17, 2012

Re: [Pharo-project] Epoch returns local offset

by Sven Van Caekenberghe

Sean, I have very little time because I need to prepare stuff for the PharoConf, so I haven't read all the mails and code that you produced on this subject. But are you sure that this is incorrect ? I am mean, combining the clock seconds with the local offset should yield a proper time, no ? The TZ of the clock is then cancelled out as far as I see it. This is code taken from https://github.com/svenvc/ztimestamp ZTimestamp class side now "Create and return a new ZTimestamp equal to the current system time" ^ self fromClockSeconds: (self clockSeconds - self clockTimezoneOffset) fromClockSeconds: seconds "Create and return a new instance from a specific number of seconds since our clock epoch, see #now" ^ self new jdn: self clockEpoch julianDayNumber + (seconds // 86400) secs: self clockEpoch secondsSinceMidnight + (seconds \\ 86400) clockEpoch "Return the epoch of the clock that we use as an instance (cached), see #now" ^ ClockEpoch ifNil: [ ClockEpoch := self year: 1901 month: 1 day: 1 ] clockSeconds "Return the total seconds count of the clock that we use as an Integer, see #now" ^ Time totalSeconds clockTimezoneOffset "Return the timezone offset of the clock that we use as an Integer seconds (cached), see #now" ^ ClockTimezoneOffset ifNil: [ ClockTimezoneOffset := DateAndTime localTimeZone offset asSeconds ] I would love to learn/discuss more, later on. It feels like you are changing dangerous things, someone else should check this out. But cleanups are of course welcome. Sven On 17 May 2012, at 21:11, Sean P. DeNigris wrote: > Fix in inbox: Name: SLICE-Issue-5913-Remove-Squeak-epoch-SeanDeNigris.1 > > This was a complicated change that's obviously at the core of the system. > Although all 385 of KernelTests-Chronology tests pass[1], I'd really > appreciate some feedback and testing... > > [1] except the DateAndTime*EpochTest classes, which should be removed; see > below > > General > * Update all comments referencing the Squeak Epoch > * There is a VM primitive that returns current seconds since the Squeak > epoch. For now, I have adjusted all users of this primitive for the Unix > epoch, but it would be cleaner to change the primitive and remove this hack > > Kernel-Chronology > * Change SqueakEpoch from ChronologyConstants > - rename to UnixEpoch > - change value to that of UnixEpoch > * Replace all uses of SqueakEpoch with UnixEpoch > * change DateAndTime class>>epoch to use UTC > > KernelTests-Chronology > * Fix all tests to pass, except the DateAndTime*EpochTest classes, which are > incredibly redundant and should be removed (Issue 5910: [Cleanup]: Gut > DateAndTimeDosEpochTests) > * Removed many magic numbers > * cleaned and refactored > > Other > * Fix MailMessage and MessageList to use new epoch -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

May 17, 2012

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

by Francois Stephany

> When I don't have the old image anymore, I create a subclass in the new > image (e.g. FileReference subclass: FSReference), do the import, then > fix up the class references. That's what I also did when Migrating from 1.3 to 1.4. It worked fine.

May 17, 2012

Re: [Pharo-project] Release of Roassal

by Alexandre Bergel

In addition to what Stef said, Roassal supports interaction much better than Mondrian. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On May 17, 2012, at 8:47 AM, Damien Cassou wrote: > Hi Alexandre, > > On Thu, May 17, 2012 at 2:38 PM, Alexandre Bergel > <alexandre.bergel(a)me.com> wrote: >> Roassal graphically renders objects using short and expressive Smalltalk >> expressions. A large set of interactions are offered for a better user >> experience. Painting, brushing, interconnecting, zooming, drag and dropping >> will just make you more intimate with any arbitrary object model. >> >> Screenshot available >> on http://objectprofile.com/pier/Products/Roassal/Screenshots > > I don't understand the differences with Mondrian and the screenshots > don't help me (probably because they are too small). > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry >

May 17, 2012

Re: [Pharo-project] [Pharo-consortium] We need your Pharo successes

by StÃ©phane Ducasse

excellent! It is now added to our nice list https://gforge.inria.fr/frs/?group_id=1299 Stef On May 17, 2012, at 9:23 PM, Tudor Girba wrote: > Hi, > > Oh, I made a mistake and rendered the wrong PDF. > > Here is another one: > http://dl.dropbox.com/u/18323746/Humane-assessment/humane-assessment-powere… > > Is it better? > > Cheers, > Doru > > > On 17 May 2012, at 13:45, StÃ©phane Ducasse wrote: > >> Hi doru >> >> could you do it in three slides >> - cool picture. >> - what it is >> - pharo assets involved? >> >> Stef >> >> On May 16, 2012, at 11:26 PM, Tudor Girba wrote: >> >>> Hi, >>> >>> I do not know if it counts, but here is one about humane assessment with Moose: >>> http://dl.dropbox.com/u/18323746/Humane-assessment/humane-assessment-3-slid… >>> >>> Cheers, >>> Doru >>> >>> >>> >>> On 11 May 2012, at 17:56, StÃ©phane Ducasse wrote: >>> >>>> Hi everybody >>>> >>>> We really want to build a "vitrine" showroom of Pharo and we would you to participate. >>>> We want to build a web page with all these successes and show them to the world. :) >>>> >>>> We would like to get from you a three slides document: >>>> >>>> slide one: >>>> a sexy picture and a teaser / who you are. >>>> >>>> slide two: >>>> what is it how cool is it. >>>> >>>> slide three: >>>> what cool pharo techno you used or developed. >>>> >>>> If you have two successes then do two set of slides. >>>> >>>> So can you please send us these three slides. We would like to present them during the >>>> Pharo conf and after put them on the web. >>>> >>>> Stef and marcus. >>>> >>>> >>>> <sample.pdf>_______________________________________________ >>>> Pharo-consortium mailing list >>>> Pharo-consortium(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-consortium >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every successful trip needs a suitable vehicle." >>> >>> >>> >>> >> > > -- > www.tudorgirba.com > > "There are no old things, there are only old ways of looking at them." > > >

May 17, 2012

Re: [Pharo-project] Are we losing method versions?

by StÃ©phane Ducasse

On May 17, 2012, at 6:32 PM, Chris Muller wrote: > Those MC upgrades which I think you ported over are needed. Not yet. I have to get the time to be really concentrated. > > Using a remote connection is recommended, because a local connection > would lock files and wouldn't be able to access multiple images > simultaneously. > >> Can I automatically publish in magma local and squeak source/ss3/... > > It is just a MC repository -- it _could_ be used as a back-end for > SqueakSource, but I don't believe that has been done. > > > > On Thu, May 17, 2012 at 7:27 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Cool I should try. >> Should I install Magma locally? >> Can I automatically publish in magma local and squeak source/ss3/... >> >> On May 17, 2012, at 4:59 AM, Chris Muller wrote: >> >>> Magma 1.3 runs on Pharo 1.3. Did anyone ever get a chance try Magma's >>> new capability in this area? >>> >>> http://wiki.squeak.org/squeak/5603 >>> >>> Of course you get all versions, but I myself have been really enjoying >>> "Browse mc origin" which it adds to the method menu -- it opens the >>> standard MCVersionInfo box to see the version notes for when that >>> version of the method was originally created. >>> >>> >>> >>> >>> On Wed, May 16, 2012 at 1:53 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> yes >>>> >>>> Now we would love to have a database storing all the methods based on the ring meta model >>>> >>>> >>>> >>>>> Isn't the .changes somehow shrinked before every release? That should explain that. >>>>> >>>>> On Wed, May 16, 2012 at 8:16 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>>>> For DateAndTime class>>#readFrom: ... >>>>> >>>>> In Pharo 1.0, only one version: 'PeterHugossonMiller 9/3/2009 01:10' >>>>> In Pharo 1.2.2, two versions, minus the one from 1.0: "#('SeanDeNigris >>>>> 8/5/2010 15:51' 'StephaneDucasse 4/24/2010 12:46')" >>>>> In Pharo 2.0, only the last version from 1.2.2 remains: 'SeanDeNigris >>>>> 8/5/2010 15:51' >>>>> >>>>> -- >>>>> View this message in context: http://forum.world.st/Are-we-losing-method-versions-tp4630520.html >>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>>> >>>>> >>>> >>>> >>> >>

May 17, 2012

Re: [Pharo-project] Release of Roassal

by StÃ©phane Ducasse

an important one. you can use roassal without been forced to use a dsl. Then you have a much better way to handle interaction and also the camera (zoom) Stef On May 17, 2012, at 2:47 PM, Damien Cassou wrote: > Hi Alexandre, > > On Thu, May 17, 2012 at 2:38 PM, Alexandre Bergel > <alexandre.bergel(a)me.com> wrote: >> Roassal graphically renders objects using short and expressive Smalltalk >> expressions. A large set of interactions are offered for a better user >> experience. Painting, brushing, interconnecting, zooming, drag and dropping >> will just make you more intimate with any arbitrary object model. >> >> Screenshot available >> on http://objectprofile.com/pier/Products/Roassal/Screenshots > > I don't understand the differences with Mondrian and the screenshots > don't help me (probably because they are too small). > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry >

May 17, 2012