PeCaN

94 ms·

811.
by PeCaN 11y ago
You know, some kind of GNU/NT using the ReactOS kernel would actually be really cool.
812.
by PeCaN 11y ago
Oh, cool. That means they must have had some platform abstraction layer, and that sort of thing almost never goes away—I'd say high chance it's still there, if perhaps not updated. Porting it could be a lot easier than expected. W
813.
by PeCaN 11y ago
Yes. While they have very similar semantics, Lua is just simpler. (ES6 though goes way beyond and is probably quite a bit harder to optimize simply because of having much more surface area.) Of course, most of LuaJIT is applicable to JS as
814.
by PeCaN 11y ago
Toonz dates back quite far, so it's probably C++ relatively deeply tied to Windows APIs.
815.
by PeCaN 11y ago
For the record, I have the same CPU as him but with 16GB of RAM and Atom is obnoxiously slow for me. Never used Sublime, but I am biased towards Vim ;-)
816.
by PeCaN 11y ago
Yeah. I thought building a text editor in a web shell was incredibly stupid until I tried VSC. It's still more memory hungry than I'd like, but it's really fast—as fast as Vim for me (but noticeably slower than NeoVim). Did
817.
by PeCaN 11y ago
I implemented my own, but I'll definitely check out jemalloc. I happen to have a use case for allocating large chunks aligned on large boundaries (high-performance garbage collector). jemalloc is common enough that I suppose it's
818.
by PeCaN 11y ago
Not as far as I'm aware. POWER, x86(_64), even Itanium all just bump a stack pointer[1]. SPARC has a funky stack, but I don't know enough about it to say how hard VLAs would be. (It's a darn cool architecture though. I wish a
819.
by PeCaN 11y ago
Perhaps that's why the article starts off with > It’s been one of the worst-kept secrets for years: the identity of the person the government was investigating in 2013 [...]
820.
by PeCaN 11y ago
This is inherited from early Lisp implementations, where it was common to define a struct car { ... }; which would get cumbersome to type.
821.
by PeCaN 11y ago
As long as we keep __builtin_apply out of the standard, GCC is loaded with good ideas.
822.
by PeCaN 11y ago
Looks like Firefox does this.
823.
by PeCaN 11y ago
They were made optional in C11. Compilers for DSPs or whatever where VLAs aren't practical don't have to implement them. Just because an _optional_ feature is impractical on a few niche architectures doesn't mean it's a
824.
by PeCaN 11y ago
free(NULL) is already perfectly legal (specced to be a no-op) as noted by the parent. The problem is that `char * s;` is probably _not_ NULL, so you'd try to free some random address on the stack. Of course it is easily fixed with `_cl
825.
by PeCaN 11y ago
Yes, that's exactly why they'd use _Auto and a header to redefine the keyword. Existing code that does auto x = 3; (implicit int type) wouldn't break, but #include <stdauto.h> auto x = 4.2f; would be the new meaning.
826.
by PeCaN 11y ago
I've only somewhat recently become a hardcore C programmer, but I actually quite like it. Wrote my own incremental generational garbage collector recently—the things you can do in C are fun. Here are some things I'd really like: N
827.
by PeCaN 11y ago
That is incredibly clever, particularly exploiting DEFLATE to generate text. I would've never thought of that.
828.
by PeCaN 11y ago
Actually, there's often no cost at all to allocating a zeroed buffer. FreeBSD zeroes out free memory in its idle time and uses that for calloc(). Linux hands out a pointer to a shared read-only page of zero memory and then gives you &q
829.
by PeCaN 11y ago
So... does your code currently break if you just happen to get zeroed-out memory from the OS? (FreeBSD for example runs a background process every once in a while to zero out free blocks, mostly for purposes of calloc() but it's defini
830.
by PeCaN 11y ago
Because with 80%+ unused code, your instruction cache is gonna choke. Also JITs can remove many more type checks, because it knows when a check would be redundant. See e.g. Lazy Basic Block Versioning[1], but existing tracing JITs do quite
831.
by PeCaN 11y ago
> You know the part where the JIT decides whether to execute X or Y? That can easily be implemented in a conditional in compiled code with the two code paths, X and Y. And that's the difference with a JIT compiler: if the value is a
832.
by PeCaN 11y ago
> turn my strict subset of JavaScript code into C, and then use emscripten to generate WebAssembly. Well, the problem there is that your subset would be... C. JavaScript without automatic memory management, closures, prototype inheritanc
833.
by PeCaN 11y ago
I used it for notifications once and it was really nice, as well as trivial to implement on the server side. I think that it can be thrown in to basically any server is a big selling point.
834.
by PeCaN 11y ago
Well, you'll need a garbage collector anyway, and with AOT compilation it would have to be conservative (which isn't that much of an issue, but precise collectors are generally a little more efficient). The problem is that you can
835.
by PeCaN 11y ago
Why would AOT compiled JS performance be better than the highly advanced JIT compilers that are _designed_ to run JS efficiently?! AOT compiling highly dynamic languages gives you very little room for optimizations.
836.
by PeCaN 11y ago
...Especially when, you know, we made that computer.... That's the really impressive part IMO. AlphaGo is an incredibly cool creation. Hats off to the DeepMind team.
837.
by PeCaN 11y ago
Dereferencing a null pointer is undefined behavior. free() on NULL is defined to be a no-op.
838.
by PeCaN 11y ago
That's when you make a nice set of M4 macros that generate C preprocessor macros that expand to templates. To be honest the time I did that it actually helped, which I guess goes to show how elegant C++ templates aren't....
839.
by PeCaN 11y ago
But... Lua is a register-based VM since like Lua 5. Not disputing that Rio Lua is also an excellent work though. Lua 5.1 only has 38 opcodes total. A complete description of how the VM works fits on a page or so.
840.
by PeCaN 11y ago
LuaJIT. It's a cutting-edge JIT with remarkably understandable algorithms and source. Every single piece of it is well thought out. Even the asm interpreters are pretty clean and explain why they work the way they do. Mike Pall is a de

More ›