opencog-dev team mailing list archive

["Joel Pitt" <joel.pitt@xxxxxxxxx>]

Yup, getting Tester working is now the focus.

Cesar commented out various parts of the code when he was initially
trying to just get things to compile... I thought I'd re-enabled those
bits and adapted them to OpenCog as appropriate, but it seems there
are a few files I missed.

J

On Wed, Jul 23, 2008 at 7:07 PM, Ari Heljakka
<ari.heljakka@xxxxxxxxxxxxxx> wrote:
> Cesar,
>
> using PLNShell for testing isn't really the best way to go at this point.
> You should use Tester.cc.
>
> Anyway, it seems that at least some of the framework is operational, but
> OTOH things like
> (null) (2)
> imply that at least there's a problem with accessing Atom names, since you
> shouldn't be seeing any nulls.
>
> -A
>
> Cesar Marcondes wrote:
>>
>> Dear Joel,
>>
>> I fixed that by calling "server();" in PLNShell main function. This
>> way, it creates a CogServer singleton accessible throughout the
>> current PLN port using CogServer::getAtomSpace(). In addition, there
>> are few asserts that break during tests so I commented out to run,
>> still investigating this issue.
>>
>> Attached you will find the PLNShell output.
>> Let me know if you find errors on it.
>> Cesar
>>
>> P.S.: I fixed the portability problems in Mac OS, created after
>> TR1/unordered_set and map were inserted. I attach the patch as well.
>>
>> On Mon, Jul 21, 2008 at 6:00 PM, Joel Pitt <joel.pitt@xxxxxxxxx> wrote:
>>>
>>> Thanks Moshe :)
>>>
>>> Yup, Ari informed me of this (elegant?) hack. So that'll be one thing
>>> for me to check up on. I actually realised this current segfault was
>>> much simpler than that tho... the AtomSpace just isn't initialised!
>>>
>>> On Tue, Jul 22, 2008 at 6:03 AM, Moshe Looks <madscience@xxxxxxxxxx>
>>> wrote:
>>>>
>>>> Hi Joel,
>>>>
>>>>> ... although now I have to work out why the PLNShell is segfaulting
>>>>> (possibly because of working in 64 bit - will check that tomorrow),
>>>>> but at least it compiles and links correctly.
>>>>>
>>>> Ari can confirm this, but as I recall there are places in the PLN code
>>>> where non-pointer data is being stored in pointers for convenience
>>>> with special-case code for checking these conditions before
>>>> dereferencing. If this is still there, it would be likely to break
>>>> when moving from 32 to 64 bit - this hypothesis should be testable
>>>> with appropriate assertions. Sorry I don't recall more, but hopefully
>>>> this is a useful hint (or maybe not ;->).
>>>>
>>>> - Moshe
>>>>
>
>
> --
> Ari Heljakka
> CTO
> Dream Broker Ltd
>
> Tekniikantie 14                 ari.heljakka@xxxxxxxxxxxxxx
> 02150 Espoo                     +358 40 568 2420
> Finland                         www.dreambroker.fi
>