World: r3wp

%rebol.r is very usefull when it works under R2 (which it doesn't 
most of the time).  you can put a few generalized functions you always 
want access to... setting lib pats, protecting/securing them, loading 
some libs by default, etc.

where is the %rebol.r file supposed to be in R3... In the same dir 
as %rebol.exe... no?

In the same directory as rebol.exe, yes.

Under R3 the generalized functions would be in modules - it makes 
scripts more predictable.

well, I've been doing that for years with slim  ;-)

Inspiration!

so, it wasn't all for naught !  cool    ;-)

btw the extensions really are a god send... its cool you wrapped 
them into modules.  good work.

Even more so soon - I've been busy.

I just discovered more reasons why you need to be careful with %rebol.r: 
It's more powerful than I thought. The %rebol.r script runs in the 
system context before the user context is created, and before the 
system object is protected. It's almost like having your own host 
code.

that is what I would expect it to do.  this way I can really use 
protect before any real code is run, and I can safely manipulate 
the global context... possibly having custom monitored versions of 
some low-level stuff like networking and I/O... so I could see what 
is going on, and even install safeguards against some external resources.

Does anyone know of any way to detect alt-down and alt-up events?

or a way to detect whether capslock is down or up?

If by alt-up/alt-down you mean alt-key modified up-key/down-key in 
opposite to plain up-key/down-key, with current R2 that's not possible 
to detect, afaik since not all OSes R2 has been designed for feature 
such a system specific key. Detecting caps lock isn't supported, 
too.

I'm sorry, wrong group, that's R3 here, so the above simply doesn't 
apply.

Time for you to chime in, Henrik :)

Hmm... let's see. :-)

I don't think caps lock is possible to capture right now.

Regarding alt-up and alt-down, you just check for them in the ON-CLICK 
actor:

	on-click: [ ; arg: event
		if arg/type = 'alt-down [foo]

When investigating the creation of a MAP function in REBOL 2, I found 
that sending functions with refinement to map required some extra 
work (the need for a DO). The rules about get-words as arguments 
has changed in REBOL 3. Maybe I should talk to Carl about it, but 
I could discuss it with you guys first to not disturb Carl too much. 
First a REBOL 2 version of MAP, that can't cope with refinements:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r f 
i] r]
>> map sine [0 30 90]
== [0.0 0.5 1.0]


f is the function, l the list and r the result. i is an item in the 
list. The critical part is

append r f i


The function f is evaluated taking the argument i. Easy to read and 
understand. But it can't cope with refinements, which are seen as 
the path! datatype. Example:

>> map sine/radians reduce [0 pi / 6 pi / 2]
== [sine radians sine radians sine radians]


This can be fixed by putting a DO before f. Now it works both with 
and without refinements:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r do 
f i] r]
>> map sine [0 30 90]
== [0.0 0.5 1.0]
>> map sine/radians reduce [0 pi / 6 pi / 2]
== [0.0 0.5 1.0]

In REBOL 3, the function is not evaluated:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r f 
i] r]
>> map sine [0 30 90]
== [sine sine sine]

Including DO just makes it worse:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r do 
f i] r]
>> map sine [0 30 90]
== [make native! [[
        "Returns the trigonometric sine."
        value [number!] "In degrees by default"
        /radians "Value is specified in radians"
    ]] make native! [[
        "Returns the trigonometric sine."
        value [number!] "In degrees by default"
        /radians "Value is specified in radians"
    ]] make native! [[
        "Returns the trigonometric sine."
        value [number!] "In degrees by default"
        /radians "Value is specified in radians"
    ]]]

To make map behave correctly, I have to do something like:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r do 
reduce [f i]] r]
>> map sine [0 30 90]
== [0.0 0.5 1.0]
>> map sine/radians reduce [0 pi / 6 pi / 2]
== [0.0 0.5 1.0]

Is this ok and accepted behaviour? Will it break many scripts?
(Sorry for the long post, but I wanted to be precise.)

BrianH: re #1210 - "--import path" ... I almost everytime prefer 
the concept of "current directory". I hate systems, which pretends 
to be "installed somewhere", and then, working with stuff in different 
directory, still pretends the current directory is that of user profile 
or installed app. That sucks big time. I always prefer simplicity, 
or at least things to be settable ...

This seems to work for R3

>> map: func [:f l /local r] [r: clear [] foreach i l [append r do 
get f i] r]
>> map sine [0 30 90]
== [0.0 0.5 1.0]

But it ignores refinements like in sine/radians.

sorry, I did not look

carefully enough

BrianH: thinking about submitting 'Call function for fixes. I gave 
it some thoughts, and I think I am not satisfied with answer, that 
'call will be part of Open Host code - we are waiting for host code 
for 2 years, and there is no guarantee, that we will see it anytime 
soon. I think call should be fixed, or it is big let-down in comparison 
to R2. It messes with console in such a way, that it looks inconsistent, 
and its output can't be trapped easily. It might be a show-stopper 
for some ppl, in regards to R3 deployment. What do you think? Maybe 
it can be improved a bit? We are seening good changes to many natives, 
so why to wait with call for host code release?

Speculating about set- and get- datatypes in relation to:
http://www.rebol.net/cgi-bin/r3blog.r?view=0229#comments


In R2, we have get-word!, set-word! and set-path!. R3 brought us 
get-path! too. Is it a good idea to have things like get-paren! and 
maybe even get-block! and set-block! ?

Carl's set-word! in a block problem could be solved with:

user: [name: "Steve" age: 38]
user/:(age:)


About get-block! and set-block!, today we can set many values with:

set [a b c] [1 2 3]

Why not just write:

[a b c]: [1 2 3]

And a get-block! like:

:[a b c]

should return a block with values like

reduce [a b c]

Just thoughts.

user: [name: "Steve"  age: 38  country: France]
I just have a question. 
How Carl knows my Vital record...

hahahaha

[a b c]: [1 2 3] and :[a b c] , very nice, very rebolish 8)

you really think he meant you?  you're giving yourself to much importance 
 ;-p

Did you noticed that too ?

I did actually hehehe

About set-block and get-block.

If it's only to save the use of SET and REDUCE, i think it's a little 
luxurious.

It would have to work like set-word!s for contexts, to have more 
meaning. Could save a line of code.

I don't see your point Henrik, can u give an example

context [
	foo: fum: none
	set [foo fum] 3
]


'foo and 'fum stays in context with the NONE line. Without it, they 
don't.

...
it's not a good example ;-)
i do this, context [foo: fum: 3]

whoops, I meant like the get-block example above.

set [foo fum] [3 5]

could also reduce the size of some object specifications:

ret-value: [test 7]

make object! [
	[fnc arg]: :ret-value
]

you can with R3
>> set c: construct [a: b:] [3 5]
== [3 5]

>> c
== make object! [
    a: 3
    b: 5
]

or more generally: it can occur often that you need to set multiple 
words sequentially. there should be a syntax for that.

steeve, contexts usually contain much more than that, so CONSTRUCT 
is very limiting here.

it works with CONTEXT too

set c: context [a: b: none] [3 5]

same problem

To me EEBOL is about syntax, and the get block set block idea seems 
very interesting.

what happens when you say:

[a [b c]: d]: [1 [2 3] 4]

very rebolish, but is that very usefull ?