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

[REBOL] Bugs, patches and distributed systems

From: sunandadh:aol at: 25-Mar-2002 6:20

Brett:
> I was thinking some more about the issue of bugs, patches and > distributed systems.
A large part of the problem is that RT only release a new version once a year or so. In the meantime, we all work round the problems or tweak'n'trade Rebol patches. It'd make more sense if RT adopted more regular "point-releases" to address bugs. But that'd have a drawback -- we'd all be forever testing the new releases to check that the fixes don't break our applications. Here's a suggestion that works at least for mezzanine-level system functions. There should be something like Patches.r in my application directory. I can download the most recent Patches.r from RT as often as I like. Patches.r Isn't just the latest source for each function. It's cleverer than that. If a function has been modified three times since the major release, patches.r contains all three versions. Rebol has some start-up magic that lets me accept or reject the patches I need, e.g. rebol -p [layout 1.2.1 view 1.2.2 make-face original] the -p says apply the patches according to the following block. The block is pairs of function names and the version required. Patches to the system object could work in the same way -- the patch would need a symbolic name so we could select the ones we want. In the ideal world, there would be some way of generating a bug list and prerequisite conditions ("patch 2 to function X required patch 1 to function Y") from the data structures in patches.r. Native functions would be a bit harder to patch in this way. But I'm sure RT can think of something along the same lines. Sunanda.