James Addison dixit: >Based on what I've learned about this bug, I believe that architecture-specific >behaviour related to stack sizes is inherent in the V8 library vendored by >upstream NodeJS.
Yes, but the v8 library’s defaults are targetting a browser, and one whose uses are much wider, e.g. inside Android, than NodeJS’s itself. Which is why I believe that NodeJS very much can and certainly should fix this by setting suitable limits. >long time. Individual codebases such as the affected 'src:dygraphs' package >can also be improved to reduce the likelihood of call stack size overflow. It’s babel7 actually which runs into this. And I believe that, rather to the contrary, further evolution of software-written-in-NodeJS will let this error show up *more* and probably on nōn-arm64 as well(!), so I’d rather have NodeJS set proper limits instead of sticking to v8’s given the latter has a different scope and run-time environment than the former. >Given those, and the absence of any sense that this is a regression, I think we >should lower the priority of this bug to below release-critical. I very much disagree, this breaks arch:all packages on some platforms so it causes issues packagers who don’t themselves use arm64 cannot discover in the first place. We need to at least achieve architecture partity in Debian, pending better upstream fixes. bye, //mirabilos -- 16:47⎜«mika:#grml» .oO(mira ist einfach gut....) 23:22⎜«mikap:#grml» mirabilos: und dein bootloader ist geil :) 23:29⎜«mikap:#grml» und ich finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann gleich mal auf usb-stick installieren -- Michael Prokop über MirOS bsd4grml
