[REBOL] Version incompatibilities
From: SunandaDH:aol at: 27-Nov-2005 5:59
In the Larry Wall's opinion of REBOL thread:
> It's because the Core is not able to load/next/header ? Post it to
> Rambo, it's a bug. Core should be able to load/next/header.
The problem is that Core in older versions cannot load the header of some
scripts written for more recent versions.
> By the way, why you don't use View to make the job? And why you are
> using CGI for such a thing? You should make the page when you upload
> the script and than use just a html files.
Let me try to explain the situation and the complications that arise:
REBOL.org is built as a completely dynamic website. There are 120+ Library
CGI scripts all of which run under the same UNIX version of Core......It would
be a nightmare to have them run under different versions of Core depending on
bugs and features needed. Though we may need to go that way. Running View is
not a good idea in a CGI environment.
In addition, we have nearly 700 contributed Library scripts that members of
the REBOL Community have donated to the Library. We never run those at all.
Running untrusted code on a webserver would be highly unsafe. But we do need to
do a load/header to analyse the contributed scripts in various ways. That
load/header of the contributed scripts is done by our Library CGI scripts, of
Once we've analysed a contributed script the (for example) HTML needed to
display the script in color *is* cached as you suggest. That's to make things run
Bit it is also broken in some instances these days.
Our problem (to repeat myself) is that the version of Core used to run the
Library CGI scripts is starting to have trouble loading the headers of some
That has been reported (directly to Carl)....But it is already fixed in later
versions of Core, so no fix for the version we are running.
So what we really need to do is change the version of Core used on REBOL.org
to a later version.
But there are incompatibilities in versions of Core that need to be fixed
first. A biggie is:
my-object: make object! [field1: 1]
if error? try[get in my-object 'field2] [
print "field2 does not exist"
In older versions, the error? is tripped and you see the message.
In newer versions, the get returns none, and the error is not tripped.
That's relatively trivial to fix: simply review 120+ Library CGI scripts to
see if the change in behaviour makes a difference in each of these conditions:
my-object: make object! [field1: 1] ;; no field2
my-object: make object! [field1: 1; field2: none] ;; field2 is none
my-object: make object! [field1: 1; field2: 2] ;; field2 is another value
And that's for every object where we use that idiom for checking for the
existence of a field. And, trust me, we do it a lot.
Then, once we've identified the code that is affected by the change, we
** recode it to work correctly in all three conditions
**continue to use the older Core for that script (if that is possible: the
Library is highly modular, so two scripts calling each other may need different
versions of Core)
And there may be a couple of other such incompatibilities.....I don't know,
because I haven't even started the checking process.
Any advice would be welcome!