Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Version incompatibilities

 [1/9] from: SunandaDH:aol at: 27-Nov-2005 5:59


Oldes: 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 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.

 [2/9] from: gabriele:colellachiara at: 27-Nov-2005 12:48


Hi Sunanda, On Sunday, November 27, 2005, 11:59:41 AM, you wrote: Sac> But there are incompatibilities in versions of Core that need to be fixed Sac> first. A biggie is: Sac> my-object: make object! [field1: 1] Sac> if error? try[get in my-object 'field2] [ Sac> print "field2 does not exist" Sac> ] May I say, that coding style sometimes matters a lot. Even back then when GET did not accept NONE, I would have coded that as: either in my-object 'field2 [ my-object/field2 ] [ print "field2 does not exist" ] Throwing errors is always going to be more expensive, so I really tend to avoid doing that when I just want to do a check. (Of course, if you just wanted to delay the check, that's a different issue; but it's not the case above.) Anyway, a possible solution to your problem is:
>> get none
== none
>> remove back tail third third :get
== []
>> get 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/

 [3/9] from: SunandaDH::aol::com at: 27-Nov-2005 16:00


Thanks for the suggestions..... Gabriele:
> Even back then when GET did not accept NONE, I would have coded > that as:
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.
> Anyway, a possible solution to your problem is:
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.
> ** patch the current Core so that it behaves like the old one. ;)
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.

 [4/9] from: SunandaDH:aol at: 3-Dec-2005 16:55


Sunanda:
> The problem is that Core in older versions cannot load the header of some > scripts written for more recent versions.
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:
>> color-code simple-script
** 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.

 [5/9] from: gabriele:colellachiara at: 5-Dec-2005 15:33


Hi Sunanda, On Saturday, December 3, 2005, 10:55:40 PM, you wrote: Sac> ** Script Error: Invalid argument: ?native? Sac> ** Where: color-code Sac> ** Near: parse/all text blk-rule: [ Just a wild guess, but could it be BREAK inside the parse rules? If you're running a version of Core without the BREAK keyword in PARSE, then it would probably consider it an invalid native! argument. Regards, Gabriele. -- Gabriele Santilli <gabriele-rebol.com> --- http://www.rebol.com/ Colella Chiara software division --- http://www.colellachiara.com/

 [6/9] from: SunandaDH:aol at: 16-Dec-2005 5:01


Hi Gabriele,
> Just a wild guess, but could it be BREAK inside the parse rules?
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.

 [7/9] from: volker:nitsch:gm:ail at: 16-Dec-2005 15:57


On 12/16/05, SunandaDH-aol.com <SunandaDH-aol.com> wrote:
> Hi Gabriele, > > Just a wild guess, but could it be BREAK inside the parse rules?
<<quoted lines omitted: 5>>
> for a later version: > load/header {rebol [needs: 99.99.99]} ;; fails with all versions I know of.
[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 ] ]
> 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).
<<quoted lines omitted: 5>>
> To unsubscribe from the list, just send an email to > lists at rebol.com with unsubscribe as the subject.
-- -Volker Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem. David Wheeler

 [8/9] from: volker:nitsch::gmail at: 16-Dec-2005 16:21


On 12/16/05, SunandaDH-aol.com <SunandaDH-aol.com> wrote:
[snip]
> 1. color-code.r only works for versions of REBOL that include 'break in the > parse dialect -- as you've just spotted
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

 [9/9] from: SunandaDH:aol at: 17-Dec-2005 5:00


Volker:
> split-script: > color-code:
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.

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted