[REBOL] Re: Enabling the REBOL community
From: john:schuhr at: 9-May-2001 11:12
Comments below :)
----------
> From: Joel Neely <[joel--neely--fedex--com]>
> To: [rebol-list--rebol--com]
> Subject: [REBOL] Re: Enabling the REBOL community
> Date: Wed, 09 May 2001 07:42:41 -0500
>
> 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
Sounds good to me :) Anything catchy is good.
> >
> > 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.
Well, I was thinking that a unit library would only be
located at the bottom of the hierarchy. Which is to say
the %text/textproc path isn't actually a library, but
contains several libraries. So if one were to specify a
non-library path, then the Unit Manager would assume you
mean to update all contained libraries recursively. But
you may have the right of it by using a seperate function
to eliminate any ambiguity.
> 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.
I think the UHUHRU part of the path should be part of all
units paths. So the cdf-parser would be called:
UHURU/libraries/text/textproc/parsers/cdf.r
And it would be up to the user as to where the UHURU home
resides on their box. So they could have it in
/usr/local/rebol/lib
making the overall path into /usr/local/rebol/lib/UHURU...
and they would use the following in their rebol.r:
unit/add-lib-path %/usr/local/rebol/lib
But unless the unit manager does recursive path searching
you would have to specify:
my-cdf-parse: unit/new UHURU/libraries/text/textproc/parsers/cdf
Ick. Thoughts?
> 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).
I agree with the "no default policy but feel free to create
your own with the given feature set" approach :)
> > 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?
Good question. It's wishful thinking.
> 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.
We may have to rely on RT for some mechanism in that
regard. Unless someone out there knows a nifty hack
for just such a thing.
