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


From: bobr:dprc at: 4-Mar-2001 0:01

At 05:31 AM 3/3/01 -0500, Mark Dickson wrote:
>The Script Library at is only updated infrequently >and 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 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 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 this would load hammer.r every time across the net. What if there were an object! or function: cache/do 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
>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>