World: r3wp

R3 win console: Thanks for everyone who tested. So it looks it works 
for you, cool. Note that the character output should be correct but 
the default console font doesn't support all the chars. You might 
try to use Lucida Console font in the console properties which should 
give you more(but not all) valid characters or get some other unicode 
capable console font from the net...

Fork.... earlier discussion of INF is here:

   http://www.rebol.org/aga-display-posts.r?offset=0&post=r3wp771x5711

As Brian says, best place for any proposals for Carl to consider 
is here:
    http://www.curecode.org/rebol3/ticket.rsp?id=1717&cursor=1


The range of possible approaches extend from INF always throws an 
error to INF is a first class value. Somwhere in the middle is INF 
acting like UNSET! -- something you can use, but must be handled 
with great care.

...approaches extend from INF always throws an error to INF is a 
first class value. Somwhere in the middle is INF acting like UNSET!...

 - I do not think this describes the situation. I see it differently, 
 thinking, that there are only two consistent alternatives (the current 
 state is inconsistent, as everybody agrees with):


1) inifinities are not REBOL values (this state existed before FP 
pairs were introduced). I am pretty sure, that the description "INF 
always throws an error" is misleading, exactly because such a value 
does not even exist in REBOL


2) infinities exist in REBOL. In this case, they have to be "first 
class values", but, of course, they are not handleable by all functions, 
since e.g. +INF + -INF is not defined

Infinities seem to exist only by accident right now: the two known 
methods of generating an INF could be declared by Carl as bugs, and 
all INFs banished.
Or they could be fully REBOLised in ways that we find useful.

It would be interesting to know:


- what is the popular demand, i.e. which variant is preferred by 
the majority
- what are the reason for such preference

As far as I am concerned, I slightly prefer 1), just since I already 
got used to it in R2.

(I have no large objections to introduce infinities to the decimal! 
datatype, though)

I really dislike having to support infinity.  it might be sexy for 
scientific stuff, but rebol doesn't have the scientific or statistical 
math muscle to make that any more viable than trying to support complex 
& imaginary numbers as first-class types.

supporting infinity opens up a can of worms IMHO.  if one really 
needs to do heavy math stuff, its probably better to use C and professional 
math libraries via an extension.

I almost agree with Maxim here. I think there should be a clear definition 
of REBOL 3 math *can* and *cannot* do. Leave the complex numbers, 
symbolic math and infinity to modules and extensions.

Actually, infinities, are not that much "scientific stuff" as it 
may look at the first sight. Anything you can do with infinities 
is not hard to do withouth them as well.

Nevertheless, since infinities are supported by IEEE754, it is actually 
(IMO) easier to have them in the language than not.

I mean "easier for the implementor of the interpreter", not more 
user-friendly, of course.

Cyphre - I re-tested with all possible special czech alphabet chars, 
and even with default font in console, it worked OK. Or was I just 
lucky, and your note was more general, e.g. that such a font can't 
support all possible chars in different than czech language?

BrianH: I just looked into Delayed extension note is CC - cool guru 
stuff :-) btw - do I understand it correctly, that unnamed modules 
will be named in module list, according to the filename? But what 
if there is unnamed module, which is not loaded from file?

Pekr, yes you are lucky because czech chars are present in the default 
font. Chars of other languages can have problems so they need the 
Lucida COnsole font or even better one.
The current situation of the win console is:

-we can have core.exe as 'console app' which will work as the 'prototype' 
I released for testing

-we can have view.exe as 'GUI app' which will always open own console 
window (even from cmd.exe)


(If we make the view.exe as 'console app' there will be always quick 
console window blink during execution where only GUI window is shown 
initially)

I don't like blinks :-)

Couldn't we just have view.exe, which is basically core with delayed 
View extension? That would not probably work, right?

same difference

first: it does not really matter for the graphics if the binary is 
compiled as console or gui app. keep that in mind

if, however, the binary is compiled as console app, a console will 
_always_ pop up (if if only for a very short blink).

so when you start view.exe by dropping a script which displays a 
rebol gui on it, you'll have a short blink of a win32 console before 
the rebol stuff launches. which is probably undesirable.

I don't understand the issue sufficiently. What I simply want is 
- messing with just one exe. Being able to either use it in SSH session, 
or from icon, including GUI :-) I know I tend to require too much 
:-)

way around this: compile view.exe as gui app :)

you can have that exe, but it'll blink

no blinks ... is MS so stupid to not allow that? Or is that behaviour 
identical to other platforms too?

nope, that's windows for you.

No secret switch for the console app to actually hide the console? 
:-)

if that switch exists, people spending way more time on this haven't 
found it :)

people within microsoft :)

This guy is somehow reusing dos console in GUI app, but maybe it 
is a different matter - it seems he is just redirecting the console 
to give it a GUI look? 
http://www.codeproject.com/KB/threads/consolepipe.aspx

read the comment timed "12:17 PM" below, that explains the situation 
clearly.

there's no 12:17

What about this?


It seems the problem goes away if I add on these two lines before 
ShowWindow(wcon, SW_HIDE)..
for(int i=0 ; !IsWindowVisible(wcon) 
&& i < 100 ; i++)
Sleep(10);

(ah sorry, fron post)

(wrong post!)

Pekr, unnamed modules stay unnamed, unless you load them by (word) 
name, not filename. They can occasionally have interesting unique 
properties.

OK, then it wasclearly my wrong guess :-) btw - how do you list unnamed 
modules in the module list then? or we don't? I thought that unnamed 
modules are auto-named according the file-name, but that would not 
be suficient anyway, as 1) one filename can contain multiple modules 
2) it still does not solve the case, when you create module e.g. 
in console manually ...

Pekr, Andreas is right. The problem is that the 'flag' if the app 
is of Console or GUI type is set at compile time. So when you execute 
file th Windows kernel just checks that flag and if set to 'Console' 
immediately creates console *before* the main() of your programm 
is called. So even if you put: ShowWindow(console, SW_HIDE); as the 
first command in your app you'll always see the console window for 
a while, which is not so nice ;)

OTOH if your app is of 'GUI' type and you execute it from CLI (for 
example cmd.exe console) the CLI automatically detaches your exe 
from the console so the cmd.exe propmpt is able accept next commands. 
This is also problem because even if you try to re-attach your GUI 
app back to the console from which it was started, the console is 
shared in paralel with the CLI process and your app. So in the best 
way you'll see two interleaved input lines...one fro rebol commands 
and one for DOS commands.

Unnamed modules (that stay unnamed) don't get listed in the module 
list. Instead, they get converted to private modules and get imported 
directly into the target context (system/contexts/user, or the context 
of the module that is requesting the import with its Needs header). 
Unlike regular private modules, if you import them again they aren't 
reused - you get a fresh module every time. This can be a useful 
property at times, so we kept it. We have done a great deal to make 
unnamed modules useful, and as a side effect even preferred in some 
cases.

Now Modules are here. A central repository is going to be created. 
Then GUI will be completed.

A question: what's next for REBOL ? Datatypes ? Will we go out of 
alpha then ?

tasking :-)

http://www.rebol.com/roadmap.html

There is still a lot of work haead. It will take 1 and half year...

Well, in last 3-4 month, look at the roadmap, and all those already 
completed things. Some VERY significant changes happened lately (host-kit, 
View transition to being fully external, modules, etc.)

You can always wait for the next release or until you have all dreamed 
on features. Whatevery product you use. It's about taking what you 
have and making the best from it.

in my opinion, R3 is already useable, apart from GUI, maybe pop, 
ftp, proxy support (nowadays I don't need it though), and ugly console 
:-)

Depends on your needs.

Actually what is stopping me from using REBOL3 is the lack of GUI 
and SQLite support but I have them in REBOL2 and I'll continue using 
it.

In REBOL3 I am only a spectator. I do not complain on the time it 
gets to be complete. I do not need the very last feature. I am passionate 
about the work you are doing on it. It is very hard.  It is nice 
to see you, genius, at work.