World: r3wp

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.

I think you should stick to announced release dates. Better axe some 
features than not to deliver

Especially when the features can be added later. The rapid release 
model means that "later" releases are still coming soon :)

what about a sum or product functions for R3?

>> sum [1 2 3]
==6

Suggest them in CureCode as wishes. Or write them up as mezz or extension 
functions - those are easy to adapt.

will do when I get the chance.

I'm all for it. I've suggested them in the past, but didn't get much 
traction. Here's a non-recursive starting point.

    ; Should our seed value be 0.0 to coerce to decimal? If they
    ; include a decimal value before any overflow, it will be OK.
    ; Changed to match the first type in the block.
    sum: func [block [any-block!] /local result] [
        result: any [
            attempt [make pick block 1 0]
            attempt [0 * pick block 1]
            0
        ]
        foreach value reduce block [result: result + value]
        result
    ]

I just added the wish request.

Why the coersion to decimal?  Just curious.

Should sum [] return 0 or none?

well, if only the default math operators could accept series of scalars 
by default, it would be incredibly simple and powerful.
It should not be so hard to have that behaviour nativly...
A + [1 2 3 4] == A + 1 + 2 + 3 + 4

Vector math has already been suggested.

yep, but we are always waiting

Coercion to decimal would be to prevetn overflow. I prefer not to 
do that though.

Zero versus none is a good question Brian. I have SUM return zero, 
but my AVG func returns none.

0 seems better, it prevents throwing useless errors
(my old claim)

We might not need to coerce to decimal. The first decimal in the 
list will make that coersion for us. And we don't want decimal results 
for a list of integers - it's a loss of precision. I suspect that 
initializing result with the integer 0 will be sufficient.

Then any decimal or money in the list will promote.

Agreed. The only issue is if you don't get a decimal value before 
an overflow occurs, but that's just something to doc.