World: r3wp

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

I have run uniserve for months on end with no problems - basically 
processing incoming spam.

Anton, do you have a preferred tool when comparing such huge files? 
do you do text comparison or you have a rebol tool? Is that correct 
that after reloading the dump in a fresh console I should have the 
same behaviour, and if not is it a sign of rebol bug?  thank you 
8)

will, reloading the dump is not likely to recreate the problem imo. 
i actually suspect that the process doesn't have any more file-ids 
available.

it's probably either rebol not completely releasing resources, or 
some weird thing in osx.

Will, I just use a text editor and flick between files using Ctrl-Tab, 
scrolling down using Page-down when I don't see anything different. 
Raw, and it works pretty well, but it's probably worthwhile looking 
for a comparison tool out there.

Gabriele that is a very good hint!

Is there a simple rebol script that I could run and test for this 
precise case?

Is there a  unix command to check for number of file-id consumed 
by process?

Althought "read %/" returned error, probe info? %/ was still working, 
can this help?

Here you can find 3 process samples, I've done when the bug appeared 
and the CPU was at 100%, like if the process was waiting for something? 
a released file-id? Because the error appear in a crescendo, cpu 
100%, than ok for some time, cpu 100%, then work ...than stop working 
at all sometimes with cpu 100% sometimes CPU normal%, here the samples:
http://reboot.ch/sample1.txt
http://reboot.ch/sample2.txt
http://reboot.ch/sample3.txt

it's a weird situation... does OSX have something like linux's /proc 
file system?

no proc..

OS X 10.4 debugging tools:
http://developer.apple.com/technotes/tn2004/tn2124.html#SECTOOLS
anything here usefull?

I remember that Carl posted a recursive copy routine in the blog 
somewhere, but I can't find it now. Does anyone know where it is?

I was able to duplicate the access error with read %/ with a clean 
Rebol  instance by opening more than 256 files.

The default max number of files per process for OS/X is 256 - see 
http://developer.apple.com/qa/qa2001/qa1005.html

I used  "fstat -p 9999" to list all the files currently open by Rebol 
- 9999 being the first PID of the Rebol instance

From a couple of experiments, Rebol was properly free the File IDs 
when the files were closed.

was -> did

so maybe Uniserve just keeps files open for performance (or a bug)?

then changing it so that it doesn't keep more than 200 open should 
fix Will's problems.

Thanks to all for bringing some light, it seams actually the problem 
IS related to file handle limit.
Checked with (suggested by Jaime):
sudo fs_usage -w -f filesys <process id>|grep 'open\|close'
and the number of open and close correspond.
Peter suggested "fstat -p <process id>", fortunately fstat isn't

there in 10.4 Tiger, so I was looking for a similar tool and found
lsof

 for which I did not find the flag to filter for only uniserve process

and there I saw something else was actually consuming file handles..
Sorry Carl to have thought about a rebol error ;-))
Uniserve is rock solid and blazing fast btw.

I take it that OSX is not a server OS.

Will, can you say more about what you used uniserve for and how it 
helped you.  ... in the uniserve group?  I've been waiting for Doc 
to give the presentation "Uniserve for the slow class".

Mike, look in uniserve group

Anybody knows, why there is such a difference between result of 'stats 
and the memory usage shown in tools like 'top or 'taks-manager? For 
example I found, that if I run a script under rebol/base in linux 
and do stats I get something like 1.7MB but in the 'top I see memory 
usage more than 5MB. The same it is under windows - pure rebol/base 
has les ten 1MB but almost 4MB in the task-manager. Strange is, that 
rebol/base shows me more memory usage in 'top, then rebol/core, but 
rebol/core more if I use 'stats.

Hi Oldes, I'm not sure, but I guess, that they are measuring different 
things, e.g. if I use process explorer (from sysinternalts.com) I 
can show 3 different sizes: 

private bytes, virtual size and working set, which differ like this 
...
15.724,           50,832,              8.824
(this is view on windows).

I'm just suprised, that Rebol/Core shows me more memory using stats 
but less in top than Rebol/Base where I have less memory in stats 
but more in top

Its typical for gc-languages. The os-memory-handling is not optimized 
for this case. So they reserve some extra memory for faster allocation.

And the difference between stats and values in top is because in 
top there are counted linked libraries as well:-)