[MacPorts] #72625: hamclock: make a port for Hamclock project

[MacPorts]

#72625: hamclock: make a port for Hamclock project
-----------------------+--------------------
  Reporter:  JDLH      |      Owner:  (none)
      Type:  request   |     Status:  new
  Priority:  Normal    |  Milestone:
 Component:  ports     |    Version:
Resolution:            |   Keywords:
      Port:  hamclock  |
-----------------------+--------------------

Comment (by pidloop):

 Oh absolutely, dynamic sizing would be great, and is one of the most
 popular requests I get. But because HamClock began life on a tiny embedded
 environment it would be almost a complete rewrite.

 All of the images, maps and fonts are stored as pointers that get aliased
 to memory blocks at compile time. To do this at runtime would mean
 ''everything'' for ''all'' sizes would have to be in memory, along with
 corresponding changes to temporary storage array sizes that come and go
 and must match. So even the smallest 800x480 would have to carry
 everything for 1600x960, 2400x1440 and 3200x920 images etc, which would
 prevent running on the smaller boards such as Raspberry Pis.

 There's also the issue of graphics resolution. HamClock draws all its
 graphics by itself, it uses no libraries. So changing sizes also requires
 changing resolutions for the Bresenham algorithms, adapting image pixel
 resolutions, the home-grown techniques for jaggie reductions, and more, on
 the fly.

 Another issue is that hamclock sends requests back to my server for all
 the real-time images and data. The replies are tailored to match the
 resolutions of the requesting size. If the request sizes from a given IP
 were to change dynamically, the backend caching algorithms would break
 causing increased load on my server. I already have to use a 16 core
 monster with 8 TB of RAM in order to handle the 10k hamclocks running out
 there every day. Plus, there are clocks that have been running for several
 years, so I would also need to maintain the existing serving mechanisms
 while growing the new set in parallel, further impacting performance.
 Since I pay for the server out of my own pocket I'm not keen to require a
 larger server.

 Would I architect it this way if I started today? No way! But such
 contortions are not so rare for a program that has morphed several times
 over a decade.

 In short: easy to ask, hard to do.

-- 
Ticket URL: <https://trac.macports.org/ticket/72625#comment:14>
MacPorts <https://www.macports.org/>
Ports system for macOS