I'm not missing your points, even as you change them. I've agreed that JS sucks. I've agreed that errors can be more helpful. I'm not trying to argue with you about that. What I have said, from the beginning, is that in the code you originally presented a behavioural change for setMonth will not help you find the problem any faster. Test failures for the wrong output occur just as often as test failures for errors, on exactly the same few days each year. The API change gives no advantage for the specific function this discussion started with in this regard. However, an approach that avoids inconsistency will, because in this particular instance, that is the real source of the problem. That is all.

In that context—the one you started with—it does not matter that there is often good reason to call Date() without arguments. The getMonthName function presented, effectively an array lookup, should produce the same output for any given input every time. It has no reason to engage in any behaviour that varies from day to day.

There is absolutely nothing wrong with getting the current date.

Bluntly, the code you presented fails precisely because it gets the current date where it should create a more specific one, and then fails to deal with that variation appropriately. You can keep distracting yourself with language design decisions, but that won't help you avoid this particular type of problem in the future because that's not where it is.

Getting the current date is often fine. In this specific instance, it is not. That is why the function doesn't work. If you are missing that point, as much as I appreciate your enthusiasm in continuing the conversation, I will take the L (and the code that actually works) and move on.

I agree with you that errors are useful feedback for coders who don't know the ins and outs of an API. And every programmer is in that group at some point. But the difficulty in identifying this particular bug doesn't stem from the API decisions.

Whether Dates throw an error, or work with what they're given, has no bearing on the subtlety of this bug. Either way, tests that don't replace Date will fail to identify it most of the time, and tests that do, based on its use within the function, would be called wrong-headed by many.

Either way, the bug only shows up at the end of months longer than the target month, and that infrequency has nothing to do with the peculiar design choices of the Date API. It stems exclusively from the evaluation of Date() called with no arguments returning different values at different times—behaviour you have not objected to, and which I'd expect to be considered entirely appropriate, in fact its very point—combined with an attempt to use that value, whatever it may be, without due consideration.

Since the month is the only part of interest, there's no reason to allow the other parts to vary at all. Fixing them, as I suggested at the beginning of all this, is the simplest approach, but setting them first, as has also been suggested, would work too.

You can once again complain about JS design decisions and I'll agree about many of them, but, as much as you might like it to be, and as annoying as so many of us think they often are, here it is beside the point. The perniciousness of this particular bug stems from unnecessarily calling a function with inconsistent output and then improperly processing that, instead of using a function call with always-predictable output.

I've tried to point that out in all the ways I can think of, so if it's still not getting through, I give up. And if your acknowledgement was too subtle for my sleepy brain, and I've ended up overexplaining, then I'm sorry.

Take a look at Engineering Mathematics by KA Stroud. It has a step-by-step approach with worked examples that might be useful to you. Even if you don't like the structure, it'll at least give you a comprehensive list of topics.

Fuck it Im gonna subject my friends to the Its alive trilogy

?

:duck-dance:

That would have been a much better President Clinton.

chiS peD Soch wo'rIvpu' je is a classic of the genre, but the sanitization for a human audience is worse than the Disney treatment of the Brothers Grimm.

The kind of majoritarianism he dislikes is bad, though, so I'd tell him he's right to be concerned for the protection of minority rights, but the empowerment of "the common people" necessarily protects all people, or else it would create a more powerful group, who could not therefore be common, so a true democracy is actually what he wants.

Ridiculous examples are the most fun to find some kernel of agreement and then spin to the conclusion of "you're right, anarcho-communism is the best way forward for America".

SuvwI' qu' SoH vIHar

Following the links will take you to a handy search tool.

Whatever you do, don't send them to a Santa Monica school!

You wrote this ten minutes after being reminded that "consent" by children is nonsense, in what is still the most approved comment.

If you want to be a successful troll, you are going to have to learn to be less obvious. If you want to discuss topics in good faith, you are going to have to learn that this "just asking questions" approach makes you look like a troll.

Admittedly, I have much less experience with i3, so I fired up a virtual machine with Debian 11.6 and installed i3 (along with lightdm) and was able to recreate the problem of .profile not being executed when logging in, so this isn't unique to your particular setup. Great!

Fortunately, this combination does execute commands in ~/.xsessionrc, so I added:—

. $HOME/.profile

to that file, then logged out and back in again. That did the trick for me, with the commands in .profile then successfully modifying the PATH variable (and writing additional lines to the execution log files), so I suggest you try creating/modifying .xsessionrc in the same way.

Are other lines in .profile being executed, or is the whole file ignored? Have you logged out and in again since adding these lines?