The Path to Beta/One

My vision for Beta/One is a running in-web tutorial that is unleashed to the world. This will teach the language, show off features, and be able to automate some browser functionality.

I'm not sure exactly what it would be able to automate. A good first step along the way will be a turtle-graphics style "pen up, pen down" kind of thing, but I don't know if that will be the most compelling demo. Consider drawing to be the worst-case scenario domain...and something more useful like PARSE-based RegExr to be a shoot-the-moon kind of target.

Expecting this before the end of the year would be naive. But I'm hoping not to miss January by much.

  • libRebol has some big issues to sort out on binding, but as I've said, it's going pretty darn well...and the JavaScript version should be just as good as the C version--if not better--to power the demo app.
  • We may not have UTF-8 Everywhere merged in by then, but its effects are already accounted for in the API...and I'm confident it's the right answer.
  • The debugger might not be fantastic, but stepwise debugging should work.
  • I'll have all the Rebmu puzzles updated and running, so Rebmu will be one of the things you can do in the browser version.

Should there be a release earlier than that?

If a version of the code works for someone for some purpose, then they may take that build and use it as-is for as long as they like. This is how R3-Alpha and Rebol2 worked, after all...it froze on one day and then that's what you had with no support thereafter. That's always an option.

And if you report a bug that gets a patch to the mainline, you can apply that patch and rebuild your executable. That is fine.

But I can't promise to commit bugfixes to your version and the master, and worry about how to build the releases, etc. I realize this may not fit everyone's wishful timelines. But I'm sorry, I don't have the bandwidth for anything else.

A Rebol by any other name...

In addition to combining the browser release with the stable release is that Beta One will be when to decide whether or not to keep calling the project Rebol. This decision will be made by essentially offering Carl a time-boxed proposal: the GitHub rebol/rebol repo gets the current code of the "Ren-C library" with a voting structure that can outvote any one person (including Carl or me), the community gets control of rebol.org and rebol.net and have the ability to launch documentation and a module repository there, and he keeps rebol.com for whatever he feels like. He may join in development or not, as he wishes.

If the time-box is not met, we very simply adopt a new project name, and stop mentioning "Rebol". Resources we control (such as this forum) will move under the new name. Resources we don't control will be forked as licensing permits, which it generally does.

Why haven't we done this yet? Firstly, because I don't think it's fair to be pressuring about a project that hasn't completely proven itself, see my remarks about R3-Alpha parity. Plus, it would be premature to make some "big announcement" about a newly-named project that still has major decisions to work out. You don't get a second chance to make a first announcement. Note just how drastic the null change was. We do not want to drop something like that on normal users after they've painstakingly written a bunch of code.

Existing Rebol users are different. They are used to being the guinea pigs and having the rug yanked out from under them (hopefully a mixed metaphor :P) But people who've been using the language for decades are worn out, and I think that's why I've really not been counting on old-school Rebol users as being the target audience for any "products".

In a sense, keeping the Rebol name is probably more a liability than anything else. Certainly Red used to see association in that way...and wanted to distance itself from the somewhat spotty track record, and "weird" community reputation. The reason to do it is to aim for holding up the standard of what the project's objectives and ground rules were...and if Carl believed it were doing so, that would be a particular accomplishment. But we can't be held hostage to it if that's not going to pan out.

Hence the name "Beta/One". When it's unleashed to the world, it will either be Rebol 3 Beta or Something-Else version One.

Feature Lock

I am starting to tag Trello issues with "Beta/One Locked" to indicate that the behavior in that card is considered, with fair confidence, to not be changing. The concept of this lock/freeze is that any code samples on that card should be vetted and work as written...and that the text of the card be basically all truthy.

As a show of seriousness about this, the card describing the new null behavior is Beta/One Locked. That might seem pretty cocky considering the behavior on that card just changed this week. But I know when something is right. I may get excited over a new behavior, but that excitement is different from when you know you have found the solution. And that is the solution.

Still, there are a lot of cards, and a lot of work, and a lot of big question marks all over the place.

Participation Matters

In a prior discussion thread on stable releases, I said:

I know people are off on other things and can't devote their lives to a strange volunteer project. I don't hold anyone to the standard that they can't go AWOL if something more important comes up. If you don't make any specific promises, you don't have any specific responsibilities.

And I allow myself that too. I was more or less on vacation last month, and didn't do a whole lot of programming--though I did do some, and I've always got a couple of things in my mind. I'll probably be back on the road again shortly after a foot sprain heals up (it's doing pretty well). If I find something more interesting to do with my time, development may slow down, and that's just the breaks.

But this comes down to a you-get-what-you-give situation. If people want to get to Beta/One faster, they'll put in time to discuss and work and help lock down more of the issues. If you are happy to see it happen whenever it happens, then just wait and see. Odds are cool things will happen, just not on any particular timeline.

2 Likes

Sounds great, Brian!

I'll comment more soon. Thanks for the great update and details.

Now that is some news!

Brian you are doing a marvellous job.

A new name for the project.... absolutely!

Thumbs up from me!

That sounds like what we need to do soon. There aren't a lot of existing bugs that can't be worked around vs missing functionality. And we don't need to patch it either unless there's something blocking.

12 posts were split to a new topic: License confusion

Ok, I've selected the latest builds and used those as the snap shot builds to be used for scripting.

See http://metaeducation.s3.amazonaws.com/index.html near the top of the page.

You can document compatible scripts on this Trello card

I'm going to note here changes (some incompatible) that occur after this version. People can edit this list I hope.

23-June-2018: Removal of /INTO from COMPOSE, REDUCE, COLLECT, and the esoteric EXTRACT. Users of snapshot e650322 should just not use /INTO, which isn't much an issue because almost no one did.

27-June-2018 PROC/PROCEDURE now folded into FUNCTION/FUNC Users of snapshot e650322 should use avoid use of PROC or PROCEDURE and use explicit returns, e.g. return: [<opt>] and then return null. This will be forward compatible, as 0-arity returns only apply to return: <void>.

28-June-2018 CONTEXT OF changed to BINDING OF. Shim compatibility is possible in e650322 by using BINDING-OF, and defining binding-of: default [specialize 'reflect [property: 'context]]...which will work in both older and newer binaries...older because it's not defined and gets the new definition, and newer because it is defined so the default won't happen.

28-June-2018 METHOD, a way of defining functions/actions inside objects/context with automatic binding to the correct context. Users of snapshot e560322 who require inheritance will get close to the same effects by saying method: default [...the definition of method...] but not bothering with the binding. Note using plain FUNC and FUNCTION will not participate in inheritance in newer builds--so defining method is important.

2-Jul-2018 PARSE returns null instead of logic false on failure. Not actually that disruptive...if PARSE results are stored into variables expecting logic directly (usually they aren't), use DID or NOT as appropriate--this will work in e560322 snapshot also. Protip: search for : parse to find places that are likely SET-WORD! followed by space followed by parse, to see if direct assignment is used.

This is a good example of why this snapshot was chosen too arbitrarily and too soon.

But the beneficial aspect of it is to sort of start thinking about what kind of organizational process and methodology is in use in a world where there is a snapshot...and people are not just downloading whatever daily build and asking for support of it. So I support the initiative to start thinking on these lines.