Ren Garden / Status / Future

Ren Garden is a project which was originally written in about a month, when I was trying to feel out what a client of the C++ API might look like. It has been periodically brought up to date so that it runs. Recently I brought it up to date so it would build, and made a debug drop for Windows:

We pretty much have Ren Garden to thank for the existence of Ren-C at all. If I hadn't tried to wire up a Rebol evaluator to Qt and a C++ API, I'd not have learned enough about how Rebol was written to start fixing it up.

I think it is a neat demo, and I like to use it when giving presentations (as opposed to just typing in an ordinary console). But while it is a promising application, it has no shortage of flaws and difficulties in its design.

One smart thing Ren Garden does is build on Qt. Qt is a nice, fluid, well-documented layer of abstraction across operating systems. It is true that the DLLs for Qt are somewhat large (the debug ones in particular, and I'd rather people be running debug builds for now). When the pieces Ren Garden wants are put together (Core, GUI, Network) the release build size w/DLLs is going to be in the ~10mb range. Doing a static build which only takes the parts of Qt that you use and puts them into the executable is a labor-intensive process--and not one that sufficient incentive has been around to do. But even then you're not going to see less than ~5mb for that exe.

I'm not too concerned about that. And if you're using KDE on Linux, you already have Qt--so long as you build for the same version as the shell is using, you shouldn't need any separate libraries. (Linux distributions try to build all the KDE apps to use the same library versions as the shell is using, and a packaged Ren Garden would do the same.)

Yet what it does is apply a QTextEdit widget in a somewhat creative way. I was trying not to pull in a full WebKit browser, being a bit size-conscious...and not wanting to make something like an Electron app. This was probably short-sighted, as with the emscripten build we would probably want to make an in-browser experience like Ren Garden, and it would be more able to share code. In either case, since it's a text editor, there has to be some amount of logic to prune off the old history if you have a long-running/long-printing process, because it just gets slower and slower as you add more lines. That's one of the many things that haven't been attended to yet.

The INPUT command doesn't currently work, and it goes through some rather experimental I/O code that works with C++ classes. Writing a C++ "iostream" turned out to be kind of more of a hassle than I realized, and I'm not sure if it's the right direction to be going. PORT!s in general need a major design review, and then thinking about how such ports will interact with C (or if it will have a special C++ interface) is something that needs to be thought about.

Having Ren Garden around helps stress the API a bit. It shows weak points, one weak point of which is still threading... it has a separate GUI thread from the evaluator thread, but even that treads on some dodgy territory.

Because it is basically the largest (only?) app that uses Rebol in an embedded way, it is a good test of new ideas and catching design problems...and so I'm glad it's there. But how to prioritize bug fixes? What features or experiments should be done with it? What is the likelihood that having honed drops of it would expand usage? Who would help, and how?

These are questions people have to answer. @szeng has brought up an interest in whether or not Rebol a Rebol/Qt linkup could supplant the AGG-based /View code... and @gchiu keeps bringing that up too. I've been hesitant to invest more in this because I don't want to be the only one doing it.

Where do other people see this standing, and is anyone willing to commit anything to it? Or is it just another "if I develop it you might use it" situation?

"What features or experiments should be done with it?"

I would like it to have a source editing area where we can send code to the repl from the source code. We could load the program from source on start up, that way the repl is ready to use with the source. This would make it closer to a lisp editing experience.

"Where do other people see this standing, and is anyone willing to commit anything to it? Or is it just another "if I develop it you might use it" situation?"

I hope to help but I have two jobs, a marriage, and course work to attend to... not much time.

Ctrl-T currently makes a new REPL tab.

I feel like tabs should be able to be REPL or code editing. I was thinking that do 3 or whatever would mean "do the contents of tab 3".

But these features need designing. I kind of put the idea out there, with things like Ctrl-Z that can bring back the selection you were at before the previous evaluation. Which is new-ish stuff (at least new to me). I know there've been workbook-style apps for a long time (I had the original MathCAD way back when, and certainly people are still building apps in this vein). I'm not trying to go too crazy with all that workbook stuff, but just try and build an ergonomic console, so playing with Rebol is more or less pleasant.

Well, while there's not much chance of us acquiring enough donations to fund expert C++ development (beyond myself, and I donate my time anyway)...I will say, that if people kick in to the Patreon for just the basic websites and documentation, I will feel more inclined to do things those people want.

$5/mo is still a donation. We'll be more confident if people put their money where their mouth is. You'd buy me a beer, so, why not fund the websites?

And then, well, maybe I'll make a code editor tab. :stuck_out_tongue:

Alright, it is the least I can do =)...


All right, looking at code editor options, we shall see.

Simplest is to scan the code for the last Rebol header in current tab and send everything from there to another tab to evaluate, or better still, to a console in a specified directory. That way we wouldn't have to update the interpreter for ren garden all the time.