cst-group / cst Goto Github PK

The Memory class has no setName and, while this is partially solved by the MemoryObject class method setType, the lack of a standard name may bring trouble when dealing with both classes and/or casting.

Swing problems

Some tests involving javax.swing classes, like ObjectViewerTest, run indefinitely as they don't pass the point that window should be visible (setVisible(true)). A deeper analysis showed that those tests stay in an infinite loop at sun.misc.Unsafe.park method, a "wait-like" method that is system-dependant (thus, unsafe).

Strangely, other tests like AbstractObjectEditorTest show no issue.

Those errors were seen in a system with the following configurations:

OS

Distributor ID: Ubuntu
Description: Ubuntu 20.04.3 LTS
Release: 20.04
Codename: focal

Java version

openjdk version "1.8.0_292"
OpenJDK Runtime Environment (build 1.8.0_292-8u292-b10-0ubuntu1~20.04-b10)
OpenJDK 64-Bit Server VM (build 25.292-b10, mixed mode)

Also, those tests passed in an ubuntu 18.04 with the same version of openjdk, but a different build (build 1.8.0_252-b09)

• Hoje, apesar de na estrutura conceitual do OWRL termos os conceitos de Episode e Scene, esses conceitos não estão materializados de fato no CST. Precisaríamos de fato criar classes para esses conceitos de tal forma a permitir seu uso no System 2.
• Particularmente, o suporte que damos ao OWRL no CST se limita aos AbstractObjects e seus derivados. Me preocupa o fato de que não damos suporte a coisas que os WMEs no SOAR possuem, por exemplo a possibilidade de relações entre objetos, que hoje não são suportadas adequadamente no OWRL.
• O ideal seria fazermos um brainstorm para repensar o OWRL como instrumento de representação do conhecimento e compará-lo aos WMEs no SOAR ou os chunks no ACT-R ... e talvez até mesmo às estruturas de dados do OpenCog (que eu não conheço direito). Talvez incluir as representações vetoriais que o Wander anda estudando como uma modalidade de representação no OWRL.

The method processInputLink(Idea il, Identifier id) on SOARPlugin class doesn't take Idea value field, which results in a wrong WME tree building and soar processing.

On a test using smartCar.soar rules, the input link was built as follows:

"(I2,CURRENT_PERCEPTION,W1)\n" +
" (W1,CONFIGURATION,W2)\n" +
" (W2,TRAFFIC_LIGHT,W4)\n" +
" (W4,CURRENT_PHASE,W5)\n" +
" (W5,PHASE,W6)\n" +
" (W2,SMARTCAR_INFO,W3)\n";

But a value (RED) was expected on PHASE.

As JSoarCodelet runs, an error sometimes appears:

java.lang.IllegalArgumentException: Comparison method violates its general contract!

Please further investigate and fix it.

It's possible to a code inadvertently (or on purpose) to completely break a running Codelet by using the method getOutput(String type, int index). If someone tries to access an index greater than the size of the outputs, it will change the enable field to false and increment enable_count. As the Codelet tries to run again it will raise an exception, but there is no place where the entity revert to its original state, preventing the Codelet from running indefinitely.

On the method ** public void registerCodelet(Codelet co, String groupName)**, the Mind class gives no Exception or warning message if someone tries to insert a Codelet with a non-existing group. The codelet is inserted, but the group adding is ignored. Consider implementing the creation of a group with the given groupName.

RawMemory method shutdown() raises a UnsupportedOperationException

Sequential getI() calls to a MemoryContainer returns different Objects even if the evaluations have not changed.
Multiples memories have the same value, therefore a random one is selected to be returned when getI() is called, but the random selection occurs every call, even if the evaluation values stayed the same between calls.

Method getAllOfType on RawMemory class raise a NullPointerException if at least one **Memory ** on the internal list has a Null name.

consider refactoring MemoryBuffer methods (like put and putList) to accept Memory instead of MemoryObject

The following exception is being thrown while executing tests and showing the STDOUT:

br.unicamp.cst.core.exceptions.MemoryObjectNotFoundException: This Codelet could not find a memory object it needs: Disconnected Codelet
	at br.unicamp.cst.core.entities.Codelet$CodeletTimerTask.run(Codelet.java:795)
	at java.util.TimerThread.mainLoop(Timer.java:555)
	at java.util.TimerThread.run(Timer.java:505)
br.unicamp.cst.core.exceptions.MemoryObjectNotFoundException: This Codelet could not find a memory object it needs: Disconnected Codelet
	at br.unicamp.cst.core.entities.Codelet$CodeletTimerTask.run(Codelet.java:795)
	at java.util.TimerThread.mainLoop(Timer.java:555)
	at java.util.TimerThread.run(Timer.java:505)
br.unicamp.cst.core.exceptions.MemoryObjectNotFoundException: This Codelet could not find a memory object it needs: Disconnected Codelet
	at br.unicamp.cst.core.entities.Codelet$CodeletTimerTask.run(Codelet.java:795)
	at java.util.TimerThread.mainLoop(Timer.java:555)

These messages continue for a long time. The interesting thing is that the actual code of the br.unicamp.cst.core.entities.DisconnectedCodeletTest should be preventing this exception being raised:

try {
			disconnectedCodelet.getInput("TYPE", 0);
		}catch(Exception e) {
			assertEquals(e.getMessage(), "This Codelet could not find a memory object it needs: Disconnected Codelet");
		}

Implement new class CodeletContainer which implements the Memory interface and has the structure depicted below: