Location of Ceptr Wiki

[GerryG]

Just realized that this is where the main fork is and why there are no issues or wiki at the metacurrency account.

Don't you think it would be better to make that version "official" for contributions and community? At one level it doesn't matter, but it should be obvious how to get here from the wrong (not active) place. Forwarding links and clarifying comments in strategic places.

[zippy]

That's going to happen when I switch gears from holochain to ceptr core and pcubed.

[GerryG]

So, holochain is moving? I picked up the P^3 is in go as is holochains, but are they merging and is that more for source organization or deeper architecturally?

Is there a picture for the new architecture? Words that might inspire a good picture? I'm exploring what I can find, and understand some may be outdated. I want to be working from most recent ideas. I am most interested in the contact points, that is how apps and systems that use ceptr will be written and structured.

[zippy]

Hey Gerry, working as hard as we can on this and docs too. Should have stuff by end of month such that you should be able to write holochain apps, in zygomas, and maybe JS. We'll have some samples implemented for people to work from. Next step after that is P^3, and ceptr integration.

[GerryG]

But what about ceptr itself? I'm trying to understand the code and it is very hard to read. I don't want to work on stuff you are going to dump soon.

Should it build and tests run as is?

[zippy]

It does compile and tests run on linux/ubuntu, There are three tests that don't pass because it's where I stopped dev. I am almost certainly converting this particular code-base to go, and this will become an archive. This code will be split into three parts: a stand-alone semtree/semtrex library, and library built out of that one, that provides an execution environment for self-reducing trees, and then finally a third one that implements the receptor contexts and message sending.

But all this doesn't mean that it's not worth your while to understand the code because tons of what I do will just be fairly straight c->go conversion. Feel free to ask me questions about specific parts of the code. To understand it, I think I would start by looking at the tests.

[cliftonm]

To chime in here, I'd be interested in participating in a port, with a (ok, not so hidden) agenda -- FlowSharpCode is at the point where I'm generating code from DRAKON flowcharts (look up DRAKON.)I'm already generating C# and Python code from components / flowcharts. What I'd like to do is first describe the components and flows in a language agnostic manner, then fill in the language specific details, adding go to that repertoire. Would you be interested in Gerry and me working on first a language-agnostic visualization of semtree/semtrex and then porting that to, at a minimum go? I'd also be interested in a C# / python port as well.

[GerryG]

If you really are basically moving to a new reference implementation, maybe we can help to that end. First to document objects and interfaces, then to convert the bits we can save. I don't think go is a bad choice for a reference implementation and I've even verified that I can link to go methods from ruby. JS might not be a bad choice either, and I think it would be good to support that possibility as best we can.

First question is whether base_defs is the basis for all the 'code in trees' parts of the implementation and we can use most of that to generate code any go or JS, right? Can we move to a more open/readable form of these definitions? A canonical representation of JSON and/or go data syntax would work for me.

Just point the direction that would help you get the core architecture down so that others can join in the implementation chores.