Update to DATE breaks Titleclock?

[chris]

Not being a TitleClock user, I can't say I know much about it.

But if one wanted to avoid disk access with each Date & Wait command call,
I suppose those two commands could be copied to T: and called from there?

Just add the two copies to the start of the script (ahead of the label)
and add the new path to the command calls.

If you want a non-script version, my old Facts program writes the env-var too (although I think it only does the time, not the date).

I considered adding it to yFacts, but it means another more frequent event loop, so I decided against it. It's easy enough to do, though - just a timer event triggering every minute, a GetSysTime and then translate that to a proper time using Locale. I might write something if there's demand for it.

Running a Shell command on a loop doesn't seem to be a terribly efficient way of doing things. Even an ARexx script using the Time() function would be better.

[xenic]

Are you sure it's not that somebody just forgot to set the "PURE" bit before adding it to AmiUpdate??

100% sure. Many commands are no longer resident. It was a cute feature in its time but hardly needed these days.

Based on that logic an Amiga is cute but hardly needed these days.

I ran extensive tests on the date command and detected a 10% speed difference between the Date command loaded from disk and resident Disk command ( using the old "pure" Date command). I think it's somewhat ironic that Amiga forum posts show a lot of user interest in performance (diskspeed, image loading, browser load times etc.) but that the OS4 dev team isn't that concerned about speed. I guess optimization is outdated now.

[ssolie]

I ran extensive tests on the date command and detected a 10% speed difference between the Date command loaded from disk and resident Disk command (using the old "pure" Date command).

If the Date command was being called say 100 times per second I would agree that was something significant. In this case, I think you wasted your time.

I think it's somewhat ironic that Amiga forum posts show a lot of user interest in performance (diskspeed, image loading, browser load times etc.) but that the OS4 dev team isn't that concerned about speed. I guess optimization is outdated now.

I really don't understand such a hostile attack due to the Date command. When we booted from floppy disks, the use of resident commands was essential. It is now 2014 and software maintenance costs far outweigh worrying about supporting floppy disk systems. I won't have developers wasting valuable development time worrying about how fast the Date command is when I feel we need smooth HD video.

See also http://en.wikipedia.org/wiki/Program_op ... o_optimize

[daveyw]

@salass

Not being a TitleClock user, I can't say I know much about it.

But if one wanted to avoid disk access with each Date & Wait command call,
I suppose those two commands could be copied to T: and called from there?

Just add the two copies to the start of the script (ahead of the label)
and add the new path to the command calls.

Thanks,

PJS

Well, no. T: can be anywhere, including HDD. Even if it is on Ram:, Ram: is still a disk.

[salass00]

Well, no. T: can be anywhere, including HDD. Even if it is on Ram:, Ram: is still a disk.

T: is assigned to RAM:T by default unless the user has changed this for some reason (most people won't have). RAM: (ram-handler) stores file contents in memory so it's not really a "disk" as such, also reading and writing are pretty fast as they are simply memory copies.

[xenic]

I really don't understand such a hostile attack due to the Date command.
See also http://en.wikipedia.org/wiki/Program_op ... o_optimize

Sorry, I didn't intend to be hostile. I just disagree with changing pure commands so that they can no longer be resident. It just seems that a number of features that I use frequently have been altered or eliminated in updates over the past year:

I can no longer do AsyncWB drag'n drop backups because links have been changed. As of the ASyncWB update last October, I can no longer drag bare icons (like SYS:System/Shell) to another partition. When I download icon archives, I can't drag individual icons to another directory; I now must use Dopus4. As of the kernal update from last October, DumpDebugBuffer no longer works after a warm reboot. After a warm reboot, the debug output no longer goes into the buffer. I'm not going to list all the changes I disagree with but I just don't see what we're gaining by eliminating features or capabilities.

[chris]

Just knocked this together: envClock

Enjoy.

[daveyw]

I have to say a much belated thanks for the replacement(s!). I think this must be the first time I've commented on a now-broken piece of software and gotten a quick replacement in return.

Thank-you!