Not removing memory element

[John Finnson]

Hi, I have this code generated from Herbal, run using JSoar.

The issue is that the memory element in question starts off as

^testing.types.Printer

^PrintString "ello!"
^PrintID "1"

But it ends up becoming:

^testing.types.Printer

^PrintString "ello!"
^PrintID "1"
^PrintString "changed"

What it should be:

^testing.types.Printer

^PrintID "1"
^PrintString "changed"

This is the action in question:

sp {apply*testing-problemspaces-initial*PrintTheString
    (state <local> ^top <top> ^parent <parent> ^name testing-problemspaces-initial ^operator <o>)
    (<o> ^name testing-operators-PrintTheString)
    (<top> ^io <i1>)
    (<i1> ^output-link <i2>)
    (<o> ^Printer <Printer>)
    (<Printer> ^PrintString <Printer-PrintString>)
    (<Printer> ^PrintID <Printer-PrintID>)
    (<o> ^Printer <Printer>)
    (<Printer> ^PrintString <Printer-PrintString>)
    (<Printer> ^PrintID <Printer-PrintID>)
    -->
    (write |<hdb>testing.operators.PrintTheString</hdb>| (crlf))
    (write |<hdb>testing.actions.PrintTheString</hdb>| (crlf))
    (<Printer> ^PrintString <Printer-PrintString> -)
    (<Printer> ^PrintString |changed| )
}


Specifically, the removal on the third last line does not seem to be working. It should remove the "ello!" PrintString and replace it with the new PrintString "changed".


--
Sincerely,
John Finnson

[John Finnson]

Hi, thank you for your response. I am still very new to Soar and do not completely understand o-support and I-support.

I do not believe I have coded this as an elaboration an have provided the full Soar code so that you can review it.

On Thu, Jun 17, 2010 at 11:19 PM, John Laird <la...@umich.edu> wrote:

One thing that might be going on here is that this is an operator elaboration rule. Not an operator application rule. It could be giving I-support which could lead to unexpected behavior. You would be better off putting these structures on the state.

It would also help if you provided a watch 5 trace when the rule fires.

John

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
soar-group mailing list
soar-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soar-group

--
Sincerely,
John Finnson

[Bob Marinier]

While this is adding to a structure that is on an operator, Soar currently only makes wmes directly on the operator i-supported. Anything deeper is still o-supported (Soar does not walk the wmes from the operator on down to figure out if a new structure is attached to an operator). So I think this is still o-supported (but the preferences command would tell us for sure).

Bob

On Thu, Jun 17, 2010 at 11:19 PM, John Laird <la...@umich.edu> wrote:

One thing that might be going on here is that this is an operator
elaboration rule. Not an operator application rule. It could be giving
I-support which could lead to unexpected behavior. You would be better
off putting these structures on the state.

It would also help if you provided a watch 5 trace when the rule fires.

John

On Jun 17, 2010, at 10:20 PM, John Finnson <john.f...@gmail.com>
wrote:

> ---
> ---
> ---