Still active?

[anthrolisp]

Is this project still active? Thanks in advance!

[JeffreyBenjaminBrown]

Josh still uses it. I haven't seen a commit in a long time. He's working on SmSn 2.0, which will use a hypergraph, not a graph. He's also taking care of a newborn. Heroic stuff.

I haven't been able to use it in a while. I recently got close, and then stuck, as briefly described here.

Today, prompted by your interest, I'm trying to build it on my home system instead of in Docker.

[anthrolisp]

Following the instruction here on this page (https://github.com/synchrony/smsn/wiki/Running-Semantic-Synchrony-and-Emacs-in-a-single-Docker-container), I got the following errors after m-x smsn in emacs:

opening connection if: make client process failed: no route to host, :name, websocket to ws://172.17.0.3:8182/gremlin, :buffer, nil, :host, 172.17.0.3, :service, 8182, :nowait, n\ il

backtrace:
Debugger entered--Lisp error: (file-error "make client process failed" "no route to host" :name "websocket to ws://172.17.0.3:8182/gremlin" :buffer nil :host "$ make-network-process(:name "websocket to ws://172.17.0.3:8182/gremlin" :buffer nil :host "172.17.0.3" :service 8182 :nowait nil) (if (eq type (quote plain)) (make-network-process :name name :buffer nil :host host :service port :nowait nil) (condition-case nil (open-network-stream name $ (let* ((type (if (equal (progn (or (and ...) (error "%s accessing a non-%s" ... ...)) (aref url-struct 1)) "ws") (quote plain) (quote tls))) (port (if (= 0 ($ (if (member (progn (or (and (memq (aref url-struct 0) cl-struct-url-tags)) (error "%s accessing a non-%s" (quote url-type) (quote url))) (aref url-struct 1))$ (let* ((name (format "websocket to %s" url)) (url-struct (url-generic-parse-url url)) (key (websocket-genkey)) (coding-system-for-read (quote binary)) (codin$ (let* ((protocols (car (cdr (plist-member --cl-rest-- (quote :protocols))))) (extensions (car (cdr (plist-member --cl-rest-- (quote :extensions))))) (on-open$ websocket-open("ws://172.17.0.3:8182/gremlin" :on-message (lambda (_websocket frame) (let ((response (websocket-frame-text frame))) (funcall websocket-respon$ create-websocket-connection("172.17.0.3" 8182) (setq websocket-connection (create-websocket-connection host port)) (progn (setq websocket-connection (create-websocket-connection host port)) (sleep-for 0.1)) (if (not (websocket-connection-is-open)) (progn (setq websocket-connection (create-websocket-connection host port)) (sleep-for 0.1))) get-websocket-connection("172.17.0.3" 8182) (let ((connection (get-websocket-connection host port))) (if (websocket-connection-is-open) (let ((payload (smsn-serde-format-request request))) (setq websoc$ smsn-websocket-send-and-receive("172.17.0.3" 8182 (:action "net.fortytwo.smsn.server.actions.GetConfiguration" :filter (:minSource nil :defaultSource nil :mi$ (if (equal "websocket" protocol) (smsn-websocket-send-and-receive host port request callback) (error "%s" (concat "unsupported protocol: " protocol))) (if (equal "http" protocol) (smsn-http-send-and-receive host port request callback) (if (equal "websocket" protocol) (smsn-websocket-send-and-receive host po$ (let ((protocol (find-server-protocol)) (host (find-server-host)) (port (find-server-port))) (if (equal "http" protocol) (smsn-http-send-and-receive host por$ issue-request((:action "net.fortytwo.smsn.server.actions.GetConfiguration" :filter (:minSource nil :defaultSource nil :minWeight 0.0 :defaultWeight 0.5)) upd$ (if (not conf) (issue-request (to-filter-request get-configuration-request) (quote update-configuration-callback))) (let ((conf (smsn-env-context-get (quote configuration)))) (if (not conf) (issue-request (to-filter-request get-configuration-request) (quote update-configur$ smsn-client-fetch-configuration() smsn-mode() smsn() call-interactively(smsn record nil) command-execute(smsn record) execute-extended-command(nil "smsn") call-interactively(execute-extended-command nil nil) command-execute(execute-extended-command)

[ketan0]

@anthrolisp I also ran into this—changed smsn-server-host to "172.17.0.2" (or whatever host the docker run command said Gremlin was using,) and it works now :)

[JeffreyBenjaminBrown]

I just got it working again this week via Docker. I've made a tiny repo with a short but detailed walkthrough of how to get it set up. Please let me know if this works for you:

https://github.com/synchrony/demo-smsn-docker

[ketan0]

I managed to get the Docker working, thank you :)

[JeffreyBenjaminBrown]

Hooray!

[joshsh]

Btw. yes SmSn is still "active" in that it has at least one very active user (myself). Most likely, it has exactly one very active user. I am bonded to this software for life, so there will always be some installable and runnable version of SmSn (though it might revert to its earlier name at some point -- Extend-o-Brain). The changes I have in mind for the next version of SmSn are really fundamental ones (including deep support for schemas a la Dragon), so they are waiting on a major development push on my part, and also on an open-source version of Dragon becoming available. I am actively working on the latter.

[JeffreyBenjaminBrown]

As the record of smsn-public will show, tt's also got one half-assed user!

[joshsh]

Indeed @JeffreyBenjaminBrown you're more active than I thought. And you're going to like schemas :-) Here are a few things which are likely to change in the v2:

• All data will be in the form of what's called BasicValue in Dragon; it's a simple JSON-like data model. YAML and JSON are two straightforward serialization formats for BasicValue data which are also friendly to line diffs, but you will free to choose from a variety of formats, including one of two RDF-based formats, and including binary formats like Protobuf, Thrift, or Avro if you need to send data over the wire, or store it efficiently in a database. All of that will be inherited from Dragon.
• schemas can also expressed as basic values, so they can be embedded in your graph along with the rest of your data. However, schemas are restricted values; they are expected to conform to a schema (yes, there is a schema of schemas; it's pretty close to a subset of Dragon's core data model).
• Likewise, any other data in your graph can be formatted according to a schema, though you will also free to create schemaless data. For example, you might create a record like {"name": "Arthur Dent", "someOtherFieldIJustMadeUp": 42} and add it to your graph, with no schema. Provided a future version of SmSn is capable of editing and displaying such schemaless data, you can do whatever you like with it. However, there will be value in adding a schema for data shapes which occur often, and for which you would like to support some sort of automation, like querying for all of the people named "Arthur", or finding all of the schemas in your graph which deal with people. Dealing with schemas, and integrating schemas into your data in this way is not a trivial problem, but most of the conceptually hard bits have already been solved in Dragon; SmSn just needs ways of navigating, displaying, and updating the data.
• SmSn's current data model can be carried forward into the new solution as one specific, rather simple schema: the Atom schema, in which all records are Atoms with required ids, timestamps, weight, data source, and other optional fields, as well as a list of zero or more children (other Atom ids). It's actually not the best model we could have chosen, as the ordering of children leads to a lot of merge conflicts in collaboratively-edited graphs, as we know. However, once your graph is in the new system, you will be free to migrate your data to more domain-specific schemas as you see fit.
• A graph in Dragon is a set of labeled elements. A SmSn graph in Dragon would be a set of elements in which the label of each element is Atom. The current SmSn approach of storing each Atom in its own file on disk will probably carry directly over into a Dragon-enabled SmSn, as small files help minimize merge conflicts, and you don't have to think very hard about how to partition the data into files. Going forward, however, graphs will probably consist of less atoms and therefore fewer files, as more domain-specific schemas will allow you to pack more information into a single element. E.g. in current SmSn, every single line of text we type becomes its own Atom, but most lines of text have only one parent; they don't really need an independent identity, and could just included as literal values within another element. Where you have one Atom with 10 other Atoms beneath it in current SmSn -- all simple lines of text -- in the future you might just have a "comments" field in your schema which lets you provide a collection of strings. Now you have one file on disk, and one vertex in your graph, instead of 11.

[JeffreyBenjaminBrown]

The parts I understood of that sound great.

Would the putative "comments" field be as searchable as titles currently are, or unsearchable like the markdown text?

Will children be unordered in SmSn 2? That seems like it could be problematic -- if you've got, e.g., a list of steps that must be performed in serial, and you want one of those steps to have multiple parents, then the steps would have to be children rather than elements of the "comments" list.

I discovered Agora yesterday. It looks like it might be a wonderful monkey wrench in these plans -- a federation of Github repos doing the knowledge base thing. I haven't gotten it to work yet but the community appears to be active.

[joshsh]

A field like comments would be searchable to the extent that your application understands the schema that defines comments. Either the graph DB needs to have built-in support for the schema, or you need to be able to configure the graph DB to index the fields which are important to you.

Children will still be ordered insofar as Atom will stay as it is; its children are ordered. However, you will have the option of creating other schemas in which this is not the case. If you need an ordered list of entities, then the list constructor in the schema language is your friend. E.g. you are free to define a steps field whose type is list: Step or list: StepId. In other words, when you really need ordering, you might want to choose a more meaningful field than children, which prescribes a particular semantics for the values of the list.

Agora looks like a good idea. Haven't quite grokked what a "digital garden" is yet (the link appears to be broken), but I'm all for building a collaborative knowledge base by federating GitHub repos.

[JeffreyBenjaminBrown]

Children will still be ordered insofar as Atom will stay as it is; its children are ordered. However, you will have the option of creating other schemas

Nice!