r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

Tomc
11-Jun-2005
[1252x3]
the carret is rebol's escape chat so
>> s: "^""
== {"}
is another way
Graham
13-Jun-2005
[1255x2]
Just reading the rbbs.r script, and there are a number of comments 
about Rebol/View embedded in it .. which is a little odd as R/View 
is not recommended to be used to run cgi scripts.
Ahhh, they were added by Dirk Weyland to make it compatible with 
his serve-it web server.
Henrik
13-Jun-2005
[1257x3]
did the latest version of OSX Rebol/Core come with the new FTP stuff? 
I have lots of trouble with a flakey FTP server here both with old 
and new versions of Rebol/Core for OSX...
User Error: Server error: tcp 500 RT not understood
 seems a bit broken to me
this is very strange... I get a whole range of different random errors: 
time outs, connection refused, commands not understood
Graham
13-Jun-2005
[1260x3]
For those that have smtp problems, I have posted a way to the mailing 
list on how to make rebol smtp send directly to the recipient's mail 
server by passing those messages about no mail forwarding allowed. 
 I would be interested to hear if anyone tries it out, and how well 
it works.
This means that a cgi script should be able to send out email even 
though the host does not provide a mail server for this purpose.
Of course, anyone using this method to spam will be $#@#!^@
Henrik
16-Jun-2005
[1263]
Working with INDEX? often, it annoys me that it can't handle none! 
values. If I for example want the index for a value and in some cases 
the value can't be found:

index? find [a b c] 'd


FIND returns none!, which INDEX? can't handle. I would have liked 
to see INDEX? also return none! or false! (like FOUND?) rather than 
an error. It gives a better flow and the same opportunity for checking 
on your FIND result, but you don't need to handle the error.


The reason I'm pointing this out is that some functions tend to go 
hand in hand, such as INDEX? FIND, and I think it would be nice that 
no errors ever occurred here in all naturally occuring states.


LENGTH? can sometimes be a bit of a pain with that too. What do you 
think?
Ashley
16-Jun-2005
[1264]
I have that problem all the time with having to write

	first find series val

as:

	if f: find series val [f: first f]
Henrik
16-Jun-2005
[1265]
absolutely. FIRST, SECOND, etc. have the same problem
Gabriele
16-Jun-2005
[1266x2]
first find series val?
i could maybe understand third... not first or second :)
Ashley
16-Jun-2005
[1268]
You're right. First is nonsensical and second could use 'select. 
I just checked my code and it is in fact 'index? not first I've had 
to code like this. ;)
Henrik
16-Jun-2005
[1269]
ah well.... :-) but I think there is a point in it, don't you? or 
maybe there ought to be some conventions, like: "Never change a block 
to a none!" or things like that
Gabriele
16-Jun-2005
[1270]
henrik: i added your wish to rambo. will probably be implemented.
Henrik
16-Jun-2005
[1271]
thanks
Ladislav
17-Jun-2005
[1272x3]
Henrik: your wish looks unnatural, I prefer the following:

    default [index? find [a b c] 'd] [none]


the Default function is available and it has been in Rambo for quite 
some time
Otoh, your example can be written using Attempt too as follows:

    attempt [index? find [a b c] 'd]
Re default: (a user poll) I wonder whether it is useful to have it 
like: 


    default [trial code here] 'error-variable [print disarm error-variable]

or in a shorter form like:

    default [trial code here] [print disarm error]


, in the last case the error variable will always be 'error, which 
will be local to the error handling block, i.e. if you want any other 
variable you have to explicitly assign the value of the 'error variable 
to it
Gabriele
17-Jun-2005
[1275x2]
my suggestion: if the arg is a block, use 'error. if it's a function, 
assume it has one argument and pass it the error. so i can write 
default [trial code] func [myerr] [print disarm myerr] if i really 
need to.
anyway, index? none returning none doesn't seem bad to me. will probably 
be faster than using attempt or default.
Volker
17-Jun-2005
[1277x2]
Carl did similar with 'remove, for failing "remove find". but may 
be better for error-checking to be explicit (rest of code expects 
dealing only with numbers, better bail out immediate.
about default, i prefer implicit error-var too. if not, at least 
put the error-var first. maybe together with an assignment?
 default 'var [index? find [a b c] 'd] [none] 
instead of
 var: default [index? find [a b c] 'd] [none]
but i prefer the second (old) version.
JaimeVargas
17-Jun-2005
[1279x2]
The problem I see is that it complicates debugging.

>> 1 + index? find "abc" "e"

** Script Error: index? expected series argument of type: series 
port
** Near: 1 + index? find "abc"

>> 1 + attempt[index? find "abc" "e"]
** Script Error: Cannot use add on none! value
** Near: 1 + attempt [index? find "abc" "e"]
So if INDEX? returns none the error of not finding the element propagates 
to the add function. In a longer expression the programmer will start 
debuging int the wrong place.
Volker
17-Jun-2005
[1281]
(thats what i wanted to say too. just wrong wording. should be "but 
<no-none> may be better for error-checking .."
Gabriele
17-Jun-2005
[1282x5]
compare:
1 + index? any [find "abc" "e" #]
to:
1 + any [index? find "abc" "e" 0]
maybe index? should directly return zero.
JaimeVargas
17-Jun-2005
[1287]
But then you need to have a test against zero in order to catch a 
not found result.
Volker
17-Jun-2005
[1288]
but when you found nothing, there is no index. 0 would give syntactically 
valid results, letting the rest of the program run. just doing wrong 
things. none will at least led to trapping it.

thinking about it, when using series instead of indices, it bails 
out on using, not immediate too. maybe index? pasing none is k.
JaimeVargas
17-Jun-2005
[1289]
The problem with returning zero is that is an attempt to handle implcitely 
something that should be explicit, that is error catching.
Ammon
17-Jun-2005
[1290]
I vote to leave it like it is.  It makes the most sense to have Index? 
fail on a non-series value.  I've found ANY to be a very handy function 
for handling things like that.  I initially just used it with EITHER 
and IF but its starting to show up in a lot of places in my code 
because it is just nice and concise. ;-)
Gabriele
17-Jun-2005
[1291x2]
is not finding a value an error? i think it isn't.
ammon: see above, if you use ANY you get 1 which is hardly what you 
want.
JaimeVargas
17-Jun-2005
[1293x2]
Not finding a value is not necesarily and error, that the reason 
find returns NONE. But it is an error to request the index of none.
Changing the semantics of INDEX? NONE is what is at stake.
Ammon
17-Jun-2005
[1295x2]
That is true but that just means that it may not be the way you want 
to handle it.  I think Ladislav is correct here.  In some situations 
it may not be bad to continue with a bad index value but I think 
the majority of the time then you need to cancel what you are doing 
if the index is not available, hence an error.
Jaime, Agreed!
Gabriele
18-Jun-2005
[1297x4]
Jaime: for INDEX? used alone, that may be true. But asking the position 
of a value in a series and asking the index of a value in a series 
are, IMHO, the same question.
pos: find series value
idx: index? find series value
so if the former should not cause an error, neither should the latter.
Volker
18-Jun-2005
[1301]
but then give 'none, not 0.