World: r3wp

Ok, I will try it.

screen -d -m /path/to/rebol args

thanks Grbriele

you're welcome

My system is developed in R3. To be honest with you, they don't like 
it. Now with the launch issue, they have more reason to complain 
about REBOL.

well... it is daring to do anything with R3 at this point... :)

Thanks Gabriele, your method with screen seems to work.

I know R3 is still in alpha. I just love it too much.

i can't blame you...

Gabriele, you are a life saver. I was arguing with the admin just 
a few minitues ago, now the problem is gone with your method. Thanks 
to you. I owe you one.

Thanks to Peterwood too. Maybe REBOL should have the spawn function 
too. :-)

UDP is not supported in R3, right?

Poste two blogs: Some experience with R3 extensions & TCP sequence 
diagram. See:
www.robertmuench.de/blog

Robert - post your Extensions blog article to Extensions group in 
R3 Chat, for Carl to notice. Maybe he will get some ideas for further 
enhancing/simplifying work with Extensions ...

Robert - btw - wrt port/device signalling - http://www.rebol.net/wiki/TCP_Port_Details

Nobody has written a UDP scheme for Rebol3 yet. I believe at the 
moment the only comms scheme is http.

We can't, it has to be coded by Carl or someone with the source because 
of the API calls.

or via an extension

Via the host code, actually. We can't do device extensions yet, but 
we can ad device types to the host code.

How good is the current networking implementation in R3?  Any notable 
bugs?  I'm looking to build a OPC Server in R3.

OPC?

http://www.opcfoundation.org/

http://www.opcfoundation.org/Default.aspx/01_about/01_whatis.asp?MID=AboutOPC

well, ports appear to have bugs, but are largely feature complete. 
the "problem" is that they are untested.

where's the port code placed? Host code, or kernel?

what do you mean by port code ? it's hard coded

I mean C layer to port code ....

Henrik, any of those bugs that are notable?  Someting significant 
enough to possibly deter development?

The ones that are found are in Curecode.

thanks Henrik.

The code that implements the port model is in the kernel. The code 
that implements the individual device types is in the host code.

The port scheme code is mezzanine, though the ports implemented through 
devices only have stub mezzanine code.

Since a device is by its nature an interface between R3 and some 
external thing, such code wold always be in the host code. Or later 
in a device extension, once we get those.

Carl's a bit silent lately. I wonder if he is working on new website, 
or continuing his work on Host Kit ....

Or enjoying Christmas :)

yes, that might be, an eventual option :-)

Does anybody else think that the news of the new Rebol 2 release 
and especially the inclusion of SSL has significantly raised the 
bar on a R3 beta?

I don't think so ... REBOL is in such a bad public acceptance shape, 
that releasing SSL and ODBC will not imo help. At least not to bring 
new ppl. But - you might be right, that it might a bit encourage 
current rebollers ...

should have been done a couple of years ago

PeterWood, no the new R2 release hasn't raised the bar for the R3 
beta - that bar is high already. The beta will still be released 
with the features it was going to have before. The rapid release 
model means that there will never be such a thing as a "final" feature 
set - the feature set will always be the current one, with more to 
come. The first release will not have feature parity with R2; some 
features will be better, some not there yet.

So you know target feature set for 3.0 beta? The feature-set was 
outlined in project-plan document, which is not however being a guideline 
anymore, and I think it never was ....

PeterWood, no the new R2 release hasn't raised the bar for the R3 
beta - that bar is high already. The beta will still be released 
with the features it was going to have before. The rapid release 
model means that there will never be such a thing as a "final" feature 
set - the feature set will always be the current one, with more to 
come. The first release will not have feature parity with R2; some 
features will be better, some not there yet.

Sorry, I didn't realize that post had gone through - it just showed 
up.

Pekr, I don't know the whole target feature set aside from what's 
in the document. However, I do know that SSL and ODBC are nlikely 
to be added for the 3.0 beta release for significant practical reasons. 
The R2 release doesn't change that because R2 already had that code, 
and it's not at all portable to R3.

nlikely -> unlikely

I would like to see Extensions and Host code finished to final state 
(it means support for devices, vectors, callbacks, etc.), and concurrency 
added too, or it imo has no sense to call it a beta ...

Rapid release model, remember. There's no such thing as a final feature 
set. Beta means that what is there is expected to work.

Nonetheless, extensions and host code in a more usable state is likely. 
Concurrency less so for the 3.0 release - concurrency is a big issue 
that needs more review, particularly once the subtleties of the model 
are well known enough to make the mezzanines task-safe.

Task-safety will require a full code review, natives included. Probably 
some adjustments to the system model and module code too.

And in the meanwhile, R3 is usable for some purposes now. More so 
with some bug fixes. It will be time to go beta soon.