r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

[unknown: 5]
27-Apr-2008
[10297]
If I have a block of datatype shouldn't I be able to do?:

find blk datatype!
BrianH
27-Apr-2008
[10298]
Yes, you can do that:
>> find [a 1 3.0] decimal!
== [3.0]
>> find [a 1 3.0] integer!
== [1 3.0]
>> find [a 1 3.0] word!
== [a 1 3.0]
[unknown: 5]
27-Apr-2008
[10299]
yeah I know that but not datatype!
BrianH
27-Apr-2008
[10300]
Oh wait, I didn't get your question
[unknown: 5]
27-Apr-2008
[10301]
in other words what if the blk has the following:

blk: [string! 2 4 5 6 integer! 7 8 9 decimal!]
BrianH
27-Apr-2008
[10302]
After checking, I got this:
>> find [1 integer!] datatype!
== none
; This is right
>> find reduce [1 integer!] datatype!
== none
; This shouldn't happen
[unknown: 5]
27-Apr-2008
[10303x2]
Yeah that is the problem I see.
I would think we would want to be able to find out if a block contains 
a datatype given that we might not know what the datatype is if it 
is populated dynamically.
BrianH
27-Apr-2008
[10305]
The parse equivalent doesn't work either:
>> parse reduce [1 integer!] [to datatype! x:] x
** Script Error: x has no value
** Where: halt-view
** Near: x
[unknown: 5]
27-Apr-2008
[10306]
Yeah I know I ran into that problem already as well.
BrianH
27-Apr-2008
[10307]
I haven't seen anyone put actual datatypes into blocks before; normally 
people just put the datatype words in as keywords. I wonder if this 
bug is the reason why.
[unknown: 5]
27-Apr-2008
[10308x2]
Could be.  I use it in TRETBASE
I use it in TRETBASE to define the datatype of each respective field. 
 It saves time and performance cost.
BrianH
27-Apr-2008
[10310]
Perhaps you could use the datatype words as keywords instead.
[unknown: 5]
27-Apr-2008
[10311]
I had it that way previously.  Now in my last release I do a save/all 
to serialize though and this has been a big boost for TRETBASE.  
I really don't need the find blk datatype! feature at this point 
but just pointing it out.
BrianH
27-Apr-2008
[10312]
Good catch.
[unknown: 5]
27-Apr-2008
[10313]
Thanks Brian.  Just wanted to post it and see if it wasn't by design.
BrianH
27-Apr-2008
[10314]
Fortunately the words can be converted to datatypes and back pretty 
easily.
>> type? to datatype! to word! integer!
== datatype!
[unknown: 5]
27-Apr-2008
[10315]
I'll submit it to Rambo as a bug even though I'm not sure it is one. 
 It just may be that nobody was thinking of doing such.
BrianH
27-Apr-2008
[10316]
If it were by design, I can see what the benefit would be. Datatypes 
and their words can be easy to get mixed up. If you make it harder 
to store datatypes in blocks and such, people would eventually avoid 
such behavior. It's similar to the way that lit-words are word-active, 
converting to words implicitly, as Fork found out.
[unknown: 5]
27-Apr-2008
[10317]
I'm sure the applications that would use such scenarios are few so 
I don't think the lack of that capability is a high priority by any 
means.
BrianH
27-Apr-2008
[10318]
These self-evaluating values can be tricky sometimes. Many get tripped 
up by the datatype words, none, true and false. :(
[unknown: 5]
27-Apr-2008
[10319]
I agree.
Robert
28-Apr-2008
[10320x3]
What's the best and safest way to execute a block of code in a function 
context? Example:

exec: func [code-to-execute][
	a: 1
	b: 1
	do code-to-execute
]

exec [print a + b]
This should give
>> 2
I know there is some "safe" way to do it but can't remember.
Dockimbel
28-Apr-2008
[10323x2]
if a & b are locally defined, you should first BIND the block to 
execute like this : do bind code-to-execute 'a
A "safe" way (preventing malicious code) could be to parse your block 
to execute and allow only some words. In others words, you can achieve 
safety by filtering the code to execute using a reduced dialect of 
REBOL. You could also just define some additional local words to 
"disable" them (like: halt, quit, call, etc...) There's several approches, 
they depend on what "safe" means to you in this context.
Oldes
28-Apr-2008
[10325]
Is it a bug or there is some system limitation which prevents to 
set a  modification-date of folder?
Robert
28-Apr-2008
[10326]
Doc, thanks.


Has anyone written a rebol code stripper to make a safe (not harming 
the executing process) way to execute code-from-the-wire?
btiffin
28-Apr-2008
[10327]
Maxim once mentioned that he spent a lot of time sandboxing his Elixir 
engine.   iirc, he was confident enough to let it be open to random 
code.
BrianH
28-Apr-2008
[10328]
That may not be technically possible in R2, once the code is loaded, 
but should be possible in R3, in theory. You could still be vulnerable 
to interpreter bugs that can crash REBOL, but you could sandbox against 
attempts to break the sandbox.
[unknown: 5]
28-Apr-2008
[10329]
How is that done in R3?
BrianH
28-Apr-2008
[10330x2]
Well, for starters:
- Words are unbound by default.
- Modules only load the contexts they are told to.

- Reflection is done by a separate native with some mezzs wrapped 
around it, not the ordinals.
This means (respectively to the above):

- You don't have to block everything, you can just allow what you 
want.

- You can just sandbox a module by having it not load the system 
context, or load your own substitute.

- You only have to eliminate one function to close the reflection 
hole, rather than replacing the ordinals with mezzs, slowing down 
all code.
Henrik
28-Apr-2008
[10332]
hmm... why does launch/quit not work with URLs?
[unknown: 5]
28-Apr-2008
[10333]
Thanks Brian, I suppose I will have to get exposed to that nature 
to understand it.
BrianH
28-Apr-2008
[10334]
Same here: Modules aren't anywhere near done yet :(
Henrik
28-Apr-2008
[10335x2]
the same when I use:

launch http://somewherequit

I wonder what the issue is here.
weird..

launch http://somewherewait 0.01 quit

works
Graham
28-Apr-2008
[10337x2]
Oldes - it's a very old bug
We should try and get that fixed for 2.7.7
Henrik
29-Apr-2008
[10339]
I'm (again) studying how to get LAUNCH to accept args when launching 
a script, when I came across this in the SDK manual:


For example, if you want to launch a second copy of your program 
to process an action:


    launch 
-c do-it"

  It says it's a special function of encapped programs, but does -c 
  do the same thing as for an ordinary rebol executable, namely --cgi?

When 
  using the same string in a regular rebol console, I get just the 
  help output as if the argument list was wrong. It won't accept any 
  other arguments except if the script name is passed as a string.
Anton
29-Apr-2008
[10340]
Oldes, modification date - can you post to Rambo.
[unknown: 5]
29-Apr-2008
[10341x2]
Is this a bug?:

>> to-block mold [<]
** Syntax Error: Invalid tag -- <
** Near: (line 1) to-block mold [<]
You might ask why would someone want to mold a block and then use 
to-block on it.  If you have added a block via the console across 
more than one line you will pick up the newline character in your 
block which you can trim/lines on if you mold the block.
BrianH
29-Apr-2008
[10343x2]
Just a syntax side effect. Try: to-block mold [ < ]
< is normally part of a tag, but there is an exception made for when 
it is surrounded by spaces.
[unknown: 5]
29-Apr-2008
[10345x2]
Yeah but that would still be a bug wouldn't it?
>>  to-block mold [ < ]
** Syntax Error: Invalid tag -- <