World: r3wp

http://www.rebol.com/r3/docs/functions/cause-error.html

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.

BODY-OF doesn't return the original for objects or modules either.

the copy I don't mind... that's cool, its the fact that it always 
unbinds (which is what you seem to say).  its not a security hole 
if the functions aren't hidden or protected in some way.


I just want to know what a function within a function actually is 
calling... if its unbound... well I can't make any real inspection 
tool or debugger... right now I can go a lot further than R2, except 
this ... unless I didn't properly understand you.

its a bit like a dll, you only have access to the dll within a debugger 
if it was compiled with debugging... I'd like that to still be the 
case within rebol.

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

Maxim, I felt the same back In time. A tool like anamonitor is not 
anymore possible. (cry on my face)

But DRM is. Whether you consider that an advantage or not though...

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.

but you cannot resolve the run-time in data. since things are bound 
dynamically.  the name of a func is useless... we need to be able 
to trace it back to its context by getting its value.


this doesn't give us the context, but at least we can see what the 
function really is.

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.

if we can't have full fledget debugger, then we are crap :-)

maybe we could have a FUNC idiom that doesn't protect anything for 
debugging purposes ?

right now, the only thing I can't "anamonitor" is a function body. 
 I can get that function's body, but can't resolve what the functions 
*it* contains really do.  


all the rest works pretty much as is did, actually it works better, 
since we have real inspection routines now.

If we want to be able to use R3 to show third-party content, then 
full debugging without the original source won't be allowed. It's 
the way of the world now.

brianh, we can't debug *with* the source right now  :-)

Ok, but for our own work, we still need to do so.

hehe

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.

huh? BrianH this has nothing to do with 3rd party.  we can't debug 
functions of any kind right now.  with source, hot chocolate or from 
the movie wizard of Oz.

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.

debugging implies that a tool shows you that information... the name 
of a function or word is irrelevant in REBOL.

If you need to debug your own source, you can do so. You just can't 
use a debugger to get past the protections.

for example, if I want to do a real time debugger which shows me 
the current content of the block which is being stepped through by 
a loop... 

I can't since I can't get access to the block which is being used 
by that function...

Yes Maximn, to do runtime debugging, we must be allowed to construct 
observable functions

There are other methods of debugging at runtime if you have the source. 
Heck, even good old print statement debugging would work.

it could be simulated with a special mezz. A function which executes 
an indirect DO on one code block instead of building a function.

So that the code block could still be inspected by a debuging tool.

hum... maybe a way to build a context when building a function, with 
the index of each member of the body block mapped out to its original 
source.

yep it should work

then the debugger could inspect the context instead.

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

we could be able to do this by switching to a "debug" version of 
the various func creating mezz

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

we could even make those functions able to trigger events based on 
"break points"  then listen on those events in a normal event loop.

so the debugger actually adds a line of code where the break should 
happen... then rebuilds the body block it executes when its called.

They could even be trace events.

since the external function isn't replaced, its transparent .

Pekr - "if we can't have full fledged debugger, then we are crap 
:-)"

Agreed, though maybe not complete crap.


Brian - "Heck, even good old print statement debugging would work."

Agreed, to an extent.

Brian - "They could even be trace events."


Ahhh, joy. What can we learn from DTrace, and what should modern 
debugging look like? I have, at times, ached for the ability to step-trace 
and set break and watch points in REBOL. At the same time, I don't 
want to be myopic and focus on how we debugged in the past.


What are the best ways to debug the things we're supposed to build 
with REBOL? And can we hope for mechanisms to let us debug things 
outside what RT says REBOL is targeted at?

using replacement function builders we could, in theory, completely 
control how execution occurs.  this would be at some speed cost and 
possibly not 100% transparent.


but setting break points and real-time value watching is definitely 
in the realms of possibility.

I just don't want to preclude the use of R3 in the biggest industry: 
content delivery and presentation.

Or for that matter, any secure client systems. Most cryptographic 
security is based on secrets. If we can't keep secrets, we can't 
be used for those purposes.

Other secure systems are debuggable

As is R3, just using different methods. You might notice that DTrace 
doesn't allow you to read the iTunes process on OSX.

Not everyone is on the board of Disney