World: r3wp

I'm all for anything that moves us forward, but solutions like cURL 
and CALL via an extension means I know I'm going to have to change 
things later, or live with more pieces.

And it can't be called alpha or beta.
 ?

CALL via extension should ideally not require any changing later 
on.

I guess I assume Carl has a prioritized list already. :-\

We can fix CALL - it's in the host code.

Ideally, yes. :-)

Carl's priorities may not match those of us in the real world

I'm assuming his main priority is for people to use R3

If it's not,everything else breaks down

We need a prioritized list of stuff that we need Carl to fix. The 
rest (mezzanine and host) we can do ourselves.

Brian, for deployment purposes. Running production services on something 
listed as Beta doesn't fly. If anything goes wrong, labeling matters.

It doesn't matter if Google gets away with it. :-)

Do we need the alpha/beta label removed for just the r3lib changes? 
It might be worth labeling as a separate product, so we can work 
on the host/extension stuff ourselves.

I narrowed down 1825/1865 to the minimal code. I'll comment them 
accordingly.

Tried on Linux or OSX as well?

(Just privmsg me and I can try it quickly.)

I rewrote http://issue.cc/r3/1865to match the real cause. Here's 
the code:

    resolve/extend/only context [] context [a1: a2: a3: a4: a5: a6: none] 
    [a]

If you all would try it on other platforms than Windows, that would 
help. On Windows you need 6 or more words in the source context to 
cause the bug. If that number is different for other platforms, it 
would be helpful to know.

Crashes on Linux and OSX as well.

The names of the words don't matter, nor does whether the word in 
the /only block is one of them or not. There needs to be at least 
one word in the /only block to crash.

But it's not "6 or more", it's precisely 6.

Maybe even multiples of 6.

Nah, appears to be basically random.

Well, thanks for reducing it.

Please note this in a ticket comment. It might be related to the 
sequence. In a fresh console on Windows, 6 will work every time.

6 works on Linux and OSX on a fresh console every time as well.

7 crashes both after the third call.

so its probably heap corruption.

Updated the description related to the number.

Certainly looks like a memory corruption issue from the outside, 
yes.

Will be much easier to pin down from the inside.

The heap corruption might be the cause of #1207 as well.

Sorry, I meant #1806.

Where exactly is one supposed to store user specific data for scripts 
eg. userid and passwords

for esmtp etc

We've talked about it before. It isn't defined yet

Is this something we can define then?  Reach a concensus?

Probably

Anyone with a suitable suggestion?

I'm suggesting a couple of wrapper functions to return userid and 
password etc so that these can be changed if the store system changes

That's a good principle

The only consensus we reached was that %user.r would be a good place 
to store preferences, and that it should only store data. Executable 
code would be prohibited in %user.r, and screened for. But we never 
started the discussion of how the preference data would be formatted 
or managed.

The no-executable-code thing is a security issue. R2's treatment 
of %rebol.r and %user.r is a big hole.

So, do we have a plan .. ??

Andreas is collecting blocks ..

These settings shouldn't go into system/user in R3, they should go 
in system/options/user. The system object will be task-specific, 
but the options are probably going to be global. And system/options/user 
might best be a map!, with categorized options in sub- maps, blocks 
or objects, depending on the situation. Or better yet just sub-maps, 
with the serialized preferences in blocks of name-value pairs so 
they can be parsed, and converted to maps at runtime.

system/options/user: make map! [
    category1 #[map! [
        option1 "value1"
        ...
    ]
    ...
]

Two-level category-options, and then the values could be any type 
you want. Screen thoroughly for evil values.

The %user.r serialization of this data should be human-writeable 
and loaded with LOAD, not DO.

The advantage to serializing directly in SAVE/all form is speed. 
The disadvantages are:

- The preferences file would be uglier to write by hand than block 
form.

- You would have to screen with ASSERT/type in FOREACH instead of 
PARSE.

But the slowness of validating would be offset by the speed of loading 
and saving, so it might be worth it.