World: r3wp

Ehm, because it word! and not logic!, ignore it.

>> switch true [#[true] [1]]
== 1

Carl show back... but not with some R3 movement only with R3 environment 
stuff: web-hosting, project page, ... I don't know why...

but it doesn't move us forward. As long as we don't get R3 out-of-the-door 
I don't need a R3 project page.

Looks like he needs a project manager

Another activity, which actually helps nothing ....

There is one thing, I hardly understand.

It was said, that he wrote R2 in a very short time, as he was not 
satisfied with R1.

Now he has the the experience with two shots, he has got a community 
with people ready to help and knowing his intentions and experience 
too.

What happens?
It fizzles out ....

One has to take the help, give some control away, live with the fact 
that not 100% will be as if you would do it yourself. But that's 
how woring in a team / with others is.

The benefit? It scales better than on person.

(wow several typos in just three lines...)

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

Looks good so far. One complaint: In the binary conversions section, 
R2's struct! type is mentioned, then it says "Something similar is 
needed in R3". Please, no, at least not for conversions.

Each of those pages needs to point to a page on rebol.net's wiki 
so we can edit them

of those points ...

Yes

Each of those pages should have something like:

Lead: ..
Members:
Completion Status: ...
Discussions: altme web link
Repository: ..

or similar

which means removing the lead and status fields from the projects 
page

No, duplicating that info on the projects page is fine. If someone 
is willing to do the work, they deserve to be recognized.

Think of the projects page as a summary.

Eh?  I'm talking about redundancy ...

unless the projects page is dynamically generated it will get out 
of sync rapidly

Right. Redundancy is fine on a summary page.

Disagree ..it must means more misinformation we don't need

The lead and status won't change that often.

That's because everything goes so slowly ...

I don't have that expectation in the future

The purpose of a summary page is to allow people to get a quick overview 
without having to go to the detail pages if they don't need to.

The lead and status summary are exactly the kind of details you want 
there.

So, use parse and extract that detail and put it on the summary page!

Can you imagine Carl is going to maintain the summary page??

Fine, but I don't expect the details page to have a summary of the 
status, I expect it to have a detailed status. If you are expecting 
projects to have a lot of activity, is it so implausible to imagine 
the projects page being maintained?

Yes, because they're different sites and different people.  We know 
Carl is the only one with access to rebol.com pages and history tells 
us he can't maintain them.

We know that Carl being the only one with access to rebol.com pages 
is considered by Carl to be a bug in the permissions system of the 
rebol.com site, and that he is working on it.

People with sufficient rank in DevBase are supposed to be able to 
edit some pages.

Of course if that is abused, they lose the rank.

Is anything being done to support proxies?

nothing is done to support anything, imo :-)

what I like though about the project is the specific one - Codecs 
being reworked from functional to port model, to better support streaming 
:-)

Does proxy support require work at the C level?

I think not necessarily. R2 supported proxies (at least some proxies) 
too. There was an idea to have networking protocols use OS specific 
layers. That would still be imo a possibility.

fromt he priorities page: "Text codec project has been deferred due 
to community input. The project will be reorganized to make codecs 
into a port datatype and allow external codec devices as well as 
streaming (with port's holding the steam state.)" ---- I really like 
it :-)

Announcing the availability of the http://www.rebol.net/wiki/Pair_enhancements
article. Discussion welcome.

As it looks, due to the efficiency issues (speed), the implementation 
of REBOL pairs as pairs of floats looks to be the fastest (since 
AGG needs double values, and conversion from float to double is faster 
than conversion from integer subpixel count to double using a foating 
point division looks slow)

So, everybody opposing this pair implementation change: please speak 
now or remain silent for long time...

Ladislav, you need to put the AGG implementation considerations on 
that page. The page currently looks like you are advocating using 
48bit integers, not floats.

OK

You might even be able to use doubles on 64bit builds of R3, due 
to the need to have larger value slots.

has it been already settled how big the available space is? (in 32-bit 
version we have 96 bits at most, as it looks)

Some of the value types require 2 pointers. On a 64bit build, pointers 
are the same size as doubles. It's an internal matter anyways.

So it looks like 128bits are available.