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

REBOL Cookbook in Beta

 [1/21] from: carl:rebol at: 28-Aug-2003 14:25


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

 [2/21] from: nitsch-lists:netcologne at: 29-Aug-2003 5:54


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.
<<quoted lines omitted: 11>>
> Ah... it feels good to get this thing up and running finally. Let me know > how it works for you.
Hi Carl. Good idea. Should we present drafts on mailing-list first, to keep the cookbook clean? Typo in the find example: I have to reduce your expectations drastically, its not text: find/ALL text "w?b" its only text: find/ANY text "w?b" Eventually you could add the test-data inline, like text: "Rebol says: Hello world!" text: find/any text "h*o" a hint that the wildcards are like file-wildcards would be good? (do windows-users know about them? dos-users do.) I try a patch of "notes": !>> The FIND function has several refinements that allow you to change the way the search works. For example, you can make it case sensitive (/case) or search for simple patterns (/any). For example, rather than searching for the string web, you can search for similar strings that have any character in the "e" position: text: find/any text "h*o" This works very similar to wildcards in file-boxes: The ? matches any character. The * matches a lot of any characters. (bad wording or funny?) See the FIND function for more information. To test, you can also set the string in the console. Easier to write Tests: text: "Rebol says: Hello world!" text: find/any text "h*o" The PARSE function can be used for much more complex types of searches involving pattern matching. (note: don't expect it to work like find (?)) <<!
> -Carl
-Volker

 [3/21] from: nitsch-lists:netcologne at: 29-Aug-2003 6:57


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

 [4/21] from: carl:rebol at: 28-Aug-2003 22:13


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

 [5/21] from: nitsch-lists:netcologne at: 29-Aug-2003 16:27


Am Freitag, 29. August 2003 06:57 schrieb Volker Nitsch:
> Am Donnerstag, 28. August 2003 23:25 schrieb [carl--rebol--com]: >
[snip] (the "reply" of my mailer trashes the responded message, so i cite myself by hand) Volker Nitsch fundamentally clever wrote the largest nop since he programmed: ->>>>>>>>>> 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) <<! <<<<<<<<<- Overwrites files with itself.. Erm, well, it could be named "touch"? but together with the following: ->>>>>>>>>>>>>>>> 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 ] <<<<<<<<<<<<<<<- it would give a "working with two directories": src-dir: read %source-dir/ dst-dir: %dest-dir/ foreach file src-dir[ if find [%.txt %.text] suffix? file [ write/binary dst-dir/:file read/binary src-dir/:file ] ] i often use repeat in a similar way, would call it "working with two series": texts: ["hi" "ho" "hey"] colors: [red green blue] ;how to make [ ["hi" red] ["ho" green] ["hey" blue] ]? ;'foreach works only with one series.. out: copy[] repeat i length? texts[ append/only out reduce[ texts/:i colors/:i] ] works basically like the directory-stuff: use an index present in both (file / integer), access it with a path ( dst-dir/:file / texts/:i ). is this information somehow usefull? Should i try an article? -Volker

 [6/21] from: Steven:White:ci:bloomington:mn:us at: 29-Aug-2003 9:46


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 >>>
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

 [7/21] from: mmastroianni:lepcorp at: 29-Aug-2003 11:12


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

 [8/21] from: nitsch-lists:netcologne at: 29-Aug-2003 17:32


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. >
right, this "short and focused" is the tricky part. the third is, get them to play with it IMHO. I tried that in my first post: the text: find/any text "h*o" looks like black magic (regular expression? uuh). So i would mention dos-wildcards -> user at home. setting up a string in a file each time needs some setup to try out. so i made a ready-to-paste example, mentioning the console: text: "Rebol says: Hello world!" text: find/any text "h*o" if i added more, please delete it. the second article was while collecting ideas. the important parts are: people will try a "dir *.r" in rebol. its a slightly advanced. they should be pointed to files: read %docs/ remove-each file files [ not find/any/match file %*.r ;attention: do NOT remove ] probe files somehow. eventually a piece of sugar in the main article, we can do a "dir *.r" to, (presenting this code.) But how this works is a bit tricky ;) Then linking to an article explaining the code - there is a block of filenames, [%file1 %file2 ..] we have to search each filenames, not in the block (note i said 'each ;) - remove-each does NOT mean "remove each file" it means "remove filenames from block". don't panik ;) a standalone article linked: - find/any/match? *scratch head* well, the /any turns on wilrdcard (like dos). the /match: see following mail
> 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.... >
BTW, if someone thinks my topics are worth refining, i try it. But you have to read the drafts here.. ;)
> -Carl
-Volker

 [9/21] from: brian::hawley::net at: 29-Aug-2003 19:16


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:

 [10/21] from: carl::cybercraft::co::nz at: 24-Dec-2003 22:34


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,
<<quoted lines omitted: 17>>
> 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/load, not read/write are the words to use to retain a value's type. Some examples...
>> save %test.txt now >> type? read %test.txt
== string!
>> type? load %test.txt
== date!
>> save %test2.txt [I am a block's contents] >> read %test2.txt
== "I am a block's contents"
>> load %test2.txt
== [I am a block's contents ] Note the values (meaning the date and block in the above examples) are saved as plain text files, it being 'load that converts them back to REBOL values. This is why you'll sometimes see 'load used on strings and other values, not just files. ie...
>> load "I am another block's contents"
== [I am another block's contents ] Warning: 'save only saves a series from its index position, not from its head, and it doesn't save the index, so you need to be careful with saving series to ensure you don't lose data.
> 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
<<quoted lines omitted: 9>>
> 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.
The style-guide in the Core User Guide explains how to write code the REBOL way... http://www.rebol.com/docs/core23/rebolcore-5.html I also started out capitalizing "my" words, but quickly changed to all lower-case. One advantage of this is it's one less decision to make per word. (: The other is there really are no reserved words in REBOL, their meaning being determined when the interpreter looks at them. The same word can be either data or code, and what appears to be reserved words can be changed at will by the script, as this silly example shows... rebol [] silly-print: func [text /local print][ print: func [string][ prin rejoin ["---> " string "^/"] ] print text ] silly-print "Hello" print "Goodbye" There the 'print word in the line... print text in the silly-print function behaves differenly than the 'print in... print "Goodbye" A more normal use of the same word would've been if I'd used 'text instead of 'string (or vice-versa) in the silly-print function, such as like this... silly-print: func [text /local print][ print: func [text][ prin rejoin ["---> " text "^/"] ] print text ] There, 'text in both cases has a string value, yet in View/VID 'text is one of the styles used in a layout. They wouldn't clash in any way though. Files and text are so common in computing that repeatedly using words like 'file and 'text can make things simplier for the programmer, if used sensibly. I don't have any problem sorting out which 'text is which in the above function, (the 'print function within it being easy to spot as seperate from the main body of the code), while the following one-liner... for n 1 3 1 [for n 5 7 1 [prin n] print join " " n] while being perfectly legal REBOL, is probably not a good example of when to use the same word. The idea is to use the words that seem right for the job, just making sure they're local to a function (or in an object) if you're worried they may over-write global words.
> 5. Uncommented samples. Short, "straight-line" samples are fairly > easy to understand with the aid of the dictionary, but when a
<<quoted lines omitted: 6>>
> would be one of the most valuable tools for helping him understand. > Sorry if this is excessively long.
Certainly not excessive and a very clear description of some of the problems beginners face with REBOL. I seem to remember all of them. ;) I doubt you will remain a perpetual beginner though. It's strange, but once REBOL begins to click, it seems to get simplier and simplier. Hang in there and I'll think you'll find this out too. -- Carl Read

 [11/21] from: greggirwin:mindspring at: 2-Sep-2003 10:10


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

 [12/21] from: mmastroianni:lepcorp at: 2-Sep-2003 18:06


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

 [13/21] from: greggirwin:mindspring at: 2-Sep-2003 17:25


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

 [14/21] from: tomc:darkwing:uoregon at: 2-Sep-2003 16:17


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:

 [15/21] from: greggirwin:mindspring at: 2-Sep-2003 20:24


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

 [16/21] from: g:santilli:tiscalinet:it at: 3-Sep-2003 10:16


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)]
== [copy el [word! [to '| | to end]] (push el)]
>> pipe-expr: [element any ['| element]]
== [element any ['| element]]
>> result: []
== []
>> push: func [element] [result: compose [(element/1) (result) (next element)]] >> parse [data | a | b | c | d | e | f] pipe-expr
== true
>> result
== [f e d c b a data] This allows you to do thing like:
>> clear result
== []
>> parse [copy "REBOL" | append " powerful" | insert "Isn't " | append "? ;-)"] pipe-expr
== true
>> result
== [append insert append copy "REBOL" " powerful" "Isn't " "? ;-)"]
>> do result
== "Isn't REBOL powerful? ;-)" The above is just very QAD, but it could be easily made useful... Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [17/21] from: g:santilli:tiscalinet:it at: 3-Sep-2003 10:25


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/

 [18/21] from: mmastroianni:lepcorp at: 3-Sep-2003 9:38


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

 [19/21] from: greggirwin:mindspring at: 3-Sep-2003 9:36


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

 [20/21] from: nitsch-lists:netcologne at: 3-Sep-2003 20:14


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
<<quoted lines omitted: 21>>
> I prefer the first for clarity, given my experiences > with the pipe idea.
You nearly got functional programming. Only you use postfix, rebol prefix. that means read stuff | process | write stuff becomes write stuff process read stuff you may need parents while learning. or: |: func ["simply return value" v [any-type!]] [get/any 'v] write stuff | process | read stuff -Volker

 [21/21] from: mmastroianni:lepcorp at: 3-Sep-2003 16:57


Hi Volker, Thanks for the comments re piping. Mike

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