UWN

> on the grounds ... ... or that the following is possible: ``` ?- [user]. p:-E=e,[t,E,s,t]. ?- p. error(existence_error(procedure,t/0),t/0), unexpected. % ..or, rather why? ```

``` ?- portray_clause(f(_,A,A)). f(A,B,B). % unexpected. Expected: f(_, A, A). ```

``` ulrich@p0:/opt/gupu/scryer-prolog$ /opt/gupu/scryer-prolog/target/debug/scryer-prolog ?- [user]. a:-a,a. ?- catch(a,error(E,_),true). memory allocation of 92274688 bytes failed Aborted (core dumped) ```

Please do not forget this one. It always takes some time to retest this...

All interesting bugs reside behind memory overflows. And it´s important to handle these cases. After all, most programs are wrong in some initial stage

One thing that I do not understand is whether or not Rust can handle stackoverflows caused by recursion. If not, every routine has to be written with manual stack management.

Currently, the error shows differently ``` ulrich@TU-Wien:/opt/gupu/scryer-prolog$ ulimit -v 1000000 ulrich@TU-Wien:/opt/gupu/scryer-prolog$ cargo run Finished dev [unoptimized + debuginfo] target(s) in 0.14s Running `target/debug/scryer-prolog` ?- [user]. a:-a,a. ?- catch(a,error(E,_),true). Segmentation fault...

Bleeding edge... but definitely fine progress.

And after looking at it a second time, there does not seem to be a `try_reserve` for the stack, right?

``` ulrich@p0:~/SO$ ulimit -v 50000 ulrich@p0:~/SO$ time /opt/gupu/scryer-prolog/target/release/scryer-prolog -f ?- use_module(library(lists),[length/2]). true. ?- length(L,N), N mod 100_000 =:= 0. L = [], N = 0 ; L = [_A,_B,_C,_D,_E,_F,_G,_H,_I,_J,_K,_L,_M,_N,_O,_P,_Q,_R,_S,_T,...], N...