Were you expecting a catchy title that hints at the whole theory of the NFL clock?  Or how about basketball time in a relativistic arena?  Rest assured, that we are not there quite yet, nor is there any plan for that sort of thing any time soon. Then again, at least I have a working clock that compiles under Visual Studio 2005 in both debug and release modes.  Even though I haven't tried adding the GPS via USB stuff to something that might actually run with just this collection of files, and maybe a little bit more, if needed, from my frame lisp library.

Yet, things appear to simplify a great deal if I just grab the files that I need, and don't try to rely on needing to link against 14 libraries.  Still, VS 2005 is doing a pretty good job, I think, when it at least tries to get the size of the executable down to just over 400K.  Which is totally bloated by hacker standards.  Shouldn't it be possible to do something like this in something like 40K, or maybe 4K, if I were trying to run this on an Apple II or a C64?  Bloated by hacker standards, but at least it is doing something.  Very reasonable, however, by modern standards.

At least RAM is cheap these days.  Still, it remains to be seen if it is possible to get something like this, with lots of fun libraries and other goodies added, or to be added, let's say, if it looks to be possible to compile for Web assembly, or something else even more fun, like Parallax hardware, or one of the many Arduino hacks that are possible, insofar as actually doing video generation are concerned.  I'll know more about what might be possible when I get to a minimum code set, maybe even if I try just piling all of the code into one big source file and then rewrite, most of it, if not all of it, in pure C, with Win32 API calls instead of MFC.  Then there would be no need to consider Widgets, or Qt, or whatever.

Atari 2600, anyone? Maybe in emulation, but not anytime soon.  Still, I do like the idea of trying something like this on a Commander X16 if I ever decide to get one.  There is another platform that I haven't done anything yet either, that might be fun to putz around with - and that is, of course, the XP clone, ReactOS.

Now that could get very interesting.  Why settle for writing your own game engine, one piece at a time, when you can have a whole OS?

Decided to try an online code conversion tool that converts C++ to Typescript. Does it work?  I don't know.  In any case this is what the actual function that calculates the position of the sun in the sky, given the longitude, latitude, and time of day appears to look like. 

compute_local_aspect() {
    let solar_time, ra_base, ecliptic_aspect;

    this.m_gmt_seconds = 3600.0 * (this.m_hour - this.m_daylight_savings - this.m_time_zone) + 60.0 * this.m_minute + this.m_second;
    solar_time = this.m_gmt_seconds * (1.0 / 3600.0);
    this.m_julian = julian_day(this.m_month, this.m_day, this.m_year) - julian_day(3, 20, 1900) + solar_time * (1.0 / 24.0);
    ecliptic_aspect = ((this.m_julian % 365.242191) * TWO_PI) / 365.242191;
    const ecliptic_aspect_vector = tensor.rotate_z(ecliptic_aspect).multiply(_vector(1, 0, 0));
    ra_base = (ecliptic_aspect * 24.0) / TWO_PI;

    const SIDT = tensor.rotate_z((solar_time - ra_base) * (TWO_PI / 24.0) - TO_RADIANS(this.m_longitude));

    let local_xyz;
    const p = new polar_orientation();
    p.m_theta = 0.0;
    p.m_phi = TO_RADIANS(this.m_latitude);
    local_xyz = p.get_xyz();

    const ROTL = tensor.rotator(
        _vector.normalize(local_xyz.cross(_vector(0, 0, 1))), p.m_phi - PI_OVER_TWO
    );

    const GLSUN = ROTL.multiply(SIDT).multiply(this.m_ROTX);
    this.m_local_solar_vector = GLSUN.multiply(ecliptic_aspect_vector);
    const q = polar_orientation.from_axis(this.m_local_solar_vector);

    this.m_el = TO_DEGREES(q.m_phi);
    this.m_az = ((360.0 + TO_DEGREES(q.m_theta)) % 360.0);
}    

 Pretty much a no-brainer, once most of the real work has been done.  So maybe adding Android or iOS as a possibly supported platform wouldn't be so hard to do after all, that is to say, if I ever decide to try to integrate some of the Teapot in the Garden stuff.

O.K., then, let's take a look at one conversion tool that says I might want to do with the CSignalView.cpp file:

Of course, I have cropped out the name of the tool, and it appears that I don't have enough free credits remaining on this one, so I will wait a while longer, or maybe try a simpler task that uses fewer credits in my free trial.  Of course, having actual PRINTER support would be nice to have for some browser-based apps, and I am not sure what else absolutely would need to be native.  So, some more research is needed before I commit any $$$ to the use of any tool.

In any case, here is the whole rant that the tool gave me, about what it might want to do with one critical part of the Windows GUI portion of the code.

You’ve asked to convert a large C++ MFC (Microsoft Foundation Classes) class (CSignalView) to TypeScript. Here’s my understanding and a proposed plan for the conversion:

Restatement of Your Request:
You want to convert the provided C++ code (which is a
Windows/MFC GUI class for drawing and printing signals, with some OpenGL and GDI code) into TypeScript.

Conversion Plan
1. Framework/Platform Mapping

C++/MFC/Win32 → TypeScript + Web Platform
MFC’s windowing, device context, and drawing APIs will be mapped to HTML5 Canvas and/or WebGL, as these are the closest web equivalents.
Message maps and Windows messages will be mapped to DOM events and class methods.

2. Class and Data Structure Mapping
CSignalView → SignalView TypeScript class.
MFC types (CDC, CBitmap, CRect, etc.) will be mapped to TypeScript classes or interfaces, or replaced with CanvasRenderingContext2D and DOMRect.
Color constants will be mapped to CSS color strings or numbers
3. Drawing and Rendering
GDI/OpenGL drawing code will be mapped to Canvas 2D or WebGL drawing.
Printing logic will be simplified or mapped to canvas export (e.g., to PNG/PDF).

4. Event Handling
MFC message handlers (ON_WM_PAINT, ON_WM_SIZE, etc.) will be mapped to DOM events (resize, paint/draw, timer via setInterval, etc.).

5. State and Member Variables
All member variables will be mapped to class properties.
Windows-specific types (e.g., BOOL, UINT) will be mapped to TypeScript types (boolean, number).

6. Unsupported/Windows-Specific Features
Clipboard, metafile, and some device context features may not have direct equivalents and will be stubbed or replaced with web-appropriate logic.
OpenGL context creation will be mapped to WebGL if needed, or stubbed if not essential.

7. File Structure
All code will be in a single TypeScript file (unless you request otherwise).
Helper classes (e.g., for color, rectangle, etc.) will be defined as needed

And so on.  While having printer support probably isn't needed for a web application, I think it would be nice to have for some things like "audio-in sheet music out applications", and maybe even high school level geometry applications, for those people who might want to actually to render things like Pythagorean proofs in a browser application, that might in turn run on iOS, Android, or in any modern browser.  Unless you need to print, apparently.