Limiting the size of the MainWindow text to allow NARS to run longer

[Jeff Thompson]

MainWindow.post does not limit the amount of text appended to ioText,
which can cause a problem if NARS runs for a long time. I've already
seen the GUI get sluggish from this. A temporary fix would be to
automatically change the Reporting Silence Level if the display text
becomes large. A long-term fix would be: if the display text becomes too
large, pause NARS and prompt the user to open a Save Experience file.
After this, the display text would be treated as FIFO, limited in size
as needed to keep the GUI responsive. Any thoughts?

[S H]

Instead of a TextArea, a JList with a JListModel and JListCellRenderer,
may be more efficient:

* http://java.sun.com/docs/books/tutorial/uiswing/components/list.html
* http://java.sun.com/docs/books/tutorial/ui/features/components.html
(visual gallery of Swing components)

Some of NARS output is sequential objects, so rather than appending
strings to a TextArea, appending a *message object* to a list. (This
could save memory if the message object's size is less than its expanded
string equivalent.)

ListCellRenderer can, depending on the content of a message object, can
adjust the font color, add an icon, or display multiple JLabel lines
(ex: title, sub-title). Buttons outside of the JList can adjust the
ListCellRenderer's parameters, like +/- sizing for more or less visible.

Some of these message objects might package the equivalent of several
TextArea "lines", such as a list of statements. Then these lists of
statements can be displayed / accessed by one GUI component. Certain
message objects could be tagged with a "reason" or "quality" of why they
were generated, affecting the color, font, icon, etc...

One disadvantage, though, is not being able to copy/paste like the
TextArea allows. Though you could generate the TextArea text from a
list of messages ex: concatenating their toString(), and the
concatenation could occur on a certain filtered subset of the messages.

[Pei Wang]

You are correct, and we can also simply set a restriction on the size
of the text, and do FIFO by default.

The current NARS is not ready to run for a long time. To do that,
there are many related issues to be fixed. So you don't need to worry
too much about that. Currently the urgent issue is still to make
single inference steps right.

Pei

[Pei Wang]

These are all good ideas, though I probably won't have time for GUI
soon --- especially after the new semester starts at today. :-(

> One disadvantage, though, is not being able to copy/paste like the
> TextArea allows.  Though you could generate the TextArea text from a
> list of messages ex: concatenating their toString(), and the
> concatenation could occur on a certain filtered subset of the messages.

Except the InputWindow, copy/paste is not absolutely necessary, though
it is desired, if not for the whole text, but for a single line or
term name.

Pei

[Jeff Thompson]

S H, at the moment, the NARS interface does not depend on the Swing
library. Your suggestion is interesting, but introduces a new
dependency. Do you have an opinion about this issue?

[SeH]

S H, at the moment, the NARS interface does not depend on the Swing
library.  Your suggestion is interesting, but introduces a new
dependency.  Do you have an opinion about this issue?

it seems NARS's current GUI is using pure AWT (no Swing).  so that would add extra dependency.

in terms of modularization ( http://code.google.com/p/open-nars/wiki/GUIRequest and http://code.google.com/p/open-nars/wiki/Modules), maybe the NARS I/O and GUI systems could be organized into:

• nars.io.awt (the current contents of nars.gui)
• nars.io.swing (new GUI components)
• nars.io.swt (eclipse plugins?)
• nars.io.gwt (AJAX web interface?)
  
• nars.io..

(replacing 'nars.gui' with 'nars.io' in consideration of how GUI's are essentially I/O channels for NARS existing at the same level as network, file, or database connections...)

maybe this could be facilitated by refactoring the Memory, NARS, Parameters, and Center classes into:

• interface NAR - "non-axiomatic reasoner", a specific instance of a NARS implementation, with self-contained memory and executive control
• specific implementations of "NAR" would utilize specific memory and inference components, through a common access interface accessed by a separate GUI layer
  

[Pei Wang]

On Wed, Sep 2, 2009 at 11:13 AM, SeH<seh...@gmail.com> wrote:
>
>> S H, at the moment, the NARS interface does not depend on the Swing
>> library.  Your suggestion is interesting, but introduces a new
>> dependency.  Do you have an opinion about this issue?
>>
>
> it seems NARS's current GUI is using pure AWT (no Swing).  so that would add
> extra dependency.

Correct. The current GUI code was mostly written in 1999, with little
changes since then. AWT was used so that the demo can run in most
browsers in that time.

I think the GUI should be moved to Swing, though the priority of that
task hasn't been high enough in my long to-do list. :-(

> in terms of modularization (
> http://code.google.com/p/open-nars/wiki/GUIRequest and
> http://code.google.com/p/open-nars/wiki/Modules), maybe the NARS I/O and GUI
> systems could be organized into:
>
> nars.io.awt (the current contents of nars.gui)
> nars.io.swing (new GUI components)
> nars.io.swt (eclipse plugins?)
> nars.io.gwt (AJAX web interface?)
> nars.io..
>
> (replacing 'nars.gui' with 'nars.io' in consideration of how GUI's are
> essentially I/O channels for NARS existing at the same level as network,
> file, or database connections...)
>
> maybe this could be facilitated by refactoring the Memory, NARS, Parameters,
> and Center classes into:
>
> interface NAR - "non-axiomatic reasoner", a specific instance of a NARS
> implementation, with self-contained memory and executive control
> specific implementations of "NAR" would utilize specific memory and
> inference components, through a common access interface accessed by a
> separate GUI layer

I need to think more about this.

Pei

[S H]

in attempting to translate opencog.org's OpenCogPrime (OCP) from C++ to Java, i wondered if NARS could fit into the design.  OCP uses a hypergraph data structure significantly, which seems sufficient for containing, among other things, NARS memory.

http://launchpad.net/jcog

NARS module code:

• http://bazaar.launchpad.net/%7Eseh999/jcog/proto2/files/head%3A/cog.nars/org/opencog/

i remember that someone had suggested or asked about merging OCP and NARS code-bases before.  it would seem there are several points of incompatibility.

one, for example, is the different meaning of OCP atom and NARS sentence's different kinds of "truth" values.  so in this prototype JCog design, each atom can associate an arbitrary set of these kinds of tags, so that OCP, NARS, and other systems can potentially act upon and within the same data.  these are differentiated as OCPAttention, OCPTruth, and NARSTruth, and are accessible through basic Atom.get(class) and Atom.set(class, value) methods.

i'm wondering, what other incompatibilities might be resolvable or transcended?

so, i imported the current NARS code into JCog and began making modifications according to the refactoring and GUI suggestions in my previous e-mail.

• refactoring the Memory, NARS, Parameters, and Center classes into "interface NAR" (instances of which would be "Non-Axiomatic Reasoners" with self-contained memory and executive control).
• removing all "static" references, so that a system can instantiate multiple reasoners rather than being restricted to one singleton.  this is also necessary for a proper unit testing framework, or to compare multiple simultaneously running NAR's.  this interestingly also might make it possible for a NAR memory to contain sub-NAR's within itself, recursively.
• making GUIs that would control, view, and edit OCP and NARS features.  there are several GUI widgets that would serve both systems, for example, browsing a list containing both OCP atoms and NARS concepts.
  

i thought it would be a good idea to ask for ideas or suggestions at this point.  the NARS code commited in JCog is not presently functional - much work remains.  though these initial refactorings are probably enough to motivate further architectural developments.

Correct. The current GUI code was mostly written in 1999, with little
changes since then. AWT was used so that the demo can run in most
browsers in that time.

I think the GUI should be moved to Swing, though the priority of that
task hasn't been high enough in my long to-do list. :-(
in terms of modularization (

maybe this could be facilitated by refactoring the Memory, NARS, Parameters,
and Center classes into:

interface NAR - "non-axiomatic reasoner", a specific instance of a NARS
implementation, with self-contained memory and executive control
specific implementations of "NAR" would utilize specific memory and
inference components, through a common access interface accessed by a
separate GUI layer