Add new RHS size function

[rezamini]

This Pull Request proposes the addition of a new RHS "size" function. The new function is based on the description provided in the Soar Manual documentation (3.3.6.6 Right-hand side Functions, page 79), and is designed to return an integer value representing the count of WME augmentations on a given ID argument. However as stated, it is important to note that providing a non-ID argument to the function will result in an error, indicating that the function is intended to be used specifically for counting WME augmentations on ID arguments.

The jsoar version of the codebase currently does not have this function implemented, and the proposed function will be a valuable addition to the codebase. It will provide developers with an easy and efficient way to count WME augmentations on ID arguments. The changes are backward-compatible and have no impact on the existing functionality of the codebase.

The proposed changes have been tested, and a test file has been included to verify the correct implementation of the new RHS size function.

[marinier]

Thank you very much for this contribution! I will take a look and merge when I get a chance, which may not be until the weekend or next week.

[rezamini]

Thank you for your response. I'm glad to hear that you will take a look at the Pull Request, and I appreciate your willingness to merge it into the main branch when you have the chance. If you have any questions or concerns about the changes, please let me know.

Additionally, I would be happy to help with any future contributions to add/port other RHS functions or other parts of the architecture. if there are any other parts of the architecture that could benefit from my contributions, please don't hesitate to let me know. I will do my best to make the time :)

[marinier]

Code looks good! Merged.

Depending on what you're looking to do, there are a lot of possibilities at varying levels of effort:

Small (1's of hours)

• Lots of missing args from various commands. E.g., print -v would be nice to have. While I've put these in the small category, the size actually varies a lot depending on what it is.
• Unit tests to cover more code. The goal isn't to get to 100% coverage or anything, but there are a lot of places that have no tests at all (e.g., many commands). This may include porting some tests from CSoar.
• Missing RHS functions.

Medium (10's of hours)

• Missing commands. gp in particular is sorely missed by some, but note that the syntax interferes with the use of Tcl. May require a syntax change to port it.
• Complete the stats command output. JSoar has only a subset of the stats reported by CSoar. This may require adding additional timers and counters in various places in the code.

Large (100's of hours)

• Update chunking. Personally I don't have much use for chunking, but unlike many of the memories it is invasive throughout the code, and updating anything else major will inevitably be difficult chunking changes will affect it in some way.
• Port SVS. My understanding is that while this is a lot of code (11k lines?), it's "easy" code that should be straightforward.
• Update smem
• Update epmem (low priority for me as I don't use it)
• Update RL
• Update working memory activation (low priority for me as I don't use it)
• Replace jTcl with normal C Tcl. This would require packaging the binaries for various platforms inside the jar and extracting them and binding to them at runtime (similar to what sqlite does). This would eliminate a major unmaintained dependency.
• Reimplement the jsoar debugger in JavaFX. I would ditch the docking frames support as it's rarely taken advantage of and there aren't great maintained libraries for it in JavaFX. This would eliminate a major unmaintained dependency (docking frames) and modernize the debugger.

Unfortunately, many of these are somewhat intertwined, especially at the medium/large level, so it may be hard to port one thing completely without touching other stuff, too. Additionally, in my experience the initial port of something goes quickly, and then it takes forever to get all the bugs out. For example, I probably did the initial port of working memory activation in ~2 hours, and then spent 20 hours trying to find the one typo I made that sometimes caused the activation numbers to come out wrong.

[rezamini]

Thank you very much for merging the PR. I'm glad that I could contribute to the project. :)

I appreciate the list of changes you provided and will review them to see if there are any that I can contribute to. I'll make a new pull request when I have something ready.