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

[REBOL] Re: Enabling the REBOL community

From: joel:neely:fedex at: 9-May-2001 7:42

Hi, John, John Schuhr wrote:
> Maybe we need an anagram for the concept. Kinda like > CPAN, but more oriented towards Rebol components? > > > ERCR (pronouned ERaCeR) > Extensible Rebol Component Repository > >
How about acronyming into Swahili, and calling it UHURU (which means "freedom", an appropriate meaning for a tool to unchain the power of REBOL). Universal Home for Useful Rebol Units
> Another possibility had popped in my head briefly of > rigging the Component Manager (working term) to update > modules from a central location (hence the Repository > part of ERCR) on demand. Kinda like: > > unit/update-lib %ERCR/libraries/text/textproc/parsers > ;or using the working term "Rebol Component Manager" > rcm/update-lib %ERCR/libraries/text/textproc/parsers > > This would cause the CM (Component Manager) to hit > against the ERCR and look for new versions of the > "ERCR/libraries/text/textproc/parsers" library, > based on version numbers in the REBOL headers or > some such thing. >
Sure. Add to that the idea of updating an entire branch of the unit library (for those with the bandwidth and time ;-) similar to unit/update-all %text/textproc/ ;or, using the alternate acronym ;-) UHURU/update-all %text/textproc/ which would recursively add all units AND branches (aka directories) under that prefix. Incidentally, I also assume that the "ERCR/libraries" (or "/usr/local/bin/rebol-lib/UHURU/" or whatever) would be supplied automatically, based on whatever library path(s) had been set up for the specific box. This raises an interesting issue: suppose one had the following code in user.r or rebol.r do %/usr/local/bin/rebol-lib/unit.r unit/add-lib-path %/usr/local/bin/rebol-lib unit/add-lib-path %/home/myacct/rebol-dev/lib There are now several policy options for what it means to say unit/update-all %text/textproc/ with multiple paths set up: 1) Assume that the first path in lib-paths is the public library, and add everything there. 2) Search all paths until finding one that contains a subpath of "text/textproc/" and add everthing there. 3) Search all paths, finding EACH one that contains a subpath of "text/textproc/" and add to all such. 4) Ask the user which path(s) to add into. If no such sub-path could be found anywhere, either 5) Fail the update attempt, with appropriate notification. 6) Assume that the first path in lib-paths is the public library, and add everything there. 7) Ask the user which path(s) to add into. I don't like (4) and (7), as they interfere with the ability to run a cron job in the middle of the night to update my libraries. Perhaps the best policy is "no policy -- specify which you want with a refinement" with some defaults, such as (1) and (6).
> Naturally, all components submitted for inclusion into > the ERCR would need to meet certain specifications for > providing documentation, standard interfaces and respecting > namespaces. Perhaps each component could be _forced_ > to use a local context. >
How? One of the nice features of Perl's "use <module>" mechanism is that one can explicitly indicate which names from the module should be exported into the current namespace. For example (using hypothetical REBOL syntax), it would be nice to define a unit as unit [simpson montecarlo] [ hiddenfunc1 func ... ;; details omitted ... hiddenfuncN func ... ;; details omitted simpson: func ... ;; details omitted montecarlo: func ... ;; details omitted ] then utilize it via math-stuff: unit/new %math/integration ... math-stuff/simpson ... math-stuff/montecarlo ... or via math-stuff: unit/new/import %math/integration [ simpson montecarlo ] ... simpson ... montecarlo ... but strictly WITHIN the current namespace.
> As for a categorical tree for components, all I can > suggest is that we get started and go from there :) > > For example: > ERCR/libraries/network/protocol/ertp.r > ERCR/libraries/text/string/similarity.r > ERCR/libraries/text/string/shellquote.r > ERCR/libraries/text/textproc/parsers/cdf.r > ERCR/libraries/text/textproc/algorithms/soundex.r > ERCR/libraries/text/textproc/generators/pdf.r >
I agree with the above, provided we can suppress the ERCR/libraries prefix, and leave it up to each platform/box to configure individually where in its directory structure the library tree is rooted. -jn-