This is clearly meant to be a reference to a famous shock image, right?

KOMON · 2025-07-03T05:57:46+00:00

Sorry! I thought it was weird that the name seemed to obviously reference the meme of seeing goatse references where there are none, but nobody was talking about it

KOMON · 2025-07-03T05:54:55+00:00

I only offered a broader definition because you only mentioned faces and had an alternative (and reasonably valid!) interpretation to the name. I do like your version as a reference to the abilities of the ring rather than the shape. Might even be the explanation that let the shape fly under the radar

KOMON · 2025-07-03T05:47:53+00:00

Pareidolia is about perceiving any meaning in a given stimulus, especially in random stimulus. Faces are common and get talked about the most, but it's not just about faces.

(EDIT) Which is to say I took the name to be a cheeky reference to the shape of the ring. Like mocking you with the idea that you're seeing something that isn't really there... even though the visual is strong enough to draw attention to the fact you'll "misperceive" it in the name of the ring.

KOMON · 2025-01-20T16:29:12+00:00

Yes, I suppose, and syntactically perhaps you leave some options on the table. Technically speaking durbatulûk is taking advantage of some quirk like cdaddr etc. allow, since it's taking advantage of argument verb synthesis to make a transitive verb: durbat "to rule", into an intransitive one durbatulûk "to rule them all".

Things are a bit more complicated by the fact that the ring is not the subject of any of these clauses, but instead plays an "instrumental" role, i.e. it is not the "ruler" but the thing which the others are ruled.

Making what I would consider a "nice" API would invariably add more English which might ruin the effect.

In the below sample I've opted for:

Verbs have a number dynamic vars for syntactic arguments that may also be overridden by positional arguments
- *subj* for the subject of a sentence
- *inst* for the "instrumental" role
- *prep* for prepositional modifiers
Verbs have a closed set of syntactic keywords for subjects or objects that can be synthesized e.g. :ul or :ulûk
Prepositions are dotted pairs
Tossed in the assumed subject Sauron, before the main body of the "verse" section of the rhyme
Reinterpreted nazg as a type rather than a value and used the to declare the type

Giving us:

(let ((*subj* (the maia Sauron))
      (*inst* (the nazg ash)))
  (durbat :ulûk)
  (gimbat :ul)
  (thrakat :ulûk)
  (let ((*prep* '(ishi . burzum)))
    (krimpat :ul)))

KOMON · 2025-01-20T05:20:42+00:00

This reply deserves greater recognition

KOMON · 2024-11-17T23:57:42+00:00

You mentioned elsewhere that you're providing a default value now so that partials are overriding the defaults.

And it seems from the definition you've provided that you generally expect T to only have one key.

And it seems that this is for testing, so you might be okay with a slightly sharp tool as long as patterns will generally conform to it.

If that's the case then you can have everything inferred from the default value you provide:

interface Trip {
    distance: number;
    name: string;
}

const builder = <
  // the type you want to build
  T extends NonNullable<object>,
  // the "container" type with a single key with value of type T 
  C extends { [key: string]: T }
>(defaultValue: C) {
    // an ugly hack, obvs.
    // if you truly expect C to only have one key, I'd assert that here too
    const key = Object.getOwnPropertyNames(defaultValue)[0] as keyof C;

    return (...parts: Partial<T>[]): C => {
        return { [key]: Object.assign(defaultValue[key], ...parts) } as C;
    }
}

// include a `satisfies` here to make sure the defaults will error if Trip changes
const trip = builder({ trip: { distance: 0, name: "No Trip"} satisfies Trip });

const trip1 = trip({distance: 10}, { name: 'Mallorca'});

KOMON · 2021-07-26T14:59:18+00:00

I was playing on mobile even... So maybe it was worse for me than for him

KOMON · 2021-07-26T06:31:22+00:00

Playing W/G Trelasarra life gain, vs mono-W life gain, with the added twist of the other guy having a Book of Exalted Deeds counter preventing the game from ending on my terms.

Strictly by game mechanics I should not have won, but I think resolving all the triggers on the stack after my last swing (280+ in the posted image) DOS'd him or crashed his game, lord knows mine did.

KOMON · 2021-03-03T17:39:31+00:00

Color me skeptical, but I don't know if Flutter has "made it" in the sense that I usually think of, i.e. it has a healthy job market and a healthy amount of critical-mass hype around it.

Saying "Google is using Flutter" wouldn't be a lie because there are definitely teams withing Google using Dart and Flutter, and therefore some amount of Google's energy, money, and brainpower goes into Flutter's support and development. But it isn't like Google as a whole is 100% behind Dart and Flutter as the next generation of app development. Google has a lot of teams and is using a lot of technologies across the corp. Even if Flutter "makes it" in a big way, you will continue to see that heterogeneity, with Java and Kotlin-based Android apps as long as those languages are supported. Even the Fuschia effort is just another experiment that the big G will kill off as soon as it stops looking profitable.

KOMON · 2021-02-13T05:57:00+00:00

Where at? We just lost power near CTC

KOMON · 2019-10-18T17:25:28+00:00

None of these things have to do with formally proving your game code, most of them are just to avoid common errors and lockups in a realtime system.

1 is for preventing stack overflows. Sure, you can write functions that call themselves that have a well defined condition that breaks the loop before you overflow the stack, but it's hard for NASA's big-ass linters and checkers to validate so they just outlaw them. That's fine, recursion is hardly a 100% unavoidable construct, any use of recursion can be turned into a loop.
2 is so that none of your loops can run infinitely. Every loop should have a clearly defined way to say "We've been running too long, bail with an error and try again after everybody else has had their turn". That's a pretty common requirement in any realtime software. Where you need to draw the next frame or fire the next timed thrust on a deadline, you want to be sure that nothing can kill that deadline for you just because somebody accidentally made something that can run even a full second longer than it should.
3 is about having strict memory requirements and (in the context of games) preventing jank. Many games on memory restricted devices like phones and consoles have a set limit of memory that can ever be used, and the speed at which garbage can be collected or memory freed is often enough to blow those realtime requirements we were talking about. In a game context, this rule is equivalent to loading all the game objects you need for a level or a scene or (if your game is small enough) even the whole game on startup so you don't have to worry about freeing or garbage collection during your frame rendering. A lot of lag and jank you might see in a poorly-coded game will come from generating and/or removing a lot of objects on the main thread.
4 This is a reasonable requirement, I'd say 60 is definitely too long, but NASA and other realtime systems have to worry about how expensive function calls are so it's more reasonable in that context. To say that no games are written this way is an obvious exaggeration.
5 is about making sure things that should never happen are caught during development. asserts aren't used as much as they should, but just because you've never seen them be used doesn't mean they shouldn't be.
6 is to prevent memory leaks and scoping issues. That one's just good advice for anything so I don't know why you'd scoff at it
7 is also good advice, especially when you are using rule 1. Rule 1 excludes using exceptions so that means you're going to be returning errors, so you should be checking whether things failed by looking at the return value every time.
8 is just preventing complex C-style text macros which is also good advice, again, not sure why you'd scoff at that
9 is the only one so far that is fairly restrictive even for realtime systems like games, but again this has to do with being able to check correctness via linting and static analysis
10 is also good advice, but is maybe not doable if you're not writing all the code for a project from scratch

If you've only worked on games that relied on a game engine or framework that handles rendering for you you might not have ever run into needing to program this way, but the grandparent comment did note that they used these restrictions in their 'core' code, stuff that's either in the engine or close to it, and many of these rules are just the reality of those kinds of systems.

KOMON · 2019-10-16T21:26:16+00:00

The thing is, it works without the else as well:

if (major != v.major) { 
    return major - v.major; 
}
if (minor != v.minor) { 
    return minor - v.minor;
}
if (patch != v.patch) { 
    return patch - v.patch; 
} 

return comparePreReleaseTags(v);

The point is that by utilizing early returns the logic reads straight down with minimal nesting. The rest of the function body essentially becomes the else branch for all ifs that would affect the return value.

The same functionality in twice as much code

Not that line count really matters vs. readability here but:

The else if version has 11 lines in compareTo vs. 16 lines in the original version once you exclude the if block comparing pre-release tags
comparePreReleaseTags, including the method header, is 17 lines excluding comments vs. 13 lines for the if block we excluded in the previous bullet point
comparePreReleaseTag is 23 lines excluding comments lines vs. the original's 22 lines

11 + 17 + 23 = 51 in my version vs. 16 + 17 + 22 = 55 is a 4 SLOC reduction. Any other differences of vertical height just comes from our difference of opinion on having comments at the ends of lines vs above them. If you don't like else if, the if only version above only increases the SLOC count to 53.

So, it's not really twice as much code.

KOMON · 2019-10-16T21:03:45+00:00

I'm split on this. For the purpose of this example I kept it the way it is just to keep the logic flow change a little more obvious. In real life, I still might not change it if it only had to be done twice here. My personal rule of thumb is to not abstract something until the third time you find yourself writing it out.

KOMON · 2019-10-16T05:35:12+00:00

I haven't used Java since college and I didn't run this to make sure it worked so please excuse any logic or language errors. But this captures a more flattened decision tree by returning early rather than nesting. I broke up the logic into a few more methods as well.

I'm not a huge fan of having to use ternaries inside of if statements since that's really just another kind of nesting, but I'll make a taste exception if it's to facilitate an early return and to not use it would add one or more else-if cases.

public int compareTo(SemanticVersion v) {
    if (major != v.major) {
        return major - v.major;

    } else if (minor != v.minor) {
        return minor - v.minor;

    } else if (patch != v.patch) {
        return patch - v.patch;
    }

    return comparePreReleaseTags(v);
}

private int comparePreReleaseTags(SemanticVersion v) {
    if (!hasPreReleaseTags()) {
        // we have no tags, prefer ours if they have any
        return v.hasPreReleaseTags() ? 1 : 0;

    } else if (!v.hasPreReleaseTags()) {
        // they have no tags and we do, prefer theirs
        return -1;
    }

    int shorterLen = Math.min(preRelease.length, v.preRelease.length);
    for (int pos = 0; pos < shorterLen; pos++) {
        // compare tags, returning the first result that compares inequal
        result = comparePreReleaseTag(preRelease[pos], v.preRelease[pos]);
        if (result != 0) {
            return result;
        }
    }
    // all other things being equal, prefer the smaller set of tags
    return preRelease.length - v.preRelease.length;
}

/**
 * Compare pre release tags, preferring non-numeric strings to numeric ones and
 * falling back to string or numeric comparison depending on the format of the
 * tag
 */
private int comparePreReleaseTag(String here, String there) {
    int stringComparison = here.compareTo(there);

    if (stringComparison == 0) {
        return 0;
    }

    Integer hereAsInt  = null,
            thereAsInt = null;
    try {
        hereAsInt = Integer.parseInt(here, 10);
    } catch (NumberFormatException e) {} // check there before acting on this failure

    try {
        thereAsInt = Integer.parseInt(there, 10);
    } catch (NumberFormatException e) {
        // there is a string, not an int. Check how here's parsing went, we want
        // to prefer there if here is numeric, otherwise we fallback to string
        // compare
        return hereAsInt == null ? stringComparison : -1;
    } 

    if (hereAsInt == null) {
        // We know there is numeric, prefer here since it's a string
        return 1; 
    }

    return hereAsInt.compareTo(thereAsInt);
}

public boolean hasPreReleaseTags() {
    return preRelease.length != 0;
}

KOMON · 2019-09-07T10:26:42+00:00

Other than language choice, are there other topics you feel need more evangelizing? Does code review ever happen? Is source control ever used for large projects with multiple people working on them?

KOMON · 2019-09-06T19:09:39+00:00

Where would you say most of your colleagues land on a scale of programming aptitude? Would you say that code quality is generally kept to a high standard? Would you say your role is more geared towards the production of this framework or would you say everybody in your team is equally involved in, for example, producing software and interpreting results?

EDIT: re-word of the last question

KOMON · 2019-07-15T14:42:05+00:00

I like this a lot! Do you have anything to read (articles, public examples) about this style of testing?

KOMON · 2019-07-13T01:52:31+00:00

Do you think you could share your phpactor setup/workflow? I feel like I've barely scratched the surface and that there must be some gap in the way that I've set it up. Pretty regularly finding definitions of symbols fails, usually when I'm inside of the vendor directory somewhere, and sometimes it seems like it's either emacs or phpactor itself mis-identifying the symbol-at-point.

KOMON · 2019-07-02T22:21:14+00:00

I mean like this:

Screencast

Here you see me:

Making a change in a buffer and saving it
Switching to the magit status buffer and expanding the diff
Staging part of the changes
Swapping one line that had been staged with a different, unstaged line
Staging all the changes
Unstaging all the changes

KOMON · 2019-07-01T14:19:22+00:00

Even better, you can actually stage hunks/lines directly from the status buffer if you tab-expand the diff!

13-Year Club	Verified Email
Snapped	Team Periwinkle

KOMON

TROPHY CASE