World: r3wp

we'll see when it gets done... and I'll be the first in line to test 
it   ;-)

SECURE is a mezz in R3, so DO/secure would need to be implemented 
in the intrinsic DO*. But It might be better to add as a SECURE option 
instead.

Right now SECURE is self-contained. If you make DO* implement DO/secure 
that would make DO* less replacable. If you implement it as SECURE/do, 
it would be easier to do without breaking SECURE's security.

maybe the policy system on which secure is run could use a stack... 
so that we could do secure/push  secure/pop style pairs.

That wouldn't work, because you would have to ask user permission 
to pop, at which point we are back in the same situation.

The only way to get around SECURE's user request thing securely is 
to do it within SECURE, and restore it before the initial call to 
SECURE returns.

Of course this means that security would be task-local, which would 
have interesting advantages as well.

All this might mean making a MAKE-TASK* intrinsic similar to MAKE-MODULE*, 
but we can't know that yet.

yeah... but something like:

secure/do [... policies ...] [

	... code ...

]


looks like the best way... though the current native security system 
doesn't support this natively.   the set-policies/get-policies do 
not operate within a stack frame but within a global heap.

it would require the security system to use the stack frame to push/pull 
"current" policies to the global set (of each task)

Maybe not, we might be able to do this in SECURE itself. But it would 
require the policies to be task-local.

The increasingly off-topic nature of this conversation makes me wish 
more and more that this was R3 chat. Then we could move messages.

off-topic?  we changed topic.

Core is for issues that aren't as R3-specific as our conversation. 
We should be discussing CATCH/all and SECURE/do in the !REBOL3 group.

but I am realizing there might be an R3 topic missing.   something 
like new ideas, proposals, etc.

to make it clear that discussions there aren't related to *Using* 
R3 but in how it can be improved.

all covered by !REBOL3

That is what !REBOL3 is for. Once the ideas are established we make 
topical groups for them, like !REBOL3 Graphics.

Formal proposals go in CureCode (eventually, after discussion in 
!REBOL3 or on a blog or wiki page).

well, where is generic *using* R3 group then?

anyhow... its just that more groups is faster than really big ones, 
so separating the use and proposal discussions seem to be a good 
thing in my mind.

Brian, in

http://www.curecode.org/rebol3/ticket.rsp?id=1744&cursor=2

you wrote: "We already have local THROW and RETURN"


If we do, I must have missed them, knowing only the global variants. 
Can you point me to them?

I would say, that this looks as a terminological misunderstanding 
to me.

I explain it for RETURN, but the case of THROW is similar. Normally, 
when you use RETURN in REBOL, it is a global function that does something. 
I demonstrated, that it is possible to have a similar construct (possibly 
even using the same name), which could work as "local" in the sense, 
that it would be assigned to a locally-bound 'return word. Such a 
"local RETURN" would, in fact, be able to "jump many levels up", 
not just one level, as the current global RETURN does, since it would 
be tied to its "function of origin".

return/to

instead of "tied" I should rather have said "bound"

(i.e. no refinement is needed)

>> a: [ b [ c [ 1 ]]]
== [b [c [1]]]
>> d: 'b
== b
>> e: 'c
== c

using a, d, and e, how would I get the value "1" ?

There may be better ways:
   first do to-path reduce ['a get 'd get 'e]

thanks

>> a/:d/:e/1
== 1

more things to try :)

Great .. works

is there a quick way to determine whether a string is enbased without 
debasing it?

Well, enbase.base 2 is easy:
     string: enbase/base "cffdf" 2
     "01" = sort unique join "10" string
And that is easily extendable to the other bases

But you might get some false positives -- say a base 16 number happened 
to be all 0s and 1s.

I think that might be OK. It's just that I need to process some fairly 
large strings 50-100 kb each and it should really happen in near 
real-time, if possible.

Good luck!

For raw speed, experiment with dropping the SORT -- and try DIFFERENCE 
- it may be faster for large strings.
    "" = difference "01"  join "10" string

Curiously, this works in R2:
    x: charset ["0" "1"]

    find x string     ;; returns TRUE for all strings made up of just 
    "0"s and/or "1"s

It does not work in R3 -- which may be deliberate and sensible.

Don't worry, I added another comment that deals with the terminological 
problem :)

You were focusing on localiity of where the code was written, and 
I was talking of locality in the code that the flow of execution 
goes through at runtime. For instance, #1744 makes it difficult for 
non-local-definition code to do man-in-the-middle attacks or spoofing, 
making it useful for secure mezzanine control flow functions. But 
#1518 prevents you from being able to pass THROW/name through unknown 
code at all, making it useless for making mezzanine control flow 
functions at all. Fixing #1518 is what we do to make #1743 possible, 
and once #1520 is implemented then the arms race will be over, everything 
else could be mezzanine or user-defined.

Henrik, i suspect that debasing may be faster than checking eg. with 
parse. are we talking base64 here or just base 2 and 16?

base64

given: http://en.wikipedia.org/wiki/Base64

>> base64: charset [#"A" - #"Z" #"a" - #"z" #"0" - #"9" #"+" #"/"]
== make bitset! #{
000000000088FF03FEFFFF07FEFFFF0700000000000000000000000000000000
}

>> parse "c3VyZS4=" [any [4 base64] [3 base64 #"=" | 2 base64 2 #"="]]
== true

ok, thanks

you may want to compare this to actual debasing to see which is faster 
on a big string. debase being native it might actually be faster.

(though, the allocation and copy of data could be significant enough 
on a big string for something like this to be worth it...)

yes, I suppose also it can't be 100% foolproof, since you can enbase 
nonsensical data?

well... enbase just converts binary (8-bit) data to a form that is 
ascii printable. it does not say anything about what the 8-bit data 
contains.

If I need case sensitive SWITCH and still want to use string values, 
is there any other way than using PARSE/case instead?