On Sun, 13 Mar 2016, David T. Lewis wrote:

> Apologies, this is not right. I was replying from a cell phone and my
> recollection was wrong.
>
> I did at one point implement a #primitiveUtcWithOffset that could receive
> an array of size two as an argument into which the result values are stored,
> instead if allocating the array in the primitive. However, I did *not* commit
> it to VMMaker, and it is not in any currently available VMs.
>
> I think I decided at the time that this approach was dangerous because it
> would invite problems in cases involving multiple processes, where some
> other process might call the primitive using the same array. In that case
> the time value in the array would magically change without the first process
> being aware.

That could only happen if the Array would be shared by multiple processes. 
For example if there were a dedicated class variable to retrieve the 
values from the VM, but that would be nothing but bad design.

Why I thought that the argument should be of any Object with two slots is 
that this would allow us to use the DateAndTime instance itself to fetch 
the values into. Or anyone could come up with their own class to store 
timestamps and still be able to use this primitive.

>
> I still think that it is a good idea, but maybe not worth the risk unless
> there is a noticable affect of performance or GC activity. Of course, adding
> the capability to the primitive would not force anyone to actually use it
> that way.

We have a long running application, which most of the time generates a few 
hundred timestamps per second, but sometimes is goes up to the thousands 
range. That would definitely benefit from such feature.

Levente

>
> Sorry for the misinformation.
>
> Dave
>
>
> On Sat, Mar 12, 2016 at 11:37:55PM -0500, David T. Lewis wrote:
>> I had the same idea, and I already implemented it in trunk interpreter
>> VMMaker, but it is probably not in oscog yet. I did not add it on the
>> image side, although we could do so if we update the VMs.
>>
>> Dave
>>
>>> I always forget to mention, even though I have had this idea since you had
>>> introduced primitiveUtcWithOffset, that it would be better if the
>>> primitive could take an optional argument to store the values in the first
>>> two slots of it instead of creating a new Array. If it's too much burden
>>> to accept any object, then the argument type can be limited to Array.
>>> This change would make it possible to decrease the GC pressure when many
>>> timestamps are created in a row.
>>>
>>> Levente
>>>
>>> On Sat, 12 Mar 2016, David T. Lewis wrote:
>>>
>>>> On Mon, Mar 07, 2016 at 12:21:38AM -0500, David T. Lewis wrote:
>>>>> On Sun, May 24, 2015 at 12:36:02PM -0400, David T. Lewis wrote:
>>>>>> UTCDateAndTime is a UTC based implementation of class DateAndTime with
>>>>>> one instance variable representing the magnitude of the point in time,
>>>>>> and another representing local time zone offset.
>>>>>
>>>>> I have updated the UTCDateAndTime package to make it loadable in the
>>>>> latest
>>>>> Squeak trunk and Spur.
>>>>
>>>> Has anyone looked at this yet? Any interest?
>>>>
>>>> Dave
>>>>
>>>>>
>>>>> A new Monticello repository is at
>>>>> http://www.squeaksource.com/UTCDateAndTime.
>>>>> The home page (with a new SAR) is at
>>>>> http://wiki.squeak.org/squeak/6197.
>>>>>
>>>>> Starting with an updated trunk image, you can load UTCDateAndTime in
>>>>> two ways:
>>>>>
>>>>> 1) Open the http://www.squeaksource.com/UTCDateAndTime repository, and
>>>>> load
>>>>> the MCZ files in sequence beginning with Chronology-Core-dtl.3.
>>>>>
>>>>> 2) In a preferences browser, in category 'updates' set the 'Update URL'
>>>>> preference to 'http://www.squeaksource.com/UTCDateAndTime', and do
>>>>> world -> help... -> update code from server.
>>>>>
>>>>> The main objective of UTCDateAndTime is to make DateAndTime
>>>>> conceptually
>>>>> simpler, but a happy side effect is that it is also significantly
>>>>> faster
>>>>> than the old implementation.
>>>>>
>>>>> Dave
>>>>
>>>>
>>>
>>
>>
>>
>>
>
>