Is doing stuff like constant folding pre-execution really worth it? I mean, won't the engine itself (V8, JSC, MozJS) be doing it anyway? I know that Google's Closure Compiler — probably still the most advanced JS optimized — also does it but I can't help but think it's probably pointless.
Stuff like constant folding won't take place until you hit an optimizing compiler tier. For the interpreter and baseline/template-compiler tiers, there's just not enough time to do that sort of dataflow optimization. So yes, it would help at least somewhat, esp. if you don't think the code is likely to tier up much for whatever reason (no one part is all that hot, or perhaps it's too polymorphic).
From the repo: "Meta continues to make periodic ad hoc contributions to this fork and merge corrections back to their private repo. The maintainer thanks Meta for this continued informal cooperation."
I hear this and it makes sense but when I actually go about implementing it, it quickly falls apart.
Most apps are UI, remote requests and maybe some storage. What do you put in the common core? Android does HTTP requests one way. iOS does them another way. You go for the lowest common denominator an implement a third way, using libcurl or something?
Or do you just put business logic in the common core? Is there really that much business logic that doesn't issue requests or access a database?
Excellent Points, this is where the answer is "it depends".
> What do you put in the common core? Android does HTTP requests one way. iOS does them another way. You go for the lowest common denominator an implement a third way, using libcurl or something?
If it's really functionality that cannot reasonable be shared don't share it.
It's probably more work to maintain bindings to a single API client in the core and fiddle with all the details of not using the native HTTP client implementations that it is to implement the API client twice.
Writing the API client twice is boring, but that's a good thing.
> Or do you just put business logic in the common core? Is there really that much business logic that doesn't issue requests or access a database?
The shared core is optional. You might have the need for it, then it's a good solution.
For an app like snapchat you'd probably share the video effects and have that in your core library.
That's perfectly reasonable but, at that point, the argument becomes: build 95% natively and maybe there's a 5% "core" that warrants extracting into a common lib. Technically? That's excellent architecture. In terms of saving development time — which is where stuff like React Native comes in? Not so much.
The first is the obvious typo around `sizeof`, which I didn't even see at first (edit: this).
The second is that code will only work for 8-bit colors, i.e. only the 8 (technically CHAR_BIT, "a byte") least-significant bits of `rgb` will be used. This is a quirk of the `memset()` standard C function, which has the prototype:
void *memset(void s[.n], int c, size_t n);
but then the man page [1] says:
The memset() function fills the first n bytes of the memory area pointed to by s with the constant byte c.
Neato! It's nice to find zserge around. He built upon the idea of my static site generator Zas [0] to create his own zs [1][2] a few years ago. I think he's still using it :)
No. This is a trend. HN is a tech and startups website so it will show trends. At one point it was VR, eventually it was Web 3.0. Right now it's LLMs but this too will pass and something else will come along.
Clasp is really cool but it’s a shame that it does not support Windows properly. A lot of C++ is used on Windows. I’ve seen this pattern repeated elsewhere — I think it has to do with Windows exception handling being different and complicated. Hopefully jank does not suffer the same fate, since author is a gamedev!
The Jank creator talking with folks at CERN about integrating with their C++ codebase makes sense too. Clasp was originally used to do some molecular simulation if memory recalls.
reply