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

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