World: r3wp

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 :-)

(I have a linux box with Fedora 1, but R3 does not work there)

I mean that there should be a header output function that is loaded 
in the CGI module. HTTP header format is cross-platform, even down 
to the line endings. The header output function could be mezzanine.

By the way, the line endings are supposed to be CRLF, even from a 
web server running on a Linux box. It's the standard.

What do you think about CGI module or any such special modules - 
would you make some of them default part of the distro, just modularised? 
Or you want them to be external? I think that CGI is basic functionality, 
which should be included in default distro, just with better support 
for sessions, not just decode-cgi, read-cgi ...

CGI is a part of the default distro for R3 when used to run CGI apps, 
but completely useless for other apps.

Session support is specific to the web server - the CGI standard 
doesn't handle them at all.

External

 doesn't mean it won't be built in to your particular copy of R3, 
 just that it won't be built into Henrik's GUI app.

R3 isn't going to be monolithic like R2.

I wonder how convenient such "build" tool is going to be. R2 encap 
was really very easy to see. I hope we will not push users to mess 
with C IDE, in order to build their R3 distro ...

Well, we were careful to design the module system so that you could 
specify requirements and relationships statically. This makes it 
relatively easy to adapt modules to a preprocessor that collects 
them into a single script, without necessarily needing special directives. 
This might make encapping easier.

I'm trying to build a svg converter (yes another one, but for R3).

As you can see here http://sites.google.com/site/rebolish/svg, it's 
pretty decent for the frogs (Rebol draw version at right)
But for the lizard, there's missing something, gradients.

But i'm stuck with the speciifications of grad-pen http://www.rebol.net/wiki/Grad-Pen

I don't  know how to build it from http://www.w3.org/TR/SVG11/pservers.html#Gradients

If someone can decipher that...

can grad-pen do all the properties of SVG gradients that you need?

I think so.
The only remaining problem will be the transform attribute.

They can apply a matrix to transform the gradient. But we don't have 
that, as-is in Draw.

We can apply rotate, scalling, and translation (i guess) on gradients, 
but separatly, not as a matrix.

I think we should ask Cyphre, whether this property can be added.

unless it's possible to perform the transformation prior to stating 
the grad-pen.

Do you mean, taking the matrix and extraction the different components 
(rotation, translation, scaling) ?
I don't know if it's possible, i'm not good enough with maths ;-)

I think it's possible to transform the gradpen alone before stating 
the shape to fill, but I haven't tested it.

I have one curiosity: REBOL3 VID is going to be an old style 2D interface. 
New interfaces, expecially for mobile device are PSEUDO 3D and touch 
based. Could this kind of interface be inplemented to support current 
and future generations of  products ?

yes, both touch and 3D are possible.

Btw, doing my SVG renderer with R3, i can't convert my drawings into 
images, it's crashing.
Using the draw function or to-image as well.

I can post a bug, but i don't know what's the problem because it 
depends of the drawing. Sometime it crashs, sometimes not.

there are a few specific things, even in R2 which cause the render 
to crash outright.

Actually,  it's not crashing the interactive rendering. it's crashing 
the to-image conversion.
So that, we can't save our drawings as images.

that is strange... never had one without the other in R2... although 
in R2 if you put the to-image call in an attempt and the effect was 
invalid (and would usually cause a rebol error), that face will never 
render again, whatever you do with it... is stays in a corrupt internal 
state.

might be based on the same very core handling of view.

note the above effect doesn't happen in all setups, but I've had 
this happen to me in an earlier version of my image expression application.