If an experimental feature was enabled in a previous snapshot installation, the release version will remember this and make the feature available.
We should either #ifdef away the implementation or make sure we handle this by ignoring the preference setting.
If you are referring to the concat feature, what is holding you back from enabling it permanently in the new release? It seems like a good and well tested feature, so why is it still flagged as experimental?
Just ignoring preferences would still cause the warning message I think. I'll prepare a patch to skip the actual registration.
concat has shown to cause major recursion issues, and enabling it without handling the recursion issues is likely to cause a lot of pain.
The fix only worked when severely limiting it. When I increased the recursion limit to 1000, things started to exhaust the stack before that limit is reached.
When using concat() in practice, even 1000 might be too few to be able to build more complex objects.
..unless I misunderstand which fix you're referring to..
Right, if we can find the stack size, this will make us able to dynamically limit recursion depth.
We still have an issue that we use way too much stack. I'm sure this is fixable with some tedious refactoring. Alternatively implement smth. like tail recursion optimization as that's the most usual case of runaway stack usage.
Register experimental features only with ENABLE_EXPERIMENTAL defined …
Yep, currently smth. between 1MB and 8MB I think, depending on OS, version and user settings. In addition, default stack size for created threads tend to be small, but we manually bump it to 1MB.
We put way too much data on the stack, so the correct solution is to keep this under control (both memory usage and stack usage).
@nophead Your stack size measurement method seems very "to the metal".
I admit I don't know much about the finer details of how the stack is laid out in memory. And I would assume (like you) that the stack is a contiguous block. I have the feeling that the stack might go from a low to high address on one arch, and from high to low on a different arch. (which you could account for). What I am unsure about is what happens when Address layout randomisation is used.
Is there not some API in the standard c libraries that gives you the amount of stack available, and the amount your process is currently using, and would take care of all the platform dependent idiosyncrasies. (If there are any)
It might work... It does depend on the stack memory being contiguous though which after reading this I am not to sure it will be:
I think the only way it can be non-contiguous in user space is if the compiler has support for it and it is enabled. Presumably we have control over that and no motivation to enable it.
Well...either way I think a better approach would be to use a heap based stack as you suggested i.e. std::stack 8MB is a huge amount of memory to need, and OpenSCAD is an interpreted, language so it should be able to have the same recursion depth as a language like say for example Python. I use a QStack<T> in RapCAD, although It doesn't handle recursion very well apparently :/
time ./rapcad recurse.rcad -p
Segmentation fault (core dumped)
Ooops, wrong version of time
Command terminated by signal 11
0.22user 0.16system 0:00.72elapsed 54%CPU (0avgtext+0avgdata 35812maxresident)k
0inputs+0outputs (0major+9152minor)pagefaults 0swaps
for anyone working on this (even though it is totally off topic) ... it might be helpful to note that the Windows cross-build system sets the stack size for Windows to be the same as on linux, so that bugs will act the same. (dont remember where the issue is on this, but its in the build files).