Initiate the as-moses repo

[kasimebrahim]

Initiate the as-moses repo

[linas]

Uh, this seems wrong, this appears to be a whole-sale merge of the entire old moses repo.

If working with that old code was the right thing to do, then the whole as-moses project should probably be done as a branch of moses, rather than as a copy.

I thought the whole point of this repo was that it would NOT be just the old moses, warmed over.

[bgoertzel]

This was Nil's suggestion ...

On Thu, Apr 26, 2018 at 9:35 PM, Linas Vepštas notifications@github.com wrote:

Uh, this seems wrong, this appears to be a whole-sale merge of the entire old moses repo.

If working with that old code was the right thing to do, then the whole as-moses project should probably be done as a branch of moses, rather than as a copy.

I thought the whole point of this repo was that it would NOT be just the old moses, warmed over.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/opencog/as-moses/pull/4#issuecomment-384642991, or mute the thread https://github.com/notifications/unsubscribe-auth/AFolXNoqqvDj4I-Z7p3N7XqJS6-x0Qa5ks5tsc0dgaJpZM4TlKXG .

-- Ben Goertzel, PhD http://goertzel.org

"Only those who will risk going too far can possibly find out how far they can go." - T.S. Eliot

[linas]

Oof. Well, if its to be done that way, it would have been a lot easier to fork moses first, then add the two files here. Let me talk to Nil.

[pennachin]

Forking was Nil's suggestion and there's still time to disregard this PR and do just that onto a new repo. I guess Kasim didn't fork it because the repo already existed, but all it has is a README and a plan/task list as an issue (https://github.com/opencog/as-moses/issues/3)

[ngeiswei]

I agree, guys, merging MOSES is a bad idea. I wonder, what about rebasing? That would yield the same history, wouldn't it?

[ngeiswei]

Linas has suggested to me to directly work on the old MOSES repo. That is up to discussion, the main reason I felt it was preferable to have it in a new repo is so that we don't have to worry much about backward compatibility. If it's in a different repo, with a different name, users will not expect backward compatibility.

The old MOSES contains a lot of stuff that is not sufficiently useful or general to be sustained in time, for instance there has been a lot superficial additions from the Aidya times, many of which we'll probably never need to port, etc.

That is said, since the MOSES user base is fairly small, and we, I believe, are in touch with all of it, then, it's probably not a big deal.

If we keep working on the old repo, we'll just create a tag...

So what do you think? Is creating a new repo worth the trouble?

[ngeiswei]

Oh, another reason is performances. It's gonna take an awful lot of time and work before as-moses outperforms the old moses. Not a big deal, users can check out the code corresponding to the tag, it's just an additional inconvenience.

The alternative is to strive to maintain the performances of the old MOSES, like having flags to use the old Combo with the old interpreter, etc. While still offering new Atomese functionality. It's possible, but is it worth it?

It's a tricky decision, help!!!

[ngeiswei]

I'm thinking... The plan I've laid out so far #3 actually maintains full compatibility, so why bother at that point?

I mean, the day we decide to hard break, then we can fork it to another repo, meanwhile, why worry?

Anyway, let me still know what you think, guys.

[pennachin]

I think a fork is the cleanest solution, as both you and Linas had suggested. I think doing this work in the main, so-far-standalone MOSES repo adds complexity for no tangible benefit.

[linas]

OK. Maybe I don't really care. I was just trying to figure out how to optimize:

-- keep ongoing code maintenance simple -- minimize messiness -- make it easy to back-track on failed attempts.

The last point is maybe the most important: as I look at #3, I see a lot of things that can go badly wrong, and, after half-a-year, one might want to throw away half the code, while keeping "the good half". This would be easiest if the bad code was isolated to some directory, instead of invasively invading everything.

[linas]

Also, I think that #3 deserves some review, before we just blast off coding it. I see several issues there, already.

[ngeiswei]

Totally agree about reviewing #3 I'm not sure what could go about wrong though, as I said, it retains full compatibility. Is it gonna bloat the code, yeah you bet! But that's probably unavoidable.

[ngeiswei]

@pennachin said

I think a fork is the cleanest solution, as both you and Linas had suggested. I think doing this work in the main, so-far-standalone MOSES repo adds complexity for no tangible benefit.

I used to think that, but now I'm less confident. The more I think about it, the more I see a benefit with attempting to maintain old MOSES alongside AS-MOSES, basically for leveraging performances and featurefulness of old MOSES.

I can come up with scenarios where we'd want to mix parts of the two together, thus in the process co-growing them (with an emphasize on AS-MOSES of course, but still).

Perhaps another option to consider would be to develop AS-MOSES on a feature branch of the MOSES repo.

Anyway, I suppose it's not terribly important since both ways allow us to keep the old MOSES alongside AS-MOSES, but it does have a small impact on the perception of how AS-MOSES is gonna evolve in the future, and if we only need one repo, while having two.

[ngeiswei]

@kasimebrahim, I've updated the Section Initiate the as-moses repo in #3 to make a clean fork. You probably don't have the permissions to force-push, if so I'll do it.

Although I'm not entirely sure yet whether we want to start development on a new as-moses repo or on the old mose repo, you may preemptively proceed.

We can let this PR open for now only to conclude the discussion about new as-moses vs old moses repo...

[kasimebrahim]

okay great

[pennachin]

There are a couple of SN services which will rely on MOSES. We could just hardcode a MOSES version for those, but it's less than ideal. So I am interested in the stability of that repo. From that perspective, using a separate repo means we don't have to worry about the interplay between as-moses and regular MOSES. I know your plan doesn't purposefully break anything, but stuff happens...

[ngeiswei]

@pennachin thanks, that's a very valid reason. Discussion closed then, moses will be forked to as-moses.