Hi Fabio, Hi All,
On Fri, Oct 19, 2018 at 11:09 AM Fabio Niephaus <lists at fniephaus.com> wrote:

> Hi all,
> On Fri, Oct 19, 2018 at 7:15 PM H. Hirzel <hannes.hirzel at gmail.com> wrote:
>
>> +1 for 5.2.1
>>
>> On 10/19/18, Levente Uzonyi <leves at caesar.elte.hu> wrote:
>> > Do you mean 5.2.1? If not, then no, we just cannot call a different
>> image
>> > 5.2.
>> >
>> > Levente
>> >
>> > On Fri, 19 Oct 2018, Chris Muller wrote:
>> >
>> >> Oh my, I didn't know we had that bug too!  Yes, we will definitely
>> >> want to include that, too, since people might want to be able to join
>> >> trunk development!
>> >>
>> >> We could either freshen the images or just hope the user clicks on
>> >> "Update Squeak".  Personally, I think we should put out a new set of
>> >> images, but I don't know how to do that myself.  Fabio is that you?
>> >> Would you be willing to push them one more time?
>>
>
> Sure, we could do another release in the next few days, but I would
> probably rename the current one to 5.2a on the website and call
> the new one 5.2b instead of 5.2.1 (just like 4.5a and 4.5b). Both would
> live as 5.2 bundles at [1] but with different update levels.
>

+1000


>
> Thoughts? When shall we do this? This Sunday maybe?
>

Sounds good to me. I'd also like to see the latest VM included (the one I
committed yesterday that passed all build tests, VMMaker.oscog-eem.2464)
because it fixes a serious bug in BitBlt that can crash the system when
using external forms.  It is not essential, so if this doesn't feel right
to you, keep the existing VMs (VMMaker.oscog-eem.2437).  But the fix is
goodness and there are no other significant changes other than a fix to
primitiveAdoptInstance, so no chance of regression.  Most of the changes
between 2437 and 2464 are either refactoring to allow VMMaker to function
in Pharo, or work on SpurSelectiveCompactor by Clément which is
experimental and doesn't affect the generated source.  Another change is
merely as refactoring of the vmParameterAt:put: primitives into separate
methods.


>
> Fabio
>
> [1] http://files.squeak.org/5.2/
>
>
>> >>
>> >> Bert, are you going to be okay with this fix at least for now?  Chris
>> >> Cunningham's explanation of why updating #hash to not account for
>> >> offset was an excellent analysis of why it may not be the best idea.
>> >> We should just go back to hard types for now.  I will add one more set
>> >> of convenience methods to Timespan make this even easier and
>> >> more-explicit...   (e,g,, #asDatespan   ^ self asDate).
>> >>
>> >> - Chris
>> >> On Fri, Oct 19, 2018 at 8:56 AM Eliot Miranda <eliot.miranda at gmail.com
>> >
>> >> wrote:
>> >>>
>> >>> Hi Chris,
>> >>>
>> >>> > On Oct 18, 2018, at 7:10 PM, Chris Muller <asqueaker at gmail.com>
>> wrote:
>> >>> >
>> >>> > It's a really bad bug, we should backport the fix to the new 5.2
>> >>> > release ASAP hopefully before the News announcement.
>> >>>
>> >>> If we’re going to “freshen” the 5.2 release we should do it quickly
>> and
>> >>> be sure to include my fix to preferences that allows one to change the
>> >>> update URL.
>> >>>
>> >>> >
>> >>> > In the meantime, a fix is available by loading
>> >>> > Chronology-Core-cmm.15.mcz from the Inbox.  With that you can do
>> >>> > everything.  No limitations, just be sure when you use #asDate on a
>> >>> > DateAndTime, since its a date that originated from a
>> >>> > timezone-sensitive object, it retains that timezone, so if you want
>> to
>> >>> > use it in a system of canonical dates, you need to convert it by
>> >>> > sending either #beCanonical or #stripTimezone (whichever you
>> prefer),
>> >>> > then it will compare equally with the one from "Date today" (which
>> >>> > always produces a canonical date).
>> >>> >
>> >>> > - Chris
>> >>> >> On Thu, Oct 18, 2018 at 8:04 PM Tim Johnson <digit at sonic.net>
>> wrote:
>> >>> >>
>> >>> >> Hi,
>> >>> >>
>> >>> >> I am very grateful to see the discussions about timezones on the
>> list
>> >>> >> recently, because I just got hit by it today.
>> >>> >>
>> >>> >> I couldn't figure out why a Set containing Date objects didn't
>> >>> >> properly
>> >>> >> detect membership of a Date which was clearly present in the Set.
>> It
>> >>> >> was
>> >>> >> because, I realize now, the Date objects in the Set had an offset
>> of
>> >>> >> -0:07:00:00 (they are created by DateAndTime>>#now), and Dates
>> >>> >> created
>> >>> >> by e.g. "Date today" or "Date yesterday" either have no offset or
>> the
>> >>> >> offset is 0:00:00:00.  I have found the comment in Timespan
>> >>> >> class>>#defaultOffset -- but it does not encourage me that I could
>> >>> >> change my defaultOffset to help myself.
>> >>> >>
>> >>> >> In my tests (code snippet below), if I make an OrderedCollection
>> from
>> >>> >> the Set, the OrderedCollection can find the date object, even
>> though
>> >>> >> the
>> >>> >> Set can't.
>> >>> >>
>> >>> >> In the Mean Time (get it?), can I create Dates with offsets?
>> >>> >> "(DateAndTime now - 1 day) asDate" works...?  Or are there any
>> other
>> >>> >> workarounds?  Should I walk away from Date and use something else?
>> >>> >>
>> >>> >> Thanks!
>> >>> >>
>> >>> >> (in a Workspace)
>> >>> >> | dates |
>> >>> >> dates := Set newFrom: { Date yesterday. Date tomorrow.  DateAndTime
>> >>> >> now
>> >>> >> asDate }.
>> >>> >> dates includes: (Date year: 2018 month: 10 day: 18).   "=> false"
>> >>> >> dates asOrderedCollection includes: (Date year: 2018 month: 10 day:
>> >>> >> 18).
>> >>> >>  "=> true"
>> >>> >>
>> >>> >>
>> >>> >> (in an inspector on a Set of dates with offsets)
>> >>> >> | a m |
>> >>> >> a := Date year: 2018 month: 10 day: 17.
>> >>> >> self includes: a.                               "-> false"
>> >>> >> self like: a.                                   "-> nil"
>> >>> >> self asOrderedCollection includes: a.  "-> true"
>> >>> >> m := self array at: 4.          "-> 17 October 2018"
>> >>> >> m start offset.                         "-> -0:07:00:00"
>> >>> >> a start offset                          "-> 0:00:00:00"
>> >>> >>
>> >>> >>
>> >>> >
>> >>>
>>
>>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20181019/95383ca3/attachment-0001.html>