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 [EMAIL PROTECTED]
02150 Espoo +358 40 568 2420
Finland www.dreambroker.fi
_______________________________________________
Mailing list: https://launchpad.net/~opencog-dev
Post to : opencog-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~opencog-dev
More help : https://help.launchpad.net/ListHelp
