On 29 April 2013 07:39, stephane ducasse wrote:
>
> On Apr 28, 2013, at 11:19 PM, Nicolas Cellier
> wrote:
>
> \\ returns a positive remainder.
> example:
> -1 \\ 86400 -> 86399
> -1 // 86400 -> -1
>
>
> Yes I saw that and now I realized I understand it.
> But funnily I did not notice the diffe
On Apr 28, 2013, at 11:19 PM, Nicolas Cellier
wrote:
> \\ returns a positive remainder.
> example:
> -1 \\ 86400 -> 86399
> -1 // 86400 -> -1
Yes I saw that and now I realized I understand it.
But funnily I did not notice the difference between the use of // and \\
> So the jdn is decremen
\\ returns a positive remainder.
example:
-1 \\ 86400 -> 86399
-1 // 86400 -> -1
So the jdn is decremented and seconds are correctly normalized.
2013/4/28 stephane ducasse
> Nicolas
>
> I read all the slice and I like it (even if they are place where I do not
> get fully it :).
> I'm dead. S
Nicolas
I read all the slice and I like it (even if they are place where I do not get
fully it :).
I'm dead. So may be this is obvious but I do not understand the or: logic
If the seconds is negative I do not understand what is happening.
normalizeSecondsAndNanos
(NanosInSecond <= nanos
Igor
could you review the changes of nicolas - I was planning to do it now but I'm
dead so I will do it but with half of my mind.
Because may be this is better to integrate his changes then do another pass
friday.
Stef
On Apr 28, 2013, at 3:38 PM, Igor Stasenko wrote:
> On 28 April 2013 08:4
Yes, this was valid when jdn, seconds and nanos where maintained in local
time...
2013/4/28 Paul DeBruicker
> Nicolas Cellier wrote
> > What I find strange:
> > - #hash uses the offset... Why ???
>
> Maybe because of this:
> http://forum.world.st/true-hash-tp4621497p4624623.html
>
> which you f
Nicolas Cellier wrote
> What I find strange:
> - #hash uses the offset... Why ???
Maybe because of this:
http://forum.world.st/true-hash-tp4621497p4624623.html
which you fixed here:
See http://forum.world.st/true-hash-tp4621497p4624706.html
--
View this message in context:
http://forum.wo
On 28 April 2013 16:19, Nicolas Cellier
wrote:
> Igor, do you mean everything related to millisecondClockValue (primitive
> 135)?
yes.
> That would be very good to get rid of this useless complexity!
> Of course it might cost some image freeze since used in Delay (I
> accidentally caused a few, b
Igor, do you mean everything related to millisecondClockValue (primitive
135)?
That would be very good to get rid of this useless complexity!
Of course it might cost some image freeze since used in Delay (I
accidentally caused a few, but then narrowed my changes to something
softer).
2013/4/28 Ig
On 28 April 2013 08:41, stephane ducasse wrote:
> thanks a lot!
> Friday we have an official sprint so I'm sure that this issue will be
> addressed.
>
yes. and i hope i will put my changes into the soup as well.
(i did not published them, and some bits are unfinished).
> Stef
>
> See https://phar
thanks a lot!
Friday we have an official sprint so I'm sure that this issue will be
addressed.
Stef
> See https://pharo.fogbugz.com/default.asp?10425# and corresponding SLICE in
> 3.0 inbox
> Note: I don't know what is the policy with the labels/states of these bug
> tracker, and it rather bo
Nicolas Cellier wrote
> Note: I don't know what is the policy with the labels/states of these bug
> tracker, and it rather bothers me, but the SLICE is ready for
> tests/reviews.
I was a bit confused at first too. You have to click "Resolved" and then you
get a whole other set of states, including
See https://pharo.fogbugz.com/default.asp?10425# and corresponding SLICE in
3.0 inbox
Note: I don't know what is the policy with the labels/states of these bug
tracker, and it rather bothers me, but the SLICE is ready for tests/reviews.
2013/4/27 Nicolas Cellier
> There is more:
>
> 1) hasEqual
There is more:
1) hasEqualTicks: use julianDayNumber instead of julianDayNumberUTC
2) (Time dateAndTime now) interprets the (Time localSeconds) which are from
the wrong primitive (seconds ellapsed since squeak epoch translated to
local time) as seconds ellapsed since squeak Epoch (UTC time).
We s
On Apr 27, 2013, at 6:33 PM, Nicolas Cellier
wrote:
> Since DateAndTime comment is out of date (sic !) and current implementation
> seems not free of bug, here is an effort to summarize and understand the
> whole thing, let's call this a review.
Thanks this is a great initiative!
> Please
Since DateAndTime comment is out of date (sic !) and current implementation
seems not free of bug, here is an effort to summarize and understand the
whole thing, let's call this a review.
Please tell me where my interpretations are wrong.
1) The DateAndTime is stored internally as
- a point in UTC
16 matches
Mail list logo