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

Re: [Pharo-dev] Why String do not implement #displayString?

by Denis Kudriashov

Hi Esteban. We have method #displayOn: but it has different purpose: argument is a kind of canvas. So it is not related. 2018-04-10 17:28 GMT+02:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > Isn't #displayString implemented in terms of #displayOn: the same way > #printString is implemented in terms of "printOn:"? > > And in the case of String #displayString should return the receiver (it > is, self), so the following should be true. > > | s | > s := 'Hello, ''Funny'' World'. > s displayString = s. "true" > s printString = s. "false" > > Regards, > > > On 10/04/2018 12:21, Denis Kudriashov wrote: > > Hi. > > > > According to the comment of #displayString it should be used as default > > textual representation of objects in the UI: > > > > "While printString is about to give a detailled information about an > > object, displayString is a message that should return a short > > string-based representation to be used by list and related UI > > frameworks. By default, simply return printString." > > "asString should not be implemented in Object, and kept for > > conversion between strings, symbols, text and characters." > > > > But String itself does not respect this message: > > > > 'some string' displayString " ==> '''someString''' " > > > > > > Is it bug? Or is there any reason for this? > > > > Best regards, > > Denis > > -- > Esteban A. Maringolo > >

April 10, 2018

Re: [Pharo-dev] call for help: answer on HN :)

by Sean P. DeNigris

philippeback wrote > Who would have envisioned the Pharo of today in the beginning? > I am thankful for Pharo, trolls be damned. Absolutely agree!! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 10, 2018

Re: [Pharo-dev] Why String do not implement #displayString?

by Esteban A. Maringolo

Isn't #displayString implemented in terms of #displayOn: the same way #printString is implemented in terms of "printOn:"? And in the case of String #displayString should return the receiver (it is, self), so the following should be true. | s | s := 'Hello, ''Funny'' World'. s displayString = s. "true" s printString = s. "false" Regards, On 10/04/2018 12:21, Denis Kudriashov wrote: > Hi. > > According to the comment of #displayString it should be used as default > textual representation of objects in the UI: > > "While printString is about to give a detailled information about an > object, displayString is a message that should return a short > string-based representation to be used by list and related UI > frameworks. By default, simply return printString." > "asString should not be implemented in Object, and kept for > conversion between strings, symbols, text and characters." > > But String itself does not respect this message: > > 'some string' displayString " ==> '''someString''' " > > > Is it bug? Or is there any reason for this? > > Best regards, > Denis -- Esteban A. Maringolo

April 10, 2018

Why String do not implement #displayString?

by Denis Kudriashov

Hi. According to the comment of #displayString it should be used as default textual representation of objects in the UI: "While printString is about to give a detailled information about an object, displayString is a message that should return a short string-based representation to be used by list and related UI frameworks. By default, simply return printString." "asString should not be implemented in Object, and kept for conversion between strings, symbols, text and characters." But String itself does not respect this message: 'some string' displayString " ==> '''someString''' " Is it bug? Or is there any reason for this? Best regards, Denis

April 10, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Sven Van Caekenberghe

> On 10 Apr 2018, at 16:46, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > This a recurring topic in the mailing list. > > See: > http://forum.world.st/Interesting-Date-Time-Thread-on-Squeak-Dev-td4778652.… > > Or directly go to this https://www.w3.org/TR/timezone/ > > Pharo's Date and Time classes are incremental/offset based, whereas a > field based Date behaves more as "expected" in terms of adding > days/months/days/hours/etc. That is not really true (that it depends on the internal representation). Any date/time/datetime object needs API/behaviour that allows accessing and manipulation in human terms. How this is implemented is up to the implementation (duh). Having separate year/month/day fields does not at all shield you from the fact that 'adding a day to jan 27' is different to 'adding a day to feb 27', of 'dec 31' - the implementation has to make sure that all this works correctly (and this is often pretty complex, needing to take many aspects into account). Having separate fields suggest this is easy, but that is a delusion. Anyway, I am pretty sure you understand. And about Java's Calendar, I know that it is an object that manipulates other objects, it just has a pretty ugly interface, and does not feel very OO like. I hear many people curse it, but it probably does its job. > The internal implementation might vary and there are going to be > tradeoffs, but IMO for scheduling solutions calendar based are better > suited. > > Regards! > > > On 10/04/2018 11:13, Stephane Ducasse wrote: >> What is a field based date and time? >> >> On Tue, Apr 10, 2018 at 1:32 PM, Esteban A. Maringolo >> <emaringolo(a)gmail.com> wrote: >>> What is missing in the current Pharo image is a field based >>> Date/DateTime instead of an offset+duration one as it currently is. >>> >>> Why not use Chronos instead? AFAIR Chronos provides that. >>> >>> An alternative would be to implement a "Calendar" (as in >>> Java.util.Calendar [1]), that can exist in parallel with the existing >>> Date class. >>> >>> Regards, >>> >>> [1] https://developer.android.com/reference/java/util/Calendar.html >>> >>> On 10/04/2018 03:30, Stephane Ducasse wrote: >>>> Hi Paul >>>> >>>> I agree and instead of patching the current system I would start using >>>> TDD to design >>>> a new Date package. >>>> >>>> stef >>>> >>>> On Mon, Apr 9, 2018 at 8:42 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: >>>>> I think #= is a bad selector for Date and should be avoided when determining >>>>> whether something happens on a date, or whether two dates are the same. We >>>>> all know March 24th in London covers a different 24 hours than March 24th in >>>>> Hawaii but Date>>#= does not. >>>>> >>>>> >>>>> >>>>> I think whats needed are more descriptive selectors like >>>>> >>>>> >>>>> Date>>#isSameOnDateAs: aDateOrDateAndTime >>>>> Date>>#overlapsWithDate: aDate >>>>> DateAndTime>>#occursOnDate: aDate >>>>> DateAndTime>>#sameHMSButDifferentUTCIn: aTimeZoneKey >>>>> DateAndTime>>#sameUTCButDifferentHMSIn: aTimeZoneKey >>>>> >>>>> and change Date>>#= to #shouldNotImplement. >>>>> >>>>> >>>>> FWIW I also don't like #offset: as before you send it you know the timezone >>>>> and after you may let that knowledge be forgotten. Real offsets can change >>>>> as laws change. >>>>> >>>>> >>>>> >>>>> I think people are aware of this but if you have need for comparing dates & >>>>> times then you must use a library that accesses the regularly updated Olson >>>>> timezone database on your system and classes that respect time zones. Time >>>>> zones are political, and legal definitions of offsets can change hours >>>>> before the DST transition dates & times. >>>>> >>>>> >>>>> I don't think it matters which default timezone you pick for the image if >>>>> you're not going to take them into account when doing comparisons. >>>>> >>>>> >>>>> Unfortunately there isn't a way to avoid this complexity until DST goes >>>>> away. >>>>> >>>>> >>>>> There's certainly flaws to how we currently do it and I think >>>>> TimeZoneDatabase and Chronos make good attempts to fix it. I haven't looked >>>>> at Chalten but would guess its good too. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Sean P. DeNigris wrote >>>>>> I was bitten by this very annoying bug again. As most of us probably know >>>>>> due >>>>>> to the steady stream of confused ML posts in the past, the bug in summary >>>>>> is >>>>>> that we have an incomplete timezone implementation that doesn't properly >>>>>> take into account historical DST changes. This flares up without warning >>>>>> especially when DST toggles. I created a wiki page to document the >>>>>> situation: https://github.com/seandenigris/pharo/wiki/Time-Zone-Fiasco >>>>>> >>>>>> Here's an example blowup: at 11:59pm before DST changes, eval aDate := >>>>>> '1/1/1901' asDate. Now, wait two minutes and at 12:01am eval self assert: >>>>>> '1/1/1901' asDate = aDate andâ¦ whammo, an exception! The "different" >>>>>> offsets >>>>>> render equal dates unequal depending on when the objects were created. >>>>>> >>>>>> The more I think about it, the more I think that we should just assume UTC >>>>>> for all Date[AndTime]s that don't explicitly specify an offset, rather >>>>>> than >>>>>> pretend to set an offset which is only sometimes correct. More advanced >>>>>> users can use one of the available libraries to get full timezone support. >>>>>> What do you think? >>>>>> >>>>>> >>>>>> >>>>>> ----- >>>>>> Cheers, >>>>>> Sean >>>>>> -- >>>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>>>> >>> -- >>> Esteban A. Maringolo >>> > > -- > Esteban A. Maringolo > > >

April 10, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Esteban A. Maringolo

On 10/04/2018 11:37, Sven Van Caekenberghe wrote: > Right now, we are discussing what should be in the image by default. > > The current system is not bad at all, it just has deficiencies that could be improved upon. > >> An alternative would be to implement a "Calendar" (as in >> Java.util.Calendar [1]), that can exist in parallel with the existing >> Date class. > > I am not so sure that is a good example. First time I new about Calendar I found it awkward (starting with the name). Years later I understood its purpose in comparison with a "point in time" Date or Timestamp. The name and implementation are TBD, but what I'm trying to exemplify is a particular case in a popular language. Regards!

April 10, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Esteban A. Maringolo

This a recurring topic in the mailing list. See: http://forum.world.st/Interesting-Date-Time-Thread-on-Squeak-Dev-td4778652.… Or directly go to this https://www.w3.org/TR/timezone/ Pharo's Date and Time classes are incremental/offset based, whereas a field based Date behaves more as "expected" in terms of adding days/months/days/hours/etc. The internal implementation might vary and there are going to be tradeoffs, but IMO for scheduling solutions calendar based are better suited. Regards! On 10/04/2018 11:13, Stephane Ducasse wrote: > What is a field based date and time? > > On Tue, Apr 10, 2018 at 1:32 PM, Esteban A. Maringolo > <emaringolo(a)gmail.com> wrote: >> What is missing in the current Pharo image is a field based >> Date/DateTime instead of an offset+duration one as it currently is. >> >> Why not use Chronos instead? AFAIR Chronos provides that. >> >> An alternative would be to implement a "Calendar" (as in >> Java.util.Calendar [1]), that can exist in parallel with the existing >> Date class. >> >> Regards, >> >> [1] https://developer.android.com/reference/java/util/Calendar.html >> >> On 10/04/2018 03:30, Stephane Ducasse wrote: >>> Hi Paul >>> >>> I agree and instead of patching the current system I would start using >>> TDD to design >>> a new Date package. >>> >>> stef >>> >>> On Mon, Apr 9, 2018 at 8:42 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: >>>> I think #= is a bad selector for Date and should be avoided when determining >>>> whether something happens on a date, or whether two dates are the same. We >>>> all know March 24th in London covers a different 24 hours than March 24th in >>>> Hawaii but Date>>#= does not. >>>> >>>> >>>> >>>> I think whats needed are more descriptive selectors like >>>> >>>> >>>> Date>>#isSameOnDateAs: aDateOrDateAndTime >>>> Date>>#overlapsWithDate: aDate >>>> DateAndTime>>#occursOnDate: aDate >>>> DateAndTime>>#sameHMSButDifferentUTCIn: aTimeZoneKey >>>> DateAndTime>>#sameUTCButDifferentHMSIn: aTimeZoneKey >>>> >>>> and change Date>>#= to #shouldNotImplement. >>>> >>>> >>>> FWIW I also don't like #offset: as before you send it you know the timezone >>>> and after you may let that knowledge be forgotten. Real offsets can change >>>> as laws change. >>>> >>>> >>>> >>>> I think people are aware of this but if you have need for comparing dates & >>>> times then you must use a library that accesses the regularly updated Olson >>>> timezone database on your system and classes that respect time zones. Time >>>> zones are political, and legal definitions of offsets can change hours >>>> before the DST transition dates & times. >>>> >>>> >>>> I don't think it matters which default timezone you pick for the image if >>>> you're not going to take them into account when doing comparisons. >>>> >>>> >>>> Unfortunately there isn't a way to avoid this complexity until DST goes >>>> away. >>>> >>>> >>>> There's certainly flaws to how we currently do it and I think >>>> TimeZoneDatabase and Chronos make good attempts to fix it. I haven't looked >>>> at Chalten but would guess its good too. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Sean P. DeNigris wrote >>>>> I was bitten by this very annoying bug again. As most of us probably know >>>>> due >>>>> to the steady stream of confused ML posts in the past, the bug in summary >>>>> is >>>>> that we have an incomplete timezone implementation that doesn't properly >>>>> take into account historical DST changes. This flares up without warning >>>>> especially when DST toggles. I created a wiki page to document the >>>>> situation: https://github.com/seandenigris/pharo/wiki/Time-Zone-Fiasco >>>>> >>>>> Here's an example blowup: at 11:59pm before DST changes, eval aDate := >>>>> '1/1/1901' asDate. Now, wait two minutes and at 12:01am eval self assert: >>>>> '1/1/1901' asDate = aDate andâ¦ whammo, an exception! The "different" >>>>> offsets >>>>> render equal dates unequal depending on when the objects were created. >>>>> >>>>> The more I think about it, the more I think that we should just assume UTC >>>>> for all Date[AndTime]s that don't explicitly specify an offset, rather >>>>> than >>>>> pretend to set an offset which is only sometimes correct. More advanced >>>>> users can use one of the available libraries to get full timezone support. >>>>> What do you think? >>>>> >>>>> >>>>> >>>>> ----- >>>>> Cheers, >>>>> Sean >>>>> -- >>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>>> >>>> >>>> >>>> >>>> -- >>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>>> >> -- >> Esteban A. Maringolo >> -- Esteban A. Maringolo

April 10, 2018

Re: [Pharo-dev] [TechTalk] April 12: GIT with Iceberg

by Esteban Lorenzano

more like to present the new UI (it received a complete revamp, so we need to inform about it ;) ) cheers! Esteban > On 10 Apr 2018, at 16:34, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > There next TechTalk will be April 12: GIT with Iceberg > > https://association.pharo.org/event-2797068 > > > A regular chat about Pharo. Happens on Discord. > > The Tech talks are open to both members and non-members! > > Topic: GIT with Iceberg. Demo of improved UI > > We will send an information to all subscribers some hours before the talk starts. > > >

April 10, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Sven Van Caekenberghe

> On 10 Apr 2018, at 13:32, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > > What is missing in the current Pharo image is a field based > Date/DateTime instead of an offset+duration one as it currently is. > > Why not use Chronos instead? AFAIR Chronos provides that. Like Sean said elsewhere, the exist (much) better add-on frameworks, if you choose to use them, but they are optional. Right now, we are discussing what should be in the image by default. The current system is not bad at all, it just has deficiencies that could be improved upon. > An alternative would be to implement a "Calendar" (as in > Java.util.Calendar [1]), that can exist in parallel with the existing > Date class. I am not so sure that is a good example. > Regards, > > [1] https://developer.android.com/reference/java/util/Calendar.html > > On 10/04/2018 03:30, Stephane Ducasse wrote: >> Hi Paul >> >> I agree and instead of patching the current system I would start using >> TDD to design >> a new Date package. >> >> stef >> >> On Mon, Apr 9, 2018 at 8:42 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: >>> I think #= is a bad selector for Date and should be avoided when determining >>> whether something happens on a date, or whether two dates are the same. We >>> all know March 24th in London covers a different 24 hours than March 24th in >>> Hawaii but Date>>#= does not. >>> >>> >>> >>> I think whats needed are more descriptive selectors like >>> >>> >>> Date>>#isSameOnDateAs: aDateOrDateAndTime >>> Date>>#overlapsWithDate: aDate >>> DateAndTime>>#occursOnDate: aDate >>> DateAndTime>>#sameHMSButDifferentUTCIn: aTimeZoneKey >>> DateAndTime>>#sameUTCButDifferentHMSIn: aTimeZoneKey >>> >>> and change Date>>#= to #shouldNotImplement. >>> >>> >>> FWIW I also don't like #offset: as before you send it you know the timezone >>> and after you may let that knowledge be forgotten. Real offsets can change >>> as laws change. >>> >>> >>> >>> I think people are aware of this but if you have need for comparing dates & >>> times then you must use a library that accesses the regularly updated Olson >>> timezone database on your system and classes that respect time zones. Time >>> zones are political, and legal definitions of offsets can change hours >>> before the DST transition dates & times. >>> >>> >>> I don't think it matters which default timezone you pick for the image if >>> you're not going to take them into account when doing comparisons. >>> >>> >>> Unfortunately there isn't a way to avoid this complexity until DST goes >>> away. >>> >>> >>> There's certainly flaws to how we currently do it and I think >>> TimeZoneDatabase and Chronos make good attempts to fix it. I haven't looked >>> at Chalten but would guess its good too. >>> >>> >>> >>> >>> >>> >>> >>> >>> Sean P. DeNigris wrote >>>> I was bitten by this very annoying bug again. As most of us probably know >>>> due >>>> to the steady stream of confused ML posts in the past, the bug in summary >>>> is >>>> that we have an incomplete timezone implementation that doesn't properly >>>> take into account historical DST changes. This flares up without warning >>>> especially when DST toggles. I created a wiki page to document the >>>> situation: https://github.com/seandenigris/pharo/wiki/Time-Zone-Fiasco >>>> >>>> Here's an example blowup: at 11:59pm before DST changes, eval aDate := >>>> '1/1/1901' asDate. Now, wait two minutes and at 12:01am eval self assert: >>>> '1/1/1901' asDate = aDate andâ¦ whammo, an exception! The "different" >>>> offsets >>>> render equal dates unequal depending on when the objects were created. >>>> >>>> The more I think about it, the more I think that we should just assume UTC >>>> for all Date[AndTime]s that don't explicitly specify an offset, rather >>>> than >>>> pretend to set an offset which is only sometimes correct. More advanced >>>> users can use one of the available libraries to get full timezone support. >>>> What do you think? >>>> >>>> >>>> >>>> ----- >>>> Cheers, >>>> Sean >>>> -- >>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>> >>> >>> >>> >>> >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>> >> > > -- > Esteban A. Maringolo >

April 10, 2018

[TechTalk] April 12: GIT with Iceberg

by Marcus Denker

Hi, There next TechTalk will be April 12: GIT with Iceberg https://association.pharo.org/event-2797068 A regular chat about Pharo. Happens on Discord. The Tech talks are open to both members and non-members! Topic: GIT with Iceberg. Demo of improved UI We will send an information to all subscribers some hours before the talk starts.

April 10, 2018