- Pharo-users - lists.pharo.org

Re: [Pharo-users] My TimeZone won't print.

by Sven Van Caekenberghe

Then you should move ;-) Of course, if a functional object (your local timezone) exists in your image, it should be able to print itself. That is a bug that we should fix. Your suggested solution is good. The Timezone class>>#timezones table is very bad though. As is the class Timezone by the way. This class is a simplification gone too far. It is only useful (and used) to deal with the current offset today, as reported by your VM/OS. Timezones need DST transitions. Also abbreviations and the names used are not unique and cannot be resolved in 2 directions. The real solution is something like ZTimestamp's ZTimezone which uses the Olsen database http://en.wikipedia.org/wiki/Tz_database. You can load this package from the Pharo Catalog. It has a certain size (memory cost), of course. But that would still not fix the problem with abbreviations not being bidirectional. (an offset of 1h can be any of a number of abbreviations). And it would not solve the problem with timezone offsets in ISO. (+0100 can be tons of timezones, with potentially different rules). Something like the following would be self-containted/context-free unambiguous. 2017-11-22T09:50:17+Australia/Sydney But as far as I know, there is no such standard (it is not part of ISO 8601). > On 22 Nov 2017, at 02:56, Richard A. O'Keefe <ok(a)cs.otago.ac.nz> wrote: > > To reproduce this, start up Pharo, create a Playground, > and in the Playground type > DateAndTime now timeZone > and <Cmd+p> to print it. > > But do this in New Zealand. Changing to <Cmd+i> > > On 22/11/17 1:47 PM, pharo-users-request(a)lists.pharo.org wrote: >> Send Pharo-users mailing list submissions to >> pharo-users(a)lists.pharo.org > > Inspector on a TimeZone (error printing) > ... > self error printing > offset 0:13:00:00 > abbreviation nil > name nil > > The simplest possible change would be to make > TimeZone>>abbreviation be > > ^abbreviation ifNil: [offset printString] > > after which > DateAndTime now timeZone<Cmd+p> > => a TimeZone(0:13:00:00) > > Another approach would be to paste > > self offset: 12 hours name: 'New Zealand Standard Time' abbreviation: 'NZST'. > self offset: 13 hours name: 'New Zealand Daylight Time' abbreviation: 'NZDT'. > > into TimeZone class>>timeZones > > but that wouldn't fix the problem for anywhere else. >

Nov. 22, 2017

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo TechTalk 21 Nov: Discord Demo

by Marcus Denker

Hi, I added links to the TechTalk archive: http://pharo.org/TechTalk > On 21 Nov 2017, at 20:02, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > > Hi, > > the TechTalk record is available at the same link: https://www.youtube.com/watch?v=33kXsOiP6wA <https://www.youtube.com/watch?v=33kXsOiP6wA> > and includes outline to simplify navigation. > > Cheers, > Juraj > > > TechTalk Outline: > - 01:58 The beginning of the talk > - 04:30 Webhook > - 04:33 How to Create Webhook > - 05:39 Webhook Examples > - 10:33 Webhook Use Case: Script of the Day from Nautilus Code Browser > - 18:39 Webhook Use Case: Server Problem Notification > - 22:45 Bot App (chatbot) > - 24:47 How to Create a Bot App > - 28:28 Bot App Examples > - 33:17 Bot Use Case: Source Code Expertise > - 41:40 Standard User Client > - 42:57 User Client Example > - 45:06 User Client Use Case: Asking Directly from Pharo Playground > - 47:06 User Client Use Case: Receiving Questions and Answering in Pharo > - 50:50 Final Thoughts About Discord Integration in Inspector and Debugger > - 52:44 Discussion > >> On Nov 21, 2017, at 12:54, Juraj Kubelka <juraj.kubelka(a)icloud.com <mailto:juraj.kubelka@icloud.com>> wrote: >> >> Hi! >> >> The TechTalk starts in about 10 minutes. Join us on Discord, the techtalk channel. >> >> Cheers, >> Juraj >> >> >>> On Nov 21, 2017, at 10:11, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>> >>> The link to the live stream is this: >>> >>> https://www.youtube.com/watch?v=33kXsOiP6wA <https://www.youtube.com/watch?v=33kXsOiP6wA> >>> >>> It start in a bit less than 3 hours. >>> >>> Marcus >>> >>>> On 18 Nov 2017, at 09:13, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>>> >>>> Pharo TechTalk: Discord Demo >>>> When? 21 Nov 2017 5:00 PM - 7:00 PM (UTC+01:00) >>>> >>>> Topic: "Discord communication Demoâ, how to script discord from Pharo. >>>> >>>> https://association.pharo.org/event-2642665 <https://association.pharo.org/event-2642665> >>> >> >

Nov. 22, 2017

Re: [Pharo-users] Timespan translateToUTC problematic

by Ben Coman

On 22 November 2017 at 01:07, Alistair Grant <akgrant0710(a)gmail.com> wrote: > On 20 November 2017 at 09:16, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > We can discuss about this ad infinitum. I think we all agree that > > there are 2 views (abstract calendar date and concrete time > > interval/span, which requires a TZ), as well as 2 possible ways to > > deal with the second case (TZ inside date or as context outside of the > > date). > > > Right, I think changing things now will be quite a bit of work. > > However there are a couple of things we can do to make life a bit easier: > > 1. Add a method that facilitates TZ independent comparisons. > 2. Add a bit more information in the class comments. > > > I've named the method #dmyEquals: below, although I don't particularly > like it. If anyone has a better idea, please reply. > how about #localEquals: i.e. local ==> ignore timezones btw, now we should move to discuss the default date format? https://xkcd.com/1179/ \ ;)-ben== /

Nov. 22, 2017

Re: [Pharo-users] Timespan translateToUTC problematic

by Benoit St-Jean

Oups!Â Didn't see that one.Â Yes! Â ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein) From: Sean P. DeNigris <sean(a)clipperadams.com> To: pharo-users(a)lists.pharo.org Sent: Tuesday, November 21, 2017 9:14 PM Subject: Re: [Pharo-users] Timespan translateToUTC problematic Pharo Smalltalk Users mailing list wrote > #hasSameDayAs:Â ----------------- Wouldn't that be #isSameDayAs:? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Nov. 22, 2017

Re: [Pharo-users] Timespan translateToUTC problematic

by Sean P. DeNigris

Pharo Smalltalk Users mailing list wrote > #hasSameDayAs:Â ----------------- Wouldn't that be #isSameDayAs:? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Nov. 22, 2017

My TimeZone won't print.

by Richard A. O'Keefe

To reproduce this, start up Pharo, create a Playground, and in the Playground type DateAndTime now timeZone and <Cmd+p> to print it. But do this in New Zealand. Changing to <Cmd+i> On 22/11/17 1:47 PM, pharo-users-request(a)lists.pharo.org wrote: > Send Pharo-users mailing list submissions to > pharo-users(a)lists.pharo.org Inspector on a TimeZone (error printing) ... self error printing offset 0:13:00:00 abbreviation nil name nil The simplest possible change would be to make TimeZone>>abbreviation be ^abbreviation ifNil: [offset printString] after which DateAndTime now timeZone<Cmd+p> => a TimeZone(0:13:00:00) Another approach would be to paste self offset: 12 hours name: 'New Zealand Standard Time' abbreviation: 'NZST'. self offset: 13 hours name: 'New Zealand Daylight Time' abbreviation: 'NZDT'. into TimeZone class>>timeZones but that wouldn't fix the problem for anywhere else.

Nov. 22, 2017

Re: [Pharo-users] Timespan translateToUTC problematic

by Benoit St-Jean

#hasSameDayAs:Â ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein) From: Alistair Grant <akgrant0710(a)gmail.com> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Sent: Tuesday, November 21, 2017 12:07 PM Subject: Re: [Pharo-users] Timespan translateToUTC problematic On 20 November 2017 at 09:16, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > We can discuss about this ad infinitum. I think we all agree that > there are 2 views (abstract calendar date and concrete time > interval/span, which requires a TZ), as well as 2 possible ways to > deal with the second case (TZ inside date or as context outside of the > date). Right, I think changing things now will be quite a bit of work. However there are a couple of things we can do to make life a bit easier: 1. Add a method that facilitates TZ independent comparisons. 2. Add a bit more information in the class comments. I've named the method #dmyEquals: below, although I don't particularly like it.Â If anyone has a better idea, please reply. I've also added some proposed text for the class comments. If I don't hear back in a couple of days I'll submit a PR (with automated tests). Cheers, Alistair ---- dmyEquals: aDate Â Â "Perform a time zone independent comparison of the dates, i.e. only compare day, month and year" Â Â ^self year = aDate year and: [ Â Â Â Â self monthIndex = aDate monthIndex and: Â Â Â Â [ self dayOfMonth = aDate dayOfMonth ] ] ---- Class comment: Instances of Date are Timespans with duration of 1 day. Their default creation assumes a start of midnight in the local time zone. !Comparing Dates We tend to use dates in one of two modes: - Time zone dependent - Time zone independent In the first instance, dates are only the same if they are in the same time zone (otherwise they are two different 24 hour periods).Â This is the default behaviour of Date. In the second, comparison is only interested in whether the day, month and year are the same. As an example, take someone's birthday.Â If I want to know whether we were born on the same day, I will want to compare dates without time zones.Â If I want to know if it is currently their birthday where they are, I'll want to use time zones. [[[language=smalltalk | birthday1 birthday2 | birthday1 := (DateAndTime fromString: '2018/01/01T00:00:00+10') asDate. birthday2 := (DateAndTime fromString: '2018/01/01T00:00:00+01') asDate. "Is it person 1's birthday now? (where they live: UTC+10)" birthday1 includes: DateAndTime now. "Do person 1 and person 2 have the same birthday?" birthday1 dmyEquals: birthday2. ]]]

Nov. 22, 2017

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo TechTalk 21 Nov: Discord Demo

by Dimitris Chloupis

Well done :) Now you can make a discord client inside the Pharo image if you want. On Tue, 21 Nov 2017 at 21:03, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > Hi, > > the TechTalk record is available at the same link: > https://www.youtube.com/watch?v=33kXsOiP6wA > and includes outline to simplify navigation. > > Cheers, > Juraj > > > TechTalk Outline: > - 01:58 The beginning of the talk > - 04:30 Webhook > - 04:33 How to Create Webhook > - 05:39 Webhook Examples > - 10:33 Webhook Use Case: Script of the Day from Nautilus Code Browser > - 18:39 Webhook Use Case: Server Problem Notification > - 22:45 Bot App (chatbot) > - 24:47 How to Create a Bot App > - 28:28 Bot App Examples > - 33:17 Bot Use Case: Source Code Expertise > - 41:40 Standard User Client > - 42:57 User Client Example > - 45:06 User Client Use Case: Asking Directly from Pharo Playground > - 47:06 User Client Use Case: Receiving Questions and Answering in Pharo > - 50:50 Final Thoughts About Discord Integration in Inspector and > Debugger > - 52:44 Discussion > > On Nov 21, 2017, at 12:54, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > > Hi! > > The TechTalk starts in about 10 minutes. Join us on Discord, the techtalk > channel. > > Cheers, > Juraj > > > On Nov 21, 2017, at 10:11, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > The link to the live stream is this: > > https://www.youtube.com/watch?v=33kXsOiP6wA > > It start in a bit less than 3 hours. > > Marcus > > On 18 Nov 2017, at 09:13, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Pharo TechTalk: Discord Demo > When? 21 Nov 2017 5:00 PM - 7:00 PM (UTC+01:00) > > Topic: "Discord communication Demoâ, how to script discord from Pharo. > > https://association.pharo.org/event-2642665 > > > > >

Nov. 21, 2017

Re: [Pharo-users] Why does the test runner show red when I correct a test?

by Richard Sargent

A test that asserts nothing has only asserted that the code ran through without throwing an error. :-) I like your proposal that such a test is an inherently failing test. (Of course, that will result in the student adding a single assertion at the end, of the form "self assert: true"!) On Tue, Nov 21, 2017 at 4:07 PM, Prof. Andrew P. Black <black(a)cs.pdx.edu> wrote: > While we are discussing colors, what should we do about a test that does > not make any assertions at all? > > A couple of years ago, a smart student who was working on a testing > dialect for me decided that such tests should be in a new category all of > their own. Later I simplified things and just made these tests fail. I am > pretty convinced now that this is the right behaviour. It certainly suits > my purposes (teaching TDD); if the student omits to make any assertions, > they have a failing test. The message is: "Failure: test made no > assertions". > > Currently, such a test is green in Pharo. In 2013, I filed a bug report > on a bunch of tests of #printOn: on collections that made no assertions. > (The test writer didnât understand how streams worked, and made assertions > for each element of the empty string.) I was reminded of this just this > week, because those tests have yet to be fixed. I suspect that if they had > been yellow, rather than green, then they would have been fixed before now. > > I plan to fix those tests on Friday, but I also wonder about changing the > behaviour of the testing framework. What do you think? > > Andrew > > >

Nov. 21, 2017

Re: [Pharo-users] Why does the test runner show red when I correct a test?

by Prof. Andrew P. Black

While we are discussing colors, what should we do about a test that does not make any assertions at all? A couple of years ago, a smart student who was working on a testing dialect for me decided that such tests should be in a new category all of their own. Later I simplified things and just made these tests fail. I am pretty convinced now that this is the right behaviour. It certainly suits my purposes (teaching TDD); if the student omits to make any assertions, they have a failing test. The message is: "Failure: test made no assertions". Currently, such a test is green in Pharo. In 2013, I filed a bug report on a bunch of tests of #printOn: on collections that made no assertions. (The test writer didnât understand how streams worked, and made assertions for each element of the empty string.) I was reminded of this just this week, because those tests have yet to be fixed. I suspect that if they had been yellow, rather than green, then they would have been fixed before now. I plan to fix those tests on Friday, but I also wonder about changing the behaviour of the testing framework. What do you think? Andrew

Nov. 21, 2017