Enabling the REBOL community
[1/27] from: joel::neely::fedex::com at: 8-May-2001 19:36
Those who are familiar with CPAN (the Comprehensive Perl
Archive Network) know that it is a significant factor in
the growth -- and ease of use -- of Perl. CPAN modules
provide:
1) A community-maintained, standard namespace for modules,
(e.g., a reasonable tree-structured taxonomy which
helps the programmer remember "where" a module is).
2) A collection of mirror sites from which modules may be
obtained.
3) A simple set of mechanisms for acquiring a module and
installing it in the standard place on one's local box.
4) A means of ensuring that a module has been successfully
loaded into a running program that wishes to use it.
5) A means of controlling the effect that loading the
module has on the global namespace.
6) A rich source of examples for newcomers learning the
language, as well as for older hands wanting to polish
their style.
I've seen many useful pieces of REBOL code written and
shared during the time I've been subscribed to this list.
I've written one or two tidbits that I hope someone has
found useful. But... where is all of this good stuff???
Some of it is in the mailing list archives, some of it
is on various individual or group sites, some may be
lost. This is sad, since there are many good wheels out
there that don't need to be re-invented.
Several of us (myself included) have written our own tools
for "include"-ing a REBOL module from a local library into a
running script. However, it occurs to me that this kind of
infrastructure itself is a wheel that doesn't need to be
re-invented.
All of this musing motivates a couple of specific questions:
1) Can we -- as a community -- begin to build the same kind
of resource for REBOL that CPAN serves for Perl?
2) Can we agree on (or at least discuss) the kinds of
standards/conventions/features that would make such a
resource effective for the old hands and easy for the
new kids on the block?
Let me give an example of the kind of thing I mean in the
second point. I've been toying with the idea that a re-
usable code unit could take the form of an "anonymous"
object, something like the following:
8<------------------------------------------------------------
rebol [
title: "Component test"
file: "cmptest.r"
author: "Joel Neely"
version: 0.1.0
date: 08-May-2001
history: [
0.1.0 [
08-May-2001 {Preliminary proposal draft}
]
]
]
make object! [
x: 1
y: 42
sum: does [x + y]
]
8<------------------------------------------------------------
At some level down under the hood, this could be included into
another script by the equivalent of...
8<------------------------------------------------------------
>> testobject: do %cmptest.r
>> testobject/sum
== 43
8<------------------------------------------------------------
but also by embedding inside other objects, as in...
8<------------------------------------------------------------
>> foo: make object! [
[ red: 23
[ yellow: 48
[ caramel: do %cmptest.r
[ ]
>> source foo
foo:
make object! [
red: 23
yellow: 48
caramel:
make object! [
x: 1
y: 42
sum: func [][x + y]
]
]
>> foo/caramel/sum
== 43
8<------------------------------------------------------------
The point of the anonymity is, of course, to avoid the danger
of conflicting with other words defined by the code that uses
the unit (or with words defined by other units).
The point of the phrase "at some level under the hood" above
is that I don't think a simple "do %unitname.r" is the right
solution. I suggest that the unit/module/component management
mechanism contain the idea of a standard path (or set of paths)
so that units stored in the canonical place are accessible to
any using code regardless of where in the directory structure
it (either one!) appears.
Therefore, the actual usage might resemble something like
8<------------------------------------------------------------
unit/add-unit-path %lib/ideas
>> foo: make object! [
[ red: 23
[ yellow: 48
[ caramel: unit/do %cmptest.r
[ ]
...
8<------------------------------------------------------------
which might imply that the file cmptest.r is in the lib/ideas
subdirectory under whatever is the standard library path (or
one of the standard library paths!) on the current box. Thus
the code above wouldn't change if I move to a different box or
platform with different library placement conventions (this,
of course, assumes that */lib/ideas/cmptest.r is in the "right"
library path for the other box/platform).
Comments, suggestions, alternatives, collaborators???
-jn-
[2/27] from: john:schuhr at: 8-May-2001 22:33
Hi List:
This is a first pass at targeting what Joel suggested. I've
created a object in "unit.r" called amazingly enough 'unit.
It's something of a crude Unit Manager, I suppose.
The 'unit has a default library path of %/c/rebol/lib but
provides the suggested function for adding new paths to the
unit manager. Then whenever you want to use an anonymous
object, you just call like so:
do %unit.r
my-new-object: unit/new %cmptest
Where you are trying to create a 'cmptest object using
%/c/rebol/lib/cmptest.r
The file extension is tacked on automatically to kind of abstract
the idea that you're just "including" a reblet somewhere. This
way you can focus on "gimme a new 'cmptest object", and not
include %cmptest.r so I can get a new object
.
If there's a another library path that your object file is in:
unit/add-lib-path %/c/rebol/powerlib
my-powerful-object: unit/new %powerline
The code for %unit.r is below.. hope this helps:
8<------------------------------------------------------------------
REBOL [
Title: "Rebol Unit Manager"
File: "unit.r"
Author: "John Schuhr"
Version: 0.1.0
Date: 8-Aug-2001
]
unit: make object! [
lib-paths: [%/c/rebol/lib]
add-lib-path: func [new-path [file!]] [
append lib-paths new-path
]
new: func [requested-unit [file!] /local new-unit valid-unit] [
valid-unit: make logic! false
foreach lib-path lib-paths [
requested-unit-location: join lib-path join "/"
join requested-unit ".r"
if exists? requested-unit-location [
new-unit: do requested-unit-location
valid-unit: true
break
]
]
if equal? valid-unit false [
make error! "Invalid unit specified"
]
new-unit
]
]
protect [unit]
8<------------------------------------------------------------------
--John Schuhr
At 07:36 PM 5/8/2001 -0500, you wrote:
[3/27] from: joel:neely:fedex at: 8-May-2001 22:30
Hi, John, (and everybody else)
Just a couple of suggestions...
John Schuhr wrote:
> Hi List:
> This is a first pass at targeting what Joel suggested...
<<quoted lines omitted: 30>>
> protect [unit]
> 8<------------------------------------------------------------------
Good start! Note that the JOIN convention also allows one to write
such things as
cdf-parser: unit/new %textproc/parsers/cdf
I suggest that unit.r (or whatever we come up with) be invoked from
within user.r (or maybe rebol.r????) so that it is just always
there,
even when running interactively.
The NEW function can tightened up a tad, as follows:
new: func [requested-unit [file!] /local new-unit] [
foreach lib-path lib-paths [
if exists? requested-unit-location:
join lib-path ["/" requested-unit ".r"]
[
return do requested-unit-location
]
]
make error! "Unknown unit specified"
]
The point of the rewording to "Unknown unit specified" is to allow
for the possibility of changing the body of the loop to
if exists? requested-unit-location:
join lib-path join "/" join requested-unit ".r"
[
if error? try [
return do requested-unit-location
][
return make error!
join "Error doing unit '" [
to-string requested-unit "'"
]
]
]
if one really wants distinct and meaningful error messages.
Another suggestion, for cross-platform portability, is to start
with an empty lib-paths block. If unit.r itself is DOne in
the user.r file, then user.r could actually contain something like
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
on one box, and
do %/c/rebol/unit.r
unit/add-lib-path %/c/rebol/lib
on another. That way the code within unit.r doesn't have to be
touched if I install it on a new platform.
All that said, the larger meta-question remains, "Is this -- or
something close -- a sufficient mechanism that we could begin to
use it as a de facto standard within the community?"
If so, can we begin to think about some of the other points,
such as a conventional tree structure for the units to live in,
and (harder) do we need a way to keep units from messing with
the global namespace?
-jn-
[4/27] from: john:schuhr at: 9-May-2001 1:52
I complete agree with all suggestions made and have
incorporated them into the prototype, as such. :)
As far as using such a mechanism as a de facto
standard.. well, I say build it and they will come.
Once it's out there with a reasonably large feature
set, then it's going to get picked up, scrutinized,
twisted into pretzels and hacked into something better.
We can't really lose. A standard becomes "whatever
works for the majority".
Maybe we need an anagram for the concept. Kinda like
CPAN, but more oriented towards Rebol components?
=======================================
ERCR (pronouned ERaCeR)
Extensible Rebol Component Repository
=======================================
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.
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.
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
Just a few thoughts :)
--John Schuhr
At 10:30 PM 5/8/2001 -0500, you wrote:
>Hi, John, (and everybody else)
>
>Just a couple of suggestions...
....
[5/27] from: agem:crosswinds at: 9-May-2001 7:50
Doesn't we have read-thru?
Why another mechanism?
Then, i find cut&paste often more usefull then wrapping with objects,
since i can hack it to fit my needs.
Means, if i have a sceleton for a subdir-search i can
change it to report the files i want, with/without dirs and so on.
That flexibility pre-coded would need a lot of inbuild options.
Something which collects all this snippets with a search-engine
would be nice. Kind of Frequently Needed Code ? :)
Volker
>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 09.05.01, 06:52:50, schrieb John Schuhr <[john--schuhr--com]> zum Thema
[REBOL] Re: Enabling the REBOL community:
[6/27] from: petr:krenzelok:trz:cz at: 9-May-2001 9:01
Hi! :-)
as I can see interesting discussion started, I would like to suggest few
points to notice:
1) It would be good if Carl could state, when aprox. Rebol module system
(as doc was posted long time ago) is going to be available. The point is
- if default Rebol module behavior (isolation) would be available, there
would not be probably any need for "hidden" object behavior Joel has
described ...
2) IIRC Andrew Martin did nice component/module system. I don't know
it's URL though ... but it would be good to look into it imo.
So far ... that's all :-)
-pekr-
[7/27] from: al:bri:xtra at: 9-May-2001 20:55
> 2) IIRC Andrew Martin did nice component/module system. I don't know it's
URL though ... but it would be good to look into it imo.
It's attached, as there's a lot of new comers recently. Place it into the
directory $/Rebol/Scripts/Units/ then put:
do %../Scripts/Units/Units.r
in your %User.r file for each of your Rebol variants in the directories:
%/Rebol/Core.
and:
%/Rebol/View/
I must get an update onto my site and finish my eText and the Index web site
builder (creates a web site from plain text files).
Andrew Martin
ICQ: 26227169 http://members.nbci.com/AndrewMartin/
-><-
-- Attached file included as plaintext by Listar --
-- File: Units.r
[
Rebol [
Name: 'Units
Title: "Units"
File: %Units.r
Author: "Andrew Martin"
eMail: [Al--Bri--xtra--co--nz]
Date: 20/April/2001
Home: http://members.nbci.com/AndrewMartin/Rebol/Units/Units.r
Version: 1.3.0
History: [
1.3.0 {Added /Directory to allow specifying a base directory}
1.2.0 {Changed allowed file extensions from string! to file! data-type.}
1.1.0 "Allowed 'Unit to take blocks of filenames."
1.0.0 "Original"
]
]
Unit!: make object! [
Units: make block! 0
Do-Once: func [Filename [file!]][
throw-on-error [
Filename: clean-path Filename
all [
not found? find Units Filename
(
do Filename
append Units Filename
true
)
]
]
]
set 'Unit func [[catch] Filename [file! block!] /Directory Dir [file! url!]][
throw-on-error [
if none? Dir [
Dir: %.
]
either block? Filename [
foreach File Filename [
Do-Once Dir/:File
]
][
Do-Once Dir/:Filename
]
]
]
]
Units: function [
Directory [file!] Units [word!] Filter [block!]
][
Unit Original-Directory Headers Files Script Header
][
Original-Directory: what-dir
Headers: make block! 0
error? try [
change-dir Directory
Unit: make object! compose [
Directory: what-dir
(to set-word! Units) make block! 0
]
Files: read %.
foreach File Files [
if all [
not dir? File
any [
found? find/tail File %.r
found? find/tail File %.rip
]
][
Script: load/header File
Header: first Script
if all bind bind Filter 'Header 'File [
do Script
append Headers reduce [to set-word! Header/Name Header]
]
]
]
]
change-dir Original-Directory
set in Unit Units make object! Headers
Unit
]
Patches: Units %../Patches/ 'Patch [
not none? in Header 'File
Header/File = File
not none? in Header 'Patch
Header/Patch = Header/Name
]
Enhancements: Units %../Enhancements/ 'Enhancement [
not none? in Header 'File
Header/File = File
not none? in Header 'Enhancement
Header/Enhancement = Header/Name
]
]
[8/27] from: al:bri:xtra at: 9-May-2001 21:10
pekr wrote:
> 1) It would be good if Carl could state, when aprox. Rebol module system
(as doc was posted long time ago) is going to be available. The point is -
if default Rebol module behavior (isolation) would be available, there would
not be probably any need for "hidden" object behavior Joel has described ...
Rebol modules would be a better solution.
Andrew Martin
Black Box Rebolutionary...
ICQ: 26227169 http://members.nbci.com/AndrewMartin/
[9/27] from: al:bri:xtra at: 9-May-2001 21:39
Previously, I wrote:
> It's attached, as there's a lot of new comers recently. Place it into the
> directory $/Rebol/Scripts/Units/ then put:
Uhm, try:
%/Rebol/Scripts/Units/
instead...
Also, if you want my current directories of %Enhancements/, %Units/, and
%Patches/ for Rebol, just email me directly as there are a lot of them.
Andrew Martin
No cents Rebolutionary...
ICQ: 26227169 http://members.nbci.com/AndrewMartin/
[10/27] from: joel:neely:fedex at: 9-May-2001 7:09
Hi, Petr...
Petr Krenzelok wrote:
> Hi! :-)
> as I can see interesting discussion started, I would like to suggest few
<<quoted lines omitted: 4>>
> would not be probably any need for "hidden" object behavior Joel has
> described ...
I completely agree, but... Several months back, when I tried to
get a similar discussion going, I posted a request for RT to give us
some sort of heads-up about where MODULE was headed so that we could
take that into account in coming up with a community unit library
scheme. I assume the time pressure of all the other development
efforts (for which I'm VERY grateful!!!) took priority over either
code or documentation for MODULE.
Consequently, in the spirit of eXtreme Programming, I'm now
suggesting
that we figure out how to use what we've currently got and figure
out
how to adapt to MODULE when it becomes available.
> 2) IIRC Andrew Martin did nice component/module system. I don't know
> it's URL though ... but it would be good to look into it imo.
>
(I can't resist noting the irony that Andrew's work -- which I'm
sure
could contribute good ideas on the problem we're discussing -- has
now become a victim of that very problem...)
-jn-
[11/27] 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
<<quoted lines omitted: 8>>
> 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 :)
<<quoted lines omitted: 5>>
> 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-
[12/27] from: joel:neely:fedex at: 9-May-2001 7:48
Hi, again, Petr,
(I forgot the other point I wanted to make about MODULE...)
Petr Krenzelok wrote:
> 1) It would be good if Carl could state, when aprox. Rebol module system
> (as doc was posted long time ago) is going to be available. The point is
> - if default Rebol module behavior (isolation) would be available, there
> would not be probably any need for "hidden" object behavior Joel has
> described ...
>
If my theory is correct (that RT has been forced to put other work
ahead of MODULE in the priority list), then perhaps there's another
benefit to our working on unit management as a community.
If we collectively define (and put to use!) an open-source-like
unit management scheme, perhaps RT would use ideas from that scheme
to influence their thinking on MODULE when it bubbles back up to
the top of the priority list. I.e., if our scheme is good enough,
maybe they'd be willing to work toward having MODULE fit within
that scheme with minimum rework.
(Not that I'm suggesting that any of us are bright visionaries
on the same level as Carl, but maybe our collective candles can
shed some light on this issue...)
-jn-
[13/27] from: allenk:powerup:au at: 9-May-2001 23:24
For the curious. I've uploaded a copy of the Module REP (REBOL Enhancement
Proposal) to.
http://www.rebolforces.com/archive/rep/rep002.html
Cheers,
Allen K
[14/27] from: joel:neely:fedex at: 9-May-2001 8:15
Hi, Volker,
Fair questions, but experience with such mechanisms in other
communities can suggest some answers. A comprehensive
unit management scheme (I think I'll stick with calling it
UHURU until we can take a community vote/poll) addresses
a number of software engineering issues and community
development issues, both of which I think would benefit
REBOL. (And I know that we all agree on THAT goal!)
Volker Nitsch wrote:
> Doesn't we have read-thru?
> Why another mechanism?
>
READ-THRU might very well be *part* of the mechanism, but it
isn't a complete answer to the fundamental issues being raised.
* You still have to have a source URL. What if you don't know
which of several dozen uncoordinated volunteer sites has the
unit you need? UHURU should support multiple mirror sites
with the identical "community standard" content. When I go
to get a unit, I should be able to tell UHURU to get me a
unit by its community standard designation, and let UHURU
deal with switching mirrors due to downed servers, etc.
* The whole business of "community standard designation" is
a BIG DEAL when the volume of available content begins to
scale up. The REBOL/View desktop currently shows 28
"Reb sites". In addition, I think there are about another
dozen web sites not directly exposed as "Reb sites". If I
know that somebody implemented a nice block-to-xml output
function, I now have to keep up with (or search through)
about three dozen places it might be. What will I do when
there are a few hundred active contributors of REBOL code?
(Or, more realistically, will there EVER be a few hundred
as long as we don't have an effective publishing system?)
OTOH, if somebody writes that nice block-to-xml output
function and submits it to UHURU under the path
/xml
or
/xml/unparse
(or whatever the community establishes), then I can find it.
This subject-based (instead of contributor-based) structure
also lets me effectively (i.e., by concept) search the UHURU
library tree for new submissions that might be useful to me.
> Then, i find cut&paste often more usefull then wrapping with objects,
> since i can hack it to fit my needs.
>
You're certainly entitled to practice reuse by cut-and-paste if
it works for you (and nothing in my proposals would prevent that
practice), but it is totally unsatisfactory for my needs. One
simple example suffices for my concern.
I've written a unit that implements some generic traversal and
processing functions over the block structures produced by the
built-in XML parser. I've used that unit in many specific
applications. A while back, I thought of a way to enhance the
performance of one of its methods.
Since the unit was maintained in a separate source file and
include
-ed where needed, I was able to implement the improvement
in that one file. Every other piece of code that used it got
the benefit the next time it was executed. If I had been using
cut-and-paste, the amount of labor required to make (universally)
that improvement would have been arbitrarily larger. I don't
have time to go around and manually re-tweak N+1 copies of the
same source, pasted into N+1 different places.
> Means, if i have a sceleton for a subdir-search i can
> change it to report the files i want, with/without dirs and so on.
> That flexibility pre-coded would need a lot of inbuild options.
>
I'm not sure I understand. If we separate out the list of
paths from the core UHURU code, then let you configure it on
your own system to search a specified list of paths in a specified
order, that gives you the flexibility without having to explicitly
set options all over the place. Or did I misunderstand your point?
-jn-
[15/27] from: john:schuhr at: 9-May-2001 11:12
Comments below :)
----------
> From: Joel Neely <[joel--neely--fedex--com]>
> To: [rebol-list--rebol--com]
<<quoted lines omitted: 15>>
> 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
<<quoted lines omitted: 20>>
> 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
<<quoted lines omitted: 23>>
> 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
<<quoted lines omitted: 3>>
> >
> 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
<<quoted lines omitted: 21>>
> 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.
[16/27] from: agem:crosswinds at: 9-May-2001 18:36
Below..
>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 09.05.01, 14:15:22, schrieb Joel Neely <[joel--neely--fedex--com]> zum
Thema [REBOL] Re: Enabling the REBOL community:
> Hi, Volker,
> Fair questions, but experience with such mechanisms in other
<<quoted lines omitted: 69>>
> order, that gives you the flexibility without having to explicitly
> set options all over the place. Or did I misunderstand your point?
Well, iam a rebol-recycler.
My current source are the script-librarys from rebol.com & rebol.org.
I have a little tool (%sucher6.r on my rebsite now),
which scans its directory and all subs for some words.
Download the script-libs, put it in the root and start..
Usually i get good suggestions after some trials
(well, i know approxemately whats in the libs).
I can't remember a script which i havent changed a bit to fit my
needs.
So »download and use« would not work in my case.
On the other hand, iam a dirty programmer in rebol,
more experimenting than planning.
I often use values which are occasionally in some var in
this specific version and so on. its simply faster written.
So featuring a library-script has sometimes broken other scripts
using it.
After that iam use copys of the original script which i can rely on
and
modify freely.
That means to, i can put a lot of project-specific debug-info
in lib-scripts.
More the prototype-style than the class-hirarchie :)
I accept your system, but for me that is java:
strong controlled, well documented apis with a lot of
configuration-options to fit all needs.
It works -hm- if you are very experienced with designing
and spend some time in it.
Its not so usable with reusing ad-hoc-scripts.
They need frozen code instead of frozen aps IMHO.
And patching instead of inheritance.
Well, after all they are shorter than javadoc-apis :)
> -jn-
Volker
ps. thinking about it, i pointed %sucher6.r to %public.
Now i can look up all scripts i looked at. Interesting..
Nice i can change the dirs in a script-copy :)
[17/27] from: joel:neely:fedex at: 9-May-2001 12:42
Thanks, Allen!
Allen Kamp wrote:
> For the curious. I've uploaded a copy of the Module REP (REBOL
> Enhancement Proposal) to.
> http://www.rebolforces.com/archive/rep/rep002.html
>
> Cheers,
>
A quick browse confirms my vague memory that it would likely be
not-too-difficult to take an object!-based unit management system
and enhance it with the additional benefits of module! once that
capability became available.
It appears to me that module! would address the namespace safety
issues touched on recently in this thread.
-jn-
[18/27] from: ryanc:iesco-dms at: 9-May-2001 10:58
I was just thinking about this over the the weekend, almost exactly as you have written
Joel. I was amazed to read your post. The simple make object! idea is
what I came up with too. I strongly agree that such a system would especially benifit
our community.
I really would like to know RT's time frame for the release of thier module system.
--Ryan
Joel Neely wrote:
> Those who are familiar with CPAN (the Comprehensive Perl
> Archive Network) know that it is a significant factor in
<<quoted lines omitted: 119>>
> [rebol-request--rebol--com] with "unsubscribe" in the
> subject, without the quotes.
--
Ryan Cole
Programmer Analyst
www.iesco-dms.com
707-468-5400
I am enough of an artist to draw freely upon my imagination.
Imagination is more important than knowledge. Knowledge is
limited. Imagination encircles the world.
-Einstein
[19/27] from: depotcity:telus at: 9-May-2001 11:24
This topic needs to address legal issues such as copyrights, licenses etc.
Are all modules free?
TBrownell
----- Original Message -----
From: "Ryan Cole" <[ryanc--iesco-dms--com]>
To: <[rebol-list--rebol--com]>
Sent: Wednesday, May 09, 2001 10:58 AM
Subject: [REBOL] Re: Enabling the REBOL community
> I was just thinking about this over the the weekend, almost exactly as you
have written Joel. I was amazed to read your post. The simple make object!
idea is
[20/27] from: joel:neely:fedex at: 9-May-2001 14:21
Hi, Volker,
Volker Nitsch wrote:
> Well, iam a rebol-recycler...
> I can't remember a script which i havent changed a bit to fit my
> needs.
> So »download and use« would not work in my case.
>
> On the other hand, iam a dirty programmer in rebol,
> more experimenting than planning.
>
Sure, I understand. But to me, that's the difference between doing
R&D and production-ready software engineering (and I do both).
When I'm in R&D mode, I fiddle and tweak and stick in debug stuff
to see what's going on (or to see what's NOT going on ;-). In
that mode, there's certainly a role for cut-and-paste. However,
once a unit of code is working (as far as I can tell at that point)
I want to be able to re-use it as a black box, with no cut/paste
effort and without messing with its innards.
Finally, when using it in mode two above, if I do find something
that needs fixing/improving/enhancing, I want to be able to do so
with neither breakage of existing usages nor the need to remember
where I used it and re-cut-and-paste to propagate the changes.
(Note that I can't simply use grep to do that remembering for me,
as I have code in multiple directores on multiple boxes.)
Not to belabor the point, but I'm perfectly happy for cut/paste
to exist for some purposes (and do it sometimes myself) but I
consider it totally inadequate as a basis for large-scale software
engineering involving multiple boxes, platforms, projects, people,
and contributors.
The last time I had work done on my house, the carpenter went to a
lumber store (a known "place") and bought some standard,
off-the-shelf parts with known characteristics and installed them.
He did have to trim a couple of pieces of molding that fit around
the door, and that's OK. However, I would have been VERY annoyed
if he had chopped down a tree, rip-sawed it, planed it into boards,
build a gluing jig, dug up some sand, melted it into glass, and
assembled all of that into a hand-built door. Those can be bought
from the store and used as delivered.
> I accept your system, but for me that is java:
>
Let me suggest instead that my model here is Smalltalk; there's
one OrderedCollection class, used throughout the system. If you
need a variant of it, you subclass it and use that subclass. If
you need to modify it (e.g., you discovered a way to speed up
an internal hashing function, or some other such improvement),
you modify the one copy and all usages of it from that point
forward get the benefit of the improvement.
What one DOESN'T do is keep cloning the system image to make
different versions with slightly different variations on
OrderedCollection, with all the overhead (storage-wise and
mental-wise) that would be required,.
> It works -hm- if you are very experienced with designing
> and spend some time in it.
>
IMHO the best way to get experience in design is to have to
do so. Reminds me of the an old saying,
Good judgment comes from experience;
experience comes from bad judgement!
> Its not so usable with reusing ad-hoc-scripts.
>
Well, if you talk to almost anyone in the Smalltalk user
community, I suspect they'd tell you that Smalltalk is very
good BOTH for ad-hod R&D and for production development. I
know that the Perl community would make the same assertion
for Their Favorite Langage.
I don't want to forbid anyone the right to experiment, play,
and cut-and-paste. I just don't want to be told that I'm
required to do so. I strongly feel that advancing beyond
that level will help foster the wider use of REBOL.
Thanks for the stimulating discussion!
-jn-
[21/27] from: joel:neely:fedex at: 9-May-2001 14:25
Hi, Terry,
Good point!
Terry Brownell wrote:
> This topic needs to address legal issues such as copyrights,
> licenses etc. Are all modules free?
>
As I understand it, submitting code to CPAN is de facto making it
available to the Perl community for re-use. We could certainly
(with appropriate legal help and language) make such a release
a prerequisite for any code submitted to UHURU.
And, of course, anyone who wants to write code that they keep
private and proprietary has a perfect right to do so; they just
can't submit that code to an open library! (You can't have your
cake and give it away, too!)
-jn-
[22/27] from: sembazuru:crosswinds at: 10-May-2001 14:46
Hello Joel Neely
On 09-May-01, Joel Neely wrote:
JN> Hi, Terry,
JN> Good point!
JN> Terry Brownell wrote:
JN>>
JN>> This topic needs to address legal issues such as copyrights,
JN>> licenses etc. Are all modules free?
JN>>
JN> As I understand it, submitting code to CPAN is de facto making it
JN> available to the Perl community for re-use. We could certainly
JN> (with appropriate legal help and language) make such a release
JN> a prerequisite for any code submitted to UHURU.
OK, I have a question here.
I really like the ideas that are being thrown around here, but what
about security? If it is set up to automagically (or at least with a
requestor) download the latest version if available, how does one
protect from some lamer uploading a trojaned update? Or even making
sure that the first time you download a module it isn't trojaned? (Us
Amiga-folk have been having a bit of trouble with this sort of thing
over on AmiNet whenever Amiga makes an announcement that some people
don't agree with...) How does CPAN deal with this? How should UHURU
deal with it?
Pax
--
Member: Team AMIGA --} WatchDog
Fingerprint: 2C 8A 03 3C D6 D3 32 7F (Chris Elliott)
66 0F 9B 9F 03 77 1D 85 PGP Key ID: A6A79259
Keys (and other stuff) are at http://www.crosswinds.net/~sembazuru
<tsb>Software suppliers are trying to make their software packages more 'user-friendly'....
Their best approach, so far, has been to take all the old brochures, and stamp the words,
'user-friendly' on the cover. -- Bill Gates
[23/27] from: g:santilli:tiscalinet:it at: 17-May-2001 9:56
Joel Neely wrote:
(Just noticed this...)
> Another suggestion, for cross-platform portability, is to start
> with an empty lib-paths block. If unit.r itself is DOne in
I'd start with system/home/lib or something like that. This way
the user won't even need to add paths in the most common case.
(Also, notice that lib-path/:file is equivalent to join lib-path
file and is IMHO more readable.)
Regards,
Gabriele.
--
Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[24/27] from: joel:neely:fedex at: 17-May-2001 7:44
Hi, Gabriele,
Gabriele Santilli wrote:
> (Just noticed this...)
> > Another suggestion, for cross-platform portability,
<<quoted lines omitted: 3>>
> This way the user won't even need to add paths in the
> most common case.
That sounds like a good plan, if we could get RT to support
the effort officially. I guess I was just thinking about
things we could do without adding to their to-do list.
> (Also, notice that lib-path/:file is equivalent to join
> lib-path file and is IMHO more readable.)
>
Yes. Thanks!
-jn-
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
[25/27] from: g:santilli:tiscalinet:it at: 18-May-2001 11:32
Joel Neely wrote:
> > I'd start with system/home/lib or something like that.
> > This way the user won't even need to add paths in the
> > most common case.
>
> That sounds like a good plan, if we could get RT to support
> the effort officially. I guess I was just thinking about
> things we could do without adding to their to-do list.
Actually I should have written system/options/home/lib... It is
already there and works!
Sorry for the typo...
Regards,
Gabriele.
--
Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[26/27] from: joel:neely:fedex at: 18-May-2001 6:39
Hi, Gabriele,
Gabriele Santilli wrote:
> Actually I should have written system/options/home/lib...
> It is already there and works!
>
>> system/options/home/lib
== %/home/jn/bin/lib
>> change-dir system/options/home/lib
** Access Error: Cannot open /home/jn/bin/lib/
** Near: change-dir system/options/home/lib
>> value? system/options/home/lib
== true
>> exists? system/options/home/lib
== false
>>
Well, it appears that
'system/options/home/lib
exists, but that's no guarantee that
exists? system/options/home/lib
works. I suppose the above expression could serve as the
acid test for whether to include it in the UHURU path list.
Your thoughts?
-jn-
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
[27/27] from: g:santilli:tiscalinet:it at: 18-May-2001 21:49
Hello Joel!
On 18-Mag-01, you wrote:
JN> Well, it appears that
JN> 'system/options/home/lib
JN> exists, but that's no guarantee that
JN> exists? system/options/home/lib
JN> works. I suppose the above expression could serve as the
JN> acid test for whether to include it in the UHURU path list.
JN> Your thoughts?
if not exists? system/options/home/lib [
make-dir system/options/home/lib
]
;-)
Or we can just continue using system/options/home/public, where
read-thru will put what is downloaded. I know that the files there
are organized by site and not like UHURU should organize them,
but UHURU's organization could be just logic, not physic.
Also, I've been reading T. B. Lee's article on the semantic web,
and I think REBOL has all that is needed to make that happen (as
Carl said, too); UHURU could be REALLY MUCH better than CPAN. :)
Regards,
Gabriele.
--
Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted