July 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [squeak-dev] Re: Time now print24

by David T. Lewis

On Fri, Jul 08, 2016 at 09:11:46PM -0500, Chris Muller wrote: > Eliot, I'm not against your suggestion about seconds:, but there is no > way you should have to mutate an object for sake of only printing it. > It should merely be the responsibility of the printing to meet the > needed requirement. +1 Dave > > On Fri, Jul 8, 2016 at 12:49 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi All, > > > > On Jul 7, 2016, at 9:33 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > Hi All, > > > > how does one produce a nice timestamp, simply date and time as in > > > > 7/7/2016 09:19:38 > > > > Trivial, right? > > > > So > > > > Date today mmddyyyy, ' ', Time now print24 '7/7/2016 09:22:40.914' > > > > .914, ah, nanos. How useful. Let's get rid of them. No nanos: accessor so > > > > Date today mmddyyyy, ' ', (Time now nanos: 0) print24 => MNU > > > > but there's a seconds accessor, so > > > > Date today mmddyyyy, ' ', (Time now seconds: Time now seconds; print24) > > '7/7/2016 00:00:41 > > > > ?? So seconds: is private, and isn't the dual of Time seconds: > > > > Time seconds > > ^ self second > > Time second > > ^ self asDuration seconds > > Duration seconds > > "Answer the number of seconds the receiver represents." > > ^seconds rem: SecondsInMinute > > > > Looks broken to me. > > > > > > Let me be more explicit, and ask for permission to fix this. One basic bug > > is the asymmetry between seconds, an accessor that answers seconds mod 60, > > and seconds: that doesn't set seconds mod 60. But seconds: is private and > > could be replaced by eg setTotalSeconds:, presumably without breaking > > clients, allowing seconds: to be redefined to do the right thing. > > > > I note that the historic bug of changing the semantics of Time now to answer > > something with finer resolution than one second could have been avoided by > > adding eg exactlyNow or preciselyNow. > > > > The problem with nanos (apart from the horrible abbreviation) is that it > > presumes a maximum precision that isn't well chosen. Microseconds work out > > much better. And I hope we change the internal representation accordingly. > > But there needs to be done accessor that rounds to the nearest second > > without revealing the internal precision. Time now toTheNearestSecond or > > Time theNearestSecondNow or...? > > > > > > Personally I think print24 should not print sub seconds. > > > > cc'ing to Pharo because I want this timestamp to be the same in both > > dialects for a profiling tool we want to use in both dialects. > > _,,,^..^,,,_ > > best, Eliot > > > > > > > >

July 9, 2016

Re: [Pharo-dev] [squeak-dev] Re: Time now print24

by David T. Lewis

On Thu, Jul 07, 2016 at 10:49:10PM -0700, Eliot Miranda wrote: > Hi All, > > > On Jul 7, 2016, at 9:33 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > Hi All, > > > > how does one produce a nice timestamp, simply date and time as in > > > > 7/7/2016 09:19:38 > > > > Trivial, right? > > > > So > > > > Date today mmddyyyy, ' ', Time now print24 '7/7/2016 09:22:40.914' > > > > .914, ah, nanos. How useful. Let's get rid of them. No nanos: accessor so > > > > Date today mmddyyyy, ' ', (Time now nanos: 0) print24 => MNU > > > > but there's a seconds accessor, so > > > > Date today mmddyyyy, ' ', (Time now seconds: Time now seconds; print24) '7/7/2016 00:00:41 > > > > ?? So seconds: is private, and isn't the dual of Time seconds: > > > > Time seconds > > ^ self second > > Time second > > ^ self asDuration seconds > > Duration seconds > > "Answer the number of seconds the receiver represents." > > ^seconds rem: SecondsInMinute > > > > Looks broken to me. > > Let me be more explicit, and ask for permission to fix this. One basic bug is the asymmetry between seconds, an accessor that answers seconds mod 60, and seconds: that doesn't set seconds mod 60. But seconds: is private and could be replaced by eg setTotalSeconds:, presumably without breaking clients, allowing seconds: to be redefined to do the right thing. > Yes please fix it. It is clearly wrong to have #seconds and #seconds: refer to two different things. And since #seconds: is private, that would be the thing to change. Changing it to #setTotalSeconds: would be good, although I note that there is a #asSeconds method too, so maybe #setSeconds: might match better with #asSeconds. But either would be fine, and yes please, go ahead and fix it. > I note that the historic bug of changing the semantics of Time now to answer something with finer resolution than one second could have been avoided by adding eg exactlyNow or preciselyNow. > I'm not sure it is a bug, more like a difference in presentation versus internal representation. I think that #now should mean "now", not "now rounded to the nearest second". But if I display the time now, I probably would prefer it to be displayed to the nearest second. > The problem with nanos (apart from the horrible abbreviation) is that it presumes a maximum precision that isn't well chosen. Microseconds work out much better. And I hope we change the internal representation accordingly. But there needs to be done accessor that rounds to the nearest second without revealing the internal precision. Time now toTheNearestSecond or Time theNearestSecondNow or...? > Absolutely right. In the UTCDateAndTime changes, the magnitude of DateAndTime is utcMicroseconds for exactly this reason. That does not preclude nanosecond precision, it just means that the common case of microsecond precision uses an integer, and higher precisions are represented as Fraction. So the common case is fast, and higher precision remains possible. Somewhat more generally, the scale is in units of seconds. Precision should be unlimited (any Number) and accuracy is dependent on the underlying system clock (milliseconds or maybe microseconds if you are lucky). Most everyday computers may be accurate to milliseconds but report precision to microseconds. Specialized real time systems (e.g. GPS) may legitimately deal with higher accuracies and are probably not lying if they claim nanosecond precision. Human beings may drift a few hours one way or the other without noticing the difference, and are thus generally satisfied with full second precision and not much accuracy at all ;-) Dave > > > > Personally I think print24 should not print sub seconds. > > > > cc'ing to Pharo because I want this timestamp to be the same in both dialects for a profiling tool we want to use in both dialects. > > _,,,^..^,,,_ > > best, Eliot >

July 9, 2016

Re: [Pharo-dev] [squeak-dev] Re: Time now print24

by Chris Muller

> But there needs to be done accessor that rounds to the nearest second > without revealing the internal precision. Time now toTheNearestSecond or > Time theNearestSecondNow or...? Time now truncatedTo: 1 second. Time now roundedTo: 1 second.

July 9, 2016

Re: [Pharo-dev] [squeak-dev] Re: Time now print24

by Chris Muller

Eliot, I'm not against your suggestion about seconds:, but there is no way you should have to mutate an object for sake of only printing it. It should merely be the responsibility of the printing to meet the needed requirement. On Fri, Jul 8, 2016 at 12:49 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi All, > > On Jul 7, 2016, at 9:33 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi All, > > how does one produce a nice timestamp, simply date and time as in > > 7/7/2016 09:19:38 > > Trivial, right? > > So > > Date today mmddyyyy, ' ', Time now print24 '7/7/2016 09:22:40.914' > > .914, ah, nanos. How useful. Let's get rid of them. No nanos: accessor so > > Date today mmddyyyy, ' ', (Time now nanos: 0) print24 => MNU > > but there's a seconds accessor, so > > Date today mmddyyyy, ' ', (Time now seconds: Time now seconds; print24) > '7/7/2016 00:00:41 > > ?? So seconds: is private, and isn't the dual of Time seconds: > > Time seconds > ^ self second > Time second > ^ self asDuration seconds > Duration seconds > "Answer the number of seconds the receiver represents." > ^seconds rem: SecondsInMinute > > Looks broken to me. > > > Let me be more explicit, and ask for permission to fix this. One basic bug > is the asymmetry between seconds, an accessor that answers seconds mod 60, > and seconds: that doesn't set seconds mod 60. But seconds: is private and > could be replaced by eg setTotalSeconds:, presumably without breaking > clients, allowing seconds: to be redefined to do the right thing. > > I note that the historic bug of changing the semantics of Time now to answer > something with finer resolution than one second could have been avoided by > adding eg exactlyNow or preciselyNow. > > The problem with nanos (apart from the horrible abbreviation) is that it > presumes a maximum precision that isn't well chosen. Microseconds work out > much better. And I hope we change the internal representation accordingly. > But there needs to be done accessor that rounds to the nearest second > without revealing the internal precision. Time now toTheNearestSecond or > Time theNearestSecondNow or...? > > > Personally I think print24 should not print sub seconds. > > cc'ing to Pharo because I want this timestamp to be the same in both > dialects for a profiling tool we want to use in both dialects. > _,,,^..^,,,_ > best, Eliot > > > >

July 9, 2016

Re: [Pharo-dev] [squeak-dev] Time now print24

by Brad Selfridge

+100 for ISO. ----- Brad Selfridge -- View this message in context: http://forum.world.st/Time-now-print24-tp4905425p4905677.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 8, 2016

Re: [Pharo-dev] Sound on Debian

by J.F. Rick

Th vm-sound-pulse plugin packaged with the Squeak VM works on Ubuntu. Cheers, Jeff On Fri, Jul 8, 2016 at 1:14 PM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Was not able to make it work in Ubuntu either, for me it work only on MacOS > > On Fri, Jul 8, 2016 at 5:54 PM jannik laval <jannik.laval(a)gmail.com> > wrote: > >> Hi pharoers, >> >> I just tried sounds on phratch on Debian 8. It returns this message: >> >> sound_Start(default) >> soundStart: snd_add_pcm_handler: Fonction non implantÃ©e >> >> Is it a problem known ? >> >> Here is my configuration: >> >> Image >> ----- >> /usr/lib/Phratch/shared/Pharo4.0.image >> Pharo4.0 >> Latest update: #40626 >> Unnamed >> >> Virtual Machine >> --------------- >> /usr/lib/Phratch/bin/pharo >> NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: >> acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 >> NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: >> acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 >> https://github.com/pharo-project/pharo-vm.git Commit: >> ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200 >> By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14826 >> >> Unix built on May 15 2014 18:29:39 Compiler: 4.6.3 >> VMMaker versionString https://github.com/pharo-project/pharo-vm.git >> Commit: ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 >> +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14826 >> NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: >> acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 >> NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: >> acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 >> >> >> Cheers, >> -- >> ~~Jannik Laval~~ >> Enseignant-chercheur >> Responsable PÃ©dagogique Licence Coordonnateur de Projet en SystÃ¨me >> d'Information >> IUT LumiÃ¨re, UniversitÃ© Lyon LumiÃ¨re >> laboratoire DISP >> http://www.jannik-laval.eu >> http://www.phratch.com >> http://www.approchealpes.info >> >

July 8, 2016

Re: [Pharo-dev] [squeak-dev] Time now print24

by Alistair Grant

On Fri, Jul 08, 2016 at 10:49:51AM +0200, Tobias Pape wrote: > > On 07.07.2016, at 18:33, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > Hi All, > > > > how does one produce a nice timestamp, simply date and time as in > > > > 7/7/2016 09:19:38 > > ... > > PS: I'd prefer ISO, nonetheless: https://xkcd.com/1179/ +2 (1 for ISO and 1 for the xkcd reference) Cheers, Alistair

July 8, 2016

Re: [Pharo-dev] [Holidays] 14 days no updates: 14th to end of July

by Peter UhnÃ¡k

On Fri, Jul 8, 2016 at 9:10 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 08 Jul 2016, at 21:04, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > > Have fun dear integrators! :) > > +10 > +â«

July 8, 2016

Re: [Pharo-dev] [Holidays] 14 days no updates: 14th to end of July

by Sven Van Caekenberghe

> On 08 Jul 2016, at 21:04, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Have fun dear integrators! :) +10 >> On 08 Jul 2016, at 19:57, stepharo <stepharo(a)free.fr> wrote: >> >> Hi marcus >> >> I will see if the temperature forces me to stay inside after afternoon naps and before jumping in water. >> In such case I will looks at easy fixes. >> But I will not do it regularly. I will probably have a look the week of 20 and take a real break from tomorrow to end of next week. >> >> Stef >>> Hi, >>> >>> We just saw that everyone who can press the button for a final integration >>> will be on Holidays from July 14 to the end of the month. >>> >>> This means there will be no update, but the issue tracker will stay open of course, >>> so issues can be submitted, fixed and reviewedâ¦ they will just not end up the downloadable >>> image for that 2 weeks. >>> >>> Marcus >>> >> >> > >

July 8, 2016

Re: [Pharo-dev] [Holidays] 14 days no updates: 14th to end of July

by Yuriy Tymchuk

Have fun dear integrators! :) > On 08 Jul 2016, at 19:57, stepharo <stepharo(a)free.fr> wrote: > > Hi marcus > > I will see if the temperature forces me to stay inside after afternoon naps and before jumping in water. > In such case I will looks at easy fixes. > But I will not do it regularly. I will probably have a look the week of 20 and take a real break from tomorrow to end of next week. > > Stef >> Hi, >> >> We just saw that everyone who can press the button for a final integration >> will be on Holidays from July 14 to the end of the month. >> >> This means there will be no update, but the issue tracker will stay open of course, >> so issues can be submitted, fixed and reviewedâ¦ they will just not end up the downloadable >> image for that 2 weeks. >> >> Marcus >> > >

July 8, 2016