Good points on both sides here! I'm convinced that given there isn't a tangible benefit aside from documentation, this is probably not worth pursuing at the moment.
I think eventually we may want to rethink our JS support more radically - in order to gain larger benefits like modularity and size wins - and at that time we should remember to use a better name, when it's a break point anyhow. But that's far off. - Alon On Thu, Oct 17, 2019 at 9:51 AM Andrej Nosky <[email protected]> wrote: > I would say the solution that Alon Zakai postponed is least invasive > towards existing codebases. I still feel like people over here tend to > underrate this problem. It's not heap and therefore we should not call it > heap. Having stack variables in HEAP object is just confusing. Not to > mention it takes some time to dig out the information that something like > STACK_MAX exists in generated js file and it virtually splits the memory > object. > > Dňa štvrtok, 17. októbra 2019 18:14:11 UTC+2 jj napísal(-a): >> >> A very large big -1 in bold, in caps, if you could type a number in caps. >> >> Very much appreciate the idea of this thread, though there are a >> million things that will be invalidated in existing code all around, >> not to mention references in communication threads, forum posts etc. A >> "var HEAP8 = MEM8;" could cause confusion as well, and just increases >> code size for no runtime benefit - one would have to remember to keep >> both in track, and invalidate both to let JS engine reclaim. I think >> this is very much in the bikeshedding territory. >> >> to 17. lokak. 2019 klo 18.27 Gabriel Cuvillier >> ([email protected]) kirjoitti: >> > >> > Hey, I definitively thought you'd say the opposite due to the various >> issues you had with unexpected changes. Well, just joking ;) >> > >> > I admit I have the same issue than you: my projects often breaks on new >> releases of Emscripten. I have to tweak the Doom 3 port regularly (well on >> this project this is just for the fun. But I agree that for customers >> projects, moving on new versions of Emscripten is a bit more worrying). But >> I understand these recent breaking changes were done for good causes: the >> new LLVM backend, Asyncify, updates toward WASI compatibility, and so on... >> as so, due to the long-term benefits of these new functionalities, I am >> happy with all that progress even at the price of short-term issues >> > >> > Cheers, >> > >> > Le 17/10/2019 à 17:13, Beuc a écrit : >> > >> > While I regularly complain about unexpected/undocumented change, I >> think Alon's plan is pretty careful and reasonable. >> > >> > Badly named variables are a perpetual mental hassle, and triggering a >> clear error message means the change won't be obscure. >> > >> > Cheers! >> > Beuc >> > >> > On 17/10/2019 17:02, Gabriel Cuvillier wrote: >> > >> > 100% agree with Floh there. Changing such a thing is an open door >> to a very obscure, hard to find, and unwanted potential "project breaker", >> for a very minor added value... >> > >> > Having to live with some minor technical debt due to badly named things >> is acceptable I suppose. >> > >> > >> > Le 17/10/2019 à 16:51, Floh a écrit : >> >> >> >> Isn't there at lot code out there in the wild that would be broken by >> >> such as change? >> >> >> > Yeah. TBH I'm not a fan of a name change even if the new name is >> slightly more fitting. That's one of those obscure things that suddenly >> breaks projects, usually at the worst possible time (even with a >> deprecation note and period, this stuff is usually ignored). If such a >> change would come with a real benefit (such as better performance, or less >> code maintenance in the future) I'd be all for it, but not when it's just >> one of the many "badly named things" in computing :) >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "emscripten-discuss" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/emscripten-discuss/10c8a820-5a3a-d1a6-dec2-6694dd9631ea%40beuc.net. >> >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "emscripten-discuss" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/emscripten-discuss/4084a0ed-cc59-55c3-83e6-46660e2d1795%40gmail.com. >> >> > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/a8687478-2222-40b9-a358-1adfb27177e3%40googlegroups.com > <https://groups.google.com/d/msgid/emscripten-discuss/a8687478-2222-40b9-a358-1adfb27177e3%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQQA2WjX0807vMtQ5YcQdPKSLphoqDXU_zH3kpmgv%3DWGg%40mail.gmail.com.
