World: r3wp

FOR should be able to work for series too according to its spec

and btw - what if you would refer to past tail - in current version 
it is error, in R3 it is supposed to return none ....

so the value-from is the block b: [1]

interesting, that series working for 'for I mean - is that anyhow 
usefull? :-)

it is the spec, so one "cure" may of course be to disallow series

I will let it to gurus to decide, but it does not sound logical to 
me, as it states - starting value, ending value ... what is starting 
value for [1 2 3 4]? What is for ["c" "a" "b"], what is for [b c 
d] (referring to others, e.g. binary?) .... we imo refer to index 
here, don't we?

starting value is [1 2 3 4], next value is [2 3 4], etc.

so my understanding is, that according to you it is not OK and you 
would suggest to disallow series as starting and ending value

yes, but my suggestion says nothing - it is natural to think in that 
way, because of how I am used to 'for from another languages - otoh 
- Rebol is dynamic and allows many things, which other languages 
don't, so I just don't know. But if you would not mention it is possible, 
I would probably never used it that way ....

don't argue with yourself leave something for others ;-)

arguing with ourselves sometimes helps to answer some questions ourselves 
:-)

... or to confuse ourselves even more :-)

;; This example illustrates a bit better the behaviour of FOR with 
series

>> series: [a b c d e f g h i j k]  

== [a b c d e f g h i j k]

>> start: skip series 0

== [a b c d e f g h i j k]

>> stop: skip series 6

== [g h i j k]

>> for b start stop 1 [print mold b]

[a b c d e f g h i j k]

[b c d e f g h i j k]

[c d e f g h i j k]

[d e f g h i j k]

[e f g h i j k]

[f g h i j k]

[g h i j k]
>> for b start stop 2 [print mold b]

[a b c d e f g h i j k]

[c d e f g h i j k
]
[e f g h i j k]

[g h i j k]
>> for b start stop 6 [print mold b]

[a b c d e f g h i j k]

[g h i j k]

>> for b start stop 7 [print mold b]

[a b c d e f g h i j k]

Just a small typo, replace b with series for the examples of FOR 
usage.

From the behavior it looks like FOR looks very similar to FORSKIP. 
Only that breaking when the series index is greater than stop.

;So a similar result can behaviour can be  accomplished  with FORSKIP, 
ie:


>> forskip series 2 [print mold series if 6 < index? series [break]]

[a b c d e f g h i j k]

[c d e f g h i j k]

[e f g h i j k]

[g h i j k]

is equivalent to

>> for b start stop 2 [print mold b]

[a b c d e f g h i j k]

[c d e f g h i j k]

[e f g h i j k]

[g h i j k]


I believe we should have only one form for acommplishing the this 
type of series traversal. FORSKIP seems like the better choice than 
FOR. I support  removing series support from FOR. If series support 
is maintained with FOR the infinite loop race condition should be 
removed.

did you know, that

    repeat i 2'148'483'647 []

is an infinite cycle in REBOL?

sorry, I meant:

    repeat 2'147'483'647 []

2'147'483'647 = (power 2  31)  - 1

yes

(the maximal integer)

ladislav, isn't the first one the correct version?

or did you mean LOOP?

I've got error! all the time, cannot reproduce it. (number is converted 
to decimal!)

Ladislav made a small typo, getting a digit wrong in the number, 
the first time, and the second time he missed the variable (i).

I my opinion, "repeat i 2'147'483'647 []" should repeat exactly 2'147'483'647. 
Not more, not lessm, not forever. If I want an infinite loop, I would 
use the "Forever" function instead.


I assume that "loop" acts the same to 2'147'483'647, as "repeat" 
does. Am I right? How about "for":

for i 2'147'483'646 2'147'483'647 1 [ print i ] 


this is not infinite loop, it prints 2'147'483'646 and 2'147'483'647. 
So I assume that for loop is never infinite.


for i 1 2'147'483'647 1 [ print i ] ; this is not infinite loop, 
I assume.

However, 
for i 1 2'147'483'647 1 [ ] ; not infinite 
 
should be kind of equivalent to
i: 1 loop 2'147'483'647 [i: i + 1 ] ; infinite

This cannot be good. I am confused.

These kinds of issues/bugs are expectable when using fixed byte-length 
numbers, as rebol does. If you avoid the maximum integer then you 
should be ok. So I don't think it is as bad as all that. I am not 
saying the errors are good and fine, but you can "expect trouble", 
when going that high.

Also, each function (LOOP, REPEAT etc) may use a different test ( 
< ,  <=  etc) and so exhibit different behaviour.

>> for i 2'147'483'646 2'147'483'647 1 [ print i ]
2147483646
2147483647
** Math Error: Math or number overflow
** Where: for
** Near: start: start + bump

If you fix FOR to catch this overflow error, then it will slow performance.

thanks, Anton, you got it right

loop works well, the bug is observable only for repeat

So I assume that for loop is never infinite.
 - actually it is infinite too in some cases

(see above)

Anton, I disagree with the statement  "you can expect trouble, when 
going that high." The condition ilustrated is clearly an error if 
the iteration forms have and issue with certain values they should 
not degrade into an infinite loop, but into an error.

If such behavior is left uncheck, it will be easy to create race 
conditions in rebol code and an attacker will have ways to create 
security exploits.

A little peeve of mine .. you have to use parens to force Rebol evaluation 
in a particular order, but parens are also used by compose.

Graham: that is why I found my Build dialect ( http://www.compkarori.com/vanilla/display/build+dialect
) more comfortable

I need to look at this :)

it looks, that the newest version is: http://www.fm.tul.cz/~ladislav/rebol/build.r

Any idea what can cause this or a good idea how to find the bug?
>> read %/

Trace:  read (word)

Trace:  %/ (file)

** Access Error: Trace:  "Cannot open" (string)

Trace:  :arg1 (get-word)
Cannot open /

** Where: boot

** Near: read %/

registry settings mucked up ?

that is on OS X

No problem with Core 2.5.6 under OS X 10.2.8

>> read %/
Trace: read (word)
Trace: %/ (file)
Result: [%.DS.......

Is it a permissions problem?

That sounds more like it.

The Core Manual  ( http://www.rebol.com/docs/core23/rebolcore-17.html
)does limit the possible causes a little:

6.3.1 cannot-open


A file could not be accessed. This could be a local or network file. 
Most common reason for this error is a nonexistent directory.

I may have been more precise.. this appens after running  (uniserve 
;-)and after a week of high traffic.. I'm thinking of parsed stuff, 
redefined words, ecc or maybe a rebol bug, async?.. Hoped some guru 
could provide some tip on how to track that down, I'm having a hard 
time! thx

If I do
>>save/all %dump rebol ;or system?

and load the dump in a fresh console, is it correct that I should 
have the same behaviour?

It may be worth to do save a dump of the system at these times:
1) after loading uniserve
2) after running for a while without error
3) after getting the error

Then compare and find differences between the second and third dump 
files.
(And if nothing is found there compare 1 & 2)