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

CPAN for REBOL

 [1/10] from: robbo1mark:aol at: 3-Mar-2001 5:31


I would like to enquire if anybody has the time to setup and run effectively a Comprehensive Archive Network simlir to PERL CPAN for REBOL scripts. The Script Library at REBOL.com is only updated infrequently and REBOL.org appears all but dead. A properly managed resource system for REBOL scripts and examples is invaluable for REBOL's credibility as a language. Lots of great script examples are posted on this list, but is anybody making a coherent and useful resource with them? If anybody want's to discuss a CPAN for REBOL please raise your voice here! PS I've also thought of a cute name that might please a certain gentleman at REBOL TEchnologies Inc. Here's the name, it's an acronym, of course! CARLS: Comprehensive Archive REBOL Language Scripts Anybody any comments? Mark Dickson

 [2/10] from: bobr:dprc at: 4-Mar-2001 0:01


At 05:31 AM 3/3/01 -0500, Mark Dickson wrote:
>The Script Library at REBOL.com is only updated infrequently >and REBOL.org appears all but dead.
if you have an update that is overdue, bring it to my attention. there is a subgroup of us revising the rebol.org site to add more interactivity, etc. we are not looking for enhancement requests but we can accelerate true submissions of code.
>I would like to enquire if anybody has the time to setup and run >effectively a Comprehensive Archive Network simlir to PERL CPAN >for REBOL scripts.
I have been working at this for the last year. "code only when you -have- to" Ideally, to quickly evolve a CPAN ( CrAN? CARLs? ) one would like to build on the work of others. It should be trivial (and I don't mean get the source and fork a new version) to build on someone else's work and discoveries and include that work as a foundation to your own. As well, it probably needs to be automatic to include the most recent version of some other authors code within your own creations without having to edit your mods in again. REBOL's built in capability to 'DO a URL goes a long way toward this. At the same time, it should be easy to make standalone files or files with live built-in test cases and sample values. (an unadorned 'do runs the examples) Working with the "N" (network) part of CPAN I realize that unlike java, rebol does not require all things come from the same source or domain. The author is free to trust any source they wish for 'do-ing sub-modules. I see a more distributed system is possible. I would like to assist in spreading out the central-depository approach and leave the maintainer free to make updates continuously. It would be nicer if you went right to the source (maintainer) for certain modules or foundation code. In that case rebol.org may just evolve to be a directory of resources and module start points. The current problem is that there is very little discipline used on this list that would create truly modular layers or do-callable sub-modules. We get plenty of great examples with plenty of hardcoded sample values. Not much that can stand on its own yet give remote invokers the ability to refine the hard-coded values beforehand without altering the authors intended utility. I hope to change that. The work I have been do-ing (pun) tries to showcase what is possible through modular layering. " But isn't 'do-ing over the net slow? " It could be -- that is where caching can help. That's where YOU (reader) can help. This caching issue came up when I got involved with reb-world game development. Consider: do http://www.mysite.com/reboltools/hammer.r this would load hammer.r every time across the net. What if there were an object! or function: cache/do http://www.mysite.com/~bobr/reboltools/hammer.r that would check against a local version and do that one first and only check the net for something newer, say once a week? The function would have to be able to distinguish hammer.r as different from ~jeff/somesubdir/hammer.r without requiring lots of subdirs on the local machine. Perhaps a hash of the path is used. Controlling your cache 101 We have to be able to set bounds and timing ... I propose a setup function with appropriate refinements: cache/setup/size 10240000 ; nearly 10 megs cache/setup/recheck-every 24:0:0 ; once a day, default is once a week An additional requirement would be that the owner of the cache be allowed to set which dirs were used to store which domains/subpaths cache/setup/location-for "jeff/somesubd" %tmp/bargain-basement-scripts/jeff/ so that if the owner of the local machine pleased, they could remove all the files in a certain directory and only affect a specific (knowable) portion of the cache. cache/setup/save %tmp/netcache.r would save the current operating parameters (if any) out to disk. cache/setup/install %user.r would update user.r so the cache is loaded on every callup of rebol. cache/setup/improve-system-do would replace the 'do function so that all calls to 'do check the cache first if the argument is a URL and invoke the system one otherwise. This way no coding change is required for older scripts to begin working with the new caching. For other common operations: cache/clearall cache/setup/trace true cache/setup/offline true ; disable weekly recheck till back online Finally, this has to work in /core with cgi's cause that's where you get some of the most steep penalties for going back out over the net. With that spec in mind I am looking for writers. Of course the cache will itself be loaded as 'do able code! I promise great fame to the writer. If you don't have your own website to host docache.r (or whatever you choose to call it) I can find some hosting for you - very quick.
>A properly managed resource system for REBOL scripts and examples >is invaluable for REBOL's credibility as a language. Lots of great script >examples are posted on this list, but is anybody making a coherent and >useful resource with them?
ME. I have a fine list of "keepers". My plan is to make it possible to have others contribute and refine the keepers pile on rebol.org
>If anybody want's to discuss a CPAN for REBOL please raise your voice >here!
BUT NO SHOUTING (please ;)
>PS I've also thought of a cute name that might please a certain gentleman >at REBOL TEchnologies Inc. > >Here's the name, it's an acronym, of course! > >CARLS: Comprehensive Archive REBOL Language Scripts
Isn't that the name of a west coast fast-food chain? Well, at least it leads to something edible! <smile>

 [3/10] from: andrew:wxc at: 4-Mar-2001 20:03


> What if there were an object! or function: > > cache/do http://www.mysite.com/~bobr/reboltools/hammer.r > > that would check against a local version and do that one first > and only check the net for something newer, say once a week?
This is a really great idea, Bob. I'm 100% for it. Andrew Martin ICQ: 26227169 http://members.nbci.com/AndrewMartin/

 [4/10] from: andrew:wxc at: 4-Mar-2001 20:48


> What if there were an object! or function: > > cache/do http://www.mysite.com/~bobr/reboltools/hammer.r > > that would check against a local version and do that one first and only
check the net for something newer, say once a week?
> The function would have to be able to distinguish hammer.r as different
from ~jeff/somesubdir/hammer.r without requiring lots of subdirs on the local machine. Perhaps a hash of the path is used. Probably best to write the cache like this: Cache/Contents: [ "www" [ "mysite" [ "com" [ "~bobr" [ "reboltools" [ %hammer.r [ ; Script contained for http://www.mysite.com/~bobr/reboltools/hammer.r ] ] ] "~jeff" [ "somesubdir" [ %hammer.r [ ; Script for ~jeff/somesubdir/hammer.r ] ] ] ] ] ] "members" [ "nbci" [ "com" [ "AndrewMartin" [ "Rebol" [ "Scripts" [ %Index.r [ ; The contents of %Index.r. Note: don't look for this, yet... ] ] ] ] ] ] ] ] That way, if the remote file changes behaviour or requires additional files, it's really easy to adjust the cache to reflect the changes. The cache then saved to disk as a block in one file and easily loaded again, plus it's readable by humans in case of problems. Opinions? Comments? Suggestions? Andrew Martin ICQ: 26227169 http://members.nbci.com/AndrewMartin/

 [5/10] from: agem:crosswinds at: 4-Mar-2001 7:41


Could be a protocol do cache://http://www.mysite.com/~bobr/reboltools/hammer.r should use the test-panel-cache. Headers should have some [expires: 24-Mar-2001/9:56:25-8:00] Volker
>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 04.03.01, 08:03:33, schrieb "Andrew Martin" <[andrew--wxc--net--nz]> zum Thema [REBOL] Re: CPAN for REBOL:

 [6/10] from: andrew:wxc at: 4-Mar-2001 21:02


Volker wrote:
> Headers should have some > [expires: 24-Mar-2001/9:56:25-8:00]
Headers should also have a redirect: Redirect: http://Users.MySite.com/MyRebolScripts/Test.r to cover the case where the code maintainer discovers a significant change in refactoring is needed, or a change of site is required. For example, my free site provider changed from Xoom to NBCi. Andrew Martin ICQ: 26227169 http://members.nbci.com/AndrewMartin/

 [7/10] from: jeff:rebol at: 4-Mar-2001 11:47


Howdy, Bob: Hey! I would have helped, but now that you're throwing my scripts in the bargain-basement and deleting them and all... zoinks -- what a meanie! ;)
> An additional requirement would be that the owner of the > cache be allowed to set which dirs were used to store which
<<quoted lines omitted: 4>>
> could remove all the files in a certain directory and only > affect a specific (knowable) portion of the cache.
Read-thru and Load-thru in VIEW are good starting places as they use the public sandbox as a cache. They could be enhanced / wrapped. System/user/home/%public/, in REBOL's default security setting, is a world read/writable sandbox for scripts to work in. Load-thru calls read-thru. -jeff
>> source read-thru
read-thru: func [ {Read a file from the net thru the public cache. Failure returns error.} url [url! file!] /update "Force update from source site" /local path file data ][ if file? url [return read url] path: parse url "/" file: last path path: rejoin [system/options/home %public/ path/3 "/"] if not exists? path [make-dir/deep path] either all [not update exists? path/:file] [read/binary path/:file] [ data: read/binary url write/binary path/:file data data ] ]

 [8/10] from: jeff:rebol at: 4-Mar-2001 11:50


I just said:
> They could be > enhanced / wrapped. System/user/home/%public/, in REBOL's > default security setting, is a world read/writable sandbox for > scripts to work in.
Sorry, I was incorrect above: Actually, as the read-thru source shows, system/options/home/%public is the cache. This defaults to the value of system/user/home if there is no $REBOL_HOME environment variable set. -jeff ;>> source read-thru ; read-thru: func [ ; ... ; path: rejoin [system/options/home %public/ path/3 "/"]

 [9/10] from: bobr:dprc at: 4-Mar-2001 22:43


At 11:47 AM 3/4/01 -0800, Jeff wrote:
> Howdy, Bob: > > Hey! I would have helped, but now that you're throwing my > scripts in the bargain-basement and deleting them and > all... zoinks -- what a meanie! ;)
gonna have to rewrite my example to use the other goeff I know. ;) if you noticed, my example made room for more than one matchpattern to map into a subdir of the bargain basement. you are not alone, there is room for more than one tortured individual down in there. <evil snicker...> on a related topic:
> for setup/location-for ... > what if 2 diff matchpatterns resolve to the SAME dir?
hashes can have collisions, I expect some list follows the hash for the internal representation. note: I am not writing it so your internal representation may vary

 [10/10] from: bobr:dprc at: 4-Mar-2001 22:34


At 07:41 AM 3/4/01 +0000, you wrote:
>Could be a protocol > >do cache://http://www.mysite.com/~bobr/reboltools/hammer.r
I like the idea of a protocol but dont want to have to require old scripts to be modified to put the prefix (cache://) on the front. I will consider something which can cache -all- url-based fetches as a revision to the std http: protocol. I think it would be fine for a given instance of rebol in a certain subtree to maintain a cache where other instances (private copies in another dir or ones run by other people on same system) do not. yes, an expires header is good though the webserver can also return an "expires" header that should probably be observed. ;# mailto: [bobr--dprc--net]

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