REBOL Cookbook in Beta

This is something I've wanted to do for a long time (about five years): The REBOL Cookbook. With the recent surge in new REBOL users, we've been getting feedback that there should be an easier way to learn REBOL from examples. New users don't want to read a 720 page manual. (Many of them are kids and young adults.) Sure the library at rebol.org is great, but beginners want more than just raw code - they need some help. So, check out http://www.rebol.net/cookbook/ to see the beta. And, if you feel like joining in, I welcome you and appreciate it greatly. Just dust off your favorite REBOL example, add a few notes, and post it to the cookbook (which is moderated by the way). Once we get 20 or 30 "recipes" we'll announce the Cookbook on the home page. Ah... it feels good to get this thing up and running finally. Let me know how it works for you. -Carl

Am Donnerstag, 28. August 2003 23:25 schrieb [carl--rebol--com]:

> This is something I've wanted to do for a long time (about five years): > The REBOL Cookbook. > Ah... it feels good to get this thing up and running finally. Let me know > how it works for you.

> -Carl

Am Donnerstag, 28. August 2003 23:25 schrieb [carl--rebol--com]: [snip] More seasoning ideas: Could "find in file" and "read directory" be crosslinked? IIRC peoples expected find/any read %./ %*.r to work. instead we need a loop. modifying your example: files: read %docs/ remove-each file files [ not find/any/match file %*.r ;attention: do NOT remove ] probe files -- the article "Convert Text File Formats" shows another use of find, find [%.txt %.text] suffix? file also the example is nice for an article about "how to copy a directory"? !>> This code will copy all the text files found in your current directory: foreach file read %./ [ if find [%.txt %.text] suffix? file [ write/binary file read/binary file ] ] You can add additional file suffixes if necessary. (/me added /binary) <<! -- Get a Directory File List : it may be surprising that read %other-dir/ returns only the files, without directories. so foreach file read %other-dir/[ process-file file ] fails. must be dir: read %other-dir foreach file dir[ process-file dir/:file ;or join dir file ] -- How to process a directory recursive is also a frequent question. The masters example would be nice (will be used a lot as snippet i guess). -- Replace Text in a File In some places "reduction of variable use" is used, here explicitly mentioned: !>> Shortcut It is common practice in REBOL to remove extra code. The above example could also be written: foreach file read %./ [ if find [%.txt %.text] suffix? file [ write file replace/all read file "web" "rebol" ] ] <<! could be another article, "shortening code" i would give an example with explicit variables, then optimizing, but variables stay there as markers, then dropping the variables. !>> foreach file read %./ [ if find [%.txt %.text] suffix? file [ text: read file replace/all text "web" "rebol" write file text ] ] could also be written: foreach file read %./ [ if find [%.txt %.text] suffix? file [ write file replace/all TEXT: read file "web" "rebol" ] ] and since we don't need the variable now foreach file read %./ [ if find [%.txt %.text] suffix? file [ write file replace/all read file "web" "rebol" ] ] -- the above mentioned {how functions allocate "new" series} ( f: func[a][append [] a ] ;ouch ) out of the masters hand would be nice. needs explanation of design-decisions. demo using [source f], eventually mentioning obvious alternatives (me, early)? copy-on-write -> same? fails write-protection -> performance? what to protect (inner blocks too)? -- When using special technics in examples, they could have a line with links? ut of the head i would mention the needed {how rebol allocates "new" series} ( f: func[a][append [] a ] ;ouch ) and this expression chaining. -- the above mentioned {how functions allocate "new" series} ( f: func[a][append [] a ] ;ouch ) out of the masters hand would be nice. (explanation of design-decisions) a demo using [source f]. eventually mentioning obvious alternatives (me, early)? copy-on-write -> 'same? fails write-protection -> performance? what to protect (inner blocks too)? -- an article about clever probing, ?ing etc? its not we lack a debugger, we don't need one ;)

> -Carl

Volker, thanks for the suggestions and corrections. One of the goals for the Cookbook is to keep each "recipe" short and focus on just one main idea. So, some of the suggestions can be added as new articles. We will be adding "see also" link capability once we get a few more articles. Also, we may eventually add a "user comments" section following each article. I'll get those corrections made tomorrow.... -Carl

Am Freitag, 29. August 2003 06:57 schrieb Volker Nitsch:

> Am Donnerstag, 28. August 2003 23:25 schrieb [carl--rebol--com]: >

An excellent idea. There probably are some things locked in the head of the Founder that would be very enlightening to others. Permit me, as a perpetual beginner, to try to explain some things that keep stumping me. They might give others some ideas. 1. What must one say? There seems to be a number of functions that are important (or critical) in certain situations. The ones that come to mind are reduce/mold/remold/compose/form/reform. You can look each up in the dictionary to find out what it does, but the reverse information is hard to gather: When might you expect to need them, what is the purpose behind them, what will not work if I don't use them. 2. What is the recommended way? This is an area that is being addressed by the cookbook, but an idea for the cookbook immediately comes to mind. Most programs need to store some data. Some of the functions must have been created with this need in mind. I am still not sure if there is a recommended way to make a small data base. Does one make a block, and then store and load it? Are read/write the appropriate functions for storing data with some structure to it? The Complete Guide, with its video data base was helpful; is that the way one is expected to make a REBOL data base? 3. System words. I see in the library and on the mailing list lots of references to system/this and system/that. I have not observed any documentation on what these are and what they might be used for. 4. Generic words. This might not apply to others, but I come from a background of computer languages with reserved words. When I first saw REBOL examples, they were very confusing because a lot of the words (which I would call "data names") were short little things, like "file," that triggered in my corrupted mind the concept of "reserved word" or command. On top of that, they were all lower case with no punctuation. Reading through examples was like translating Latin. In the few REBOL programs I have written I have made all the words of my own invention upper case with at least one hyphen, to make it obvious that they are not REBOL functions. 5. Uncommented samples. Short, "straight-line" samples are fairly easy to understand with the aid of the dictionary, but when a scripts gets longer and has some functions, I find it hard to locate some firm ground to stand on to get a view of what is going on. I sent a sample to the library (popcheck.r, which I see made it in) that I wrote at first for my own use, and to make it easy for me to remember how it worked I commented it to a level that many would consider excessive. I think that for a beginner excessive commenting would be one of the most valuable tools for helping him understand. Sorry if this is excessively long. Steven White City of Bloomington 2215 W Old Shakopee Rd Bloomington MN 55431-3096 USA 952-563-4882 (voice) 952-563-4672 (fax) [swhite--ci--bloomington--mn--us]

>>> [carl--rebol--com] 08/28/03 04:25PM >>>

Well said, Steve. I feel like I'm a perpetual beginner for many of the reasons you list, although I do employ REBOL in significant and beneficial ways in my company despite said reasons -- a testament to the power of the language. I'm too steeped in languages like awk, *nix shells and Basic to "get it" too easily, I'm afraid. (But I *will* try!) Mike

Am Freitag, 29. August 2003 07:13 schrieb [carl--rebol--com]:

> Volker, thanks for the suggestions and corrections. > > One of the goals for the Cookbook is to keep each "recipe" short and > focus on just one main idea. So, some of the suggestions can be > added as new articles. >

> We will be adding "see also" link capability once we get a few more > articles. Also, we may eventually add a "user comments" section > following each article. > > I'll get those corrections made tomorrow.... >

> -Carl

Here's some feedback: - 0002 Convert Text File Formats: Add a section about converting to the format of another platform other than the current one with write/with - All of the cookbook entries related to files so far load the file completely into memory. Is there an easy way to do these functions on files larger than available memory? I can figure out the hard ways... Off-topic: Is there going to be a similar site for REBOL gotchas? Third-party would probably be better, for RT marketing purposes. - Brian Hawley At 02:25 PM 8/28/03 -0700, Carl wrote:

Hi Steven, I'll answer a couple of your questions, and leave the others in for others to have a crack at... On 30-Aug-03, Steven White wrote:

> An excellent idea. There probably are some things locked in the head > of the Founder that would be very enlightening to others. Permit me, > it? The Complete Guide, with its video data base was helpful; is > that the way one is expected to make a REBOL data base?

>> save %test.txt now >> type? read %test.txt

>> type? load %test.txt

>> save %test2.txt [I am a block's contents] >> read %test2.txt

>> load %test2.txt

>> load "I am another block's contents"

> 3. System words. I see in the library and on the mailing list lots > of references to system/this and system/that. I have not observed > made all the words of my own invention upper case with at least one > hyphen, to make it obvious that they are not REBOL functions.

> 5. Uncommented samples. Short, "straight-line" samples are fairly > easy to understand with the aid of the dictionary, but when a > would be one of the most valuable tools for helping him understand. > Sorry if this is excessively long.

Hi Mike, MJM> I'm too steeped in languages like awk, MJM> *nix shells and Basic to "get it" too MJM> easily, I'm afraid. (But I *will* try!) It took me a while to let go of some things, and to really starting understanding how REBOL works. I still have to catch myself when I think in terms of other languages, but it gets easier. Since you're a *nix/AWK guy (I was a BASIC/VB guy for a loooooong time), any thoughts you have about what would help people with your experience use REBOL would be great. I've written a small AWKish tool (RAWK) and some simple pseudo-emulations for other *nix utils (grep, wc, cut, cat, cmp) but I lack the perspective to know how to make them really useful and appealing to *nix folks. e.g. what are the most important utilities? Should they just be REBOL functions, or how best to emulate things like redirection without having to encap them all? Stuff like that. -- Gregg

Hi Gregg, Well, I think the thing is this: unless you're using REBOL/Command (and maybe even if you *are*), it's a bit tricky to pipe the output of one rebol program into another, and into another, etc., in true *nix style: ls *.txt | tail +10 | sort > pipe.result The reason in practice is that there are lots of oddball interactions that manifest themselves in specific shell environments, in my experience. We use Windows XP here a lot, calling REBOL programs from command shell scripts, but I also use a Bash-like shell from Thompson Toolkit, and folks use products like MKS Toolkit under Windows to get a *nix-like environment as well. (Even Microsoft provides a *nix environment set of utilities - I just got a sample CD in the mail.) I imagine REBOL is better behaved in this regard under Linux, but I think the cross-platform benefit of a standard paradigm that is elegant and works would be far better, in retrospect. That said, aside from well-designed functions that work well together, or maybe the OO stuff that I don't fully appreciate yet in REBOL, what *is* that paradigm or structure that would provide the clean utility of a pipe ? Perhaps this is best implemented as an enhancement to REBOL, as I believe the idea of a pipe is *very* elegant and conducive to problem-solving in a way that is very light and natural to understand. Maybe the way ports are implemented in REBOL would provide a means to implement pipe-like functionality. When you break it down, REBOL *has* all the "stuff" that you need to take data, transform it, transform it again, and again, etc., ad nauseum until you get the desired result. The problem for me is that instead of seeing a clear linear flow of data transformations that a pipe approach reveals, you end up with nested transformations that might tend to obscure what you're trying to accomplish. I.e., sort of the difference between the following ideas a < data | b | c | d | e | f > outfile and write f(e(d(c(b(a(data)))))) I prefer the first for clarity, given my experiences with the pipe idea. There was also something I heard IBM folks raving about a while back about the elegance and utility of "named pipes", which may also be a productive thing to look at. Not sure if this is helpful in the way you'd hoped... Mike

Hi Mike, Thanks for the thoughts! That's exactly the kind of thing I'm trying to figure out. It's easy enough to create a REBOL script that will take the entire command line and do all the work itself, or with other REBOL scripts, basically becoming its own shell with a supporting pipe dialect. The hard part is how to intersperse other system tools in that pipeline if you want. I'm not sure if you can use the shebang approach for general script usage in a pipeline with REBOL (simple redirection is easy enough, as is CGI). I seem to recall that my initial attempt at that failed under Windows. If you can, then it's a simple matter of writing scripts to work in that environment (i.e. using INPUT and PRINT). MJM> ...what *is* that paradigm or structure that would MJM> provide the clean utility of a pipe ? Perhaps MJM> this is best implemented as an enhancement to REBOL, MJM> as I believe the idea of a pipe is *very* elegant MJM> and conducive to problem-solving in a way MJM> that is very light and natural to understand. MJM> Maybe the way ports are implemented in REBOL would MJM> provide a means to implement pipe-like functionality. I think a dialect is the way to go, because you could do so much with it. Each app could have its own dialect, basically replacing command line options, so you could string together long chains of commands that were easy to understand. One problem I have is that I'm torn. On one hand, I think being compatible with standard *nix utilities, and being able to mix them with REBOL scripts in a pipeline, would be great. On the other hand, REBOL can easily deal with more structured data that is easier to work with, richer in meaning, etc. and just making things REBOL functions is conducive to using them in other scripts, but going the more "pure REBOL" route isn't going to help many *nix people see its potential or benefit from it. Thanks! -- Gregg

I do like piping in *uix (solaris), I do not know if the method I use fails on other systems but what works for me is basicly . insert system/ports/output PROCESS copy system/ports/input where PROCESS is whatever your script does. here is an example of a filter I call from procmail to preprocess mail before it is sent to spamassassin. ! /home/users/tomc/bin/rebol -sqw rebol[ Title: "no comment" Author: "Tom Conlin" Date: 25-Mar-2003 Purpose: "to strip html comment tags intended to hide spam" ] set-modes system/ports/input [lines: false binary: false] comments: copy "" spam: copy system/ports/input parse spam [ thru <html> any[to "<!" mark: copy s thru ">" (append comments copy s loop length? s[remove :mark]) :mark ] ] insert system/ports/output rejoin [spam newline comments] On Tue, 2 Sep 2003, Michael J. Mastroianni wrote:

Hi Tom, TC> I do like piping in *uix (solaris), I do not know if TC> the method I use fails on other systems but what works for me is TC> basicly . So you can use your REBOL script in a pipeline as long as the shebang is there? If so, that's great! I'll have to revisit it here (unless someone else can confirm that it works on Windows). And for those who may not know, INPUT and PRINT can often be used as shortcuts for system/ports/input|output. ; Simple I/O echo while [data: input] [print data] -- Gregg

Hi Michael, On Wednesday, September 3, 2003, 12:06:16 AM, you wrote: MJM> trying to accomplish. I.e., sort of the difference MJM> between the following ideas MJM> a < data | b | c | d | e | f > outfile MJM> and MJM> write f(e(d(c(b(a(data)))))) MJM> I prefer the first for clarity, given my experiences MJM> with the pipe idea. That's just syntactic sugar; indeed, you can easily make a "pipe" dialect in REBOL:

>> element: [copy el [word! [to '| | to end]] (push el)]

>> pipe-expr: [element any ['| element]]

>> result: []

>> push: func [element] [result: compose [(element/1) (result) (next element)]] >> parse [data | a | b | c | d | e | f] pipe-expr

>> result

>> clear result

>> parse [copy "REBOL" | append " powerful" | insert "Isn't " | append "? ;-)"] pipe-expr

>> result

>> do result

Hi Gregg, On Wednesday, September 3, 2003, 4:24:57 AM, you wrote: GI> So you can use your REBOL script in a pipeline as long as the shebang GI> is there? Of course. Also, Jeff wrote an article about using REBOL on Unix long ago: http://www.rebolforces.com/articles/rebolandtheshell/ Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

Hi Gabrielle, Wow. Perhaps you would consider conducting a Master's class in REBOL for us sometime ? I think the mere attempt to slowly take your code apart will be a very valuable exercise for me - no reflection on the clarity of your code! -- rather, how basic my knowledge of REBOL still remains ... Mille Grazie - Mike

Thanks Gabriele! GI>> So you can use your REBOL script in a pipeline as long as the shebang GI>> is there? GS> Of course. Also, Jeff wrote an article about using REBOL on Unix GS> long ago: GS> http://www.rebolforces.com/articles/rebolandtheshell/ I know it *should* work. :) Under Windows I wonder if the file association overrides the shebang path. Just trying simple redirection doesn't work (View comes up instead of Core which is in the shebang). If I call REBOL with the script and redirection on the command line, it all works fine. Guess I'll have to tinker some more. -- Gregg

Am Mittwoch, 3. September 2003 00:06 schrieb Michael J. Mastroianni:

> Hi Gregg, >

> That said, aside from well-designed functions > that work well together, or maybe the OO stuff > I prefer the first for clarity, given my experiences > with the pipe idea.

Hi Volker, Thanks for the comments re piping. Mike