sleyzerzon / soar

Automatically exported from code.google.com/p/soar
1 stars 0 forks source link

epmem -- close is no longer implemented #156

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
epmem --close used to work (I used it in late 2012). It seems to not be 
implemented any more. Please restore this!

Original issue reported on code.google.com by marin...@gmail.com on 25 Mar 2014 at 5:57

GoogleCodeExporter commented 8 years ago
What is the expected behavior of close?

I don't think I've done any extensive modification to epmem since late 2011, so 
maybe this change came from Mazin's work with the LTMs?

Original comment by justinn...@gmail.com on 25 Mar 2014 at 6:03

GoogleCodeExporter commented 8 years ago
Reading the notes from r13788, it appears that Mazin has replaced --close with 
--init: the code is still in episodic_memory.cpp/h, but that the CLI no longer 
exposes the functionality.

Original comment by nate.der...@gmail.com on 25 Mar 2014 at 6:09

GoogleCodeExporter commented 8 years ago
Close closes the database connection. It effectively forces everything to flush 
and releases any handles to the file so that the database can then be opened by 
another agent, copied, etc. (I think it may only make sense for on-disk 
databases.) I believe this is a sqlite operation, but I'm not sure.

If I try to do it now (on the trunk), I just get an error message saying there 
is no such option.

Original comment by marin...@gmail.com on 25 Mar 2014 at 6:09

GoogleCodeExporter commented 8 years ago
Assigning this to Mazin instead.

Original comment by justinn...@gmail.com on 25 Mar 2014 at 6:21

GoogleCodeExporter commented 8 years ago
Yes, it did happen in Jan 2013 when we changed the schema around.  It may be 
related to how we handled changes to the memory/file/append settings and how 
the database was initialized.  It may be that we thought the proper way for a 
user to close the database file and leave epmem in a valid state was to switch 
to memory mode or to turn off epmem.  I'll check it out.  If that's the case, 
we could always add the old command back and have it do one of those two 
things.  

btw, if you're looking for that command because you're debugging a crash and 
want to insure all data gets flushed, maybe it makes more sense to add the 
previous close command as a debug command instead and not make it visible to 
the typical user.

Note that there is a re-init command that will first close the database and 
then re-open it.  This could be a workaround for now.  Just make sure the 
append database setting is on, otherwise it will empty the tables when it 
re-opens them.  

Original comment by maz...@gmail.com on 25 Mar 2014 at 6:23

GoogleCodeExporter commented 8 years ago
Looks like this was removed in r13783. The underlying function (epmem_close) is 
still in episodic_memory.cpp, but the --close option was removed from 
cli_epmem.cpp:

http://code.google.com/p/soar/source/detail?r=13783

Original comment by marin...@gmail.com on 25 Mar 2014 at 6:24

GoogleCodeExporter commented 8 years ago
My use case is actually for unit testing where multiple agents may want to use 
the same epmem database file in sequence, and we need to guarantee that the 
previous agent has released it before the next one tries to open it. (This is 
what we used it for in 2012.)

Original comment by marin...@gmail.com on 25 Mar 2014 at 6:26

GoogleCodeExporter commented 8 years ago
I added the command back.  Note that stepping again will reinitialize the 
database.  So, if you have it set to not append to the database, it will erase 
the current contents.  You may want to turn append on, turn episodic memory off 
or switch to memory mode when using the close command.

Original comment by maz...@gmail.com on 26 Mar 2014 at 7:59

GoogleCodeExporter commented 8 years ago

Original comment by maz...@gmail.com on 26 Mar 2014 at 7:59

GoogleCodeExporter commented 8 years ago
Thanks Mazin! These additional notes about --close would be great to include in 
the documentation (see issue 152)

Original comment by bob.mari...@soartech.com on 26 Mar 2014 at 8:03