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

Re: [Pharo-project] Problem with Date comparing summer time CEST

by Sven Van Caekenberghe

On 30 Oct 2012, at 23:09, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> Yes, Paul: this is the only way to remain sane ;-) >> >> That is one of the reasons why I wrote ZTimestamp, a point-in-time alternative to DateAndTime and TimeStamp with second precision, living in UTC, using ISO/International conventions and protocols only. >> >> http://mc.stfx.eu/Neo > > we should actually consider putting that into pharo ;) > I guess we can do a quick discussion round at the sprint on Friday... OK! BTW: I have a half done implementation of ZTimestampFormat based on example strings as specification for formatting & parsing as well ;-) -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Oct. 30, 2012

Re: [Pharo-project] [OT] RTalk

by dimitris chloupis

Well according to the author of RTalk , he never intended for this to be a full implementation of smalltalk , but later in his video presentation mentions that RTalk ended being a full implementation of DigiTalk which is the smalltalk his company was using for its legacy code. He actually does special mentions how he implemented non local returns. He even claims that not only he was able to replicate all digitalk bytecode but even instruct JVM to construct bytecode unrelated to Java. But me being a total beginner with smalltalk means I could as well misunderstood his presentations. Of course without having an opportunity to take a look at the actual code this is just a moot point. ----- Original Message ----- From: Camillo Bruni <camillobruni(a)gmail.com> To: Pharo-project(a)lists.gforge.inria.fr Cc: Sent: Tuesday, 30 October 2012, 23:18 Subject: Re: [Pharo-project] [OT] RTalk On 2012-10-30, at 18:39, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > On 30/10/12 15:39, dimitris chloupis wrote: >> Hey Torsten and thanks for the reply. >> >> I am not here to recommend pharo to move to JVM. Rtalk author also >> mention this, moving a language to another platform like JVM is quite >> easy , > > I've spent quite some time playing with Java and JVM. I don't think in case of Smalltalk language it would be exactly 'quite easy' to move > to JVM. > There are certain constructs, prevalent in Smalltalk codebase, that would be tricky to implement *efficiently* on JVM. Non-local returns, > proceedable exceptions, class extensions, snapshotting to name some. not to mention instance migration! (which might be circumvented in non-development mode)

Oct. 30, 2012

Re: [Pharo-project] Problem with Date comparing summer time CEST

by Camillo Bruni

On 2012-10-30, at 22:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 30 Oct 2012, at 22:20, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > >> For me, my image's internal timezone is set to UTC. I use Chronos and store >> everything as UTC, use UTC values for every calculation, then convert it >> back to the local time only on display to a user. right, just for completeness, in 2.0 all time objects are stored in UTC. Additionally they store the timezone, used for conversions and displaying. > Yes, Paul: this is the only way to remain sane ;-) > > That is one of the reasons why I wrote ZTimestamp, a point-in-time alternative to DateAndTime and TimeStamp with second precision, living in UTC, using ISO/International conventions and protocols only. > > http://mc.stfx.eu/Neo we should actually consider putting that into pharo ;) I guess we can do a quick discussion round at the sprint on Friday...

Oct. 30, 2012

Re: [Pharo-project] Problem with Date comparing summer time CEST

by Sven Van Caekenberghe

On 30 Oct 2012, at 22:20, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > For me, my image's internal timezone is set to UTC. I use Chronos and store > everything as UTC, use UTC values for every calculation, then convert it > back to the local time only on display to a user. Yes, Paul: this is the only way to remain sane ;-) That is one of the reasons why I wrote ZTimestamp, a point-in-time alternative to DateAndTime and TimeStamp with second precision, living in UTC, using ISO/International conventions and protocols only. http://mc.stfx.eu/Neo Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Oct. 30, 2012

Re: [Pharo-project] Problem with Date comparing summer time CEST

by Camillo Bruni

If you're on 1.4 you have serious issues when moving between timezones (in this case the winter/summer time switch) see https://code.google.com/p/pharo/issues/detail?id=5919 and http://forum.world.st/Bug-in-DateAndTime-td2293749.html the problem is, that the reference point was not defined in a fixed time-zone but rather relative, which breaks under certain conditions!! On 2012-10-30, at 22:20, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > Sabine KnÃ¶fel wrote >> I have an attribute "date" in a domain object. Last week, I created some >> objects with this attribute. Today I created objects again with the same >> date value in this attribute. When comparing the dates (=), the result is >> false. >> >> Reason is, that in germany, we had a switch from Central European Summer >> Time (CEST) (Sommerzeit) to Daylight Saving Time (DST) this weekend. >> >> Date has an attribute "start" which has an instance of DateAndTime. This >> DateAndTime object has another value depending on the CEST/DST >> >> 2012-10-02T00:00:00+ > * >> 01:00 > * >> (DST) >> 2012-10-02T00:00:00+ > * >> 02:00 > * >> (CEST) >> >> When I create two Dates with same date, I expect that = evaluates to true, >> independent from the CEST/DST. But Date (Timespan) uses > / >> = comparand >> ^ self class = comparand class >> and: [ > * >> self start = comparand start > * >> and: [ self duration = comparand duration ]] > / >> >> >> What do you recommend? Create my own compare method? Did I miss something? > > > Localized dates and times are awful to mess with because the timing of the > daylight savings transitions are political and vary from place to place and > year to year. > > This is good advice from Tom Rushworth on comparing dates: > http://forum.world.st/Should-Dates-be-Timezone-specific-tp3647678p3649107.h… > > Also on Squeaksource the TimeZoneDatabase and Chronos packages have > mechanisims for keeping up to date about when offsets should be changed in > the image. > > For me, my image's internal timezone is set to UTC. I use Chronos and store > everything as UTC, use UTC values for every calculation, then convert it > back to the local time only on display to a user. > > > > -- > View this message in context: http://forum.world.st/Problem-with-Date-comparing-summer-time-CEST-tp465335… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Oct. 30, 2012

Re: [Pharo-project] Problem with Date comparing summer time CEST

by Paul DeBruicker

Sabine KnÃ¶fel wrote > I have an attribute "date" in a domain object. Last week, I created some > objects with this attribute. Today I created objects again with the same > date value in this attribute. When comparing the dates (=), the result is > false. > > Reason is, that in germany, we had a switch from Central European Summer > Time (CEST) (Sommerzeit) to Daylight Saving Time (DST) this weekend. > > Date has an attribute "start" which has an instance of DateAndTime. This > DateAndTime object has another value depending on the CEST/DST > > 2012-10-02T00:00:00+ * > 01:00 * > (DST) > 2012-10-02T00:00:00+ * > 02:00 * > (CEST) > > When I create two Dates with same date, I expect that = evaluates to true, > independent from the CEST/DST. But Date (Timespan) uses / > = comparand > ^ self class = comparand class > and: [ * > self start = comparand start * > and: [ self duration = comparand duration ]] / > > > What do you recommend? Create my own compare method? Did I miss something? Localized dates and times are awful to mess with because the timing of the daylight savings transitions are political and vary from place to place and year to year. This is good advice from Tom Rushworth on comparing dates: http://forum.world.st/Should-Dates-be-Timezone-specific-tp3647678p3649107.h… Also on Squeaksource the TimeZoneDatabase and Chronos packages have mechanisims for keeping up to date about when offsets should be changed in the image. For me, my image's internal timezone is set to UTC. I use Chronos and store everything as UTC, use UTC values for every calculation, then convert it back to the local time only on display to a user. -- View this message in context: http://forum.world.st/Problem-with-Date-comparing-summer-time-CEST-tp465335… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 30, 2012

Re: [Pharo-project] [OT] RTalk

by Camillo Bruni

On 2012-10-30, at 18:39, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > On 30/10/12 15:39, dimitris chloupis wrote: >> Hey Torsten and thanks for the reply. >> >> I am not here to recommend pharo to move to JVM. Rtalk author also >> mention this, moving a language to another platform like JVM is quite >> easy , > > I've spent quite some time playing with Java and JVM. I don't think in case of Smalltalk language it would be exactly 'quite easy' to move > to JVM. > There are certain constructs, prevalent in Smalltalk codebase, that would be tricky to implement *efficiently* on JVM. Non-local returns, > proceedable exceptions, class extensions, snapshotting to name some. not to mention instance migration! (which might be circumvented in non-development mode)

Oct. 30, 2012

Re: [Pharo-project] Phobos Jenkins builds

by Bernardo Ezequiel Contreras

F.... cool! i NEED one ! On Tue, Oct 30, 2012 at 3:26 PM, Esteban A. Maringolo <emaringolo(a)gmail.com>wrote: > There even are Github branded mates: http://instagram.com/p/LrLRBtJr03/ > > > > > > -- > View this message in context: > http://forum.world.st/Phobos-Jenkins-builds-tp4653316p4653362.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Bernardo E.C.

Oct. 30, 2012

Re: [Pharo-project] Phobos Jenkins builds

by Esteban A. Maringolo

There even are Github branded mates: http://instagram.com/p/LrLRBtJr03/ -- View this message in context: http://forum.world.st/Phobos-Jenkins-builds-tp4653316p4653362.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 30, 2012

Re: [Pharo-project] Phobos Jenkins builds

by Pavel Krivanek

Yes, I had no doubts from where the name comes from ;-) I was only surprised that it is not the project by Mateman Polito ;-) -- Pavel On Tue, Oct 30, 2012 at 6:59 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Pavel, we drink it in the restaurant at the PharoConf ;) > Anyway, it is also a project being done between RMOD (France) and Argentina > and it is related about VM and how to implement as much as possible "at the > language level"...or something like that. > Cami or Guido may tell you better. > > On Tue, Oct 30, 2012 at 6:56 PM, Bernardo Ezequiel Contreras > <vonbecmann(a)gmail.com> wrote: >> >> <joke> >> The collateral effects of the Argentinian invasion! >> see >> http://en.wikipedia.org/wiki/Mate_(beverage) >> </joke> >> >> >> >> On Tue, Oct 30, 2012 at 2:26 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> wrote: >>> >>> Well, I need to create a configuration. >>> >>> BTW what is Mate? ;-) >>> >>> -- Pavel >>> >>> On Tue, Oct 30, 2012 at 3:07 PM, Camillo Bruni <camillobruni(a)gmail.com> >>> wrote: >>> > Some remarks: >>> > ------------- >>> > >>> > - Could you use the latest setup as in >>> > >>> > https://ci.lille.inria.fr/pharo/view/Rmod/job/Mate/configure >>> > >>> > cause I want to get rid of all bash scripts in jenkins if possible >>> > ;) >>> > >>> > >>> > best >>> > cami >>> > >>> > >>> > On 2012-10-30, at 14:42, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>> > wrote: >>> > >>> >> Hi, >>> >> >>> >> I created a set of Jobs related to Phobos on the Jenkins server: >>> >> https://ci.lille.inria.fr/pharo/view/Phobos/ >>> >> >>> >> The latest changes in Phobos include special integer input fields with >>> >> automatic focus change, trees styling, various small fixes etc. >>> >> >>> >> Cheers, >>> >> -- Pavel >>> >> >>> > >>> > >>> >> >> >> >> -- >> Bernardo E.C. > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Oct. 30, 2012