World: r3wp

BrianH: did you know about the 'evoke function? :-)

Only of its existence, not how to use it.

evoke 'someword gives instructions

it is now clearer, because of my stack-size request ...

I had to put new ticket there though, as we need stack keyword for 
secure ...

secure none
evoke [stack-size 1000000]

I don't like the entire removal of security in order to be able to 
raise the stack. We need secure [stack allow] or even better secure 
[stack 1000000], and in such a case evoke is not needed ...

Apart from that, I don't regards #1252 to be solved. Carl just allowed 
the stack to be settable, but he left default value to be at 1/4 
of the R2 value. 4009 recursion stack limit? Come-on ...

Secure evoke.

Secure evoke? Yes, if 'evoke will be used for some other magic things 
than setting the stack :-) I wonder what is its another usage :-)

A suggestion, not something that yet exists.

I know - you might add it as a comment to #1259

it is maybe better than secure stack ...

as for Console2 - but that is gfx console, no? Will it work on terminal 
set-up?

R3 is targeted at low-memory applications as well.

Think about it: Even on a high-memory system, you might have dozens 
of concurrently rnning R3 instances, particularly once we start compiling 
ouur own hosts. Maybe hundreds. Memory adds up - better to start 
small.

Does raising the stack to 1mil for e.g., consumes much more memory?

Yes, much more.

Hmm, more on evoke:

>> evoke '?
Flags: crash-dump delect watch-recycle watch-obj-copy crash

... so its help is not adapted to reflect stack-size parameter. Will 
CC it ...

BrianH: I DDed Console2 - how can I make R3 to open in the Console2? 
:-)

You can't, because it unnecessarily allocates its own console, as 
I noted before. To be fixed.

hmm, but even if it would not - how do you tell to general app, that 
Windows has now new console available to be used?

I want to be able to run R3 from the *Windows* command line, not 
its own copy of the Windows command line.

You call the app from that console.

aha, so it just "switches" to >> prompt, and here we go - R3?

Running from the windows command line: that would also remove the 
side effect that a console would be opened, when starting a R3 GUI 
app from the desktop.

will it be difficult to fix? If not, we could get it for the beta, 
no?

Yup, just like Mac or Linux.

We should CC it, as a 'wish :-)

This would be trivial to fix. I even planned to fix it myself once 
the host code was released.

One thing I don't like under OSX/Linux is that you can't create a 
new console. A new instance is piped to the same console "melding" 
the two together, making them both nearly useless.

I like that effect - it's what makes CGI work on Linux.

it's not useful for end users, but of course I see your point.

And the lack of that effect is what makes CGI not work on Windows 
(in addition to Unicode issues).

I want to be able to pop up a new console if I need to, but it should 
be a GUI console and I should be able to pop up more than one in 
the same R3 process, in different tasks. Text mode console usage 
should use the text mode console.

I am curious about HOW do we actually fix the unicode issues. This 
might be more deep problem, that might seem. Because If I am not 
able to print in UTF-8, I need to first print the header, using some 
conversion, and then the content = the code is not easily cross-platform 
...

I'm OK with that, as long as you can debug a launched script in OSX.

isn't there 'launch for launching a new REBOL process? Messing 2 
consoles in one is a bit weird ..

No, but it doesn't need to be cross-platform - it's in the host code.

Pekr, it's not really weird. It's just how proper piping works. REBOL 
just doesn't pipe to a different console in those cases where we 
would want it to.

As for launch, that function needs a rework. It's not done yet.

BrianH: so what is the fix for the Windows Unicode related header 
print problem? ;-)

Make the shift in response to the --cgi option.

CGI output should be binary, and the headers output in 7bit ASCII 
(not UTF-8) through that binary output.

--cgi option is not working now, or is it?

Any encoding is none of the business of the CGI channel - it is a 
matter between the script and the cliennt.

As to your remark - I wonder, how R3 itself decides, what is, and 
what is not a header :-) You probably mean, that I have to be responsible 
for the conversion?

The --cgi option is not working on Windows. It works on Linux.

That should be fixed, no? :-) I want to start to do some tests with 
CGI, and no will to mess with Linux here :-)