Thread Previous • Date Previous • Date Next • Thread Next |
Hi Joel,unfortunately there is absolutely no way in which you can, in a reasonable time, complete the porting by changing all PLN code to use the VersionHandle system.
With luck, I might be able to do it myself with 3-4 days of work. For someone not experienced with various subtleties of PLN, even for a pro like you, less than 3 weeks would sounds optimistic.
I suggest that, instead, the fresh-parameter is introduced to OpenCog core (with default = false), and it is implemented so that its functionality mimics the functionality of the fresh parameter in NM core. That should not prove to be much work, and it may have uses beyond PLN. (It wasn't created for PLN in the 1st place.)
The "fresh" parameter is a feature that is fundamentally required by PLN.The point of freshness is that you can have multiple instances of an atom with identical structure. And, when you add a new atom to atom space, PLN wants to have the option to either force it to be independent of previous such atoms, or to allow its integration to existing such atoms.
If you don't want to or can't change the OpenCog atom space interface to support that, then you may be able to simulate it in the AtomTableWrapper.
In principle VHs can mimic the "freshness" conceptually, but in practise it'll be hell of a job to convert between these 2 representations of the same thing.
Regarding the template debugging, I've always found Linux C++ dev tools to be a time-drain for serious stuff (which is why I use Visual Studio which handles template debugging etc. in a nice way), but there _is_ a semi-useful tool for tackling the template naming debug issue for Linux, but it is suitable only for parsing the output of the compiler/linker I think, not IIRC real-time debugging. I can ask if anyone remembers the name of it if you wish.
-A Joel Pitt wrote:
Hi Ari and Ben, I've got to stage where PLN compiles, the shell runs and Tester gets to a certain point before an assertion fails regarding a Handle not being "real" (which from my understanding means it has a Handle less than the number of atom types). I don't have enough holistic understanding of PLN to debug this immediately... although I could step through from the beginning, it'd be slow. The only thing that I *expect* to be breaking things is adding atoms to the AtomSpace. In OpenCog there is no fresh or managed parameter, thus I had to remove those from the addAtom calls to get it to compile. Removing the fresh=true bug was also one of the next tasks for me to tackle... thus my inclination is to try to fix that bug first before trying to trace the exact cause of the un"real" Handles in places they shouldn't be.From memory, I think the plan was to use VersionHandles? Is this correct?I've been trying to trawl through my gmail archives to glean insights about the problem, and while I'm slowly getting there, any advice or a point in the right direction would be appreciated. Also... if there are particularly important conversations or wiki pages that I should read, feel free to point me at those. Oh, and lastly, does anyone have any suggestions of tools for parsing and understanding template while debugging? With each Vertex being a somewhat long boost::variant it can get tedious to comprehend the output... Currently I'm just using Vim and gdb along with a .gdbinit hack that allows one to print all the stlcontainers more nicely. Thanks, J
-- Ari Heljakka CTO Dream Broker Ltd Tekniikantie 14 ari.heljakka@xxxxxxxxxxxxxx 02150 Espoo +358 40 568 2420 Finland www.dreambroker.fi
Thread Previous • Date Previous • Date Next • Thread Next |