_a1_

The fact that my perfectly valid comment was down voted like this shows that HN has a pretty dysfunctional community. I think that is my last comment here ;)

I appreciate the article, but it would be really nice if the author could add a timestamp to his blog posts. Without timestamps, it's impossible to know if any issue described in the article body still exists.

I didn't read it, because it might present outdated knowledge.

> Sure, there's a whole slew of crap being grafted onto it like systemd, Wayland, Chromium, etc...

But... you don't have to use any of this

(in fact, I can't even use Wayland at all, even if I wanted to [because of Nvidia])

Where did you get this from?

People who train themselves to reliably induce lucid dreams call themselves oneironauts (Oneiros = Greek god of dreams).

I was actively interested in this topic when I was younger and had much time to sleep and practice, but after I got my job and life problems kicked in, suddenly I realized that the only thing I require from a dream is to get a good night sleep so I will have strength to face problems during the day. A little bit sad but true.

But, during my lucid dreaming endeavors I realized the technique itself is incredibly powerful. Especially for people who have tendencies for daydreaming. One easy technique used during learning is to create a habit of looking at the watch and asking oneself if this is a dream or not. Doing it for a few times during a day will eventually create a habit, and will eventually increase the chances of unintentionally doing it during the actual dream. Then, the question "is this a dream?" will have a chance of recalling that we have consciousness, while still being inside the dream. It will be a lucid dream.

Maintaining lucid state of a lucid dream is another topic. Sometimes a few seconds after starting to be in a lucid dream, we forget about the state and we go right back to a normal, non-lucid dream. There are techniques for prolonging the state, but require training (like everything I guess).

> If you think this approach is wrong, could you articulate the reasons why you think it is wrong?

Because later if you want to reuse parts of the code in a continuous environment (e.g. a daemon), then you will be surprised that you have memory leaks all over the place (or worse, someone else will discover it by accident).

I don't have a problem with the end-of-process-releases-all-memory optimization. But I had the impression that the author uses let's-worry-about-leaks-later-because-OS-takes-care-of-it-for-free-(in-my-use-case).

Best approach to take would be to create a memory pool with fast allocation (e.g. TLAB allocation in Java, or how computer games do it), in order to have control over how the memory is freed or when.

> As an implementation strategy, we do not care about memory leak because we really can't save that much memory by doing precise memory management. It is because most objects that are allocated during an execution of mold are needed until the very end of the program. I'm sure this is an odd memory management scheme (or the lack thereof), but this is what LLVM lld does too.

The fact that someone does it wrong doesn't mean that we should do it wrong as well ;(

I don't think I like this approach. It may work now, but will probably seriously limit the possibilities in the future.

I wait for the day that chess will be banned in USA, or some fork of chess will emerge, because obviously chess is racist: white is always first.

> Scala just has implicits which can be used for method extension.

I don't think it's fair to say it like this. Scala's implicits can mean different things, depending on where they're used. Scala 3 even divides 'implicit' to multiple keywords.

(kind of 'static' in C++ I guess, only more complicated)

Using scalac is not a standard use case.

Standard use case is to use sbt (well, or mill, since we're in lihaoyi's thread :D). Sbt starts up slow, but with bloop, or sbtn (native client of sbt), the compilation is really fast (much faster than C++ for example):

    $ time sbtc compile                                                                          
    [info] entering *experimental* thin client - BEEP WHIRR
    [info] terminate the server with `shutdown`
    > compile
    [info] compiling 1 Scala source to /home/.../target/scala-2.13/classes ...
    [info] compile completed
    [success] Total time: 0 s, completed Feb 11, 2021 4:21:51 PM
    sbtc compile  0,08s user 0,02s system 21% cpu 0,492 total

You're right, I missed that.

> When I hit the start menu, it’s because I want to launch an application. I don’t need to see the rest of the desktop. So why is the Start menu by default only occupying a small portion of the screen, and wasting the remaining space?

Hilarious.

I mean, I fully agree with the author on that. But since the author is not tied to a Windows ecosystem, he doesn't know that a full-screen start menu actually happened on Windows 8, and it was nearly boycotted by Windows userbase because of the fact that it occupies full screen space. Users demanded to have a Windows95-style start menu, and MS had to redesign it.

Why it's so important for Windows users to have a Windows95-style menu, is beyond me.

There you have it :D

hate speech?

So many comments and I have no idea what monkey.org is and why I should care.