World: r3wp

r to reply, not p, but yes.

It you do p, you post in the header you are in (you can tell which 
that is from the prompt).

after "n", my prompt is: "pekr:>>" - so where actually I would post? 
:-)

Yeah, that's an annoying bug :(

It's why I always go somewhere on purpose, either by typing  in the 
header number manually or reading a message on the subject.

Brain - what is holding you back now from integrating your module 
changes? :-)

I've had a week of dealing with personal/family stuff. Some of us 
don't have blogs/twitter :-/

no problem with personal stuff. I meant it other way - if you are 
waiting for some other Carl's fixes, or is it your turn? If it is 
your turn, it will come, week or two sooner or later, who cares, 
just take your time :-)

It's my turn - I only had one unexpected factor, and it doesn't depend 
on Carl's work.

Brian - as for #706 - how is rebol.r placed in system/options/home 
more secure than having it in current directory?

Is this a bug?
blk: [a: 23 b: 34]
to-object blk
** error - invalid argument
make object! blk
== make object! [a: 23 b: 34]

What's the difference between the make and to functions?

TO does conversion, MAKE does construction.

As for bug#706, it's a file permissions thing. You can set the permissions 
of the directory that REBOL is installed in, so that only authorized 
users can write to it (generally, only the administrator). This means 
that %rebol.r can't be written by untrusted scripts. If you let %rebol.r 
be loaded from just any diirectory, regardless of who has permissions 
to write to the directory, then you have enabled %rebol.r to be used 
as a malware installer.

well, any "system friendly" (=somewhere deep shitty path) placement 
is VERY uncomfort for me :-)

I will have to think about it, but if you think about script's current 
dir = user has already right to place script there, why should placing 
user.r there be a security violation? Well, truth is, that most of 
the time I am local admin, so my knowledge is limited here ...

The %rebol.r file is only meant to be used by the person who installs 
REBOL, for the purposes of adding custom stuff that is specific to 
a particular computer. Loading standard libraries will be handled 
by the module system instead. This is the same reason why we are 
planning to replace %user.r with a preferences file.

I will not use any system, where any of my files resides outside 
my current dir. I hate that, and imo this is fatal design error of 
last century :-)

Then put REBOL in your current directory too.

I hope R3 does not need to be installed at all. I use flash disk 
all the time - Total commander, XnView, Miranda - no installation. 
I can tell you - sometimes in the future, there will not be any installation 
process at all :-)

yes, REBOL in my current directory ...

No install needed. The whole %rebol.r concept is meant for use by 
sysadmins who want to control what programs can be run on their system 
- there is even a Windows Policy that lets you limit which directories 
programs can run from. Regular users would never use %rebol.r at 
all.

In general, if I were a sysadmin, I would not load any functions 
in %rebol.r - I would just put a call to SECURE in there, to limit 
access to my resources. This would help me lock down my user's scripts. 
I wouldn't use %rebol.r at all for user's personal computers, just 
for public-use computers.

bbl

%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.