Re: Atom table full

[Vic Bancroft]

JCK wrote:
> I'm getting an "Atom table full" error.  Admittedly, I do not know 
> much about the atom table, I didn't even know there was one until I 
> found out mine was full.  I read a post in the archives concerning 
> this which stated that:  it was planned in the future to have an atom 
> table without limitations (which I don't think has been done since I'm 
> getting this message); and the only way to change the limit was to 
> modify the code and recompile.
Are you running on a 32 bit operating system ? 
What version of mysql are you using ?
> The thing is I'm quite sure I don't need that many atoms, the portion 
> of my code that seems to be the culprit is a loop which reads in data 
> (from mysql), processes the data and writes data back (to mysql).  I 
> was running into problems with stack size, so instead of looping 
> recursively, I used a 'repeat' which seemed to have improved my stack 
> issues but then I got "Atom Table Full'.  I think it's just looping so 
> many times that any number of atoms that get created and not destroyed 
> will eventually fill the table.  I even exit the 'repeat' loop every X 
> number of loops (in hopes of cleaning thing up), and then re-enter the 
> 'repeat' loop.
That sounds like an appropriate way to deal with a database, though 
there seems to be some dangling reference.  Can you post your code or a 
test case that replicates the problem ?
> I have no need for backtracking during this portion of the code and 
> have no need for the data after a loop is completed (it's in mysql).  
> So I guess my question is:
>
> (1) is there anyway of clearing the atoms that won't be used again 
> from table?
> (2) there's nowhere in the loop where a huge number of atoms are 
> created.  The only place I can think of there being atoms created is 
> after SQL calls when I'm converting and putting the data into prolog 
> variables.  Is there anyone else who's had this problem found a 
> culprit which is known for creating lots of atoms?
> (3) Any suggestions are welcome.
I have not used mysql from gprolog for a while, but am interested in 
it's proper operation.

My system is a linux x86_64 platform, running GNU Prolog 1.3.0 and 
mysql-5.0.27, so perhaps we can see if the situation can replicated here 
. . .

more,
l8r,
v

--
"The future is here. It's just not evenly distributed yet."
-- William Gibson, quoted by Whitfield Diffie