jrapdx3

Appreciate your reply! I am interested in trying it out, I'm familiar with MS tools so I don't think I'd have too much trouble following the procedures you've described. Glad to hear Hyper-V is an option since I've used it quite often, usually straightforward enough installing an OS.

Anyway your project sounds sufficiently different from established OSs to make me curious to see it running. However I think you're right, long-term success depends on gaining developer support to grow a large useful software catalog. Having that happen relies on having good tools available and to the extent possible clear interfaces to program against.

BTW one of the problems programming for Windows is the ungodly number of ABIs propagated by MS. AIUI MSVC is considered a legacy technology. MS encourages using UCRT, sort of modernized MSVC, and not fully compatible. Many more examples are out there.

Anyway my point is the virtue of keeping it simple, at least making it no more complicated than necessary.

Finally I'm curious about your reasons for developing on Windows. Doesn't seem the obvious or intuitive choice, but you've done well to make it work. Should be fun to try it out.

Well, there's a (modest) learning curve involved in customizing color schemes and of course more complex tasks that are still in the domain of user's options.

Users can be fearful of "messing it up" if they change defaults. Making changes necessarily confers responsibility to follow instructions, learn how to alter settings and know the set of options that are appropriate to change and which are not.

I concur that TclTk is enormously versatile and productive. I've always regarded Tcl as a Lisp-like language. Tcl and Lisp share characteristics like homoiconicity that enable benefits you describe.

Tcl isn't as widely known and used as it deserves to be. I think that's in part due to its syntax being sufficiently different from "mainstream" languages. The learning curve isn't particularly steep, but enough so that developers question whether it's worth the effort to go there.

FWIW Tcl 9.0 has recently been released. The language has been enriched with sophisticated object-oriented capabilities, coroutines, full math tower, etc. It's also rather easy to write extensions in C.

Anyway, the GUI toolkit (Tk) has been "borrowed" by many other languages (e.g., Python's tkinter), so quite a few programmers use TclTk, know it not.

While novel OSs are frequently introduced on HN, this project is rather different.

That it's built under Windows strikes me as quite an unusual feature. To their credit the developers provide sufficiently detailed build instructions that aren't too hard to follow. However the build environment is very specific. VC has a lot of configuration options, so no doubt very close attention is required to make sure everything is set up correctly.

Running the compiled system in a VM is sensible, kind of a shame though that Windows native Hyper-V isn't supported. Perhaps that will be possible in a later iteration of the OS.

Would be nice if the authors gave a rundown of how this OS compares with others out there. Without having a clear idea of this OS's features and advantages, potential contributors might feel hesitant about investing time and energy in its development.

> "People also said that GPS navigation would hurt people's ability to use a map, or create one in their heads. And I'm old enough to say: it absolutely did."

Thing is some people never were good at reading/using maps, much less creating them. Even with GPS at hand I still prefer seeing a map to know where I'm going. Anyway, retaining at least a modicum of "classic" skills is beneficial. After all, GPS isn't infallible. As with all complex technologies, possibility of failure warrants having alternatives.

I was recently on a cruise, someone asked the ship's navigator whether officers were trained on using old instruments like the sextant. He replied that they were, and continue to drill on their use. Sure, the ship has up-to-date equipment, but knowing the "old ways" is potentially still relevant.

> "The question is: what are the second- and third-order effects of losing those skills, or not learning them in the first place?"

Naturally, old skills fade with advent of newer methods. There's a shortage of ferriers, people who shoe horses. Very few people are being apprenticed in the trade. (Though I'm told the work pays very well.) Owning horses is a niche but robust interest, so ferriers have full workloads, the occupation is not disappearing.

Point is that in real-world terms losing skills diminishes the richness of human lives because there's value in all constructive human endeavor. Similarly an individual's life is enriched by acquiring fundamental skills even if seldom used. Of course we have to parcel our time wisely, but sparing a bit of time to exercise basic capabilities is probably a good idea.

Indeed so. Printing on paper and other substrates is inherently subtractive in nature which limits the gamut of colors and values that can be reproduced. Digital methods make the job of translating additive to subtractive media easier vs. the analog techniques available to film photographers. In any case, the image quality classic photography was able to achieve is truly remarkable.

Notably, the dodging and burning used by photographers aren't obsolete. There's a reason these tools are included in virtually every image-editing program out there. Manipulating dynamic range, particularly in printed images, remains part of the craft of image-making.

As a matter of fact, Tcl/Tk has been doing exactly that since the 1990s. Of course, Tk has been "borrowed" by other languages, Python's tkinter is well-known. Any language using Tk widgets still has to input options in text form. Obviously that's not particularly difficult to accomplish.

Yes, indeed it is. While these PRNGs are all pretty decent, improvements are always welcome. Most impressive is the utter simplicity of the algorithms, including LoopMix128. Definitely makes it easy to incorporate high-quality PRNG functionality in applications.

From the Github repo: "Created by Daniel Cota after he fell down the PRNG rabbit-hole by circumstance." I understand how that can happen.

Wondering how this PRNG compares to PCG PRNGs that also claim to be "simple fast space-efficient statistically good algorithms" and "hard to predict" [0].

In any case, it's good to see the excellent work being accomplished in this space.

[0] https://www.pcg-random.org/

Back in the ancient 80s Prolog made a splash for a time. There was Turbo Prolog (Borland) that I used for a couple of years, wrote some useful programs with it. I also have "The Art of Prolog" and pull it out once in a while. My Prolog skills seem subject to rapid decay with disuse. While the appeal of declarative programming is still there, the most that can be said is Prolog's influence is evident in subsequent languages. The incorporation of pattern matching is one example that comes to mind.

Actually, concern about doing harm is central to current concepts of medical ethics. The idea may be ancient but still highly relevant. Ethics declare a primary obligation of healers is "above all do no harm".

That of course doesn't exclude doing good, being helpful, using skills and technologies to produce favorable outcomes. It does mean that healers must exercise due vigilance for unintended adverse consequences of therapies, let alone knowingly providing services that cause harm.

The problem with "safe/not safe" designation is simply that these states are more often than not indistinct. Or put another way, it depends on subtle contextual attributes that are hard to discern. Furthermore individual differences can make it difficult to predict safety of applying a procedure.

As a result healers should be cautious in approaching problems. Definitely prevention is better than cure, it's simply that relatively little is known about preventing burdensome conditions. Exercising what is known is a high priority.

AFAIK cationic calcium, et. al., combine with dissolved CO2 forming carbonates which having low water solubility eventually precipitate out of solution. Area with "hard water" often have issues with buildup of scale in water pipes. The scale is mainly calcium carbonate and sulfate.

This is normally a gradual process requiring ample moisture. Releasing finely ground rock into the air wouldn't likely be effective. For one thing, such dispersal would be rather dilute. IOW the dispersion wouldn't reliably react with CO3 ions before settling out of the air. Another consideration is the salicaceous content of the rock being a potential health hazard.

The original idea of adding crushed rock to water-containing soil is logically the best way for the project to accomplish its goals.

Like many others writing here, I enjoy coding (well, mostly anyway), especially the when it requires deep thought and patient experimentation to get anywhere. It's also great to preside over finally wiring together the routines (modules, libraries) that bind a project into a coherent whole.

Haven't much used AI to assist. After all, hard enough finding authentic humans capable and willing to voluntarily review/critique one's code. So far AI doesn't consistently provide that kind of help. OTOH seems almost certain over time AI systems will improve in terms of specific and comprehensive "insights" into the particular types of code one is writing.

I think an issue is that human creativity is hard to measure. Likely enough AI is even tougher to assess. Probably AI will increasingly be assigned tasks like constructing project skeletons, assuring parts can be joined together without undue strain, handling "boilerplate" and other routine chores. To be sure the landscape will look different in 50 years, I'm certain we'd be amazed were we able to see what future systems will be doing.

In any case, we shouldn't hesitate to use tools that genuinely boost our creativity. One badly needed role would be enabling development of higher reliability software. Still that's a far cry from the contributions emanating from the best of human originality, talent and motivation.

IME producing artwork that relies on subtle color relationships requires high quality, "full spectrum" illumination. Natural daylight is the obvious canonical option, but of course not always practical.

My studio gets very little natural light, so selecting optimum light sources is crucial. At one time the most practical option was D50 compliant fluorescent tubes, but these were only fairly acceptable.

Situation with LED lamps is also difficult. Even CRI 90 is inadequate, mainly poor red emission and excessive blue radiation. However D50 compliant LED fixtures are available if somewhat more expensive vs. typical LED lamps.

One vendor worth checking out is Waveform Lighting [0]. They offer several types of products with CRI 95 and CRI 99. I've been using their D50 'shop light' for several months and find it very satisfactory.

[0] https://www.waveformlighting.com

As a search of the Tcl wiki shows, attempts to add named-argument capability to the Tcl proc command have been around for several years.

My own nxproc extension is more comprehensive. (See wiki [0].)

The extension enables named arguments, regular positional arguments, and 'rest' arguments, nxargs and nxunknown. Nxproc also provides (optional) type-checking of procedure arguments. (Types: string, number, bool and enumerated. Enums are lists of values restricting what the arg can contain.)

Nxproc supports TclOO with nxcontructor and nxmethod commands -- same feature set as "plain" nxproc. Also provides case-insensitive '-ci' variants, and runtime display of named-argument default/actual values and types.

Nxproc is a Tcl C extension. Bundle has Windows, Linux binaries. Compiles easily on other platforms.

[0] https://wiki.tcl-lang.org/page/nxproc

I remember when Fry's opened in the Portland, OR area (actually ~15 miles south). It occupied the former Incredible Universe site. We considered it a notable upgrade.

Fry's was like a museum of common and obscure electronic parts, devices and strangely miscellaneous stuff (mundane office supplies, home appliance accessories, etc.). It was definitely the go to place for computer building blocks and related supplies.

It was amazing what could be found there. One really great thing was relay racks and all kinds of shelves and attachments for them. Too good to pass up I bought one. It was used in my office (for webserver and LAN) and still houses my home server.

Like everywhere else Fry's closed unceremoniously. I guess the chain couldn't withstand the growing online competition and waning interest in desktop machines. Too bad they had to go, now and then it would be so convenient if neighborhood purveyors of "exotic" electronics were still around.

Certainly seems it ought not to be, but evidently the will to provide "the same protections" is lacking. The unavoidable conclusion is that antisemitism is policy even if it's not official and documented. That truly defies logic considering some of the university's brightest lights have been Jews who've made major contributions to their fields, the school and the country as a whole.

> "US politics can be quite mad at times."

No question about the truth of that statement.

However, though the FTC approved the acquisition 10 years ago, the current FTC commissioners have evidently concluded that in the interim things have changed. Whether the court agrees with the FTC's logic remains to be seen.

Of course you're right. I've written non-trivial programs in Scheme, Emacs is a good tool for it, but certainly don't know of an environment that matches the Lisp machines.

IDEs provide such environments for the most common languages but major IDEs offer meager functionality for Lisp/Scheme (and other "obscure" languages). With a concerted effort it's possible an IDE could be configured to do more for Lisp. Thing is the amount of effort required is quite large. Since AFAIK no one has taken up the challenge, we can only conclude it's not worth the time and energy to go there.

The workflow I've used for Scheme programming is pretty simple. I can keep as many Emacs windows ("frames") open as necessary with different views of one or several modules/libraries, a browser for documentation, terminals with REPL/compiler, etc. Sort of a deconstructed IDE. Likely it does take a bit more cognitive effort to work this way, but it gets the job done.

For the record, Tcl doesn't use garbage collection, rather objects are reference-counted and freed when ref count is <= 0.

But interestingly, Tcl is a good example of languages that took a piece of Lisp's domain. In fact, Tcl is quite Lisp-like with a syntax distinct from Lisp. Tcl has been successful and with the recent release of v. 9.0, it stands to gain traction among programmers.

OTOH CL and Scheme remain underused though current implementations are generally well-equipped to handle contemporary requirements. I've used Scheme to build website generators and other tools but there's a dearth of large-scale, visible Lisp/Scheme projects out there to attract developers.

Starting such a project is a big commitment, probably programmers are hoping somebody else will pick up the ball and run with it.

"Prickly ash" is an ingredient in Chinese cuisine, particularly Szechuan cooking. We buy it in quantity at Asian groceries where it's pretty inexpensive.

In the US it's known as "Szechuan peppercorn". Preparing it for use requires carefully inspecting a handful for stems and thorns (which can be quite big), pan toasting and crushing/grinding to a coarse powder.

As pointed out in the sister comment, the spice has a mild numbing effect which counters the heat of chilis. Adding a little to hot dishes makes the flavor more complex and enjoyable.

For people who like to cook it's an ingredient worth experimenting with across culinary boundaries.

Appreciate the thoughtful comment. Yes, under the hood indeed "every physical system is quantum", yet at the macro level physical systems are more or less predictable, including the brain. The brain's immensely complex structure and extensive interactivity make understanding how it works largely a mystery. The relatively simplistic models we're able to create have so far illuminate only a small part of its functionality.

The idea of free will has been a subject of eternal debate. I suspect this reflects lack of consistent definition. I would posit that free will isn't absolute but necessarily constrained by the nature of individual exercising its will. The stochastic attributes of a system or entity mean its actions are to an extent unpredictable, providing an "opening" for willful behavior.

Humans imagine they have free will because they're aware of their decisions or actions while unaware of the range of factors contributing to a decision or action. Intuitive (vs. analytical) cognition is the operational default. By definition intuition is a computation occurring outside of the person's awareness.[0] Consequently, it augments the impression of exercising unfettered free will.

Perhaps it's most accurate to say we have will or volition but not free of constraints imposed by our biology and physical/social environments. While the randomness inherent in biological systems allows volition to evolve, it also limits what an organism can will itself to do.

[0] Journal of Cognitive Engineering and Decision Making 2017, Volume 11, Number 1, March 2017, pp. 5–22

After decades of providing treatment for ADHD adults I've come to the conclusion that ADHD is one of the most disabling mental health disorders. In some ways ADHD can be as devastating to a person's life as bipolar disorder or schizophrenia. While ADHD is highly prevalent among adults its manifestations are typically subtle. As a result, symptoms are attributed to incidental factors and the nature of the person's condition remains hidden.

The article does a good job of addressing factors that contribute to ADHD-linked disability, and ways to deal with them. Clearly underdiagnosis sums up the primary issue. Solving a problem starts with recognizing the problem exists. However the article didn't discuss an important reason ADHD is overlooked, that is, widespread tremendous bias against recognizing the realities of adult ADHD.

Reducing the burden of ADHD via social approaches faces a major challenge: how to inform or educate the public about realities of ADHD throughout the life cycle. While there has been marginal improvement over the last 25 years, prejudice or misunderstanding remain predominant.

IMO the place to start is with the provider community. Healthcare practitioners need training to recognize ADHD among comorbidities and participate in its management. Once providers are actively advocating appropriate treatment for ADHD patients, family members, et. al., will likely follow clinicians' lead, become more amenable to helping ADHD individuals.

Economic costs of ADHD are substantial. Reports give estimates that of $143 to $246 billion/year in the US alone.[0] If nothing else these figures illustrate the potential benefits of providing proper care to adults with ADHD.

[0] https://www.jaacap.org/article/S0890-8567(12)00538-2/abstrac...

I'm not familiar with an app showing spectra of pigments as used in painting, etc. Some high-end printers (plotters) incorporate spectrophotometers to measure properties of colors, but that's a highly controlled use of colorants.

In contrast, a painter can use a color in thick or thin layers, mixed with white, or clear medium, among other variations. And pigments can work differently in oil vs. acrylic vs. watercolor media. The spectrophotometric properties of a pigment change depending on usage so the information gleaned from measurement would probably not be that useful.

OTOH some manufacturers offer visual color mixing guides that can be helpful to artists. Here's one I've used from time to time: https://goldenartistcolors.com/mixer/acrylic?tab=color-syste...

This offers matching artists colors to RGB or CMYK specifications.

As an artist I have a perspective on color from a pragmatic (as opposed to theoretical) point of view. Visual artists use materials like paints or inks applied to substrates. These all are exploiting subtractive color, primaries are complements of additive color, CMY vs. RGB.

The standard color wheel interleaves CMY with RGB, which sets up useful symmetries and complementary relationships. But of course, the color wheel is really a color cylinder, or set of cylinders when color properties other than hue are considered. Color saturation and value are crucial to artistic work, but when these additional dimensions are accounted for it's no longer the simple model the basic color wheel portrays.

Color classification systems emerged in the 20th century and over time evolved into the highly rigorous regimes codified by the International Color Consortium. Everybody is familiar with ICC profiles and their uses. I can't say I have a thorough understanding of them, I'd guess relatively few people do.

Artists don't have handy ICC profiles to guide creating a painting or print. They learn how to mix colors mainly by trial and error. However the paints and inks are precisely formulated by manufacturers who very much understand the science of color. This precision results in product constancy which makes life far easier for artists. With experience they gain an intuitive "fix" on particular colors and their locations on the extended color wheel.

To make it even more convoluted there are metallics, gold, silver, copper, etc. and the range of man-made iridescent and interference pigments. These "colors" aren't easy to merge with even multidimensional color "wheels" (or matrices). Nonetheless, people typically interpret these pigments as colors.

A subtle factor is opaque vs. transparent color effects. These aren't mutually exclusive, but in "pure" form are distinct. Opaque colors may be mixed to form an intermediate color, but at lower saturation and value. More than not this is how people are taught to manipulate colors often in accordance with the basic color wheel.

Transparent colors may be mixed like opaques, with somewhat similar results. However, layering transparent colors potentially produces extended effects. While both opaque mixing and layered color are subtractive, layering can combine in several ways producing multiple "virtual" colors modified by filtering effects of layers.

Any color wheel, or multidimensional matrix, is unlikely to accommodate the numerous ways colors combine or mix, or non-color colors. Artists use color wheels or more complex structures to gain pragmatic info about the colors they're using and predict results of manipulations. In any case, most real-world paints, inks, etc., don't behave like pure colors. A color wheel is only valuable as a pragmatically useful tool.

I'm a medical professional and I read medical journals regularly. Abbreviations and acronyms are a scourge, a single article can have dozens of cryptic abbreviated names. There's a good chance some are used that I don't immediately recognize and decipher. Some journals print a list of the articles abbreviated forms along with the "long" form which is quite helpful.

Of course, authors are supposed to given the long form and abbreviated form in parentheses. The trouble is in printed journals it can be difficult to find the first use of the abbreviation. Fortunately viewing articles in an electronic medium it's usually possible to do a search which is a real time-saver.

Furthermore, an abbreviation can have multiple meanings, especially across disciplines. For example, PSA can stand for prostate specific antigen, pressure-sensitive adhesive, public service announcement and probably some others too. Anyway I try to be mindful of the ambiguity abbreviations can produce. By all means, spelling out the term(s) abbreviations refer to should be considered mandatory.

Yes, you're right, Tcl suffers from lack of Scheme-like macros. While a lot can be done using procedures, methods and introspection "tricks", often enough it's far from elegant. However I haven't been stymied all that often. Missing functionality can sometimes be provided by C-API extensions which I've gotten pretty good at writing.

Completely agree about the utility of Tk. I remember reading somewhere that HTML/CSS widgets were influenced by Tk. Don't know how true that is but I can see how it could be.

Interestingly I've had a similar experience. I used Chicken Scheme for a number of years after programming in Tcl for a long time. Tcl always seemed to be a kind of Lisp, an impression that only increased over time. Eventually I resumed using Tcl when I realized the language had been steadily improved over several years. With Tcl 9.0 on the horizon I see no reason to look elsewhere for accomplishing most programming tasks.

That's exactly what happened at the last eclipse back in 2017. To get to the path of totality, I had to drive on an unpaved forest service road for several miles. Where the road ended there was a big clearing with a bunch of people already there. Fortunately they were very friendly, it was kind of a party atmosphere.

Anyway, it was worth all the trouble. One thing was that I got some great photos of the eclipsed sun. I'm looking forward to the upcoming event in April. I'll be in Mexico where viewing should be good, bad weather being less likely in that region. Hopefully I'll be able to get even better photos this time around.

I imagine the answer to "why are flowers beautiful" is probably linked to a different question: why do humans have superior color vision vs. almost all other mammalian creatures?

A dominant theory is that natural selection favored individuals with extended long wave (red) perception. Better color perception enhanced locating high-quality food resources and avoiding toxic plants. Human vision also resolves finer detail than many mammals.

Flowers are worth noticing, after all, they're precursors to fruit which may be edible when ripe. Appreciating the form and color of flowers isn't a random phenomenon. In its present-day form, like most things human, the "beauty of flowers" is a complex phenomenon arising out of interacting biological, social and environmental factors.