Tcpinterface

[ryanpeach]

I'm still working on the TCP aspect of this (using python as the testbed) but I just completed the asyncronous input/output test via the reader and writer channels. Just wanted to update you all on my progress, and ask if you have any pointers based on what I have so far?

[ryanpeach]

Out of memory error?

[patham9]

Nice work! I had only a short look at it so far, but will give more feedback these days.

About:

+; Support functions
+(defn exists?
+  "Tests: v equals some item in l?"
+  [v l]
+  (some #(= v %) l))

Clojure idiomatic way would be not having this function and using: (some #{v} l)

[ryanpeach]

Good to know!

Btw, the help docstring is wrong. (Outdated) The server sends strings like this: ID:>:op-name:>:arg1:>:arg2.... And receives ID:<:op-name:<:arg1:<:arg2.... (or maybe the other way around lol)

ID's are anything useful for hashing, and I'm using them to track specific "conversations" between the server/client.

Example: Server: 0:<:do-op1 Server: 1:<:do-op2 Client: 0:>:True Client: 1:>:Invalid

[patham9]

Looks good and clean so far, will look at it in more detail these days! :) And I will ask jarradh to look at the pull request also, his Clojure is better than mine and Tony's.

Best regards, Patrick

[ryanpeach]

Had my first big success tonight working with /src/examples/tcp/interface.clj and /src/examples/tcp/tcprepl.py

Working on interface.py and testing new-op function next.

Also, the app does not close gracefully, and does not support multiple clients, those would both be nice features.

[patham9]

This pull request is already finished?

Then I try an example where 1. input is given from python, 2. an answer is handled by python and 3. and operation called by NARS is executed by python, if all 3 cases work, it can already be merged.

Best regards, Patrick

[ryanpeach]

The operation handling (#3) has not yet been been a success due to implementation time for blocking and timeouts, but best I remember it's near working. (#1) and (#2) are verified working. (also) Connection/Disconnect/Reconnect is verified working with no errors. The python I am testing with is passing most of the operations, but I don't yet have an operation-execution interface to test with. In order to get it done by this weekend, I will try to set up a simple test for an addition operation with the code I have. I suggest putting the python TCP interface in its own repo on the opennars account. For cleanliness. I'll create something for you to fork. Keep the clojure files under examples (though I wonder if maybe it would be better to create a new top-level folder under src/ called something like "tools" or "modules" to separate them from .nal files.

Regards,Ryan Peach

Date: Wed, 21 Sep 2016 08:32:09 -0700 From: notifications@github.com To: opennars2@noreply.github.com CC: ryan.peach@outlook.com; author@noreply.github.com Subject: Re: [opennars/opennars2] Tcpinterface (#64)

This pull request is already finished?

Then I try an example where 1. input is given from python, 2. an answer is handled by python and 3. and operation called by NARS is executed by python, if all 3 cases work, it can already be merged.

Best regards,

Patrick

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[patham9]

No hurry! :) And no worry: If it blocks it's also fine for now, just means the operation-creator has to take some care. And while operator-executor is blocking because it waits for the result of the operation, the rest of the system is still going and even able to send new requests to operator executor.

[ryanpeach]

I'll send you a msg with the terminal output if it shows up again, but what I meant by having trouble with promise blocking is it actually throws an exception in pulsar. I have recently found pulsar native promises with timeouts built in and am hoping that making that simple replacement will solve the problem. I have decided to have the op-executor simply receive a confirmation from the client, basically confirming the arity and types. Then having the host send back data via narsese-input events. Regards,Ryan Peach

Date: Wed, 21 Sep 2016 13:16:56 -0700 From: notifications@github.com To: opennars2@noreply.github.com CC: ryan.peach@outlook.com; author@noreply.github.com Subject: Re: [opennars/opennars2] Tcpinterface (#64)

No hurry! :) And no worry: If it blocks it's also fine for now, just means the operation-creator has to take some care. And while operator-executor is blocking because it waits for the result of the operation, the rest of the system is still going and even able to send new requests to operator executor.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[pei2nars]

SELF is introduced in NAL-8, and described in https://github.com/opennars/opennars/wiki/OpenNARS-One-Dot-Six. There are not too many predefined concepts at this moment. Probably only SELF and the ones mentioned in http://cis-linux1.temple.edu/~pwang/Publication/emotion.pdf. We do need a wiki page for them.

On Wed, Oct 12, 2016 at 10:59 AM, Ryan Peach notifications@github.com wrote:

@ryanpeach commented on this pull request.

In src/examples/python/test.py https://github.com/opennars/opennars2/pull/64:

• assert in2, "Did not detect correct narsese as expected."+str(in2)
• def test_input_narsese(self): self._test_input_narsese(self.client.input_narsese)
• def test_valid_narsese(self): self._test_input_narsese(self.client.valid_narsese) +
• def test_ask(self):
• self.client.input_narsese("b>.", "c>.")
• assert(self.client.ask("c>?"))
• try:
• self.client.ask("d>?", 1)
• raise Exception("Expected TimeoutError")
• except TimeoutError:
• pass +
• def test_op(self):
• self.client._input_narsese('new-op','plus')
• self.client.input_narsese("<(*, 1, 2, ?out) --> plus>!", id0="1")

Great!

So is {SELF} a predefined concept? Is there a page on the wiki listing concepts like this?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/opennars/opennars2/pull/64, or mute the thread https://github.com/notifications/unsubscribe-auth/AHxfsS2DW8qzDxKus1ghipzCc3Qog5iaks5qzPW7gaJpZM4Jsmdo .