From [email protected] on July 23, 2009 00:32:35

Description From Bob Marinier 2006-10-06 19:58:06 (-) [reply]
In email "Thoughts on debugging" 10/1-10/3) we have discussed adding a
limited
trace window which displays the critical information required to determine
when
more in-depth debugging should be done (in the traditional trace). This is
a
summary of that discussion.

There are really two parts:

1. Change the traditional trace to be more memory efficient.
2. Add a new module (the limited trace).

For the traditional trace, instead of storing the full trace in memory, we
will
log it to a file. An index will be kept in memory so that when someone
expands
a node, the contents of that node can be loaded from the file and
displayed.
Thus, it is still possible to scroll around quickly in the trace, but it
should
take far less memory.

For the limited trace, the idea is that we do not have a scrolling window
(since no one will scroll back anyway). The information displayed
summarizes
the most recent decisions and messages. It could be exactly like a
traditional
trace (e.g. showing the last 10 decisions/messages), but we can get more
power
by adding two capabilities: ordering and grouping.

Grouping is the ability to group multiple similar decisions (e.g. same
operator
name or same impasse type) together so they only take one line in the
trace. A
count can be displayed for the collapsed group. Thus, an agent that waits
for
17 cycles will just display "O: (wait) (17 times)". Similarly for an agent
that starts state no-changing. There are at least two kinds of grouping:
group
all similar decisions together, or group only those similar decisions that
have
actually occurred in sequence.

Ordering is the idea that we might want to display the information
non-chronologically. Certainly chronological is one ordering. Other
orderings
include by count or alphabetically.

Since the limited trace is non-scrolling and we want to change ordering on
the
fly, it probably makes more sense to implement it as a table than a text
window.

There are some other details. If a user is relying primarily on the
limited
trace during a run, we should provide the option to not update the
traditional
trace during the run. We may even want to put the traditional trace in a
tab
group with the limited trace, so we only have to see one at a time (no
sense in
wasting all of that screen realestate if we're not going to be updating
it).
Also, since the trace may be quite long, loading it into the traditional
trace
window when the agent stops may take a long time, in which case we may need
to
do so asynchronously (starting the end). This way the user can start
inspecting it immediately.

We may also consider putting a limit on the length of the trace (possibly
based
on available memory) so that we throw out the oldest stuff to avoid running
out
of memory (presumably it will still be in the log file, but not available
in
the trace window).

We also will need to modify the existing Edit->Find functionality to search
the
file, since the full trace will not be loaded in memory.

The email discussion contains more details about the motivation for some of
this and some examples of how the limited trace might look, but I think
I've
captured the desired functionality here.

Original issue: http://code.google.com/p/soar/issues/detail?id=19

Skipping this issue number to maintain synchronization with Google Code issue IDs.

_Original issue: http://code.google.com/p/soar/issues/detail?id=11 _

From [email protected] on July 23, 2009 00:06:50

Description From Bob Marinier 2005-07-13 09:06:13 (-) [reply]

1. Start the Java debugger
2. Change the state tab's command to "print s1"
3. Step. Notice the format of the output of the command.
4. Step twice more. Notice that, even though the contents of the output
   haven't
   changed, the formatting has.
5. Step 4 times more. The formatting has changed again.
6. Step 5 times more. The formatting has changed again. The formatting
   seems
   to stabilize here.

I've confirmed the issue exists in TestCommandLineInterface as well.

This is probably an issue with how the formatting is generated internally
in the
kernel. If that's the case, then the issue should go away when we switch
over
to using XML output for everything (at least, it'll fix it for the tree
view).
Given that, it may not be worth fixing this specific issue (unless it's
really
easy).

Original issue: http://code.google.com/p/soar/issues/detail?id=5

From [email protected] on July 23, 2009 00:12:16

Description From Jonathan Voigt 2006-02-07 13:09:23 (-) [reply]
rmarinie:
Second, I propose adding the ability to register additional help
directories with the help command. For example, QuickLink might have
its own help dir, and we can add that to the "help path" that gets
searched when the help command is used. The standard help directory
will always be in the help path, but some applications may add
additional directories with something like "help --append-dir
myapp/help". Furthermore, the help command will know which command help
files are in the standard directory and which aren't, so it can mark the
application-specific commands with an * (or other distinguishing mark)
when the available commands are listed, so someone can see at a glance
what new commands are available for this application.

voigtjr:
As for additional help directories, I can see that being no problem but I'm
not
sure it is necessary. The commands shouldn't overlap, so putting all the
help
in that one directory (and maybe renaming it Help/ instead of CLIHelp) I
think
is the best idea, although I could be talked out of that I think.

rmarinie:
The main reason for having separate help directories is so
application-specific help is only listed when running those
applications. If we put all of the help in one directory, it would be
difficult to tell which commands are really available for the current
application -- I would get QuickLink's commands listed when running the
debugger (unless we start adding special tags to the beginning of files
to say what applications they are for, which might be ok but sounds more
complex/bug prone).

Also, it is possible that an application would override a standard
command and thus have a special help file for it (but with the same name
as the original command). I don't think it's a good idea for an
application to do this (and I don't think any currently do), but it is
technically possible.

Original issue: http://code.google.com/p/soar/issues/detail?id=9

From [email protected] on July 23, 2009 00:59:44

Description From Bob Marinier 2008-07-02 14:53:45 (-) [reply]
I profiled the TOHSML demo to get an idea of where time was being spent in
SML/Soar, and it turns out that the biggest offender was ElementXML.

Anyway, it looked like most of the time was being spent in construction and
destruction of objects. We may be able to avoid most of the cost by using
memory pools. (Boost has a memory pool class that we might look into, or
it
might be simple enough to do it ourselves).

These results should be taken with a grain of salt, though, since I'm not
that
familiar with the tool used (AMD's CodeAnalyst). Certainly, we should try
to
reproduce the results a few ways before doing too much work.

Original issue: http://code.google.com/p/soar/issues/detail?id=35

From [email protected] on July 23, 2009 00:54:42

Description From Bob Marinier 2008-06-13 11:16:14 (-) [reply]
Time sources are used in various places in Soar and SML, including:

1. Timers in the kernel itself, used to keep track of how long various
   parts of
   the code take to run (as reported by the stats command).

2. The "time" command, which reports how long a given command takes to
   execute.

3. In soar_thread::OSSpecificTimer (added on the gski-rem branch; used to
   profile connections and by TestSMLPerformance).

Each of these uses a different mechanism for tracking time, with different
resolutions and consequences. For example, clock() has a low resolution,
and
it measures real time (as opposed to process time). In contrast, the
Windows
system call QueryPerformanceCounter is high resolution and measures process
time (and thus is not affected by things like multi-processor systems and
power
saving features that change the processor frequency). Ideally, we want to
use
the same timing mechanisms throughout all the code, and it should be high
resolution. It should measure real time or processor time as appropriate
(e.g., the "time" command claims to report both).

Here's how times are currently tracked by various parts of the code:

1. Kernel times are tracked using getrusage on linux, and GetProcessTimes
   on
   windows. These both have low resolution and high call cost.

2. The "time" command reports processor time and real time. For processor
   time, it uses gettimeofday on linux and GetTickCount on windows. For real
   time
   it uses clock. As far as I can tell, all of these report real time (so the
   results of this command are incorrect). Clock and GetTickCount are low
   resolution. gettimeofday is affected by anything that changes the system
   clock
   (e.g., NTP services), and is also affected by anything that changes the
   processor frequency (e.g., power saving modes).

3. soar_thread::OSSpecificTimer uses gettimeofday on linux (with the
   problems
   as noted above) and QueryPerformanceCounter on windows, which has a high
   call
   cost, but is the highest resolution timer available on windows, and isn't
   affected by power saving features or changes to the system time, and
   shouldn't
   be affected by multiprocessor/core systems (barring BIOS bugs).

Choosing the "best" time source: It seems like there is no single time
source
that has no disadvantages. Furthermore, there is no cross-platform time
source. On Windows, QueryPerformanceCounter is probably the best choice:
it
has the best resolution, and the overhead shouldn't be any worse than what
we
already have. On Linux, the highest resolution seems to be gettimeofday,
which
is unfortunate given all of its drawbacks. A possible alternative is to
use
RDTSC (assembly instruction), but this is only available on Intel machines,
and
suffers from various problems (see the MS and Intel references below).
Still,
it may be the best we can do on Linux. For process time (as opposed to
real
time), it looks like we're stuck with GetProcessTimes and getrusage.

Regardless of the decisions we make here, we should have a single class for
getting time information that is used by all of these different places. I
recommend using the existing soar_thread::OSSpecificTimer (which will have
to
be moved out of ConnectionSML, but the thread stuff doesn't really belong
there
anyway). Then as we learn more we can update the code in one place, and
everything will be consistent.

For places where the code runs so fast that timing is useless (e.g., timing
some of Soar's phases), it may make sense to disable the timers altogether.
If
the code appears to be running slow, people can turn the timers back on to
investigate. As it is, timers introduce significant overhead in the kernel
(~25% in the towers-of-hanoi demo, as measured with timers --off.
Admittedly,
more complex code will be less affected).

References:

Increasing Timing Resolution for Processes and Threads in Linux http://ww2.cs.fsu.edu/~hines/present/timing_linux.pdf Win32 Performance Measurement Options http://www.ddj.com/windows/184416651 In particular: http://www.ddj.com/showArticle.jhtml? documentID=win0305a&pgno=18

Thread on gettimeofday resolution http://kerneltrap.org/mailarchive/linux-kernel/2008/4/10/1392304 Game Timing and Multicore Processors http://msdn.microsoft.com/en-us/library/bb173458(VS.85).aspx Measure Code Sections Using The Enhanced Timer http://softwarecommunity.intel.com/articles/eng/2589.htm ------- Comment #1 From Bob Marinier 2008-06-15 14:40:43 (-) [reply] ------
Another library to consider is boost::date_time. This uses gettimeofday on
linux and ftime on windows. Both report real time and not process time.

I explored the effects of making the timers in the kernel itself header-
only
(to promote inlining). This made no difference in the times. However,
running
TestSoarPerformance with "timers --off" resulted in a 20% savings, which is
consistent with the earlier test. Running TestSMLPerformance with "timers
--off" resulted in a 6-8% savings, which shows that they have an impact
even
when the kernel isn't doing anything.

Given that timers appear to be inherently expensive to use, especially
process
timers, our best option may be to extend the timers command to give the
user
more control over which timers are enabled.

Currently, they can all be turned on or off. In my experience, people
often
use the kernel and total times reported by stats, but only look at the
phase
times if there is a problem. In the absence of a problem, the phase times
are
often lower than the resolution of the clock anyway, and thus don't report
meaningful data.

An improvement would be to allow kernel and total timers to be on, but all
other timers to be turned off. (Arguably, the flexibility to manipulate
individual timers would be useful, but it seems like this would rarely be
used). Furthermore, the stats command would report that a timer is off
rather
than report zero times in the table. Finally, the phase timers would be
off by
default (or at least many people would find value in turning them off).

We should still have a separate "header only" timers library that cam be
used
to get process or real time. This will increase consistency and fix
existing
bugs as noted above.

Original issue: http://code.google.com/p/soar/issues/detail?id=31

From [email protected] on July 23, 2009 00:08:26

Description From Andrew Nuxoll 2005-07-14 16:09:08 (-) [reply]
I'm told that right now, the print()/print_with_symbols() statements are
still
in the kernel code and that duplicate messages are sent to the debugger via
GenerateMessageXML/GenerateWarningXML/GenerateErrorXML/etc. I'm told that
I
should enter a bug report stating that in all of these places there should
only
be one function call that does both. So here it is.

Original issue: http://code.google.com/p/soar/issues/detail?id=6

From [email protected] on July 23, 2009 00:35:29

Description From Bob Marinier 2007-05-26 15:37:18 (-) [reply]
Currently, running Soar is a blocking call. Given the way we (at UM at
least)
typically design environments, Doug says it makes more sense for run to be
non-blocking. Dave Ray points out, however, that in some cases blocking is
better, and in the typical SoarTech case, running is asynchronous, so it
doesn't matter much.

This kind of change would break existing code, so the possibilities include
waiting until Soar9 (in which lots of stuff will break anyway), or to leave
existing stuff the way it is and just introduce new methods that are
non-blocking (so people have a choice). If it makes sense, the flexible
route
is probably best. I don't know if this interacts with the threading model
stuff (bug 1001) at all.

Original issue: http://code.google.com/p/soar/issues/detail?id=22

From [email protected] on July 23, 2009 01:00:34

Description From Bob Marinier 2008-07-02 15:28:15 (-) [reply]
According to stats, a run that does nothing but wait is spending most of
its
time in I/O callbacks. Here's a trace from TestCLI:

1 (raw) test> waitsnc --on
1 (raw) test> w 0
1 (raw) test> run 100000
1 (raw) test> stats
Soar 9.0.0 on dodo atWed Jul 02 15:20:49 2008

0 productions (0 default, 0 user, 0 chunks)

• 0 justifications
  | Computed
  Phases: Input Propose Decide Apply Output | Totals
  ========================================================|===========
  Kernel: 0.404 0.107 0.222 0.170 0.329 | 1.232
  ========================================================|===========
  Input fn: 0.206 | 0.206
  ========================================================|===========
  Outpt fn: 0.000 | 0.000
  ========================================================|===========
  Callbcks: 8.878 0.000 0.000 0.000 0.140 | 9.018
  ========================================================|===========
  Computed------------------------------------------------+-----------
  Totals: 9.488 0.107 0.222 0.170 0.469 | 10.456

Values from single timers:
Kernel CPU Time: 2.763 sec.
Total CPU Time: 12.953 sec.

100000 decisions (0.028 msec/decision)
0 elaboration cycles (0.000 ec's per dc, 0.000 msec/ec)
0 p-elaboration cycles (0.000 pe's per dc, 0.000 msec/pe)
0 production firings (0.000 pf's per ec, 0.000 msec/pf)
6 wme changes (6 additions, 0 removals)
WM size: 6 current, 6.000 mean, 6 maximum

We should investigate what's going on here and see if we can optimize it
(e.g.,
maybe SML is registered for kernel callbacks unnecessarily).

(It's possible that this is just a bug in stats or the timers, but the
total
time reported is about right based on a wallclock measurement).

Original issue: http://code.google.com/p/soar/issues/detail?id=36

From [email protected] on July 23, 2009 01:04:25

Description From Bob Marinier 2008-08-24 18:11:26 (-) [reply]
I ran TestCLI with valgrind (just started and quit without doing anything),
and
valgrind reports several "leaks" in the "still reachable" category and all
stemming from this line:

hLibrary = dlopen(newLibraryName.c_str(), RTLD_LAZY);

Basically, we never unload the library, and thus we get a bunch of "leaks".
If
I hack in some code to unload the library (by storing the handle on the
class
and then dlclose'ing the handle in CloseConnection) then most of the leaks
go
away. (It goes from 1052 bytes in 6 blocks to 20 bytes in 1 block).

There are other problems with dlopen which do not appear to be our fault.
For
example, we get the error described here: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/114032 ...the last comment of which suggests a workaround (although I don't know
how
to do what it suggests).

My concern here is not to waste time on issues that don't affect anyone,
but
rather to clean up valgrind's output so we can see any real errors as they
come
up. Perhaps we can get buildbot to automatically run valgrind and ignore
these
errors (so we only get failures on new errors).

Original issue: http://code.google.com/p/soar/issues/detail?id=39

From [email protected] on July 23, 2009 00:02:59

Description From Bob Marinier 2004-06-17 12:31:17 (-) [reply]
Consider these rules:

sp {propose
(state ^superstate nil)
-->
( ^operator +)
}

From [email protected] on July 23, 2009 00:33:37

Description From Bob Marinier 2007-05-26 11:53:31 (-) [reply]
Currently, a common coding pattern looks like this:

if(wme doesn't exist)
create wme
else
update wme

Doug suggested adding a method along the lines of CreateOrUpdateWME that
would
simplify this kind of code.

Original issue: http://code.google.com/p/soar/issues/detail?id=20

From [email protected] on July 22, 2009 23:56:47

Description From Bob Marinier 2004-06-03 09:44:04
The code which determines the support a match should get (in rete.c,
p_node_left_addition) processes each match separately, but stores the
determined support type for all matches in the same variable (prod_type).
Thus, whichever match's support type is determined last is the support type
that all of the matches get.

Ideally, this could be fixed by storing the support type for each match in
a
separate variable, or moving the code which pushes the matches onto the
ms_o_assertions or ms_i_assertions lists into the loop which processes the
matches, and push them on to the correct list one at a time. The problem
with
this approach is it seems all of the matches are stored in the same
structure,
msc. It isn't clear to me how or if they can be split up.

One might wonder, is it even possible for different matches to get
different
support? Yes, if there are states which are not connected in the
conditions.
Consider this example:

(state ^operator )
(state ^foo bar)
-->
( ^hello world)

If this gets two matches (->S1,->S2) and (->S2,->S1), the
first
one should get i-support and the second one should get o-support.

Perhaps this is considered a contrived example which shouldn't be allowed.
In
that case, an alternative is to redefine how o-support works so this isn't
possible. Then we could remove the loop which determines the support type
for
each match and just determine the support type of one of the matches (say
the
first one on the list) and use that to push all of the matches on the right
list.

Original issue: http://code.google.com/p/soar/issues/detail?id=2

From [email protected] on July 23, 2009 01:12:48

Description From Jonathan Voigt 2009-06-02 13:21:33 (-) [reply]
Consider the following) SML WMEs (with fictional time-tags):

(I2 ^foo F1: 1)
(I2 ^foo F2: 2)
(F1 ^bar F2: 3)
(F2 ^bar F1: 4)

If I2 is deleted (say, on agent destruction), WMEs 1, 2 are deleted fine
but 3,
4 are not.

Original issue: http://code.google.com/p/soar/issues/detail?id=47

From [email protected] on July 23, 2009 00:04:55

Description From Karen Coulter 2004-12-17 14:05:50 (-) [reply]
this functionality is either not general enough to be part of the supported
Soar
distribution, or needs Soar Consortium approval before being added.

-- "deepCopy" is a new RHS function that is deeply embedded in the kernel,
and is commented as a "HACK that should be doable through the external
kernel interface" It creates a copy of a wme, makes a fake pref, and
then
deallocates the wme, all in the matcher (create_instantiation) and also
adds references to objects. I haven't investigated the cost of this code,
but it has potential to be significant. I think this is the sort of change
that should go to the Soar Consortium if SoarTech wants it to stay in the
distribution. Certainly they can add it back in to their versions easily.

Nov 29: ==>> should go thru Consortium for sure. There may be other ways
to
implement this, and alternatives should be evaluated. Remove from kernel.

-- O_REJECTS_FIRST compiler directive added. I think we should ask
SoarTech whether they still use this or whether it was for some
experiments.
It doesn't cost anything since it's a compiler directive, but it is one
more
option to support and understand.

Nov 29: yep, we should take it out. check w/ SoarTech if even being used
regularly.

Original issue: http://code.google.com/p/soar/issues/detail?id=4

From [email protected] on July 23, 2009 00:14:32

Description From Jonathan Voigt 2006-02-09 13:18:50 (-) [reply]
Port as much documentation to the wiki as possible. Exceptions include the
Soar
Manual and tutorials.

Original issue: http://code.google.com/p/soar/issues/detail?id=10

From [email protected] on July 23, 2009 01:14:30

Many kernel data structures are still in 32 bits that could be 64 bits, such
as
the hash tables. These things need to be moved to 64 bits.

Original issue: http://code.google.com/p/soar/issues/detail?id=49

From [email protected] on July 23, 2009 01:05:47

Description From Sam Wintermute 2008-09-10 12:31:18 (-) [reply]
Soar has numeric tests for >,<,<=,>=, but not plain equality. This is
apparently because that should be handled by just matching values, but that
does not work when one number is internally an integer and the other is
internally a float. So, Soar can detect that 1 <= 1.0 and 1 >= 1.0, but 1
!=
1.0 as detected by matching.

There should be a operator for equality across ints and floats, or the
matcher
should do implicit conversions, since these types are hidden from the user,
and
for symmetry with the rest of the numeric tests. If this isn't done, the
manual
should be updated to note this when the comparison operators are discussed.

Original issue: http://code.google.com/p/soar/issues/detail?id=41

From [email protected] on July 23, 2009 01:12:01

Description From Joseph Xu 2009-01-28 18:21:53 (-) [reply]
Created an attachment (id=115) [details]
same test case as in comment

In python sml, it seems that calling ConvertToIdentifier() on an identifier
object returns an object that is not equal to the original object, as is
the
case in C++. Here's a test case:

import Python_sml_ClientInterface as sml

kernel = sml.Kernel.CreateKernelInCurrentThread(' SoarKernel SML', True)
agent = kernel.CreateAgent("soar1")

id1 = agent.CreateIdWME(agent.GetInputLink(), 'blah')
id2 = id1.ConvertToIdentifier()

print "id1:", id1
print "id2:", id2
print "id1 == id2:", id1 == id2

This program will print the following when run:

id1: <Python_sml_ClientInterface.Identifier; proxy of <Swig Object of type
'sml::Identifier *' at 0x86a02a0> >
id2: <Python_sml_ClientInterface.Identifier; proxy of <Swig Object of type
'sml::Identifier *' at 0x86a02a0> >
id1 == id2: False

Note that even though both objects are proxies of the same swig object
(same
address), they're still considered unequal. This is arguably unexpected and
undesirable behavior.

Attachment: test.py

Original issue: http://code.google.com/p/soar/issues/detail?id=46

From [email protected] on July 23, 2009 01:01:05

Description From Bob Marinier 2008-08-20 10:32:01 (-) [reply]
As per bug 1088, the RL documentation is currently not in the actual manual.
Eventually it should be.

Targeting for 9.0.1 just so we remember to discuss it (not because we'll
necessarily do it for that release).

Original issue: http://code.google.com/p/soar/issues/detail?id=37

From [email protected] on July 23, 2009 00:41:19

Description From Dave Ray 2007-08-15 12:53:10 (-) [reply]
It seems like the speed of a system can vary based on who initiates the run
command. To reproduce:

• Run TankSoar and create a new agent with obscure-bot.soar and no debugger
• Run the java debugger and connect it to the TankSoar kernel
• Run the agent from the TankSoar interface and note the rate of the watch
  1
  output printed in the debugger.
• Now stop the agent
• Run the agent from the debugger and note the rate of the watch 1 output
  printed.

When I do this test there is a noticeable decrease in speed when the agent
is
run from the debugger. I also occasionally sees great variation in speed
just
starting and stopping the agent repeatedly in the debugger.

Original issue: http://code.google.com/p/soar/issues/detail?id=24

From [email protected] on July 23, 2009 01:02:19

Description From Bob Marinier 2008-08-24 14:21:27 (-) [reply]
In o-support mode 4 (the default), support for a wme is determined like
this:

If a rule does not test a selected operator on the LHS, then all wmes it
creates get i-support. If a rule does test a selected operator on the LHS,
then all wmes it creates get o-support, unless the wmes it creates are on
the
operator itself, in which case they get i-support (because they are
elaborating
the operator).

There are a couple problems with this:

1. An operator elaboration only gets i-support if it is directly on the
   operator. Substructure further down does not get i-support. This often
   leads
   to rules that have mixed support (and which should then default to i-
   support),
   like this:

sp {mixed-support
(state ^operator )
-->
( ^i-supported.o-supported mixed)
}

From [email protected] on July 23, 2009 00:09:52

Description From Karen Coulter 2005-08-19 22:38:34 (-) [reply]
Impacts SoarKernel , gSKI and CLI.

now that Soar has been fixed so that ref cts on the top-level are no longer
necessary, memory is no longer leaked on the top state. But once Soar
allocates
memory, it never gives it back to the OS. Therefore when returning from
subgoals and even after init-soar, Soar hangs on to memory blocks that it
may
never need again. Propose changes to allow:

1. --memory flag on init-soar that would release unused blocks from mem
   pools.
2. "memory" user interface command that could release unused blocks from
   mem
   pools whenever Soar agent isn't running. Also could provide the same info
   as
   "stats -m" output (but we shouldn't deprecate that arg from "stats" either)

Original issue: http://code.google.com/p/soar/issues/detail?id=7

From [email protected] on July 23, 2009 01:07:04

Description From Sam Wintermute 2008-12-12 10:03:42 (-) [reply]
I'd ideally like to be able to re-use learned RL template instantiations
between runs, where I might restart the whole kernel (not just init-soar).
This
isn't easy to do, since templates will get instantiated once the first time
they match at each run, Soar can't tell that there is already a version of
the
needed instantiation from a previous run.

There seems to be two reasons behind this:
Soar's duplicate production detection isn't perfect, so all initial
instantiations (= 0) are duplicated every time. Here are two actual
productions
I got that are really the same, after the first was transferred by printing
it
and sourcing it in a new kernel:

sp {rl_blocks-world_template_1
(state ^superstate nil ^named-on ^named-on ^named-on

^named-on ^operator +)
( ^bottom |blockC| ^top |blockD|)
( ^bottom point2 ^top |blockC|)
( ^bottom |blockA| ^top |blockB|)
( ^bottom point1 ^top |blockA|)
( ^target point1 ^moving |blockD| ^name move)
-->
( ^operator = 0)
}
sp {rl_blocks-world_template_34
(state ^superstate nil ^named-on ^named-on ^named-on

^named-on ^operator +)
( ^bottom point1 ^top |blockA|)
( ^bottom |blockA| ^top |blockB|)
( ^bottom point2 ^top |blockC|)
( ^bottom |blockC| ^top |blockD|)
( ^target point1 ^moving |blockD| ^name move)
-->
( ^operator = 0)
}

So something in the printing/sourcing/instantiation process is rewriting
things
in such a way that duplicates can't be detected.

The other reason this won't work is that an instantiation that has been
modified by RL to change the value can coexist with an = 0 new
instantiation,
since they really are different rules. Even if the reordering thing were
fixed,
this would still be a problem.

So templates need to be a bit smarter if they can be used across kernel
instances. Might be hard to fix, but at least the manual should mention
something about avoiding this.

Original issue: http://code.google.com/p/soar/issues/detail?id=43

From [email protected] on July 23, 2009 00:49:23

Description From Sam Wintermute 2007-12-04 16:38:16 (-) [reply]
I'm starting to run into problems with running multiple Soar kernels on the
same computer. Specifically, most applications use SML's default port
(12121),
and the listener thread will shut down if that port is in use. This is a
problem when running multiple instances of applications with local Soar
kernels
(eg, TL and SVI), they need to be able to generate unique port numbers at
run
time if remote connections will be possible (necessary for SVI, nice to
have
for TL).

It seems like the way to implement this would be to have an option when
creating a kernel through SML to get a unique port number, which could then
be
returned and passed to other parts of the program as necessary / printed
out
for the user. Maybe a good option would be to use 12121 by default (since
that
is what people are used to), and pick another randomly if that is in use.
It
looks like ports 49152 to 65535 are typically used for this purpose: http://en.wikipedia.org/wiki/Ephemeral_port ------- Comment #1 From Dave Ray 2007-12-04 16:54:50 (-) [reply] -------
I don't know what the SML code will do with this, but if you set the
sin_port
parameter in the address structure passed to bind() when setting up the
server
socket, a free port will be automatically assigned
( http://everything2.com/index.pl?node=bind()) . No need for random or
anything.
It may just be a matter of setting SML's port to zero and then retrieving
the
port and printing it out or something.

The final port can be retrieved with the getsockname() function:

...
struct sockaddr_in addr;
addr.sin_port = 0;
... bind, etc ...

getsockname(sock, (struct sockaddr *)&addr, &len);

int port = ntohs(addr.sin_port);

Looking at the code, it looks like SML might let zero through for the port,
but
it would be tough to figure out which port was actually chosen.

Original issue: http://code.google.com/p/soar/issues/detail?id=27

From [email protected] on July 23, 2009 00:19:10

Description From Bob Marinier 2006-03-29 16:32:15 (-) [reply]

1. Start TestCLI
2. source toh
3. w 5
4. w --fullwmes
5. run

Around dc 2 we segfault with the following error message:

Internal Soar Error: symbol_to_string called on bad symbol
Soar cannot recover from this error.
You will have to restart Soar to run an agent.
Data is still available for inspection, but may be corrupt.
If a log was open, it has been closed for safety.Internal Soar Error:
symbol_to
_string called on bad symbol
Soar cannot recover from this error.
You will have to restart Soar to run an agent.
Data is still available for inspection, but may be corrupt.
If a log was open, it has been closed for safety.

Note that this was originally encountered in Java TankSoar so it's not
specific
to TestCLI.

This works fine in 8.5.2.

Original issue: http://code.google.com/p/soar/issues/detail?id=12

Skipping this issue number to maintain synchronization with Google Code issue IDs.

_Original issue: http://code.google.com/p/soar/issues/detail?id=14 _

From [email protected] on July 23, 2009 00:50:47

Description From Bob Marinier 2008-02-28 11:29:13 (-) [reply]
Sometimes I find myself with a large group of productions that I want to
easily
enable or disable. I could add a flag to the top state and change every
production to test this flag, but this is a pain (and error prone, if I
mistype
something). A much easier solution would be to incorporate #define-like
syntax
in Soar, so entire blocks of code can be included or excluded easily.

Syntax: Since # already has a meaning, we should probably use something
else,
e.g., just the words define, ifdef, ifndef, and endif. (Note that I am not
arguing for a fully functional macro language like C/C++; I just want to be
able to easily flag which blocks of code to use). Here's a possible
example:

define DEBUG

ifdef DEBUG
sp {monitor*....
...
endif

Implementation: There are at least two ways I can see implementing this: in
the
kernel, as a new syntax, or as commands (in which case they would be part
of
commandline interface). I favor the command approach for simplicity
(changing
Soar's parser is probably hard). Basically, the define command will keep a
list of constants that have been defined, and the ifdef/ifndef commands
will
set CLI switches (if the test fails, ignore all commands until endif is
reached; otherwise execute commands as usual). I suppose the switch could
be
set in the parser directly, but telling CLI to ignore commands is probably
simpler.

Also, these do not have to all be separate commands. There can be just one
command, e.g. define, with arguments to do all this, and the rest can just
be
aliases.

One source of confusion for C/C++ programmers may be the fact that, in
Soar,

define FOO actually does NOT define FOO, since the line is commented out.

But
I think they'll get used to it (the alternative is to add special-case
processing to code to recognize the difference between a comment and a
define,
and that sounds like a buggy situation).

There are some issues like, will we support nesting, or logical tests of
flags?
I say we start simple, and see what people really want as far as more
complex
features go.

Incidentally, this approach also gives Soar the ability to block-comment
code,
e.g.:

ifdef COMMENT #COMMENT is not define'd anywhere
...
endif

...which is something I've wanted for a long time.

Original issue: http://code.google.com/p/soar/issues/detail?id=28

From [email protected] on July 23, 2009 00:22:00

Description From Bob Marinier 2006-04-25 13:15:29 (-) [reply]
In bug 709, the problem was that a callback could still be executing when
the
kernel was deleted, causing a crash. In that case, the debugger was
crashing,
so the fix was to make the debugger wait 1 second between the time it
shutdown
the kernel and the time it was deleted. This gives callbacks a chance to
finish.

However, this solution is not general. Each client that has a similar
problem
will have to separately implement a similar fix. We expect such clients to
be
rare, so we have not yet created a universal solution -- that's what this
bug is
about.

Doug proposed creating a ShutDownWithDelayedDelete method. However, some
languages (like C++) do not delete the kernel on ShutDown, so maybe a
better
solution is ShutDownWithDelay, which in Java would still delete the kernel
(after a delay) and in C++ would just delay the return of the function call
(so
the kernel can't be deleted too quickly). Regardless, the solution is just
to
move the delay into an SML method.

Original issue: http://code.google.com/p/soar/issues/detail?id=13

From [email protected] on July 23, 2009 01:13:38

Description From Nick Gorski 2009-06-22 13:22:31 (-) [reply]
Mac people at the tutorial noticed there is no script to launch the TOH demo
(s/b named run-toh.sh I think).

Original issue: http://code.google.com/p/soar/issues/detail?id=48

From [email protected] on July 23, 2009 00:30:02

Description From Bob Marinier 2006-08-25 11:08:47 (-) [reply]
With the addition of numeric indifferent preferences, it can be difficult
for
the user to tell just how likely it is that various operators will get
selected. For example, when I run prefs with my code, I get something like
this:

acceptables:
O3 (attend) +
O4 (attend) +
O5 (attend) +
O6 (attend) +
O1 (task) +

rejects:
O6 (attend) -
O3 (attend) -

worsts:
O1 (task) <

binary indifferents:
O4 (attend) =50
O5 (attend) =50
O5 (attend) =25
O6 (attend) =O3 (attend)
O5 (attend) =O3 (attend)
O4 (attend) =O3 (attend)
O3 (attend) =O6 (attend)
O3 (attend) =O5 (attend)
O3 (attend) =O4 (attend)
O6 (attend) =O4 (attend)
O5 (attend) =O4 (attend)
O4 (attend) =O6 (attend)
O4 (attend) =O5 (attend)
O6 (attend) =O5 (attend)
O5 (attend) =50
O5 (attend) =O6 (attend)

It's very hard to tell from this what the probabilities are, especially
since
I'm using numeric-indifferent-mode --sum.

It would be nice if the preferences command could be extended to report
these
probabilities. It could either list them separately at the end, or on the
same
line with each acceptable preference. If listed separately, only those
operators with non-zero probability need be listed.

Here's what a separate listing might look like (based on the above
preferences;
calculations are rough estimates based on my understanding of how it
works):

selection probabilities:
O4 (attend) 5.2%
O5 (attend) 94.8%

If listed with the acceptables, it might look like this:

acceptables:
O3 (attend) + (0%)
O4 (attend) + (5.2%)
O5 (attend) + (94.8%)
O6 (attend) + (0%)
O1 (task) + (0%)

Original issue: http://code.google.com/p/soar/issues/detail?id=18

From [email protected] on July 23, 2009 00:39:12

Description From Dave Ray 2007-08-15 11:44:36 (-) [reply]
Steps to reproduce:

• Run TankSoar and create a new tank with obscure-bot.soar and no debugger
• Hit run to start the TankSoar sim
• Run the java debugger and connect to the running kernel in TankSoar.
• The debugger will freeze until TankSoar is stopped from the TankSoar
  interface.

This is a problem if you have Soar embedded in a free-running program
without
start and stop controls. The debugger should be able to connect to a
running
kernel and inspect the agents as they run without freezing.

Original issue: http://code.google.com/p/soar/issues/detail?id=23

From [email protected] on July 23, 2009 00:58:54

Description From Jonathan Voigt 2008-06-19 17:40:54 (-) [reply]
sysparam modifications should fire an event. The event is fired if the
KernelHelpers method for modifying sysparams is used, but not necessarily if
sysparams are modified outside of that function.

Original issue: http://code.google.com/p/soar/issues/detail?id=34

From [email protected] on July 23, 2009 00:26:32

Description From Bob Marinier 2006-05-12 09:26:15 (-) [reply]
It would be useful to have a rand command for generating random numbers for
at
least two reasons:

1. It allows applications to use the same random number generator as Soar,
   which
   will make creating deterministic runs easier (since seeding only needs to
   be
   done in one place). This kind of feature is also mentioned in bug 776.

2. It allows productions to call rand on the RHS (which I at least would
   find
   useful).

The reason to make rand a command line command as opposed to just an SML
function is to support the second case (and thus kill two birds with one
stone),
although certainly an SML wrapper function could be provided.

As for what the command would look like, I imagine something like this:

rand : returns a real number in [0,1](calls SoarRand%28%29)
rand n : returns a real number in [0,n](calls SoarRand%28max%29)
rand --integer : returns an integer in [0,2^32-1](calls SoarRandInt)
rand --integer n : returns an integer in [0,n], n<2^32 (calls
SoarRandInt(max))

One possible issue is that some of these return reals and some return ints.
I'm
not sure what the range on integer representation is for doubles, but we
may be
able to use doubles for both. Alternatively, we may be able to return them
as
strings, and require the user (or wrapper functions) to convert them.
Finally,
we could provide two different commands: rand and rand-int.

Original issue: http://code.google.com/p/soar/issues/detail?id=16

From [email protected] on July 23, 2009 00:34:30

What steps will reproduce the problem? 1. 2. 3. What is the expected output? What do you see instead? Please use labels and text to provide additional information.

Original issue: http://code.google.com/p/soar/issues/detail?id=21

From [email protected] on July 23, 2009 00:44:04

Description From Bob Marinier 2007-09-14 14:57:57 (-) [reply]
Created an attachment (id=93) [details]
Code from Laird that uses up memory until crash.

1. Source the attached code
2. w 0
3. run 100000

Note two things:

• memory usage grows over time
• it takes a while to exit, but there are no unexpected leaks when it does
  so

What's happening is the code generates justifications which immediately
retract. However, the justification instantiation is not deallocated, and
this
leaves an extra reference count on the justification production, which then
also does not get deallocated.

Here's what happens in more detail

1. Justification is created with ref count = 1
2. Instantiation of justification is created, which increases ref count to
   2
3. Instantiation is retracted. During this, the justification is excised,
   which brings the ref count back down to 1.
4. The function possibly_deallocate_instantiation is called. This checks
   if
   inst->in_ms is 0 (it is) and inst->preferences_generated is 0 (it is not).
   Since this check fails, the instantiation is not deallocated, and thus the
   reference count on the justification production never goes to zero.

What is preferences_generated?

From comments in the code:

preferences_generated: header for a doubly-linked list of existing
preferences that were created by this instantiation.
...
Reference counts on instantiations:
+1 if it's in the match set
+1 for each preference it created that's still around
The reference count is kept implicitly using the preferences_generated
and in_ms fields. We deallocate an instantiation if its reference count
goes to 0.

So where are these preferences coming from? They appear to get generated
by
the function make_clones_of_results. The comments there say:

                   Make Clones of Results

When we build the initial instantiation of the new chunk, we have
to fill in preferences_generated with copies of all the result
preferences. These copies are clones of the results. This routine
makes these clones and fills in chunk_inst->preferences_generated.

This is where I'm getting stuck -- I don't understand why things are
getting
cloned, and why they aren't going away later.

Any ideas?

Original issue: http://code.google.com/p/soar/issues/detail?id=25

Skipping this issue number to maintain synchronization with Google Code issue IDs.

_Original issue: http://code.google.com/p/soar/issues/detail?id=138 _

From [email protected] on July 23, 2009 00:52:05

Description From Bob Marinier 2008-03-12 13:11:03 (-) [reply]
Dave Ray found and fixed a bug relating to strings not being properly freed
in
JNI code for RHS function stuff (see bug 1031). There's a very good chance
that there are other similar bugs elsewhere in the JNI code, and possibly
related bugs in other languages.

I can imagine checking for this occurring in two stages:

1. Find similar patterns in JavaCallbackByHand.h (rev 8396) similar to the
   ones
   Dave fixed and fix them. (Looking at the diff, it actually looks like Dave
   made changes throughout the file, so perhaps he's already done this).

2. Port Dave's Java test program (attached to bug 1031) to other languages
   and
   see if they show similar problems (C# in particular, since it is most
   similar
   to Java).

Original issue: http://code.google.com/p/soar/issues/detail?id=29

From [email protected] on July 23, 2009 01:04:59

Description From Sam Wintermute 2008-08-25 16:54:46 (-) [reply]
The -layout option for the SoarJavaDebugger currently looks in the .SoarFiles
directory for the specified file, so absolute paths don't work. In addition,
the provided layout file is automatically overwritten on exit if a different
layout is loaded.

Original issue: http://code.google.com/p/soar/issues/detail?id=40

From [email protected] on July 23, 2009 00:25:14

Description From Bob Marinier 2006-05-09 16:48:45 (-) [reply]
Starting with ActiveTcl 8.4.11.2, all Tcl packages are built with threading
enabled (although the core itself is supposedly not built this way). This
seems
to cause some problems with FilterTcl, since events are coming in on a
different
thread.

Uncommenting the calls to the Tcl threaded stuff in the SWIG file seems to
mostly fix the issues. The remaining problem is that some callbacks
(including
the one that FilterTcl uses) need to return information, but that
information is
being generated from another thread, so we need to block until it is
available.

Original issue: http://code.google.com/p/soar/issues/detail?id=15

From [email protected] on July 23, 2009 01:06:22

Description From Bob Marinier 2008-09-27 17:09:37 (-) [reply]
If I type the following:

select o7

...it will fail even if there is an operator O7 available. This appears to
be a
case sensitivity issue. Since most Soar programmers are lazy, this should
be
made case insensitive (an identifier letter can never be lower case, so
this
shouldn't cause any ambiguity).

Additionally, if I accidentally type:

select 07

(note that's a zero), I don't get any error until the operator is actually
selected. Something should check that the input is actually a legal
identifier
(a letter followed by a number). Additionally, perhaps we can check against
the
list of currently proposed operators (available from the preferences
command)
and print a warning if the selected operator is not yet proposed (this
shouldn't necessarily be an error since someone may know what legal
operators
will be when the decision phase comes, so we shouldn't force them to have
to
run select at exactly the right time). Finally, I think this check should
be
separate from the legal identifier check because one is an error and the
other
is just a warning.

Original issue: http://code.google.com/p/soar/issues/detail?id=42

From [email protected] on July 22, 2009 21:54:01

The user should be able to set a variable specifying a maximum number of
partial matches for a single production. If the kernel has too many of these
then it will abort processing and ask the user what to do about it (e.g.,
continue/abort/debug).

Original issue: http://code.google.com/p/soar/issues/detail?id=1

From [email protected] on July 23, 2009 00:53:35

Description From Bob Marinier 2008-05-08 21:07:20 (-) [reply]
We implemented several new widgets in the debugger that are driven by RHS
functions. When the widget is created (e.g., when the debugger layout is
loaded), it automatically registers the RHS function specified in its
properties.

The problem occurs when you create a second agent. The debugger
automatically
creates a second window, which contains a second instance of the widget,
which
tries to register for the RHS function again. This fails with an error
message.

I think the right thing to do is to register the RHS function once in the
debugger, and then route incoming calls to the proper widget based on the
agent
it's coming from (the agent object is passed into the RHS function
callback).
Thus, the RHS function callback is primarily a router that keeps track of
which
agents have windows, and routing changes appropriately. If a window is
closed,
then that agent is removed from the routing table, etc.

Note that we can't expect people to actually use these widgets until this
is
fixed.

Original issue: http://code.google.com/p/soar/issues/detail?id=30

From [email protected] on July 23, 2009 00:47:52

Description From Bob Marinier 2007-10-28 13:28:47 (-) [reply]
When calling RHS functions, generally you would use either "cmd" (for
calling
Soar commands) or exec (for calling custom RHS functions). "cmd"
automatically
puts spaces between the arguments, but exec does not (because people might
want
to concatenate the args).

Dave Ray makes two points about exec: concatenating arguments is definitely
the
less common case, and there is already a concat RHS function that does this
explicitly. I didn't even know there was a concat function (it's not
documented; looking at the code, it appears to have been added by gSKI).

Changing exec now would be bad for compatibility reasons, so Dave and I
agree
that the best option is to introduce a new exec-like function that
automatically puts the spaces between the args (this should result in
cleaner
Soar code, too). Dave suggests that, "in the great Unix tradition", this
function be called execv.

Original issue: http://code.google.com/p/soar/issues/detail?id=26

From [email protected] on July 23, 2009 01:09:09

Description From Jonathan Voigt 2009-01-08 10:48:44 (-) [reply]
From Bob's email, verbatim:

I've been working on my emo2 branch, which is up-to-date with the latest
changes from the trunk. It works well most of the time, but when I try to
run
my thesis system with the DEBUG_MEMORY #define turned on (which clears
memory
returned to the pools), I get a crash under the following conditions:

• this message appears in the trace: "inner elaboration loop finished but
  not
  at quiescence."
• the system is trying to assert a preference for this rule:

sp {apply_operator_remove-command
(state ^operator.actions
^io.output-link

)
(
^ )
( ^status complete)
-->
(
^ -)}

Stepping through the code, what appears to happen is this preference (among
others) gets put on thisAgent->newly_created_instantiations during
create_instantiation, as does justification-11 (during
chunk_instantiation),
the justification associated with the above rule. Going into
assert_new_preferences, the preference for justification-11 is at the head
of
the newly_created_instantiations list.

assert_new_preferences does a two-pass algorithm: first it goes through the
newly_created_instantiations list and puts any reject preferences
associated
with these instantiations on an o_rejects list (the instantiations are
still on
the newly_created_instantiations list). These preferences are then
processed,
which possibly includes deallocating them. When a preference is
deallocated,
the associated instantiation may also be deallocated.

Next, the items on the newly_created_instantiations list are processed, and
this is where we get a crash. It appears that the instance associated with
justification-11 got deallocated, and thus the head of the
newly_created_instantiations list is bad. The code apparently expects the
o_reject stuff to still be in this list, since it checks for them and
ignores
them (presumably since they've already been processed).

Interestingly, if I turn off DEBUG_MEMORY, then it's the instance
associated
with the rule that is at the head of the list instead of the justification.
This appears to be a side effect of the deallocation (the address changes
in
free_with_pool).

Anyway, it's amazing this works at all. I'm not sure if the instance is
supposed to be deallocated or not, but maybe it makes sense, since the
instance
only has one pref (to remove something), and it's already been processed,
so we
don't need the instance anymore. In that case, perhaps the right fix is to
splice any instances we deallocate out of the newly_created_instantiations
list
(although that seems inefficient, as we have to find it in the list first,
if
it's even there). Another possibility is to delay deallocating the
preferences
until after all of the instances have been processed. This would mean doing
a
third pass (albeit just over the o_rejects list).

As this last approach is the simplest, I tried it and it seems to fix the
crash. Unfortunately, it also appears to break init-soar (lots of leaked
ids
reported, even in the water-jug demo, which doesn't have any
justifications).

Finally, I don't know how to reproduce the crash in a simple example. It's
possible it's related to the new waterfall changes somehow. Finally, I
can't
guarantee it isn't related to my emotion code, since I can't run my system
outside of my branch. I'm not sure what next steps to take.

Original issue: http://code.google.com/p/soar/issues/detail?id=45

From [email protected] on July 23, 2009 00:10:59

Description From Bob Marinier 2006-01-26 10:00:31 (-) [reply]
It seems clear that one of the reasons people get burned by the GDS is
because
they don't even know it exists, much less the constraints it places on good
programming practices. This is because the only mention of it in the
manual is
in an appendix, and there is no tutorial on it.

I think it would be a good idea to add a short tutorial on th GDS to the
current
tutorials. It could be based on a simple counting example to demonstrate
the
potential pitfalls and how to debug problems when you run into them. Karen
also
suggested doing something with the water-jug-look-ahead code, since it's a
good
example of why one would want to create o-supported structures in substates
and
how to properly do it.

It would be great if this tutorial was written in time for the Soar
workshop,
since then we could give an advanced tutorial on it.

Original issue: http://code.google.com/p/soar/issues/detail?id=8

From [email protected] on July 23, 2009 01:07:42

Description From Bob Marinier 2008-12-16 16:40:37 (-) [reply]
To reproduce:

0. Start with a debug or debug scu build.
1. Open two command prompt windows in the SoarLibrary/bin directory.
2. In the first one, do "java -jar SoarJavaDebugger .jar".
3. In the second one, do "java -jar SoarJavaDebugger .jar -remote".
4. Close the first debugger. This should close both debugger windows
   (unless
   you've changed the default debugger settings).

Tons of memory leaks are reported by the second debugger (the first has
none).
Many of them appear to be related to ElementXML.

Note that, to debug leaks in Java, you can set a memory leak breakpoint
near
the bottom of sml_ClientInterface.i (in the Resources Files folder of the
ClientSMLJava project in Visual Studio). But this probably has nothing to
do
with Java, so it might be worth the effort to reproduce it in C++.

Original issue: http://code.google.com/p/soar/issues/detail?id=44

From [email protected] on July 23, 2009 00:58:04

Description From Bob Marinier 2008-06-13 13:55:07 (-) [reply]
Some of the constants contained in sml::sml_Names (sml_Names.h in
ConnectionSML) are redundant with constants contained in soar_TraceNames
(soar_TraceNames.h in shared). These should be removed from sml_Names in
order
for it to be clear which constants are used by the kernel vs. the ones used
exclusively by SML.

Original issue: http://code.google.com/p/soar/issues/detail?id=33

From [email protected] on July 23, 2009 00:27:55

Description From Bob Marinier 2006-05-22 11:05:58 (-) [reply]

1. Start debugger
2. Load TOH
3. run
4. While running, right-click in trace window. Leave context menu up while
   Soar runs.
5. When TOH completes, click somewhere to remove context menu.

Notice that the message "An agent halted during the run." doesn't get printed
until after the context menu is removed.

Original issue: http://code.google.com/p/soar/issues/detail?id=17