Archived Scripts


I have a proof-of-concept up now, for integrating the archived scripts into the new site.

Try switching the version (in the top-left corner where it says "Archived") and you can see how the Documentation section is able to seamlessly switch between the two different looks, and also have two different types of content.

So this is working pretty nicely, but I have run into a lot of questions (and potential issues) too ...

Do you like the retro look?

I am having a hard-time deciding if it is really, really bad or really, really good :rofl:

It's sort of a mashup of @rgchris site and Rebol Desktop. However, I think I took it too literally and got stuck in the 90's. Then again, maybe the retro feel is tugging at your heart strings. Turn on some Cobain and then let me know what you think!

Should the script use different Prettify highlighting?

I think it's clashing a bit with the rest of the archived page. Using the colors @rgchris used on his site would look better (assuming we want to keep the page's color scheme, or some variation of it). But then again, I wasn't sure if we wanted to keep all code examples looking the same on the site (regardless of if it was archived or not). Any opinions on this?

Do we have the rights to use the old Rebol logo and/or Rebol Desktop icons?

I'm guessing we don't, but I thought I would ask. If we don't, then what other logo would we use?

Do we need to keep all old links?

I got the following links redirecting properly ...

However, I noticed there are a lot more links in the old Script Library. For example ...

Do they all need to keep working? I think some of these are going to be challenging, if not impossible, to get working on a static Github site.

What about the links on the rest of the site (i.e. AltME, Mail List, Articles, Search, etc)? If we take over the domain one day, are all these links expected to keep working? This would be possible if we had control over the web server, but it is not possible on Github... which leads me to my next question.

Are you okay with JavaScript redirects?

A static Github site can not use HTTP redirects, i.e. it cannot send back a 301, 302 or 303 header to the client. I had to get those redirects working by using a "meta refresh" tag, which means all redirects are sending back a 200 OK. It works, but it's not really the way they should be done. Also, on top of that, these old links have parameters that identify the script to load up (e.g. ?script=form-date.r), and the only way to parse that on a static site is by using JavaScript.

The page loads, I use JavaScript to grab the name of the script, and then using JavaScript again, I write the "meta refresh" tag to the HTML, and this tells the browser to send me to the correct /docs/archived/scripts/ page. So this solution will work, but only with a browser, because it has the ability to run JavaScript. If a HTTP cURL client or Rebol script was loading the page, it would not get redirected properly.


I'll call it good--glad to see you're getting into it! :slight_smile:

It's fun, and a consistent truth-in-advertising direction for the site. Anyone using those scripts non-ironically will be using Rebol2...and that's the look of the viewtop...with no expectations for change. (In Carl's overtures to possibly returning to Rebol work someday, he has said the GUI is not what he's interested in.)

Absolutely. The whole point of the archival site is to distinguish it, and ideally it could look good in its own right. (Not trying to make it look bad, just dated. If it can look dated and good, that's ideal.)

I don't actually think of the black and white logotype as being deprecated/outdated/"old". As far as I'm concerned it's still applicable, the [o] icon is just what I think of as the "shorter" version.

Some riff on the old app icon with which people are familiar could be neat, something in this spirit:

I don't think rights issues would be much of a concern. IIRC, @rgchris even drew that R logo (with REBOL2/View code).

But definitely great if you can avoid having two codebases, and just doing this through a theme!

It would be nice if the links still did something. But the database-y searches for scripts-by-author or otherwise do not need to actually do the searches. Perhaps just have a table of links from username to their current web presence for Rebol-or-otherwise related things, e.g.

If they have anything they consider notable, they can curate it on their own time. And if that page were in GitHub, people could update their links to whatever they liked.

(My suggested concept for was an official source of scripts, where the community had kind of taken responsibility and ownership for the scripts, and adopted them. The "standard library", so to speak. You wouldn't go to it and look for "scripts by author", there might even not be any authorship on the modules. For this reason, I might suggest redirecting all of this under instead of

I'm not sure how much of a problem that's going to be. Presumably the few people affected loading scripts from a do of a URL from can change their URLs to raw.github, and keep going. If someone reports a specific zombie site relying on a fetched URL, stubbing in a page to serve for that one specific link should be good enough.

As I see it, you're doing a lot of hard work here. So anyone who has a problem with a detail like this, the burden is on them to come up with a solution--or pay someone to solve it. :slight_smile:


Looks great! Much better than the original!


@hostilefork and @BlackATTR, thanks for the feedback guys, I appreciate it !

I will proceed with getting the rest of the scripts imported then, update the Prettify highlighting for the archived code examples, and look into getting those other Script Library links working too.


The Prettify highlighting has been updated now, and after a lot of struggle with character encodings in Jekyll, and conflicts with their liquid template syntax, I was able to finally import all the archived scripts. I also wrote a rebol script to parse the script headers and add Jekyll front matter to them too, and this will allow us to have pages where we can automatically display them sorted by author, category and license.

So that is all good, but Jekyll now takes 2 1/2 minutes to generate the site, lol. It is painfully slow. So I am currently looking into this issue ...


Nice! It's managing to look "retro" without being too ugly. (I think the contrast between the areas is sufficient without needing dark borders too, though if it's considered to be part of the "look" then the borders might should be on everything.)

A slow update is better than updates that never happen, or can't be made at all (!)

From my point of view, if a background job regenerated pages intermittently (every half hour, with a possible ability for administrators to synchronously override) that would be enough. I mean that about the documentation; I'm not particularly concerned about the archival site.

Just a reminder that what might be personally disappointing on the surface--in terms of performance for something of this nature--may not bother us that much!


I got the Jekyll generation time down to 30 seconds now. It was mostly being caused by having all the scripts display on the left-hand nav, but that was only a temporary thing while I was experimenting with stuff. After removing that, it got faster.

Anyway, all the scripts are imported now, and I have them grouped by domain.

I am not sure If I like color scheme for the tables that the scripts are listed in, still mulling that over. I am also still working on getting the left-hand nav to display the domain categories, only AI is up at the moment.

Updates are going to be a bit slow for a little while. I have been busy planning my wedding anniversary recently, which is coming up in June.

Does anyone know if the script documentation files have been archived anywhere? Specifically the HTML version.


No worries if you have to take time off, we'll try and save some work for you. :stuck_out_tongue:

Script archive still a fairly secondary concern. Though with pretty much most things I usually go back to "serving the purpose". Is the purpose to be found on Google? To preserve old inbound links? Who's looking at a long table and browsing in that form, and why?

If people are going to actually be reading something, you probably want it more like the code with a solid background. Design-wise I usually think lines are to be avoided when the line and surrounding spacing is as big as the things being separated. Better to work with negative space...


All the domain categories are up now, and I tweaked the look of the table a bit too.