Re: max string size

Don Cohen wrote:
> This seems (so far) to have worked:
>   ./configure CC='gcc -DTYPECODES' build-dir
> then after make I get
>   [1]> (software-type)
>   "gcc -DTYPECODES  -g -O2 -no-integrated-cpp -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -Wno-shift-negative-value -O2 -fwrapv -fPIC -fno-strict-aliasing -DNO_ASM -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES    libgnu.a  -lreadline -lncurses /usr/local/lib/libffcall.so -Wl,-rpath -Wl,/usr/local/lib  /usr/local/lib/libsigsegv.a
>   SAFETY=0 TYPECODES WIDE_HARD SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
>   libsigsegv 2.14
>   libreadline 8.1
>   libffcall 2.4"
>   [2]> (length (make-array (* 1024 1024 5) :element-type 'character))
>   5242880
>   [3]> (length (make-array (* 1024 1024 9) :element-type 'character))
>   9437184
>   [4]> (length (make-array (* 1024 1024 17) :element-type 'character))
>   17825792
>   [5]> (length (make-array (* 1024 1024 33) :element-type 'character))
>   34603008

It looks like, with this build, larger arrays are supported.

> I'm a bit surprised by SAFETY=0 -- should I be worried?

SAFETY=0 is the default setting; no need to worry.

> The TYPECODES WIDE_HARD SPVW_BLOCKS agree with what I saw in 2.49+ (2010)
> but the SPVW_MIXED TRIVIALMAP_MEMORY differs from that and is what I see
> in 2.49.93+ (2018), as opposed to SPVW_PURE SINGLEMAP_MEMORY in 2.49+
> 
> I have no idea whether those choices are good, bad or indifferent.

These are the default choices of the object representation, based on the
constraint that you want TYPECODES. The default has changed over the years,
based on practical experiences. If it works for you, all is fine.

In your build with the TYPECODES constraint, some limits may be different
(such as the max. number of conses that can be present at the same time),
and some memory/speed trade-offs may be different. But all in all, if the
only unusual requirement of yours is to have huge arrays, you can trust
this build.

Bruno





_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel