AltME groups: search

Yeah, and that illustrates the consistency argument: if paths with 
a map! as underlying would be redefined to behave like get-paths 
per default, what should get-paths on maps do :) ?

Hi, I corrected http://www.fm.tul.cz/~ladislav/rebol/evaluate.r(I 
omitted a USE-RULE call for the last rule in the script), and renamed 
the accumulator 'a in accordance with industry standards.


Also, I added an efficiency note related to R3 protection disallowing 
us to use a simple binding method to create the USE-RULEs during 
function initialization (creation) instead of creating the USE-RULEs 
every time the respective function is called, which is inefficient.


I wonder, whether we should consider a way how to allow the creator 
of the function to perform some additional initialization during 
function creation.

This is probably the least "cryptic" way how to be able to initialize 
functions:

func-with-init: func [
	init [block!] {initialization code}
	spec [block!] {
		Help string (opt) followed by arg words 
		(and opt type and string)
	}
    body [block!] "The body block of the function"
] [
	spec: copy/deep spec
	body: copy/deep body
	insert body compose/only [
		if init? (init)
		init?: false
	]
	body: use [init?] reduce [
		first [init?:] true
		body
	]
    make function! copy/deep reduce [spec body]
]


>> fr: func-with-init [initialized: now] [] [print ["this function 
was initialized:" initialized]]
>> fr
this function was initialized: 22-Sep-2010/9:36:22+2:00

Pekr, network protocols are still there and bundled within the binary.

Let's use DECODE-CGI as a simple example: currently in R2, you fire 
up R2 and can use decode-cgi in your code straight away.

In the future in R3, the code itself will be bundled with R3, but 
if you fire up R3 and type decode-cgi, it won't be available straight 
away. You'll have to explicitly import the CGI functions with import 
'cgi first.

And obviously there are many REBOL scripts which will never need 
the CGI stuff :)

And to reduce clutter in the "global" default namespace.

The question is what tradeoffs are best? I have to say, even with 
Base available, I like having everything just work out of the box. 
How much does each exclusion save us? This is a tough call. Of course 
I want things lean and mean, but I also don't want every script I 
write to have 5 or 10 lines of import statements for what we've come 
to expect as standard functionality.


Do we have any kind of cross reference or dependency list? That is, 
do we know exactly what we're talking about?

And you can do imports in the header, or on a single line.

and the plus package is on by default, unless you switch it off on 
the command-line.  which is a good idea IMO.

Right, what I don't want is to have to explicitly import "basic functionality" 
in every script. The question is what is basic? And while we can 
certainly do it in a single header line, that's far from the same 
as having it "just work". 


I just want to make sure we're saving enough to make it worthwhile. 
You know how I hate premature optimization. ;-)

And some simple modularisation helps everyone, in the end.

Right, so where is our list of options and dependencies?

Heh, _compiling_ that list of options and dependency is part of the 
work in progress, I think :)

Yes, and that task is important.

Not sure I want to think about what those simple, generic, rebol-leveraging 
funcs might look like. Still, I'll keep an open mind. Show me the 
benefit and let me count the cost.

If we had a list of modules, along with their cost in memory consumption, 
"clutter", and load time, it would be easy to weigh their value.

I guess the first step will be to go through these 480 functions 
and group them into some basic modules: possibly core, extra, math, 
debug.

extra == "plus". In a recent CC bug Carl for example mentioned having 
LAST? in core and moving SINGLE? to plus, if it is still wanted.

(And note that all "plus" functions will still be immediately available 
per default.)

I often use those protocols in console, and I don't want to become 
'import monkey ...

And as I mentioned above, most likely READ will do the import automagically 
for some "blessed" internal modules.

And I'm sure there'll be a way to just put the import in user.r/rebol.r 
and be done with it.

Andreas, while the typing is simple, do you agree that you aren't 
just going to type it once, and that there is a cognitive overhead 
to defining the imports?

Again, I'm not necessarily against it, as long as there is a benefit. 
If the benefit is 3ms faster loading and 30K less memory consumption, 
I will probably say that my time is more valuable than that. :-)

Don't be that anxious about your console. Once modularisation is 
done, it is ridiculously easy to get back a REBOL console with all 
modules and then some enabled and ready to use just like nothing 
ever happened.

Yes, and you'll be nicely able to do just that :)

Sorry for not being here earlier to clear up the misconceptions about 
the module system and functionality split :(

yep, I prefer something short and shiny

Hm, I was in favour of KEY-WORD! or KEYWORD!, but LABEL! is very 
nice and concise.

it also makes 'LIB a reserved word in general, which is not really 
cool either.


I would much prefer if carl at least used the full word 'LIBRARY 
and also 'SYSTEM.. . not 'SYS or 'LIB.


I am sure another word is even better than 'LIB, but 'EXPORTS always 
was perfect already.... so why change that?

I even don't like sys, I thought it is the rename of system, but 
that's not true, so we have got system, and sys. However, it seems 
to me, that Carl needs our eye. I mostly agreed to naming conventions, 
but 'lib and using integer for boot-level is imo an oversight ...

I did a little of research... and found (remembered) the exact word 
it should be called.   

'RESIDENT

The same goes for the 'sys boot level argument - it is also imo not 
accurate. Boot level arguments don't directly link its meaning to 
system contexts and hierarchy. They are more like packages of functionality 
to boot. 'sys should be imo definitely replaced by 'base, which we 
are used to for all those years ...

ok, maybe it is just that my english vocabulary is rather limited. 
In regards to module and oop systems, import/export work rather nicely 
...

I am actually fine with LIB and SYS, but I'd prefer if they were 
not bound in LIB per default. I.e. I'd rather prefer that you only 
have system/contexts/lib and system/contexts/sys to refer to those 
contexts, per default.

uh, what's Carl doing? ;-) He changed the blog content, and now it 
does not make sense at all ... boot levels confusion to the max .....

ah, it changed once again, and now it seems OK :-)

Having short words for the 'lib and 'sys contexts opens a lot of 
possibilities for system simplification. If they are renamed to something 
else, make sure that the replacement words are no longer than 4 characters 
each. And if you don't predefine them in the 'lib context, definitely 
make sute that they are predefined and protected in the 'sys context 
- that way the at least the system code won't be as disadvantaged 
as the user code will be by not including them in 'lib.

IIUC the lib context is automatically imported into the user context. 
So you'll only have to reference LIB if you shadow some name in lib 
with your own definition and then need to refer to the original definition 
again.

BrianH: that does not change the fact, that 'lib as a name sucks 
a lot. It says namely nothing, and in my eyes is a degradation from 
'exports ....

Why would they be referenced a lot?

 - Because we are trying to make using your own versions of the built-in 
 functions as easy as possible, especially through using local definitions 
 of the words. No reserved words in the DO dialect (except the two 
 in MAKE module!). In some cases *only* through using local redefinitions 
 of the words because the built-in definitions may need to be protected 
 from modification. This means that we want to make referencing the 
 built-in definitions as easy and concise as possible. 


This especially the case with the 'sys word, since the context it 
refers to isn't imported by default because it is the context for 
system internals (no, we can't use 'int). When you need to access 
the publicly visible words of 'sys you won't be able to get them 
imported: sys is not a module. You can copy over the words manually 
(maybe with the EXTEND enhancements).


Whether or not the 'lib and 'sys words are defined in the 'lib context, 
they definitely need to be defined where the mezzanines are being 
implemented (which is likely a combination of the lib and sys contexts, 
we shall see). Don't handicap the implementors of R3 just because 
you want to handicap yourself.

Maxim, you made a couple of wrong statements:

it obfuscates the meaning of what that context is...
 (about changing 'exports to 'lib):

Actually, if you read the boot levels blog post, you might notice 
that the R3 module system is now optional at the base boot level, 
and to a certain extent at the sys boot level too. The new role of 
the 'lib context is to be a runtime library - it is not dependent 
on the module system anymore, nor does it necessarily contain any 
exports from anything.

it also makes 'LIB a reserved word in general

Nope, you can override 'lib or 'sys locally in any module or script 
you need to. It might not be a good idea to do so, but that doesn't 
mean that it is not trivially possible. On the other hand, in top-level 
module code the words 'export and 'hidden *are* reserved keywords, 
so watch out.

If you still think that the word 'exports is appropriate, there is 
something you need to know: All this boot code, the 'sys and 'lib 
contexts and such is already pretty much there. And when it's done, 
only then can the module system be added. The 'sys and 'lib contexts 
don't depend on the module system at all, and currently don't include 
any code from it. The module system will integrate into and use the 
'sys and 'lib contexts, but don't define them.

One further question to boot-levels. There are three. And the top 
one is:


mods: initialize up to and including lower-level resident modules. 
In addition to boot-sys, this level adds high-priority resident modules, 
but not mezz plus (higher level mezzanines). 


I am a bit confused - what should I use for CGI? E.g. I don't need 
help, etc.

Hm, I just had error because of the change and had to change the 
datatype to something different. I used email! (I can't use string!), 
but I don't think it's the best replacement for old issue!.

For most actual users of the issue! type the new issues will be faster 
to use. And the "running out of words" argument isn't anywhere near 
as much of a problem as it is in R2, as noone has yet run out of 
words in R3 afaik.

Carl used -'base name, for some thing, which is almost useless, apart 
from few gurus. But I understand why such mode is needed. It just 
should be called 'debug or so. I thought that boot-level is about 
"packages of functionality", and for all long years, by 'base we 
refer to minimal runnable rebol environemnt ...

Pekr, most of the time you will not specify the boot level if you 
are doing CGI. The default (unspecified) boot level loads the module 
system and all of the opt-out modules.

All I needed to know in the past is, that for CGI I need fast system, 
which will not load unnecessary code, e.g. help, etc. Hence I used 
/base executable. Now:


base - initialize only the lower levels. This option is for special 
purpose testing only because it provides no way to load external 
code. (No schemes, such as file access, nor load or do functions.) 
If your host-kit build is crashing on startup, you can use this option 
to confirm that the exe image is loadable and runable.


sys - initialize up to and including the basic runtime lib and sys 
contexts. This option allows you to run a very "lean" system (minimal 
memory and boot time) where your code will be supplying all other 
run-time functions and modules. Provides a basic load function but 
with very limited special options (no import, needs, versions, or 
related features.)


mods - initialize up to and including lower-level resident modules. 
In addition to boot-sys, this level adds high-priority resident modules, 
but not mezz plus (higher level mezzanines).

And as for 'mods. This is why you try to define mezz+ packages? So 
that help will be e.g. in mezz+? So 'mods is now old /base?

Right. And no specified boot level is the old /Core.

This stuff will require very precise documentation and examples, 
explaining e.g. how user can save some cycles for CGI purposes, yet 
how he/she can load his own framework (modules) etc.

The 'sys level is good for really low-level programming, replacing 
the mezzanines with your own, testing host code, all sorts of things. 
And it will enable the few users in the REBOL community who write 
their own module systems to use them instead of the standard one. 
You might be able to build sandboxes at that level too.

I like the SDK aproach - you get your base, and then you include 
any mezz funcs/packages you want. This all now sounds so cryptic 
...

It only sounds cryptic because it isn't done yet. A system redesign 
has been planned for a while now, but we had to nail down the semantics 
of the language first and fix a *lot* of bugs.

The module system, the boot levels, it is all progressive-reveal. 
By default, things are really simple for users and there isn't that 
much to understand. As you learn options you can make the system 
do more tricks, but the default is really simple.

I am putting the finishing touches on the initial implementation. 
More tweaks will be necessary for the integration (mostly renaming 
variables), but the new system model will simplify things a bit. 
In particular, the predefined 'sys word makes the module-tools mixin 
unnecessary, which simplifies the bootstrapping and use of the system 
immensely.

Well, there was a new feature required (delayed modules) that when 
added had wide-reaching implications for the rest of the module system, 
and caused a bunch of other features and the improving of others 
as a side-effect. Also, the old module system violated the "hit by 
a bus" principle: I was the only person who understood the code fully, 
so noone else could modify or enhance the code, and if I went away 
the code would become instantly unmaintainable. So the new code is 
easier to use, does more, and can be understood by the average REBOL 
guru. Believe me, it was that last part that has been the trickiest.

BrianH note that if you read my blog posts, I am rooting for 'RESIDENT... 
not 'EXPORTS.


and thanks for your better explanations they shed a little bit more 
light on the whole thing.

But it will be easier to discuss this once there is a concrete implementation 
to play with and discuss, not just vapour.

And in any case, even having 'lib defined in 'lib won't stop script 
writers from just ignoring it, continuing to use the LIB name for 
their own purposes, and refer to the LIB context as system/contexts/lib 
if they ever need it.

uh oh, now I fear Carl will scrap BrianH's work, and we are going 
to wait for 3 months for Carl to come-up with his own version :-)

I hope this is not the case, however following is scary, while understandable 
-  ".... a fight between simplicity and complexity, between maintainability 
and chaos, between elegance and ugliness"

no Brian is doing the module work, its just that the changes to how 
the contexts are now layed out provoke deep changes in how things 
are bound.


because that is a big part of the module system's job, it means Brian 
has to update a lot of the code.


also remember that Brian has been splitting up the module code into 
sub-functions, so all of that makes it simpler, and more re-usable.

Earlier prototypes worked well. They were functional, clean, and 
simple. Understandable.

 - that simply means, that Carl does not like something about current 
 system ...

They where coding at opposite ends of the spectrum, now they are 
fighting to merge the two together.  that's how I read it.


IMO its just a question of getting it to work again. with new contexts 
layout and new, better module functionality.

The module system has grown to include many advanced features, which 
are all usefull and viable.  Brian has been working to simplify the 
code by breaking it up into smaller pieces.   At some point you can't 
have features without at least a minimal amount of code.


The new contexts layout makes it a more complex task because my guess 
is that basically, its broken everywhere and that is hard to debug.


The original module system wasn't very powerfull in the sense that 
it didn't add much more than special objects... what Brian is doing 
is sooooo much more than that.

So I don't think Carl and Brian are fighting... hehe

I think they are fighting the code  :-)

I've looked at the module code and it was a large and barely understandable 
by its complexity.  Even by Brian.   He was already working on this 
problem... its just that now that its all broken, they can't ignore 
it anymore  ;-)>

We weren't ignoring it, trust me. I have been working on integrating 
the new features, which resulted in a redesign of the semantics. 
But the code was intimidating even after the rewrite, and there were 
some repeating awkward code patterns that needed native replacement, 
which I couldn't do. The new module system that Carl and I are working 
on is based on my work, even if the code may not resemble my code 
on a surface level.

Main changes so far, relative to my recent work:

- A different code style which Carl thinks will be easier to read 
and maintain (mostly using CASE/all).

- Some of the more awkward repeating code patterns have been split 
out into functions, which in some cases will be made native.

- The API of LOAD has been simplified, though is more flexible. Its 
behavior with no options is the same, but some options have changed.

- Some functions are renamed, and some code has been moved from function 
to function (this was expected).

- The sys and lib contexts take the role previously planned for the 
exports context and module-tools mixin, though the usage is the same.

- Fewer functions will be exported into lib than I was expecting. 
The short names of the lib and sys contexts enable this.

Those first three were tricks that I couldn't do, because I don't 
set the standard APIs and don't write the natives. But the core semantics 
are quite similar to my recent work.

Here's a low-level function to parse and process script headers, 
which shows how many features are built into the base script model 
in R3:

load-script: funct [
	"Decode a script into [header-obj script-ref body-ref]"

 source [binary! string!] "Source code (string will be UTF-8 encoded)"
	/header "Return the header object only, no script processing"

 ;/check "Calculate checksum and assign it to the header checksum 
 field"
	/original "Use original source for Content header if possible"
] compose [
	data: either string? source [to-binary source] [
		unless find [0 8] tmp: utf? source [ ; Not UTF-8
			cause-error 'script 'no-decode ajoin ["UTF-" abs tmp]
		]
		source
	]

 ; Checksum all the data, even that before the header or outside the 
 block
	;sum: if check [checksum/secure data]  ; saved for later
	
	if tmp: script? data [data: tmp] ; Find the start of the script
	
	; Check for a REBOL header
	set/any [hdr: rst:] transcode/only data
	unless case [
		:hdr = 'rebol [ ; Possible REBOL header
			set/any [hdr rst] transcode/next/error rst
			block? :hdr ; If true, hdr is header spec
		]
		:hdr = [rebol] [ ; Possible script-in-a-block
			set/any [hdr rst] transcode/next/error rst
			if block? :hdr [ ; Is script-in-a-block
				unless header [ ; Don't decode the rest if /header
					data: first transcode/next data
					rst: skip data 2
				]
				true
			] ; If true, hdr is header spec
		]
	] [ ; No REBOL header, use default
		hdr: [] rst: data
	]
	; hdr is the header spec block, rst the position afterwards

 ;assert/type [hdr block! data [binary! block!] rst [binary! block!]]
	;assert [same? head data head rst]
	
	; Make the header object, or fail if we can't

 unless hdr: attempt [construct/with :hdr system/standard/header] 
 [
		cause-error 'syntax 'no-header data
	]
	; hdr is a correct header object! here, or you don't get here

 ;if check [append hdr 'checksum  hdr/checksum: sum]  ; calculated 
 earlier

 ;assert [sum =? select hdr 'checksum]  ; Should hdr/checksum be reserved?
	

 if header [return hdr] ; If /header, no further processing necessary

 ; Note: Some fields may not be final because post-processing is not 
 done.
	
	; Skip any whitespace after the header

 ws: (charset [1 - 32]) ; For whitespace skipping (DEL not included)
	if binary? rst [parse rst [any ws rst:]] ; Skip any whitespace
	
	; Check for compressed data and decompress if necessary
	case [
		; Magic autodetection of compressed binary
		tmp: attempt [decompress rst] [
			data: rst: tmp  ; Use decompressed data (no header source)
			append hdr 'compressed  hdr/compressed: true ; Just in case
		]
		; Else not directly compressed (without encoding)
		(select hdr 'compressed) != true [] ; Not declared, do nothing
		; Else it's declared to be compressed, thus should be
		binary? rst [ ; Regular script, check for encoded binary
			set/any [tmp rst] transcode/next/error rst
			either tmp: attempt [decompress :tmp] [
				data: rst: tmp  ; Use the decoded binary (no header source)
				hdr/compressed: 'script  ; So it saves the same way
				; Anything after the first binary! is ignored
			] [cause-error 'script 'bad-press -3] ; Else failure
		]
		; Else it's a block, check for script-encoded compressed binary
		tmp: attempt [decompress first rst] [

   data: rst: tmp  hdr/compressed: 'script  ; It's binary again now
		]
		; Else declared compressed but not compressed, so fail
		'else [cause-error 'script 'bad-press -3]
	]
	
	; Save the script content in the header if specified
	if :hdr/content = true [
		hdr/content: either original [source] [copy source]
	]
	

 ;assert/type [hdr object! data [binary! block!] rst [binary! block!]]
	;assert [same? head data head rst]

 reduce [hdr data rst]  ; Header object, start of source, start of 
 body
]


Note all the commented assert statements: they are for testing (when 
uncommented) and documentation. Also, I later removed the checksum 
calculation from this code because it was the wrong place to put 
it, at least as far as modules are concerned. However, Carl didn't 
know this because he was working on it while I was offline for a 
few days.

Here is the corresponding function in the code reorg, renamed. The 
friendly empty lines and comments haven't been added yet.

load-header: funct/with [
	"Loads script header object and body binary (not loaded)."

 source [binary! string!] "Source code (a string! will get UTF-8 encoded)"

 no-decompress [logic!] "Skip decompression of body (because we want 
 to look at header mainly)"
][
	; This function decodes the script header from the script body.

 ; It checks the 'checksum, 'compress and 'content fields of the header.

 ; It will set the 'content field to the binary source if 'content 
 is true.

 ; It will set the 'compress field to 'script for compressed embedded 
 scripts.

 ; If body is compressed, it will be decompressed (header required).

 ; Normally, returns the header object and the body text (as binary).

 ; If no-decompress is false and the script is embedded and not compressed
	; then the body text will be a decoded block instead of binary.
	; Errors are returned as words:
	;    no-header
	;    bad-header
	;    bad-checksum
	;    bad-compress
	; Note: set/any and :var used - prevent malicious code errors.
	case/all [
		binary? source [data: assert-utf8 source]
		string? source [data: to binary! source]
		not data: script? data [return reduce [none data]] ; no header

  set/any [key: rest:] transcode/only data none ; get 'rebol keyword

  set/any [hdr: rest:] transcode/next/error data none ; get header 
  block

  not block? :hdr [return 'no-header] ; header block is incomplete

  not attempt [hdr: construct/with :hdr system/standard/header][return 
  'bad-header]

  :hdr/content = true [hdr/content: data] ; as of start of header (??correct 
  position??)
		:key = 'rebol [ ; regular script

   rest: any [find rest non-ws rest] ; skip whitespace after header

   ;rest: any [find rest #[bitset! [not bits #{7FFFFFFF80}]] rest] ; 
   skip whitespace
			case/all [

    all [:hdr/checksum :hdr/checksum != checksum/secure rest] [return 
    'bad-checksum]

    no-decompress [return reduce [hdr rest]] ; decompress not done

    :hdr/compress = 'script [set/any 'rest first transcode/next rest]
			] ; rest is now suspect, use :rest
		]

  :key = [rebol] [ ; embedded script, only 'script compression supported
			case/all [
				:hdr/checksum [return 'bad-checksum] ; checksum not supported

    no-decompress [return reduce [hdr rest]] ; decompress not done

    rest: skip first transcode/next data 2 none ; decode embedded script

    :hdr/compress [hdr/compress: unbind 'script  set/any 'rest first 
    rest]
			] ; rest is now suspect, use :rest
		]

  :hdr/compress [rest: attempt [decompress :rest]] ; :rest type-checked 
  by decompress

  not :rest [return 'bad-compress] ; only happens if above decompress 
  failed
	]

 ;assert/type [hdr object! rest [binary! block!]] ; just for documentation
	reduce [hdr rest]
][
	non-ws: charset [not 1 - 32]
]

Notes:

- The other half of the CASE/all style is a lot of explicit shortcut 
RETURN statements, whenever the normal flow differs.

- Errors are returned as a word from the error catalog, which is 
later passed to CAUSE-ERROR.

- Carl redid the checksum calculation so that scripts can verify 
against a checksum in their header, to detect corruption.

- The checksum in the header probably can't be used for the module 
checksum because the header itself matters for modules.

- Compressed scripts lost a couple minor, unimportant features that 
we are likely better without. Quiz: What features?

- Part, but not all of the reason the code is shorter is because 
the doc comments haven't been added yet. The CASE/all style helps 
though.

The new code is not much less complex than the original, but it is 
more compact and faster too. And it is easier to maintain, because 
rearranging CASE clauses is easier to do without a full reorg than 
nested conditional code.

can someone please tell me how we can generate errors in R3.  cause-error 
has no list of appropriate values and everytime I've tried to use 
it it just fails with "you have no clue" errors.

one function which I would really like to see added to R3 is a search 
function which searches the body of all resident code and returns 
paths or full text of every place an occurence of your search is 
found.

in this case, I could see where cause-error is used and could learn 
from the mezz code.

It seems    do  to-error "whatever"    also works.


but I'd like to get the list of valid types and expected args for 
cause-error.

I hope the  above function makes it easier for you guys to track 
down where words are being used and defined.  :-)

note, it only accumulates then within objects and functions for now.

Maxim, to answer your questions about cause-error: Three arguments, 
the first two being words from system/catalog/errors, the last one 
eiither being a single value of any type or a block of up to three 
values, depending on which error you are generating. All the info 
you need about a particular error is in system/catalog/errors. The 
number of arguments in the argument block is fixed, per error. The 
usage is in the phrasing of the error message. Pick arguments that 
when molded and put in that position in the error message would make 
the error message make sense.

CAUSE-ERROR is mezzanine in R3 and 2.7.7, so just source it :)

yes, that would be a good first clue, since the current docs give 
no indication on how to proceed right now... 


I should have sourced cause-error, and I usually do... but this time 
well... I guess I assumed it was a native  :-)

First thing I do when wondering about a function is HELP it. That 
tells me the basics, and also mentions its datatype.

I took Brian's notes from above and edited some basic CAUSE-ERROR 
docs around them.

No bound copy of a function body, for security reasons. The kind 
of hot-patching that was possible in R2 was always a security hole. 
Plus, it's not task-safe. For that matter, BODY-OF always returns 
a copy or constructed value, never the original, and code that currently 
uses it relies on this.

There are two ways of hiding values. The tricky way is to use PROTECT/hide 
on a publically visible context. The more common, easier way is to 
use contexts that aren't publically accesible. There is no way that 
a reflector can tell if a bound context is not accessible, but the 
unbind trick prevents that kind of hack. And since inaccesible contexts 
might contain private information like encryption keys that might 
not belong to the person running the R3 process, there is no security 
setting that can make this safe to not do.

I just finished a very powerfull new version of the search tool... 
it now even allows you to search for any value, even unset!. ( I 
just did a search to find all unset words in the whole system and 
it works without a hitch... )


also, if some data in the system is a string, it tries to find a 
formed value of your search value inside of it:-)

well, we can, but its severely limits debugging and frankly there 
is a way to do .   any context should have the possibility of having 
a private/public flag on it... its that simple. whenever you try 
to reflect a private context, it returns unset! (unbound) values.

It is assumed that people doing debugging have access to the source. 
And in the case of source written in REBOL, that is likely the case 
now.

Though debuging the source and a runtime session, is not the same 
thing.

if things really need to be private, then anything which comes from 
a private context could just be flagged as such and inspection routines 
wouldn't return their values.

I can (and do) want the world to be open and all information to be 
free, but it's just not the way the world is now.

And you can debug if you have the source. However, some of the process 
will go through your head, in the form of knowledge of where functions 
are defined. Or you can take portions of the source without the protections 
and debug them independently.

Right, and that kind of thing works now. But allowing a debugger 
to get past the protections just isn't going to happen. We don't 
have a way to know at runtime which person needs to be asked for 
permission to break past a protection like that. Since it certainly 
isn't the user.

you will just have to furnish mezzs to replace the standard, func, 
funco and funct

Yes, and replace those functions before the system is protected to 
support the reset.