[REBOL] Dialecting Re:(2)
[EMAIL PROTECTED] wrote: How is dialecting different from defining a new word in Forth? How does this make REBOL better than any language which allows you to define new words? And Elan replied: Dialecting goes beyond just extending REBOL's vocabulary. It permits you to also define your own syntactic structures (i.e. language grammar). How does this make REBOL better than any language which allows you to define new words? Some differences between REBOL and languages that allow you to define new words: 1. There are now holy cows, i.e. keywords. REBOL allows you to define new words as well as any word from REBOL's existing vocabulary to be anything you want. For example, I can (and do) define 'head to mean the head section of a HTML dialect, whereas in REBOL it normally means return the head of a series. 2. Using REBOL's dialecting support, you can also define new syntactic structures. For example, replacing loop constructs which normally return the results of a block as an item to instead return items in a block ready to be joined. Very handy for making tables in HTML. 3. Using contexts you can precisely control under what circumstances your new word definitions/syntactic structures become affective, without impacting REBOL's default vocabulary and behaviour. For example: print HTML/Dialect [ ; dialect code here head [Title "My title"] body [] [H1 Title] ] print head "123" Note different uses of 'Title and 'head, in above REBOL code. 4. Based on contexts you can freely mix REBOL's default behaviour and any number of dialects. Or even embed many dialects in one all encompassing dialect. Example: See the CID dialect that is shipping REBOL/View beta. Hope this helps, I hope this helps! :-) Andrew Martin Inventing the future... ICQ: 26227169 http://members.xoom.com/AndrewMartin/ --
[REBOL] Dialecting Re:
Hi, if you don't have /View, you can look at some dialects even in /Core. REBOL's default "dialect" is a functional language, but there are: 1) parse dialect 2) secure dialect 3) function arguments block dialect You can see that in these contexts words have different meaning and different order than functions and their arguments. [EMAIL PROTECTED] wrote: How is dialecting different from defining a new word in Forth? How does this make REBOL better than any language which allows you to define new words? __ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup -- Michal Kracik
[REBOL] FTP and recycle
Hi Last week I complained about problems with FTP. After a sleepless night and tracing down a few variants, I could get rid of the problems. I inserted a "recycle on" in my main loop. After that everything went fine. In that context I noticed, that " probe system/schemes/ftp" is possible before any ftp action, but locks REBOL completely after the first successful ftp action. AR -- Sent through GMX FreeMail - http://www.gmx.net
[REBOL] [REBOL]Advice in using global values Re:(2)
Michael Jelinek wrote:
...I have noticed that loop indices are local to the loop block, and of
course function (dummy) arguments are local to the function...
It's revealing to look at the source of 'forall:
source forall
forall: func [
"Evaluates a block for every value in a series." [throw]
'word [word!] {Word set to each position in series and changed as a
result}
body [block!] "Block to evaluate each time"
][
while [not tail? get word] [
do body
set word next get word
]
]
Andrew Martin
ICQ: 26227169
http://members.xoom.com/AndrewMartin/
--
[REBOL] [REBOL]Formatting variables in strings Re:(3)
Also print ["the numbers are:" test "and" test + 1] print ["the numbers are:" test "and" add test 1] At 11:19 AM 4/3/00 -0800, you wrote: Thanks: That did it! tj At 10:12 AM 4/3/00 -0800, you wrote: print reform ["the numbers are:" test "and" (test + 1)]
[REBOL] recommend a REB friendly host Re:(3)
Hi Olivier, login at http://freeadmin.prohosting.com/ then you'll get info on where exactly your pages are located. The following script works for me ... #!/usr/home2/tobeone/html/rebol/rebol -cs REBOL [ Title: "CGI Test Script" ] print "Content-Type: text/html^/" print compose [ HTML TITLE "CGI Info" /TITLE BODY pre (mold system/options/cgi) /pre /BODY /HTML ] I hope this helps, Ingo Those were the words of [EMAIL PROTECTED]: I'm interested in how you did it because I already have a Prohosting free account on thor.prohosting.com. I tried to upload rebol and a CGI script but it didn't work. Could you tell me in which directory you installed it, and send me a script that work ? Are you using a user.r file ? Olivier -- _ ._ ingo@)|_ /| _| _ We ARE all ONE www._|_o _ _ ._ _ www./_|_) |o(_|(/_ We ARE all FREE ingo@| |(_|o(_)| (_| http://www.2b1.de/Rebol/ ._| ._|
[REBOL] Homer Simpson CGI
For the longest time, I couldn't get my REBOL CGI to work no matter which switches or file extensions I would use. Then I realized the REBOL binary I had uploaded to my cgi-bin on my server was the same binary I was using on my local machine - a BeOS binary. Doh! Thanks to netcraft.com and some simple troubleshooting, I was able to determine that one of my hosting services used Linux and the other Solaris. Further troubleshooting revealed which specific binaries (Linux libc5 and Solaris Sparc) were needed. It's such a simple, stupid thing to overlook, but it just didn't occur to me at first. smackKeep It Simple Stupid/smack -Ryan
[REBOL] Port question Re:
Hi Joachim,
I think you want the code from multisession.r on rebol.org. Thank you Alfred
Pang for this script!
- Michael Jelinek
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 04, 2000 6:55 AM
To: [EMAIL PROTECTED]
Subject: [REBOL] Port question
If I create a port ("server-port: open tcp://:"), is there any way
of making it non-blocking? If there is, can that method also be used to
make the connected "clients" non-blocking?
I would like to do something like the following (pseudo code), but it
won't work unless the ports are non-blocking:
server-port: open tcp://:
forever [
if (server-port have a connection) [
client-port: first server-port
(append client-port to a client-list)
]
foreach client client-list [
if (have input on client) [
(read and process data from client)
]
]
]
Maybe someone have a better solution?
/ Joachim
==
Joachim PileborgEMail: [EMAIL PROTECTED]
Software Engineer FMT AB ( http://www.fmt.se/
http://www.fmt.se/ )
==
[REBOL] CGI problem
Ok, well I figured out what was wrong and why I was getting a security violation before. It wasn't a system security violation, it was a REBOL security violation. In any case, I've tried a bunch of different command line things in the shebang line, among other things, including: (#!rebol --cgi ;this is the one I use normally, which works.) #!rebol --cgi -s #!rebol --cgi --secure none and "secure [file none]" in the script but the only one that has worked has been: #!rebol -cs Anyone know why I'm having a problem? Thanks a lot! Keith
[REBOL] CGI problem Re:
[Charset iso-8859-1 unsupported, filtering to ASCII...] Ok, well I figured out what was wrong and why I was getting a security violation before. It wasn't a system security violation, it was a REBOL security violation. In any case, I've tried a bunch of different command line things in the shebang line, among other things, including: (#!rebol --cgi ;this is the one I use normally, which works.) #!rebol --cgi -s #!rebol --cgi --secure none and "secure [file none]" in the script but the only one that has worked has been: #!rebol -cs If rebol starts from the first line of text file with executable flag, it takes only one option (only one '-?'). It's not problem of rebol AFAIK, it's common manner. I don't know why. Please take it as the fact. Regards, Jan -- Jan Strejcek [EMAIL PROTECTED]
[REBOL] Return types Re:
You can specify a return type. Just say "return to-(whatever) returnvalue" at the end of your function. For instance: returner: make function! [][return to-integer "4"] returner == 4 type? returner == integer! Hope this helps, and I hope this is even what you meant :) Keith - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, April 04, 2000 12:14 PM Subject: [REBOL] Return types One thing that bothers me is that I can't specify a return type for functions in REBOL. Many people consider this to be a bad idea so I'm wondering what the idea behind this is. There are obviously advantages and disadvantages with this, but do the advantages really outweigh the disadvantages? Gisle
[REBOL] Return types Re:
REBOL/core does not define words to support this, but you can always create your own dialect, or simply extend the word set to do so. I've never considered specifying return types for functions. I suppose they could catch an error every now and then when the function returns something you don't expect (just like argument types). - Michael Jelinek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 04, 2000 9:15 AM To: [EMAIL PROTECTED] Subject: [REBOL] Return types One thing that bothers me is that I can't specify a return type for functions in REBOL. Many people consider this to be a bad idea so I'm wondering what the idea behind this is. There are obviously advantages and disadvantages with this, but do the advantages really outweigh the disadvantages? Gisle
[REBOL] [REBOL]Formatting variables in strings Re:(4)
I like that too... and perhaps less overhead than using reform? tj At 09:16 AM 4/4/00 -0700, you wrote: Also print ["the numbers are:" test "and" test + 1] print ["the numbers are:" test "and" add test 1] At 11:19 AM 4/3/00 -0800, you wrote: Thanks: That did it! tj At 10:12 AM 4/3/00 -0800, you wrote: print reform ["the numbers are:" test "and" (test + 1)]
[REBOL] Return types Re:
Hi Gisle, why should return types be defined for functions? At 05:14 PM 4/4/00 +0100, you wrote: One thing that bothers me is that I can't specify a return type for functions in REBOL. Many people consider this to be a bad idea so I'm wondering what the idea behind this is. There are obviously advantages and disadvantages with this, but do the advantages really outweigh the disadvantages? Gisle ;- Elan [: - )]
[REBOL] Return types Re:(2)
Those were the words of [EMAIL PROTECTED]: Hi Gisle, why should return types be defined for functions? Just some random thoughts on this: 1) it would be easier to guess what a function does, or how to use it: compare this help compress Compresses a string series and returns it. Arguments: data -- Data to compress (any-string) to this help compress Compresses a string series and returns it. Arguments: data -- Data to compress (any-string) Returns: binary! -- Maybe with some more explanation here which carries more information for you? How do you use it correctly? 2) If you change the function some time later it is more likely that you don't introduce changes which would break existing code. regards, Ingo -- _ ._ ingo@)|_ /| _| _ We ARE all ONE www._|_o _ _ ._ _ www./_|_) |o(_|(/_ We ARE all FREE ingo@| |(_|o(_)| (_| http://www.2b1.de/Rebol/ ._| ._|
[REBOL] CGI problem Re:(3)
Hi Keith, Those were the words of [EMAIL PROTECTED]: Awesome, thanks. I was not aware of that :) My only remaining question then is why "secure [file none]" in my script doesn't work. The answer is twofold, first secure doesn't allow 'none, it should be allow. Second, we are talking CGI here, aren't we? So whom do you expect to answer the security question? secure [file none] ** Script Error: Invalid argument: none. ** Where: secure [file none] secure [file allow] REBOL - Security Check: Script requests permission to lower security level Yes, allow all, no, or quit? (Y/A/N/Q) What you _could_ do, is something like #!rebol -cs REBOL[] secure [net quit] This would give all access to files, but none to the web. hope that helps, Ingo -- _ ._ ingo@)|_ /| _| _ We ARE all ONE www._|_o _ _ ._ _ www./_|_) |o(_|(/_ We ARE all FREE ingo@| |(_|o(_)| (_| http://www.2b1.de/Rebol/ ._| ._|
[REBOL] Return types Re:(3)
Hi Ingo, If I'm not mistaken, both your answers touch on documentation issues, not on function implementation. I don't see any harm in having a type specifier as part of the function declaration, which enforces a return type ... as long as it's *optional* ;-). Something like: func [ a [any-type!] b [integer!] /local ... /return [any-type!]] [ ] Perhaps with auto-conversion? At 09:49 PM 4/4/00 +0200, you wrote: Those were the words of [EMAIL PROTECTED]: Hi Gisle, why should return types be defined for functions? Just some random thoughts on this: 1) it would be easier to guess what a function does, or how to use it: compare this help compress Compresses a string series and returns it. Arguments: data -- Data to compress (any-string) to this help compress Compresses a string series and returns it. Arguments: data -- Data to compress (any-string) Returns: binary! -- Maybe with some more explanation here which carries more information for you? How do you use it correctly? 2) If you change the function some time later it is more likely that you don't introduce changes which would break existing code. regards, Ingo -- _ ._ ingo@)|_ /| _| _ We ARE all ONE www._|_o _ _ ._ _ www./_|_) |o(_|(/_ We ARE all FREE ingo@| |(_|o(_)| (_| http://www.2b1.de/Rebol/ ._| ._| ;- Elan [: - )]
[REBOL] Return types Re:
Well Gisle... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 04, 2000 11:15 AM One thing that bothers me is that I can't specify a return type for functions in REBOL. Many people consider this to be a bad idea so I'm wondering what the idea behind this is. There are obviously advantages and disadvantages with this, but do the advantages really outweigh the disadvantages? This question can be answered 3 ways, from the perspective of REBOL in particular, of functional languages, and in general. REBOL is currently an interpreted language. This means that all of the various language processing, including type-checking, is done at runtime. Under these circumstances, type-checking is a luxury, only done to catch errors. Since any errors in the function return type are localized to the function, there are often more efficient ways to deal with them than declarative type-checking. Regardless, these types of errors should be handled within the function before return; any error that results from the return itself would need handling by the caller of the function. For functional languages in general, strong typing is typically done a little differently than in procedural languages. Although function parameters are typed, function return types are usually determined by inference. Type inference allows strong typing without requiring the programmer to specify return types that the compiler is perfectly capable of figuring out for itself. REBOL already lets you specify enough information to perform type inference, but it currently doesn't do type inference because of the runtime overhead this would cause in an interpreter. A type inferencer for REBOL would be possible to do, but would be a better preliminary testing tool than a runtime tester. In general, declarative type checking only makes sense when the types are checked before runtime. Runtime checking should only be done by code that can recover from any errors, and usually close to the source of the error (in the function) rather than distributed all over the place in calling functions. An exception to this is functions that primarily run code passed to them (language functions like foreach), which should handle any errors internal to the function, but pass on ones caused by the code passed to them. None of these cases are helped by declarative return type checking. Does this make any sense? Brian
[REBOL] Core Distribution Question
If I write a client-side application using REBOL/Core, may I distribute it without requiring users to obtain their own copy through rebol.com? The Core agreement seems to say "no" in that part about non-transferability. I'm hoping I got this wrong as it would put a damper on the distribution of my application. "REBOL Technologies (REBOL) hereby grants you a non- exclusive and non-transferable license to use the Software and Documentation for the purpose of designing, developing, writing, testing and running computer software applications. If you do not agree with the terms herein, then do not use the software." Take Java for example. The runtime can be separated from the development environment so they have separate license agreements but that is not the case with REBOL since it is both the environment and the runtime. If the answer to my question really is "no" then I am disappointed both for the viability of my application and for that of REBOL in general as it will be difficult for it to overtake Java's level of market penetration without changing the agreement. __ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup
[REBOL] Return types Re:(4)
Hi Elan, You wrote: I don't see any harm in having a type specifier as part of the function declaration, which enforces a return type ... as long as it's *optional* ;-). How would this be enforced in an interpreted language that creates its functions at runtime? Testing for return type at function creation time would need a type-inference engine to determine the type. Type inference is too slow to do at runtime. Testing for return type at function execution time would add an type-checking exception after the end of the function block. The function code wouldn't be able to handle such an exception, so it would have to ensure that the error couldn't occur using internal error-checking code, which would mean that the built-in return type-checking code would just be overhead. Something like: func [ a [any-type!] b [integer!] /local ... /return [any-type!]] [ ] Perhaps with auto-conversion? I noticed that you put the return type you listed was in a block. Blocks are used for the other types so that multiple types could be specified. If multiple types are specified, which type do you auto-convert to? What about conversions that aren't so automatic? Functions in REBOL are often polymorphic, returning types that depend on the types or values of their arguments. Any conversion or type checking in such an environment is better done manually. It's usually faster too, because you can remove tests where they aren't needed. A type inference engine would be a great development-time tool to check your code before release, though. It would be a good thing to have for documentation too. Wanna write one? ;-) Brian
[REBOL] recommend a REB friendly host Re:(4)
I know much more things than you about the server that host my site
(thor.prohosting.com) because I wrote a CGI script that let me browse the
filesystem of the server, and view the error log file of the server. But
this didn't helped me.
REBOL returns an error code of 1 or 2 when I remotely run it.
I checked 3 times that I uploaded the BSDI version ("uname -a" says "BSD/OS
thor.prohosting.com 3.1 BSDI BSD/OS 3.1 Kernel #0: Thu Jan 28 00:02:17 MST
1999 [EMAIL PROTECTED]:/usr/src/sys/compile/THOR i386").
It seems to me that thor.prohosting.com has a different configuration than
your server :(
(my home directory is in /usr/home where yours is in /usr/home2, for
example).
Olivier.
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, April 04, 2000 1:03 PM
Subject: [REBOL] recommend a REB friendly host Re:(3)
Hi Olivier,
login at http://freeadmin.prohosting.com/ then you'll get
info on where exactly your pages are located.
The following script works for me ...
#!/usr/home2/tobeone/html/rebol/rebol -cs
REBOL [
Title: "CGI Test Script"
]
print "Content-Type: text/html^/"
print compose [
HTML
TITLE "CGI Info" /TITLE
BODY
pre
(mold system/options/cgi)
/pre
/BODY
/HTML
]
I hope this helps,
Ingo
Those were the words of [EMAIL PROTECTED]:
I'm interested in how you did it because I already have a Prohosting
free
account on thor.prohosting.com.
I tried to upload rebol and a CGI script but it didn't work.
Could you tell me in which directory you installed it, and send me a
script
that work ?
Are you using a user.r file ?
Olivier
-- _ ._
ingo@)|_ /| _| _ We ARE all ONE www._|_o _ _ ._ _
www./_|_) |o(_|(/_ We ARE all FREE ingo@| |(_|o(_)| (_|
http://www.2b1.de/Rebol/ ._| ._|
[REBOL] CGI problem Re:(4)
The answer is twofold, first secure doesn't allow 'none, it should be allow. Yes, thanks. My error, I meant allow. Second, we are talking CGI here, aren't we? So whom do you expect to answer the security question? secure [file none] ** Script Error: Invalid argument: none. ** Where: secure [file none] secure [file allow] REBOL - Security Check: Script requests permission to lower security level Yes, allow all, no, or quit? (Y/A/N/Q) Haha, I never checked it interactively. Thanks. What you _could_ do, is something like #!rebol -cs REBOL[] secure [net quit] This would give all access to files, but none to the web. hope that helps, Ingo Thanks so much. Keith
[REBOL] [REBOL]Advice in using global values Re:(2)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 04, 2000 10:05 AM To: [EMAIL PROTECTED] Subject: [REBOL] [REBOL]Advice in using global values Re: As Rebol reads through a script, when it encounters begin-block symbol ( "[" ) it sets aside a special place (?) for any variables that are subsequently defined. When Rebol encounters the corresponding end-block symbol ( "]" ) all the variables in that special place are freed(?). So, to keep the number of variables low, you want to insure that variables are defined as late as possible, and freed as early as possible. The way to do this is to divide your script into blocks ( "func" blocks ), and do not introduce variables until you reach the block you need them. It kinda works this way for locally defined words of a function, but not for blocks in general. For REBOL it's better though of as: any local definition of a word "masks" the previous definition. The word isn't really "freed up" when the local definition falls out of context. The word is still defined in system/words. The very first time a word is referred to, it is immediately defined in system/words with a value of unset!. If you assign a value (to a "new" word) in a global context, this unset! is changed to the value. If you assign a value (to a "new" word) in a local context - masking the previous value of unset! - then fall out of that context, the value of the word reverts to unset!. If you work long enough in the same REBOL session - not just doing the same thing over and over - you'll fill up system/words even though most of them were defined as local variables which are out of context (and/or set to unset!). - Michael Jelinek
[REBOL] [ANN] Vanilla (alpha)
Hello Rebolizers, I've written a simple wiki-like hypertext system named Vanilla in Rebol (implemented as Apache CGI script). It's still an Alpha but already quite usable. Eventually it should evolve to become a full-featured CMS, but since it's more a pet project of mine than anything else progress is steady but still slow. Intro Installation: http://www.langreiter.com/vanilla/INSTALL Download: http://www.langreiter.com/vanilla I find Vanilla useful for ... * site prototyping (content structuring) * brainstorming * simple databases (adress lists, links etc.) * interconnecting ideas * weblogging Vanilla is extremely flexible and it depends mainly on your creativity what you are able to get out of it. It has a super-simple extension "architecture" and several interesting capabilities like inclusion and more or less intelligent linking. One of next things I'd like to implement is WML rendering. I hope some of you are fearless enough to try it out and comment on/improve it. Best regards, Chris _ c h r i s langreiter - - - unterlangkampfen 3 2 7 f o r m is function -- autriche 6322 langkampfen 0 0 4 3 / (0) 5 3 3 2 / 8 7 6 0 7 c a l l - n o w w w w . l a n g r e i t e r . c o m There are three kinds of lies: lies, damn lies, and statistics. --Benjamin Disraeli
[REBOL] Return types Re:(5)
Hi Brian, I sure enjoy your thoughts on the subject. I can certainly do without typed functions, but as long as they're optional ... Why not separate function constructors which support return type enforcement from functions that don't? Let's say we wish to enforce types or automatically convert types. This example auto-converts. Example usage: f: rt-func [a /local return-type [string!] ] [return a] Note that the return-type is entered in the /local part of the function's specification block (cheap trick, simplifies my implementation of rt-func somewhat). f 1 == "1" f [EMAIL PROTECTED] == "[EMAIL PROTECTED]" f http://www.rebol.com == "http://www.rebol.com" f 123.128.000 == "123.128.0" f [a b d] == "abd" f: rt-func [a /local return-type [block!] ] [return a] f 1 == [1] f [EMAIL PROTECTED] == [[EMAIL PROTECTED]] f http://www.rebol.com == [http://www.rebol.com] f [a b d] == [a b d] Later we go into production and want to optimize for speed (no auto-conversion). We set rt-func to func: rt-func: :func and now our functions behave normal: f: rt-func [a /local return-type [string!] ] [return a] f 1 == 1 f [EMAIL PROTECTED] == [EMAIL PROTECTED] f http://www.rebol.com == http://www.rebol.com f 123.128.000 == 123.128.0 The function rt-func could look something like this DISCLAIMERS Warning this is not production quality code. Just a rough draft, to get an idea. Does not support results of type object!: f make object! [a: none] == "?object?" "Things that can't be converted are not handled intelligently!" (TM) Probably there are other exceptions. A more careful approach would be to first check whether the function prototype contains the return-type word ... rt-func: func [spec [block!] body [block!] ] [ insert body compose/deep [ return: func [result /local return-type] [ return-type: (spec/return-type) system/words/return to return-type result ] ] remove/part find spec 'return-type 2 append spec [return] return func spec body ] At 04:56 PM 4/4/00 -0500, you wrote: Hi Elan, You wrote: I don't see any harm in having a type specifier as part of the function declaration, which enforces a return type ... as long as it's *optional* ;-). How would this be enforced in an interpreted language that creates its functions at runtime? Testing for return type at function creation time would need a type-inference engine to determine the type. Type inference is too slow to do at runtime. Type inference could not possibly be complete, since any function can be called via REBOL console. How do you infer the type of user input? Testing for return type at function execution time would add an type-checking exception after the end of the function block. The only possible solution. The function code wouldn't be able to handle such an exception, so it would have to ensure that the error couldn't occur using internal error-checking code, which would mean that the built-in return type-checking code would just be overhead. Sure would. Something like: func [ a [any-type!] b [integer!] /local ... /return [any-type!]] [ ] Perhaps with auto-conversion? I noticed that you put the return type you listed was in a block. Blocks are used for the other types so that multiple types could be specified. If multiple types are specified, which type do you auto-convert to? First one by default. What about conversions that aren't so automatic? Too bad. Functions in REBOL are often polymorphic, returning types that depend on the types or values of their arguments. Which is the reason I don't quite see why return type checking is so important. Any conversion or type checking in such an environment is better done manually. It's usually faster too, because you can remove tests where they aren't needed. See above. A type inference engine would be a great development-time tool to check your code before release, though. It would be a good thing to have for documentation too. Perhaps, when I have a little more time. Wanna write one? ;-) Brian ;- Elan [: - )]
[REBOL] [REBOL]Advice in using global values Re:(3)
Thank you. Very good information and well explain. My hat's off to you! Tim At 03:52 PM 4/4/00 -0700, you wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 04, 2000 10:05 AM To: [EMAIL PROTECTED] Subject: [REBOL] [REBOL]Advice in using global values Re: As Rebol reads through a script, when it encounters begin-block symbol ( "[" ) it sets aside a special place (?) for any variables that are subsequently defined. When Rebol encounters the corresponding end-block symbol ( "]" ) all the variables in that special place are freed(?). So, to keep the number of variables low, you want to insure that variables are defined as late as possible, and freed as early as possible. The way to do this is to divide your script into blocks ( "func" blocks ), and do not introduce variables until you reach the block you need them. It kinda works this way for locally defined words of a function, but not for blocks in general. For REBOL it's better though of as: any local definition of a word "masks" the previous definition. The word isn't really "freed up" when the local definition falls out of context. The word is still defined in system/words. The very first time a word is referred to, it is immediately defined in system/words with a value of unset!. If you assign a value (to a "new" word) in a global context, this unset! is changed to the value. If you assign a value (to a "new" word) in a local context - masking the previous value of unset! - then fall out of that context, the value of the word reverts to unset!. If you work long enough in the same REBOL session - not just doing the same thing over and over - you'll fill up system/words even though most of them were defined as local variables which are out of context (and/or set to unset!). - Michael Jelinek
[REBOL] ftp - tcp 500 illegal port
Win98 2.2.0.3.1 I open a REBOL console, dialin to my ISP and try ftp'ing to my website read ftp://edmunds:[EMAIL PROTECTED]/ I get this error msg: ***User Error: Server error: tcp 500 Illegal PORT rejected (address wrong).. Still connected, I open a new REBOL console and type exactly the same line read ftp://edmunds:[EMAIL PROTECTED]/ This time, I get the directly listing. I go back to the first console, same server error msg. I disconnected (leaving the second console -- the one that got thru -- still open). I reconnected to my ISP and typed: read ftp://edmunds:[EMAIL PROTECTED]/ again. Now that one gives me the server error! I open a new REBOL console, and get thru. Is this a known bug? -- What's going on? Doug Edmunds 4 April 2000 YOU'RE PAYING TOO MUCH FOR THE INTERNET! Juno now offers FREE Internet Access! Try it today - there's no risk! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
[REBOL] [REBOL]Advice in using global values Re:
This time to the right list! At 02:49 PM 4/2/00 -0800, you wrote: How do I make a value global? That is, so that it can be "seen" by any code in a file, include user-define functions? I would also welcome advice as to the pro and cons of using globals, as well as when best to use them, and what under what circumstances where such usage would be a bad idea. thank in advance. tim I was wondering about that too. Maybe if I reply to this we can get Allen, Andrew, Gabriele, pekr, Robert, or Volker to give a definitive answer... Just another newbie here, also trying to improve my style... So forgive me if I'm covering the same ground you've been over... Mostly I'm just thinking out loud about this topic, areas where I assume there is a more accurate explanation I've marked with a (?) symbol... If you define words after the Rebol[] block at the head of your script, myscript.r Rebol[] my_global_1: [1 2 3 4] my_global_2: "abcd" and then do %myscript.r my_global_1 and my_global_2 will be added to system/words (?), and available to all scripts that run afterwards in that Rebol window. They will occupy space in memory until you close the Rebol window, regardless if they are used frequently or used rarely. As a programmer you have to keep track of them and their side effects. You don't want to have to deal with more of them than you need to. Throughout your entire program, you can have lots and lots of variables, but the number of variables at any given moment should be low; the variables you don't yet need shouldn't be loaded, and the variables you're finished with should be freed from memory. As Rebol reads through a script, when it encounters begin-block symbol ( "[" ) it sets aside a special place (?) for any variables that are subsequently defined. When Rebol encounters the corresponding end-block symbol ( "]" ) all the variables in that special place are freed(?). So, to keep the number of variables low, you want to insure that variables are defined as late as possible, and freed as early as possible. The way to do this is to divide your script into blocks ( "func" blocks ), and do not introduce variables until you reach the block you need them. Get the user's guide available from do http://www.rebol.com/users-guide.r on the page expfunctions.html, there is a very short section on func blocks, also read about scope. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ That raises another question. How do you make variables seen by other Rebol windows? Let's imagine that you're doing some very intense calculation (e.g. creating a fractal image, calculating pi, removing noise from a sound file, etc.) and you start your Rebol script on a machine that you know has some kind of limitation (e.g. your account has a time limit, or the hard drive has very little remaining space, or the operating system has low system resources, etc.). You want to stop for now and continue later in a better environment. One way to do this might be to save all your variables to a file, email it to the other machine (or machines, if you have more than one), and then reload the variables later in that better environment, and then run your script again. What are some other alternative ways of running scripts across multiple machines? An eventual goal might be a "Beowulf"-style massively parallel multiple processing system held together by Rebol. At 01:19 PM 4/2/00 -0700, you wrote: Hi t, A file! type is a filename with a leading % character. Example: %myfile.r %/c/mydir/. A file! may be any type of file, including a directory. A port! datatype is a low-level i/o abstraction that REBOL uses to serialize different types of i/o channels, such as files (here we are not talking about the filename, but access to the file's contents), and socket i/o. The access to ports is typically controlled by protocols that define how information is read and written to a port, and also commonly implement some convenient navigation functions for the port's datastream, such as first, next, insert, pick, etc. These functions work in a sensible way on a port! datatype. They enable you to treat ports as though they were series values (i.e. blocks, paths, hashes ...) to a degree, hence the term serialize is used to describe this type of access to i/o channels. There are some limitations, since not all ports lend themselves to being treated as a series effectively with respect to all series! functions. I haven't been following this thread, so I don't know why you are using ports. Generally speaking, it is often more convenient to use higher level functions when dealing with files, then accessing them as ports. read, write, read/lines, write/append write/lines, write/append/lines, save, load, come to mind. All of these functions take a filename (type file!), and do not require that you manage the file on the port level, for instance with respect to positioning, etc. Hope this helps. ;- Elan [: - )]
