[REBOL] [REBOL]Evaluating characters in a string Re:
On Tue, 04 Apr 2000, [EMAIL PROTECTED] wrote:
Hello All:
I want to search each element in a string.
I want to count occurances of some elements
and change other elements
;example count every occurance of 'm'
; change every occurance of '+' to ' '
ms: 0
str: "my+name+is+tim"
pairs: 0
forall str
[
if same? first str "m"
[ms: ms+ 1]
if same? first str "+"
[change str #" "]
]
print ["ms: " ms]
str: head str
print str
;The preceding code obviously doesn't work.
what am I doing wrong.
TIA
Tim
Tim,
Here is a working version with these changes:
if same? first str "m" is nowif str/1 = #"m"
change str #" " is nowstr/1: #" "
REBOL [
Purpose: {example count every occurance of 'm'
change every occurance of '+' to ' '}
]
ms: 0
str: "my+name+is+tim"
forall str [
if str/1 = #"m" [ ms: ms + 1 ]
if str/1 = #"+" [ str/1: #" " ]
]
str: head str
print ["ms: " ms]
print str
-Karl
[REBOL] Return types Re:(2)
On Tue, 4 Apr 2000 [EMAIL PROTECTED] wrote: Well Gisle... 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. OK, good points! However, I can't quite see how you can make a type inferencer (as a preliminary testing tool, just for the purpose of spotting stupid mistakes early) when functions can return values of different types from one call to the next given the same argument types. Example: ? find Finds a value in a series and returns the series at the start of it. Arguments: series -- (series port bitset) value -- (any-type) Refinements: . . . What the documentation doesn't say here is that find can also return the value none if it doesn't find what it's looking for. How is it possible to infer this when 'find is native? I can see it's possible when you have the source of the function and the source of all functions called by it and so on, but this is never the case in rebol is it? How can I make a script that allow me to check this sort of thing? It would be especially helpful in cases like 'find, since it could check if I handle all possible return types. Elan's idea of being able to optionally specify return types of a function would be nice provided that all natives that can return more than one type used it. Maybe I'm missing something? Any comments? Gisle
[REBOL] [REBOL]Evaluating characters in a string Re:
instead of "same?" use "equal?" and use "#" in single character tests. This works: ms: 0 str: "my+name+is+tim" forall str [ if equal? first str #"m" [ms: ms + 1] if equal? first str #"+" [change str #" "] ] print ["ms: " ms] str: head str print str [EMAIL PROTECTED] 04/05 12:36 AM Hello All: I want to search each element in a string. I want to count occurances of some elements and change other elements ;example count every occurance of 'm' ; change every occurance of '+' to ' ' ms: 0 str: "my+name+is+tim" pairs: 0 forall str [ if same? first str "m" [ms: ms+ 1] if same? first str "+" [change str #" "] ] print ["ms: " ms] str: head str print str ;The preceding code obviously doesn't work. what am I doing wrong. TIA Tim
[REBOL] Dialecting Re:
[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? You will appreciate the difference when REBOL/Core 2.3 will be released. You not only can redefine words, you can create your own language. Regards, Gabriele. -- Gabriele Santilli [EMAIL PROTECTED] - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[REBOL] [REBOL]Evaluating characters in a string Re:(2)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 05, 2000 7:24 AM To: [EMAIL PROTECTED] Subject: [REBOL] [REBOL]Evaluating characters in a string Re: instead of "same?" use "equal?" and use "#" in single character tests. This works: ms: 0 str: "my+name+is+tim" forall str [ if equal? first str #"m" [ms: ms + 1] if equal? first str #"+" [change str #" "] ] print ["ms: " ms] str: head str print str ; Yep, although I always use the '= word: forall str [if #"m" = first str [ms: ms + 1]] ; I really don't like 'forall because it changes the index. ; I try to use 'parse where ever I can (just because it's there): parse str [any[thru "m" (ms: ms + 1)]] ; The "change each occurance" of an element is a no-brainer (I just recently found this command). This also works with multiple elements (instead of "m" you could replace "my", for instance). replace/all str "m" " " [EMAIL PROTECTED] 04/05 12:36 AM Hello All: I want to search each element in a string. I want to count occurances of some elements and change other elements ;example count every occurance of 'm' ; change every occurance of '+' to ' ' - Michael Jelinek
[REBOL] Core Distribution Question Re:
Yes, these were exactly my concerns I once tried to express to Carl, but I didn't succeed well. I think the license for the free versions of Rebol should definitely show this freedom. regards, Ingo Those were the words of [EMAIL PROTECTED]: 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. license agreement stripped 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. -- _ ._ ingo@)|_ /| _| _ We ARE all ONE www._|_o _ _ ._ _ www./_|_) |o(_|(/_ We ARE all FREE ingo@| |(_|o(_)| (_| http://www.2b1.de/Rebol/ ._| ._|
[REBOL] RFC: Split-Path
Request for Comments on Split-Path Revision --- Issue: Should split-path be changed? Discussion: Split-path currently returns the last element of a path, regardless of whether it is a file or directory. That is: split-path %a/b/c == [%a/b/ %c] split-path %a/b/c/ == [%a/b/ %c/] This allows writing iterative code like: path: %/a/b/c/d == %/a/b/c/d while [path %/] [set [path file] split-path path print file] d c/ b/ a/ (Note, this example also shows another problem with split-path... in that it has no regular iterative termination condition. If you provided a path of %a/b/c/d this code would loop forever, because the path would reduce to %./ not %/ ) However, you would normally think that a split path type of function would separate the directory path from the file name itself. This would take %a/b/c/ and return a directory path of %a/b/c/ and a file of none (not a file of %"", which is a file with no name). However, you loose the iterative "peeling" shown above. Since split-path has other issues that we will be fixing very soon, I would like to get your comments on this issue soon. Do not consider legacy with existing code base. It is better to correct this problem today, rather than when the child is 20. -Carl "Dad"
[REBOL] parse / space
parse is very powerfull but still kills me with spacer: parse "asergd" lib-name == true parse "LIB1" lib-type == true so the 2 elements matches the 2 single rules. but pout together they don't : parse "asergd LIB1" [lib-name lib-type] == false probe parse "asergd LIB1" [lib-name lib-type] false == false parse/all "asergd LIB1" [lib-name lib-type] == false but the white space means trouble: parse/all "asergd LIB1" [lib-name " " lib-type] == true why one matches with extra white space and not the other ? parse "LIB1 " lib-type == false parse "asergd " lib-name == true parse " asergd " lib-name == true lib-name: [name] name: [ some symbol ] lib-type: [ "LIB1" | "LIB2" ] symbol: charset [#"0" - #"9" #"A" - #"Z" #"a" - #"z" #"." #"-" #"_" #"$" #"+" ]
[REBOL] RFC: Split-Path Re:
On Wed, Apr 5, 2000, [EMAIL PROTECTED] wrote: Request for Comments on Split-Path Revision --- Issue: Should split-path be changed? Discussion: Split-path currently returns the last element of a path, regardless of whether it is a file or directory. That is: split-path %a/b/c == [%a/b/ %c] split-path %a/b/c/ == [%a/b/ %c/] This allows writing iterative code like: path: %/a/b/c/d == %/a/b/c/d while [path %/] [set [path file] split-path path print file] d c/ b/ a/ (Note, this example also shows another problem with split-path... in that it has no regular iterative termination condition. If you provided a path of %a/b/c/d this code would loop forever, because the path would reduce to %./ not %/ ) However, you would normally think that a split path type of function would separate the directory path from the file name itself. This would take %a/b/c/ and return a directory path of %a/b/c/ and a file of none (not a file of %"", which is a file with no name). However, you loose the iterative "peeling" shown above. Since split-path has other issues that we will be fixing very soon, I would like to get your comments on this issue soon. Do not consider legacy with existing code base. It is better to correct this problem today, rather than when the child is 20. Isn't this a good case for refinements? While, I'm not sure what the best default behavior should be, split-path/file and split-path/dir refinements seem like reasonable extensions to add. .:Eric Sneak a peek... http://www.smallandmighty.com/reblog/
[REBOL] Return types Re:(3)
Hi Gisle, you wrote: Elan's idea of being able to optionally specify return types of a function would be nice Thank you. I think this email contains a rather complete return type enforcer function (further below). provided that all natives that can return more than one type used it. This is not how I meant it. An optional return type specifier would be used by the programmer who implements his own functions and wishes to prescribe legal return types for his function. Here's an example for what I mean: This works: x f email@ connecting to: ... This generates an error identifying the function f as the culprit: x f ftp:// ** Script Error: Expected one of: return type: [email!] - not: url!. ** Where: f ftp:// Let me explain (and demonstrate below): The return type specifier is not intended to announce which types will be returned. Rather, it is meant to exclude certain, unlisted, types from being returned and - instead of returning them - it will alert you to the fact your function is returning an unexpected type that you have outlawed in your return type specification block. What's that good for? In a world in which functions have polymorphic return values, you may be returning values from one function that are subsequently handled by a chain of other functions *without* complaints - those functions have polymorphic parameters - until some point in time in which a function does not support that datatype. It is probably time consuming to detect where in your code that value originates, since in our scenario the immediate suspect, the function that evaluated the failed expression, is not to blame. Let me illustrate with a simple example. Given the functions f, and x: f: func [value] [ return join value ["site.com"] ] x: func [value] [ send value "Hi" ] The following example works: x f email@ connecting to: ... The following example x f ftp:// in REBOL/Core generates this error: ** Script Error: send expected address argument of type: email block. ** Where: send value "Hi Since the error message quotes the send function as the source for the complaint we would begin to search for the problem in function x. Consider that in a real-word situation there may be any number of functions that mediate between f and x, x .. w .. v .. u .. s .. t .. .. g .. f and functions w .. g may have no problem dealing with url! types instead of email! types. Here we would have to review function w thru g until we arrive in f and determine that f is the source of improper datatype because join is return type polymorphic. Compare the previous error message to the following one: x f ftp:// ** Script Error: Expected one of: return type: [email!] - not: url!. ** Where: f ftp:// This error message tells you where the error originated - in f not in x -, tells you it is a return type error, and what improper return type the function attempted to return instead of using one of the legal choices defined in the block. Here is how the improved error message came about: f: rt-func [[catch] value /local return-type [email!]] [ return join value ["site.com"] ] x: func [value] [ send value "Hi" ] x f ftp:// ** Script Error: Expected one of: return type: [email!] - not: url!. ** Where: f ftp:// This is the version of rt-func I used: rt-func: func [spec [block!] body [block!]] [ insert body compose/deep [ return: func [result /local return-type] [ return-type: reduce [(spec/return-type)] either found? find return-type type? result [ system/words/return result ][ throw make error! reduce ['script 'expect-set join "return type: " [mold return-type] mold type? result ] ] ] ] remove/part find spec 'return-type 2 append spec [return] return func spec body ] Hope this helps. ;- Elan [: - )]
[REBOL] parse / space Re:
Apparently the 'some is matching the leading/trailing white space: parse " LIB1 " [lib-type] == false parse " LIB1 " [some lib-type] == true Curiously though, try this: parse "asergd asergd" [some symbol some symbol] == false parse "asergd asergd" [some symbol] == true Thus, [some symbol] (using 'charset) is matching the entire string, regardless of "breaking" white space. To support this, try: parse "LIB1 asergd" [lib-type some symbol] == true - Michael Jelinek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 05, 2000 10:42 AM To: [EMAIL PROTECTED] Subject: [REBOL] parse / space parse is very powerfull but still kills me with spacer: parse "asergd" lib-name == true parse "LIB1" lib-type == true so the 2 elements matches the 2 single rules. but pout together they don't : parse "asergd LIB1" [lib-name lib-type] == false probe parse "asergd LIB1" [lib-name lib-type] false == false parse/all "asergd LIB1" [lib-name lib-type] == false but the white space means trouble: parse/all "asergd LIB1" [lib-name " " lib-type] == true why one matches with extra white space and not the other ? parse "LIB1 " lib-type == false parse "asergd " lib-name == true parse " asergd " lib-name == true lib-name: [name] name: [ some symbol ] lib-type: [ "LIB1" | "LIB2" ] symbol: charset [#"0" - #"9" #"A" - #"Z" #"a" - #"z" #"." #"-" #"_" #"$" #"+" ]
[REBOL] Core Distribution Question Re:(2)
Perfect timing. We're closely reviewing our user license right now and are re-considering the transferability of REBOL for non-commercial uses. Thanks for your feedback and suggestions! best regards, Dan At 01:34 PM 4/4/00 +0200, you wrote: Yes, these were exactly my concerns I once tried to express to Carl, but I didn't succeed well. I think the license for the free versions of Rebol should definitely show this freedom. regards, Ingo Those were the words of [EMAIL PROTECTED]: 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. license agreement stripped 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. -- _ ._ ingo@)|_ /| _| _ We ARE all ONE www._|_o _ _ ._ _ www./_|_) |o(_|(/_ We ARE all FREE ingo@| |(_|o(_)| (_| http://www.2b1.de/Rebol/ ._| ._|
[REBOL] bug ? Re: parse / space
thx , good point. but i cannot change the input string to parse. so if it is a bug can we get a fix, and how to workaround it ? it's only a piece of a much longer and still growing dialect . -- Apparently the 'some is matching the leading/trailing white space: -- -- Thus, [some symbol] (using 'charset) is matching the entire string, -- regardless of "breaking" white space. To support this, try: -- -- parse "LIB1 asergd" [lib-type some symbol] -- == true
[REBOL] positive? bug
Hello. I think I found bug in positive? for numbers it works like a champ: positive? -1 == false positive? 0 == false positive? 1 == true but for time it has a bug imho: positive? -1:00 == false positive? 0:00 == true positive? 1:00 == true I think that positive? 0:00 should be false, or shouldn't ? (version: 2.2.0.4.2) Regards, Jan -- Jan Strejcek [EMAIL PROTECTED] Are working on CGI's in REBOL? - http://www.rebol.cz/cgi
[REBOL] recommend a REB friendly host Re:(5)
Hi Olivier,
I'm not a CGI person, really so I can't be of much help here,
I have a user.r file supplied.
My first problems were due to a wrong path, and I found about
my home-dir somewhere in the unofficial faq.
The only things I could add, have you tried the script locally?
Have you ftp'd as ascii (or from another *nix system)?
That's about everything, sorry
Ingo
Those were the words of [EMAIL PROTECTED]:
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.
-- _ ._
ingo@)|_ /| _| _ We ARE all ONE www._|_o _ _ ._ _
www./_|_) |o(_|(/_ We ARE all FREE ingo@| |(_|o(_)| (_|
http://www.2b1.de/Rebol/ ._| ._|
[REBOL] parse / space Re:
Hi bciceron, The short version is: I believe it's a bug. The long version: space at the begining of string: parse " LIB1" ["LIB1"] == true space smack in the middle of token: parse "LI B1" ["LIB1"] == false Now, that somehow makes sense. If I am parsing for the token LIB1 I do not want the two tokens "LI" and "B1" separated by anything - including a space - to qualify. Otherwise I should make white spaces separating "LI" and "B1" part of my rule. parse "LIB1 " ["LIB1"] == false Apparently "LIB1 " with a trailing space is treated like "LI B1" with a space separating two parts of the token. That space is not being ignored. I think that's a parse bug and should be reported as such. The trailing space should be ignored. That's because: SPACE NOT IGNORED: parse "LIB1 " ["LIB1"] == false SPACE IS IGNORED: parse "LIB1 " ["LIB1"(print "found it")] found it == true Note that I did not change the rule that determines which tokens are recognized! I only added an instruction to print "found it" when the token has been recognized. Since the token to be recognized has not changed, and the string being parsed has not changed, the two previous cases should evaluate to the same thing. Here's another example: parse "LIB1 " [some ["LIB1"]] == true Here I permit multiple occurences of "LIB1" in the input stream. Again the trailing space is ignored. My guess is that the parser does something like this: 1. Is the current character in the input stream identical to the current character in the token? 2. Answer to 1: No. Am I ignoring spaces and current character in input stream is character? If Yes: increment input stream index. Reset token index to beginning. Return to 1. If No: Return false 3. Answer to 1: Yes. Then Increment input stream index, increment token index 4. Is the token index exhausted? Yes. Check input stream index: 5. Is there anymore stuff left in the input stream? Yes. 6. Are there anymore rules left? No. 7. Report false. Instead, 7 should be 7. Am I ingoring spaces? Yes. Then 8. Do I encounter only spaces until string index is exhausted? 9. If 8. evaluates to YES: return true If 8. evaluates to NO: return false Until this is repaired you may want to go with the some version of lib-type, i.e. lib-type: [some ["LIB1" | "LIB2"] ] == [some ["LIB1" | "LIB2"]] parse "LIB1 " lib-type == true Hope this helps. At 12:41 PM 4/5/00 -0500, you wrote: parse is very powerfull but still kills me with spacer: parse "asergd" lib-name == true parse "LIB1" lib-type == true so the 2 elements matches the 2 single rules. but pout together they don't : parse "asergd LIB1" [lib-name lib-type] == false probe parse "asergd LIB1" [lib-name lib-type] false == false parse/all "asergd LIB1" [lib-name lib-type] == false but the white space means trouble: parse/all "asergd LIB1" [lib-name " " lib-type] == true why one matches with extra white space and not the other ? parse "LIB1 " lib-type == false parse "asergd " lib-name == true parse " asergd " lib-name == true lib-name: [name] name: [ some symbol ] lib-type: [ "LIB1" | "LIB2" ] symbol: charset [#"0" - #"9" #"A" - #"Z" #"a" - #"z" #"." #"-" #"_" #"$" #"+" ] ;- Elan [: - )]
[REBOL] Salvaging ASCII data from binary file Re:
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, April 06, 2000 6:46 AM Subject: [REBOL] Salvaging ASCII data from binary file Hi, I have been given a messed up (beyond hope) database file of 5MB and would like to remove all the extended and unprintable characters, then save the result as a text file. The following displays the characters: good-chars: charset [#" " - #"/" #"0" - #"9" #"A" - #"Z" #"a" - #"z"] file: to-file ask "Filename? " data: read/binary file forall data [ if find good-chars first data [ print to-string copy/part data 1 ] ] but what is the best way to collect all of these and save as a plain ASCII text file, say, good.txt ? Thanks, Hi Peter, Assuming your above code works..You could try just replacing print with write/append. if find good-chars first data [ write/append %good.txt to-string copy/part data 1 ] Cheers, Allen K -- Peter H. Geddes; Savannah, Georgia USA mailto:[EMAIL PROTECTED] --
[REBOL] RE: Salvaging ASCII data from binary file
Without denigrating any potential REBOL-based solutions, this problem could be solved with the free Icon language pretty trivially. There is a library function in Icon called "deletec(s,c)" which deletes all characters in string s that belong to charset c. In Icon both strings and charsets are atomic types. It is a very powerful string-processing language. http://www.cs.arizona.edu/icon/ Best regards, Mark Evans -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 05, 2000 3:46 PM To: [EMAIL PROTECTED] Subject: [REBOL] Salvaging ASCII data from binary file Hi, I have been given a messed up (beyond hope) database file of 5MB and would like to remove all the extended and unprintable characters, then save the result as a text file. [snip]
[REBOL] Salvaging ASCII data from binary file Re:
Peter, I assume you do not have access to a UNIX? If you did, the first thing I would do is to run a "strings" on the database file. That may give you more than the limited 'charset below, but it would be trivially easy. - Michael Jelinek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 05, 2000 1:46 PM To: [EMAIL PROTECTED] Subject: [REBOL] Salvaging ASCII data from binary file Hi, I have been given a messed up (beyond hope) database file of 5MB and would like to remove all the extended and unprintable characters, then save the result as a text file. The following displays the characters: good-chars: charset [#" " - #"/" #"0" - #"9" #"A" - #"Z" #"a" - #"z"] file: to-file ask "Filename? " data: read/binary file forall data [ if find good-chars first data [ print to-string copy/part data 1 ] ] but what is the best way to collect all of these and save as a plain ASCII text file, say, good.txt ? Thanks, -- Peter H. Geddes; Savannah, Georgia USA mailto:[EMAIL PROTECTED] --
[REBOL] bug ? parse / space Re:(2)
I suspect that you won't be able to use 'parse - or at least as simplified as the example you gave. I have a gripe with 'parse also, which I would REALLY like to see changed in an upcoming release. When I use the '| operator (for OR), 'parse will search the entire string for the first pattern then, if this isn't found, it will begin searching for the second pattern. Although a person may want to do this, I do not. What I want is to match the first or second pattern, WHICHEVER COMES FIRST in the search string. Bummer, huh? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 05, 2000 1:23 PM To: [EMAIL PROTECTED] Subject: [REBOL] bug ? Re: parse / space thx , good point. but i cannot change the input string to parse. so if it is a bug can we get a fix, and how to workaround it ? it's only a piece of a much longer and still growing dialect . -- Apparently the 'some is matching the leading/trailing white space: -- -- Thus, [some symbol] (using 'charset) is matching the entire string, -- regardless of "breaking" white space. To support this, try: -- -- parse "LIB1 asergd" [lib-type some symbol] -- == true
[REBOL] REBOL/view downloading
Hi everybody! Could you please help me? I want to download REBOL/view. (for AmigaOS or Win). What could I do? Maxim.
[REBOL] CGI problem Re:(5)
Hello, 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. Why would one do that? Can it still process a form? How does this exactly limit Rebol? Regards, Rachid
[REBOL] RFC: Split-Path Re:(2)
On 05-Apr-00, [EMAIL PROTECTED] wrote: On Wed, Apr 5, 2000, [EMAIL PROTECTED] wrote: Request for Comments on Split-Path Revision However, you would normally think that a split path type of function would separate the directory path from the file name itself. This would take %a/b/c/ and return a directory path of %a/b/c/ and a file of none (not a file of %"", which is a file with no name). However, you loose the iterative "peeling" shown above. Since split-path has other issues that we will be fixing very soon, I would like to get your comments on this issue soon. Isn't this a good case for refinements? While, I'm not sure what the best default behavior should be, split-path/file and split-path/dir refinements seem like reasonable extensions to add. Right. We want to be able to get the dir/path and file name separately. -- ---===///||| Donald Dalley |||\\\===--- The World of AmiBroker Support http://webhome.idirect.com/~ddalley UIN/ICQ#: 65203020
