Version incompatibilities

The problem is that Core in older versions cannot load the header of some scripts written for more recent versions.

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 course. 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 faster. 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 contributed scripts. 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 either: ** 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! Sunanda.

== none

== []

** Script Error: get expected word argument of type: any-word object ** Near: get none which will give you back that error. Sac> my-object: make object! [field1: 1] ;; no field2 Sac> my-object: make object! [field1: 1; field2: none] ;; field2 is none Sac> my-object: make object! [field1: 1; field2: 2] ;; field2 is another value Note that if you checked the result of IN instead, you'd have no problems with any of those cases. Sac> Then, once we've identified the code that is affected by the change, we Sac> either: Sac> ** recode it to work correctly in all three conditions Sac> **continue to use the older Core for that script (if that is possible: the Sac> Library is highly modular, so two scripts calling each other may need different Sac> versions of Core) ** patch the current Core so that it behaves like the old one. ;) (In the few cases when you're not going to be able to do it, you'll have to fix the scripts.) Regards, Gabriele. -- Gabriele Santilli <gabriele-rebol.com> --- http://www.rebol.com/ Colella Chiara software division --- http://www.colellachiara.com/

Neat. That would probably have bypassed *this* problem if we'd used that idiom. Bit it may have led to slightly more convoluted code in a case like this: attempt [return get in my-object 'field] ;; code here for initialising my-object/field Either way, the substantive issue is that of behaviour changes that make it harder to migrate REBOL code to newer versions. 'get is just the one we've found so far. We've also hit the odd platform inconsistency that means we have to swerve around issues on different platforms (the live site runs UNIX. The test servers are Windows and MAC OS), Surprisingly few of those, luckily.

The potential problem there is there may be some built-in mezzanine code that expects the new behaviour -- after all, Carl made the change for some reason. So we'd have to do some fairly extensive testing to check we weren't introducing bugs at that level.

Ideally, there'd be a standard way to do that: system/compatibility/get: [accept-none: false] Ditto for other changes in behaviour -- like head reverse. Though (as noted above) it may need RT-supplied mezzanines to operate in a different system/compatibility context to application code. Sunanda.

I'd like to revise my analysis here, having looked a little closer: It's not load/header/next (at least I don't think it is any more). It's an oddity with parse. If you use this script from the library: http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=col or-code.r and ask it to colorize a simple script like this.... simple-script: {rebol [] does []} ....It's going to crash in older versions -- including the version of REBOL.exe we use for CGIs in the Library:

** Script Error: Invalid argument: ?native? ** Where: color-code ** Near: parse/all text blk-rule: [ What is strange is that color-code *does* work for all but two of the scripts in the Library, despite tripping over on such a simple example. If anyone has any insights into how to patch the parse to work around whatever the problem is, I'd be very grateful. To summarise our constraint: upgrading the version of REBOL.exe used in the Library is a lot of pain, so if we can get color-code to work on the existing version, it will be a big step in the right direction. Thanks! Sunanda.

Thanks. That looks highly likely. Seems we have two problems: 1. color-code.r only works for versions of REBOL that include 'break in the parse dialect -- as you've just spotted 2. No version of REBOL can load a header for a script that has a 'needs entry for a later version: load/header {rebol [needs: 99.99.99]} ;; fails with all versions I know of. The parse problem blinded me to the load problem -- hence my inaccurate statement about load/header not being a problem (see earlier in this thread). There is an old RAMBO report outstanding about load/header (3968) but it doesn't cover this case, so I've just added a new one. We've applied a bit of lateral thinking to the problem -- it now looks like everything works at REBOL.org despite the obstacles.

[rebol[] split-script: func [string /local left hdr right] [ ; first "[" must be the headers one. ; maybe needs more checks? left: find string "[" set [hdr right] load/next left left: copy/part string left reduce [left hdr right] ] join-script: func [parts] [ rejoin [parts/1 mold parts/2 parts/3] ] if not system/script/args [;demo probe s: split-script probe mold/only [ rebol [ title: "my-title" comment: ".." ] print "Hello world" ] s/2: union/skip s/2 [ Title: "No title" Lib-header: [.. default ..] ] 2 probe join-script s ] ]

-- -Volker Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem. David Wheeler

[snip]

http://polly.rebol.it/test/test/compat/color-code.html

[snip] -- -Volker Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem. David Wheeler

Nice work! Thanks. We've used a similar sort of "cheat" to your split-code to load headers that won't load other ways. In both your case (as you've noted) and ours, the added code can be fooled by text that precedes the REBOL[] header....But not many people do that *and* have a needs: header; so the two approaches work except in very rare circumstances. I've added a discussion note to the color-code.r script pointing people to your improved version: http://www.rebol.org/cgi-bin/cgiwrap/rebol/discussion.r?script=color-code.r Thanks again, Sunanda.