Hi all,
I noticed the following: | t1 t2 s | t1 := TimeStamp now. s := String streamContents: [:stream | t1 storeOn: stream ]. t2 := TimeStamp readFrom: s readStream. { t1 offset. t2 offset. t1 = t2 } printIt -> {-0:07:00:00 . 0:00:00:00 . false} A web search turned up this thread from 2017: I’m wondering if there has been any resolution or if the situation is the same: I should try the fixes from UTCDateAndTime. Happy to write a test if this is worth the effort. Thanks, Tim |
On Mon, Apr 02, 2018 at 08:26:39AM -0700, Tim Johnson wrote:
> Hi all, > > I noticed the following: > > | t1 t2 s | > t1 := TimeStamp now. > s := String streamContents: [:stream | t1 storeOn: stream ]. > t2 := TimeStamp readFrom: s readStream. > { t1 offset. t2 offset. t1 = t2 } printIt -> {-0:07:00:00 . 0:00:00:00 . false} > > A web search turned up this thread from 2017: > > http://forum.world.st/DateAndTime-offset-just-bit-me-td4938463.html <http://forum.world.st/DateAndTime-offset-just-bit-me-td4938463.html> > > I???m wondering if there has been any resolution or if the situation is the same: I should try the fixes from UTCDateAndTime. > > Happy to write a test if this is worth the effort. Hi Tim, I would be very happy to see a few people try UTCDateAndTime. I think that it makes time calculations and local offsets much easier to understand, and it provides a good performance boost also. I should warn you that I have not tried loading it fresh into the latest trunk image in a while, so you may encounter problems. If so I'll fix them (but not today, I'll be traveling). Thanks, Dave |
In reply to this post by Tim Johnson-2
Don't use TimeStamp. I see several issues which break your snippet:
1) #printOn: and #storeOn: ignore time zone information (offset). 2) Class side #readFrom: ignores time zone information (offset). 3) Class side #readFrom: can not fully parse the output of #storeOn:. It seems to only work by accident. 4) It's a subclass of DateAndTime, but it seems to add noting generally useful. Based on the class comment, it has the same purpose as DateAndTime, but that's not the case. So, use DateAndTime instead: | t1 t2 s | t1 := DateAndTime now. s := String streamContents: [:stream | t1 storeOn: stream ]. t2 := Compiler evaluate: s. { t1 offset. t2 offset. t1 = t2 } "==> {0:02:00:00 . 0:02:00:00 . true}" Levente On Mon, 2 Apr 2018, Tim Johnson wrote: > Hi all, > I noticed the following: > > | t1 t2 s | > t1 := TimeStamp now. > s := String streamContents: [:stream | t1 storeOn: stream ]. > t2 := TimeStamp readFrom: s readStream. > { t1 offset. t2 offset. t1 = t2 } printIt -> {-0:07:00:00 . 0:00:00:00 . false} > > A web search turned up this thread from 2017: > > http://forum.world.st/DateAndTime-offset-just-bit-me-td4938463.html > > I’m wondering if there has been any resolution or if the situation is the same: I should try the fixes from UTCDateAndTime. > > Happy to write a test if this is worth the effort. > > Thanks, > Tim > > > > |
On Mon, Apr 2, 2018 at 8:59 AM, Levente Uzonyi <[hidden email]> wrote: Don't use TimeStamp. I see several issues which break your snippet: Seconded - don't use TimeStamp. It did exist before DateAndTime, then was moved to a subclass to ease porting. Besides the reasons Levente gave, a few external packages (on SqueakMap/SqueakSource) contain TimeStamp extensions and/or redefinition that really, really mess up with the current definition. If you get unlucky enough to load one of these and you are using TimeStamp, things stop working (or mostly work while corrupting your data). -cbc So, use DateAndTime instead: |
Thanks all! I always used DateAndTime previously, but thought about
using TimeStamp instead for a new project. I will rethink that and go back to DateAndTime. Best, Tim On 2018-04-02 11:19, Chris Cunningham wrote: > On Mon, Apr 2, 2018 at 8:59 AM, Levente Uzonyi <[hidden email]> > wrote: > >> Don't use TimeStamp. I see several issues which break your snippet: >> 1) #printOn: and #storeOn: ignore time zone information (offset). >> 2) Class side #readFrom: ignores time zone information (offset). >> 3) Class side #readFrom: can not fully parse the output of #storeOn:. >> It seems to only work by accident. >> 4) It's a subclass of DateAndTime, but it seems to add noting >> generally useful. Based on the class comment, it has the same purpose >> as DateAndTime, but that's not the case. > > Seconded - don't use TimeStamp. It did exist before DateAndTime, then > was moved to a subclass to ease porting. > Besides the reasons Levente gave, a few external packages (on > SqueakMap/SqueakSource) contain TimeStamp extensions and/or > redefinition that really, really mess up with the current definition. > If you get unlucky enough to load one of these and you are using > TimeStamp, things stop working (or mostly work while corrupting your > data). > > -cbc > So, use DateAndTime instead: > > | t1 t2 s | > t1 := DateAndTime now. > s := String streamContents: [:stream | t1 storeOn: stream ]. > t2 := Compiler evaluate: s. > { t1 offset. t2 offset. t1 = t2 } "==> {0:02:00:00 . 0:02:00:00 . > true}" > > Levente > > On Mon, 2 Apr 2018, Tim Johnson wrote: > > Hi all, > I noticed the following: > > | t1 t2 s | > t1 := TimeStamp now. > s := String streamContents: [:stream | t1 storeOn: stream ]. > t2 := TimeStamp readFrom: s readStream. > { t1 offset. t2 offset. t1 = t2 } printIt -> {-0:07:00:00 . > 0:00:00:00 . false} > > A web search turned up this thread from 2017: > > http://forum.world.st/DateAndTime-offset-just-bit-me-td4938463.html > > I'm wondering if there has been any resolution or if the situation is > the same: I should try the fixes from UTCDateAndTime. > > Happy to write a test if this is worth the effort. > > Thanks, > Tim |
In reply to this post by Levente Uzonyi
Hi Levente,
> On Apr 2, 2018, at 8:59 AM, Levente Uzonyi <[hidden email]> wrote: > > Don't use TimeStamp. Can we deprecate it then? > I see several issues which break your snippet: > 1) #printOn: and #storeOn: ignore time zone information (offset). > 2) Class side #readFrom: ignores time zone information (offset). > 3) Class side #readFrom: can not fully parse the output of #storeOn:. It seems to only work by accident. > 4) It's a subclass of DateAndTime, but it seems to add noting generally useful. Based on the class comment, it has the same purpose as DateAndTime, but that's not the case. > > So, use DateAndTime instead: > > | t1 t2 s | > t1 := DateAndTime now. > s := String streamContents: [:stream | t1 storeOn: stream ]. > t2 := Compiler evaluate: s. > { t1 offset. t2 offset. t1 = t2 } "==> {0:02:00:00 . 0:02:00:00 . true}" > > Levente > >> On Mon, 2 Apr 2018, Tim Johnson wrote: >> >> Hi all, >> I noticed the following: >> | t1 t2 s | >> t1 := TimeStamp now. >> s := String streamContents: [:stream | t1 storeOn: stream ]. >> t2 := TimeStamp readFrom: s readStream. >> { t1 offset. t2 offset. t1 = t2 } printIt -> {-0:07:00:00 . 0:00:00:00 . false} >> A web search turned up this thread from 2017: >> http://forum.world.st/DateAndTime-offset-just-bit-me-td4938463.html >> I’m wondering if there has been any resolution or if the situation is the same: I should try the fixes from UTCDateAndTime. >> Happy to write a test if this is worth the effort. >> Thanks, >> Tim > |
Hi Eliot,
On Mon, 2 Apr 2018, Eliot Miranda wrote: > Hi Levente, > >> On Apr 2, 2018, at 8:59 AM, Levente Uzonyi <[hidden email]> wrote: >> >> Don't use TimeStamp. > > Can we deprecate it then? Sure, but there are still users in the image. Mainly Monticello, SqueakMap Client and SUnit. It will take some time to go through them and properly rewrite the code. Levente > >> I see several issues which break your snippet: >> 1) #printOn: and #storeOn: ignore time zone information (offset). >> 2) Class side #readFrom: ignores time zone information (offset). >> 3) Class side #readFrom: can not fully parse the output of #storeOn:. It seems to only work by accident. >> 4) It's a subclass of DateAndTime, but it seems to add noting generally useful. Based on the class comment, it has the same purpose as DateAndTime, but that's not the case. >> >> So, use DateAndTime instead: >> >> | t1 t2 s | >> t1 := DateAndTime now. >> s := String streamContents: [:stream | t1 storeOn: stream ]. >> t2 := Compiler evaluate: s. >> { t1 offset. t2 offset. t1 = t2 } "==> {0:02:00:00 . 0:02:00:00 . true}" >> >> Levente >> >>> On Mon, 2 Apr 2018, Tim Johnson wrote: >>> >>> Hi all, >>> I noticed the following: >>> | t1 t2 s | >>> t1 := TimeStamp now. >>> s := String streamContents: [:stream | t1 storeOn: stream ]. >>> t2 := TimeStamp readFrom: s readStream. >>> { t1 offset. t2 offset. t1 = t2 } printIt -> {-0:07:00:00 . 0:00:00:00 . false} >>> A web search turned up this thread from 2017: >>> http://forum.world.st/DateAndTime-offset-just-bit-me-td4938463.html >>> I’m wondering if there has been any resolution or if the situation is the same: I should try the fixes from UTCDateAndTime. >>> Happy to write a test if this is worth the effort. >>> Thanks, >>> Tim >> |
Lots of database packages rely on variants of that class : TimeStamp and Timestamp... Some packages even provide their own version ! It's always been a mess!
----------------- 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)
On Tuesday, April 3, 2018, 9:14:20 a.m. EDT, Levente Uzonyi <[hidden email]> wrote:
Hi Eliot, On Mon, 2 Apr 2018, Eliot Miranda wrote: > Hi Levente, > >> On Apr 2, 2018, at 8:59 AM, Levente Uzonyi <[hidden email]> wrote: >> >> Don't use TimeStamp. > > Can we deprecate it then? Sure, but there are still users in the image. Mainly Monticello, SqueakMap Client and SUnit. It will take some time to go through them and properly rewrite the code. Levente > >> I see several issues which break your snippet: >> 1) #printOn: and #storeOn: ignore time zone information (offset). >> 2) Class side #readFrom: ignores time zone information (offset). >> 3) Class side #readFrom: can not fully parse the output of #storeOn:. It seems to only work by accident. >> 4) It's a subclass of DateAndTime, but it seems to add noting generally useful. Based on the class comment, it has the same purpose as DateAndTime, but that's not the case. >> >> So, use DateAndTime instead: >> >> | t1 t2 s | >> t1 := DateAndTime now. >> s := String streamContents: [:stream | t1 storeOn: stream ]. >> t2 := Compiler evaluate: s. >> { t1 offset. t2 offset. t1 = t2 } "==> {0:02:00:00 . 0:02:00:00 . true}" >> >> Levente >> >>> On Mon, 2 Apr 2018, Tim Johnson wrote: >>> >>> Hi all, >>> I noticed the following: >>> | t1 t2 s | >>> t1 := TimeStamp now. >>> s := String streamContents: [:stream | t1 storeOn: stream ]. >>> t2 := TimeStamp readFrom: s readStream. >>> { t1 offset. t2 offset. t1 = t2 } printIt -> {-0:07:00:00 . 0:00:00:00 . false} >>> A web search turned up this thread from 2017: >>> http://forum.world.st/DateAndTime-offset-just-bit-me-td4938463.html >>> I’m wondering if there has been any resolution or if the situation is the same: I should try the fixes from UTCDateAndTime. >>> Happy to write a test if this is worth the effort. >>> Thanks, >>> Tim >> |
Any elimination of TimeStamp should be accompanied by ensuring
backward compatibility with existing persistent instances in our own Monticello database. It'd be too infeasible to require a conversion of all old mcz packages. On Tue, Apr 3, 2018 at 5:57 PM, Benoit St-Jean via Squeak-dev <[hidden email]> wrote: > Lots of database packages rely on variants of that class : TimeStamp and > Timestamp... Some packages even provide their own version ! > > It's always been a mess! > > > ----------------- > 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) > > > On Tuesday, April 3, 2018, 9:14:20 a.m. EDT, Levente Uzonyi > <[hidden email]> wrote: > > > Hi Eliot, > > On Mon, 2 Apr 2018, Eliot Miranda wrote: > >> Hi Levente, >> >>> On Apr 2, 2018, at 8:59 AM, Levente Uzonyi <[hidden email]> wrote: >>> >>> Don't use TimeStamp. >> >> Can we deprecate it then? > > Sure, but there are still users in the image. Mainly Monticello, SqueakMap > Client and SUnit. > It will take some time to go through them and properly rewrite the code. > > > Levente > >> >>> I see several issues which break your snippet: >>> 1) #printOn: and #storeOn: ignore time zone information (offset). >>> 2) Class side #readFrom: ignores time zone information (offset). >>> 3) Class side #readFrom: can not fully parse the output of #storeOn:. It >>> seems to only work by accident. >>> 4) It's a subclass of DateAndTime, but it seems to add noting generally >>> useful. Based on the class comment, it has the same purpose as DateAndTime, >>> but that's not the case. >>> >>> So, use DateAndTime instead: >>> >>> | t1 t2 s | >>> t1 := DateAndTime now. >>> s := String streamContents: [:stream | t1 storeOn: stream ]. >>> t2 := Compiler evaluate: s. >>> { t1 offset. t2 offset. t1 = t2 } "==> {0:02:00:00 . 0:02:00:00 . true}" >>> >>> Levente >>> >>>> On Mon, 2 Apr 2018, Tim Johnson wrote: >>>> >>>> Hi all, >>>> I noticed the following: >>>> | t1 t2 s | >>>> t1 := TimeStamp now. >>>> s := String streamContents: [:stream | t1 storeOn: stream ]. >>>> t2 := TimeStamp readFrom: s readStream. >>>> { t1 offset. t2 offset. t1 = t2 } printIt -> {-0:07:00:00 . >>>> 0:00:00:00 . false} >>>> A web search turned up this thread from 2017: >>>> http://forum.world.st/DateAndTime-offset-just-bit-me-td4938463.html >>>> I’m wondering if there has been any resolution or if the situation is >>>> the same: I should try the fixes from UTCDateAndTime. >>>> Happy to write a test if this is worth the effort. >>>> Thanks, >>>> Tim >>> > > > > |
In reply to this post by Squeak - Dev mailing list
I was wondering if images for different platforms (Mac, Linux, Windows)
and VMs (32bit, 64bit) are, code-wise, the same? By "the same", I mean
do they all have the exact same code base or some classes/methods are in
some and not in others or different? ----------------- 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) |
On Wednesday 11 April 2018 03:45 AM, Benoit St-Jean via Squeak-dev wrote:
> I was wondering if images for different platforms (Mac, Linux, Windows) > and VMs (32bit, 64bit) are, code-wise, the same? By "the same", I mean > do they all have the exact same code base or some classes/methods are in > some and not in others or different? Short answer - Images yes, VMs no. "Squeak" without qualification refers to the image. The official release contains separate VMs for different platforms but only a single image. Squeak VM is different for each platform, but they do share the source code for bytecode interpreter, primitives and object manager and some (algorithmic) plugins. The launcher and device-based plugins (e.g. display) are host-specific. Generally, you should be able to save your image on Windows and resume it on a Linux or Mac without any issues. There may be minor irritants like differently configured CTRL/ALT/CMD keys or fonts but the overall experience is stunningly smooth. HTH .. Subbu |
Hi Benoît,
+1 I do some development on windows and copy the image to a Raspberry Pi running Linux. I can't test everything as my windows box doesn't have the GPIO pins of the Raspberry but that is to be expected. Lou On Wed, 11 Apr 2018 12:53:37 +0530, K K Subbu <[hidden email]> wrote: >On Wednesday 11 April 2018 03:45 AM, Benoit St-Jean via Squeak-dev wrote: >> I was wondering if images for different platforms (Mac, Linux, Windows) >> and VMs (32bit, 64bit) are, code-wise, the same? By "the same", I mean >> do they all have the exact same code base or some classes/methods are in >> some and not in others or different? > >Short answer - Images yes, VMs no. > >"Squeak" without qualification refers to the image. The official release >contains separate VMs for different platforms but only a single image. > >Squeak VM is different for each platform, but they do share the source >code for bytecode interpreter, primitives and object manager and some >(algorithmic) plugins. The launcher and device-based plugins (e.g. >display) are host-specific. > >Generally, you should be able to save your image on Windows and resume >it on a Linux or Mac without any issues. There may be minor irritants >like differently configured CTRL/ALT/CMD keys or fonts but the overall >experience is stunningly smooth. > >HTH .. Subbu > Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon |
> On 11-04-2018, at 5:46 AM, Louis LaBrunda <[hidden email]> wrote: > > Hi Benoît, > > +1 Indeed - image files are identical across platforms and pretty much always have been. The only general issue when moving an image from one to another is if the writer has used implicit assumptions about a platform - the commonest I see is assuming the format of file names and carelessly using string concatenations and '/'' & '.' to assemble strings instead of proper file name objects. > > I do some development on windows and copy the image to a Raspberry Pi running Linux. I can't > test everything as my windows box doesn't have the GPIO pins of the Raspberry but that is to be > expected. Actually... https://www.raspberrypi.org/blog/gpio-expander/ I'm fairly sure that you could also build the pigpio library to run on a pc/mac and talk to pretty much any actual Pi also running the pigpiod daemon. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim All programmers are playwrights and all computers are lousy actors. |
In reply to this post by Squeak - Dev mailing list
Benoit St-Jean wrote on Tue, 10 Apr 2018 22:15:13 +0000 (UTC)
> I was wondering if images for different platforms (Mac, Linux, Windows) > and VMs (32bit, 64bit) are, code-wise, the same? By "the same", I mean > do they all have the exact same code base or some classes/methods > are in some and not in others or different? All images that have been released for Squeak have been exactly the same for all platforms. You can save your work on an ARM based Raspberry Pi and continue it on a x86 Windows PC. That said, there are a few classes that are specific to each platform. See FileDirectory, for example, which has as subclasses AcornFileDirectory, DosFileDirectory, MacFileDirectory, MacHFSPlusFileDirectory and UnixFileDirectory. Your application should normally only use the abstract class and the right class for your particular platform will get called and this will more or less work for the Pi to PC move I described above. I wrote "more or less" because obviously open files would be a problem, but they wouldn't make sense on a different machine in any case. You could strip out the classes for the platforms you are not interested in, but they are such a tiny part of the image it wouldn't be worth it. The subclasses of KeyboardInputInterpreter {MacRomanInputInterpreter . NoInputInterpreter . WinShiftJISInputInterpreter . MacShiftJISInputInterpreter . UnixEUCJPInputInterpreter . UnixUTF8JPInputInterpreter . WinGB2312InputInterpreter . WinKSX1001InputInterpreter . SymbolInputInterpreter . CP1250InputInterpreter . ISO88592InputInterpreter . MacUnicodeInputInterpreter . UTF32InputInterpreter . UnicodeInputInterpreter . UTF32JPInputInterpreter . UnixUnicodeInputInterpreter} are the only other platform specific parts of the image I am aware of. In the early days the official Squeak images included all the code needed to generate the virtual machine. That has since been moved to a separate package called VMMaker which you now have to load explicitly if you want to. That has quite a bit of platform specific code. -- Jecel |
Free forum by Nabble | Edit this page |