World: r3wp

repeat  n 100 [
	print join "top of loop LN:" [n]
	catch [
		print "top of CATCH"
		if random 10 > 5 [ throw ]
		print "BOTTOM BELOW THROW CONDITIONAL"
	]
	print "BOTTOM BELOW CATCH"
]

regarding the source of minimum-of and maximum-of, i assume they 
fall in the wrong side

They are infrequently used functions, and as such are a good candidate 
to be mezzanines, for 2 reasons:
- Frees up some native space for more important functions.
- Easier to modify or replace with better functions.

The really interesting thing is the intrinsics - REBOL code called 
internally by natives.

i see, sort of hooks, but currently there's only 3 intrinsics func, 
is that enough ?

For now, there are 5 intrinsic functions. There can be more later.

it could be amazing if we have an intrinsic func for each type of 
value (when they are evaluated) but i assume it would be very slow

You are thinking of actions.

(seems devbase is not up to date, i see only 3 functions)

There are several dozen actions.

in which group of devbase are they filled (actions) ?

DevBase is up to date (as of this week, except for the View stuff). 
The other intrinsics are defined elsewhere in the source.

Actions are native code, which is not in DevBase yet.

ok, i see the actions now, do u say that we can redefine actions 
?

efishant - for what you want to do with the loop just put the while 
loop inside a function (assuming you manipulation a series) and then 
have it break out on a conidtion is met and then change the series 
to the desires position and pass back to the function if needed. 
 Not sure exactly what your trying to accomplish.

No, but actions are handled on a type-specific basis, and R3 will 
have user-defined types.

Also efishant regarding ports you don't need to use port/state/index 
as you can just use 'at.

The list of actions is fixed (for the REBOL version). Each datatype 
has its own set of action handlers though.

Paul, does the INDEX? function return the port/state/index of a port! 
type?

It returns an integer

integer!

i see Brian, so that we can create new datatype (overriden the primary 
ones) so that we can use our own combinations of actions

I mean, is that integer! the value assigned to the port's state/index 
field?

yes it is

Steeve, I'm not sure how well you can override a built-in types (not 
decided yet), but you will be able to create new ones.

My belief i s that difference is that index is used to move the head 
to the specific position of the file where as using 'at keeps you 
at the head of the file.

But I don't know and asked before here and got no answer.

Paul, Brian, others, i used to manipulate the port/state/index with 
read-io and write-io because it's faster (i made some tests).

But the main reason is that we can directly manage the buffer used 
so that we avoid some overhead existing in the standard port handler

Paul, you don't move the head, you move the position. AT and SKIP 
are relative to the current position, 1 or 0 based respectively. 
INDEX? returns the current position, relative to the head.

How did you do those test STeeve?  I have been interesting in changing 
Trebases operation depending on how that works.

Right Brian but it doesn't seem to.

I'll defer to Steeve on this one - I am more familiar with the R3 
port model than the R2 one.

Not with the file port Brian.  At  seems to always work from the 
head.

if you open a port in direct mode it is always at head but in seek 
mode you can pick from the a specific point in the file.

Yeah, the port-as-series model doesn't work with direct very well.

Paul, it's just using port/state/index is theoricaly faster than 
at (because at is a wrapper)

internally 'at uses port/state/index

you can  see the source (i don't remember where)

iirc

the most annoying overhead comes from the wrapper of the copy func.
you should use read-io instead of, if you want very fast access

read-io and write-io use correctly the port/state/index, just don't 
forget that port/state/index is zero based (seems to be a bug)

Steeve, yeah I would assume that is the case.  So the difference 
your seeing in performance is really just a small one as a result 
of the 'at then being a wrapper?

I'm might do some tests here to see myself

agreed it's a small overhead concerning at, but not concerning copy 
(see the source if you find it)

source for what?

source for the file port handler, ok i'm looking for it....

You can't see the source of the file port handler.

in the past i found something...

It's native code.

perhaps it's the scheme to be exact