World: r3wp

Wow, that must be the error Brian mentioned.

I assume you tried the RT binary A107?

Would you be so kind and try http://bolka.at/2010/rebol3/r3-a107-20100913.exe
instead?

RT binaries are built as GUI apps, the above is built as Console 
app.

Pekr, we found that error too and fixed it for the next release.

A109 for Win32 released:
http://www.rebol.com/r3/downloads/r3-a109-3-1.exe

launch from cmd.exe is fixed. Although I would like to see R3 to 
reuse cmd console, if it does not include GUI ...

Pekr, did you try the custom-built A107 binary I linked to above?

not yet, let me try ...

:-) http://xidys.com/rebol/r3-console2.jpg

I can even start view scripts ;-) I suspect it being so, because 
view is not externalised? So could we now conclude, that from now 
on, R3 could be built as a console app?

Yes, it is a "View" build.

And yes as well, until R3 gets an R2-style REBOL console, building 
it as Win32 console executable might be worth it.

However, ChristianE hat some problems with Unicode in combination 
with console builds, IIRC.

had*

Not sure what that was about though. Maybe Christian remembers, otherwise 
I'll have to recover the lost !REBOL3 Hostkit from backup.

yes, you can see in the screenshot, that czech locale is not correct 
...

from my experience, if I build R3 as 'console app' the win console 
(the way it is handled now)  doesn't render characters in unicode. 
So far I haven't found a way how to fix that (and after brief googling 
the net it looks this is known issue)

that's bad :-(

Cyphre, Andreas, that's what I was seeing, too. Build as console 
app --> no unicode chars displayed, build as gui app --> unicode 
chars are fine, but you can't run in a console window. I don't know 
what other languages are doing or if there is a way to fix this at 
all. From the information I gathered back then, I'd say, probably 
there isn't.

imo, for the 'console app'  version you would need to use different 
approach...detect if the process already have console attached and 
the reuse it. But I  haven't looked into any details so it is possible 
even this won't work well.

Cyphre - we are already reusing the console (I mean - Andreas, I 
just do some tests). We can even get czech chars displayed, byt typing 
czech chars firing enter quits R3 ...

ok, that is in the 'console app' mode....sorry I meant that there 
might be a way how to check if the 'GUI app' is run standalone or 
from console and then decide what approach to use. But I haven't 
tried to play with it yet.

yeah, that would be interesting.

unfortunately there seems to be no way for a GUI app to keep an association 
to the console it was launched from.

you can try to attach to the console of the parent process, but carl 
seems to have tried that and it is now disabled for some reason.

well, needs further investigation :)

The reason was the blog article I posted - see the comments ...

http://www.rebol.net/cgi-bin/r3blog.r?view=0282#comments- so those 
are the problems Carl faced ...

in any case, i fear the console on win32 is mostly a lost cause :)

I haven't given up on it yet :)

I see there's no Linux release beyond alpha 107, so I can't do any 
testing

They are working on Linux and host kit issues now (for European sleep 
schedule values of now).

Don't worry, I'm more aligned with US sleep schedules :-)

The mix of mutating and non-mutating series functions sometimes really 
is maddening. Not to mention the uglyness of the resulting code.

MAP-EACH copies, REMOVE-EACH modifies, SORT modifies, UNIQUE copies, 
... yuck.

yes, I agree, but therefore it needs to be clear which function modifies 
and which one does not:

? modifies

Yes, that's fine.

Doesn't beautify the code or make it less maddening that does pieces 
do not fit together nicely.

those*

I also think we could use a document that states why some of the 
functions modify and some copy. I had a longer discussion about UNIQUE 
recently.

? "(Modifies)" will be a great start to write a always-copy overlay 
module.

For those who worry more about elegance and conciseness than about 
performance ...

That can be a doc string convention and it would work just as well. 
We have already put (modifies) in a lot of doc strings.

However, a better convention would be to put (modified) on the doc 
strings of the particular parameters that are modified. Some functions 
modify only one or two of their parameters, not the rest.

Consistent application of this convention is key here, or else HELP 
won't find them.

We should consider this to be a requirement for the multitasking 
project, since using the modifying functions can be tricky when multitasking.

Is there a reason MAP-EACH copies?  Wouldn't it be faster if it modified?

Certainly an option. But that are not the semantics one usually associates 
with "map". In that case, "change-each" would be a much better name.

MAP-EACH that modifies would be FOREACH. Generating a new block is 
the entire reason for MAP-EACH.