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

serious proposition...WAS: RE: Standards

 [1/12] from: maximo::meteorstudios::com at: 6-Nov-2003 17:36


Well, I'm sort of scared of letting it out of the bag, but here is a complete answer. I'd like an OFFICIAL, community blessed library/module standard. Some of you are aware of my idea, some have even tried the ancestor of the new tool, steel's open-library function... The new tool is an object. It makes creating modules even easier and is also more mindfull to the rebol way of thinking, as it uses the rebol header as the library's header, for example. I still have no official name but librarian, liberator, modulator, moderator, vault, rock, libman top the list. basically, it supports versioning, reloading, recycling, direct from net uploads installation, even should have the setup ui built-in. Softwares will also be able to interact with the installation and setup of the library on that user's machine. The spec itself really isn't restrictive. actually the base object of any library currently has no mandatory attributes or methods. some will say that there are security issues... I AGREE, and this should be reduced once the plugin architecture is available. But then again, any module architecture, by definition, implies a security breach. Its a question of trusting the source of your tools. If you don't want to use the default librarian tool, at least you could adhere to its api and then any one who wants to share or use code, has a common method of using it, whatever the loader he uses. This helps us to progress instead of turning in circles. IF a master list of peer-reviewed libraries comes into existence (THIS is my goal), then we will be able to increase the code base as one community. Not as a group of individuals. my hope is that a central server (hey that sounds like rebol.org ;-) would have a depository of all personal/beta/rebol patch/master modules for all of us to use. instead of having several sites to follow for specific tools, we could all just dump our libraries at one place and those which are peer-reviewed, get "official" blessing by the whole community. Any bug, any tweek can be suggested on this list (or another), and debated. The author or manager of any library is then able to integrate it. If it is an "official" library then a "higher-order" workgroup of dedicated fellows are all allowed to put in the change, when they have time. I'd be the first one to volonteer as an updater, as long as a real working group is built and I'm not expected to be a community servant. The basic advantage of a master library directory is that it would enforce backwards-compatibility, and takes care about the contents, safety, performance and future. This makes all of us accept a tool as stable, and in turn, allows us the chance to assume and be relax of any of those shared tool we would use. It also makes it easier to continue development on any tool for which the author disapears or for which times keeps him from integrating all the good ideas we all have about everything. I'd even see RT collaborating, if they wish, to stress-test some ideas or view the public's reaction to future ideas without having to distribute and commit to official new beta releases... many of the new things just are new/changed rebol functions... They could also either share some information about future orientations, and bless some initiatives, if they feel they complement some of their own plans, instead of staying in the dark. I mean, if I'm going to build a stable glass release and they think its enough of an advance, for example, that VID 2.0 is less of a pressing issue, they might shift to improving view itself, supporting stuff like 2d/3d OpenGL. I know the idea of all of us agreeing to one thing is a hard to forsee project, but I really feel we are at the point where such a concensus is essential for the growth of the "platform". I am also one to think that RT cannot plug all holes. Such a community acceptance would allow them to relax on some stuff that we all want, we ARE capable of doing many things ourselves. We already have. I'm sure many of you don't agree on the usefulness of what I am proposing, but other languages have benefitted by this and I feel rebol is another which would. some the above might sound extreme, pretentious, harsh, useless, controling, whatever. It isn't meant as such, if that's how you read it... its just someone wanting to make things move in a good hearted matter... and sometimes, more opinionated language stirs more discussion... :-) cheers! :-) -MAx --- You can either be part of the problem or part of the solution, but in the end, being part of the problem is much more fun.

 [2/12] from: atruter:labyrinth:au at: 7-Nov-2003 10:54


Hi Max, If this tool / methodology / mechanism can deliver the equivilant of a CPAN to the REBOL world then I think that would be a good thing indeed. There are already a number of standards that folks adhere to, including: - word naming conventions - REBOL header usage - code indentation I see this as a logical (and unifying) progression, with the priviso that it probably won't get off the ground unless RT give it their blessing. To really encourage fence-sitters like me, how about working with RT to get a REBOL/Library (for example) document added to their site's documentation section. Once it's set in concrete like this it's a lot harder to ignore! ;) Regards, Ashley

 [3/12] from: andrew:martin:colenso:school at: 24-Dec-2003 22:45


Max wrote:
> I'd like an OFFICIAL, community blessed library/module standard.
A lot of us are still waiting for Carl's module standard to arrive. I've given up on the idea of waiting, though I can see how useful it would be. Max, can you give an example of your proposed library module, please? Perhaps for a function that depends upon the presence of another function (or word definition)? Here's my example of 'Address and the word ('HTML_Obfuscate) that 'Address relies upon: [ Rebol [ Name: 'Address Title: "Address" File: %"Address.r" Author: "A J Martin" Owner: "Aztecnology" Rights: "Copyright (c) 2003 A J Martin, Aztecnology." eMail: [Rebol--orcon--net--nz] Web: http://www.rebol.it/Valley/ Needs: [%HTML_Obfuscate.r] Tabs: 4 Purpose: { Writes ML dialect for current script's File, Date & Version, along with the script's Author, email and web address. } Language: 'English Date: 19/July/2003 Version: 2.7.2 ] Address: has [File Date Version] [ File: Rebol/script/header/File Date: Rebol/script/header/Date Version: Rebol/script/header/Version compose/deep [ div/class "Address" [ address [ (rejoin ["Script: " File "; Date: " Date ; Version: Version "; "]) "Author: " a/href/title ( rejoin [ "mailto:" HTML_Obfuscate Rebol/script/header/eMail "?subject=" "Script: " replace mold File #"%" "%25" "; Date: " Date "; Version: " Version #"." ] ) "Send email about this script to the author" (Rebol/script/header/Author) "; " "Web: " a/href/title (Rebol/script/header/Web) "Go to the author's web site" (Rebol/script/header/Web) #"." br ] ] ] ] ] [ Rebol [ Name: 'HTML_Obfuscate Title: "HTML_Obfuscate" File: %"HTML_Obfuscate.r" Author: "A J Martin" Owner: "Aztecnology" Rights: "Copyright (c) 2003 A J Martin, Aztecnology." eMail: [Rebol--orcon--net--nz] Web: http://www.rebol.it/Valley/ Tabs: 4 Purpose: {Obscures text by converting characters into HTML entities.} Language: 'English Acknowledgements: "Brian Hawley" Date: 17/July/2003 Version: 2.0.8 ] HTML_Obfuscate: function [Plain [string! email!]] [Out] [ Out: make string! 6 * length? Plain foreach C Plain [ C: to-integer C Out: insert Out reduce [ "&#" any [ if C < 10 ["00"] if C < 100 [#"0"] "" ] C #";" ] ] head Out ] ] The nice part is that my library script, %Values.r, loads each script in the library directory, %Values/, and interprets the 'Needs block. If %Values.r finds a file! value, it loads that script (and checks the 'Needs block, recursively), before 'do-ing the first script. This system has the advantage that I can simply copy any library script that I like into the %Values.r directory and it runs when any version of Rebol is launched. (I've got the line: do %/C/Rebol/Values/Values.r in my %User.r file.) I've recently realised that there's some disadvantages in the above system in that it's file-centric, instead of word-centric. That is, the 'Needs field refers to file! values rather than word! values. It also lacks a way of describing what words are given values to by each library/values script; in other words, the above needs a 'Provides (or similar word) name-value in the header. For example, my %Dir.r script has this content: CD: :change-dir LD: :list-dir MD: :make-dir WD: :what-dir There should really be a Provides in the header like: Provides: [CD LD MD WD] And for my first library script: %"Address.r", like: Provides: [Address] Needs: [HTML_Obfuscate] With this change, I can then have my library script automatically check the library directory and create one script file with all the library functions on it, to maximise the OS caching of files and to speed Rebol's interpretation of the startup script by processing only one file instead of dozens of files. If I were to use any other library manager, it would have be as simple to use as the above. I'd like to know more about your module system. Andrew J Martin Attendance Officer Speaking in tongues and performing miracles. Colenso High School Arnold Street, Napier. Tel: 64-6-8310180 ext 826 Fax: 64-6-8336759 http://colenso.net/scripts/Wiki.r?AJM http://www.colenso.school.nz/ DISCLAIMER: Colenso High School and its Board of Trustees is not responsible (or legally liable) for materials distributed to or acquired from user e-mail accounts. You can report any misuse of an e-mail account to our ICT Manager and the complaint will be investigated. (Misuse can come in many forms, but can be viewed as any material sent/received that indicate or suggest pornography, unethical or illegal solicitation, racism, sexism, inappropriate language and/or other issues described in our Acceptable Use Policy.) All outgoing messages are certified virus-free by McAfee GroupShield Exchange 5.10.285.0 Phone: +64 6 843 5095 or Fax: +64 6 833 6759 or E-mail: [postmaster--colenso--school--nz]

 [4/12] from: nitsch-lists:netcologne at: 7-Nov-2003 7:30


Hi Maxim, Am Donnerstag, 6. November 2003 23:36 schrieb Maxim Olivier-Adlhoch:
> Well, > > I'm sort of scared of letting it out of the bag, but here is a complete > answer. > > I'd like an OFFICIAL, community blessed library/module standard. >
Thats there. download script to folder, do it.
> Some of you are aware of my idea, some have even tried the ancestor of the > new tool, steel's open-library function...
<<quoted lines omitted: 7>>
> will also be able to interact with the installation and setup of the > library on that user's machine.
Sounds complicated. Where are the benefits? If i use tools, they are either inbuild, short snippets which i patch or standalone scripts/directories when its more complicated. Scripts without dependencies. That works well with the most complicated scripts i have seen.
> The spec itself really isn't restrictive. actually the base object of any > library currently has no mandatory attributes or methods.
<<quoted lines omitted: 5>>
> any one who wants to share or use code, has a common method of using it, > whatever the loader he uses.
There are different levels of security risks. Autoupdate is a lot riskier then downloading a script, inspect it and the source, agree and use exactly this script all the time. Can i be sure the sources i trust today will not be hacked tomorrow? And auto-downloaded? Loading a lot of unneeded libraries automatically is a risk to. Lot more places for holes. Better to know what goes in the image IMHO
> This helps us to progress instead of turning in circles. IF a master list > of peer-reviewed libraries comes into existence (THIS is my goal), then we > will be able to increase the code base as one community. >
If we increase the code-base we increase the entry level of knowledge, at least subjectively. Users of large libraries slowly realise they write some code faster themself then to lookup help forever to do it with library-functions IMHO. Rebol follows the "if it can be done with some code, dont wrap it in a library. If you make a library, only if a lot more can be done with some code then." IMHO, and i like it.
> Not as a group of individuals. > > my hope is that a central server (hey that sounds like rebol.org ;-) > would have a depository of all personal/beta/rebol patch/master modules for > all of us to use. instead of having several sites to follow for specific > tools, we could all just dump our libraries at one place and those which > are peer-reviewed, get "official" blessing by the whole community. >
Carl said "keep all in one script and no dependency hassles" for rebol.org IIRC.
> Any bug, any tweek can be suggested on this list (or another), and > debated. The author or manager of any library is then able to integrate > it. If it is an "official" library then a "higher-order" workgroup of > dedicated fellows are all allowed to put in the change, when they have > time. >
Usually contacting the Author directly works pretty well. After all, he knows his code. What would a debate bring? Making PDF-Maker better by adding wishes? If an Author needs feedback, he can ask here. The Art of Rebol is: all fits together, all works similar. (Is the magic word synergy?) Thats different to other philosophies about implementing lots of user-wishlist. the users have a harder time to find the right functions then.
> I'd be the first one to volonteer as an updater, as long as a real working > group is built and I'm not expected to be a community servant.
<<quoted lines omitted: 5>>
> tool for which the author disapears or for which times keeps him from > integrating all the good ideas we all have about everything.
If you want backward compatibility, don't change the script. Or use lots of wrappers to keep apis abstract. MB MB MB. Lots of code to understand. Change the behavior of a face for example. if possible at all.
> I'd even see RT collaborating, if they wish, to stress-test some ideas or > view the public's reaction to future ideas without having to distribute and > commit to official new beta releases... many of the new things just are > new/changed rebol functions... >
I disagree. if RT wants to experiment, they have to make sure they can throw the stuff away. Freezing dependencies somewhere in a large library is the wrong way then. Putting it in a library sets standards.
> They could also either share some information about future orientations, > and bless some initiatives, if they feel they complement some of their own
<<quoted lines omitted: 3>>
> issue, they might shift to improving view itself, supporting stuff like > 2d/3d OpenGL.
Why do you need all this library-smartness for glass? why not just giving a script (or directory of scripts), say "do it, and here is the docu"? Having a internal scheme for a large tool is ok, but why force different libraries to work the same way? IIRC some people had problems with your librariomatic, which may have affected testing? And, please, stay out of %user.r. thats private array i want full control over. ;)
> I know the idea of all of us agreeing to one thing is a hard to forsee > project, but I really feel we are at the point where such a concensus is > essential for the growth of the "platform". I am also one to think that RT > cannot plug all holes. Such a community acceptance would allow them to > relax on some stuff that we all want, we ARE capable of doing many things > ourselves. We already have. >
They can not plug all holes anyway. simply because people want to use other software they are used to, have to use etc. They can plug some holes very well. also holes in this software. like distributing. And rely on peoples be smart enough to rely on standards for documents.
> I'm sure many of you don't agree on the usefulness of what I am proposing, > but other languages have benefitted by this and I feel rebol is another > which would. >
Rebol thinks this languages have failed because of such features AFAIK. Lots to complex. Rebol does the same without it. Instead it gives us the ability to do most stuff in 50K. so there is not so much to organize and version and download and discuss etc. Regarding failing, these squeak-guis had some experience with similar concepts lately. trying hypersmart declare-everything strict-structure modules. Now they have squeakmap instead, which is basically "download script and drop into image." everyone understands, works pretty well.
> some the above might sound extreme, pretentious, harsh, useless, > controling, whatever. It isn't meant as such, if that's how you read it... > its just someone wanting to make things move in a good hearted matter... > and sometimes, more opinionated language stirs more discussion... >
Me is overracting too ;) Everytime someone tells me Rebol is not complex enough ;)
> :-) > > cheers! :-) > > -MAx
Cheers, -Volker
> --- > "You can either be part of the problem or part of the solution, but in the > end, being part of the problem is much more fun." >
True. But sometimes avoiding the problem is better. More time too choose problems with more fun ;)

 [5/12] from: nitsch-lists:netcologne at: 7-Nov-2003 7:40


Am Freitag, 7. November 2003 00:54 schrieb Ashley Trüter:
> Hi Max, > If this tool / methodology / mechanism can deliver the equivilant of a
<<quoted lines omitted: 9>>
> section. Once it's set in concrete like this it's a lot harder to ignore! > ;)
Which means people who woudl contribute do not contribute because they can't ignore the rules. And are worried they dont understand or do someting wrong. Currently standards are set because scripts are accepted and commented ("better do" etc). If its reaonable, people adopt. I don't know how strict cpan is. A style-document is somewhere, aout your three examples. Then i like a lot of example-scripts in RT-style instead of more rule-documents. IMHO people like to copy style when beginning. Hmm, eventually rebol.org could mark RT-style-scripts so people can look up "official" examples when in doubt?
> > Regards, > > Ashley
-Volker

 [6/12] from: bry:itnisk at: 7-Nov-2003 9:48


This is something I've wanted for a long time, although I don't think I could have phrased it as well as Maxim.

 [7/12] from: antonr:iinet:au at: 8-Nov-2003 2:27


Andrew,
> Provides: [CD LD MD WD]
My include system uses, in the header: Public-Functions: [cd ls md wd] I think Provides is a better word, since they aren't always functions, and more concise too. My system also doesn't have a concept of dependencies that the Needs block addresses (yet). It's up to the programmer to write in the header somewhere which words are needed and up to the user to check. I've been planning to add that at some stage but haven't figured out the details of how to handle dependencies with different versions properly yet. There are lots of issues there. Got to think about it some more and design properly before jumping out into the blue. Anton.

 [8/12] from: maximo:meteorstudios at: 7-Nov-2003 13:16


Hi All, I am happy for all the replies (was expecting even more ;-) Some have even sent me some private mail, cause they didn't want their ideas debated in public. (that's ok too :-) I don't have time to give replies to anyone right now, but should be doing so before sunday. keep posting if you have any other comments... especially WRT opposition, functionality and feature ideas. I respect all views and I know that many have diverging oppinions and that's cool. I'd also love to get some reactions from RT (personal mail?) if anyone is following this thread even if lightly. I don't want to start such a large project if its going to be superseeded by their own thing in a week/month. I'd gladly contribute/test their tool with my own libs, if it exists somewhere unreleased. -MAx PS: private replies should use my work and home e-mail address for personnal posts, cause I won't be able to see any mail sent to work during the week-end. ;-) I split it up it so its harder to harvest with web bots home address: moliad at aei dot ca

 [9/12] from: rotenca:telvia:it at: 7-Nov-2003 20:09


> Hi All, > > I am happy for all the replies (was expecting even more ;-)
I think that only RT can set a standard for this kind of things. Modules, libraries are an important aspect of a language, not external tools. Knowing Carl Sassenrath work on Amiga and his deep modular code, i think that Carl has not forgotten libraries when he wrote Rebol. --- Ciao Romano

 [10/12] from: andrew:martin:colenso:school at: 24-Dec-2003 22:45


Hi, Anton. You wrote:
> My system also doesn't have a concept of dependencies that the Needs
block addresses (yet). It's up to the programmer to write in the header somewhere which words are needed and up to the user to check. I've been planning to add that at some stage but haven't figured out the details of how to handle dependencies with different versions properly yet. There are lots of issues there. Could you describe some of these issues please? Thanks! Andrew J Martin Attendance Officer Speaking in tongues and performing miracles. Colenso High School Arnold Street, Napier. Tel: 64-6-8310180 ext 826 Fax: 64-6-8336759 http://colenso.net/scripts/Wiki.r?AJM http://www.colenso.school.nz/ DISCLAIMER: Colenso High School and its Board of Trustees is not responsible (or legally liable) for materials distributed to or acquired from user e-mail accounts. You can report any misuse of an e-mail account to our ICT Manager and the complaint will be investigated. (Misuse can come in many forms, but can be viewed as any material sent/received that indicate or suggest pornography, unethical or illegal solicitation, racism, sexism, inappropriate language and/or other issues described in our Acceptable Use Policy.) All outgoing messages are certified virus-free by McAfee GroupShield Exchange 5.10.285.0 Phone: +64 6 843 5095 or Fax: +64 6 833 6759 or E-mail: [postmaster--colenso--school--nz]

 [11/12] from: antonr:iinet:au at: 10-Nov-2003 18:04


Mmmmm.. ok. Scenario 1 Imagine a function "f1" in a library of functions. It needs to have a function "f2" defined from another library to work properly, but an older version of f2 doesn't work, and f1 knows about that incompatibility. How should it be specified that the old version is no good and what action should be taken when f1 is attempted to be loaded? Possible actions: (A) f2 just tries to use whatever version of f1 is currently installed. (B) f2 downloads the latest f1 (into the cache) and uses it. (C) f2 downloads the latest f1 and uses it (without overwriting the cache). (D) f2 advises the user with an message dialog about the clash and asks which action to take. Problems of the above actions: (A) the f2 program will probably fail, because the old version of f1 is known to be incompatible. (B) f2 will work fine, but now there is a new version of f1, other programs that used to work fine may now not work. (C) f2 and other programs will work fine as long as there is a net connection and the user doesn't mind f2 using it. (D) User may interpret that as unfriendly, not smart enough to handle the case without supervision. I think the solution is to have a versioning notation system that separates "new-feature" versions and "bug-fix" versions. But you have to be strict in doing that. (Quite often in adding new features to a library I catch some errors while I'm there. Really, using such a system I should make two separate releases.) The user should be notified with full information (as possible) about the "upgrade" options and what they do (bug-fix/new-feature). Of course, this requires more discipline and takes more effort to maintain. ---- Scenario 2 Imagine a script uses two functions; f1 & f2, and they both need function f3. Should: - f1 and f2 each try to load f3 into its context when they are loaded, or .. - the main script load f3 into its context once (so that it is available to f1 and f2) ? In the first case, it's possible that two different copies of f3 exist and strange results may be experienced if it has "static" variables. This seems memory inefficient, though the situation can be caught, and a reference to the first instance of f3 loaded can be returned to subsequent user-programs that ask for f3. ie. f1 tries to load f3 and gets it ok. Now f2 tries to load f3 and gets a reference to the first instance of f3 that f1 has already loaded, so now: f1 f2 \ / \/ f3 That "caching" ability of the include function isn't so hard (I haven't written it yet for mine), but how, now, do you specify that you *do* want to load a new instance (say, if f1 wants to modify f3's code a bit, but f2 doesn't), or you *do* want to overwrite the first instance of f3 (say, you just downloaded a new version and you want to dynamically refresh). Ok, these options can be handled with refinements, but grr...! complication! Which options should be the less-harmful, defaults ? It probably depends what kind of data you are loading. Better make a neat system and document really clearly. In the second case, the main contexts' words have been polluted by f3, a support function only needed by f1 and f2 ! ("I didn't *ask* for "f3", I only asked for "f1" and "f2". If I wanted f3 I would have asked for it!!!!) --- These issues plague my mind so much when I think about it I have to switch off for a while in order to get anything done. :) My other idea, which I will continue to pursue at some point, is to make a dedicated downloader for any site. It can tell you which scripts are out-of-date, download all, or a selection, for you automatically, show information about newer/older versions, and also be able to revert selected scripts to older versions. Anton.

 [12/12] from: antonr:iinet:au at: 10-Nov-2003 19:30


A perfect example! I caught some bugs in the last post. You will notice I switched f1 and f2 after Possible actions: :-/ But I was going to say, also that in Action D, it is difficult to collect all the information required to properly advise the user. Which is the program that has this problem? Is it f1 that has the problem, f2, or the main script? (Or the script which called the "main" script? ad infinitum) Which library file needs to be updated? What other scripts that the user already has, that use this library file, may be affected by the update? Anton.

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