mras0

Sounds like a "Dutch auction" (or variant) https://en.wikipedia.org/wiki/Dutch_auction

"Roll you own" seems to be interpreted differently in the comments. Absolutely implement existing ciphers/algorithms like AES/RSA/ECC (and various modes of operation/padding) etc. to get a feeling of how they work, and just don't deploy them in production. You'll definitely get a lot from that. Great way to learn while reading the corresponding papers.

What you probably shouldn't do is try to come up with your own encryption scheme/mode of operation/padding scheme and think you've learned something valuable. By all means, try that as well, but know that you've now entered the really dangerous territory.

Honored to see that it made the cut in your updated list, but it seems like there's a stray ']' at the end of the link :)

I made a toy ECMAScript interpreter a couple of years ago: https://github.com/mras0/mjs

Not really notable, expect perhaps being the only one on the list with an ES1 mode? :) (Can't promise it's accurate though, as it was hard to find examples).

Otherwise pretty boring (C++, hand-written parser, AST interpreter, ES1/ES3/ES5.1 support minus some regexp/timezone/locale stuff).

Depends on the target, but sometimes you can use your regular debugger. Otherwise good old printf debugging/blinking with LEDs/toggling output pins/staring at the code while crying depending on the circumstances.

Thanks. Ideally I'd have liked if bootstrapping only required an assembler (and then successively more advanced versions could compiler the next in line), but this was enough of a challenge for a side project. Maybe later :)

Author here. Sorry for the confusing naming, the "S"-prefix came before I'd figured out a good name (to match my assembler/DOS project https://github.com/mras0/sasm). Tiny CC would have been a better name, but (as mentioned in another comment) was already taken by a superior project. I hadn't heard about the other SCC before.

This is a good idea, but I'd be selective about it. There's a lot of tedious and uninteresting (IMO) stuff in there, like https://tc39.es/ecma262/#sec-array.prototype.splice or how unicode is handled in the source text.

But looking into the details of how object prototypes and properties really work is essential for getting a good grasp of the language.

Hadn't seen Mini-C before, that's quite the feat. Apart from the awesome C4, I also like 8cc (https://github.com/rui314/8cc) in this category.

Recently did this myself (https://github.com/mras0/scc/blob/master/scc.c) but it took waaaaay more than 10 hours and I had many previous failed attempts before that.

I don't think it matters what bash actually does, the issue (as I see it) is that when a program calls write(N, ...) it sometimes wants to refer to the "stale" file descriptor N. Consider this contrived example:

    write(STDERR_FILENO,"test",4); // OK, write to normal stderr
    close(STDERR_FILENO);
    open(....); // Open some log file
    // later
    write(STDERR_FILENO,"x",1); // OK, write to log file

Even though fd 2 refers to different files I think the above is required to work for POSIX compliance.

Didn't see your reply before commenting, but it gave me a thought: We really only need a "local" solution. If there were a way of requesting fd's that weren't required to be the lowest available ones (perhaps even 64-bit ones with a process unique uppper part), that'd probably be good enough here. Of course we're still sharing address space with buggy code, so maybe it's not worth it.

I think quite a bit of software actually relies on closing and re-opening file descriptors, especially stdin/stdout/stderr just before/after forking. This was the first example I found via a quick web search: https://unix.stackexchange.com/a/148410 but it suggest that e.g. bash would break :)

It might be possible with some hacks/heuristics to catch many errors (perhaps one could create a valgrind tool/santizier), but I suspect it's not possible in general since there's no way of knowing if the call to write(2,....) meant the old stderr or the new one.

I don't have a good resource, but having just finished a small C-compiler myself[0] after previously getting stuck on the codegen part, I have a few suggestions:

Keep it simple and focus on making it composable. By that I mean if you're targeting x86 keep the current value in [r|e]ax (forget about non-integer stuff for now :), if it's a stack based VM: focus on the stack top. A numeric literal loads [r|e]ax (or pushes it on the stack). Binary operators first pushes computes the lhs; pushes the result; computes rhs, combines and leaves the result in [r|e]ax (or the stack top).

Output to some kind of text format and lean on existing tools. It's probably not a bad idea to output C, LLVM bitcode, JVM/.NET bytecode or x86 assembly at first rather than going all the way to machine code starting out.

Postpone thinking about optimizations and reduce your level of ambition. All of my previous attempts at finishing compiler projects failed because the complexity got out of hand. For instance in a C compiler don't try to optimize expressions of smaller-than-int types. Maybe all expressions in your language can be calculated using doubles?

Finally as GP says: You need to be comfortable with the output language (assembly or otherwise). Study the output of similar compilers and translate code by hand into assembly to get a feel of what your compiler should be doing.

[0]: https://github.com/mras0/scc

I'm curious about what kind of situations you're using this pattern in C++. Not objecting to the practice in any way, it's just that I haven't encountered many situations where I wouldn't just have created another function for the allocating case that called the non-allocating one.

Ideally memory handling and I/O should be overridable (and often is by creating some kind of "context"), but when it isn't then, yeah it should be obvious from the naming.

If it isn't - and especially if you're dealing with a closed source library - you have to assume the worst and even then you're often unpleasantly suprised :/

When you start Vim (without arguments) it says "VIM - Vi IMproved" .... "Help poor children in Uganda! type :help iccf<Enter> for information". I just noticed that it actually cycles a few through messages now (version 8.something), so you may have to restart a couple of times to see the message. But IIRC it used to always just display the "help children in Uganda" message.

Because it's a standard pitfall: https://gcc.gnu.org/onlinedocs/cpp/Duplication-of-Side-Effec...

For the record I'm pretty sure my implementation uses a very large amount of memory in both cases as I'm not doing anything to avoid it (like escape analysis).

Good luck with your project, for now you should trust the other implementations more :)

But I've tried to keep the code reasonably small and (hopefully) readable - which is why it's currently targeting ES1997 - rather than having lots of features, so it's probably more understandable than V8.

Sorry for the confusion. I just chose something short when starting the project and since it's just a hobby project I didn't bother checking for name clashes.

Yeah, I've had my share of interesting bugs (see the article I linked in another post).

All pointers are tracked automatically (except for specially optimized classes), so that part isn't so bad, but it's still (too) easy to accidentally use a stale pointer value.

At the moment I can safely collect after every statement, but there is still work to be done before I can claim to support collecting after every expression (like I'd ideally be able to - so I can collect when I run out of heap).

Actually that part wasn't too bad once the GC was working as I handle activation records more or less like normal ECMAScript objects.

Yesterday I finished an article (https://mras0.github.io/mjs/doc/gc/initial.html) on how I implemented the GC and some of the challenges, if you're curious.