HackerLangs
TopNewTrendsCommentsPastAskShowJobs

chrishill89

no profile record

Submissions

Tell HN: Happy May Day

13 points·by chrishill89·há 2 meses·5 comments

Note that ambiguous commit IDs are not even remotely as scary (2024)

lore.kernel.org
1 points·by chrishill89·há 10 meses·0 comments

comments

chrishill89
·há 22 dias·discuss
> After reading about the default mode network here a few times recently, I think missing out on all that critical "daydreaming" time is a bigger problem.

Part of the reason why I listen to music and scroll my phone is to get some peace from the default mode network.

I don't feel like I would do it as often if my mind didn't insist on being busy all the time.

> The DMN seems to fall into a similar area as meditation (remember when that was all the rage among tech leaders?); the lowered input noise gives the brain time to clear things out.

I am not skilled enough in that department to say anything with certainty. But formal meditation is about intentionally focusing the mind, and the talkative mind or whatever it is called in the buddhist traditions is probably this default mode network. Which is the first obstacle; being able to focus on the meditation object without having your attention hijacked because oh what's for dinner, did I send that email, but what about that other email, oh but I couldn't log in on my phone, oh by the way that phone is also annoying in terms of that related thing, but I should stop using my phone as much anyway what about getting one of those dual SIM cards that I read about on HN.

In my experience, it's probably healthier for the mind to have the DMN active more than someone who can distract themselves all the time do. But to me DMT looks to meditation like sunbathing looks to a day's hike (yeah you're outside for both of these activities but).
chrishill89
·há 26 dias·discuss
I write mostly for myself. That's a trite I guess observation considering that I happen to write a lot of private notes. But I think writing for broadcasting is overrated.

Journaling or diarying is writing for myself, and often in a form that will never leave the disk inside the the computer. But I also want to write more complicated things than just what I thought about today, how I solved some problem, or a reminder for three months from now. Why? Because writing as a solitary pursuit is similarily rewarding like reading for pleasure. We can read without growing an audience. We can read without have any extrinsic motivation. We can just do it and leave it at that. But writing is a bit too much associated with communicating (small) and broadcasting (large).

I could probably write a book on the most idiosyncratic topics, something that not even my mother would like to skim the foreword of. Because imagine if that process would help me know myself? How valuable would that be? The writing artifact might be useless, even. But the process could be enriching.

I would never hope to read a book by someone I don't know and be able to absorb their wisdom, not even 10%. Some things cannot be transmitted like that. The printing press probably has not helped us know ourselves more than just, you know modestly more. Some things have to be worked on by you and you alone.

This also translates to more practical subjects than knowing yourself. But that's what I felt like spending the word count here on.

But in terms of public writing. I am currently working on an article-length piece for a niche "publishing". And I find that process to be rewarding.
chrishill89
·há 26 dias·discuss
If works/doesn't are semantic checkpoints, then I use that every day for myself with Git notes.
chrishill89
·há 29 dias·discuss
Many years ago I helped a friend with some draft that had to do with him finishing his doctorate. It ended up being maybe 50-60 between three of us and as fine grained as possible.

That agents need something "beyond git" is lost on me but it keeps coming up. For one subject the tool doesn't matter -- in fact it can be obtuse like git or bash and it's fine because agents will handle it. Then for another thing the story is opposite.
chrishill89
·mês passado·discuss
Absolutely. You didn't have to make an account to remind me, at least. His relationship with Epstein was shameful and there is no excuse for it.
chrishill89
·mês passado·discuss
IMO that is only a problem for those who demand that the issue key needs to go first in the subject (which again IMO is bad for readability). I don't see why you can't just stick it somewhere after all the conventional commits junk? Issue keys ought to be something that can be janked out based on a regex like an alphanumeric prefix followed by a number, so things like this "standard" have little need to set aside a space for it.

Personally (without conventional commits) I tend to put them at the end in parentheses if the commit has something to do with that issue. But if there is a stronger relationship like that it fixes the issue, I put a `Fixes` trailer in the message as well.
chrishill89
·mês passado·discuss
Want machine-readable? Use the footers/trailers.

I can not say anything nice about conventional commits. The format takes up space in the most-read part of the message. The categories or types have little information. They can be replaced with an honest English verb embedded in the subject like a sentence. It also reads way better with just a sentence instead of three kinds of punctuation (:, (), !). Okay, I can tolerate an "area" in the subject. And that predates this conventio.

At my dayjob we make a webapp for non technical people. I can write a changelog for that just fine (in norwegian). The commit messages are irrelevant to the users. And demanding that all commits should be good enough for an end-user changelog? That's not happening for us anytime soon.

Use footers/trailers instead.
chrishill89
·mês passado·discuss
Does that show Jensen in a better light?
chrishill89
·mês passado·discuss
It took me many years to even think of problems that I wanted to solve. Or were missing. But eventually it happened. And it seems that the more time passes the more that list of ideas just expands since no one can follow up on all of those ideas.

Someone skilled enough should have many original enough problems to work on. But such persons would have to speak on that topic.
chrishill89
·mês passado·discuss
Setting up a Mac user account.

   What accessibility settings do you need?

   - [four options/catgories]
   - Remind me Later (or something)
And I guess the Later option is technically accurate.
chrishill89
·mês passado·discuss
I wrote an essay and sent it to Chomsky once. He wrote back that he probably won't have time to read it.

Some years ago I realized that I can just start sending emails to an OSS mailing list. Without introduction just starting to post as if I belonged there. I had already made some grammar fixes more than five years before that but I started to comment and critique submissions. And submitting my own patches. Now checking the mailing list is daily habit. Unfortunately I didn't have time to post the second version of a submission on the bus today (another documentation fix).

People, and especially in my culture, are very good at staying out of places where they do not belong through self-policing alone. Unfortunately to the point where at least I do get stuck in narrow patterns and never even consider certain opportunities.
chrishill89
·mês passado·discuss
I really like the Oracle tutorial on Java asserts.

https://docs.oracle.com/javase/8/docs/technotes/guides/langu...

And I'm pretty happy with its design considering its age.

Notably this is not a function call and indeed things are not called unless you enable it. Contrast with Zig. So I guess you will only suffer from code bloat if you never enable them.

The tutorial mentions the dangers of side effects. But it also mentions how to use them for more complicated assertions. That's natural since you'll want something like that when you need to check a post-condition.

Programming assertions get joked on because of, ahem.

- Step one: Turn on extra checks in test environments where the stakes are low

- Step two: Turn them off in production (with realistic data because prod eq. reality) to save cycles

And that seems to be partially accurate. However the truly interesting assertions can test complex conditions that might break complexity (Big O) contracts. Like a private mininum function that is advertised as O(1) on account of taking a sorted list. But there is no type guarantee that the list is sorted. So you assert that it is sorted. But that breaks the complexity contract.

Overall I have not used assertions in Java for trivial conditions in like five years. They're better deployd for something more complex than that.

Then there is the whole thing about -- and more topics to be sure -- crashing the whole application or not. That's not necessarily great for us regular Java programmers. However we can (though discoraged) catch AssertionError if we want to.
chrishill89
·mês passado·discuss
Pretty recent Git versions have git-last-modified(1) which can list all files along with the last modified commit.
chrishill89
·há 2 meses·discuss
> Maybe the worst part about this is that it can entirely come from a patch being exported by git and then imported straight back in to git.

No one wants to apply diffs in commit messages. But some people use this technique via email:

    Finally fix it

    ---

    Changes in v2:

    - Proper formatting
    - Remove irrelevant typo fix
They’ve used the `---` commit message delimiter in the commit message itself so that everything after it won’t be applied by git-am(1). So that’s intentional loss of round tripping.

I would personally use Git notes instead though.

    Finally fix it

    ---

    Notes:
        Changes in v2: ...
chrishill89
·há 2 meses·discuss
git-am(1) (apply patches) delimits the commit message from the patch/diff by looking for (1) a line `---` or (2) a line that starts with `diff -` or (3) a line that starts with `Index:SP` (SP is space). Only the first rule is necessary for patches generated git-format-patch(1). But git-am(1) is for applying patches, and you are free to bring patches from some other system. That’s why, I suppose, there are multiple options.

This means that it will try to apply any unindented diffs in the commit message. But you’re fine if you indent the diff. (Newschool code fencers will have a worse time here.)

I imagine that this worked fine for changes that were authored by one person and submitted by another person via email, or by their friend, or by someone trying to resurrect a previous attempt at getting something upstreamed. Someone is likely to notice that examples diffs are getting applied. But it won’t work well at all if you are some software distributor who is using patch files to apply modifications to packages.

Recall that git-am(1) will not apply indented diffs. Well have a look at my GNU patch 2.7.6:

    If the entire diff is indented by a consistent amount, if lines end in
    CRLF, or if a diff is encapsulated one or more times by prepending "- "
    to lines starting with "-" as specified by Internet RFC 934, this is
    taken into account.
Some may say that patch(1) should work like a more straightforward importer. But I’ve been itching to point out something else.

    Larry Wall wrote the original version of patch.
Is it surprising if patch(1) is a bit DWIM?
chrishill89
·há 3 meses·discuss
> It's very widely remarked that the Git CLI is pretty miserable, and as soon as a better (so I hear) alternative comes along they suddenly realise and start improving it... This happens all the time in software.

This command is implemented by just one single (but prolific) contributor. His own idea.
chrishill89
·há 3 meses·discuss
Yeah it’s a direct inspiration.
chrishill89
·há 3 meses·discuss
I don’t know what the semantics of invoking Git means?

These two commands operate on the same level of abstraction. And they should be equally powerful, which means that whichever you choose to learn will be able to serve all of your restore-content needs. That's what I mean.

Of course there is always the pedagogic cost of having two similar commands.
chrishill89
·há 3 meses·discuss
Neither of these two commands are any more really-operates than the other.
chrishill89
·há 3 meses·discuss
The git-restore(1) implementation looks like about 35 lines of code. Then add a little more complexity for some apparent common functions that needed to be factored out.

For a dedicated "restore" it's worth it to me... (who will not maintain it)