Hi,
we have learned recently that exception handling might become
unreliable if a process approaches
complete memory starvation.
For that reason I had introduced a 100 MByte safety margin that
cases WS FULL to be reported
a little earlier
ot;
Sent: Tuesday, January 22, 2019 9:43:38 PM GMT -07:00 US/Canada Mountain
Subject: Re: [Bug-apl] WS FULL
You should probably ensure you have enough swap. Just add a few GB and you'll
be fine.
On Tue, 22 Jan 2019, 22:24 Hudson Flavio Meneses Lacerda <
hud...@hudsonlacerda.com wro
You should probably ensure you have enough swap. Just add a few GB and
you'll be fine.
On Tue, 22 Jan 2019, 22:24 Hudson Flavio Meneses Lacerda <
hud...@hudsonlacerda.com wrote:
> Hi.
>
>
> After closing some other programs (== freeing memory), APL worked.
>
> It seems it requires about 100 MiB o
Hi.
After closing some other programs (== freeing memory), APL worked.
It seems it requires about 100 MiB of free RAM as minimum?
Here I hardly will have that much (hardware: 450MiB of RAM)
)values generates lines like this:
Value #123: Flags = COMPLETE, ⍴⊏27⊐ ≡1:
SYNTAX ERROR: → in mac
Some info:
x86 32bit
Debian Jessie
GCC 4.9.2
Build command:
DYNAMIC_LOG_WANTED='yes' \
CXX_WERROR='no' \
./configure \
--with-gtk3 \
--with-pcre
make
sudo make install
On Wed, 16 Jan 2019 15:58:18 -0200
Hudson Flavio Meneses Lacerda wrote:
> Hi.
>
> I tried the ne
Some info:
x86 32bit
Debian Jessie
GCC 4.9.2
Build command:
DYNAMIC_LOG_WANTED='yes' \
CXX_WERROR='no' \
./configure \
--with-gtk3 \
--with-pcre \
make
sudo make install
On Wed, 16 Jan 2019 15:58:18 -0200
Hudson Flavio Meneses Lacerda wrote:
> Hi.
>
> I tried the
Hi.
I tried the newest trunk version (1114), but the program shows this
strange behaviour:
...
This program is free software, and you are welcome to redistribute
it according to the GNU Public License (GPL) version 3 or later.
a← 2
No. It's a system wide setting. The concept is called overcommit, and most
of the details seem to be covered in this Serverfault question:
http://serverfault.com/questions/362589/effects-of-configuring-vm-overcommit-memory
Regards,
Elias
Hi Elias,
interesting, thanks. Do you by chance know the na
Hi Elias,
interesting, thanks. Do you by chance know the name of the config
option?
Or is it a mallopt() setting?
/// Jürgen
On 06/17/2016 03:08 PM, Elias Mårtenson
wrote:
If you are running put if
If you are running put if RAM+swap on the machine, a default Linux
installation will not return NULL from malloc(). Instead, it will simply
kill the process when it tries to access the memory (actually, when it
attempts to map in a memory page, and the mapping operation fails). This is
likely what
Hi Blake,
if I start apl directly then it seems like GNU APL behaves
properly (I tried your
examples and always got a WS FULL).
I could imagine, though, that your shell (resp. script) is killing
APL when APL
tries to allocate too much mem
Sometimes, when you have, essentially, a WS full situation, GNU APL just
dies instead of giving a WS FULL error.
x←⍳1
x[1]←445
y←x
/home/blake/bin/apl: line 3: 7341 Doneakt
7342 Killed | /usr/local/bin/apl "$@"
blake@blake-v
12 matches
Mail list logo
