World: r3wp

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.

Finally implemented http://curecode.org/rebol3/ticket.rsp?id=637
thanks to a bugfix in alpha 108.

Congratulations

My dreamed feature is to have a release, instead of a not-for-distribution 
- which effectively doesn't exist

Please reconsider http://www.curecode.org/rebol3/ticket.rsp?id=1734.

Checking... I thought it was still open.

Added clarification. Changed bug status.

Thanks.

The question is what a script writer should do.

And I guess the answer is always using QUIT/now/return.

No, you don't want to do that.

The example script you gave is valid: for what you've written, I 
consider there to be a bug.

Can we have this particular bug fixed in A110 :) ?

I need a reliable way to QUIT with a return value from a script. 
But I do not know how this script is called.

Fixed in A110.

Great!

A friend of mine is asking about support for IPV6 addresses in REBOL 
3. he figured that REBOL 3 would have to support 128-bit numbers. 
I told him that there might be a separate datatype for it, but would 
it possible or would there a different way?

We can keep the addresses in strings, and the decoded addresses in 
binary data, and then make R3 support IPv6 without syntax changes 
(except to the URL parser). In theory.

my friend was interested in comparing address ranges, which was why 
he wanted to map them to 128-bit numbers.

If the addresses are stored in binary then the comparisons can be 
done on the binary values. Almost no system that supports IPv6 has 
or uses 128bit numbers.

ok

Almost no system = no system at all that I am aware of, but maybe 
there are mainframes or super computers out there that use 128bit 
numbers and have IPv6 support :)

Hey, the VAX had 128-bit integers, IIRC :)

perhaps this could be used: http://gmplib.org/

(he keeps asking for large-number support :-))

Andreas, coincidentally, he owns and actively uses a VAX :-)

Hehehe. Well, that's probably where that comes from :)

Do I recall correctly that there was a reason tuple! values couldn't 
be extended to 16 slots? I don't know that it's a great idea to map 
IPv6 addresses to them, or the feasibility of adding an ipv6! type. 
A utype! may be good enough, but I don't know how those are going 
to work either.

I use VAX 6151 SX - http://www.simsim.lv/published/publicdata/WEB59DB1/attachments/SC/products_pictures/m_120311_VAX6151SX.jpg

:-)

If we go all out for IPv6 integration then we can do a utype or even 
a built-in type with syntax (utypes won't have literal syntax). But 
we don't need to do that to get IPv6 support; we can get that now 
using the existing datatypes and some functions to work on the data, 
in theory.

yeah, as long as the functions know its an ipv6, there's nothing 
stopping us... in the end, its only bits  ;-)

Brian, You meant the vtypes not the utype, aka "the virtual types"
Huhu...

No, I meant utypes. That utype! datatype is short for user-defined 
datatypes, a planned feature (for R3.1). But literal syntax for utypes 
is *not* planned.

(I think Steeve was joking about utypes still being some virtual 
concept... after years of talk... ;-)