Bumps max length

[gampleman]

This makes it harder to hit the Fuzz.rollDice: Your fuzzers have hit the max size of RandomRun (generating too much data).

[Janiczek]

Can Elm lists realistically hold millions of elements? 🤔 This limit is for the length of the RandomRun List Int. I think this x1024 increase just makes it meaningless.

I'm down to just removing the limit (and its usages - elm-review no-thoughts-attached style) instead, but yeah we can also find a good new limit.

I wonder, does your fuzzer still hit the limit if you just double the limit? x4? x8?

[gampleman]

My fuzzer is not even remotely done and is hitting the limit, so doubling is unlikely to help.

Can Elm lists realistically hold millions of elements?

Yeah, for instance running this in elm repl is fine:

let
   b = List.repeat (64 * 1024 * 1024) 1
in
List.sum b
-- About 7 seconds later:
67108864 : number

However, it is on the limit. Node seems to error out even if you just double that number. So perhaps one advantage of keeping it like this is that you get a slightly friendlier or easier to debug error rather than just:

<--- Last few GCs --->
fi[22797:0x7f9601216000]    17045 ms: Mark-Compact (reduce) 3771.5 (3869.0) -> 3771.4 (3838.0) MB, 4021.4 / 0.0 ms  (+ 0.2 ms in 2 steps since start of marking, biggest step 0.2 ms, walltime since start of marking 4030 ms) (average mu = 0.150, current mu = [22797:0x7f9601216000]    22115 ms: Mark-Compact (reduce) 3933.5 (4002.8) -> 3933.5 (4002.8) MB, 4546.7 / 0.0 ms  (+ 0.2 ms in 3 steps since start of marking, biggest step 0.1 ms, walltime since start of marking 4555 ms) (average mu = 0.124, current mu =

<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10da68025 node::Abort() (.cold.1) [/Users/hampl/.asdf/installs/nodejs/19.5.0/bin/node]
 2: 0x10c3c35e9 node::Abort() [/Users/hampl/.asdf/installs/nodejs/19.5.0/bin/node]
 3: 0x10c3c37cf node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/Users/hampl/.asdf/installs/nodejs/19.5.0/bin/node]
 4: 0x10c556916 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/Users/hampl/.asdf/installs/nodejs/19.5.0/bin/node]
 5: 0x10c742387 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/hampl/.asdf/installs/nodejs/19.5.0/bin/node]
 6: 0x10c746fd1 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [/Users/hampl/.asdf/installs/nodejs/19.5.0/bin/node]
 7: 0x10c742f75 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::internal::GarbageCollectionReason, char const*, v8::GCCallbackFlags) [/Users/hampl/.asdf/installs/nodejs/19.5.0/bin/node]
 8: 0x10c7402b8 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/hampl/.asdf/installs/nodejs/19.5.0/bin/node]
 9: 0x10c73f6bf v8::internal::Heap::HandleGCRequest() [/Users/hampl/.asdf/installs/nodejs/19.5.0/bin/node]
10: 0x10c6d4451 v8::internal::StackGuard::HandleInterrupts() [/Users/hampl/.asdf/installs/nodejs/19.5.0/bin/node]
11: 0x10cb9bd58 v8::internal::Runtime_StackGuard(int, unsigned long*, v8::internal::Isolate*) [/Users/hampl/.asdf/installs/nodejs/19.5.0/bin/node]
12: 0x10cfe6bf9 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [/Users/hampl/.asdf/installs/nodejs/19.5.0/bin/node]
13: 0x116a0a3c3
14: 0x10cf5ea9c Builtins_InterpreterEntryTrampoline [/Users/hampl/.asdf/installs/nodejs/19.5.0/bin/node]
15: 0x10cf5ea9c Builtins_InterpreterEntryTrampoline [/Users/hampl/.asdf/installs/nodejs/19.5.0/bin/node]

We could make it a bit less (perhaps 1024 * 1024) to make that outcome more likely in more realistic conditions.

[Janiczek]

Closed via 02f4e3675ad2b18a32a5238c4c4b423ebf2e9020 2.1.2 will not have the limit anymore