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

Bugs, patches and distributed systems

 [1/5] 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.

 [2/5] from: hallvard:ystad:helpinhand at: 25-Mar-2002 13:24


Dixit [SunandaDH--aol--com] (12.20 25.03.2002):
>It'd make more sense if RT adopted more regular "point-releases" to address >bugs.
<<quoted lines omitted: 3>>
>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 alone won't do, because we need to specify what version of rebol our programs will work on. Having predefined milestone releases every 6 months and irregularly releasing patches inbetween could be a good solution, I think. This is how the OpenBSD team works, and in my opinion, that works fine. ~H

 [3/5] from: sunandadh:aol at: 25-Mar-2002 9:51


Hallvard:
> Patches alone won't do, because we need to specify what version of rebol
our
> programs will work on.
I've run into that problem myself -- someone started telling me an application was failing for no reason I could duplicate. It turned out they'd accidentally gone back to using View1.2.0 rather than 1.2.1. I added these lines at the top of the application to detect the version needed: if "1.2.1" > copy/part to-string system/version 5 [request/ok "Sorry. We need at least Version 1.2.1 of Rebol" quit ] If you have concerns about running the right version, this is an easy fix -- though I agree RT could come up with something more elegant. Distributed systems will also come across the problem where my code executes one of your scripts but our scripts disagree on what patches/versions we need. I don't see any easy solution for that other than one of us makes our code compatible with the other's Sunanda.

 [4/5] from: jason:cunliffe:verizon at: 25-Mar-2002 7:46


> 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
<<quoted lines omitted: 4>>
> lets me accept or reject the patches I need, e.g. > rebol -p [layout 1.2.1 view 1.2.2 make-face original]
RVS - rebol versioning system great idea! Recently I have been reading up on CVS [concurrent versioning system] and wondering how to base a rebol/vanilla dynasnip extension on the idea. I have been interested in how it might work for media content, sequences, collections, metadata and associations. ..Kind of general purpose VCR for media-oriented metadata. The reason I especially like to do this in rebol is because it seems to encourage a very granular approach. Simplexity system where each little piece of rebol is just smart enough. But a powerful whole system set of behaviors can emerge. The way rebol treats everything as data makes this seem more 'natural'. A fascinating article for inspiration is the new[ly] [named] science of 'Proteomics'. Check out the April issue of Scientific American Magazine for an clear introduction. ./Jason

 [5/5] from: chalz::earthlink::net at: 25-Mar-2002 23:21


> if "1.2.1" > copy/part to-string system/version 5 > [request/ok "Sorry. We need at least Version 1.2.1 of Rebol" > quit > ]
While initially reading about the REBOL [] block in a script a while back, I remembered a list of 'suggested' fields to use, one of which being a Requires block. In a perfect world, people would open up the scripts they were about to run and give them a once-over, then verify that they have all that's required and approve of the general operation. In a perfect world. But yeah, that is a pretty quick and easy fix.
> Distributed systems will also come across the problem where my code executes > one of your scripts but our scripts disagree on what patches/versions we > need. I don't see any easy solution for that other than one of us makes our > code compatible with the other's
Which is frequently what you have to do right now anyways, unless people agree to use similar setups, layouts, libraries etc ahead of time. This could be another good place for the online library - scriptA and scriptB are working together, each one requires different patch sets, each one can just call up the patches it needs on the fly. Again, this requires being connected or having easy local access to a copy of the DB... oy. -C

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